You are currently offline, waiting for your internet to reconnect

DC cloning fails with no DSRM, duplicate source and clone computer

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:
  • The DSA Working Directory 
  • %systemroot%\NTDS
  • Removable read/write media, in order of drive letter, at the root of the drive

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:
  • - "New/existing domain controller" - A non-duplicated DC that exists in the environment already or was promoted as part of this KB article's repair work
  • - "Original source domain controller" - The DC that was copied to make a clone
  • - "Duplicate domain controller" - The DC that was supposed to clone from the original DC but is now another identical copy

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:

bcdedit.exe /set safeboot dsrepair shutdown.exe /s /t 0

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:

shutdown.exe /r /t 0

3. Pause the Netlogon service on the duplicate domain controller using the following sample command:

sc.exe pause netlogon

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 <duplicate DC name> +DISABLE_INBOUND_REPL

For example:

repadmin.exe /options +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 <new DC name> 
For example:

repadmin.exe /showrepl 

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

For example:

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 <new/existing DC name> <Duplicate DC DSA GUID> <naming context> /statistics

For example:

repadmin.exe /showchanges dc1.corp.contoso.com5d083398-4bd3-48a4-a80d-fb2ebafb984fdc=corp,dc=contoso,dc=com

repadmin.exe /showchanges 

repadmin.exe /showchanges 

repadmin.exe /showchanges 

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:

Bcdedit.exe /deletevalue safebootShutdown.exe /r /t 0

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 
<duplicate DC name> 

For example:

repadmin.exe /options -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.

More information
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:

HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\ParametersDSA Working Directory

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:

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Article ID: 2742970 - Last Review: 09/05/2012 08:18:00 - Revision: 6.0

  • Windows Server 2012 Datacenter
  • Windows Server 2012 Standard
  • KB2742970
> <\/script>"); ms.js" '="">