Home / server / Questions / 190173
Accepted
Greg Buehler
Asked: 2010-10-13 09:07:24 +0800 CST

'This server's clock is not synchronized with the primary domain controller's clock' when accessing shared drive

  • 772

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?

time active-directory time-synchronization

3 Answers

  1. Best Answer

    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.
    • 2

  2. 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.

    • 1

  3. 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.

    • 0