KomuraSoft LLC
Kontakt
Menü

Windows-Zeitsynchronisation (w32time) und Unternehmenssysteme — „Die Protokoll-Zeitstempel stimmen nicht überein“ von den Grundlagen her lösen

· · w32time, NTP, Zeitsynchronisation, Windows, Protokollierung, Fehlerbehebung, Geräteintegration, Active Directory

„Die Anlage ist unerwartet stehen geblieben. Wir haben das Protokoll des Geräts neben das Anwendungsprotokoll auf dem PC gelegt, und die Zeitstempel lagen 40 Sekunden auseinander — wir können also nicht sagen, ob der Gerätefehler oder der Kommunikationsabbruch der Anwendung zuerst aufgetreten ist.“ Diese Szene ist uns bei Störungsanalysen an geräteintegrierten Systemen immer wieder begegnet. Netzwerkkameras, SPS, Prüfgeräte und Windows-PCs: Jedes von ihnen versieht seine Protokolle mit der eigenen Uhr, und wie sich herausstellt, hatte nie jemand sichergestellt, dass diese Uhren übereinstimmen.

Zeitabweichungen bleiben im normalen Betrieb fast vollständig unbemerkt. Sie schlagen erst bei einer Störungsanalyse zu — genau dann, wenn als Nachweis geklärt werden muss, „was zuerst passiert ist“. Und sobald man zu graben beginnt, häufen sich die Befunde: „die Arbeitsgruppen-PCs haben sich nur einmal wöchentlich synchronisiert“, „die virtuelle Maschine wurde sowohl vom Host als auch von NTP gezogen“, „die Uhr des Geräts wurde überhaupt nie gestellt“.

Dieser Artikel richtet sich an Entwickler und IT-Mitarbeiter, die schon einmal Mühe hatten, Protokolle zwischen Geräten und PCs oder zwischen Servern und Clients abzugleichen. Er behandelt die Funktionsweise des Windows-Zeitdienstes (w32time), die praktische Seite der Diagnose mit den w32tm-Befehlen, realistische Erwartungen an die Genauigkeit sowie die Frage, wie man das Geschäftssystem selbst unter der Annahme entwirft, dass „die Zeit abweicht und auch zurückspringen kann“ — alles gestützt auf die Primärdokumentation von Microsoft.

1. Das Wichtigste zuerst

  • Die Windows-Zeit wird vom Windows-Zeitdienst (w32time) verwaltet. Er ist keine strikte NTP-Implementierung, sondern ein NTP-Client/-Server, der die Algorithmen der NTP-Spezifikation zur Disziplinierung der Uhr nutzt und über UDP-Port 123 kommuniziert.1
  • Eine Domänenumgebung besitzt eine feste Zeithierarchie. Mitglieder synchronisieren sich mit einem DC, DCs synchronisieren sich mit einem DC der übergeordneten Domäne, und an der Spitze steht der PDC-Emulator der Gesamtstruktur-Stammdomäne. Ist die Spitze nicht mit einer genauen externen Zeitquelle synchronisiert, ist die gesamte Domäne gemeinsam falsch.1
  • Arbeitsgruppenrechner (ohne Domäne) synchronisieren sich standardmäßig mit niedriger Frequenz mit time.windows.com. Der Registrierungs-Standardwert für SpecialPollInterval beträgt in einer eigenständigen Konfiguration 604.800 Sekunden (eine Woche). Abweichungen von einigen Dutzend Sekunden entstehen dabei „genau wie vorgesehen“.23
  • Für die Diagnose genügt der w32tm-Befehlssatz. w32tm /query /status für Synchronisierungsstatus und Quelle, /stripchart zur Messung der tatsächlichen Abweichung gegenüber einer Gegenstelle, /config /manualpeerlist zur Angabe des Synchronisierungsziels und /resync, um eine sofortige Neusynchronisierung zu erzwingen.2
  • w32time korrigiert kleine Abweichungen allmählich über die Taktrate (Slewing) und große Abweichungen durch direktes Stellen der Uhr (Stepping). Mit anderen Worten: Die Systemuhr kann sowohl vor- als auch zurückspringen. Ebenso wichtig ist, dass, sobald die Abweichung die Grenzwerte (MaxPos/MaxNegPhaseCorrection) überschreitet, überhaupt keine Korrektur mehr vorgenommen wird und das Ereignis lediglich ins Ereignisprotokoll geschrieben wird.12
  • Das Genauigkeitsziel der Standardkonfiguration lautete ursprünglich „ausreichend, um die Fünf-Minuten-Vorgabe von Kerberos zu erfüllen“. Ab Windows Server 2016 / Windows 10 1607 wurde dies erheblich verbessert, sodass eine Genauigkeit von 1 Sekunde / 50 ms / 1 ms unterstützt wird, sofern Bedingungen bezüglich einer genauen Stratum-1-Zeitquelle, der Netzwerklatenz, der Hop-Anzahl und Ähnlichem erfüllt sind.4
  • Ein Hyper-V-Gast verfügt über zwei Zeitanbieter: den Host und NTP. Ab Windows Server 2016 wurde der Gast so verbessert, dass er jeweils den besseren auswählt; bei domänengebundenen Gästen mit 2012 R2 oder älter wird jedoch empfohlen, den Hyper-V-Zeitsynchronisierungsanbieter zu deaktivieren.3
  • Entwerfen Sie auf Anwendungsseite unter der Annahme, dass die Zeit abweicht und auch zurückspringen kann. Zeichnen Sie Protokollzeiten in UTC auf und messen Sie verstrichene Zeit mit Stopwatch, das monoton und unabhängig von der Systemuhr zunimmt. Diese Arbeitsteilung ist die Grundlage.56

