(0) exportieren Drucken
Alle erweitern

Ausführen von Domänencontrollern in Hyper-V

Letzte Aktualisierung: April 2011

Betrifft: Windows Server 2008, Windows Server 2008 R2, Windows Virtualization

Mit Hyper-V™ können unterschiedliche Serverrollen auf einem einzigen physischen Computer konsolidiert werden. In diesem Leitfaden wird beschrieben, wie Domänencontroller als 32-Bit- oder 64-Bit-Gastbetriebssysteme ausgeführt werden.

noteHinweis
Dieses Dokument kann auch aus dem Microsoft Download Center (Ausführen von Domänencontrollern in Hyper-V, "http://go.microsoft.com/fwlink/?LinkId=203977") heruntergeladen werden.

In diesem Leitfaden werden folgende Themen behandelt:

Themen dieses Abschnitts sind die Hardwareanforderungen für Hyper-V-Server, die Vermeidung einzelner Fehlerquellen (Single Points of Failure, SPOFs), die Auswahl des geeigneten Konfigurationstyps für die Server und virtuellen Computer der Hyper-V-Umgebung sowie Überlegungen zur Sicherheit und Leistung.

Zum Installieren und Verwenden der Hyper-V-Rolle ist Folgendes erforderlich:

  • Ein x64-Prozessor. Hyper-V ist in x64-basierten Versionen von Windows Server 2008 oder höher verfügbar.

  • Hardwareunterstützte Virtualisierung. Dieses Feature ist für Prozessoren mit Virtualisierungsoption (Intel Virtualization Technology (Intel VT) oder AMD Virtualization (AMD-V)) verfügbar.

  • Hardware-Datenausführungsverhinderung (Data Execution Protection, DEP). Die Hardware-DEP muss verfügbar und aktiviert sein. Das heißt, Sie müssen Intel XD-Bit (Execute Disable Bit) oder AMD NX-Bit (No Execute Bit) aktivieren.

Bei der Planung für die Bereitstellung virtualisierter Domänencontroller sollten Sie darauf achten, einzelne Fehlerquellen (d. h. Komponenten, deren Ausfall den Ausfall des gesamten Systems verursachen würde) möglichst zu vermeiden. Zu diesem Zweck empfiehlt es sich, Systemredundanz vorzusehen. Erwägen Sie beispielsweise die folgenden Empfehlungen (unter Berücksichtigung der potenziell höheren Verwaltungskosten):

  1. Führen Sie mindestens zwei virtualisierte Domänencontroller pro Domäne auf anderen Virtualisierungshosts aus. Dadurch wird das Risiko verringert, bei Ausfall eines Virtualisierungshosts alle Domänencontroller zu verlieren.

  2. Verwenden Sie zur Ausführung der Domänencontroller unterschiedliche Hardware (z. B. unterschiedliche CPUs, Hauptplatinen oder Netzwerkadapter), wie auch für andere Technologien empfohlen. Dadurch minimieren Sie Auswirkungen von Fehlfunktionen, die auf bestimmte Elemente (z. B. Anbieterkonfigurationen, Treiber, Hardwaremodelle oder Hardwaretypen) beschränkt sind.

  3. Domänencontroller sollten möglichst auf Hardware ausgeführt werden, die sich in unterschiedlichen geografischen Regionen befindet. Dies verringert die Auswirkungen von Notfällen oder Fehlern an einem bestimmten Standort, an dem Domänencontroller gehostet werden.

  4. Versehen Sie all Ihre Domänen mit physischen Domänencontrollern. Dies verringert die Auswirkungen einer Fehlfunktion einer Virtualisierungsplattform (von der auch die von der Plattform abhängigen Hostsysteme betroffen wären).

Der Hostcomputer, auf dem die virtuellen Domänencontroller ausgeführt werden, muss ebenso sorgfältig wie ein beschreibbarer Domänencontroller verwaltet werden, selbst wenn es sich nur um ein Domänenmitglied oder einen Arbeitsgruppencomputer handelt. Dies ist ein wichtiger Sicherheitsaspekt. Ein unzureichend verwalteter Host ist anfällig für Rechteerweiterungsangriffe (d. h., ein böswilliger Benutzer verschafft sich Zugriff und erlangt Systemberechtigungen, die nicht autorisiert oder nicht ordnungsgemäß zugewiesen wurden). Durch einen solchen Angriff können alle vom betroffenen Computer gehosteten virtuellen Computer, Domänen und Gesamtstrukturen gefährdet werden.

Berücksichtigen Sie bei der Planung der Virtualisierung von Domänencontrollern unbedingt die folgenden Sicherheitsaspekte:

  • Der lokale Administrator eines Computers, auf dem virtuelle, beschreibbare Domänencontroller gehostet werden, sollte bezüglich der Anmeldeinformationen als gleichwertig betrachtet werden mit dem Standarddomänenadministrator aller Domänen und Gesamtstrukturen, denen die betreffenden Domänencontroller angehören.

  • Zur Vermeidung von Sicherheits- und Leistungsproblemen wird als Konfiguration empfohlen, auf einem Host eine Server Core-Installation von Windows Server 2008 oder höher mit Hyper-V als einziger Anwendung auszuführen. Je weniger Anwendungen und Dienste auf dem Server installiert sind, desto höher ist die Leistung und desto geringer ist das Risiko von Angriffen auf den Computer oder das Netzwerk über installierte Anwendungen oder Dienste. Diese Art der Konfiguration bietet eine sogenannte reduzierte Angriffsfläche. Für Zweigstellen oder andere Standorte, die nicht ausreichend geschützt werden können, wird ein schreibgeschützter Domänencontroller (Read-Only Domain Controller, RODC) empfohlen. Falls ein separates Verwaltungsnetzwerk vorhanden ist, sollte der Host nur mit dem Verwaltungsnetzwerk verbunden werden.

Weitere Informationen zu RODCs finden Sie im Planungs- und Bereitstellungshandbuch für schreibgeschützte Domänencontroller unter "http://go.microsoft.com/fwlink/?LinkID=135993".

Weitere Informationen zum Schützen von Domänencontrollern finden Sie im Handbuch mit bewährten Methoden für den Schutz von Active Directory-Installationen unter " http://go.microsoft.com/fwlink/?LinkID=28521" .

Die Verwendung virtueller Computer ermöglicht viele verschiedene Konfigurationen von Domänencontrollern. Die Art und Weise, wie virtuelle Computer Begrenzungen und Vertrauensstellungen in Ihrer Active Directory-Topologie beeinflussen, muss sorgfältig berücksichtigt werden. Mögliche Konfigurationen für einen Active Directory-Domänencontroller und -Host (Hyper-V-Server) sowie dessen Gastcomputer (virtuelle Computer, die auf dem Hyper-V-Server ausgeführt werden) werden in der folgenden Tabelle beschrieben:

 

Computer Konfiguration 1 Konfiguration 2

Host

Arbeitsgruppen- oder Mitgliedscomputer

Arbeitsgruppen- oder Mitgliedscomputer

Gast

Domänencontroller

Arbeitsgruppen- oder Mitgliedscomputer

Domänencontroller, die auf Hyper-V-Servern ausgeführt werden
  • Der Administrator des Hostcomputers hat hinsichtlich der beschreibbaren Domänencontrollergäste die gleichen Zugriffsrechte wie ein Domänenadministrator und muss als solcher behandelt werden. Bei RODC-Gästen hat der Administrator des Hostcomputers hinsichtlich des Gast-RODCs die gleichen Zugriffsrechte wie ein lokaler Administrator.

  • Ein Domänencontroller auf einem virtuellen Computer hat Administratorrechte hinsichtlich des Hosts, wenn dieser derselben Domäne angehört. Ein böswilliger Benutzer, der sich zunächst Zugriff auf den virtuellen Computer 1 verschafft, kann alle virtuellen Computer gefährden. Dieses Phänomen wird als Angriffsvektor bezeichnet. Wenn Domänencontroller für mehrere Domänen oder Gesamtstrukturen vorhanden sind, sollten diese Domänen zentral verwaltet werden, wobei der Administrator einer Domäne für alle Domänen als vertrauenswürdig gelten muss.

  • Die Angriffsmöglichkeit vom virtuellen Computer 1 aus besteht, selbst wenn dieser als RODC installiert wird. Ein RODC-Administrator verfügt zwar nicht explizit über Domänenadministratorrechte, doch der RODC kann zum Senden von Richtlinien an den Hostcomputer verwendet werden. Diese Richtlinien können Startskripts enthalten. Bei erfolgreicher Ausführung des Vorgangs sind der Hostcomputer - und dadurch auch die anderen virtuellen Computer auf dem Hostcomputer - gefährdet.

Eine VHD-Datei eines virtuellen Domänencontrollers entspricht der physischen Festplatte eines physischen Domänencontrollers. Daher sollte sie genauso sorgfältig wie die Festplatte eines physischen Domänencontrollers geschützt werden. Stellen Sie sicher, dass nur zuverlässige und vertrauenswürdige Administratoren auf die VHD-Dateien des Domänencontrollers zugreifen können.

Ein Vorteil von RODCs ist, dass sie an Standorten verwendet werden können, an denen die physische Sicherheit nicht garantiert werden kann (z. B. an Zweigstellen). Mit der Windows® BitLocker™-Laufwerkverschlüsselung können Sie die VHD-Dateien selbst (nicht aber ihre Dateisysteme) für den Fall schützen, dass der physische Datenträger des Hosts gestohlen wird. Weitere Informationen zu BitLocker in Hyper-V finden Sie im Thema zu Windows Server 2008 Hyper-V und zur BitLocker-Laufwerkverschlüsselung unter " http://go.microsoft.com/fwlink/?LinkID=123534".

Mit der neuen Microkernel-64-Bit-Architektur wurde die Leistung von Hyper-V im Vergleich zu früheren Virtualisierungsplattformen erheblich verbessert. Zur Optimierung der Hostleistung sollte für den Host eine Server Core-Installation von Windows Server 2008 oder höher vorgesehen werden, und außer Hyper-V sollten keine anderen Serverrollen installiert werden.

