Verbesserungen bei der Zeitgenauigkeit für Windows Server 2016

• Gilt für::

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2 and 22H2

Windows Server 2016 hat die Algorithmen für die Korrektur der Uhrzeit und für die Festlegung der Bedingungen für die Synchronisierung der lokalen Uhrzeit mit der koordinierten Weltzeit (UTC) verbessert. Das Netzwerkzeitprotokoll (Network Time Protocol, NTP) verwendet vier Werte, um die Zeitdifferenz zu berechnen, basierend auf den Zeitstempeln der Clientanforderung/-antwort und der Serveranforderung/-antwort. Allerdings sind Netzwerke mit Störungen behaftet, und es kann aufgrund von Netzwerküberlastung und anderen Faktoren, die die Netzwerkwartezeiten beeinflussen, zu Lastspitzen bei den von NTP eingehenden Daten kommen. Windows Server 2016-Algorithmen normalisieren diese Störungen auf ein Mittelmaß durch verschiedene Verfahren, die zu einer stabilen und präzisen Uhrzeit führen. Die Quelle, die wir für die genaue Zeit verwenden, verweist auch auf eine verbesserte API, die uns eine bessere Lösung bietet. Mit diesen Verbesserungen können wir eine Genauigkeit von 1 ms in Bezug auf die UTC in einer Domäne erzielen.

Hyper-V

Windows Server 2016 hat den Hyper-V-TimeSync-Dienst verbessert. Zu den Verbesserungen gehören eine genauere Anfangszeit beim Start oder bei der Wiederherstellung von virtuellen Computern (VMs) sowie eine Korrektur der Latenzzeitunterbrechung für Stichproben, die für den Windows-Zeitdienst (W32Time) bereitgestellt werden. Dank dieser Verbesserung können wir weniger als 10 μs vom Host entfernt bleiben und einer mittleren quadratischen Abweichung (Indikator für die Varianz) von 50 μs, selbst wenn ein Computer eine Auslastung von 75 % aufweist. Weitere Informationen findest du unter Hyper-V-Architektur.

Hinweis

Die Auslastung wurde unter Verwendung des prime95-Benchmarks mithilfe eines ausgeglichenen Profils erstellt.

Die Stratum-Ebene, die der Host dem Gast meldet, ist transparenter. Zuvor hätte der Host unabhängig von seiner Genauigkeit ein festes Stratum von 2 angegeben. Aufgrund der Änderungen in Windows Server 2016 meldet der Host ein Stratum 1, das höher ist als das Stratum des Hosts, woraus sich eine bessere Zeit für virtuelle Gäste ergibt. Das Stratum des Host wird von W32Time auf herkömmliche Weise basierend auf seiner Quellzeit bestimmt. Einer Domäne beigetretene Windows Server 2016-Gäste finden die genaueste Uhr, statt den Host als Standard zu wählen. Deshalb solltest du die Einstellung für den Hyper-V-Zeitanbieter für Computer, die Teil einer Domäne in Windows R2 und niedriger sind, manuell deaktivieren.

Überwachung

Leistungsindikatoren wurden hinzugefügt. Mithilfe dieser Indikatoren kannst du eine Baseline einrichten, die Zeitgenauigkeit überwachen und eventuelle Probleme lösen. In der folgenden Tabelle sind die Indikatoren aufgeführt.

Leistungsindikator	Beschreibung
Berechnete Zeitdifferenz	Die absolute Zeitdifferenz zwischen Systemuhr und ausgewählter Zeitquelle, wie vom W32Time-Dienst in Mikrosekunden berechnet. Wenn eine neue gültige Stichprobe verfügbar ist, wird die berechnete Zeit anhand der von der Stichprobe angegebenen Zeitdifferenz aktualisiert. Dies Zeit entspricht der tatsächlichen Zeitabweichung der lokalen Uhr. W32Time initiiert die Zeitanpassung anhand dieser Differenz und aktualisiert die berechnete Zeit zwischen Stichproben mit der verbleibenden Zeitdifferenz, die auf die lokale Uhr angewendet werden muss. Durch diesen Leistungsindikator kann die Zeitgenauigkeit mit einem niedrigen Abrufintervall (z. B. 256 Sekunden oder weniger) überwacht werden. Dabei sollte der Leistungsindikatorwert kleiner als der gewünschte Grenzwert für die Zeitgenauigkeit sein.
Anpassung der Taktfrequenz	Die Anpassung der absoluten Taktfrequenz, die von W32Time am lokalen System vorgenommen wird (Anzahl pro Milliarde Einheiten). Dieser Leistungsindikator hilft, die von W32Time vorgenommenen Aktionen zu visualisieren.
NTP-Roundtripverzögerung	Die aktuelle Roundtripverzögerung des NTP-Clients beim Empfang einer Antwort vom Server in Mikrosekunden. Diese Verzögerung entspricht der Zeit, die auf dem NTP-Client zwischen der Übertragung einer Anforderung an den NTP-Server und dem Empfang einer gültigen Antwort vom Server verstrichen ist. Mithilfe dieses Leistungsindikators werden die auf dem NTP-Client aufgetretenen Verzögerungen klassifiziert. Längere oder variierende Roundtrips können zu ungenaueren NTP-Zeitberechnungen führen, was sich wiederum auf die Genauigkeit bei der Zeitsynchronisierung durch NTP auswirken könnte.
Anzahl von Zeitquellen des NTP-Clients	Die aktive Anzahl der NTP-Zeitquellen, die vom NTP-Client verwendet werden. Diese Anzahl entspricht der Anzahl der aktiven eindeutigen IP-Adressen von Zeitservern, die auf Anforderungen dieses Clients antworten. Die Anzahl könnte größer oder kleiner sein als die Anzahl der konfigurierten Peers. Dies richtet sich nach der DNS-Auflösung von Peernamen und der aktuellen Erreichbarkeit.
Eingehende Anforderungen des NTP-Servers	Die Anzahl der vom NTP-Server empfangenen Anforderungen (Anforderungen/Sek.).
Ausgehende Antworten des NTP-Servers	Die Anzahl der vom NTP-Server beantworteten Anforderungen (Anforderungen/Sek.).

Die ersten drei Leistungsindikatoren zielen auf Szenarien zur Behandlung von Genauigkeitsproblemen ab. Weitere Informationen finden Sie im Abschnitt Behandlung von Genauigkeitsproblemen bei der Zeit und dem NTP weiter unten in diesem Artikel. Die letzten drei Leistungsindikatoren decken NTP-Serverszenarien ab und sind hilfreich, wenn Sie die Auslastung und das Aufstellen einer Baseline für Ihre aktuelle Leistung ermitteln wollen.

Konfigurationsaktualisierungen nach Umgebung

In der folgenden Tabelle werden die Änderungen an der Standardkonfiguration zwischen Windows Server 2016 und früheren Versionen für jede Rolle beschrieben. Die Einstellungen für Windows Server 2016 und Windows 10 Anniversary Update (Build 14393) sind nun eindeutig, weshalb sie in separaten Spalten angezeigt werden.

Role	Einstellung	Windows Server 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
Eigenständig/Nano Server
	Zeitserver	time.windows.com	–	time.windows.com
	Abrufhäufigkeit	64 bis 1024 Sekunden	–	Einmal pro Woche
	Aktualisierungsrate der Uhr	Einmal pro Sekunde	–	Einmal pro Stunde
