Windows Time Service : Registry Settings

Configuring a Standalone NtpServer

Ryan Sizemore — Wed, 02 Apr 2008 20:24:00 GMT

Recently, I had a customer ask if they can use w32time as a time source for other computer & devices on their network. The Windows Time Service is fully capable of acting as a time source for anything that is NTPv3 compliant. Before we start firing up w32tm to configure the service, we will examine how the service operate to know if we need to do anything at all.

For the purposes of this exercise, we can think of the time service as being composed of two parts: The 'client piece' and the 'server piece'. The client piece is responsible for locating another time source and keeping the local clock synchronized. When the 'client piece' makes a request for a time sample, the sample that is returned will be used to improve the accuracy of the local clock, assuming that the sample passes all validation steps. The server is responsible for answering requests from other NTP clients. When another computer or device makes a request for a time sample, the 'server piece' will formulate a response based on the clock of the local computer, which is (hopefully) being made more accurate by the 'client piece'. The point here is to show that although the 'client piece' and the 'server piece' are encapsulated into the same service, they can be seen as two separate entires linked together by the clock on the local machine.

By default, the 'server piece' is turned off, but in some cases the w32time service may already be configured to act as a time source (having the 'server piece' turned on). Specifically, if the machine is acting as a domain controller, then the 'server piece' is already turned on. When a machine is promoted to a domain controller, part of the dcpromo process it to enable the 'server piece' time service. You can verify if the server is turned on by running the following command:

w32tm /query /configuration

Keep in mind that you will need to be elevated to run this command. When you execute this, you will get back a laundry list of configuration settings. We are specifically interested in the NtpServer section:

NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)

The third line will specify whether or not the NtpServer (aka the 'server piece') is turned on. If Enabled is 1, then it's on. If you see that Enabled is 0, then it is off. If you aren't running Vista or Server 2008, you can query the registry directly:

reg query HKLM\system\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer

You should see an entry that looks something like the following:

Enabled REG_DWORD 0x1

As before, 1 is on, 0 is off. You can turn on the NtpServer at any time by running the following commands:

reg add HKLM\system\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 0x1 /f

w32tm /config /update

The first command will change the Enabled flag in the registry to 1 (turning on the NtpServer), then the second command will tell the w32time service that the configuration in the registry need to be re-read, to make the changes active. You can confirm that the NtpServer is in fact running by calling w32time again:

w32tm /query /configuration

If you see enabled is 1, then you are good to go. If not, take a look at the registry using either regedit or the reg command to ensure that the change really made it into the registry.

As usual, If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Directory Services section of the Microsoft Technet forums.

Configuring the Time Service: Max[Pos/Neg]PhaseCorrection

Ryan Sizemore — Fri, 29 Feb 2008 01:40:00 GMT

In the last few months of the Windows Server 2008 development, a good friend of mine was discussing a problem they have been seeing with customers. The problem, lovingly titled as the "Large Time Jump" issue involves a machine in the domain (usually the PDC) making a large jump in time, either forward or backwards. Regardless of the direction of the jump, the results are equally catastrophic.

How it all happens

Lets look at how this can happen. Some of the causes are more likely than you think. Here is a quick list:

Hardware changes. It is quite common for a company to have a hardware failure for a DC, even the PDC. Assume a situation where the motherboard in the PDC fails. After the hardware is all installed, the technician boots the machine back up. As hoped, the machine looks to be running just fine. However, the part that the manufacturer shipped out is considered an "after market" part, so the BIOS isn't configured correctly. By default, the BIOS date is set to the manufacture date of the motherboard - sometime in the past. Of course, when the technician gets the new part, he sees that everything looks to be in order, but he neglects to notice that the date it wrong.
Bad external time source. Sometimes, the time source that you are syncing the PDC with (such as a network device, like a high-end router) can get a wild hair and jump to an invalid time.
Bad CMOS battery. Every once in a while, a BIOS battery in a computer will fails. After all, they don't last forever. If the PDC isn't configured to sync with an external time source, it will by default use its own internal clock, which is based on the BIOS clock. A computer cannot maintain it's time across a reboot, so it stores the current time in the BIOS. If the CMOS battery has failed, the time after the reboot will be incorrect.
User error. It is not outside of the realm of possibility for someone to log onto the root PDC and change the clock. It sounds unlikely, but it is still possible.