2. Wie w32time funktioniert — Domäne und Arbeitsgruppe verhalten sich vollkommen unterschiedlich

Der Windows-Zeitdienst (W32Time) ist die Standardkomponente zur Zeitsynchronisierung unter Windows. Er bezieht Zeitproben von Netzwerk-Zeitquellen über NTP (sowie die innerhalb einer Domäne verwendete sichere MS-SNTP-Variante), wählt mithilfe der NTP-Algorithmen für Taktfilterung und Taktauswahl die beste Probe aus und passt die lokale Uhr an.1

Wichtig ist zu verstehen, dass sich die Art, wie das Synchronisierungsziel bestimmt wird, je nach Konfiguration grundlegend unterscheidet.

In einer Domänenumgebung (Type=NT5DS) besitzt die AD-DS-Gesamtstruktur eine vorgegebene Zeithierarchie. Mitglieds-PCs und -Server synchronisieren sich mit einem DC ihrer eigenen Domäne, DCs synchronisieren sich mit einem DC der übergeordneten Domäne, und an der Spitze der Hierarchie steht der PDC-Emulator der Gesamtstruktur-Stammdomäne (oder ein als zuverlässige Zeitquelle konfigurierter DC). NTP-Pakete werden mit einem Kerberos-Sitzungsschlüssel signiert, und nur authentifizierte Zeit wird akzeptiert.1 Dadurch stimmen PCs innerhalb einer Domäne in der Regel recht gut überein. Das Problem liegt an der Spitze: Ist der PDC-Emulator nicht mit einer genauen externen Zeitquelle (einer GPS-Uhr oder einem vertrauenswürdigen NTP-Server) synchronisiert, sind alle gemeinsam falsch. Diese Abweichung wird sichtbar, sobald Sie Ihre Protokolle mit einem System außerhalb des Unternehmens oder einem in der Cloud gehaltenen Datensatz abgleichen.

In einer Arbeitsgruppenumgebung (Type=NTP) lautet das Standard-Synchronisierungsziel time.windows.com,0x1. Das Flag 0x1 (SpecialInterval) bedeutet, dass das Abfrageintervall aus dem Registrierungswert SpecialPollInterval übernommen wird, dessen Standardwert in einer eigenständigen Konfiguration 604.800 Sekunden = eine Woche beträgt.2 Selbst ein Windows-10-Client fragt nur etwa einmal täglich ab, und der Standardwert der Windows-Server-2012-R2-Generation lag bei einmal wöchentlich.3 Die interne Uhr eines PCs (ein Quarzoszillator) weicht abhängig von Temperatur und anderen Umgebungsfaktoren üblicherweise um Sekunden pro Tag ab, sodass bei wöchentlicher Synchronisierung Abweichungen von einigen Dutzend Sekunden völlig normal sind. Das ist meist die ganze Geschichte hinter den eingangs genannten „40 Sekunden Differenz“.

Praktisch ebenso wichtig ist das Verhalten der Taktdisziplinierung. Solange die Abweichung klein ist, beschleunigt oder verlangsamt w32time die Geschwindigkeit, mit der die Uhr voranschreitet, und gleicht sie allmählich an (Slewing); überschreitet die Abweichung MaxAllowedPhaseOffset, wird die Uhr direkt gestellt (Stepping).12 Überschreitet die Abweichung außerdem MaxPosPhaseCorrection/MaxNegPhaseCorrection (Standardwert eigenständig 54.000 Sekunden = 15 Stunden), wird lediglich ein Ereignis protokolliert, ohne überhaupt zu korrigieren.2 Wenn „es sollte doch synchronisieren, wird aber nie richtig“, haben Sie manchmal genau diese Grenze erreicht. Und Stepping-Korrekturen gelten auch in negativer Richtung — das heißt, die Windows-Systemuhr kann zurückspringen —, was in die später folgende Diskussion zum Anwendungsdesign überleitet.

3. Arbeiten mit den w32tm-Befehlen — Status prüfen, Abweichung messen, Quelle ändern

Für zeitbezogene Untersuchungen benötigen Sie im Wesentlichen fünf Befehle. Alle werden aus einer erhöhten Eingabeaufforderung ausgeführt.2

Prüfen Sie zunächst den aktuellen Status.

w32tm /query /status

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 7.7756348s
ReferenceId: 0xC0A80A14 (source IP:  192.168.10.20)
Last Successful Sync Time: 7/22/2026 8:14:02 AM
Source: dc01.example.local
Poll Interval: 10 (1024s)

