Zum Inhalt springen

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


Master112

Empfohlene Beiträge

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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 :D

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb Maniska:

Ich hab mich schon gewundert wann das kommt :D

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. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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!

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...