Active Directory USN Rollback

Focus: USN, USN Rollback, DSA GUID and Invocation GUID

Unique Sequence Number (USN)

USN is an AD database change tracking number. Any change or transaction made in a DC is represented by a USN increment. The USN of DCs in the same domain need not be same.
The USN of a DC is particular only to that DC, also the USN of other DCs will be tracked in the HWMV table of a DC.

Server Object GUID (DSA GUID)

DSA (Directory System Agent) GUID is used in USNs to track originating writes. It is also used by DC to identify its replication partners. The value of DSA GUID is stored in objectGUID attribure of the NTDS settings object. DSA GUID is created when AD is initially installed on a DC and will not change during its lifetime until or unless the DC is removed from the domain controller. DSA GUID ensures that the DC is recognizable even in case of a DC rename.

Server Database GUID (Invocation GUID)

AD database has its own GUID which is used to identify the database version. The value of Invocation GUID is stored in invocationId attribute of NTDS settings object. Unlike DSA GUID, Invocation GUID is changed during an AD restore process to ensure replication consistency.

Coming to the USN rollback scenario:

Cause

USN Rollback is mainly caused by restoring a DC using non Microsoft restore process like Norton's Ghost, VMware snapshot etc.. or when we perform a V2V of an existing DC.

Explanation
When we restore DC using the conventional methods of AD restoration, the Invocation ID of the DC will be reset which in turn resets the USN to make the DC understand that the database is restored. The Invocation ID tracks the version of the database of DC. The previous Invocation ID will be marked as retired. When we use methods other than the conventional restoration methods, this ID will not be reset. This prevents other DC from replicating with the rolledback DC, the changes made after the image was taken. 
In this scenario, other DCs will believe that the rolled back DC will be holding updated data and will not replicate, which makes the AD data inconsistent.

Resolution
  1. Forcefully demote the DC
  2. Remove metadata using metadata cleanup
  3. Seize FSMO roles
  4. Re promote the server

Comments

Popular posts from this blog

VMware and Windows Interview Questions: Part 2

VMware and Windows Interview Questions: Part 3

VMware vMotion error at 14%