Time Service Errors — w32tm 0x800705B4

Introduction

A server has drifted a few minutes out of sync, and Kerberos authentication is starting to fail for anything talking to it. The obvious move is w32tm /resync. Instead of fixing the drift, it comes back immediately with a failure and an error code that says nothing about clocks: 0x800705B4.

This is one of the more misleading Windows Time errors, because the instinct is to treat it as a time problem. It is not. It is a networking and topology problem wearing a time-service error code.

What the Error Looks Like

Running a manual resync produces this on the console:

C:\>w32tm /resync /rediscover
Sending resync command to local computer
The computer did not resync because no time data was available

The same underlying condition shows up as 0x800705B4 when you run w32tm /stripchart against a specific source, and it usually travels with one of these two System log entries from Microsoft-Windows-Time-Service:

Event ID: 129
NtpClient was unable to set a domain peer to use as a time source
because of discovery error. NtpClient will try again in 15 minutes
and double the reattempt interval thereafter. The error was:
The entry is not found. (0x800706E1)

Event ID: 134
NtpClient was unable to set a manual peer to use as a time source
because of DNS resolution error on 'time.windows.com,0x9'. NtpClient
will try again in 15 minutes and double the reattempt interval
thereafter. The error was: No such host is known. (0x80072AF9)

What It Actually Means

0x800705B4 is a generic Windows timeout code, and W32Time reuses it whenever an NTP request goes out and no valid response comes back within the expected window. That covers three distinct situations: the client cannot even resolve the target server’s name, the request reaches the network but nothing answers on UDP 123, or something answers but is not actually functioning as an NTP source.

In other words, the error tells you the symptom, not the cause. Diagnosis means working outward from the client, through name resolution and the network path, to whether the target is really serving time at all.

How to Diagnose

Work from cheapest check to deepest. Each of these commands narrows down which of the three causes you are looking at.

# Check current sync status, source, and last error
w32tm /query /status /verbose

# Check which peers are configured and how they are reachable
w32tm /query /peers

# Check the effective runtime configuration and where each setting came from
w32tm /query /configuration

# Force a rediscovery and resync, waiting for the result
w32tm /resync /rediscover

# Compare offset against a specific source without changing anything
w32tm /stripchart /computer:dc01.corp.example.com /samples:5 /dataonly

# On a domain-joined host, check every DC's sync health in one pass
# (prefix a name with * to mark it as the PDC)
w32tm /monitor /computers:dc01.corp.example.com,*dc02.corp.example.com

# Confirm the target DC is actually advertising as a domain controller
dcdiag /test:Advertising /s:dc02.corp.example.com

w32tm /query /status /verbose is the first stop. Its Source and Last Sync Error fields say whether the client has a working source at all, and its Stratum line shows how many hops removed the current source is from an authoritative clock:

Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: 5/23/2026 7:51:39 PM
Source: VM IC Time Synchronization Provider
Poll Interval: 6 (64s)

Common Causes

The Fix

The most common real-world cause behind this error in a domain environment is a PDC emulator with no working upstream source — every other DC inherits time from it, so once it stalls, the whole hierarchy eventually reports 0x800705B4 on resync. Making the PDC authoritative is a registry change, not a w32tm /config one-liner, so do it deliberately.

On the PDC emulator, open regedit and set the following:

# 1. Set the server type to NTP
# Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
# Value: Type = NTP

# 2. Mark this server as a reliable, always-on time server
# Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
# Value: AnnounceFlags (DWORD) = 5

# 3. Enable the built-in NTP server so it can answer requests
# Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
# Value: Enabled (DWORD) = 1

# 4. Point it at real external time sources
# Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
# Value: NtpServer = pool0.ntp.corp.example.com,0x1 pool1.ntp.corp.example.com,0x1

# 5. Restart the service so the changes take effect
net stop w32time && net start w32time

The ,0x1 suffix on each server name sets the SpecialInterval flag, which tells W32Time to poll on the interval defined by SpecialPollInterval instead of letting the poll interval float. Without it, changes to the peer list silently do not take effect.

Every other domain controller keeps its default AnnounceFlags value of 10 (0xA) — do not copy the PDC’s value of 5 onto member DCs; that value specifically marks a server as reliable and externally sourced, which only the PDC should claim.

For a non-DC member server or workstation that just needs to point at a specific NTP source rather than the domain hierarchy, the fix is a single command instead of a registry edit:

# Point a member server at explicit peers instead of the domain hierarchy
w32tm /config /manualpeerlist:"ntp1.corp.example.com ntp2.corp.example.com" /syncfromflags:manual /update

# Force it to apply immediately
net stop w32time && net start w32time
w32tm /resync /rediscover

How to Prevent It

This error tends to reappear on the same forest for the same reason each time, so the fix is monitoring the hierarchy, not just repairing it once.

Run w32tm /monitor against all domain controllers on a schedule and alert on any DC reporting a large offset or an error instead of a stratum value. Confirm the PDC emulator’s external NTP sources stay reachable from wherever it actually sits — a PDC role transfer during a DR failover can move the role to a DC with no route to the configured NTP servers.

Keep the manual peer list’s DNS records current; a decommissioned or renamed NTP appliance is one of the most common causes of Event 134. And verify UDP 123 is explicitly permitted between sites in any network firewall change, not just the local Windows Firewall — the local rule is enabled by default, but the network path often is not.

If clock drift is what led you here in the first place, it is worth checking whether the accounts locking out or failing Kerberos are a symptom of the same skew — see the walkthrough on Kerberos clock skew and KRB_AP_ERR_SKEW.

Final Thoughts

0x800705B4 is one of those errors that sends people looking in the wrong place, because it is filed under the Windows Time service but almost never caused by anything the time service controls directly. Name resolution, a firewall rule, and the domain’s time hierarchy account for nearly every case.

Treat the PDC emulator’s time configuration as part of the domain’s core dependency chain, not a one-time setup step. Every DC, every domain-joined client, and every Kerberos ticket downstream of it depends on it staying correctly configured after DR failovers, role transfers, and firewall changes.