Windows: The Windows Time Service

<< SQL Server: Malicious triggers | Home | Commerce Server 2002: Reporting — Query Best Practice >>

Overview

The time service is a critical part of any Windows Active Directory infrastructure. Why? Because it is part of how Active Directory replicates correctly, because it supports the implementation of Kerberos and because all your networked computers will be synchronised using it, even if you don't configure it.

Quite often, a seemingly unrelated error message will be caused by time service configuration errors. I've written small guidance notes quite often to help administrators sort out these problems, but I wanted to collect my knowledge into a single blog post so that it is available for everyone.

This knowledge has been accrued over several years, referencing many blogs, Microsoft knowledge base articles and books in production environments. I'll reference what I can, but the rest is straight out of my head...

Normative operation

When working correctly, the time service ensures that all servers and workstations in the Active Directory forest have the correct time configured. See How Windows Time Service Works (Microsoft TechNet) for the authoritative reference on this.

By default, all forest member computers with one exception (more in a moment) will synchronise their clocks to this one authority. The authority is the domain controller in the forest root domain that is configured to be reliable. Normally, this will mean the domain controller that has the PDC-emulator FSMO role.

Communication with the Windows Time Service between computers is authenticated by Kerberos. Kerberos will allow small deviations in clocks but anything more than about 5 minutes is likely to cause an authentication failure, thereby preventing the clock correction that would enable Kerberos authentication! If your clocks are already out of sync, then you will need to adjust them manually. See Basic Concepts for the Kerberos Protocol (Microsoft TechNet) for a conceptual look at Kerberos.

Although the time service can use hardware devices to ensure accuracy, the most common scenario is the use of a public NTP time service.

Symptoms of failure

The following list are common symptoms that may indicate an underlying time synchronisation error:

Outlook 2007 can't connect to Exchange Server. It keeps prompting for credentials. By default, Outlook 2007 uses the Negotiate method for authentication. This results in it using Kerberos rather than NTLM and the client can't connect if the clocks are skewed by five minutes or more. See You are repeatedly prompted to enter your credentials when you try to connect to an Exchange 2003 mailbox by using Outlook 2007 (Microsoft Support)
You can't access some or all network resources
You can't logon to a domain computer that you haven't recently logged on to
Domain trusts aren't working, or replication is failing:
- There are currently no logon servers available to service the logon request
- The trust cannot be validated
- Windows cannot find a domain controller for the ... domain
Group Policy not being applied correctly
Offline Files not synchronising correctly, possibly deleting files

Virtual servers and Windows guests

In general, you should not synchronise the host time and the guest time. If you do, you undermine the operation of the Windows Time Service. This can affect any virtual server solution including Microsoft Windows Hyper-X, Microsoft Virtual Server, Microsoft Virtual PC, VMWare Server, VMWare ESX Server and Xen.

You may be affected by this if you have a hosted solution. Check that your service provider is not attempting to synchronise the clock on the virtual machine.

Configuration

To configure the time service, you first need to find appropriate servers for your root domain PDC to connect to. You can use multiple Internet providers, but ideally they should be in the same time zone as the server. See the following for public NTP server lists:

Next, you need to decide on which flags to use. These flags control how the server will connect to the public NTP server, and are required for correct function. Microsoft documents the use of the 0x1 flag for use with NTP servers specified by a DNS name (such as time.windows.com). However, with these public time servers you typically also need the 0x8 flag which puts the NTP connection into a client mode. See here for reference: Windows Time Service (Microsoft TechNet).

There are several ways in which you can make the changes on the PDC:

Edit the registry directly
Use the NET TIME /SETSNTP command
Use the W32TM command

The service must be restarted after the changes have been made. A typical command looks like the following:

w32tm /config "/manualpeerlist:ntp.domain1.com,0x8 ntp.domain2.com,0x8 ntp.domain3.com,0x8" /syncfromflags:manual

See here W32tm (Microsoft TechNet) for more on the W32TM command.

Note that I haven't used the 0x1 flag in this configuration. I've used this style for many years and it has been successful. If it works, leave it alone :)

Also notice that I've surrounded the manualpeerlist option in quotes and separated the servers with a single space character. This is the correct syntax.

Other considerations

The NTP protocol uses UDP port 123 for both source and destination, so you'd better make sure that the firewall is going to allow the connection. Also, because it is a session-less connection (UDP not TCP), timeouts can be a factor. If you see lots of blocked UDP 123 packets at your firewall, coming from the configured NTP servers, then they are probably late replies. You might need to consider increasing the timeout or creating a static route. This can be quite common.

You might also get the occasional event log entry suggesting that connectivity to one or all NTP servers is down. This may be because the server is down, or because the reply is too late. Infrequent messages like this are nothing to worry about. The time service will log a further event indicating that the connection has been reestablished as soon as it has.

Troubleshooting

Search Microsoft Support (http://support.microsoft.com) for "w32time events" to find many more potential solutions. Also, remember to install service packs. Several issues were resolved with Windows 2000 Service Packs 2 and 3.

Versions