FSMO Role Transfer Failed: A Read-First Owner, Replication, Permission, and Seize-or-Wait Triage

Helpdesk: "DC01 died Saturday night (the vendor says the replacement board won't arrive before Thursday). Since then nobody can create new user accounts on one of the remaining DCs, and a password reset took ages to show up. Someone tried to move the roles to DC02 in Active Directory Users and Computers and got 'The current FSMO holder could not be contacted.' A forum post says to seize all five roles with ntdsutil right now, then just power DC01 back on when the board comes. Can we do that?"

Not that way. "FSMO role transfer failed" usually isn't a broken role. A transfer is a conversation between the current holder and the new one, so it fails whenever the current holder is offline, unreachable, not yet replicated since it last started, or recorded as a server that no longer exists; a seizure skips that conversation, which is why it's a one-way decision about the old DC, not a stronger retry. Microsoft's guidance is blunt about both halves: "Role seizure should be performed only as a last resort", and "Do not allow a former operations master role holder whose role has been seized to return to an online domain controller." Seizing all five roles and then powering DC01 back on is the one combination that page warns about. Microsoft also notes that "FSMO roles assigned to domain controllers that are offline or in an error state only have to be transferred or seized if role-dependent operations are being done", so the first question is which operations are actually failing. Work through it as a chain: which roles, and what's failing because of them → who owns each role, according to more than one DC? → is the current holder online and replicating? → is the target DC the right one? → does your account have the rights for this role? → transfer, wait, or seize? → transfer it properly → seize it properly, only if Step 6 says so → clean up the old DC and the owners that still point at it → prove every DC agrees. netdom query fsmo, Get-ADDomain, Get-ADForest, Get-ADObject on the role objects, dcdiag /test:KnowsOfRoleHolders, repadmin /replsummary, Get-ADReplicationPartnerMetadata, Get-ADDomainController, and whoami /groups are the sources for that chain. Seize every role "to be safe" and you may burn RID space, leave a stale owner in a DNS application partition, and create a duplicate role holder the day the old hardware comes back.

If the role holder can't be reached because replication itself fails with RPC errors, Active Directory Replication Error 1722 covers that side first. If the new PDC emulator now has to become the forest's time source, Windows Time Not Syncing With Domain Controller covers the time chain. This post covers "an operations master (FSMO) role won't transfer, or you're deciding whether to seize it: 'The requested FSMO operation failed. The current FSMO holder could not be contacted.', 0x20AF or 0x20AE from ntdsutil or PowerShell, 'Access is denied' when you try, a role owner that shows a deleted DC, a demotion that can't determine role ownership, or a role holder that died and isn't coming back, and you need a read-first path before you run seize or -Force."

TL;DR

• Transfer needs the old holder; seize doesn't, and that's the risk. Microsoft: "We recommend that you only seize all roles when the previous role holder isn't returning to the domain." (Step 6).
• Read the owners from more than one DC. dcdiag's KnowsOfRoleHolders test "doesn't check all DCs knowledge for consistency", so compare netdom query fsmo and the fSMORoleOwner values from each DC (Step 2).
• A holder that just restarted isn't a holder yet. "The DC waits until it receives inbound replication for its naming context" before acting on a role, and so does a new holder after a transfer (Steps 3 and 10).
• Connect ntdsutil to the new holder, not the dead one. In Microsoft's procedure, the server you connect to "is the name of the DC that you want to assign the Operation Master role to." (Steps 7 and 8).
• Seizing the RID master costs RIDs. "The Move-ADDirectoryServerOperationMasterRole cmdlet increases the next Rid pool by 30,000 from what it finds in Active Directory." (Step 8).
• After a seizure, the old DC never comes back as it was. Clean up its metadata, and rebuild it from scratch if you want it as a DC again (Step 9).

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

Step 2: Read who owns each role, from more than one DC (read-only)

Start with the two quick reads (Microsoft says netdom query must run from an elevated command prompt), then repeat them against the target DC and at least one other DC. Each DC answers from its own copy of the directory:

# The role owners as this computer's DC sees them (Microsoft's netdom query fsmo)
netdom query fsmo

# The same question answered by specific DCs (/server is the DC that performs the query)
netdom query /server:DC02 fsmo
netdom query /server:DC03 fsmo

# Domain roles and forest roles, asked of one DC at a time
Get-ADDomain -Server DC02 | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest -Server DC02 | Select-Object SchemaMaster, DomainNamingMaster

