Direct Inward Dialing: +1 408 916 9892
Demoting a domain controller (DC) removes the Active Directory Domain Services (AD DS) role from the server and reverts it to a member server or a standalone server. The server stops authenticating users, replicating directory data, and hosting DNS zones integrated with AD.
If you demote the last DC in a domain, the entire domain is removed from the forest. This is irreversible. It deletes all domain-specific objects, trusts, and Group Policy configurations tied to that domain.
There are two paths for demotion. A graceful demotion contacts replication partners, transfers remaining data, and cleanly removes the DC's presence from the directory. A forced demotion bypasses replication entirely and is only appropriate when the DC is offline, corrupted, or cut off from the network.
Here are the most common scenarios:
Complete every check in this table before you start. Skipping any step can cause authentication failures, data loss, or orphaned objects.
| Check | Why it matters | How to verify |
|---|---|---|
| FSMO roles | If the DC holds any FSMO role, that role is lost on demotion unless you transfer it first | netdom query fsmo to list current holders; transfer with Move-ADDirectoryServerOperationMasterRole |
| Replication health | All outbound changes must replicate to at least one partner before the DC goes offline | repadmin /replsummary and repadmin /showrepl |
| DNS zones | The DC may host AD-integrated DNS zones that other DCs don't | DNS Manager or dnscmd /enumzones on the target DC |
| Global Catalog role | At least one other DC in the site must hold the GC role | AD Sites and Services: right-click the NTDS Settings object and check GC status |
| System state backup | A full backup lets you roll back if something goes wrong | Windows Server Backup: wbadmin start systemstatebackup |
| Dependent services | DHCP, Certificate Authority (ADCS), Network Policy Server (NPS), or other roles hosted on this DC need to be migrated first | Services console or Get-WindowsFeature on the target DC |
| Stakeholder notification | Applications and users pointing to this DC's IP address will lose connectivity after demotion | Review DNS A records, DHCP scope options, and GPO-hardcoded server references |
These steps apply to Windows Server 2016, 2019, and 2022.
The server demotes and reboots automatically. After the reboot, log on with the local administrator account to confirm the server is now a member server.
The Uninstall-ADDSDomainController cmdlet gives you a scriptable alternative to the Server Manager wizard.
Validate before demoting:
Test-ADDSDomainControllerUninstallation -LocalAdministratorPassword (Read-Host -Prompt "Set local admin password" -AsSecureString)
This command runs prerequisite checks without making changes. Review the output for warnings before you proceed.
Graceful demotion (standard case):
Uninstall-ADDSDomainController `
-LocalAdministratorPassword (Read-Host -Prompt "Set local admin password" -AsSecureString) `
-Credential (Get-Credential) `
-RemoveApplicationPartitions `
-DemoteOperationMasterRole
| Parameter | Purpose |
|---|---|
| -LocalAdministratorPassword | Sets the local admin password after demotion |
| -Credential | Provides Domain Admin or Enterprise Admin credentials |
| -RemoveApplicationPartitions | Removes application directory partitions hosted on this DC |
| -DemoteOperationMasterRole | Forces transfer of any FSMO roles the DC holds during demotion |
Demoting the last DC in a domain:
Uninstall-ADDSDomainController `
-LocalAdministratorPassword (Read-Host -Prompt "Set local admin password" -AsSecureString) `
-LastDomainControllerInDomain `
-RemoveApplicationPartitions
The -LastDomainControllerInDomain flag removes the entire domain from the forest. Only use this when you intend to delete the domain permanently.
The server reboots after the cmdlet completes. Log on with the local administrator password you set.
A forced demotion is your fallback when the DC can't contact any replication partner. Common scenarios include a DC that's permanently offline, one with corrupted NTDS.dit, or one isolated from the network after a site link failure.
PowerShell (forced):
Uninstall-ADDSDomainController -ForceRemoval `
-LocalAdministratorPassword (Read-Host -Prompt "Set local admin password" -AsSecureString)
Server Manager (forced):
During the Active Directory Domain Services Configuration Wizard, check Force the removal of this domain controller. This skips replication and removes the AD DS role without contacting partners.
Forced demotion does not clean up the DC's metadata in Active Directory. The server object, NTDS Settings object, DNS records, and computer account all remain in the directory until you remove them yourself. If you skip metadata cleanup, replication topology errors, authentication failures, and stale SPN entries will pile up.
After demotion (graceful or forced), complete these cleanup steps to keep the domain healthy.
1. Metadata cleanup (required after forced demotion):
ntdsutil
metadata cleanup
connections
connect to server <working-DC-name>
quit
select operation target
list domains
select domain <number>
list sites
select site <number>
list servers in site
select server <number>
quit
remove selected server
This removes the orphaned NTDS Settings object and server reference from AD.
2. DNS record cleanup:
Open DNS Manager on a remaining DC and remove these records for the demoted server:
3. AD Sites and Services cleanup:
Open AD Sites and Services, navigate to the site that contained the demoted DC, expand Servers, right-click the server object, and select Delete.
4. Group membership and computer object:
Remove the demoted server's computer account from the Domain Controllers OU if it wasn't already moved automatically. Verify it no longer appears in any privileged group membership.
5. Update client configurations:
If clients, DHCP scopes, or application configurations reference the demoted DC's IP address for DNS resolution, update those references to point to a remaining DC.
6. Verify replication health:
repadmin /replsummary
Confirm zero replication failures across all remaining DCs. Failures at this stage point to incomplete cleanup or a topology issue that needs attention.
A botched or unauthorized DC demotion opens real holes in your environment. These aren't theoretical; they show up in post-incident reviews with uncomfortable regularity.
Stale DC objects in AD Sites and Services remain visible to anyone with directory read access. An attacker doing reconnaissance can spot these orphaned objects and identify that the domain has unresolved topology issues. In practice, this usually correlates with weak monitoring across the board.
Orphaned SPN entries left after a failed or incomplete demotion can be exploited through Kerberoasting. When an SPN still points to a service account that ran on the demoted DC, an attacker can request a service ticket for that SPN and crack it offline to recover the service account password.
Lingering NTDS Settings objects confuse the Knowledge Consistency Checker (KCC) and can cause remaining DCs to attempt replication with a partner that no longer exists. This generates repeated failures that flood security event logs and bury genuine replication problems in noise.
Metadata left after forced demotion can make DCShadow attacks easier to pull off. In a DCShadow attack, an adversary registers a rogue DC in AD by manipulating the same directory objects that a poorly cleaned-up demotion leaves behind. Orphaned server objects lower the barrier.
Unauthorized demotion by a compromised admin account removes audit visibility from an entire segment of the domain. If an attacker with Domain Admin credentials demotes a DC, they eliminate that DC's security event logs and reduce the number of replication partners recording changes. You lose eyes on whatever happened there.
ADAudit Plus detects Kerberoasting attempts and DCShadow attacks through its Attack Surface Analyzer. It provides real-time alerts when these techniques target orphaned DC objects or stale SPNs left after an incomplete demotion.
Native Windows tools show you pieces of what happened during a demotion, but they can't give you a centralized, correlated view. Here's where they fall short:
Event Viewer logs are local to each DC. Security events generated during the demotion process exist only on the DC being demoted. Once that server is wiped or repurposed, those logs are gone.
No native real-time alerting on DC removal. Windows doesn't send a notification when a DC is demoted or when its computer account is deleted from the Domain Controllers OU. You find out when you manually check, or when something breaks.
repadmin is a point-in-time snapshot, not continuous monitoring. You can run repadmin /replsummary to check replication health, but it won't alert you when a topology change occurs or when a replication partner disappears.
No correlation between demotion events and downstream impact. Native tools can't connect a DC demotion to the resulting DNS record deletions, GPO link changes, or group membership removals in a single timeline. You piece it together yourself across multiple consoles.
No behavioral baseline for demotion activity. Windows has no built-in way to flag an unusual demotion, like one happening outside a maintenance window or performed by an account that has never touched infrastructure before.
ADAudit Plus captures the full chain of changes that occur when a domain controller is demoted. It correlates them into a single audit trail with the identity of the administrator, the timestamp, and the source machine for every event.
| Capability | Native tools | ADAudit Plus |
|---|---|---|
| Centralized DC change tracking | No (logs stored per DC) | Yes (single console for all domains) |
| Real-time alerts on DC removal | No | Yes (alert profiles with email and SMS) |
| Replication failure detection | Manual (repadmin) | Automated reports with scheduled delivery |
| DNS record deletion tracking | Manual (DNS Manager) | DNS Nodes Removed report |
| Unauthorized demotion detection | No | UBA anomaly detection |
| Historical audit trail | Limited by local log retention | Archived data with schedulable reports |
| Attack detection (Kerberoasting, DCShadow) | No | Attack Surface Analyzer |
Try ADAudit Plus free for 30 days. No credit card required.
The entire domain is removed from the forest. All domain-specific objects (users, groups, computers, GPOs, trusts) are deleted permanently, and the domain's DNS zone is removed. Other domains in the forest lose any trust relationships they held with the deleted domain.
Only proceed with last-DC demotion after you've migrated all accounts and resources to another domain.
Yes. If the DC holds any of the five FSMO roles (Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master), transfer those roles to another DC before demotion. The Uninstall-ADDSDomainController cmdlet with -DemoteOperationMasterRole can force the transfer during demotion, but a planned transfer beforehand is safer because it gives you time to verify the new role holder is working correctly.
A graceful demotion contacts replication partners, replicates any unreplicated changes, and cleanly removes the DC's presence from the directory. A forced demotion skips replication entirely. Use forced demotion only when the DC is offline or can't communicate with any partner.
Forced demotion always requires manual metadata cleanup afterward.
Use ntdsutil with the metadata cleanup command to remove the orphaned server object. Then manually delete the demoted DC's DNS records (A, SRV, NS, and _GC records) and remove the server object from AD Sites and Services.
Yes. After demotion, the server is a regular member server. You can re-promote it by running Install-ADDSDomainController in PowerShell or by adding the AD DS role through Server Manager and running the promotion wizard.
The server receives a fresh copy of the AD database through replication.
