A Windows computer that is constantly a few seconds or minutes behind may look like a minor annoyance, but incorrect system time can cause much more serious problems.

A wrong clock can affect:

• website certificates and HTTPS connections;
• VPN authentication;
• Microsoft 365 and cloud services;
• Active Directory authentication;
• Kerberos;
• file synchronization;
• backups;
• scheduled tasks;
• log timestamps;
• software licensing;
• two-factor authentication;
• email timestamps;
• application logs.

One common symptom is a Windows laptop or desktop that remains one or two minutes behind the correct time even after selecting Set time automatically or changing the Internet time server.

In many cases, the real problem is not the NTP server itself. Windows may not actually be using NTP at all.

This guide explains how Windows time synchronization works, how to diagnose it, and how to repair common problems involving the Windows Time service, NTP, registry settings, and Group Policy.

What Is NTP?

NTP stands for Network Time Protocol.

It is the standard protocol used by computers, servers, routers, phones, and many other devices to synchronize their clocks with reliable time sources over a network.

NTP normally uses:

UDP port 123

Instead of manually setting the clock, the operating system periodically contacts an NTP server and adjusts its local time.

Typical public NTP servers include:

time.windows.com
time.cloudflare.com
time.nist.gov

There are also large public NTP networks such as the NTP Pool Project.

Why Accurate Time Matters More Than You Think

A difference of two minutes does not sound significant, but modern computer systems rely heavily on accurate timestamps.

For example, authentication systems may reject credentials if the local clock differs too much from the server.

HTTPS certificates also have validity periods. A badly configured system clock can produce browser errors such as:

Certificate not yet valid

or:

Certificate expired

Even when the clock difference is small, incorrect timestamps can create confusing entries in:

• Windows Event Viewer;
• web server logs;
• firewall logs;
• backup logs;
• application diagnostics.

Keeping accurate system time is therefore part of basic system maintenance.

How Windows Synchronizes Time

Windows uses a service called:

Windows Time

Its service name is:

w32time

Microsoft also provides a command-line tool called:

w32tm

This utility can display the current configuration, show the active time source, test NTP servers, and force synchronization.

Step 1: Check the Current Windows Time Source

Open PowerShell or Command Prompt as Administrator.

Run:

w32tm /query /source

On a correctly configured standalone computer, you may see something like:

time.windows.com,0x8

or:

time.cloudflare.com,0x8

However, if you see:

Local CMOS Clock

or:

Free-running System Clock

Windows is probably not currently synchronized with an external NTP source.

This is one of the most important clues when troubleshooting clock drift.

Step 2: Check Windows Time Status

Run:

w32tm /query /status

A healthy synchronized system may show information such as:

Stratum: 4
Source: time.cloudflare.com,0x8
Last Successful Sync Time: ...

The exact values will vary.

The important fields are:

Source

This tells you where Windows is obtaining its time.

Last Successful Sync Time

This shows when a successful synchronization occurred.

Stratum

NTP servers are arranged in levels called strata.

A lower stratum is closer to the original authoritative time source.

For a normal workstation, seeing something such as:

Stratum: 3

or:

Stratum: 4

is completely normal.

Step 3: Check the Complete Windows Time Configuration

Run:

w32tm /query /configuration

This command is extremely useful because it shows not only the configured values but also where those values came from.

You may see entries marked as:

(Local)

or:

(Policy)

That distinction is very important.

For example:

Type: NTP (Policy)
NtpServer: time.example.com,0x8 (Policy)

means Group Policy is controlling the setting.

A local configuration command may therefore not be able to override it permanently.

A Very Common Problem: The NTP Client Is Disabled

Inside the configuration output, look for:

NtpClient

A broken configuration may look like:

NtpClient
Enabled: 0

That means Windows’ NTP client is disabled.

Even if you change the NTP server in Windows Settings, synchronization cannot work correctly if the NTP client itself is disabled.

The expected configuration is normally:

Enabled: 1

How to Enable the Windows NTP Client

Run PowerShell as Administrator and execute:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" /v Enabled /t REG_DWORD /d 1 /f

Then ensure Windows is configured to use NTP:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters" /v Type /t REG_SZ /d NTP /f

Restart the Windows Time service:

net stop w32time
net start w32time

Then force synchronization:

w32tm /resync /rediscover

What Does “No Time Data Was Available” Mean?

One common error is:

The computer did not resync because no time data was available.

This does not necessarily mean the NTP server is offline.

It can also mean:

• the NTP client is disabled;
• no valid NTP server is configured;
• Group Policy is overriding the settings;
• DNS cannot resolve the NTP hostname;
• UDP port 123 is blocked;
• the Windows Time service is not running;
• the server configuration is malformed.

Before changing firewall rules, check the configuration carefully.

A Particularly Tricky Problem: An Invalid NTP Server Policy

One possible configuration looks like this:

Type: NTP (Policy)
NtpServer: ,0x1 (Policy)

This looks unusual because there is nothing before the comma.

That effectively means the configured NTP server hostname is empty.

Windows has been told to use NTP, but it has not been given a valid server.

As a result, you may see:

Source: Local CMOS Clock

and:

The computer did not resync because no time data was available.

Checking the Windows Time Group Policy Registry Settings

Group Policy settings for Windows Time can be stored under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time

You can inspect them with:

reg query "HKLM\SOFTWARE\Policies\Microsoft\W32Time" /s

For example, a broken configuration might look like:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters

NtpServer    REG_SZ    ,0x1
Type         REG_SZ    NTP

The key problem here is:

NtpServer = ,0x1

There is no actual NTP server name.

Configuring Valid NTP Servers

A reliable configuration can include more than one server.

For example:

time.cloudflare.com
time.windows.com

A Group Policy registry value can be configured with:

reg add "HKLM\SOFTWARE\Policies\Microsoft\W32Time\Parameters" /v NtpServer /t REG_SZ /d "time.cloudflare.com,0x8 time.windows.com,0x8" /f

Verify it:

reg query "HKLM\SOFTWARE\Policies\Microsoft\W32Time\Parameters"

A correct result should resemble:

NtpServer    REG_SZ    time.cloudflare.com,0x8 time.windows.com,0x8
Type         REG_SZ    NTP

What Does “,0x8” Mean?

You will often see an NTP server written like this:

time.cloudflare.com,0x8

The server name is:

time.cloudflare.com

The:

,0x8

part tells the Windows Time service to use the server in client mode.

This is often the safest setting when connecting a Windows workstation to public NTP servers.

Another commonly seen flag is:

,0x1

which tells Windows to use a special polling interval.

Flags can also be combined.

For most standalone Windows computers using public NTP servers, 0x8 is a practical choice.

Restart the Windows Time Service

After making configuration changes, restart the service:

net stop w32time
net start w32time

Then reload the configuration:

w32tm /config /update

You should receive:

The command completed successfully.

Check Which NTP Peers Windows Knows About

Run:

w32tm /query /peers

A correct configuration may show:

#Peers: 2

Peer: time.cloudflare.com,0x8
State: Active

Peer: time.windows.com,0x8
State: Active

This confirms that Windows knows about the configured NTP servers.

Force Windows to Synchronize

Use:

w32tm /resync /rediscover

A successful result looks like:

Sending resync command to local computer
The command completed successfully.

Then check the active source:

w32tm /query /source

You should now see something similar to:

time.cloudflare.com,0x8

rather than:

Local CMOS Clock

Test the NTP Server Directly

Windows provides another very useful diagnostic command:

w32tm /stripchart /computer:time.cloudflare.com /dataonly /samples:5

This communicates directly with the NTP server and compares its time with the local computer.

Example:

Tracking time.cloudflare.com
Collecting 5 samples.

07:25:57, +00.0064477s
07:25:59, -00.0009673s
07:26:01, -00.0007916s
07:26:03, -00.0005781s
07:26:05, -00.0010035s

These numbers show the difference between the local clock and the remote server.

A difference such as:

-00.0010035s

is approximately one millisecond.

That is excellent for a normal workstation.

What If the Clock Was Previously Two Minutes Wrong?

