Virtualisieren von Domänencontrollern mit Hyper-V

Gilt für: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Windows Server 2012 und höher unterstützen virtualisierte Domänencontroller (DCs) mit Sicherheitsvorkehrungen zur Verhinderung von USN-Rollbacks (Update Sequence Number) auf virtuellen DCs und der Möglichkeit, virtuelle DCs zu klonen. Die Virtualisierung konsolidiert verschiedene Serverrollen auf einem einzigen physischen Computer. Weitere Informationen finden Sie unter Sichere Virtualisierung von Active Directory Domain Services (AD DS).

Dieser Leitfaden beschreibt, wie DCs als 32-Bit- oder 64-Bit-Gastbetriebssysteme ausgeführt werden können.

Planen der Virtualisierung

Die folgenden Abschnitte enthalten Planungsüberlegungen, die Sie bei der Virtualisierung eines DC beachten sollten, einschließlich Hardwareanforderungen, Architektur, Konfiguration und Verwaltung von Sicherheit und Leistung.

Hyper-V-Anforderungen

Um die Hyper-V-Rolle zu installieren und zu verwenden, muss Ihre Hardware die folgenden Anforderungen erfüllen:

• Sie müssen einen x64-Prozessor haben.

• Ihr Prozessor muss die Möglichkeit bieten, die hardwaregestützte Virtualisierungsfunktion zu aktivieren.

  • In der Regel wird diese Einstellung als Intel Virtualization Technology (Intel VT) oder Advanced Micro Devices Virtualization (AMD-V) bezeichnet.

• Ihr Prozessor muss die Hardware Data Execution Protection (DEP) unterstützen.

  • Sie können Hyper-V nur verwenden, wenn Sie das Intel-Bit „execute disable“ (XD) oder das AMD-Bit „no execute“ (NX) aktivieren.

Vermeiden Sie einzelne Fehlerquellen

Bei der Planung Ihrer virtuellen DC-Bereitstellung sollten Sie eine Strategie zur Vermeidung von Single Points of Failure entwickeln. Durch die Implementierung von Systemredundanzen können Sie potenzielle Single Points of Failure oder Bereiche, in denen ein Ausfall das gesamte System lahmlegen kann, vermeiden.

Die folgenden Empfehlungen können dazu beitragen, einzelne Fehlerquellen zu vermeiden. Es ist jedoch auch wichtig zu bedenken, dass die Befolgung dieser Empfehlungen die Verwaltungskosten erhöhen kann.

• Verwenden Sie pro Domäne mindestens zwei virtualisierte Domänencontroller auf verschiedenen Virtualisierungshosts. Diese Konfiguration verringert das Risiko, alle DCs zu verlieren, wenn ein Virtualisierungshost nicht mehr funktioniert.

• Diversifizieren Sie die Hardware, auf der Ihre DCs laufen. Verwenden Sie zum Beispiel verschiedene CPUs, Motherboards, Netzwerkadapter usw. Diverse Hardware verhindert Schäden durch Geräte- und Hardwarefehlfunktionen oder die Konfiguration des Herstellers.

• Betreiben Sie Ihre DCs nach Möglichkeit auf Hardware, die sich in verschiedenen Regionen befindet. Dieser Ansatz verringert die Folgen von Katastrophen, die einen der Standorte betreffen, an denen Ihre DCs gehostet werden.

• Fügen Sie physische DCs zu all Ihren Domänen hinzu. Wenn Sie Ihr System so konfigurieren, dass es über physische DCs verfügt, verhindern Sie, dass Ihre Hostsysteme Störungen der Virtualisierungsplattform ausgesetzt sind.

Sicherheitshinweise

Sie müssen den Host-Computer, auf dem Sie Ihre virtuellen DCs ausführen, genauso sorgfältig verwalten wie einen beschreibbaren DC, auch wenn es sich bei dem Computer nur um einen domänenverbundenen oder Arbeitsgruppen-Computer handelt. Dies ist aus Sicherheitsgründen erforderlich. Falsch verwaltete Hosts sind anfällig für Angriffe zur Erhöhung von Berechtigungen, bei denen sich böswillige Benutzer Zugriff auf höhere Berechtigungen verschaffen, als sie eigentlich haben sollten, weil der Administrator einer untergeordneten Rolle die falsche Berechtigungsstufe zugewiesen hat. Diese Angriffe können alle virtuellen Maschinen (VMs), Domänen und Forests gefährden, die von dem betroffenen Computer gehostet werden.

Wenn Sie planen, Ihren DC zu virtualisieren, sollten Sie die folgenden Sicherheitsaspekte beachten:

• Die lokalen Admin-Anmeldeinformationen eines Computers, der virtuelle beschreibbare DCs hostet, sollten dem Standard-Domänen-Admin aller Domänen und Forests, zu denen diese DCs gehören, gleichgestellt werden.

• Wir empfehlen Ihnen, Ihr System so zu konfigurieren, dass ein Host mit einer Server Core-Installation von Windows Server ohne andere Anwendungen als Hyper-V ausgeführt wird. Diese Konfiguration beschränkt die Anzahl der Anwendungen und Server, die Sie auf dem Server installieren können. Diese Einschränkung führt zu einer besseren Systemleistung und schafft auch eine geringere Angriffsfläche, bei der es weniger Einstiegspunkte für bösartige Angriffe über Anwendungen und Dienste gibt.

• Für Zweigstellen oder andere schwer zu sichernde Standorte empfehlen wir die Verwendung von schreibgeschützten DCs (RODCs). Wenn Sie ein separates Verwaltungsnetzwerk haben, empfehlen wir, den Host nur mit dem Verwaltungsnetzwerk zu verbinden. Weitere Informationen zu RODCs finden Sie unter Installieren Sie einen Windows Server Active Directory Read-Only Domain Controller (RODC) (Level 200).

• Sie können Ihre DCs mit BitLocker sichern. In Windows Server 2016 und höher können Sie auch die virtuelle Trusted Platform Module (TPM)-Funktion verwenden, die das zum Entsperren des Systemvolumens erforderliche Gastschlüsselmaterial bereitstellt.

• Geschütztes Fabric und abgeschirmte VMs können weitere Mechanismen zum Schutz Ihrer Domänencontroller bereitstellen.

Weitere Informationen zum Schützen von Domänencontrollern finden Sie im Leitfaden mit bewährten Methoden für den Schutz von Active Directory-Installationen.

Sicherheitsgrenzen für Host- und Gastkonfigurationen

