[Server 2016] Time issues

[HKLM_]

Na een middagje google kom ik niet meer uit onderstaand issue (helaas)

Case: Drie domaincontrollers waarbij de tijd regelmatig niet goed loopt. In de event viewer zie ik:

1 fysieke DC (master)
2 virtueel met Hyper-v time sync uitgeschakeld

code:

The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

code:

The time service has stopped advertising as a time source because the local clock is not synchronized.

Soms komen ze dagen niet voor soms komen ze een paar x per dag voor. Je zou zeggen he als je het niet doet dan doe je het niet toch?

Onze primaire DC heeft ook de PDC Emulator bij zich en als ik een w32tm / doe in CMD krijg ik onderstaand:
w32tm /query /status

code:

Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1258388s
Root Dispersion: 69.9330485s
ReferenceId: 0x81FA23FA (source IP:  129.250.35.250)
Last Successful Sync Time: 10-12-2018 16:27:34
Source: 0.nl.pool.ntp.org,0x9
Poll Interval: 8 (256s)

w32tm /query /configuration

code:

NtpClient (Local)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Policy)
ResolvePeerBackoffMaxTimes: 7 (Policy)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 0 (Policy)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 3600 (Policy)
Type: NTP (Policy)
NtpServer: 0.nl.pool.ntp.org,0x9 (Policy)

NtpServer (Local)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)

Als ik in het register kijk zie ik op de DC met de PDC Emulator heeft hij als type NTP. De andere DC's hebben NT5DS waarmee ze kijken naar de PDC Emulator (dacht ik)

Tevens hebben we uit het verleden een NTP policy die de NTP op 0.nl.pool.ntp.org zet. Ik vraag mij af of deze roet in het eten aan het gooien is.... Ik heb tevens de re-registering van de windows time uitgevoerd maar dat was hem niet.

De firewall op de DC's staat momenteel uit, ik kan de NTP server 0.nl.pool.ntp.org ook pingen dus ik zoek het issue waarom hij soms niet wilt syncen.

Iemand die mij een zetje in de juiste richting kan geven

[ Voor 3% gewijzigd door HKLM_ op 10-12-2018 16:41 ]

[Glashelder]

Je hebt niet iets als VMWare Tools draaien dat aan het syncen is met de host?

[HKLM_]

Glashelder schreef op maandag 10 december 2018 @ 16:39:
Je hebt niet iets als VMWare Tools draaien dat aan het syncen is met de host?

Damm vergeet ik helemaal...

1 fysieke DC (master)
2 virtueel met Hyper-v time sync uitgeschakeld

[MAX3400]

Hyper-V is responsible for time operations when the guest is off, the Hyper-V Time Synchronization Service is responsible for time operations while it is on.

Dus...

[zwittrooper]

Je Hyper-V host synced niet toevallig de tijd met je DC, terwijl je DC VM de tijd van de host krijgt? Dan ontstaat er misschien een loop

Edit: Verkeerd gelezen, de DC is geen VM

[ Voor 13% gewijzigd door zwittrooper op 10-12-2018 16:50 ]

[HKLM_]

MAX3400 schreef op maandag 10 december 2018 @ 16:42:
[...]

Dus...

Ik las op google dat je voor domain controllers Time synchronization beter uit kan zetten om time issues te voorkomen. Dit omdat een DC als het goed is de time onderling uitwisselt. En aangezien we een fysieke hebben zou dat goed moeten gaan.

Ik heb dat voor de virtuele DC's dan ook uit geschakeld.

[ Voor 7% gewijzigd door HKLM_ op 10-12-2018 16:48 ]

[MAX3400]

@HKLM_ dat is, naar mijn weten, alleen valide als je een passthrough NIC voor de virtuele DC hebt gedefinieerd; niet als je op de external virtual switch van je host bent aangesloten.

[HKLM_]

MAX3400 schreef op maandag 10 december 2018 @ 16:50:
@HKLM_ dat is, naar mijn weten, alleen valide als je een passthrough NIC voor de virtuele DC hebt gedefinieerd; niet als je op de external virtual switch van je host bent aangesloten.

