Torsten's Blog

 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 (0×090C)
** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
The Run Count value in the site control file is 4. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
!!!!Valid AD container 0: LDAP://OU=OU01,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
!!!!Valid AD container 1: LDAP://OU=OU02,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
!!!!Valid AD container 2: LDAP://OU=OU03,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0×0CFC)

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 (0×03A8)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
The Run Count value in the site control file is 6. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
!!!!Valid AD container 0: LDAP://OU=OU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0×03A8)

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 (0×090C)
** 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)

Das System Center Configuration Manager 2007 Toolkit (Download hier) sollte (muß!) jeder SCCM-Admin kennen. Alleine schon trace32 macht es deutlich einfacher, Logfiles zu lesen, da die Anzeige automatisch aktualisiert wird, Hervorhebungen/Filter möglich sind, etc.
Ein Bild sagt mehr als tausend Worte:

Notepad:

 trace32.exe:

Hat sich schon einmal jemand geärgert, dass es von trace32 keine 64-bit-Version gibt? Nein? trace32 läuft ja auch auf x64-Betriebssystemen. Ja, ABER nicht unter x64-WinPE … dort laufen nämlich keine 32bit-Apps. Deshalb gibt es jetzt eine 64-bit-Version, enthalten hier.

Bisher war das Patchen von Drittanbieterprodukten (wie z.B. Adobe, Java u.ä.) mit SCCM zwar möglich – aber kompliziert. Entweder erstellte man dynamische Collections und aktualisierte die Produkte per klassischer Softwareverteilung oder aber man erstellte mit dem SCUP (System Center Updates Publisher) eigene Patchkataloge und importierte diese dann in den WSUS (SUP), um diese Produkte als Software-Update zu verteilen.
Seit heute bietet Shavlik das Produkt SCUPdates an und liefert somit fertige Kataloge, die per SCUP in ConfigMgr/SUP importiert werden können. Eine Liste der damit unterstützen Produkte findet man hier.

Microsoft hat kürzlich 4 neue Dokumente zum Thema SCCM veröffentlicht:

• SystemCenterConfigurationManager2007DeploymentGuide (pdf, 14,5 MB)
• SystemCenterConfigurationManager2007OperatingSystemDeploymentGuide (pdf, 14,4 MB)
• SystemCenterConfigurationManager2007SoftwareDistributionGuide (pdf, 10,1 MB)
• SystemCenterConfigurationManagerSoftwareUpdateManagementGuide (pdf, 5,7 MB)

Insgesamt ca. 500 Seiten, leider nur in Englisch verfügbar.

Der PXE Servicepoint (WDS) unter SCCM speichert(e) Anfragen von Clients eine Stunde lang zwischen, was zu Problemen bei OS Deployments führt(e). Deshalb wurde http://support.microsoft.com/kb/969113/en-us veröffentlicht, der die Zwischenspeicherzeit von 1h auf 1min zurücksetzte. Genauer betrachtet wird der Wert HKLM\Software\Microsoft\SMS\PXE\CacheExpire auf 0 gesetzt und als 60s interpretiert.
Laut http://support.microsoft.com/kb/971348/en-us ist kb969113 im Service Pack (SP) 2 für ConfigMgr enthalten. HKLM\Software\Microsoft\SMS\PXE\CacheExpire steht zwar dann weiterhin auf 0, jedoch wird dies (fälschlicherweise wieder) als 3600s interpretiert. Zu erkennen ist das im smspxe.log:

Loaded PXE settings from reg key HKLM\Software\Microsoft\SMS\PXE:
PXE Settings:
    IsActive: Yes
    SupportUnknownMachines: No
    MACIgnoreListFile: <empty>
    ResponseDelay: 0
    CacheExpire: 3600 
    HTTP Port: 80
    HTTPS Port: 443
    IISSSLState: 0×0
    BindPolicy: Exclude <empty>
    TRK: <non empty>
    SiteSignCert: <empty>
    Root CA Certs: <empty>
    PXE GUID: <GUID>
    PXEPassword: <empty>

 Lösung / Workaround: Setzen des Wertes CacheExpire auf einen kleinen Wert <> 0 (z.B. 120) in der Registry auf den PXE Servicepoints.

Wer mehr als einen PXE Servicepoint in Einsatz hat oder den Prozeß automatisieren will, der kann auch eine Collection aller PXE SPs erstellen und ein einfaches .reg-File verteilen.

Collection:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.SystemRoles = “SMS PXE Service Point”

Regfile:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE]
“CacheExpire”=dword:00000078

Gestern ging hier in Redmond bzw. Bellevue der MVP Global Summit 2010 zu Ende. Es war eine extrem informative Woche bei Microsoft im EEC-Lab mit vielen Informationen über v.Next von System Center Configuration Manager.

Falls Paketquellen auf einem Server 2008 R2 liegen, kann es zu Problemen kommen, falls der Siteserver auf einem OS kleiner als Server 2008 R2 läuft:

“SMS Distribution Manager failed to access the source directory “\\server\share\directory” for package “ABC12345″. The operating system reported error 5: Access is denied.” 

Stimmen alle Share- und NTFS-Berechtigungen, dann kann vielleicht http://support.microsoft.com/kb/973278/en-us (“Error message when you use a computer that is running Windows Vista or Windows Server 2008 to read a file that is located on a computer that is not running these operating systems: “0×00000032 (ERROR_NOT_SUPPORTED)”") Abhilfe schaffen.

Beim Import (OS Deployment) von Treibern für Windows7 kann es passieren, dass die Meldung “The selected driver is not applicable to any supported platforms” auftaucht (ausgenommen sind hierbei wohl Siteserver, die auf Server 2008 R2 laufen), obwohl laut .inf-Dateien Win7 unterstützt wird. Abhilfe schafft kb978754.

Unter http://technet.microsoft.com/en-us/library/ff385001.aspx stehen ab sofort neue Superflows zum Download bereit. Was ist ein “Superflow”? Ein Superflow stellt einen SCCM-Ablauf/Prozeß ähnlich einem Flussdiagramm dar und ist gespickt mit extrem vielen und tiefgehenden Informationen zu den einzelnen Prozeßschritten. Prädikat: absolut empfehlenswert!

Für das Deployment von IBM Servern gibt es seit kurzem das IBM Deployment Pack v1.2.