Sie können virtuelle Maschinen (VMs) auf vielen verschiedenen Arten von DC-Konfigurationen implementieren. Daher müssen Sie sorgfältig abwägen, wie sich diese VMs auf Grenzen und Vertrauensstellungen in Ihrer Active Directory-Topologie auswirken. Die folgende Liste beschreibt zwei Konfigurationen, die Sie für Active Directory-DCs und -Hosts auf einem Hyper-V-Server und für Gastcomputer, die als VMs auf dem Hyper-V-Server ausgeführt werden, einrichten können:

• Ein Host, der eine Arbeitsgruppe oder ein Mitgliedscomputer ist, mit einem Gast, der ein DC ist.
• Ein Host, der ein Arbeitsgruppen- oder Mitgliedscomputer ist, mit einem Gast, der ebenfalls ein Arbeitsgruppen- oder Mitgliedscomputer ist.

Das folgende Diagramm zeigt eine Konfiguration von drei Gast-DC-VMs, die auf einem Hyper-V-Server gehostet werden.

Ein Diagramm für eine beispielhafte Bereitstellung von drei virtuellen Maschinen (VMs) und einem Hyper-V-Server. Die drei VMs befinden sich innerhalb eines blauen Rechtecks mit der Aufschrift „Gastmaschinen“ Alle drei VMs sind Domänencontroller. VM 1 befindet sich in der Domäne Corp und in der Gesamtstruktur Contoso.com. VM2 befindet sich in der Domäne Fabrikam und in der Gesamtstruktur Fabrikam.com. VM 3 befindet sich in der HQ-Domäne und in der Fineartschool.net-Gesamtstruktur. Der Hyper-V-Server befindet sich außerhalb des blauen Rechtecks. Es handelt sich um einen Mitgliedsserver, der sich in der Domäne Corp und der Gesamtstruktur Contoso.com befindet.

Ausgehend von der Beispielkonfiguration im vorherigen Diagramm finden Sie hier einige wichtige Überlegungen, die Sie bei der Planung einer derartigen Bereitstellung anstellen sollten:

• Administrator-Zugang

  • Die Anmeldedaten des Administrators auf dem Host-Computer sollten mit denen des Domänenadministrators auf dem beschreibbaren DC gleichgesetzt werden. Bei einem RODC-Gast sollten die Administrator-Anmeldeinformationen des Host-Computers genauso behandelt werden wie die des lokalen Administrators auf dem Gast-RODC.

• DC-Verwaltungsrechte auf dem Host-Computer

  • Ein Administrator eines virtualisierten DCs hat administrative Rechte auf dem Host, wenn Sie den Host mit derselben Domäne verbinden. Diese Zugriffsberechtigung kann jedoch auch böswilligen Benutzern die Möglichkeit geben, alle VMs zu kompromittieren, wenn sie sich Zugang zu VM 1 verschaffen können. Dieses Szenario schafft einen möglichen Angriffsvektor. Sie können diesen Angriffsvektor verhindern, indem Sie sicherstellen, dass alle DCs, die für mehrere Domänen oder Forests konfiguriert sind, eine zentrale Verwaltungsdomäne haben, der alle Domänen vertrauen, und den Virtualisierungshost zu einem Mitglied der hoch privilegierten Verwaltungsdomäne machen. Dieser Ansatz verhindert, dass einzelne Domänenadministratoren den Host und damit die anderen Domänen kontrollieren können.

• Vermeidung von Angriffen

  • Böswillige Anwender können VM 1 angreifen, auch wenn Sie sie als RODC installieren. Obwohl RODC-Administratoren nicht explizit über Domänenadministratorrechte verfügen, können sie dennoch über den RODC Richtlinien auf den Hostcomputer anwenden. Diese Richtlinien können zum Beispiel Startskripte enthalten. Wenn ein böswilliger Akteur einen Weg findet, um RODC-Administratorrechte zu erhalten und eine Richtlinie mit einem böswilligen Startskript zu senden, kann er den Host-Computer kompromittieren und ihn verwenden, um andere VMs auf dem Host zu kompromittieren.

• Sicherheit von VHD-Dateien (virtuelle Festplatten)

  • VHD-Dateien für einen virtuellen DC sind wie die physische Festplatte eines physischen DCs. Sie sollten bei der Sicherung der VHD-Datei genauso vorsichtig sein wie bei einer Festplatte. Stellen Sie sicher, dass nur zuverlässige und vertrauenswürdige Administratoren auf diese VHD-Dateien zugreifen können.

• RODCs

  • Sie können RODCs an Standorten platzieren, an denen die physische Sicherheit nicht gewährleistet ist, z. B. in Zweigstellen. Sie können ihre VHD-Dateien mit Windows BitLocker Drive Encryption vor Angriffen auf den Host schützen, die den Diebstahl der physischen Festplatte beinhalten. Diese Schutzmaßnahmen gelten jedoch nicht für die Dateisysteme innerhalb des RODC.

Überlegungen zur Leistung

Die Microkernel 64-Bit-Architektur bietet eine bessere Hyper-V-Leistung als frühere Virtualisierungsplattformen.

Die Leistung einer VM hängt von der Arbeitslast ab, für die Sie sie einsetzen. Wir empfehlen Ihnen, bestimmte VM-Topologien zu testen, um sicherzustellen, dass Sie mit der Leistung Ihrer Active Directory-Bereitstellung zufrieden sind. Sie können die Leistung unter Arbeitslasten über einen bestimmten Zeitraum mit Tools wie dem Reliability and Performance Monitor (Perfmon.msc) oder dem Microsoft Assessment and Planning (MAP) Toolkit bewerten. Das MAP-Tool kann Ihnen auch dabei helfen, eine Bestandsaufnahme aller Server und Serverrollen in Ihrem Netzwerk zu erstellen.

Um Ihnen eine Vorstellung davon zu geben, wie das Testen der Leistung virtualisierter DCs funktioniert, haben wir einen Beispielleistungstest mit dem Active Directory Performance Testing Tool (ADTest.exe) erstellt.

Lightweight Directory Access Protocol (LDAP) Tests wurden auf einem physischen DC mit ADTest.exe durchgeführt. Die gleichen Tests wurden mit einem virtualisierten DC durchgeführt, der aus einer VM bestand, die auf einem mit dem physischen DC identischen Server gehostet wurde. In diesem Beispiel wurde nur ein logischer Prozessor für den physischen Computer und nur ein virtueller Prozessor für die VM verwendet. Mit dieser Konfiguration konnte die CPU-Auslastung leicht 100 Prozent erreichen.

In der folgenden Tabelle sind die Testergebnisse für die physischen und virtuellen DCs aufgeführt. Die Buchstaben und Zahlen in Klammern neben den Testnamen sind ihre Bezeichnungen in ADTest.exe. Diese Daten zeigen, dass die Leistung des virtualisierten DC zwischen 88 und 98 Prozent der Leistung des physischen DC lag.