Drei Dinge lohnen einen Blick: ob „Source“ die beabsichtigte Gegenstelle ist (Local CMOS Clock oder Free-running System Clock bedeutet faktisch unsynchronisiert); ob „Last Successful Sync Time“ aktuell ist (liegt sie Tage zurück, funktioniert die Synchronisierung nicht); und ob der „Stratum“-Wert plausibel ist (wie viele Hops von einer genauen Zeitquelle entfernt — w32time akzeptiert nur Stratum 15 oder niedriger).7 Wenn Sie nur die Quelle wissen möchten, verwenden Sie w32tm /query /source; für den Status mehrerer Gegenstellen w32tm /query /peers; und für die konfigurierten Werte samt ihrer Herkunft (Richtlinie oder lokal) w32tm /query /configuration.

Als Nächstes folgt das Messen der tatsächlichen Abweichung gegenüber einer Gegenstelle. Damit setzen Sie bei einer Störungsanalyse eine Zahl auf die Frage „wie weit liegen Server und dieser PC gerade auseinander“.

w32tm /stripchart /computer:192.168.10.20 /samples:5 /dataonly

Tracking 192.168.10.20 [192.168.10.20:123].
The current time is 7/24/2026 9:41:03 AM.
09:41:03, +28.1246875s
09:41:05, +28.1250120s
09:41:07, +28.1248533s
09:41:09, +28.1251008s
09:41:11, +28.1249517s

Aus diesem Beispiel lässt sich sofort ablesen, dass „dieser PC der Gegenstelle um rund 28 Sekunden hinterherhinkt“. Da /stripchart lediglich zur Anzeige misst und die lokale Uhr nicht verändert, können Sie es auch auf einem produktiven Geräte-PC gefahrlos ausführen. Es gegen alle beteiligten Rechner auszuführen, bevor Sie mit dem Protokollabgleich beginnen, und zuerst eine Abweichungstabelle aufzubauen, ist bei einer Störungsanalyse bei uns der allererste Schritt.

Um die Synchronisierungsquelle ausdrücklich anzugeben, verwenden Sie /config. Der Standardweg, einen Rechner auf einen internen NTP-Server (oder einen DC) auszurichten, sieht so aus.

w32tm /config /manualpeerlist:"ntp1.example.local,0x8 ntp2.example.local,0x8" /syncfromflags:manual /update
w32tm /resync

0x8 ist das Flag für die Synchronisierung im Client-Modus; kombiniert man es mit 0x1 (SpecialInterval) — also ,0x9 — wird im durch SpecialPollInterval vorgegebenen Intervall abgefragt. Da 0x1 allein das Client-Modus-Flag entfernt, sollten Sie entweder ,0x8 oder ,0x9 angeben. Wenn Sie nur zwei Server bereitstellen können, empfiehlt es sich, einem davon 0x2 (UseAsFallbackOnly) hinzuzufügen, um die Priorität ausdrücklich festzulegen (Microsoft empfiehlt ohnehin drei oder mehr Server).2 Um die manuelle Angabe von Gegenstellen zu beenden und zur Domänenhierarchie zurückzukehren, führen Sie w32tm /config /syncfromflags:domhier /update aus und starten den Dienst neu. w32tm /resync verwirft angesammelte Fehlerstatistiken und erzwingt eine sofortige Neusynchronisierung; verwenden Sie es, um zu bestätigen, dass eine Konfigurationsänderung wirksam geworden ist.2

Beachten Sie, dass eine mit /manualpeerlist angegebene externe NTP-Quelle etwas anderes ist als authentifizierte Domänenzeit und nicht authentifiziert wird; sie sollte daher grundsätzlich nicht auf Domänenmitgliedern verwendet werden — sie ist für die Spitze der Hierarchie (den PDC-Emulator) und für Nicht-Domänenrechner gedacht.1

4. Zur Genauigkeit — Wie nah kommt die Standardeinstellung, und was 1 ms voraussetzt

„Wie genau ist die NTP-Synchronisierung von Windows letztlich?“ Die Antwort hängt von der Ära ab.

Bei Windows Server 2012 R2 / Windows 8.1 und älter bestand das Entwurfsziel von w32time darin, eine für die Anforderungen der Kerberos-Authentifizierung (standardmäßig fünf Minuten) ausreichende Genauigkeit sowie „ungefähr genaue Zeit“ innerhalb einer einzelnen Gesamtstruktur bereitzustellen; strengere Genauigkeitsanforderungen liegen ausdrücklich außerhalb der Entwurfsspezifikation und werden nicht unterstützt.4 Mit anderen Worten: Hier gilt „auf etwa eine Sekunde genau“ bereits als bestimmungsgemäßes Verhalten.

