Helpdesk: "PC-ACC-114 is seven minutes behind the wall clock, Outlook keeps asking for a password, and the Finance share says access denied. FS02 is a couple of minutes off too. A forum thread says to push a GPO that points every machine at pool.ntp.org, then run w32tm /resync /force everywhere. Can we just do that tonight?"
Don't push that GPO yet. "Windows time not syncing with the domain controller" is several different breaks that all show up as a wrong clock. Microsoft's own description of the Windows Time service explains why the forum fix backfires: manually specified time sources "are not authenticated unless a specific time provider is written for them," and "if a computer synchronizes with a manually specified source rather than its authenticating domain controller, the two computers might be out of synchronization, causing Kerberos authentication to fail." The domain already has a time design. A member follows a domain controller, the domain controllers follow the hierarchy, and the PDC emulator of the forest root sits at the top. Work through it as a chain: the machine, its offset, its source, and the events on the ticket → what the client is actually using (w32tm /query /source, /status, /configuration) → the hierarchy above it: which DC, and how far off each hop is → the forest root PDC emulator: is it reading a real external source, or its own clock? → virtual machines: is the hypervisor overriding the domain? → the network: UDP 123, DC discovery, events 129 and 134 → Group Policy that rewrites the time settings → big offsets, phase correction limits, and the Kerberos five-minute window. w32tm, Get-ADDomain, Get-ADDomainController -Discover, Get-VMIntegrationService, and the Time-Service events in the System log are the sources for that chain. Point every PC at the internet and the domain controllers are still wrong tomorrow, only now the clients disagree with them.
If the ticket started as "The trust relationship between this workstation and the primary domain failed" after a clock jump, read Trust Relationship Between This Workstation and the Primary Domain Failed after this one. If the symptom is Kerberos-only SSO prompts, Entra Seamless SSO Not Working covers the ticket side. This post covers "Windows clients, member servers, or domain controllers aren't syncing time with the domain: the clock drifts, w32tm /resync says no time data was available, the source reads Local CMOS Clock or Free-running System Clock, a DC follows its Hyper-V or VMware host, or Kerberos fails on clock skew, and you need a read-first path through source, hierarchy, PDC emulator, virtualization, network, policy, and phase correction before you re-register W32Time, point machines at the internet, or widen the Kerberos tolerance."
TL;DR
-
Read the source before you resync. Microsoft's first step for a specific client is
w32tm /query /status: "The source indicates with whom you synchronize time in the domain." - Domain members should be NT5DS. Microsoft: "Most domain-joined computers have a time client type of Net Time 5 Directory Service (NT5DS)." The exception is the forest root PDC emulator, which is "configured to synchronize time with an external time source."
-
Find the hop where it goes wrong. Microsoft: run
w32tm /monitor, and "By locating the point where the time offset gets significantly worse, you can pinpoint the root of the incorrect time." - "No time data was available" is a reachability problem. Microsoft's three scenarios: the client can't find the server, UDP 123 is blocked, or the target "isn't advertising as an NTP Server."
- Virtual DCs should follow the domain, not the host. Microsoft recommends that you "disable time synchronization between the host system and guest OS that's acting as a DC."
- Five minutes is the Kerberos line. Microsoft: the difference between the DC and the client or target server "must be less than five minutes."
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Machines, offsets, sources, and event IDs written down | "Time is wrong" with no source or offset |
| 2. Client source | Source is a DC; type NT5DS; last sync recent | Source Local CMOS Clock, Free-running System Clock, time.windows.com, or the VM provider |
| 3. Hierarchy | Each hop up to the PDC emulator is close | One DC is off and every client behind it follows |
| 4. Forest root PDC emulator | Type NTP, a real external or hardware source, marked reliable | Event 12; PDC on its own clock; a second "reliable" DC |
| 5. Virtualization | DC guests follow the domain hierarchy | DC jumps after a host change, migration, or restore |
| 6. Network and discovery | UDP 123 open both ways; DCs found and advertising | Events 129 or 134; "no time data was available" |
| 7. Policy | One GPO design; no conflicting Configure Windows NTP Client
|
Settings come back after every fix |
| 8. Offset size and Kerberos | Offsets inside the phase correction limits and well under five minutes |
KRB_AP_ERR_SKEW; a DC that refuses a 3-day correction |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Every PC on pool.ntp.org, DCs still wrong |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which machines are off, and by how much | One PC, one site, every member of one DC, or every DC point at different steps |
| Ahead or behind, and is it drifting or jumping? | Slow drift reads as no sync. A sudden jump reads as a bad sample, a host, or a restore (our reading) |
| Role of each machine | Member, DC, PDC emulator, forest root or child domain. Each has its own time rules (Step 3) |
| Physical or virtual, and which hypervisor | Hyper-V, VMware, and Azure each have Microsoft guidance (Step 5) |
| What changed? | PDC role moved, DC rebuilt, VM migrated, firewall change, new GPO, BIOS battery, a long power-off |
| Time-Service events in the System log | 12, 36, 129, 134, 35, 37, and 138 each point at a different step |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
One PC off; source is time.windows.com or a manual peer |
It was configured manually, or it was set up before it joined the domain (Microsoft's tools page names that case) | Steps 2, 7 |
Source Local CMOS Clock or Free-running System Clock
|
Not taking time from any peer right now | Steps 2, 6 |
| Every client behind one DC is off by the same amount | That DC is wrong, and its clients are following it correctly | Step 3 |
| Every DC and client off together | The top of the hierarchy: the forest root PDC emulator or its source | Step 4 |
| A virtual DC jumps after maintenance | The hypervisor's time provider is winning | Step 5 |
w32tm /resync says no time data was available |
Discovery, name resolution, or UDP 123 (Microsoft's three scenarios) | Step 6 |
Your fix is gone after a reboot or a gpupdate
|
A GPO is rewriting the W32Time settings | Step 7 |
| Kerberos errors, offset over five minutes | Clock skew. Microsoft's Kerberos checklist covers this case | Step 8 |
Step 2: Read what the client is actually using (read-only)
Microsoft's tools page describes the four /query views: /source "Displays the time source," /configuration "Displays the runtime configuration and the source of the settings," /peers "Displays a list of peers and their status," and /status "Displays the W32Time status." Run them on PC-ACC-114:
# Read-only. What is this machine using right now, and where did that setting come from?
w32tm /query /source
w32tm /query /status /verbose
w32tm /query /configuration
w32tm /query /peers
# Read-only. The same from an admin workstation (Microsoft: remote use needs Domain Admins)
foreach ($c in 'PC-ACC-114', 'FS02') { "== $c"; w32tm /query /computer:$c /source }
Microsoft's sample /status /verbose output, from a machine taking time from its Hyper-V host, includes these lines:
Last Successful Sync Time: 5/23/2023 7:51:39 PM
Source: VM IC Time Synchronization Provider
Poll Interval: 6 (64s)
Phase Offset: -0.0000013s
Time Source Flags: 3 (Authenticated Hardware )
Last Sync Error: 0 (The command completed successfully.)
Source reads |
What it means (our reading unless noted) | Next |
|---|---|---|
A DC in the same domain, e.g. DC02.corp.contoso.com
|
Following the hierarchy. Microsoft's check: the source "should be the name of a domain controller (or an administrator-configured time server) in the same Active Directory domain" | Step 3: is that DC right? |
time.windows.com or another internet name on a domain member |
Manual or non-domain configuration. Microsoft: non-domain computers default to time.windows.com | Step 7, then Step 9 |
Local CMOS Clock |
Running on its own hardware clock. Microsoft shows this as expected only on a DC with GPS hardware and its NTP client turned off | Step 6 on a member; Step 4 on a PDC |
Free-running System Clock |
No usable peer. Microsoft Q&A threads show it on a DC that should follow the hierarchy | Steps 4, 6 |
VM IC Time Synchronization Provider |
Taking time from the Hyper-V host (Microsoft's sample output) | Step 5 |
Then the type and where it came from. /configuration prints each value with its origin, such as (Local) in Microsoft Q&A output. A (Policy) tag means a GPO set it (our reading of "the source of the settings").
Type |
Microsoft's meaning | Expected on |
|---|---|---|
NT5DS |
"The time service synchronizes with the domain hierarchy." | Members and every DC except the forest root PDC emulator (Microsoft: default on domain members) |
NTP |
"The time service synchronizes with the servers specified in the NtpServer registry entry." | The forest root PDC emulator; stand-alone machines (Microsoft: default on stand-alone) |
AllSync |
"The time service uses all the available synchronization mechanisms." | Rare by design (our note) |
NoSync |
"The time service doesn't synchronize with other sources." | Only a deliberate root that trusts its own clock |
Why it may look slow to fix itself. Microsoft's registry defaults put MinPollInterval at 10 and MaxPollInterval at 15 (log base 2 seconds) on domain members, against 6 and 10 on domain controllers. By our arithmetic that's 1,024 seconds up to about 9 hours between polls on a member. A member left alone can take a while to notice a fixed DC (our reading). That's what /resync is for, after the read.
Step 3: Walk the hierarchy (read-only)
Microsoft's default hierarchy, from the authoritative time server article: "All client desktop computers nominate the authenticating domain controller as their in-bound time partner," member servers do the same, "All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner," and "the PDC operations master at the root of the forest becomes authoritative for the organization." The How-it-works page adds the selection detail. A DC makes up to six queries and scores candidates:
| Domain controller status | Microsoft's score |
|---|---|
| Located in the same site | 8 |
| Marked as a reliable time source | 4 |
| Located in the parent domain | 2 |
| Is a PDC emulator | 1 |
Microsoft: "The scores assigned by the time service are cumulative." A same-site PDC emulator scores 9. The 2016 improvements page adds that this check "happens once when the time service is started." So a member can keep following a DC you've since fixed or retired until it restarts or rediscovers (our reading).
# Read-only. Who should be at the top: the forest root domain and its PDC emulator
$root = (Get-ADForest).RootDomain
Get-ADDomain -Identity $root | Select-Object DNSRoot, PDCEmulator
# Read-only. Which DC does discovery hand out for time? (Microsoft's -Service values)
Get-ADDomainController -Discover -Service TimeService | Select-Object HostName, Site
Get-ADDomainController -Discover -Service ReliableTimeService -ErrorAction SilentlyContinue | Select-Object HostName, Site
# Read-only. Offsets for every DC Microsoft's monitor can find
w32tm /monitor /domain:corp.contoso.com
# Read-only. One hop at a time: the client's source, then that DC's source
w32tm /stripchart /computer:dc02.corp.contoso.com /samples:5 /dataonly
w32tm /query /computer:dc02.corp.contoso.com /source
Microsoft's 2016 page gives the method: start with w32tm /query /status on the client, "use the source entry from the preceding command and use the /stripchart parameter to find the next time source in the chain," and use w32tm /monitor /domain:my_domain, which "lists each DC it can find in the specified domain" and "includes machines that were configured manually." /stripchart "Displays a strip chart of the offset between this computer and another computer," and /dataonly "Displays the data only, without graphics."
| What the hops show | What it usually means (our reading unless noted) | Next |
|---|---|---|
| Client off, its DC off by the same amount, PDC fine | The DC is the problem | Run Step 2 on that DC |
| Every DC off by the same amount as the PDC emulator | The top is wrong | Step 4 |
| A DC's source is another non-PDC DC, which reads free-running | A second DC is announcing itself as reliable | Step 4, AnnounceFlags
|
| Child-domain DCs fine, forest root off | Microsoft: child-domain DCs "synchronize time with domain controllers in their parent domains." Fix the root first | Step 4 |
/stripchart times out |
Can't reach that hop. Microsoft lists intermittent "Request timed out" as an unresponsive NTP source | Step 6 |
Step 4: The forest root PDC emulator (read-only)
Microsoft's FSMO article: "The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source." The Engage Center remediation page names the warning you see when it isn't: "configuring this domain controller to sync time with the domain hierarchy is not valid. The Windows Time Service warns you of this condition by writing event ID 12." It also names the risk of leaving the PDC on its hardware clock: "If the time and date is not set accurately in the PDC emulator BIOS, time and date settings will be incorrect across the domain."
Read DC01 (the PDC emulator from Step 3):
# Read-only, on DC01. Type, peers, flags, and where each came from
w32tm /query /configuration
w32tm /query /source
w32tm /query /status /verbose
# Read-only. Is the upstream source answering, and how far off is it?
w32tm /stripchart /computer:ntp1.corp.contoso.com /samples:5 /dataonly
# Read-only. Time-Service warnings on DC01, last 7 days
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Time-Service'
Id = 12, 36, 129, 134
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List
# Read-only. AnnounceFlags, Type, and NtpServer on every DC in this domain
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
"== $dc"
w32tm /query /computer:$dc /configuration | Select-String -Pattern 'AnnounceFlags|Type:|NtpServer:'
}
What Microsoft's authoritative time server article configures on the forest root PDC, and what Microsoft's resync article expects on the other DCs:
| Setting | Forest root PDC emulator (Microsoft) | Other DCs (Microsoft) |
|---|---|---|
Parameters\Type |
NTP |
Domain hierarchy (NT5DS, the domain-member default) |
Parameters\NtpServer |
Your peers. The KB says append ,0x1 to each name; Microsoft's Engage Center and 2016 pages use ,0x8
|
Not used under NT5DS |
Config\AnnounceFlags |
5. Use 0xA instead if the upstream link is unreliable or you use a fixed SpecialPollInterval
|
10 |
TimeProviders\NtpServer\Enabled |
1 |
1 on all DCs |
Config\MaxPosPhaseCorrection / MaxNegPhaseCorrection
|
A "reasonable value, such as 1 hour (3600) or 30 minutes (1800)" | Default 172,800 (48 hours) on DCs |
AnnounceFlags values, from the tools page: 0x01 always time server, 0x02 automatic time server, 0x04 always-reliable time server, 0x08 automatic reliable time server. So 5 is 0x01 (Always time server) plus 0x04 (Always-reliable time server), and 10 is 0x02 plus 0x08, the automatic pair (our arithmetic).
| Finding on the PDC emulator | What it means (our reading unless noted) | Next |
|---|---|---|
Event 12, Type is NT5DS
|
The forest root PDC is set to follow a hierarchy with nothing above it (Microsoft's Engage Center page) | Step 9: point it at a real source |
Type NTP, source Local CMOS Clock or free-running |
Its peers aren't answering, or the names don't resolve |
/stripchart each peer, then Step 6 |
/stripchart to the peer shows a large offset |
The upstream itself is wrong | Pick a better source. Microsoft: a hardware source is "actually a better solution" |
AnnounceFlags 5 on a DC that isn't the PDC |
A second "reliable" DC. Microsoft's score table gives reliable +4, so others may prefer it | Step 9: back to the default after a role move |
PDC role moved recently, old PDC still NTP and reliable |
The old configuration stayed behind on the old PDC | Step 9: swap both |
Microsoft also explains why a root that can't reach its source is worse than it looks: "If the root of the synchronization hierarchy is not set to NoSync and if it is unable to synchronize with another time source, clients do not accept the packet that this computer sends out because its time cannot be trusted." And the 2016 page: a DC that loses its authoritative state "returns Unknown Stratum when queried via NTP. After trying multiple times, the DC logs System Event Time-Service Event 36."
Step 5: Virtual machines and the host clock (read-only)
Microsoft's guidance for running domain controllers in Hyper-V: "For VMs you configured to be DCs, we recommend that you disable time synchronization between the host system and guest OS that's acting as a DC. If the guest DC doesn't synchronize with the host system, then it synchronizes with the domain hierarchy instead." For other hypervisors, the 2016 page: "When Windows is virtualized, by default, the Hypervisor is responsible for providing time. But domain-joined members need to be synchronized with the DC for Active Directory to work properly. It's best to disable any time virtualization between the guest and the host of any third-party virtual platforms."
# Read-only, on the Hyper-V host HV01. Is the time integration service on for the DC guests?
Get-VMIntegrationService -VMName 'DC01', 'DC02' -Name 'Time Synchronization' |
Select-Object VMName, Name, Enabled, PrimaryStatusDescription
# Read-only, on HV01. Where does the host itself take time from?
w32tm /query /source
# Read-only, inside a guest. The Hyper-V time provider and its service
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider' -Name Enabled -ErrorAction SilentlyContinue
Get-Service -Name vmictimesync
Microsoft's integration services reference names the service vmictimesync ("Synchronizes the virtual machine's system clock with the system clock of the physical computer"). The Time Synchronization name and the selected properties are ours.
Read the Microsoft pages together, because they don't all say the same thing:
| Source | What it says |
|---|---|
| Running domain controllers in Hyper-V | Disable host time sync for DC guests: "turn the VM off, then go to the VM settings, select Integration Services and uncheck the Time synchronization check box" |
| Integration services reference | For vmictimesync: "When disabled, the virtual machine's clock drifts erratically" (written for VMs in general) |
| Windows Server 2016 improvements, "Virtualized domains" | For Windows Server 2012 R2 DCs, set VMICTimeProvider Enabled to 0. But "For the PDC, you don't want to disable the entry because the Hyper-V host delivers the most stable time source" |
| Same page, Azure | A DC VM in an on-premises forest: "TimeSync (VMIC) should be disabled." A domain-joined VM: disable TimeSync and sync with its DC. A workgroup VM: "keep the default time configuration" |
Our reading: follow the current DC page for every DC guest, and pick one documented design for the PDC emulator VM. If you keep host time on the PDC VM, the host's own time source becomes the top of your forest. Then check where the host gets its time. A domain-joined Hyper-V host normally takes time from a DC (the member default). If that DC is a guest taking time from the same host, the two can follow each other (our reading, and the kind of loop Microsoft's hierarchy is "designed to protect against").
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
DC guest source VM IC Time Synchronization Provider
|
The host's clock is driving that DC | Step 9: disable host time sync for that DC |
Enabled True on Time Synchronization for DC guests |
Not following Microsoft's DC guidance | Step 9 |
| VMware or another hypervisor; DC jumps after vMotion or tools updates | Hypervisor time sync still on (Microsoft: disable it on third-party platforms) | Your hypervisor's setting, then Step 2 again |
| Host source is a DC that's a guest on that host | A possible loop | Give the host, or the PDC, an independent source |
| A DC restored or reverted with the wrong time | A clock change plus an AD restore. Read Step 8 before you touch it | Step 8 |
Step 6: Network, discovery, and the Time-Service events (read-only)
Microsoft: "W32Time follows the Network Time Protocol (NTP) specification, which requires the use of User Datagram Protocol (UDP) port 123 for all time synchronization." The service's client is stricter than the test tool. /resync: "The NTP client requires UDP 123 as the source port." /stripchart: "The NTP client uses an ephemeral UDP source port to communicate to the server." So a firewall rule that allows ephemeral ports but not source port 123 can let /stripchart succeed while the service still fails (our reading).
# Read-only. Name, then a real NTP exchange, then DC discovery
Resolve-DnsName -Name 'dc02.corp.contoso.com'
w32tm /stripchart /computer:dc02.corp.contoso.com /samples:3 /dataonly
nltest /dsgetdc:corp.contoso.com /force /kdc
# Read-only, on the DC: does it advertise its roles?
dcdiag /test:Advertising
# Read-only. Which Time-Service events, how often, last 7 days
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Time-Service'
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Group-Object Id | Select-Object Name, Count
Test-NetConnection tests TCP, so it can't prove UDP 123 either way (our note). The nltest form is Microsoft's Kerberos checklist command. Microsoft's dcdiag reference: Advertising "Checks whether each domain controller advertises itself in the roles that it should be capable of performing," and fails "if the Netlogon Service has stopped or failed to start."
The events, with Microsoft's text where Microsoft's pages carry it:
| Event | Microsoft's text or meaning | Read it as |
|---|---|---|
| 129 | "NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter." | The member can't find a DC to take time from. Microsoft's archived event page: "There should be other events in Event Viewer that indicate that there is a problem locating a domain controller" |
| 134 | "NtpClient was unable to set a manual peer to use as a time source because of DNS resolution error on 'time.windows.com,0x9'" | A manual peer that doesn't resolve. On a domain member, also a sign it isn't on NT5DS (our reading) |
| 36 | Microsoft's 2016 page ties it to drifting clients and to a DC returning "Unknown Stratum" | The machine hasn't synced for a long time. Look upstream |
| 12 | Forest root PDC set to the domain hierarchy (Microsoft's Engage Center page) | Step 4 |
| 35 and 37 | Microsoft's archived event page: confirm they appear to verify that W32Time "synchronized successfully with its time source" | Good news after a fix |
| 138 | Same page: a recovery "from a previous failure to synchronize" | Good news after an outage |
Microsoft's resync error article lists three causes for "The computer did not resync because no time data was available":
| Scenario | Microsoft's cause | Microsoft's check |
|---|---|---|
| 1 | "The NTP client can't find the NTP server": DNS, or a misspelled name or IP in NtpServer
|
Check the spelling and the DNS servers |
| 2 | "UDP port 123 is blocked" on the local Windows Firewall or a non-Microsoft firewall | Capture traffic while you run w32tm /resync /rediscover. No outbound 123 = local firewall. Outbound with no reply = a firewall in the path |
| 3 | The target "isn't advertising as an NTP Server" | Check the hierarchy from the PDC down with w32tm /monitor, run dcdiag /test:Advertising, and check NtpServer Enabled=1 and AnnounceFlags on the DCs |
One more network case. Microsoft: some NTP servers "that don't run Windows respond only to requests that use client mode," while DCs use symmetric active mode by default. The fix is the 0x8 flag on that peer (Step 9). Our reading: suspect it when the PDC's upstream is a router or appliance and /stripchart answers but the service never syncs.
Step 7: Group Policy that rewrites the time settings (read-only)
Microsoft: W32Time policy lives under Computer Configuration\Administrative Templates\System\Windows Time Service, and "the values defined by Group Policy overwrite any preexisting values in the W32Time section of the registry. Some of the preset GPO settings differ from the corresponding default W32Time registry entries." Policy values are written under HKLM\SOFTWARE\Policies\Microsoft (the W32Time\... subkeys below are our reading of that footnote).
# Read-only. Policy-delivered W32Time values, if any GPO sets them
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\W32Time\Parameters' -ErrorAction SilentlyContinue
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\W32Time\TimeProviders\NtpClient' -ErrorAction SilentlyContinue
# Read-only. The service's own values (Microsoft: reference only; don't edit these by hand)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' | Select-Object Type, NtpServer
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config' |
Select-Object AnnounceFlags, MaxPosPhaseCorrection, MaxNegPhaseCorrection, MaxAllowedPhaseOffset
# Read-only. Which GPOs reached this computer
gpresult /scope computer /r
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
Configure Windows NTP Client enabled with Type NTP on a GPO linked to every computer |
Members leave the domain hierarchy. Microsoft's GPO default for domain-joined machines is NT5DS
|
Fix the GPO, not the PCs |
NtpServer set by GPO on a domain member |
"W32Time doesn't use the NtpServer registry value." Check with w32tm /query /configuration
|
Read the effective value, not the registry |
| A PDC GPO linked to the Domain Controllers OU without filtering | Every DC gets the PDC's external source. Microsoft's Engage Center steps remove Authenticated Users and add only the PDC emulator machine | Filter it to the PDC emulator |
| That filtered GPO names a computer that's no longer the PDC | The policy didn't follow the role transfer (our reading) | Update the filter with the role move |
/configuration shows (Policy) next to the value you keep fixing |
Your manual change will be overwritten (our reading) | Change the GPO |
If GPO is the layer, start with Group Policy Not Applying to confirm which policy wins.
Step 8: Big offsets, phase correction, and Kerberos (read-only)
How W32Time corrects. Microsoft: when the offset is at or under MaxAllowedPhaseOffset, it adjusts "gradually by using the clock rate"; above it, it sets "the computer clock immediately." Default MaxAllowedPhaseOffset: 300 seconds on domain members, 1 on stand-alone machines.
When it refuses. MaxPosPhaseCorrection and MaxNegPhaseCorrection are the largest corrections the service makes. "If the service determines that a change larger than this value is required, it logs an event instead." Microsoft's defaults:
| Machine |
MaxPos/NegPhaseCorrection (Microsoft) |
|---|---|
| Domain members |
0xFFFFFFFF: "the service always corrects the time" |
| Domain controllers | 172,800 seconds (48 hours) |
| Stand-alone clients and servers | 54,000 seconds (15 hours) |
Microsoft's large-offset article explains the 48 hours: "If any single domain controller experiences an unusual time jump of more than 48 hours, the value that you set ... will prevent other computers from making the same time jump," and an out-of-range sample "is ignored, and the time service logs the following message in the W32Time private log file: TOO BIG." It also lists what time travel breaks: "Passwords on computer accounts, on user accounts, and on trust relationships can be prematurely updated," and quarantines "can be identified by NTDS Replication Event 2042."
Kerberos. Microsoft's Kerberos checklist: "The difference in time between the domain controller and the client computer or the target server must be less than five minutes." It lists two cases that need action, "The clocks are out of sync by more than 48 hours," and "The out-of-sync clock doesn't use a domain controller in its domain as a time server, or doesn't use the same time server as those domain controllers do," with w32tm /resync /computer:<Target> /rediscover as the fix. The error strings: KERB_AP_ERR_SKEW with event ID 4. The policy behind it, Maximum tolerance for computer clock synchronization, is 5 minutes in the Default Domain Policy, and Microsoft's countermeasure is to "Configure ... to 5 minutes."
# Read-only. Offset from this machine to the PDC emulator and to its own DC
w32tm /stripchart /computer:dc01.corp.contoso.com /samples:5 /dataonly
w32tm /stripchart /computer:dc02.corp.contoso.com /samples:5 /dataonly
# Read-only. Kerberos event 4 mentioning skew, last 24 hours (the message filter is ours)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 4; StartTime = (Get-Date).AddDays(-1) } -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'SKEW' } | Select-Object TimeCreated, ProviderName, Message -First 5
# Read-only. Cached tickets on the client
klist
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Offset under 300 s and shrinking | It's slewing toward the right time | Wait and re-read. Don't step it by hand |
| Offset over five minutes, Kerberos failing | Clock skew outage on that machine | Fix the source (Steps 2-7), then /resync /rediscover
|
| DC off by more than 48 hours, no correction | The phase correction limit is holding it (Microsoft's design) | Find why it jumped before you correct it |
| Machine back after months off, wrong date | BIOS time used at boot until W32Time syncs (Microsoft) | Read the trust relationship post if logons fail |
| Many machines failing Kerberos at once | Upstream is wrong, not the clients | Step 4 |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| GPO that points every machine at pool.ntp.org | Microsoft: manual sources aren't authenticated, and a member off its authenticating DC "might be out of synchronization, causing Kerberos authentication to fail" | Members on NT5DS; only the forest root PDC on an external source |
w32tm /resync /force |
/force isn't in Microsoft's documented /resync switches (/computer, /nowait, /rediscover, /soft), our reading of the Learn table |
w32tm /resync /rediscover after you fix the source |
w32tm /unregister and /register first |
Wipes the configuration. Microsoft: /unregister "removes all its configuration information from the registry" |
Read /configuration and the GPO first |
| Raising the Kerberos tolerance | It hides the skew. Microsoft's countermeasure is 5 minutes | Fix the time source |
Setting MaxPos/NegPhaseCorrection to 0xFFFFFFFF on DCs |
Microsoft recommends a value "other than" MAX, so one bad DC can't drag the others | Keep the limits; investigate the jump |
| Marking a second DC reliable "for redundancy" | Microsoft's score table gives reliable +4; others may follow it | Redundancy at the PDC's upstream (three or more peers) |
Leaving the old PDC as NTP + reliable after a role move |
Two roots, one of them stale (our reading) | Swap both in Step 9 |
| Setting the date by hand on a DC | Microsoft's time-jump list: passwords prematurely updated, replication quarantine | Fix the source, then let W32Time correct |
| Turning host time sync off for every VM | Microsoft's DC guidance is for DC guests; the integration services page warns VM clocks can drift "erratically" without it | Domain-joined guests follow the domain; check each role |
Trusting Test-NetConnection for NTP |
NTP is UDP 123; that cmdlet tests TCP (our note) |
w32tm /stripchart plus a capture |
| Disabling W32Time | Microsoft: only when you deploy "a third-party time synchronization product that uses NTP" | Fix W32Time's configuration |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1-8 point at. Export the W32Time key on that machine first, and test on one machine before a fleet:
# Low-risk write. Save the current W32Time configuration before you change it (our habit)
reg export HKLM\SYSTEM\CurrentControlSet\Services\W32Time C:\Temp\w32time-before.reg /y
w32tm /config has no dry-run switch. Your dry run is the read in Steps 2-7 and the export above.
A member that left the hierarchy (Step 2), when no GPO sets it (Step 7). Microsoft's own command for this case, plus the /rediscover resync from Microsoft's Kerberos checklist:
# Change. Back to the domain hierarchy, restart the service, then rediscover and resync
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /rediscover
Microsoft: /rediscover "Redetects the network configuration, rediscovers network sources, and then resynchronizes." If a GPO sets Type NTP, change the GPO instead, or the next refresh puts it back.
Forest root PDC emulator on a real source (Step 4). Microsoft's 2016 GTIMESERV form and Engage Center command, with three internal peers because Microsoft recommends "three or more time servers" for multiple peers:
# Change, on DC01 only. External or appliance peers in client mode, mark reliable
w32tm /config /manualpeerlist:"ntp1.corp.contoso.com,0x8 ntp2.corp.contoso.com,0x8 ntp3.corp.contoso.com,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resync /rediscover
Microsoft's KB 816042 does the same through the registry (Type = NTP, AnnounceFlags = 5, NtpServer Enabled = 1, peers with ,0x1, lower phase correction limits), then restarts W32Time. With only two peers, Microsoft says to flag one 0x2 (UseAsFallbackOnly). Either way, configure the PDC emulator of the forest root only. Child-domain PDCs follow the parent domain (Microsoft).
After a PDC role move (Step 4). Our combination of Microsoft's /syncfromflags and /reliable switches:
# Change, on the OLD PDC emulator. Back to the hierarchy, no longer reliable
w32tm /config /syncfromflags:domhier /reliable:no /update
net stop w32time
net start w32time
# Then run the DC01 command above on the NEW PDC emulator, and update any PDC-filtered GPO (Step 7)
Then w32tm /resync /rediscover on DCs that logged 129 after the move, because Microsoft's time-source check "happens once when the time service is started."
A virtual DC following its host (Step 5). Microsoft's steps turn the VM off first, then clear Time synchronization in Integration Services. The cmdlet form is ours, and it has a real -WhatIf:
# Change, on HV01, with DC02 shut down. Dry-run first
Disable-VMIntegrationService -VMName 'DC02' -Name 'Time Synchronization' -WhatIf
On a Windows Server 2012 R2 DC guest, Microsoft's alternative is VMICTimeProvider Enabled = 0 plus a W32Time restart. For the PDC emulator VM, decide using the Step 5 table and write the decision down. For VMware and other platforms, Microsoft says to disable time virtualization between guest and host, so use that platform's own setting.
A non-Windows upstream that only answers client mode (Step 6). Microsoft's KB 875424 command:
# Change, on DC01. Client mode (0x8) for an appliance that ignores symmetric active requests
w32tm /config /manualpeerlist:"ntp1.corp.contoso.com,0x8" /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync
Microsoft's mode flags: 0x01 SpecialInterval, 0x02 UseAsFallbackOnly, 0x04 SymmetricActive, 0x08 Client.
A GPO that sends the wrong machines to the internet (Step 7): change or re-filter the GPO, run gpupdate /force on one test machine, then re-read w32tm /query /configuration for (Policy) values before you widen it.
A DC that jumped by days (Step 8): don't widen the phase correction limits to "let it through." Microsoft's point is that the limits keep the bad DC apart "until the administrator can investigate and take corrective action." Find the cause (BIOS clock, host provider, a restore, an upstream peer), fix that, then correct the time on that DC while you watch replication and secure channels. If accounts or trusts were touched, read the trust relationship post before you reset anything.
Need more detail from W32Time itself: Microsoft's debug log is a low-risk write. Turn it off when you're done:
# Low-risk write. W32Time private log (Microsoft's example path and size), then turn it off afterwards
w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
w32tm /debug /disable
Read-only confirm afterwards:
# Read-only. Source, last sync, and offset on the machine you fixed and on its DC
w32tm /query /source
w32tm /query /status
w32tm /stripchart /computer:dc01.corp.contoso.com /samples:3 /dataonly
w32tm /monitor /domain:corp.contoso.com
Watch one full cycle. The source is a DC (or the PDC's chosen peer), Last Successful Sync Time is recent, /monitor shows small offsets at every hop, events 35 and 37 (or 138 after an outage) appear, and the Kerberos errors stop.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Member on a manual peer, no GPO |
/syncfromflags:domhier, restart, /resync /rediscover
|
Re-registering W32Time |
GPO sets Type NTP for members |
Fix the GPO scope | Fighting it on each PC |
| Forest root PDC on NT5DS (event 12) | Three peers with /syncfromflags:manual /reliable:yes
|
Every DC on internet time |
| PDC role moved | Swap the old and new PDC settings; re-filter the GPO | Two reliable DCs |
| DC guest on host time | Disable host time sync for that DC (VM off) | Disabling it on every VM by reflex |
| Appliance ignores symmetric active |
0x8 on that peer |
Disabling the firewall to "test" |
| UDP 123 blocked | A rule for UDP 123 with source port 123 | Assuming /stripchart proves the service path |
| DC jumped more than 48 hours | Find the cause; correct deliberately |
0xFFFFFFFF phase correction on DCs |
| Kerberos skew errors | Fix the source and resync | Raising the Kerberos tolerance |
FAQ
Why is Windows time not syncing with the domain controller?
Run w32tm /query /source and /configuration on the machine first. If the source isn't a DC, the machine left the hierarchy (a manual peer, a GPO, or Type NTP). If the source is a DC, that DC or something above it is wrong: walk the hops with w32tm /stripchart and w32tm /monitor. If there's no usable source at all, check DNS, DC discovery, and UDP 123 (events 129 and 134).
What does w32tm /resync do?
Microsoft: it "Tells a computer that it should resynchronize its clock as soon as possible, throwing out all accumulated error statistics." /rediscover also "rediscovers network sources" first, and /nowait returns immediately. It doesn't change where the machine takes time from, so fix the source before you resync.
What is the difference between NT5DS and NTP in w32tm?
NT5DS follows the domain hierarchy, and Microsoft makes it the default for domain members. NTP uses the servers in NtpServer, and Microsoft makes it the default for stand-alone machines. In a domain, only the forest root PDC emulator should normally be NTP, pointed at an external or hardware source.
Why does w32tm /query /source say Local CMOS Clock or Free-running System Clock?
The machine isn't taking time from a peer right now (our reading). On a member, check the Step 6 events and reachability. On the forest root PDC emulator, it usually means the external peers aren't answering, or event 12 says it was never pointed at one. Microsoft shows Local CMOS Clock as expected only on a DC with its own GPS hardware.
Should a Hyper-V domain controller use Time Synchronization integration services?
Microsoft's DC guidance says to disable it for DC guests so they follow the domain hierarchy, with the VM turned off first. Microsoft's 2016 page adds a Windows Server 2012 R2 exception for the PDC emulator. Pick one design, write it down, and check where the host itself gets its time.
Related posts
- Trust Relationship Between This Workstation and the Primary Domain Failed (what a clock jump or a restore does to a machine's secure channel)
- Entra Seamless SSO Not Working (Kerberos ticket triage when the clocks are already right)
- Group Policy Not Applying (when a Windows Time Service GPO wins, or never arrives)
Free checklist
Clock skew is a sign-in outage that looks like an access problem. So is a Conditional Access policy enforced before anyone checked who it blocks. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=windows-time-not-syncing
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: w32tm /query (/source, /status, /configuration, /peers), w32tm /stripchart, w32tm /monitor, Get-ADForest, Get-ADDomain, Get-ADDomainController -Discover, Get-VMIntegrationService, Get-ItemProperty on the W32Time and policy keys, Get-Service, Get-WinEvent on the System log, Resolve-DnsName, nltest /dsgetdc, dcdiag /test:Advertising, gpresult, and klist. reg export and w32tm /debug write local files. w32tm /config, restarting W32Time, w32tm /resync, disabling the Hyper-V time integration service, VMICTimeProvider changes, GPO changes, and gpupdate /force are deliberate changes. Change one layer at a time, test on one machine first, and check current Microsoft Learn for version-specific behavior.
