Configuring the Windows Time Service

by [Published on 18 Nov. 2004 / Last Updated on 18 Nov. 2004]

This article walks you through the process of setting up an authoritative time server for a Windows Server 2003-based network running Active Directory. The article outlines procedures for syncing to both an internal and external time source, and also lists additional resources for configuring the Windows Time service and troubleshooting time synchronization problems.

The Windows Time service (W32Time) is designed to maintain date and time synchronization for computers running Windows 2000XP/2003. The primary use for such time synchronization is to ensure the security of Kerberos authentication within an Active Directory environment. To prevent replay attacks, Kerberos tickets presented to domain controllers by clients are time-stamped. The authenticating domain controller checks to make sure the timestamp is unique and falls within an allowable skew before accepting the ticket and authenticating the client. To ensure this system works properly, both the client and the domain controller clocks must be loosely synchronized within the allowable skew, and W32Time ensures this is the case.

W32Time is based on the Simple Network Time Protocol (SNTP) as specified in RFC RFC 1769 (now superceded by RFC 2030). SNTP is designed to ensure loose synchronization only, which in the W32Time implementation means the clocks of all Windows 2000/XP/2003 machines in a forest will agree within 20 seconds of one another (or 2 seconds difference within a particular site). W32Time expresses clock times in Coordinated Universal Time (UTC), an atomic time scale previously known as Greenwich Mean Time (GMT). W32Time is started by default on Windows XP and Windows Server 2003 machines regardless of whether they belong to a workgroup or a domain. On Windows 2000 however, W32Time must be manually started on machines belonging to a workgroup.

Time Hierarchy

W32Time synchronizes clocks within a forest using a time hierarchy that begins with the PDC Emulator in the forest root domain, which is considered the stratum 2 time source for the forest. This domain controller can have its own clock controlled several ways:

  • By synching to a reliable time server on the Internet.
  • By synching to an locally-connected hardware time source such as an atomic clock.
  • By relying on its own internal CMOS clock for reliable time.

In the first two examples above, the Internet time server or atomic clock is considered a stratum 1 time source. Other domain controllers in the forest root domain and PDC Emulators in child domains use W32Time to poll the PDC Emulator in the forest root domain periodically to ensure their clocks remain synchronized. Workstations and member servers then poll domain controllers in their domains to synchronize their own clocks, with the result being that all computers in the forest synchronize their clocks, either directly or indirectly, with the PDC Emulator in the forest root domain (and hence the external time server or atomic clock, if present). The following table summarizes how the W32Time hierarchy works, starting from the external source.




Locally connected hardware clock (optional)

Internet time server (optional)


PDC Emulator in forest root domain


Other domain controllers in forest root domain

PDC Emulators in child domains


Workstations and member servers in forest root domain

Other domain controllers in child domains


Workstations and member servers in child domains

The polling process is initiated when W32Time starts on the client and is repeated every 45 minutes by default. If clocks are determined to be synchronized for three consecutive polls, the polling interval is increased to every 8 hours.

Because of changes in the operation of the Windows Time service, the remainder of this article focuses on time synchronization in an Active Directory environment where domain controllers are running Windows Server 2003. For information about configuring W32Time in a Windows 2000 domain controller environment, see the following white paper from Microsoft.

Synching to an Internal Time Source

The simplest solution to time synchronization in an Active Directory environment is to let the PDC Emulator in the forest root domain use its own CMOS clock as the source of reliable time for the forest. To do this, you can simply take no action. The only annoying result is that you will occasionally see the following event logged to the System log in Event Viewer:

Event ID: 12

Event source: W32Time

Event description: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.