Die Leistung virtueller Computer hängt insbesondere von der Arbeitsauslastung ab. Testen Sie verschiedene Topologien, um eine zufriedenstellende Leistung von Active Directory sicherzustellen. Bewerten Sie die aktuelle Arbeitsauslastung über einen bestimmten Zeitraum mit einem Tool wie der Zuverlässigkeits- und Leistungsüberwachung ("Perfmon.msc") oder dem Microsoft Assessment and Planning (MAP) Toolkit (http://go.microsoft.com/fwlink/?LinkId=137077). Das MAP-Tool ist außerdem hilfreich, um eine Bestandsaufnahme aller gegenwärtigen Server und Serverrollen im Netzwerk vorzunehmen.

Um eine grobe Vorstellung von der Leistung virtualisierter Domänencontroller zu erhalten, wurden die folgenden Leistungstests mit dem Active Directory-Leistungstesttool ("ADTest.exe") (http://go.microsoft.com/fwlink/?LinkId=137088) ausgeführt:

LDAP-Tests (Lightweight Directory Access-Protokoll) wurden zunächst auf einem physischen Domänencontroller mit "ADTest.exe" und anschließend auf einem virtuellen Computer (gehostet auf einem mit dem physischen Domänencontroller identischen Server) ausgeführt. Um problemlos eine CPU-Auslastung von 100 % zu erreichen, wurde für den physischen Computer nur ein logischer Prozessor und für den virtuellen Computer nur ein virtueller Prozessor verwendet. In der folgenden Tabelle bezeichnen der Buchstabe und die Zahl in Klammern (jeweils nach der Testbeschreibung) die verschiedenen Tests von %amp;quot;ADTest.exe". Die Leistung des virtualisierten Domänencontrollers betrug demnach zwischen ca. 88 und 98 % von der des physischen Domänencontrollers.

 

Messwert Test Physisch Virtuell Delta

Suchen/Sek.

Suche nach einem allgemeinen Namen im Basisbereich (L1)

11508

10276

-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

1242

-3,27 %

Suchen/Sek.

Suche nach einem allgemeinen Namen im Unterstrukturbereich (L6)

8613

7904

-8,23 %

Erfolgreiche Bindungen/Sek.

Ausführen schneller Bindungen (B1)

1438

1374

-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/Sek.

Schreiben mehrerer Attribute (W2)

6467

5885

-9,00 %

Zur Sicherstellung einer zufriedenstellenden Leistung wurden Integrationskomponenten installiert, damit das Gastbetriebssystem Optimierungen oder hypervisorkompatible synthetische Treiber verwenden konnte. Zur Installation sind möglicherweise emulierte IDE- (Integrated Drive Electronics) oder Netwerkadaptertreiber erforderlich. In Produktionsumgebungen sollten Sie diese emulierten Treiber durch synthetische Treiber ersetzen, um die Leistung zu optimieren.

Wenn Sie die Leistung virtueller Computer mit der Zuverlässigkeits- und Leistungsüberwachung ("Perfmon.msc") überwachen, sind die CPU-Informationen des virtuellen Computers nicht ganz zutreffend. Dies ist auf das Verfahren zurückzuführen, mit dem die virtuelle CPU auf dem physischen Prozessor zeitlich abgestimmt wird. Zum Abrufen von CPU-Informationen für einen virtuellen Computer, der auf einem Hyper-V-Server ausgeführt wird, verwenden Sie die Leistungsindikatoren "Logischer Prozessor für Hyper-V-Hypervisor" in der Hostpartition.

Weitere Informationen zur Leistungsoptimierung für die Active Directory-Domänendienste und Hyper-V finden Sie im Thema zu Leistungsoptimierungsrichtlinien für Windows Server 2008 unter "http://go.microsoft.com/fwlink/?LinkId=137276".

Zudem ist davon abzuraten, eine differenzierende virtuelle Festplatte (Virtual Hard Disk, VHD) auf einem virtuellen Computer zu verwenden, der als Domänencontroller konfiguriert ist, da dadurch die Leistung beeinträchtigt werden kann. Weitere Informationen zu Hyper-V-Datenträgertypen, einschließlich differenzierender Datenträger, finden Sie im Thema zum Assistenten für neue virtuelle Festplatten unter "http://go.microsoft.com/fwlink/?LinkId=137279".

Weitere Informationen zu den Active Directory-Domänendiensten in virtuellen Hostumgebungen finden Sie im Artikel 888794 der Microsoft Knowledge Base unter "http://go.microsoft.com/fwlink/?LinkId=141292".

Mehrere gängige Praktiken im Zusammenhang mit virtuellen Computern sollten bei der Bereitstellung virtualisierter Domänencontroller vermieden werden. Zudem gelten spezielle Empfehlungen für die Zeitsynchronisierung und Speicherung.

Virtualisierungsplattformen, wie z. B. Hyper-V, bieten eine Reihe von Features, die das Verwalten, Warten, Sichern und Migrieren von Computern vereinfachen. Bei der Bereitstellung virtualisierter Domänencontroller empfiehlt es sich jedoch, die folgenden gängigen Praktiken (und zugehörigen Features) zu vermeiden:

  • Implementieren Sie keine differenzierenden virtuellen Festplatten auf einem virtuellen Computer, den Sie als Domänencontroller konfigurieren. Dies macht die Wiederherstellung einer früheren Version zu einfach, und die Leistung wird reduziert. Weitere Informationen zu VHD-Typen finden Sie im Thema zum Assistenten für neue virtuelle Festplatten unter "http://go.microsoft.com/fwlink/?LinkID=137279".

  • Klonen Sie die Installation eines Betriebssystems nur mit "Sysprep.exe", da andernfalls die Sicherheits-ID des Computers nicht aktualisiert wird. Weitere Informationen zum Ausführen des Systemvorbereitungsprogramms (Sysprep) finden Sie im Abschnitt zur Verwendung virtueller Festplatten des Themas zum Bereitstellen eines Betriebssystems auf einem virtuellen Computer unter "http://go.microsoft.com/fwlink/?LinkId=137100".

    WarningWarnung
    Die Ausführung von Sysprep auf einem Domänencontroller wird nicht unterstützt.

  • Zur Vermeidung einer Rollbacksituation der Aktualisierungssequenznummern (Update Sequence Numbers, USNs) sollten Kopien einer VHD-Datei, die zu einem bereitgestellten Domänencontroller gehört, nicht zum Bereitstellen weiterer Domänencontroller verwendet werden. Weitere Informationen zu USN-Rollbacks finden Sie unter USN und USN-Rollback.

  • Verwenden Sie das Exportfeature von Hyper-V nicht zum Exportieren eines virtuellen Computers, auf dem ein Domänencontroller ausgeführt wird.

System Center Virtual Machine Manager (VMM) 2008 ermöglicht die einheitliche Verwaltung physischer und virtueller Computer. Außerdem kann ein physischer Computer zu einem virtuellen Computer migriert werden. Dieser Vorgang wird als Physical-to-Virtual-Konvertierung (P2V) bezeichnet. Während der P2V-Konvertierung dürfen der neue virtuelle Computer und der physische Domänencontroller, der migriert wird, nicht gleichzeitig eingeschaltet sein. So wird eine USN-Rollbacksituation, wie unter USN und USN-Rollback beschrieben, vermieden.

Die P2V-Konvertierung sollte im Offlinemodus ausgeführt werden, damit die Verzeichnisdaten einheitlich sind, wenn der Domänencontroller wieder eingeschaltet wird. Der Offlinemodus ist die empfohlene Option im Assistenten zum Konvertieren des physischen Servers. Eine Beschreibung des Unterschieds zwischen dem Online- und Offlinemodus finden Sie im Thema zum P2V-Konvertieren physischer Computer in virtuelle Computer in VMM unter "http://go.microsoft.com/fwlink/?LinkId=155072". Während der P2V-Konvertierung sollte der virtuelle Computer nicht mit dem Netzwerk verbunden sein. Aktivieren Sie den Netzwerkadapter des virtuellen Computers erst nach Abschluss und Überprüfung der P2V-Konvertierung. Zu diesem Zeitpunkt ist der physische Quellcomputer ausgeschaltet. Bevor Sie den physischen Quellcomputer wieder mit dem Netzwerk verbinden, formatieren Sie die Festplatte neu.

CautionVorsicht
Stellen Sie sicher, dass jeweils nur eine Instanz (physisch oder virtuell) eines bestimmten Domänencontrollers in einem bestimmten Netzwerk vorhanden ist. So vermeiden Sie Probleme bei der Active Directory-Replikation.

Mithilfe der P2V-Migration über VMM können Sie Testumgebungen erstellen. Sie können Produktionsdomänencontroller von physischen zu virtuellen Computern migrieren, um eine Testumgebung zu erstellen, ohne die Produktionsdomänencontroller dauerhaft offline zu schalten. Falls jedoch zwei Instanzen desselben Domänencontrollers benötigt werden, muss sich die Testumgebung in einem anderen Netzwerk als die Produktionsumgebung befinden. Gehen Sie beim Erstellen von Testumgebungen mit der P2V-Migration äußerst vorsichtig vor, um USN-Rollbacks zu vermeiden, die sich negativ auf Ihre Test- und Produktionsumgebungen auswirken können. Mit der folgenden Methode können Sie Testumgebungen mit dem P2V-Verfahren erstellen:

Ein Produktionsdomänencontroller aus jeder Domäne wird zu einem virtuellen Testcomputer migriert, wobei die P2V-Konvertierung nach den Empfehlungen im Abschnitt Physical-to-Virtual-Migration (P2V) verwendet wird. Die physischen Produktionscomputer und die virtuellen Testcomputer müssen sich in unterschiedlichen Netzwerken befinden, wenn sie wieder online geschaltet werden. Um USN-Rollbacks in der Testumgebung zu vermeiden, müssen alle Domänencontroller, die von physischen zu virtuellen Computern migriert werden sollen, offline geschaltet werden. (Beenden Sie dazu den NTDS-Dienst, oder starten Sie den Computer im Verzeichnisdienst-Wiederherstellungsmodus (Directory Services Restore Mode, DSRM) neu.) Wenn die Domänencontroller offline sind, sollten in der Umgebung keine neuen Updates vorgenommen werden. Die Computer müssen während der P2V-Migration offline bleiben. Keiner der Computer darf wieder online geschaltet werden, bevor alle Computer vollständig migriert sind. Weitere Informationen zu USN-Rollbacks finden Sie unter USN und USN-Rollback.

Spätere Testdomänencontroller sollten in der Testumgebung als Replikate höher gestuft werden.

Bei virtuellen Computern, die als Domänencontroller konfiguriert werden, empfiehlt es sich, die Zeitsynchronisierung zwischen dem Hostsystem und dem Gastbetriebssystem, das als Domänencontroller dient, teilweise zu deaktivieren. Auf diese Weise vermeiden Sie einen Zeitversatz, wenn der Gastdomänencontroller aus einem Zustand Gespeichert wiederhergestellt wird, behalten jedoch die Zeitsynchronisierung für die Domänenhierarchie bei.

Zum teilweisen Deaktivieren der Hyper-V-Zeitsynchronisierung lassen Sie Zeitsynchronisierung unter Integrationsdienste aktiviert, und führen Sie über eine Eingabeaufforderung mit erhöhten Rechten den folgenden Befehl aus:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

Durch diesen Befehl verhindern Sie, dass der Windows-Zeitdienst (W32Time) die Hyper-V-Zeitsynchronisierungsintegration verwendet, wenn das Betriebssystem des Gastdomänencontrollers gestartet wird. Der Hyper-V-Zeitsynchronisierungsanbieter wird nur verwendet, wenn der Gastdomänencontroller neu gestartet oder aus einem Zustand Gespeichert wiederhergestellt wird.

Zur Vermeidung von Zeitversatz ist es wichtig, dass der Hostcomputer mit einem zuverlässigen Zeitdienst synchronisiert wird.

Weitere Informationen zum Hyper-V-Zeitsynchronisierungsdienst finden Sie im Blogeintrag zur Zeitsynchronisierung in Hyper-V unter " http://go.microsoft.com/fwlink/?LinkId=211846".

Weitere Informationen zum Installieren und Verwenden der Integrationsdienste finden Sie in den Ersten Schritten mit Hyper-V unter " http://go.microsoft.com/fwlink/?LinkId=137146".

Zum Optimieren der Leistung des virtuellen Computers, der als Domänencontroller dient, wird zum Speichern von Betriebssystem-, Active Directory- und VHD-Dateien Folgendes empfohlen:

  • Gastspeicherung: Speichern Sie die Active Directory-Datenbankdatei (" Ntds.dit") sowie die Protokoll- und SYSVOL-Dateien auf einem anderen virtuellen Datenträger als die Betriebssystemdateien. Integrationskomponenten müssen installiert sein, damit anstelle der Emulation synthetische Treiber für IDE (Integrated Drive Electronics) verwendet werden können. Virtuelle SCSI- und IDE-Datenträger werden mit der gleichen Geschwindigkeit ausgeführt, wenn synthetische Treiber verwendet werden.

  • Hostspeicherung von VHD-Dateien: Die Empfehlungen für die Hostspeicherung beziehen sich auf die Speicherung von VHD-Dateien. Zur Optimierung der Leistung sollten Sie VHD-Dateien nicht auf einem Datenträger speichern, der häufig von anderen Diensten oder Anwendungen verwendet wird, wie z. B. auf dem Systemdatenträger, auf dem das Windows-Hostbetriebssystem installiert ist. Speichern Sie jede der VHD-Dateien auf einer vom Hostbetriebssystem und anderen VHD-Dateien getrennten Partition. Die ideale Konfiguration ist die Speicherung jeder VHD-Datei auf einem separaten physischen Laufwerk.

  • Feste virtuelle Festplatten oder Pass-Through-Datenträger: Es gibt viele Methoden zum Konfigurieren der Speicherung für virtuelle Computer. Wenn VHD-Dateien verwendet werden, sind virtuelle Festplatten mit fester Größe effizienter als dynamische virtuelle Festplatten, da der Arbeitsspeicher für virtuelle Festplatten mit fester Größe beim Erstellen zugeordnet wird. Eine noch höhere Leistung ermöglichen Pass-Through-Datenträger, die von virtuellen Computern für den Zugriff auf physische Speichermedien verwendet werden können. Pass-Through-Datenträger sind im Prinzip physische Datenträger oder logische Gerätenummern (Logical Unit Numbers, LUNs), die einem virtuellen Computer zugeordnet sind. Das Snapshotfeature wird von Pass-Through-Datenträgern nicht unterstützt. Dies macht Pass-Through-Datenträger zur bevorzugten Festplattenkonfiguration, da bei Domänencontrollern von der Verwendung von Snapshots abgeraten wird.

Verwenden Sie SCSI-Controller, oder deaktivieren Sie den Schreibcache für ATA/IDE-Laufwerke, um das Risiko einer Beschädigung von Active Directory-Daten zu reduzieren. Im Einzelnen:

  • Verwenden Sie auf Hyper-V-Servern, auf denen virtuelle Domänencontroller gehostet werden, nicht ATA/IDE-Laufwerke, sondern physische SCSI-Laufwerke. Falls Sie keine SCSI-Laufwerke verwenden können, stellen Sie sicher, dass der Schreibcache für die ATA/IDE-Laufwerke, auf denen virtuelle Domänencontroller gehostet werden, deaktiviert ist. Weitere Informationen finden Sie im Thema zur Ereignis-ID 1539/Datenbankintegrität unter " http://go.microsoft.com/fwlink/?LinkId=162419".

  • Verwenden Sie virtuelle SCSI-Controller für alle virtuellen Computer, die als Domänencontroller ausgeführt werden. Falls Sie keine virtuellen SCSI-Controller verwenden können, stellen Sie sicher, dass für die virtuellen IDE-Laufwerke von virtuellen Computern, die als Domänencontroller ausgeführt werden, der Schreibcache deaktiviert ist. Im Dialogfeld mit den Einstellungen von Virtual Machine Manager wird angezeigt, welcher Typ von Datenträgercontrollern installiert ist. Weitere Informationen finden Sie im Thema zum Konfigurieren virtueller Computer unter "http://go.microsoft.com/fwlink/?LinkID=129912".

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. Folgende Features der Virtualisierungssoftware und folgende Praktiken sollten bei virtualisierten Domänencontrollern nicht verwendet werden:

  • Vermeiden Sie es, den gespeicherten Zustand eines virtualisierten Domänencontrollers für einen längeren Zeitraum als die Tombstone-Lebensdauer der Gesamtstruktur anzuhalten, zu beenden oder zu speichern und dann ausgehend vom angehaltenen oder gespeicherten Zustand weiterzuarbeiten. Dadurch können Probleme bei der Replikation verursacht werden. Informationen zum Bestimmen der Tombstone-Lebensdauer für die Gesamtstruktur finden Sie im Thema zum Bestimmen der Tombstone-Lebensdauer für die Gesamtstruktur unter " http://go.microsoft.com/fwlink/?LinkId=137177".

  • Kopieren oder klonen Sie keine virtuellen Festplatten.

  • Erstellen oder verwenden Sie keine Snapshots eines virtuellen Domänencontrollers.

  • Verwenden Sie keine differenzierende virtuelle Festplatte auf einem virtuellen Computer, der als Domänencontroller konfiguriert ist. Dies macht die Wiederherstellung einer früheren Version zu einfach, und die Leistung wird reduziert.

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

  • Verwenden Sie zum Wiederherstellen eines Domänencontrollers oder Ausführen eines Rollbacks für den Inhalt einer Active Directory-Datenbank ausschließlich unterstützte Sicherungsvorgänge Weitere Informationen finden Sie unter Überlegungen zum Sichern und Wiederherstellen für virtualisierte Domänencontroller.

Durch diese Empfehlungen soll ein Rollback der Aktualisierungssequenznummern vermieden werden. Weitere Informationen zu USN-Rollbacks finden Sie unter USN und USN-Rollback.

Das Sichern von Domänencontrollern ist für jede Umgebung eine wichtige Aufgabe. Sicherungen schützen bei einem Fehler des Domänencontrollers oder Administrators vor Datenverlust. Nach einem solchen Fehler muss der Systemstatus des Domänencontrollers mithilfe eines Rollbacks auf einen Zeitpunkt vor Auftreten des Fehlers zurückgesetzt werden. Das unterstützte Verfahren dazu besteht darin, mithilfe einer Active Directory-kompatiblen Sicherungsanwendung, wie z. B. der Windows Server-Sicherung, eine Systemstatussicherung wiederherzustellen, die aus der aktuellen Installation des Domänencontrollers stammt. Weitere Informationen zum Verwenden der Windows Server-Sicherung mit den Active Directory-Domänendiensten finden Sie in der schrittweisen Anleitung für die Sicherung und Wiederherstellung in den Active Directory-Domänendiensten unter http://go.microsoft.com/fwlink/?LinkId=138501.

Im Zusammenhang mit der Virtualisierungstechnologie erhalten bestimmte Anforderungen für Active Directory-Wiederherstellungsvorgänge zusätzliche Bedeutung. Wenn Sie z. B. einen Domänencontroller mithilfe einer Kopie der VHD-Datei wiederherstellen, umgehen Sie einen wichtigen Schritt: die Aktualisierung der Datenbankversion eines wiederhergestellten Domänencontrollers. Die Replikation wird mit ungeeigneten Trackingnummern fortgesetzt, was zu Datenbankinkonsistenzen zwischen den Domänencontrollerreplikaten führt. In den meisten Fällen wird dieses Problem vom Replikationssystem nicht erkannt, und trotz der Inkonsistenzen werden keine Fehler gemeldet.

Ein einziges Verfahren wird zum Sichern und Wiederherstellen eines virtualisierten Domänencontrollers unterstützt:

  1. Führen Sie die Windows Server-Sicherung im Gastbetriebssystem aus.

Wie bereits erwähnt, gelten für virtualisierte Domänencontroller im Vergleich zu physischen Domänencontrollern gewisse Einschränkungen. Folgende Features der Virtualisierungssoftware und folgende Praktiken sollten beim Sichern und Wiederherstellen eines virtualisierten Domänencontrollers nicht verwendet werden:

  • Kopieren oder klonen Sie keine VHD-Dateien von Domänencontrollern als Ersatz für regelmäßige Sicherungen. Kopierte oder geklonte VHD-Dateien können veralten. Wenn dann die virtuelle Festplatte im normalen Modus gestartet wird, kann es zwischen den Replikationsdaten der Gesamtstruktur zu Abweichungen kommen. Führen Sie stattdessen ordnungsgemäße Sicherungsvorgänge aus, die von den Active Directory-Domänendiensten (Active Directory Domain Services, AD DS) unterstützt werden (beispielsweise mit der Windows Server-Sicherung).

  • Verwenden Sie zur Sicherung und Wiederherstellung virtualisierter Domänencontroller nicht das Snapshotfeature. Dies führt zu Problemen bei der Replikation, wenn Sie einen früheren Zustand des virtuellen Computers wiederherstellen. Weitere Informationen finden Sie unter USN und USN-Rollback. Bei RODCs verursacht die Wiederherstellung anhand eines Snapshots zwar keine Replikationsprobleme, doch auch in diesem Fall wird davon abgeraten.

Damit Sie einen fehlerhaften Domänencontroller wiederherstellen können, müssen Sie den Systemstatus regelmäßig sichern. Zum Systemstatus gehören Active Directory-Daten und -Protokolldateien, die Registrierung, das Systemvolume (SYSVOL-Ordner) sowie verschiedene Elemente des Betriebssystems. Diese Anforderung unterscheidet sich nicht zwischen physischen und virtualisierten Domänencontrollern. Die Verfahren zur Systemstatuswiederherstellung, die von Active Directory-kompatiblen Sicherungsanwendungen ausgeführt werden, sind dafür ausgelegt, nach einer Wiederherstellung die Konsistenz zwischen lokalen und replizierten Active Directory-Datenbanken sicherzustellen. Dazu zählt auch die Benachrichtigung von Replikationspartnern über Zurücksetzungen der Aufrufkennung. Die Überprüfungen, die gewöhnlich beim Wiederherstellen des Domänencontroller-Systemstatus ausgeführt werden, können jedoch vom Administrator umgangen werden - etwa mit virtuellen Hostumgebungen oder Anwendungen zur Erstellung von Datenträger- oder Betriebssystemimages.

Wenn bei einem virtuellen Computer eines Domänencontrollers ein Fehler aufgetreten ist und kein Rollback der Aktualisierungssequenznummern vorliegt, bestehen zwei Möglichkeiten zum Wiederherstellen des virtuellen Computers:

  • Falls eine gültige Sicherung der Systemstatusdaten vorhanden ist, die vor dem Auftreten des Fehlers erstellt wurde, können Sie den Systemstatus mithilfe des Sicherungsprogramms wiederherstellen, mit dem Sie die Sicherung erstellt haben. Die Sicherung der Systemstatusdaten muss mit einem Active Directory-kompatiblen Sicherungsprogramm innerhalb der Tombstone-Lebensdauer erstellt worden sein, also standardmäßig vor maximal 180 Tagen. Es empfiehlt sich, die Domänencontroller spätestens bei Erreichen der Hälfte der Tombstone-Lebensdauer zu sichern. Anweisungen zum Bestimmen der Tombstone-Lebensdauer für die Gesamtstruktur finden Sie im Thema zum Bestimmen der Tombstone-Lebensdauer für die Gesamtstruktur unter "http://go.microsoft.com/fwlink/?LinkID=137177".

  • Wenn zwar eine Arbeitskopie der VHD-Datei, aber keine Systemstatussicherung verfügbar ist, können Sie den vorhandenen virtuellen Computer entfernen. Stellen Sie den vorhandenen virtuellen Computer mithilfe einer vorherigen Kopie der VHD-Datei wieder her. Starten Sie den Computer jedoch unbedingt im Verzeichnisdienst-Wiederherstellungsmodus (Directory Services Restore Mode, DSRM), und konfigurieren Sie die Registrierung ordnungsgemäß, wie im folgenden Abschnitt beschrieben. Anschließend starten Sie den Domänencontroller im normalen Modus neu.

Bestimmen Sie anhand des folgenden Schemas die optimale Methode zum Wiederherstellen Ihres virtualisierten Domänencontrollers:

Schreibfähige Domänencontroller-Wiederherstellung in Hyper-V

Bei RODCs sind der Wiederherstellungsvorgang und die zu treffenden Entscheidungen einfacher:

Schreibgeschützte Domänencontroller-Wiederherstellung in Hyper-V

Wenn eine gültige Systemstatussicherung für den virtuellen Computer eines Domänencontrollers vorhanden ist, können Sie die Sicherung problemlos wiederherstellen. Führen Sie dazu das Wiederherstellungsverfahren des Sicherungstools aus, mit dem Sie die VHD-Datei gesichert haben.

ImportantWichtig
Sie müssen den Domänencontroller im Verzeichnisdienst-Wiederherstellungsmodus starten, um ihn ordnungsgemäß wiederherstellen zu können. Der Domänencontroller darf nicht im normalen Modus gestartet werden. Falls Sie beim Starten des Systems den Verzeichnisdienst-Wiederherstellungsmodus nicht rechtzeitig aufgerufen haben, schalten Sie den virtuellen Computer des Domänencontrollers aus, bevor er im normalen Modus gestartet werden kann. Der Domänencontroller muss unbedingt im Verzeichnisdienst-Wiederherstellungsmodus gestartet werden, da bei einem Start im normalen Modus die Aktualisierungssequenznummern erhöht würden (auch dann, wenn der Domänencontroller vom Netzwerk getrennt ist). Weitere Informationen zu USN-Rollbacks finden Sie unter USN und USN-Rollback.

  1. Starten Sie den virtuellen Computer des Domänencontrollers, und drücken Sie F5, um den Bildschirm des Windows-Start-Managers zu öffnen. Falls Sie Anmeldeinformationen für die Verbindung eingeben müssen, klicken Sie auf dem virtuellen Computer sofort auf die Schaltfläche Pause, damit der Startvorgang nicht fortgesetzt wird. Geben Sie anschließend die Anmeldeinformationen für die Verbindung ein, und klicken Sie auf dem virtuellen Computer auf die Schaltfläche Wiedergabe. Klicken Sie auf eine Stelle im Fenster des virtuellen Computers, und drücken Sie dann die Taste F5.

    Wenn der Bildschirm des Windows-Start-Managers nicht angezeigt wird, schalten Sie den virtuellen Computer aus, bevor der Domänencontroller im normalen Modus gestartet werden kann. Wiederholen Sie diesen Schritt so oft wie nötig, bis Sie auf den Bildschirm des Windows-Start-Managers zugreifen können. Über das Menü "Windows-Fehlerbehebung" kann der Verzeichnisdienst-Wiederherstellungsmodus nicht aufgerufen werden. Wenn das Menü "Windows-Fehlerbehebung" angezeigt wird, schalten Sie den Computer aus, und versuchen Sie es erneut.

  2. Drücken Sie im Bildschirm des Windows-Start-Managers die Taste F8, um auf die erweiterten Startoptionen zuzugreifen.

  3. Markieren Sie im Bildschirm Erweiterte Startoptionen die Option Verzeichnisdienstwiederherstellung, und drücken Sie dann die EINGABETASTE. Dadurch wird der Domänencontroller im Verzeichnisdienst-Wiederherstellungsmodus gestartet.

  4. Verwenden Sie das passende Wiederherstellungsverfahren für das Tool, mit dem Sie die Systemstatussicherung erstellt haben. Falls Sie die Windows Server-Sicherung verwendet haben, finden Sie weitere Informationen im Thema zur nicht autoritativen Wiederherstellung von Active Directory-Domänendiensten unter "http://go.microsoft.com/fwlink/?LinkID=132637".

Wenn vor dem Auftreten des Fehlers beim virtuellen Computer keine Systemstatussicherung erstellt wurde, können Sie den auf dem virtuellen Computer ausgeführten Domänencontroller mithilfe einer vorherigen VHD-Datei wiederherstellen. Erstellen Sie möglichst eine Kopie der VHD-Datei. So können Sie das Verfahren wiederholen, falls ein Problem auftritt oder Sie einen Schritt auslassen.

ImportantWichtig
  • Das folgende Verfahren eignet sich nicht als Ersatz für regelmäßig geplante und terminierte Sicherungen.

  • Diese Form der Wiederherstellung wird von Microsoft nicht unterstützt und kommt nur in Betracht, wenn keine andere Alternative besteht.

  • Verwenden Sie das Verfahren nicht, wenn die Kopie der virtuellen Festplatte, die Sie zur Wiederherstellung verwenden, von einem beliebigen virtuellen Computer im normalen Modus gestartet wurde.

  1. Starten Sie den virtuellen Domänencontroller wie im vorherigen Abschnitt beschrieben im Verzeichnisdienst-Wiederherstellungsmodus, wobei Sie die vorherige VHD-Datei verwenden. Der Domänencontroller darf nicht im normalen Modus gestartet werden. Wenn der Bildschirm des Windows-Start-Managers nicht angezeigt wird, schalten Sie den virtuellen Computer aus, bevor der Domänencontroller im normalen Modus gestartet werden kann. Ausführliche Anweisungen zum Aktivieren des Verzeichnisdienst-Wiederherstellungsmodus finden Sie im vorherigen Abschnitt.

  2. Öffnen Sie den Registrierungs-Editor. Klicken Sie zum Öffnen des Registrierungs-Editors auf Start und dann auf Ausführen, geben Sie regedit ein, und klicken Sie dann auf OK. Wenn das Dialogfeld Benutzerkontensteuerung angezeigt wird, bestätigen Sie die angegebene Aktion durch Klicken auf Ja. Erweitern Sie im Registrierungs-Editor den Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Suchen Sie nach dem Wert DSA Previous Restore Count. Wenn dieser Wert vorhanden ist, notieren Sie sich die Einstellung. Wenn dieser Wert nicht vorhanden ist, entspricht die Einstellung dem Standardwert, also Null. Fügen Sie keinen Wert hinzu, falls kein Wert angezeigt wird.

  3. Klicken Sie mit der rechten Maustaste auf den Registrierungsschlüssel Parameters, klicken Sie auf Neu, und klicken Sie dann auf DWORD-Wert (32-Bit).

  4. Geben Sie den neuen Namen Von Sicherung wiederhergestellte Datenbank ein, und drücken Sie die EINGABETASTE.

  5. Doppelklicken Sie auf den soeben erstellten Wert, um das Dialogfeld DWORD-Wert (32-Bit) bearbeiten zu öffnen, und geben Sie dann 1 im Feld Wert ein. Die Option Von Sicherung wiederhergestellte Datenbank ist verfügbar auf Domänencontrollern unter Windows 2000 Server mit Service Pack 4 (SP4), unter Windows Server 2003 mit den im Artikel 875495 der Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=137182) beschriebenen installierten Updates sowie unter Windows Server 2008.

  6. Starten Sie den Domänencontroller im normalen Modus neu.

  7. Wenn der Domänencontroller neu gestartet wird, öffnen Sie die Ereignisanzeige. Klicken Sie zum Öffnen der Ereignisanzeige imStartmenü auf Systemsteuerung, doppelklicken Sie auf Verwaltung, und doppelklicken Sie dann auf Ereignisanzeige.

  8. Erweitern Sie Anwendungs- und Dienstprotokolle, und klicken Sie dann auf das Protokoll Verzeichnisdienste. Vergewissern Sie sich, dass im Detailbereich Ereignisse angezeigt werden.

  9. Klicken Sie mit der rechten Maustaste auf das Protokoll Verzeichnisdienste, und klicken Sie dann auf Suchen. Geben Sie im Feld Suchen nach die Zeichenfolge 1109 ein, und klicken Sie auf Weitersuchen.

  10. Es sollte mindestens ein Eintrag mit der Ereignis-ID 1109 angezeigt werden. Falls dieser Eintrag nicht angezeigt wird, führen Sie den nächsten Schritt aus. Doppelklicken Sie andernfalls auf den Eintrag. Die Aktualisierung des invocationID-Werts sollte mit dem folgenden (oder einem ähnlichen) Text bestätigt werden:

    Die Active Directory-Domänendienste wurden vom Sicherheitsmedium wiederhergestellt, oder Active Directory wurde als Host für eine Anwendungspartition konfiguriert. 
    Das invocationID-Attribut für diesen Domänencontroller wurde geändert. 
    Die höchste Aktualisierungssequenznummer zum Zeitpunkt der Erstellung der Sicherung lautet wie folgt. <Zeit>
    
    InvocationID-Attribut (alter Wert):<vorheriger InvocationID-Wert>
    InvocationID-Attribut (neuer Wert):<aktueller InvocationID-Wert>
    Aktualisierungssequenznummer:<USN>
    
    Das invocationID-Attribut wird geändert, wenn ein Domänencontroller vom Sicherungsmedium wiederhergestellt oder als Host für eine beschreibbare Anwendungsverzeichnispartition konfiguriert wird.
    
    
  11. Schließen Sie die Ereignisanzeige.

  12. Überprüfen Sie im Registrierungs-Editor, ob der Wert in DSA Previous Restore Count dem vorherigen Wert plus 1 entspricht. Falls der Wert nicht korrekt ist und Sie in der Ereignisanzeige keinen Eintrag mit der Ereignis-ID 1109 finden, überprüfen Sie, ob die Service Packs des Domänencontrollers aktuell sind. Sie können dieses Verfahren mit derselben VHD-Datei nicht wiederholen. Jedoch können Sie es mit einer Kopie der VHD-Datei oder einer anderen virtuellen Festplatte, die nicht im normalen Modus gestartet wurde, erneut versuchen. Beginnen Sie dazu wieder bei Schritt 1.

  13. Schließen Sie den Registrierungs-Editor.

In diesem Abschnitt werden Replikationsprobleme beschrieben, die auftreten können, wenn die Active Directory-Datenbank mit einer älteren Version eines virtuellen Computers fehlerhaft wiederhergestellt wurde. Weitere Informationen zum Active Directory-Replikationsvorgang finden Sie im Thema zur Funktionsweise des Active Directory-Replikationsmodells unter "http://go.microsoft.com/fwlink/?LinkID=27636".

USNs dienen den Active Directory-Domänendiensten zur Nachverfolgung der Replikation von Daten zwischen Domänencontrollern. Bei jeder Änderung von Daten im Verzeichnis wird die USN erhöht.

Für jede auf einem Zieldomänencontroller gespeicherte Verzeichnispartition werden mithilfe von USNs das neueste Quellupdate, das der Datenbank eines Domänencontrollers hinzugefügt wurde, sowie der Status jedes anderen Domänencontrollers, auf dem ein Replikat der Verzeichnispartition gespeichert ist, nachverfolgt. Bei der Replikation von Änderungen zwischen Domänencontrollern werden von den Replikationspartnern diejenigen Änderungen abgerufen, deren USNs größer sind als die USN der letzten vom jeweiligen Partner empfangenen Änderung.

Die USNs sind in zwei Tabellen mit Replikationsmetadaten enthalten. Sie werden vom Quell- und Zieldomänencontroller verwendet, um die vom Zieldomänencontroller benötigten Änderungen zu bestimmen.

  1. Aktualitätsvektor: Eine vom Zieldomänencontroller verwaltete Tabelle zum Nachverfolgen der Quellupdates, die von den verschiedenen Quelldomänencontrollern eingehen. 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. Nach erfolgreichem Abschluss eines Replikationszyklus sendet der Quelldomänencontroller dem Zieldomänencontroller seinen Aktualitätsvektor. So kann der Zieldomänencontroller sicherstellen, dass seine Daten mit den Quellupdates aller übrigen Domänencontroller synchronisiert wurden und auf dem aktuellen Stand sind.

  2. Obere Kontingentgrenze: Ein vom Zieldomänencontroller verwalteter Wert zum Nachverfolgen der letzten Änderungen, die von einem bestimmten Quelldomänencontroller für eine bestimmte Partition eingegangen sind. Die obere Kontingentgrenze verhindert, dass dem Zieldomänencontroller vom Quelldomänencontroller wiederholt dieselben Änderungen gesendet werden.

Neben USNs wird von Domänencontrollern auch die Verzeichnisdatenbankidentität der Quellreplikationspartner nachverfolgt. Die Identität der auf dem Server ausgeführten Verzeichnisdatenbank wird separat von der Identität des Serverobjekts selbst verwaltet. Die Verzeichnisdatenbankidentität wird auf den einzelnen Domänencontrollern im invocationID-Attribut des NTDS-Einstellungsobjekts gespeichert, das sich im folgenden LDAP-Pfad (Lightweight Directory Access-Protokoll) befindet: cn=NTDS Settings, cn=ServerName, cn=Servers, cn=SiteName, cn=Sites, cn=Configuration, dc=ForestRootDomain. Die Serverobjektidentität wird im objectGUID-Attribut des NTDS-Einstellungsobjekts gespeichert. Die Identität des Serverobjekts bleibt unverändert. Die Identität der Verzeichnisdatenbank hingegen ändert sich, wenn auf dem Server eine Systemstatuswiederherstellung ausgeführt wird oder wenn eine Anwendungsverzeichnispartition auf dem Server hinzugefügt, entfernt und dann erneut hinzugefügt wird. (Ein weiteres Szenario: Wenn von einer Hyper-V-Instanz die eigenen VSS Writer in einer Partition ausgelöst werden, die eine VHD-Datei eines virtuellen Domänencontrollers enthält, löst auch der Gast seine eigenen VSS Writer aus. Da es sich um denselben Mechanismus wie beim oben beschriebenen Sicherungs- und Wiederherstellungsvorgang handelt, wird auch in diesem Fall die invocationID zurückgesetzt.)

Das invocationID-Attribut dient also letztlich dazu, einen Satz von Quellupdates auf einem Domänencontroller einer bestimmten Version der Verzeichnisdatenbank zuzuordnen. Anhand der beiden genannten Tabellen, Aktualitätsvektor und obere Kontingentgrenze, können die Domänencontroller - unter Verwendung der invocationID und der GUID des Domänencontrollers - feststellen, aus welcher Kopie der Active Directory-Datenbank bestimmte Replikationsinformationen stammen.

Die invocationID ist eine GUID (Globally Unique Identifier), die in einer der ersten Zeilen des Ausgabetexts angezeigt wird, nachdem Sie den Befehl repadmin /showrepl ausgeführt haben. 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 die Active Directory-Domänendienste auf einem Domänencontroller ordnungsgemäß wiederhergestellt werden, wird die invocationID zurückgesetzt. Damit geht - entsprechend der Größe der zu replizierenden Partition - ein gesteigerter Replikationsdatenverkehr einher.

Angenommen, VDC1 und DC2 sind zwei Domänencontroller in derselben Domäne. Die folgende Abbildung zeigt, wie VDC1 von DC2 wahrgenommen wird, wenn der Wert der invocationID bei einer ordnungsgemäßen Wiederherstellung zurückgesetzt wird.

Replikationsprozess für Domänencontroller

Ein USN-Rollback erfolgt, wenn die regulären Updates der USNs umgangen werden und ein Domänencontroller eine USN zu verwenden versucht, die niedriger als das letzte Update ist.

Unter Windows Server 2008 oder Windows Server 2003 Service Pack 1 (SP1) wird das USN-Rollback erkannt, und in den meisten Fällen wird die Replikation beendet, bevor Abweichungen in der Gesamtstruktur entstehen. Für Windows 2000 Server müssen die Updates im Artikel 885875 der Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=137184) installiert werden, um diese Erkennung zu ermöglichen.

