Torsten's Blog

ConfigMgr 2012 hat vor kurzem den RC2-Status erreicht (Build 7703) und kann hier http://technet.microsoft.com/en-us/evalcenter/hh667640.aspx heruntergeladen werden.
Vor der Installation im Lab lohnt sich ein Blick auf die unterstützen Konfigurationen: http://technet.microsoft.com/en-us/library/gg682077.aspx. Vor allem bei SQL ist die Auswahl relativ eingeschränkt: “SQL Server 2008 SP2 mit Cumulative Update 7″ oder “SQL Server 2008 R2 mit SP1 und Cumulative Update 4″. Die Auswahl der SQL-Edition bestimmt übrigens auch die Anzahl der maximal unterstützen Clients.
Zum Thema Collation gibt es bereits hier einen eigenen Artikel. Eine Aktualisierung von RC1 auf RC2 ist im Lab nicht vorgesehen. Hier muss leider neu installiert werden, was aber Dank der “Export”-Funktion einzelner Objekte (Applications, Tasksequenzen usw) nicht zu aufwändig ist.

Gestern hat Microsoft das neue Lizenzierungsmodell für die System Center 2012 Suite vorgestellt. Einfach gesagt gibt es nur noch 2 unterschiedliche Lizenz-Modelle: “System Center 2012 Standard” und “System Center 2012 Datacenter”.
Weitere Informationen gibt es hier http://download.microsoft.com/download/1/1/1/11128EC7-2BE7-480C-9D46-4ECECA9E481A/System%20Center%202012%20Licensing%20Datasheet.pdf, http://www.microsoft.com/licensing/about-licensing/SystemCenter2012.aspx und http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx

Für ConfigMgr 2012 muss unbedingt SQL_Latin1_General_CP1_CI_AS als server / database collation verwendet werden! Die Dokumentation http://technet.microsoft.com/en-us/library/gg682077.aspx ist etwas missverständlich. Man könnte meinen, dass dies nur für Hierarchien gilt, bei denen Replikation im Spiel ist (also CAS plus Primaries). Dies gilt aber ebenfalls für standalone primary Sites! Die Dokumentation wird noch angepasst.

Ab sofort ist auch SQL 2008 R2 für ConfigMgr 2012 RC1 supported. Es müssen allerdings SQL 2008 R2 SP1, CU3 für SQL 2008 R2 SP1 und KB2603910 installiert sein.
UPDATE: der genannte Hofix (kb2603910) ist mittlerweile in CU4 enthalten. Somit ist SQL 2008 R2 SP1 + CU4 ebenfalls unterstützt.

Eine große Neuerung von ConfigMgr 2012 ist das “application management”. Dies ist quasi der “Nachfolger” der klassichen Packages und Programs, welche man bereits von ConfigMgr 2007 kennt. Ich werde in einem kommenden Blog-Artikel mehr Details dazu verfassen.

Bei ConfigMgr 2007 war nur der Returncode des Programs ausschlaggebend für den Verteilerfolg. Returncode = 0 wurde dabei als “success” gewertet, alle anderen (RC <> 0) als Fehler. “Spezialfälle” wie “3010″ (Der angeforderte Vorgang wurde erfolgreich abgeschlossen. Änderungen werden erst nach einem Neustart des Systems wirksam.) sollen an dieser Stelle unbetrachtet bleiben. ConfigMgr 2007 ging also davon aus, dass das Program bei einem Returncode = 0 erfolgreich installiert worden ist. Die Rückmeldung eines Erfolgs- oder Fehlercodes obliegt aber ausschliesslich dem gestarteten Prozess. Es war / ist also gut möglich, dass ein Program nicht installiert worden ist, obwohl “0″ zurückgemeldet worden ist. Einfachstes Beispiel: Start einer Installation eines MSIs per vbs-Skript und “WScript.Quit(0)” als letzte Zeile. Somit wird immer Returncode = 0 an ConfigMgr geliefert, auch wenn die Installation mit 1603 fehlgeschlagen ist. Ebensowenig “wusste” ConfigMgr 2007, ob eine Applikation bereits auf dem Rechner installiert ist. Auch bei bereits installierter Software XYZ wurde die command line des Programs erneut ausgeführt.

