8 hours ago8 hr Time problems never show up as "the clock is wrong". They show up as a user who randomly can't authenticate, Group Policy that stops applying, or me trying to line up firewall logs against server logs and finding them minutes apart. Kerberos tolerates five minutes of clock skew by default, and past that things get weird fast. The design is simple once you see it. The DC holding the PDC emulator role in the forest root domain syncs to a reliable external NTP source. Every other DC syncs from the PDC emulator, or another DC higher up the hierarchy. Member servers and workstations sync from a DC in their domain, and that part happens on its own for domain-joined machines. So nearly all the work is on the PDC. You'll need admin access to your DCs, outbound UDP 123 from the PDC emulator to the NTP servers you pick, and about fifteen minutes. Find the PDC and see what it's doing netdom query pdc # or (Get-ADDomain).PDCEmulator Then on the PDC emulator: w32tm /query /status w32tm /query /source w32tm /query /configuration Read the Source and Stratum lines. If Source says Free-running System Clock, the server has no time source at all and just trusts its own clock. Local CMOS Clock is the same problem, it's reading the hardware clock. VM IC Time Synchronization Provider means it's getting time from the Hyper-V host, which I'll come back to. The domain that drifted together On one domain we took over, users were hitting intermittent Kerberos failures and the timestamps on firewall and server logs disagreed by several minutes. w32tm /query /source on the PDC came back Free-running System Clock. Nobody had ever given it an external source, so it was counting on its own oscillator, and every other machine in the domain was faithfully following it. The fix was exactly the next section, then a resync on the other DCs. The clients corrected themselves over the next few polling cycles. Point the PDC at external NTP w32tm /config /manualpeerlist:"time.nist.gov,0x8 0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update net stop w32time net start w32time w32tm /resync /rediscover /manualpeerlist is a space-separated list of peers. The ,0x8 suffix tells Windows to use client mode with them, which is what public NTP servers expect. /syncfromflags:manual says to use that list instead of the domain hierarchy. /reliable:yes advertises this DC as a reliable time source to the rest of the domain, and /update tells the service to load the new config. I always list more than one peer, so a single unreachable server doesn't leave you free-running again. If the status still shows the local clock afterwards, check that UDP 123 is actually getting out. w32tm /stripchart /computer:time.nist.gov timing out is a good sign the firewall is blocking it. And if the PDC is already far off, Windows may refuse to jump the clock because of the maximum correction limits (MaxPosPhaseCorrection and MaxNegPhaseCorrection). Set the time by hand close to correct, then resync. Put everyone else back on the hierarchy Run this on every other DC, and on any member server someone "fixed" by hand at some point: w32tm /config /syncfromflags:domhier /update net stop w32time net start w32time w32tm /resync w32tm /query /source The source should now be a DC name, not an internet server or the local clock. Virtual DCs shouldn't trust the host A virtual DC shouldn't take its time from the hypervisor. The host's clock is often the thing that's wrong, and then the whole domain is following an unmanaged box nobody ever set up NTP on. On Hyper-V, the cleanest fix that keeps the integration service's other benefits is to disable only the VM IC time provider inside the guest: reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f net stop w32time net start w32time w32tm /query /source You can also untick Time synchronization under Integration Services in the VM settings. On VMware, make sure periodic time sync with the host is off in VMware Tools for DC guests, and give the ESXi hosts proper NTP so any one-off syncs (after a vMotion or snapshot revert, for example) are at least correct. Checking your work w32tm /query /status w32tm /monitor w32tm /stripchart /computer:time.nist.gov /samples:5 /dataonly On the PDC, /query /status shows one of your NTP peers as the source, a sensible stratum (typically 2 to 4), and a recent Last Successful Sync Time. w32tm /monitor lists every DC with a small offset from the PDC. /stripchart against an external server shows offsets in milliseconds, not seconds. On a workstation, w32tm /query /source shows a DC. If you ever move the PDC role The manual peer config lives on the server, not the role. Transfer the PDC emulator to a new DC and the new one keeps following the hierarchy, so nothing in the domain talks to an external source anymore. Configure the new PDC as above and set the old one back to domhier. Some teams handle this with a GPO linked to the Domain Controllers OU, using a WMI filter that matches only the PDC (Select * from Win32_ComputerSystem where DomainRole = 5), so the setting follows the role automatically. If you've got ten seconds today, run w32tm /query /source on your PDC. I'm still surprised how often the answer is wrong.
Create an account or sign in to comment