Windows Server Time Synchronization Troubleshooting Checklist

Why Windows Server time matters

Time drift can cause Kerberos authentication failures, certificate validation problems, scheduled task issues, cluster warnings and inconsistent application logs. Start by establishing whether the problem affects one server, a group of servers or the domain time hierarchy.

Check the current time configuration

Run w32tm /query /status and w32tm /query /configuration. Check the source, stratum, last successful synchronization and configured providers. Compare the server time with a known-good domain controller or approved NTP source.

Check the Windows Time service

Verify the service with Get-Service W32Time. If it is stopped, review the System event log before restarting it. A restart can confirm whether the issue is service state or configuration.

Validate the domain time hierarchy

For domain-joined servers, determine whether the machine should synchronize from the domain hierarchy rather than a manually configured public NTP server. On the PDC emulator, verify the external time source and configuration.

Force a synchronization

After correcting the configuration, use w32tm /resync. If the command fails, review the Windows Time operational events and confirm UDP 123 connectivity to the configured source.

Production checklist

Record the current source, stratum, last sync time and local offset. Correct the time hierarchy first, then validate Kerberos, certificates, scheduled tasks and clustered workloads.