Ab Windows Server 2016 / Windows 10 1607 wurden die Algorithmen verbessert und die Standard-Aktualisierungsfrequenz der Uhr deutlich erhöht (Server passten die Uhr beispielsweise nicht mehr nur einmal pro Stunde, sondern einmal pro Sekunde an).3 Dadurch sind Genauigkeiten von 1 Sekunde, 50 ms und 1 ms nun als Support-Grenzen definiert, sofern die Bedingungen erfüllt sind. Die wichtigsten Bedingungen für 1 ms lauten wie folgt — und umgekehrt dürfen Sie in einer Umgebung, die sie nicht erfüllt, keine 1 ms erwarten.4

  • Eine NTP-Hierarchie, an deren Spitze eine genaue, stabile Stratum-1-Zeitquelle steht (etwa eine GPS-Uhr), wobei jeder Windows-Rechner auf dem Pfad für hohe Genauigkeit konfiguriert ist
  • Netzwerklatenz zur Zeitquelle unter 0,1 ms sowie innerhalb von Stratum 5 und 4 Hops zur Zeitquelle
  • CPU-Auslastung auf jeder Ebene der Hierarchie (Tagesdurchschnitt) bei höchstens 80 % (einschließlich des Hosts in einer virtualisierten Umgebung)

Es wird zudem festgehalten, dass bei einer entfernten Internet-Zeitquelle wie time.windows.com keine 1-ms-Genauigkeit zu erwarten ist, bedingt durch Pfadasymmetrie und Stauungen.7 Als praktische Faustregel ist es am sichersten, in drei Stufen zu denken: „Arbeitsgruppen-Standard = Abweichungen von Sekunden bis einigen Dutzend Sekunden“, „korrekt konfigurierte interne NTP-Synchronisierung = einige Dutzend Millisekunden bis unter einer Sekunde“ und „eigens dafür ausgelegte Zeitquelle und Konstruktion = Millisekundenklasse“. Wenn Ihre Geräteintegration eine Reihenfolge auf Millisekundenebene benötigt, sollten Sie sich überhaupt nicht auf Zeitsynchronisierung verlassen — stützen Sie sich stattdessen, wie unten beschrieben, auf ein Design, das mit der Uhr eines einzelnen Rechners misst.

5. Zeit auf virtuellen Maschinen — Die doppelte Beziehung zwischen dem Hyper-V-Zeitsynchronisierungsdienst und NTP

Die Zeit auf einer virtuellen Maschine gerät leichter durcheinander als auf physischer Hardware. Der Grund ist einfach: Es gibt zwei Quellen, die ihr die Zeit anbieten. Windows in einem Hyper-V-Gast verfügt sowohl über den Hyper-V-Zeitsynchronisierungsdienst (den VMICTimeSync-Anbieter), der die Zeit vom Host bezieht, als auch über den gewöhnlichen NTP-Client — und Windows wählt anhand von Stratum, Root Delay, Root Dispersion und Abweichung, in dieser Reihenfolge, „den besseren“ aus.7

Windows Server 2016 hat diesen Mechanismus erheblich verbessert. Die Anfangszeit beim Start und bei der Wiederherstellung der VM wurde genau, um Interrupt-Latenz korrigierte Proben werden inzwischen an w32time übergeben, und eine Genauigkeit von rund 10 µs gegenüber dem Host lässt sich aufrechterhalten. Auch der Stratum-Wert, den der Host dem Gast meldet, wurde zu einem die Realität widerspiegelnden Wert („Host-Stratum + 1“), und domänengebundene Gäste ab 2016 wählen inzwischen die genaueste Uhr, statt sich dem Host unterzuordnen.3

Andererseits kann beim Betrieb eines Gasts mit Windows Server 2012 R2 oder älter in einer Domäne der Hyper-V-Zeitsynchronisierungsanbieter die Domänen-Zeitsynchronisierung stören, weshalb Microsoft empfiehlt, den Anbieter zu deaktivieren.3

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time

Auch Azure-VMs sind abgedeckt, wobei die Kernaussage lautet: „Bei domänengebundenen VMs (besonders virtualisierten DCs) TimeSync deaktivieren und sich ausschließlich auf die Domänenhierarchie verlassen; bei eigenständigen Nicht-Domänen-VMs die Hostsynchronisierung als Standard belassen“.3 Der Gedanke gilt ebenso für Hypervisoren anderer Anbieter (VMware und andere), bei denen es für domänengebundene Gäste empfohlen wird, die Zeitsynchronisierungsfunktion des Hosts zu deaktivieren.3 Zeigt sich das Symptom „NTP und Hostsynchronisierung ziehen abwechselnd an der Uhr, sodass Protokollzeiten hin- und herwandern“, liegt der Verdacht auf dieser doppelten Beziehung nahe. Ein weiterer betrieblicher Hinweis: Nach dem Wiederherstellen einer VM aus einem gespeicherten Zustand oder unmittelbar nach einer Live-Migration beginnt die Korrektur aus einem stark abgewichenen Zustand heraus, weshalb Protokollzeiten unmittelbar nach einer Wiederherstellung als besonders unzuverlässig zu behandeln sind.

6. Das Geschäftssystem entwerfen — auf der Annahme aufbauen, dass die Zeit abweicht und zurückspringt

Alles bisher Gesagte betraf die Infrastrukturseite, doch egal wie gut Sie die Zeitsynchronisierung einrichten, wird die Abweichung nie ganz null. Wer Software zur Geräteintegration baut, entwirft Protokollierung und Zeitmessung unter der Annahme, dass die Zeit abweicht und manchmal auch zurückspringt.