Ein USN-Rollback kann viele Ursachen haben: beispielsweise die Verwendung alter VHD-Dateien oder die Ausführung einer P2V-Konvertierung, ohne sicherzustellen, dass der physische Computer nach der Konvertierung dauerhaft offline bleibt. Mit den folgenden Maßnahmen können Sie die Ausführung von USN-Rollbacks verhindern:

  • Erstellen oder verwenden Sie keinen Snapshot eines virtuellen Computers eines Domänencontrollers.

  • Kopieren Sie die VHD-Datei des Domänencontrollers nicht.

  • Exportieren Sie nicht den virtuellen Computer, auf dem ein Domänencontroller ausgeführt wird.

  • Verwenden Sie zum Wiederherstellen eines Domänencontrollers oder zum Ausführen eines Rollbacks für die Inhalte einer Active Directory-Datenbank ausschließlich eine unterstützte Sicherungslösung, wie z. B. die Windows Server-Sicherung.

In manchen Fällen bleibt ein USN-Rollback unerkannt. Es kann jedoch auch weitere Replikationsfehler zur Folge haben. Bei solchen Fehlern muss zunächst das Ausmaß des Problems festgestellt werden, um es dann zeitnah zu beheben. Informationen zum Entfernen veralteter Objekte als Folge eines USN-Rollbacks finden Sie im Artikel 870695 der Microsoft Knowledge Base unter "http://go.microsoft.com/fwlink/?LinkId=137185".

