Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

Restoring a DC from a Snapshot

Restoring a Virtual DC from a Snapshot

Sorry about the formatting, I will have to retype at some point... 

This covers Windows 2008 R2 and all previous Windows o/s's

Let me start off by saying, if you are considering using this procedure, it should be your LAST option.  This is by no means is a supported Microsoft procedure and use of it could damage Active Directory.  In moving forward with this, you should also be reassessing your environment and take the proper steps to ensure this recovery model doesn’t have to be used again.

A little background, before the required steps:

Each Domain Controller’s DIT file (NTDS.DIT) is assigned a unique GUID, the name assigned to the DIT is its Invocation Id.  When an AD aware restoration occurs the Invocation Id is modified and any changes that have occurred on this DC between the restoration date and the current date need to be replicated back to this DC from its replication partners.  If a non-AD aware restore occurs the Invocation Id remains the same and the replication partners within the domain won’t replicate back changes.  These changes could be adds, changes or deletes with can creates orphans or within the AD world it is known as Update Sequence Number (USN) rollback.

 

To better understand this, consider the following scenario:

You have three DC’s, in one site, in your domain.  Each DC will keep track of the highest USN received for each partition (At a minimum three -Domain Naming, Configuration and Schema) of its replication partner(s); this is better known as the High Watermark Vector Table (HWVT). 

 

 

Please note the Invocation Id’s are actually 32 (GUID’s) characters in length.  To keep it simple I reduced the length for simplicity.  Also, the last used USN on each DC is noted as the Highest Committed USN.

 

Being it is a Friday, we are going to ensure we take a snapshot of DC-Accounting.  We need to ensure we have a full backup of a highly complex application that maintains all the corporate data.  Losing this data could cripple the business.

 

In figure 1, you will see that the three DC’s have fully replicated with one another, if you inspect the Highest Committed USN and compare it to the HWVT of the other DC’s you will see they are all equivalent.

 

 

Figure 1

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24873

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-Engineering

274369

16874

 

 

Next let’s look at what happens after an event creates a Change Notification to its replication partners.

 

It is Monday morning and 5 employees were recently hired and the object creation is reflected against the DC, DC-Accounting.  You will note that the Highest Committed USN has incremented from 24873 à 24878.  If you notice (Figure 2) neither DC, DC-Engineering or DC-HumanResources knows about the newest objects.  During the replication cycle each DC will let its replication partner know about the highest USN it has within its DIT, which is determined by transmitting the HWVT.  If the Highest Committed USN (On the requested DC)is larger than the USN sent from its requesting DC then the requested DC will replicate those USN’s that are greater than the requesting DC is aware of.

 

 

Figure 2

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24878

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

New Objects

USN

User – Jimmy Falon

24874

User – Karen Wallace

24875

User – Michele Jacobs

24876

User – David O’Shannon

24877

User – Steve Berger

24878

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-Engineering

274369

16874

 

 

 

As you can see, in Figure 3 the replication has completed. 

 

As the morning rolls on, disaster strikes, a water pipe in the ceiling bursts and destroys the HOST virtual machine hosting the guests of this server, one of which was DC-Accounting.  Recovering this DC and its application takes the highest priority, the companies financial systems have come to a halt and can’t move forward until the guest server, DC=Accounting is recovered.

 

 

Figure 3

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24878

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-Engineering

274369

16874

 

 

Note: If you recall earlier, the snapshot used for the recovery will have to come from Friday night prior to when the 5 new employees were entered into Active Directory and specifically, they were created on DC-Accounting.

 

You are quickly able to restore the guest DC-Accounting  on a different Host virtual server and getting the DC back online, bringing great praise from the boss and even a nice note from the president.  Little does anyone know that problems lurk that have the potential to create a nightmare.

 

If you examine Figure 4, you will note that both DC-Engineering and DC-HumanResources have HWVT values for DC-Accounting that are greater than what DC-Accounting itself knows about.  In other words both DC-Engineering and DC-HumanResources have objects that were created on DC-Accounting that DC-Accounting doesn’t know about.  Since the restore was unaware of the restoration of the DIT file no steps were taken to notify the partners to  DC-Accounting that it needs to be updated from its own missing records. 

 

To make matters worse, the next five objects created on DC-Accounting will go unreplicated since the USN values for these objects is less than what the other DC’s currently have as DC-Accounting’s HWVT.  This will create more problems since the next 5 USN’s will represent objects other than the 5 previous objects created prior to the water pipe break disaster.

 

 

Figure 4

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24873

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-Engineering

274369

16874

 

 

 

The way the DC’s will know to replicate this data back is if the Invocation Id were to change, since the DC’s manage the object replication comparison via the Invocation and its associated HWVT.  If you don’t follow the steps noted below which will generate a new Invocation Id, you will create lingering objects and a whole lot of trouble for yourself.  To take this one step further, you will also need to do an non-authoritative restore on the sysvol, since sysvol also uses USN’s and can also end up with lingering objects!  So sysvol also needs to be properly updated.

 

 

 

Use at your own risk!

 

 

1)      Do your clone recovery

2)      Configure your nic to be unable to talk to the network

3)      Note the value of your Invocation Id

a.       From a command prompt run the following command

                                                               i.      Repadmin /showrepl

4)      Reboot your DC, make sure you boot into Directory Services Restore Mode (DSRM)

5)      Stop the NTFRS service

6)      Start up regEdit

a.       Drill down to HKLM\System\CurrentControlSet\Services\NTDS\Parameters

                                                               i.      Modify the RegKey “Database restored from backup” = 1

1.       If this RegKey doesn’t exist create one as a DWORD and set to a 1

                                                             ii.      If the RegKey DSA Previous Restore Count exists in the same path, note its value.  Upon reboot it should increment by one.  If it didn’t exist it should be created and it should be set to a value of 1.

b.      Drill down to HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process

                                                               i.      Modify the RegKey BurFlags to D2

7)      Reboot the server

8)      Log into the DC

a.       Verify that the Invocation Id has changed

b.      In the Event Log look for the Event Id 1109 (AD restored from backup)

9)      If both events have occurred in bullet 8 then, enable the nic

 

 

Thanks to Ulf and Jorge for assistance

Published Friday, January 14, 2011 4:32 PM by Paul Bergson

Comments

Friday, January 14, 2011 5:53 PM by steve tretakis

# re: Restoring a DC from a Snapshot

Just to be clear, your talking about a single DC, not the Forest. Had they lost all the DC's could not a snapshot (or a copy of a VM DC)  been used as the "base", (forest root DC) for a Forest recovery? After the snap shot comes up, restore from last good backup, (following all the steps and procedures in MS forest recovery Doc). Then build out other DC's from scratch and allow them to replicate from the recovered root? What do think of keeping one VM DC, from each domain in the forest) in a Recovery site, who's sole use is to be a source for weekly snaps , to be used in the unlikely event, of a need for a Forest Recovery?

Sunday, January 16, 2011 1:07 AM by Paul Bergson

# re: Restoring a DC from a Snapshot

With a single DC there is no replciation and a snap would work.

I would never rely on a snapshot for a DR scenario.  There are plenty of tools available to protect a domain, so there is no need to use a snapshot.

# Virtualizing Domain Controllers

Virtualizing Domain Controllers Ace Fekay, MVP, MCT, MCTIP EA, MCTS Windows 2008 & Exchange 2007

# Virtualizing Domain Controllers and the Windows Time Service

Virtualizing Domain Controllers and the Windows Time Service Ace Fekay, MVP, MCT, MCTIP EA, MCTS Windows

# Active Directory Lingering Objects, Journal Wraps, USN Rollbacks, Tombstone Lifetime, and Event IDs 13568, 13508, 1388, 1988, 2042, 2023

Active Directory Lingering Objects, Journal Wraps, Tombstone Lifetime, and Event IDs 13568, 13508, 1388

Friday, September 26, 2014 2:09 AM by http://www.Elamus.ee

# http://www.Elamus.ee

Paul Bergson (MVP - Directory Services) : Restoring a DC from a Snapshot

Anonymous comments are disabled