
Active Directory Administration Cookbook, Second Edition
By :

The IFM
feature for promoting domain controllers leverages the fact that the contents of the Active Directory database and the Active Directory SYSVOL are identical throughout all domain controllers within the domain. The domain controller cloning feature takes this one step further and leverages the fact that all domain controllers are largely identical – not just the Active Directory-related files but all operating system files, most agent installations, information security measures, and most configuration items.
When a domain controller is properly prepared and promoted, it can serve as a template.
The domain controller cloning feature requires the following:
The domain controller you intend to clone needs to adhere to the following requirements:
When cloning domain controllers, check for proper Active Directory replication before cloning. This ensures that the domain controllers are up to date with all changes in Active Directory and can communicate the changes involved in adding a domain controller.
There are four steps to cloning a domain controller:
To successfully clone a domain controller, all agents and software packages that you've installed and configured on the domain controller you intend to clone need to support it.
When you install the Active Directory Domain Services role on a Windows Server 2012 installation, or on any newer version of Windows Server, there is the Get-ADDCCloningExcludedApplicationList
PowerShell cmdlet that you can use. When you run this PowerShell cmdlet, it will return the applications and services that Microsoft does not know whether you can successfully clone.
All Microsoft services and add-on packages that ship with Windows Server are tested, so these are already part of the DefaultDCCloneAllowList.xml
file. The contents of C:\Windows\System32\DefaultDCCloneAllowList.xml
are shown as follows:
Figure 2.13 – Contents of the DefaultDCCloneAllowList.xml file
For any other service and/or application, the recommended practice is to ask the vendor whether domain controller cloning is supported. When all services and applications check out, you can run the following line of PowerShell to add them to your organization's CustomDCCloneAllowList.xml
file:
Get-ADDCCloningExcludedApplicationList -GenerateXml -Path C:\Windows\NTDS -Force
In the preceding line of Windows PowerShell, the default path for the Active Directory database is supplied. Change it accordingly before running it.
After cloning, the domain controller picks up this file when you store it on removable media or in the same path as the Active Directory database.
The new domain controller that is created when an existing domain controller is cloned will need to be different from the existing one. It will need a different hostname, IPv4 address(es), IPv6 address(es), possibly different DNS Server allocations, or a different Active Directory site.
Microsoft provides a way to supply this information through the DCCloneConfig.xml
file. Again, after cloning, the domain controller picks up this file when you store it on removable media or in the same path as the Active Directory database.
If no DCCloneConfig.xml
file is supplied, the new domain controller will boot into Directory Services Restore Mode.
If an empty DCCloneConfig.xml
file is supplied, the new domain controller will be assigned the following:
If a specific hostname, Active Directory site, or IP address is needed, look at the parameters you can specify for New-ADDCCloningConfig
, such as the -SiteName
, -CloneComputerName
, and -Static -IPv4Address
parameters.
A sample PowerShell one-liner to create a new domain controller with the name DC04
in the Active Directory site named RemoteLocation
with the correct IPv4 information would look like the following:
New-ADDCCloneConfigFile -CloneComputerName "DC04" -SiteName RemoteLocation -Static -IPv4Address "10.0.1.3" -IPv4SubnetMask "255.255.255.0" -IPv4DefaultGateway "10.0.1.1" -IPv4DNSResolver "10.0.0.2"
Change the values for the -SiteName
, -CloneComputerName
, -Static
, -IPv4Address
, -IPv4SubnetMask
, -IPv4DefaultGateway
, and -IPv4DNSResolver
parameters for parameters that make sense for your environment.
In large organizations, the team responsible for managing Active Directory is usually a different team from the one managing the hypervisor platform. Through the integration components and/or VMware tools, the latter team might configure domain controllers for cloning and clone them, adding to the management burden of the Active Directory management team.
Therefore, the Active Directory team must explicitly allow a domain controller to be cloned in Active Directory. The mechanism to do so is to add source domain controllers to the Cloneable Domain Controllers group.
The following line of PowerShell accomplishes this for a source domain controller named DC03
in the lucernpub.com
Active Directory domain:
Add-ADGroupMember "Cloneable Domain Controllers" "CN=DC03,OU=Domain Controllers,DC=LucernPub,DC=com"
Replace the distinguishedName
value of DC03
with the distinguishedName
value of the domain controller you want to add to the Cloneable Domain Controllers group.
Now, the hypervisor platform team can clone the source domain controller.
As an Active Directory administrator, shut down the domain controller you intend to clone. After cloning has been successful, remove the source domain controller from the Cloneable Domain Controllers group and start it again as one of the domain controllers for the domain, or leave it off and allow it to be cloned repeatedly for a maximum period of 60 to 180 days, depending on the current tombstone lifetime period settings.
Domain controller cloning leverages the VM-GenerationID feature found in most modern hypervisor platforms. Through the specifications that Microsoft wrote for this feature, this ID is stored in every virtual machine's RAM and only changes under certain circumstances. These circumstances are the following:
Active Directory Domain Services is the first server role to take advantage of the VM-GenerationID feature to do the following:
By storing the 128-bit value for the VM-GenerationID in RAM in the Active Directory database, and the domain controller checking the value stored in the database with the value in RAM before each major action, the domain controller can sense when a snapshot is applied or when the hard disk is reused.
Important Note
As the VM-GenerationID feature is a hypervisor platform feature, a domain controller cannot sense when a snapshot is applied or when the hard disk is reused when these actions originate from the storage fabric or otherwise outside of the hypervisor platform.
When a hard disk is reused and the domain controller is properly prepared to be cloned, domain controller cloning creates a perfect clone of the source domain controller.
Domain controller cloning only allows cloning of fully writable domain controllers. It does not apply to read-only domain controllers.
Use the information in the Determining whether a virtual domain controller has a VM-GenerationID recipe to see whether the hypervisor platform supports domain controller cloning.
Refer to the Modifying the tombstone lifetime period recipe in Chapter 16, Hardening Azure AD, to find out whether domain controllers can be cloned for 60 or 180 days.