Zeitserver-Probleme

[soulseeker 13]

Hallo zusammen,

 

nachdem heute früh die Anmeldung an unserem Terminalserver nicht mehr funktionierte, bin ich schnell dahinter gekommen, dass die Zeitsynchronisation bei uns nicht richtig läuft.

 

Wir nutzen 3 DCs, einen auf Blech (Win2008R2), einen als VM (Win2008R2/ESX) und einen in der Cloud (Win2012R2/Azure).

 

Alle DCs haben als Policy ptbtime1.ptb.de und die Clients nutzen dann mal den einen und mal den anderen DC als Zeitserver.

 

w32tm /monitor zeigt aber, alle 3 DCs auseinanderlaufen, teilweise um 80 Sekunden.

 

Der Blech-DC und der ESX-DC zeigen mir zumindest den gleichen NTP-Server an, aber warum sind die nicht im Sync?

 

Beim azure-DC wird ein anderer NTP-Server verwendet, vermutlich, weil das ganze ja unter Hyper-V läuft und die Azure-VM diesen als NTP benutzt.

 

Wie bekomme ich meine DCs wieder synchron? 

 

Ich habe w32tm unregister /register / resync durchgeführt aber es ändert sich nichts. Wenn ich die Zeiten manuell ändere, laufen sie bald wieder auseinander. Die ESX-Hosts habe ich auf unsere DCs als Zeitserver umkonfiguriert, aber das ändert auch nichts :(.

 

Viele Grüße

 

Marcel

[NorbertFe 1.835]

Wenn alle DCs extern syncen, dann ist das bei dir "grenzwertig" konfiguriert. Normalerweise bekommt nur der PDC Emulator eine externe Zeitquelle, alle anderen synchen vom PDC Emulator. Die ESX sollten dann natürlich auch gegen einen der DCs synchen (im Idealfall einfach den Domain-Name eintragen, wenns keine IP sein muß). Host-Timesync sollte dann gar nicht genutzt werden.

 

Bye

Norbert

[soulseeker 13]

Ok, ich sehe gerade das die NTP-Einstellung in der Domain controllers policy vorgenommen wird.

 

Soll ich diese GPO-Einstellung dann besser entfernen und die DCs so konfigurieren, wie du es beschreibst? 

[NorbertFe 1.835]

ICh empfehle: http://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

 

Bye

Norbert

[soulseeker 13]

Danke Norbert, diese Seite habe ich zeitgleich gefunden :-)

 

Derzeit ist es wie folgt: Default Domain Policy hat NTP-Settings. Das löse ich nun also auf.

 

Ich habe eine neue Policy erstellt, ebenso meinen WMI-Filter. Damit sollte also nur der PDC-Emulator mit dieser Policy versorgt werden.

 

Ich verstehe allerdings Schritt zwei nicht - warum werden hier die Domainmembers mit time.windows.com konfiguriert, der PDC-Emulator aber mit pool.ntp.org? Ich denke den Domain-Members sollte ich dann den PDC-Emulator geben?

 

Und was ich auch merkwürdig finde (sorry, wenn ich hier Unwissen offenbare) - wenn ich w32tm /query /source auf einem Client ausführe, dann verwenden alle Clients derzeit einen der verschiedenen DCs. Das wird aber nirgendwo per GPO konfiguriert, habe ich gerade mit gpresult /h geprüft. Ist es normal, dass bei unkonfigurierten Clients in einem AD die DCs automatisch als Zeitserver verwendet werden?

[NorbertFe 1.835]

Siehe hier: http://www.mcseboard.de/topic/202337-domänencontroller-mit-externem-zeitserver-synchronisieren/page-2#entry1260434

[Daniel -MSFT- 129]

Wenn ich mich richtig erinnere, dann ist die Reihenfolge:

1. Der Host-Sync in der Virtualisierungsumgebung wird abgeschaltet, damit die nicht bei der Zeit dazwischenfunkt(muss konfiguriert werden).
2. Der PDC-Emulator wird mit einer externen Zeitquelle synchronisiert (muss konfiguriert werden).
3. Alle DCs gleichen sich gegen den PDC-Emulator ab (Standard).
4. Alle Member-Server und Clients gleichen sich gegen den Logon-Server ab (Standard).

