Windows Server Time Sync: W32Time, NTP, and RDP Authentication Fixes

An inaccurate clock on a Windows VPS does more than show the wrong timestamp: a skew of more than 5 minutes breaks RDP logins, Kerberos authentication, and Active Directory communication entirely. This guide covers how Windows Server keeps time, how to point W32Time at reliable NTP sources, and how to fix the authentication errors that follow a drift. You will need administrator access to the server and the ability to open outbound UDP port 123 if your provider blocks it.

How Time Sync Works on a Windows VPS

Time on Windows Server is managed by the W32Time service. On most VPS deployments the default source is the hypervisor clock (VMIC time sync), which keeps the VM roughly in step with the host but does not give you a true NTP-stratum source. For servers that participate in a domain or handle authentication, you want a real NTP source.

Check the current configuration first:

w32tm /query /status
w32tm /query /source
Get-Service w32time

If the source shows “VM IC Time Synchronization Provider” or “Local CMOS Clock”, the server is not using network time. That works for a lone web server but becomes a problem the moment authentication enters the picture.

Point W32Time at Reliable NTP Servers

Set manual peers with the 0x8 flag (client mode) so the server synchronizes periodically instead of once:

w32tm /config /manualpeerlist:"pool.ntp.org,0x8 time.cloudflare.com,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resync

These settings live in HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. If your VPS provider blocks outbound UDP port 123, ask them to open it or use their documented time endpoint instead – NTP cannot work through a blocked port. After changing the config, verify the resync actually happened:

w32tm /query /status
w32tm /query /peers

Fix RDP and Kerberos Authentication Failures

When a server drifts more than 5 minutes from the domain or client clock, you will see errors like “The time stamp on this computer is more than 5 minutes different from the time on this computer”, RDP logon rejections, and Kerberos failures in Event Viewer under the System and Security logs. In the W32Time event log, Event ID 36 or Event ID 12 usually accompanies a failed sync.

• Resync immediately: w32tm /resync.
• Confirm the source: w32tm /query /source should show your NTP peer, not “Local CMOS Clock”.
• Restart the service if needed: Restart-Service w32time.
• Verify after resync: w32tm /query /status and check the Last Successful Sync Time value.
• If drift keeps returning, disable the hypervisor time provider so it stops fighting NTP: set HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICClockProvider to Enabled=0 and restart W32Time.

Set the Correct Time Zone

A correct UTC offset is as important as the time itself. Windows stores time internally as UTC, and most server logs expect UTC; set the zone explicitly to avoid display drift. Getting this wrong shows up in odd places: scheduled tasks fire at the wrong local hour, IIS logs carry the wrong timestamp, and certificate validation windows shift by the offset.

Set-TimeZone -Id "UTC"          # or tzutil /s "UTC"
Get-TimeZone -ListAvailable     # find your zone ID

Command	Purpose
w32tm /query /status	Show current sync state and source
w32tm /config /manualpeerlist	Set NTP peers and sync flags
w32tm /resync	Force an immediate time correction
w32tm /stripchart /computer:pool.ntp.org	Measure offset against a remote source

If you run Active Directory on the VPS, keep the PDC emulator as the authoritative time source and configure member servers to sync from it, not from the internet. A domain with two time sources will slowly split into two clocks, and Kerberos tickets start failing between the halves – the errors are intermittent and hard to diagnose, so standardize on one hierarchy.

Finally, watch drift over time rather than fixing it once. A cheap way to monitor is a weekly scheduled task that logs the offset:

w32tm /stripchart /computer:pool.ntp.org /samples:3 /dataonly >> C:\logs\ntp_offset.log

If the offset creeps past one second between runs, the NTP peer list or the hypervisor time provider is the first thing to re-check. You can compare Windows VPS providers on our comparison table for plans with reliable uptime, and find more Windows Server administration guides on windows-vps.org.

Testing time sync on a new server is easy – Contabo offers affordable Windows VPS plans where you can run these commands within minutes of provisioning.