How to Seize FSMO Roles From Dead Domain Controller

9.5K

This guide explains how to seize an FSMO role from a failed domain controller in Active Directory.

Quick note on FSMO roles

The Flexible Single Master Operations (FSMO) roles are critical components of an Active Directory environment. If a domain controller (DC) that is holding one or more of the five FSMO roles becomes permanently unavailable, the administrator should seize the FSMO role from the original failed DC to another healthy DC.

A simple AD lab with two domain controllers is used in this demonstration:

• DC1 — is a failed domain controller that’s the current owner of all FSMO roles.
• DC2 — the additional domain controller to which we’ll forcefully reassign the FSMO roles.

The administrator account that is used to seize the FSMO role must be a member of the following Active Directory security groups:

FSMO Role	Administrator must be a member of
Schema Master	Schema Admins
Domain Naming Master	Enterprise Admins
RID Master	Domain Admins
PDC Emulator
Infrastructure Master

If necessary, add your Admin account to these groups.

FSMO Roles: Transferring vs. Seizing

The two ways to reassign FSMO roles are transfer and seize. Both methods ultimately move the FSMO roles to another DC.

• Role transferring — is used for the planned demotion of a domain controller (for example, when you decommission a server) or when a DC is temporarily disconnected while performing maintenance tasks. Used when both source and destination DCs are online and healthy.
• Role seizing — should only be used in the event of a complete server failure where recovery is impossible. The source DC is not available in this case.

Microsoft recommendation to seize FSMO role

Microsoft recommends to seize FSMO role in the following situations:

• The DC server has crashed due to an unrecoverable physical hardware or software/OS problem (and you do not have an up-to-date backup of this DC to perform a non-authoritative ADDS restore ).
• The previous Operation Master role holder has been removed using the forceremoval option of Uninstall-ADDSDomainController or the deprecated dcpromo command.
• The Windows Server OS on the DC no longer exists or has been reinstalled.

In short, you can gracefully move (transfer) FSMO roles from one working DC to another or forcefully grab (seize) the FSMO roles from a dead DC.

Important note! Seize the role only if the previous role holder will never come back online and reconnect to the domain. Otherwise, it will cause serious problems in Active Directory. Note that once a role has been seized, the original DC must never be returned to the domain without being rebuilt/properly demoted.

Determine FSMO Roles Owners in AD

Use one of the following commands to list the domain controllers in the forest:

