With the new domain controllers fully in place and the old ones retired, one often-overlooked aspect is configured correctly: time synchronization (NTP). In Active Directory, proper time sync is crucial because Kerberos authentication relies on timestamps. By default, if the clocks differ by more than 5 minutes, authentication fails.
The authoritative time source in a domain is the PDC Emulator FSMO role holder in the forest root domain. Now that we’ve moved the PDC role to a Windows Server 2025 DC, we should configure that new DC to synchronize with a reliable external time source. Additionally, we’ll reflect on the placement of the FSMO role. In our migration, we placed all FSMO roles on DC2025-1. It’s a good time to verify if that distribution still makes sense.
Configuring the PDC Emulator as an Authoritative Time Source
When a server becomes the PDC Emulator, it doesn’t automatically start syncing time from an external NTP source. It might continue following the domain hierarchy, which can create a circular sync loop if it’s now at the top.
Steps to Configure NTP on PDC (DC2025-1): #Choose External NTP Servers: #Recommended options: "0.pool.ntp.org", "1.pool.ntp.org", "time.windows.com", or any regional time source. #Stop the Time Service: net stop w32time #Configure the Time Source: w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com,0x8 0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /reliable:yes /update #Restart the Time Service: net start w32time #Force a Resync and Verify: w32tm /resync w32tm /query /status #You can also run: w32tm /query /source #This should show one of your NTP servers as the time source. If it says “Local CMOS Clock,” recheck the configuration. #Ensure Domain Members Sync from PDC On other DCs: w32tm /config /syncfromflags:DOMHIER /update net stop w32time & net start w32time #Domain members will then inherit proper time sync via the domain hierarchy.
Real-World Insight
Time misconfiguration is a silent killer. In one environment, a PDC wasn’t syncing externally and drifted by several minutes over a few months, leading to system authentication failures. Always set the PDC to an external time source and monitor it with Event Viewer or w32tm /monitor.
FSMO Role Realignment Considerations
Now that migration is complete, it’s worth evaluating whether FSMO roles are optimally distributed. In our case, all roles were placed on DC2025-1:
- This is fine for single-domain environments – it simplifies management.
- In larger or more complex environments, consider distributing roles:
Recommendations:
- Schema Master & Domain Naming Master: These are rarely used. It can be moved to another DC (e.g., DC2025-2) to distribute the load.
- Infrastructure Master:
- Only matters in multi-domain forests where not all DCs are Global Catalogs.
- This is irrelevant if all DCs are GCs (as in our case).
- RID Master:
- Coordinates object creation IDs.
- Works well on the same server as PDC.
- PDC Emulator:
- Handles time sync, password replication, and default GPMC targeting.
- Needs to be reliable and well-connected.
Checking FSMO Roles:
Get-ADDomain | FL InfrastructureMaster,RIDMaster,PDCEmulator Get-ADForest | FL SchemaMaster,DomainNamingMaster
This confirms who owns what. If all lists DC2025-1, which aligns with your design, you’re good.
It’s wise to update the documentation with current FSMO role holders. After migrations, this information often gets lost.
Summary
- Our new PDC Emulator (DC2025-1) is now configured to sync with a reliable external time source.
- Other domain controllers and clients will follow the domain hierarchy for time.
- FSMO roles are confirmed to be on stable hardware.
- No further role realignment is necessary unless specific design goals require it.
With time synchronized and roles realigned, your domain runs clean and efficiently on Windows Server 2025. In Part 9, we’ll cover extending AD to Azure by adding a domain controller in the cloud, supporting hybrid identity scenarios.
Cristal Kawula, Checkyourlogs.net