Oke dat kan ik wel proberen inderdaad, alleen dan heb ik nog mijn fysieke DC die het issue ook heeft....

[Jazzy]

De domain controllers halen standaard hun tijd op bij de domain controller die de PDC Emulator rol heeft. Omdat dit de hoogste tijdsautoriteit in je domein is wil je die vaak synchroniseren met een pool van externe NTP servers of zoals vroeger met zo'n hardwarematige klok die de atoomtijd ophaalt.

Alle andere domain controllers synchroniseren met de DC met de PDC emulator rol dus dat zou goed moeten gaan. Enige probleem is dat virtuele servers vaker uit de tijd lopen omdat de hypervisor creatief om gaat met de kloktikken die ze toebedeeld krijgen, daardoor kunnen ze al snel vrij veel afwijken voordat ze de tijd weer synchroniseren met de DC die de PDC Emulator rol heeft.

Work-around is om op virtuele DC's dan de tijdsynchronisatie van de hypervisor te gebruiken om te voorkomen dat de tijd snel uit de pas loopt. Wel ervoor zorgen dat je hypervisor met dezelfde bron synchroniseert als je DC met de PDC emulator rol.

[Turdie]

In most cases it's best to use pool.ntp.org to find an NTP server (or 0.pool.ntp.org, 1.pool.ntp.org, etc if you need multiple server names). The system will try finding the closest available servers for you.

 net time /setsntp:pool.ntp.org 

[ Voor 16% gewijzigd door Turdie op 10-12-2018 17:22 ]

[plukke]

Je zou kunnen kijken of je een trial versie van Domain Time II van Greyware op je VMs kan draaien. Daar zit een drift graph in waaraan je heel mooi kunt zien hoe ver en hoe snel je bij een bepaalde NTP server vandaan drift. Configureer m even zodat ie alleen monitort en niet je tijd zet. Dat zou je een redelijk goed beeld moeten geven van wie welke kant op gaat.

[HKLM_]

shadowman12 schreef op maandag 10 december 2018 @ 17:19:
[...]

 net time /setsntp:pool.ntp.org 

Ik ga hem daar morgen eens op zetten.

[Jazzy]

Let dan wel even op waar je dat doet, zie mijn bericht hierboven.

[HKLM_]

Jazzy schreef op maandag 10 december 2018 @ 17:27:
Let dan wel even op waar je dat doet, zie mijn bericht hierboven.

Als ik je goed begrijp op de machine die die PDC heeft

[Hero of Time]

Op m'n vorige werk hadden ze 4 domain controllers. 2 fysiek, 2 virtueel. Een daarvan, ik dacht een virtuele, iig niet die de PDC rol had, week behoorlijk af. De beheerders daar verantwoordelijk voor de machines hebben meen ik alle domain controllers met dezelfde NTP server laten synchroniseren, dus niet de PDC met NTP en de rest met de PDC. Wil je dat wel, kijk dan heel goed welke NT5DS ze gebruiken en welke status die heeft, alsmede de interval. Zeker met virtuele machines wil je die interval zo klein mogelijk houden omdat de tijd daar heel snel heel veel kan afwijken.

Je zegt ook dat je denkt dat de andere servers naar je PDC kijken voor de tijd. Schijn bedriegt, tijd sync in Windows kan een drama zijn als je het niet fatsoenlijk instelt. Het kan zomaar van NT5DS naar local of CMOS gaan en dan ben je het bokkie als je dat niet oplost.

Als ik het niet vergeet zal ik morgen een link plaatsen met informatie over tijd sync settings voor je forest. Die kan je aanhouden als best practise.

[HKLM_]

Gisteravond toch maar even de pool aangepast en vanmorgen loopt alles gelijk. Nu eens aankijken wat het de komende dagen gaat doen. Thx alvast!!

*Soms is het gewoon zo makkelijk schijnbaar maar zie je het gewoon even niet....

[ Voor 29% gewijzigd door HKLM_ op 11-12-2018 09:13 ]

[Hero of Time]

Was ik 't toch vergeten. En nu je 't topic weer in zicht hebt gebracht, gelijk het linkje voor je:
https://blogs.technet.mic...tion-in-active-directory/

[HKLM_]

