Hyper-V Replica Failover fuer Domain Controller

Hallo, hier wieder einmal Rol mit einem Ausflug in die neuen Server 2012 Feature-Gefilde von Hyper-V.
Einige von euch haben vom neuen Virtualisierungs-Feature “Hyper-V Replica” sicher schon gehört, siehe auch “Hyper-V Replica Overview”, https://technet.microsoft.com/en-us/library/jj134172.aspx  
Dahinter steckt eine eigene Synchronisation einer virtualisierten Disk, die als Replica mit einer primären Instanz nach initialer VM-Replikation periodisch auf Stand gehalten wird.
Dennoch kann nicht garantiert werden, daß der Stand 100% identisch ist. Für Domain Controller ergibt sich beim Failover auf das VM-Replica damit natürlich automatisch die Frage, ob dadurch nicht ein USN Rollback möglich ist, wie beschrieben in “USN and USN Rollback”; https://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#usn_and_usn_rollback und dabei die weitere AD Replikation unterbunden wird, siehe KB Artikel “ 875495 How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2”; https://support.microsoft.com/kb/875495/EN-US ?

Bei Server 2012 Domain Controller Guest gibt es bei Server 2012 Hyper-V das neue Feature der “VM-Generation ID”, bei der der DC Guest bei einer Änderung einem potentiellen USN Rollback automatisch vorbeugt, indem er die AD Replikation mit einer neuen “Incovation ID” betreibt. Dieser Mechanismus ist sehr schön beschrieben in “ Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100) ”, https://technet.microsoft.com/en-us/library/hh831734.aspx als Einführung für das ebenfalls neue Feature “ Virtualized domain controller cloning ” (beschrieben in  “ Virtualized Domain Controller Technical Reference (Level 300) ”; https://technet.microsoft.com/en-us/library/jj574214.aspx ), aber funktioniert das auch mit dem eingangs beschriebenen Virtualisierungs-Feature “Hyper-V Replica”?

Da wir auf der Suche in unseren Microsoft Whitepapern dazu keine klare Aussage finden konnten, haben Robert, unser Hyper-V Experte  (der auch seinen eigenen Blog “https://blogs.msdn.com/b/robertvi” pflegt), und ich das ganze ausprobiert.

Zunächst hatte Robert ein Server 2012 Hyper-V Replica angelegt. Im Hyper-V Manager wird das für seinen DC Guest vDC2 in einem eigenen Tab “Replication” angezeigt:

replica-1

Im Anschluß haben wir dann den Ausfall von vDC2 auf dem Primären Server, hier Host CL1N2 simuliert, sind auf den Replica Server CL2N1 gegangen und haben dort den Failover von Guest vDC2 initiiert:

replica2-1

Hier kommt dann die allgemeine Warnung über möglichen Datenverlust. Das reflektierte dann zunächst unsere Bedenken bezüglich USN Rollback:

replica31

Umso gespannter waren wir also, nachdem der Replica DC gestartet war. Doch die folgenden Directory Service Events gaben dann schnell Entwarnung, daß dar Failover Vorgang über die “VM-Generation ID” sauber gehandhabt worden war (Failover wurde um 9:25 Uhr ausgeführt). Hier die DS Events von Replica vDC2:

Zunächst prüft der 2012 DC Guest über seinen Hypervisor Driver ob “VM Generation ID” unterstützt wird und welcher Wert übermittelt wird:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2168
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The DC is running on a supported hypervisor. VM Generation ID is detected.
Current value of VM Generation ID: 4763348314524170831

Im Anschluß überprüft der DC dann den Wert seines eigenen Computer Attributes msDS-GenerationId im AD:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2172
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: Read the msDS-GenerationId attribute of the Domain Controller's computer object.
msDS-GenerationId attribute value: 7055439790112386533

So ermittelt er die Änderung als Auslöser für das sogenannte “Virtualization Safeguarding”:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2170
Task Category: Internal Configuration
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: A Generation ID change has been detected.
Generation ID cached in DS (old value): 7055439790112386533
Generation ID currently in VM (new value): 4763348314524170831
The Generation ID change occurs after the application of a virtual machine snapshot, after a virtual machine import operation or after a live migration operation. Active Directory Domain Services will create a new invocation ID to recover the domain controller. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services aware backup application.

Wie erwartet ändert er nun seine "Invocation ID" wie bei einem Restore, das vermeidet dann auch USN Rollback:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 1109
Task Category: Replication
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is as follows:
InvocationID attribute (old value): dd1a3c48-9ddc-4706-adfd-59cf21d6a731
InvocationID attribute (new value): 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
Update sequence number: 671753
The invocationID is changed when a directory server is restored from backup media, is configured to host a writeable application directory partition, has been resumed after a virtual machine snapshot has been applied, after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services-aware backup application.

Dies ist auch nachvollziehbar mit der Ausgabe von REPADMIN /SHOWSIG <DCNAME> über die gesamte Invocation History:

Repadmin: running command /showsig against full DC localhost
Default-First-Site-Name\VDC2
Current DSA invocationID: 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
dd1a3c48-9ddc-4706-adfd-59cf21d6a731 retired on 2012-11-28 09:25:22 at USN 671753
c9669f31-192d-40ea-9305-d793c81b634b retired on 2012-11-27 15:19:27 at USN 663560 (richtig, Test vom Vortag :) )

