As mentioned in one of my earlier posts, I’ve been performing some tests with Active Directory restores to provide myself with a refresh of the procedure as I haven’t done it for awhile and just so I won’t need to do this again in the future, I thought it would be beneficial to myself to document the process so I have screenshots and steps to reference to in the future.
We’re all familiar with the native NTBackup utility that Windows Server 2003 provides and it is important to remember that whenever a change is to be made to your directory service, always remember to perform a backup of your domain controller. I almost always perform a backup of more than one domain controller whenever I’m about to make any changes.
Backup Process
Start up NTBackup on your domain controller and select the System State from the list of items to be backed up:
Click on the Start Backup button and wait for the backup to complete:
Now that we have a backup completed, let’s begin mimicking an unintended change in Active Directory. For the purpose of this example, we’ll be deleting the Public Key Services node in the Configuration container:
As shown in the screenshot above, the Public Key Services node in the Configuration container has been deleted (bye bye CA services) from Active Directory.
Restore Process
Prior to actually proceeding to restore the System State that was backed up, we will need to restart the domain controller in Directory Services Restore Mode either locally or remote. Locally is done by simply hitting F8 during start up while for remote, we’ll need to edit the start up options in the boot.ini file:
To force the domain controller to restart in Directory Services Restore Mode simply append the following to the end of the boot.ini file:
/SAFEBOOT:DSREPAIR
... which will change your boot.ini file to look something like this:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /noexecute=optout /fastdetect /SAFEBOOT:DSREPAIR
Once the changes have been completed, proceed with rebooting the domain controller:
If you have access to the console, you’ll notice that once the domain controller begins to start up, the wallpaper will look different:
Wait for the boot up process to complete and you’ll be able to remote desktop to the domain controller:
It’s important to note that you will need to login with the Active Directory Restore Mode password and if for some reason you need to have forgotten it, use the following KB article to reset it: http://support.microsoft.com/kb/322672.
Once you’ve successfully logged in, you’ll be promopted with the following warning/informational message:
One of the first things I do once I successfully get into the domain controller is to remote the /SAFEBOOT:DSREPAIR switch from the boot.ini file:
Once you’ve completed the change to the boot.ini file, continue with restoring the the backed up System State to the domain controller:
Note that if the domain controller you are restoring is the only domain controller in your environment, you will need to select the last option:
When restoring replicated data sets, mark the restored data as the primary data for all replicas.
Once the backup is complete, click on the Close button and remember to select No when asked to reboot:
Marking an object or objects as authoritative
Start up NTDSUTIL:
Then execute the following command:
authoritative restore: restore subtree "CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=local"
You’ll be prompted with a confirmation message asking if you’re sure you would like to perform this authoritative restore so continue by selecting Yes and you will see the following output:
C:\>ntdsutil
ntdsutil: authoritative restore
authoritative restore: restore subtree "CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=local"
Opening DIT database... Done.
The current time is 04-20-11 14:57.04.
Most recent database update occured at 04-19-11 22:24.00.
Increasing attribute version numbers by 100000.
Counting records that need updating...
Records found: 0000000008
Done.
Found 8 records to update.
Updating records...
Records remaining: 0000000000
Done.
Successfully updated 8 records.
The following text file with a list of authoritatively restored objects has beencreated in the current working directory:
ar_20110420-145704_objects.txt
None of the specified objects have back-links in this domain. No link restore file has been created.
Authoritative Restore completed successfully.
authoritative restore:
Once the restore is complete, proceed to reboot the server:
Verifying the restored object
Once the domain controller has been rebooted, open ADSIEdit, connect to domain controller you restored the partition on and navigate to the node that contains the restored object:
As seen in the screenshot above, while DC1 has the Public Key Services node in the Configuration container restored, the changes haven’t been replicated to DC2 yet:
What’s also worth noting is that opening Replication Monitor and forcing a replication shows that certain partitions aren’t replicating properly:
What’s important at this point is not to panic because it does take a bit of time for the 2 domain controllers (or more if you had more than 2) to resolve the conflicts they seen between each other after a restore.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
For those who are interested in how this conflict is resolved, domain controllers actually have an attribute named uSNChanged that it uses to track which domain controller has the most up-to-date value for the attribute and just so I don’t accidentally give the wrong explanation for this attribute because of my poor memory, I will simply provide a copy and paste from Microsoft:
When a domain controller modifies an object it sets that object's uSNChanged attribute to a value that is larger than the previous value of the uSNChanged attribute for that object, and larger than the current value of the uSNChanged attribute for all other objects held on that domain controller. As a consequence, an application can find the most recently changed object on a domain controller by finding the object with the largest uSNChanged value. The second most recently changed object on a domain controller will have the second largest uSNChanged value, and so on.
Reference: http://msdn.microsoft.com/en-us/library/ms677627.aspx
This means that if you open up the properties of the object you’re restoring, you can compare the uSNChanged values for the same object on 2 domain controllers to determine which one will eventually take precedence against the other:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Depending on your environment, it may take some time before the restored object shows up on the other domain controllers so what I typically do is to force a replication periodically in Replication Monitor and use the results of the replication to determine whether the changes have been replicated already. Just in case the previous sentence wasn’t clear, what I basically mean is:
- If you see problems in the forced replication, it means you still need to wait.
- If you see a successful replication when you force a replication, it means the restore has been replicated.
Once no errors are reported in the replication, you should be able to see the restored object within ADSIEdit:
Hope this helps anyone out there who have not seen what the backup and restore process looks like. Reference articles from Microsoft can be found here:
Performing an Authoritative Restore of Active Directory Objects: http://technet.microsoft.com/en-us/library/cc779573(WS.10).aspx
Appendix A: Forest Recovery Procedures: http://technet.microsoft.com/en-us/library/cc781218(WS.10).aspx
NTDSUTIL: http://technet.microsoft.com/en-us/library/cc755915(WS.10).aspx