Heel de dag gaat het goed en vanaf 15:00 heb ik weer een ID 50 met 2minuten verschil..... op de fysieke dc.

code:

The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

Dat lijkt er dus op dat hij het wel doet maar zo nu en dan niet. maar hoe de fuck kom je daar achter met alleen een event ID waarop ik google maar gewoon niks verder lijkt te komen...

[ Voor 15% gewijzigd door HKLM_ op 11-12-2018 15:39 ]

[Turdie]

HKLM_ schreef op dinsdag 11 december 2018 @ 15:34:
Heel de dag gaat het goed en vanaf 15:00 heb ik weer een ID 50 met 2minuten verschil..... op de fysieke dc.

code:

The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

Dat lijkt er dus op dat hij het wel doet maar zo nu en dan niet. maar hoe de fuck kom je daar achter met alleen een event ID waarop ik google maar gewoon niks verder lijkt te komen...

Netwerk issues of te hoge latency? Je zou is een andere NTP kunnen proberen, die van xs4all is wel goed, ntp.xs4all.nl is ook een strato 1 volgens mij net zoals ntp.org (op de pdc dan)

En daarna even resyncen:
w32tm /config /syncfromflags:domhier /update

After that you have to run:

net stop w32time
net start w32time

[Hero of Time]

Is de tijd op de PDC machine ook echt afwijkend, of wijken de andere af van de PDC en krijg je de melding alleen op de server met de PDC rol? Je kan dit controleren door https://time.is open te houden op de server, dan zie je wat er afwijkt.

Controleer daarnaast ook de polling en herstel interval op de servers. De standaard waardes kunnen te groot zijn voor domain controllers. De link die ik postte vanochtend al gelezen? Die zou alle informatie moeten bevatten die je nodig hebt om de tijd fatsoenlijk en correct te laten lopen op alle machines.

[Wim-Bart]

Dit is echt een waardeloos probleem. Eigenlijk is er maar 1 goede oplossing heb ik zelf gemerkt. Time sync dus niet via domein controllers op Internet laten lopen. Er zijn twee mogelijkheden:

• Fysieke time server
• Core switches als time server
• Firewall als time server

Dit device noemen we een reliable time source en kan met een atoomklok of via ntp.pool.org (of ander) synchroniseren.

Ongeacht het scenario is de inrichting vrij eenvoudig:

• Alle fysieke machines synchroniseren met de reliable timesource (1 van de drie hier boven). Dus:
• Alle BMC's, RAC, iLO, RILO, etc. management consoles op servers
• Alle Netwerk componenten
• Alle Hypervisors (ESX, XEN, Hyper-V ....)
• Alle Fysieke Domein Controllers met PDC rol

De overige systemen:

• Windows - via domein
• Linux - via de reliable source

Daarnaast "geen" tijd synchronisatie met Virtuele host, en een VM nooit als time-source laten werken.

Verder is het een plus wanneer je in het datacentrum een UPS hebt die de frequentie gelijk houdt. Dus exact 50Hz. Servers hebben nogal eens de nijging om hierdoor af te gaan wijken.

Onder Windows kan je dan met GPO/Register instellingen zaken aanpassen, bijvoorbeeld polling interval. Andere settings via https://docs.microsoft.co...ervice-tools-and-settings

Meer info: http://techgenix.com/configuring-windows-time-service/

[HKLM_]

Hero of Time schreef op dinsdag 11 december 2018 @ 16:53:
Is de tijd op de PDC machine ook echt afwijkend, of wijken de andere af van de PDC en krijg je de melding alleen op de server met de PDC rol? Je kan dit controleren door https://time.is open te houden op de server, dan zie je wat er afwijkt.

Controleer daarnaast ook de polling en herstel interval op de servers. De standaard waardes kunnen te groot zijn voor domain controllers. De link die ik postte vanochtend al gelezen? Die zou alle informatie moeten bevatten die je nodig hebt om de tijd fatsoenlijk en correct te laten lopen op alle machines.

Ja de tijd op de PDC is ook echt afwijkend ik check het inderdaad met https://time.is/ en daar zie ik dan een verschil tussen. Ik kom net op kantoor en de laatste error in de event log is van gister avond uur of 6 en nu loopt hij weer goed... maar dat was gisteren ook.

