Bad time on Windows Server 2025 can cause Kerberos failures, Active Directory replication warnings, and certificates with impossible dates. These faults look unrelated until you check the clock.
Kerberos allows five minutes of clock skew by default. Repeating w32tm /resync won’t repair a bad source or time hierarchy. Check the active source, offset, and configuration type first.
Prerequisites
This guide applies to:
- Windows Server 2025 with the Windows Time service
- Domain-joined servers, domain controllers, and standalone servers
- An elevated Command Prompt or PowerShell session
- Administrative access for service, policy, or firewall changes
- Network access to the approved time source over UDP port
123
Commands and output were checked against the Windows Server 2025 w32tm interface on August 2, 2026. Peer names in the examples are placeholders. Replace them with NTP servers approved for your network.
Before changing domain time settings, find the domain controller that owns the PDC emulator Flexible Single Master Operation role. Changing the wrong DC leaves the real time authority untouched. That’s an efficient way to lose an afternoon.
Quick Diagnosis
1. Check synchronization status
Open Command Prompt or PowerShell as Administrator:
w32tm /query /statusA synchronized server should show the intended source, a recent successful sync, and a sensible stratum:
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference – syncd by (S)NTP)
Last Successful Sync Time: 8/2/2026 6:28:41 AM
Source: DC01.example.net
Poll Interval: 10 (1024s)
Start with Source. It shows what the server uses now, which may differ from an old configuration record. Local CMOS Clock or Free-running System Clock means the server has no usable network time source.
The poll interval is an exponent. A value of 10 means 2^10, or 1,024 seconds.
2. Inspect configured peers
w32tm /query /peersExpected output includes the configured peer and its state:
#Peers: 1
Peer: DC01.example.net
State: Active
Time Remaining: 824.3817490s
Mode: 3 (Client)
Stratum: 2 (secondary reference – syncd by (S)NTP)
A configured peer isn’t always the active source. Compare /query /peers with /query /status. The first shows candidates. The second shows the selected source.
3. Compare domain computer offsets
Run this from a domain-connected administrative computer:
w32tm /monitorTypical output looks like this:
DC01.example.net *** PDC *** [192.0.2.10]:
ICMP: 1ms delay
NTP: +0.0000000s offset from DC02.example.netDC02.example.net [192.0.2.11]:
ICMP: 1ms delay
NTP: -0.0186421s offset from DC01.example.net
An offset of 18 milliseconds, as shown above, is routine. Large or growing offsets suggest a bad source, network fault, stopped service, or competing hypervisor clock control.
Treat the ICMP and NTP results separately. A 1 ms ping proves IP reachability. It doesn’t prove that UDP 123 works.
4. Check Windows Time events
Open Event Viewer and go to:
Windows Logs > System
Filter the log by the Microsoft-Windows-Time-Service event source. Check warnings and errors near the last failed sync. Reading every time event since installation rarely pays off.
You can also query the 20 newest entries in PowerShell:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Time-Service'
} -MaxEvents 20The PowerShell query is easier to paste into a ticket or run remotely. Event Viewer helps when you need nearby service, DNS, or network events.
Symptoms and Quick Fixes
| Symptom | Likely cause | Quick fix |
|---|---|---|
| Kerberos rejects tickets | Clocks differ by more than five minutes | Repair the NT5DS hierarchy, then resynchronize |
Source shows Local CMOS Clock | No usable network source | Check peers, policy, service state, and UDP 123 |
/resync reports no time data | Peer is unreachable or invalid | Diagnose the peer and firewall before retrying |
| Domain member uses an internet peer | Incorrect local or Group Policy setting | Restore NT5DS or domain-hierarchy synchronization |
| PDC emulator uses an internal DC | Forest time authority is misconfigured | Configure approved external peers on the PDC emulator |
| VM clock jumps after correction | Hypervisor and W32Time are competing | Select one intended time authority |
| Certificate dates appear wrong | Local clock or time zone is incorrect | Correct synchronization and confirm the time zone |
Use this table for triage, but still run /query /status. Two servers can show the same Kerberos error for different reasons.
Common Issues and Solutions
Problem: Kerberos Authentication Fails Because of Clock Skew
Symptoms:
- Users cannot sign in or access domain services.
- Kerberos reports clock-skew or ticket-validity errors.
- The affected server differs from a domain controller by close to or more than five minutes.
- Replication or secure-channel operations also fail.
Why it happens: Kerberos uses timestamps to limit replay attacks. Its default tolerance is five minutes. Past that limit, valid tickets can appear expired or not yet valid.
Solution:
Check the active source and compare domain controllers:
w32tm /query /status
w32tm /monitorOn an ordinary domain member, restore sync through the Active Directory domain hierarchy:
w32tm /config /syncfromflags:domhier /update
w32tm /resync/syncfromflags:domhier selects the domain hierarchy instead of a manual internet peer. /update applies the new Windows Time configuration without restarting the service.
This repair suits a normal domain member. Don’t point every affected server at public NTP. That creates several separate clocks and a larger mess.
Verification:
w32tm /query /statusConfirm that Source names a suitable domain time source. Last Successful Sync Time should be current. If the source remains wrong, check effective Group Policy before changing the local settings again.
Problem: “The Computer Did Not Resync Because No Time Data Was Available”
Symptoms:
The computer did not resync because no time data was available.
w32tm /resyncfails at once or after a timeout.- Peers appear configured but remain pending or unreachable.
- The server falls back to its hardware clock.
Why it happens: W32Time received no usable reply from its intended source. Common causes include a wrong peer name, failed DNS, blocked UDP 123, an unavailable NTP service, or the wrong sync type.
Solution:
Inspect the current settings before retrying:
w32tm /query /status
w32tm /query /peers
w32tm /query /configurationResolve the configured peer:
Resolve-DnsName ntp1.example.netReplace ntp1.example.net with the approved source. A successful DNS lookup clears only one checkpoint. You still need outbound UDP 123, return traffic, and an NTP service that accepts this client.
Check edge firewalls, network access lists, host firewall policy, and upstream NTP restrictions. Checking only Windows Defender Firewall misses plenty of real failures.
After correcting the source or network path:
w32tm /resync
Verification:
w32tm /query /statusThe source should no longer be Local CMOS Clock. The last successful sync time should update. If it doesn’t, return to the Time Service events. Another resync request won’t make a blocked packet less blocked.
Problem: A Domain Member Uses a Direct External NTP Peer
Symptoms:
/query /statusshows an internet or external source on an ordinary member server./query /configurationreports manual NTP instead of domain sync.- Time settings differ between servers in the same domain.
Why it happens: A local command or Group Policy Object moved the computer away from the NT5DS Active Directory time hierarchy.
Ordinary domain members should normally use NT5DS. Separate external peers break the managed domain time chain and make faults harder to trace.
Solution:
Restore the domain hierarchy:
w32tm /config /syncfromflags:domhier /update
w32tm /resyncReview effective policy to find any domain-linked policy that forces manual peers:
gpresult /scope computer /rLocal settings lose to Group Policy during the next refresh. If your fix keeps disappearing, stop applying it locally and find the winning GPO.
Verification:
w32tm /query /status
w32tm /query /configurationConfirm that the active source belongs to the domain hierarchy. The effective type should also suit a domain member.
Problem: The PDC Emulator Uses the Wrong Source
Symptoms:
- Domain members agree with each other, but the whole domain drifts.
- The forest-root PDC emulator uses another ordinary domain controller.
- The PDC reports
Local CMOS Clock. - Authentication, replication, and certificate warnings affect several systems.
Why it happens: The PDC emulator in the forest-root domain sits at the top of the standard Active Directory time hierarchy. It should get time from reliable external providers approved by your organization.
First, identify the role holder:
netdom query fsmoExpected output includes:
PDC DC01.example.net
The command completed successfully.
Run the next command on that PDC emulator. Don’t use whichever DC happens to be open in your terminal. Configure at least two approved peers:
w32tm /config /manualpeerlist:"ntp1.example.net,0x8 ntp2.example.net,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resyncReplace both example.net names. The 0x8 flag requests client-mode communication. /reliable:yes marks this domain controller as a reliable source for downstream domain clients. Don’t set it on every member server.
Two peers provide failover, but poor peers still provide poor time. Use sources your network team permits and can monitor.
Verification:
w32tm /query /peers
w32tm /query /statusConfirm that the PDC uses an approved external source. Then run w32tm /monitor and check downstream offsets. A correct PDC source won’t repair every badly skewed client at once. The offsets should start moving in the right direction.
Problem: Group Policy NTP Settings Do Not Apply
Symptoms:
- Local changes disappear after policy refresh.
NtpServerdoes not contain the expected sources.- A member server keeps switching between NT5DS and manual NTP.
/query /configurationshows policy settings that differ from local settings.
Why it happens: You may have edited the wrong Group Policy Object. A higher-priority policy may win. The setting may also be linked to the wrong computer organizational unit.
Solution:
Edit the intended computer policy at:
Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers
Open Configure Windows NTP Client. Enable it only where policy should manage the settings, then set:
- NtpServer: Organization-approved peer list
- Type:
NT5DSfor ordinary domain members, orNTPfor the authoritative PDC or applicable standalone system - Other controls: Keep organization-specific polling and compatibility values unless you have a documented reason to change them
Refresh computer policy:
gpupdate /forceThen request sync:
w32tm /resyncgpupdate /force reapplies all computer policy, so other settings refresh too. On a busy server, use a suitable change window if other policies can affect services or security.
Verification:
gpresult /scope computer /r
w32tm /query /configuration
w32tm /query /statusRead these in order. gpresult identifies applied policy. /configuration shows the effective W32Time settings. /status shows the source Windows selected.
Problem: A Standalone or Workgroup Server Cannot Synchronize
Symptoms:
- The server has no domain hierarchy.
- The source remains the hardware clock.
/query /peersshows no peer or an unusable peer.- Certificate and log timestamps drift over time.
Why it happens: A standalone server can’t use Active Directory NT5DS discovery. It needs approved NTP peers configured directly.
Solution:
Configure the peers:
w32tm /config /manualpeerlist:"ntp1.example.net,0x8 ntp2.example.net,0x8" /syncfromflags:manual /update
w32tm /resyncReplace the placeholder names with approved sources. Don’t add /reliable:yes; that option is for a server acting as an authoritative domain time source.
Manual peers add another setting to maintain. Document them, especially on workgroup servers that won’t receive a domain GPO when providers change.
Verification:
w32tm /query /peers
w32tm /query /statusCheck the active source, last successful sync, and stratum. A peer listed as Pending hasn’t completed a successful exchange.
Problem: A Hyper-V or VMware Guest Clock Keeps Jumping
Symptoms:
- The clock becomes correct, then jumps backward or forward.
- Event timestamps show frequent corrections.
- Drift returns after migration, pause, resume, or snapshot restore.
- The guest switches between host-provided time and a domain source.
Why it happens: Hyper-V Integration Services or VMware Tools can adjust the guest clock while W32Time follows NT5DS or NTP. Two active time authorities can keep correcting each other.
Solution:
Choose the authority that controls steady-state guest time:
- Domain-joined Windows guests should normally follow NT5DS.
- Standalone guests need a planned NTP or host-time design.
- Hypervisor time integration can help during boot or resume, but its behavior must match your policy.
Review the persistent VM integration setting on the host. In Hyper-V Manager, open the VM’s Settings > Integration Services and inspect Time synchronization. In VMware, inspect the VM’s VMware Tools time sync controls.
Don’t disable host integration across every VM without checking snapshot, resume, and boot behavior. Hypervisor time support can recover a guest after a long pause. Continuous correction may conflict with W32Time.
After removing the conflict, run inside the guest:
w32tm /resync
w32tm /query /statusVerification: Monitor the guest for several polling intervals. Its source should remain stable, and its offset shouldn’t keep growing. One clean status query proves less than 30 minutes of stable behavior.
Error Messages Reference
| Error or status | Meaning | What to check |
|---|---|---|
The computer did not resync because no time data was available | No usable response reached W32Time | Peer name, DNS, UDP 123, peer availability, and sync type |
The service has not been started | Windows Time is stopped | Service state, startup policy, and service-related System events |
The following error occurred: Access is denied. (0x80070005) | The session lacks required rights | Open the terminal as Administrator and check policy delegation |
Local CMOS Clock | The hardware clock is the current fallback source | Intended peer, NT5DS hierarchy, network path, and event log |
Free-running System Clock | The system has no active synchronized source | W32Time state, peers, policy, and connectivity |
Peer state is Pending | No successful exchange has completed yet | DNS, routing, firewall, and server response |
Large positive or negative /monitor offset | Computers disagree on current time | Time hierarchy, PDC source, VM integration, and recent restores |
| Kerberos clock-skew error | Client and domain authority exceed allowed skew | Compare offsets and repair NT5DS before retrying authentication |
Error text tells you where to begin, not what to change. No time data was available, for example, can point to DNS, firewall, peer, or configuration trouble.
Platform-Specific Issues
On iOS
Windows Time Service doesn’t run on iOS. An iPhone or iPad also can’t perform local w32tm administration. Open a remote session on the Windows Server through an approved method. Run the Windows commands there.
Don’t use the iOS device’s clock as the authority for Active Directory. Compare the server with its domain source or approved NTP system.
On macOS
W32Time is a Windows Server component, so w32tm commands don’t run locally on macOS. From a Mac, connect to a Windows administrative workstation or the server through an approved remote path. Run the commands in an elevated Windows session.
The Mac’s time settings don’t change NT5DS, the PDC emulator, or Windows NTP Client policy. The Mac works as a remote console, but it has no role in the Windows time chain.
Configuration Issues to Avoid
| Configuration | Correct use | Common mistake |
|---|---|---|
NT5DS | Ordinary domain members and most domain controllers | Replacing it with direct internet peers on every server |
| Manual NTP | Forest-root PDC emulator or standalone server | Applying the same manual peer policy across the domain |
/reliable:yes | Appropriate authoritative domain time source | Marking members or multiple unrelated servers as reliable |
NtpServer policy | Centrally managed, approved peer list | Using an invalid name or applying it to the wrong organizational unit |
w32tm /resync | Requesting sync after the cause is corrected | Repeating it without checking status, peers, logs, or connectivity |
| Hypervisor time sync | Boot, resume, or a documented guest-time design | Letting host integration compete with NT5DS continuously |
UDP 123 firewall access | Required between client and intended NTP source | Opening an unrelated TCP rule or checking only the local firewall |
The usual problem is competing authority. Domain hierarchy, manual peers, Group Policy, and hypervisor integration work when each has a defined job. Overlap makes the clock unpredictable.
Getting Help
Collect evidence before escalating:
w32tm /query /status /verbose
w32tm /query /peers
w32tm /query /configuration
w32tm /monitorAlso export relevant entries from Event Viewer > Windows Logs > System, filtered to Microsoft-Windows-Time-Service.
Include these details in the support case:
- Server name, Windows Server 2025 build, and domain membership
- Whether the server is the PDC emulator
- Current source, peer list, stratum, and last successful sync
- Measured offsets from
w32tm /monitor - Applicable Group Policy Object and effective configuration
- Firewall or network controls between the server and its source
- Hyper-V or VMware time-integration state
This bundle answers the first round of support questions before the ticket bounces between identity, network, and virtualization teams. Redact internal names or addresses only when the support channel requires it.
Microsoft documents the service in Windows Time Service tools and settings and How the Windows Time Service works.
Prevention Tips
- Keep one clear hierarchy: Let ordinary domain members use NT5DS and place approved external peers at the correct PDC emulator.
- Configure more than one approved peer: A second source keeps one failed provider from stopping external sync.
- Monitor the PDC emulator: Alert on stale sync, unexpected sources, and growing offsets.
- Audit Group Policy: Avoid overlapping NTP policies with different
TypeorNtpServervalues. - Document firewall paths: Record where UDP
123must pass between each time authority. - Review VM templates: Ensure cloned Hyper-V and VMware guests use the intended time design.
- Check time after restores: Snapshots, restores, pauses, and migrations can cause sudden clock changes.
- Track role transfers: Recheck external time settings when the PDC emulator role moves.
I’d put PDC source monitoring and role-transfer checks near the top of the operations list. A healthy domain can drift as one unit without an obvious split between members.
Frequently Asked Questions
How can I tell whether Windows Server 2025 is synchronized?
Run w32tm /query /status. Check the source, last successful sync time, leap indicator, and stratum. A recent sync from the intended source is the clearest proof.
Which domain controller should use an external NTP source?
In the standard Active Directory hierarchy, configure the PDC emulator in the forest-root domain with approved external NTP providers.
Should ordinary domain members use external NTP peers?
Normally, no. Ordinary domain members should use NT5DS and follow the Active Directory time hierarchy. Direct peers create separate time paths and more settings to audit.
How do I request synchronization after changing settings?
Run:
w32tm /resyncIf it fails, check the source, policy, Time Service events, and UDP 123 path before retrying. The command requests a sync. It doesn’t repair the cause of a failed sync.
Wrapping Up
| Step | Action | Applies To |
|---|---|---|
| 1 | Check status, source, and stratum | All servers |
| 2 | Inspect peers, offsets, and System events | All servers |
| 3 | Restore NT5DS | Ordinary domain members |
| 4 | Configure approved external peers | Forest-root PDC emulator |
| 5 | Configure manual peers | Standalone servers |
| 6 | Resolve firewall or hypervisor conflicts | Affected systems |
| 7 | Resynchronize and verify | All corrected servers |
A stable Windows time design has one trusted domain path and direct peers only where needed. Keep the hypervisor from fighting W32Time. Check the active source first, and the fault often becomes a short routing or policy job.
Run w32tm /resync after the source and network path are correct. That order is less dramatic, but it works.
Last updated: 2026-08-02 | Applies to Windows Server 2025 Windows Time Service
For more information on Windows Server 2025, you can visit How to Migrate from Windows Server 2019/2022 to 2025 Safely or Fix Windows Server 2025 Boot Issues with DISM, BCDEdit, WinRE, and ReAgentC.