Eigenständiger Client
	Zeitserver	–	time.windows.com	time.windows.com
	Abrufhäufigkeit	–	Einmal pro Tag	Einmal pro Woche
	Aktualisierungsrate der Uhr	–	Einmal pro Tag	Einmal pro Stunde
Domänencontroller
	Zeitserver	PDC/GTIMESERV	–	PDC/GTIMESERV
	Abrufhäufigkeit	64 bis 1024 Sekunden	Nicht verfügbar	1,024 bis 32,768 Sekunden
	Aktualisierungsrate der Uhr	Einmal pro Sekunde	–	Einmal pro Stunde
Domänenmitgliedsserver
	Zeitserver	DC	–	DC
	Abrufhäufigkeit	64 bis 1024 Sekunden	Nicht verfügbar	1,024 bis 32,768 Sekunden
	Aktualisierungsrate der Uhr	Einmal pro Sekunde	–	Einmal alle 5 Minuten
Domänenmitgliedsclient
	Zeitserver	–	DC	DC
	Abrufhäufigkeit	Nicht verfügbar	1,204 bis 32,768 Sekunden	1,024 bis 32,768 Sekunden
	Aktualisierungshäufigkeit der Uhr	–	Einmal alle 5 Minuten	Einmal alle 5 Minuten
Hyper-V-Gast
	Zeitserver	Wählt die beste Option aus, basierend auf dem Stratum des Hosts und des Zeitservers.	Wählt die beste Option aus, basierend auf dem Stratum des Hosts und des Zeitservers.	Standardeinstellung ist Host
	Abrufhäufigkeit	Basierend auf der oben genannten Rolle	Basierend auf der oben genannten Rolle	Basierend auf der oben genannten Rolle
	Aktualisierungshäufigkeit der Uhr	Basierend auf der oben genannten Rolle	Basierend auf der oben genannten Rolle	Basierend auf der oben genannten Rolle

Hinweis

Informationen zu Linux in Hyper-V finden Sie unten im Abschnitt Linux die Verwendung der Hyper-V-Hostzeit gestatten.

Auswirkungen von erhöhter Abruf- und Aktualisierungshäufigkeit der Uhr

Um eine genauere Zeit bereitzustellen, werden die Standardwerte für die Abrufhäufigkeiten und Aktualisierungen der Uhr erhöht, was es uns gestattet, häufiger kleinere Anpassungen vorzunehmen. Diese Änderung führt zu erhöhtem UDP (User Datagram Protocol)/NTP-Datenverkehr. Diese Pakete sind klein, weshalb dies nur sehr geringe oder gar keine Auswirkungen auf Breitbandverbindungen haben sollte. Der Vorteil besteht jedoch darin, dass die Zeit für eine größere Vielfalt von Hardware und Umgebungen besser sein sollte.

Bei Geräten mit Akku kann das Erhöhen der Abrufhäufigkeit zu Problemen führen. Geräte mit Akku speichern die Zeit nicht, während sie ausgeschaltet sind. Wenn sie wieder eingeschaltet werden, könnte es sein, dass die Uhr häufig korrigiert werden muss. Eine Erhöhung der Abfragehäufigkeit führt dazu, dass die Uhr instabil wird und auch mehr Strom verbrauchen könnte. Es wird empfohlen, die Standardeinstellungen des Clients nicht zu ändern.

Auswirkungen auf Domänencontroller (DCs) sollten minimal sein, selbst wenn man den vervielfachten Effekt durch die erhöhten Aktualisierungen von NTP-Clients in einer Active Directory-Domäne berücksichtigt. NTP weist im Vergleich zu anderen Protokollen einen wesentlich geringeren Ressourcenverbrauch und hat nur geringe Auswirkungen. Es ist wahrscheinlicher, dass Sie Grenzwerte für andere Domänenfunktionen erreichen, bevor die erweiterten Einstellungen für Windows Server 2016 Auswirkungen für Sie haben könnten. Active Directory verwendet sicheres NTP, das tendenziell dazu neigt, die Zeit weniger genau zu synchronisieren als Simple NTP. Wir haben sichergestellt, dass es sich bis zu Clients hochskalieren lässt, die zwei Strata vom Primary Domain Controller (PDC) entfernt sind.

Als konservativen Plan solltest du 100 NTP-Anforderungen pro Sekunde pro Kern reservieren. Beispielsweise sollten Sie bei einer Domäne, die aus vier DCs mit jeweils vier Kernen bestehen, in der Lage sein, 1600 NTP-Anforderungen pro Sekunde zu bedienen. Wenn Sie 10.000 Clients so konfiguriert haben, dass sie alle 64 Sekunden die Zeit synchronisieren, und die Anforderungen im Laufe der Zeit gleichmäßig empfangen werden, werden Sie feststellen, dass 10.000/64 Sekunden oder ungefähr 160 Anforderungen/Sekunde auf alle DCs verteilt werden. Diese Anzahl liegt problemlos innerhalb unserer 1600 NTP-Anforderungen/Sek. basierend auf diesem Beispiel. Hierbei handelt es sich um konservative Planungsempfehlungen, die in hohem Maße von Ihrem Netzwerk, den Prozessorgeschwindigkeiten und der Auslastung abhängen. Führen Sie also wie immer in Ihren Umgebungen Tests durch und richten Sie eine Baseline ein.

Wenn Ihre DCs mit einer beträchtlichen CPU-Auslastung von mehr als 40 % laufen, wird diese Auslastung mit hoher Wahrscheinlichkeit zu Störungen in den NTP-Antworten führen und die Zeitgenauigkeit in Ihrer Domäne beeinträchtigen. Auch hier musst du in deiner Umgebung Tests durchführen, um die tatsächlichen Ergebnisse zu verstehen.

Messungen der Zeitgenauigkeit

Zum Messen der Zeitgenauigkeit für Windows Server 2016 haben wir unterschiedliche Tools, Methoden und Umgebungen verwendet. Du kannst diese Methoden verwenden, um deine Umgebung zu messen und zu optimieren und zu bestimmen, ob die Genauigkeitsergebnisse deinen Anforderungen entsprechen.

Methodik

Die Quelluhr unserer Domäne bestand aus zwei hochpräzisen NTP-Servern mit GPS-Hardware. Wir haben ferner einen separaten Referenztestcomputer für Messungen verwendet, der ebenfalls über hochpräzise GPS-Hardware von einem anderen Hersteller verfügte. Für einige der Tests benötigen Sie eine exakte und zuverlässige Uhrenquelle, die zusätzlich zur Uhrenquelle Ihrer Domäne als Referenz verwendet werden kann.

Wir haben vier verschiedene Methoden verwendet, um die Genauigkeit mit beiden physischen und virtuellen Computern zu messen. Mehrere Methoden boten unabhängige Möglichkeiten zur Validierung der Ergebnisse.

1. Messen der lokalen Uhr, die von w32tm gesteuert wird, anhand unseres Referenztestcomputers, der über separate GPS-Hardware verfügt.

2. Messen von NTP-Pings vom NTP-Server an Clients mittels „stripchart“ von W32tm.

3. Messen von NTP-Pings vom Client an den NTP-Server mittels „stripchart“ von W32tm.

