Powershell Howto: Seizing FSMO roles

This will be the first of many weekly Powershell how-to’s.

Powershell has become one of the first things in my toolbox I go to when confronted with an issue. It is also a great way to automate several daily tasks and procedures. So, if you’re not up to speed on Powershell, I HIGHLY recommend you begin learning. A great place for a things Powershell is Powershell.org. Head over there and check it out if you’re interested in learning.

With that said, onto the main attraction!


How-to Seize FSMO roles with Powershell.


Okay…  so you’re wondering…  “This is an odd choice of topic for your very first Powershell how-to.”

Under normal circumstances you would be correct, but I’ve run into a situation with my home lab that several IT admins have found themselves in the past. The DC holding my FSMO roles is flat on it’s face after a power outage as my Hyper-V host dropped hard.

With AD, unless you have a very specific reason, I find it almost more time efficient to seize roles, do metadata cleanup, and build a whole new DC,  than to attempt DR with your backup utility. Main reason being AD can be a bit picky in regards to being restored, plus, if setup correctly, it’s inherently redundant (you have 2 DCs in your environment right? RIGHT?!?!)

So in this situation my primary DC is dead in the water. It held all the FSMO roles and I need to have my secondary DC seize the roles.

Note: If you’re curious and don’t know to begin with you can determine the current location of your FSMO roles by using both the Get-ADForest and Get-ADDomain cmdlets as needed.

I can utilize the Move-ADDirectoryServerOperationMasterRole Powershell cmdlet to accomplish this. This operation can be completed by any domain attached PC, assuming you have the AD powershell module and sufficient access and rights.

Syntax of the cmdlet is as follows:

Move-ADDirectoryServerOperationMasterRole [-Identity] <ADDirectoryServer> [-OperationMasterRole]
<ADOperationMasterRole[]> [-AuthType <ADAuthType>] [-Credential <PSCredential>] [-Force [<SwitchParameter>]]
[-PassThru [<SwitchParameter>]] [-Server <String>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]

This cmdlet can be used to both seize the roles and move them gracefully as well. A section of the help file (below) explains the difference in the operations quite efficiently. Main difference being the force parameter.

The Move-ADDirectoryServerOperationMasteRole cmdlet provides two options for moving operation master roles:

1. Role transfer, which involves transferring roles to be moved by running the cmdlet using the Identity parameter to specify the current role holder and the OperationMasterRole parameter to specify the roles for transfer. This is the recommended option.

Operation roles include PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, or DomainNamingMaster. To specify more than one role, use a comma-separated list.

2.  Role seizure, which involves seizing roles you previously attempted to transfer by running the cmdlet a second time using the same parameters as the transfer operation, and adding the Force parameter. The Force parameter must be used as a switch to indicate that seizure (instead of transfer) of operation master roles is being performed. This operation still attempts graceful transfer first, then seizes if transfer is not possible.

Unlike using Ntdsutil.exe to move operation master roles, the Move-ADDirectoryServerOperationMasteRole cmdlet can be remotely executed from any domain joined computer where the Active Directory PowerShell administration module is installed and available for use. This can make the process of moving roles simpler and easier to centrally administer as each of the two command operations required can be run remotely and do not have to be locally executed at each of the corresponding role holders involved in the movement of the roles (i.e. role transfer only allowed at the old role holder, role seizure only allowed at the new role holder).

In my case I’ll be seizing the roles, so I will have to utilize the -force parameter as shown below.


I have now successfully seized the PDCEmulater role. I will now move the other 4 roles over at once.


You’ll see that all were successful with the exception of the SchemaMaster roles. This is because the account I used to run the command does not have Schema Admin rights inside of AD. To get around that I opened a Powershell session as the domain admin and ran the command as seen below.


I have now successfully seized all my FSMO roles as evidenced by the screenshots below showing they are now running on ANDO-DC02.



I would now complete the metadata cleanup process and remove all references to the dead DC from DNS and AD. Once that step is completed I will build a new DC and place it into the AD infrastructure per the normal DC provisioning procedure.

Thanks for reading!

Share Button