The Flexible Single Master Operations (FSMO) roles are critical components of an Active Directory domain controller. They are responsible for managing various operations within the domain, including creating and deleting objects, schema updates, and domain renaming.
If a domain controller holding an FSMO role fails, it is crucial to seize the role quickly to avoid disruption to the domain.
This blog post will discuss how to seize an FSMO role from a failed domain controller in Active Directory. We will provide step-by-step instructions and highlight important things to watch out for during the process.
This tutorial will demonstrate the examples using two domain controllers.
- DC1.theitbros.local – The failed domain controller who’s the current owner of all FSMO roles.
- DC2.theitbros.local – The additional domain controller to which we’ll forcefully transfer the FSMO roles.
Apart from that, your administrator account must be a member of the following Active Directory groups:
- Domain Admins
- Schema Admins
FSMO Roles: Transferring vs. Seizing
The two ways to reassign FSMO roles are transfer and seize. Both methods ultimately transfer the FSMO roles to another DC.
- Transfer — 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.
- Seize — used when the physical server has failed (and you do not have an up-to-date Active Directory backup of this DC to perform a non-authoritative restore of Active Directory Domain Services) or Windows Server is faulty; or after you have forcibly demoted a domain controller to a member server.
In a gist, you can gracefully move (transfer) FSMO roles from one working DC to another or forcefully grab (seize) the FSMO roles from a dead DC.
Determine the FSMO Roles to Owner
Note. The AD PowerShell cmdlets are available in the Active Directory module 2.0 or newer on domain controllers with Windows Server 2008 R2 or higher.
Suppose DC1 goes kaput, and you must transfer the FSMO roles it holds to another domain controller. Having FSMO roles on different domain controllers is common. So you must confirm which FSMO roles the dead server holds.
First, let’s list the domain controllers in our environment.
# List all DCs ## Using PowerShell Get-ADDomainController -Filter * | Select-Object ` HostName, Site, OperatingSystem ## Using DSQUERY dsquery server -forest
As you can see below, this forest has two domain controllers. And we know that DC1 is dead. So that makes DC2 our candidate as the new FSMO role owner.
Next, list the FSMO roles owner using the commands below.
# List FSMO Roles owners ## Using PowerShell Get-ADDomain | Select-Object PDCEmulator, InfrastructureMaster, RIDMaster Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster ## Using NETDOM netdom query fsmo
As confirmed, DC1 owns all FSMO roles (PDC Emulator, RID Master, Infrastructure Master, Domain Naming Master, Schema Master).
How to Transfer FSMO Roles From a Failed Domain Controller
Seize FSMO Roles Step by Step (ADUC)
Log on to the domain controller that will be the new FSMO roles owner. In this example, that server is DC2.
Once you’ve logged on to DC2, open the ADUC console.
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. Those FSMO roles will be transferred to the additional domain controller (DC2) when you click OK.
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:
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.
Seize FSMO Roles Step by Step (PowerShell)
The PowerShell method of seizing the FSMO roles involves fewer steps than the others, making it an ideal emergency break-glass method.
Log on to the domain controller (DC2) and open PowerShell as admin.
Next, define the roles to seize. The below code defines all roles in a variable named $fsmoRoles.
$fsmoRoles = @( 'SchemaMaster', 'DomainNamingMaster', 'InfrastructureMaster', 'PDCEmulator', 'RIDMaster' )
You can also substitute the operations master’s names with their corresponding numbers.
|Operation Master Role Name||Number|
Run the following commands to move the FSMO roles to DC2.itbros.local forcefully. The first command gets the domain controller object (Get-ADDomainController). The second command ([Move-ADDirectoryServerOperationMasterRole](https://theitbros.com/transfer-fsmo-roles-using-powershell/)) transfers the FSMO roles:
$targetDC = Get-ADDomainController -Identity DC2.theitbros.local Move-ADDirectoryServerOperationMasterRole ` -Identity $targetDC ` -OperationMasterRole $fsmoRoles ` -Confirm:$false ` -Force
If there are no errors or output on the screen, the FSMO role move operation was completed successfully.
To confirm, let’s check the new FSMO roles owner.
Get-ADDomain | Format-List PDCEmulator, InfrastructureMaster, RIDMaster Get-ADForest | Format-List DomainNamingMaster, SchemaMaster
Suffice it to say the PowerShell method is quick and convenient.
Seize FSMO Roles Step by Step (NTDSUTIL)
In this last method, we’ll go old school. This method is interactive using the ntdsutil tool.
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 naming master FSMO role.
seize naming master
You will be prompted to confirm the role seizure. You will see this confirmation dialog for each FSMO role you are seizing. Click Yes.
NTDSUTIL will first attempt a safe role transfer. As expected, the safe transfer fails because DC1 is already dead. It proceeds with the seizure of the role instead.
As shown below, NTDSUTIL successfully seized the Naming Master role to DC2.
Now, run each command below to seize the remaining FSMO roles.
seize infrastructure master seize rid master seize schema master seize pdc q
Now, let’s enter the metadata cleanup mode.
metadata cleanup connections connect to server DC2 q
List the existing Active Directory sites:
select operation target list sites
This domain has only one AD site called EAST-US. Type the site number where the failed domain controller belongs. Then, list the servers on that site.
select site 0 list servers in site
Select the failed controller (DC1) and display the list of domains:
select server 0 list domains
Select the domain and return to the metadata cleanup menu:
select domain 0 q
Delete the selected server (DC1):
remove selected server
And you will get this confirmation dialog. Click Yes.
Whew! That was a lot of steps! I don’t think I’ll often use ntdsutil for FSMO roles operations.
Post FSMO Seizure Clean-Up Tasks
After you’ve successfully seized the FSMO roles, here are some tasks you must do.
Delete the Failed Domain Controller
You can delete the DC from the Active Directory Sites and Services (dssite.msc).
Click Yes to confirm the deletion.
Delete DNS Records
Once you’ve deleted the domain controller object, make sure to delete the DNS records that point to that DC.
You can let the DNS scavenging take care of it or manually remove them using the DNS manager. In the below example, the DC1 DNS entry is already removed automatically.
Check for Errors
After capturing the FSMO roles, check for errors in the Directory Services and DNS logs in the Event Viewer. If there are problems, use the following commands to help you fix the most common errors automatically.
dcdiag /v /fix netdiag /v /fix
Things to Watch Out For
- Seizing an FSMO role should only be done as a last resort when a domain controller holding an FSMO role fails and cannot be recovered.
- Seizing an FSMO role can cause conflicts if the original domain controller is recovered or brought back online.
- After seizing an FSMO role, ensuring that the domain is fully functional and has no issues is crucial.
- Wait for the changes to replicate throughout the AD forest.
In conclusion, seizing an FSMO role from a failed domain controller is a critical task that must be performed carefully. By following the steps outlined in this blog post and keeping an eye on potential issues, you can ensure that the domain remains fully functional even after a domain controller failure.