USN-Rollbacks ohne Zurücksetzung der invocationID (verursacht durch unzulässige Wiederherstellungsverfahren) werden in den meisten Fällen erkannt. Windows Server 2008 bietet Schutzmaßnahmen, um zu verhindern, dass nach einem unzulässigen Wiederherstellungsvorgang für einen Domänencontroller eine Replikation ausgeführt wird. Diese Schutzmaßnahmen werden dadurch ausgelöst, dass ein unzulässiger Wiederherstellungsvorgang niedrigere USNs für Quelländerungen ergibt, die die Replikationspartner bereits empfangen haben.

Wenn unter Windows Server 2008 und Windows Server 2003 SP1 ein Zieldomänencontroller Änderungen über eine bereits verwendete USN anfordert, wird die Antwort des Quellreplikationspartners vom Zieldomänencontroller dahin gehend gedeutet, dass die Replikationsmetadaten veraltet sind. Dies bedeutet, dass für die Active Directory-Datenbank auf dem Quelldomänencontroller ein Rollback auf einen vorherigen Status ausgeführt wurde. Beispielsweise kann für die VHD-Datei eines virtuellen Computers ein Rollback auf eine vorherige Version ausgeführt worden sein. In diesem Fall werden vom Zieldomänencontroller die folgenden Quarantänemaßnahmen auf dem Domänencontroller gestartet, bei dem eine unzulässige Wiederherstellung festgestellt wurde:

  • 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.

  • Zur Meldung dieses Zustands wird von den Active Directory-Domänendiensten die Ereignis-ID 2095 im Verzeichnisdienst-Ereignisprotokoll generiert.