Daher siehst Du am Client verschiedene DCs als Zeitserver. Dient dem Lastenausgleich.

 

Bei dem Artikel wird in Schritt 2 die Konfiguration auf die Synchronisation in einer Domäne gesetzt. Der time.windows.com-Eintrag wird dabei nicht benutzt. Der ist dafür da, wenn man den Client aus der Domäne rausnimmt, dass der Client dann auf NTP umschaltet und diesen als Quellserver nimmt.

 

In Deutschland kannst Du auch de.pool.ntp.org nutzen.

 

Have fun!
Daniel

[soulseeker 13]

Ok, jetzt habe ich es kapiert, besten Dank an euch beide. Keine Ahnung, warum das hier so falsch konfiguriert war. Allerdings wundert es mich trotzdem, dass die Zeit trotz gleicher logon-server unterschiedlich war. Aber egal. Die Zeit zwischen dem Blech-DC und dem ESX-DC ist nun synchron.

 

Bleibt jetzt nur noch mein Azure-Problem, der läuft 40 Sec nach und nutzt als Source das hier:

 

 

Leap Indicator: 0(no warning)

Stratum: 2 (secondary reference - syncd by (S)NTP)

Precision: -6 (15.625ms per tick)

Root Delay: 0.0000000s

Root Dispersion: 0.0100000s

ReferenceId: 0x564D5450 (source IP:  86.77.84.80)

Last Successful Sync Time: 2/25/2015 2:14:41 PM

Source: VM IC Time Synchronization Provider

Poll Interval: 10 (1024s)

 

Bei Hyper-V wüsste ich, wo ich den NTP-Abgleich mit dem host deaktivieren müsste, aber nicht bei Azure.

[edit] was haltet ihr hiervon: http://stackoverflow.com/questions/17239608/can-you-setup-an-azure-server-to-sync-with-a-outside-ntp-server

 

[edit2] das scheint es zu sein, jetzt ist auch auf der Azure-VM unser PDC-Emulator als NTP-Server eingetragen, allerdings schleicht sich nun wieder ein leichter delay von einigen Sekunden ein. Ist das normal? Ich habe mit w32tm /monitor noch nie in dem Maße angeschaut, wie heute ...

 

Kerberos-Probleme gibt es ja eigentlich erst, wenn die Zeitserver mehr als 5 Minuten auseinander liegen.

bearbeitet 25. Februar 2015 von soulseeker

[NorbertFe 1.835]

Bei Azure kann ich dir leider nicht helfen. Aber einen Versuch mit dem Vorgehen aus deinem Link wäre ja es ja wert. Wobei du dann aber w32tm /config /update /syncfromflags: DOMHIER nutzen müßtest, da du ja von der Domänenhierarchie synchen willst. ;)

 

Bye

Norbert

Keine Ahnung, warum das hier so falsch konfiguriert war.

Ich hätte da so diverse Vermutungen. ;) Die erste wäre "Unwissenheit". ;)

[soulseeker 13]

Hmm mit domhier steht das ganze aber wieder auf "local cmos clock" ... nicht so sinnvoll bei Azure.

 

Nur wenn ich >w32tm /config /syncfromflags:manual /manualpeerlist:zeit.domain.de eingebe, wird der richtige NTP-Server gefragt.

 

Mit dem "out of sync" hatte ich mich verguckt - das waren millisekunden. ;)

 

Unwissenheit - vermutlich. Oder keinen Bock gehabt, komischerweise war der WMI-Filter schon vorhanden, nur nicht verwendet.

[daabm 1.199]

Dass ntp immer ein paar Sekunden auseinanderläuft (und auch w32time) ist "by design".Gibt auch KB-Artikel oder MS-Blogs dazu, die das beschreiben. URLs hab ich grad nicht zur Hand, aber GooBing findet die bestimmt :D

[NorbertFe 1.835]

Bingle auch