A clock 12 minutes out breaks Windows Update, and the error never mentions time

A device stops scanning for updates. The error is a hex code that mentions security, or a network, or a certificate. It does not mention the clock. So nobody checks the clock.

That is the whole failure. Windows Update reaches Microsoft over HTTPS, and in an Active Directory environment it also touches Kerberos on the way to a WSUS or Configuration Manager server. Both treat the local system clock as a security input. Move the clock far enough and they stop trusting the device, and neither says so in plain English.

The problem: the error you get never mentions the clock

Start with the Windows Update error code Microsoft explicitly ties to time. Its support article for 0x80072f8f opens by saying the error "typically indicates issues that affect SSL negotiation because of out-of-sync clock settings or untrusted SSL certificates". Two causes, one code.

Now ask Windows what that code means. certutil -error is the fastest local decoder and needs no elevation, so it is safe to run on a user's machine mid-incident.

That contrast is why this failure survives in fleets for months. Windows is perfectly capable of naming the system clock in an error string - CERT_E_EXPIRED does it in so many words. The code Windows Update actually surfaces resolves to a WinHTTP facility error whose entire message is five words long, and one of them is not "time".

So the symptom class is broader than one code. A device that cannot scan, cannot download, or fails a WSUS scan with a generic transport, certificate or trust error is a candidate for a clock problem. Treat the code as a hint about which layer failed, not as a diagnosis.

There is a second reason clock problems hide. In a domain the operating system usually papers over small skew on its own - Microsoft's Kerberos guidance says "Typically, if the clocks aren't synchronized, Windows can resynchronize them automatically." So the device limps and self-corrects for weeks. Then it loses its time source entirely, drift accumulates unopposed, and one morning the update stack falls over.

Why it happens: two time-sensitive gates sit in front of every scan

Before the update stack does anything interesting, the device has to prove who it is to something. There are two independent gates, and each uses the clock as an input.

Gate one: TLS certificate validity is evaluated against your clock

Every Windows Update endpoint is HTTPS. Validating the server's certificate chain means checking that each certificate is currently inside its validity window, and "currently" is the operative word. Windows does not consult an external notion of now. It reads the local clock.

The API contract says so. CertVerifyTimeValidity, exported from crypt32.dll, takes a pointer to the comparison time and a pointer to the certificate, and Microsoft documents the parameter plainly: "If NULL, the current time is used." It returns minus one if your comparison time is before the certificate's NotBefore, plus one if it is after NotAfter, and zero if the time is valid. The certificate is fixed; the verdict is not. Any code path passing NULL is asking the local clock to arbitrate trust.

That is also why there is no single number for "how much skew breaks TLS" - it depends on the width of the window on the certificate in front of you. A long-lived server certificate issued last year survives twelve minutes of skew without blinking. A certificate issued in the last few minutes, which is what short-lived and automatically rotated certificates look like, can be "not yet valid" on a device whose clock runs slow. That is a minus-one return from a healthy device talking to a healthy service.

Gate two: Kerberos has a documented number, and it is five minutes

The Kerberos gate has an actual policy behind it. The setting is Maximum tolerance for computer clock synchronization, at Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy, documented as determining "the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller that provides Kerberos authentication".

The default in the Default Domain Policy is 5 minutes. Permitted values run from 1 to 99,999, and Microsoft's own best-practice advice is to leave it at 5. The tolerance exists for replay protection: "To prevent 'replay attacks,' the Kerberos v5 protocol uses time stamps as part of its protocol definition."

The Kerberos troubleshooting guidance restates it operationally - "The difference in time between the domain controller and the client computer or the target server must be less than five minutes" - and when it is not, the protocol error is KRB_AP_ERR_SKEW, code 0x25. That guidance maps Event ID 4 carrying KERB_AP_ERR_SKEW to a single instruction: "Make sure that the computer clocks are synchronized".

