Windows Time Service Fails to Synchronize

NTT Terin 60 Reputation points
2026-11-10T03:29:21.26+00:00

Why does the Windows Time service fail to synchronize with the configured NTP server even though the server is reachable?

Windows for business | Windows 365 Business
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Domic Vo 37,000 Reputation points Independent Advisor
    2026-11-10T05:09:30.6266667+00:00

    Hello,

    A reachable NTP server does not necessarily mean Windows Time can synchronize with it. The service uses UDP port 123, and synchronization can fail because of incorrect NTP configuration, firewall filtering, DNS resolution, invalid time samples, or domain time hierarchy settings.

    Start by checking the current configuration and synchronization status from an elevated Command Prompt:

    w32tm /query /status
w32tm /query /configuration
w32tm /query /peers

    Pay particular attention to Source, Stratum, Last Successful Sync Time, and the configured NTP peer.

    Test actual NTP communication rather than relying on ping:

    w32tm /stripchart /computer:ntp.example.com /dataonly /samples:5

    If requests time out, check UDP 123 in both directions through the local and network firewalls. Ping only confirms ICMP connectivity, not NTP availability. If requests receive responses but synchronization still fails, check the Windows Time event log under Event Viewer > Windows Logs > System, filtering for source Time-Service.

    If this is a domain-joined computer, it should normally use the Active Directory time hierarchy (NT5DS), rather than an independently configured public NTP server. Restore that configuration with:

    w32tm /config /syncfromflags:DOMHIER /update
net stop w32time
net start w32time
w32tm /resync /rediscover

    For a standalone computer that should use a manual NTP server, verify the peer configuration instead:

    w32tm /config /manualpeerlist:"ntp.example.com,0x8" /syncfromflags:MANUAL /update
net stop w32time
net start w32time
w32tm /resync

    The 0x8 flag specifies NTP client mode, which can be necessary when synchronizing with non-Windows NTP servers.

    Could you confirm whether the affected machine is domain-joined or standalone, and share the output of w32tm /query /status together with any error returned by w32tm /resync?

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-11-10T03:29:38.4+00:00

    A reachable NTP server can still fail to synchronize with Windows Time for several documented reasons:

    1. Windows may be using the wrong request mode for that server
      Windows domain controllers use symmetric active mode by default when sending time synchronization requests. Some non-Windows NTP servers respond only to client mode requests. In that case, the server is reachable, but synchronization still fails. Use client mode with: 
         w32tm /config /manualpeerlist:<NTP_server_IP_Address>,0x8 /syncfromflags:MANUAL
   net stop w32time
   net start w32time
   w32tm /resync
      The 0x8 flag sets Windows Time to use client mode.
    2. SpecialPollInterval can prevent correction in some cases
      If the client is configured with a manual NTP server and uses SpecialPollInterval, and the time offset is greater than LargePhaseOffset, the client can enter SPIKE state and not correct its time even after waiting. A workaround is to use MinPollInterval/MaxPollInterval instead of SpecialPollInterval, and avoid the 0x1 flag in /manualpeerlist. Example: 
         w32tm /config /update /manualpeerlist:NTP_server_IP_Address,0x8 /syncfromflags:MANUAL
    3. Large SpecialPollInterval values may be ignored or delay sync unexpectedly
      On workgroup computers, large SpecialPollInterval values can cause synchronization to occur at longer intervals than expected. One workaround is to set a smaller SpecialPollInterval value between MinPollInterval and MaxPollInterval, such as 3600 seconds, or switch to automatic polling by changing the peer flag from 0x9 to 0x8.
    4. The system may have lost its Windows Time configuration
      After certain in-place upgrades, Windows Time settings can revert to defaults. For example:
      • upgraded domain members may start syncing with time.windows.com instead of the domain hierarchy
      • a PDC emulator can lose its external time source configuration
      • a server may stop advertising as a time server
      In that case, the configured NTP server may be reachable, but Windows is no longer actually using it.
    5. The root or authoritative server may not be trusted
      If the root of the synchronization hierarchy is not set to NoSync and cannot synchronize with another source, clients do not trust the packets it sends. Only time servers identified as reliable are trusted by clients even if they have not synchronized with another source.
    6. UDP port 123 must be available to Windows Time
      Windows Time uses UDP 123 for both NTP and SNTP. If another product needs that port, Windows Time must be disabled because Windows reserves UDP 123 while the service is running.

    In short, reachability alone is not enough. Common causes are protocol mode mismatch, polling configuration issues, lost configuration after upgrade, trust/authoritative state problems, or UDP 123 conflicts.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.