How to fix ADDS already contain a computer account
In this blogpost, we will learn how to fix ADDS already contain a computer account. This issue can occur after a swing migration, such as the one outlined in “Build a New DC vs Swing Migration: Upgrade Server OS Correctly“. Replacing a Domain Controller (DC) hardware is one of those tasks that looks simple but can quickly become catastrophic if done incorrectly. Please, see Active Directory: How to Setup a Domain Controller, and How to add a second Domain Controller.
Active Directory is not just another application. It is a distributed database, a security boundary, and the identity backbone of the entire environment.
Upgrading Domain Controllers (DCs) while retaining the same IP addresses is a common practice in environments where static IPs are hardcoded into applications, printers, or networking equipment. Most times, this will lead you to performing a swing migration which I recommend against or performing a DC in-place upgrade, or rebuilding a new Domain Controller (DC) which is the recommended best practice. If you performed a swing migration or perform in-place upgrade, you might encounter this error.
Microsoft’s recommended method for upgrading a Domain Controller’s operating system involves provisioning a new server with the desired operating system (OS), promoting it to a Domain Controller (DC) within the existing domain, transferring FSMO roles (if applicable), verifying replication, and then gracefully demoting the old DC.
My take away, do not perform a swing migration or in-place upgrade. A simple rebuild is better as discussed here (Reddit), Silverpchu, and here (Microsoft).
Why this happens “ADDS already contain a computer account”?
As you can see below, we already had a DC with the name that has been removed from the Domain but not correctly demoted with the server object named TECHDC02 in Active Directory with the command below.
netdom computername TempDC /makeprimary:TechDC02.techdirectarchive.comSo, netdom would not let the alternate name become the primary name. In other words, the name was already reserved somewhere in AD metadata, even if we thought the server had been remove via the forceful DC removal via Sites and Services.
Note: netdom checks AD for duplicate names before it renames the computer. Since TechDC02 already exists as a server object in Active Directory Sites and Services. The rename is blocked to avoid creating a duplicate identity.
Please see AZURE Kubernetes Service (AKS) upgrade minor version from 1.32.3 to 1.33.7, Service Principal Name: How to add or reset and delete SPNs, and Specify user account name when adding a DC to an existing Forest.
Cleanup Stale Metadata
To perform some cleanup, I will launch Active Directory Site and Services. Then, navigate to Sites and then Servers. As you can see, there is a lingering DC with the name TechDC02 which we are currently having issues with. I will proceed and have them removed.
Removal of DCs in progress.
For a quick test, I will want to test AD replication. As you can see, we only have one DC left and the result should support this argument for a single DC with the below query.
The below commands shows every naming context on TECHDC01 syncing successfully. This means there are no replication errors to another partner in the current state (Syncall finished with no erros).
repadmin /sync /AdeP
DC Alternate Name and Rename to fix ADDS already contain a computer account
Now that we have removed all lingering meta data and no replication issue for TechDC01. We will have an alternate name for the second DC “TechDC02”. We should be able to without issues this time as we have removed the lingering data.
netdom computername TempDC /makeprimary:TechDC02.techdirectarchive.comThe /enumerate flag lists the names currently registered on that server. This way, you can confirm the rename state before and after /makeprimary and /remove flag as the case maybe.
netdom computername TempDC /enumerateNote: If /enumerate does not show the new name after /add, then /makeprimary will fail because the name is not yet registered as an alternate name. That is the safest way to check whether AD still has a conflicting object or whether the rename is progressing correctly.
To change the DC name during a swing operation. You have to run the command below but replacing with your FQDN or servername.
netdom computername TempDC /makeprimary:TechDC02.techdirectarchive.comAs you can see, after cleaning up the meta data and removing the duplicate name. We are able to rename the DC from TempDC to TechDC02 as the primary name.
Note that this process requires a reboot to complete the change. You can employ any of the arious ways on Wuindows Server to perform a restart. Here I will be using the command below since I am already on the Termainal (Comamnd Prompt/PowerShell).
Also see Video Conversion Desktop Software for Windows, How to Reset a Cisco 3650 Catalyst Switch, and how to reset and reinstall Windows 10 locally.
FAQs
Why is it better to offload DNS and DHCP from a domain controller?
Offloading DNS and DHCP reduces the DC’s role as a critical network dependency. Clients no longer rely on the DC for name resolution, so AD replication, logons, and GPO processing continue without interruption. This makes DC replacements or rebuilds much safer and easier.
Do I need to reuse the old DC’s hostname or IP when replacing it?
It depends on where DNS is hosted:
–> External DNS: No, you don’t need to reuse the old hostname or IP. New DCs automatically register their DNS A and SRV records, and clients dynamically resolve DCs via _ldap._tcp.dc._msdcs.domain.local. Functionality remains intact even with different hostnames or IPs.
–> DC-hosted DNS: Yes, reusing the old hostname or IP may be necessary temporarily. Many servers and applications rely on static DNS entries pointing to the old DC. Replacing it with a new hostname or IP can cause resolution issues until DNS replication and updates fully propagate. Careful planning is required to avoid service disruptions.
How does external DHCP help during a DC transition?
External DHCP servers that dynamically update DNS records ensure clients always have valid name resolution. This eliminates dependency on the DC for DNS updates and maintains DNS integrity even while promoting, demoting, or rebuilding domain controllers.
Does separating DNS/DHCP improve security or stability?
Yes. Running DNS and DHCP externally isolates network services from authentication tasks. DCs can focus solely on Active Directory operations, reducing load, minimizing update impacts, and allowing easier patching or rollback without affecting client connectivity.
I hope you found this article on how to fix ADDS already contain a computer account very useful. Please feel free to leave a comment below.
