How to Safely Demote a Domain Controller Before Decommissioning

Demoting a domain controller is usually straightforward. The part that deserves most of the attention happens before you click Demote.

A domain controller may be doing much more than authenticating users and replicating Active Directory. It might also be providing DNS, holding FSMO roles, acting as a Global Catalog, providing NPS or DHCP, hosting file shares, running certificate services, or supporting an application somebody configured years ago and forgot about.

A clean demotion removes the server from Active Directory properly and lets the remaining domain controllers take over its directory responsibilities. A forced removal is different. It’s a recovery procedure, not the normal way to decommission a DC.

The workflow:

1. Find out what the DC is responsible for
2. Make sure another DC can provide those services
3. Check Active Directory and replication health
4. Move FSMO roles if necessary
5. Fix DNS and time dependencies
6. Demote the DC normally
7. Verify AD, DNS and client authentication afterwards
8. Only perform metadata cleanup if the normal demotion didn’t complete

Find out what the server actually does

Before checking replication or moving FSMO roles, establish what the server is doing.

At a minimum:

• Active Directory Domain Services
• DNS Server
• Global Catalog
• FSMO roles
• DHCP
• NPS/RADIUS
• Active Directory Certificate Services
• File and print services
• Azure AD Connect or Microsoft Entra Connect
• Scheduled tasks and scripts
• Backup and monitoring agents
• Any application with the server name or IP configured

This matters most in older environments. A server that started life as a domain controller tends to accumulate other roles.

Demoting a DC does not move DHCP, NPS, file shares or certificate services anywhere. Those have to be migrated separately.

Check installed roles:

powershell

Get-WindowsFeature | Where-Object Installed

Check the DC’s own attributes:

powershell

Get-ADDomainController -Identity "DC01" |
    Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

And see what’s listening, with the process names resolved:

powershell

Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort,
        @{N='Process';E={(Get-Process -Id $_.OwningProcess).ProcessName}} |
    Sort-Object LocalPort

Without that calculated property you get process IDs, which tells you very little. From an elevated command prompt, netstat -abno gives the same picture with executable names.

The point isn’t to remove every service you find. It’s to know what disappears when the server does.

Find out who is actually using it for LDAP

“Applications using LDAP” appears on every decommissioning checklist, and it’s the item people guess at. There’s a better way than guessing.

Enable LDAP interface events logging on the DC a week or two before the planned demotion:

powershell

Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" `
    -Name "16 LDAP Interface Events" -Value 2

That writes LDAP client activity to the Directory Service event log. Event 2887 in particular reports the number of unsigned and clear-text LDAP binds, and the associated detailed events identify the connecting clients.

Leave it running long enough to catch monthly and weekly jobs, not just daily ones. A backup job that only runs on the first Sunday of the month won’t appear in three days of logging.

Set the value back to 0 when you’re finished, because verbose LDAP logging is noisy.

This turns a checklist item into evidence. It tells you which clients are actually binding to this DC rather than which ones you remember configuring.

Check Active Directory health first

Don’t use a demotion to try to clean up an already unhealthy directory.

text

repadmin /replsummary

text

dcdiag /v

Not every line of dcdiag needs to be perfect, but replication failures, DNS problems and unexplained errors should be understood before removing a DC.

Troubleshooting a two-DC environment is much easier than discovering after the demotion that your remaining DC wasn’t replicating properly.

Check what AD currently knows about:

powershell

Get-ADDomainController -Filter * |
    Select-Object HostName,Site,IPv4Address,IsGlobalCatalog

If you expected three healthy DCs and the output says otherwise, stop and investigate.

Check FSMO roles

The five roles:

• PDC Emulator
• RID Master
• Infrastructure Master
• Schema Master
• Domain Naming Master

Current holders:

powershell

Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster

If the DC being removed holds any of these, transfer them first.

-Identity is the destination, not the source

This catches people out.

In Move-ADDirectoryServerOperationMasterRole, -Identity specifies the DC that will receive the role. It is not the DC you’re retiring.

So if DC01 is going and DC02 is staying:

powershell

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
    -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

The numeric equivalents also work:

powershell

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
    -OperationMasterRole 0,1,2,3,4