Messung	Test	Physisch	Virtuell	Delta
Suchen/Sek.	Suche nach einem allgemeinen Namen im Basisbereich (L1)	11.508	10.276	-10,71 %
Suchen/Sek.	Suche nach einem Attributsatz im Basisbereich (L2)	10123	9005	-11,04 %
Suchen/Sek.	Suche nach allen Attributen im Basisbereich (L3)	1284	1.242	-3,27 %
Suchen/Sek.	Suche nach einem allgemeinen Namen im Unterstrukturbereich (L6)	8.613	7904	-8,23 %
Erfolgreiche Bindungen/Sek.	Ausführen schneller Bindungen (B1)	1438	1.374	-4,45 %
Erfolgreiche Bindungen/Sek.	Ausführen einfacher Bindungen (B2)	611	550	-9,98 %
Erfolgreiche Bindungen/Sek.	Ausführen von Bindungen mithilfe von NTLM (B5)	1068	1056	-1,12 %
Schreibvorgänge/s	Schreiben mehrerer Attribute (W2)	6.467	5.885	-9,00 %

Um die Leistung in unserem Testeinsatz zu maximieren, haben wir in diesem Test-Build Integrationskomponenten (IC) installiert, die es dem Gastbetriebssystem ermöglichen, Hypervisor-fähige synthetische Treiber zu verwenden. Wenn Sie einen IC installieren, müssen Sie manchmal emulierte IDE-Treiber (Integrated Drive Electronics) oder Netzwerkadaptertreiber verwenden. In Produktionsumgebungen sollten Sie diese emulierten Treiber durch synthetische Treiber ersetzen, um die Leistung zu optimieren.

Ziehen Sie auf der Grundlage dieses Tests die folgenden Empfehlungen zur Verbesserung der Leistung in Betracht:

• Wenn Sie die VM-Leistung mit dem Tool Perfmon.msc überwachen, sind die CPU-Informationen für die VM manchmal nicht ganz genau. Diese Ungenauigkeit ist darauf zurückzuführen, wie die virtuelle CPU auf dem physischen Prozessor geplant ist. Für genauere CPU-Informationen für VMs, die auf Hyper-V-Servern laufen, verwenden Sie stattdessen die Zähler des Hyper-V Hypervisor Logical Processor in der Host-Partition. Weitere Informationen zur Leistungsoptimierung für AD DS und Hyper-V finden Sie unter Richtlinien zur Optimierung der Leistung für Windows Server 2022.

• Wir empfehlen, die Verwendung von VHDs mit unterschiedlichen Festplatten auf einer als DC konfigurierten VM zu vermeiden, da VHDs mit unterschiedlichen Festplatten die Leistung verringern können. Weitere Informationen zu Hyper-V-Datenträgertypen, einschließlich differenzierender Datenträger, finden Sie unter New Virtual Hard Disk Wizard (Assistent für neue virtuelle Festplatten).

• Wir empfehlen Ihnen auch, sich mit den Informationen über die Verwendung von AD DS in virtuellen Hosting-Umgebungen vertraut zu machen, indem Sie Dinge, die Sie beim Hosten von Active Directory-DCs in virtuellen Hosting-Umgebungen beachten sollten lesen.

Überlegungen zur Bereitstellung

In den folgenden Abschnitten werden allgemeine VM-Methoden beschrieben, die bei der Bereitstellung von Domänencontrollern vermieden werden sollten. Außerdem werden dort besondere Überlegungen im Zusammenhang mit Zeitsynchronisierung und Speicherung behandelt.

Bereitstellungsempfehlungen

Virtualisierungsplattformen wie Hyper-V verfügen über zahlreiche Funktionen, die die Verwaltung, Wartung, Sicherung und Migration von Rechnern erleichtern. Es gibt jedoch bestimmte Empfehlungen, die Sie befolgen müssen, um die Vorteile dieser Funktionen für Ihre virtuellen DCs zu nutzen.

• Um sicherzustellen, dass Ihre Active Directory-Schreibvorgänge dauerhaft sind, sollten Sie virtuelle DC-Datenbankdateien, wie die NTDS.DIT Active Directory-Datenbank, Protokolle und SYSVOL, nicht auf virtuellen IDE-Festplatten bereitstellen. Erstellen Sie stattdessen eine zweite virtuelle Festplatte (VHD), die an einen virtuellen Small Computer System Interface (SCSI)-Controller angeschlossen ist, und stellen Sie sicher, dass sich die Datenbankdateien auf der VM-SCSI-Platte befinden, wenn Sie den DC installieren.

• Implementieren Sie keine VHDs mit unterschiedlichen Festplatten auf einer VM, die Sie als DC konfigurieren. Dieser Ansatz erleichtert zwar die Rückgängigmachung der Bereitstellung auf frühere Versionen, verringert aber auch die Leistung. Weitere Informationen zu VHD-Typen finden Sie unter New Virtual Hard Disk Wizard (Assistent für neue virtuelle Festplatten).

• Stellen Sie Active Directory-Domänen und -Wälder nicht auf einer Kopie eines Windows Server-Betriebssystems bereit, ohne sie zuvor mit dem Systemvorbereitungstool (sysprep) für die Bereitstellung vorzubereiten. Weitere Informationen zum Ausführen von Sysprep finden Sie unter Übersicht über Sysprep (Systemvorbereitung).

  Warnung

  Es wird nicht empfohlen, Sysprep auf einem aufgerüsteten DC auszuführen, da es sich negativ auf die AD-Datenbank und die damit verbundenen Komponenten auswirken und die folgenden Probleme verursachen kann:

  • Datenverlust
  • Beschädigung der AD-Datenbank
  • Stabilitäts- und Funktionsprobleme
  • Probleme mit Anwendungen, Diensten und Treibern

• Stellen Sie keine anderen DCs mit einer Kopie einer VHD-Datei von einem DC bereit, das Sie bereitgestellt haben. Die Nichtverwendung von Kopien verhindert mögliche USN-Rollback-Szenarien. Weitere Informationen zum USN-Rollback finden Sie unter USN und USN-Rollback.

  • In Windows Server 2012 und höher können Administratoren DC-Images klonen, um weitere DCs bereitzustellen, allerdings nur, wenn sie ordnungsgemäß vorbereitete Images verwenden.

