19
NTP Exchange onprem
Hallo zusammen,
Wir haben einen Exchange Server 2016 (Vmware) welche die Zeit vom PDC im Netz zieht.
ich finde den Pool Interval von 32768s (9std) sehr lange.
Was ist hier Best Practice?
Vielen Dank und Grüsse,
PS C:\Users\adm> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0625000s
Root Dispersion: 0.0942708s
ReferenceId: 0x0A0A1920 (source IP: 10.xx.xx.xx)
Last Successful Sync Time: 19.04.2023 04:31:00
Source: Servername
Poll Interval: 15 (32768s)
Wir haben einen Exchange Server 2016 (Vmware) welche die Zeit vom PDC im Netz zieht.
ich finde den Pool Interval von 32768s (9std) sehr lange.
Was ist hier Best Practice?
Vielen Dank und Grüsse,
PS C:\Users\adm> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0625000s
Root Dispersion: 0.0942708s
ReferenceId: 0x0A0A1920 (source IP: 10.xx.xx.xx)
Last Successful Sync Time: 19.04.2023 04:31:00
Source: Servername
Poll Interval: 15 (32768s)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6835582664
Url: https://administrator.de/contentid/6835582664
Printed on: April 27, 2024 at 10:04 o'clock
19 Comments
Latest comment
Moin,
Gruß,
Dani
ich finde den Pool Interval von 32768s (9std) sehr lange.
wie groß ist Abweichung der Zeit auf dem Exchange Server im Vergleich zum PDC innerhalb den 9 Stunden? Dürften doch keine 5 Sekunden sein.Gruß,
Dani
Moin,
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen. Das führt (fast) immer zu Problemen.
my 2 cents
Erik
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen. Das führt (fast) immer zu Problemen.
my 2 cents
Erik
2Zitat von @erikro:
Moin,
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen. Das führt (fast) immer zu Problemen.
my 2 cents
Erik
Moin,
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen. Das führt (fast) immer zu Problemen.
my 2 cents
Erik
Schwachsinn. Wenn man weiß was man tut und einen Grund dazu hat, ist es kein Problem. Wenn eine von diesen beiden Bedingungen nicht zutrifft, sollte man es lassen.
Ich hatte heute ein Benutzer der eine Kalenderzeit abweichung hatte, ich habe dann mit w32tm die Zeitsynchronisierung auf dem Exchange kontrolliert und diese Angaben (9std) gefunden.
Gibt es eine Best Practice - in welchem Intervall Exchange Server die Zeit beim PDC abholen sollen?
Danke
Gibt es eine Best Practice - in welchem Intervall Exchange Server die Zeit beim PDC abholen sollen?
Danke
Dürften doch keine 5 Sekunden sein.
Wohl eher unter 1 Sekunde!Lesenwert dazu:
Wenn man in Tokio einen Server dem NTP-Pool hinzufügt
Moin,
Naja, dann sind halt die Erfahrungen, die ich, seit es AD gibt, und auch schon vorher mit NT gemacht habe, Schwachsinn. Ich würde mal behaupten, dass jeder Kollege, der Erfahrung hat, den Schwachsinn bestätigen wird.
Und welcher Grund sollte das sein?
Liebe Grüße
Erik
Naja, dann sind halt die Erfahrungen, die ich, seit es AD gibt, und auch schon vorher mit NT gemacht habe, Schwachsinn. Ich würde mal behaupten, dass jeder Kollege, der Erfahrung hat, den Schwachsinn bestätigen wird.
Wenn man weiß was man tut und einen Grund dazu hat
Und welcher Grund sollte das sein?
Liebe Grüße
Erik
1
Macht Ihr die GPO für NTP für die DC's und die Memberserver - oder jeweils nur für die DC's?
Moin,
Auch wenn das einige als Schwachsinn bezeichnen, nochmal deutlich:
In einer Windows-Domain muss keine NTP-Konfiguration vorgenommen werden. Davon gibt es nur eine Ausnahme. Das ist der PDC-Emulator. Nur bei diesem sollte eine externe Zeitquelle konfiguriert werden. Alle anderen Rechner (Server wie Clients) beziehen ihre Zeit letztlich vom PDC-Emulator der Domain. Deshalb nochmal: Finger weg vom NTP in der Windows-Domain.
Liebe Grüße
Erik
Zitat von @adrian138:
Macht Ihr die GPO für NTP für die DC's und die Memberserver - oder jeweils nur für die DC's?
Macht Ihr die GPO für NTP für die DC's und die Memberserver - oder jeweils nur für die DC's?
Auch wenn das einige als Schwachsinn bezeichnen, nochmal deutlich:
In einer Windows-Domain muss keine NTP-Konfiguration vorgenommen werden. Davon gibt es nur eine Ausnahme. Das ist der PDC-Emulator. Nur bei diesem sollte eine externe Zeitquelle konfiguriert werden. Alle anderen Rechner (Server wie Clients) beziehen ihre Zeit letztlich vom PDC-Emulator der Domain. Deshalb nochmal: Finger weg vom NTP in der Windows-Domain.
Liebe Grüße
Erik
Zitat von @erikro:
Moin,
Auch wenn das einige als Schwachsinn bezeichnen, nochmal deutlich:
In einer Windows-Domain muss keine NTP-Konfiguration vorgenommen werden. Davon gibt es nur eine Ausnahme. Das ist der PDC-Emulator. Nur bei diesem sollte eine externe Zeitquelle konfiguriert werden. Alle anderen Rechner (Server wie Clients) beziehen ihre Zeit letztlich vom PDC-Emulator der Domain. Deshalb nochmal: Finger weg vom NTP in der Windows-Domain.
Liebe Grüße
Erik
Moin,
Zitat von @adrian138:
Macht Ihr die GPO für NTP für die DC's und die Memberserver - oder jeweils nur für die DC's?
Macht Ihr die GPO für NTP für die DC's und die Memberserver - oder jeweils nur für die DC's?
Auch wenn das einige als Schwachsinn bezeichnen, nochmal deutlich:
In einer Windows-Domain muss keine NTP-Konfiguration vorgenommen werden. Davon gibt es nur eine Ausnahme. Das ist der PDC-Emulator. Nur bei diesem sollte eine externe Zeitquelle konfiguriert werden. Alle anderen Rechner (Server wie Clients) beziehen ihre Zeit letztlich vom PDC-Emulator der Domain. Deshalb nochmal: Finger weg vom NTP in der Windows-Domain.
Liebe Grüße
Erik
Im Großen und Ganzen korrekt. Mein "Schwachsinn" bezieht sich auf deine Aussage
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen.
Und dazu stehe ich auch. Sag niemals nie. Kunde von mir hatte Probleme mit seiner Telefonanlage. Die waren darauf zurück zu führen, dass der Domänencontroller keine Zeit vom NTP-Server bekommen hat.
Zitat von @3063370895:
Im Großen und Ganzen korrekt. Mein "Schwachsinn" bezieht sich auf deine Aussage
Im Großen und Ganzen korrekt. Mein "Schwachsinn" bezieht sich auf deine Aussage
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen.
Das ist im Zusammenhang kein Schwachsinn. Es geht hier um die Konfiguration eines Mitgliedsservers. Daran ändert man niemals etwas.
Und dazu stehe ich auch. Sag niemals nie. Kunde von mir hatte Probleme mit seiner Telefonanlage. Die waren darauf zurück zu führen, dass der Domänencontroller keine Zeit vom NTP-Server bekommen hat.
Ein DC oder der PDC-Emulator? Wie gesagt, das ist die Ausnahme von der Regel, da der PDC-Emulator der Herr über die Zeit in der Domain ist und daher erstmal keinen Zeitserver hat. Alle anderen haben automatisch einen.
Das ist im Zusammenhang kein Schwachsinn. Es geht hier um die Konfiguration eines Mitgliedsservers. Daran ändert man niemals etwas.
Geb ich dir recht. Aber:
Deine Aussage war ganz klar
niemals, wirklich niemals an den NTP-Einstellungen der Domain spielen.
Sie war sehr generell gehalten und nicht auf einen Mitgliedsserver bezogen.
Als du sie dann etwas spezifiziert hast, habe ich dir ja auch zugestimmt. Aber die generelle Aussage
Niemals irgendwas an NTP in einer Domain ändern
ist und bleibt Schwachsinn.
Wie kommt der PDC-Emulator an seine Zeit, wenn man nicht "irgendwas an NTP in einer Domain ändert"?
Hi,
Erik hat recht, an der Zeit pfuscht man in der Domäne nicht rum, das funktioniert out of the Box hervorragend. Nur den PDC konfiguriert man und fertig.
Falls der Rechner allerdings eine VM ist, kann die Zeit auch vom Host zur VM synchronisiert werden. Wenn dann der Host nach dem Mond geht…
Viele Grüsse
Markus
Erik hat recht, an der Zeit pfuscht man in der Domäne nicht rum, das funktioniert out of the Box hervorragend. Nur den PDC konfiguriert man und fertig.
Falls der Rechner allerdings eine VM ist, kann die Zeit auch vom Host zur VM synchronisiert werden. Wenn dann der Host nach dem Mond geht…
Viele Grüsse
Markus
N'Abend.
Cheers,
jsysde
Zitat von @3063370895:
Schwachsinn. Wenn man weiß was man tut und einen Grund dazu hat, ist es kein Problem. Wenn eine von diesen beiden Bedingungen nicht zutrifft, sollte man es lassen.
Wenn man weiß, was man tut - konfiguriert man seinen PDC-Emulator als NTP-Quelle und überlässt den Rest einfach der Domain-Hierarchie.Schwachsinn. Wenn man weiß was man tut und einen Grund dazu hat, ist es kein Problem. Wenn eine von diesen beiden Bedingungen nicht zutrifft, sollte man es lassen.
Cheers,
jsysde
Moin,
Typische Fehlerquelle. Deshalb stellt man das auch so ein, dass der VM-Host auch gegen den PDC-Emulator synchronisiert. Problem behoben.
Liebe Grüße
Erik
Zitat von @mmw2000:
Falls der Rechner allerdings eine VM ist, kann die Zeit auch vom Host zur VM synchronisiert werden. Wenn dann der Host nach dem Mond geht…
Typische Fehlerquelle. Deshalb stellt man das auch so ein, dass der VM-Host auch gegen den PDC-Emulator synchronisiert. Problem behoben.
Liebe Grüße
Erik
1
Moin,
Gruß,
Dani
Typische Fehlerquelle. Deshalb stellt man das auch so ein, dass der VM-Host auch gegen den PDC-Emulator synchronisiert. Problem behoben.
und das die VM keinen falls mit dem Host synchronisiert.Gruß,
Dani
1
Eben!
Hi
und darum eine "non-M$" Quelle als dedizierten Zeitserver im Netzwerk worauf sich dann die Geräte synchronisieren. Cisco Call Manager mag z.B. nicht so gern den Windows NTP Server, was weis ich warum (kann auch sein das es irgendwann nach CM9.x gefixt wurde) - das ganze natürlich im HA - darauf kann sich dann der PDC syncen und es für alle M$ Clients verteilen.
Eine MS Domain kann 5 min wegen Kerberos vertragen, wenn man mit MFA-OTP arbeitet sind 30s schon zu viel, es kommt immer darauf an, welche Anwendungen man hat, wichtig ist nur: es muss im gesamten Netz synchron sein, das gilt für einen DC, Client und ebenso dem ESXi , ansonsten kann man sich auch jede Art von Logging sparen, wenn erst immer die Zeiten abgleichen und umrechnen muss (lange Stunden des Log-Abgleichs haben dazu geführt das Thema "Zeit" im Netzwerk mal korrekt einzurichten :D )
Speziell bei Clients: Zeiterfassungsterminals sind auch so ein Sache, wenn z.B. zwei Terminal zueinander in Sichtweite stehen und die beiden nicht exakt die gleiche Zeit anzeigen, dann kommt mal ganz fix ein Anruf der Schichtleiter - denen ist egal ob die Zeit der Stempelung vom Buchungsprozess des Servers kommt - die syncen bei uns alle 300s/5min die Zeiten - das erspart uns den Mistgabel-Fackel-Mob der Kollegen aus der Produktion :p.
Just my 2 Cent
und darum eine "non-M$" Quelle als dedizierten Zeitserver im Netzwerk worauf sich dann die Geräte synchronisieren. Cisco Call Manager mag z.B. nicht so gern den Windows NTP Server, was weis ich warum (kann auch sein das es irgendwann nach CM9.x gefixt wurde) - das ganze natürlich im HA - darauf kann sich dann der PDC syncen und es für alle M$ Clients verteilen.
Eine MS Domain kann 5 min wegen Kerberos vertragen, wenn man mit MFA-OTP arbeitet sind 30s schon zu viel, es kommt immer darauf an, welche Anwendungen man hat, wichtig ist nur: es muss im gesamten Netz synchron sein, das gilt für einen DC, Client und ebenso dem ESXi , ansonsten kann man sich auch jede Art von Logging sparen, wenn erst immer die Zeiten abgleichen und umrechnen muss (lange Stunden des Log-Abgleichs haben dazu geführt das Thema "Zeit" im Netzwerk mal korrekt einzurichten :D )
Speziell bei Clients: Zeiterfassungsterminals sind auch so ein Sache, wenn z.B. zwei Terminal zueinander in Sichtweite stehen und die beiden nicht exakt die gleiche Zeit anzeigen, dann kommt mal ganz fix ein Anruf der Schichtleiter - denen ist egal ob die Zeit der Stempelung vom Buchungsprozess des Servers kommt
- die syncen bei uns alle 300s/5min die Zeiten - das erspart uns den Mistgabel-Fackel-Mob der Kollegen aus der Produktion :p.Just my 2 Cent
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!