Windows Time Service

Getting ahead of the storm

For those out there who haven't yet heard, VMWare is experiencing a problem (as of Aug 12) with licensing for ESX and ESXi. You can find out more here: http://kb2.vmware.com/kb/1006716.html

The crux of the issue seems to be that a recent update caused the license to expire, preventing any guest OSs from starting. A talked about workaround (see http://www.deploylinux.net/matt/2008/08/all-your-vms-belong-to-us.html) is to disable the NTP client on the host machine and roll the clock back a day or 2. Before embarking on this solution, let me add a word of caution:

The guest OS will take the host OS's time if you are using the 'time synchronization' option for the VMWare guest tool (as recommended by VMWare). This will cause any domain controllers running as a guest OS to roll its time backward. Now, VMWare has promised a solution to the problem by 12:00 PST Aug 13. If you can operate safely without these domain controller, it may be advisable to do so, as opposed to rolling back the clock.

I know this is a hot issue, so I will try my best to stay on top of any questions posted in the comments. Keep in mind, I have no knowledge of VMWare's systems.

High accuracy time, and why we don't support it

To be (reliable) or not to be (reliable)

Of the many things that w32time does, figuring out which host to sync from is one of the most important, and thus, one of the most talked about. In the stand-alone scenario, peer discovery (aka figuring out which host to sync with) is an entirely manual process. W32time chooses a peer based on the contents of the NtpServer registry key, which contains a list of hosts and some optional host-specific flags. However, in the domain-joined scenario, the peer discovery process is almost completely automatic. In a domain, computers inform each other of what "services" they provide through the use of NetLogon flags. Services running on a particular machine can use the NetLogon facility to set these NetLogon flags. W32time makes use of these flags to inform machines on the domain of where to find a time source. 

NetLogon provides two flags that are created specifically for w32time's use. These are the TIMESERV flag and the GTIMESERV flag (note the subtle 'G' at the beginning of the second flag). Note that changing the state of the advertising flags does not stop w32time from sending & receiving requests and responses. This is an important distinction that is overlooked sometimes by even the brightest (myself included). The TIMESERV flag indicates that the machine is currently synchronized and can provide time sync responses. The GTIMESERV flag means that a machine is "special" because it is a "good" source of time. In practice, a machine is declared to be a good source of time when it is directly connected to a reliable time source (such as a hardware clock) or when it is simple the most reliable source of time on the network. For example, a small business might not have the bankroll to afford a $2000 NTP hardware device to synchronize with, so they configure the PDC of their domain to synchronize with the NIST time servers. In this case, the PDC might not be a perfectly accurate time source, but it is in fact the most accurate time source on the domain. You can view flags using the nltest utility. The output should look something like the following:

 D:\Program Files>nltest /dsgetdc:
           DC: \\mydc.mydomain.com
      Address: <some ip>
     Dom Guid: d1e31ae5-fe27-4cbf-9b41-c2d0f6b2c895
     Dom Name: mydomain.com
  Forest Name: mydomain.com
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET
The command completed successfully

Note the TIMESERV flag in the 'Flags' section above. Now that we know a bit about the flags that w32time leverages and how they are used, let's take a look at how we can control these flags.

As discussed in a previous post, the domain hierarchy serves as the base for which peers are selected, with one major (and maybe one or two other small) exception. The AnnounceFlags registry key allows an administrator to control a bit of the peer selection process. This key is a bitwise mask, with the following flags:

• 0x00 Not a time server
• 0x01 Always time server
• 0x02 Automatic time server
• 0x04 Always reliable time server
• 0x08 Automatic reliable time server

0x00 will cause the service to not advertise at all (via NetLogon) as a time service. It will still respond to NTP requests (both NTP and NT5DS types), but other peers will not be able to discover it as a time source

0x01 will cause the service to always advertise as a time server, regardless of its own status

0x02 will cause the service to only advertise as a time source when it is receiving reliable time from another peer, either via NTP or NT5DS

0x04 will cause the service to always advertise as a reliable time source. This is actually the bit that gets set when you use the w32tm command with the Reliable:YES option

0x08 will cause the service to automatically advertise as reliable when the DC is a) the PDC in the root domain of the forest, and b) when it is unable to locate a time source. The reason for this flag is to allow the root domain PDC to self-elect as the authoritative time source for the forest, allowing all other DCs to use it for time.