• Verwenden Sie die Hyper-V-Exportfunktion nicht, um eine VM zu exportieren, auf der ein DC ausgeführt wird.

  • In Windows Server 2012 und höher behandelt das System das Exportieren und Importieren von virtuellen DC-Gästen wie eine nicht autorisierte Wiederherstellung. Dieser Prozess erkennt, ob sich die Generations-ID geändert hat und ob der DC nicht für das Klonen konfiguriert ist.

  • Wenn Sie eine Gast-VM exportieren, müssen Sie sicherstellen, dass sie von niemandem benutzt wird. Um die Arbeit zu erleichtern, können Sie mit Hyper-V Replication eine inaktive Kopie des DC erstellen. Wenn Sie mit der Verwendung des replizierten Abbilds beginnen, müssen Sie wie beim Quellabbild nach dem Exportieren eines DC-Gastabbilds eine Bereinigung durchführen.

Konvertierung von physisch zu virtuell

Mit System Center VM Manager (VMM) können Sie physische Maschinen und VMs auf eine einheitliche Weise verwalten. Sie können auch VMM verwenden, um einen physischen Computer in eine VM zu migrieren. Dieser Migrationsprozess wird als physical-to-VM conversion oder P2V-Konvertierung bezeichnet. Um den P2V-Konvertierungsprozess zu starten, müssen Sie sicherstellen, dass die VM und der physische DC, die Sie migrieren, nicht gleichzeitig ausgeführt werden. Wenn Sie sicherstellen, dass die beiden Maschinen nicht gleichzeitig laufen, verhindern Sie USN-Rollback-Szenarien, wie in USN und USN-Rollback beschrieben.

Sie sollten die P2V-Konvertierung im Offline-Modus durchführen, damit die Verzeichnisdaten konsistent bleiben, wenn Sie den DC wieder einschalten. Sie können den Offline-Modus im Convert Physical Server-Installationsprogramm einschalten. Weitere Informationen über die Verwendung des Offline-Modus finden Sie unter P2V: Konvertierung physischer Computer in VMs im VMM.

Außerdem sollten Sie die VM während der P2V-Konvertierung vom Netzwerk trennen. Sie sollten den Netzwerkadapter erst aktivieren, wenn Sie den Konvertierungsprozess abgeschlossen haben und überprüfen, ob alles funktioniert. Zu diesem Zeitpunkt sollten Sie den physischen Quellcomputer ausschalten. Schalten Sie den physischen Quellcomputer erst wieder ein und verbinden Sie ihn mit dem Netzwerk, nachdem Sie die Festplatte neu formatiert haben.

Vermeidung eines USN-Rollbacks

Wenn Sie virtuelle DCs erstellen, sollten Sie die Erstellung von USN-Rollback-Szenarien vermeiden. Um einen Rollback zu vermeiden, können Sie einen neuen virtuellen DC mit regulärer Promotion, Promotion durch Install from Media (IfM) oder durch Klonen des DC einrichten, wenn Sie bereits mindestens einen virtuellen DC haben. Mit diesem Ansatz können Sie auch Hardware- oder Plattformprobleme vermeiden, die bei P2V-konvertierten virtuellen Gästen auftreten können.

Warnung

Um Probleme mit der Active Directory-Replikation zu vermeiden, stellen Sie sicher, dass zu jedem Zeitpunkt nur ein physischer oder virtueller DC in einem bestimmten Netzwerk existiert. Sie können eine der folgenden Methoden verwenden, um die Wahrscheinlichkeit zu verringern, dass der alte Klon zu einem Problem wird:

• Wenn der neue virtuelle DC ausgeführt wird, führen Sie den folgenden Befehl zweimal aus, um das Passwort des Computerkontos zu ändern:

  netdom resetpwd /Server:<domain-controller>
  

• Exportieren und importieren Sie den neuen virtuellen Gast, um zu erzwingen, dass er eine neue Generierungs-ID und damit eine Datenbankaufruf-ID erhält.

Testumgebungen und P2V-Migration

Sie können die P2V-Migration in Kombination mit dem VMM verwenden, um Testumgebungen zu erstellen. Mit dieser Methode können Sie Produktions-DCs von physischen Rechnern auf VMs migrieren, um eine Testumgebung zu schaffen, ohne die Produktions-DCs dauerhaft außer Betrieb zu setzen. Sie müssen jedoch die Testumgebung in einem von der Produktionsumgebung getrennten Netzwerk aufbauen, damit zwei Instanzen desselben DCs existieren können. Es ist wichtig, USN-Rollbacks zu vermeiden, wenn Sie Testumgebungen mit P2V-Migration erstellen.

Erstellen einer Testumgebung

Wir empfehlen Ihnen, bei der Erstellung von Testumgebungen mit P2V wie folgt vorzugehen:

• Migrieren Sie einen Produktiv-DC aus jeder Domäne in eine Test-VM, indem Sie P2V gemäß den Empfehlungen in Physikalische-zu-virtuelle-Konvertierung verwenden.

• Platzieren Sie die physischen Produktionsmaschinen und die Test-VMs in unterschiedlichen Netzwerken, wenn Sie sie wieder online stellen.

• Um USN-Rollbacks in der Testumgebung zu vermeiden, trennen Sie alle DCs, die Sie migrieren möchten, vom Netzwerk. Sie können Ihre DCs abschalten, indem Sie den NTDS-Dienst stoppen oder die Rechner im Verzeichnisdienst-Wiederherstellungsmodus (DSRM) neu starten.

• Führen Sie keine neuen Updates in der Umgebung ein, nachdem Sie die DCs vom Netzwerk getrennt haben.

• Verbinden Sie während der P2V-Migration keinen der Rechner mit dem Netzwerk. Sie können sie erst wieder verbinden, wenn Sie die Migration aller Rechner abgeschlossen haben.

• Sie sollten nur Test-DCs, die Sie nach der P2V-Konvertierung erstellen, als Replikate in die Testumgebung aufnehmen.

Zeitdienst und Synchronisierung

Für VMs, die Sie als DCs konfiguriert haben, empfehlen wir, die Zeitsynchronisierung zwischen dem Hostsystem und dem Gastbetriebssystem, das als DC fungiert, zu deaktivieren. Wenn der Gast-DC nicht mit dem Hostsystem synchronisiert wird, wird er stattdessen mit der Domänenhierarchie synchronisiert.

Um den Hyper-V Zeitsynchronisationsanbieter zu deaktivieren, schalten Sie die VM aus, gehen Sie dann zu den VM-Einstellungen, wählen Sie Integration Services und deaktivieren Sie das Kontrollkästchen Zeitsynchronisation.

Speicher und Optimierung