So a twelve-minute clock is a specific, meaningful number. It is not near the boundary; it is more than twice the documented default, which puts every Kerberos exchange on that device outside the window the domain controller will accept. For update triage that bites in two places: managed scan targets like WSUS with Windows authentication or a Configuration Manager management point are domain resources reached with domain credentials, and the time service itself is authenticated with Kerberos.

Where the clock is supposed to come from

The Windows Time service has four components, which Microsoft names as the Service Control Manager, the Windows Time Service Manager, Clock Discipline, and the time providers. The providers are the pluggable part: NtpClient is the input provider that fetches samples, NtpServer is the output provider that answers other machines, and Clock Discipline moves the clock - either adjusting the clock rate to converge slowly or setting the time outright when the gap is too large to slew. Accuracy is expressed as a stratum, counting hops away from a reference clock: "As a computer's stratum number increases, the time on its system clock may become less accurate."

Which source a device uses is decided by the Type value, and there are exactly four.

Note what is missing from NT5DS: a fallback. A domain member set to NT5DS that cannot locate a domain controller does not quietly reach out to time.windows.com instead - it runs free on the motherboard clock. That is exactly the state the lab device was in, and the next section is the measurement that proved it.

How to verify: measure the skew, then find out who owns the clock

Two questions, and they are independent. How wrong is the clock right now? and is anything keeping it right? A device can pass the first and fail the second, which is the dangerous combination: it looks healthy today and will not be healthy next week. Work the steps in order. None of them changes the machine.

Step 1: measure the offset against a source you trust

Do not read the taskbar clock. It rounds to the minute, it shows local time, and a device eleven minutes out looks identical to one that is right unless the observer is holding a reference. Use w32tm /stripchart, which Microsoft documents as displaying "a strip chart of the offset between this computer and another computer".

Read three things out of that. The sign gives direction - negative means the local clock is behind the reference. The consistency across samples says it is real skew rather than one congested packet. And d:, the round-trip delay, is your confidence interval: an offset smaller than the delay is noise, an offset of seconds against a delay of milliseconds is a finding.

Step 2: ask who the device thinks owns its clock

An offset of 1.89 seconds sounds like nothing. It is well inside the Kerberos tolerance and will not break a handshake. Step 2 is where the lab device stopped looking healthy.

Source: Local CMOS Clock is the headline: the device is not taking time from anything. It is reading the battery-backed clock on the motherboard and calling that authoritative. Microsoft's guidance on large offsets describes exactly this handover - "When Windows starts, the kernel pulls the current time from the BIOS. This current time is used as the initial time until the W32Time service can sync up with another time source." On this device the second half never happened.

Leap Indicator: 3(not synchronized) with Stratum: 0 (unspecified) is the service admitting it; a synchronised domain member reports leap indicator 0 and a stratum one greater than its source. Last Successful Sync Time: unspecified paired with Time since Last Good Sync Time: 4178.2576831s says there has never been a successful sync and the service has been failing for about seventy minutes. Last Sync Error: 1 (The computer did not resync because no time data was available.) is the cause in one line - not "access denied", not "wrong signature". No data arrived at all.

This is the teaching point of the whole article. The measured offset was under two seconds, so a skew check alone would have passed this device. The service state says the clock is unmanaged and drifting, and the only thing between it and a Kerberos-breaking offset is the quality of the crystal on that motherboard.

Step 3: read the configuration and the peer list

Every line in [Configuration] is annotated (Local), meaning registry defaults rather than Group Policy - confirmed independently, since HKLM\SOFTWARE\Policies\Microsoft\W32Time does not exist on this device. Microsoft notes the corollary: if you set NtpServer by Group Policy on a domain member, "W32Time doesn't use the NtpServer registry value", so w32tm /query /configuration is the only honest view of effective settings. And #Peers: 1 is the kind of thing an inventory script gets wrong - technically true, but the peer has no name, no mode and no stratum, and its state is Pending.

