Transferring Windows Server roles to a new server, Part II FSMO

TL;DR how to move the FSMO roles in AD.

Welcome to Part II of our PDC & DFS migration!

Part I: DFS

Part II: FSMO roles

Part III: Setup the new PDC

Background

Picking up from Part I, we have three VMs in ESXi. All three are Domain Controllers (DCs) and at this point two are hosting Target Folders for the DFS namespace. TestDC and BackupDC are running Server 2016, BackupDC3 is running Server 2019. TestDC is being decommissioned prior to a clean install of Server 2019. The domain is test.local.

FSMO, err “Operations Masters”

Microsoft has deprecated the term Flexible Single Master Operation (FSMO) in favor of Operations Masters. However for simplicity’s sake I will use the term ‘FSMO’ in this writeup, and the term lives on in commands. Just be aware of that terminology in case you are taking a Microsoft exam.

There are five FSMO roles, known by their name and their number; PDCEmulator (0), RIDMaster (1), InfastructureMaster (2), SchemaMaster (3), and DomainNamingMaster (4). As the names imply, SchemaMaster and DomainNamingMaster are Forest wide roles. The other three are domain wide.

• The PDC Emulator handles backwards compatibility functions for Windows NT 4.0, which hardly matters in this day and age. However it also handles time synchronization across the domain and password changes.
• The RID Master handles Relative IDs (RIDs). Suffice to say that without RIDs the creation of new objects in Active Directory (AD) will not work.
• The Infrastructure Master handles cross domain functions, such as a user in one domain being added to a group in another domain.
• The Schema Master replicates schema changes to all other DCs forest wide. This is important for enabling something like the Local Admin Password Solution (LAPS) as it adds attributes to the existing schema.
• The Domain Naming Master handles changes such as adding a child domain.

Querying which DC currently holds each FSMO role and changing the role to a new DC is one of those tasks in Windows where PowerShell is actually a lot easier than using the GUI. To find or change the FSMO roles in the GUI one has to open three different management tools, after running ‘regsvr32 schmmgmt.dll’ from either cmd or PowerShell and then adding the Active Directory Schema snap in to MMC. So to use the GUI for this task one still has to use the command line.

Note; I didn’t even bother pulling up FSMO roles in the GUI until after the migration, hence it shows BackUpDC3 holding them. This is shown simply to illustrate how much simpler this task is via the command line.

A much easier way to see which DC holds these roles is to simply run

netdom query fsmo

from either PowerShell or cmd.exe

Alternatively one can run the PowerShell commands

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

Moving the FSMO roles

At this point we can easily move all five FSMO roles to BackupDC3 by simply executing one command in PowerShell:

Move-ADDirectoryServerOperationMasterRole -Identity BackupDC3 -OperationMasterRole pdcemulator, ridmaster, infrastructuremaster, schemamaster, domainnamingmaster

However this makes me a bit nervous, so I am going to take advantage of the Snapshot feature in the free version of ESXi first.

Please note; if the DC holding the FSMO roles is down for any reason and you need to transfer the roles, simply run the command above and add ‘-Force’. Once this is done Microsoft does not recommend bringing the original FSMO role holding DC back online without re-installing first. It will likely cause too many problems on the domain as it will attempt to act as the FSMO role.

Checking afterwards

Attempting to create a new user account aptly named test.dummy and logging into the Windows 10 domain client succeeded, so the lab is still up post migration.

Some housekeeping

As per the Best Practices Analyzer (BPA) tool available in Server Manager, the new PDC-Emulator should be set to sync it’s time with a valid time source.

This is easy to set by simply running the below commands to sync with MS’s NTP server:

w32tm.exe /config /syncfromflags:manual /manualpeerlist:131.107.13.100,0x8 /reliable:yes /update
w32tm.exe /config /update

Then verify by running:

w32tm /query /configuration

The built in OUs in AD such as Domain Controllers are not protected from accidental deletion by default. This is easily remedied by either checking Advanced Features under the View menu in ADUC -> right click the OU -> Object tab -> hit the checkbox

Or from PowerShell run:

Get-ADObject -LDAPFilter “objectClass=organizationalUnit” -SearchBase “OU=Domain Controllers,DC=test,DC=local” | Set-adobject -ProtectedFromAccidentalDeletion $true

On a sidenote, moving the FSMO roles from a Windows Server 2016 DC to a Server 2019 DC does not alter the domain or forest functional level.

This is relevant as one cannot have a Windows Server 2016 DC on a Server 2019 functional domain level.

Lastly we will backup all GPOs to the share drive just to be safe:

All DCs maintain a copy of the GPOs in \\<ComputerName>\SYSVOL\test.local\Policies, hence performing a manual backup prior to decommissioning TestDC is really just a ‘peace of mind’ thing.

On a sidenote, this folder is readable by domain users, which is why Microsoft and every security guy out there tell administrators to no longer use Group Policy Preferences (GPP) to manage the local admin password on domain workstations. Microsoft would know, they leaked the encryption key that protected the password stored in a GPO’s *.xml (cpassword) on MSDN. Microsoft has since patched this so that Windows will no longer allow administrators to use GPP for passwords, but this does not remove pre-existing passwords stored in SYSVOL.

The common wisdom today is to use the Local Admin Password Solution (LAPS) for this. It stores the passwords in plain text in Active Directory, but the attribute is only viewable by Domain Admins by default. There are plenty of great guides out there on why you should use LAPS and how to set it up, so I won’t re-invent the wheel here. I used this one personally.

There is a security sidenote regarding LAPS and RSAT. That writeup ended up being a bit long, so I spun it off into another howto. The TL;DR is that using RSAT to pulls LAPS data risks a MITM.

Summary

That’s it for moving the FSMO roles to a new server. It’s a simple process and can be performed in a single PowerShell command, but it’s important to ensure that command is correct before executing it and verify the roles afterward.

References:

https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/transfer-or-seize-fsmo-roles-in-ad-ds

http://blog.technotesdesk.com/move-all-fsmo-roles-from-server-to-another-in-active-directory

https://en.wikipedia.org/wiki/Flexible_single_master_operation

https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/configure-the-root-pdc-with-an-authoritative-time-source-and-avoid-widespread-time-skew

https://www.technipages.com/active-directory-how-to-check-domain-and-forest-functional-level

https://stealthbits.com/blog/how-to-backup-and-recover-group-policy-objects/

https://adsecurity.org/?p=2288