Fixing the glitch

The real problem here is that in a domain environment, domain controller completely and utterly trust the time that they get from another DC. The root PDC is a special case, but it still counts.

The solution is to do a "sanity check" on the time that any domain controller gets from anywhere. In this way, you are ensuring that if a domain controller gets out of whack, it will not spread that time to other DCs. This is done by setting the MaxPosPhaseCorrection and MaxNegPhaseCorrection values.

MaxPosPhaseCorrection and MaxNegPhaseCorrection limit the allowable offset taken from a time sample. When any instance of w32time polls another machine for the time, it will determine the offset between the time source and itself. This value is known as the "Sample Offset". Before the samples is used by the time service, it will be compared to the phase correction limits. If the sample offset is greater than the phase correction limit, then sample will be thrown out and a "TOO BIG" event will be generated. The event contains all of the information about the time sample, including who sent it. The purpose of doing this is to isolate domain controllers in the network who get into a bad time state. In this way, the other DCs will log and error about the time samples being too big rather than blindly accepting it.

Knowing your limits

The next question is: What is an acceptable limit of phase correction? After much analysis and debate, we are advising a value of 48 hours. If a domain controller receives a sample that says it is more than 48 hours off, either in the future or in the past, the domain controller will throw it out. However, every customer should evaluate their own situation to be sure.

This is advised for both limits, both forward and backwards.

A packaged solution

Here is an example of a registry entry that you can merge on-demand to apply a 48 hour limit to the phase correction:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"MaxNegPhaseCorrection"=dword:0002a300
"MaxPosPhaseCorrection"=dword:0002a300

Configuring the Time Service: Enabling the Debug Log

Ryan Sizemore — Fri, 29 Feb 2008 00:38:00 GMT

The debug log is a powerful tool in the W32Time bag of tricks when you need to figure out why something isn't working. The debug log tell you (for better or worse) what the Time Service is doing under the hood. Where it is connecting to, how long it is waiting between polls, etc.

In Windows Vista/Server 2008, we added the /debug option to the w32tm.exe command. This is the quickest and easiest way to configure the time service, and should be used if possible. A secondary option (if you are running XP/W2k3) is to edit the settings in the registry. Both will have the same effect, but using the w32tm command will keep you from having to get your hands dirty with registry editing. We will take a look at the w32tm command first:

Using the w32tm.exe command

To enable the w32time debug logging:

w32tm /debug /enable /file:C:\windows\temp\w32time.log /size:10000000 /entries:0-300

The command uses the following options:

/debug - This tells w32tm that you will be changing the debug log settings
/enable - We are turning on the debug log (as opposed to turning it off)
/file - Here we are specifying the full path of where the log file will be created; in this case: "C:\windows\temp\w32time.log"
/size: The maximum size of the log file, in bytes; in this case, it is 10 Mb. When the log is full, the w32time service will wrap to the top of the log file
/entries: This field is a mask, where you can mask off certain types of entries. More about this later.

Turning off the debug log is just as easy:

w32tm /debug /disable

Using the registry

In essence, the w32tm.exe command shown above does exactly what we are about to do here. The only real difference is that when you use w32tm, it handles the reloading of the config, which will actually apply the values found in the registry. Since we will now be making the changes ourselves, we will need to reload the config ourselves.

Note: If you just want a quick .reg file that you can modify and merge, skip to the bottom of this post.

To get started, fire up the Windows registry editor:

Start -> Run -> Regedit.exe

Next, browse to the w32time config key, where we keep all of the w32time configuration:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Here, you will be creating the following three keys (if they do not exist):

FileLogName (REG_SZ)
FileLogSize (REG_DWORD)
FileLogEntries (REG_SZ)

Once they are created, go ahead and add the values that you want.