Verify afterwards:

powershell

Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster

Transfer, don’t seize. Seizure is for a DC that’s already gone.

-DemoteOperationMasterRole is not an automatic transfer

This is worth being explicit about, because the name suggests otherwise.

-DemoteOperationMasterRole does not transfer FSMO roles for you.

It allows the demotion to proceed even though the server holds FSMO roles. Those roles then have to be seized onto another DC afterwards, which is a worse position than transferring them cleanly beforehand.

It belongs in a forced-removal scenario. For a planned retirement, move the roles first and verify them.

The PDC Emulator and time

If the DC being removed holds the PDC Emulator role, time synchronisation needs attention.

The PDC Emulator in the forest root domain is the authoritative time source for the forest unless another reliable source has been configured.

After transferring the role, check the Windows Time configuration on the new holder:

text

w32tm /query /configuration
w32tm /query /status
w32tm /query /peers

If your environment uses an external NTP source, configure the new PDC to use it.

The FSMO role moved. The server’s Windows Time configuration did not move with it.

That’s a common oversight, and the symptom is a forest gradually drifting until Kerberos starts failing.

Check DNS before touching the DC

Is the DC running DNS?

powershell

Get-WindowsFeature DNS

Check the zones, and make sure another DNS server can answer for the AD-integrated ones.

More importantly, check the DNS client settings on the remaining domain controllers.

If DC02 points at DC01 as its only DNS server, removing DC01 creates an entirely avoidable problem.

powershell

Get-DnsClientServerAddress -AddressFamily IPv4

Run that on every remaining DC and on any infrastructure that depends on the retiring server for resolution. Also check DHCP scope options and any statically configured clients.

Test the AD DNS configuration:

text

dcdiag /test:DNS /v

If the retiring DC is the only server providing a particular zone, delegation or forwarder, fix that dependency first.

Check Global Catalog coverage

powershell

Get-ADDomainController -Filter * |
    Select-Object HostName,IsGlobalCatalog,Site

If the DC being removed is a Global Catalog, make sure another suitable DC provides that service.

This matters most in multi-site environments. The goal isn’t just having another GC somewhere in the domain. It’s having directory services available where clients and applications actually need them.

Check AD Sites and Services

Open Active Directory Sites and Services and look at the server object, NTDS Settings, replication connections, site membership and the associated subnet.

Good opportunity to confirm the remaining DCs are correctly placed in the expected sites.

Don’t start deleting objects manually. A successful demotion handles the directory removal itself.

Take a backup

A system state backup before a significant AD change is sensible.

It isn’t a substitute for checking the environment first. It’s a layer of protection if something unexpected happens.

If you use a third-party backup platform, confirm you have a usable recovery point rather than assuming the server showing as “protected” means anything.

Demote the domain controller

Once the dependencies are handled, the demotion itself is the easy part.

Server Manager

Manage → Remove Roles and Features

Select the local server and clear Active Directory Domain Services.

Because the server is a domain controller, Windows won’t simply remove the binaries. The wizard offers Demote this domain controller instead.

Read the warnings rather than clicking past them. The wizard identifies DNS, Global Catalog and operations master roles on the server, which is telling you what disappears when the DC goes.

You’ll be prompted to set a new local Administrator password, because after demotion the server is a member server with its own local accounts again.

If the server is the last domain controller in the domain, stop and confirm that’s actually what you intend. That’s an entirely different operation.

PowerShell

powershell

Uninstall-ADDSDomainController -Credential (Get-Credential)

Microsoft’s Uninstall-ADDSDomainController documentation covers the full parameter set.

Two practical notes.

-LocalAdministratorPassword is optional. Omit it and you’re prompted to set and confirm the password interactively. That’s fine when you’re sitting at the console, but a script that omits it will stall waiting for input. For automation:

powershell

$pw = Read-Host -AsSecureString -Prompt "New local Administrator password"
Uninstall-ADDSDomainController -LocalAdministratorPassword $pw -Credential (Get-Credential)

-Credential is only needed if you aren’t already logged on with sufficient rights. Domain Admins for a replica DC, Enterprise Admins for the last DC in a domain.

