My Scripts and Tips

The time on my PC at work has been gradually getting out of wack. So I took a look at the PDC Emulator (PDCe)in the root of our Active Directory forest and found lots of W32Time errors like:

The time provider NtpClient cannot reach or is currently receiving invalid time data from 192.168.1.1 (ntp.m|0x8|172.16.1.1:123->192.168.1.1:123).

192.168.1.1 is a Windows Server 2003 machine in our DMZ. The DMZ server synchs the time with time.windows.com and the PDCe synchs the time with the DMZ server. This used to work fine (well after many teething problems) when the server in the DMZ ran Linux. However, since moving the function to a Windows server it seems to have failed.

Looking at the debug logs (see the entries for the various filelog registry keys for information on enabling logging) I found the following errors:

149095 16:21:16.1250000s - ListeningThread -- response heard from 192.168.1.1:123 149095 16:21:16.1250000s - /-- NTP Packet:
149095 16:21:16.1250000s - | LeapIndicator: 3 - not synchronized;  VersionNumber: 3;  Mode: 4 - Server;  LiVnMode: 0xDC
149095 16:21:16.1250000s - | Stratum: 0 - unspecified or unavailable
149095 16:21:16.1250000s - | Poll Interval: 15 - out of valid range;  Precision: -6 - 15.625ms per tick
149095 16:21:16.1250000s - | RootDelay: 0x0000.0000s - unspecified;  RootDispersion: 0x0001.0400s - 1.01563s
149095 16:21:16.1250000s - | ReferenceClockIdentifier: 0x00000000 - unspecified
49095 16:21:16.1250000s - | ReferenceTimestamp:   0xCD676E70C58C64FD149095 16:21:16.1250000s -  - 12881592560771673500ns - 149092 12:09:20.7716735s
149095 16:21:16.1250000s - | OriginateTimestamp:   0xCD6B9DFC20000000149095 16:21:16.1250000s -  - 12881866876125000000ns - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | ReceiveTimestamp:     0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - | TransmitTimestamp:    0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - >-- Non-packet info:
149095 16:21:16.1250000s - | DestinationTimestamp: 149095 16:21:16.1250000s - 0xCD6B9DFC20000000149095 16:21:16.1250000s -  - 12881866876125000000ns149095 16:21:16.1250000s -  - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | RoundtripDelay: 000ns (0s)
149095 16:21:16.1250000s - | LocalClockOffset: -142822326500ns - 2:22.822326500
149095 16:21:16.1250000s - \--
149095 16:21:16.1250000s - Peer 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123) is not Win2K. Setting compat flags.
149095 16:21:16.1250000s - Packet test 6 failed (not syncd or bad interval since last sync).
149095 16:21:16.1250000s - Packet test 7 failed (bad stratum).
149095 16:21:16.1250000s - Ignoring packet that failed tests from 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123).

Note the bad stratum message. I don’t know why these servers didn’t want to work together. The commands

w32tm /stripchart /computer:192.168.1.1

and

w32tm /monitor /computers:192.168.1.1

showed that they communicate using NTP. The way I got around it was to simply configure the PDCe to synch with the time server of a local ISP:

rem Stop the Windows Time service
net stop w32time

rem Set everything back to defaults
w32tm /unregister
w32tm /register

rem Start the Windows Time service
net start w32time

rem Specify the NTP server
w32tm /config /manualpeerlist:100.20.3.4 /syncfromflags:manual /reliable:yes /update

Note I thought about synching the PDCe with time.windows.com, but that address resolves to time.microsoft.akadns.net – so I imagine that the IP address will change fairly often which would cause a problem on the firewall access-list.
For troubleshooting information on Windows and NTP I recommend Windows Time and the W32TM service.