The purpose of the 0x08 flag dates back to the original design for w32time. The primary goal of the w32time service is to keep all of the clocks in the domain in loose synchronization with each other. As a secondary goal, keep all of these clock also in sync with an external time source. However, it is worth mentioning that the reason for this design is because if the clocks are more than 5 minutes out of sync, Kerberos will fail and problems in the domain will begin to mount.

To be (reliable) or not to be (reliable)

So one of the most common question I get is "When should I use the GTIMESERV flag?" (or other variations on that theme). If you refer back to one of my original posts on how domain synchronization works, I showed the scoring mechanism that w32time uses to decide what machine is the "best" candidate. In the scoring, the highest criteria that is scored is whether or not the machine has the GTIMESERV flag set. The reason is straightforward: The administrator of a network needs to have the ability to override where a machine synchronizes.

The most common situation for using the GTIMESERV flag it to create a reliable time source in the root domain to safeguard against a failed PDC. In a typical situation, the PDC in the root domain is configured to synchronize with an external time source. If the PDC goes down (or the role is transferred or seized), then the new PDC needs to be configured in the same way. In an ideal world, this "moving of configuration" would happen automatically, but we don't live in a perfect world. The new PDC goes into place, and does not sync externally. Eventually, it begins to lose sync with the outside world, and the whole domain suffers.

To safeguard against this, we recommend electing a machine in the root domain as a GTIMESERV, and configuring it to synchronize to your external time source. This will allow the PDC (both the old one and the new one) to correctly pick the GTIMESERV as their time source, keeping the domain always on time.

Configuring a Standalone NtpServer

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

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

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: Enabling the Debug Log

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:

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: NtpServer and SpecialPollInterval

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:

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.

A Tale of Two Clocks

In the very first post, I tried (for better or worse) to summarize the purpose of the Windows Time Service. The goal for this service is to keep the clock in sync with whatever time source the user prescribes. In this post, I will take a more abstract view of W32Time and what it tries to acheive.

The ultimate goal of W32time (or any service that implements NTP) is to keep the local clock synchronized. But what do we mean by "the local clock"? For that matter, what is a clock? These two questions have been the basis for a number of questions I have had to answer, since they are both interesting and confusing.

Back to basics

On every computer, in one form or another, there is a hardware-based clock. This physical device is a component on the motherboard, and consists of two parts. These are:

• A timer, to produce a 'tick' at a regular interval
• A chunk of memory, used to store the current 'tick count'.

The way in which a hardware clock is implemented isn't to store the time as "Nov 3, 2007, 12:44:05 PM". This would not only be inefficient, but computing the date every second becomes time-consuming (pun not intended) and would require a microcontroller to do the processing. A much simpler implementation is to simply store the number of 'ticks' (usually in seconds) since a predefined date. This way, the only thing stored in memory is a counter that tell how many ticks have elapsed since the predefined date (known as an epoch). The epoch is usually set by either the motherboard manufacturer or the BIOS manufacturer.

The other issue to consider with hardware clocks is resolution. For every clock (be it hardware or software), the frequency at which is it updated will determine the resolution of the clock. In most systems, the hardware clock is driven by a oscilator running at 32.768 kHz. This frequency is the magical number for computer-based clocks because it is very easly divisible into 1Hz by counting every 2^15 pulse.

The soft clock

Inside of the operating system, you have another (similar) clock. This clock is known as the "system clock", and it is maintained by the kernel of the OS. For all intents and pruposes, this is the clock that you see when you look at the clock in your system tray, or you call the GetSystemTime(...) API function, or just about any other clock you see on the computer. All of these reference the system clock.

In the hardware clock, a timer is used to tell when to increment the clock. The system clock uses a similar contept, but at a higher frequency. Rather than waiting until 2^15 pulses have elapsed to increment the clock, the kernel increments the clock at a much higher interval. By having the kernel increment the clock (in milliseconds) every 32 pulses, you can very easily acheive a clock with 1ms accuracy.