Der erste Grundsatz lautet, Protokoll-Zeitstempel in UTC aufzuzeichnen. Wird die Ortszeit aufgezeichnet, stehen Zeitzonen, Sommerzeit und rechnerspezifische Konfigurationsunterschiede dem Abgleich im Weg (dieses Thema wird ausführlich in „Datum, Uhrzeit und Zeitzonen in Geschäftsanwendungen“ behandelt). Der zweite Grundsatz lautet, für „wann ist es passiert“ und „wie lange hat es gedauert“ unterschiedliche Uhren zu verwenden.

// [Falle] Verstrichene Zeit mit der Systemuhr messen
// Wendet w32time eine Stepping-Korrektur an, kann diese Differenz länger oder kürzer
// als real ausfallen, oder sogar negativ sein
var start = DateTime.UtcNow;
ExecuteInspection();
var elapsed = DateTime.UtcNow - start;   // wird dies für eine Timeout-Prüfung verwendet, schlägt sie fehlerhaft an

// [Standardpraxis] Verstrichene Zeit mit Stopwatch messen (eine monotone Uhr)
long t0 = Stopwatch.GetTimestamp();
ExecuteInspection();
TimeSpan elapsed2 = Stopwatch.GetElapsedTime(t0);   // .NET 7 oder höher; davor Stopwatch.StartNew()

Stopwatch ist eine Klasse, die eigens zur Messung verstrichener Zeit dient, indem sie Ticks des hochauflösenden Leistungszählers zählt (das Äquivalent zu QueryPerformanceCounter), und bleibt von Korrekturen der Systemuhr unberührt.5 DateTime.UtcNow hingegen ist die Systemuhr selbst, und seine Auflösung hängt vom Systemtimer ab (etwa 0,5 bis 15 ms).6 Timeout-Prüfungen, Wiederholungsintervalle, Leistungsmessung, Geräteantwortzeiten — alles, was mit „Dauer“ zu tun hat, gehört auf die Stopwatch-Seite.

Schreiben Sie beide Werte ins Protokoll. Ein Wanduhr-Wert (UTC) gepaart mit einem monotonen Wert erlaubt es Ihnen, Reihenfolge und Intervalle im Nachhinein zu rekonstruieren, selbst über ein Intervall hinweg, das eine NTP-Stepping-Korrektur enthält.

public sealed class OpLog
{
    private static readonly long _baseTimestamp = Stopwatch.GetTimestamp();
    private static long _seq;

    public static void Write(string message)
    {
        long seq = Interlocked.Increment(ref _seq);
        // UTC-Zeit (wann es passiert ist) + monotone ms seit dem Start (Reihenfolge und Intervalle)
        // + Sequenznummer (Reihenfolge innerhalb desselben Zeitstempels)
        var line = $"{DateTime.UtcNow:yyyy-MM-dd'T'HH:mm:ss.fff'Z'}\t" +
                   $"{Stopwatch.GetElapsedTime(_baseTimestamp).TotalMilliseconds:F1}\t" +
                   $"{seq}\t{message}";
        // ... in Datei/ETW schreiben
    }
}

Für den Abgleich von Protokollen über mehrere Rechner und Geräte hinweg kommen zwei weitere Punkte hinzu. Erstens: die Abweichung zur Uhr der Gegenstelle regelmäßig protokollieren. Geräte mit eigener Uhr, etwa Kameras und SPS, lassen sich meist über das Kommunikationsprotokoll auslesen, sodass Sie beim Anwendungsstart und in einem festen Rhythmus (etwa stündlich) „die Differenz zwischen der UTC-Zeit des PCs und der Gerätezeit“ protokollieren. Das ist das geräteseitige Gegenstück zu w32tm /stripchart und erlaubt es Ihnen, nach einer Störung mechanisch abzugleichen: „für diesen Zeitraum die Zeitstempel des Geräteprotokolls mit einer Korrektur von +12,3 Sekunden lesen“. Zweitens: die Zeitbasis der eigenen Protokolle mit der von Ereignisprotokoll und ETW-Datensätzen in Einklang bringen (siehe „Eine Einführung in Windows-Ereignisprotokoll und ETW“). Für das Design von Absturznachweisen („Windows-Apps so entwerfen, dass sie bei einem Absturz Protokolle und Dumps hinterlassen“) und für die Untersuchung netzwerkbedingter Störungen wie eines Kamera-Kommunikationsabbruchs („Warum TCP-Neuübertragungen die Kommunikation industrieller Kameras ins Stocken bringen“) macht es einen Unterschied von einer Größenordnung in der Untersuchungszeit, ob die Zeitbasen übereinstimmen.