4. Messen von Hyper-V-Ergebnissen vom Host an den Gast unter Verwendung des Zeitstempelindikators (Time Stamp Counter, TSC). Dieser Leistungsindikator wird von beiden Partitionen und der Systemzeit in beiden Partitionen gemeinsam genutzt. Wir haben die Differenz zwischen der Hostzeit und der Clientzeit auf der VM berechnet. Dann haben wir die TSC-Uhr verwendet, um die Hostzeit über den Gast zu interpolieren, da die Messungen nicht gleichzeitig stattfinden. Außerdem haben wir die TSC-Uhr verwendet, um Verzögerungen und Wartezeiten in der API auszuklammern.

W32tm ist integriert, aber die anderen Tools, die wir bei unseren Tests verwendet haben, sind für das Microsoft-Repository auf GitHub als Open Source für Ihre Tests und zu Ihrer Verwendung verfügbar. Weitere Informationen über die Verwendung der Tools zur Durchführung von Messungen finden Sie unter Windows Time Calibration Tools Wiki.

Die aufgeführten Testergebnisse sind eine Teilmenge der Messungen, die wir in einer der Testumgebungen vorgenommen haben. Sie veranschaulichen die Genauigkeit, die am Anfang der Zeithierarchie aufrechterhalten wird, sowie beim untergeordneten Domänenclient am Ende der Zeithierarchie. Diese Ergebnisse werden zur Veranschaulichung mit denselben Computern in einer 2012-basierten Topologie verglichen.

Topologie

Zum Vergleich haben wir eine Windows Server R2- und eine Windows Server 2016-basierte Topologie getestet. Beide Topologien bestehen aus zwei physischen Hyper-V-Hostcomputern, die einen Windows Server 2016-Computer referenzieren, auf dem GPS-Uhrenhardware installiert ist. Auf jedem Host werden 3 der Domäne beigetretene Windows-Gäste ausgeführt, die entsprechend der folgenden Topologie angeordnet sind. Die Zeilen stellen die Zeithierarchie sowie das verwendete Protokoll bzw. den Transport dar.

Grafische Übersicht der Ergebnisse

Die beiden folgenden Diagramme stellen die Zeitgenauigkeit für zwei bestimmte Mitglieder in einer Domäne auf der Grundlage der oben vorhergehenden Topologie dar. Jedes Diagramm zeigt eine Überlagerung der Ergebnisse von Windows Server R2 und von 2016, wodurch sich die Verbesserungen visuell veranschaulichen lassen. Die Genauigkeit wurde auf dem Gastcomputer im Vergleich zum Host gemessen. Die grafischen Daten repräsentieren eine Teilmenge des gesamten Testumfangs, den wir durchgeführt haben, und zeigen die Best-Case- und Worst-Case-Szenarien.

Leistung des PDC der Stammdomäne

Der Stamm-PDC wird mit dem Hyper-V-Host (mittels VMIC) synchronisiert, wobei es sich um einen Windows Server 2016 mit GPS-Hardware handelt, die nachweislich genau und stabil ist. Diese Anforderung ist kritisch für eine Genauigkeit von 1 ms, die als grün schattierter Bereich mit einer Beschreibung dargestellt ist.

Leistung des Clients der untergeordneten Domäne

Der Client der untergeordneten Domäne ist mit einem untergeordneten Domänen-PDC verbunden, der mit dem Stamm-PDC kommuniziert. Seine Zeit liegt auch innerhalb der Anforderung von 1 ms.

Langstreckentest

Im folgenden Diagramm wird 1 virtueller Netzwerk-Hop mit 6 physischen Netzwerk-Hops mit Windows Server 2016 verglichen. Zwei Diagramme sind transparent überlagert, um überlappende Daten darzustellen. Das Erhöhen der Netzwerkhops bedeutet eine höhere Wartezeit und stärkere Zeitabweichungen. Das Diagramm ist vergrößert, sodass die durch den grün schattierten Bereich dargestellten 1-ms-Grenzen größer sind. Wie du sehen kannst, liegt die Zeit bei mehreren Hops immer noch innerhalb von 1 ms. Es ist negativ verschoben, was eine Netzwerkasymmetrie veranschaulicht. Alle Netzwerke sind anders, und die Messungen hängen von zahlreichen Umgebungsfaktoren ab.

Bewährte Methoden für exakte Zeitmessungen

Befolgen Sie diese bewährten Methoden für exakte Zeitmessungen.

Stabile Quellenuhr

Eine Computerzeit ist nur so gut wie die Quellenuhr, mit der sie synchronisiert wird. Um eine Genauigkeit von 1 ms zu erreichen, benötigen Sie GPS-Hardware oder ein Zeitgerät in Ihrem Netzwerk, das Sie als Masterquellenuhr referenzieren können. Wenn Sie den Standard time.windows.com verwenden, liefert dieser möglicherweise keine stabile und lokale Zeitquelle. Da Sie sich weiter von der Quellenuhr entfernen, wirkt sich das Netzwerk auf die Genauigkeit aus. Zum Erzielen einer optimalen Genauigkeit ist es erforderlich, in jedem Rechenzentrum eine Masterquellenuhr zu haben.

Hardware-GPS-Optionen

Verschiedene Hardwarelösungen können eine genaue Zeit bieten. Im Allgemeinen basieren Lösungen heute auf GPS-Antennen. Funk- und DFÜ-Modemlösungen verwenden dedizierte Leitungen. Sie werden entweder als Gerät mit Ihrem Netzwerk verbunden oder an einen PC angeschlossen, z. B. Windows über ein PCIe- oder USB-Gerät. Verschiedene Optionen bieten unterschiedliche Genauigkeitsstufen, und wie immer hängen die Ergebnisse von Ihrer Umgebung ab. Zu den Variablen, die die Genauigkeit beeinflussen, zählen GPS-Verfügbarkeit, Netzwerkstabilität und -auslastung sowie die PC-Hardware. All diese Faktoren sollten beachtet werden, wenn Sie eine Quellenuhr auswählen, die eine Voraussetzung für eine stabile und genaue Zeit darstellt.

Domäne und Synchronisierung der Zeit

Domänenmitglieder verwenden die Domänenhierarchie, um zu bestimmen, welchen Computer sie als Quelle für die Synchronisierung der Zeit verwenden. Jedes Domänenmitglied findet einen anderen Computer, mit dem es sich synchronisiert, und speichert diesen als Uhrenquelle. Jeder Typ von Domänenmitglied folgt einem anderen Satz von Regeln, um eine Quellenuhr für die Zeitsynchronisierung zu finden. Der PDC in der Gesamtstruktur ist die Standarduhrenquelle für alle Domänen. Hier sind verschiedene Rollen und allgemeine Beschreibungen für die Weise aufgeführt, wie sie eine Quelle finden:

• Domänencontroller mit PDC-Rolle: Dieser Computer ist die maßgebliche Zeitquelle für eine Domäne. Er besitzt die präziseste in der Domäne verfügbare Zeit. Er muss mit einem Domänencontroller in der übergeordneten Domäne synchronisiert werden, außer wenn die GTIMESERV-Rolle aktiviert ist.
• Jeder andere Domänencontroller: Dieser Computer fungiert als Zeitquelle für Clients und Mitgliedsserver in der Domäne. Ein DC kann eine Synchronisierung mit dem PDC seiner eigenen Domäne oder mit einem beliebigen Domänencontroller in seiner übergeordneten Domäne durchführen.
• Clients/Mitgliedsserver: Dieser Computer kann sich mit einem beliebigen DC oder PDC seiner eigenen Domäne oder mit einem DC oder PDC in der übergeordneten Domäne synchronisieren.