ConfigMgr 2012 geht hier einen Schritt weiter. Im neuen “Application Model” sind die Applikationen “state based”. Einerseits wird vor einer Installation geprüft, ob die Applikation bereits installiert ist – andererseits wird nach Installation geprüft, ob die Applikation erfolgreich installiert worden ist.
Hier kommen die “detection methods” in’s Spiel. Bei msi-basierten Installationen wird standardmäßig der MSI Product Code verwendet um die Präsenz einer Applikation zu erkennen:

Dies hat zwei Vorteile:
- es kann vor der Installation erkannt werden, ob die zu verteilende Applikation bereits auf dem Zielrechner vorhanden ist
- es kann nach der Installation ermittelt werden, ob das Produkt erfolgreich installiert worden ist

Dies kann man im AppDiscovery.log finden (%windir%\CCM\Logs):

Entering ExecQueryAsync for query “select * from CCM_AppDeliveryType where (AppDeliveryTypeId = “ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494″ AND Revision = 2)” 
    Performing detection of app deployment type Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)(ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, revision 2) for user.
+++ Application not discovered. [AppDT Id: ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, Revision: 2]
+++ Did not detect app deployment type Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)(ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, revision 2) for S-1-5-21-4129626385-392748059-3710697109-1156.

Danach wird die Installation der Anwendung gestartet (AppEnforce.log):

+++ Starting Install enforcement for App DT “Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)” ApplicationDeliveryType – ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, Revision – 2, ContentPath – C:\WINDOWS\ccmcache\4, Execution Context – System
    A user is logged on to the system. 
    Performing detection of app deployment type Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)(ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, revision 2) for user.
+++ Application not discovered. [AppDT Id: ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, Revision: 2]
    App enforcement environment:
 Context: Machine
 Command line: msiexec /i “AcroRead.msi” /q
 Allow user interaction: No
 UI mode: 0
 User token: not null
 Session Id: 1
 Content path: C:\WINDOWS\ccmcache\4
 Working directory:
    Prepared working directory: C:\WINDOWS\ccmcache\4
Found executable file msiexec with complete path C:\WINDOWS\system32\msiexec.exe
    Prepared command line: “C:\WINDOWS\system32\msiexec.exe” /i “AcroRead.msi” /q /qn
Valid MSI Package path = C:\WINDOWS\ccmcache\4\AcroRead.msi 
AdvertisePackage [C:\WINDOWS\ccmcache\4\AcroRead.msi] – Created Temp File Name : C:\WINDOWS\CCM\SystemTemp\tmp1C72.tmp 
    Working directory C:\WINDOWS\ccmcache\4
    Post install behavior is BasedOnExitCode
    Waiting for process 2796 to finish.  Timeout = 120 minutes. 
    Process 2796 terminated with exitcode: 0 
    Looking for exit code 0 in exit codes table… 
    Matched exit code 0 to a Success entry in exit codes table. 
    Performing detection of app deployment type Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)(ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, revision 2) for user.
+++ Discovered application [AppDT Id: ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494, Revision: 2] 
++++++ App enforcement completed (191 seconds) for App DT “Adobe Reader 9.4.0 – Deutsch – Windows Installer (Native)” [ScopeId_63D8B365-0776-4B2F-BA8D-51ECF8B1677D/DeploymentType_171ce5f6-d343-4325-9f88-af75aece1494], Revision: 2, User SID: S-1-5-21-4129626385-392748059-3710697109-1156] ++++++

Wie man sieht, ist es essentiell, die “detection methods” richtig zu erstellen, denn der “Nachteil” ist: selbst wenn eine Applikation erfolgreich installiert worden ist, dies von der “detection method” nicht erkannt wird, versucht ConfigMgr 2012 immer wieder eine Installation!

Folgende Skripte können helfen, auf einfache Art und Weise die msi-Detection ohne ConfigMgr zu überprüfen und somit Zeit zu sparen (Vorsicht mit copy’n paste wegen straight/smart quotes in WordPress):

Skript 1 – GetProductCodeFromMSIfile.vbs – Liest den MSI Product Code aus einer msi-Datei aus

msiFile = “d:\Sources\Apps\Adobe\Reader9\AcroRead.msi”

Set objInstaller = CreateObject(“WindowsInstaller.Installer”)
Set objmsi = objInstaller.OpenDatabase(msiFile,0)

