Psst! Hey buddy, you got the Windows Time?

Dec 10, 2010 6 min read

Disclaimer: This article is now very old (in Internet years), so you are at your own risk in heeding any advice herein.

Listen up, Windows domain admins: it’s imperative that you understand Windows Time. Maybe you already know that it’s important because it can break Kerberos authentication, but most Windows admins I’ve met won’t dig any deeper to figure out how it works and how to keep it working. In fact, too many times I’ve walked into a small business client for the first time and found that their previous techies had disabled the Windows Time service thinking that it’s unused and unimportant (hearkening back to the Windows NT days, perhaps).

In this post I’ll try to make it easy for you to do it right—heck, I want to make it easy for me to remember, too!—and give you links to more detailed info for the curious.

Key concept: Time is synchronized through the domain hierarchy

All the Windows computers in your domain must have their times match with no more than 5 minutes* skew or they’ll have trouble communicating (*by default, but this maximum tolerance value is configurable). Oh, and don’t worry about different time zones and such—Windows is generally smart enough to figure that out correctly.

But for the most part, Windows should do the synchronization in the background for you. Every XP/Vista/Win7 client will try to synchronize with the domain controller they first authenticated with, and the domain controllers will try to synchronize with the one DC in their domain which is holding the “PDC Emulator” FSMO role (more on that in a moment), and PDC Emulators in subdomains will sync with those of the parent domain. Thus, you want this master time source configured to sync with a more reliable time source, like one of the publicly-accessible NTP servers on the Internet.

Key concept: The PDC Emulator is the domain’s primary time source

Perhaps somewhere in your MCSE training or Google searches you’ve heard the term “FSMO” (commonly pronounced “fizz-moe”), which stands for “Flexible Single Master of Operation”. I’ll let you read up on it elsewhere if you’re unfamiliar, but suffice it to say that the server or servers in your domain which are hosting any of the 5 FSMO roles are pretty important. One of those roles is called the “PDC Emulator” (here we are back to the NT days again!), and one thing that this computer does alone is be the master time source for the entire domain.

Step 1: Find the PDC Emulator

So in order to configure your domain correctly, you first need to identify your PDC Emulator. You can identify the FSMO roles via the administration tools GUI or, as is my preference, from the command-line:

dsquery server -hasfsmo pdc

Step 2: Configure the PDC Emulator

A lot of Windows people remember the net time command, which allowed you to configure time synchronization with SNTP (“Simple” Network Time Protocol, in contrast to classic NTP). You should forget about it; go ahead, wipe it from your mind because it won’t do you any good. The command you need to know is w32tm.

Typically, I have my PDC Emulator sync up to one of the public NTP servers available at pool.ntp.org; others I know prefer to use US military or university NTP services that have been around since the dawn of the Internet. In any case, you need to use w32tm to tell the server where to get the time, how to set it (that is, manually), and to serve out reliable time to other domain members. I recommend the following command line:

w32tm /config /manualpeerlist:"0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org" /syncfromflags:manual /reliable:yes /update

Oh, and if you’re curious how far off your server’s time is from the sync source, you can use this handy little line to watch it update:

w32tm /stripchart /computer:0.us.pool.ntp.org

Step 3: Configure the domain members

Now you want to ensure that all the other domain members—including domain controllers, member servers, and client PCs—are configured correctly. Generally, the client OSes XP/Vista/Win7 will behave okay by default, but you most want to run this config on the other DCs and member servers. (If you have a login script only for server admin/domain admin accounts, you could put it there.)

w32tm /config /update /syncfromflags:DOMHIER
w32tm /resync /rediscover

The first line tells the system to find its sync source via the domain hierarchy (“DOMHIER”). The second line says, “Now you go find your time server and sync with it. Go ahead, I’ll wait.” If you look in your System Event Log, you should see event ID 37 from the source W32Time which reads: “The time provider NtpClient is currently receiving valid time data from X.”

Errors and Troubleshooting

Here are a couple of the errors you will see in the System Event Log if the time service is not working correctly:

Event ID 24 from source W32Time: “Time Provider NtpClient: No valid response has been received from domain controller after 8 attempts to contact it. This domain controller will be discarded as a time source and NtpClient will attempt to discover a new domain controller from which to synchronize.”
Event ID 29 from source W32Time “The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time.”

The above events often suggest that your PDC Emulator service is either (a) not responding to time requests or (b) not configured correctly—specifically, not configured as a “reliable” source. (Note that even in a correctly-configured environment, you will probably see these messages whenever you reboot the domain controller which holds the PDC Emulator role. In this case, you will probably see event 37 report success a few minutes later, so no need to worry. If you see the message a lot, then something else is broken.)

Troubleshooting steps could include the following:

Ensure that the PDC Emulator is on and responding to network requests like ping.
Ensure that the Windows Time service (w32time) is configured to start automatically and is running on all domain controllers.
Re-apply the configuration on the PDC Emulator and ask it to sync now; check the System Event Logs for errors.
Re-apply the configuration on the domain controller and/or client machines… I don’t quite know why, but sometimes the clients get confused and stop syncing with their closest DC, but resetting these options and resyncing usually resolves it quickly.

FMI: Recommended Reading

Here are a few places you could go to read up on the topic:

What else?

I realize that the increasing use of server virtualization in enterprise data centers adds some more challenges and questions to the time synchronization topic. For example: Should Windows-based virtual guests sync with their VM host, or with their Windows DC? Should the virtual hosts sync with the PDC Emulator or with an external NTP source? I won’t dig into those questions here, but if there is interest I will gladly weigh in on them at a later time. In the meantime, feel free to comment and ask questions on this page. Hope this helps you out!

Windows Administration