Even if you set Windows Time service to Automatic start, it stops within a few seconds. Why? How do you set up Windows Time to behave like it would on a domain client?

Service Trigger Events:  The Japanese Secret

When I noticed that the Windows Time service wasn’t running, I found that it did in fact start when the system started, but then it stopped a few seconds later with this message:

Log Name:      System
Source:        Service Control Manager
Event ID:      7042
Task Category: None
Level:         Information
Description:   The Windows Time service was successfully sent a stop control. The reason specified was: 0×40030011 [Operating System: Network Connectivity (Planned)]  Comment: None

A Microsoft support rep pointed me to a Japanese knowledge base article that (with the help of Google Translate) lifts the veil on Windows Time behavior. In Windows 7 and 2008 R2, Windows Time additionally depends on service triggers to determine whether it keeps running.

http://support.microsoft.com/kb/2385818/ja

http://translate.google.com/translate?hl=en&sl=ja&u=http://support.microsoft.com/kb/2385818/ja

As you can see by typing

sc qtriggerinfo w32time

Windows Time is stopped if the computer is not domain joined.

I chose their workaround #2, to run Windows Time whenever a network is detected:

sc triggerinfo w32time start/networkon stop/networkoff

Background Research

Here’s the boring background. Skip to the next section for the summary of how to set up Windows Time on a Hyper-V host running a domain controller guest.

At the bottom of the translated Japanese KB article, I saw reference to the Time Synchronization scheduled task. Here we see a task that starts the Time Service once a week. The task_started parameter apparently tells the service to start, sync the time, and stop.

Let’s compare stand-alone and domain-joined behavior, with the help of this TechNet reference.

In a stand-alone (non-domain-joined) machine, we have this setup for Windows Time:

Type:  NTP (uses manual peer)
NtpServer:  time.windows.com,0×1 (0×1 means use SpecialPollInterval)
SpecialPollInterval:  604800 in seconds = 7 days
Windows Time is set to Manual start.  Even if set to Automatic, Windows Time service trigger stops service because not domain joined.
Windows Time service started once a week by scheduled task, stops after time sync.

On a domain-joined machine, we have this setup for Windows Time:

Type:  NT5DS (uses domain controller; NtpServer and SpecialPollInterval have no effect; system determines polling frequency)
MinPollInterval:  10 in Log(2) seconds = 2^10 = 1024 seconds = 17.1 minutes
MaxPollInterval:  15 in Log(2) seconds = 2^15 = 32768 seconds = 546.1 minutes = 9.1 hours
Windows Time service trigger does not stop service; Windows Time always running.
Windows Time service started once a week by scheduled task, ends with 0×420 ERROR_SERVICE_ALREADY_RUNNING.

Set Up Windows Time on a Hyper-V Host Running a Domain Controller Guest

If your Hyper-V host has a domain controller as a guest, here’s how to set up Windows Time. All commands apply to the host.

1. In Hyper-V Server Manager, go to the Settings for your domain controller guest and disable Time Synchronization. (This assumes the domain controller guest is configured properly to sync time with an external source.)

2. Open an administrative command prompt on the host and tell Windows Time to run as long as the network is available:

sc triggerinfo w32time start/networkon stop/networkoff

3. In services.msc, set Windows Time Startup Type to Automatic. Start the service.

4. Still at the command prompt, set Windows Time to retrieve time from the guest:

w32tm /config /manualpeerlist:DC_server_IP_Address,0x8 /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync

The Results

After running those commands, we hopefully have a server that simulates a domain-joined client:

Type:  NTP (uses manual peer)
NtpServer:  DC_server_IP_Address,0×8 (0×8 means act as client; system determines polling frequency)
MinPollInterval:  10 in Log(2) seconds = 2^10 = 1024 seconds = 17.1 minutes
MaxPollInterval:  15 in Log(2) seconds = 2^15 = 32768 seconds = 546.1 minutes = 9.1 hours
Windows Time service trigger lets service run when network is connected, so Windows Time always running.
Windows Time service started once a week by scheduled task, ends with 0×420 ERROR_SERVICE_ALREADY_RUNNING.

Here are the event details. Note that the first one is recorded as an Information event but actually indicates an issue.

Event Type:    Information
Event Source:    W32Time
Event Category:    None
Event ID:    38
Description:
The time provider NtpClient cannot reach or is currently receiving invalid time data from SBS2008Server.mydomain.local (ntp.d|192.168.1.25:123->192.168.1.2:123).

Event Type:    Warning
Event Source:    W32Time
Event Category:    None
Event ID:    24
Description:
Time Provider NtpClient: No valid response has been received from domain controller SBS2008Server.mydomain.local 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 Type:    Error
Event Source:    W32Time
Event Category:    None
Event ID:    29
Description:
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.

Analysis

The SBS machine is the domain controller, so it’s also the default NTP server.

I had already followed Hyper-V best practices for domain controllers by disabling Time Synchronization and setting the SBS machine to sync with an external source. That’s working fine.

Client computers in the domain, both physical and virtual, were not reporting time sync errors even though they also get time from SBS (Type is NT5DS; see how to check this). So why can’t Server 2003 sync time as well?

Microsoft KB 875424, “Time synchronization may not succeed when you try to synchronize with a non-Windows NTP server in Windows Server 2003,” describes the symptoms pretty well except for the “non-Windows” part. But even after putting the Server 2003 machine into “client mode” (/syncfromflags:MANUAL) pointed directly at the domain controller, the time sync errors continued. So I set it back to domain mode (/syncfromflags:DOMHIER).