## Using PowerShell
Get-ADDomainController -Filter * | Select-Object `
HostName, Site, OperatingSystem

## Using DSQUERY
dsquery server -forest

Now find the current FSMO role owners in domain:

netdom query fsmo

Before seizing an FSMO role, you should verify that the target DC is healthy and has no unresolved AD replication/DNS problems. Make sure you have a current, supported backup of the DCs and that you understand the available AD DS recovery options. AD Recycle Bin can help recover deleted directory objects, but it is not a substitute for a DC/System State backup.

To check the overall AD health and replication status, run the following:

dcdiag /v
repadmin /replsummary
repadmin /showrepl DC2

Then you need to check that the target DC is a writable DC and review its site, Global Catalog status, and current FSMO roles:

Get-ADDomainController -Identity DC2 |
Select-Object HostName, Site, IsGlobalCatalog, OperatingSystem, OperationMasterRoles

Windows Server 2025 environments may use either an 8K/32K-capable AD database, depending on how the DC was deployed and whether the optional 32K database page feature has been enabled. Note that the database page size does not change the FSMO seizure procedure.

There are two domain controllers in this forest. And we know that DC1, which holds all five FSMO roles, is dead. This makes DC2 our candidate for the new FSMO role.

Note. If you try to run the FSMO role check using dcdiag /test:FSMOcheck command, you will get an error:

The server holding the PDC role is down.

Windows Server 2025 and 32K database pages. Windows Server 2025 introduces support for 32K database pages in AD DS, but not every Server 2025 DC uses the 32K format by default. The 32K database feature is optional and forest-wide, and it does not change the FSMO seizure procedure. Before enabling it, you need to ensure all DCs in the forest are 32K-capable and meet Microsoft’s requirements.

How to Seize FSMO Roles From a Failed Domain Controller

You can seize FSMO roles in three ways — PowerShell, NTDSUTIL, and Active Directory Users and Computers (ADUC) console.

Check for a recoverable backup first. Before seizing an FSMO role, you need to confirm that the failed DC cannot be recovered using a recent, valid system-state backup. If the DC can be restored using a supported AD DS recovery procedure, recovery may be preferable to seizing its FSMO roles. If the DC cannot be recovered and will remain permanently offline, you should proceed with FSMO seizure.

Seize FSMO Roles with PowerShell

The Move-ADDirectoryServerOperationMasterRole PowerShell cmdlet is the easiest way to seize FSMO roles from a dead DC (this is a built-in Active Directory module cmdlet).

Log on to the domain controller (DC2) and open an elevated PowerShell console. To seize one FSMO role, specify the target DC name and the role name (or its number). For example:

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole SchemaMaster -Force

Or

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole 3 -Force

Or you can seize all the roles at once:

Move-ADDirectoryServerOperationMasterRole `
-Identity DC2 `
-OperationMasterRole `
PDCEmulator,
RIDMaster,
InfrastructureMaster,
SchemaMaster,
DomainNamingMaster `
-Force

If there are no errors or output on the screen, the FSMO role move operation has been completed successfully.

To verify the new FSMO role owners, use the following PowerShell commands:

Get-ADDomain | Format-List PDCEmulator, InfrastructureMaster, RIDMaster
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

For a quick consolidated check of all five FSMO roles, you can also use:

netdom query fsmo

Seize FSMO Roles using ADUC

It is possible to seize the FSMO roles using the graphical Active Directory snap-ins. It is a fairly simple and intuitive way, but it takes longer compared to PowerShell.

Note that this method performs metadata cleanup and role seizure simultaneously. It is less granular than PowerShell because you can’t seize individual roles.

Log on to the domain controller that will be the new FSMO roles owner (DC2) and open the ADUC console (dsa.msc).

Click the Domain Controllers Organizational Unit (OU) and look for the failed domain controller (DC1). Right-click the failed DC and click Delete.

When asked to confirm the deletion, click Yes.

You’ll receive a warning that you’re deleting a domain controller without running the removal wizard. But since we’re removing a dead domain controller, check the box to Delete this Domain Controller anyway and click Delete.

Click Yes to confirm the deletion of this domain controller.

The deletion will detect that DC1 is the owner of the FSMO roles. If the deleted DC owned FSMO roles, Active Directory will prompt you to seize and reassign those roles during the cleanup process.

Once DC1 is deleted, right-click the domain and click Operations Masters.

Now, click through each tab (RID, PDC, and Infrastructure) and confirm that the operations master is DC2.

Next, open the Active Directory Domains and Trusts console. Click Action → Operations Master.

Confirm that DC2 is now the Domain Naming operations master.

Now, let’s check the Schema Master role. Run the below command in an elevated PowerShell window to register the Active Directory Schema Management console:

regsvr32 schmmgmt.dll

Next, open MMC and add the Active Directory Schema snap-in.

Right-click the Active Directory Schema node → Operations Master. Confirm the DC2 is the current schema master.

Using the GUI, you’ve successfully seized the FSMO role from a failed domain controller.

Alternative Legacy Method Using NTDSUTIL

NTDSUTIL is a legacy AD management tool that is still supported in modern Windows Server versions. However, Microsoft and enterprise admins now commonly prefer PowerShell cmdlets for FSMO seizure and metadata cleanup tasks (they are easier to automate, less error-prone, and better suited for modern admin workflows). You should use NTDSUTIL primarily for compatibility/advanced troubleshooting.

Open PowerShell or command prompt as admin and run the ntdsutil command.

Next, enter each command below.

roles
connections
connect to server DC2
q

Run the below command to seize the Schema master FSMO role:

seize schema master

You will be prompted to confirm the role seizure. You will be prompted to confirm the seizure operation. Click Yes.

Repeat the seizure process for the remaining FSMO roles as needed:

seize naming master
seize infrastructure master
seize rid master
seize pdc

Keep in mind that the NTDSUTIL tool remains useful for compatibility and advanced recovery cases, but you should prefer PowerShell for most FSMO role seizure tasks.

Post-Seizure Validation Tasks

After you’ve successfully seized the FSMO roles, here are some post-cleanup tasks you must do.

1. Verify that metadata cleanup for the failed DC is complete. If you used Active Directory Users and Computers and selected Delete this Domain Controller anyway, metadata cleanup is normally performed as part of that operation. In case the failed DC was removed using Remove-ADDomainController -ForceRemoval, keep in mind that force removal does not clean the DC’s metadata from the remaining domain controllers. You need to verify the cleanup and remove any remaining metadata using Active Directory Sites and Services or the documented metadata cleanup procedure. Do not bring the old DC back online after its FSMO roles have been seized. If the server is still required as a DC, you should rebuild it and promote it again.
   

   

2. Make sure you delete the DNS records pointing to the removed DC. These DNS records can be removed automatically by DNS Scavenging, or you can remove them manually using the DNS Manager console.

   

3. After seizing the FSMO roles, review the Directory Services and DNS logs in Event Viewer and check AD replication health using the following commands:
   
   dcdiag /v
   repadmin /replsummary
   repadmin /showrepl
   Resolve-DnsName yourdomain.local
   
   # Check replication failures on all DCs
   # This checks for recorded replication failures on each DC in the domain
   Get-ADDomainController -Filter * | ForEach-Object {
   Get-ADReplicationFailure -Target $_.HostName
   }
   
   In case the PDC Emulator role was seized, you need to verify that the new FSMO role holder is correctly functioning as the domain time source:
   
   w32tm /query /status
   w32tm /query /configuration
   w32tm /monitor
   
   Don’t forget to verify that the new PDC Emulator is syncing time correctly and advertising itself as a reliable time source for the domain.

If the RID Master role was seized, you should check if the new role holder can allocate RID pools correctly and that no RID-related errors are reported:

dcdiag /test:ridmanager /v

Note that seizing an FSMO role from a failed DC is a critical task that must be performed carefully. It should be used as a last resort if a domain controller holding an FSMO role fails and cannot be restored.

AD CS considerations. In case the failed DC also hosted an Enterprise CA, FSMO seizure does not recover the Certificate Authority. You should treat the CA as a separate recovery task and follow Microsoft’s AD CS recovery procedure to restore/migrate the CA (including its database, private key, config, and CRL publishing).

Hybrid identity environments

If the domain is synced with Microsoft Entra ID, you need to check that Microsoft Entra Connect Sync continues to communicate with a healthy DC after the failed DC is removed. A failed DC does not normally require reconfiguring the Entra Connect connector, but you should verify sync health and connector connectivity.

If sync fails because the connector or its AD DS connection still depends on the failed DC, you need to update the connector config to use a healthy DC and run a sync cycle.

Verify Global Catalog availability

If the failed DC was hosting the Global Catalog role, you need to make sure that another DC is configured as a Global Catalog server.

You can check GC status with the following command:

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

If no Global Catalog server is available, you should enable the Global Catalog option on an appropriate DC using Active Directory Sites and Services. Make sure at least one healthy DC remains available as a Global Catalog server.