w32time on win 2003 not syncing

Question

We have a Windows 2003 file server with a Windows 2008 R2 DC. For a while this has been working fine, but now the time on the file server is drifting and not synching any more. The file server is a virtual machine. What is funny is that it has a "partner" server on a different site, also a virtual win 2003 machine, which does not have time problems.

Here is a part of the log from w32time on the file server:

150728 13:50:53.4960127s - PeerPollingThread: WaitTimeout
150728 13:50:53.4960127s - PeerPollingThread: waiting 0.564s
150728 13:50:54.0726836s - PeerPollingThread: WaitTimeout
150728 13:50:54.0726836s - Polling peer mypdc.acme.org (ntp.d|192.168.43.12:123->192.168.43.236:123)
150728 13:50:54.0726836s - Peer poll: Max:1024.0000000s Cur:00.0000000s
150728 13:50:54.0726836s - PeerPollingThread: waiting 1024.000s
150728 13:50:54.0726836s - ListeningThread -- DataAvailEvent set for socket 0 (192.168.43.12:123)
150728 13:50:54.0726836s - ListeningThread -- response heard from 192.168.43.236:123
150728 13:50:54.0726836s - /-- NTP Packet:
150728 13:50:54.0726836s - | LeapIndicator: 0 - no warning;  VersionNumber: 3;  Mode: 4 - Server;  LiVnMode: 0x1C
150728 13:50:54.0726836s - | Stratum: 5 - secondary reference (syncd by (S)NTP)
150728 13:50:54.0726836s - | Poll Interval: 10 - 1024s;  Precision: -6 - 15.625ms per tick
150728 13:50:54.0726836s - | RootDelay: 0x0000.1892s - 0.0959778s;  RootDispersion: 0x0000.23FDs - 0.140579s
150728 13:50:54.0726836s - | ReferenceClockIdentifier: 0xC0A8001E - source IP: 192.168.43.30
150728 13:50:54.0726836s - | ReferenceTimestamp:   0xD5D45A701C48D632150728 13:50:54.0726836s -  - 13022948592110486400ns - 150728 13:43:12.1104864s
150728 13:50:54.0726836s - | OriginateTimestamp:   0xD5D45C3E129B6474150728 13:50:54.0726836s -  - 13022949054072683600ns - 150728 13:50:54.0726836s
150728 13:50:54.0726836s - | ReceiveTimestamp:     0xD5D45C3891885320150728 13:50:54.0726836s -  - 13022949048568486400ns - 150728 13:50:48.5684864s
150728 13:50:54.0726836s - | TransmitTimestamp:    0xD5D45C3891885320150728 13:50:54.0726836s -  - 13022949048568486400ns - 150728 13:50:48.5684864s
150728 13:50:54.0726836s - >-- Non-packet info:
150728 13:50:54.0726836s - | DestinationTimestamp: 150728 13:50:54.0726836s - 0xD5D45C3E129B6474150728 13:50:54.0726836s -  - 13022949054072683600ns150728 13:50:54.0726836s -  - 150728 13:50:54.0726836s
150728 13:50:54.0726836s - | RoundtripDelay: 000ns (0s)
150728 13:50:54.0726836s - | LocalClockOffset: -5504197200ns - 0:05.504197200s
150728 13:50:54.0726836s - \--
150728 13:50:54.0726836s - Response received from domain controller mypdc.acme.org authenticated successfully.
150728 13:50:54.0726836s - Peer poll: Max:1024.0000000s Cur:1024.0000000s
150728 13:50:54.0726836s - Response from peer mypdc.acme.org (ntp.d|192.168.43.12:123->192.168.43.236:123), ofs: -05.5041972s
150728 13:50:54.0726836s - 5 Age:5 Ofs:-06.1273581s Dly:+00.0312500s RDly:+00.0956116s Dsp:00.0904750s RDsp:00.1467743s Dst:00.1061000s FDsp:00.3115804s
150728 13:50:54.0726836s - 4 Age:4 Ofs:-05.9394288s Dly:+00.0312500s RDly:+00.0960541s Dsp:00.0786231s RDsp:00.1322479s Dst:00.0942481s FDsp:00.3734060s
150728 13:50:54.0726836s - 3 Age:3 Ofs:-06.1068232s Dly:+00.0312500s RDly:+00.0960236s Dsp:00.0667690s RDsp:00.1476593s Dst:00.0823940s FDsp:00.4880160s
150728 13:50:54.0726836s - 2 Age:2 Ofs:-05.9046802s Dly:+00.0312500s RDly:+00.1008759s Dsp:00.0549171s RDsp:00.1345673s Dst:00.0705421s FDsp:00.4442495s
150728 13:50:54.0726836s - 1 Age:1 Ofs:-06.0798168s Dly:+00.0312500s RDly:+00.1007690s Dsp:00.0430630s RDsp:00.1517487s Dst:00.0586880s FDsp:00.5099345s
150728 13:50:54.0726836s - 0 Age:0 Ofs:-05.5041972s Dly:+00.0312500s RDly:+00.0959778s Dsp:00.0312110s RDsp:00.1405792s Dst:00.0468360s FDsp:00.2549672s
150728 13:50:54.0726836s - W32TmServiceMain: resync req, reg too soon.
150728 13:50:54.0726836s - W32TmServiceMain: waiting 7.619s
150728 13:51:01.6785052s - W32TmServiceMain: timeout
150728 13:51:01.6785052s - TimeProvCommand([NtpClient], TPC_GetSamples) called.
150728 13:51:01.6785052s - NtpClient returned 1 samples.
150728 13:51:01.6785052s - Sample 0 offset:-05.5041972s delay:+00.1272278s dispersion:00.4268454s
150728 13:51:01.6785052s - Intersection successful with 0 dropped samples.
150728 13:51:01.6785052s -   0: Sample:0 SyncDist:804904593 SelectDisp:0
150728 13:51:01.6785052s - Sample 0 chosen. Select Dispersion:00.0000000s
150728 13:51:01.6785052s - ClockDispln:ClockDispln Update: SO:-55018056 KPhO:-89181 *PhO:-54928875 uT:65574 SD:2986169 LI:0 S:6 RDl:1272278 RDs:59197329 TSF:0x2 Spike->Unset
150728 13:51:01.6785052s -   PhCRA:-2 phcT:7972 KPhO:-89181
150728 13:51:01.6785052s - Logging warning: The time service detected a time difference of greater than 5000 milliseconds for 900 seconds.  The system clock is unsynchronized.  This is usually caused by synchronizing from low-accuracy time sources, or by poor network conditions.
150728 13:51:01.6785052s - W32TmServiceMain: waiting 1024.000s

Is my interpretation correct that w32time can not correct the time, as the difference is too large? How can I fix this? I am a bit puzzled to the reasons for this, as the other hosts in the network have no time problem.

It is VM (question updated). With "host time sync" you mean w32time service? — Isaac, Sep 06 '13 at 14:36
No, he means VM guest time synced with the VM host via VMware Tools or Hyper-V Integration Services, or some other Host component that syncs guest time with host time. — joeqwerty, Sep 06 '13 at 14:44
I think MDMarra has, once again, identified the problem. The message is normal if the time is very skewed. You need to correct the time on the VM host machine. It will then correct the client machines. That, or disable host machine time syncing. — Ian Murphy, Sep 06 '13 at 15:34
If these are Hyper-V VM's it's not recommended to disable Host time sync, but you can partially disable it so that the VM syncs it's time with the host upon startup but then syncs with your domain hierarchy afterward. - http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx — joeqwerty, Sep 06 '13 at 16:10
@joeqwerty the recommendation to not disable host time sync assumes that your hosts are also syncing from the same reliable NTP source as their clients. And if you search about, the directory services teams and hyper-v teams disagree on this issue more than once :) I, personally, leave time sync on and configure the Hyper-V hosts to sync from the PDCe just like the guests do, but if you don't do that, time sync can be an issue — MDMarra, Sep 06 '13 at 17:58
@Isaac I mean, do your Hyper-V integration tools or VMware Tools settings tell your guest to sync from the host operating system's clock? If so, is that host clock correct? Or is this server with the time issue a physical box? — MDMarra, Sep 06 '13 at 17:59
the server with the time issue is a vm. I'll check the settings when I am back in the office tomorrow. — Isaac, Sep 08 '13 at 11:55
Yes, the VMware Tools are set to sync the thime with the host clock. I will change that and see what the results are. — Isaac, Sep 09 '13 at 06:50

w32time on win 2003 not syncing

0 Answers0