Abgelegt unter: Erkenntnisse | Tags: ActiveDirectory, Replication, SCCM, SiteHierarchy
Die Frage tauchte auf, ob es möglich sei, SCCM-Sites über Domänengrenzen zu einer Hierarchie zu verbinden. So sollen z.B. alle Pakete der übergeordneten Site (Central Site) für die Systeme der untergeordneten Site (Primary Site) bereitgestellt werden und die Systeme der untergeordneten Site aus der übergeordneten Site mitverwaltet werden. Doch die unterzuordnende Site befindet sich in einer anderen Active-Directory-Domäne, ja sogar in einem anderen Forest. Und dass zwischen den beiden Forests keine Vertrauensstellungen existieren, macht die Angelegenheit noch interessanter. Ist so ein Szenario überhaupt machbar?
Um die Antwort gleich vorweg zu nehmen: Ja, es geht. Und dies sogar erstaunlich einfach!
Nachfolgend werden die dazu notwendigen Schritte beschrieben, dabei gehe ich davon aus, dass beide Siteserver bereits mit derselben Version von SCCM installiert sind.
Notwendige Vorbereitungen
In vertrauten Umgebungen werden normalerweise die Computerobjekte der Site-Server in die passende Gruppe(n) aufgenommen, um die Kommunikation zwischen den Site-Servern zu ermöglichen. Genau dies ist jedoch in diesem Szenario nicht möglich, da das Computerobjekt des anderen Site-Server in der unvertrauten Domäne nicht sichtbar ist. Aus diesem Grund muss in jeder Domäne ein passendes Benutzerkonto erstellt werden, das für die Kommunikation verwendet werden kann.
Ich erstellte deshalb folgende beiden Benutzerkonti in der jeweiligen Domäne(die <Platzhalter> wären mit den passenden Werten zu ersetzen)
- <Parentdomain>\SCCM-Sender-<Child>-to-<Parent>
- <Childdomain>\SCCM-Sender-<Parent>-to-<Child>
Auf jedem Siteserver existiert eine lokale Gruppe mit dem Namen „SMS_SiteToSiteConnection_<Sitecode>“, in welche das soeben generierte AD-Benutzerkonto aufzunehmen ist, womit für die Vergabe der notwendigen Zugriffsrechte an diese Benutzerkonti gesorgt wird. Auch dies war mit wenigen Mausklicks erledigt.
Definition der Sender
Nun können die Sender konfiguriert werden, welche für die Ãœbermittlung der Daten sorgen. Dazu wird in der SCCM-Konsole zu „Site Database“, „<Site>“, „Site Settings“, „Site Settings“, „Addresses“ navigiert und dort eine neue „Standard Sender Address“ erstellt:
Wichtig ist hier einfach, dass wir beim Sender der Parent-Site das AD-Konto der Child-Domäne konfigurieren und beim Sender der Childsite das entsprechende Konto der Parent-Site.
Austausch der Schlüssel
Innerhalb von vertrauten Active-Directory-Forests können die Sites ihre öffentlichen Schlüssel selbständig austauschen, dies muss nun in diesem Szenario manuell nachgeholt werden, da ansonsten die Sitehierarchie nicht erstellt werden kann. Dazu muss auf dem Siteserver der zukünftigen Parent-Site der Befehl
preinst.exe /KEYFORCHILD
Wir starten dazu eine CMD.exe mit Administratorrechten und wechseln ins Verzeichnis <Path-to>\Microsoft Configuration Manager\bin\i386\00000409, wo preinst.exe zu finden ist und setzen den genannten Befehl ab. Damit wird im Root-Verzeichnis der betreffenden Festplatte die Key-Datei „<Parentsitecode>.ct5“ erstellt.
Auf dem Siteserver der zukünftigen Child-Site muss nun der entsprechende Befehl
preinst.exe /KEYFORPARENT
ausgeführt werden, womit auf diesem im Rootverzeichnis der betreffenden Festplatte die Key-Datei „<Childsitecode>.ct4“ erstellt wird.
Randbemerkung: Als ich dies im konkreten Falle durchführen wollte, wurde ich bei der Ausführung von preinst.exe plötzlich mit folgender Fehlermeldung konfrontiert: „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.„ Diese Meldung lässt ein gröberes Problem befürchten, hat aber eine einfache Ursache: Die CMD.exe wurde nicht mit Administrator-Rechten gestartet. Mit Administrator-Rechten funktionierte es problemlos…
Die beiden Key-Files müssen nun manuell ausgetauscht werden:
Der öffentliche Schlüssel der Child-Site muss auf der Parent-Site importiert werden. Dazu muss die Datei <Childsitecode>.CT4 in den Ordner <Path-to>\Microsoft Configuration Manager\inboxes\hman.box auf dem Parentsite-Server kopiert, die <Parentsitecode>.CT5 in den entsprechenden Ordner der Childsite kopiert werden.
Die Komponente „SMS_Hierarchy_Manager“ importiert nun den jeweiligen Schlüssel, was in <Path-to>\Microsoft Configuration Manager\logs\hman.log protokolliert wird.
Damit ist nun das Gröbste geschafft, nun muss nur noch in der Childsite die entsprechende Parent-Site konfiguriert werden, wozu wir in den „Properties“ der Childsite den Button „Set Parent Site“ finden. Sobald hier die Parent-Site konfiguriert wurde, beginnen die Siteserver mit dem Austausch der Daten, was z.B. in folgenden Protokollen mitverfolgt werden kann:
- hman.log
- sender.log
- replmgr.log
- objreplmgr.log
- distmgr.log
- …
Tauchen dort keine Fehlermeldungen auf und die Replikation läuft wunschgemäss, ist der Sprung über die Domänengrenze geschafft und die Childsite in der fremden AD-Domäne kann nun wie jede andere Childsite von der Parent-Site her verwaltet werden.