Set View = objmsi.OpenView(“Select `Value` From Property WHERE `Property`=’ProductName’”)
View.Execute
Set msiProductName = View.Fetch
  
Set View = objmsi.OpenView(“Select `Value` From Property WHERE `Property`=’ProductCode’”)
View.Execute
Set msiProductCode = View.Fetch

Wscript.echo “msi file = ” & msiFile
wscript.echo “Productname = ” & msiProductName.StringData(1)
wscript.echo “Productcode = ” & msiProductCode.StringData(1)

Skript 2 – ListInstalledMSIandProductCodes.vbs – Liest den MSI Product Code aller installierten MSIs aus:

Set objInstaller = CreateObject(“WindowsInstaller.Installer”)
i = 0
set Products = objInstaller.products

For Each Product In Products
 i = i + 1
 Productname = objInstaller.ProductInfo(Product, “ProductName”)
 wscript.echo i & vbTab & objInstaller.ProductInfo(product, “ProductName”)
 GetProductCode ProductName
Next

Function GetProductCode(ProdName)

 If objInstaller.ProductState(ProdName) <> msiInstallStateUnknown Then
 
 For Each productCode In objInstaller.Products
  If LCase(productName) = LCase(objInstaller.ProductInfo(productCode, “ProductName”)) Then
   GetProductCode = productCode
   wscript.echo vbTab & GetProductCode
  
  End If
 Next
 Else
  wscript.echo vbTab & “NOT FOUND”
 End If

End Function

Migriert man ConfigMgr 2007 Packages und Programs nach ConfigMgr 2012 so resultiert dies wiederum im gleichen Objekt-Typ, nämlich: Package/Program. Somit sind die Vorteile des neuen App-Models nicht zu nutzen.
Microsoft stellt jedoch ein Tool zu Verfügung (in der RC1-Version als separater Download), welches bei der Konvertierung von Packages/Programs zu Applications/Deployment-Types unterstützt: der Package Conversion Manager (PCM). Nach der Installation findet man diesen in der AdminUI unter Software Library -> Overview -> Application Management:

Eine Analyse oder Konvertierung einzelner oder mehrerer Pakete kann über die Schaltflächen “Analyze Package”, “Convert Package” und “Fix and Convert” gestartet werden. Diese findet sich im Ribbon bei Software Library -> Overview -> Application Management -> Packages:

Eine Übersicht (Dashboard) über die Analyse- und Konvertierungsergebnisse stellt den aktuellen Fortschritt übersichtlich dar:

 Durch die Änderungen an der ConfigMgr-Konsole sind manche Dinge beim ersten Mal nicht mehr ganz so einfach oder intuitiv zu finden.

Ein Beispiel dafür ist die Installation eines PXE-Service Points. Hierfür gibt es keine separate Rolle mehr, da dessen Funktionalität in die des normalen Distribution Points integriert worden ist. Entsprechend aktiviert man die Rolle in den Properties des DPs:

Die nächste Hürde ist dann das Verteilen des WinPE Boot-Images auf den PXE Service Point. Dies passiert in den Eigenschaften des WinPE’s: ”Deploy this boot image from the PXE service point”:

Muss bei einem geplanten Einsatz einer Hierarchie (d.h. CAS und mind. 1 Primary Site) das SQL-Feature “SQL Server Replication” ebenfalls installiert werden?

  Nein, denn die Replikation wird per “SQL Service Broker” abgehandelt.

Eine weitere Änderung bzw. Neuerung von ConfigMgr 2012 ist das Wegfallen der SLP (Server Locator Point)-Rolle. Die Funktion des SLPs übernimmt nun der Management Point (MP). Der SMSSLP-Parameter ist als ccmsetup.exe Property weiterhin vorhanden und kann somit in der ccmsetup.exe command line und als Client Push Parameter verwendet werden, jedoch muss dann auf den MP verwiesen werden.

Es steht eine aktualisierte Version der bereits hier beschriebenen FEP-Tools zu Verfügung: http://www.microsoft.com/download/en/details.aspx?id=26613. Dabei wurde vor allem das “Definition Update Automation Tool for Forefront Endpoint Protection 2010″ (softwareupdateautomation.exe) überarbeitet und einige Fehler behoben.