Abhängig von den verfügbaren Kandidaten wird ein Bewertungssystem verwendet, um die beste Zeitquelle zu ermitteln. Dieses System berücksichtigt die Zuverlässigkeit der Zeitquelle und ihren relativen Standort. Dies geschieht einmalig, wenn der Zeitdienst gestartet wird. Wenn du eine präzisere Kontrolle über die Art der Zeitsynchronisierung benötigst, kannst du gute Zeitserver an bestimmten Standorten oder Redundanz hinzufügen. Weitere Informationen finden Sie im Abschnitt Angeben eines lokalen zuverlässigen Zeitdiensts mithilfe von GTIMESERV.

Gemischte Betriebssystemumgebungen (Windows Server 2012 R2 und Windows Server 2008 R2)

Obwohl für eine optimale Genauigkeit eine reine Windows Server 2016-Domänenumgebung erforderlich ist, bietet eine gemischte Umgebung dennoch einige Vorteile. Dank der oben genannten Verbesserungen profitieren die Gäste von der Bereitstellung von Windows Server 2016 Hyper-V in einer Windows Server 2012-Domäne. Dies ist aber nur dann der Fall, wenn die Gäste ebenfalls Windows Server 2016 verwenden. Ein Windows Server 2016 PDC kann eine genauere Zeit bereitstellen und bietet aufgrund der verbesserten Algorithmen eine stabilere Quelle. Da das Ersetzen Ihres PDC möglicherweise keine Option ist, können Sie stattdessen einen Windows Server 2016 DC mit der GTIMESERV-Rollengruppe hinzufügen, wobei es sich um ein Upgrade hinsichtlich der Genauigkeit für Ihre Domäne handeln würde. Ein Windows Server 2016-Domänencontroller kann Downstream-Zeitclients eine bessere Zeit bereitstellen, ist aber nur so gut, wie seine Quell-NTP-Zeit.

Wie bereits erwähnt, wurden auch die Abruf- und Aktualisierungshäufigkeiten der Uhr mit Windows Server 2016 geändert. Diese Häufigkeiten können manuell für Ihre Downlevel-DCs geändert oder über Gruppenrichtlinien angewandt werden. Wir haben diese Konfigurationen nicht getestet, sie sollten sich aber in Windows Server 2008 R2 und Windows Server 2012 R2 gut verhalten und einige Vorteile bieten.

Versionen, die älter sind als Windows Server 2016, wiesen mehrere Probleme beim Aufrechterhalten genauer Zeitmessungen auf. Das führte dazu, dass sich die Systemzeit sofort nach Vornahme einer Anpassung verschob. Aus diesem Grund führt das häufige Abrufen von Zeitstichproben von einer exakten NTP-Quelle und das Konfigurieren der lokalen Uhr mit den Daten zu einer geringeren Abweichung der Systemuhren im Zeitraum zwischen den Stichprobennahmen. Das wiederum führt zu besseren Zeitmessungen bei Downlevel-Betriebssystemversionen. Die beste beobachtete Genauigkeit lag bei ungefähr 5 ms, als ein Windows Server 2012 R2-NTP-Client, für den die hohe Genauigkeit konfiguriert war, seine Zeit von einem präzisen Windows Server 2016-NTP-Server synchronisierte.

In einigen Szenarien mit Gastdomänencontrollern können Hyper-V-TimeSync-Stichproben die Zeitsynchronisierung der Domänen stören. Dies sollte bei Server 2016-Gästen, die auf Hyper-V-Hosts mit Server 2016 ausgeführt werden, kein Problem mehr sein.

Lege den folgenden Gastregistrierungsschlüssel fest, um zu deaktivieren, dass der Hyper-V-TimeSync-Dienst Stichproben für W32Time bereitstellt:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Linux die Verwendung der Hyper-V-Hostzeit gestatten

Für Linux-Gäste, die in Hyper-V ausgeführt werden, werden Clients in der Regel so konfiguriert, dass sie den NTP-Daemon für die Zeitsynchronisierung mit NTP-Servern verwenden. Wenn die Linux-Distribution das TimeSync-Protokoll Version 4 unterstützt und auf dem Linux-Gast der TimeSync-Integrationsdienst aktiviert ist, wird er mit der Hostzeit synchronisiert. Dieses Szenario könnte zu inkonsistenten Zeitmessungen führen, wenn beide Methoden aktiviert sind.

Um ausschließlich mit der Hostzeit zu synchronisieren, empfehlen wir, die NTP-Zeitsynchronisierung mit einer der folgenden Methoden zu deaktivieren:

• Deaktivieren aller NTP-Server in der Datei ntp.conf.
• Deaktivieren des NTP-Daemons.

In dieser Konfiguration ist der Zeitserverparameter dieser Host. Seine Abrufhäufigkeit beträgt 5 Sekunden, und die Aktualisierungshäufigkeit der Uhr beträgt ebenfalls 5 Sekunden.

Um ausschließlich über NTP zu synchronisieren, empfehlen wir Ihnen, den TimeSync-Integrationsdienst auf dem Gast zu deaktivieren.

Hinweis

Die Unterstützung einer exakten Zeit bei Linux-Gästen erfordert eine Funktion, die nur in den neuesten Linux-Upstreamkernels unterstützt wird Das Feature ist noch nicht in allen Linux-Distributionen allgemein verfügbar. Weitere Informationen zu unterstützten Distributionen finden Sie unter Unterstützte virtuelle Linux- und FreeBSD-Computer für Hyper-V unter Windows.

Angeben eines lokalen zuverlässigen Zeitdiensts mithilfe von GTIMESERV

Sie können einen oder mehrere DCs als exakte Quellenuhren angeben, indem Sie die GTIMESERV-Kennzeichen (guter Zeitserver) verwenden. Beispielsweise können bestimmte DCs, die mit GPS-Hardware ausgestattet sind, als GTIMESERV gekennzeichnet werden. Durch diese Kennzeichnung wird sichergestellt, dass Ihre Domäne auf eine Uhr basierend auf der GPS-Hardware verweist.

Hinweis

Weitere Informationen zu Domänenkennzeichnungen finden Sie in der MS-ADTS-Protokolldokumentation.

TIMESERV ist ein weiteres verwandtes Domänendienstekennzeichen, das anzeigt, ob ein Computer zurzeit autoritativ ist, was sich ändern kann, wenn ein DC die Verbindung verliert. Ein DC in diesem Zustand gibt Unknown Stratum zurück, wenn er über NTP abgefragt wird. Nach mehreren Versuchen protokolliert der DC das Systemereignis „Zeitdienstereignis 36“.

Wenn Sie einen DC als GTIMESERV konfigurieren möchten, können Sie ihn mithilfe des folgenden Befehls manuell konfigurieren. In diesem Fall verwendet der DC einen anderen Computer als Masteruhr. Bei diesem Computer kann es sich um ein Gerät oder einen dedizierten Computer handeln.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Hinweis

