Gu4rdi4n 58 Geschrieben 20. Dezember 2016 Melden Teilen Geschrieben 20. Dezember 2016 (bearbeitet) Hi, ich habe einen Server 2012 R2 auf dem AD läuft. Nun habe ich folgende Einstellungen gemacht: Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Syste, -> Windows-Zeitdienst -> Zeitanbieter Windows-NTP-Client aktivieren -> Aktiviert Windows-NTP-Client konfigurieren -> Aktiviert - NTP Server: 10.10.0.1,0x9 (meine Firewall) - Type: NTP - CrossSiteSyncFlags: 2 - ResolvePeerBackoffMinutes : 15 - ResolvePeerBackMaxTimes: 7 - SpecialPollInterval: 3600 - EventLogFlags: 0 Die GPO wird zwar gezogen, allerdings gibt mit w32tm /monitor folgendes aus: SRV1.Domain.de *** PDC ***[10.10.10.10:123]: ICMP: 0ms Verzögerung NTP: +0.0000000.s Offset von SRV1.Domain.de RefID: 80.84.77.86.rev.sfr.net [86.77.84.80] Stratum: 2 Der DHCP gibt keinen NTP mit. Eigentlich sollte er ja den NTP mit 10.10.0.1 vergeben. Kann mir jemand sagen was hier schief läuft? bearbeitet 20. Dezember 2016 von Gu4rdi4n Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 20. Dezember 2016 Melden Teilen Geschrieben 20. Dezember 2016 Wieso sollte der dhcp einen timeserver vergeben, wenn du das per gpo konfigurierst? Für das Thema timesync und gpo schau mal hier, bevor was schiefläuft. http://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 20. Dezember 2016 Autor Melden Teilen Geschrieben 20. Dezember 2016 (bearbeitet) Wieso sollte der dhcp einen timeserver vergeben, wenn du das per gpo konfigurierst? Für das Thema timesync und gpo schau mal hier, bevor was schiefläuft. http://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Das war ein bischen b***d geschrieben. Ich wollte nur sagen, dass im DHCP Server die bereichsoption 4 nicht aktiv ist Mit "Eigentlich sollte er..." meinte ich den AD Server Ich les es mir mal durch, danke! Kleine anmerkung noch: Der Hyper V Host zieht die richtlinie richtig und stellt auch den richtigen Zeitserver ein. Nur die VMs machen das nicht edit: Beim erstellen des WMI Filters bekomme ich folgende Meldung: bearbeitet 20. Dezember 2016 von Gu4rdi4n Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 20. Dezember 2016 Melden Teilen Geschrieben 20. Dezember 2016 Ich kann dir nur abraten da einen ntp Server per gpo zu verteilen. Lies dir mal den Link durch, dann wird auch klar, warum das die bessere Methode ist. 1 Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 20. Dezember 2016 Melden Teilen Geschrieben 20. Dezember 2016 Moin, erst Mal muss ich Norbert zustimmen. NTP richtig per GPO konfigurieren und das Thema ist gegessen. Möchtest Du wirklich, ich wiederhole _wirklich_, dass die VMs ihre Zeit von einem NTP und nicht vom Hypervisor beziehen, muss in den VM Eigenschaften/Integrationsdienste die Zeitsynchronisierung abgeschaltet werden. 1 Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 21. Dezember 2016 Autor Melden Teilen Geschrieben 21. Dezember 2016 (bearbeitet) Also momentan sieht die w32tm /monitor abfrage so aus: C:\Users\administrator.domain>w32tm /monitor Server1.domain.de *** PDC ***[10.10.10.10:123]: ICMP: 0ms Verzögerung NTP: +0.0000000s Offset von Server1.domain.de RefID: 80.84.77.86.rev.sfr.net [86.77.84.80] Stratum: 2 [Warnung] Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet. Soll man das dann also so lassen? Laut deinem Link soll man den PDC Emulator konfigurieren. Warum denn, wenn ich sowieso den standard timeserver nehme und nichts abändere? Moin, erst Mal muss ich Norbert zustimmen. NTP richtig per GPO konfigurieren und das Thema ist gegessen. Möchtest Du wirklich, ich wiederhole _wirklich_, dass die VMs ihre Zeit von einem NTP und nicht vom Hypervisor beziehen, muss in den VM Eigenschaften/Integrationsdienste die Zeitsynchronisierung abgeschaltet werden. Also doch konfigurieren, aber nur die VM's die Zeit vom Hyper V host ziehen lassen? Ich blick jetzt nichtmehr so ganz durch was gut und was nicht gut ist. bearbeitet 21. Dezember 2016 von Gu4rdi4n Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 21. Dezember 2016 Melden Teilen Geschrieben 21. Dezember 2016 Wenn deine Clients Mitglied der Domäne sind, lass alles so wie es ist (keine externen ntp Server für die Clients), oder konfiguriere es nach dem how to. So schwer zu verstehen ist das doch nicht. ;) Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 21. Dezember 2016 Autor Melden Teilen Geschrieben 21. Dezember 2016 ok, verstanden. Mich hat nur verwirrt was in deinem Link stand. "Viele Fragen in Foren und Newsgroups betreffen die Zeitsynchronisation innerhalb einer Domäne. Normalerweise funktioniert der Zeitabgleich automatisch und es muss nur der PDC Emulator entsprechend konfiguriert werden." Aber scheinbar muss ja nichts wirklich konfiguriert werden! Danke für die hilfe! :thumb1: Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 21. Dezember 2016 Melden Teilen Geschrieben 21. Dezember 2016 Doch der pdc muss seine Zeit ja irgendwo herbekommen. ;) Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 21. Dezember 2016 Autor Melden Teilen Geschrieben 21. Dezember 2016 Die bekommt er doch vom Hyper V Host oder nicht?! Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 21. Dezember 2016 Melden Teilen Geschrieben 21. Dezember 2016 (bearbeitet) Die bekommt er doch vom Hyper V Host oder nicht?! Und genau das sollte er ja nicht. Der Artikel ist zwar von 2010, hat aber sicherlich nichts an Aktualität verloren: http://www.faq-o-matic.net/2010/04/21/virtuelle-dcs-zeitprobleme-vermeiden/ EDIT: Noch einer: http://www.faq-o-matic.net/2012/05/16/zeitsynchronisation-in-virtuellen-umgebungen/ bearbeitet 21. Dezember 2016 von Sunny61 Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 21. Dezember 2016 Melden Teilen Geschrieben 21. Dezember 2016 Die bekommt er doch vom Hyper V Host oder nicht?! Nee sollte er hoffentlich nicht. Denn bei keiner konfiguration wird der ntp Server des Dcs irgendwann keine vertrauenswürdige Zeit mehr an die Clients liefern. Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 21. Dezember 2016 Melden Teilen Geschrieben 21. Dezember 2016 Moin, und woher bekommt der Host seine Zeit, wenn er AD-Mitglied ist? :rolleyes: Warum postet man dir hier Links, wenn du sie ignorierst? Der Artikel von Norbert auf Gruppenrichtlinien.de stellt den State of the Art dar. So macht man das, nicht anders. Zu dem Thema "Zeitabgleich mit dem VM-Host" hier noch ein Link zum Ignorieren: [Zeitsynchronisation in virtuellen Umgebungen | faq-o-matic.net]http://www.faq-o-matic.net/2012/05/16/zeitsynchronisation-in-virtuellen-umgebungen/ Meine Empfehlung dazu lautet, für alle DCs und alle AD-Mitglieder die Zeitsynchronisation mit dem Host abzuschalten. Gruß, Nils Zitieren Link zu diesem Kommentar
Gu4rdi4n 58 Geschrieben 22. Dezember 2016 Autor Melden Teilen Geschrieben 22. Dezember 2016 (bearbeitet) Ich habe die links nicht ignoriert. Ich bin nur sehr verwirrt. Einerseits schreibt ihr hier:"Ich kann dir nur abraten da einen ntp Server per gpo zu verteilen." dann "Wenn deine Clients Mitglied der Domäne sind, lass alles so wie es ist (keine externen ntp Server für die Clients), oder konfiguriere es nach dem how to" Um jetzt nochmal klarzustellen: Ich sollte den PDC emulator konfigurieren, damit der PDC die Firewall als Zeitgeber hat. Dazu muss ich in den Integrationsdiensten bei jeder VM die Zeitsynchronisierung abschalten Ich sollte NICHT die Clients auf den externen Zeitgeber einstellen, da diese die Zeit vom PDC bekommen richtig? @NilsK dein link sagt folgendes: "Um hier Probleme zu vermeiden, sollte der DC mit der PDCe-Rolle nicht virtualisiert sein, sondern auf Hardware laufen (alle anderen DCs können prinzipiell auch virtualisiert sein). Nur dieser Server sollte seine Zeit von einer externen Quelle holen, also einem NTP-Server im Internet oder einer lokalen Uhr." Ich habe allerdings nur einen DC und der ist Virtualisiert. Großes problem? Edit: im Link von Norbert steht noch das hier: "Schritt 2: eine Richtlinie für alle anderen Domänenmitglieder konfigurieren, um eine eventuelle Fehlkonfiguration zu korrigieren.Da diese Richtlinie für alle Computer innerhalb der Domäne gelten soll, ist es das Einfachste, diese auf Domänenebene zu verknüpfen, oder eventuell die Default Domain Policy dafür zu verwenden. Unabhängig davon für welche Variante man sich entscheidet, muss im Gruppenrichtlinieneditor die folgende Richtlinie aktiviert und konfiguriert werden:" Soll ich jetzt doch die Clients auf die Firewall setzen? Es hieß doch, dass ich alles so lassen soll? Die aussagen in dem link und hier widersprechen sich irgendwie. Oder habe ich gerade irgendwie tomaten auf den augen? bearbeitet 22. Dezember 2016 von Gu4rdi4n Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 22. Dezember 2016 Melden Teilen Geschrieben 22. Dezember 2016 Moin, also ... Du liest Norberts Artikel noch mal in Ruhe. Du prüfst, ob deine Firewall wirklich das bestgeeignete Gerät ist, um die Zeitquelle für alle zu sein. Du richtest die beiden Gruppenrichtlinien nach Norberts Artikel ein. Damit erreichst du, dass der PDC-Emulator auch nach einem Rollenwechsel korrekt konfiguriert ist. Außerdem korrigiert die Lösung auch Fehlkonfigurationen bei den Clients. Du stellst für alle Domänenmitglieder (DCs, Server, Clients) die Zeitsynchronisation mit dem VM-Host ab. Nur einen DC zu haben, ist grob fahrlässig, wenn es mehr als fünf oder zehn Unser gibt. (In dem Fall können wir uns aber auch den Aufwand hier sparen.) Wenn alle DCs virtuell sind, hat man eine ungünstige Abhängigkeit von der VM-Umgebung. Die Nachteile für den Zeitdienst sind dann eher sekundär. Und die von dir zitierten Aussagen widersprechen sich nicht. Du willst vielleicht noch mal über die Bedeutung des Worts "oder" nachdenken. Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.