Die neue Invocation ID wird mit REPADMIN /SHOWREPL <DCNAME> sichtbar:

Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\VDC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 28381ac8-100c-4584-9778-c474c7245fcf
DSA invocationID: 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
==== INBOUND NEIGHBORS ======================================
DC=CONTOSO,DC=COM
    Default-First-Site-Name\DC1 via RPC
        DSA object GUID: ce5ca510-a1a3-4d99-a27a-ae5ff9330ce1
        Last attempt @ 2012-11-28 13:49:00 was successful.
CN=Configuration,DC=CONTOSO,DC=COM
    Default-First-Site-Name\DC1 via RPC
        DSA object GUID: ce5ca510-a1a3-4d99-a27a-ae5ff9330ce1
        Last attempt @ 2012-11-28 12:49:16 was successful

Auch Sysvol wird Non-Authoritative zurückgesetzt:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2208
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: N/A
Computer: VDC2.CONTOSO.COM
Description: Active Directory Domain Services deleted DFSR databases to initialize SYSVOL replica during a non-authoritative restore.
Active Directory detected that the virtual machine that hosts the domain controller was reverted to a previous state. Active Directory Domain Services needs to initialize a non-authoritative restore on the local SYSVOL replica. For DFSR, this is done by stopping the DFSR service, deleting DFSR databases, and re-starting the service. Upon restarting DFSR will rebuild the databases and start the initial sync.

Abschließend setzt der DC sein Computer Attribute msDS-GenerationId im AD zu dem neuen Wert, den er vom Hypervisor über “VM Generation ID” erhalten hat:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2179
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The msDS-GenerationId attribute of the Domain Controller's computer object has been set to the following parameter:
GenerationID attribute: 4763348314524170831

Damit ist er dann fertig – ich kann nur sagen “gut gemacht”:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:32
Event ID: 1000
Task Category: Service Control
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: Microsoft Active Directory Domain Services startup complete, version 6.2.9200.16384

So ist nun bewiesen, daß die Features “Hyper-V Replica” und “Virtualization Safeguarding” vom DC Guest gut zusammenarbeiten. Für die Verfügbarkeit von Server 2012 DCs ist das schon eine super Sache!!!
Dennoch ist natürlich angeraten, alle Spielarten selbst auszutesten, denn nichts hilft für den Ernstfall mehr, als eigene Erfahrung.

Damit nun “Happy Virtualization” !
Robert und Rol