By now you must have heard that one of the most awesomest and hyper-cool features to make it into the Microsoft Windows Server 2012 operating system is its explicit “out of the box” support for Domain Controller virtualization. And, if you haven’t, head over to Virtualized Domain Controller Architecture and feast your eyes (and brains) on the gory details. This post can wait while you engage in that useful pursuit.

Now that you are back with us, yes virtualizing a Windows Active Directory Domain Controller is now not only a “supported” operation, it is also (apparently, given the way Microsoft people are preaching it to customers these days) a “recommended practice” as well. Because, come to think of it, how are we going to get you to get off your behinds and move your enterprise workload into the next frontier of computering IF you are still beholden to the “brick-and-mortal” approach to computing? So, be nice to that Microsoft sales or technical resource as (s)he tries to shame you into getting with the program by informing you that the last obstacle to your adoption of the virtualization mindset has been vaporized by the wizards of Redmond. As with everything else you will hear from a consultant or a salesperson in this field, tiny devils are invariably lurking in the nooks and crannies of otherwise broad details.

You see, while Microsoft did indeed go to great lengths to make the process of virtualizing a Windows Domain controller as easy, painless and less destructive as technically possible (as of this writing), such operation is NOT exactly without risk. In other words, the VM-Generation ID feature is indeed a very useful innovation, but it does not completely remove the danger of virtualizing domain controllers. VM-Generation ID and the “DC Safeguard” features both combine to help reduce the possibility of accidental corruption and pollution of your Active Directory infrastructure. But, there are still scenarios where these “safety nets” are unable to achieve the intended objectives. One such scenarios is the subject of this post.

There are many feature differences among the many hypervisor flavors in the industry today. One of the differences between the VMware vSphere hypevisor (aka ESXi) and its Microsoft alternative (Hyper-V) is the ability to make an identical copy (clone) of virtual machine while that virtual machine is powered on and continues to provide services. This has long been a staple feature of the VMware hypervisor. This is commonly referred to as “Hot Cloning”. There is no equivalent feature present in the Microsoft hypervisor. There is no native option available in Hyper-V to simulate a hot-clone operation.

Consequently, as Microsoft planned, tested and finalized engineering and functional requirements for VM-Generation ID, hot cloning a Domain Controller was (understandably) not one of the use cases accounted for. The net result of this is that it was impossible to trap, analyze and account for VM-Generation ID behaviors and functionalities when subjected to a hot-cloning operation.

Which brings us to today.

Currently, Microsoft does NOT support hot cloning a Windows Server 2012 Domain Controller on any hypervisor platform. Period. You may not see explicit language similar to the previous statement in any other places, but ….. there you have it. To help you better understand why – there is no concept of “Hot Cloning” in Hyper-V and Hyper-V was the proofing ground for VM-Generation ID and all the features it exposes to facilitate easier and safer virtualization of Domain Controllers. So, the features were not tested against a hot-cloning operation.

For its part, VMware is providing guidance to its customer to make them aware of the negative consequences of hot-cloning a Windows Server 2012 Domain Controller on the vSphere platform. Remember that Windows, Active Directory, VM-Generation ID and all the related features and attributes described here all belong to Microsoft. VMware has always encouraged customers to adhere to configuration and support guidance provided by any third-party vendor of any product or operating system hosted on VMware’s hypervisor.

Share →