Maniska Geschrieben 14. Juli 2020 Teilen Geschrieben 14. Juli 2020 Hallo zusammen ich habe heute festgestellt, dass ich wohl ein kleines Timingproblem in meiner Domäne habe. Es gibt 2 Standorte: Hauptstandort mit DC1, Server 2012, Altlast, war früher PDC und lebt nur deshalb noch weil er in ein paar alten nicht Windowssystemen noch als DNS Server eingetragen ist DC2, Server 2016, neuer PDC DC4, Server 2016 Niederlassung DC3 und DC5, beides Server 2016 Was ist passiert: Heute morgen hat mein Monitoring gemeckert, dass die DCs 3+5 ~97 Sekunden falsch gehen. Nach Prüfung hat der DC 5 die Zeit vom DC 3 übernommen, dieser wiederum hat seine Zeit von der "Local CMOS Clock", sagt er. Plötzlioch ploppen immer mehr Server im Montitoring auf, diesmal alle mit dem selben Zeitversatz von ~107 Sekunden. Also mal nachgeschaut "W32tm /query /status" Im Hauptstandort findet sich dort "überall" als Quelle der DC1, in der Niederlassung der DC3, beide holen sich ihre Zeit von der "Local CMOS Clock" und gehen 107 bzw 97 Sekunden vor (im VErgelich zum PDC der auch das Monitoring befeuert) Wie sollte es eigentlich aussehen? Der PDC holt sich die Zeit von pool.ntp.org und veteilt (in der Domäne) diese Zeit via GPO. Hierzu gibt es in Summe 3 GPOs die (unter anderem) das Zeitthema anfassen: PDC-NTP, liegt auf der OU "Domain Controllers", ist erzwungen und hat den WMI Filter "PDC-Server" --> Select * from Win32_ComputerSystem where DomainRole = 5 Dort ist unter Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Windows-Zeitdienst - Zeitanbieter konfiguriert: Windows NTP-Client aktivieren -> aktiv Windows NTP-Client konfigurieren-> aktiv (pool.ntp.org , NTP, 2, 15, 7, 1024, 1) Windows NTP-Serveraktivieren -> aktiv Default Server, liegt auf dem Domain Root und hat den WMI Filter "Win-Servern inkl DCs" --> select * from Win32_OperatingSystem where ProductType="2" or ProductType="3" Dort ist unter Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Windows-Zeitdienst - Zeitanbieter konfiguriert: Windows NTP-Client aktivieren -> aktiv Windows NTP-Client konfigurieren-> aktiv (dc2.domain.local , NTP, 2, 15, 7, 1024, 1) Windows NTP-Serveraktivieren -> aktiv Default Client, liegt auf dem Domain Root und hat den WMI Filter "Win-Clieet" --> select * from Win32_OperatingSystem where ProductType="1" Dort ist unter Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Windows-Zeitdienst - Zeitanbieter konfiguriert: Windows NTP-Client aktivieren -> aktiv Windows NTP-Client konfigurieren-> aktiv (dc2.domain.local , NTP, 2, 15, 7, 1024, 1) Windows NTP-Serveraktivieren -> aktiv Was habe ich gemacht dass das verursachen könnte Nichts Ich habe die GPOs aufgeräumt, also versucht die gefühlten 50 Objekte sinnvoll zusammen zu fassen und die GPOs möglichst weit oben aufzuhängen, daher auch die Default Client/Server/User GPO. Ich habe die Einstellungen jeder einzelnen Richtlinie 1 zu 1 in die neue Übertragen und bei Widersprüchen geschaut, was davon früher gezogen hat und was eigentlich richtig wäre. Wenn ich auf einen betroffen eGerät schauen, werden die GPOs auch gezogen, laut der Überprüfung der Gruppenrichtlinenergebnisse auf dem DC passt alles, aber es wird nicht übernommen. Ich finde auch nichts woher die Server den DC1 bzw3 haben könnten, und selbst wenn ich händisch versuche die EInstellungen anzupassen (cmd oder Registry) bleiben die falschen Einstellungen hartnäckig stehen. Aktuell habe ich mir so beholfen, dass ich bei den DC1 und 3 die Zeit manuell angepasst habe, damit zumindest das Offset weg ist, aber das ist ja keine Lösung. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
maximemelian Geschrieben 14. Juli 2020 Teilen Geschrieben 14. Juli 2020 Laufen die Server in einem vCenter o.ä.? Nicht, dass durch die VMware Tools eine falsche Zeit reingereicht wird, die deine Bemühungen übern Haufen wirft. Das war bei mir mal das Problem. Ich hatte teils Zeitabweichungen von mehreren Minuten(!) nachdem ich die Uhr am vCenter gestellt hab ging auch alles wieder... o_O Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Maniska Geschrieben 14. Juli 2020 Autor Teilen Geschrieben 14. Juli 2020 ESX-hosts und vCenter ziehen sich die Zeit auch vom PDC und gehen soweit ich das sehe auch richtig. Für mich ist halt merkwürdig, dass ich null nachvollziehen kann wer sich warum wo bedient. Soll: PDC holt von außen und alles was nicht Windows ist holt sich bei ihm (über die IP) die Zeit, also auch die ESXe am Hauptstandort ESX in der Niederlassung holt vom DC3 Alles was Windowsdomäne ist sollte sich beim PDC bedienen (selbst wenn er den ESX nimmt, der holt vom PDC.. also müsste das über den Weg auch passen) Ist: PDC holt von außen und alles was nicht Windows ist holt sich bei ihm (über die IP) die Zeit, also auch die ESXe am Hauptstandort ESX in der Niederlassung holt vom DC3, da beißt sich also die Katze in den Schwanz Alles was Windowsdomäne ist holt von einem komplett anderen DC, und ich weiß nicht warum... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
varafisi Geschrieben 14. Juli 2020 Teilen Geschrieben 14. Juli 2020 Das selbe Problem hatten wir gestern auch. Wir haben in unserer Shipping Software Anfragen an den SQL Server gestellt, der zu einem Zeitpunkt 9:05 auf der Uhr hatte und der Client einfach mal 09:08 also 3 Minuten in der Zukunft war. Grund war hierfür, dass ein auf den Ausschluss vorbereiteter DC der 01er immernoch als Zeitserver genommen wurde, den wir über den DHCP mit verteilen. Hier müssen wir ggf. nochmal schauen, wo wir noch eine Einstellung vergessen haben. Die Lösung dahinter war, den W32time Dienst zu beenden und neu anzustarten. Den W32Time-Resync haben wir auf die Microsoft Vorgabe von einer viertel Stund gesetzt also 900 Sekunden. Nach mehreren Sync Zeiten waren die Server und die Clients wieder im Lot und konnten erfolgreichen Traffic generieren. Das war ein Akt..... 4 Stunden dieser Sch***... So ganz kann ich mir das immer noch nicht erklären.... der 01er zieht sich die Zeit über 2 PTB Server in Braunschweig (meine ich) und übernimmt dort die Zeit. Deshalb haben wir den 01er als Zeitserver definiert aber dennoch kommt es zu einer Verschiebung innerhalb des Netzwerks... Davor hatten wir die Resync-Zeit auf 24 Stunden. Könnte das evtl. mit erhöhtem Datentraffic zu tun haben? Ich weiß zwar nicht wann der Resync vom DC mit den Zeitservern stattfindet aber ich könnte mir vorstellen, dass der sich so um die späte Abendszeit mal seine Infos holt. Die Clients müssten dann aufgrund des hohen Datentraffic wegen den Backups die Zeit später ziehen... Das ist alles nur eine Vermutung aber wie gesagt, eine ganz kuriose Geschichte... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Enno Geschrieben 14. Juli 2020 Teilen Geschrieben 14. Juli 2020 Hast du daran gedacht das du die NTP Option auch per DHCP mitgeben kannst? IMHO waren das die Optionen 004 (veraltet) und 042 aktuell. Musst mal suchen. Nicht das da irgendwer mal rumgefummelt hat, dort was komisches mitgibt. Und das bisher nur nicht aufgefallen ist weil die alten GPO das überschrieben haben. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thanks-and-Goodbye Geschrieben 14. Juli 2020 Teilen Geschrieben 14. Juli 2020 Klärt zwar nicht das Zeitproblem, aber... vor 8 Stunden schrieb Maniska: war früher PDC "Früher" war mal zu NT4.0-Zeiten. Seit Windows 2000 ist die Bezeichnung PDC und BDC obsolet. Wir reden heute nur noch vom Träger der FSMO-Rollen und ggf. von einem RO-DC (readonly-DC). Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Maniska Geschrieben 15. Juli 2020 Autor Teilen Geschrieben 15. Juli 2020 vor 9 Stunden schrieb Chief Wiggum: Wir reden heute nur noch vom Träger der FSMO-Rollen ABER, es weiß jeder was ich meine und "PDC" ist bedeutend Kürzer wie "Träger der FSMO-Rollen" Das ist wie Tempo für Taschentuch, Schraubenzieher statt -dreher oder Meterstab vor 9 Stunden schrieb Enno: Hast du daran gedacht das du die NTP Option auch per DHCP mitgeben kannst? Wenn ich gewusst hätte, das das geht bestimmt, gleich mal gucken. Wobei ich mir davon nicht viel erhoffe, im Servernetz gibt es keine DHCP Range und die Serverleins haben alle eine feste Telefonnummer. /geschaut: es wird in allen Netzen nur 003 Router, 006 DNS, 045 Domäne und ggf. 044 WINS mitgegeben. ABER: welcher Weg ist denn der "richtige", "bessere"? Zeitserver über GPO oder DHCP? Bei GPO bekommen es alle Geräte mit die in der Domäne sind, egal ob DHCP oder static IP, bei DHCP bekommen es auch alle "nicht Windows" Geräte mit... Nur wie viele habe ich davon die DHCP nutzen *am Kopf kratz*. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Enno Geschrieben 15. Juli 2020 Teilen Geschrieben 15. Juli 2020 @Maniska wenn beides gleich Konfiguriert ist, dann auf beiden Wegen mitgeben. So erreichts du alle Domänen geräte die nicht DHCP machen = Server und alle DHCP Geräte die nicht in der Domäne hängen. Alle DHCP Domänengeräte eh. Bleiben dann also nur die übrig die weder DHCP machen noch in der Domäne sind. Allerdings löst das ja aktuell dein Problem nicht das die Uhrzeiten nicht syncron laufen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Maniska Geschrieben 15. Juli 2020 Autor Teilen Geschrieben 15. Juli 2020 So, nachdem ich nun meine "Default-Sever" umgehängt habe, die GPO Einstellungen für die Zeit also nicht mehr für die DCs greifen, laufen die DCs wieder synchron und bedienen sich auch brav beim PDC (ja, PDC, ich bleib dabei!!!) Es lag also wohl an den NTP Einstellungen der GPO, warum, weiß ich nicht. Bedeutet ich muss entweder meine "Default Server" umbasteln, eine "Default DC" erstellen oder NTP komplett aus den GPOs rausnehmen und mich auf die Domäne verlassen. Ich tendiere zu Letzterem, vor allem da sich die Memberserver nun bei "einem" DC bedienen und nicht beim DC2. Scheint also eh nicht ganz zu greifen das Teil... Verstehen tu ich es zwar nicht (Erklärung wäre herzlich willkommen) aber das ist ja nicht schlimm. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Eleu Geschrieben 15. Juli 2020 Teilen Geschrieben 15. Juli 2020 vor 33 Minuten schrieb Maniska: So, nachdem ich nun meine "Default-Sever" umgehängt habe, die GPO Einstellungen für die Zeit also nicht mehr für die DCs greifen, laufen die DCs wieder synchron und bedienen sich auch brav beim PDC (ja, PDC, ich bleib dabei!!!) Es lag also wohl an den NTP Einstellungen der GPO, warum, weiß ich nicht. Bedeutet ich muss entweder meine "Default Server" umbasteln, eine "Default DC" erstellen oder NTP komplett aus den GPOs rausnehmen und mich auf die Domäne verlassen. Ich tendiere zu Letzterem, vor allem da sich die Memberserver nun bei "einem" DC bedienen und nicht beim DC2. Scheint also eh nicht ganz zu greifen das Teil... Verstehen tu ich es zwar nicht (Erklärung wäre herzlich willkommen) aber das ist ja nicht schlimm. Alle Computer welche Mitglied in der Domäne sind beziehen die Uhrzeit von dem Domänencontroller mit den Betriebsmasterrollen Hier gefunden: https://mntechblog.de/ntp-zeitserver-im-active-directory-konfigurieren/ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
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.