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)

Was steckt dahinter und wie kann man dies beispielsweise umsetzen?

Hinter Branch Cache verbirgt sich eine neue Technologie, die mit Server 2008 R2 eingeführt wurde und es prinzipiell ermöglicht, Dateien zu cachen (zwischenzuspeichern), um somit die WAN-Auslastung zu reduzieren. Dies wird erreicht, indem gleiche Inhalte nur einmal über die WAN-Leitung übertragen werden. Branch Cache kann hierbei in zwei unterschiedlichen Modi konfiguriert werden: dem “distributed cache mode” oder dem “hosted cache mode“. Eine detaillierte Zusammenfassung findet man hier: http://technet.microsoft.com/de-de/library/ee307962(WS.10).aspx.

Die ConfigMgr-Dokumentation ist hierbei etwas knapp gehalten. In dem Artikel “Von Configuration Manager 2007 SP2 unterstützte Konfigurationen” liest man folgende gute Erklärung über die Funktionsweise:

“Auf einem Clientcomputer mit aktivierter Branch-Cache-Funktion wird Inhalt, der von einem Verteilungspunkt unter Windows Server 2008 R2 zum ersten Mal heruntergeladen wird, lokal zwischengespeichert, sofern auf dem Verteilungspunkt die Branch-Cache-Funktion ebenfalls aktiviert ist. Bei späteren Anforderungen zum erneuten Herunterladen des Inhalts von diesem Verteilungspunkt durch andere Clients am selben Standort, auf denen die Branch-Cache-Funktion aktiviert ist, wird der Inhalt vom ersten Client über das lokale Netzwerk freigegeben. D. h., der Inhalt muss nicht erneut vom Verteilungspunkt heruntergeladen werden. Zur weiteren Verbesserung der Leistung wird der von Peer zu Peer übertragene Inhalt auf den Computern mit der Downloadanforderung ebenfalls zwischengespeichert. Auf diese Weise sind für gleichzeitige Übertragungen mehrere Computer verfügbar.“

Was allerdings alles zu tun ist, um dies umzusetzen, wird noch knapper abgehandelt:

“Die Branch-Cache-Funktion wird nur unterstützt, wenn sowohl die Verteilungspunkt-Standortsysteme, auf denen Windows Server 2008 R2 ausgeführt wird und BITS aktiviert ist, als auch die Verteilungspunkt-Dateifreigabe dafür konfiguriert wurden. Auf Clients muss außerdem der Branch-Cache-Dienst für die Ausführung im verteilten Modus konfiguriert und die Branch-Cache-Unterstützung muss in den BITS-Clienteinstellungen aktiviert werden.“

Als erstes sticht einem “Server 2008 R2″ in’s Auge. Als Voraussetzung für den Einsatz von Branch Cache ist also ein Distribution Point auf Server 2008 R2 notwendig. Clientseitig wird Windows 7 (oder eben Server 2008 R2) vorausgesetzt. Mit einem Update des BITS-Dienstes (“Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)”) auf die Version 4.0 können allerdings auch Windows Server 2008 mit Service Pack 2 und Windows Vista mit Service Pack 1 oder 2 die Branch Cache-Funktionalität nutzen. Somit sind also die softwareseitigen Voraussetzungen geklärt.

Nun zur Umsetzung (diese stellt keine vollständige step-by-step Anleitung dar, sondern dient nur zur prinzipiellen Erläuterung. Eine Konfiguration kann je nach Umgebung abweichen, so dass manche Schritte überflüssig sind oder eventuell auch fehlen können).

Serverseitig:

Auf dem Distribution Point (zur Erinnerung: hier kommt nur Server 2008 R2 in Frage) muss das Feature “BranchCache” installiert werden:

Alternativ kann man dies auch recht einfach über die Kommandozeile durchführen: ServerManagerCmd.exe -i BranchCache.

Über das “Share und Storage Management” muss anschließend die Freigabe des Distribution Points (SMSPKGX$) bzw. der DP Share (DP-Share in meinem Beispiel) noch für die Nutzung von Branch Cache aktiviert werden:

Serverseitig sind die Vorbereitungen damit abgeschlossen (vorausgesetzt der DP bzw. DP-Share sind schon BITS-enabled).

Clientseitig:

Die Änderungen betreffen hier nur den BITS- und Branch Cache-Dienst. Am einfachsten lässt sich die Konfiguration mittels einer Group Policy (Gruppenrichtlinie, GPO) umsetzen:

• Computer Configuration -> Policies -> Administrative Templates -> Network -> Background Intelligent Transfer Service (BITS): Allow BITS Peercaching: Enabled
• Computer Configuration -> Policies -> Administrative Templates -> Network -> BranchCache: Configure BranchCache for network files: Enabled | 0 (“0″ damit zu Testzwecken keine Messung der Latenz durchgeführt wird)
• Computer Configuration -> Policies -> Administrative Templates -> Network -> BranchCache: Set BranchCache Distributed mode: Enabled
• Computer Configuration -> Policies -> Administrative Templates -> Network -> BranchCache: Turn on BranchCache: Enabled

Um die clientseitigen Einstellungen zu kontrollieren, kann man sich die Ausgabe von “netsh branchcache show status” anzeigen lassen:

Das war’s eigentlich schon, was die Konfiguration von nicht-SCCM-Komponenten anbelangt. In ConfigMgr selbst sind keine speziellen Settings vorzunehmen, die Verwendung des neuen Features passiert automatisch, wenn “download & execute” verwendet wird.

Was passiert also clientseitig?

Dazu kurz eine Info zu dem “Testpaket”, welches schlicht 2 Files beinhaltet (File.001 und File2.001) und auf einem DP-Share namens “DP-Share” im Verzeichnis “BranchCacheTest” liegen:

Auf dem ersten Client, der das Advertisement empfängt, laufen die normalen ConfigMgr-Mechanismen ab, um Content zu ermitteln und der Inhalt des Pakets wird per BITS in den lokalen Cache geladen. Spannend ist in diesem Fall das Eventlog des BITS-Client:

EventID 60 ist hier speziell zu beachten. Hier wird der Download pro File protokolliert:

Bisher hat sich der Vorgang noch nicht von einer “normalen” Softwareverteilung unterschieden. Der Vorteil des Branch Caches kommt erst zum Tragen, wenn ein weiterer Client das gleiche Advertisement ausführen soll.

Hier sieht man, dass der Transfer dann von einem “Peer” gekommen ist:

Wie man sieht: es ist einiges an Vorbereitung nötig, aber die Branch Cache-Funktionalität von ConfigMgr SP2 integriert sich nahtlos und schont die Bandbreite von WAN-Verbindungen.