Active Directory restore and backup

Please Note: The contents mentioned below are valid for Active Directory Infrastructure which has its Active Directory domain services working in either Windows 2000 or Windows 2003 or has Windows 2008 Active Directory DS working in Mixed mode with Windows 2003 DCs still alive.

Restoration of objects deleted accidently in Windows 2008 or Windows 2012 Active Directory Domain services working in native mode has become easy with introduction of "Recycle Bin". First you need to enable it to use it. While Recycle bin can be used only using PowerShell in Windows 2008 Active Directory Domain Services, GUI has been introduced in Windows 2012 AD DS and this has made restoration of objects deleted accidently very easy.

Recycle Bin Windows 2008 R2

Recycle Bin Windows 2012


Authoritative Restore and Non Authoritative Restore in Windows 2000 and Windows 2003 Active Directory Domain Services.

Non-authoritative restore of Active Directory
A non-authoritative restore returns the domain controller to its state at the time of backup, then allows normal replication to overwrite that state with any changes that have occurred after the backup was taken. After you restore the system state, the domain controller queries its replication partners. The replication partners replicate any changes to the restored domain controller, ensuring that the domain controller has an accurate and updated copy of the Active Directory database.

Non-authoritative restore is the default method for restoring Active Directory, and you will use it in most situations that result from Active Directory data loss or corruption. To perform a non-authoritative restore, you must be able to start the domain controller in Directory Services Restore Mode.

Authoritative restore of Active Directory
An authoritative restore is an extension of the non-authoritative restore process. You must perform the steps of a non-authoritative restore before you can perform an authoritative restore. The main difference is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory. Restore the smallest unit necessary, for example, do not restore the entire directory in order to restore a single subtree.

As with a non-authoritative restore, after a domain controller is back online, it will contact its replication partners to determine any changes since the time of the last backup. However, because the version number of the object attributes that you want to be authoritative will be higher than the existing version numbers of the attribute held on replication partners, the object on the restored domain controller will appear to be more recent and therefore will be replicated out to the rest of the domain controllers within the environment.

Unlike a non-authoritative restore, an authoritative restore requires the use of a separate tool, Ntdsutil.exe. No backup utilities— including the Windows 2000 Server system tools— can perform an authoritative restore.

An authoritative restore will not overwrite new objects that have been created after the backup was taken. You can authoritatively restore only objects from the configuration and domain-naming contexts. Authoritative restores of schema-naming contexts are not supported.

Perform an authoritative restore when human error is involved, such as when an administrator accidentally deletes a number of objects and that change replicates to the other domain controllers and you cannot easily recreate the objects. To perform an authoritative restore, you must start the domain controller in Directory Services Restore Mode.

If you wish to read more and know more about active directory restore and backup, please read this article.

 The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting

Read More

Troubleshooting AD Replication

Replication is another common AD trobleshooting scenario.
AD replication issues usually turn out to be caused by one of the following:

a) Faulty, substandard or misconfigured network equipment or WAN links
b) USN rollback issues caused by using unsupported restore methods (disk imaging of DC's, P2V utilities, snapshots, etc.)
c) DNS issues
d) Lingering objects

Further reading is available at "Troubleshooting AD Replication"

How to detect and recover from a USN rollback in Windows Server 2003
How to detect and recover from a USN rollback in Windows 2000 Server
Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server
How to remove data in Active Directory after an unsuccessful domain controller demotion

Remember metadata cleanup in Windows 2008 or Windows 2012 active directory is taken care of automatically. This is how it works. Suppose after you demote the DC using DCPROMO and its ends up in failure, or say the H\W of an old DC gave up and now you wish to replace it with a new one follow the setps given below: 

1) Get into the AD users and computers snap in. 
2) Select the OU where that DC resides. 
3) Right click on it and delete it. 
4) Rest of the metadata cleanup activity will be carried out by AD itself. So you see how easy it has become in Windows 2008 and Windows 2012. 

Read More

What happens in a Journal Wrap?

