In-Depth

Hyper-V and the Cloneable Domain Controller

Is the new feature an IT game changer or an unnecessary headache?

• By Rick Vanover
• 09/19/2014

Sounds funny, but believe it or not, it's real. Since its release in Windows Server 2012, Hyper-V supports cloning of Domain Controller VMs. Cloning may seem an incredibly naughty task for a domain controller! In fact, I grew up with my Active Directory practice of preferring to address all situations through dcpromo. This includes removing a failed domain controller, moving roles around and transferring to new hardware or a new virtual machine. Windows Server 2012 has a new option that you may want to consider with Hyper-V ... Or should you stick to how you've been doing Active Directory?

Domain controller cloning in Windows Server 2012 has a few catch points. For one, it has to be a Windows Server 2012 domain (so don't try this with your 2008/2003 domains!) and additionally, it's only supported for Hyper-V.

At first glance, regarding Active Directory, my historical preference is to use dcpromo. Since 2012, it's taken on a few changes as well. For starters, it is integrated into the new Server Manager; like many other tools. But the cloneable domain controller is a special Hyper-V-only benefit, and it starts with a special PowerShell cmdlet, New-ADDCCloneConfig.

If you add the domain controller (computer account) that you are going to clone to the Users/Cloneable Domain Controllers security group, you can run this cmdlet to see if your environment supports domain controller cloning:

The warning at the end states that a few applications are not supported for cloning. This can include typical domain controller roles/features that may be in place like DHCP, DNS, or any third-party applications. And that's OK. It's just telling you what the new VM won't be able to run as part of the cloning process.

Seems pretty straightforward, right? Well, not so much. There are a number of additional tasks that are needed to create the cloned domain controller. This includes building the configuration file with IP networking and site specifications (through PowerShell) as an XML output, shutting down the domain controller and copying it via PowerShell, then importing a new one with the  new configuration. Quite an ordeal. In fact, I was going to go through with it in my lab but the fact that this new feature requires the domain controller VM to be shut down made me stop and think about the usability of this new feature.

I read through Tom Moser's post at length about this feature at the TechNet blog. If you haven't read this blog about the new feature, you should. While I think that the idea of having hypervisor-aware application cloning profiles makes sense, I don't like it for Active Directory where the domain controller needs to be turned off. A lot of command line stuff I can handle -- , it's a learning curve. But that's the Hyper-V way of recent.

So, I think for the need of scaling out domain controllers, I'm going to stick with my virtualization practice as it's been. Build a clean new VM, add the AD DS role and any other features needed, and then administer in my normal happy place:

What do you think about the cloneable domain controller? On very large scale, I believe there is a use case -- but I've not hit that type of scale in my virtualization practice. I'll give the feature a nod that it is entirely driven through command line (PowerShell), so those large environments that need it will appreciate it. But when it comes to the discussions between the Hyper-V administrator and the Active Directory administrator in large environments, I think they'll pass on this feature. Do you see a need for the cloneable domain controller feature? How would you use it? Share your comments below.