New features in Active Directory Domain Services in Windows Server 2012, Part 13: Domain Controller Cloning

In the previous blogpost in this series I discussed virtualization-aware Active Directory. With the use of the newly introduced VM-GenerationID, virtual Domain Controllers can now detect when they are reverted back to an earlier state or when their virtual hard disk is reused. Let's look into the latter scenario a bit.

In Windows Server 2008 R2 and earlier, when you'd reuse a hard disk of a Domain Controller to create a new host on the same network, two Domain Controllers would exist with the same hostnames, IP addresses and invocationIDs. This would cause all sorts of problems.      

What's New

But actually, cloning a Domain Controller isn't even that counterintuitive. Sure, we've been conditioned to promote additional Domain Controllers with or without Install from Media (IfM), but in reality, when you have a standardized environment, dedicated Domain Controllers are 98% equal. Besides, it's not the process of promoting a server to a Domain Controller that takes up a lot of time. It's installing the Windows updates since the last Service Pack, installing drivers, installing anti-malware, backup, monitoring, UPS- and other management agents, configuring these updates, installing their updates and making sure they all work, that's the bulk of the work. No wonder, IT departments work with SLAs that permit them to work days to set up a new production server…

So how does configuring a replica Domain Controller within 10 minutes sound?

Because that's exactly what the Active Directory team has created in Windows Server 2012, building on top of the VM-GenerationID and virtualization safeguards. The feature is called Domain Controller Cloning, or DCCloning for short.         

Cloning Domain Controllers from the GUI (mostly)

Cloning a Domain Controller is done in seven steps:

1. Allow the source Domain Controller to be cloned

In the previous blogpost I explained how Active Directory in Windows Server 2012 is now virtualization-safe; Virtualization Admins no longer need to know which virtual machines to be careful with and Active Directory Admins no longer have to fear the work done by the Virtualization Admins.

For Active Directory Admins to keep control of their virtual Domain Controllers, they are the ones to authorize their servers for Domain Controller Cloning. When a Domain Controller is unauthorized, a Virtualization Admin cannot clone a virtual Domain Controller. (It will boot into the Domain Services Restore Mode).

Authorizing a Domain Controller for Domain Controller Cloning, it's computer object needs to be made a member of the Cloneable Domain Controllers global security group, located in the Users container.

Alternatively you can grant the DS-Clone-Domain-Controller extended right, as, under the hood, this is the right the Cloneable Domain Controllers group grants.

2. Resolve Service Principal Name issues

One of the limitations of Domain Controller Cloning is the ability to clone Service Principal Names (SPN). Therefore, you should manually check for SPNs on the Domain Controller before cloning a Domain Controller. The following PowerShell one-liner, when run on the source Domain Controller, shows you the Service Principal Names in use:

Get-ADServiceAccount –filter:"*"

Check the output of this command. When it returns one or more service accounts, make sure to either remove the associated service (temporarily) or convert the service account into a group Managed Service Account (gMSA).

3. Resolve problems with non-cloneable applications, agents and services

Applications, agents and services in use on Domain Controllers might pose a challenge when you clone a Domain Controller. Microsoft has done an incredible amount of work to make sure their services are cloneable. This work can be seen when examining C:\Windows\System32\DefaultDCCloneAllowList.xml. However, with new applications, agents and services being released by both Microsoft and other vendors, we are bound to bump into software that has not been tested, yet. To get a list of installed software that is not on the list of tested software (DefaultDCCloneAllowList.xml), perform the following PowerShell one-liner:

Get-ADDCCloningExcludedApplicationList

This command might return a set of applications and services that are not tested. Now, when the Domain Controller Cloning process runs into an application, agent of service that is not on the Default Domain Controller Clone Allow List (DefaultDCCloneAllowList.xml) it will feel it is not allowed to perform the clone. When the command doesn't detect any untested applications, agents or services, you and the Domain Controller are good to go to the next step. When the command returns programs or services, you need to resolve the issues. You can do this in two ways:

1. Uninstall the program or service (temporarily)
2. (Work with the software vendor to) Test the application, agent and/or service for cloning.

When following the second method and you feel the applications and services detected using the Get-ADDCCloningExcludedApplicationList command don't stand in the way of successful Domain Controller Cloning, you can add these applications to a Custom Domain Controller Clone Allow List (CustomDCCloneAllowList.xml). This last file uses the same syntax as the Default Domain Controller Clone Allow List, so it will look something like this:

Place the CustomDCCloneAllowList.xml file in the same folder as the Active Directory database (ntds.dit) on the source Domain Controller.

Note:
By default, the location of the Active Directory database is C:\Windows\NTDS.

4. Write the DcCloneConfig file

In this step we specify the configuration of the target Domain Controller; the Domain Controller that will be the result of Domain Controller cloning. For this purpose we write a DCCloneConfig.xml file.

As the basis for our file, we use C:\Windows\System32\SampleDCCloneConfig.xml:

As the file shows, it has predefined fields we can use to specify configuration information for the new Domain Controller. When you work with DHCP Reservations for your Domain Controllers, are fine with Microsoft-generated Domain Controller names and want the target Domain Controllers to show up in the same Active Directory site as the source Domain Controller, you can use this file as is and save it as DCCloneConfig.xml in one of the following locations:

