PowerShell Fix Time Sync Issues: Root Cause Checks

Use PowerShell to fix time sync by checking three layers first: Windows Time service state, current time source configuration, and domain hierarchy; only force a resync after those checks pass. This failure means Windows cannot finish clock synchronization. If the cause is not addressed, clocks can drift and Kerberos, logon, or certificate errors may affect Windows 10, Windows 11, and Server. This guide shows the exact commands to verify each layer and then resync cleanly when the configuration is correct.

What is most likely broken?

Many time-sync failures come from a stopped or disabled W32Time service, an invalid or unreachable NTP source, or a domain policy that overrides local settings. Less often, the clock is so far off that a simple resync will not work, or network filtering blocks NTP traffic before Windows can reach its source.

Stopped or disabled Windows Time service

If W32Time is not running, resync commands fail even when the source is correct. On Windows 10 and Windows 11, this often looks like the clock never changes after a manual sync attempt. Check service state first, then set the startup type correctly before you try to force sync.

1. Open PowerShell as administrator.
2. Run Get-Service W32Time.
3. If the status is Stopped or the startup type is disabled, run Set-Service W32Time -StartupType Automatic.
4. Run Restart-Service W32Time.
5. Run w32tm /resync from PowerShell or via Start-Process w32tm -ArgumentList '/resync' -Verb RunAs.

Bad NTP source or unreachable server

A working service still fails if Windows points at the wrong source, or if time.windows.com or another approved NTP server cannot answer. This is common on standalone PCs after policy changes, VPN changes, or stale settings that survive an upgrade. Check the configured source before you keep forcing sync.

1. Run w32tm /query /source.
2. If the source is wrong or blank, confirm the current config with w32tm /query /configuration.
3. Set the approved source in the Time service settings or through domain policy.
4. Restart W32Time with Restart-Service W32Time.
5. Run w32tm /resync /rediscover to refresh the peer list.

Domain hierarchy or policy overriding local settings

On domain-joined machines and Windows Server, local manual time settings can be ignored. The device follows the domain hierarchy, and the domain controller or PDC Emulator becomes the real source of truth. If local settings keep reverting, the fix usually belongs in Group Policy or on the domain time source, not on the client.

1. Run systeminfo or Get-CimInstance Win32_ComputerSystem to confirm domain membership.
2. On the server or controller, check w32tm /query /source.
3. Verify the PDC Emulator is using a valid external or upstream source.
4. Change time policy at the domain level, not just on the local machine.
5. Restart W32Time, then resync after the hierarchy is corrected.

Clock skew is too large for a simple resync

If the local clock is far from the source, a normal resync can fail or seem to do nothing. That is a symptom, not the full problem. Compare the time before and after you change the service or source, and use the error in Event Viewer to decide whether the source is unreachable or the skew is beyond a quick fix.

1. Run Get-Date before any change.
2. Run w32tm /query /status and note the source and last successful sync.
3. Restart W32Time with Restart-Service W32Time.
4. Run w32tm /resync /force if the source is valid.
5. If the clock still refuses to move, check Event Viewer under the time-service log.

Restart the Windows Time service

Use this first when the service is stopped, disabled, or stuck in a bad state. Restarting W32Time is the cleanest first repair because the resync command depends on that service being active. If it is disabled, PowerShell can set it back to Automatic before you try again.

1. Open PowerShell as administrator. per Microsoft support
2. Run Get-Service W32Time and confirm that it is running.
3. If needed, run Set-Service W32Time -StartupType Automatic.
4. Run Restart-Service W32Time.
5. Run w32tm /resync.

Suppose a Windows 11 laptop shows a login warning after sleep, and Get-Service W32Time returns Stopped. Restarting the service often clears the stale state without touching the time source, which keeps the fix narrow and easy to verify.

Fix the NTP time source

Use this when W32Time runs but the source is wrong, blank, or unreachable. A valid source matters more than a forced resync, because resync only asks Windows to fetch time from whatever source it already trusts. On standalone PCs, that is often an external NTP server such as time.windows.com.

