How to Transfer (Seize) AD FSMO Roles Using PowerShell

9.2K

This guide explains how to transfer or seize FSMO roles between domain controllers using PowerShell.

What Are FSMO Roles in Active Directory?

When deploying a new Active Directory domain, all 5 FSMO roles are assigned to the first domain controller in the forest root domain. After adding the second and subsequent DCs, the domain administrator can move one or more AD operation master roles from one domain controller to another.

Supported Windows Server Versions

The PowerShell commands in this guide apply to modern Windows Server versions, including Windows Server 2019, 2022, and 2025, with the Active Directory PowerShell module installed. For older Windows Server releases, you need to check the available ActiveDirectory module and cmdlet parameters before using the examples.

Methods to Move FSMO Roles

There are two ways to move FSMO roles between domain controllers:

• Role transfer — if both source and target DCs are online and healthy, an FSMO role can be gracefully transferred to a new owner. Role transfer is used when it’s necessary to maintain (upgrade) the DC’s hardware and/or software, change the DC’s IP address, demote the DC, etc.
• Role seizing — emergency process during which you are forcibly assigning FSMO roles from a permanently unavailable/failed DC to another DC. Keep in mind that seizing should only be performed when the original FSMO role holder cannot be recovered.

Check FSMO Role Holders in Active Directory

Before moving or seizing FSMO roles, you need to ensure that the Active Directory PowerShell module is installed and available. On Windows Server, it is provided by the AD DS/RSAT management tools. On Windows client systems, install the RSAT: Active Directory Domain Services and Lightweight Directory Services Tools feature.

Run PowerShell/Windows Terminal with elevated privileges and use an account with the permissions required for the FSMO operation. Note that Schema Master and Domain Naming Master operations require forest-level admin privileges, while the domain-level FSMO roles require appropriate domain-level admin permissions.

PowerShell 7 compatibility

The ActiveDirectory PowerShell module is natively compatible with PowerShell 7 on supported modern Windows versions, including Windows Server 2019, Windows Server 2022, Windows Server 2025, and Windows 10/11 1809 and later, provided the required RSAT Active Directory tools are installed.

In PowerShell 7, import the module normally:

Import-Module ActiveDirectory

You can check if the module is available with the following command:

Get-Module ActiveDirectory -ListAvailable

Check your PowerShell version with:

$PSVersionTable.PSEdition
$PSVersionTable.PSVersion

In case the AD module cannot be loaded natively in a particular environment, you can use the Windows PowerShell compatibility layer:

Import-Module ActiveDirectory -UseWindowsPowerShell

This compatibility option is primarily a fallback for environments where the native PowerShell 7 module cannot be loaded. On current supported Windows Server versions, it should not be necessary for normal AD administration.

Using Get-ADDomain Cmdlet

Check the three domain-level FSMO role owners in the current AD domain:

Get-ADDomain | select InfrastructureMaster, PDCEmulator, RIDMaster

Using Get-ADForest Cmdlet

Then find two FSMO owners at the AD-forest level:

Get-ADForest | select DomainNamingMaster, SchemaMaster

Using Netdom Query

Or use the netdom command to check how FSMO roles are assigned in your AD:

Note that netdom.exe is included with the AD DS/AD LDS management tools. It is available by default on a DC with the AD DS role installed; on administrative workstations, you need to install the appropriate RSAT AD DS/AD LDS tools first.

netdom query fsmo

In our example, m-dc01 holds all five FSMO roles.

Check Active Directory Replication Health

Note that before transferring/seizing FSMO roles, you need to check if the AD replication is healthy across all DCs. To check replication summary, run the command:

repadmin /replsummary

Run a full DC diagnostic test:

dcdiag /e /c /v

In case there are unresolved replication/DNS issues in the domain, you should not transfer or seize FSMO roles!

Note that many FSMO transfer failures are actually caused by DNS misconfig/replication problems. You need to ensure that all DCs use only internal AD DNS servers and can resolve each other correctly.

Verify Time Synchronization

Kerberos authentication and AD replication depend on accurate time sync between DCs.

To check time source and sync status, use the following command:

w32tm /query /status

In order to verify time config, run the command:

w32tm /query /configuration

Large time drift between DCs can cause FSMO transfer failures and replication errors.

Validate the Target DC

Before transferring FSMO roles, you should verify if the target DC is healthy and reachable.

You need to check that the target DC:

• Is online and reachable over the network
• Has no replication errors
• Is writable (not RODC)
• Is properly registered in DNS
• Is synced with the domain
• Is configured as a Global Catalog server when appropriate

You can check DC status with:

Get-ADDomainController -Identity dc2

To verify if the DC is writable, run the command:

Get-ADDomainController -Identity dc2 | Select HostName,IsReadOnly

To check whether the DC is a Global Catalog:

Get-ADDomainController -Identity dc2 | Select HostName,IsGlobalCatalog

Keep in mind that you should never transfer FSMO roles to an unhealthy/partially replicated DC.