Suppose the computer was approximately two minutes behind.

Before synchronization, stripchart might show an offset approaching:

120 seconds

After a successful synchronization, the offset should drop dramatically.

For example:

0.006 seconds

and then:

0.001 seconds

At that point, NTP synchronization is working correctly.

Verify the Final Configuration

Run these commands:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

A healthy setup should have all of the following characteristics:

NtpClient
Enabled: 1

A valid server:

NtpServer: time.cloudflare.com,0x8

A real NTP source:

Source: time.cloudflare.com,0x8

And a non-local stratum such as:

Stratum: 4

Local CMOS Clock vs NTP Server

If Windows reports:

Source: Local CMOS Clock

the computer is effectively relying on its own hardware clock.

Computer hardware clocks are not perfectly accurate.

They naturally drift over time because of:

• temperature;
• crystal oscillator tolerances;
• battery condition;
• motherboard design;
• power states.

A drift of several seconds or even minutes over time is therefore possible.

NTP exists specifically to correct this drift.

What Is “Free-running System Clock”?

Another possible source is:

Free-running System Clock

This usually indicates Windows is running on its internal software clock without a valid external synchronization source.

It may still display a:

Last Successful Sync Time

but that does not necessarily mean the system is synchronized with an Internet NTP server.

Always check:

w32tm /query /source

to identify the real source.

Group Policy Can Override Your NTP Settings

This is one of the most confusing aspects of Windows time troubleshooting.

You may run:

w32tm /config /manualpeerlist:"time.cloudflare.com,0x8" /syncfromflags:manual /update

and still find Windows using another setting.

Why?

Because Group Policy has higher priority.

If the configuration shows:

NtpServer: something (Policy)

then changing the ordinary Windows Time settings may not override it.

You need to correct the policy itself.

Using Local Group Policy Editor

On Windows editions that include Local Group Policy Editor, run:

gpedit.msc

Navigate to:

Computer Configuration
→ Administrative Templates
→ System
→ Windows Time Service
→ Time Providers

Look at:

Enable Windows NTP Client

and:

Configure Windows NTP Client

Make sure the NTP client is enabled and that the configured server name is valid.

For example:

time.cloudflare.com,0x8

Be Careful With gpupdate /force

The command:

gpupdate /force

reloads Group Policy.

That is normally useful.

However, if the policy contains a bad NTP configuration, running gpupdate /force can restore the broken setting after you manually corrected the registry.

For example, you might repair:

NtpServer = time.cloudflare.com,0x8

only to have Group Policy change it back to:

NtpServer = ,0x1

If that happens, correct the actual policy source rather than repeatedly editing the registry.

How to Tell Whether a Setting Comes From Policy

Run:

w32tm /query /configuration

Windows will explicitly show the origin.

For example:

Type: NTP (Policy)

versus:

Enabled: 1 (Local)

This makes the command extremely useful for diagnosing conflicting settings.

What If the Windows Time Service Is Stopped?

Check the service:

sc query w32time

Or simply start it:

net start w32time

If it is already running, Windows may display:

The requested service has already been started.

That is harmless.

Error 0x80070426: The Service Has Not Been Started

If you run:

w32tm /config /update

while the Windows Time service is stopped, you may receive:

The service has not been started. (0x80070426)

The solution is simple:

net start w32time

Then run:

w32tm /config /update

again.

Completely Resetting the Windows Time Service

If the configuration is badly damaged, you can re-register the service.

Use this only after checking Group Policy, because a policy problem may simply recreate the bad configuration.

Run:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Then configure the desired NTP server again.

Check Firewall and UDP Port 123

If the configuration looks correct but NTP still does not work, network connectivity may be the issue.

NTP normally uses:

UDP 123

Possible blockers include:

• Windows Firewall;
• corporate firewall;
• router ACL;
• VPN software;
• security software;
• ISP filtering;
• captive portals.

A very useful first test is:

w32tm /stripchart /computer:time.cloudflare.com /dataonly /samples:5

If this produces valid time samples, UDP NTP communication is working.

If it repeatedly times out, investigate networking or firewall rules.

