Cleanup
The following tasks can help you to clean up Active Directory after you move it to the destination computer.
Resetting the DC Shared Secret
Every domain controller (DC) has a shared secret that it shares with the other domain controllers to establish a secure channel for inter-DC communication in order to replicate Active Directory changes between DCs.
If there are other domain controllers in the domain, and if more than 60 days have elapsed, you might need to reset the shared secret with the other domain controllers. The symptom of a lapsed shared secret are replication errors with the error message Access denied or Failed to authenticate.
Understanding the DC Shared Secret
It helps to understand how the DC shared secret works and how it is stored. The following is an overly-simplified explanation. (For a more complete explanation see Detailed Concepts: Secure Channel Explained and Machine Account Password Process on the Microsoft Directory Services Team Blog.)
The DC shared secret is used to establish a secure communication channel between two domain controllers for the purpose of replicating Active Directory. Every DC has a machine account in Active Directory, which is basically just another user account. (The difference is that the machine account represents the entire machine, not just one person.)
For example, a DC with the DNS name dc02.acme.local will have a corresponding user account in Active Directory named dc02$. (The dollar sign indicates a hidden user account.)
Let's assume that the DC named pdc01.acme.local wants to pull replication data out of dc02.acme.local. (Remember, all replication in Active Directory is done via pull-replication.)
First, Pdc01 consults its own local copy of AD to fetch the password hash for dc02$. If then connects to Dc02 with the user account dc02$ and the password hash. Dc02 compares the supplied password hash with its own master copy in its private registry, at HKEY_LOCAL_MACHINE\Security\Policy\Secrets\$MACHINE.ACC. The registry value contains both the current password hash (CurrVal) and the prior password hash (OldVal). If either one matches, the connection is allowed. If not, access is denied and the error is reported in the Event Log for Directory Services on Pdc01, and a security audit failure event is generated in the Event Log on Dc02.
By default, a new password hash is renegotiated every 30 days (MaximumPasswordAge in Group Policy), which copies CurrVal to OldVal and replaces CurrVal with the new password hash. The password attribute in the AD object CN=dc02$ is changed to match CurrVal, and the change is replicated to all domain controllers in the domain.
Example
Let's assume that you used U-Move to restore a domain controller named Dc02 using an old backup snapshot (.BKF file) that was created more than 60 days ago. Dc02's registry gets restored along with its private copy of Active Directory. The restored password hash in $MACHINE.ACC on Dc02 is now three generations old. When Pdc01 next attempts to connect to dc02, Dc02 will reject the password hash in CN=Dc02$ (on Pdc01) because it matches neither CurrVal nor OldVal, and so access is denied. This prevents Pdc01 from pulling replication data from Dc02.
Similarly, when Dc02 attempts to pull replication data from Pdc01, the restored AD object CN=Pdc01$ (in Dc02's out-of-date copy of AD) will match neither CurrVal nor OldVal on Pdc01, so Dc02 cannot pull the replication data from Pdc01. Pull replication fails in both directions.
First Step: Verify Network Connectivity
Before attempting to reset the DC shared secret, make sure that the restored DC has network connectivity to the other DCs. In particular, make sure that ping works.
Select one of the other DCs and try to ping it. (Use the DC with the Primary Domain Controller FSMO role if you can.)
On the newly restored DC, open an administrative console and type,
ping pdc01.acme.local
where pdc01.acme.local is the fully qualified domain name (FQDN) of the Primary Domain Controller in the domain. If this fails you have a basic network connectivity problem. You need to fix that first. See Troubleshooting a Remote Connection.
Reset the DC Shared Secret (Restored DC)
On the newly restored DC (Example: Dc02), run the Netdom console utility to reset its machine account password:
netdom resetpwd /server:pdc01.acme.local ↵
/UserD:ACME\Administrator /PasswordD:*
where Administrator is the name of a user account on Pdc01 that has administrator privileges to change the passwords of other users, and ACME is the name of the domain.
The command Netdom resetpwd will do following:
- Write the new random password hash to $MACHINE.ACC in the registry of the local computer (Dc02) as CurrVal. The prior password hash is moved to OldVal.
- Update the AD object CN=Dc02$ on Pdc01 with the new password hash (using the supplied logon credentials).
- Update the AD object CN=Dc02$ on the local computer (Dc02) with the same new password hash (for local loopback connections).
This will allow Pdc01 to connect to Dc02 to pull replication data from Dc02. Pdc01 will replicate the new password to all of the other DCs in the domain, allowing them all to also connect to Dc02.
Note: In rare cases you might also need to stop and restart the Kerberos Distribution Center (KDC) service. See How to use Netdom.exe to reset machine account passwords of a Windows Server domain controller.
Reset the DC Shared Secret (Primary DC)
Next, you need to reset Pdc01's shared secret so that Dc02 can pull replication data in the reverse direction. On the primary DC (Pdc01), run the Netdom console utility to reset its machine account password:
netdom resetpwd /server:dc02.acme.local ↵
/UserD:ACME\Administrator /PasswordD:*
The command Netdom resetpwd will do following:
- Write the new random password hash to $MACHINE.ACC in the registry of the PDC (Pdc01) as CurrVal. The prior password hash is moved to OldVal.
- Update the object CN=Pdc01$ on Dc02 with the new password hash (using the supplied logon credentials).
- Update the object CN=Pdc01$ on the local computer (Pdc01) with the same new password hash (for local loopback connections).
This will allow Dc02 to connect to Pdc01 to pull replication data from it. Other DCs can still connect to Pdc01 using the old password hash (in $MACHINE.ACC OldVal). They will receive an update with Pdc01's new password hash via normal replication.
Eventually the new password hash in CN=Pdc01$ will replicate to all of the other DCs in the domain.
Foreign Trusts and Inter-Domain Trusts
The shared secret for inter-domain trusts and foreign trusts operates logically the same way using a Trusted Domain Object (TDO) instead of a user logon account. Only PDCs can exchange the shared secrets across domain boundaries. If your domain has a trust relationship with another domain you can use Active Directory Domains and Trusts (domain.msc) to reset the trust relationship, or you can you can use the console utility netdom trust. See Netdom trust (Microsoft Docs) and How Domain and Forest Trusts Work (Microsoft Docs).
Uninstall U-Move
When you are satisfied that Active Directory is working OK you can delete the staging folder and uninstall U-Move.
| U-Move for Active Directory |