Weitere Informationen finden Sie unter Konfigurieren des Windows-Zeitdiensts.

Wenn auf dem DC die GPS-Hardware installiert ist, müssen Sie die folgenden Schritte ausführen, um den NTP-Client zu deaktivieren und den NTP-Server zu aktivieren.

Deaktivieren Sie zunächst den NTP-Client und aktivieren Sie den NTP-Server, indem Sie die folgenden Registrierungsschlüsseländerungen verwenden:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

Starten Sie als Nächstes den Windows-Zeitdienst erneut.

net stop w32time && net start w32time

Geben Sie zum Schluss an, dass dieser Computer eine zuverlässige Zeitquelle besitzt:

w32tm /config /reliable:yes /update

Um zu überprüfen, ob die Änderungen ordnungsgemäß durchgeführt wurden, können Sie die folgenden Befehle ausführen, die die hier gezeigten Ergebnisse liefern sollten:

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 auf virtuellen Drittanbieterplattformen

Wenn Windows virtualisiert ist, ist standardmäßig der Hypervisor für die Bereitstellung der Zeit verantwortlich. Der Domäne beigetretene Mitglieder müssen jedoch mit dem DC synchronisiert werden, damit Active Directory ordnungsgemäß funktioniert. Es empfiehlt sich, jegliche Zeitvirtualisierung zwischen dem Gast und dem Host jeglicher Drittanbieterplattform zu deaktivieren.

Ermitteln der Hierarchie

Da die Verkettung der Zeithierarchie mit der Masterzeitquelle in einer Domäne dynamisch ist und ausgehandelt wird, müssen Sie den Status eines bestimmten Computers abfragen, um seine Zeitquelle und die Verkettung mit der Masterquellenuhr zu verstehen. Diese Information kann bei der Diagnose von Zeitsynchronisierungsproblemen hilfreich sein.

Wenn Sie Probleme mit einem bestimmten Client behandeln möchten, besteht der erste Schritt darin, seine Zeitquelle zu verstehen. Verwenden Sie hierzu den w32tm-Befehl:

w32tm /query /status

Die Ergebnisse zeigen unter anderem die Quelle an. Die Quelle zeigt an, mit wem Sie die Zeit in der Domäne synchronisieren. Dies ist der erste Schritt in der Zeithierarchie dieses Computers. Verwenden Sie als Nächstes den zuvor genannten Quelleneintrag sowie den /stripchart-Parameter, um die nächste Zeitquelle in der Kette zu finden.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Was ebenfalls nützlich ist: Der folgende Befehl listet alle DCs auf, die in der angegebenen Domäne gefunden werden können, und gibt ein Ergebnis aus, mit dem Sie alle Partner bestimmen können. Dieser Befehl schließt Computer ein, die manuell konfiguriert wurden.

w32tm /monitor /domain:my_domain

Mithilfe der Liste können Sie die Ergebnisse durch die Domäne verfolgen und die Hierarchie sowie die Zeitdifferenz bei jedem Schritt verstehen. Indem du den Punkt auffindest, an dem die Zeitdifferenz signifikant schlechter wird, kannst du die Ursache für die fehlerhafte Zeit festmachen. Von dort aus können Sie versuchen herauszufinden, warum diese Zeit falsch ist, indem Sie die w32tm-Protokollierung aktivieren.

Verwenden von Gruppenrichtlinien

Sie können Gruppenrichtlinien verwenden, um eine höhere Genauigkeit zu erreichen, indem Sie beispielsweise Clients zur Verwendung bestimmter NTP-Server zuweisen oder steuern, wie Vorgängerversions-Betriebssysteme bei der Virtualisierung konfiguriert werden. Hier finden Sie eine Liste möglicher Szenarien und relevanter Gruppenrichtlinieneinstellungen:

Virtualisierte Domänen: Zum Steuern virtualisierter DCs in Windows 2012 R2, damit sie ihre Zeit mit ihrer Domäne synchronisieren, anstatt mit dem Hyper-V-Host. Du kannst diesen Registrierungseintrag deaktivieren. Für den PDC sollten Sie den Eintrag nicht deaktivieren, da der Hyper-V-Host die stabilste Zeitquelle bereitstellt. Der Registrierungseintrag erfordert, dass Sie W32Time neu starten, nachdem er geändert wurde.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Genauigkeitsabhängige Workloads: Für genauigkeitsabhängige Workloads können Sie Gruppen von Computern so konfigurieren, dass die NTP-Server und alle verwandten Zeiteinstellungen, z. B. Abruf- und Uhraktualisierungshäufigkeit, festgelegt werden. Dieser Task wird normalerweise von der Domäne gehandhabt. Um mehr Kontrolle zu erlangen, könnten Sie bestimmte Computer festlegen, die direkt auf die Masteruhr verweisen sollen.

Gruppenrichtlinieneinstellung	Neuer Wert
NtpServer	ClockMasterName, 0 x 8
MinPollInterval	6 bis 64 Sekunden
MaxPollInterval	6
UpdateInterval	100 – Einmal pro Sekunde
EventLogFlags	3 – Sämtliche spezifische Zeitprotokollierung

Hinweis

Die NtpServer- und EventLogFlags-Einstellungen befinden sich unter „System\Windows Time Service\Time Providers“ unter Verwendung der Einstellungen zum Konfigurieren des Windows-NTP-Clients. Die anderen 3 befinden sich unter „System\Windows Time Service“ unter Verwendung der Einstellungen für Globale Konfiguration.

Remote-Genauigkeitsabhängige Workloads: Für Systeme in verzweigten Domänen wie „Einzelhandel“ oder „Kreditunternehmen“ verwendet Windows die aktuellen Standortinformationen und den Domänencontroller-Locator, um einen lokalen DC zu finden, sofern keine manuelle NTP-Zeitquelle konfiguriert ist. Diese Umgebung erfordert eine Genauigkeit von 1 Sekunde, was die Konvergenz zur richtigen Zeit beschleunigt. Diese Option gestattet W32Time, die Uhr zurückzustellen. Wenn dieses Verhalten akzeptabel ist und Ihre Anforderungen erfüllt, können Sie die folgende Richtlinie erstellen. Stellen Sie wie bei jeder Umgebung sicher, dass Sie das Netzwerk testen und eine Baseline entwickeln.

Gruppenrichtlinieneinstellung	Neuer Wert
MaxAllowedPhaseOffset	1, jedoch wenn länger als eine Sekunde, dann stellen Sie die Uhr auf die richtige Zeit.

Die Einstellung MaxAllowedPhaseOffset befindet sich unter „System\Windows Time Service“ unter Verwendung der Einstellungen für Globale Konfiguration.

Hinweis

Weitere Informationen zu Gruppenrichtlinien und verwandten Einträgen finden Sie im TechNet-Artikel Windows-Zeitdiensttools und -einstellungen.

IaaS-Überlegungen für Azure und Windows

Im Folgenden sind einige Punkte aufgeführt, die Sie für die Azure- und Windows-Infrastruktur als Dienst (IaaS) berücksichtigen sollten.

Virtueller Azure-Computer: Active Directory-Domänendienste (AD DS)

