Migrating FSMO Roles and Troubleshooting Group Policy Issues in a Windows Server Environment

In this blog post, I’m sharing a real-world experience of migrating a Windows Server Active Directory (AD) environment to a new domain controller (DC), with a focus on FSMO role transfer, DNS cleanup, and resolving Group Policy update issues. Whether you’re an IT admin managing a small business or working on a home lab setup, this guide walks you through the key steps, challenges, and resolutions during AD migration.

1. Preparing the Environment

Before starting, both domain controllers were up and running. AD1 was the original DC, holding all FSMO (Flexible Single Master Operation) roles. AD2 was newly promoted, joined to the domain, and configured with a static IP (192.168.1.11). I made sure that:

AD2 had the same domain and forest functional levels.

DNS was properly installed and running on AD2.

AD2 replicated successfully with AD1.

2. Transferring FSMO Roles

Using PowerShell on AD2, I ran the following command to transfer all FSMO roles:

Open Powershell and the below comment:

Move-ADDirectoryServerOperationMasterRole -Identity “AD2” -OperationMasterRole 0,1,2,3,4 -Confirm:$false

Then I verified the transfer with:

Then I verified the transfer with:

Use Powershell

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

All FSMO roles successfully moved to AD2.

3. Initial Tests Before Shutting Down AD1

Before shutting down AD1, I checked a few things:

• Replication Status: Ran repadmin /replsummary to ensure AD1 and AD2 were in sync.
• DNS Health: Ensured that AD2 was listed as a nameserver for the domain and that DNS zones had been replicated.
• Clients: Verified that client PCs could resolve domain names using AD2 as DNS

4. Shutting Down AD1 and Encountering Issues

After verifying everything, I shut down AD1 to see how the network would behave. Immediately, I ran into a few problems on the client machines:

• Running gpupdate /force gave errors

The processing of Group Policy failed. Windows could not obtain the name of a domain controller.
This could be caused by a name resolution failure.

Replication failed with RPC server is unavailable errors.

DNS lookups using nslookup testing.com still returned old IPs (like 192.168.1.10).

5. Troubleshooting DNS Issues

The main issue was DNS. Even though AD1 was off, its IP (192.168.1.10) still appeared in DNS query results.

Steps I took:

1. Cleaned Up Old DNS Records:
   • Opened DNS Manager on AD2.
   • Deleted all A records pointing to 192.168.1.10.
   • Also removed outdated NS records still listing AD1.
2. Verified DHCP Settings:
3. Flushed DNS Cache:
   • Ran ipconfig /flushdns and ipconfig /registerdns on clients and AD2.
   • Restarted the netlogon service on AD2.
4. Checked Forward and Reverse Zones:
   • Ensured that both forward and reverse lookup zones in AD2 pointed only to 192.168.1.11.
   • Made sure AD2 was listed under the “Name Servers” tab in the zone properties.
5. After these cleanup steps, running nslookup testing.com correctly showed only 192.168.1.11 and no trace of the old IP.

6. Fixing Group Policy (gpupdate) Errors

Even after DNS cleanup, gpupdate /force was still failing on client machines. The error message remained the same — “Windows could not obtain the name of a domain controller.”

Here’s what helped resolve it:

• Verified that AD2 was properly advertising its domain controller services.
• Made sure AD2’s firewall was not blocking RPC or LDAP ports (especially port 135).
• Used nltest /dsgetdc:testing.com to check which DC was being contacted — it correctly pointed to AD2.
• Removed any lingering references to AD1 in Active Directory Sites and Services, especially under NTDS settings.

Eventually, gpupdate /force started working normally again.

7. Final Checks

Once everything stabilized:

• I re-ran repadmin /replsummary — no more errors since AD1 was offline and AD2 was the only DC.
• Ensured Event Viewer on AD2 had no critical DNS or AD-related warnings.
• Restarted a few clients and verified logon, DNS resolution, and Group Policy all worked fine.

Lessons Learned

Here are a few takeaways that might help you if you’re planning a similar migration:

1. DNS Cleanup is Crucial: Even if you transfer FSMO roles, stale DNS records can cause major issues.
2. DHCP Scope Must Point to New DNS: Ensure DHCP hands out the correct DNS IPs (AD2 in this case).
3. Don’t Rush to Demote Old DC: Test thoroughly with AD1 off before fully removing it.
4. Verify Netlogon and SYSVOL: Make sure these shared folders are accessible on the new DC.

Migrating FSMO roles and making a new DC the primary domain controller isn’t too complex, but small DNS or replication oversights can lead to frustrating problems. I hope this summary helps you prepare better, troubleshoot smarter, and ensure a smooth transition in your environment.