dcdiag has a test for this, but read its scope: KnowsOfRoleHolders "returns the DCs knowledge of the five Flexible Single Master Operation (FSMO) roles but doesn't check all DCs knowledge for consistency. Using the /e parameter provides data for comparison." The similarly named FsmoCheck test isn't the same thing; Microsoft's description ends with "This test does not test any of the servers for operations master roles."

REM Every DC in the enterprise reports what it knows about the five roles; compare the answers
dcdiag /test:KnowsOfRoleHolders /e /v

When the friendly names look wrong, read the raw owner. Each role is an fSMORoleOwner value on one object, and Microsoft's own instruction for a partition's infrastructure master is to "query the fSMORoleOwner attribute on the infrastructure object under the naming context root in question." The same read works for every role object:

# Read-only: the raw owner (an NTDS Settings DN) of every role object, as DC02 sees it
$dc   = 'DC02'
$root = Get-ADRootDSE -Server $dc
$dom  = $root.defaultNamingContext
$fr   = $root.rootDomainNamingContext
$objs = @(
    $dom                                          # PDC emulator (domain head)
    "CN=RID Manager`$,CN=System,$dom"             # RID master
    "CN=Infrastructure,$dom"                      # infrastructure master
    "CN=Partitions,$($root.configurationNamingContext)"  # domain naming master
    $root.schemaNamingContext                     # schema master
    "CN=Infrastructure,DC=DomainDnsZones,$dom"    # DNS application partition (domain)
    "CN=Infrastructure,DC=ForestDnsZones,$fr"     # DNS application partition (forest)
)
foreach ($o in $objs) {
    try {
        Get-ADObject -Identity $o -Server $dc -Properties fSMORoleOwner -ErrorAction Stop |
            Select-Object DistinguishedName, fSMORoleOwner
    } catch { "Not found on ${dc}: $o" }
}

Run it with $dc set to each DC you care about. Read the results like this:

Step 3: Is the current holder online and replicating? (read-only)

A transfer only works when the current holder takes part, and a holder only acts as one after it has replicated. Microsoft's transfer-or-seize article: "When a DC that has been acting as a role holder starts to run (for example, after a failure or a shutdown), it doesn't immediately resume behaving as the role holder." The per-role details are in Microsoft's FSMO roles article: the RID master "is active only when the role owner has inbound replicated the domain NC successfully since the Directory Service started", and the schema and domain naming masters have the same rule for their partitions. The PDC emulator is the exception: "There is no inbound replication requirement."

So read replication for the holder and the target before anything else:

REM Forest-wide summary: which DCs are failing inbound or outbound replication, errors first
repadmin /replsummary /errorsonly

REM Inbound replication status, per partition and partner, for the target and for the holder
repadmin /showrepl DC02
repadmin /showrepl DC01

# Read-only: the target's inbound partners for every partition it holds, with the last result
Get-ADReplicationPartnerMetadata -Target DC02 -Partition * |
    Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess,
        LastReplicationResult, ConsecutiveReplicationFailures |
    Format-Table -AutoSize

# Read-only: replication failures recorded for the target and the holder
Get-ADReplicationFailure -Target DC02, DC01

# Is the holder's name resolving and answering at all? (ICMP can be blocked; this is a hint, not proof)
Test-NetConnection -ComputerName DC01

Microsoft's note on the /showrepl output: "If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection." Then look at the events around the failed attempt on the DC that did the work:

# Directory Service events Microsoft's role articles mention (1586 after a PDC seizure, 2091 in a demotion log)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 1586, 2091
    StartTime = (Get-Date).AddDays(-2)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, Message

# RID issuance events (Microsoft: logged in the System log under Directory-Services-SAM)
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 16642, 16643, 16644, 16645, 16655, 16656, 16657
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, Message

Step 4: Is the target DC the right one? (read-only)

Microsoft's criteria for the new role holder are short: "It resides in the same domain as the previous role holder." and "It has the most recent replicated writable copy of the role partition." Its placement guidance adds: "Place the RID master on the domain PDC in the same domain." and "Place the schema master on the PDC of the forest root domain." The usual answer is a healthy DC in the same site that's a direct replication partner of the old holder. Microsoft's standby-master guidance says to "Ensure that the standby operations masters are direct replication partners of the actual operations masters."

# Read-only: every DC in the domain, its site, and whether it's a GC or read-only
Get-ADDomainController -Filter * |
    Select-Object Name, Site, IsGlobalCatalog, IsReadOnly |
    Sort-Object Site, Name | Format-Table -AutoSize

# Microsoft's single-DC global catalog check (True or False)
(Get-ADDomainController -Filter { Name -Eq 'DC02' }).IsGlobalCatalog