Step 4: the registry values worth knowing by name

All of the following live under one root. The subkey is shown in the value column.

Step 5: read the Time-Service log, both halves of it

There are two places Windows writes time-service events and practitioners routinely check only one. The System log carries the classic warnings under the provider Microsoft-Windows-Time-Service. Separately, Microsoft added a traceability channel in Windows 10 1703 and Windows Server 2016 1709 that is "enabled by default and can be found in the event viewer under the Applications and Services Log\Microsoft\Windows\Time-Service\Operational channel".

Event 129 answers "why is the source Local CMOS Clock". The device is configured for the domain hierarchy, tried to find a domain controller to take time from, and failed at discovery. The back-off text is not decoration: it maps onto two registry values you can read, and it explains why the device will not recover on its own within a working day.

Now the traceability channel. Microsoft publishes what each of these events is for, which makes them unusually easy to use as a timeline. The table below pairs the documented meaning with the count observed on the lab device.

Step 6: if it is a domain, check the whole domain

One device eleven minutes out is a device problem. Every device in a site eleven minutes out is a hierarchy problem, and you find that with w32tm /monitor. Microsoft documents it as monitoring W32Time across a domain, with /domain: to pick the domain, /computers: for an explicit comma-separated list where a name prefixed with * is treated as a PDC, and /threads: to set concurrency - default 3, range 1 to 50. Run it before you touch a single endpoint. If the domain controllers disagree with each other, fixing one laptop achieves nothing.

The fix: repair the time source, not the update stack

The fix follows from which of the two questions failed.

If the offset is large but the service is healthy - a named source, a populated last-sync time, a sane stratum - the source itself is wrong or the device has just come back from a long sleep. Force a resynchronisation. Microsoft's Kerberos guidance gives the exact form, including the flag that matters:

/rediscover is documented as redetecting the network configuration, rediscovering network sources and then resynchronising. Plain /resync reuses the source the device already believes in, which is useless when the source is the problem. There is also /nowait if you do not want to block, and /soft, which Microsoft describes as resynchronising using existing error statistics and retained purely for compatibility - not the option you want in a diagnosis.

If the service never synchronised at all, as on the lab device, a resync fails the same way it has been failing. The fault is upstream and there are three usual causes.

1. Domain controller discovery. Event 129 is a locator failure, not a time failure. Confirm the device can find a DC at all before blaming the clock - Windows Update triage and DC-locator triage are now the same ticket.
2. UDP 123 blocked. W32Time follows the NTP specification, which "requires the use of User Datagram Protocol (UDP) port 123 for all time synchronization". The Kerberos port list states it as W32Time on the client's ephemeral range to server port 123 UDP. Split-tunnel VPN profiles and host firewalls break this more often than anyone expects.
3. A device set to NT5DS with nowhere to fall back to. This is the structural problem behind the lab device's state: NT5DS has no documented fallback, so a discovery failure means the CMOS clock wins. AllSync is the documented behaviour you probably wanted - fall back to NtpServer when the domain hierarchy is unavailable.

If the machine is a virtual machine, look for two clocks fighting. A virtualised domain controller on a Hyper-V host can be taking time from the host through the Time Synchronization integration service and from the domain hierarchy through W32Time. Microsoft's article on Windows Time Service event IDs 24, 29 and 38 names the mechanism directly: "If domain controllers synchronize time from their own source and synchronize time from the host, the domain controller time can change frequently." The debug log line that gives it away is "The time service is now synchronizing the system time with the time source VM IC Time Synchronization provider."

The documented resolution is to disable time synchronisation on the host - Hyper-V Manager, Settings, Integration services, clear Time Synchronization - and let the guest use domain hierarchy synchronisation. The stakes on a DC are high: Microsoft lists lingering objects left in caches and replication stopping, because "many domain controller tasks are tied to the system time".

