A log is a claim about what happened at a time. When the machines disagree about the time, the claims cannot be lined up, and your beautiful central console becomes a shelf of unconnected anecdotes.
Ask an investigator what they trust least and the answer is timestamps from machines nobody disciplined. A firewall five minutes fast and a server seven minutes slow will happily produce a story where the file was accessed before the user logged in. Time sync is not housekeeping; it is the foundation every report in this series stands on. The good news: in a Windows domain the machinery already exists. It only needs checking, and occasionally, rescuing.
Correlation rules chain events by time, so skew scrambles exactly the feature you bought the tool for. Searches sorted by time interleave wrongly. Worst of all, evidence loses credibility: the first thing anyone challenges in a dispute is a timeline, and a five-minute hole is all it takes.
Kerberos adds a practical sting: Windows authentication itself tolerates only a small clock difference, five minutes by default, so drifting machines eventually start failing logons for a reason users describe as random.
In a domain, time has a hierarchy. Members sync from their domain controller, domain controllers sync from the one holding the PDC Emulator role, and that machine should sync from a reliable external NTP source. Workgroup machines and network devices point at an NTP server directly.
Most drift problems are a break in that chain: a PDC emulator still pointing at a dead server from 2019, a virtual DC whose host keeps dragging its clock, or a firewall set to manual time in a setup menu nobody revisited.
On any Windows machine, ask it where it believes time comes from and how far off it thinks it is:
w32tm /query /status
w32tm /stripchart /computer:dc01 /samples:3
Replace dc01 with your domain controller's name. The stripchart prints the offset directly; anything beyond a second or two on a LAN deserves a fix, and anything near a minute means your logs have been fiction for a while. Run the same check on the EventLog Analyzer server itself first, because its clock is the one your searches are framed around.
w32tm, and Microsoft documents the exact configuration for the forest root.Force a resync with w32tm /resync on a machine that is merely drifted; a machine configured to the wrong source needs the configuration fixed, not repeated resyncs.
Finish where you started: cause the same event on two sources at once, a failed logon through the firewall's VPN against a DC account, and watch both records land in EventLog Analyzer within the same minute, in the right order. That tiny experiment is the certificate your whole retention and alerting setup quietly depends on.
Then add clock checks to the monthly routine. Time drifts back the way dust returns; only the checking schedule decides whether you notice.
Give the time chain one check before you install, and the video's install steps land on ground that will hold every report you build later.
▶️ Watch Full VideoFor human reading, a few seconds is nothing. For correlation and Kerberos, minutes are trouble; Windows authentication defaults to about five minutes of tolerance. Aim for under a second on a LAN, which healthy NTP gives you for free, and treat anything over a minute on any source as a defect.
In a domain, the PDC Emulator syncing to a reliable external NTP source, with everything else following the domain hierarchy. Network devices should use the same external source or your DCs, so every log in the console shares one timeline.
Yes. Hypervisors also offer time sync to guests, and two masters fighting is a classic cause of a DC clock that will not stay fixed. Pick one authority, usually NTP for a DC, disable the competing host sync for that guest, and verify with stripchart over a few days.