Windows Server 2003 – Authoritative Restore
An Authoritative Restore of Active Directory is one of the hardest tasks in Windows Server 2003. To succeed, you need to understand how Active Directory Replication works, be an expert with NTDSutil, find the backup tapes and above all, a sound written plan.
Because you can only test an Authoritative Restore in Directory Services Restore Mode (F8 on the boot menu), I exhort you to try my other NTDSutil commands, just to get the hang of how this Microsoft utility works.
Tutorial Topics for Authoritative Restore
- Typical Authoritative Restore Scenario
- Why do you need an Authoritative Restore?
- Authoritative Restore Plan and Example
- Learning Points for Authoritative Restore
- Important Follow-up – Restore Subtree DN
- Real Life Problem – Authoritative Restore
- Summary of Authoritative Restore
Let us take a minute to understand what can go wrong and thus trigger the need for an Authoritative Restore. You instruct a junior administrator to delete a user account in the Bosses OU. They open up Active Directory Users and Computers, select the OU. Now instead of selecting the individual user, they select the entire OU container object and press delete. Even though they get two warning messages, they ignore them and press OK. In this scenario we have to assume that this deletion is replicated to all other domain controllers before the senior administrator realizes what has happened. There is no recycle bin to restore the users, the LostAndFound folder is no good in this situation. What we need is a laborious Authoritative Restore.
It is worth spending a minute taking stock of why we need an Authoritative Active Restore as opposed to a non-Authoritative restore. The heart of the problem is that in the above scenario, Active Directory is too clever for its own good. If you delete an ordinary file and restore it from backup, then great, you have the old file back just as it was. However, when you restore Active Directory, the other domain controllers try and be smart and replicate later transactions so a non-authoritative restore is no good for recovering an OU. What happens is another Domain Controller just replicates the transactions that deleted the OU because they are newer than the restored version. As we will see, an Authoritative Restore tricks the other Domain Controllers into accepting the old object by artificially incrementing its version number by 100000.
Guy’s Recommendation – EaseUS Todo Backup Server for 2003/2008 Server
EaseUS Todo Backup Server is an award-winning backup solution for 2003/2008 server users, completing disaster recovery in minutes. Version 4.5 has following advantages:
√ Backup and recovery – backup system, files and recover data in minutes.
√ System backup – one-click system backup and recovery.
√ Differential backup – only backup changed files since last full backup.
√ Incremental – only backup changed files since last backup, save your disk space.
√ Clone – upgrade hard drive to a new one without reinstalling system and applications.
√ Universal restore – easily restore system to dissimilar hardware.
√ Flexible storage options – backup to a local hard drive, CD/DVD, tape devices, network share, etc.
√ Backup Exchange and SQL Server available in EaseUS Todo Backup Advanced Server.
Knowledge is power. Now that we understand the problem, we can make a plan and then put it into action. NTDSutil will play the star role. To recap the example problem is that someone deleted an OU called Bosses.
1) The plan is to start with a normal restore. This is a non-authoritative restore, nothing fancy – yet. Once you have verified the initial restore, reboot, then press F8, and select Directory Services Restore Mode. Now its over to NTDSutil and ADSI Edit. (Incidentally if you have trouble with the DSRM password, check here.)
2) While NTDSutil will carryout the actual Authoritative Restore, ADSI Edit will help identify the LDAP name of the deleted OU. As a matter of tactics we only want to restore one branch or one SubTree of active directory. If for example, 20 users had been created since the initial disaster, we would not want to wipe them out by the Authoritative Restore. Fortunately, from the normal restore ADSI Edit will reveal the whereabouts of the OU. Let us assume that the deleted object was: OU=bosses,DC=ourdom,DC=com. The point is we only want to restore this one part of Active Directory, all the other objects must be left as they are.
3) Remember, we are in Directory Services Restore Mode, so we are all set to run NTDSutil, here are the commands:
Authoritative Restore Example
ntdsutil: authoritative restore
authoritative restore: restore object OU=bosses,DC=ourdom,DC=com
Opening DIT database… Done.
The current time is 06-17-05 12:34.12.
Most recent database update occurred at 06-16-05 00:41.25.
Increasing attribute version numbers by 100000.
Counting records that need updating…
Records found: 0000000012
1) NTDSutil has about 8 modes, we want specifically, Authoritative Restore.
2) Success or failure depends employing ADSI Edit to get the correct path, for me this is the most nerve wracking part of the exercise.
3) Notice how NTDSutil increases the version number by 100000. This makes sure that these restored object have a later version number than any equivalent object on the other domain controllers. As a result, when you reboot this machine it will replicate the restored OU=bosses to the other domain controllers.
4) NTDSutil is a Microsoft utility built-in to Windows Servers.
The above example used restore object. In real-life you probably want to restore the contents of the Bosses OU. Thus you would substitute Restore Subtree for Restore object if you wanted to reinstate the users in that Bosses OU.
Microsoft also recommends actually running the restore subtree TWICE if the OU contains User Objects. The explanation, is because the first time restores the object with the SID, the second time will actually traverse the remaining items and restore Group Memberships… it’s simple enough to hit the up arrow and run it twice.
I thank Tony Baker for pointing out the limitation of my original example, and for recommending restore subtree.
The main reason to monitor your network is to check that your all your servers are available. If there is a network problem you want an interface to show the scope of the problem at a glance.
Even when all servers and routers are available, sooner or later you will be curious to know who, or what, is hogging your precious network’s bandwidth. A GUI showing the top 10 users makes interesting reading.
Another reason to monitor network traffic is to learn more about your server’s response times and the use of resources. To take the pain out of capturing frames and analysing the raw data, Guy recommends that you download a copy of the SolarWindsfree Real-time NetFlow Analyzer.
When you have to perform an Authoritative restore be on the lookout for peripheral problems that are unique to your situation. Here is an example kindly sent in by Juha Pearson.
Group membership is often a pain to control; it is certainly amongst the most difficult attributes to script. The specific problem with an Authoritative Restore is when the group was created in Windows 2000 rather than Windows 2003. Active Directory understands a feature called LVR (Linked value replication), the underlying factor is the technology that allows replication of a single property change, rather than the whole object. For example, in W2K3 one change in group membership, resulted in only one property being replicated.
The problem diminishes if you have applied at least SP1 to your Windows 2003 Servers. However, what happens is that the Windows Server 2003 SP1 / SP2 machines may produce LDIF files with the extra LVR information.
You need to perform a procedure such as this:
- Open a command prompt and navigate to the directory containing the .ldf file and its respective log files.
- At the command prompt, type the following command, and then press ENTER:
- ldifde -i -k -f FileName
- For FileName, substitute the name of the .ldf file that you want to run, for example,
I say again this is but one example of the care and the research that you need before you undertake an Authoritative Restore of Active Directory.
‘Self heal’ works against you restoring when you try and restore Active Directory objects. The trick, which NTDSutil performs, is to fool AD that the restore has a higher version number than any existing Active Directory records. Mastering Authoritative Restore is like passing your final NTDSutil exam. Take the time to understand the role played by ADSI Edit in obtaining the restored object, for example, OU=bosses,DC=ourdom,DC=com
If you like this page then please share it with your friends