Wir empfehlen Ihnen, die Speicherempfehlungen in diesem Abschnitt zu befolgen, um die Leistung Ihrer DC-VM zu optimieren und sicherzustellen, dass Ihre Active Directory-Schreibvorgänge dauerhaft sind.

• Speichern Sie für den Gastspeicher die Active Directory-Datenbankdatei (Ntds.dit) sowie die Protokoll- und SYSVOL-Dateien auf einer von den Betriebssystemdateien getrennten virtuellen Festplatte. Wir empfehlen Ihnen, diese Dateien auf einer virtuellen SCSI-Platte in einer zweiten VHD zu speichern, die an einen virtuellen SCSI-Controller angeschlossen ist. Eine virtuelle SCSI-Festplatte erhöht die Leistung und unterstützt Forced Unit Access (FUA). Mit FUA schreibt und liest das Betriebssystem direkt von den Medien und umgeht dabei jegliche Zwischenspeicherungsmechanismen.

• Wenn Sie BitLocker zum Sichern Ihres virtuellen DC-Gastes verwenden, konfigurieren Sie die zusätzlichen Volumes für die automatische Entsperrung mit dem PowerShell-Cmdlet Enable-BitLockerAutoUnlock.

• Wenn Sie VHD-Dateien auf Hosts speichern, sollten Sie einen Datenträger verwenden, der nicht häufig von anderen Diensten oder Anwendungen verwendet wird, z. B. den Systemdatenträger des Host-Betriebssystems. Speichern Sie jede VHD-Datei auf einer vom Host-Betriebssystem und anderen VHD-Dateien getrennten Partition, vorzugsweise auf einem separaten physischen Laufwerk.

• Ihr physisches Host-Festplattensystem muss mindestens eines der folgenden Kriterien erfüllen, um die Anforderungen an die Datenintegrität virtualisierter Workloads zu erfüllen:

  • Der Host verwendet Festplatten der Serverklasse, wie SCSI oder Fibre Channel.

  • Der Host stellt sicher, dass die Festplatten an einen batteriegepufferten Caching-HBA angeschlossen sind.

  • Der Host verwendet einen Speicher-Controller wie ein RAID-System (Redundant Array of Independent Disks) als Speichergerät.

  • Der Host verwendet eine unterbrechungsfreie Stromversorgung (USV) zur Stromversorgung der Festplatte.

  • Der Host deaktiviert die Schreib-Caching-Funktion der Festplatte standardmäßig.

• Bei der Verwendung von VHD-Dateien empfehlen wir die Verwendung von Pass-Through-Datenträgern oder VHDs mit fester Größe, da diese für die Leistung optimiert sind. Wir raten davon ab, Festplatten dynamisch zu erweitern und zu differenzieren, da dies zu Verzögerungen, Leistungseinbußen bei hoher Festplattenaktivität und potenziellem Datenverlust beim Zurücksetzen auf einen früheren Snapshot führen kann.

• Wir empfehlen Ihnen, virtuelle SCSI-Controller zu verwenden, um das Risiko einer Beschädigung Ihrer Active Directory-Daten zu verringern.

  • Auf Hyper-V-Servern, die virtuelle DCs hosten, sollten Sie physische SCSI-Laufwerke verwenden. Wenn Sie in Ihrem Szenario keine SCSI-Laufwerke verwenden können, sollten Sie stattdessen das Schreibcaching auf dem Advanced Technology Attachment (ATA)- oder Integrated Drive Electronics (IDE)-Laufwerk deaktivieren. Weitere Informationen finden Sie unter Ereignis-ID 1539 – Datenbankintegrität.

Betriebseinschränkungen für VM-Domänencontroller

Die Verwendungsmöglichkeiten von Domänencontrollern, die auf virtuellen Computern ausgeführt werden, sind im Vergleich zu Domänencontrollern, die auf physischen Computern ausgeführt werden, eingeschränkt. Wenn Sie einen virtualisierten DC verwenden, müssen Sie diese Richtlinien befolgen:

• Der gespeicherte Zustand eines DCs darf nicht länger als die Tombstone-Lebensdauer des Forests in einer VM unterbrochen, angehalten oder gespeichert werden. Die Wiederaufnahme eines gespeicherten Zustands, den Sie angehalten oder länger als die Tombstone-Lebensdauer gespeichert haben, kann die Replikation beeinträchtigen. Informationen zur Bestimmung der Tombstone-Lebensdauer für die Gesamtstruktur finden Sie unter Determine the tombstone lifetime for the forest (Bestimmen der Tombstone-Lebensdauer für die Gesamtstruktur).

• VHDs dürfen nicht kopiert oder geklont werden.

• Erstellen oder verwenden Sie keine Snapshots von virtuellen DCs. Sie sollten stattdessen eine dauerhafte und zuverlässige Sicherungsmethode verwenden.

• Verwenden Sie das Exportfeature nicht auf einem virtuellen Computer, auf dem ein Domänencontroller ausgeführt wird.

• Stellen Sie Ihren DC oder den Inhalt einer Active Directory-Datenbank nicht mit einer nicht unterstützten Sicherungsmethode wieder her oder führen Sie ein Rollback durch.

Überlegungen zu Sicherung und Wiederherstellung

Sie müssen Ihre DCs sichern, um Datenverluste aufgrund von Katastrophenszenarien oder Verwaltungsfehlern zu vermeiden. Die von Active Directory unterstützte Backup-Methode ist die Verwendung einer Backup-Anwendung zur Wiederherstellung eines Systemstatus-Backups, das von der aktuellen Installation des DCs erstellt wurde. Es sollte sich um eine Anwendung handeln, die mit Active Directory kompatibel ist, wie z. B. Windows Server Backup. Weitere Informationen zu unterstützten Sicherungsmethoden finden Sie unter AD DS Sicherung und Wiederherstellung Schritt-für-Schritt-Anleitung.

Bei virtualisierten Bereitstellungen müssen Sie bestimmte Anforderungen für Active Directory-Sicherungsvorgänge besonders beachten. Wenn Sie beispielsweise einen DC mit einer Kopie der VHD-Datei wiederherstellen und die Datenbankversion des DC nach der Wiederherstellung nicht aktualisieren, kann dies zu Problemen bei der Replikation führen, da die Nummern der DC-Replikate nicht korrekt sind. In den meisten Fällen erkennt die Replikation dieses Problem nicht und meldet keine Fehler, aber Inkonsistenzen zwischen DCs können in bestimmten Szenarien zu Problemen führen.

Empfohlene Methode zur Sicherung und Wiederherstellung von virtualisierten DCs

Die von uns empfohlene Methode zur Sicherung und Wiederherstellung Ihrer virtualisierten DCs ist die Ausführung von Windows Server Backup im Gastbetriebssystem. Weitere Informationen finden Sie unter Wiederherstellen eines virtuellen Domänencontrollers.