FRS is a multi-master replication system that takes care of replicating the contents of Sysvol between all DC’s in the domain (it can also replicate normal data but we're primarily interested in Sysvol replication in the blog entry).
With proper care and maintenance, Post-SP2 FRS on W2k3 is pretty stable and happily hums along as long as there isn’t an external condition such as a network outage or disk problems that cause it to break down (assuming the data you're replicating isn't completely unsuitable for replicating like .PST files, profile data or content that changes frequently).

The most frequent FRS issue is where a Journal Wrap occurs; let’s take a closer look at what happens during a Journal Wrap under the hood.

The way FRS works is that it has an internal database that contains all the files and folders it is replicating and each of these has a unique global ID (GUID). The dababase also contains a pointer to the last NTFS disk operation (in the USN Journal/NTFS Journal) that the FRS service processed.

If a user changes a file or folder on a disk, the following happens:
1) the operation is picked up by NTFS and an entry is made in the NTFS Journal
2) FRS monitors the NTFS Journal for changes and notes that a change has been made to that file
3) FRS keeps a record of the last NTFS Journal event that it processed and checks if it has processed it already
4) If it hasn’t processed it already, it looks at whether it is a file that it should replicate
5) If it should be replicated, the file goes into the normal process of staging, replicating, etc.
6) FRS increments the entry in its database about the NTFS Journal event that it has processed so it won’t consider it again

Now…let’s simplify things a bit.
- Our disk contains one file and one folder (e:\Test and test.txt)
- Our NTFS journal has a size of 10 entries (default NTFS Journal size in RL is ~512 Mb depending on your OS/SP level)
- Our FRS database contains three entries
o a GUID for E:\test
o a GUID for E:\test\test.txt
o A referral to the last NTFS Journal entry we processed (let’s say #4)
Normal operations:
- someone makes a change to test.txt
o the NTFS Journal is updated to #5
o FRS notes that the NTFS journal says that a change has been made to test.txt and it sees that it hasn’t processed that change
o Stage/Replicate and update the FRS database to reflect that we have processed that NTFS Journal entry.
Now, an Admin stops the FRS service for 30 minutes….
- Someone makes 10 changes to test.txt
o The NTFS Journal is updated 20 times and is now at #24 (remember we have a log size limit of the last 10 entries so therefore need to wrap around)
o FRS is stopped so it isn’t monitoring the NTFS Journal log
At this point, we have changes on the disk which FRS isn’t aware of. FRS still knows the last NTFS Journal entry that it processed and it will compare this with the current NTFS Journal the next time it restarts.
The next time the FRS service starts, it sees that it has missed NTFS operations on the disk (it last processed NTFS operation #4 but the NTFS Journal is now at #24 and we only have a log that goes back 10 entries so we’re missing operations #5-#14 from the database.
This is when FRS complains it has reached a Journal Wrap state, the NTFS Journal log has wrapped around and it doesn’t know the current state of things on the disk.
The impact of this on an affected DC is that FRS will not set the IsSysvolReady registry key to indicate to the Netlogon service that all is well, Sysvol will therefore not be shared out and the DC will not be able to authenticate users fully until the Journal Wrap condition has been resolved.
Manually sharing out Sysvol or setting the IsSysvolReady registry key to 1 are not valid methods of resolving this issue and are not addressing the real problem.

For FRS to recover from a Journal wrap, you’ll basically have to start from scratch and reset the FRS database and start counting the NTFS Journal from the current values it has.
This means either:
- Replicating in data from an existing inbound partner (The d2 or non-authoritative FRS restore approach)
- Making your own data authoritative and let everyone else replicate from you (the d4 or authoritative FRS restore approach)

The d2 approach is fairly simple to perform, the requirements are however that you have a good network connection with the inbound replication partner and the time it will take is dependent on the amount of data to be replicated vs. the capacity of the link

On the other hand, this may not always be sufficient and you can find yourself being forced to go with the d4 option. Going with the d4 approach should always be a last resort, it’s a time-consuming operation that requires careful planning and co-ordination between all DC's and they will be more or less inoperative during that time as the FRS service has to be stopped on each and only restarted gradually as the operation progresses. This is especially important for DC’s as they will have a hard time servicing users without a proper Sysvol being present.
For a full description of the d2/d4 burflags and how to use them, See KB 290762.


Further reading:
Troubleshooting journal_wrap errors on Sysvol and DFS replica sets
Using the BurFlags registry key to reinitialize File Replication Service replica sets
How to rebuild the SYSVOL tree and its content in a domain
Monitoring and Troubleshooting the File Replication Service
Why is placing the Sysvol directory on a separate partition a good practice?
Troubleshooting File Replication Service

Read More