Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
Why Windows says time synchronization failed, the five causes and a one-minute test for each, how time flows in a domain, and the w32tm fix order.
A clock that drifts takes sign-ins, certificates and log timelines down with it, and Windows only tells you with a one-line error in Settings. The cause sits in one of five places, and on a domain the fix depends on where the machine sits in the time hierarchy. This guide walks through what "time synchronization failed" means, how to find which of the five it is, and the w32tm commands that fix each one in order.
The error comes from the Windows Time service, W32Time, the background service that keeps the system clock in step with a time source over the Network Time Protocol (NTP). You see it in Settings under Time and language when you press Sync now and the service gets no usable answer back.
What counts as the time source depends on the machine. A standalone or workgroup PC asks time.windows.com. A domain-joined PC ignores that and asks a domain controller. Microsoft's how the Windows Time service works page states both defaults plainly, and it is the first fact to establish on any ticket. The command that tells you in one line:
codew32tm /query /source
A hostname or a DC name means the client knows where to look. "Local CMOS Clock" means it has given up and is free-running on the motherboard clock, and "Free-running System Clock" means the same with extra steps.
Every version of this ticket lands on one of five causes, and each has a test that takes under a minute.
UDP 123 is blocked. NTP runs on UDP port 123, and Microsoft's tools and settings reference adds a detail that catches people: the built-in client can only use 123 as its source port too. A firewall rule that allows outbound UDP to any port but filters the source port, or an ISP router that drops NTP, stops the sync while ping still works.
Our guide to TCP vs UDP covers why a connectionless protocol fails quietly. Test it with w32tm /stripchart /computer:time.windows.com /samples:3, which uses a random source port, so a stripchart that works while resync fails points straight at a source-port rule.
The time server is unreachable or unresolved. The error text in w32tm /resync tells you which: "The peer is unresolved" is a DNS problem, "no time data was available" means the peer answered nothing usable. A Group Policy that sets a time server by a name that no longer resolves produces the second one across a whole fleet at once.
The service is stopped or never started. On a workgroup machine W32Time is set to start on a trigger, not at boot, so it can sit stopped for days. Check with sc query w32time and look for RUNNING.
A virtual machine is taking its time from the host. Hyper-V and VMware both offer guest time synchronization through their integration tools. When the host clock is wrong, every guest inherits it, and w32tm /query /source shows "VM IC Time Synchronization Provider" instead of a server.
The offset is too large to correct. Windows will not jump the clock past a limit. Microsoft's reference sets MaxPosPhaseCorrection and MaxNegPhaseCorrection at 54,000 seconds, 15 hours, on standalone machines and 172,800 seconds, 48 hours, on domain controllers. A machine whose clock is off by more than that logs an event and refuses to move until someone sets the time by hand.
The workgroup case in this thread is the first cause in disguise. Time would not sync on a Windows 11 PC unless it was on a VPN, even after a clean reinstall and a new CMOS battery, and time.windows.com answered pings the whole time:
Ping is ICMP, NTP is UDP 123, and the VPN tunnel carried the packets past whatever was dropping them at home. The Windows Firewall rules on the PC are the first place to look, the router second.
On a domain, time is a chain, and the error usually means one link is pointing somewhere it should not. Members sync from a domain controller in their own domain. Domain controllers sync from a more authoritative DC. At the top sits the domain controller holding the PDC emulator role in the forest root domain, and it is the only machine that should talk to an external time source.
The reason is security as much as accuracy. Inside the domain, Microsoft's documentation explains, the time a DC hands a member is signed with the computer's Kerberos session key, and a packet that is not signed correctly is rejected. A member pointed at pool.ntp.org with a manual peer list gets unsigned time, drifts away from its DC, and starts failing Kerberos. Microsoft names the symptom directly: printing and file sharing break first. If a machine shows that pattern, the trust relationship failed error is often the next ticket from the same desk.
So the configuration that works is short. Members and every DC except the root PDC use the domain hierarchy, which is the default and needs no setting. The root PDC gets an external peer list and is marked as a reliable source. Our explainer on what a domain controller does covers where the PDC emulator role lives and how to find it with netdom query fsmo.
The r/sysadmin thread below, from August 2026, is the textbook version. Two DCs, the PDC emulator pointed at pool.ntp.org, workstations set to NT5DS by Group Policy, UDP 123 confirmed open, and every resync failing with "no time data was available". The replies walk the checklist in the right order: is the PDC a VM taking host time, is it marked reliable with /reliable:yes, and does a Group Policy somewhere set a time server by a name that does not resolve.
Run these from an elevated prompt, in this order, and stop at the first one that changes the answer. Each step reads or changes one thing.
w32tm /query /status shows the source, the last successful sync, the phase offset and a Leap Indicator. A Leap Indicator of 3 means not synchronized.w32tm /query /source tells you whether the client is asking a DC, a manual peer, the VM host or nothing.w32tm /resync /rediscover throws away accumulated error statistics, rediscovers network sources and resyncs. On a member this alone fixes a client that had cached a dead DC.w32tm /config /syncfromflags:domhier /update. On the root PDC or a standalone machine, set real peers: w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update, dropping /reliable:yes on anything that is not the root PDC. Microsoft recommends three or more peers since Windows Server 2016.net stop w32time then net start w32time, then resync again.w32tm /unregister, then w32tm /register, then start the service and reapply step 4. This wipes the W32Time registry configuration back to defaults, which is the point and also the risk.If the machine is on a domain, also run gpresult /h report.html and search it for "Windows Time Service". A Group Policy setting overwrites whatever you configured with w32tm on the next refresh, which is the most common reason a fix "comes back".
Every technician who has worked this ticket has seen the same output enough times to recite it:
For a full domain walkthrough, including setting the PDC emulator's external source and checking the result on members, this video covers it end to end:
On a fleet, the useful version of steps 1 and 2 is a report rather than a session. A script that runs w32tm /query /status and w32tm /query /source on every machine and collects the source and offset shows which machines are on the hierarchy, which are free-running and which inherited a manual peer from an old build. If you run OpenFrame, that is one script run across a client's devices with the output collected in one place.
Kerberos is the reason a small offset becomes an outage. Microsoft's policy reference for the maximum clock tolerance sets the default at 5 minutes: a client and a DC whose clocks differ by more than that cannot exchange tickets, because Kerberos uses timestamps to block replayed credentials. Past the line, sign-ins, mapped drives and printers fail together, and the event logs blame authentication rather than time.
Certificates fail the other way. A clock set a year in the past sees every current certificate as not yet valid, so browsers throw warnings and TLS connections to cloud services fail. And logs from machines that disagree on the time cannot be lined up in an investigation, which matters most on the day you need them.
A virtual machine has two possible time sources: W32Time, and the host through the hypervisor's integration tools. For an ordinary member server or VDI desktop, letting the host provide time is fine, as long as the host itself is in sync. For a domain controller, it is the wrong source.
Microsoft's troubleshooting article for Windows Time events 24, 29 and 38 on virtualized DCs describes the conflict: a DC that syncs from both the host and the domain hierarchy sees its time change often, and because so many DC tasks are tied to the clock, a jump can leave lingering objects and stop replication. The resolution is to clear Time Synchronization under the VM's Integration Services in Hyper-V Manager and let the DC use the domain hierarchy. VMware's equivalent is the periodic time sync option in VMware Tools.
Our Hyper-V guide covers where Integration Services lives.
One reply in the August thread is worth carrying forward: even with host sync disabled, several operations can still push host time into the guest. Check the source after events such as a resume from saved state or a migration.
"Time synchronization failed" means W32Time asked its source and got nothing it could use. Find out what the source is with w32tm /query /source, test UDP 123 with a stripchart, and walk the fix order from resync to re-register. On a domain, only the root PDC emulator talks to the outside world, and a Group Policy or a VM host overriding that is behind most repeat tickets.
If the same machines are also throwing sign-in errors, the next read is the trust relationship failed guide, since a clock outside the 5-minute window is one of its causes.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.