ConfigMgr 2012 – msi detection method

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

 

 

3 Gedanken zu „ConfigMgr 2012 – msi detection method

  1. Florian

    Wenn die VBScripts diese Fehlermeldung ausgeben: “(1, 33) Kompilierungsfehler in Microsoft VBScript: Ungültiges Zeichen” einfach die Anführungszeichen in Notepad++ etc. ersetzen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert