VMs (Domänencontroller + Memberserver Uhrzeit geht 5min vor)

[Master112]

Hallo,

an meinem Domänencontroller und auf allen 10 Memberserver (alles VMs) geht die Uhrzeit synchron um 5Minuten vor.

Sprich: Haben wir in Wirklichkeit jetzt 19:55 ist es auf allen VMs (DC+Memberservers) bereits 20:00 Uhr.

Welche Schritte muss ich im Details auf dem PDC eingeben, damit sich der DC die Zeit neu zieht? Welche NTP Server soll ich angeben? Was muss ich auf den Memberservern tun? Oder ziehen sich die Memberserver automatisch die Uhrzeit, wenn diese auf dem PDC neu gesynct wurde?

Vielen Dank und LG
Michael

[Chief Wiggum]

Steuert der VM Host die Zeit, sprich synchronisieren die Guests mit der Virtualisierungsplattform?

https://kb.vmware.com/s/article/1003736

Dann solltest du die Bios-Uhr vom Host stellen. Alterantiv deaktiviere diese Funktion, der PDC Emulator sollte dann der NTP für die Domain werden. Dieser Server braucht dann natürlich freien Zugriff auf die MS Timeserver im Internet.

[Master112]

Aktuell ist in den Einstellungen jeder VM noch der Haken gesetzt, dass sich der Guest die Zeit vom Host zieht. Das möchte ich aber unterbinden und der Domaincontroller soll als PDC die entsprechenden NTP Server kontaktieren im Internet. Ich finde bei Google diverse Anleitungen. Vorab habe ich mich gegen die Registry bzw. GPO Variante entschieden, sondern für die CMD Lösung mit w32tm. Jedoch spuckt mir google verschiedene Reihenfolgen aus mit Befehlen für die CMD. Deshalb wollte ich mal vorsichtig hier anfragen, in welcher Reihenfolge ich beginnend auf dem DC (PDC) die Befehle absetzen muss und ob sich die Clients automatisch die Uhrzeit dann ziehen, nachdem der PDC die Zeit neu gezogen hat? Oder muss ich auf jeden Memberserver auch nochmal w32tm Befehle absetzen? Da fehlt mir gerade noch der Leitfaden.

[Chief Wiggum]

Sobald die Guests nicht mehr mit dem Host synchronisieren ist der Domaincontroller mit der PDC-Emulator-Rolle der "Chef im Ring", alle anderen Domaincontroller im AD und die weiteren Clients (Memberserver sind Clients) sollten sich automatisch die Zeit vom PDC Emulator ziehen. Da braucht es keine Eingriffe in der Registry und auch w32time braucht man nicht.

[Master112]

ok. Also brauche ich nur in vSphere den Haken entfernen bei "Guest ziehen sich die Uhrzeit vom Host" (sinngemäß) ?
Ich muss doch mindestens einmal die Uhrzeit am PDC syncen mit dem Befehlsatz w32tm? Sonst behält der doch weiterhin die alte Zeit?

[Master112]

Anders herum gefragt...Kann irgendetwas schief gehen wenn ich in vSphere die Haken wegnehme und der w32tm Sync auf dem PDC nicht funktioniert? Ich weiß, dass DC und Memberserver die gleiche Uhrzeit haben müssen wegen den Kerberos Tickets.....

[Chief Wiggum]

Ich hatte mal das Vergnügen mit einem DC ohne FSMO-Rollen an einem entfernten Standort, der durch einen Fehler in den Firewallrichtlinien nicht mehr mit dem FSMO-Träger kommunizieren konnte. Der ist dann auch von der Domainzeit abgedriftet und hat sich automatisch wieder synchronisiert nachdem die Firewall ihn wieder durchgelassen hat.

vor 6 Minuten schrieb Master112:

Kann irgendetwas schief gehen wenn ich in vSphere die Haken wegnehme und der w32tm Sync auf dem PDC nicht funktioniert?

Können wir bitte bei den korrekten Bezeichnungen bleiben? Seit Windows 2000 gibt es die Unterscheidung PDC / BDC nicht mehr, es gibt nur noch die FSMO-Rolle "PDC Emulator", die auf einem der gleichberechtigten DCs in der Domain liegt.

Du solltest natürlich für ALLE Server den Sync mit dem Host deaktivieren. Du solltest nur einplanen, dass du die Systeme eventuell einmal durchbooten kannst. Also: Wartungsfenster.

[Master112]

Gut alles klar !! Dann mache ich das am Wochenende und berichte von meinem Erfolg 😉 Vielen Dank für die Unterstützung. Schönen Abend und LG

 

[Chief Wiggum]

Viel Erfolg!

[Maniska]

vor 11 Stunden schrieb Chief Wiggum:

Können wir bitte bei den korrekten Bezeichnungen bleiben? Seit Windows 2000 gibt es die Unterscheidung PDC / BDC nicht mehr, es gibt nur noch die FSMO-Rolle "PDC Emulator", die auf einem der gleichberechtigten DCs in der Domain liegt.

Ich hab mich schon gewundert wann das kommt

Ich (persönlich) würde das Setup so hochziehen, dass sich die Firewall (steht ja eh schon im Internet) die Zeit von einem externen NTP Server (z.B. pool.ntp.org) hot und "nach Innen" den NTP Dienst verteilt.

Alle anderen Geräte (ESXi Hosts, Switche, Drucker, Storage...) und der PDC ( 😛 ) holen sich die Zeit von der Firewall. Warum? Weil die Firewall tendenziell das langlebigste Gerät ist und selbst bei einem Austausch die neue Firewall im Regelfall mit der alten IP kommt. Also am Wenigsten zum Tauschen.

Dann dem PDC sagen, dass er sich die Zeit von der Firewall holen soll (Per Registry, GPO (sauberste Lösung) oder w32tm (was auch nur ein extra Step zur Registry ist).

Nachdem nun alle die Zeit von der Firewall holen, ist es "fast" egal ob die VMs sich beim Host bedienen oder bei ihrem DC. Sauber ist aber die Lösung mit DC. Sprich den VMs sagen "du nix nehmen Kerze Zeit vom Host" und entweder warten, die VM neu starten, oder "w32tm /resync".

Im Regelfall springen die VMs auch nicht von 21:00 auf 21:15, sonder sie lassen die Zeit langsamer/schneller laufen bis sie wieder in Sync sind.

In der Domäne wird per Default ein Zeitunterschied bis zu 600 Sekunden (5 Minuten) toleriert.

[Enno]

vor 2 Stunden schrieb Maniska:

Ich hab mich schon gewundert wann das kommt

Ich (persönlich) würde das Setup so hochziehen, dass sich die Firewall (steht ja eh schon im Internet) die Zeit von einem externen NTP Server (z.B. pool.ntp.org) hot und "nach Innen" den NTP Dienst verteilt.

Alle anderen Geräte (ESXi Hosts, Switche, Drucker, Storage...) und der PDC ( 😛 ) holen sich die Zeit von der Firewall. Warum? Weil die Firewall tendenziell das langlebigste Gerät ist und selbst bei einem Austausch die neue Firewall im Regelfall mit der alten IP kommt. Also am Wenigsten zum Tauschen.

Autsch.

a) nicht jede Firewall kann NTP

b) Aua einfach.

c) im lokalen DNS nen fixen Namen eintragen der auf die IP des aktuellen NTP zeigt.
also z.b. Local_NTP -> 192.168.1.x

wenn du nun den NTP wechselst musst du nur die IP Reservierung ändern und es sind wieder alle Ontime.

[Maniska]

vor 2 Minuten schrieb Enno:

Autsch.

a) nicht jede Firewall kann NTP

b) Aua einfach.

c) im lokalen DNS nen fixen Namen eintragen der auf die IP des aktuellen NTP zeigt.
also z.b. Local_NTP -> 192.168.1.x

wenn du nun den NTP wechselst musst du nur die IP Reservierung ändern und es sind wieder alle Ontime.

Joar geht auch. Ich hatte bis jetzt nur Firewalls im Einsatz die das können.

Ich hatte halt auch zum Teil Geräte die es nicht sonderlich mochten den NTP via Name zu erhalten (vor allem alte Produktionsmaschinen), die musste ich via IP befüttern. Also müsste ich an der Stelle trotzdem 1:1 tauschen, ob mit oder ohne DNS Eintrag.

Ich denke aber wir sind uns an einer Stelle trotzdem einig: EINER holt die Zeit von außen und verteilt sie intern, und das sollte nicht ein/der DC sein.

[Enno]

vor 3 Minuten schrieb Maniska:

Ich denke aber wir sind uns an einer Stelle trotzdem einig: EINER holt die Zeit von außen und verteilt sie intern, und das sollte nicht ein/der DC sein.

Agree

[Chief Wiggum]

vor 8 Stunden schrieb Maniska:

EINER holt die Zeit von außen und verteilt sie intern, und das sollte nicht ein/der DC sein.

Warum? Ich kann verstehen, dass der FSMO-Träger sowenig nach aussen soll wie nur notwendig, er kann sich ja die Zeit gerne von einem NTP auf der Firewall holen und ansonsten abgeschottet sein. Was aber spricht dagegen, die mit dem PDC-Emulator kommende Funktion "interner Zeitserver" zu nutzen? Welchen Sinn soll es haben, alle anderen DCs im Netz von dieser PDC-Emulator-Funktion abzukoppeln?

Kurz: die DCs sollten untereinander so ungestört wie nur möglich kommunizieren können - und eine Aufgabe dabei ist der Abgleich über NTP. Erklärt mir bitte, warum der PDC-Emulator eben NICHT NTP machen soll.

[Maniska]

vor 12 Stunden schrieb Chief Wiggum:

Kurz: die DCs sollten untereinander so ungestört wie nur möglich kommunizieren können - und eine Aufgabe dabei ist der Abgleich über NTP. Erklärt mir bitte, warum der PDC-Emulator eben NICHT NTP machen soll.

Ok, unglücklich ausgedrückt:

Einer (kein DC) holt die Zeit von draußen und ist intern primäre Anlaufstelle für alles was "direkt" einen NTP eingetragen bekommt (ILO, ESXi Host, Switch, Linuxmaschinen etc.) und den PDC. Die NTP Hierarchie innerhalb der Domäne würde ich auch nicht antasten.

Externer NTP -> Interner (Haupt-)NTP (z.B. Firewall) -> PDC (+ alles was nicht Domäne ist) -> DCs -> Member (Client/Server)

Mir ging es um:

Am 8.5.2023 um 20:04 schrieb Chief Wiggum:

der PDC Emulator sollte dann der NTP für die Domain werden. Dieser Server braucht dann natürlich freien Zugriff auf die MS Timeserver im Internet.

Gerade DEN Server lasse ich ungern Richtung Internet.

Und Enno findet die Idee NTP via IP zu verteilen nicht schön. Kann ich nachvollziehen, ist aber im Produktionsumfeld nicht immer machbar.

[Master112]

Also Problem gelöst wie folgt:

 

1) Auf den ESX Hosts den Haken als Zeitgeber entfernt

2) Auf dem Domänencontroller (PDC) in der cmd den Befehl abgesetzt, sich die aktuelle Zeit von den entsprechenden Servern zu ziehen und einen w32tm /resync durchgeführt. DC hatte danach die richtige Uhrzeit

3) Da ich nicht auf den Poll der restlichen Memberserver warten wollte, habe ich auf jeden meiner 10VMs eben den Befehl "net time \\"domänencontroller" /set abgesetzt und danach hat er sich die Zeit vom PDC gezogen.

 

Läuft jetzt ! Danke!