In this article, we will show how to identify the domain controller holding the PDC Emulator FSMO role and config it to sync time with an external NTP server.
Why is time synchronization important with Active Directory Domain Controllers?
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.
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.
Why external NTP synchronization is needed
This configuration ensures a reliable time source for all devices within the network. It also enables the Windows NTP client on each domain controller to synchronize time accurately with the PDC emulator.
Time can deviate
However, this internal time synchronization can deviate over time, requiring the DC to synchronize time with an external source. Therefore, configuring DC for sync time with an external NTP server is crucial. External NTP servers, such as public NTP servers, follow the NTP protocol, providing high accuracy and reliability.
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. Born out of the necessity for reliable and accurate timekeeping in the digital world, NTP has become a cornerstone protocol in today’s internet infrastructure.
NTP server stratum levels explained
External NTP servers, such as public NTP servers available on the internet, usually operate at Stratum 1 or Stratum 2. These servers provide a reliable and accurate time source for other devices to synchronize with, leveraging the NTP protocol.
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 the context of a Windows Server environment, configuring DC for sync time with external NTP server becomes a vital part of ensuring accurate and reliable time across the domain. Domain controllers, including the primary domain controller, are usually configured to synchronize time with these external NTP servers.
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 or member servers synchronize time with the nearest domain controller (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);
All DCs sync time with the PDC Emulator in their domain;
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 PDC Emulator DC
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.
To find the current PDC Emulator, you should run the following command from any domain-joined machine with appropriate permissions:
netdom query fsmo
The output will display all FSMO role holders, including the PDC Emulator:
Schema master DC01.contoso.com
Domain naming master DC01.contoso.com
PDC DC02.contoso.com
RID pool manager DC01.contoso.com
Infrastructure master DC01.contoso.com
Alternatively, you can use PowerShell:
(Get-ADDomain).PDCEmulator
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:
/Syncfromflags:manual โ configures the Windows Time service to use manually specified NTP peers.
/manualpeerlist:โ0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8โณ โ lists external NTP servers for synchronization for configured NTP servers. The 0x8 parameter specifies the NTP client mode, which means that the computer sends time synchronization 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;
0x2 โ UseAsFallbackOnly mode;
0x4 โ SymmetricActive, symmetric active mode;
0x8 โ Client, send request in client mode.
Now you need to advertise the PDC-Emulator as a reliable source of time for domain clients:
w32tm /config /reliable:yes
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 synchronize the time immediately run the command:
w32tm /resync
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.
A small and stable offset between DCs indicates that the AD time hierarchy is working correctly.
In order to check active configuration of the Windows Time Service, run the following command:
w32tm /query /configuration
The output should show the current time source used by Windows Time Service. On the PDC Emulator configured with an external NTP source, it should display one of the configured NTP servers. The /status output shows sync details (including the current stratum level and last successful sync time).
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 standard GPO filtering does not automatically detect the current PDC Emulator FSMO role holder. If the PDC Emulator role is transferred to another DC, review the policy scope or use a startup script that dynamically detects the current PDC Emulator.
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 (Get-ADDomain).PDCEmulator 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 This WMI filter identifies computers reporting the Primary Domain Controller role. Note that this is a legacy Windows terminology and does not directly check the FSMO PDC Emulator role in AD. Important. This WMI filter does not reliably identify the current holder of the PDC Emulator FSMO role. Before relying on this approach, you should check in your environment that the policy is applied only to the intended DC. If you need to ensure that only the current PDC Emulator uses an external NTP source, you need to use a startup script that checks the current FSMO role holder dynamically and applies the config only on that server.
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.
It remains to run the following commands on DC to force synchronizing. Open elevated command prompt and type:
gpupdate /force
w32tm /config /update
net stop w32time && net start w32time
To check the current NTP time sources and their statuses, run the command:
w32tm /query /peers
w32tm /query /source
If you need to guarantee that only the current PDC Emulator is configured with an external NTP source, you should use a Group Policy startup script that determines the current FSMO role holder dynamically before applying the config. This method avoids relying solely on WMI filtering.
Monitor Time Offset
To measure the actual time difference between the DC and an external NTP server, use the following command:
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.
Registry and service restart commands
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
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.
Wrapping up
In essence, configuring a Domain Controller (DC) to synchronize time with an external NTP server is a fundamental yet crucial aspect of managing an Active Directory Domain Services (AD DS) environment. Understanding the importance of time synchronization and the role played by the PDC emulator allows us to see why this configuration is essential. Keep in mind that regular validation using tools such as w32tm /monitor helps identify time sync issues between DCs before they cause authentication or Kerberos-related problems.
In virtualized environments, maintaining a single authoritative time source is especially important because additional sync mechanisms provided by hypervisors can interfere with the AD time hierarchy.
Active Directory’s hierarchical nature, particularly the PDC emulator’s role, ensures that time is consistent across the domain hierarchy, from multiple domain controllers to individual member servers. However, to maintain the highest accuracy and reliability, the PDC emulator should be configured to sync with an external time source.
Network Time Protocol (NTP) is indispensable for accurate and reliable time synchronization, offering a robust solution for maintaining system time across various networks. By configuring the DC to sync with external NTP servers, we harness the power of the NTP protocol to keep our AD environment running smoothly.
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
2 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.