Obwohl Sie technisch gesehen Snapshots oder Kopien von VHD-Dateien zur Wiederherstellung eines Backups verwenden können, raten wir aus den folgenden Gründen von diesen Methoden ab:

• Wenn Sie eine VHD-Datei kopieren oder klonen, wird die Datenbank veraltet, da die Versionsnummer der Datenbank beim Wiederherstellen nicht automatisch aktualisiert wird. Diese Inkonsistenz bei den Tracking-Nummern bedeutet, dass Sie, wenn Sie die VHD im normalen Modus starten, möglicherweise einen USN-Rollback verursachen können.

• Windows Server 2016 und spätere Versionen sind zwar mit Snapshots kompatibel, aber Snapshots bieten nicht die Art von stabilem, dauerhaftem Sicherungsverlauf, den Sie für die konsistente Wiederherstellung Ihres Systems in Katastrophenszenarien benötigen. Die auf VSS (Volume Shadow Copy Service) basierenden Snapshots, die Sie in Windows Server 2016 Hyper-V und höher erstellen können, sind ebenfalls nicht mit BitLocker kompatibel, was zu potenziellen Sicherheitsproblemen führen kann. Dieses Problem verhindert, dass die Active Directory-Datenbank-Engine auf die Datenbank zugreifen kann, die den Snapshot enthält, wenn Hyper-V versucht, das Snapshot-Volume zu mounten.

Hinweis

Das unter Guarded Fabric und Shielded VMs beschriebene Shielded VM-Projekt hat ein Hyper-V Host-gesteuertes Backup als Nicht-Ziel für maximalen Datenschutz der Gast-VM.

USN und USN-Rollback

In diesem Abschnitt werden Replikationsprobleme beschrieben, die auftreten können, wenn die Active Directory-Datenbank nicht ordnungsgemäß mit einer älteren Version eines virtuellen Computers wiederhergestellt wurde. Weitere Informationen zum Active Directory-Replikationsprozess finden Sie unter Active Directory-Replikationskonzepte.

Verwendung von USNs durch AD DS und Domänencontroller

AD DS verwendet USNs, um die Replikation von Daten zwischen Domänencontrollern nachzuverfolgen. Jedes Mal, wenn Sie Daten im Verzeichnis ändern, wird die USN erhöht, um eine neue Änderung anzuzeigen.

Ziel-DCs verwenden USNs, um Aktualisierungen für jede Verzeichnispartition, die sie speichern, zu verfolgen. Der USN verfolgt auch den Status jedes DC, das Repliken dieser Verzeichnispartitionen speichert. Wenn DCs Änderungen untereinander replizieren, fragen sie ihre Replikationspartner nach Änderungen mit USNs ab, die größer sind als die letzte Änderung, die der DC von seinem Partner erhalten hat.

Die Replikationsmetadatentabellen, die die USNs enthalten, finden Sie im Aktualitätsvektor und in der Hochwassermarke. Sowohl die Quell- als auch die Ziel-DCs verwenden diese Tabellen, um erforderliche Aktualisierungen für die Ziel-DCs zu filtern.

Der Ziel-DC unterhält die Up-to-Date-Vektortabelle, um die von allen Quell-DCs empfangenen Ursprungs-Updates zu verfolgen. Wenn ein Zieldomänencontroller Änderungen für eine Verzeichnispartition anfordert, stellt er dem Quelldomänencontroller seinen Aktualitätsvektor bereit. Der Quelldomänencontroller filtert dann mithilfe dieses Werts die dem Zieldomänencontroller zu sendenden Updates. Das Quell-DC sendet seinen Aktualitätsvektor an das Ziel-DC, nachdem ein erfolgreicher Replikationszyklus beendet wurde. Die Quell-DC verwendet die USN, um festzustellen, ob die Ziel-DC mit den Ursprungs-Updates an jeder DC synchronisiert ist und ob die Updates an den Zielen auf dem gleichen Stand wie die Quelle sind.

Der Ziel-DC unterhält die High-Water-Mark-Tabelle, um die letzten Änderungen zu verfolgen, die er von einem bestimmten Quell-DC für eine bestimmte Partition erhalten hat. Die High-Water-Mark-Tabelle verhindert, dass das Quell-DC Änderungen versendet, die das Ziel-DC bereits von ihm erhalten hat.

Verzeichnisdatenbankidentität

Neben USNs wird von Domänencontrollern auch die Verzeichnisdatenbankidentität der Quellreplikationspartner nachverfolgt. Das System behält die Identität der auf dem Server laufenden Verzeichnisdatenbank getrennt von der Identität des Serverobjekts selbst bei. Die Verzeichnisdatenbankidentität auf jedem Domänencontroller wird im invocationID-Attribut des NTDS Settings-Objekts gespeichert, das sich am folgenden LDAP-Pfad (Lightweight Directory Access-Protokoll) befindet: cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*.

Das System speichert die Identität des Serverobjekts im Attribut objectGUID des Objekts NTDS Settings. Die Identität des Serverobjekts bleibt unverändert. Die Identität der Verzeichnisdatenbank ändert sich jedoch unter den folgenden Umständen:

• Wenn auf dem Server ein Verfahren zur Wiederherstellung des Systemstatus durchgeführt wird.

• Wenn Sie dem Server eine Anwendungsverzeichnispartition hinzufügen, sie dann entfernen und dann wieder hinzufügen.

• Wenn eine Hyper-V-Instanz ihre VSS-Schreiber auf einer Partition auslöst, die eine VHD eines virtuellen DCs enthält.

  In diesem Szenario löst der Gast seine eigenen VSS Writer-Instanzen aus. Diese Aktion ist derselbe Mechanismus, den auch der Sicherungs- und Wiederherstellungsprozess verwendet. Diese Methode setzt das Attribut invocationID zurück.

Das Attribut invocationID verknüpft eine Reihe von Ursprungsupdates auf einem DC mit einer bestimmten Version der Verzeichnisdatenbank. Der Aktualitätsvektor und die Hochwassermarkierungstabellen verwenden die invocationID bzw. die DC-GUID, damit die DCs erkennen können, von welcher Kopie der Active Directory-Datenbank die Replikationsinformationen stammen.

Das Attribut invocationID ist ein GUID-Wert (Globally Unique Identifier), der nach Ausführung des Befehls repadmin /showrepl am oberen Rand der Ausgabe sichtbar ist. Im Folgenden ein Beispiel für den Ausgabetext dieses Befehls:

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Wenn Sie AD DS auf einem DC wiederherstellen, setzt das System das Attribut invocationID zurück. Diese Änderung erhöht den Replikationsverkehr, dessen Dauer von der Größe der zu replizierenden Partition abhängt.

