DC promotion, demotion and metadata cleanup

Identify the stage that failed

Installing AD DS binaries doesn’t make a server a DC. It still needs promotion, a restart, initial replication and readiness to advertise usable services. Even after the directory service starts, SYSVOL or the GC may still be waiting. Check which stage completed before deciding what failed.

Start with the intended operation: additional writable DC, staged RODC, new domain/forest, replacement or demotion. Keep the parameters, selected site/source DC, credentials used by role, error and time window. Repeatedly adding bypass switches makes it harder to understand the original failure. Microsoft’s deployment troubleshooting methodology.

Validate prerequisites against the intended operation

For an additional DC, check the target’s DNS/locator path, source replication health, time, required role-holder access, supported OS/functional-level combination, permissions, local paths/free space and pending restart/name changes. The correct source is a healthy replica of the required domain, not simply the nearest responding LDAP server.

On the future DC, with AD DS deployment tools available, an illustrative prerequisite test is:

$deploymentCredential = Get-Credential
Test-ADDSDomainControllerInstallation -DomainName 'contoso.com' `
    -Credential $deploymentCredential -InstallDns -SiteName 'Sydney' `
    -ReplicationSourceDC 'dc1.contoso.com'

Use the existing site and intended options; the test can prompt for DSRM credentials. It checks prerequisites without promoting the server. Install-ADDSDomainController -WhatIf instead describes proposed changes. A passing check only tells you the prerequisites were met at that time; connectivity can still fail later. Test-ADDSDomainControllerInstallation.

The installation cmdlet runs prerequisite checks normally. -SkipPreChecks is not a remedy for their failure, and -AllowDomainControllerReinstall is not permission to collide with an existing live DC identity. For a staged RODC, use the parameter set for the precreated account rather than redundantly supplying incompatible options. Installation parameters.

Check schema preparation and functional levels separately from OS installation. New-DC promotion can perform applicable adprep work with the required credentials; in-place OS upgrades have their own preparation path. Use migration and upgrade planning and the current functional-level matrix instead of copying an old forest-preparation sequence.

Preserve the deployment logs by phase

The Microsoft log map distinguishes these stages. Read back from the final rollback message to find the earlier failure, its extended error and the affected partner. A [warning] or [error] label on its own won’t explain the outcome.

For a bounded local event query:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-DirectoryServices-Deployment/Operational'
    StartTime = (Get-Date).AddHours(-4)
} | Select-Object TimeCreated,Id,TaskDisplayName,LevelDisplayName,Message

Prerequisite checks log in this channel, including event 103 under the Core task. Keep full messages because successive checks can share an event ID. AD DS prerequisite-checking architecture.

IFM reduces the seed, not the need for replication

Install From Media supplies initial directory data to reduce network transfer. The new replica still needs the live directory, authentication and subsequent replication. You can’t use it to deploy an independent offline copy or turn a stale backup into the current domain.

Create media for the intended target OS/version and writable/RODC role using the documented tooling; verify the exact compatibility before transporting it. Writable media and RODC media are different products even when a writable source DC is used to generate them. ntdsutil has explicit create full, create rodc and SYSVOL variants; the IFM command reference documents those distinctions.

Put the media on the target’s local disk and protect it as sensitive directory material. The deployment troubleshooting guide documents failures with remote UNC paths and incompatible media types. An integrity check alone won’t tell you whether the media is compatible or live replication will work. Record its source domain, source DC/build, creation time and intended role, and how it will be handled and disposed of.

The installation reference separates -InstallationMediaPath from -ReplicationSourceDC. If seeding works and live replication fails, investigate DNS, authentication, the actual RPC endpoints and source state rather than recreating the same media repeatedly. Include database format in compatibility planning for 32 KB capable deployments.

Prove readiness after the required restart

After the documented promotion completes and the server restarts, query the intended replica explicitly:

repadmin /showrepl dc-new.contoso.com
dcdiag /s:dc-new.contoso.com /test:Advertising /test:Services /test:SysVolCheck /v
dcdiag /s:dc-new.contoso.com /test:DNS /v

Check the expected naming contexts, initial SYSVOL synchronization, actual SYSVOL/NETLOGON access and intended GC readiness. Then test a client/application from the network that will use the DC. DC health explains what readiness flags and these tests establish. Do not set SysvolReady or disable initial synchronization merely to make the new server appear available.

A parent-zone delegation warning needs a closer look at the DNS design. Find out which server is authoritative for the parent and whether clients need that delegation. A first forest and a child domain integrated into existing DNS have different requirements. The warning also tells you nothing about whether internal DNS registration and locator tests passed.

Demote deliberately while partners can cooperate

Before graceful removal, find the applications targeting this DC, its DNS/GC dependencies, hosted application partitions, FSMO roles and other services. Replace the capacity you’ll lose and confirm the changes have replicated. Check whether it’s the last DC, last relevant writable replica or last DNS server for a zone. Each of those changes what removal will do.

Demote through ADDSDeployment or the supported wizard before removing the AD DS binaries, then complete the required restart. Direct DISM removal of AD DS from a functioning DC is unsupported and can leave it unable to boot normally. The demotion workflow distinguishes directory demotion from subsequent role removal.

Test-ADDSDomainControllerUninstallation can run prerequisite checks for the intended operation. The actual Uninstall-ADDSDomainController is a directory/server change, with a local Administrator credential needed for the resulting member/standalone server. Parameters such as -LastDomainControllerInDomain, -RemoveApplicationPartitions and -IgnoreLastDnsServerForZone encode consequential choices; they are not generic switches for dismissing errors. Demotion procedure and uninstallation parameters.

A CA on the DC needs its own inventory and supported migration/recovery plan before changing roles. Do not remove an issuing CA as a prerequisite workaround without preserving its identity and dependencies. See CA continuity.

Forced removal leaves work for the surviving directory

Forced demotion is for a DC that can’t cooperate with its partners during removal. It can discard unreplicated changes and leaves server metadata to clean up. Treat the DC as permanently removed, plan any role recovery and keep the old installation from returning as a functioning DC. If connectivity is only temporarily broken, fixing it and demoting gracefully may be the better option.

Modern AD Users and Computers can perform metadata cleanup when deleting the permanently offline DC’s computer account. In Sites and Services, the documented automatic cleanup requires deleting its NTDS Settings first. A generic server-object delete or arbitrary ADSI edit is not the same procedure. Metadata cleanup also handles replication connections and attempts role transfer/seizure, so verify the resulting ownership. Supported metadata cleanup.

After cleanup replicates, check that the DC account/NTDS Settings are gone, then check the remaining topology, relevant DNS/delegation records and clients with explicit targets. If other child objects remain beneath the Sites and Services server object, find out what uses them before deleting the parent. Finish by checking replication between the surviving DCs and the client operations that depended on the removed server.