The operating system maintains its own clock in software, but in a different way. Deep within the kernel of the OS, there is a chunk of memory (much in the same way as the hardware clock) that maintains the tick count since the epoch. However, the epoch for an OS is different that of the hardware clock. The epoch for Windows Operating Systems is Jan 1, 1601 at 12:00:00 AM, whereas the epoch or Unix Operating Systems is Jan 1, 1970 at 12:00:00 AM.

Then there was light...

When Windows loads up (or most any other real-time operating system), the kernel has no idea what time it is. System memory gets wiped clean during reboot/shutdown, and storing the time on the hard drive is just a bad idea. During the startup sequence, the kernel will grab time from the hardware clock, and proceed using that time. It will then increment the system clock as explained above. In a perfect world, this would be the end of the story.

However, we don't live in a perfect world. A hardware clock is only accurate to the second, and w32time (or NTP in general) can achieve accuracy better than 1 second, so the clock will always be able to be more accurate than just using the time provided by the hardware clock alone. Let's put this all together to see how the clock behaves when the machine is starting up.

1. The machine is off. The current time is held in the hardware clock, and it only accurate to the second
2. The machine is turned on. At some point during startup, the kernel reads the time from the hardware clock and starts increments it all on its own.
3. Once the machine has been up and running, the w32time service starts and attempts to discipline the clock (to make it more accurate).
4. Duing shutdown, the w32time service writes the current time back to the hardware clock, so as to preserve as much of the accuracy as possible that was garnered while w32time was running.

Conclusion

So in this article, we took a look at the basic operations of clock in a computer. Hopefully you have some insight into how these two clocks interact during startup and shutdown. 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 Windows Vista Applications section of the Microsoft Technet forums.

Disclaimer

The information and metrics listed above are general principals I have personally gathered over the years. This information is not to be taken as a guide as to how the Windows kernel operates; they are generic principals used to illustrate the concepts in this article. New advancements in computers, such as High Performance Event Timers (HPET), can change things around quite a bit.

Keeping the Domain On Time

Windows Time Service on a domain (referred to as 'Domain Synchronization' or 'Domain Sync' for short) is a huge topic. I will do my best to cover all of its aspects in this article, but some concepts won't be covered until a later date, and others still relate directly to the original RFC for NTP.

Background

As I stated in my previous post, the original reasons for developing w32time stemmed from the requirements imposed by Kerberos. In order for Kerberos to function securely, the time difference between the participating machines needs to be less than five minutes. In time, other components have come to rely on w32time, including Active Directory Replication and Windows Update. In a Windows domain, w32time needs to keep machines synchronized, and it needs to do so in a quick, efficient, and quiet manner.

Beyond NTP

The NTP protocol described in the RFC goes a long way toward designing a robust time synchronization solution. But in the end, what we are really interested in is just that: the solution. Keeping time synchronized between two machines is possible, but the solution needs to be more robust to deal with computers belonging to a domain. In particular, w32time works to answer these questions (just to name a few):

• How do we ensure that in a large network of computers, an efficient chain of time sources is picked?
• How do we auto-configure so that an administrator has to do a minimal amount of work to set it up?
• How do we keep it secure and still auto-configurable?
• How do we allow administrators to get a look at what is happening?
• How do we alert the administrators when something goes wrong?

These questions are important, specifically in the domain scenario (as opposed to the home user scenario), since the needs of the home user and the needs of the domain user are quite different.

Designing Inside the Box

Because many components within Windows depend on w32time to keep the clock synchronized, w32time cannot take (hardly) any dependencies itself. If w32time relied on component X to do something fancy, and component X relied on Kerberos, then we would have a problem, since Kerberos relies on w32time. This would create a circular dependency and, well, that's a bad thing.

For this reason, w32time has a simplified mechanism to authenticate time syncs. More information on the authentication mechanism will be covered in a future post.

Intelligent Design 

The first issue to address is finding someone to synchronize with. Each machine needs to sync with another machine to get its time. To do this efficiently and automatically, w32time uses the domain hierarchy created with the domain itself. In the simplest frame of mind, a domain consists of the following distinct entities (aka computers):

• Exactly one primary domain controller (or PDC-emulator)
• Zero or more replica domain controllers (DCs)
• Zero or more member computer (either server or workstations)

The inner working of what a domain is and how it operates is beyond the scope of this post, but this should be enough to provide the groundwork for our discussion.

Time Source Selection