Um dieses Szenario zu veranschaulichen, zeigt das folgende Diagramm eine Beispielumgebung, in der der virtuelle Domänencontroller VDC1 und der Domänencontroller DC2 zwei DCs in derselben Domäne sind. Dieses Diagramm zeigt, wie DC2 den Wert invocationID in VDC1 nach einem Reset in einem unterstützten Wiederherstellungsszenario erkennt.

Ein Diagramm, das ein Flussdiagramm der Sicht des VDC1 auf sich selbst und der Sicht des DC2 auf das VDC1 darstellt. In der VDC1-Zeile beginnt VDC1 mit einer USN von 1000 und einer Invocation-ID von B. Dann wird die vorherige Version wiederhergestellt, die eine USN von 500 und einen InvocationID-Wert von B hat. In der Zeile „DC2 view of VDC1“ beginnt DC2 mit einer Invocation ID von VDC1(A)@USN1000. Nachdem VDC1 wiederhergestellt wurde, setzt DC2 seine erwartete USN von 1000 auf 500 zurück, wodurch sein Wert für die Invocation ID B VDC1(B)@USN500 wird. Sie verfolgt weiterhin sowohl die Invocation ID A als auch die Invocation ID B. Nach der nächsten Reihe von Änderungen an VDC1 verfolgt DC2 nun die Invocation ID A von USN 1000 und die neue Invocation ID B von USN 600 von VDC1.

USN-Rollback

Ein USN-Rollback tritt auf, wenn das System eine USN nicht wie üblich aktualisieren kann, ein Benutzer USN-Aktualisierungen umgeht oder ein DC versucht, eine USN zu verwenden, die niedriger ist als die letzte Aktualisierung. Wenn das System einen USN-Rollback feststellt, stoppt es die Replikation, bevor die Abweichung eine Divergenz im Forest verursachen kann.

Viele Faktoren können einen USN-Rollback verursachen. Dies kann zum Beispiel passieren, wenn Sie alte VHD-Dateien verwenden oder eine P2V-Konvertierung durchführen, ohne den physischen Rechner nach der Konvertierung dauerhaft zu trennen.

Verhinderung des USN-Rollbacks

Sie können USN-Rollbacks verhindern, indem Sie die folgenden Vorkehrungen treffen:

• Erstellen bzw. verwenden Sie keine Momentaufnahme eines virtuellen Domänencontrollercomputers, wenn Sie nicht mindestens Windows Server 2012 verwenden.

• Erstellen Sie keine Kopie der VHD-Datei des Domänencontrollers.

• Wenn Sie nicht Windows Server 2012 oder höher ausführen, exportieren Sie keine VM, auf der ein DC ausgeführt wird.

• Stellen Sie einen DC nur wieder her oder rollen Sie den Inhalt einer Active Directory-Datenbank nur mit unterstützten Erstanbieter-Backup-Lösungen wie Windows Server Backup zurück.

Manchmal kann das System ein USN-Rollback nicht erkennen, bevor es zu Replikationsfehlern führen kann. Wenn Sie auf Replikationsfehler stoßen, müssen Sie das Ausmaß des Problems ermitteln und es so schnell wie möglich beheben. Weitere Informationen zum Entfernen von verweilenden Objekten, die als Ergebnis eines USN-Rollbacks auftreten können, finden Sie unter Active Directory-Replikationsereignis-ID 1388 oder 1988: Ein verweilendes Objekt wird entdeckt.

USN-Rollbackerkennung

In den meisten Fällen kann das System USN-Rollbacks erkennen, indem es Inkonsistenzen im Attribut invocationID aufspürt, die durch die Wiederherstellung einer DC ohne Rücksetzung des Attributs verursacht werden. Windows Server 2008 bietet Schutz vor Replikationsfehlern nach nicht unterstützten DC-Wiederherstellungsvorgängen. Diese Schutzmaßnahmen werden ausgelöst, wenn eine nicht unterstützte Wiederherstellung USNs erzeugt, die niedriger sind als die Originalversionen und Änderungen darstellen, die die Replikationspartner bereits erhalten haben.

Wenn in Windows Server ein Ziel-DC Änderungen unter Verwendung einer zuvor verwendeten USN anfordert, interpretiert der Ziel-DC die Antwort des Replikationspartners so, dass seine Replikationsmetadaten veraltet sind. Veraltete Metadaten bedeuten, dass die Active Directory-Datenbank auf dem Quell-DC auf einen früheren Zustand zurückgesetzt wurde, so dass das System entsprechend reagiert.

Nehmen wir zum Beispiel an, die VHD-Datei einer VM wird auf eine frühere Version zurückgesetzt. In diesem Fall leitet der Ziel-DC die folgenden Quarantänemaßnahmen für den DC ein, den er als nicht unterstützte Wiederherstellung identifiziert hat:

• Der Netzwerkanmeldedienst wird von den Active Directory-Domänendiensten angehalten, wodurch Benutzer- und Computerkonten am Ändern von Kontokennwörtern gehindert werden. Diese Maßnahme verhindert den Verlust solcher Änderungen im Anschluss an eine unzulässige Wiederherstellung.

• Die ein- und ausgehende Active Directory-Replikation wird von den Active Directory-Domänendiensten deaktiviert.

• AD DS erzeugt die Ereignis-ID 2095 im Ereignisprotokoll des Verzeichnisdienstes, um den Vorfall aufzuzeichnen.

Das folgende Diagramm zeigt die Abfolge der Ereignisse, die auftreten, wenn AD DS ein USN-Rollback auf VDC2, dem Ziel-DC, der auf einer VM läuft, erkennt. In dieser Abbildung erfolgt die Erkennung eines USN-Rollbacks auf VDC2, wenn ein Replikationspartner feststellt, dass VDC2 einen aktuellen USN-Wert gesendet hat, der zuvor vom Ziel-DC gesehen wurde. Dieser Zustand zeigt an, dass die VDC2-Datenbank einen Rollback erlebt hat.