Wenn die Azure-VM, auf der Active Directory Domain Services ausgeführt wird, Teil einer vorhandenen lokalen Active Directory-Gesamtstruktur ist, sollte TimeSync (VMIC) deaktiviert werden. Diese Aktion ermöglicht es allen DCs in der Gesamtstruktur (sowohl physischen als auch virtuellen), eine einzige Zeitsynchronisierungshierarchie zu verwenden. Weitere Informationen finden Sie unter Ausführen von Domänencontrollern in Hyper-V.

Virtueller Azure-Computer: Einer Domäne beigetretener Computer

Wenn Sie einen Computer hosten, der einer Domäne einer vorhandenen Active Directory-Gesamtstruktur (virtuell oder physisch) beigetreten ist, besteht die bewährte Methode darin, TimeSync für den Gast zu deaktivieren und sicherzustellen, dass W32Time für die Synchronisierung mit seinem DC konfiguriert ist, indem Sie die Zeit auf Type=NTP5 konfigurieren.

Virtueller Azure-Computer: Eigenständiger Arbeitsgruppencomputer

Wenn der virtuelle Azure-Computer keiner Domäne beigetreten und auch kein Domänencontroller ist, empfehlen wir Ihnen, die Standardzeitkonfiguration beizubehalten und die VM sich mit dem Host synchronisieren zu lassen.

Windows-Anwendung, die exakte Zeit erfordert

Hier sind einige Aktionen aufgeführt, die Sie ausführen können, wenn Ihre Windows-Anwendung die exakte Zeit erfordert.

Zeitstempel-API

Programme, die hinsichtlich UTC, nicht aber hinsichtlich der Zeitspanne, eine höchstmögliche Genauigkeit erfordern, sollten die GetSystemTimePreciseAsFileTime-API verwenden. Durch Verwendung dieser API wird sichergestellt, dass Ihre Anwendung die Systemzeit abruft, die vom Windows-Zeitdienst abhängig ist.

UDP-Leistung

Wenn Sie über eine Anwendung verfügen, die UDP-Kommunikation für Transaktionen verwendet, und es dabei wichtig ist, die Wartezeit zu minimieren, gibt es einige verwandte Registrierungseinträge, die Sie verwenden können, um einen Bereich von Ports zu konfigurieren, der von der Basisfilter-Engine ausgeschlossen wird. Durch diese Aktion wird die Wartezeit verbessert und der Durchsatz erhöht. Änderungen an der Registrierung sollten jedoch erfahrenen Administratoren vorbehalten sein. Diese Problemumgehung schließt Ports vom Schutz durch die Firewall aus. Weitere Informationen finden Sie weiter unten im Referenzartikel.

Für Windows Server 2012 und Windows Server 2008 müssen Sie zunächst einen Hotfix installieren. Weitere Informationen finden Sie unter Datagrammverlust beim Ausführen einer Multicastempfänger-Anwendung in Windows 8 und Windows Server 2012.

Aktualisieren von Netzwerktreibern

Einige Netzwerkhersteller verfügen über Treiberupdates, die die Leistung in Bezug auf Treiberwartezeiten und Pufferung von UDP-Paketen verbessern. Wenden Sie sich an Ihren Netzwerkhersteller, um zu ermitteln, ob Updates vorhanden sind, die beim UDP-Durchsatz helfen können.

Protokollierung zu Überwachungszwecken

Zur Einhaltung von Bestimmungen für die Zeitablaufverfolgung können Sie w32tm-Protokolle, Ereignisprotokolle und Systemmonitorinformationen manuell archivieren. Später können die archivierten Informationen verwendet werden, um die Compliance zu einem bestimmten Zeitpunkt in der Vergangenheit nachzuweisen. Die folgenden Faktoren werden verwendet, um die Genauigkeit anzuzeigen:

1. Uhrgenauigkeit mithilfe des Leistungsindikators Berechnete Zeitdifferenz. Dieser Indikator zeigt die Uhr innerhalb der gewünschten Genauigkeit an.
2. Die Uhrquelle sucht Peer Response from in den w32tm-Protokollen. Im Anschluss an den Meldungstext finden Sie die IP-Adresse oder VMIC, die die Zeitquelle sowie die nächste in der Kette der Referenzuhren zu validierende beschreibt.
3. Uhrenbedingungsstatus unter Verwendung der w32tm-Protokolle, um zu überprüfen, dass ClockDispl Discipline: \*SKEW\*TIME\* auftritt. Dieser Status zeigt an, dass w32tm zu dem Zeitpunkt aktiv ist.

Ereignisprotokollierung

Um eine ganzheitliche Übersicht zu erhalten, benötigen Sie auch Ereignisprotokollinformationen. Durch das Erfassen des Systemereignisprotokolls und Filtern nach „Time-Server“, „Microsoft-Windows-Kernel-Boot“ und „Microsoft-Windows-Kernel-General“ können Sie eventuell ermitteln, ob andere Einflüsse vorliegen, die die Zeit geändert haben, wie z. B. Drittanbieter. Diese Protokolle sind möglicherweise erforderlich, um externe Störungen auszuschließen. Eine Gruppenrichtlinie kann Einfluss darauf haben, welche Ereignisprotokolle in das Protokoll geschrieben werden. Weitere Informationen finden Sie im vorherigen Abschnitt Verwenden von Gruppenrichtlinien.

Debug-Protokollierung in W32Time

Um w32tm zu Überwachungszwecken zu aktivieren, aktiviert der folgende Befehl die Protokollierung, die die regelmäßigen Aktualisierungen der Uhr sowie die Quellenuhr anzeigt. Starte den Dienst neu, um die neue Protokollierung zu aktivieren.

Weitere Informationen finden Sie unter Aktivieren der Debug-Protokollierung im Windows-Zeitdienst.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Systemmonitor

Der Windows-Zeitdienst von Windows Server 2016 stellt Leistungsindikatoren zur Verfügung, die zum Erfassen der Protokollierungsdaten für die Überwachung verwendet werden können. Diese Indikatoren können lokal oder remote protokolliert werden. Sie können die Leistungsindikatoren Computerzeitdifferenz und Roundtripverzögerung aufzeichnen. Wie bei jedem Leistungsindikator können Sie diese remote überwachen und Benachrichtigungen mithilfe von System Center Operations Manager erstellen. Sie können beispielsweise eine Warnung verwenden, die Sie benachrichtigen wird, wenn die Zeitdifferenz von der gewünschten Genauigkeit abweicht. Weitere Informationen finden Sie im System Center Management Pack.

Beispiel für die Windows-Nachverfolgbarkeit

In w32tm-Protokolldateien solltest du zwei Informationen überprüfen. Die erste ist ein Hinweis darauf, dass die Protokolldatei zurzeit „Uhr festlegen“ aufweist. Dadurch wird nachgewiesen, dass Ihre Uhr zum strittigen Zeitpunkt vom Windows-Zeitdienst festgelegt wurde.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Entscheidend ist, dass Sie Meldungen mit dem Präfix ClockDispln Discipline, sehen, was den Beweis dafür liefert, dass W32Time mit Ihrer Systemuhr interagiert.

