Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
DC cloning fails with no DSRM, duplicate source and clone computer
Article ID: 2742970 - View products that this article applies to.
You are using the Virtualized Domain Controller (VDC) cloning feature introduced in Windows Server 2012. After attempting to clone a domain controller and using automatic IP addressing, you find that the DC has not cloned and booted normally. You now have a duplicate domain controller servicing requests with the same name as the source DC. The duplicated DC will not reliably replicate AD DS changes outbound or inbound when both domain controllers are running simultaneously and both servers allow local AD DS changes.
There are two possible causes:
1. You did not create the DcCloneConfig.xml file in one of the following locations:
2. You did create the DcCloneConfig.xml file in one of the correct locations, but later rebooted the source computer before cloning. This reboot renames the file with a time date stamp to prevent accidental cloning when the VM-Generation ID did not change. After the file was renamed, you shut down the source computer and cloned it.
In these steps, the following terms and examples are used:
You must run all steps from an elevated CMD prompt while logged on as a member of the Domain Admins group. To simplify recovery, all domain controllers are pointed primarily to the same DNS server.
Ensure that you know (or set) the Directory Services Repair Mode password on the original source domain controller before starting these steps, using the ntdsutil.exe command with the set dsrm password options.
1. On the original source domain controller, run the following sample commands:
Note: This shuts down the source domain controller and when it boots up, it will start in DS Repair Mode. This ensures that if the original source DC is accidentally restarted at any time before the steps are completed, it will not force you to start over.
2. Restart the duplicate domain controller gracefully using the following sample command:
3. Pause the Netlogon service on the duplicate domain controller using the following sample command:
Note: This prevents further automatic location of the duplicate domain controller by users and computers.
4. Disable inbound AD DS replication on the duplicate DC locally using the following sample command:
repadmin.exe /options DC2.corp.contoso.com +DISABLE_INBOUND_REPL
Note: This prevents further updates onto the duplicate DC from other domain controllers.
5. Possibly unnecessary step: If you do not already have a third "existing DC" (i.e. you were attempting to clone the only domain controller in the domain), you must promote a new domain controller gracefully in the same AD domain and site as the duplicate domain controller. If there is already an existing domain controller in this domain that was not duplicated, skip this step.
6. Ensure the new/existing DC from step 5 has an inbound replication partnership from the duplicate domain controller, using DsSites.msc or repadmin.exe /addrepsto to create a manual connection, if necessary. Confirm that the duplicate DC is configured to replicate successfully outbound with the new/existing domain controller by running the following command on the duplicate DC locally:
repadmin.exe /showrepl dc1.corp.contoso.com
Note: The new/existing DC must have an inbound replication connection from the duplicate DC before you can proceed to step 7. The /repsto argument can also be used to see outbound replication connections from the duplicate within the same site or if change notification is configured on inter-site links.
7. On the duplicate domain controller, configure the Windows Firewall with Advanced Security (or your third party firewall) to block the following ports and protocols inbound:
a. Ports 138 and 445 over TCP and UDP
b. Ports 389 and 636 over TCP
netsh.exe advfirewall firewall add rule name="MSFT block LDAP in" protocol=tcp dir=in localport=389 action=block
netsh.exe advfirewall firewall add rule name="MSFT block LDAPS in" protocol=tcp dir=in localport=636 action=block
netsh.exe advfirewall firewall add rule name="MSFT block SMB in" protocol=tcp dir=in localport=445 action=block
netsh.exe advfirewall firewall add rule name="MSFT block NB DG in" protocol=tcp dir=in localport=138 action=block
Note: This step prevents users from originating further updates on the duplicate domain controller through common AD DS protocols.
8. Ensure that all pending changes replicate from the duplicate DC to the new/existing DC. The DSA GUID listed by repadmin in step 6 is required here. Use the following command on the duplicate DC locally to ensure that all changes have replicated outbound from the Domain naming context, the Configuration naming context, and the DNS naming context(s):
repadmin.exe /showchanges dc1.corp.contoso.com5d083398-4bd3-48a4-a80d-fb2ebafb984fdc=corp,dc=contoso,dc=com
repadmin.exe /showchanges dc1.corp.contoso.com5d083398-4bd3-48a4-a80d-fb2ebafb984fcn=configuration,dc=corp,dc=contoso,dc=com
repadmin.exe /showchanges dc1.corp.contoso.com5d083398-4bd3-48a4-a80d-fb2ebafb984fdc=domaindnszones,dc=corp,dc=contoso,dc=com
repadmin.exe /showchanges dc1.corp.contoso.com5d083398-4bd3-48a4-a80d-fb2ebafb984fdc=forestdnszones,dc=corp,dc=contoso,dc=com
When all replication is in sync, the statistics for all the Object and Attributes fields will be "0" (zero). If you remove the /statistics argument, you can see the specific objects and attributes pending replication.
9. Use the Windows Server 2012 GPMC.msc Status tab to ensure that all SYSVOL changes have replicated from the duplicate domain controller to the new/existing partner DC (set the duplicate DC as the baseline). If all servers run a Server Core installation, use GPMC from a Windows 8 client with RSAT installed. If out of sync, ensure that the missing updates originated from another domain controller (i.e. group policy changes made after inbound replication was disabled on this server in step 4) before continuing.
10. Shut down the duplicate domain controller gracefully, back up its disks for safekeeping, then discard the virtual machine and its disks. It must not be allowed to boot up as a duplicate ever again.
11. Ensure that the new/existing domain controller has replicated all of the duplicate domain controller updates outbound to other domain controllers, ensuring that the delta of changes created on the duplicate DC are not lost to the forest forever.
12. Possibly unnecessary step: Demote the new domain controller gracefully, if created in step 5.
13. Start the original source domain controller. Logon with the DSRM administrator account and run the following sample commands:
Note: This removes the automatic DSRM boot flag for all subsequent restarts.
14. Enable inbound AD DS replication on the original source DC locally using the following sample command:
repadmin.exe /options DC2.corp.contoso.com -DISABLE_INBOUND_REPL
15. Ensure that new objects created in the environment both to and from the original source DC to any other existing domain controllers.
This behavior is expected. When cloning a domain controller, Virtualized DC implements safeguards by creating a new invocation ID and invalidating the local RID pool. This allows the duplicated domain controller to continue replicating inbound and creating new security principals. However, other duplicate server metadata prevents outbound AD DS and SYSVOL replication from working with current domain controllers in the environment. Only a new domain controller with no previous knowledge of the duplicate DC will allow inbound replication from the duplicate DC.
These steps ensure that no delta of changes is permanently lost, which would happen if you were to simply turn the duplicate DC off and discard it. If you booted the duplicate domain controller and noticed immediately that it was a duplicate, you have the option to shut it down and discard it without performing the steps in this article, but with the realization that any changes made on that duplicate DC - such as recent object creation, password changes, group membership modification - will be permanently lost.
The potential for DC duplication has existed since Windows 2000, but Windows Server 2012 VDC makes it more likely than in previous operating systems. These steps are applicable even if not cloning and simply trying to recover from a duplicate domain controller, either virtual or physical from disk cloning.
Microsoft does not recommend domains with only one DC.
The DSA Working Directory is defined by registry REG_SZ value:
To download the Remote Server Administration Tools for Windows 8, see:
For more information on how to reset the DSRM password, see:
For more information on configuring and troubleshooting VDC with details and step-by-step guidance, see:
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.