Ik heb je link gezien en gelezen en de settings die daar genoemt worden register en gpo staan net zo als in het voorbeeld. Alleen wij gebruiken pool.ntp.org i.p.v time.windows.

[Turdie]

Wim-Bart schreef op dinsdag 11 december 2018 @ 17:37:
Dit is echt een waardeloos probleem. Eigenlijk is er maar 1 goede oplossing heb ik zelf gemerkt. Time sync dus niet via domein controllers op Internet laten lopen. Er zijn twee mogelijkheden:

• Fysieke time server
• Core switches als time server
• Firewall als time server

Dit device noemen we een reliable time source en kan met een atoomklok of via ntp.pool.org (of ander) synchroniseren.

Ongeacht het scenario is de inrichting vrij eenvoudig:

• Alle fysieke machines synchroniseren met de reliable timesource (1 van de drie hier boven). Dus:
• Alle BMC's, RAC, iLO, RILO, etc. management consoles op servers
• Alle Netwerk componenten
• Alle Hypervisors (ESX, XEN, Hyper-V ....)
• Alle Fysieke Domein Controllers met PDC rol

De overige systemen:

• Windows - via domein
• Linux - via de reliable source

Daarnaast "geen" tijd synchronisatie met Virtuele host, en een VM nooit als time-source laten werken.

Verder is het een plus wanneer je in het datacentrum een UPS hebt die de frequentie gelijk houdt. Dus exact 50Hz. Servers hebben nogal eens de nijging om hierdoor af te gaan wijken.

Onder Windows kan je dan met GPO/Register instellingen zaken aanpassen, bijvoorbeeld polling interval. Andere settings via https://docs.microsoft.co...ervice-tools-and-settings

Meer info: http://techgenix.com/configuring-windows-time-service/

toon volledige bericht

Maar waar laat je de PDC dan mee synchroniseren?

[Hero of Time]

shadowman12 schreef op woensdag 12 december 2018 @ 10:40:
[...]

Maar waar laat je de PDC dan mee synchroniseren?

Zoals hij zegt, niet met een bron op het internet. De gegeven voorbeelden zijn een switch, router of aparte NTP machine, in je eigen netwerk natuurlijk.

[ Voor 5% gewijzigd door Hero of Time op 12-12-2018 10:49 ]

[HKLM_]

Ik heb met Domain Time manager II een test gedaan op pool.ntp.org deze zat nogal hoog in de ms en regelmatig een timeout. Heb daarna de server van xs4all gepakt en deze was beduidend sneller en minder timeouts. Ik heb deze nu ingesteld en wacht het weer even af..

[Turdie]

Hero of Time schreef op woensdag 12 december 2018 @ 10:48:
[...]

Zoals hij zegt, niet met een bron op het internet. De gegeven voorbeelden zijn een switch, router of aparte NTP machine, in je eigen netwerk natuurlijk.

Dan moet je router of switch wel een NTP server aanboord hebben.

[Equator]

Het grote voordeel van pool.nlp.org is dat iedereen er aan mee kan doen. Het grote nadeel is dat iedereen er aan mee kan doen. Je weet dus eigenlijk nooit wat voor stratum de tijdbron heeft waar je aan verbonden wordt, en wat de afwijking is.

Voor een testopstelling of thuis is het prima, maar voor een wat belangrijkere omgeving (aka productie) pak je liever een stratum 1 server zoals:
ntp0.nl.uu.net
ntp1.nl.uu.net

Deze zijn gratis. Er zijn ook betaalde diensten die wellicht sneller reageren.

Wil je onafhankelijk zijn, dan zet je zelf een paar GPS antennes op je dak en koppel daar een NTP appliance aan

[ Voor 26% gewijzigd door Equator op 12-12-2018 11:35 . Reden: Voorbeeld NTP Appliance gelinked :) ]

[Wim-Bart]