Each member of the domain follows a different set of requirements, based on its role. Lets take a look at those roles:

• Primary Domain Controller - This machine is the authoritative time source for a domain. It will have the most accurate time available in the domain, and must sync with a DC in the parent domain (except in special cases).
• Replica Domain Controller - This machine will act as a time source for clients and member servers in the domain. A DC can sync with the PDC of its own domain, or a DC or PDC in the parent domain.
• Clients/Member Servers - This machine can sync with any DC or PDC of its own domain, or a DC or PDC in the parent domain

These are the default rules of where a machine can go looking for a time source. Keep in mind that there are corner cases where the rules can be bent a little. A few additional rules:

• A machine can only look for a time source in its own domain or the parent domain. A machine will never go to a domain on a parallel level, or a "skip-level" parent domain.
• Within a domain, a machine cannot sync with its own kind. A DC cannot sync with another DC. A client cannot sync with another client.

Also, you may have noticed that a PDC can only sync from a DC or PDC in the parent domain. Well, what if you are in the parent domain already? This is a special case, which is detailed below in the section "Special Case: The Root PDC".

The time source selection mechanism works great to enumerate the possible machines to sync from. The problem is that this usually leaves more than one machine as a possible partner. We need a way to pick the "best" one of the group, and that is what scoring does for us.

Score!

Each possible machine is given a score, based on certain criteria. Once all of the candidates have a score, w32time simply chooses the machine with the highest score. Here is what the scoring looks like:

• 8 points if the machine is in-site
• 4 points if the machine is "reliable"
• 2 points if the machine is in the parent domain
• 1 point if the machine is a PDC (or PDC emulator)

So why are these points given? Let's look at the rules individually. Machines that are in the same site as the one in question have the best chance of providing us with good time.

• Machines that are out of site probably are disconnected physically in one way or another, and would likely introduce delay.
• A machine that is "reliable" is pre-configured to be directly connected to a reliable time source, such as a GPS or atomic clock. These devices provide very accurate, very stable time samples. If a machine is configured to sync directly with one of these devices, a registry value can be changed to indicate that this machine will be a source of reliable time.
• A machine higher in the forest will be closer to the root, and hence will have more accurate time than a machine in the current domain.
• A PDC (or PDC-emulator) will be more accurate than a DC in the same domain because it is guaranteed to sync with a machine in the parent domain.

From this, we can derive a score for each machine, and then choose the machine with the highest score.

Examples

When a machine boots up, it will go looking for a time source. Depending on its role, it will be required to choose from a subset of possible machines to sync with. But how do we prioritize between the available choices? Lets take a look at the following example:

Example 1:

This example utilized the graphic above. The domains will be referred to as the "Left Domain", the "Right Domain", and the "Parent Domain". 

Computer foo has just been joined to the Left Domain as a regular client (not a DC), and it booting up for the first time on a domain. First, we need to enumerate which machines are possible as partners to sync with. We will look at each machine to see if it is a possible sync partner.

• "Domain Controller" [Left Domain]  is a DC in the same domain, so it is a valid choice
• "PDC Emulator" [Left Domain] is a PDC in the same domain, so it is a valid choice
• "Domain Controller" [Parent Domain] is a DC in the parent domain, so it is a valid choice
• "PDC Emulator" [Parent Domain] is a PDC in the parent domain, so it is a valid choice

Which machines aren't valid? Let's take a look (and find out why)

• "Workstation" [Left Domain] is not a DC, so it is not a valid choice
• "Server" [Left Domain] is not a DC, so it is not a valid choice
• "Workstation" [Parent Domain] is not a DC, so it is not a valid choice
• "Server" [Parent Domain] is not a DC, so it is not a valid choice
• Anything in the [Right Domain] is not in the same domain, and not in the parent domain, so it is not a valid choice

Ok, so we have our possible choices, but now we need to prioritize them to pick the best one. To do this, we will utilize the scoring system. Assuming that our entire forest is in one site, and we don't have any machines configured as "reliable":

• "Domain Controller" [Left Domain]  Score = 8
• "PDC Emulator" [Left Domain] Score = 8 + 1 = 9
• "Domain Controller" [Parent Domain] Score = 8 + 2 = 10
• "PDC Emulator" [Parent Domain] Score = 8 + 2 + 1 = 11

