Verbeteringen in tijdnauwkeurigheid voor Windows Server 2016

Windows Server 2016 heeft de algoritmen verbeterd die worden gebruikt om de tijd te corrigeren en de lokale klok te synchroniseren met Coordinated Universal Time (UTC). Het Network Time Protocol (NTP) gebruikt vier waarden om de tijdsverschil te berekenen op basis van de tijdstempels van de clientaanvraag/-reactie en serveraanvraag/-reactie. Netwerken zijn echter luidruchtig en er kunnen pieken zijn in de gegevens van NTP vanwege netwerkcongestie en andere factoren die van invloed zijn op de netwerklatentie. Algoritmen van Windows Server 2016 middelen deze ruis uit door verschillende technieken te gebruiken, wat resulteert in een stabiele en nauwkeurige klok. De bron die we gebruiken voor nauwkeurige tijd verwijst ook naar een verbeterde API, wat ons een betere oplossing biedt. Met deze verbeteringen kunnen we de nauwkeurigheid van 1 ms met betrekking tot UTC in een domein bereiken.

Hyper-V

Windows Server 2016 heeft de Hyper-V TimeSync-service verbeterd. Verbeteringen omvatten nauwkeurigere initiële tijd op het starten van de virtuele machine (VM) of de herstel- en onderbrekingslatentiecorrectie voor voorbeelden die zijn verstrekt aan de Windows Time-service (W32Time). Door deze verbetering kunnen we binnen 10 μs van de host blijven met een wortelgemiddelde kwadraat van 50 μs, wat de variantie aangeeft, zelfs op een machine met 75% belasting. Zie Hyper-V architectuurvoor meer informatie.

Notitie

De belasting is gemaakt met behulp van de prime95-benchmark en een gebalanceerd profiel.

Het Stratum-niveau dat de host aan de gast rapporteert, is transparanter. Voorheen zou de host een vaste Stratum van 2 presenteren, ongeacht de nauwkeurigheid ervan. Met de wijzigingen in Windows Server 2016 rapporteert de host een Stratum 1 groter dan de host Stratum, wat resulteert in betere tijd voor virtuele gasten. De host Stratum wordt door W32Time bepaald via standaardmethoden op basis van de oorspronkelijke tijd. Windows Server 2016-gasten die lid zijn van een domein, zoeken de meest nauwkeurige klok op in plaats van standaard de host. Daarom raden we u aan de Hyper-V Time Provider--instelling handmatig uit te schakelen voor computers die deelnemen aan een domein in Windows Server 2012 R2 en eerder.

Controle

Prestatiemonitortellers zijn toegevoegd. Met deze tellers kunt u tijdnauwkeurigheid als referentie vaststellen, monitoren en problemen oplossen. De volgende tabel bevat de tellers.

To fully match the intended meaning, context is required to provide the correct Dutch translation.	Beschrijving
Berekende tijdsverschil	De absolute tijdverschil tussen de systeemklok en de gekozen tijdbron, zoals berekend door de W32Time-service in microseconden. Wanneer er een nieuwe geldige steekproef beschikbaar is, wordt de berekende tijd bijgewerkt met de tijdsverschil aangegeven door de steekproef. Deze tijd is de werkelijke tijdsverschil van de lokale klok. W32Time initieert klokcorrectie met behulp van deze offset en werkt de berekende tijd tussen steekproeven bij met de resterende tijdsverschil dat op de lokale klok moet worden toegepast. De nauwkeurigheid van de klok kan worden bijgehouden met behulp van deze prestatiemeter met een laag polling-interval (bijvoorbeeld 256 seconden of minder) en controleren of de tellerwaarde kleiner is dan de gewenste kloknauwkeurigheidslimiet.
Klokfrequentie aanpassen	De absolute klokfrequentie-aanpassing van de lokale systeemklok door W32Time in delen per miljard. Deze teller helpt bij het visualiseren van de acties die zijn uitgevoerd door W32Time.
NTP Rondreisvertraging	De meest recente roundtrip latency die de NTP-client heeft bij het ontvangen van een reactie van de server in microseconden. Deze vertraging is de tijd die is verstreken op de NTP-client tussen het verzenden van een aanvraag naar de NTP-server en het ontvangen van een geldig antwoord van de server. Deze teller helpt bij het karakteriseren van de vertragingen die door de NTP-client worden ervaren. Grotere of verschillende roundtrips kunnen ruis toevoegen aan NTP-tijdberekeningen, die op hun beurt de nauwkeurigheid van tijdsynchronisatie via NTP kunnen beïnvloeden.
Aantal NTP-clientbronnen	Het actieve aantal NTP-tijdbronnen dat door de NTP-client wordt gebruikt. Dit aantal is een telling van actieve, afzonderlijke IP-adressen van tijdservers die reageren op de aanvragen van deze client. Dit aantal kan groter of kleiner zijn dan de geconfigureerde peers, afhankelijk van de DNS-resolutie van peernamen en de huidige bereikbaarheid.
NTP-server inkomende aanvragen	Aantal aanvragen ontvangen door de NTP-server (aanvragen per seconde).
Uitgaande antwoorden van NTP-server	Aantal aanvragen beantwoord door NTP-server (antwoorden per seconde).

De eerste drie prestatiemeteritems zijn gericht op scenario's voor het oplossen van nauwkeurigheidsproblemen. Zie de sectie Problemen met tijdnauwkeurigheid en NTP- verderop in dit artikel voor meer informatie. De laatste drie tellers hebben betrekking op NTP-serverscenario's en zijn handig wanneer u de belasting bepaalt en een basislijn vaststelt voor uw huidige prestaties.

Configuratie-updates per omgeving

In de volgende tabel worden de wijzigingen in de standaardconfiguratie tussen Windows Server 2016 en eerdere versies voor elke rol beschreven. De instellingen voor Windows Server 2016 en Windows 10 Jubileumupdate (build 14393) zijn nu uniek. Daarom worden ze weergegeven als afzonderlijke kolommen.

Rol	Instelling	Windows Server 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
Zelfstandige/Nano Server
	Tijdserver	time.windows.com	NA	time.windows.com
	Pollingfrequentie	64 - 1024 seconden	NA	Eenmaal per week
	Frequentie van klokupdates	Eenmaal per seconde	NA	Eenmaal per uur
