Windows Server 2019 — Windows Time service drifts beyond Kerberos tolerance — Fix & Prevention

📖 ~1 min read

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution — Primary Fix
7. Solution — Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

The Windows Time service on Windows Server 2019 drifts more than five minutes from the PDC emulator, so Kerberos rejects tickets and authentication fails. Member servers report time-skew errors and services that depend on accurate timestamps misbehave.

Environment & Reproduction

Reproduce on hosts with unreliable hardware clocks, broken NTP sources, or virtualization hosts that override guest time. Inspect w32tm output.

Get-Service -Name w32time
Get-WinEvent -LogName System -MaxEvents 40
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Root Cause Analysis

Causes include misconfigured NTP source, Hyper-V time sync conflict with NTP, blocked UDP 123 to the source, or stopped W32Time service.

Quick Triage

Capture current time offset, configured NTP source, and W32Time service state before remediation.

sc.exe query w32time
Get-Service -Name w32time | Select-Object Status,StartType
Get-EventLog -LogName System -Newest 30 | Where-Object {$_.Source -match 'w32time'}

Step-by-Step Diagnosis

Run w32tm to inspect peer state, time offset, and source quality.

Get-WinEvent -LogName System -MaxEvents 50 | Where-Object {$_.ProviderName -match 'w32time'} | Select TimeCreated,Id,LevelDisplayName,Message
sc.exe qfailure w32time
sfc /verifyonly

Solution — Primary Fix

Configure an authoritative NTP source, restart W32Time, and force resync to bring offset within tolerance.

Restart-Service -Name w32time -Force
Get-Service -Name w32time | Select-Object Status,StartType
Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.ProviderName -match 'w32time'}

Solution — Alternative Approaches

On Hyper-V guests, disable the time provider on either Hyper-V Integration or Windows Time depending on policy.

sc.exe config w32time start= auto
sc.exe failure w32time reset= 86400 actions= restart/60000/restart/60000/run/1000
Restart-Service -Name w32time -Force

Verification & Acceptance Criteria

Time offset is within tolerance, W32Time peers are healthy, and Kerberos errors stop on dependent hosts.

Get-Service -Name w32time
Get-WinEvent -LogName System -MaxEvents 25 | Where-Object {$_.ProviderName -match 'w32time' -and $_.LevelDisplayName -eq 'Error'}
Test-NetConnection -ComputerName localhost -Port 

Rollback Plan

Restore the previous W32Time configuration and earlier NTP source if a regression occurs.

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
wbadmin get versions
# Restore previous configuration export if available

Prevention & Hardening

Use a layered NTP design, monitor time offset continuously, and document the time source hierarchy.

Get-Service -Name w32time | Export-Clixml C:/Temp/w32time-baseline.xml
Get-WinEvent -LogName System -MaxEvents 50 > C:/Temp/w32time-events.txt
Get-ScheduledTask | Where-Object {$_.TaskName -match 'w32time'}

Related Errors & Cross-Refs

Linked to events 36, 38, and Kerberos KRB_AP_ERR_SKEW.

Related tutorial: View the step-by-step tutorial for Windows Server 2019.

View all Windows Server 2019 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Microsoft Learn references for Windows Time configuration on Windows Server 2019.