Best Practice: Demoting a Domain Controller

Demoting a Domain Controller KB ID 0001932

Problem

I was having a conversation with some colleagues this week, the conversation was about the placing of an RDS license server, and somebody had recommended putting it on the domain controller, I pointed out that this wasn’t a perfect idea, because in four or five year’s time somebody’s going to demote and take that to my controller off-line and forget all about the fact that it’s running RDS licensing. Therein lies the problem: while it’s pretty easy to demote a domain controller, then remove it from the domain, and then turn it off. Problems usually occur because the domain controller is doing something else, for example, it’s a DNS server for a site, or it’s handling LDAP requests from a firewall for remote access VPN logins, etc.

So here are a few steps to take before deeming a DC.

If something jumps up (post demotion) that bites you, please post below to save someone else from your heartache.

Solution: Demoting a Domain Controller

Common Sense Check: You are about to change something on your infrastructure; make sure you have reliable backups (and your backup solution is ‘domain aware’). Then take some time to document what the server is doing, what roles have been installed, and what software is on that server. Simply taking this step will shine a light on things you would have ordinarily forgotten, and more importantly, when everything bursts into flames and there’s a problem, you can recover quickly and more completely.

Domain Checks: Demoting a Domain Controller

FSMO Roles: Make sure your DC is not currently holding any FSMO roles, and if it is those roles are transferred to another healthy DC before it is demoted. See the following articles.

Windows Server – Locating, Transferring, and Seizing FSMO Roles

Replication Status: Ensure that the server has a healthy domain replication with its neighbouring domain controllers (repadmin /replsummary).

If there are problems, follow the following article.

Domain Replication Issues – Fix Replication Issues

Global Catalogue Status: Is the server a global catalogue server? There should be one GC per site (well, per site that has users). So if you are retiring this DC, then there needs to be a DC left behind afterwards that is a GC server (unless you are removing the site, of course). If not, then authentication traffic will traverse the site links (which is not a good design). The following command will list ALL the global catalogue servers.

Get-ADDomainController | Select-Object Name,IsGlobalCatalog

DCDIAG: The next most important check is the general health of the domain controller itself. To check this, use dcdiag, (or dcdiag /v for a more detailed response).

Roles & Role Services: Each DC will (at least) be running DNS services, and possibly DHCP, The following command will list all the roles and services that have been installed, for you to remove and investigate before thinking about demotion.

Get-WindowsFeature | Where-Object {$_.Installed -eq $true}

Third Party Applications: This can be a tricky one; you can do a search using Get-WMIObject, but it can be a bit hit and miss. The best way is to interrogate the registry and look for x64 and x32 bit applications. Use the following script.

$paths = @(
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*",
"HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

External Dependencies: These are the trickiest to locate, and (in all honesty) are the ones you usually find post demotion when something stops working. I’ve been at this for a few years, and here are some examples of things I’ve found in the past.

• Other Domain Controllers: Each DC should look to itself first for DNS, then have a second DC listed (preferably in the same AD site) as a secondary DNS server. If your other DCs are still pointing to the DC that is going to be retired, then that needs to be changed MANUALLY on each DC.
• DHCP scopes on other servers are still sending the (soon ot be retired) DC as a DNS (or even WINS in this day and age!) Server.
• Static IP devices are still pointing to the DC either for authentication, DNS lookups, or LDAP lookups. e.g. Other servers and clients on the network, printers/multifunction devices, MFA appliances (RSA SecureID, Duo appliances), Security systems (Firewalls, CCTV, Door lock control, ID Card scanners).
• Microsoft Applications, Microsoft Exchange famously loves getting its claws into a domain controller. Or SQL servers set to domain authentication.
• RADIUS or LDAP/LDAPS devices that are hard-coded to this domain controller.
• Wi-Fi controllers or clients are possibly hard-coded to this DC.
• VoIP systems.
• Monitoring tools (Solarwinds, PRTG, or Cacti).
• NAS Devices (or SAN controllers).

Note: If anyone can post below something that has tripped them up, I’ll add it to the list!

Tools that May Assist : Demoting a Domain Controller

Audit LDAP: Open the registry (regedit), then navigate to.

HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > NTDS > Diagnostics

Find the key “16 LDAP Interface Events”. Set its value to 2 (verbose logging).

• 0: No logging
• 1: Minimal
• 2: Verbose (recommended)

To view the output: Go to Applications and Services Logs > Directory Service > Look for Event ID 2889 (LDAP binds) and Event ID 4624 (network logons)

Audit DNS: Open DNS Manager. > Right-click the server name > Properties > Go to the Debug Logging tab > Enable Log packets for debugging and select:

• Queries
• Responses
• Incoming/outgoing packets

You can view the log at  %systemroot%\System32\dns\DNS.log

In addition, you can use tools like Wireshark to see what is talking to your DCs.

Additional Best Practice:  Demoting a Domain Controller

• Never force-remove a DC without trying a clean demotion first.
• Ensure at least one other DC is online and healthy before removing.
• Communicate with teams before removing a DC, especially if it hosts other services like DHCP, Certificate Services, or Exchange.
• Document the changes for future audits.

Demoting a Domain Controller

Once you are happy, you have a proven working backup, and you’ve documented everything. THEN you can demote the domain controller.

Should I snapshot it? (to be safe): NO! Suddenly having domain controllers appearing back on a network they have been gracefully removed from can cause problems. Go on your favourite AI/LLM and ask about ‘SID bubbles’ and ‘USN rollback’ problems associated with snapshots of domain controllers if you don’t believe me.

Using Server Manager (Preferred if Server is Accessible) >Open Server Manager > Manage  >Remove Roles and Features > Uncheck “Active Directory Domain Services” and follow the wizard to demote the DC >Provide credentials and confirm removal.

Using PowerShell: Use the following command (see the link below for options ands switches)

Uninstall-ADDSDomainController

Related Articles, References, Credits, or External Links

Uninstall-ADDSDomainController