The server restarts as part of the normal process. -NoRebootOnCompletion exists but Microsoft recommends allowing the restart.

For a planned demotion I wouldn’t add -Force just to make it unattended. Let the validation and confirmation run.

Forced demotion is a different thing

-ForceRemoval is for a DC that can’t contact its replication partners and where there’s no reasonable way to fix that.

A forced removal doesn’t replicate the DC’s final directory changes to its partners. It leaves cleanup work behind:

• FSMO role seizure
• DNS cleanup
• Computer account cleanup
• Sites and Services cleanup
• Global Catalog verification
• Application partition considerations
• Replication verification

It isn’t a shortcut for a normal retirement.

Verify Active Directory afterwards

Give replication a little time, then:

text

repadmin /replsummary
dcdiag /v

powershell

Get-ADDomainController -Filter * |
    Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

The retired DC should no longer appear.

Test discovery from a client

This is the check I wouldn’t skip, because it tests the thing users actually depend on.

From a domain-joined workstation:

text

nltest /dsgetdc:yourdomain.local

That asks DC Locator to find a domain controller now.

text

echo %LOGONSERVER%

These answer different questions. nltest /dsgetdc performs current discovery, while %LOGONSERVER% reflects the DC recorded at logon and can be stale. I’ve covered that distinction in more detail in how to find the domain controller you’re authenticated to.

Then force a policy refresh:

text

gpupdate /force

A client that discovers a remaining DC, authenticates and applies policy is much better evidence than a computer object having disappeared from an OU.

Check DNS records

After the demotion, look for references to the old server:

• A records
• PTR records
• SRV records
• CNAME records
• Delegations
• Conditional forwarders

Don’t blindly delete every record containing the server name. Verify what each one is for.

AD-integrated DNS data replicates between remaining DNS servers, so check more than one if you have multiple sites.

Metadata cleanup is not a routine step

If the demotion succeeded, you shouldn’t need:

text

ntdsutil
metadata cleanup

That’s a recovery procedure for a DC that was forcibly removed or disappeared without a successful demotion.

Since Windows Server 2008, deleting the computer object of a permanently offline DC from the Domain Controllers OU in Active Directory Users and Computers performs the metadata cleanup automatically. Manual ntdsutil is rarely necessary now.

Metadata cleanup modifies Active Directory directly. It shouldn’t be something you run because you’ve finished a successful demotion.

Post-demotion checklist

Active Directory

text

repadmin /replsummary
dcdiag /v

Confirm: replication healthy, FSMO roles on the intended servers, Global Catalog coverage correct, Sites and Services clean, no unexpected errors.

DNS

Confirm: remaining DCs use working DNS servers, AD zones available, SRV records correct, clients resolve the domain, no stale records causing problems.

Client authentication

text

nltest /dsgetdc:yourdomain.local
gpupdate /force

Time

On the new PDC Emulator:

text

w32tm /query /status
w32tm /query /configuration
w32tm /query /peers

Applications and infrastructure

Confirm DHCP still works, NPS/RADIUS authentication works, LDAP applications work, certificate services remain available, file shares have been migrated or retired deliberately, monitoring and backup jobs aren’t still targeting the old server, and network devices referencing the old IP have been updated.

Finally

Don’t reuse the IP address immediately. Leave it unassigned for a while so anything still pointed at it fails visibly rather than reaching an unrelated server.

The sequence matters

Don’t start with the demotion wizard.

Start by asking what the server is responsible for. Then check AD health, replication, DNS, Global Catalog availability, FSMO roles and time. Check what else is running on the machine and move anything that needs to survive.

Once the dependencies are dealt with, do a normal demotion and let Windows remove the DC cleanly.

Then verify from both sides: repadmin and dcdiag on the remaining DCs, and actual discovery and authentication from a client.

The distinction worth holding onto is between planned demotion and forced removal. A planned demotion leaves the directory clean. Forced removal is what you reach for when the normal process isn’t possible, and it comes with cleanup attached.

References

• Uninstall-ADDSDomainController – the full parameter set including forced removal
• Move-ADDirectoryServerOperationMasterRole – FSMO transfer, and why -Identity is the destination

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.