FileLogName should point to the full path where you want to store the log file. C:\windows\temp is the preferred location. Just ensure that a service running as LOCAL_SYSTEM has write access to the directory.
FileLogSize should be the maximum size of the log file, in bytes. Remember to convert to hex as needed 10Mb in hex would be 0x989680.
FileLogEntries is a numerical mask of the entries that you want to have logged in the log file. Each number in the range 1 - 300 represents a particular logging entry, such as polling intervals, packets received, etc. For the sake of simplicity, you should enable all logging. This is really only useful if you need to track a particular entry over a long period of time, and you don't want all of the other logging to clobber your file. Using 0-300 will guarantee that everything possible will be logged.

Once you apply the changes to the registry, you need to tell the w32time service that it needs to re-read the configuration information. To do this, you can use the following command:

w32tm /config /update

Example .reg file

Here is an example .reg file you can modify to simplify the process:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"FileLogName"="C:\\windows\\temp\\w32time.log"
"FileLogEntries"="0-300"
"FileLogSize"=dword:00989680

Configuring the Time Service: NtpServer and SpecialPollInterval

Ryan Sizemore — Wed, 27 Feb 2008 02:11:00 GMT

One of the most talked about configuration options for W32Time has to be the list of time sources that W32Time connects to for synchronization. It is important to note that W32Time will only actively synchronize with one time source at a time, even though you are able to list more than one time source. The reason for this is simple: If your favorite time source goes down, it would be good to have a backup, or possibly a list of backups.

W32Time configures the list of time sources through the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

The NtpServer key is a space-delimited list of time servers, either as DNS address or as IP addresses. Each server in the list can optionally have a set of flags, which are denoted as a hex value at the end of the address, separated by a comma. We will get to the flags in a moment. Here are a few examples of NtpServer values:

time.windows.com,0x01

time.windows.com,0x01 time.nist.gov,0x01 my.time.server.com,0x02

In the first example, we are specifying a time source of time.windows.com, with the 0x01 and 0x08 flags. In the second example, we are specifying 3 time sources, each with a different set of flags (0x01 & 0x08; 0x01; 0x02 respectively).

Now lets take a look at the flags. We have 4 possible flags:

•	0x01 SpecialInterval
•	0x02 UseAsFallbackOnly
•	0x04 SymmatricActive
•	0x08 Client

For 99% of cases, we only care about the first two options, so that is where we will focus. If you use the SpecialInterval flag, then you need to also set the "SpecialPollInterval" key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\
NtpClient\SpecialPollInterval

Normally, W32Time will poll (make a time request) on a floating interval, based on the quality of the time samples being returned by the time source. You can however specify a static interval that the time service will syncronize on. This value is in seconds. For example, if you set a of 3600, the time service will syncronize every hour (60 minutes * 60 seconds).

The second flag is the UseAsFallbackOnly option. Setting this flag will tell the time service that you want to try every other time server specified before trying this one.

That wraps up this one. As usual, If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Directory Services section of the Microsoft Technet forums.

What is Windows Time Service?

Ryan Sizemore — Sun, 08 Jul 2007 05:40:00 GMT

Welcome to the Windows Time Service blog. This blog is here to answer some of the questions about the service and show off some of the useful features that it has. Every week, I will try to cover a new topic surrounding Windows Time Service (w32time for short). If anyone has any requests/suggestions for topics, please feel free to let me know. This blog is for you.

So what is Windows Time Service?

In short, it is a Windows service that keeps your computer clock accurate. Of course, the "how" is much more interesting than the "why", but for the sake of being the initial post, I will start with why time service exists; and for that, we require a bit of history. NOTE: Most of the information about the history of w32time comes from previous knowledge, which is not very extensive. If you find a mistake, please let me know.

In the days of Windows NT 4.0 and prior, there actually wasn't NTP support, but rather SNTP. This was an initial version of the time service that focused on basic time synchronization (I believe the service was called TimeServ). SNTP doesn't support most of the features of the full NTP protocol, which would be needed in future versions of Windows.

Windows 2000 brought about a wealth of new features, including Kerberos authentication. As part of the Kerberos protocol (section 1.6, 4th bullet of the RFC), computers using Kerberos authentication need to have clocks that are "loosely synchronized", which is defined as 5 minutes by default. To meet this need, SNTP was abandoned and w32time was born. From Windows 2003 though Vista/Windows Server 2008, w32time has been upgraded & retrofitted to support more features, differing environments, and basically meet whatever needs customers and other internal components have.

How does Windows Time Service work?

Well, without getting into some of the messy details, w32time communicates with other computers in your network to keep the time on your local computer accurate. The overreaching goal is to keep your local clock in step with a remote clock. In this way, w32time is synchronizing your computer's clock to that of your time source. (Keep in mind that most of this information can also found in the NTP v3.0 RFC, which w32time is based on). This is done by sampling the time on a remote system (known as the time source). The communication between a time client and a time source looks something like this:

The time client makes a request for a timestamp at time t1
The time source receives the request a time t2
The time source sends back a response a time t3
The time client receives the response a time t4

This is the fundamental interaction between a time client and a time source. The astute reader would first ask the following question:

Well, if the 2 computers are not currently synchronized (which is the point of this communication in the first place), then how can those time values (t1 - t4) be useful at all?

This is a great question because it demonstrates the ingenious design of NTP to be computer independent. Without making assumptions about the relationship of the time source and time client, we can make these initial observations:

(t4 - t1) is the total time that is took for the time source to send out a request and get back a response (transit time)
(t3 - t2) is the total time that the time source spent processing the request (processing time)
((t4 - t1) - (t3 - t2)) is the total transit time of the request (transit time - processing time)

Using this, we can make the following additional observation:

((t2 - t1) + (t3 - t4)) / 2 is the clock offset between the two computers

[EDIT: The above formula has been corrected. Thanks occulations]

Now that we have the clock offset, we can start to correct the clock on the local computer (the time client). Correcting the time on a computer can be done in two ways: skewing and setting. If the time difference is small enough*, we can adjust the clock gradually over time. However, if the time difference is too large* (such as hours or days), it is better to simply set the local clock to the desired time.

* The concept of "too large" or "too small" is relative. These values are adjustable in the registry so that you can control when w32time skews, sets or does nothing at all.

The relationship between w32time and local clock (yes, they are two distinct entities) is complicated and will be explained in a later post.

Time source selection

Aside from how the service determines the time difference, the next most common question is: How does w32time choose a time source (known as a peer)? The service can operate in one of two possible modes:

NTP (as defined in the original RFC)
NT5DS (using domain lookup mechanisms)

The NTP mode is straight-forward: Try to sync with the peer specified. If you can't, wait until you can. This is the mode that non-domain joined computers use. The DNS name or IP address of the peer can be changed in the registry, but it comes as 'time.windows.com' by default. Microsoft hosts its own NTP server, which is how your computer gets correct time "out of the box".

Domain joined computers utilize the NT5DS mode. This mode uses netlogon API calls to find an eligible peer to sync with. Because domains can become both large and deep, and w32time needs to operate in an optimal fashion either way, there is a complex algorithm that is used to find a peer. I will be covering this later in a seperate post (since it is such a large and involved topic), but you can find a reasonable explaination at TechNet for Windows Server 2003. Here is the quick overview:

Computers sync with DCs, preferably from their own site/domain
DC sync with local PDC, but will go out of site/domain if needed
PDCs sync with other PDC, but possible DCs higher up in the forest if needed

At the top of the forest (at the root domain), there needs to be either a local time source or a link to an external peer that provides reliable time data. Again, this really needs a long discussion to make proper sense, but in essence the domain needs to get its time data from somewhere. The w32time service is responsible for distributing the time throughout the domain, but it needs to go to another source to get the data to distribute in the first place.

Wrap Up

This should give you a brief look at the Windows Time Service and how it works. If you have topic ideas, please let me know. I'm only one man, and this isn't the Shell Blog. I have a list (and it is growing) for future topics, but if the community feels that one or more issues are more important, I will do my best to cover them first. As I said in the beginning, this blog is for you.