# Is the AD Recycle Bin enabled? (changes whether the infrastructure master matters)
Get-ADOptionalFeature -Identity 'Recycle Bin Feature'

REM Health of the proposed target, verbose
dcdiag /s:DC02 /v

If you need a property that isn't in that list, Microsoft's note on Get-ADDomainController is to pipe one DC to Get-Member and read all of them.

Step 5: Does your account have the rights for this role? (read-only)

Microsoft's current article: "The signed-in user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the infrastructure master roles are being transferred." Its older per-role procedures name Schema Admins for the schema master ("Membership in Schema Admins, or equivalent, is the minimum required to complete this procedure."), so for a schema master move, be in both (our reading).

# Read-only: what the current session's token actually contains (look for the groups above)
whoami /groups

# Read-only: who's in the forest-level groups (ask a forest root DC)
Get-ADGroupMember -Identity 'Schema Admins' -Server DC02 | Select-Object Name, SamAccountName
Get-ADGroupMember -Identity 'Enterprise Admins' -Server DC02 | Select-Object Name, SamAccountName

Step 6: Transfer, wait, or seize? (decision, no changes yet)

This is the step the forum post skips. Microsoft's rules:

• Transfer when "The current role holder is operational and can be accessed on the network by the new Operation Master owner."
• Seize when "The current role holder is experiencing an operational error that prevents an Operation Master-dependent operation from completing successfully, and you can't transfer the role.", after a forced demotion, or when "The operating system on the computer that originally owned a specific role no longer exists or has been reinstalled."
• Wait when you can: "If the role holder can be made operational before the role is needed, you may delay seizing the role." Except for one role: "The PDC role in each domain should always be online."

