Zeitsynchronistation Windows Domäne
Hallo Zusammen,
wir haben bei uns in der Windows Domäne seit einiger Zeit Probleme mit der Zeitsynchronisation.
Ursache dafür ist vermute ich das hinzufügen einer Windows 2012 R2 als DC und anschließend wurde dieser auch mit allen FSMO Rollen bestückt.
Also die ausgabe für den Befehl netdom query fsmo zeigt für alle Rollen den neuen Server. Nennen wir Ihn DC01.
Es gibt noch zwei weitere DCs beides 2008 R2.
Die Uhrzeit auf allen mitgliedservern ist korrekt. Also entspricht der des PDC.
w32tm /query /source auf den Mitgliedservern bringt folgendes Ergebnis:
DC01.domäne.intra
w32tm /query /source auf verschiedenen Clients in der Domäne:
local cmos clock
w32tm /resync auf den Mitgliedservern bringt folgendes Ergebnis:
Der Befehl wurde erfolgreich ausgeführt.
w32tm /resync auf verschiedenen Clients in der Domäne:
... es sind keine Zeitdaten vorhanden
So ich bin hier im Haus leider durch Mitarbeiterabbau etc... egal, der Mann dr das richten darf. Meine Schwerpunkte liegen aber eig. wo anders. Egal.
Zu dem DC01 und dem DC02 ist noch zu sagen das diese auf ESX VMWare Hosts als VM liegen. Die zeitsynchronisation über die VMWare Tools ist aber nicht aktiviert.
Die getesteten Clients sind alles Windows Clients Win 7, Win 8 und Win 10. Bei allen das gleiche Ergebnis.
Hat hier jemand eine art Anleitung für mich wie ich diesem Fehler auf die Spur kommen kann.
Ich bin für jeden Tipp dankbar.
Beste Grüße
Marco
wir haben bei uns in der Windows Domäne seit einiger Zeit Probleme mit der Zeitsynchronisation.
Ursache dafür ist vermute ich das hinzufügen einer Windows 2012 R2 als DC und anschließend wurde dieser auch mit allen FSMO Rollen bestückt.
Also die ausgabe für den Befehl netdom query fsmo zeigt für alle Rollen den neuen Server. Nennen wir Ihn DC01.
Es gibt noch zwei weitere DCs beides 2008 R2.
Die Uhrzeit auf allen mitgliedservern ist korrekt. Also entspricht der des PDC.
w32tm /query /source auf den Mitgliedservern bringt folgendes Ergebnis:
DC01.domäne.intra
w32tm /query /source auf verschiedenen Clients in der Domäne:
local cmos clock
w32tm /resync auf den Mitgliedservern bringt folgendes Ergebnis:
Der Befehl wurde erfolgreich ausgeführt.
w32tm /resync auf verschiedenen Clients in der Domäne:
... es sind keine Zeitdaten vorhanden
So ich bin hier im Haus leider durch Mitarbeiterabbau etc... egal, der Mann dr das richten darf. Meine Schwerpunkte liegen aber eig. wo anders. Egal.
Zu dem DC01 und dem DC02 ist noch zu sagen das diese auf ESX VMWare Hosts als VM liegen. Die zeitsynchronisation über die VMWare Tools ist aber nicht aktiviert.
Die getesteten Clients sind alles Windows Clients Win 7, Win 8 und Win 10. Bei allen das gleiche Ergebnis.
Hat hier jemand eine art Anleitung für mich wie ich diesem Fehler auf die Spur kommen kann.
Ich bin für jeden Tipp dankbar.
Beste Grüße
Marco
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 304886
Url: https://administrator.de/forum/zeitsynchronistation-windows-domaene-304886.html
Ausgedruckt am: 13.04.2025 um 16:04 Uhr
28 Kommentare
Neuester Kommentar
Hallo Marco
Ok
Hast du mal auf einem Mitgliedsserver
ausgeführt?
Gruss Urs
w32tm /query /source auf den Mitgliedservern bringt folgendes Ergebnis:
DC01.domäne.intra
DC01.domäne.intra
Ok
w32tm /query /source auf verschiedenen Clients in der Domäne:
local cmos clock
nicht ok, hier sollte ebenfalls DC01.domäne.intra kommenlocal cmos clock
Hast du mal auf einem Mitgliedsserver
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
Zu dem DC01 und dem DC02 ist noch zu sagen das diese auf ESX VMWare Hosts als VM liegen. Die zeitsynchronisation über die VMWare Tools ist aber nicht aktiviert.
OkGruss Urs
Hallo Marc,
wie @Meierjo schreibt solltest du dem DC der jetzt nicht mehr die PDC-Emulator Rolle inne hat seine Zeitsyncquelle umstellen und den Zeitdienst neu starten.
Auf dem DC auf den du die PDC-Emulator-Rolle verschoben hast konfigurierst du dann eine manuelle Zeitquelle (ebenfalls mit anschließendem Neustart des Zeitdienstes):
Ich denke das das noch nicht vorgenommen wurde und deswegen die Clients keine "verlässliche" Zeitquelle nutzen konnten.
Eine gute Erklärung für die Funktionsweise der Zeitsynchronisation innerhalb von Domänen findest du hier:
“It’s Simple!” – Time Configuration in Active Directory
und hier
Time Synchronization in Active Directory Forests
Danach sollten deine Domainjoined-Clients wieder die korrekte Zeit erhalten.
Sollten die Clients dann trotzdem noch immer nicht die Zeit vom DC erhalten, konfiguriere eine GPO für die Workstations
mit dem Wert NT5DS als Typ.
Grüße Uwe
wie @Meierjo schreibt solltest du dem DC der jetzt nicht mehr die PDC-Emulator Rolle inne hat seine Zeitsyncquelle umstellen und den Zeitdienst neu starten.
w32tm /config /syncfromflags:domhier /update
Auf dem DC auf den du die PDC-Emulator-Rolle verschoben hast konfigurierst du dann eine manuelle Zeitquelle (ebenfalls mit anschließendem Neustart des Zeitdienstes):
w32tm /config /manualpeerlist:de.pool.ntp.org /syncfromflags:manual /reliable:yes /update
Eine gute Erklärung für die Funktionsweise der Zeitsynchronisation innerhalb von Domänen findest du hier:
“It’s Simple!” – Time Configuration in Active Directory
und hier
Time Synchronization in Active Directory Forests
Danach sollten deine Domainjoined-Clients wieder die korrekte Zeit erhalten.
Sollten die Clients dann trotzdem noch immer nicht die Zeit vom DC erhalten, konfiguriere eine GPO für die Workstations
Computer Configuration\Policies\Administration Templates\System\Windows Time Service\Time Providers\Configure Windows NTP Client
Grüße Uwe
Die GPO über WMI Filtering bringt mich denke ich neicht weiter da diese sich aj auf Computer mit DomainRole 5 auswirken soll also den PDC.
Nee, nicht diese GPO nehmen sondern die für die Clients die ich oben gepostet habe! Dort sollte als Typ NT5DS angegeben werdenComputer Configuration\Policies\Administration Templates\System\Windows Time Service\Time Providers\Configure Windows NTP Client
Diese natürlich nur auf die OU der Client-Computer anwenden.
Dann muss auf dem Client beim Ausführen von
w32tm /query /configuration
[Zeitanbieter]
NtpClient (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
CrossSiteSyncFlags: 2 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Lokal)
ResolvePeerBackoffMaxTimes: 7 (Lokal)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 1 (Lokal)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 3600 (Lokal)
Type: NT5DS (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 0 (Lokal)
InputProvider: 0 (Lokal)
Type: NT5DS (Lokal)
Wenn dort nicht NT5DS steht ist was oberfaul am Client.
Lösch auch mal den DNS-Cache am Client.
Was sagt das Eventlog dazu, es muss dort eine Meldung dazu am Client geben.
Ansonsten kannst du mal testweise versuchen den Client auf einen bestimmten DC den (am besten den PDC) zu zwingen um die anderen DCs als Fehlerquelle auszuschließen:
https://technet.microsoft.com/library/cc957290
http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/A ...
Da wurde definitiv bei der Migration etwas übersehen oder falsch gemacht. Hmm...
Ansonsten kannst du mal testweise versuchen den Client auf einen bestimmten DC den (am besten den PDC) zu zwingen um die anderen DCs als Fehlerquelle auszuschließen:
https://technet.microsoft.com/library/cc957290
http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/A ...
Da wurde definitiv bei der Migration etwas übersehen oder falsch gemacht. Hmm...
Hallo Marco
Sehe grade in deinen Logs, das beim Befehl w32tm /query /Status jeweils Stratum=0 (nicht angegeben) erscheint
Beim meinem (korrekt funktionierenden Client) erscheint hier Stratum: 2 (Sekundärreferenz - synchr. über (s)NTP)
Probier doch mal Folgendes:
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
http://serverfault.com/questions/611671/windows-ntp-server-a-stratum-is ...
Gruss
Sehe grade in deinen Logs, das beim Befehl w32tm /query /Status jeweils Stratum=0 (nicht angegeben) erscheint
Beim meinem (korrekt funktionierenden Client) erscheint hier Stratum: 2 (Sekundärreferenz - synchr. über (s)NTP)
Probier doch mal Folgendes:
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
http://serverfault.com/questions/611671/windows-ntp-server-a-stratum-is ...
Gruss
Dann solltest du mal die betreffenden Registry-Keys der Clients mit einem funktionsfähigen Client vergleichen.
https://technet.microsoft.com/en-us/library/cc773263.aspx#w2k3tr_times_t ...
Mehr kann ich dazu jetzt leider nicht mit Forumsmitteln beisteuern.
Grüße Uwe
https://technet.microsoft.com/en-us/library/cc773263.aspx#w2k3tr_times_t ...
Mehr kann ich dazu jetzt leider nicht mit Forumsmitteln beisteuern.
Grüße Uwe
HP 1810G:
Autsch das tut weh, kein Wunder Hier noch der Link für eine Erklärung und für die Nachwelt:
http://louwrentius.com/hp-procurve-auto-dos-feature-causing-network-pro ...
If you enable the Auto DoS feature, traffic is blocked based on one of these conditions:
- the source port (TCP / UDP) is identical to the destination port (NTP, SYSLOG, etc)
- the source port (TCP / UDP) is 'privileged' thus in the range of 1 -1023.
Ich könnte mir in den Arsch beißen! Ein Haken und alles läuft!
Mach das nicht, schmeiß lieber die HP Gurke beim nächsten Upgrade auf den Sondermüll Also vielen Dank für eure Unterstützung!
you're welcomeGrüße Uwe