Before you get started

To find and move FSMO roles using PowerShell, you must take the following steps:

1. If you're using Windows 10, you can either install Remote Server Administration Tools (RSAT), including the required AD module, or add the required features using Optional features within the control panel.

2. If you use Windows 11, you can enable the component by adding the RSAT: Remote Access Management Tools feature.
3. Ensure your computer meets the following prerequisites:
   1. The computer must run PowerShell.
   2. The computer needs domain joining.
4. Ensure you have the appropriate permissions to move FSMO roles.

Types of FSMO roles

There are five FSMO roles in an AD forest, each with a specific purpose:

1. Schema master. This role controls the AD forest schema modifications. The schema defines the structure and rules for objects and attributes stored in AD, so this role ensures that changes to the schema synchronize with all domain controllers in the forest.
2. Domain naming master. This role controls adding or removing domains from the AD forest. It ensures that there are no naming conflicts when adding new domains and that the names are unique.
3. Infrastructure master. This role updates references to group-to-user mappings within a domain. It ensures that changes to group memberships synchronize across all domain controllers.
4. Relative identifier (RID) master. This role allocates a pool of unique RIDs to each domain controller in a domain. RIDs get mapped to security principals, such as user accounts, groups and computer accounts.
5. Primary domain controller (PDC) emulator. This role provides backward compatibility for older clients and manages password changes. It's responsible for time synchronization across the domain, which is critical for Kerberos authentication.

AD assigns each FSMO role to a specific domain controller. The roles must distribute and function correctly to maintain a healthy AD environment.

Use PowerShell to find FSMO roles

To find the FSMO roles in AD using PowerShell, you can use two commands: Get-AdDomain and Get-AdForest. These commands are necessary because some FSMO roles are at the forest level, while others are at the domain level.

Using the Get-AdForest command, you can identify which domain controllers hold the DomainNamingMaster and SchemaMaster roles.

Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster | Format-List

The Get-AdDomain command lets you identify which domain controllers hold InfrastructureMaster, PDCEmulator and RIDMaster roles.

Get-ADDomain | Select-Object InfrastructureMaster, PDCEmulator, RIDMaster | Format-List

To make it easier, combine these commands into a function you can use when writing a reusable script.

function Get-AdFsmoRoles {
     [pscustomobject]@{
          InfrastructureMaster = (Get-ADDomain).InfrastructureMaster
          PDCEmulator = (Get-ADDomain).PDCEmulator
          RIDMaster = (Get-ADDomain).RIDMaster
          DomainNamingMaster = (Get-ADForest).DomainNamingMaster
          SchemaMaster = (Get-ADForest).SchemaMaster
     }
}

Using this function, you can then access the various property values using either of these approaches:

(Get-AdFsmoRoles).InfrastructureMaster

$results = Get-AdFsmoRoles
$results.InfrastructureMaster

If you need to check for FSMO roles across all domain controllers, you can use PowerShell like this:

foreach ($dc in $domainControllers)
    {Write-Host "Domain Controller: $($dc.Name)"
    $dcInfo = Get-ADDomainController -Identity $dc.Name
    if ($dcInfo.OperationMasterRoles) {
        $dcInfo | `
        Select-Object Name, Domain, Forest, OperationMasterRoles | `
        Format-Table -AutoSize
    }
    else
    {
            Write-Host "No FSMO roles found."
    }
}

How to transfer FSMO roles

Now that you have checked where the FSMO roles reside, you can move them by calling Move-ADDirectoryServerOperationMasterRole, setting the domain controller and the role to move.

$domainController = "WIN2019BDC"
Move-ADDirectoryServerOperationMasterRole `
    -Identity $domainController `
    -OperationMasterRole PDCEmulator

The PowerShell command also accepts the use of splatting:

$params = @{
Identity = $domainController
OperationMasterRole = "RIDMaster"
}
Move-ADDirectoryServerOperationMasterRole @params

Once executed, you can then check the location of the FSMO roles.

Finding the FSMO role holders before moving them is unnecessary, but knowing the state before making these significant changes is helpful.

How to seize FSMO roles

Sometimes, you need to seize the FSMO roles from other domain controllers. Seizing FSMO roles is taking over the role from the domain controller that has permanently failed or is no longer available. You can't simply move roles; you must seize them. It's important to note that seizing an FSMO role should be done as a last resort after all other methods of transferring the role have failed or are impossible. Seizing an FSMO role should only be done if the previous holder is permanently unavailable and there is no chance of it returning to service.

This process is the same as the normal move; however, you add the -Force parameter to the command. If you were seizing the RIDMaster role, PowerShell changes to this:

$domainController = "WIN2019BDC"
$params = @{
Identity = $domainController
OperationMasterRole = "RIDMaster"
}
Move-ADDirectoryServerOperationMasterRole @params -Force

Once completed, you can execute the function you created earlier, Get-AdFsmoRoles, to confirm that the roles now reside on the selected domain controller.

In general, transferring FSMO roles using PowerShell is a straightforward process. You can transfer FSMO roles to ensure redundancy and fault tolerance in your AD environment. However, it's essential to plan the moves carefully, considering the requirements for each FSMO role and the effect of the transfer on your domain. With careful planning and attention to detail, you can confidently transfer FSMO roles and maintain the integrity and availability of your AD environment.