Note: This article is written for “modern” versions of the Windows operating system – that is, Windows Server 2008, Windows Server 2008 R2, Windows Vista, and Windows 7. For older versions of the Windows operating system, the concepts still apply, but some of the command line parameters for w32tm have changed.
Windows, especially in an Active Directory environment, requires “good” time. For this discussion, having “good” time means that all members of a domain are capable of synchronizing their clock to a domain controller. Domain controllers synchronize their clocks with the domain controller which holds the PDCe (Primary Domain Controller emulator) role in their Active Directory domain. PDCe’s in child domains synchronize their clocks with the PDCe of the root domain of the Active Directory forest.
When Windows does not have good time, log file entries have incorrect timestamps, event logs have incorrect timestamps, database transaction logs have incorrect timestamps, etc. etc. When the time on a computer becomes too far off from that of a domain controller (more than five minutes above or below), the computer is no longer capable of acquiring Kerberos tickets – this means that a computer and/or a user will not be able to log in to the Active Directory domain, nor will they be able to access any resources on the Active Directory network.
This can happen to user workstations and to servers. Obviously, a server may effect more users than a single workstation; but that doesn’t mean you should pay any less attention to your user workstations.
The “Windows Time” service is responsible for keeping a computer’s clock synchronized. This service can be controlled and configured on each computer by a command line tool named w32tm. Modifying any parameters for the Windows Time service requires local administrator permissions (and if UAC is enabled on the computer, it also requires an elevated command prompt or PowerShell session).
Determining whether a computer can synchronize its clock is easy to test (this is irrespective of whether the correct time source is configured – just that the computer can synchronize to the configured time source). Open an elevated command prompt or PowerShell session, and then enter:
w32tm /resync
Does it work? If so, then this computer can synchronize its clock with its configured time source. If the clock on the computer is off (“skewed” is the typical term used for this situation), then further analysis is required. If the time on the clock is off by an even number of hours, you should probably be looking at the timezone configured for the user or computer, not at the time synchronization sources.
If there are other computers whose time is skewed, then enter the same command on the other computers. The command should work there too.
If the resync commands work, but the computers are getting the wrong time, you need to begin analyzing the configuration for the Windows Time service. From your shell or PowerShell session, enter:
w32tm /query /source
This allows you to determine where the particular computer is getting its time. There are a number of possible responses. These include:
Local CMOS Clock
In this case, the computer is using the hardware clock on the computer as its time source. If you are using VMware, this means that the virtual machine is synchronizing to the VMware host.
Free Running System Clock
In this case, the computer is not using any external source, but depending on the time tick generated by the System Idle Process running on the computer. This value will generate a skewed time more quickly than any other.
a hostname of a domain controller in the Active Directory forest
In this case, the computer is using a domain controller as either an NTP server or as the time source via Active Directory. To determine which, see “/query /configuration”, discussed later.
a hostname of a computer running a NTP server
In this case, the computer is using a non-Active Directory server running an NTP server as its time source.
VM IC Time Synchronization Provider
In this case, the computer is using Hyper-V virtualization services as its time source.
Best practices from Microsoft recommend that you never use virtualization services (regardless of your hypervisor provider) as a time source for domain-joined computer; instead, you should depend on typical Active Directory synchronization methods.
VMware recommends that, for domain-joined computers, you install an NTP server on the VMware host and you have the computers synchronize to that NTP server.
*** Edit on June 25, 2010 – A VMware employee contacted me at the end of May suggesting that the above line was not accurate. Indeed, VMware updated their documentation (the linked VMware KB 1318 article below) in March of 2010. Now, for most intents and purposes, the VMware recommendations match the Microsoft recommendations.
In my mind, you are better off starting with the Microsoft recommendations and then go from there.
Here are references to the above comments and best practices:
Virtual Domain Controllers and Time Synchronisation
Considerations when hosting Active Directory domain controller in virtual hosting environments
Deployment Considerations for Virtualized Domain Controllers
VMware KB: Timekeeping best practices for Windows
Now, if the initial resync command doesn’t work – that particular failure reason is what you need to figure out. The first thing I always check is the firewall configuration. By default, time synchronization requires that that a computer be capable of sending a UDP request to port 123 on the NTP server (and receiving the response). NTP servers also listen on port 123 for TCP requests. The Windows Advanced Firewall in the modern Windows operating systems will automatically have an entry opened for time synchronization on UDP port 123 to your domain controllers. However, if you are configuring your PDC emulator server, you also need to ensure that the external firewall also allows that request. If you have non-domain-joined computers, then you may need to globally allow port 123 requests in your firewall.
The command below will tell you the time source for a particular computer:
w32tm /query /configuration
You are initially most interested in the value of the Type variable which is displayed. There are a number of possible responses. These include:
NTP – the external time source is the NTP server(s) specified by the NtpServer variable
NT5DS – the external time source is the domain hierarchy (that is, time synchronization originates from a domain controller)
NoSync – there is no external time source
AllSync – the computer should use both the domain hierarchy and the manually specified NTP server(s) as external time sources
There may be multiple external NTP servers listed in the NtpServer variable.
To properly set up a time source synchronization hierarchy for your domain, you need to begin by locating the domain controller which holds the PDC emulator FSMO role (obviously, if you have a single domain controller, such as is normally the case in SBS 2008, this process can be shortcut). To determine the holders of the FSMO roles, at that earlier-opened command prompt or PowerShell session, enter:
netdom query fsmo
Next, on the domain controller which is revealed to hold the PDC emulator role, you should do something like this:
w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover
This ensures that this particular domain controller will attempt to synchronize with an external source providing known good time. pool.ntp.org is a common source. Windows computers come configured by default to use time.windows.com, which sometimes works and sometimes doesn’t.
For all other domain-joined computers, the appropriate configuration is:
w32tm /config /syncfromflags:domhier
w32tm /config /update
net stop w32time
net start w32time
W32tm /resync /rediscover
That really should take care of it. /syncfromflags:domhier is the default for domain-joined workstations and should be for all DCs except for the one in the root domain holding the PDCe role.
When a computer is properly synchronizing from an external source (after the Windows Time service restarts or becomes capable of synchronizing after some interval where it can’t synchronize), the following entry is made to the System Event Log:
Log Name: System
Source: Microsoft-Windows-Time-Service
Date: 1/24/2010 1:01:27 AM
Event ID: 35
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: W2008R2-DC
Description:
The time service is now synchronizing the system time with the time source pool.ntp.org (ntp.m|0x0|0.0.0.0:123->69.26.112.120:123).
If the time source is a DC, the DC will be named and its IP address listed, just as if it were an external source.
Until next time…
If there are things you would like to see written about, please let me know.
Follow me on twitter: @EssentialExch
