Restoring a DC from a Snapshot

Reading Time: 5 minutes

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

  1. From a command prompt run the following command
  2. 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

  1. Drill down to HKLM\System\CurrentControlSet\Services\NTDS\Parameters
  2. Modify the RegKey “Database restored from backup” = 1
  3. If this RegKey doesn’t exist create one as a DWORD and set to a 1
  4. 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.
  5. Drill down to HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
  6. Modify the RegKey BurFlags to D2

7)      Reboot the server

8)      Log into the DC

  1. Verify that the Invocation Id has changed
  2. 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