The forest-root PDC Emulator is normally the authoritative time source for the AD time hierarchy in an AD forest. Our article shows how to identify the forest-root PDC Emulator and config it to sync with an approved external/internal NTP source.
Our article applies to Windows Server 2025, Windows Server 2022, Windows Server 2019 and Windows Server 2016 (extended support until January 2027). The procedures in this guide use the built-in Windows Time Service (W32Time), w32tm, Active Directory Domain Services, and Group Policy. The commands and configuration described here apply to supported Windows Server versions we have mentioned above.
Why is time synchronization important with Active Directory DCs?
Time synchronization in a network environment is more than a convenience; it’s an absolute necessity, especially when it comes to domain controllers within an Active Directory Domain Services (AD DS) infrastructure.
Common issues caused by unsynchronized DCs
Why, though? Imagine having multiple domain controllers spread across your domain hierarchy, each with a different system time. This lack of sync would result in many problems, including authentication failures and inconsistencies in event logs, which are essential for monitoring and security purposes. Inconsistencies can be problematic when tracing an event across multiple domains or even within a single domain with multiple domain controllers.
Windows Time Service
The Windows Time service, integral to both member servers and domain controllers, provides the necessary time synchronization service across your network. This service follows a hierarchical structure, where the PDC Emulator of the forest root domain is typically configured as the authoritative time source for the forest. For an overview of the Windows Time Service architecture and how W32Time works, see the official Microsoft documentation.
Secure Time Seeding on Windows Server 2025
Keep in mind that Windows Server 2025 differs from earlier supported Windows Server versions in its default Secure Time Seeding (STS) config. STS is disabled by default in Windows Server 2025, while it is enabled by default in Windows Server 2019 and Windows Server 2022.
Microsoft recommends that enterprise admins review the STS config on Windows Server systems, particularly on Active Directory DCs and other systems where accurate and predictable timekeeping is important. In case your organization requires STS to remain disabled, you should check the UtilizeSslTimeData setting rather than assuming the default config.
You can check the local setting with the following command:
A value of 0 means that Secure Time Seeding is disabled.
PDC Emulator plays a key role
The PDC emulator performs a crucial role. The DC that holds the PDC emulator role is configured to synchronize time with an external NTP server, serving as the authoritative time server for the entire AD infrastructure. Other domain controllers and member servers synchronize time with the PDC emulator.
The forest-root PDC Emulator should sync with an approved authoritative time source because the local system clock can drift over time. Other DCs and domain members normally sync through the AD time hierarchy rather than directly with an external NTP service.
What is Network Time Protocol (NTP)?
The Network Time Protocol, commonly referred to as NTP, is a protocol designed for time synchronization among computer systems over packet-switched, variable-latency data networks.
NTP server stratum levels explained
Public NTP services can provide a convenient external time source for a DC. However, the stratum and sync quality of a public server depend on the specific service and network path and should not be treated as a guarantee of accuracy. You should use an approved internal NTP source/time appliance when available.
The beauty of NTP lies in its ability to provide time synchronization with remarkable precision over the public internet, where latency and network jitter can vary significantly. It does this through a complex algorithm that estimates network delay and adjusts time accordingly, even compensating for the time it takes for time requests to travel from the client to the server and back.
In an AD environment, the forest-root PDC Emulator normally sync with an approved authoritative NTP source. Other DCs and domain members normally obtain time through the AD time hierarchy rather than directly from external NTP servers.
NTP uses a stratum hierarchy to describe the distance of a time source from a reference clock. Stratum 0 refers to reference clocks such as GPS/GNSS receivers or atomic clocks and is not normally an NTP server. A Stratum 1 server is directly synced to a Stratum 0 reference. Stratum 2 servers sync from Stratum 1 servers, and the hierarchy continues upward.
Stratum
Description
0
Reference clocks such as GNSS/GPS or atomic clocks; not normally NTP servers
1
NTP servers directly connected to a Stratum 0 reference
2
Servers synchronized to Stratum 1 sources
3+
Servers synchronized through higher stratum levels
How time synchronization works in Active Directory?
First of all, we remind you how time synchronization works in the Active Directory forest:
All domain computers/member servers sync time with the nearest DC (in the client AD site) running in your Active Directory Domain Services environment or with the DC with the PDC role (if AD sites are not configured);
In case you are working with a multi-domain AD forest, the forest-root PDC Emulator is normally the authoritative time source for the forest. It should sync with an approved internal/external NTP source. Other DCs and domain members normally sync through the AD time hierarchy rather than directly with an external NTP service. Each child domain also has its own PDC Emulator, but that server should normally remain part of the AD time hierarchy rather than being configured as an independent external NTP client;
Note that domain-joined machines normally use the Windows Time Service (W32Time) with Type = NT5DS, which synchronizes time through the AD domain hierarchy rather than using manually configured NTP peers. The forest-root PDC Emulator is typically configured with Type = NTP to synchronize with an external/internal authoritative NTP source.
The PDC Emulator in the forest root domain becomes the authoritative time source by default. You can config it to sync with an external NTP server.
Configuring time synchronization using the w32tm command
You can configure time synchronization on the PDC manually or using a GPO.
Find the Forest-Root PDC Emulator
Before configuring an external NTP server, you need to identify the DC that holds the PDC Emulator FSMO role. Only this DC should be configured to sync time with an external NTP source.
In order to identify the PDC Emulator in the forest-root domain, first you need to determine the forest-root domain name. The netdom command should then explicitly query that domain:
netdom query fsmo /domain:contoso.com
Don’t forget to replace contoso.com with the DNS name of your forest-root domain. This avoids accidentally configuring the PDC Emulator of a child domain when the command is run from a different domain.
The output will display all FSMO role holders, including the PDC Emulator:
The returned hostname is the DC where you should config external NTP synchronization.
Note that command shown above requires the Active Directory PowerShell module (RSAT-AD-PowerShell).
Configure using w32tm command
The w32tm.exe utility is used to configure time synchronization manually.
Open an elevated command prompt (administrative command prompt) on the PDC and run the command:
Important. You need to config the external NTP source only on the PDC Emulator of the forest-root domain. Do not config external NTP independently on PDC Emulators of child domains. Child-domain DCs should normally use the AD time hierarchy.
Don’t forget to replace these hostnames with NTP servers approved by your organization. In production, you should prefer an internal NTP service, dedicated time appliance, or approved provider-operated NTP service rather than an unmanaged public NTP pool.
/Syncfromflags:manual โ configures the Windows Time service to use manually specified NTP peers.
manualpeerlist:”ntp1.example.com,0x8 ntp2.example.com,0x8″ โ specifies the NTP servers that the machine uses for time sync. Replace these example hostnames with the approved NTP servers used in your environment. The 0x8 flag specifies Client mode, which causes Windows Time to send periodic sync requests to the specified NTP servers.
The following values are allowed for synchronization parameters with external NTP servers:
0x1 โ SpecialInterval, use of a special polling interval;
NTP security considerations. Windows Time Service (W32Time) does not support Network Time Security (NTS). The standard NTP config shown in our article therefore does not provide NTS-based cryptographic authentication of the external time source.
When working with enterprise environments, you should prefer an approved internal NTP source/dedicated time service when available. In case an external NTP source is used, you need to restrict outbound NTP traffic to approved servers and allow only the required UDP port 123.
Now you need to advertise the PDC-Emulator as a reliable source of time for domain clients:
w32tm /config /reliable:yes
Protect the PDC Against Large Time Corrections
The forest-root PDC is the authoritative time source for the AD forest, so an incorrect large time correction on this server can affect the entire domain hierarchy. Windows Time Service limits the size of corrections accepted from a time source through the MaxPosPhaseCorrection and MaxNegPhaseCorrection settings.
On DCs, the default value for both settings is 172800 seconds (48 hours). For an authoritative forest-root PDC, you need to config explicit limits appropriate for your environment rather than relying on the permissive default.
For example, the following config limits a single positive/negative correction to one hour:
The 3600-second value is an example policy, not a universal requirement. You need to choose a value that matches the reliability of the configured time sources and the organization’s recovery procedures.
Note that these limits should not be used to hide/ignore a large time offset. If a DC exceeds the configured correction limit, you need to investigate the time source, network connectivity, virtualization time sync, and system clock before applying a large manual correction.
Important. Before applying a restrictive phase-correction limit, you need to check the current clock offset on the forest-root PDC. In case the PDC clock is already more than the configured limit away from the authoritative NTP source, W32Time may reject the required correction. You need to perform the initial sync/controlled clock correction first when necessary, then apply the restrictive MaxPosPhaseCorrection and MaxNegPhaseCorrection values.
You can verify the current Windows Time service config using:
w32tm /query /configuration
Don’t forget to ensure that the LocalClockDispersion, AnnounceFlags, and synchronization settings reflect the expected config of an authoritative time source.
Now you need to restart the W32Time service on the PDC:
net stop w32time && net start w32time
To sync the time immediately, run the command:
w32tm /resync /rediscover
The /rediscover option forces Windows Time Service to rediscover available time sources using the current config. It is useful after changing the NTP peer config.
Verifying Time Sync
After configuring the PDC Emulator, verify that the Windows Time service is synchronized correctly and uses the expected time source.
w32tm /query /status
To check the time source, use the command:
w32tm /query /source
In order to verify time sync across DCs in the Active Directory domain, use the following command:
w32tm /monitor
This command queries DCs and displays the time offset between DCs, their stratum level, and info about the current time sync hierarchy.
Here is an example output:
Example output from w32tm /monitor may look similar to the following. Note that values and formatting vary by Windows version and environment.
When reviewing the output, you need to pay particular attention to the NTP offset, Stratum, and RefID values. The offset shows the estimated time difference, Stratum indicates the server’s position in the NTP hierarchy, and RefID identifies the reference time source.
A small and stable offset between DCs indicates that the AD time hierarchy is working correctly.
In order to review the effective Windows Time Service config, run the command below:
w32tm /query /configuration
This displays the configured W32Time settings and their sources, such as local config/Group Policy. It does not show the time source currently being used for sync.
To check the current time source, run the command below:
w32tm /query /source
In case you need to view sync status, including the current stratum and last successful synchronization time, use the following:
w32tm /query /status
Tip. The list of current NTP sources is stored in the registry key HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters in the NtpServer parameter.
Configuring time synchronization using Group Policy
To centrally manage Windows Time Service settings, you can use Group Policy. However, additional care is required because a standard GPO link does not target the PDC Emulator by FSMO role. In order to apply the NTP settings only to the current PDC Emulator, you should use a WMI filter that evaluates the DC’s current DomainRole value. This filter is evaluated dynamically, so after the PDC Emulator role is transferred to another DC, the new PDC matches the filter and the previous PDC no longer does.
Before configuring the policy, you need to check which DC currently holds the PDC Emulator FSMO role. You can do this with netdom query fsmo command or with the following PowerShell command:
Open the Group Policy Management Console (GPMC.msc) and create a new policy PDC_NTP_sync;
Assign this policy to the OU Domain Controllers;
Create a WMI filter with the following code and link it to your policy:
Select * from Win32_ComputerSystem where DomainRole = 5
The WMI filter DomainRole = 5 targets the DC that Windows currently identifies as the Primary Domain Controller (PDC Emulator). Because the filter is evaluated on each machine when Group Policy is processed, it follows the current PDC Emulator after an FSMO role transfer.
Switch to the policy editing mode and go to the section Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers. Enable the policy Enable Windows NTP Client and edit the Configure Windows NTP Client policy.
The command shown above sends multiple time queries to the specified NTP server and displays the measured clock offset for each sample. You need to replace ntp1.example.com with one of your approved upstream NTP servers.
To measure the offset between the current PDC Emulator and another DC, you need to specify the PDC Emulator identified earlier:
A small and stable offset indicates that time sync is working correctly. Keep in mind that large/inconsistent offsets may indicate network latency, connectivity problems, or issues with the configured time source.
Reset and restart the Windows Time service
To reset the time service settings and clear the list of external NTP servers, run the following commands:
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
Time sync for virtualized DCs
If a DC is running as a VM, time sync requires additional consideration.
The PDC Emulator should remain the authoritative time source for the AD environment and should sync with an external NTP server.
Other DCs and domain members should follow the normal AD time hierarchy and sync time from the DC hierarchy.
You should avoid using continuous hypervisor time sync together with Windows Time Service on DCs. For example, enabling both VMware Tools time sync and Windows Time sync can create competing time sources and cause unexpected clock corrections.
For virtualized DCs, we recommend you the following approach:
Config the PDC Emulator to sync with external NTP servers.
Allow other DCs to sync from the AD hierarchy.
Disable continuous hypervisor time sync for DCs. You should use it only during initial deployment, recovery cases, or after restoring a VM snapshot/backup.
This prevents conflicts between the virtualization platform and the Windows Time service.
For example, a DC may receive time updates from two different sources:
VMware Tools or Hyper-V Integration Services;
Windows Time Service (W32Time).
If these sources provide different time values, the system clock may continuously adjust, which can lead to Kerberos authentication failures and unreliable event timestamps.
Kerberos authentication normally allows a maximum clock difference of 5 minutes between systems. This is controlled by the Maximum tolerance for computer clock sync Kerberos policy, whose default value is 5 minutes. DCs and clients should therefore maintain their clocks well within this tolerance.
Do not confuse the Kerberos 5-minute tolerance with the MaxPosPhaseCorrection and MaxNegPhaseCorrection settings. Kerberos tolerance defines how much clock difference is allowed for authentication, while the W32Time phase-correction settings define how large a time correction Windows Time Service will accept from a configured time source.
Firewall requirements. The forest-root PDC must be allowed in order to send outbound UDP/123 traffic to the configured upstream NTP servers. DCs that provide time to domain members must also accept inbound UDP/123 from the appropriate internal networks. This allows domain members and other DCs to obtain time from the Windows Time Service on the DC. Firewall rules should be restricted to the required internal subnets/management networks rather than allowing UDP/123 from arbitrary sources. Do not expose a DC’s NTP service directly to the Internet.
Time synchronization is essential for security and stability in Active Directory. Without accurate time, Kerberos authentication may fail, replication can break, and event logs may become inconsistent across domain controllers.
The PDC Emulator is the authoritative time source in an AD forest. All other domain controllers and member servers synchronize with it, ensuring uniform time across the environment. The PDC itself should be configured to sync with reliable external NTP servers.
Yes. You can specify multiple NTP servers using the /manualpeerlist parameter in the w32tm.exe command. Listing multiple servers ensures redundancy in case one NTP source is unavailable.
I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.
What happens when the PDC moves to a different DC… then the old PC is still going external for the NTP Time source as opposed to the new ( Role Moved ) PDC.
How can the NTP Settings revert back to the default model ( instead of being tattooed to stay going to the external time source ) of all DCs looking to the PDC and the PDC going to atomic clock.
Doug
3 months ago
In the section labled: Configure using w32tm command, you have the peer list as 0.pool.ntp.org 1.pool.ntp.org etc. Then in the directions below you start talking about 0x8 at the end of each. It’s confusing.
What happens when the PDC moves to a different DC… then the old PC is still going external for the NTP Time source as opposed to the new ( Role Moved ) PDC.
How can the NTP Settings revert back to the default model ( instead of being tattooed to stay going to the external time source ) of all DCs looking to the PDC and the PDC going to atomic clock.
In the section labled: Configure using w32tm command, you have the peer list as 0.pool.ntp.org 1.pool.ntp.org etc. Then in the directions below you start talking about 0x8 at the end of each. It’s confusing.
Thanks for the comment, we already updated it.