von Redaktion IT-A…
Lesezeit
3 Minuten
Active Directory-Replikation mit der PowerShell (1)
Die Active Directory-Replikation ist ein komplexes Feld – sowohl in Sachen Verständnis als auch technologisch. Erschwerend kommt hinzu, dass eine fehlerhafte oder schlecht administrierte Replikation so gut wie immer dramatische Konsequenzen für die Infrastruktur hat. Somit ist der Administrator gut beraten, den Datenaustausch zwischen den Domänencontrollern jederzeit im Blick und unter Kontrolle zu haben. Hilfe kann er dabei auch von der PowerShell erwarten. Dieser Artikel zeigt Cmdlets für Administration und Troubleshooting der AD-Replikation. Im ersten Teil erkunden wir die Replikationsstruktur und machen uns auf, Replikationsverbindungen zu bereinigen.
Die erste Version des Active Directory-Moduls für die PowerShell bot vor allem Cmdlets für die Datenverwaltung des Verzeichnisdienstes. Objekte ließen sich erstellen, löschen und ändern, neue Funktionen wie der Papierkorb für das Active Directory aktivieren und Funktionen, die bisher noch nicht über die grafische Benutzeroberfläche verwaltet werden konnten, stellte die PowerShell unkompliziert zur Verfügung.
In den Versionen seit Windows Server 2012 bringt die PowerShell aber auch erweiterte Möglichkeiten für die Verwaltung des Infrastrukturdienstes mit sich, die bisher über zusätzliche Kommandos wie zum Beispiel repadmin.exe möglich waren. Damit kann der Administrator die Replikation anstoßen und insbesondere überprüfen, sowie erweiterte Aufgaben für die Fehlersuche und -Behebung in der Infrastruktur nutzen.
Die Replikationsstruktur erkunden
Die Active Directory-Replikation ist vergleichsweise komplex. Der Administrator muss die physikalische Standortstruktur mittels Standortobjekten nachbauen und über Standortverbindungen festlegen, welche Standorte wie häufig und wann miteinander replizieren. Diese Informationen werden von den Active Directory-Komponenten KCC (Knowledge Consistency Checker) und ISTG (Intersite Topology Generator) verwendet, um eine Replikationsstruktur innerhalb von Standorten und Standortübergreifend aufzubauen. Dabei wird definiert, welcher Domänencontroller (DC) von welchem anderen DC die Updates erhält. Betrachtet er eine komplexere Replikationsstruktur an, wird der Administrator feststellen, dass innerhalb eines Standortes ein "Replikationskreis" gebildet wird, der aber auch Querverbindungen enthält, damit die Replikation bei vielen DCs entsprechend beschleunigt wird.
Standortübergreifend werden zumeist zwei Replikationsverbindungen (pro Domäne) gebildet: eine eingehende und eine ausgehende. Ob diese zwischen den gleichen oder verschiedenen Servern liegt, ist unerheblich und abhängig von der Konfiguration der Bridgehead-Server. Sind DCs mit dieser speziellen "Rolle" konfiguriert, so kümmern sich diese um die Standortübergreifende Replikation – ohne die Definition von Bridgehead-Servern kann jeder DC sich auch um die standortübergreifende Replikation kümmern. Die Definition von Bridgehead-Servern muss genau überdacht und konzeptioniert werden und ist in den meisten Umgebungen nicht sinnvoll.
Bild 1: Die Replikationsverbindung verbirgt sich in "Active Directory-Standorte und -Dienste" im Pfad "Standort / Servers /
Servername / NTDS Settings". Hier handelt es sich um die eingehende Replikationsverbindung von ITA-DC2 zu ITA-DC1.
Die Replikationsverbindungen werden auch als Objekte im AD hinterlegt, allerdings sollten diese vom System verwaltet werden. Sehen kann der Administrator die Replikationsverbindungen in der altbekannten Managementkonsole "Active Directory-Standorte und -Dienste". Die Replikationsverbindungen sollten nicht manuell geändert werden, wenn diese geöffnet werden ist es wichtig, den Dialog mit "Abbrechen" zu verlassen, aber dazu später mehr.
Ihnen stehen nun aber auch die neuen Cmdlets der PowerShell zur Verfügung, um die Replikationsstruktur zu erkunden. Mit dem folgenden Cmdlet erhalten Sie mehr Informationen über die Replikationspartner eines bestimmten Domänencontrollers:
Ein Domänencontroller merkt sich die zuletzt replizierten USNs seiner Replikationspartner. Dadurch kann er bei einer Replikation wie folgt vorgehen:
Seite 1: Die Replikationsstruktur erkunden
Seite 2: Bereinigung von Replikationsverbindungen
jp/ln/Ulf B. Simon-Weidner
In den Versionen seit Windows Server 2012 bringt die PowerShell aber auch erweiterte Möglichkeiten für die Verwaltung des Infrastrukturdienstes mit sich, die bisher über zusätzliche Kommandos wie zum Beispiel repadmin.exe möglich waren. Damit kann der Administrator die Replikation anstoßen und insbesondere überprüfen, sowie erweiterte Aufgaben für die Fehlersuche und -Behebung in der Infrastruktur nutzen.
Die Replikationsstruktur erkunden
Die Active Directory-Replikation ist vergleichsweise komplex. Der Administrator muss die physikalische Standortstruktur mittels Standortobjekten nachbauen und über Standortverbindungen festlegen, welche Standorte wie häufig und wann miteinander replizieren. Diese Informationen werden von den Active Directory-Komponenten KCC (Knowledge Consistency Checker) und ISTG (Intersite Topology Generator) verwendet, um eine Replikationsstruktur innerhalb von Standorten und Standortübergreifend aufzubauen. Dabei wird definiert, welcher Domänencontroller (DC) von welchem anderen DC die Updates erhält. Betrachtet er eine komplexere Replikationsstruktur an, wird der Administrator feststellen, dass innerhalb eines Standortes ein "Replikationskreis" gebildet wird, der aber auch Querverbindungen enthält, damit die Replikation bei vielen DCs entsprechend beschleunigt wird.
Standortübergreifend werden zumeist zwei Replikationsverbindungen (pro Domäne) gebildet: eine eingehende und eine ausgehende. Ob diese zwischen den gleichen oder verschiedenen Servern liegt, ist unerheblich und abhängig von der Konfiguration der Bridgehead-Server. Sind DCs mit dieser speziellen "Rolle" konfiguriert, so kümmern sich diese um die Standortübergreifende Replikation – ohne die Definition von Bridgehead-Servern kann jeder DC sich auch um die standortübergreifende Replikation kümmern. Die Definition von Bridgehead-Servern muss genau überdacht und konzeptioniert werden und ist in den meisten Umgebungen nicht sinnvoll.
Bild 1: Die Replikationsverbindung verbirgt sich in "Active Directory-Standorte und -Dienste" im Pfad "Standort / Servers /
Servername / NTDS Settings". Hier handelt es sich um die eingehende Replikationsverbindung von ITA-DC2 zu ITA-DC1.
Die Replikationsverbindungen werden auch als Objekte im AD hinterlegt, allerdings sollten diese vom System verwaltet werden. Sehen kann der Administrator die Replikationsverbindungen in der altbekannten Managementkonsole "Active Directory-Standorte und -Dienste". Die Replikationsverbindungen sollten nicht manuell geändert werden, wenn diese geöffnet werden ist es wichtig, den Dialog mit "Abbrechen" zu verlassen, aber dazu später mehr.
Ihnen stehen nun aber auch die neuen Cmdlets der PowerShell zur Verfügung, um die Replikationsstruktur zu erkunden. Mit dem folgenden Cmdlet erhalten Sie mehr Informationen über die Replikationspartner eines bestimmten Domänencontrollers:
Get-ADReplicationPartnerMetadata localhostBetrachten wir die AD-Replikation detaillierter, stellen wir fest, dass die zugrundeliegende Datenbank keine Replikation zur Verfügung stellt. Die Replikation basiert rein auf der "Anwendungsschicht", die über den zuvor beschriebenen Weg mit KCC und ISTG eine Replikationstopologie erstellt. Jeder DC weiß daraufhin, mit welchen weiteren DCs er in welcher Richtung replizieren soll. Für jeden Wert eines Objektes gibt es eine Update Sequency Number (USN) und eine Versionsnummer. Die Versionsnummer wird bei der Änderung eines Wertes um 1 erhöht. Die USN gilt über alle Objekte hinweg auf einem Domänencontroller, aber auch nur auf diesem. Wird ein Wert geändert, vermerkt der DC dann zusätzlich die USN und erhöht diese um 1. Unterschiedliche Werte können dabei auch mal die gleiche USN erhalten, wenn sie in der gleichen Transaktion geändert oder geschrieben wurden (zum Beispiel werden viele Werte, die von einem neuen Benutzerobjekt stammen, beim Erstellen gleichzeitig geschrieben).
Ein Domänencontroller merkt sich die zuletzt replizierten USNs seiner Replikationspartner. Dadurch kann er bei einer Replikation wie folgt vorgehen:
- Der DC fragt seine Replikationspartner nach allen Änderungen, die neuer sind als die USN der letzten erfolgreichen Replikation.
- Der DC erhält die geänderten Werte inklusive derer Versionsnummer. Er vergleicht, ob die erhaltene Versionsnummer eines Attributes größer ist als die Versionsnummer des gleichen Attributes, die er selber verwaltet. Wenn die Versionsnummer höher ist, wird der Wert des Attributes überschrieben und die Versionsnummer um 1 erhöht. Auch die eigene USN wird angepasst.
- Ist die Versionsnummer identisch, vergleicht er die Zeitstempel der Änderung. Die zuletzt erfolgte Änderung "gewinnt".
- Nach erfolgreicher Replikation merkt sich der DC die höchste USN des Replikationspartners, die während der Replikation bearbeitet wurde.
Get-ADReplicationUpToDatenessVectorTable LocalhostIm Ergebnis unter "Partner" finden Sie hier normalerweise das "NTDS Settings"-Objekt des Replikationspartners. Wenn dieses Feld leer ist, kann das zum Beispiel bedeuten, dass ein Domänencontroller neu installiert wurde. Da das AD nicht wissen kann, ob der "alte" DC noch einmal online kommt, wird auch dieser Wert gespeichert und lässt sich mittels der PartnerInvocationID dem richtigen System zuweisen. Bei der InvocationID handelt es sich um eine GUID (Global Unique Identifyer), die eine Replikationsinstanz eindeutig identifiziert. Bei dem Wert "LastReplicationSuccess" kann der Administrator erkennen, wann diese Replikationsverbindung zuletzt erfolgreich repliziert hat, sowie über den Wert "UsnFilter", welche USN zuletzt repliziert wurde.
Seite 1: Die Replikationsstruktur erkunden
Seite 2: Bereinigung von Replikationsverbindungen
| Seite 1 von 2 | Nächste Seite >> |
jp/ln/Ulf B. Simon-Weidner
