There have been a few enhancements made to the domain controllers’ role in Windows Server 2012. Two of the interesting ones I like is the ability to clone domain controllers e.g. if you need to deploy a new DC into your environment you no longer need to build a server, run a DCPromo etc. just simply copy the VHD of an existing DC and create a new VM! (You do need to do a few pre-requests first). The second feature I like is that DCs have some intelligence built into them so they know if they have been reverted to an earlier snapshot or had its VHD copied and put into production.
This second enhancement is a great improvement, before Server 2012 if you restored an earlier snap shot you would have a huge Active Directory mess to sort out (if you could sort it out at all) and it would take hours of work usually involving an expensive support call to Microsoft. As virtualizing domain controllers is becoming more common so was the problem.
These two enhancements are possible as the active directory team has been working closely with the Hyper-V team. They have come up with the idea of a new ‘VM-Generation ID’ which has been added which is stored in the non-replicated attribute DC’s computer object. This ‘VM-Generation ID’ is a unique 128-bit identifier that guest operating systems and applications can leverage. The domain controller will use this ‘VM-Generation ID’ to be sure nothing has happened to it, which it does not know about.
Cloning a Domain Controller
Of course there are some requirements that must be in place for all of this to work but nothing too in-depth.
- First you must be running a 2012 PDC.
- Secondly you need to be running these VMs on Hyper-V 3.0 (Windows Server 2012 version). This is because when the VM is starting it checks the ‘VM-Generation ID’, of the virtual machine, if it detects this is different to what it was expecting and the DCCloneConfig.xml is present (more on that in a minute) then it knows it has been cloned.
- The final requirement is for you to add it to a new group called ‘Cloneable Domain Controllers’ unless it is part of this group you will be unable to complete the clone process – you will get an error when running the power-Shell command.
Once everything is in place you are all set to create a DC clone. Here are the steps to very quickly create a new DC in your environment.
- Find a suitable 2012 DC to clone.
- Add the DC’s computer account object to the group ‘Cloneable Domain Controllers’
- One further requirement is that this DC is not running any ‘un-cloneable’ applications. This command will look though everything that is installed and will check it against a list of applications in its whitelist. You can manually add applications to this list if you need. The default location of the XML list is: %windir%\System32\DefaultDCCloneAllowList.xml. If you do have any applications that aren’t in the white list you will be shown a list that you need to resolve. All of the obvious ones you will usually find on a DC such as DNS, DHCP, FRS and DFRS are all included in the whitelist by default.
By default the file will be saved to %windir%\NTDS and is called ‘DCCloneConfig.xml’. (If the server detects that it is a cloned VM as the ‘VM-Generation ID’ has changed, but it can’t find the ‘DCCloneConfig.xml’it will look in the root of removable drives, if it still can’t find the file the server will boot into ADRS and await further instruction.)
Next, shut down the machine, copy the VHD, attach it to your new machine and boot it.
If everything has gone to plan you will see this screen while the server boots. Once complete you have a new fully functional DC up and ready to go.
At this point the server calls SysPrep providers for select components to cleanup machine state. Next it will reset the identifier (invocationID) to ensure replication can complete and Invalidates RID pool eliminating potential for duplicate SIDs. If the source was a FSMO role holder the FSMO role is discarded.
You can just boot the machine you shut down to create the clone from. This machine will boot up and rename the ”DCCloneConfig.xml ‘ file by appending the date.time to the end and will then carry on as if nothing had happened.
Restoring a Domain Controller snap shot
As mentioned earlier there is a second enhancement to virtualized domain controllers, you now, no need to worry about someone creating and restoring a snap shot of a virtual domain controller – Microsoft have you covered there too!
The problem was that when you restored a snap shot you would restore the RID pool back to what it was when the snap shot was taken. You could have added hundreds or even thousands of changes since then (depending on the size if your organization). This would lead the server to start assigning new accounts the same SID which would cause security risk – the two accounts now have the same SID – so they have the same permissions! They would be able to read each other’s files and access each other’s folders. This would be a temporary problem as active directory would eventually detect this and would then disable the affected accounts. This would lead to hundreds or thousands (again depending on the number of users in your environment) of support calls to your helpdesk.
The second problem that would be caused is that the same USNs (update sequence number) would be used which means that when the DC tried to replicate with other DCs on the network they would accept all of the updates. This would lead to lingering objects, mismatched passwords and incorrect group membership depending on the DC the user tried to authenticate to.
This slide taken from a Microsoft TechEd presentation is a good one for showing the problem:
We can see this in action for ourselves. This is before the snap shot has been taken and shows when the RID pool was created and changed as well as the nextRID ID
Next several accounts are created so that we start to deplete the RID pool:
And finally the original snap shot is restored and as you can see the RID pool NextRID is the same as before the snap shot was taken! This in a live production environment would cause serious problems.
We can now compare this to what would happen if the same procedure was completed on a Windows Server 2012 domain controller.
Again, before the snap shot is taken we can see the RID pool ‘NextRID’ value and the date of creating & changing for the RIDPool.
Next we create the new accounts and we can see the RID pool has been depleting as the new accounts are created.
Finally we restore the snap shot and we can see that Server 2012 has detected this has happened and marked the RID pool as being bad. The server then contacted the RID master and requested a new RID pool.
So in summary before any changes are made to the local active directory database the server checks to see what its ‘VM-Generation ID’ is, if it is not what it is expecting then it will do several things.
- The first thing that will be done is the local RID pool will be invalidated and a new RID pool will be requested from the RID master.
- Next the invocation ID will be increased so that the when replication happens even though the USN would be the same the domain controllers invocation ID would be different meaning the other domain controllers would accept the update and replicate.
This is definitely NOT a replacement to backups – you should still carry on backing up your domain controllers as you currently are. I will write a post about how this can simplify a DR situation at a later date.
As a side not this will only work with Hyper-V 3.0 if you are running your domain controllers on VMware or XEN servers then I’m afraid you can’t take advantage of either of these features. Microsoft have said they are working with VMware to I wouldn’t be too surprised to see this available in the future.
This is a great new addition to server 2012 and just goes to show that Microsoft have been listening to customer feedback and watching support calls to see how they can help customers.