Check DNS Resolution

NTP cannot work if the server hostname cannot be resolved.

Try:

nslookup time.cloudflare.com

or:

Resolve-DnsName time.cloudflare.com

If DNS resolution fails, fix the DNS problem before troubleshooting NTP further.

Public NTP Servers You Can Use

Common choices include:

time.windows.com
time.cloudflare.com
time.nist.gov

For redundancy, more than one server can be configured:

time.cloudflare.com,0x8 time.windows.com,0x8

This allows Windows to use another source if one server becomes unavailable.

Should You Use time.nist.gov?

time.nist.gov is a legitimate NTP service, but changing from one public server to another will not solve a problem caused by:

• a disabled NTP client;
• invalid policy;
• a stopped service;
• blocked UDP 123;
• an empty NTP server configuration.

Always verify the Windows Time configuration before assuming the server itself is responsible.

Domain-Joined Computers Are Different

If the computer belongs to an Active Directory domain, do not immediately force it to use public NTP servers.

Domain-joined Windows computers normally synchronize through the Active Directory time hierarchy.

Typically:

workstation
→ domain controller
→ PDC emulator
→ external authoritative NTP source

Kerberos depends on consistent time across domain members.

Changing domain workstations to arbitrary public NTP servers can therefore create authentication problems.

For domain environments, troubleshoot the domain time hierarchy instead.

How Often Does Windows Synchronize?

Windows does not necessarily contact the time server every few seconds.

The polling interval changes according to configuration and operating conditions.

You may see values such as:

Poll Interval: 10 (1024s)

That means a polling interval of approximately:

1024 seconds

or about 17 minutes.

Windows can adjust its polling interval dynamically.

Is a Few Milliseconds of Difference Normal?

Yes.

A result such as:

-00.0010035s

is approximately:

1 millisecond

That is extremely accurate for an ordinary Windows computer synchronizing over the Internet.

Network latency alone can easily introduce several milliseconds of variation.

There is no reason to expect a desktop computer’s clock to remain mathematically identical to an Internet time server at every instant.

A Practical Windows NTP Diagnostic Checklist

If your Windows clock is wrong, work through these checks in order:

1. Check the source:

w32tm /query /source

2. Check status:

w32tm /query /status

3. Check full configuration:

w32tm /query /configuration

4. Make sure:

NtpClient Enabled: 1

5. Look for settings marked:

(Policy)

6. Check policy registry values:

reg query "HKLM\SOFTWARE\Policies\Microsoft\W32Time" /s

7. Confirm the NTP hostname is not empty.
8. Check peers:

w32tm /query /peers

9. Restart Windows Time:

net stop w32time
net start w32time

10. Force synchronization:

w32tm /resync /rediscover

11. Test the NTP server directly:

w32tm /stripchart /computer:time.cloudflare.com /dataonly /samples:5

12. Confirm the final source:

w32tm /query /source

If it returns a real NTP hostname instead of Local CMOS Clock, synchronization is working.

Example of a Healthy Final Result

A repaired system may show:

Source: time.cloudflare.com,0x8
Stratum: 4
Last Successful Sync Time: ...

A direct NTP test may show:

+00.0064477s
-00.0009673s
-00.0007916s
-00.0005781s
-00.0010035s

That means the system is synchronized to within a few milliseconds.

Final Thoughts

When a Windows clock is constantly wrong, changing the Internet time server is not always enough.

The real problem may be hidden deeper in the Windows Time configuration.

The most important diagnostic command is:

w32tm /query /configuration

It can reveal whether:

• the NTP client is disabled;
• the server configuration is invalid;
• Group Policy is overriding local settings;
• Windows is relying on its CMOS clock;
• an external NTP server is actually being used.

A particularly confusing situation occurs when Windows is configured with:

Type: NTP

but the server value is effectively empty:

NtpServer: ,0x1

In that situation Windows appears to be configured for Internet time, but it has no actual NTP server to contact.

Once the NTP client is enabled, a valid server is configured, the Windows Time service is restarted, and synchronization succeeds, a clock that was minutes behind can return to millisecond-level accuracy.