Ein Diagramm, das ein Flussdiagramm der VDC2-Aktualisierungen und den DC1-Aktualitätswert für VDC2 zeigt. VDC2 beginnt mit einer USN von 100 und der Invocation ID A. Dann aktualisiert es seine USNs von 101 auf 200, was auf DC1 repliziert wird. Der Benutzer erstellt jedoch auch eine VHD-Kopie von VDC2 USN 200. Als nächstes aktualisiert VDC2 auf USN 201 bis 350 und repliziert diese Änderungen auf DC1. VDC2 schlägt dann jedoch fehl. Der Benutzer stellt dann VDC2 mit der Kopie wieder her, die er auf der USN 200 VHD erstellt hat. Danach nimmt der Benutzer ein weiteres Update auf VDC2 vor, um eine neue Version der USNs 201-355 zu erhalten. DC1 fordert von VDC2 Änderungen an, die größer als USN 350 sind, und wird repliziert, weil die USN auf VDC2 höher ist als die von DC1. Die neuen Versionen der USNs 201 bis 350 sind jedoch nicht mit denen auf DC1 identisch, was zu einem USN-Rollback führt.

Beheben von Problemen mit der Ereignis-ID 2095

Wenn Sie die Ereignis-ID 2095 im Ereignisprotokoll des Verzeichnisdienstes sehen, befolgen Sie sofort die folgenden Anweisungen:

1. Isolieren Sie den virtuellen Computer, von dem der Fehler erfasst wurde, vom Netzwerk.

2. Prüfen Sie, ob die gemeldeten Änderungen von diesem DC stammen und auf andere DCs übertragen wurden. Wenn das Ereignis auf die Verwendung eines Snapshots oder einer Kopie einer VM zurückzuführen ist, versuchen Sie herauszufinden, wann der USN-Rollback stattgefunden hat. Sobald Sie die Zeit haben, können Sie die Replikationspartner dieses DCs überprüfen, um festzustellen, ob nach dem Rollback eine Replikation stattgefunden hat.

   Sie können mit dem Repadmin-Tool überprüfen, woher die Änderungen stammen. Weitere Informationen zur Verwendung von Repadmin finden Sie unter Monitoring and Troubleshooting Active Directory Replication Using Repadmin (Überwachung und Problembehandlung der Active Directory-Replikation mithilfe von Repadmin). Sollten Sie nicht sicher sein, wenden Sie sich an den Microsoft-Support.

3. Erzwingen Sie eine Herabstufung des Domänencontrollers. Dieser Vorgang umfasst das Bereinigen der Metadaten des DCs und das Beschlagnahmen der Operations-Master-Rollen, auch bekannt als Flexible Single Master Operations (FSMO)-Rollen. Weitere Informationen finden Sie unter Wiederherstellung von USN-Rollback.

4. Löschen Sie alle vorherigen VHD-Dateien für den Domänencontroller.

Unerkanntes USN-Rollback

In den folgenden Szenarien erkennt der DC möglicherweise kein USN-Rollback:

• Die VHD-Datei ist unterschiedlichen virtuellen Computern zugeordnet, die gleichzeitig an verschiedenen Standorten ausgeführt werden.

• Die USN des wiederhergestellten DCs ist höher als die letzte USN des anderen DCs.

Im VHD-Dateiszenario können andere DCs mit einer der beiden VMs replizieren, und Änderungen können auf einer der beiden VMs auftreten, ohne auf die andere repliziert zu werden. Solche Abweichungen in der Gesamtstruktur sind schwer zu erkennen. Das Resultat sind unvorhersehbare Verzeichnisantworten. Die beschriebene Situation kann nach einer P2V-Migration eintreten, wenn der physische Domänencontroller und der virtuelle Computer im gleichen Netzwerk aktiv sind. Möglich ist diese Situation auch, wenn mehrere virtuelle Domänencontroller auf der Grundlage des gleichen physischen Domänencontrollers erstellt und dann im gleichen Netzwerk ausgeführt werden.

Im USN-Szenario gilt eine Reihe von USNs für zwei verschiedene Gruppen von Änderungen. Dieses Szenario kann längere Zeit unerkannt bleiben. Wenn Sie ein Objekt ändern, das Sie während dieses Zeitraums erstellt haben, erkennt das System ein verweilendes Objekt und meldet es als Ereignis-ID 1988 in der Ereignisanzeige. Das folgende Diagramm zeigt, warum der DC in diesem Szenario möglicherweise kein USN-Rollback erkennt.

Diagramm, das ein Flussdiagramm für den Rollback-Erkennungsprozess in einem Beispiel-Build zeigt. Es gibt zwei Domänencontroller mit den Bezeichnungen „VDC1“ und „DC2“ Die erste Phase des Flussdiagramms zeigt, dass das virtuelle DC, VDC1, einen Schnappschuss macht, wenn seine USN 2000 ist. Nach dem Snapshot erstellt VDC1 100 Benutzer, und das aktualisierte VDC1 hat jetzt eine USN von 2100. Die Aktualisierungen auf VDC1 werden auf DC2 repliziert, das nun die USN 2100 hat. Das VDC1 verwendet dann jedoch den Snapshot, den es erstellt hat, um zu seiner USN 2000-Version zurückzukehren. Die rückgängig gemachte Version des VDC1 schafft 150 neue Nutzer, wodurch sich die USN auf 2150 erhöht. Das aktualisierte VDC1 wird auf DC2 repliziert, aber DC2 erkennt die nicht übereinstimmenden Änderungen nicht, da seine USN höher ist als die USN von DC2 (2100). Der Text am unteren Rand lautet: „USN-Rollback wird nicht erkannt, was zu einer unerkannten Abweichung führt, bei der die USNs 2001 bis 2100 zwischen den beiden Domänencontrollern nicht übereinstimmen.

Schreibgeschützte DCs

Schreibgeschützte Domänencontroller (RODCs) sind DCs, die schreibgeschützte Kopien der Partitionen in einer Active Directory-Datenbank hosten. Da RODCs keine Änderungen in anderen Domänencontrollern replizieren, werden die meisten Probleme im Zusammenhang mit USN-Rollbacks vermieden. Wenn ein RODC jedoch von einem beschreibbaren DC repliziert, der von einem USN-Rollback betroffen ist, wirkt sich das Rollback auch auf den RODC aus.

Es wird nicht empfohlen, einen Snapshot zur Wiederherstellung eines RODC zu verwenden. Sie sollten einen RODC nur mit einer Active Directory-kompatiblen Sicherungsanwendung wiederherstellen. Wie bei beschreibbaren DCs dürfen Sie auch bei RODCs nicht zulassen, dass sie länger als die Tombstone-Lebensdauer offline sind. Andernfalls kann es auf den RODCs zu veralteten Objekten kommen.

Weitere Informationen zur Implementierung von RODCs finden Sie im detaillierten Leitfaden für schreibgeschützte Domänencontroller.

Zusätzliche Inhalte

Erfahren Sie, wie Sie virtualisierte DCs wiederherstellen können: Wiederherstellen virtualisierter Domänencontroller.