I turned on time service logging as described in Microsoft KB 816043. Didn’t learn much here except that SBS is returning time packets with Precision: –6, so the issue I had a few years ago with very high precision servers is not the problem here.

Solution

Eventually I noticed that when starting the Windows Time Service, I would get an event indicating that time was being synchronized with the Hyper-V integration services provider:

Event Type:    Information
Event Source:    W32Time
Event Category:    None
Event ID:    35
Description:
The time service is now synchronizing the system time with the time source VM IC Time Synchronization Provider.

A little more Googling and I found this article suggesting that the solution is to disable Time Synchronization on all Hyper-V guests, not just on domain controllers. Once I disabled the Time Synchronization integration service on the Server 2003 machine and rebooted, the errors stopped.

I still don’t know why Hyper-V Time Synchronization integration service causes the standard domain-based time synchronization to fail (why not play nicely together?), but disabling Hyper-V Time Synchronization on all virtual machines seems to solve the problem.

Bonus Tip:  Time Sync on the Hyper-V Server

All the machines above are running on Windows Server 2008 R2 as the Hyper-V host. Follow Microsoft’s recommendation, the host is not joined to the domain since the domain controller is running as a guest. To keep the host’s time in sync, I set it to client mode and pointed it at the SBS domain controller. This command sequence does the trick:

sc triggerinfo w32time start/networkon stop/networkoff
w32tm /config /manualpeerlist:SBS_server_IP_Address,0x8 /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync


Note:  If you get a message that the Windows Time service is not running, from services.msc, set it to Automatic and start it. For more details, see this later blog post.

Some time ago, I set up two NTP time sources for my Windows 2003 / SBS 2003 domain controllers:  time-nw.nist.gov in Redmond, Washington, and time-a.nist.gov in Gaithersburg, Maryland.

I noticed that the machines don’t ever seem to sync with time-nw.nist.gov. I keep getting W32Time errors:

Event ID: 38
“The time provider NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov”

Event ID: 47
“No valid response has been received from manually configured
peer time-nw.nist.gov,0×8 after 8 attempts to contact it.”

However, my second source, time-a.nist.gov, usually works, so the servers’ times are still in sync:

Event ID: 37
“The time provider NtpClient is currently receiving valid time data from time-a.nist.gov”

I tried replacing  time-nw.nist.gov with a couple other servers from the NIST’s list of public servers, but the other two options failed as well. What’s going on here? Only one clock in the country works? Finally I came across this thread on a Channel 9 forum.

On April 25, 2007, “PeterInSydney” turned on w32time logging (here’s how), and discovered that the w32time client was rejecting time with a “precision” value of -31. A Microsoft employee in Redmond, Matthew van Eerde, confirmed that this is a bug in the w32time client:  “The w32time client incorrectly rejects packets with precision < -30.” Van Eerde followed up on April 27 with a very helpful summary of what situations are broken (basically any XP or Win2003 machine trying to talk to a “very high-precision” server). The April 27 post mentions that, “Recently (March time frame) time.nist.gov became ‘very high
precision.’” The workaround is to use a lower-precision server.

Sure enough, when I turned on w32time debugging on my server, I see that time-nw.nist.gov is also returning a -31 precision, whereas time-a.nist.gov is still “only” -30. That explains why only time-a.nist.gov is working.

Pardon the pun, but isn’t this a time bomb waiting to explode? So far I haven’t been able to find a list of which servers offer what level of precision. But if the NIST servers are gradually being upgraded to higher precision, won’t the Windows machines that rely on them eventually be left high and dry?

The Hotfix 

Fortunately, reading further in the (four-page) Channel 9 thread, on September 4, Microsoft’s van Eerde announced that a hotfix for Windows Server 2003 is available:

The Windows Time service in Windows Server 2003 does not synchronize time
with a time server if the precision value of the NTP response is less than -30
http://support.microsoft.com/kb/940742

So I submitted an online hotfix request, and in under two hours, the hotfix instructions arrived. Once applied and rebooted, time is now syncing properly with very high precision servers.

Still Getting Errors 

Even though the Windows servers will now sync with very high precision NTP servers, I still sometimes get the 38 and 47 errors. Examing the debug log, this time it is due simply to the NTP server not responding to a query:

Polling peer time-nw.nist.gov (ntp.m|0×8|192.168.1.2:123->131.107.1.10:123)
Sending packet to time-nw.nist.gov (ntp.m|0×8|192.168.1.2:123->131.107.1.10:123) in Win2K detect mode, stage 1.
No response from peer time-nw.nist.gov (ntp.m|0×8|192.168.1.2:123->131.107.1.10:123).
Logging information: NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov (ntp.m|0×8|192.168.1.2:123->131.107.1.10:123).

So even though Windows is now able to handle high precision servers, you still have to find servers that are responsive. I never got time-nw.nist.gov to respond, and time.nist.gov was intermittent. Maybe w32time made too many requests and was blocked by the servers. In any case, I finally found two geographically separated NIST servers that are responding well. Here’s how I set them up (commands adapted from KB 875424):

w32tm /config /manualpeerlist:”nist1.symmetricom.com,0×8 time-b.timefreq.bldrdoc.gov,0×8″ /syncfromflags:MANUAL

net stop w32time

net start w32time

w32tm /resync