HKLM_ schreef op woensdag 12 december 2018 @ 11:02:
Ik heb met Domain Time manager II een test gedaan op pool.ntp.org deze zat nogal hoog in de ms en regelmatig een timeout. Heb daarna de server van xs4all gepakt en deze was beduidend sneller en minder timeouts. Ik heb deze nu ingesteld en wacht het weer even af..

Dat is dan ook de reden dat je een hardware NTP source binnen je eigen netwerk moet hebben. Je kan best een hardware device hebben die tijd van Internet haalt van een "unreliable source" en zelf een "reliable source" is. Reliable = met minimale latency voorzien in de tijd met minimale afwijking.

In de meest ideale situatie:
Externe cock = Stratum 1 wat hogere latency door Internet wat er tussen zit (stratum 1 wordt meestal met atoomklok gesynced)
Interne clock = Stratum 2 met hele lage latency waardoor dit de basis server wordt binnen je netwerk
Alle hardware + Windows PDC = Stratum 3
Overige = Stratum 4

Zelf heb ik de voorkeur om twee core switches in het netwerk Stratum 2 NTP servers te maken waarbij de configuratie als volgt is:
Core 0 -> 0.pool.ntp.org, 1.pool.ntp.org, core 1
Core 1 -> 2.pool.ntp.org, 3.pool.ntp.org, core 0

Overigens zijn alle servers op Internet Stratum 1, wil je een eigen Stratum 1 source hebben, dan moet je zelf een hardware clock hebben, bijvoorbeed een Microsemi S600 of een S650.

Voor de Tweakers een RPi Stratum 1: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

[Equator]

Wim-Bart schreef op woensdag 12 december 2018 @ 11:47:
[...]

Overigens zijn alle servers op Internet Stratum 1

Nou, daar ben ik het niet mee eens. Een stratum 1 is een device wat zijn tijd bij een atoomklok krijgt. Als jij je tijd weghaalt bij een stratum 1, dan ben jij een stratum 2, enz.

Dat het voor jou de bron is, maakt het geen stratum 1.

[Wim-Bart]

Equator schreef op woensdag 12 december 2018 @ 12:23:
[...]


Nou, daar ben ik het niet mee eens. Een stratum 1 is een device wat zijn tijd bij een atoomklok krijgt. Als jij je tijd weghaalt bij een stratum 1, dan ben jij een stratum 2, enz.

Dat het voor jou de bron is, maakt het geen stratum 1.

De meeste halen hun bron bij een Stratum 0. Maar bijvoorbeeld Pool.ntp.org is een Stratum 2 volgens mij (althans zo benader ik hem). Een GPS NTP is ook een Stratum 1.

[Equator]

Als ik met een RPi (of elke andere computer) een NTPd mag draaien en mijn IP adres mag toevoegen aan nl.pool.ntp.org, dan weet je als afnemer van pool.ntp.org toch niet wat mijn afwijking gaat zijn?

Daarnaast zijn de meeste PC's niet zo heel goed in het beperken van de drift. We hebben immers geen speciale hardware / kristal daarvoor.

Ik zou pool.ntp.org dus ook eerder klassificeren als een Stratum 3. Prima voor thuis, maar niet op kantoor. Zoals ik hier: Equator in "[Server 2016] Time issues" aangeef, gebruik een paar (al dan niet gratis) publieke Stratum 1 systemen.

[Turdie]

Wim-Bart schreef op woensdag 12 december 2018 @ 13:12:
[...]

De meeste halen hun bron bij een Stratum 0. Maar bijvoorbeeld Pool.ntp.org is een Stratum 2 volgens mij (althans zo benader ik hem). Een GPS NTP is ook een Stratum 1.

Binnen het pool.ntp.org project zitten allerlei verschillende stratum levels 3 en 4 mogen ook meedoen, staat ook op de site.

[HKLM_]

Afgelopen 24 uur is de tijd door de PDC meerdere malen goed opgehaald. We gebruiken nu de ntp.xs4all.nl en ik heb momenteel op alle servers met het issue geen gerelateerde eventlogs meer en een goed lopende tijd gelijk met time.is

Nu hopen dat dit ook in het weekend zo blijft (maar dat zien we maandag)

Dank voor alle tips en hulp

[ Voor 12% gewijzigd door HKLM_ op 13-12-2018 15:55 ]