Als Nächstes müssen Sie im Protokoll die letzte Meldung vor dem strittigen Zeitpunkt finden, die den Quellcomputer angibt, der zurzeit als Referenzuhr verwendet wird. Bei dieser Information kann es sich um eine IP-Adresse, einen Computernamen oder den VMIC-Anbieter handeln. Sie alle deuten darauf hin, dass die Synchronisierung mit dem Host für Hyper-V stattfindet. Im folgenden Beispiel wird die IPv4-Adresse „10.197.216.105“ bereitgestellt:

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Nachdem Sie das erste System in der Referenzzeitkette überprüft haben, müssen Sie die Protokolldatei auf die Referenzzeitquelle untersuchen und dieselben Schritte wiederholen. Dieser Prozess dauert so lange, bis Sie zu einer physischen Uhr wie GPS oder einer bekannten Zeitquelle wie NIST gelangen. Wenn es sich bei der Referenzuhr um GPS-Hardware handelt, sind möglicherweise auch Protokolle des Herstellers erforderlich.

Überlegungen zu Netzwerken

Die NTP-Protokollalgorithmen sind von der Symmetrie deines Netzwerks abhängig. Wenn Sie die Anzahl der Netzwerkhops erhöhen, steigt die Wahrscheinlichkeit für eine Asymmetrie. Daher ist es schwierig, vorherzusagen, welche Arten von Genauigkeiten in Ihren spezifischen Umgebungen angezeigt werden.

Die Leistungsüberwachung und die neuen Windows-Zeitleistungsindikatoren in Windows Server 2016 können verwendet werden, um die Genauigkeit Ihrer Umgebungen zu bewerten und Baselines zu erstellen. Sie können auch eine Problembehandlung durchführen, um die aktuelle Differenz aller Computer in Ihrem Netzwerk zu ermitteln.

Es gibt zwei allgemeine Standards für die genaue Zeit für das Netzwerk:

• Precision Time Protocol - IEEE 1588 (PTP): PTP hat strengere Anforderungen an die Netzwerkinfrastruktur, kann aber häufig eine Submicrosekundengenauigkeit bereitstellen.
• Network Time Protocol – RFC 1305 (NTP):NTP funktioniert auf einer größeren Vielfalt von Netzwerken und Umgebungen, wodurch die Verwaltung vereinfacht wird.

Windows unterstützt für Computer, die keiner Domäne beigetreten sind, standardmäßig Simple NTP (RFC2030). Für Computer, die einer Domäne beigetreten sind, verwenden wir ein sicheres NTP namens MS-SNTP, das von der Domäne aushandelte geheime Schlüssel nutzt, die einen Verwaltungsvorteil gegenüber dem in RFC1305 und RFC5905 beschriebenen authentifizierten NTP bieten.

Sowohl einer Domäne beigetretene als auch nicht beigetretene Protokolle erfordern UDP-Port 123. Weitere Informationen zu den bewährten Methoden für NTP finden Sie im Network Time Protocol Best Current Practices IETF Draft.

Zuverlässige Hardwareuhr (RTC)

Windows nimmt nur dann eine schrittweise Anpassung der Uhr vor, wenn bestimmte Grenzen überschritten werden, und kontrolliert sonst eher die Uhr. Dies bedeutet, dass w32tm die Aktualisierungshäufigkeit der Uhr in regelmäßigen Abständen mit der Einstellung Aktualisierungshäufigkeit der Uhr anpasst, wofür der Standardwert bei Windows Server 2016 einmal pro Sekunde ist. Wenn die Uhr nachgeht, wird die Häufigkeit erhöht. Wenn sie vorgeht, wird die Häufigkeit verringert. Während der Zeiträume zwischen den Anpassungen der Aktualisierungshäufigkeit der Uhr übernimmt die Hardwareuhr die Kontrolle. Wenn ein Problem mit der Firmware oder der Hardwareuhr vorliegt, kann die Zeit auf dem Computer ungenauer werden.

Dieses Szenario ist ein weiterer Grund, warum Sie in Ihrer Umgebung Tests durchführen und Baselines einrichten müssen. Wenn sich der Leistungsindikator Berechnete Zeitdifferenz nicht bei der Genauigkeit stabilisiert, die Sie anstreben, sollten Sie überprüfen, ob Ihre Firmware auf dem neuesten Stand ist. Sie können außerdem testen, ob duplizierte Hardware dasselbe Problem reproduziert.

Problembehandlung im Zusammenhang mit der Zeitgenauigkeit und NTP

Sie können den Abschnitt Ermitteln der Hierarchie verwenden, um die Quelle der ungenauen Zeit zu ermitteln. Betrachten Sie die Zeitdifferenz und versuchen Sie herauszufinden, an welchem Punkt in der Hierarchie die Zeit am stärksten von ihrer NTP-Quelle abweicht. Sobald Sie die Hierarchie verstanden haben, sollten Sie analysieren, warum diese spezielle Zeitquelle keine genaue Zeit erhält.

Indem Sie sich auf das System mit der abweichenden Zeit konzentrieren, können Sie mithilfe der nachfolgend aufgeführten Tools weitere Informationen sammeln, um das Problem zu ermitteln und eine Lösung zu finden. Die UpstreamClockSource-Referenz ist die Uhr, die mithilfe von w32tm /config /status ermittelt wurde:

