Measure the Windows guest’s offset against the intended domain references, then correlate any jump with Windows Time policy and VMware Tools lifecycle corrections. Turning off periodic host synchronisation does not prove that one-off corrections are disabled. A snapshot event is evidence to investigate, not proof that every snapshot reset the clock.
The reference guest is domain-joined Windows Server 2022. The VMware source explicitly lists ESXi 7.x and 8.x; do not extrapolate its UI or settings to another release without checking that release. This procedure is source-researched and untested. No clock, service or time policy was changed.
Separate clock time from displayed local time
Windows and applications can display the same instant in different local time zones. Microsoft explains that NTP uses Coordinated Universal Time, or UTC, independently of time-zone settings S1. A different displayed hour therefore does not automatically mean the underlying clocks disagree.
Record the guest’s time zone, the log’s stated time basis and the collector’s conversion behaviour. Some application logs record local time while other infrastructure logs record UTC. Preserve original timestamps alongside any normalised incident timeline.
Look for evidence of actual offset against the approved time reference, not just a disagreement between two screenshots. Record when and how the comparison was made. A delayed log delivery can also make event order differ from event occurrence.
For an application timing investigation, distinguish wall-clock timestamps from elapsed-duration measurements. A corrected wall clock can complicate comparisons made by subtracting timestamps across systems. Keep the measurement method and known clock offsets with the result.
Understand the intended Windows time hierarchy
Domain members normally participate in the Windows domain time hierarchy. Microsoft’s Windows Time explanation describes the hierarchy and the role of domain controllers, including the forest-root PDC emulator’s position in the authoritative chain.
Begin with that intended design. A domain-joined application server should not be assigned an arbitrary external peer merely because an internet time service responds. Determine whether the machine is following domain policy, an approved explicit configuration or an unintended override.
Record the machine’s role. A member server and a domain controller do not have the same responsibility in the hierarchy. Changes to authoritative domain time require the directory owner’s review and are outside this member-server diagnostic.
Also record the dependency on network and authentication services. A configured source that is unreachable or rejected is not the same as a healthy synchronisation relationship. The status and recent events must establish what the machine actually used.
Capture the guest’s current evidence
Microsoft’s time-service command reference documents the following query forms. They read configuration and state rather than request a clock change. They have not been run here; the operator must confirm installed help and approved access for the target before use.
w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers
Save the output with the machine identity and observation time in a protected diagnostic record. /source reports the source, /status reports service state, and /configuration includes runtime settings and where those settings originate. /peers reports peer information S2.
Do not reduce the result to a single server name. Review whether the source is expected, whether synchronisation has succeeded recently and whether the effective settings came from policy or local configuration. A stale successful event does not establish that the current path is healthy.
Inspect relevant Windows Time events over the incident interval. Preserve failures and source changes. Compare them with application errors, network changes and VM lifecycle events rather than assuming the first time-service warning caused every nearby symptom.
No output is fabricated in this article. If the query is denied, unsupported or unavailable, record the missing evidence and arrange the appropriate read access. Do not register, reset or restart the time service merely because a diagnostic query failed.
Check VMware time corrections separately
Broadcom distinguishes periodic VMware Tools time synchronisation from one-off corrections associated with VM lifecycle events S3. These are separate behaviours. A checkbox controlling periodic synchronisation is not evidence that every host-to-guest correction is disabled.
The cited article recommends native guest time services such as Windows Time for normal synchronisation and describes one-off corrections as separately enabled behaviour. It also documents differences in the controls before and from vSphere 7.0 Update 1. Match the actual host, guest and Tools configuration to that scope.
Record the host’s time state and the VM’s configured synchronisation settings without changing them. If the guest’s clock changes after a Tools restart, resume or migration-related event, compare the event with the host and guest observations. Timing correlation is a reason to investigate the correction path, not proof of its exact cause.
Do not disable every VMware time option as a universal remedy. The platform and Windows owners must agree how lifecycle corrections and native synchronisation work together for this workload. A virtual domain controller requires the separate supported domain-controller design.
Likewise, do not enable periodic host synchronisation simply because the guest currently has an offset. First establish whether the host is itself accurate and whether that change conflicts with the intended domain hierarchy.
Measure a bounded offset and check lifecycle evidence
Untested Windows Server 2022 diagnostics, run by the authorised Windows operator against reachable, approved domain references S2. Replace these names with the authenticating domain controller and, separately, the forest-root PDC emulator identified by the domain owner:
w32tm /stripchart /computer:dc01.example.test /samples:5 /dataonly
w32tm /stripchart /computer:pdc-root.example.test /samples:5 /dataonly
Each command stops after five samples and does not set the clock. The timestamped signed value reports the sampled offset in seconds between this computer and that target. Record magnitude, variation, target and observation time; do not turn its sign into a manual correction. A timeout is a failed measurement, not zero offset. Stripchart's ephemeral UDP source port also differs from the built-in NTP client's path S2.
Broadcom KB 326306, scoped to ESXi 7.x/8.x, lists these possible host synchronisation circumstances S3: resuming a suspended VM, vMotion migration, taking a snapshot, restoring to a snapshot, shrinking the virtual disk, and restarting VMware Tools, including guest reboot. It describes one-off synchronisation as on by default and periodic synchronisation as off by default. Inspect effective controls and correlate timestamps; this list does not establish that a correction occurred on every event.
The same source says Tools does not set time backwards except once when periodic synchronisation is turned on S3. That statement concerns Tools, not every Windows/application time adjustment. Do not infer that disabling one checkbox prevents all backward corrections.
Windows Time's MaxPosPhaseCorrection and MaxNegPhaseCorrection bound corrections. If the required change exceeds the configured limit, the service logs an event instead S2. Effective policy and machine role matter; inspect the configuration rather than copying a universal default. In Windows Event Viewer, inspect Applications and Services Logs → Microsoft → Windows → Time-Service → Operational for the relevant interval and preserve the message and event ID. Microsoft documents this traceability channel for Windows Server 2022 R1.
Microsoft explains that synchronising a member to a manually selected peer instead of its authenticating DC can leave them out of sync and cause Kerberos authentication failures S1. This is why both the domain reference and the authentication symptom belong in the same timeline.
Find the first incorrect boundary
If the guest follows an unexpected peer, compare effective policy with the approved design. Identify the owner of the setting before editing it locally. A policy-managed value can return after a temporary local change, making the apparent fix short-lived.
If the expected source is configured but synchronisation fails, investigate the documented time-service network path and the relevant authentication or service events. A successful ping is not proof that the time protocol exchange succeeded.
If several guests on one host show similar changes around the same event, include that host’s time evidence. If only one guest is affected, inspect its policy and application-specific behaviour before changing a shared host setting.
If logs disagree while the clocks appear correct, inspect time-zone conversion, application logging format and collector delay. Do not alter an accurate clock to make one application’s incorrectly labelled timestamps look consistent.
Treat suspend, resume and restore history as part of the evidence. A VM can return from an earlier saved state with different time circumstances from a continuously running machine. Use the build-specific guidance rather than a general instruction to force the clock forward or backward.
Plan correction as an operational change
Once the incorrect boundary is established, record the intended source or policy and the exact setting to change. Review effects on authentication, scheduled tasks, application ordering and monitoring with the responsible owners.
Microsoft documents a resynchronisation operation separately from query operations S2. It changes time-service behaviour and discards accumulated error statistics. It is not part of the read-only collection above, and this article does not provide an automatic resynchronisation or service-reset script.
Avoid manual backward or forward time jumps on a live application server as a diagnostic experiment. The application’s reaction and any scheduling consequences need a reviewed procedure. Retain the original state and define how to recover if authentication or application processing is affected.
Where the correction is policy-based, test it on an approved representative machine and verify the policy source afterwards. A setting saved locally is not sufficient if the next policy refresh restores an unintended value.
Verify stability and the original symptom
After the approved correction, repeat the read-only observations through a representative operating interval. Confirm the selected source, recent synchronisation evidence and consistency with the intended hierarchy. Use normal monitoring rather than repeated manual polling as the long-term solution.
Correlate a controlled application event with its guest and infrastructure records. Record the expected time basis and any measured offset. If authentication was the symptom, test the intended remote authentication path separately; a correct clock does not establish correct SPNs or database permissions.
Include a relevant planned lifecycle event in an isolated rehearsal where the incident specifically involved one. Do not migrate, restart or suspend a production VM solely to test this article. State which lifecycle cases remain untested.
Keep the result bounded. A short observation establishes behaviour during that interval, not indefinite accuracy or compliance with a specialised precision requirement. Such requirements need their own validated time architecture and measurement method.
Limitations
The reference is domain-joined Windows Server 2022 and the Broadcom article’s ESXi 7.x/8.x scope. Network probes are samples, not proof of long-term stability. Domain-controller recovery and time-policy changes need separate specialist procedures; no clock adjustment is supplied.
Acceptance checklist
- UTC/time-zone display distinguished from measured offset.
- Guest, authenticating DC and forest-root reference observations correlated.
- Effective Windows limits and Tools controls recorded with lifecycle events.
- Owned automated measurements and the original authentication symptom checked after repair.
Learning notes
- Time-zone display and actual clock offset are different observations.
- Periodic Tools synchronisation and one-off lifecycle corrections are separate controls.
- A configured time source must be checked against actual synchronisation evidence.
Related reading: SQL Kerberos After Migration: Check SPNs and NTLM Use; Scheduled Jobs After Migration: Prevent Duplicate Work; VMware Tools Not Running or Out of Date: What It Breaks; Domain Controllers on VMware: Snapshots and Restores.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- How the Windows Time Service Works | Microsoft Learn
- Windows Time Service Tools and Settings | Microsoft Learn
- Disabling Time Synchronization for virtual machines
Additional revision sources: