Heute hat mich das Tool preinst.exe bei Verwendung der Parameter /keyforparent bzw /keyforchild mit einer Meldung überrascht, die ich bisher noch niemals gesehen habe: “This site’s public key has not been created, and configured yet.  Therefore, keys cannot be dumped from this site.  Please allow Hierarchy Manager to correct the situation, and try again.“ 
Weder der Hierarchy Manager (hman.log) noch andere Statusmeldungen gaben aber einen Hinweis auf ein Problem. Der Verursacher war in diesem Fall auch nicht ConfigMgr, sondern die User Account Control (UAC) von Server 2008: die cmd war nicht explizit als Administrator gestartet worden. Im Admin-Kontext funktionierte preinst dann problemlos.

Gerade eben wunderte ich mich, wieso in meinem Testlab keine vituellen AppV-Applikationen mehr auf den Clients ankamen. In dem Advertisement Status war zu sehen, dass die Ankündigung empfangen worden ist. Am Client war die Applikation aber nie in “Run Advertised Programs” zu sehen.
Ein Blick in das execmgr.log ergab nur folgenden Hinweis: “On policy activation ignore disabled policy [Virtual application]“.
Der Grund: Im “Advertised Programs Client Agent” war  “Allow virtual application package advertisement”  nicht (mehr) aktiviert. Nach Änderung dieser Einstellung und einem Policy Refresh tauchte dann schließlich wenig später im execmgr.log “Execution of virtual application advertisements is now ENABLED.” auf und die virtuelle Applikation war startbar.

Das wichtigste Log für Troubleshooting beim Operating System Deployment (OSD) mit ConfigMgr ist das smsts.log.
Dieses ist aber leider – je nach Situation – an unterschiedlichen Stellen zu finden:

- X:\windows\temp\smstslog\smsts.log: Boot von WindowsPE / vor dem Formatieren der HDD
- C:\_SMSTaskSequence\logs\smstslog\smsts.log: smsts.log wird nach dem Formatieren der HDD dorthin kopiert
- C:\_SMSTaskSequence\logs\smstslog\smsts.log: Ziel-OS bereits vorhanden, aber ConfigMgr-Client noch nicht installiert
- %windir%\system32\ccm\logs\smstslog\smsts.log: Ziel-OS bereits vorhanden, ConfigMgr-Client jedoch schon installiert
- %windir%\system32\ccm\logs\smsts.log: nach der Ausführung des Tasksequenz

(Vorausgesetzt es wurde kein abweichender Installations-Pfad angegeben. Bei x64 Betriebssystemen befindet sich der Client in %windir%\SysWoW64\ccm).

 UPDATE: und schon ist ein Hotfix von Microsoft verfügbar: http://support.microsoft.com/kb/978757/en-us

Mit Service Pack 2 für ConfigMgr kann es unter gewissen Umständen beim Discovery zu einem Fehlverhalten kommen.

Welche Voraussetzung muss gegeben sein, damit dieser Fehler auftritt?

Gegeben sei folgende OU-Struktur im Active Directory:

Und AD System oder AD System Group Discovery mit folgender Konfiguration:

An dieser Stelle funktioniert das Discovery noch ohne Schwierigkeiten. OU1, OU2 und OU3 werden wie gewohnt in das Discovery einbezogen, was auch am korrespondierenden Logfile ersichtlich ist:

SMS_EXECUTIVE started SMS_AD_SYSTEM_DISCOVERY_AGENT as thread ID 3324 (0xCFC). SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 2316 (0x090C)
** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
The Run Count value in the site control file is 4. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 0: LDAP://OU=OU01,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 1: LDAP://OU=OU02,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 2: LDAP://OU=OU03,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)

Jetzt fügt man zusätzlich die OU “OU” (also eine OU, der Namen ähnlich den anderen ist) dem Discovery hinzu:

Was passiert? Es wird nur noch die OU “OU” in das Discovery einbezogen, die restlichen (OU01, OU02 und OU03)  ignoriert:

** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
The Run Count value in the site control file is 6. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
!!!!Valid AD container 0: LDAP://OU=OU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)

Gleichzeitig wird eine Status Message erzeugt:
Status Message ID: 5204
Component: SMS_AD_SYSTEM_DISCOVERY_AGENT
Description: SMS Active Directory System Group Discovery failed to bind to container. Error: The parameter is incorrect.
Possible cause: The AD container specified earlier might be invalid now. The Domain Controller is inaccessible.

Workaround: Verschieben der OUs unter eine neue Toplevel-OU, da das Verhalten wohl nur auftritt, wenn ähnliche Toplevel OUs in das Discovery einbezogen sind:

SMS_EXECUTIVE started SMS_AD_SYSTEM_DISCOVERY_AGENT as thread ID 1576 (0×628). SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 2316 (0x090C)
** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
The Run Count value in the site control file is 7. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 0: LDAP://OU=OU,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 1: LDAP://OU=OU01,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 2: LDAP://OU=OU02,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 3: LDAP://OU=OU03,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)

Taucht im DataTransferService.log der Fehler

DTS job {0793D9D4-B40E-4708-9867-7919F191EBC9} has completed:
 Status : ERROR (0×80080005)
 Start time : 12/21/2009 10:11:40
 Completion time : 12/21/2009 10:20:40
 Elapsed time : 540 seconds 
DTSJob {C21636C8-775D-4993-A658-15556F927CF8} in state ‘Error’.

auf, so lohnt es sich, einen Blick auf den BITS-Dienst zu werfen. Läuft dieser nicht, oder lässt er sich nicht starten, so wäre dies ein Grund für oben stehende Fehlermeldung (die übrigens dafür sorgt, dass der Client keine Policies empfängt).
Wenn versucht wird, den BITS-Dienst zu starten, taucht im System-Eventlog “The Background Intelligent Transfer Service service terminated with service-specific error 2147942405 (0×80070005)” (EventID 7024) auf.
Lösung: das Verzeichnis \Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader löschen und den BITS-Dienst neu starten.