Architektur virtualisierter Domänencontroller
Dieser Artikel behandelt die Architektur für das Klonen und die sichere Wiederherstellung virtualisierter Domänencontroller. Sie finden Flussdiagramme zu den Klon- und Wiederherstellungsprozessen sowie eine detaillierte Erklärung der einzelnen Prozessschritte.
Architektur für das Klonen virtualisierter Domänencontroller
Architektur zur sicheren Wiederherstellung virtueller Domänencontroller
Architektur für das Klonen virtualisierter Domänencontroller
Übersicht
Das Klonen virtualisierter Domänencontroller benötigt einen von der Hypervisor-Plattform bereitgestellten Bezeichner mit dem Namen VM-Generations-ID, mit dem die Erstellung virtueller Computer erkannt wird. AD DS speichert diesen Bezeichner bei der Heraufstufung des Domänencontrollers in der Datenbank (NTDS.DIT). Beim Hochfahren des virtuellen Computers wird der aktuelle Wert der VM-Generations-ID des virtuellen Computers mit dem Wert in der Datenbank verglichen. Unterscheiden sich die beiden Werte, wird die Aufruf-ID zurückgesetzt und der RID-Pool verworfen, um das erneute Verwenden der USN oder die mögliche Erstellung doppelter Sicherheitsprinzipale zu verhindern. Anschließend sucht der Domänencontroller nach der Datei DCCloneConfig.xml an den in Schritt 3 unter Details zum Klonprozess beschriebenen Orten. Wenn die Datei „DCCloneConfig.xml“ gefunden wird, geht der Domänencontroller davon aus, dass er als Klon bereitgestellt wird und initialisiert das Klonen, um sich selbst durch erneute Heraufstufung als zusätzlichen Domänencontroller bereitzustellen. Dabei werden die vom Quellmedium kopierten Inhalte von NTDS.DIT und SYSVOL verwendet.
In gemischten Umgebungen, in denen nicht alle Hypervisoren die VM-Generations-ID unterstützen, kann es passieren, dass ein Klonmedium versehentlich auf einem Hypervisor bereitgestellt wird, der die VM-Generations-ID nicht unterstützt. Das Vorhandensein der Datei DCCloneConfig.xml gibt die Absicht an, einen DC klonen zu wollen. Wenn also die Datei „DCCloneConfig.xml“ beim Hochfahren gefunden wird, aber keine VM-Generations-ID vom Host angegeben wurde, wird der Klon-DC mit dem Verzeichnisdienste-Wiederherstellungsmodus (Directory Services Restore Mode, DSRM) gestartet, um Auswirkungen auf die restliche Umgebung zu verhindern. Das Klon-Medium kann anschließend auf einen Hypervisor verschoben werden, der die VM-Generations-ID unterstützt, und das Klonen dort wiederholt werden.
Wenn das Klonmedium auf einem Hypervisor bereitgestellt wird, der die VM-Generations-ID unterstützt, und die Datei „DCCloneConfig.xml“ nicht vorhanden ist, löst der Domänencontroller Schutzmaßnahmen gegen USN-Wiederverwendung und doppelte SIDs aus, wenn er eine Änderung der VM-Generations-ID zwischen seiner eigenen DIT und der DIT der neuen VM erkennt. Der Klonvorgang wird jedoch nicht gestartet, sodass der sekundäre Domänencontroller weiterhin unter derselben Identität wie der Quelldomänencontroller ausgeführt wird. Der sekundäre DC sollte schnellstmöglich aus dem Netzwerk entfernt werden, um Inkonsistenzen in der Umgebung zu vermeiden.
Details zum Klonprozess
Das folgende Diagramm zeigt die Architektur für den ursprünglichen Klonprozess und für Wiederholungen des Klonprozesses. Diese Prozesse werden im Verlauf dieses Artikels genauer beschrieben.
Ursprünglicher Klonprozess
Wiederholung des Klonprozesses
In den folgenden Schritten wird der Prozess genauer beschrieben:
Ein existierender virtueller Domänencontroller wird in einem Hypervisor hochgefahren, der die VM-Generations-ID unterstützt.
Diese VM hat nach der Heraufstufung keine existierende VM-Generations-ID im entsprechenden AD DS-Computerobjekt.
Selbst wenn die ID null ist, wird sie bei der nächsten Computererstellung geklont, da eine neue VM-Generations-ID nicht übereinstimmt.
Die VM-Generations-ID wird nach dem nächsten Neustart des Domänencontrollers festgelegt und wird nicht repliziert.
Anschließend liest der virtuelle Computer die vom VMGenerationCounter-Treiber bereitgestellte VM-Generations-ID aus. Die beiden VM-Generations-IDs werden verglichen.
Wenn die IDs übereinstimmen, handelt es sich nicht um einen neuen virtuellen Computer, und der Klonvorgang wird nicht fortgesetzt. Wenn eine DCCloneConfig.xml-Datei existiert, benennt der Domänencontroller die Datei mit einem Zeitstempel um, um das Klonen zu verhindern. Der Startvorgang des Servers wird normal fortgesetzt. Jeder Neustart eines virtuellen Domänencontrollers unter Windows Server 2012 erfolgt auf diese Weise.
Wenn die beiden IDs nicht übereinstimmen, handelt es sich um einen neuen virtuellen Computer, der eine NTDS.DIT-Datei aus einem vorherigen Domänencontroller enthält (oder es handelt sich um eine wiederhergestellte Momentaufnahme). Wenn eine DCCloneConfig.xml-Datei existiert, fährt der Domänencontroller mit dem Klonprozess fort. Andernfalls wird der Wiederherstellungsprozess der Momentaufnahme fortgesetzt. Weitere Informationen finden Sie unter Sichere Wiederherstellungsarchitektur für virtualisierte Domänencontroller.
Wenn der Hypervisor keine VM-Generations-ID zum Vergleich bereitstellt, aber die Datei „DCCloneConfig.xml“ vorhanden ist, benennt der Gast die Datei um und startet im DSRM, um das Netzwerk vor doppelt vorhandenen Domänencontrollern zu schützen. Wenn keine Datei vom Typ „DCCloneConfig.xml“ vorhanden ist, fährt der Gast normal hoch (mit einem möglichen doppelt vorhandenen Domänencontroller im Netzwerk).
Der NTDS-Dienst prüft den Wert des VDCisCloning-DWORDs in der Registrierung (unter HKEY_Local_Machine\System\CurrentControlSet\Services\Ntds\Parameters).
Wenn dieser Wert nicht vorhanden ist, handelt es sich um den ersten Versuch, diesen virtuellen Computer zu klonen. Der Gast implementiert die Sicherheitsmaßnahmen gegen doppelte VDC-Objekte, indem er den lokalen RID-Pool ungültig macht und eine neue Replikations-Aufrufkennung für den Domänencontroller einrichtet
Wenn diese bereits auf den Wert „0x1“ festgelegt ist, handelt es sich um einen Wiederholungsversuch zum Klonen, und der vorherige Klonvorgang war nicht erfolgreich. Die Sicherheitsmaßnahmen gegen doppelte VDC-Objekte werden nicht implementiert, da diese bereits zuvor ausgeführt werden mussten und den Gast ansonsten unnötigerweise mehrfach ändern würden.
Der IsClone DWORD-Registrierungswert wird nicht geschrieben (unter Hkey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters)
Der NTDS-Dienst ändert die Gast-Boot-Kennzeichnung, um zukünftige Neustarts im DS-Reparaturmodus auszuführen.
Der NTDS-Dienst versucht, die Datei DcCloneConfig.xml an den drei möglichen Orten zu lesen (DSA-Arbeitsverzeichnis, %windir%\NTDS oder les-/schreibbare Wechselmedien in der Reihenfolge der Laufwerkbuchstaben im Stammverzeichnis des Laufwerks).
Wenn die Datei an keinem gültigen Ort vorhanden ist, prüft der Gast die IP-Adresse auf Duplikate. Wenn die IP-Adresse nicht dupliziert ist, wird der Server normal hochgefahren. Wenn eine duplizierte IP-Adresse vorhanden ist, startet der Computer im DSRM, um das Netzwerk vor doppelt vorhandenen Domänencontrollern zu schützen.
Wenn die Datei an einem der gültigen Orte existiert, prüft der NTDS-Dienst die enthaltenen Einstellungen. Wenn die Datei leer ist (oder einzelne Einstellungen leer sind), konfiguriert NTDS automatische Werte für diese Einstellungen.
Wenn die Datei DcCloneConfig.xml existiert, aber ungültige Einträge enthält oder nicht lesbar ist, schlägt der Klonvorgang fehl und der Gast startet in den Verzeichnisdienstwiederherstellungsmodus (DSRM).
Der Gast deaktiviert die automatische DNS-Registrierung, um eine versehentliche Übernahme von Quell-Computername und IP-Adressen zu verhindern.
Der Gast beendet den Anmeldedienst, um Ankündigungen oder Antworten auf AD DS-Anfragen von Clients aus dem Netzwerk zu verhindern.
NTDS überprüft, ob keine Dienste oder Programme installiert sind, die nicht in „DefaultDCCloneAllowList.xml“ oder „CustomDCCloneAllowList.xml“ enthalten sind.
Falls Dienste oder Programme installiert sind, die nicht in der Standardausschlussliste oder der benutzerdefinierten Ausschlussliste enthalten sind, tritt beim Klonvorgang ein Fehler auf, und der Gast startet im DSRM, um das Netzwerk vor doppelt vorhandenen Domänencontrollern zu schützen.
Falls keine Inkompatibilitäten vorliegen, wird der Klonvorgang fortgesetzt.
Wenn automatische IP-Adressierung aufgrund leerer DCCloneConfig.xml-Netzwerkeinstellungen verwendet wird, aktiviert der Gast DHCP auf den Netzwerkkarten, um eine IP-Adresslease, Netzwerkrouting und Namensauflösungsinformationen zu erhalten.
Der Gast sucht und kontaktiert den Domänencontroller, der die PDC-Emulator-FSMO-Rolle ausführt. Dazu werden DNS und das DCLocator-Protokoll verwendet. Der Gast stellt eine RPC-Verbindung her und ruft die Methode IDL_DRSAddCloneDC auf, um das Domänencontroller-Computerobjekt zu klonen.
Wenn das Quell-Computerobjekt des Gasts die erweiterte Domänenkopf-Berechtigung "Zulassen, dass sich ein DC selbst klont" enthält, wird der Klonvorgang fortgesetzt.
Wenn das Quellcomputerobjekt des Gasts diese erweiterte Berechtigung nicht enthält, schlägt der Klonvorgang fehl, und der Gast startet im DSRM, um das Netzwerk vor doppelt vorhandenen Domänencontrollern zu schützen.
Der Name des AD DS-Computerobjekts wird auf den in DCCloneConfig.xml angegebenen Namen gesetzt, falls vorhanden, oder andernfalls automatisch auf dem PDCE generiert. NTDS erstellt das korrekte NTDS-Einstellungsobjekt für den entsprechenden logischen Active Directory-Ort.
Wenn es sich um einen PDC-Klonvorgang handelt, benennt der Gast den lokalen Computer um und startet neu. Nach dem Neustart werden die Schritte 1 – 10 erneut durchlaufen und anschließend Schritt 13 ausgeführt.
Falls ein Replikat-DC geklont wird, findet zu diesem Zeitpunkt kein Neustart statt.
Der Fast stellt die Heraufstufungseinstellungen für den DS-Rollenserverdienst bereit, der die Heraufstufung beginnt.
Der DS-Rollenserverdienst beendet alle AD DS-bezogenen Dienst (NTDS, NTFRS/DFSR, KDC, DNS).
Der Gast erzwingt eine NT5DS (Windows NTP)-Zeitsynchronisierung mit einem anderen Domänencontroller (in einer normalen Windows-Zeitdiensthierarchie wird dazu der PDCE verwendet). Der Gast kontaktiert den PDCE. Alle existierenden Kerberos-Tickets werden gelöscht.
Der Gast konfiguriert die DFSR- oder NTFRS-Dienste für die automatische Ausführung. Der Gast löscht alle vorhandenen DFSR- und NTFRS-Datenbankdateien (standardmäßig „c:\windows\ntfrs“ und „c:\system volume information\dfsr\<Datenbank_GUID>“), um beim nächsten Start des Diensts eine nicht autoritative Synchronisierung von SYSVOL zu erzwingen. Der Gast löscht die Dateiinhalte von SYSVOL nicht, um vorab das Seeding für SYSVOL auszuführen, wenn die Synchronisierung später gestartet wird.
Der Gast wird umbenannt. Der DS-Rollenserverdienst auf dem Gast beginnt mit der AD DS-Konfiguration (Heraufstufung) und verwendet dabei die NTDS.DIT-Datenbankdatei als Quelle, anstelle der in c:\windows\system32 enthaltenen Datenbankvorlage, wie bei einer normalen Heraufstufung.
Der Gast kontaktiert den Inhaber der RID-Master-FSMO-Rolle, um eine neue RID-Pool-Zuweisung zu erhalten.
Der Heraufstufungsprozess erstellt eine neue Aufrufkennung und generiert das NTDS-Einstellungsobjekt für den geklonten Domänencontroller neu (dies ist unabhängig vom Klonvorgang Teil der Domänen-Heraufstufung, wenn eine existierende NTDS.DIT-Datenbank verwendet wird).
NTDS wird in Objekten repliziert, die fehlen, neuer sind oder eine höhere Versionsnummer haben, von einem Partner-Domänencontroller. NTDS.DIT enthält bereits Objekte vom Zeitpunkt, zu dem der Quell-Domänencontroller offline genommen wurde. Diese Objekte werden nach Möglichkeit verwendet, um den eingehenden Replikations-Datenverkehr zu minimieren. Die globalen Katalogpartionen werden gefüllt.
Der DFSR- oder FRS-Dienst wird gestartet. Da keine Datenbank vorhanden ist, wird SYSVOL nicht autoritativ von einem Replikationspartner in eingehender Richtung repliziert. Dieser Prozess verwendet bereits vorhandene Daten im SYSVOL-Ordner, um den Replikationsdatenverkehr im Netzwerk zu minimieren.
Der Gast aktiviert die DNS-Clientregistrierung erneut, da der Computer nun eindeutig benannt und mit dem Netzwerk verbunden ist.
Der Gast führt die im <SysprepInformation>-Element in der Datei „DefaultDCCloneAllowList.xml“ angegebenen SYSPREP-Module aus, um Verweise auf den vorherigen Computernamen und die frühere SID zu entfernen.
Klonvorgang und Heraufstufung sind abgeschlossen.
Der Gast entfernt das DSRM-Startkennzeichen, sodass der nächste Neustart normal ausgeführt wird.
Der Gast benennt die Datei „DCCloneConfig.xml“ mit angefügtem Datums-/Uhrzeitstempel um, sodass diese beim nächsten Neustart nicht erneut gelesen wird.
Der Gast entfernt den VdcIsCloning DWORD-Registrierungswert unter HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters.
Der Gast setzt den "VdcCloningDone" DWORD-Registrierungswert unter HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters auf 0x1. Windows verwendet diesen Wert nicht, stellt ihn jedoch als Markierung für Drittanbieter bereit.
Der Gast aktualisiert das msDS-GenerationID-Attribut seines eigenen geklonten Domänencontroller-Objekts auf den aktuellen Wert der Gast-VM-Generations-ID.
Der Gast wird neu gestartet. Er ist nun ein normaler Domänencontroller mit Ankündigungen.
Architektur zur sicheren Wiederherstellung virtueller Domänencontroller
Übersicht
AD DS benötigt einen von der Hypervisor-Plattform bereitgestellten Bezeichner mit dem Namen VM-Generations-ID, um die Wiederherstellung einer Momentaufnahme eines virtuellen Computers zu erkennen. AD DS speichert diesen Bezeichner bei der Heraufstufung des Domänencontrollers in der Datenbank (NTDS.DIT). Wenn ein Administrator den virtuellen Computer aus einem früheren Momentaufnahme wiederherstellt, wird der aktuelle Wert der VM-Generations-ID des virtuellen Computers mit einem Wert in der Datenbank verglichen. Unterscheiden sich die beiden Werte, wird die Aufruf-ID zurückgesetzt und der RID-Pool verworfen, um das erneute Verwenden der USN oder die mögliche Erstellung doppelter Sicherheitsprinzipale zu verhindern. Die sichere Wiederherstellung kann in zwei Szenarien erfolgen:
Beim Start eines virtuellen Domänencontrollers, nachdem eine Momentaufnahme im heruntergefahrenen Zustand wiederhergestellt wurde
Beim Wiederherstellen einer Momentaufnahme auf einem laufenden virtuellen Domänencontroller
Wenn sich der virtuelle Domänencontroller im Unterbrechungsstatus befindet und nicht heruntergefahren wurde, müssen Sie den AD DS-Dienst neu starten, um eine neue RID Pool-Anfrage auszulösen. Sie können den AD DS-Dienst über das Dienste-Snap-In oder mithilfe von Windows PowerShell (Restart-Service NTDS -force) neu starten.
In den folgenden Abschnitten wird die sichere Wiederherstellung für die einzelnen Szenarien detailliert beschrieben.
Sichere Wiederherstellung: Detaillierter Prozess
Das folgende Flussdiagramm beschreibt die sichere Wiederherstellung beim Start eines virtuellen Domänencontrollers, nachdem eine Momentaufnahme im heruntergefahrenen Zustand wiederhergestellt wurde.
Wenn der virtuelle Computer nach der Wiederherstellung einer Momentaufnahme hochfährt, erhält er vom Hypervisor-Host eine neue VM-Generations-ID aufgrund der Wiederherstellung.
Die neue VM-Generations-ID des virtuellen Computers wird mit der VM-Generations-ID in der Datenbank verglichen. Da die beiden IDs nicht übereinstimmen, werden Virtualisierungssicherheitsmaßnahmen implementiert (siehe Schritt 3 im vorigen Abschnitt). Nach Abschluss der Wiederherstellung wird die VM-Generierungs-ID des AD DS-Computerobjekts aktualisiert, um mit der neuen, vom Hypervisor-Host bereitgestellten ID übereinzustimmen.
Der Gast implementiert die folgenden Virtualisierungs-Sicherheitsmaßnahmen:
Der lokale RID-Pool wird ungültig gemacht.
Für die Domänencontroller-Datenbank wird eine neue Aufrufkennung gesetzt.
Hinweis
Dieser Teil der sicheren Wiederherstellung überlappt sich mit dem Klonvorgang. Obwohl es sich um eine sichere Wiederherstellung eines virtuellen Domänencontrollers nach dem Neustart nach einer Momentaufnahmen-Wiederherstellung handelt, werden dieselben Schritte auch beim Klonvorgang ausgeführt.
Das folgende Diagramm zeigt, wie die Virtualisierungs-Sicherheitsmaßnahmen Abweichungen durch USN-Rollback verhindern, wenn eine Momentaufnahme auf einem laufenden Domänencontroller wiederhergestellt wird.
Hinweis
Die vorige Illustration wurde vereinfacht, um die Konzepte zu erläutern.
Zum Zeitpunkt T1 erstellt der Hypervisor-Administrator eine Momentaufnahme des virtuellen DC1. DC1 hat zu diesem Zeitpunkt einen USN-Wert (highestCommittedUsn in der Praxis) von 100, einen InvocationId (im vorigen Diagramm als ID dargestellt)-Wert von A (in der Praxis wäre dies die GUID). Beim savedVMGID-Wert handelt es sich um die VM-Generations-ID in der DIT-Datei des DC (für das Computerobjekt des DC in einem Attribut mit dem Namen msDS-GenerationId gespeichert). VMGID ist der aktuelle Wert der VM-Generations-ID aus dem Treiber des virtuellen Computers. Dieser Wert wird vom Hypervisor bereitgestellt.
Zu einem späteren Zeitpunkt T2 werden 100 Benutzer zu diesem DC hinzugefügt (betrachten Sie Benutzer als ein Beispiel für Änderungen, die zwischen T1 und T1 auf diesem DC durchgeführt wurden. Diese Änderungen können in der Praxis eine Mischung aus Benutzererstellungen, Gruppenerstellungen, Kennwortänderungen, Attributänderungen usw. sein). In diesem Beispiel verbraucht jede Änderung eine eindeutige USN (obwohl eine Benutzererstellung in der Praxis mehr als eine USN verbrauchen kann). Vor der Übernahme dieser Änderungen prüft DC1, ob der Wert der VM-Generations-ID in dessen Datenbank (savedVMGID) mit dem aktuellen, aus dem Treiber verfügbaren Wert (VMGID), übereinstimmt. Die beiden Werte sind gleich, da noch kein Rollback erfolgt ist. Daher werden die Änderungen übernommen, und die USN wird auf 200 festgelegt, um anzugeben, dass für die nächste Änderung USN 201 verwendet werden kann. InvocationId, savedVMGID und VMGID ändern sich nicht. Diese Änderungen werden beim nächsten Replikationszyklus auf DC2 repliziert. DC2 aktualisiert seinen hohen Grenzwert (und UptoDatenessVector), hier einfach dargestellt als DC1(A) @USN = 200. DC2 kennt also alle Änderungen aus DC1 im Kontext der Aufrufkennungen A bis USN 200.
Zum Zeitpunkt T3 wird die zum Zeitpunkt T1 erstellte Momentaufnahme auf DC1 angewendet. Für DC1 wurde ein Rollback ausgeführt. Die USN wird daher auf 100 zurückgesetzt, um anzugeben, dass USNs ab 101 für die folgenden Änderungen verwendet werden können. Zu diesem Zeitpunkt wäre der Wert von VMGID jedoch unterschiedlich auf Hypervisoren, die die VM-Generations-ID unterstützen.
Wenn auf DC1 in der Folge irgendwelche Änderungen durchgeführt werden, wird der Wert der VM-Generations-ID in der Datenbank (savedVMGID) mit dem Wert aus dem Treiber des virtuellen Computers (VMGID) verglichen. In diesem Fall stimmen die IDs nicht überein. DC1 interpretiert dies als Hinweis auf einen Rollback und löst Virtualisierungssicherheitsmaßnahmen aus. d. h. die eigene Aufrufkennung (ID = B) wird zurückgesetzt und der RID-Pool gelöscht (im vorigen Diagramm nicht gezeigt). Anschließend speichert DC1 den neuen VMGID-Wert in seiner Datenbank und committet diese Änderungen (USN 101–250) im Kontext der neuen Aufrufkennung B. Beim nächsten Replikationszyklus ist DC2 nichts über DC1 im Kontext von Aufrufkennung B bekannt, und DC2 fragt alle Daten zu DC1 im Kontext von Aufrufkennung B ab, und die auf DC1 nach der Wiederherstellung der Momentaufnahme durchgeführten Änderungen werden sicher zusammengeführt. Außerdem werden die zum Zeitpunkt T2 auf DC1 durchgeführten Änderungen (die auf DC1 nach der Wiederherstellung der Momentaufnahme verloren gegangen waren) bei der nächsten Replikation wieder auf DC1 repliziert, da diese Änderungen zuvor auf DC2 repliziert worden waren (angezeigt durch die gepunktete Linie zurück zu DC1).
Nachdem der Gast die Virtualisierungssicherheitsmaßnahmen implementiert hat, repliziert NTDS die Active Directory-Objektdifferenzen nicht autoritativ von einem Domänencontroller in eingehender Richtung. Der Aktualitätsvektor des Zielverzeichnisdienstes wird entsprechend aktualisiert. Anschließend synchronisiert der Gast SYSVOL:
Falls FRS verwendet wird, beendet der Gast den NTFRS-Dienst und setzt den D2 BURFLAGS-Registrierungswert. Anschließend wird der NTFRS-Dienst gestartet. Dabei erfolgt eine nicht autoritative Replikation in eingehender Richtung, und es werden nach Möglichkeit vorhandene und unveränderte SYSVOL-Daten wiederverwendet.
Falls DFSR verwendet wird, beendet der Gast den DFSR-Dienst und löscht die DFSR-Datenbankdateien (Standardspeicherort:%systemroot%\system volume information\dfsr\<Datenbank-GUID>). Anschließend wird der DFSR-Dienst gestartet. Dabei erfolgt eine nicht autoritative Replikation in eingehender Richtung, und es werden nach Möglichkeit vorhandene und unveränderte SYSVOL-Daten wiederverwendet.
Hinweis
- Falls der Hypervisor keine VM-Generations-ID zum Vergleich bereitstellt, unterstützt dieser die Virtualisierungs-Schutzmaßnahmen nicht und der Gast funktioniert wie ein virtualisierter Domänencontroller unter Windows Server 2008 oder einer früheren Version. Der Gast implementiert den USN Rollback-Quarantäneschutz, falls versucht wird, mit USNs zu replizieren, die unterhalb der zuletzt vom Partner-DC gesehenen USN liegen. Weitere Informationen zum USN-Rollback-Quarantäneschutz finden Sie unter USN und USN-Rollback.