• Systemereignisprotokolle
• Aktivieren Sie die Protokollierung mittels w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• w32Time-Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Lokale Netzwerkablaufverfolgungen
• Leistungsindikatoren (vom lokalen Computer oder UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource, um die Wartezeit und die Anzahl der Hops zur Quelle zu ermitteln
• Tracert UpstreamClockSource

Problem	Symptome	Lösung
Die lokale TSC-Uhr ist nicht stabil.	Verwenden von Perfmon – Physischer Computer – Synchronisierungsuhr, stabile Uhr, doch dies tritt weiterhin alle 1 bis 2 Minuten von mehreren 100 µs auf.	Aktualisieren Sie die Firmware, oder überprüfen Sie, ob dasselbe Problem bei anderer Hardware vielleicht nicht auftritt.
Netzwerklatenz.	Das w32tm Stripchart zeigt eine RoundTripDelay von mehr als 10 ms an. Schwankungen bei der Verzögerung können zu Störungen in einer Größenordnung von der Hälfte der Roundtripzeit führen, beispielsweise eine Verzögerung, die nur in eine Richtung wirksam ist. UpstreamClockSource ist mehrere Hops, wie von PING angegeben. TTL sollte nahe bei 128 liegen. Verwende Tracert, um die Wartezeit bei jedem Hop zu ermitteln.	Suche eine näher liegende Uhrenquelle für die Zeit. Eine Lösung besteht darin, eine Quellenuhr im selben Segment zu installieren oder auf die geografisch näher liegende Quellenuhr manuell zu verweisen. Füge in einem Domänenszenario einen Computer mit der GTimeServ-Rolle hinzu.
Die NTP-Quelle kann nicht zuverlässig erreicht werden.	W32tm /stripchart gibt zeitweise „Zeitüberschreitung bei Anforderung“ zurück.	NTP-Quelle reagiert nicht.
NTP-Quelle reagiert nicht.	Überprüfen Sie die Perfmon-Leistungsindikatoren „Anzahl von Zeitquellen des NTP-Clients“, „Eingehende NTP-Serveranforderungen“ und „Ausgehende NTP-Serverantworten“ und legen Sie die Verwendung fest, indem Sie einen Vergleich mit den Baselines durchführen.	Bestimmen Sie mithilfe von Serverleistungsindikatoren, ob sich die Last in Bezug auf Ihre Baselines geändert hat. Liegen Netzwerküberlastungsprobleme vor?
Der Domänencontroller verwendet nicht die genaueste Uhr.	Änderungen in der Topologie oder kürzlich hinzugefügte Masterzeituhr.	w32tm /resync /rediscover
Clientuhren weisen Abweichungen auf.	„Zeitdienstereignis 36“ im Systemereignisprotokoll und/oder Text in der Protokolldatei besagt: Der Indikator „Anzahl von Zeitquellen des NTP-Clients“ wechselt von 1 auf 0.	Behandle Probleme der Upstreamquelle, und finde heraus, ob dort Leistungsprobleme auftreten.

Durchführen von Baselining für die Zeit

„Baselining“ ist wichtig, damit Sie zunächst die Leistung und Genauigkeit Ihres Netzwerks ermitteln und sie später bei auftretenden Problemen mit der Baseline vergleichen können. Sie sollten Baselines für den Stamm-PDC oder alle mit GTIMESRV markierten Computer einrichten. Außerdem empfehlen wir Ihnen, für den PDC in jeder Gesamtstruktur Baselines einzurichten. Wählen Sie schließlich alle kritischen DCs oder Computer aus, die interessante Merkmale aufweisen, wie z. B. Entfernung oder hohe Auslastung, und erstellen Sie Baselines für sie.

Es ist auch hilfreich, die Baseline von Windows Server 2016 mit der Baseline der Version 2012 R2 zu vergleichen. Sie verfügen jedoch nur über w32tm /stripchart als Tool, mit dem Sie einen Vergleich durchführen können, da Windows Server 2012 R2 keine Leistungsindikatoren aufweist. Sie sollten zwei Computer mit denselben Eigenschaften auswählen, oder einen Computer upgraden und die Ergebnisse nach dem Upgrade vergleichen. Der Nachtrag zu Windows-Zeitmessungen bietet weitere Informationen zum Ausführen detaillierter Vergleichsmessungen zwischen 2016 und 2012.

Sammeln Sie unter Verwendung aller W32time-Leistungsindikatoren mindestens eine Woche lang Daten. Durch diese Daten wird sichergestellt, dass Sie über ausreichend Referenzdaten verfügen, um die Netzwerkvariationen im zeitlichen Verlauf berücksichtigen zu können, und dass die Ausführung ausreicht, um eine zuverlässige Zeitgenauigkeit zu gewährleisten.

NTP-Serverredundanz

Für die manuelle Konfiguration von NTP-Servern, die für Computer verwendet wird, die keiner Domäne beigetreten sind oder für die der PDC verwendet wird, empfiehlt es sich, im Falle einer Nichtverfügbarkeit mehrere Server zu verwenden. Dies kann auch in einer besseren Genauigkeit resultieren, wenn davon ausgegangen wird, dass alle Quellen präzise und stabil sind. Wenn die Topologie jedoch nicht gut entworfen wurde, oder die Zeitquellen nicht stabil sind, könnte die resultierende Genauigkeit möglicherweise schlechter sein, weshalb Vorsicht geboten ist. Der Grenzwert für unterstützte Zeitserver, die W32Time manuell referenzieren kann, ist 10.

Schaltsekunden

Die Erdumdrehungsdauer schwankt im zeitlichen Verlauf, was durch klimatischen und geologische Ereignissen verursacht wird. In der Regel beläuft sich diese Schwankung alle zwei Jahre auf ungefähr eine Sekunde. Immer, wenn die Abweichung von der Atomuhrzeit zu groß wird, wird eine Korrektur von einer Sekunde (nach oben oder unten) durchgeführt, die als „Schaltsekunde“ bezeichnet wird. Diese Korrektur wird in einer solchen Weise durchgeführt, dass die Schwankung niemals höher ist als 0,9 Sekunden. Diese Korrektur wird sechs Monate vor der tatsächlichen Korrektur angekündigt. Vor Windows Server 2016 hat der Microsoft-Zeitdienst Schaltsekunden nicht berücksichtigt, sondern verließ sich darauf, dass diese Schwankung vom externen Zeitdienst berücksichtigt würde. Mit der zunehmenden Zeitgenauigkeit von Windows Server 2016 arbeitet Microsoft an einer geeigneteren Lösung für das Problem der Schaltsekunde.

Sicheres Zeitseeding

W32Time in Server 2016 bietet die Funktion für sicheres Zeitseeding. Diese Funktion bestimmt die ungefähre aktuelle Zeit von ausgehenden SSL-Verbindungen. Dieser Zeitwert wird verwendet, um die lokale Systemuhr zu überwachen und grobe Fehler zu korrigieren. Weitere Informationen zu dieser Funktion findest du in diesem Blogbeitrag. Bei Bereitstellungen mit zuverlässigen Zeitquellen und gut überwachten Computern, die eine Überwachung der Zeitdifferenzen einschließen, können Sie entscheiden, die Funktion für sicheres Zeitseeding nicht zu verwenden und sich stattdessen auf Ihre vorhandene Infrastruktur verlassen.

So deaktivieren Sie die Funktion:

1. Verwenden Sie Gruppenrichtlinien zum Verwalten der Funktion SecureTimeSeeding. Weitere Informationen finden Sie im entsprechenden Abschnitt zur Einstellung UtilizeSslTimeDataLearn: CSP-Richtlinie – ADMX_W32Time.

2. Alternativ können Sie den Registrierungswert manuell festlegen. Legen Sie den Konfigurationswert des Registers UtilizeSSLTimeData auf einem bestimmten Computer auf 0 fest.

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

3. Wenn Sie den Computer aus einem bestimmten Grund nicht sofort neu starten können, können Sie W32Time darüber benachrichtigen, dass die Konfiguration aktualisiert wurde. Dadurch wird die Zeitüberwachung und -erzwingung basierend auf den von SSL-Verbindungen gesammelten Zeitdaten beendet.

   W32tm.exe /config /update
   

4. Durch einen Neustart des Computers wird die Einstellung sofort wirksam und bewirkt ferner die Beendigung der Erfassung von Zeitdaten von SSL-Verbindungen. Letzteres ist lediglich mit einem geringen Aufwand verbunden und sollte die Leistung nicht beeinträchtigen.

5. Um diese Einstellung in einer ganzen Domäne anzuwenden, legen Sie den UtilizeSSLTimeData-Wert in der W32Time-Gruppenrichtlinieneinstellung auf 0 fest und veröffentlichen Sie diese Einstellung. Wenn die Einstellung von einem Gruppenrichtlinien-Client abgerufen wird, wird W32Time benachrichtigt und beendet die Zeitüberwachung und -erzwingung mithilfe von SSL-Zeitdaten. Die Erfassung von SSL-Zeitdaten wird bei jedem Neustart eines Computers beendet. Wenn Ihre Domäne über tragbare schlanke Laptops/Tablets und andere Geräte verfügt, sollten Sie diese Computer von dieser Richtlinienänderung ausschließen. Bei diesen Geräten kommt es manchmal zu einer Erschöpfung des Akkus und die Funktion für sicheres Zeitseeding muss ihre Zeit bootstrappen.