Basically, what this event means is that the PDC Emulator in the forest root domain has not been configured to synchronize its clock with an external stratum 1 time source, and as a result the clocks on all machines in your forest cannot be considered reliable. Now this may be an issue if employees rely upon their workstations’ CMOS clocks for signing in and out, but as far as Kerberos is concerned it’s a non-issue because Kerberos only requires that clocks on clients and authenticators agree with each other, not that they display accurate time. So if every machine’s clock in the forest is one hour late, Kerberos will still work fine and replay attacks will be prevented, which is the purpose of W32Time anyway.

Synching to an External Time Source

If you want to ensure that the clocks on your machines are more accurate in terms of absolute (and not just relative) time, you can sync the PDC Emulator in your forest root domain to one of the reliable time servers available on the Internet. This is a good idea if your company is a large enterprise with sites spanning several countries, or if your organization has two or more forests linked by forest trusts. The procedure for doing this on a PDC Emulator running Windows Server 2003 in the forest root domain is as follows. Open Registry Editor (regedit.exe) and configure the following registry entries:


This registry entry determines which peers W32Time will accept synchronization from. Change this REG_SZ value from NT5DS to NTP so the PDC Emulator synchronizes from the list of reliable time servers specified in the NtpServer registry entry described below.


This registry entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change this REG_DWORD value from 10 to 5 here.


This registry entry specifies a space-delimited list of stratum 1 time servers from which the local computer can obtain reliable time stamps. The list may consist of one or more DNS names or IP addresses (if DNS names are used then you must append ,0x1 to the end of each DNS name). For example, to synchronize the PDC Emulator in your forest root domain with, an open-access SNTP time server run by the United States Naval Observatory, change the value of the NtpServer registry entry from,0x1 to,0x1 here. Alternatively, you can specify the IP address of this time server, which is instead.

Now stop and restart the Windows Time service using the following commands:

net stop w32time

net start w32time

It may take an hour or so for the PDC Emulator to fully synchronize with the external time server because of the nature of the polling method W32Time uses. Depending on the latency of your Internet connection, the accuracy of the CMOS clock on your forest root PDC Emulator may be within a second or two of UTC. If you need more accurate time however, you can purchase a hardware time source like an atomic clock and connect it to your PDC emulator.

Alternatively, if you don’t want to wait for time convergence to occur between your stratum 2 time server (your forest root PDC Emulator) and the external stratum 1 time server, you can run the following command on your PDC Emulator:

w32tm /resync /rediscover

There are additional registry settings you can configure to ensure external time synchronization operates effectively, see this article in the Microsoft Knowledge Base for details.

Additional Resources

The following resources can be of use in configuring and troubleshooting operation of the Windows Time service in Windows-based environments:

  • How to configure an authoritative time server in Windows Server 2003 - This KB article outlines in further detail how to sync your forest root PDC Emulator to both internal and external time sources. It also has several tips for troubleshooting time synchronization problems involving W32Time.
  • How to configure an authoritative time server in Windows XP - This KB article is useful if you need to sync standalone XP machines to an external time source.
  • Windows Time Service Tools and Settings - This section of the online Windows Server 2003 Technical Reference describes the tools, registry settings, and Group Policy settings that can be used for configuring the Windows Time service.
  • USNO NTP Network Time Servers - This page on the website for the Time Service Department of the United States Naval Observatory lists the different stratum 1 external time servers operated by the USNO that you can use to establish reliable time on your Active Directory-based network. 

Final Tip

Be sure to open UDP port 123 on the firewall at your network’s edge if you are syncing your forest root PDC Emulator to an external time source on the Internet. This is because UDP port 123 is the default port used by SNTP, which is the protocol used by W32Time for time synchronization over a network. Furthermore, if you have deployed Windows XP Service Pack 2 then you need to ensure UDP port 123 is also opened on Windows Firewall on your desktop machines as well.

See Also

The Author — Mitch Tulloch

Mitch Tulloch avatar

Mitch Tulloch is a well-known expert on Windows Server administration and cloud computing technologies. He has published over a thousand articles on information technology topics and has written, contributed to or been series editor for over 50 books.


Featured Links