In einem Offline-Werks-LAN (ohne Internetverbindung) ist time.windows.com nicht erreichbar, weshalb der Standardansatz darin besteht, einen lokalen NTP-Server im LAN einzurichten und alle Geräte darauf auszurichten. Eine GPS-Uhr ist ideal, aber auch ohne sie erreichen Sie im Wesentlichen alles, was für den Protokollabgleich nötig ist, wenn Sie einen Zustand herstellen, in dem „die absolute Zeit zwar etwas abweichen mag, aber alle Geräte auf dieselbe Referenz ausgerichtet sind“. Erwägen Sie beim Referenzserver auch, LocalClockDispersion anzupassen, das bestimmt, welche Genauigkeit er sich selbst zuschreibt, solange er sich nicht extern synchronisieren kann.2

7. Entscheidungstabelle nach Umgebung

Umgebung Standardquelle und -frequenz Typisches Symptom Empfohlene Maßnahme
Domänengebundener PC/Server DC (NT5DS) → PDC-Emulator an der Spitze1 Die gesamte Domäne weicht gegenüber der Außenwelt einheitlich ab Auf dem PDC-Emulator eine genaue externe Zeitquelle mit /manualpeerlist konfigurieren. Mitglieder auf Standardeinstellungen belassen
Arbeitsgruppen-PC time.windows.com, Standard ist niedrige Frequenz — etwa wöchentlich2 Abweichungen von einigen Dutzend Sekunden werden zur Norm Mit /manualpeerlist (,0x9 = Client + SpecialInterval) einen internen NTP-Server angeben und SpecialPollInterval verkürzen (z. B. 3.600 Sekunden)
Hyper-V/Azure-VM (domänengebunden) Zwei Quellen: der Host (VMIC) und NTP7 Doppelte Korrektur lässt die Zeit wandern; starke Abweichung unmittelbar nach einer Wiederherstellung Ab 2016 auf beiden Seiten mit Standardeinstellungen koexistenzfähig. Bei Gästen mit 2012 R2 oder älter VMICTimeProvider deaktivieren3
Hyper-V/Azure-VM (eigenständig) Wie oben Selten ein Problem Hostsynchronisierung auf Standard belassen3
Offline-Werks-LAN Keine Quelle (jeder Rechner auf sich allein mit der internen Uhr) Jedes Gerät weicht unabhängig ab Alle Geräte (PCs und Anlagen) auf einen lokalen NTP-Server als Referenz ausrichten. Abweichung zu Geräteuhren regelmäßig protokollieren
Reihenfolge auf Millisekundenebene erforderlich — Genauigkeit der Zeitsynchronisierung reicht nicht aus Bedingungen für Windows Server 2016 oder höher plus hochpräzise Konfiguration prüfen4. Wo möglich, auf ein Design mit Messung über die Stopwatch eines einzelnen Rechners umsteigen

8. Zusammenfassung

  • Die Windows-Zeit wird von w32time verwaltet: hierarchische Synchronisierung mit dem PDC-Emulator an der Spitze in einer Domäne und standardmäßig niedrigfrequente Synchronisierung mit time.windows.com in einer Arbeitsgruppe. Abweichungen von einigen Dutzend Sekunden sind kein Fehler — sie sind die Folge der Standardwerte.
  • Die Untersuchung beginnt mit w32tm /query /status, um Quelle und letzte Synchronisierungszeit zu prüfen, sowie mit w32tm /stripchart, um die tatsächliche Abweichung gegenüber einer Gegenstelle zu messen. Mit /config /manualpeerlist die Quelle ausdrücklich festlegen und mit /resync sofort anwenden.
  • w32time korrigiert kleine Abweichungen durch Slewing und große durch Stepping. Denken Sie daran, dass die Systemuhr zurückspringen kann und dass, sobald die Grenzwerte überschritten sind, überhaupt nichts mehr korrigiert wird.
  • Historisch lag das Genauigkeitsziel der Standardkonfiguration bei „ausreichend für die fünf Minuten von Kerberos“. Genauigkeit im Millisekundenbereich kam mit Windows Server 2016 hinzu und wird nur unterstützt, wenn die Bedingungen bezüglich Zeitquelle, Latenz, Hop-Anzahl und CPU-Last erfüllt sind.
  • Virtuelle Maschinen verfügen über zwei Quellen: Hostsynchronisierung und NTP. Domänengebundene VMs sollten sich grundsätzlich ausschließlich auf die Domänensynchronisierung verlassen (VMICTimeProvider bei älteren Gast-Betriebssystemen deaktivieren), eigenständige VMs sollten bei der Hostsynchronisierung bleiben.
  • Auf Anwendungsseite: UTC für Zeitstempel, Stopwatch für verstrichene Zeit und eine regelmäßige Aufzeichnung der Abweichung zur eigenen Uhr des Geräts. Diese drei Dinge bewahren Sie vor Störungsanalysen, bei denen sich nicht sagen lässt, „was zuerst war“.

Verwandte Artikel

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt Untersuchungen der Art „die Protokollzeiten von Gerät und PC stimmen nicht überein, sodass sich bei einer Störung die Reihenfolge der Ereignisse nicht feststellen lässt“, das Design der Zeitsynchronisierung für Werks-LANs und geräteintegrierte Umgebungen sowie die Entwicklung und Verbesserung von Software zur Geräteintegration — einschließlich Fehlern rund um Timeouts und Zeitmessung.

