Bestimmungen in vielen Sektoren erfordern, dass Systeme bezogen auf UTC ablaufverfolgbar sind. Dies bedeutet, dass die Abweichung eines Systems in Bezug auf die UTC nachgewiesen werden kann. Zum Aktivieren regulatorischer Complianceszenarien bieten Windows 10 (Version 1703 oder höher) und Windows Server 2016 (Version 1709 oder höher) neue Ereignisprotokolle, um ein Bild aus der Perspektive des Betriebssystems bereitzustellen und so ein Verständnis der an der Systemuhr vorgenommenen Aktionen zu erstellen. Diese Ereignisprotokolle werden fortlaufend für den Windows-Zeitdienst generiert und können untersucht sowie zur späteren Analyse archiviert werden.
Diese neuen Ereignisse ermöglichen die Beantwortung der folgenden Fragen:
- Wurde die Systemuhr verändert?
- Wurde die Taktfrequenz geändert?
- Wurde die Konfiguration des Windows-Zeitdiensts geändert?
Availability
Diese Verbesserungen sind in Windows 10, Version 1703 oder höher, und Windows Server 2016, Version 1709 oder höher, enthalten.
Configuration
Zur Verwendung dieser Funktion ist keine Konfiguration erforderlich. Diese Ereignisprotokolle sind standardmäßig aktiviert und befinden sich in der Ereignisanzeige unter dem Kanal Anwendungs- und Dienstprotokolle\Microsoft\Windows\Time-Service\Operational.
Liste der Ereignisprotokolle
Im folgenden Abschnitt werden die Ereignisse beschrieben, die für die Verwendung in Ablaufverfolgungsszenarien protokolliert werden.
Dieses Ereignis wird protokolliert, wenn der Windows-Zeitdienst (W32Time) startet und Informationen zur aktuellen Zeit, zur aktuellen Taktanzahl, zur Laufzeitkonfiguration, zu Zeitanbietern und zur aktuellen Taktfrequenz protokolliert.
| Ereignisbeschreibung |
Dienststart |
| Details |
Tritt beim Start von W32Time auf. |
| Protokollierte Daten |
- Aktuelle Zeit in UTC
- Aktuelle Taktanzahl
- W32Time-Konfiguration
- Zeitanbieterkonfiguration
- Taktfrequenz
|
| Einschränkungsmechanismus |
None. Dieses Ereignis wird bei jedem Start des Diensts ausgelöst. |
Example:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937.
Command:
Diese Informationen können auch mithilfe der folgenden Befehle abgefragt werden.
W32Time- und Zeitanbieterkonfiguration
w32tm.exe /query /configuration
Taktfrequenz
w32tm.exe /query /status /verbose
Dieses Ereignis wird protokolliert, wenn der Windows-Zeitdienst (W32Time) beendet wird und Informationen zur aktuellen Zeit und Taktanzahl protokolliert.
| Ereignisbeschreibung |
Dienststopp |
| Details |
Tritt beim Herunterfahren von W32Time auf. |
| Protokollierte Daten |
- Aktuelle Zeit in UTC
- Aktuelle Taktanzahl
|
| Einschränkungsmechanismus |
None. Dieses Ereignis wird bei jedem Beenden des Diensts ausgelöst. |
Beispieltext:W32time service is stopping at 2018-03-01T05:42:13.944Z (UTC), System Tick Count 6370250.
Dieses Ereignis protokolliert regelmäßig die aktuelle Liste der Zeitquellen und die ausgewählte Zeitquelle. Außerdem wird die aktuelle Taktanzahl protokolliert. Dieses Ereignis wird nicht bei jeder Zeitquellenänderung ausgelöst. Andere Ereignisse, die später in diesem Dokument aufgeführt sind, bieten diese Funktionalität.
| Ereignisbeschreibung |
Regelmäßiger Status des NTP-Clientanbieters |
| Details |
Liste der vom NTP-Client verwendeten Zeitquellen |
| Protokollierte Daten |
- Verfügbare Zeitquellen
- Der ausgewählte Referenzzeitserver zum Zeitpunkt der Protokollierung
- Aktuelle Taktanzahl
|
| Einschränkungsmechanismus |
Wird alle 8 Stunden einmal protokolliert. |
Beispieltext: NTP-Clientanbieter regelmäßiger Status:
Der NTP-Client empfängt Zeitdaten von den folgenden NTP-Servern:
server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123)server2.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123); und der ausgewählte Referenzzeitserver ist Server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123) (RefID:0x08d6648e63). Aktuelle Taktanzahl 13.187.937
Befehl Diese Informationen können auch mit den folgenden Befehlen abgefragt werden.
Identifizieren von Peersw32tm.exe /query /peers
| Ereignisbeschreibung |
Konfiguration und Status des Zeitdiensts |
| Details |
W32Time protokolliert regelmäßig seine Konfiguration und seinen Status. Dies entspricht dem Aufrufen von:
w32tm /query /configuration /verbose
OR
w32tm /query /status /verbose |
| Einschränkungsmechanismus |
Wird alle 8 Stunden einmal protokolliert. |
Dieses Ereignis protokolliert jede Instanz, wenn die Systemzeit mithilfe der SetSystemTime-API geändert wird.
| Ereignisbeschreibung |
Systemzeit wird gestellt. |
| Einschränkungsmechanismus |
None. Dieses Ereignis sollte nur selten auf Systemen mit angemessener Zeitsynchronisierung erfolgen, und wir möchten dies bei jedem Auftreten protokollieren. Wir ignorieren die Einstellung „TimeJumpAuditOffset“ beim Protokollieren dieses Ereignisses, da diese Einstellung zum Drosseln von Ereignissen im Windows-Systemereignisprotokoll gedacht war. |
| Ereignisbeschreibung |
Systemtaktfrequenz angepasst |
| Details |
Die Systemtaktfrequenz wird von W32Time konstant geändert, wenn die Uhr eng synchronisiert wird. Wir möchten „hinreichend signifikante“ Anpassungen erfassen, die an der Taktfrequenz vorgenommen werden, ohne das Ereignisprotokoll zu überfüllen. |
| Einschränkungsmechanismus |
Alle Taktanpassungen unterhalb von „TimeAdjustmentAuditThreshold“ (Minimum = 128 ppm (parts per million, Teile pro Mio.), Standardwert = 800 ppm) werden nicht protokolliert. Eine 2 ppm-Änderung der Taktfrequenz mit der aktuellen Granularität ergibt eine 120 μs/Sek.-Änderung der Taktgenauigkeit. Bei einem synchronisierten System liegen die meisten Anpassungen unterhalb dieses Niveaus. Wenn du eine genauere Nachverfolgung wünschst, kann diese Einstellung nach unten angepasst werden, oder du kannst Leistungsindikatoren verwenden oder beides. |
| Ereignisbeschreibung |
Änderung der Zeitdiensteinstellungen oder Auflisten der geladenen Zeitanbieter. |
| Details |
Das erneute Lesen von W32Time-Einstellungen kann bewirken, dass bestimmte kritische Einstellungen im Arbeitsspeicher geändert werden, was sich wiederum auf die Gesamtgenauigkeit der Zeitsynchronisierung auswirken kann.
W32Time protokolliert jedes Vorkommen, wenn es seine Einstellungen erneut liest, woraus sich die potenziellen Auswirkungen auf die Zeitsynchronisierung ergeben. |
| Einschränkungsmechanismus |
None.
Dieses Ereignis tritt nur auf, wenn ein Administrator oder eine Gruppenrichtlinienaktualisierung die Zeitanbieter ändert und dann W32Time auslöst. Wir möchten jede Instanz einer Änderung von Einstellungen aufzeichnen. |
| Ereignisbeschreibung |
Änderung an vom NTP-Client verwendeten Zeitquellen |
| Details |
Der NTP-Client zeichnet ein Ereignis mit dem aktuellen Zustand der Zeitserver/Peers auf, wenn sich der Zustand eines Zeitservers/Peers ändert (Ausstehend – >Synchronisierung, Synchronisierung –> Nicht erreichbar oder andere Übergänge). |
| Einschränkungsmechanismus |
Maximale Häufigkeit: nur einmal alle 5 Minuten, um das Protokoll vor vorübergehenden Problemen und einer fehlerhaften Anbieterimplementierung zu schützen. |
| Ereignisbeschreibung |
Änderungen an der Zeitdienstquelle oder Stratumnummer |
| Details |
Zeitquelle und Stratum-Nummer von W32Time sind wichtige Faktoren der Zeitablaufverfolgbarkeit, und alle Änderungen daran müssen protokolliert werden. Wenn W32Time über keine Zeitquelle verfügt und Sie es nicht als zuverlässige Zeitquelle konfiguriert haben, beendet es die Ankündigung als Zeitserver und antwortet entwurfsbedingt auf Anforderungen mit einigen ungültigen Parametern. Dieses Ereignis ist kritisch, um die Zustandsänderungen in einer NTP-Topologie zu verfolgen. |
| Einschränkungsmechanismus |
None. |
| Ereignisbeschreibung |
Erneute Synchronisierung der Zeit wird angefordert |
| Details |
Dieser Vorgang wird in folgenden Fällen ausgelöst:- Netzwerkänderungen
- Rückkehr des Systems aus dem verbundenen Standbymodus/Ruhezustand
- Es wurde länger keine Synchronisierung vorgenommen.
- Administrator sendet den resync-Befehl.
Dieser Vorgang führt zu einem sofortigen Verlust der fein aufgelösten Zeitsynchronisierungsgenauigkeit, da der NTP-Client dadurch seine Filter löscht. |
| Einschränkungsmechanismus |
Max. Häufigkeit: einmal alle 5 Minuten.
Es ist möglich, dass eine fehlerhafte Netzwerkkarte (oder ein schlecht geschriebenes Skript) diesen Vorgang wiederholt auslöst und dies zum Überlaufen der Protokolle führt. Hieraus resultiert die Notwendigkeit zur Drosselung dieses Ereignisses.
Es dauert wesentlich länger als 5 Minuten, um die genaue Zeitsynchronisierung zu erzielen, und bei der Drosselung gehen keine Informationen zum ursprünglichen Ereignis verloren, das zum Verlust der Zeitgenauigkeit geführt hat. |