Only after the clock has a source do you go back to Windows Update. That ordering is the entire point. And when you do return, be careful which log you reach for. C:\Windows\WindowsUpdate.log on a modern build is a small stub pointing at Get-WindowsUpdateLog; the real traces are ETW .etl files under C:\Windows\Logs\WindowsUpdate. Microsoft's own 0x80072f8f article points at that folder and offers a nice cross-check for this investigation: you can "quickly verify clock accuracy from WindowsUpdate.log that always prints traces in local time".

Proof it worked: a real strip chart and a named reference source

A fix is proven when the service names a source and the offset collapses. Both are visible in the Operational channel, and the lab device holds real examples of the healthy state from earlier in its history - which is how you know the difference is the network, not the build.

That ntp.d versus ntp.m distinction is worth committing to memory. Microsoft's documented example of event 259 renders manual peers as ntp.m|0x8|[::]:123->[IPAddress]:123; domain-hierarchy peers on the lab device render as ntp.d. One character in an event message tells you whether a device is following your design or somebody's fix from 2022.

The confirmation sequence, in order:

1. w32tm /query /source returns a domain controller name, not Local CMOS Clock.
2. w32tm /query /status shows Leap Indicator: 0, a non-zero stratum, a real Last Successful Sync Time, and Last Sync Error of 0.
3. w32tm /query /peers shows a peer with a name and an active state, rather than a blank entry stuck in Pending.
4. A fresh w32tm /stripchart against the same reference shows the offset collapsed, now comparable to the round-trip delay rather than orders of magnitude larger.
5. Only then re-run the update scan and look for Microsoft-Windows-WindowsUpdateClient/Operational Event 26 ("Windows Update successfully found N updates") and Event 41 ("An update was downloaded").

The binaries involved, and where they actually live

Time diagnostics get written by people who assume there is a w32time.exe. There is not. Here is what is really on disk, measured on the lab device.

The cheap version of all of this is three commands and two logs. w32tm /stripchart for the number, w32tm /query /source and /status for the ownership, then the System log for Event 129 and the Operational channel for 259, 264 and 265. That is a two-minute check, it changes nothing, and it belongs at the front of every Windows Update triage - because the failure it catches is the one whose error message will never point you at it.

References

• Windows Time Service Tools and Settings - every w32tm parameter, the UDP 123 requirement, and the full registry reference for Config, Parameters, NtpClient and NtpServer.
• How the Windows Time Service Works - the four service components, stratum, the domain hierarchy and PDC emulator, Kerberos session key signing of NTP packets, and the documented behaviour of AllSync.
• Windows Time for Traceability - the Operational channel path and the documented purpose and throttling of events 257 through 266.
• Maximum tolerance for computer clock synchronization - the 5 minute default, the 1 to 99,999 range, the Kerberos Policy location, and the replay-attack rationale.
• Kerberos Authentication Troubleshooting Guidance - the "less than five minutes" statement, Event ID 4 with KERB_AP_ERR_SKEW, the w32tm /resync /rediscover form, and the W32Time firewall ports.
• Troubleshoot Windows Update Error 0x80072f8f - the out-of-sync clock and untrusted certificate causes, the WSUS and Configuration Manager SSL case, and the local-time trace tip.
• CertVerifyTimeValidity function - the NULL means current time contract, the minus one, plus one and zero return values against NotBefore and NotAfter, and the Crypt32.dll requirement.
• Windows Time Service event IDs 24, 29 and 38 on a virtualized domain controller - the host-plus-hierarchy double source, the VM IC debug log line, and the Integration Services resolution.
• Configure W32Time against huge time offset - the BIOS handover at boot, MaxPosPhaseCorrection and MaxNegPhaseCorrection defaults by role, the TOO BIG log entry, and why the default is 48 hours.
• Windows Time Service (W32Time) - the top-level index, including the accuracy and support-boundary articles for anyone chasing sub-second requirements.