1. Run w32tm /query /source.
2. Run w32tm /query /status and check the last sync details.
3. If the source is stale, configure the approved NTP server in the Windows Time settings or policy.
4. Restart the service with Restart-Service W32Time.
5. Run w32tm /resync /rediscover so Windows re-reads the source list.

A common first-timer mistake is forcing w32tm /resync again and again after a router change, even though the problem is that UDP 123 is blocked or the source was never reachable. In that case, the command fails for the same reason every time.

Fix domain time hierarchy

Use this for domain-joined PCs and Windows Server. If the machine belongs to a domain, the local clock usually follows domain time rather than a manual NTP entry. The PDC Emulator and upstream source matter more than the local setting, especially when Kerberos tickets or logon timing start to fail.

1. Confirm domain membership with Get-CimInstance Win32_ComputerSystem.
2. Run w32tm /query /source on the client and on the domain controller.
3. Check whether the PDC Emulator has a valid external source.
4. Correct the hierarchy through Group Policy or domain configuration.
5. Run Restart-Service W32Time and then w32tm /resync /rediscover.

For Windows Server, treat local manual changes as temporary unless the server is meant to act as a time source. A broken controller chain can make every joined system look wrong even when each local service is running.

Time sync troubleshooting matrix

This matrix separates the common failure modes by device type. Use the symptom column to match what you see, then run the check before choosing the fix command. The escalation column tells you when PowerShell is no longer the right tool.

Pre-check: run Get-Date and save the current local time, then run w32tm /query /status to capture the source and last sync. After the fix, run both commands again and confirm the clock changed and the status reports a recent synchronization.

When PowerShell is not enough

If the service runs and the source looks right but sync still fails, move to the network and event logs. Time sync needs UDP 123 to reach the NTP source, and Windows Time errors often show the real reason in Event Viewer before the command line does. That is the next place to look when a resync fails twice in a row.

1. Open Event Viewer and check the time-service log for source, authentication, or communication errors.
2. Verify firewall rules and network policy for NTP traffic.
3. On domain systems, confirm the domain controller or PDC Emulator is healthy.
4. If the machine is a server, review the hardware clock and the upstream time source together.

Prevention: keep W32Time set to Automatic, and verify the configured source after VPN changes, GPO updates, or server role changes.

Frequently asked questions

How do I fix Windows time not syncing with PowerShell?

Start with Get-Service W32Time, then Set-Service W32Time -StartupType Automatic if needed, followed by Restart-Service W32Time and w32tm /resync. If the source is wrong, check it with w32tm /query /source before resyncing again.

What PowerShell command forces time sync on Windows?

w32tm /resync is the direct command. Run it from an elevated PowerShell window after confirming W32Time is running. If the machine has just changed networks or policies, w32tm /resync /rediscover is often the better follow-up.

How do I resync time with time.windows.com from PowerShell?

First confirm that the machine is supposed to use an external NTP source, then set or verify time.windows.com in the time source configuration. After that, run Restart-Service W32Time and w32tm /resync /rediscover, then verify the result with w32tm /query /source.

Why does Windows time sync keep failing?

Most repeated failures come from a stopped W32Time service, a bad source, a blocked NTP path, or domain policy overriding the local setting. Check Get-Service W32Time, w32tm /query /source, and Event Viewer time-service logs before forcing another sync.

How do I restart the Windows Time service from PowerShell?

Open PowerShell as administrator and run Restart-Service W32Time. If the service is disabled, set it first with Set-Service W32Time -StartupType Automatic. Then run w32tm /resync to confirm the service can talk to its source again.

Can PowerShell fix time sync issues on Windows Server?

Yes, but only if the hierarchy is already correct. On Windows Server, use w32tm /query /source and w32tm /query /status to verify the time chain, then restart W32Time and resync. If the PDC Emulator or upstream source is wrong, fix that first.