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

Reading Time: 9 minutes

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.

The Cloneable Domain Controllers Global Security Group in Active Directory Administrative Center (click for larger screenshot)

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:

CustomDCCloneAllowList.xml (click for larger screenshot)

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:

The contents of SampleDCCloneConfig.xml (click for larger screenshot)

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:

The target Domain Controller showing the progress of Domain Controller Cloning (click for larger screenshot)

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:

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.

 

Concluding

Domain Controller Cloning is useful when you want to create a replica Domain Controller fast.

Of course, you can use it to quickly create an extra Domain Controller when the current Domain Controllers are burdened, but you can also use it as a Disaster Recovery method. Combining Domain Controller Cloning with only a backup copy of one pre-prepped Domain Controller in each domain within an Active Directory environment, allows for fast and easy re-creation of the environment.

Related KnowledgeBase articles

2742844 Domain controller cloning fails, server boots in DSRM
2742908 After cloning domain controller, "no logon servers available"
2742927 New-AdDcCloneConfig error "Index was out of range"
2747974 Domain controller cloning event 2224 gives incorrect guidance
2742959 Domain controller cloning error 8437
2743278 Domain controller cloning error 0x80041005
2742916 Domain controller cloning fails with error 8610
2742970 DC cloning fails with no DSRM, duplicate source and clone computer
2745013 New-AdDcCloneConfigFile error "the server is not operational"
2742874 DC cloning does not recreate all service principal names
2742836 Extra DHCP leases after cloning domain controllers
2737880 DC configuration error "The service cannot be started"
243330 Well-known security identifiers in Windows operating systems

Further reading

TechNet Wiki: Windows Server 2012 : Virtualization Safeguards (en-US)
Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)
Virtualized Domain Controller Technical Reference (Level 300)
Windows Server 8 AD Cloning, Virtualization, and Snapshots Warning
The future of a virtual domain controller
Safely Cloning Virtualized Domain Controllers with Windows Server 2012
Windows 8: support for snapshotting/cloning a DC is coming…
What’s New in Windows Server 2012 Active Directory
Windows Server 2012 ile Virtual Domain Controller VDC – VDC Klonlama
Virtual Domain Controllers and Windows Server 2012 Improvements
AD in Windows Server “8”: Was (wahrscheinlich) kommt
Safely Cloning an Active Directory Domain Controller with Windows Server 2012
Virtualized Domain Controller Cloning in Windows Server 2012
Domain Controller cloning in Windows Server 8 beta

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

  1.  

    "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."

    Are you sure?
    http://technet.microsoft.com/en-us/library/jj574223.aspx
    and
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2050242

    From my experience… (tested in the lab), this lead to problems (lingering objects)….

  2.  

    Excellent, clear, thorough–well done.
    thanks

  3.  

    This has proven to be one of the clearest documents to clone the DC as setting up multiple DCs was awkward before 2012.
    Thanks for this document.

    Raj Navalgund

  4.  

    Beautiful explanation. Thanks!

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.