Regulations in many sectors require systems to be traceable to UTC. This means that a system's offset can be attested with respect to UTC. To enable regulatory compliance scenarios, Windows 10 (version 1703 or higher) and Windows Server 2016 (version 1709 or higher) provides new event logs to provide a picture from the perspective of the Operating System to form an understanding of the actions taken on the system clock. These event logs are generated continuously for Windows Time service and can be examined or archived for later analysis.
These new events enable the following questions to be answered:
Was the system clock altered
Was the clock frequency modified
Was the Windows Time service configuration modified
Availability
These improvements are included in Windows 10 version 1703 or higher, and Windows Server 2016 version 1709 or higher.
Configuration
No configuration is required to realize this feature. These event logs are enabled by default and can be found in the event viewer under the Applications and Services Log\Microsoft\Windows\Time-Service\Operational channel.
List of Event Logs
The following section outlines the events logged for use in traceability scenarios.
This event is logged when the Windows Time Service (W32Time) starts and logs information about the current time, current tick count, runtime configuration, time providers, and current clock rate.
Event description
Service Start
Details
Occurs at W32time Startup
Data logged
Current Time in UTC
Current Tick Count
W32Time Configuration
Time Provider Configuration
Clock Rate
Throttling mechanism
None. This event fires every time the service starts.
Example:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937.
Command:
This information can also be queried using the following commands
W32Time and Time Provider configuration
w32tm.exe /query /configuration
Clock Rate
w32tm.exe /query /status /verbose
This event is logged when the Windows Time Service (W32Time) is stopping and logs information about the current time and tick count.
Event description
Service Stop
Details
Occurs at W32time Shutdown
Data logged
Current Time in UTC
Current Tick Count
Throttling mechanism
None. This event fires every time the service stops.
Example text:W32time service is stopping at 2018-03-01T05:42:13.944Z (UTC), System Tick Count 6370250.
This event periodically logs its current list of time sources and its chosen time source. It also logs the current tick count. This event doesn't fire each time a time source changes. Other events listed later in this document provide this functionality.
Event description
NTP Client Provider Periodic Status
Details
List of time sources used by NTP Client
Data logged
Available time sources
The chosen reference time server at the time of logging
Current Tick Count
Throttling mechanism
Logged once every 8 hours.
Example text:
NTP Client provider periodic status:
Ntp Client is receiving time data from the following NTP Servers:
server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123)server2.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123); and the chosen reference time server is Server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123) (RefID:0x08d6648e63). System Tick Count 13187937
Command
This information can also be queried using the following commands
Identify Peersw32tm.exe /query /peers
Event description
Time service configuration and status
Details
W32time periodically logs its configuration and status. This is the equivalent of calling:
w32tm /query /configuration /verbose OR w32tm /query /status /verbose
Throttling mechanism
Logged once every 8 hours.
This event logs each instance when System Time is modified using the SetSystemTime API.
Event description
System Time is set
Throttling mechanism
None.
This event should happen rarely on systems with reasonable time synchronization, and we want to log it each time it occurs. We ignore TimeJumpAuditOffset setting while logging this event since that setting was meant to throttle events in the Windows System event log.
Event description
System clock frequency adjusted
Details
System clock frequency is constantly modified by W32time when the clock is in close synchronization. We want to capture "reasonably significant" adjustments made to the clock frequency without overrunning the event log.
Throttling mechanism
All clock adjustments below TimeAdjustmentAuditThreshold (min = 128 parts per million, default = 800 parts per million) aren't logged.
2 PPM change in clock frequency with current granularity yields 120 µsec/sec change in clock accuracy.
On a synchronized system, most of the adjustments are below this level. If you want finer tracking, this setting can be adjusted down or you can use PerfCounters, or you can do both.
Event description
Change in the Time service settings or list of loaded time providers.
Details
Re-reading W32time settings can cause certain critical settings to be modified in-memory, which can affect the overall accuracy of the time synchronization.
W32time logs each occurrence when rereading its settings, which gives the potential impact on time synchronization.
Throttling mechanism
None.
This event occurs only when an admin or GP update changes the time providers and then triggers W32time. We want to record each instance of change of settings.
Event description
Change in time sources used by NTP Client
Details
NTP Client records an event with the current state of the time servers/peers when a time server/peer changes state (Pending ->Sync, Sync -> unreachable, or other transitions)
Throttling mechanism
Max frequency – only once every 5 minutes to protect the log from transient issues and bad provider implementation.
Event description
Time service source or stratum number changes
Details
W32time Time Source and Stratum Number are important factors in time traceability and any changes to them must be logged. If W32time has no source of time and you haven't configured as a reliable time source, then it will stop advertising as a time server, and by-design respond to requests with some invalid parameters. This event is critical to track the state changes in an NTP topology.
Throttling mechanism
None.
Event description
Time resynchronization is requested
Details
This operation is triggered:
When network changes occur
System returns from connected standby/hibernation
When we didn't sync for a long time
Admin issues the resync command
This operation results in immediate loss of fine-grained time sync accuracy because it causes NTP client to clear its filters.
Throttling mechanism
Max frequency - once every 5 minutes.
It's possible that a bad network card (or a poor script) can trigger this operation repeatedly and result in logs getting overwhelmed. Hence the need to throttle this event.
Accurate time sync takes far more than 5 minutes to achieve, and throttling doesn't lose information about the original event that resulted in loss of time accuracy.