28
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
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: 304886
Url: https://administrator.de/contentid/304886
Printed on: April 26, 2024 at 19:04 o'clock
28 Comments
Latest comment
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
Hallo Ihr,
danke für eure Antworten. Also ich habe das Update auf einem der Memberserver durchgeführt. Nach einem Resync zeigt der aber auch wieder brav auf den DC01.
Habe das dann auch auf dem ehemaligen PDC durchgeführt. Gleiches ergebnis.
Der neue DC wurde auch bereits in der Vergangenheit als zuverlässiger Zeitgeber konfiguriert. Der holt sich aktuell die Zeit von der Uni Erlangen.
Ich habe mir die beiden Links noch nicht angesehen. Mach ich aber auf jedenfall noch.
Ich würde ungern die Zeitsynchronisation über die GPO machen. Weil wie ich das verstanden habe das ganze ja ohne zusätzlichen Eingriff durch GPO oder. irgendwelcher andere Hilfsmittel funktionieren.
Ich habe mal auf den Clients noch folgenden Befehle ausgeführt:
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfgbar waren.
w32tm /query /peers gibt folgendes aus:
Anzahl Peers: 1
Peer: DC01ASC.asc.intra
Status: Aktiv
Verbleibende Zeit: 180.5938504s
Modus: 3 (Client)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)
HostAbrufintervall: 8 (256s)
w32tm /query /status gibt folgendes aus:
Sprungindikator: 3(die letzte Minute umfasst 61 Sekunden)
Stratum: 0 (nicht angegeben)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0000000s
Stammabweichung: 0.0000000s
Referenz-ID: 0x00000000 (nicht angegeben)
Letzte erfolgr. Synchronisierungszeit: nicht angegeben
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)
w32tm /config /syncfromflags:domhier /update gibt folgendes aus:
Der Befehl wurde erfolgreich ausgefhrt.
Allerdings führt der Befehl nicht an allen Clients zu einer korrektur der Zeit. Bei meinem Arbeitsplatz aber schon.
Ich mach jetzt nochmal einen Neustart von meinem PC und werde schaue ob das irgendwelche Verbesserung bringt!
Grüße
danke für eure Antworten. Also ich habe das Update auf einem der Memberserver durchgeführt. Nach einem Resync zeigt der aber auch wieder brav auf den DC01.
Habe das dann auch auf dem ehemaligen PDC durchgeführt. Gleiches ergebnis.
Der neue DC wurde auch bereits in der Vergangenheit als zuverlässiger Zeitgeber konfiguriert. Der holt sich aktuell die Zeit von der Uni Erlangen.
Ich habe mir die beiden Links noch nicht angesehen. Mach ich aber auf jedenfall noch.
Ich würde ungern die Zeitsynchronisation über die GPO machen. Weil wie ich das verstanden habe das ganze ja ohne zusätzlichen Eingriff durch GPO oder. irgendwelcher andere Hilfsmittel funktionieren.
Ich habe mal auf den Clients noch folgenden Befehle ausgeführt:
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfgbar waren.
w32tm /query /peers gibt folgendes aus:
Anzahl Peers: 1
Peer: DC01ASC.asc.intra
Status: Aktiv
Verbleibende Zeit: 180.5938504s
Modus: 3 (Client)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)
HostAbrufintervall: 8 (256s)
w32tm /query /status gibt folgendes aus:
Sprungindikator: 3(die letzte Minute umfasst 61 Sekunden)
Stratum: 0 (nicht angegeben)
Pr„zision: -6 (15.625ms pro Tick)
Stammverz”gerung: 0.0000000s
Stammabweichung: 0.0000000s
Referenz-ID: 0x00000000 (nicht angegeben)
Letzte erfolgr. Synchronisierungszeit: nicht angegeben
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)
w32tm /config /syncfromflags:domhier /update gibt folgendes aus:
Der Befehl wurde erfolgreich ausgefhrt.
Allerdings führt der Befehl nicht an allen Clients zu einer korrektur der Zeit. Bei meinem Arbeitsplatz aber schon.
Ich mach jetzt nochmal einen Neustart von meinem PC und werde schaue ob das irgendwelche Verbesserung bringt!
Grüße
Also der Neustart hat natürlich nichts gebracht.
Habe die GPo für meien Computer erstellt. Habe den Wert auc hin der Registry überprüft. Also unter HKLC ... w32time ... parameters
Keine Besserung. Es werden immer noch keine Zeitdaten gefunden. Wie gesagt was mich stutzig macht das nur Windows Clients Probleme haben. Server also nicht DCs bekommen die korrekte Urzeit und zeigen mittels w32tm /query /source auch an das Sie diese über den DC01 beziehen.
an meinem Client ist mir noch fogender Eintrag im Windows Log aufgefallen. Vermute aber das dieser ok ist.
Time-Server ID 158
Der Zeitanbieter 'VMICTimeProvider' hat angegeben, dass die aktuelle Hardware- und Betriebssystemumgebung nicht unterstützt wird und beendet wurde. Dieses Verhalten wird für VMICTimeProvider in Nicht-HyperV-Gastumgebungen erwartet. Dies kann auch das vom aktuellen Anbieter erwartete Verhalten in der aktuellen Betriebsumgebung sein.
Arbeite mich eben mal durch die beiden Links und lerne mal ein bischen dazu
Bis später.
Habe die GPo für meien Computer erstellt. Habe den Wert auc hin der Registry überprüft. Also unter HKLC ... w32time ... parameters
Keine Besserung. Es werden immer noch keine Zeitdaten gefunden. Wie gesagt was mich stutzig macht das nur Windows Clients Probleme haben. Server also nicht DCs bekommen die korrekte Urzeit und zeigen mittels w32tm /query /source auch an das Sie diese über den DC01 beziehen.
an meinem Client ist mir noch fogender Eintrag im Windows Log aufgefallen. Vermute aber das dieser ok ist.
Time-Server ID 158
Der Zeitanbieter 'VMICTimeProvider' hat angegeben, dass die aktuelle Hardware- und Betriebssystemumgebung nicht unterstützt wird und beendet wurde. Dieses Verhalten wird für VMICTimeProvider in Nicht-HyperV-Gastumgebungen erwartet. Dies kann auch das vom aktuellen Anbieter erwartete Verhalten in der aktuellen Betriebsumgebung sein.
Arbeite mich eben mal durch die beiden Links und lerne mal ein bischen dazu
Bis später.
Die GPO brauchst du nur einmal anwenden danach sollten die Clients auch wieder auf der Spur sein.
Hatte das Verfahren schon mal bei der Umstellung einer größeren Domain (>500 Clients) angewendet. Hat dort zuverlässig geholfen. Ansonsten hast du ganz andere Probleme.
Hatte das Verfahren schon mal bei der Umstellung einer größeren Domain (>500 Clients) angewendet. Hat dort zuverlässig geholfen. Ansonsten hast du ganz andere Probleme.
Hi Meierjo,
also der Hotfix ist leider nicht geeignet für Win 10. Ich such mal nach einem FixIt für Windows 10. Aber wie gesagt das Problem tritt auf allen Client OS Rechnern auf. Egal ich schau mal.
also der Hotfix ist leider nicht geeignet für Win 10. Ich such mal nach einem FixIt für Windows 10. Aber wie gesagt das Problem tritt auf allen Client OS Rechnern auf. Egal ich schau mal.
Das mit der GPO habe ich wie gesagt für meinen Client getestet. Den interessiert diese Änderung aber nicht wirklich. Also das Verhalten ist gleich geblieben. Ich habe aber getestet ob die GPO auch wirklich gezogen hat. Laut Windows Log und Registry - > JA.
https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-c ...
Habe mir den Link mal durchgelesen und finde die Infos darin auch echt hilfreich. Also allgemein aber für mein Problem stellt das denke ich aber keine Lösung dar.
Es muss irgendwo eine Einstellung geben die alle Mitglieder mit der DomainRole 1 anders behandelt werden. Memberserver bekommen ja die korrekte Zeit. Wobei die Memberserver unterschiedliche Source ausgeben. Immer irgendeiner der DCs. Als Dc02 oder Dc03. Die DCs allerdings immer den PDC. Das müsste aber auch so richtig sein.
Die Frage ist doch jetzt warum die Clients mit der DomainRole 1 die Uhrzeit nicht finden können. Das ist der Unterschied welchen ich ausmachen konnte. Alles mit der Domain Role 1 will nicht.
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. Der macht aber meiner meinung nach was er soll. Kann es an einer Berechtigung liegen?
Ich werde nicht locker lassen bis hier die verdamte Uhrzeit passt! Arg!
Habe mir den Link mal durchgelesen und finde die Infos darin auch echt hilfreich. Also allgemein aber für mein Problem stellt das denke ich aber keine Lösung dar.
Es muss irgendwo eine Einstellung geben die alle Mitglieder mit der DomainRole 1 anders behandelt werden. Memberserver bekommen ja die korrekte Zeit. Wobei die Memberserver unterschiedliche Source ausgeben. Immer irgendeiner der DCs. Als Dc02 oder Dc03. Die DCs allerdings immer den PDC. Das müsste aber auch so richtig sein.
Die Frage ist doch jetzt warum die Clients mit der DomainRole 1 die Uhrzeit nicht finden können. Das ist der Unterschied welchen ich ausmachen konnte. Alles mit der Domain Role 1 will nicht.
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. Der macht aber meiner meinung nach was er soll. Kann es an einer Berechtigung liegen?
Ich werde nicht locker lassen bis hier die verdamte Uhrzeit passt! Arg!
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.
Das ist das Ergebnis von w32tm /query /configuration
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 10 (Lokal)
MaxPollInterval: 15 (Lokal)
MaxNegPhaseCorrection: 4294967295 (Lokal)
MaxPosPhaseCorrection: 4294967295 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 1 (Lokal)
UpdateInterval: 30000 (Lokal)
[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)
NtpServer (Lokal)
DllName: C:\WINDOWS\SYSTEM32\w32time.DLL (Lokal)
Enabled: 0 (Lokal)
InputProvider: 0 (Lokal)
ja das hatte ich schon richtig verstanden. Die eine GPO geht um DC Konfiguration. Also den zeitanbieter für due Domäne zu konfigurieren. Die andere soll die Konfiguration der Clients anpassen. Das habe ich aber auch gemacht und das brachte leider keinen Unterschied im Verhalten.
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 10 (Lokal)
MaxPollInterval: 15 (Lokal)
MaxNegPhaseCorrection: 4294967295 (Lokal)
MaxPosPhaseCorrection: 4294967295 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 1 (Lokal)
UpdateInterval: 30000 (Lokal)
[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)
NtpServer (Lokal)
DllName: C:\WINDOWS\SYSTEM32\w32time.DLL (Lokal)
Enabled: 0 (Lokal)
InputProvider: 0 (Lokal)
ja das hatte ich schon richtig verstanden. Die eine GPO geht um DC Konfiguration. Also den zeitanbieter für due Domäne zu konfigurieren. Die andere soll die Konfiguration der Clients anpassen. Das habe ich aber auch gemacht und das brachte leider keinen Unterschied im Verhalten.
Das wäre och die Ausgabe am PDC:
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 5 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
[Zeitanbieter]
NtpClient (Lokal)
DllName: C:\Windows\system32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Lokal)
ResolvePeerBackoffMaxTimes: 7 (Lokal)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 1 (Lokal)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 3600 (Lokal)
Type: NTP (Lokal)
NtpServer: ntp0.fau.de (Lokal)
NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 5 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
[Zeitanbieter]
NtpClient (Lokal)
DllName: C:\Windows\system32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Lokal)
ResolvePeerBackoffMaxTimes: 7 (Lokal)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 1 (Lokal)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 3600 (Lokal)
Type: NTP (Lokal)
NtpServer: ntp0.fau.de (Lokal)
NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
Das die Ausgabe an einem der Memberserver (also nicht DC)
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 10 (Lokal)
MaxPollInterval: 15 (Lokal)
MaxNegPhaseCorrection: 4294967295 (Lokal)
MaxPosPhaseCorrection: 4294967295 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 1 (Lokal)
UpdateInterval: 30000 (Lokal)
[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)
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 10 (Lokal)
MaxPollInterval: 15 (Lokal)
MaxNegPhaseCorrection: 4294967295 (Lokal)
MaxPosPhaseCorrection: 4294967295 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 1 (Lokal)
UpdateInterval: 30000 (Lokal)
[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)
Werf mal testweise einen Client aus der Domäne und joine ihn wieder.
p.s. Deine Codeschnippsel kannst du in einen Post schreiben, dazu musst du nicht jedes mal ein neues Kommentar posten! Merci.
p.s. Deine Codeschnippsel kannst du in einen Post schreiben, dazu musst du nicht jedes mal ein neues Kommentar posten! Merci.
Das die Ausgabe ean einem der Backup DCs
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
[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)
NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
[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)
NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
OK
Habe einen Client nun mal aus der Domäene raus, neustart durchgeführt, in die Domäne rein und Neustart. Keine Änderung im Verhalten!
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...
Also das mit dem Logonserver hat nix gebracht. Leider. Wäre auch zu schön gewesen.
Ich habe nachdem es ja ruhiger ist bei uns einfach mal die anderen beiden DCs heruntergefahren
Anschließend abgemeldet und mittels "set" den logonserver ermittelt. War dann natürlich der PDC. Rest war ja offline.
Hat aber nix geändert! arg!!
Ich habe nachdem es ja ruhiger ist bei uns einfach mal die anderen beiden DCs heruntergefahren
Anschließend abgemeldet und mittels "set" den logonserver ermittelt. War dann natürlich der PDC. Rest war ja offline.
Hat aber nix geändert! arg!!
Wie sieht es mit den Firewalls aus?
Hören DCs und Clients den NTP Port 123 ab und wird dieser auch nicht durch irgendwelche Security-Suiten blockiert?
Hören DCs und Clients den NTP Port 123 ab und wird dieser auch nicht durch irgendwelche Security-Suiten blockiert?
netstat -ano | findstr ":123"
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
Und auch mal ein
hinterher schicken und dann
Habt Ihr eventuell mehrere DNS-Server? Die würde ich auf jeden Fall auch nochmal die Einträge der DCs checken.
w32tm /resync /rediscover
w32tm /query /source
Hallo Zusammen,
also die DNS Server sind alle OK. Also die replikation ist nicht fehlerhaft etc. Es gibt ja auch überhaupt keine DNS Probleme.
Ich habe mal den Befehlt
w32tm /monitor gibt folgendes aus
Die AD-DC-Liste fr die Standarddom„ne wird abgerufen...
Analyse: -- -- -- (0 of 3)
DC01.domäne.loc * PDC *[x.x.x.1:123]:
ICMP: 0ms Verz”gerung
NTP: +0.0000000s Offset von DC01.domäne.loc
RefID: ntp0.ntpserverdeinerwahl.de [x.x.x.x]
Stratum: 2
DC02.domäne.loc[x.x.x.2:123]:
ICMP: 0ms Verz”gerung
NTP: -0.0216086s Offset von DC01.domäne.loc
RefID: DC01.domäne.loc [x.x.x.1]
Stratum: 3
DC03.domäne.loc[x.x.x.3:123]:
ICMP: 0ms Verz”gerung
NTP: -0.0065465s Offset von DC01.domäne.loc
RefID: DC01.domäne.loc [x.x.x.1]
Stratum: 3
[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.
Der DC03 (ist der alte PDC)
hatte vor einer Korrektur Stratum 0 da dieser seine Zeit von local cmos clock bezogen hat. Warum keine Ahnung. Egal. Habe das über einen /resync /rediscover behoben nun zeigt sich obiges Bild.
Am Client habe ich das anschließend auch probiert. Aber der Fehler bleibt gleich. /status zeigt keinen unterschied. Weiterhin Stratum 0 was aber nicht mehr bedeutet als das er local sein eigener Zeitserver ist. Also er hat seine zeit nicht von extern. Mein Chef will mit Sicherheit bald wissen was ich hier treibe und wo das Problem ist. Toll.
lg
also die DNS Server sind alle OK. Also die replikation ist nicht fehlerhaft etc. Es gibt ja auch überhaupt keine DNS Probleme.
Ich habe mal den Befehlt
w32tm /monitor gibt folgendes aus
Die AD-DC-Liste fr die Standarddom„ne wird abgerufen...
Analyse: -- -- -- (0 of 3)
DC01.domäne.loc * PDC *[x.x.x.1:123]:
ICMP: 0ms Verz”gerung
NTP: +0.0000000s Offset von DC01.domäne.loc
RefID: ntp0.ntpserverdeinerwahl.de [x.x.x.x]
Stratum: 2
DC02.domäne.loc[x.x.x.2:123]:
ICMP: 0ms Verz”gerung
NTP: -0.0216086s Offset von DC01.domäne.loc
RefID: DC01.domäne.loc [x.x.x.1]
Stratum: 3
DC03.domäne.loc[x.x.x.3:123]:
ICMP: 0ms Verz”gerung
NTP: -0.0065465s Offset von DC01.domäne.loc
RefID: DC01.domäne.loc [x.x.x.1]
Stratum: 3
[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.
Der DC03 (ist der alte PDC)
hatte vor einer Korrektur Stratum 0 da dieser seine Zeit von local cmos clock bezogen hat. Warum keine Ahnung. Egal. Habe das über einen /resync /rediscover behoben nun zeigt sich obiges Bild.
Am Client habe ich das anschließend auch probiert. Aber der Fehler bleibt gleich. /status zeigt keinen unterschied. Weiterhin Stratum 0 was aber nicht mehr bedeutet als das er local sein eigener Zeitserver ist. Also er hat seine zeit nicht von extern. Mein Chef will mit Sicherheit bald wissen was ich hier treibe und wo das Problem ist. Toll.
lg
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
Also das Problem ist gelöst!
Hat nichts mit Windows Konfiguration oder so zu tun gehabt. Unser Switch über den alle Cliens angschlossen sind ist die Ursache. Bzw. irgend etwas auf dem Weg dorthin. Ich habe mal testweise 3 Clients direkt in unserem Serverraum aangeschlossen und dort an den selben Switch wiue alle Server und ESX angeschlossen. Und es geht!
Vielen Dank für eure Mühe und Geduld. Ich bin begeistert!
Juhu Gelöst!! Und dabei viel über w32tm gelernt)
Hat nichts mit Windows Konfiguration oder so zu tun gehabt. Unser Switch über den alle Cliens angschlossen sind ist die Ursache. Bzw. irgend etwas auf dem Weg dorthin. Ich habe mal testweise 3 Clients direkt in unserem Serverraum aangeschlossen und dort an den selben Switch wiue alle Server und ESX angeschlossen. Und es geht!
Vielen Dank für eure Mühe und Geduld. Ich bin begeistert!
Juhu Gelöst!! Und dabei viel über w32tm gelernt
)
Danke für die abschließende Info, wäre interessant was die Switche gefiltern haben, wenn du das noch rausfinden kannst wäre das vielleicht für den ein oder anderen noch interessant (L3 Switch? /Switch-Logs / WIreshark etc.), nur wenn die Zeit es natürlich zulässt 
.
Grüße Uwe
.Grüße Uwe
Hallo Zusammen,
es funktioniert. Ich habe mir die Config vom Switch angeschaut.
HP 1810G:
Security -> Advanced Security
Dort die Option Auto DoS deaktivieren! Fertig!
Ich könnte mir in den Arsch beißen! Ein Haken und alles läuft!
Also vielen Dank für eure Unterstützung!
LG
es funktioniert. Ich habe mir die Config vom Switch angeschaut.
HP 1810G:
Security -> Advanced Security
Dort die Option Auto DoS deaktivieren! Fertig!
Ich könnte mir in den Arsch beißen! Ein Haken und alles läuft!
Also vielen Dank für eure Unterstützung!
LG
HP 1810G:
Autsch das tut weh, kein Wunder Alles was bei HP auf 'auto' steht bei mir immer unter Generalverdacht. Das wird mir unser @aqui sicher bestätigen 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