Zelfstandige cliënt
	Tijdserver	NA	time.windows.com	time.windows.com
	Polling-frequentie	NA	Eenmaal per dag	Eenmaal per week
	Frequentie van klokupdates	NA	Eenmaal per dag	Eenmaal per uur
Domeincontroller
	Tijdserver	PDC/GTIMESERV	NA	PDC/GTIMESERV
	Pollingfrequentie	64 -1024 seconden	NA	1.024 - 32.768 seconden
	Klokupdatefrequentie	Eenmaal per seconde	NA	Eenmaal per uur
Domeinlidserver
	Tijdserver	DC	NA	DC
	Pollingfrequentie	64 -1.024 seconden	NA	1.024 - 32.768 seconden
	Frequentie van klokupdates	Eenmaal per seconde	NA	Eenmaal per 5 minuten
Domeinlid-Client
	Tijdserver	NA	DC	DC
	Pollingfrequentie	NA	1.204 - 32.768 seconden	1.024 - 32.768 seconden
	Frequentie van klokupdates	NA	Eenmaal per 5 minuten	Eenmaal per 5 minuten
Hyper-V gast
	Tijdserver	Kiest de beste optie op basis van het stratum van de host en de tijdserver.	Kiest op basis van het stratum van de host en de tijdserver de beste optie.	Standaardinstellingen voor host
	Pollingfrequentie	Op basis van de bovenstaande rol	Op basis van de bovenstaande rol	Op basis van de bovenstaande rol
	Klokupdatefrequentie	Op basis van de bovenstaande rol	Op basis van de bovenstaande rol	Op basis van de bovenstaande rol

Notitie

Zie voor Linux in Hyper-V de sectie Linux toestaan om de Hyper-V hosttijd te gebruiken.

Impact van verhoogde polling- en klokupdatefrequentie

Om nauwkeurigere tijd te bieden, worden de standaardwaarden voor pollingfrequenties en klokupdates verhoogd, waardoor we kleine aanpassingen vaker kunnen aanbrengen. Deze wijziging veroorzaakt meer UDP-verkeer (User Datagram Protocol)/NTP. Deze pakketten zijn klein, dus er moet weinig of geen effect zijn via breedbandverbindingen. Het voordeel is dat de prestaties beter zouden moeten zijn op een grotere verscheidenheid aan hardware en omgevingen.

Voor apparaten met batterijsteun kan het verhogen van de pollingfrequentie problemen veroorzaken. Batterijapparaten slaan de tijd niet op terwijl ze zijn uitgeschakeld. Wanneer ze weer worden hervat, moeten ze mogelijk frequente correcties op de klok uitvoeren. Door de pollingfrequentie te verhogen, wordt de klok instabiel en kan ook meer vermogen worden gebruikt. U wordt aangeraden de standaardinstellingen van de client niet te wijzigen.

