1

This is so weird I feel compelled to ask for advice.

I have a handful of workstations who are receiving time from a GPS timeclock. The PDC has the default domain policy set to use the GPS timeclock as the NTP timesource. All the workstations sync to the timeclock with precision ranging from 50ms to 1.5ms so my delta values are grossly within margins for Kerebos tickets.

Almost all the workstations access my fileserver with absolutely no problems, however a single workstation began prompting me with the message This server's clock is not synchronized with the primary domain controller's clock and unless w32tm /stripchart /computer:PDC is lying, 20ms is more than close enough to be synchronized.

Is there something I might be missing here?

2
  • The problem seems to be the PTP time source that was providing time stamping for the database had been turned back to 7/23/10. Evidently one of our engineers was preforming regression testing on another part of the network and had reset the PTP master time to hand out the same time range as the previous tests. I disabled the PTP radio card from updating the Windows time and set it by hand to be close to the workstations that use NTP. I'll mark answers accordingly if I continue to have no other problems with my time sources. Oct 13, 2010 at 13:43
  • Feel free to post your fix as an answer & accept. And thanks for coming back with that - might help someone someday. Oct 13, 2010 at 15:29

3 Answers 3

2

Now that I'm convinced the problem is fixed, I'll answer my own question.

Things to Verify:

  • Verify the modulation from the timesource If the IRIG signal is modulated, make sure your configuration is looking for a modulated time signal. If the IRIG signal is unmodulated, make sure you have the hardware configured for unmodulated signal.

  • Verify the correct time If the 'Grandmaster Clock' is not receiving the correct time value from the timeclock, nothing is going to be correct. Make sure that you have the correct offset period for the correct year. Leap seconds (as of this writing) should be offset by 34 seconds.

  • Verify there are no forced values, or debugging If someone is debugging a process using a frequency generator to 'fake' the time, nothing is going to be right if it overrides the Stratum time.

  • Verify Time Services If your clock radio has separate software to synchronize the system time to the timesource, make sure that Windows Time Service is disabled. If you don't turn off Windows Time Service the clock will be corrected by both services.

  • Verify Time Zones Timezones must be set correctly on both the time server and clients. I highly recommend setting everything to GMT without any daylight bias or UTC and creating a second time display showing the local timezone with daylight preferance.

  • Verify DST is Patched If you don't have a correct implementation of DST running, you will encounter 'phantom' problems.

  • Verify delta is small enough for initial synchronization If the delta time is large, the clients cannot synchronize to the time source. You may be required to set the clock to within approximately 10 minutes for the time service to be able to synchronize.

For troubleshooting:

  • use w32tm /tz to verify the timezones.
  • use w32tm /stripchart /computer:[host to compare with] to measure differences and time drift between the 2 computers.
1

My guess is a DST patching issue on that workstation. Last time I ran into it, I'd loaded a workstation from image, then applied XP SP3. That's when I discovered that my image fell into a fringe case where the DST patching didn't take place when patched in that way. If that's the issue, hopefully the MS DST page will help out.

3
  • 1
    Ah yes, this. Try w32tm /tz on a working and non-working machine, and see if one is under DST while the other one is not. Oct 12, 2010 at 21:50
  • Thanks, that's the command I was trying to locate. Brain's not working tonight. Oct 12, 2010 at 22:05
  • w32tm /tz showed that they were both set for GMT and ignoring daylight time bias. Oct 13, 2010 at 13:38
1

This error started happening on our network on multiple workstations after the 2019 change from daylight savings to standard time. In order to fix, I rebooted one of my two domain controllers and the network shares started working again.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .