Office 0xC004F06C: the KMS request timestamp is invalid (clock skew)

Fix it now

Microsoft publishes 0xC004F06C as the KMS host determining that the request timestamp is invalid, and names three conditions behind it: the Windows Time service is not working, the NtpClient time provider is not enabled, or a domain-joined computer is not syncing time with Active Directory. The tolerance is four hours, compared in UTC.

w32tm /query /status /verbose
w32tm /query /source
w32tm /resync
w32tm /stripchart /computer:kms.contoso.local

1. The first command is the one on Microsoft’s page for this code. Read the last successful sync and the offset before changing anything.
2. /resync takes only /computer:, /nowait, /rediscover and /soft. There is no /force parameter, and adding one makes w32tm print usage instead of resynchronising.
3. The stripchart measures the offset against the KMS host directly, which beats comparing two clocks by eye.
4. Retry activation from the Office folder: cscript ospp.vbs /act.

Setting the time zone will never fix this. The comparison is made in Coordinated Universal Time, so two correct clocks in different time zones agree perfectly.

If activation completes you are done. If the clock drifts again within a day, the fault is upstream and the next section finds it.

Why it happens

The KMS exchange is time-bound. The client builds a request carrying a timestamp, the host compares it with its own clock, and if the gap is too large the request is discarded rather than answered. Microsoft states the figure on its page for the neighbouring code 0xC004F074: a difference of more than four hours between the client’s system time and the host’s produces this failure, and time is coordinated between the two in Coordinated Universal Time.

That UTC detail is where most of the wasted effort goes. A client in Prague and a host in London can show clocks an hour apart on screen and agree perfectly, because both store the same underlying time. Changing a time zone to compensate for drift fixes nothing and breaks everything that depends on local time.

Microsoft’s dedicated page for 0xC004F06C names three conditions rather than describing drift in the abstract, and they are worth checking in order because each has a different fix: the Windows Time service is not working, the NtpClient time provider is not enabled, or domain-joined computers are not synchronising with Active Directory Domain Services. All three produce the same symptom of a clock nobody is correcting.

Four hours is a wide tolerance by design, so when it is exceeded something has usually gone properly wrong rather than slightly wrong: a dead firmware battery, a virtual machine whose clock is overwritten by its host, a machine that has never reached a time source since deployment, or a domain hierarchy whose authoritative server is itself adrift.

Full reference

The w32tm commands, as documented

w32tm /resync /force appears in a great deal of published guidance and does not work. /force is not a documented parameter, and given an unrecognised switch w32tm reports the argument as unexpected, prints its usage block and exits without resynchronising. Anyone who ran it and saw the clock change had something else correct it.

Reading the symptom before you change anything

When the whole site fails overnight

Hundreds of machines do not drift together. When a whole site crosses the line on the same night, the authoritative clock changed, not the clients. Identify the domain controller holding the primary domain controller emulator role, point it at a reliable external source rather than its own hardware clock, and use w32tm /monitor from a member machine to see how the rest of the domain compares once the top of the hierarchy is correct.

How accurate the clock actually needs to be

Four hours is the activation tolerance, and it is generous. In practice you want the clock within seconds, because Kerberos authentication is far stricter than KMS and will fail long before activation does. If activation is the first thing to break, the clock has been wrong for a while and something else has been masking it.

The four companion codes

Read the machine’s own text with cscript ospp.vbs /ddescr: on an Office client or slui.exe 0x2a on Windows. If one of them turns up on its own, without 0xC004F06C, this is probably the wrong article, because nothing published connects them to clock skew.

Every code this article covers

Confirm the fix worked

1. w32tm /query /status /verbose shows a recent successful sync and a small offset.
2. w32tm /query /source names the source you intended, not a local clock.
3. w32tm /stripchart /computer:<KMS host> shows an offset measured in seconds rather than hours.
4. cscript ospp.vbs /act completes without an error.
5. Reboot, wait for the machine to settle, and confirm the clock is still correct and Office still licensed.

Questions people ask about this