Domeincontrollers (DC's) moeten minimaal beïnvloed worden, zelfs met het versterkte effect van de toegenomen updates van NTP-clients in een Active Directory-domein. NTP heeft een veel kleiner resourceverbruik in vergelijking met andere protocollen en een marginaal effect. Het is waarschijnlijker dat u limieten bereikt voor andere domeinfunctionaliteit voordat u last krijgt van de verhoogde instellingen voor Windows Server 2016. Active Directory maakt gebruik van beveiligde NTP, die de tijd doorgaans minder nauwkeurig synchroniseert dan eenvoudige NTP. We hebben geverifieerd dat het kan worden opgeschaald naar clients die zich twee Stratum niveaus verwijderd bevinden van de primaire domeincontroller (PDC).

Als conservatief plan moet u 100 NTP-aanvragen per seconde per kern reserveren. Met een domein dat bestaat uit vier DC's met elk vier kernen, moet u bijvoorbeeld 1600 NTP-aanvragen per seconde kunnen verwerken. Als u 10.000 clients hebt geconfigureerd om de synchronisatietijd één keer per 64 seconden te synchroniseren en de aanvragen gelijkmatig in de loop van de tijd worden ontvangen, ziet u 10.000/64, of ongeveer 160 aanvragen/seconde, verspreid over alle DC's. Dit bedrag valt eenvoudig binnen onze 1600 NTP-aanvragen per seconde op basis van dit voorbeeld. Deze planningsaanbevelingen zijn conservatief en zijn grotendeels afhankelijk van uw netwerk, processorsnelheden en werkbelasting. Zoals altijd, stel een basislijn vast en test in uw omgevingen.

Als uw DC's worden uitgevoerd met een aanzienlijke CPU-belasting, groter dan 40%, voegt deze belasting vrijwel zeker ruis toe aan NTP-reacties en is dit van invloed op uw tijdnauwkeurigheid in uw domein. Nogmaals, u moet testen in uw omgeving om inzicht te hebben in de werkelijke resultaten.

Tijdsnauwkeurigheidsmetingen

Om de tijdnauwkeurigheid voor Windows Server 2016 te meten, hebben we verschillende hulpprogramma's, methoden en omgevingen gebruikt. U kunt deze technieken gebruiken om uw omgeving te meten en af te stemmen en te bepalen of de nauwkeurigheidsresultaten aan uw vereisten voldoen.

Methodologie

Onze domein bron klok bestond uit twee hoge precisie NTP servers met GPS hardware. We gebruikten ook een afzonderlijke referentietestmachine voor metingen, die ook een hoge precisie GPS-hardware van een andere fabrikant had geïnstalleerd. Voor sommige tests hebt u een nauwkeurige en betrouwbare klokbron nodig om te gebruiken als verwijzing naast de bron van de domeinklok.

We hebben vier verschillende methoden gebruikt om nauwkeurigheid te meten met zowel fysieke als virtuele machines. Meerdere methoden bieden onafhankelijke middelen om de resultaten te valideren.

1. Meet de lokale klok, die wordt geconditioneerd door w32tm, tegen onze referentietestmachine, die afzonderlijke GPS-hardware heeft.

2. Meet NTP pings van de NTP-server naar clients met behulp van de W32tm stripchart.

3. Meet NTP pings van de client naar de NTP-server met behulp van de W32tm stripchart.

4. Meet Hyper-V resultaten van de host naar de gast met behulp van de TSC (Time Stamp Counter). Deze teller wordt gedeeld tussen beide partities en de systeemtijd in beide partities. We hebben het verschil berekend van de hosttijd en de clienttijd in de VIRTUELE machine. Vervolgens hebben we de TSC-klok gebruikt om de hosttijd van de gast te interpoleren omdat de metingen niet tegelijkertijd plaatsvinden. Daarnaast hebben we de tijdgesegmenteerde volumeklok gebruikt om vertragingen en latentie in de API te compenseren.

W32tm is ingebouwd, maar de andere hulpprogramma's die we tijdens onze tests hebben gebruikt, zijn beschikbaar voor de Microsoft-opslagplaats op GitHub als open source voor uw tests en gebruik. Zie voor meer informatie over het gebruik van de tools voor het uitvoeren van metingen de Wiki-pagina Windows Time Calibration Tools.

De weergegeven testresultaten zijn een subset van metingen die we hebben gemaakt in een van de testomgevingen. Ze illustreren de nauwkeurigheid die aan het begin van de tijdhiërarchie wordt gehandhaafd en de subdomeinklant aan het einde van de tijdhiërarchie. Deze resultaten worden vergeleken met dezelfde machines in een topologie op basis van 2012 voor vergelijking.

Topologie

Ter vergelijking hebben we topologieën getest op basis van Windows Server 2012 R2 en Windows Server 2016. Beide topologieën bestaan uit twee fysieke Hyper-V hostmachines die verwijzen naar een Windows Server 2016-computer waarop GPS klok hardware is geïnstalleerd. Elke host draait drie Windows-gasten die lid zijn van een domein en zijn gerangschikt volgens de volgende topologie. De regels vertegenwoordigen de tijdhiërarchie en het protocol/transport dat wordt gebruikt.

Overzicht van grafische resultaten

De volgende twee grafieken vertegenwoordigen de tijdnauwkeurigheid voor twee specifieke leden in een domein op basis van de voorgaande topologie. In elke grafiek worden zowel de resultaten van Windows Server 2012 R2 als 2016 weergegeven, waarin de verbeteringen visueel worden gedemonstreerd. De nauwkeurigheid is gemeten vanuit de gastcomputer in vergelijking met de host. De grafische gegevens vertegenwoordigen een subset van de volledige set tests die we hebben uitgevoerd en toont de beste en slechtste scenario's.

Prestaties van het hoofddomein PDC

De hoofd-PDC wordt gesynchroniseerd met de Hyper-V host (met behulp van VMIC), een Windows Server 2016 met GPS-hardware die zowel nauwkeurig als stabiel is. Deze vereiste is essentieel voor nauwkeurigheid van 1 ms, die wordt weergegeven als het gearceerde gebied dat wordt geïdentificeerd door het bijschrift.

Prestaties van de child domein client

De onderliggende domeinclient is gekoppeld aan een onderliggend domein PDC dat communiceert met de hoofd-PDC. De tijd is ook binnen de vereiste van 1 ms.

Langeafstandstest

In de volgende grafiek wordt één virtuele netwerkhop vergeleken met zes fysieke netwerkhops met Windows Server 2016. Twee grafieken zijn met transparantie over elkaar gelegd om overlappende gegevens weer te geven. Het verhogen van netwerkhops betekent hogere latentie en grotere tijddeviaties. De grafiek wordt vergroot, dus de grenzen van 1 ms, vertegenwoordigd door het gearceerde gebied, zijn groter. Zoals u kunt zien, is de tijd nog steeds binnen 1 ms met meerdere hops. Het is negatief verschoven, wat een netwerkasymmetrie aantoont. Elk netwerk is verschillend en metingen zijn afhankelijk van veel omgevingsfactoren.

Aanbevolen procedures voor nauwkeurige tijdsregistratie

Volg deze aanbevolen procedures voor nauwkeurige tijdregistratie.

Solide bronklok

De tijd van een machine is slechts zo goed als de bronklok waarmee deze wordt gesynchroniseerd. Voor een nauwkeurigheid van 1 ms hebt u GPS-hardware of een tijdapparaat in uw netwerk nodig waarnaar u verwijst als de hoofdbronklok. Het gebruik van de standaardwaarde van time.windows.com biedt mogelijk geen stabiele en lokale tijdbron. Naarmate u verder weg bent van de bronklok, is het netwerk van invloed op de nauwkeurigheid. Het hebben van een hoofdbronklok in elk datacenter is vereist voor de beste nauwkeurigheid.

Gps-opties voor hardware

Verschillende hardwareoplossingen kunnen nauwkeurige tijd bieden. In het algemeen zijn oplossingen tegenwoordig gebaseerd op GPS-antennes. Radio- en inbelmodemoplossingen maken gebruik van speciale lijnen. Ze worden als apparaat aan uw netwerk gekoppeld of aangesloten op een pc, bijvoorbeeld Windows via een PCIe- of USB-apparaat. Verschillende opties bieden verschillende nauwkeurigheidsniveaus en zoals altijd zijn de resultaten afhankelijk van uw omgeving. Variabelen die van invloed zijn op nauwkeurigheid zijn gps-beschikbaarheid, netwerkstabiliteit en belasting en pc-hardware. Deze factoren zijn allemaal belangrijk wanneer u een bronklok kiest, wat een vereiste is voor stabiele en nauwkeurige tijd.

Domein en synchronisatietijd

Domeinleden gebruiken de domeinhiërarchie om te bepalen welke computer ze als bron gebruiken om de tijd te synchroniseren. Elk domeinlid vindt een andere computer om mee te synchroniseren en slaat deze op als de klokbron. Elk type domeinlid volgt een andere set regels om een klokbron voor tijdsynchronisatie te vinden. De PDC in de hoofdmap van het forest is de standaardklokbron voor alle domeinen. Hier vindt u verschillende rollen en beschrijvingen op hoog niveau voor de manier waarop ze een bron vinden:

• domeincontroller met PDC-rol: deze computer is de gezaghebbende tijdbron voor een domein. Het heeft de meest nauwkeurige tijd beschikbaar in het domein. Deze moet worden gesynchroniseerd met een domeincontroller in het bovenliggende domein, behalve in gevallen waarin de rol GTIMESERV is ingeschakeld.
• Alle andere domeincontrollers: deze computer fungeert als tijdbron voor clients en lidservers in het domein. Een domeincontroller kan synchroniseren met de PDC van het eigen domein of een DC in het bovenliggende domein.
• clients/lidserver: Deze computer kan worden gesynchroniseerd met elke DC of PDC van zijn eigen domein of een DC of PDC in het bovenliggende domein.

Op basis van de beschikbare kandidaten wordt een scoresysteem gebruikt om de beste tijdbron te vinden. Dit systeem houdt rekening met de betrouwbaarheid van de tijdbron en de relatieve locatie. Deze controle vindt eenmaal plaats wanneer de tijdservice wordt gestart. Als u meer controle wilt hebben over de synchronisatie van tijd, kunt u goede tijdservers toevoegen op specifieke locaties of redundantie toevoegen. Zie de sectie Een lokale betrouwbare tijdservice opgeven met behulp van GTIMESERVvoor meer informatie.

Omgevingen met gemengde besturingssystemen (Windows Server 2012 R2 en Windows Server 2008 R2)

Hoewel een pure Windows Server 2016-domeinomgeving vereist is voor de beste nauwkeurigheid, zijn er nog steeds voordelen in een gemengde omgeving. Het implementeren van Windows Server 2016 Hyper-V in een Windows Server 2012-domein profiteert de gasten vanwege de verbeteringen die we hebben genoemd, maar alleen als de gasten zich ook op Windows Server 2016 bevinden. Een WINDOWS Server 2016 PDC kan nauwkeuriger tijd leveren vanwege de verbeterde algoritmen, dus het is een stabielere bron. Omdat het vervangen van uw PDC mogelijk geen optie is, kunt u in plaats daarvan een Windows Server 2016 DC toevoegen aan de GTIMESERV-rollet, wat een upgrade in nauwkeurigheid voor uw domein zou zijn. Een Windows Server 2016 DC kan betere tijd leveren aan downstream tijdcliënten, maar het is slechts zo betrouwbaar als de NTP-tijdbron.

Zoals eerder vermeld, zijn de klok polling- en vernieuwingsfrequenties aangepast in Windows Server 2016. Deze frequenties kunnen handmatig worden gewijzigd in uw dc's op lager niveau of worden toegepast via Groepsbeleid. We hebben deze configuraties niet getest, maar ze moeten zich goed gedragen in Windows Server 2008 R2 en Windows Server 2012 R2 en bieden enkele voordelen.

Versies voorafgaand aan Windows Server 2016 kenden meerdere problemen met precieze tijdsynchronisatie, wat ertoe leidde dat de systeemtijd onmiddellijk na een aanpassing verschoof. Vanwege dit probleem leidt het vaak verkrijgen van tijdsmonsters van een nauwkeurige NTP-bron en het conditioneren van de lokale klok met de gegevens tot een kleinere drift in hun systeemklokken in de intra-samplingperiode. Het resultaat is een betere tijdsregistratie voor versies van het besturingssysteem op lager niveau. De best waargenomen nauwkeurigheid was ongeveer 5 ms toen een Windows Server 2012 R2 NTP-client, geconfigureerd met de instellingen voor hoge nauwkeurigheid, de tijd synchroniseerde vanaf een nauwkeurige Windows Server 2016 NTP-server.

In sommige scenario's met betrekking tot gast-DC's kan Hyper-V TimeSync-voorbeelden domeintijdsynchronisatie verstoren. Dit probleem mag niet meer bestaan voor gasten van Windows Server 2016 die worden uitgevoerd op Windows Server 2016 Hyper-V hosts.

Als u de Hyper-V TimeSync-service wilt uitschakelen voor het leveren van voorbeelden aan W32Time, stelt u de volgende sleutel voor het gastregister in:

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

Toestaan dat Linux Hyper-V hosttijd gebruikt

Voor Linux-gasten die draaien op Hyper-V, worden clienten doorgaans geconfigureerd om de NTP-daemon te gebruiken voor tijdsynchronisatie met NTP-servers. Als de Linux-distributie het TimeSync versie 4-protocol ondersteunt en de Linux-gast de TimeSync-integratieservice heeft ingeschakeld, wordt deze gesynchroniseerd met de hosttijd. Dit scenario kan leiden tot inconsistente tijdsregistratie als beide methoden zijn ingeschakeld.

Als u exclusief wilt synchroniseren met de hosttijd, raden we u aan om NTP-tijdsynchronisatie uit te schakelen met een van de twee methoden:

• Schakel NTP-servers uit in het ntp.conf-bestand.
• Schakel de NTP-daemon uit.

In deze configuratie is de parameter "Time Server" deze host. De polling-frequentie is 5 seconden en de klokupdate-frequentie is ook 5 seconden.

Als u exclusief wilt synchroniseren via NTP, raden we u aan om de TimeSync-integratieservice in de gast uit te schakelen.

Notitie

Ondersteuning voor nauwkeurige tijd met Linux-gasten vereist een functie die alleen wordt ondersteund in de nieuwste upstream Linux-kernels. De functie is nog niet algemeen beschikbaar in alle Linux-distributies. Zie Ondersteunde Virtuele Linux- en FreeBSD-machines voor Hyper-V op Windowsvoor meer informatie over ondersteuningsdistributies.

Een lokale betrouwbare tijdservice opgeven met behulp van GTIMESERV

U kunt een of meer DC's opgeven als nauwkeurige bronklokken met behulp van de vlag GTIMESERV van Good Time Server. Zo kunnen specifieke DC's met GPS-hardware worden gemarkeerd als GTIMESERV. Deze vlag zorgt ervoor dat uw domein verwijst naar een klok op basis van de GPS-hardware.

Notitie

Zie de MS-ADTS protocoldocumentatievoor meer informatie over domeinvlagmen.

TIMESERV is een andere gerelateerde Domain Services-vlag die aangeeft of een computer momenteel gezaghebbend is, wat kan veranderen als een DC-verbinding verliest. Een domeincontroller met deze status retourneert Unknown Stratum wanneer er een query wordt uitgevoerd via NTP. Nadat u het meerdere keren hebt geprobeerd, registreert de DC System Event Time-Service Event 36.

Als u een DC wilt configureren als GTIMESERV, configureert u deze handmatig met behulp van de volgende opdracht. In dit geval gebruikt de DC een andere machine als de hoofdklok. Deze machine kan een apparaat of toegewezen machine zijn.

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

Notitie

Zie De Windows Time-service configureren voor meer informatie

Als op de DC de GPS-hardware is geïnstalleerd, gebruikt u de volgende stappen om de NTP-client uit te schakelen en de NTP-server in te schakelen.

Schakel eerst de NTP-client uit en schakel de NTP-server in met behulp van deze registersleutelwijzigingen:

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

Start vervolgens de Windows Time-service opnieuw op:

net stop w32time && net start w32time

Ten slotte geeft u aan dat deze machine een betrouwbare tijdbron heeft:

w32tm /config /reliable:yes /update

Als u wilt controleren of de wijzigingen correct zijn uitgevoerd, voert u de volgende opdrachten uit, die van invloed zijn op de resultaten die hier worden weergegeven:

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 op virtuele platforms van derden

Wanneer Windows wordt gevirtualiseerd, is de Hypervisor standaard verantwoordelijk voor het leveren van tijd. Maar leden die lid zijn van een domein moeten worden gesynchroniseerd met de domeincontroller voor Active Directory om goed te kunnen werken. U kunt het beste op elk gewenst moment virtualisatie uitschakelen tussen de gast en de host van virtuele platforms van derden.

De hiërarchie ontdekken

Omdat de keten van tijdhiërarchie naar de bronklok van de master dynamisch en onderhandelbaar is in een domein, moet u de status van een bepaalde machine controleren om de tijdbron en keten naar de bronklok van de master te begrijpen. Deze informatie kan helpen bij het vaststellen van problemen met tijdsynchronisatie.

Als u problemen met een specifieke client wilt oplossen, is de eerste stap het begrijpen van de tijdbron met behulp van deze w32tm opdracht:

w32tm /query /status

In de resultaten wordt onder andere de bron weergegeven. De bron geeft aan met wie u tijd synchroniseert in het domein. Dit is de eerste stap van de tijdhiërarchie van deze machine. Gebruik vervolgens de bronvermelding uit de voorgaande opdracht en gebruik de parameter /stripchart om de volgende keer bron in de keten te vinden.

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

Ook nuttig, de volgende opdracht geeft een lijst van elke domeincontroller die in het opgegeven domein kan worden gevonden en geeft een resultaat weer waarmee u elke partner kunt identificeren. Deze opdracht bevat machines die handmatig zijn geconfigureerd.

w32tm /monitor /domain:my_domain

Met behulp van de lijst kunt u de resultaten traceren via het domein en inzicht in de hiërarchie en de tijdverschil bij elke stap. Door het punt te vinden waar de tijdverschuiving aanzienlijk slechter wordt, kunt u de oorzaak van de onjuiste tijd aanwijzen. Van daaruit kunt u proberen te begrijpen waarom die tijd onjuist is door w32tm logboekregistratie in te schakelen.

Groepsbeleid gebruiken

U kunt Groepsbeleid gebruiken om strengere nauwkeurigheid te bereiken door bijvoorbeeld clients toe te wijzen om specifieke NTP-servers te gebruiken of om te bepalen hoe downlevel besturingssystemen worden geconfigureerd wanneer gevirtualiseerd. Hier volgt een lijst met mogelijke scenario's en relevante groepsbeleidsinstellingen:

Gevirtualiseerde domeinen: als u gevirtualiseerde DC's in Windows Server 2012 R2 wilt beheren zodat ze tijd synchroniseren met hun domein, in plaats van met de Hyper-V host, kunt u deze registervermelding uitschakelen. Voor de PDC wilt u de invoer niet uitschakelen omdat de Hyper-V host de meest stabiele tijdbron biedt. Voor de registervermelding moet u W32Time opnieuw starten nadat deze is gewijzigd.

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

Nauwkeurigheid gevoelige belastingen: voor tijdnauwkeurigheid gevoelige werkbelastingen kunt u groepen computers configureren om de NTP-servers en eventuele gerelateerde tijdinstellingen in te stellen, zoals polling en klokupdatefrequentie. Deze taak wordt normaal gesproken verwerkt door het domein, maar voor meer controle kunt u specifieke computers richten om rechtstreeks naar de hoofdklok te verwijzen.

Groepsbeleidsinstelling	Nieuwe waarde
NtpServer	ClockMasterName,0x8
MinPollInterval	6 – 64 seconden
MaxPollInterval	6
UpdateInterval	100 – Eenmaal per seconde
EventLogFlags	3 – Alle speciale tijdregistratie

Notitie

De instellingen voor NtpServer en EventLogFlags bevinden zich onder System\Windows Time Service\Time Providers via de Windows NTP-client configureren-instellingen. De andere drie bevinden zich onder System\Windows Time Service met behulp van de globale configuratie instellingen.

Afstandsgevoelige belasting voor nauwkeurigheid: Voor systemen in wijkdomeinen, bijvoorbeeld Retail en de Betalingskrediet Industrie (PCI), gebruikt Windows de huidige site-informatie en de DC Locator om een lokale DC te vinden, tenzij er een handmatige NTP-tijdbron is geconfigureerd. Voor deze omgeving is 1 seconde nauwkeurigheid vereist, die snellere convergentie naar de juiste tijd gebruikt. Met deze optie kan W32Time de klok naar achteren verplaatsen. Als dit gedrag acceptabel is en aan uw vereisten voldoet, kunt u het volgende beleid maken. Zorg ervoor dat u, net als bij elke omgeving, uw netwerk test en een referentielijn vaststelt.

Groepsbeleidsinstelling	Nieuwe waarde
MaxAllowedPhaseOffset	1, maar als het meer dan één seconde is, stel de klok in op de juiste tijd.

De MaxAllowedPhaseOffset-instelling bevindt zich onder System\Windows Time Service met behulp van de algemene configuratie--instellingen.

Notitie

Zie Windows Time-servicehulpprogramma's en het artikel Instellingen op TechNet voor meer informatie over Groepsbeleid en verwante vermeldingen.

Overwegingen voor Azure en Windows IaaS

Hier volgen enkele punten die u moet overwegen voor Azure en Windows Infrastructure as a Service (IaaS).

Virtuele Azure-machine: Active Directory Domain Services

Als de Azure-VM met Active Directory Domain Services deel uitmaakt van een bestaand on-premises Active Directory-forest, moet TimeSync (VMIC) worden uitgeschakeld. Met deze actie kunnen alle DC's in het forest, zowel fysiek als virtueel, één tijdsynchronisatiehiërarchie gebruiken. Voor meer informatie, zie Draaien van domeincontrollers in Hyper-V.

Virtuele Azure-machine: aan een domein gekoppelde machine

Als u een computer host die lid is van een domein dat is toegevoegd aan een bestaand Active Directory-forest, virtueel of fysiek, is het raadzaam TimeSync voor de gast uit te schakelen en ervoor te zorgen dat W32Time is geconfigureerd om te synchroniseren met de domeincontroller via de configuratietijd voor Type=NTP5.

Virtuele Azure-machine: zelfstandige werkgroepmachine

Als de Virtuele Azure-machine niet is gekoppeld aan een domein en dit geen DC is, raden we u aan de standaardtijdconfiguratie te behouden en de VM te laten synchroniseren met de host.

Windows-toepassing vereist nauwkeurige tijd

Hier volgen enkele acties die u kunt uitvoeren als uw Windows-toepassing nauwkeurige tijd nodig heeft.

Tijdstempel-API

Programma's waarvoor de grootste nauwkeurigheid is vereist ten opzichte van UTC en niet het verstrijken van de tijd, moeten de GetSystemTimePreciseAsFileTime-APIgebruiken. Door deze API te gebruiken, zorgt u ervoor dat uw toepassing systeemtijd krijgt, die wordt geconditioneerd door de Windows Time-service.

Prestaties van UDP

Als u een toepassing hebt die gebruikmaakt van UDP-communicatie voor transacties en het is belangrijk om latentie te minimaliseren, zijn er enkele gerelateerde registervermeldingen die u kunt gebruiken om een reeks poorten te configureren die moeten worden uitgesloten van de poortbasisfilteringsengine. Deze actie verbetert zowel de latentie als verhoogt de doorvoer. Wijzigingen in het register moeten echter worden beperkt tot ervaren beheerders. Met deze tijdelijke oplossing worden poorten uitgesloten van beveiliging door de firewall. Raadpleeg de volgende referentie voor meer informatie.

Voor Windows Server 2012 en Windows Server 2008 moet u eerst een hotfix installeren. Zie Datagram-verlies wanneer u een multicastontvangertoepassing uitvoert in Windows 8 en in Windows Server 2012voor meer informatie.

Netwerkstuurprogramma's bijwerken

Sommige netwerkleveranciers hebben stuurprogramma-updates die de prestaties verbeteren ten opzichte van de latentie van stuurprogramma's en het bufferen van UDP-pakketten. Neem contact op met uw netwerkleverancier om te zien of er updates zijn om u te helpen met UDP-doorvoer.

Logboekregistratie voor controledoeleinden

Als u wilt voldoen aan de regelgeving voor tijdtracering, kunt u handmatig w32tm logboeken, gebeurtenislogboeken en prestatiemetergegevens archiveren. Later kunnen de gearchiveerde gegevens worden gebruikt om naleving te bevestigen op een bepaald tijdstip in het verleden. De volgende factoren worden gebruikt om de nauwkeurigheid aan te geven:

1. Gebruik de kloknauwkeurigheid door middel van de berekende tijdoffset met de prestatiemonitorteller. Deze teller toont de klok binnen de gewenste nauwkeurigheid.
2. Klokbron die zoekt naar Peer Response from in de w32tm logboeken. Na de berichttekst staan het IP-adres of de VMIC, die de tijdbron en de volgende klok in de keten van referentieklokken beschrijven die gevalideerd moeten worden.
3. Controleer de klokstatus door gebruik te maken van de w32tm logboeken om na te gaan of ClockDispl Discipline: \*SKEW\*TIME\* optreedt. Deze status geeft aan dat w32tm actief is op het moment.

Gebeurtenisregistratie

Voor het volledige verhaal hebt u ook informatie over gebeurtenislogboeken nodig. Door het systeemgebeurtenislogboek te verzamelen en filteren op Time-Server, Microsoft-Windows-Kernel-Boot en Microsoft-Windows-Kernel-General, kunt u mogelijk detecteren of andere invloeden de tijd hebben gewijzigd, bijvoorbeeld derden. Deze logboeken kunnen nodig zijn om externe interferentie uit te sluiten. Groepsbeleid kan van invloed zijn op welke gebeurtenislogboeken naar het logboek worden geschreven. Zie de voorgaande sectie Groepsbeleid gebruikenvoor meer informatie.

W32Time-foutopsporingslogboek

Als u w32tm wilt inschakelen voor controledoeleinden, schakelt de volgende opdracht logboekregistratie in die de periodieke updates van de klok weergeeft en de bronklok aangeeft. Start de service opnieuw om de nieuwe logboekregistratie in te schakelen.

Zie Foutopsporingslogboeken inschakelen in de Windows Time-servicevoor meer informatie.

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

Prestatiemeter

De Windows Server 2016 Windows Time-service maakt prestatiemeteritems beschikbaar, die kunnen worden gebruikt voor het verzamelen van logboekregistratie voor controle. Deze tellers kunnen lokaal of extern worden geregistreerd. U kunt de tellers computertijdverschil en retourvertraging opnemen. Net als elke prestatiemeteritem kunt u ze op afstand bewaken en waarschuwingen maken met Behulp van System Center Operations Manager. U kunt bijvoorbeeld een waarschuwing gebruiken om u te waarschuwen wanneer de tijdsverschil afdrijdt van de gewenste nauwkeurigheid. Zie het System Center Management Packvoor meer informatie.

Voorbeeld van tracering van Windows

Vanuit w32tm logboekbestanden wilt u twee stukjes informatie valideren. De eerste is een indicatie dat het logboekbestand momenteel een voorwaardeklok is. Deze indicatie bewijst dat uw klok wordt geconditioneerd door de Windows Time-service op het betwiste tijdstip.

 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

Het belangrijkste punt is dat u berichten ziet die zijn voorafgegaan door ClockDispln Discipline, wat bewijs is dat W32Time interactie heeft met uw systeemklok.

Vervolgens moet u het laatste rapport in het logboek vinden voor de betwiste tijd die de broncomputer rapporteert, die momenteel wordt gebruikt als referentieklok. Deze informatie kan een IP-adres, computernaam of de VMIC-provider zijn, die aangeeft dat deze wordt gesynchroniseerd met de host voor Hyper-V. In het volgende voorbeeld ziet u een IPv4-adres van 10.197.216.105:

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

Nu u het eerste systeem in de referentietijdketen hebt gevalideerd, moet u het logboekbestand op de referentietijdbron onderzoeken en dezelfde stappen herhalen. Dit proces gaat door totdat u bij een fysieke klok komt, zoals GPS of een bekende tijdbron, zoals NIST. Als de referentieklok GPS-hardware is, kunnen logboeken van de fabrikant ook vereist zijn.

Netwerkoverwegingen

De NTP-protocolalgoritmen hebben een afhankelijkheid van de symmetrie van uw netwerk. Naarmate u het aantal netwerkhops verhoogt, neemt de kans op asymmetrie toe. Daarom is het moeilijk om te voorspellen welke typen nauwkeurigheid u in uw specifieke omgevingen ziet.

Prestatiemeter en de nieuwe Windows Time-tellers in Windows Server 2016 kunnen worden gebruikt om de nauwkeurigheid van uw omgeving te beoordelen en basislijnen te maken. U kunt ook probleemoplossing uitvoeren om de huidige offset van elke computer in uw netwerk te bepalen.

Er zijn twee algemene standaarden voor nauwkeurige tijd via het netwerk:

• Precision Time Protocol - IEEE 1588(PTP): PTP heeft strengere vereisten voor de netwerkinfrastructuur, maar kan vaak een nauwkeurigheid van submicroseconden bieden.
• Network Time Protocol – RFC 1305(NTP): NTP werkt op een grotere verscheidenheid aan netwerken en omgevingen, waardoor het eenvoudiger te beheren is.

Windows ondersteunt standaard eenvoudige NTP (RFC2030) voor niet-gekoppelde computers. Voor computers die lid zijn van een domein, gebruiken we een beveiligde NTP genaamd MS-SNTP, die gebruikmaakt van door een domein onderhandelde geheimen die een beheervoordeel bieden ten opzichte van geverifieerde NTP die wordt beschreven in RFC1305 en RFC5905.

Voor zowel de domein- als niet-domein-gekoppelde protocollen is UDP-poort 123 vereist. Zie Network Time Protocol Best Practices IETF Draftvoor meer informatie over best practices voor NTP.

Betrouwbare hardwareklok (RTC)

Windows voert geen tijdsaanpassingen uit, tenzij bepaalde grenzen worden overschreden, maar corrigeert in plaats daarvan de klok. Dat betekent dat w32tm de frequentie van de klok met een regelmatig interval aanpast met behulp van de instelling Klokupdatefrequentie, die standaard één keer per seconde met Windows Server 2016 wordt ingesteld. Als de klok achterloopt, versnelt het de frequentie. Als het vooruit is, wordt de frequentie vertraagd. Tijdens de tijd tussen klokfrequentieaanpassingen is de hardwareklok echter in controle. Als er een probleem is met de firmware of de hardwareklok, kan de tijd op de machine minder nauwkeurig worden.

Dit scenario is een andere reden waarom u een test en basislijn in uw omgeving moet uitvoeren. Als de berekende tijdcompensatie prestatiemeter niet stabiliseert met de nauwkeurigheid die u nastreeft, wilt u mogelijk controleren of uw firmware up-to-date is. Als een andere test kunt u zien of dubbele hardware hetzelfde probleem reproduceert.

Problemen met tijdnauwkeurigheid en NTP oplossen

U kunt de sectie De hiërarchie ontdekken gebruiken om de bron van de onnauwkeurige tijd te begrijpen. Kijkend naar het tijdsverschil, vindt u het punt in de hiërarchie waar de tijd het meest afwijkt van zijn NTP-bron. Wanneer u de hiërarchie begrijpt, wilt u proberen te begrijpen waarom die specifieke tijdbron geen nauwkeurige tijd ontvangt.

Door u te concentreren op het systeem met uiteenlopende tijd, kunt u de volgende hulpprogramma's gebruiken om meer informatie te verzamelen om u te helpen het probleem te bepalen en een oplossing te vinden. De UpstreamClockSource-verwijzing is de klok die werd ontdekt met behulp van w32tm /config /status.

• Systeemlogboeken
• Logboekregistratie inschakelen met behulp van w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• Registersleutel w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Lokale netwerktraceringen
• Prestatiemonitoren (vanaf de lokale computer of UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING-UpstreamClockSource om de latentie en het aantal hops naar de bron te begrijpen
• Tracert-UpstreamClockSource

Probleem	Symptomen	Resolutie
Lokale TSC klok is niet stabiel.	Met Perfmon - Fysieke computer – Synchroniseer stabiele klok, maar u ziet nog steeds dat er elke 1-2 minuten een afwijking van meerdere honderd microseconden optreedt.	Werk firmware bij of valideer dat er niet hetzelfde probleem wordt weergegeven op verschillende hardware.
Netwerklatentie.	In het w32tm stripdiagram wordt RoundTripDelay van meer dan 10 ms weergegeven. Variatie in de vertraging kan ruis veroorzaken zo groot als de helft van de retourtijd, bijvoorbeeld een vertraging die slechts in één richting is. UpstreamClockSource heeft meerdere hops, zoals aangegeven door PING. TTL moet dicht bij 128 liggen. Gebruik Tracert om de latentie bij elke hop te vinden.	Zoek een dichtere klokbron voor tijd. Eén oplossing is het installeren van een bronklok in hetzelfde segment of handmatig verwijzen naar een bronklok die geografisch dichter bij elkaar ligt. Voor een domeinscenario voegt u een machine toe met de rol GTimeServ.
Kan de NTP-bron niet betrouwbaar bereiken.	W32tm /stripchart geeft af en toe 'Aanvraag is verlopen'.	NTP-bron reageert niet.
NTP-bron reageert niet.	Controleer Perfmon-tellers voor NTP Client Bronaantal, NTP Server Inkomende Verzoeken en NTP Server Uitgaande Antwoorden en bepaal uw gebruik in vergelijking met uw referentiewaarden.	Bepaal met behulp van serverprestatiemeters of de belasting is gewijzigd ten opzichte van uw basislijnen. Zijn er problemen met netwerkcongestie?
De domeincontroller gebruikt niet de meest nauwkeurige klok.	Wijzigingen in de topologie of onlangs toegevoegde hoofdtijdklok.	w32tm /resync /herontdekking
Clientklokken zweven.	Time-Service gebeurtenis 36 in het systeemgebeurtenislogboek en/of tekst in het logboekbestand waarin wordt beschreven dat NTP Client Time Source Count teller van 1 naar 0 gaat.	Los de upstream-bron op en begrijp of er prestatieproblemen optreden.

Tijd voor basislijnafstemming

Basislijning is belangrijk, zodat u inzicht krijgt in de prestaties en nauwkeurigheid van uw netwerk en deze vervolgens in de toekomst kunt vergelijken met de basislijn wanneer er problemen optreden. U wilt de basislijn van de root-PDC of van computers die zijn gemarkeerd met GTIMESRV vaststellen. We raden u ook aan om de PDC in elk woud een vast uitgangspunt te geven. Kies ten slotte alle kritieke DC's of machines met interessante kenmerken, zoals afstand of hoge belastingen, en stel een basislijn op voor deze.

Het is ook handig om Windows Server 2016 volgens de basislijn te gebruiken ten opzichte van 2012 R2. U hebt echter alleen w32tm /stripchart als hulpprogramma dat u kunt gebruiken om te vergelijken, omdat Windows Server 2012 R2 geen prestatiemeteritems heeft. U moet twee machines met dezelfde kenmerken kiezen of een computer upgraden en de resultaten na de update vergelijken. De Windows Time Measurements addendum bevat meer informatie over het uitvoeren van gedetailleerde metingen tussen 2016 en 2012.

Door alle W32Time-prestatiemeteritems te gebruiken, verzamelt u gegevens gedurende ten minste een week. Deze gegevens zorgen ervoor dat u voldoende referentie hebt om rekening te houden met variaties in het netwerk in de loop van de tijd en voldoende uitvoering om er zeker van te zijn dat uw tijdnauwkeurigheid stabiel is.

NTP-serverredundantie

Voor handmatige NTP-serverconfiguratie die wordt gebruikt met niet-aan het domein gekoppelde machines of de PDC, is het hebben van meer dan één server een goede redundantiemeting in het geval van beschikbaarheid. Het kan ook een betere nauwkeurigheid geven, ervan uitgaande dat alle bronnen nauwkeurig en stabiel zijn. Als de topologie echter niet goed is ontworpen of de tijdsbronnen niet stabiel zijn, kan de resulterende nauwkeurigheid slechter zijn, dus voorzichtigheid wordt geadviseerd. De limiet van ondersteunde tijdservers waarnaar W32Time handmatig kan verwijzen is 10.

Schrikkelseconde

De rotatieperiode van de aarde varieert in de loop van de tijd vanwege klimatologische en geologische gebeurtenissen. Normaal gesproken is de variatie ongeveer een seconde om de twee jaar. Wanneer de variatie van atomaire tijd te groot wordt, wordt een correctie van één seconde (omhoog of omlaag) ingevoegd, die een schrikkelseconde wordt genoemd. Deze invoeging wordt zodanig uitgevoerd dat het verschil nooit langer is dan 0,9 seconden. Deze correctie wordt zes maanden voor de werkelijke correctie aangekondigd. Vóór Windows Server 2016 was de Microsoft Time-service niet op de hoogte van schrikkelseconden, maar vertrouwde het op een externe tijdservice om dit probleem aan te pakken. Met de toegenomen tijdsnauwkeurigheid van Windows Server 2016 werkt Microsoft aan een geschiktere oplossing voor het schrikkelsecondeprobleem.

Veilige tijdsynchronisatie

W32Time in Server 2016 bevat de functie Secure Time Seeding. Deze functie bepaalt de geschatte huidige tijd van uitgaande SSL-verbindingen. Deze tijdwaarde wordt gebruikt om de klok van het lokale systeem te controleren en eventuele brutofouten te corrigeren. Meer informatie over de functie vindt u in dit blogbericht. In implementaties met betrouwbare tijdbronnen en goed bewaakte machines die bewaking voor tijdverschil bevatten, kunt u ervoor kiezen om de functie Secure Time Seeding niet te gebruiken en in plaats daarvan te vertrouwen op uw bestaande infrastructuur.

De functie uitschakelen:

1. Groepsbeleid gebruiken om SecureTimeSeedingte beheren. Zie de sectie die verwijst naar de instelling UtilizeSslTimeData: Learn: Policy CSP - ADMX_W32Time.

2. U kunt de registerwaarde ook handmatig instellen. Stel de UtilizeSSLTimeData registerconfiguratiewaarde in op 0 op een specifieke computer:

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

3. Als u de computer niet onmiddellijk opnieuw kunt opstarten, kunt u W32Time op de hoogte stellen van de configuratie-update. Deze melding stopt tijdcontrole en afdwinging op basis van tijdgegevens die zijn verzameld via SSL-verbindingen.

   W32tm.exe /config /update
   

4. Het opnieuw opstarten van de machine zorgt ervoor dat de instelling onmiddellijk wordt uitgevoerd en zorgt er ook voor dat het verzamelen van tijdgegevens van SSL-verbindingen wordt gestopt. Het laatste deel heeft een kleine overhead en mag geen prestatieprobleem zijn.

5. Als u deze instelling in een heel domein wilt toepassen, stelt u de UtilizeSSLTimeData waarde in de groepsbeleidsinstelling W32Time in op 0 en publiceert u de instelling. Wanneer de instelling wordt opgehaald door een groepsbeleidsclient, wordt W32Time op de hoogte gesteld en wordt tijdcontrole en afdwinging gestopt met behulp van SSL-tijdgegevens. Het verzamelen van SSL-tijdgegevens stopt wanneer elke computer opnieuw wordt opgestart. Als uw domein draagbare slanke laptops/tablets en andere apparaten heeft, kunt u dergelijke machines uitsluiten van deze beleidswijziging. Deze apparaten hebben uiteindelijk last van het leeglopen van de batterij en hebben de functie Secure Time Seeding nodig om hun tijd te initialiseren.