</content>

  1. Microsoft Learn, How the Windows Time Service Works. Dazu, dass w32time der Standard-Zeitsynchronisierungsdienst von Windows ist, der die Algorithmen der NTP-Spezifikation nutzt; zur Zeithierarchie einer AD-DS-Gesamtstruktur (Mitglied → DC → DC der übergeordneten Domäne → PDC-Emulator der Stammdomäne der Gesamtstruktur); dazu, dass Nicht-Domänenrechner sich standardmäßig mit time.windows.com synchronisieren; zur Authentifizierung der Zeit über Kerberos-Sitzungsschlüssel; dazu, dass manuell angegebene Zeitquellen nicht authentifiziert werden; zur Taktdisziplinierung über Slewing und Stepping; sowie zur Nutzung von UDP-Port 123. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, Windows Time service tools and settings. Zu den verschiedenen w32tm-Befehlsoptionen (/query /status, /source, /peers, /configuration, /stripchart, /resync, /config /manualpeerlist /syncfromflags); zu den NtpServer-Flags (0x1 SpecialInterval, 0x2 UseAsFallbackOnly, 0x8 Client) und der Empfehlung, bei einer Zwei-Server-Konfiguration 0x2 zu verwenden; dazu, dass der eigenständige Standard time.windows.com,0x1 mit einem SpecialPollInterval-Standardwert von 604.800 Sekunden lautet; zum Wechsel zwischen Slewing und Stepping über MaxAllowedPhaseOffset; dazu, dass bei Überschreiten von MaxPos/MaxNegPhaseCorrection (eigenständiger Standardwert 54.000 Sekunden) nur ein Ereignis protokolliert wird; sowie zu LocalClockDispersion. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  3. Microsoft Learn, Time accuracy improvements for Windows Server 2016. Zu den Verbesserungen am Hyper-V-TimeSync-Dienst (genaue Anfangszeit bei VM-Start/-Wiederherstellung, Korrektur der Interrupt-Latenz, Meldung von Host-Stratum + 1, sowie zur Wahl der genauesten Uhr durch domänengebundene 2016-Gäste); zur Empfehlung, den Hyper-V-Zeitanbieter bei domänengebundenen Gästen mit 2012 R2 oder älter zu deaktivieren, und zur VMICTimeProvider-Registrierungseinstellung; zu den Hinweisen für Azure-VMs (TimeSync bei domänengebundenen VMs deaktivieren, Hostsynchronisierung bei eigenständigen VMs beibehalten); sowie zum Versionsvergleich der Standard-Abfrage- und Uhraktualisierungsfrequenzen (wöchentlich bei eigenständigen Rechnern der 2012-R2-Generation, sekündliche Uhraktualisierung bei 2016). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  4. Microsoft Learn, Support boundary for high accuracy time. Dazu, dass w32time vor Windows 10 1607 / Windows Server 2016 ein Entwurfsziel hatte, das für die Anforderungen von Kerberos v5 ausreichende Genauigkeit vorsah, wobei hohe Genauigkeit nicht unterstützt wurde; dazu, dass ab 2016 eine Genauigkeit von 1 Sekunde / 50 ms / 1 ms unterstützt wird, sofern die Bedingungen erfüllt sind; sowie zu den Bedingungen für 1-ms-Genauigkeit (eine Stratum-1-Zeitquelle, Netzwerklatenz unter 0,1 ms, innerhalb von Stratum 5 und 4 Hops, CPU-Auslastung von höchstens 80 % und Ähnliches). ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Stopwatch Class (System.Diagnostics). Dazu, dass Stopwatch eine Klasse zur genauen Messung verstrichener Zeit ist; zum Zählen von Ticks des hochauflösenden Leistungszählers, sofern Hardware und Betriebssystem dies unterstützen; dazu, dass Frequency/GetTimestamp anstelle von QueryPerformanceFrequency/QueryPerformanceCounter verwendet werden können; sowie zur Messung über GetTimestamp und GetElapsedTime. ↩ ↩2

  6. Microsoft Learn, DateTime.UtcNow Property. Dazu, dass DateTime.UtcNow das aktuelle Datum und die aktuelle Uhrzeit des Computers in UTC zurückgibt — also die Systemuhr —, und dazu, dass die Auflösung vom Systemtimer abhängt, im Allgemeinen zwischen 0,5 und 15 ms. ↩ ↩2

  7. Microsoft Learn, Accurate Time for Windows Server 2016. Dazu, dass ein Hyper-V-Gast anhand von Kriterien wie dem Stratum die beste Zeitquelle aus mehreren Anbietern wählt — dem VMIC-Anbieter des Hosts und NTP; dazu, dass der Standard für eigenständige Rechner time.windows.com ist; dazu, dass bei einer entfernten Zeitquelle keine 1-ms-Genauigkeit zu erwarten ist; dazu, dass w32time nur Stratum 15 oder niedriger akzeptiert; sowie zu den drei Voraussetzungen für genaue Zeit (eine stabile Zeitquelle, eine stabile Client-Uhr und symmetrische NTP-Kommunikation). ↩ ↩2 ↩3 ↩4

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Die Protokolle auf meinem PC und die Protokolle des Geräts stimmen nicht überein. Was sollte ich zuerst prüfen?
Führen Sie zunächst auf dem PC w32tm /query /status aus und prüfen Sie „Quelle“ (womit synchronisiert wird) und „Letzte erfolgreiche Synchronisierungszeit“. Steht als Quelle Local CMOS Clock, oder liegt die letzte Synchronisierung Tage zurück, ist dieser PC faktisch mit nichts synchronisiert. Messen Sie anschließend mit w32tm /stripchart /computer:<Gegenstelle> /dataonly die tatsächliche Abweichung gegenüber der Gegenstelle (einem Server oder dem NTP-Port des Geräts), damit Sie eine Zahl dafür haben, wer wie weit abweicht. Führt das Gerät eine eigene Uhr, lesen Sie die Gerätezeit über dessen Einstellungsbildschirm oder die Kommunikation aus und protokollieren Sie die Differenz zur PC-Zeit — dieser Datensatz erlaubt es später auch, historische Protokolle abzugleichen.
Wie oft synchronisiert ein Windows-Rechner in einer Arbeitsgruppe seine Zeit tatsächlich?
Ein Windows-Rechner, der keiner Domäne beigetreten ist, synchronisiert sich standardmäßig mit time.windows.com, allerdings ist die Frequenz sehr niedrig eingestellt. Der Registrierungs-Standardwert für SpecialPollInterval beträgt in einer eigenständigen Konfiguration 604.800 Sekunden (eine Woche), und selbst ein Windows-10-Client fragt nur etwa einmal täglich ab. Interne PC-Uhren weichen üblicherweise um Sekunden bis einige Dutzend Sekunden pro Tag ab, sodass bei dieser Frequenz keine für den Abgleich von Geschäftsprotokollen ausreichende Genauigkeit zu erwarten ist. Wo die Zeitgenauigkeit von Protokollen wichtig ist, ist es üblich, den Rechner mit w32tm /config /manualpeerlist auf einen internen NTP-Server auszurichten und SpecialPollInterval zu verkürzen.
Sollte eine virtuelle Maschine auf Hyper-V ihre Zeit vom Host oder von NTP beziehen?
Ein Hyper-V-Gast verfügt über zwei Zeitanbieter — den Hyper-V-Zeitsynchronisierungsdienst (VMICTimeSync) und den NTP-Client —, und Windows wählt anhand von Kriterien wie dem Stratum den besseren der beiden aus. Für einen domänengebundenen Gast gilt die Regel, sich mit der Domänenhierarchie (einem DC) zu synchronisieren; ab Windows Server 2016 sowohl auf Host- als auch auf Gastseite wurden beide so verbessert, dass sie koexistieren können. Betreiben Sie einen Gast mit Windows Server 2012 R2 oder älter in einer Domäne, empfiehlt Microsoft, VMICTimeProvider zu deaktivieren und sich ausschließlich auf die Domänensynchronisierung zu verlassen. Bei einer eigenständigen VM in einer Arbeitsgruppe ist es die einfache und zuverlässige Wahl, die Standard-Hostsynchronisierung beizubehalten.
Was passiert in einer Domänenumgebung, wenn die Zeit stark abweicht?
Kerberos, das Active Directory zur Authentifizierung nutzt, verlangt standardmäßig eine Übereinstimmung von Client- und Serveruhr auf fünf Minuten genau. Wird das überschritten, schlägt die Authentifizierung fehl, und grundlegende Domänenfunktionen — der Zugriff auf Freigabeordner, die Anwendung von Gruppenrichtlinien und Ähnliches — funktionieren nicht mehr. Domänengebundene PCs synchronisieren sich standardmäßig mit einem DC und letztlich über eine Hierarchie, an deren Spitze der PDC-Emulator der Gesamtstruktur-Stammdomäne steht, sodass eine derart große Abweichung ungewöhnlich ist. Umgekehrt gilt: Ist der PDC-Emulator selbst nicht mit einer genauen externen Zeitquelle synchronisiert, ist die gesamte Domäne „gemeinsam falsch“ — weshalb die Prüfung der Konfiguration an der Spitze der Hierarchie wichtig ist.
Warum sollte ich DateTime.UtcNow nicht zur Messung verstrichener Zeit verwenden?
Weil DateTime.UtcNow die Systemuhr ausliest und damit die Korrekturen von w32time in voller Wucht mitbekommt. Ist die Abweichung groß, gleicht w32time nicht allmählich an (Slewing), sondern stellt die Uhr direkt (Stepping), wobei die Zeit sowohl vor- als auch zurückspringen kann. Das bedeutet, dass eine durch Subtraktion zweier UtcNow-Werte berechnete verstrichene Zeit länger als real, kürzer als real oder sogar negativ ausfallen kann. Verwenden Sie für verstrichene Zeit und Timeouts Stopwatch (bzw. Stopwatch.GetTimestamp), das monoton und unabhängig von der Systemuhr zunimmt, und behandeln Sie UtcNow ausschließlich als Aufzeichnung von „wann ist das passiert“.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.

Kontakt
Zurück zum Blog