So there we have it. The PDC in the parent domain will be our time source. But what if the [Left Domain] was put into a separate site?

Example 2:

Assume the same scenario as the above example, except that [Left Domain] exists in a different site from the rest of the forest. We will use the same logic applied above to determine a time source.

So the [Left Domain] is in a different site. Since the first part of time source selection does not take site location into consideration, we will get the same possible machines to sync with. However, the scoring system will provide us with a different machine when all is said and done. Lets look at how the scoring would now occur:

• "Domain Controller" [Left Domain]  Score = 8
• "PDC Emulator" [Left Domain] Score = 8 + 1 = 9
• "Domain Controller" [Parent Domain] Score = 2 = 2
• "PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

Because the DC and PDC in the [Parent Domain] are in a different site, they don't get the +8 to their score. This leaves us with the PDC of the current domain, with a score of 9. But what about the PDC of the [Left Domain]?

Example 3:

Assume the same scenario as Example 2, Again, we will use the same logic applied above to determine a time source. 

With the left domain in a different site from the rest of the forest, and with the PDC of the [Left Domain] being the authoritative time source for the [Left Domain], we will need to go out of site for a time source - we have no other choice. So we will look at the scores for the various eligible time sources:

"Domain Controller" [Parent Domain] Score = 2 = 2
"PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

We cannot sync with any time sources in our own domain, so we only have the time sources from the [Parent Domain]. The scoring will give us the PDC of the [Parent Domain].

Plan B: Fail over

So what happens when things don't go as planned? Windows Time Service has been built to handle fail over situations from the beginning. For a generic example, assume that a client is currently synchronizing with a time source. If the time source goes away for one reason or another, the client will need to go looking for another time source.

For this reason, we use the scoring system illustrated above. The client will reassess the available time sources, score each of them, and choose the best one. Since the previous time source (which was probably the best first choice) has gone away, w32time will pick the next highest scoring time source.

Special Case: The Root PDC

The PDC for the domain at the root of the forest (the root PDC) poses a problem. Since it has no time sources that are more authoritative than it, it cannot choose a time source automatically. Thus, the administrator will need to set one up manually, or the domain will operate in a "standalone" mode. In the case of a standalone domain, the root PDC will still be the authoritative time source, but its time will come from its own clock.

Wrap Up

We have taken a look at how w32time operates in a domain at a very high level. Future posts will dive deeper into specific areas of w32time, and this will provide a groundwork for those other articles. 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 Windows Vista Applications section of the Microsoft Technet forums. One way or another, questions posted there should make their way to my inbox, and I will do my very best to answer them.

References

1. http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true

We don't measure time. We define it.

It sounds a bit egotistical, but in fact, it is quite correct. I was recently reading an interesting article on the Discover Magazine website. If you have the time on your hands, I would recommend reading the original article (linked at the bottom). Here are a few excerpts:

 “I recently went to the National Institute of Standards and Technology in Boulder,” says Lloyd. (NIST is the government lab that houses the atomic clock that standardizes time for the nation.) “I said something like, ‘Your clocks measure time very accurately.’ They told me, ‘Our clocks do not measure time.’ I thought, Wow, that’s very humble of these guys. But they said, ‘No, time is defined to be what our clocks measure.’ Which is true. They define the time standards for the globe: Time is defined by the number of clicks of their clocks.”

Rovelli, the advocate of a timeless universe, says the NIST timekeepers have it right. Moreover, their point of view is consistent with the Wheeler-DeWitt equation. “We never really see time,” he says. “We see only clocks. If you say this object moves, what you really mean is that this object is here when the hand of your clock is here, and so on. We say we measure time with clocks, but we see only the hands of the clocks, not time itself. And the hands of a clock are a physical variable like any other. So in a sense we cheat because what we really observe are physical variables as a function of other physical variables, but we represent that as if everything is evolving in time.

Very interesting indeed.

Link to the original article

PS: This blog isn't dead. I've been extremely busy, and the upcoming articles are quite detailed, so they are taking a considerable amount of time to produce. More to come, I promise.

What is Windows Time Service?

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:

1. The time client makes a request for a timestamp at time t1
2. The time source receives the request a time t2
3. The time source sends back a response a time t3
4. 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.