Transfer FSMO Roles Using PowerShell

The Move-ADDirectoryServerOperationMasterRole cmdlet is used to gracefully transfer FSMO roles between Active Directory domain controllers.

Specify at least two necessary parameters as arguments of the cmdlet:

• -Identity the target DC to transfer the FSMO role
• -OperationMasterRole — one or more FSMO roles to move to the target DC

FSMO Role Names and Numeric Values

The following table shows the names of the FSMO roles and their corresponding numerical values. The user account that runs the role transfer must be a member of the administrative groups:

FSMO role	Numeric value	Required AD Privileges
Schema Master	3	Schema Admins
Domain Naming Master	4	Enterprise Admins
RID Master	1	Domain Admins
PDC Emulator	0	Domain Admins
Infrastructure Master	2	Domain Admins

Infrastructure Master Considerations. Note that in multi-domain forests, the Infrastructure Master role should not be placed on a DC that is also a Global Catalog server (unless all DCs in the domain are Global Catalogs).

Schema Master Considerations. Keep in mind that you should be especially careful when transferring/seizing the Schema Master role (because schema-related operations affect the entire forest).

Use the command to check your user’s AD group membership:

Get-ADPrincipalGroupMembership jbrion | Select name

Add an account to the required administrative groups. If the account doesn’t have the required administrative permissions, an Access Denied error will occur when the role is transferred.

Example: Transfer PDC Emulator Role

For example, to transfer the PDC Emulator role to a domain controller named dc2, use the command (you can run this command from any DC):

Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole PDCEmulator

Or replace the role name with its numeric value:

Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole 0

Transferring Multiple FSMO Roles at Once

It is possible to transfer several operation master roles at once:

Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Or the same but shorter command:

Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole 0,1,2,3,4

Press Y > Enter to confirm the role transfer. To skip the confirmation, you can add the –Confirm:$false parameter to the command.

Confirming Successful Role Transfer

Use the Get-ADForest and Get-ADDomain cmdlets to verify that the operation master role transfer completed successfully.

Post-Transfer Validation

After transferring FSMO roles, you should perform the following:

• You need to verify AD replication health
• Check Event Viewer for Directory Service errors
• Confirm that clients can authenticate normally
• Verify SYSVOL/NETLOGON accessibility
• Make sure that DNS replication completed successfully

Useful commands for these steps:

repadmin /replsummary

dcdiag /test:replications

Seizing FSMO Roles Using PowerShell

When to Seize FSMO Roles

If the current FSMO role holder is non-operational, you’ll get an error when attempting to transfer the role from DC:

The transfer of the operation master role cannot be performed because: The requested FSMO operation failed. The current FSMO role holder could not be contacted.

The directory service is unavailable

In this case you can seize the role to another DC. Role seizing should only be used in the event of catastrophic failure, when the operation master DC crashes or goes down for an extended period.

PowerShell Command for Role Seizing

The -Force parameter attempts a graceful transfer first and performs a seizure only if the transfer fails. You should use it only when the current FSMO role holder is permanently unavailable. Here is an example:

Move-ADDirectoryServerOperationMasterRole `
-Identity DC02 `
-OperationMasterRole PDCEmulator `
-Force

For planned maintenance, you should transfer the role normally without -Force.

Risks After Seizing FSMO Roles

The old FSMO role holder should never be brought back online after the seize process is complete. There will be conflicts and inconsistencies in the ADDS if the old domain controller is connected to your infrastructure.

Keep in mind that you should not restore old DC snapshots/VM checkpoints after FSMO role seizure. Restoring outdated AD DS snapshots may cause USN rollback, replication corruption, and serious AD inconsistencies.

RID Master Seizing Warning

Note that you should be especially careful when seizing the RID Master role. In case the old RID Master later comes back online, you can face duplicate SID allocation problems in the domain.

After seizing the RID Master role, you must ensure that the old DC is permanently removed from the environment and never reconnects to the network.

Performing Metadata Cleanup After Seizing FSMO Roles

If the failed DC is permanently offline, you need to perform metadata cleanup from a surviving writable DC. You can use Active Directory Users and Computers, Active Directory Sites and Services, or ntdsutil. Replace DC02 with the name of a surviving writable DC and DC01 with the name of the failed DC:

ntdsutil
metadata cleanup
connections
connect to server DC02
quit
remove selected server DC01
quit
quit

This removes stale DC metadata and replication references associated with the failed DC.

Verify DNS and AD Cleanup

After seizing FSMO roles and performing metadata cleanup, you need to check that no references to the failed DC remain.

Check DNS for stale A/AAAA and AD-related SRV records (especially under _msdcs):

Resolve-DnsName old-dc.domain.com

Remove stale DNS records if they still exist.

Also check if the failed DC’s NTDS Settings and computer object were removed by metadata cleanup. If they remain, you need to remove them using Active Directory Users and Computers/Active Directory Sites and Services as appropriate.

Do not remove DNS records or AD objects until you have confirmed that the old DC will not return to the domain!