How much each role can wait, and how bad a duplicate would be (Microsoft's function list and its replication-island table):

Then decide:

Before a seizure, Microsoft also asks for patience: "do not perform a role seizure until enough time has passed to complete at least one end-to-end replication cycle across your network." The more of the old holder's last changes reach the target, the less you lose.

Step 7: Transfer it properly (a change)

Only when Step 6 says transfer. In PowerShell, -Identity is the DC that gets the roles; Microsoft: "The Identity parameter specifies the directory server that receives the roles." The cmdlet doesn't have to run on either DC: it "can be remotely executed from any domain joined computer where the Active Directory module for Windows PowerShell administration module is installed and available for use."

# Preview, then move the three domain roles to DC02 (Domain Admins of that domain)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -WhatIf
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

# The two forest roles (Enterprise Admins; Schema Admins as well for the schema master)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole SchemaMaster, DomainNamingMaster

# Only have the FQDN? Microsoft's Example 5: resolve it with Get-ADDomainController first
$Server = Get-ADDomainController -Identity "dc02.contoso.com"
Move-ADDirectoryServerOperationMasterRole -Identity $Server -OperationMasterRole PDCEmulator

That last pattern matters: "There is a known issue where the Move-ADDirectoryServerOperationMasterRole cmdlet fails when an FQDN is specified directly as the value of the Identity parameter."

With ntdsutil, run it on the DC that will receive the roles (Microsoft's recommendation), connect to that DC, then transfer. Microsoft's syntax is transfer <role>; type ? at the fsmo maintenance: prompt to see the exact role names your version accepts:

C:\> ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC02
server connections: q
fsmo maintenance: ?
fsmo maintenance: transfer pdc
fsmo maintenance: transfer rid master
fsmo maintenance: transfer infrastructure master
fsmo maintenance: q
ntdsutil: q

The consoles do the same thing, one role at a time, as long as you point them at the target DC first:

Step 8: Seize it properly, only if Step 6 says so (a change)

A seizure is a decision about the old DC, so make it once and write it on the ticket. Microsoft's older procedure explains the risk: "If two domain controllers are performing the same operations master role simultaneously, the severity of the effect from duplicate operations master roles varies, depending on the role that was seized. The effect can range from no visible effect to potential corruption of the Active Directory database."

On the target DC, in an elevated prompt, connect ntdsutil to that DC (Microsoft: "If ServerFQDN does not succeed, use the NetBIOS name of the DC."), then seize. The seize commands are Microsoft's; note the two exceptions: "Exceptions are for the PDC emulator role, whose syntax is seize pdc, and the Domain naming master, whose syntax is seize naming master."

C:\> ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server DC02.contoso.com
server connections: quit
fsmo maintenance: seize pdc
fsmo maintenance: seize rid master
fsmo maintenance: seize infrastructure master
fsmo maintenance: seize naming master
fsmo maintenance: seize schema master
fsmo maintenance: quit
ntdsutil: quit

Seize only the roles the dead DC held (from Step 2), not every role in the forest. Expect ntdsutil to try a transfer first: "When you use Ntdsutil.exe to seize an operations master role, the tool first attempts a transfer from the current role owner." You'll see a transfer error and then the seizure. For the RID master, Microsoft adds that the target "tries to synchronize with a replication partner before accepting this role", and if it can't, "a dialog box appears asking you whether you want to continue with the operation despite this computer not being able to synchronize with a partner. Click Yes."

The PowerShell equivalent is the Step 7 command with -Force. Microsoft: "This operation still attempts graceful transfer first, then seizes if transfer is not possible."

# Seize only the roles the dead DC held (Microsoft's Example 4 form, with this post's role list)
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -Force

Know what a RID master seizure costs before you run it. Microsoft: "Rid Master seizures increment the next available RID in the pool when you seize the RID master role." The amount depends on the tool: "The Move-ADDirectoryServerOperationMasterRole cmdlet increases the next Rid pool by 30,000 from what it finds in Active Directory." and with ntdsutil "it increases the next Rid pool by 10,000." Microsoft's conclusion: "So seize the Rid Master only when you're sure that the current Rid Master can't be brought back into service." A domain has "capacity for roughly one billion security principals", so one seizure is affordable; a habit of seizing isn't (our reading). Microsoft's read of the remaining pool:

REM Microsoft's form: the available RID pool for the domain, from the RidManager test
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

Step 9: Clean up the old DC and every owner that still points at it (a change)

After a seizure, the old DC doesn't get its old life back. Microsoft's options for it: format and reinstall, or forcibly demote it, then remove its metadata from another DC; "After you clean up the metadata, you can repromote the computer to a DC, and transfer a role back to it." Restoring it from a backup is the wrong rebuild: "If you plan to use the repaired computer as a DC, we recommend that you rebuild the computer into a DC from scratch instead of restoring the DC from a backup." When the board in the opener arrives, keep DC01 off the network until it's reinstalled or demoted (our reading).

Metadata cleanup. Microsoft: "Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS)." The GUI way is to delete the DC's computer object from the Domain Controllers OU in Active Directory Users and Computers and select "This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO)". If it still holds roles, that dialog moves them to a DC it picks: "You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure." The command-line way, connected to a replication partner of the removed DC (Microsoft: "This domain controller must be a replication partner of the removed domain controller."):

C:\> ntdsutil
ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server DC02
server connections: quit
metadata cleanup: remove selected server DC01
metadata cleanup: quit
ntdsutil: quit

If cleanup says "Access is denied", Microsoft's note is to "make sure that the computer object and the NTDS Settings object for the domain controller are not protected against accidental deletion." Afterward, Microsoft's check is that the DC is gone from the Domain Controllers OU and that its server object in Sites and Services no longer has an NTDS Settings object.

DNS application partition owners. Rerun the Step 2 read for CN=Infrastructure,DC=DomainDnsZones,... and CN=Infrastructure,DC=ForestDnsZones,.... If either still names a deleted owner, demotions and adprep /rodcprep fail later. Microsoft's resolution: "Use ADSIEDIT.MSC to assign the DN path for the fsMORoleOwner attribute to a live DC that was a direct replication partner of the original FSMO role owner." or run the script in its adprep article, cscript fixfsmo.vbs DC=DomainDnsZones,DC=contoso,DC=com (and again for ForestDnsZones), copied from that article, not retyped.

Time. If the PDC emulator of the forest root moved, the time source moved with it. Microsoft: "The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source." Microsoft's w32tm /config example for a manual peer list, plus its /reliable:YES option ("This setting is only meaningful on domain controllers."), with your own time servers in place of its example names:

REM On the new forest-root PDC emulator (Microsoft's example peer names; use your own)
w32tm /config /manualpeerlist:"ntpserver.contoso.com clock.adatum.com" /syncfromflags:manual /reliable:YES /update

REM On a former PDC that's still a DC (transfer case): follow the domain hierarchy again
w32tm /config /syncfromflags:domhier /update

Windows Time Not Syncing With Domain Controller covers checking that chain afterward. The PDC emulator is also Microsoft's "Default target domain controller for Group Policy updates.", so Group Policy edits now land on the new holder; if they don't show up on clients, Group Policy Not Applying covers that path. Microsoft's placement article also notes that NTDS Replication event 1586 occurs when "the PDC FSMO role for a particular domain has been seized.", so expect it after a PDC seizure.

Step 10: Prove every DC agrees (read-only)

A new holder doesn't start work the moment the command returns. Microsoft: "After a role transfer or seizure, the new role holder doesn't act immediately." It waits for a successful inbound replication cycle of the role's partition, and "To have full effect, the change must replicate to all domain controllers in the domain for a domain-level role and to all domain controllers in the forest for a forest-level role."

# Every DC's answer, not just the one you're signed in to
Get-ADDomainController -Filter * | ForEach-Object {
    $n = $_.Name
    $d = Get-ADDomain -Server $n
    $f = Get-ADForest -Server $n
    [pscustomobject]@{
        AskedDC = $n
        PDC     = $d.PDCEmulator
        RID     = $d.RIDMaster
        Infra   = $d.InfrastructureMaster
        Schema  = $f.SchemaMaster
        Naming  = $f.DomainNamingMaster
    }
} | Format-Table -AutoSize

REM The same check, the dcdiag way, plus RID master health and replication
dcdiag /test:KnowsOfRoleHolders /e
dcdiag /test:RidManager /v
repadmin /replsummary

Microsoft's ntdsutil view of the connected DC's roles is roles > connections > connect to server DC02 > quit > select operation target > list roles for connected server.

Pass criteria (our reading): every DC names the same live holder for every role, the Step 2 fSMORoleOwner read (including both DNS application partitions) shows no deleted owner, repadmin /replsummary shows no failures, dcdiag /test:RidManager passes, and the operation from the ticket (creating an account on the DC that couldn't, a password reset, a Group Policy edit) works. Then close the ticket with the decision from Step 6 written down.

Common false starts

When a change is justified

FAQ

What's the difference between transferring and seizing FSMO roles?
A transfer moves a role with the current holder's cooperation, so nothing is lost; Microsoft recommends it when "The current role holder is operational and can be accessed on the network by the new Operation Master owner." A seizure assigns the role without the old holder, so it's for a holder that isn't coming back, and that old DC must not return as it was (Steps 6-8).

Why does FSMO role transfer fail with "The current FSMO holder could not be contacted"?
The DC doing the work couldn't get the current holder to take part: it's offline, unreachable from that DC, or it restarted and hasn't completed inbound replication for the role's partition yet. Read replication for the holder and the target with repadmin /replsummary and repadmin /showrepl before you think about seizing (Steps 3 and 6).

Can I bring the old domain controller back after seizing its roles?
Not as it was. Microsoft: "Do not allow a former operations master role holder whose role has been seized to return to an online domain controller." Reinstall it or force-demote it, clean up its metadata, then promote it fresh if you want it back as a DC (Step 9).

Why does seizing FSMO roles say "Access is denied"?
Usually the account isn't in the group the role needs (Schema Admins for the schema master, Enterprise Admins for the domain naming master, Domain Admins for the domain roles), the membership was added after you signed in, or the prompt isn't elevated. Check whoami /groups in the same window (Step 5). During metadata cleanup, it can also mean the objects are protected from accidental deletion (Step 9).

How do I seize FSMO roles with PowerShell?
Use Move-ADDirectoryServerOperationMasterRole with -Identity set to the DC that receives the roles, -OperationMasterRole listing only the roles the dead DC held, and -Force. It "still attempts graceful transfer first, then seizes if transfer is not possible." For the RID master, it raises the next RID pool by 30,000, three times what ntdsutil does (Step 8).

Related posts

• Active Directory Replication Error 1722 (when the role holder can't be reached because replication fails with RPC errors)
• Windows Time Not Syncing With Domain Controller (when the new forest-root PDC emulator has to become the time source)
• The Target Principal Name Is Incorrect (when the holder and the target fail Kerberos between them)
• Group Policy Not Applying (when policy edits stall after the PDC emulator moves)

Free checklist

Seizing all five roles before anyone read who owns them, or whether the old DC is coming back, is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=fsmo-role-transfer-failed

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=fsmo-role-transfer-failed

Admin Pack Studio; not affiliated with Microsoft. Steps 1-6 and 10 are read-only checks: netdom query, Get-ADDomain, Get-ADForest, Get-ADRootDSE, Get-ADObject, dcdiag, repadmin /replsummary and /showrepl, Get-ADReplicationPartnerMetadata, Get-ADReplicationFailure, Test-NetConnection, Get-WinEvent, Get-ADDomainController, Get-ADOptionalFeature, whoami /groups, and Get-ADGroupMember. Transferring or seizing roles, editing fSMORoleOwner, metadata cleanup, demoting or rebuilding a DC, changing group membership, and changing the time configuration are deliberate changes. Change one link at a time, prove it from every DC, and check current Microsoft Learn for version-specific behavior.