Die folgende Abbildung veranschaulicht die Abfolge von Ereignissen, wenn ein USN-Rollback auf VDC2, dem auf einem virtuellen Computer ausgeführten Zieldomänencontroller, erkannt wird. In diesem Beispiel wurde das USN-Rollback auf VDC2 erkannt, weil ein Replikationspartner festgestellt hat, dass ein von VDC2 gesendeter Aktualitäts-USN-Wert dem Zieldomänencontroller bereits bekannt war. Dies ist ein Hinweis darauf, dass für die Datenbank von VDC2 ein unzulässiges Rollback ausgeführt wurde.

Beispiel dafür, wie Replikation inkonsistent werden kann

Wenn im Verzeichnisdienst-Ereignisprotokoll die Ereignis-ID 2095 gemeldet wird, führen Sie sofort das folgende Verfahren aus:

  1. Trennen Sie die Netzwerkverbindung des virtuellen Computers, von dem der Fehler aufgezeichnet wurde.

  2. Versuchen Sie festzustellen, ob Änderungen dieses Domänencontrollers an andere Domänencontroller weitergegeben wurden. Falls das Ereignis auf den Start eines Snapshots oder einer Kopie eines virtuellen Computers zurückzuführen ist, versuchen Sie den Zeitpunkt des USN-Rollbacks festzustellen. Anschließend können Sie die Replikationspartner des Domänencontrollers auf Replikationen nach diesem Zeitpunkt überprüfen.

    Hierfür eignet sich das Tool Repadmin. Weitere Informationen zum Verwenden von Repadmin finden Sie im Thema zur Überwachung und Problembehandlung der Active Directory-Replikation mithilfe von Repadmin unter "http://go.microsoft.com/fwlink/?LinkId=122830". Wenn Ihnen diese Überprüfung selbst nicht möglich ist, wenden Sie sich an die Microsoft-Kundenbetreuung (http://go.microsoft.com/fwlink/?LinkID=102491).

  3. Erzwingen Sie eine Herabstufung des Domänencontrollers. Dies beinhaltet das Bereinigen der Metadaten des Domänencontrollers und das Übernehmen der Betriebsmasterrollen (auch als FSMO-Rollen bezeichnet). Weitere Informationen finden Sie im Abschnitt "Wiederherstellung nach einem USN-Rollback" des Artikels 875495 der Microsoft Knowledge Base unter "http://go.microsoft.com/fwlink/?LinkID=137182".

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

Ein USN-Rollback wird in den folgenden beiden Fällen möglicherweise nicht erkannt:

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

  2. Die USN auf dem wiederhergestellten Domänencontroller ist höher als die letzte USN, die vom anderen Domänencontroller empfangen wurde.

Im ersten Fall können infolge einer Replikation mit anderen Domänencontrollern Änderungen auf einem der virtuellen Computer auftreten, die nicht an den anderen virtuellen Computer repliziert 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 sowohl der physische als auch der virtuelle Computer im selben Netzwerk ausgeführt werden. Möglich ist diese Situation auch, wenn mehrere virtuelle Domänencontroller vom selben physischen Domänencontroller erstellt und dann im selben Netzwerk ausgeführt werden.

Im zweiten Fall gilt ein USN-Bereich für zwei unterschiedliche Änderungen. Dieses Problem kann sich über längere Zeit fortsetzen, ohne erkannt zu werden. Wenn jedoch ein während dieses Zeitraums erstelltes Objekt geändert wird, wird ein veraltetes Objekt erkannt und als Ereignis-ID 1988 in der Ereignisanzeige gemeldet. Die folgende Abbildung veranschaulicht, wie ein USN-Rollback in einer solchen Situation möglicherweise nicht erkannt wird.

Kein USN-Rollback erkannt - Replikationsabweichung

RODCs sind Domänencontroller, auf denen schreibgeschützte Kopien der Partitionen einer Active Directory-Datenbank gehostet werden. Da RODCs keine Änderungen an andere Domänencontroller replizieren, werden die meisten Probleme im Zusammenhang mit USN-Rollbacks vermieden. Kommt es jedoch zur Replikation mit einem beschreibbaren Domänencontroller, der von einem USN-Rollback betroffen ist, dann ist auch der RODC betroffen.

Von der Wiederherstellung eines RODCs mithilfe eines Snapshots wird abgeraten. Verwenden Sie zur Wiederherstellung von RODCs eine Active Directory-kompatible Sicherungsanwendung. Zudem muss wie auch bei beschreibbaren Domänencontrollern darauf geachtet werden, dass RODCs nicht länger als die Tombstone-Lebensdauer offline bleiben. Andernfalls kann es auf den RODCs zu veralteten Objekten kommen.

Weitere Informationen zu RODCs finden Sie im Planungs- und Bereitstellungshandbuch für schreibgeschützte Domänencontroller unter "http://go.microsoft.com/fwlink/?LinkID=135993".

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft