Small Town Sysadmin
Free CJIS checklist

Field notes

Field note: the whole building's clock was 20 minutes off

Every PC in a building drifted because the domain controller handing out time was trusting its own failing hardware clock.

Someone noticed the clocks were wrong, and it wasn’t one PC. The whole building was about 20 minutes off, because every PC was faithfully syncing with the domain controller, and the domain controller was wrong.

Why it matters

Time sounds cosmetic, but Active Directory depends on it. Kerberos, the sign-in protocol domain PCs use, allows only five minutes of difference between a computer and the domain controller by default. Past that, sign-ins and Group Policy start failing in confusing ways. Twenty minutes off is well past it.

What was wrong

In a domain, PCs get their time from domain controllers, and the domain controllers follow the one holding the PDC emulator role. That one is supposed to get its time from a reliable outside source. This one wasn’t. Checking it showed:

w32tm /query /source
w32tm /query /status

The source came back as Local CMOS Clock: the server’s own hardware clock, with no outside time source at all. And a hardware clock that drifts this far usually means the little battery on the motherboard is dying.

The time settings in the Windows clock app were greyed out, too. Group Policy was managing Windows Time, so the GUI couldn’t fix it.

A gotcha on the way

My first move was net time \\yourdc /set /y to correct it quickly. That command works the other way around from what you’d expect. It sets your computer’s clock from the server, not the server’s clock from yours. All it did was copy the bad time onto my workstation. Make the change on the domain controller itself.

The fix

On the PDC emulator, I pointed Windows Time at outside time servers and told it to trust them:

w32tm /config /manualpeerlist:"time.nist.gov,0x9 time.windows.com,0x9" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync /rediscover
w32tm /query /status

After the restart, /query /source showed an outside server instead of the CMOS clock, and the building’s PCs came back into line on their next sync. A battery replacement went on the list for the next maintenance window, so the hardware clock stops wandering.

If a Group Policy setting controls Windows Time on your domain controllers, check it too. Otherwise it can put the old setting back at the next policy refresh.

What I took away from it

  • The PDC emulator should always sync from an outside source. Everything else in the domain follows it.
  • “Local CMOS Clock” as the time source on a domain controller is a red flag.
  • net time \\server /set sets your clock from the server, not the other way around.
  • A clock that keeps drifting on a server is usually a dying CMOS battery.
  • Check for a GPO managing Windows Time before your manual change gets overwritten.

Replacing an old domain controller? The time setup for the PDC emulator is part of our domain controller replacement guide.

Sources

All articles