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
- From a command prompt run the following command
- 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
- Drill down to HKLM\System\CurrentControlSet\Services\NTDS\Parameters
- Modify the RegKey “Database restored from backup” = 1
- If this RegKey doesn’t exist create one as a DWORD and set to a 1
- 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.
- Drill down to HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
- Modify the RegKey BurFlags to D2
7) Reboot the server
8) Log into the DC
- Verify that the Invocation Id has changed
- 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