• the same folder as the Active Directory database (ntds.dit) on the source Domain Controller.
• In the root of (virtual) removable media, such as virtual floppy drives (*.vfd files) or virtual CD- and DVD-drives (*.iso-files)

Note:
When you save DCCloneConfig.xml on removable storage, make sure the admin creating the clone (step 4) attaches the removable storage to the virtual machine, but does not make the virtual machine boot from the media.

When you want to specify environment-specific configuration settings, do so before saving the file.

Tip!
In Windows Server 2012 you can mount a virtual hard disk when it's not in use by a virtual machine by right-clicking it. This way, it's possible to insert the DCCloneConfig.xml file in a later stadium. Right before you start up the target Domain Controller for instance.

5. Copy the virtual hard disk of the source Domain Controller and base the target Domain Controller on it.

Now, the source Domain Controller is fully checked, prepped and authorized. A Virtualization Admin can now copy its virtual hard disk VHD and create a new Virtual Machine, with that virtual hard disk.

Tip!
The source Domain Controller does not need to be turned off for you to be able to make a copy of its virtual hard disk for the target Domain Controller.

6. Start the target Domain Controller

Now it's time to feed the virtual machine its DCCloneConfig.xml file when using removable media and start it up.

When successful, the target Domain Controller will boot up and display its progress in Domain Controller cloning:

7. Restore any (temporarily) removed functionality

After the Domain Controller is done cloning, log on and restore any (temporarily) removed applications, agents, services and Service Accounts.     

Automating Domain Controller Cloning with PowerShell

While using the Graphical User Interface (GUI) to prepare the source Domain Controller gives great control over the individual steps of the process, PowerShell can help to cover all the bases and get the process streamlined.

Below is information on performing the steps that error out using PowerShell commands:

1. Adding the source Domain Controller to the Cloneable Domain Controllers group

To add the source Domain Controller to the Cloneable Domain Controllers group through PowerShell, use the following PowerShell one-liner:

Add-ADGroupMember "Cloneable Domain Controllers" "cn=dc01,ou=Domain Controllers,dc=domain,dc=tld"     

2. Resolve Service Principal Name issues

As stated above, you can run Get-ADServiceAccount on the source Domain Controller, to get the list of Service Principal Names in use. To remove the Service accounts automatically, use the following PowerShell one-liner:

Get-ADServiceAccount –filter:"*" | Remove-ADServiceAccount 
-confirm:$false   

3. Resolve problems with non-cloneable applications, agents and services

You would typically run the Get-ADDCCloningExcludedApplicationList PowerShell Cmdlet to get a list of the programs and services blocking successful Domain Controller Cloning. The following PowerShell one-liner can be used to automatically create the CustomDCCloneAllowList.xml file in C:\Windows\NTDS:

C:\PS>Get-ADDCCloningExcludedApplicationList -GenerateXml -Path C:\Windows\NTDS –Force   

4. Write the DCCloneConfig file

At this stage, run the New-ADDCCloningConfigFile PowerShell Cmdlet. You do not need to specify any parameters if you don't want to. When you don't, this Cmdlet will create the cleanest of DCCloneConfig.xml files in the Active Directory database path. This specific DCCloneConfig.xml will use the following Domain Controller Cloning configuration:

• The target Domain Controller will be assigned IP-addresses through DHCP
• The target Domain Controller name will be automatically generated
• The target Domain Controller will show up in the same Active Directory site as the source Domain Controller

If you want to specify a name, Active Directory site or IP addressing information take a look at the parameters you can specify for New-ADDCCloningConfig, like the –SiteName,
–CloneComputerName and –Static –IPv4Address parameters. A sample PowerShell one-liner would look like:

New-ADDCCloneConfigFile -CloneComputerName "DC02" -SiteName "ADSite01" -Static -IPv4Address "10.0.1.2" -IPv4SubnetMask "255.255.255.0" -IPv4DefaultGateway "10.0.1.1" -IPv4DNSResolver "10.0.0.2"  

 

Requirements

To use the Domain Controller Cloning feature, you should take care of the following requirements:

• At least one Windows Server 2012-based Domain Controller needs to be configured to host the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role. This change should be replicated to all Domain Controllers in affected Active Directory sites.
• The source Domain Controller needs to be run on a VM-GenerationID-capable virtualization platform and the Integration Components / Tools need to be installed and running.
• The source Domain Controller needs to run Windows Server 2012.
• The source computer needs to be a member of the Cloneable Domain Controllers group or needs to be granted the DS-Clone-Domain-Controller extended right.
• The source Domain Controller cannot be assigned Managed Service Accounts (MSAs), unless these accounts are group Managed Service Accounts (gMSAs).
• Applications that are incompatible with cloning should be uninstalled or added to CustomDCCloneAllowList.xml.
• The information specified in DcCloneConfig.xml should be unique. When a duplicate or invalid computername is specified, when an IP address conflict is detected, when IP and DNS information is left out and there is no DHCP Server on the network, when only one WINS Server address is specified or when a typo is made in the Active Directory sitename, the Domain Controller Cloning feature will halt. 

Note:
You can only create replica Domain Controllers with Domain Controller cloning, not Read-only replica Domain Controllers.

Note:
After you clone a Domain Controller the DCCloneConfig.xml file gets renamed (appended with the date), so the server won't accidentally clone itself again.