How to safely clone a domain controller

• Author
• Recent Posts

Paul Middleton

Paul Middleton has been an IT professional for the past 20 years. Starting out as an IT support analyst in the UK, he moved onto being a systems engineer specializing in Microsoft core technologies such as Active Directory and Exchange. He is now based in the US and manages an infrastructure team supporting a large multinational enterprise. He is a subject matter expert in many infrastructure technologies.

Latest posts by Paul Middleton (see all)

• How to install and configure Microsoft LAPS - Mon, Mar 22 2021
• How to safely clone a domain controller - Wed, Feb 3 2021

Note that this is not the same as using the New-ADDCCloneConfigFile command to create a new production domain controller. The following guide will create a DC that hopefully never touches your production domain again.

Selecting a domain controller for cloning

The first step is to find yourself a clean domain controller. You need to select one that meets as many of the following criteria as possible:

1. The least amount of software that isn't essential for the functioning of Active Directory.
2. No additional roles or features installed.
3. Can be powered down for a few minutes at some point without triggering an outage that will have a director yelling your name like an angry TV police captain.
4. Holds most or all of the FSMO roles.
5. Ideally is already virtualized.

Prepping for cloning

If you cannot find a suitable cloning candidate, a good, safe option is to build a new temporary domain controller. Don't install anything on it at all, but transfer the FSMO roles to it if you can. Then you do not have to worry about removing software and reinstalling it later, or powering down domain controllers that might be in use by somebody somewhere.

Once you have selected a suitable candidate, there are a few things you'll need to do to make this run as smoothly as possible.

First, if you use multiple accounts for administration and user functions, make sure you know your domain admin password before you start—and that it's not about to expire! This might just save you having to start again later on.

Second, add the computer to the AD group named "Cloneable Domain Controllers". This group exists as of Windows Server 2012. It's not strictly necessary for this type of clone, but it might give you a smoother ride, especially if you plan to move the clone to different hardware. We just need to remember that when we're done, this membership needs to be removed, as there are some security implications.

Third, make sure your chosen domain controller holds all the FSMO roles so you don't have to seize them later. The easiest way to check is by typing "NETDOM QUERY FSMO". You can also check with PowerShell if you prefer:

Identifying the current FSMO roles

If you need to transfer the roles, run the following PowerShell line:

Move-ADDirectoryServerOperationMasterRole “TargetDC” –OperationMasterRole 0,1,2,3,4

Verify the move was successful before proceeding.

Transferring the FSMO roles

Finally, shut down the domain controller. You don't need to make a backup since we're not planning on making any changes to this copy.

Send in the clones

Now we're ready to start the cloning. How we do this depends on the source system. Ideally, we're working on a virtual machine. If so, then you can use the clone function of your hypervisor to create a copy of the server. For VMware, you'd right-click and select "Clone to Virtual Machine". For Hyper-V, you'd need to export the VM and then reimport it as a new VM.

Whichever option you use, make sure you disconnect the NIC of the target VM during clone or import. You don't want it booting up and getting back on the network with the same name as your source DC. The longer it takes to spin up your new DC, the worse the resulting problems can get.

If you're using a physical machine, you've got an extra bit of leg work. A good option is to boot from a CD or USB drive running a VMware cold clone and P2V the physical server into a VM. I'm not going to cover that here, but I'm sure your search engine of preference can help you with that.

A little cleanup

Now that we have a new domain controller and it is sufficiently disconnected from the network, let's clean up after ourselves a little and get the source DC back online. Start up your source DC again. If you transferred any roles to it before you began, transfer them back where they need to be using the same process described earlier.

If you built a temporary domain controller, you can now demote it back to a member server and begin the decommission process. If you used an existing domain controller, remove it from the "Cloneable Domain Controllers" group. Your environment should now be back to how it was before you started.

Making the clone workable

So now all traces of our tinkering have been removed from our production environment. Let's focus on the clone and get this thing running.

First, we need to get it on an isolated network where it can only communicate with whatever we allow. You're probably going to need your network or security team to do this. The first thing we need to do is allow only RDP traffic in TCP and UDP 3389. This means we can RDP instead of using the VM console. All other inbound and outbound traffic should be blocked. If you're comfortable with the Windows firewall, you can set that up instead—but it's a lot of work and there's more room for error.

Once that has been done, start your domain controller and give it an IP address. Send a few test pings out to make sure the firewall guys haven't messed anything up. It shouldn't be able to successfully ping any other DC. Try the same in reverse; no domain controllers should be able to ping it.

Now you can RDP in to make things a little easier. All that's left to do at this point is to tidy up a little.

Last bit of tidying up

Most of this is optional, but I'd recommend it if you want to keep your event logs of your new cloned DC free of a constant stream of useless errors.

Seize all the FSMO roles forcibly if you didn't transfer them before you started.

Delete all the replication links between all the (now unavailable) domain controllers.

Remove NTDS links

Delete the NTDS settings from the unavailable domain controllers.

Delete the NTDS settings

When prompted that the server is a global catalog, choose to delete anyway.

Finally, delete the unavailable domain controller AD object.

Delete the domain controller

You'll want to repeat these steps on all the other domain controllers in that AD site.

Ready to go!

You now have a perfect replica of your live production environment that your developers can play with to their hearts' content, safe in the knowledge that your Active Directory is protected from any bad code and cowboy antics.