19.05.2018, aktualisiert um 14:20:40 Uhr

47438

Windows Clients synchronisieren Zeit nicht mit DC

Hallo,

ich habe einige Windows Clients in einer Domäne.
Der Domänencontroller synct die Zeit mit dem Tool NetTime.

Auf den Clients habe ich den Befehl

w32tm /config /syncfromflags:domhier /update

ausgeführt.

Danach den Dienst neu gestartet

net stop w32time && net start w32time

Trotz gibt es noch diese meldung

C:\WINDOWS\system32>w32tm /query /source
Local CMOS Clock

Ich habe auch schon den Dienst neu registriert

w32tm /unregister
w32tm /register

Mit

w32tm /monitor

wird mir auch der richtige Server angezeigt.

Was kann ich noch tun?
Dieses Problem habe ich bei allen Clients.
Eine GPO gibt es nicht, die den Dienst konfiguriert.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 374489

Url: https://administrator.de/contentid/374489

Ausgedruckt am: 22.11.2024 um 01:11 Uhr

31 Kommentare

Neuester Kommentar

Hallo,

da brauchst du kein NetTime-Tool, keine GPO und eigentlich auch nichts manuell auf den Clients konfigurieren.
Ich setze bei einer Domäne mal einen Windows Server voraus. Wenn die Clients Ihre IP-Adressen per DHCP
bekommen, dann öffnest du auf dem Server DHCP und direkt unterhalb von IPv4 in den Server-Optionen
legst du z.B. den Windows-Server selbst als Zeitserver fest und als zweiten Zeitserver eine externe Quelle.

Als externen Zeitserver kannst du z.B. "de.pool.ntp.org" oder "ptbtime1.ptb.de" verwenden.

Die Clients bekommen dann Ihre Timeserver via DHCP und fertig. Wobei eigentlich alle Clients ohnehin den autorisierenden DC als
Zeitserver verwenden.

Den Windows-Server konfigurierst du für die Verwendung einer externen Zeitquelle. Siehe hier:

https://support.microsoft.com/de-de/help/816042/how-to-configure-an-auth ...

Gruß knuddel256

Hi,

Bloss gut das gestern Freitag war.

Die Clients bekommen dann Ihre Timeserver via DHCP und fertig.

Windowsclients ignorieren bekanntlicherweise diesen DHCP-Eintrag.

Wobei eigentlich alle Clients ohnehin den autorisierenden DC als Zeitserver verwenden.

Wozu dann der Aufwand mit DHCP?

Dem DC eine verlaessliche Zeitquelle geben, passende GPO und gut ist.

Schoenes WE.

BFF

Den Link habe ich schon beachtet.
Der DC wurde wie im Link konfiguriert.

Nur die Clients haben definitiv falsche Uhrzeiten (teileweise mehr als 2 Minuten Unterschied).

Hallo,

Nur die Clients haben definitiv falsche Uhrzeiten (teileweise mehr als 2 Minuten Unterschied).

Dann liefert der DC u.U. keine Zeit. Und damit er das tut, musst Du halt ran und ein paar Einstellungen taetigen.

Ackere Dich mal hier durch. Ist leichtere Kost.

https://www.windowspro.de/wolfgang-sommergut/zeiteinstellungen-windows-d ...
https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaen ...

Und schmeiss das nettime vom DC.

BFF

Der DC liefert Zeiten zurück via

w32tm /stripchart /computer:pdc.domain.local

Dann schmeiß ich nächste Woche mal das nettime runter und teste dann

Moin,

wurde vielleicht der PDC aus der Domain entfernt und vergessen, die Rolle vorher zu übertragen? Was gibt denn

dsquery server -hasfsmo pdc

zurück?

Liebe Grüße

Erik

oder "ptbtime1.ptb.de" verwenden.

Nein !
Die PTB hat das untersagt bzw. wenn, dann muss man sich dort vorher registrieren lassen. Es gibt aber Alternativen:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html

Hi,
und nochmal am Rande erwähnt:
In einer Windows AD Umgebung muss man an Domain Member überhaupt nichts konfigurieren, damit sich diese mit dem PDC-Emulator Ihrer Domäne synchronisieren.

Wie funktioniert der Windows-Zeitdienst
Abschnitt: Domäne Hierarchie-basierte Synchronisierung

Ggf. nur den PDC-Emulator der Stammdomäne mit einer externen Quelle synchronisieren. Sonst nichts rumfummeln.
Keinen Zeitserver am Client einstellen, keinen per GPO oder DHCP verteilen. Alles unnötig.

How to configure the Windows Time service against a large time offset
Das ist noch ein alter Artikel aber vielleicht hilft er ja trotzdem.

Rein für Windows ist eine Genauigkeit von bis zu 5 min zwischen Server und Client ausreichend.
Man muss auch bedenken, dass der NTP-Dienst keine Zeitsprünge ausführt sondern immer versucht, die Zeit "einzuschwingen" indem er die Zeittakte der Clients verlangsamt oder beschleunigt.

E.

Zitat von @erikro:

Moin,

wurde vielleicht der PDC aus der Domain entfernt und vergessen, die Rolle vorher zu übertragen? Was gibt denn

dsquery server -hasfsmo pdc

zurück?

Liebe Grüße

Erik

Der Befehl liefert den richtigen Server zurück.

Zitat von @emeriks:

Hi,
und nochmal am Rande erwähnt:
In einer Windows AD Umgebung muss man an Domain Member überhaupt nichts konfigurieren, damit sich diese mit dem PDC-Emulator Ihrer Domäne synchronisieren.

Wie funktioniert der Windows-Zeitdienst
Abschnitt: Domäne Hierarchie-basierte Synchronisierung

Ggf. nur den PDC-Emulator der Stammdomäne mit einer externen Quelle synchronisieren. Sonst nichts rumfummeln.
Keinen Zeitserver am Client einstellen, keinen per GPO oder DHCP verteilen. Alles unnötig.

How to configure the Windows Time service against a large time offset
Das ist noch ein alter Artikel aber vielleicht hilft er ja trotzdem.

Rein für Windows ist eine Genauigkeit von bis zu 5 min zwischen Server und Client ausreichend.
Man muss auch bedenken, dass der NTP-Dienst keine Zeitsprünge ausführt sondern immer versucht, die Zeit "einzuschwingen" indem er die Zeittakte der Clients verlangsamt oder beschleunigt.

E.

Das Problem ist, dass der PC für die Zeiterfassung genutzt wird. Und wenn im Radio die Nachrichten kommen um 12 Uhr zum Beispiel und dann der PC nicht auch 12 Uhr sondern erst 11:58 Uhr anzeigt, gibt das ein Problem.

5 Minuten ist eine lange Zeitspanne.

Moin,

Zitat von @Vanillakop:

Zitat von @erikro:
wurde vielleicht der PDC aus der Domain entfernt und vergessen, die Rolle vorher zu übertragen? Was gibt denn

dsquery server -hasfsmo pdc

zurück?

Der Befehl liefert den richtigen Server zurück.

Das ist ja schonmal was. ;) Und was gibt

w32tm /monitor

auf dem betroffenen Client zurück?

Liebe Grüße

Erik

Auch das richtige. Die drei DCs werden aufgelistet.

C:\WINDOWS\system32> w32tm /monitor
W08-DATA.Horstkemper.de[192.168.1.11:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0964492s Offset von W16-FPDC.Horstkemper.de
        RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]
        Stratum: 0
HV16-SERVER.Horstkemper.de[192.168.1.2:123]:
    ICMP: 0ms Verzögerung
    NTP: -0.0117097s Offset von W16-FPDC.Horstkemper.de
        RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]
        Stratum: 14
W16-FPDC.Horstkemper.de *** PDC ***[192.168.1.3:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de
        RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]
        Stratum: 14
[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.

Moin,

Zitat von @Vanillakop:

Auch das richtige. Die drei DCs werden aufgelistet.

Nicht wirklich.

>         RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]
> 

Hier sollte der PDC stehen. Die Frage ist jetzt, warum er da nicht steht.

Liebe Grüße

Erik

RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]

Hier sollte der PDC stehen. Die Frage ist jetzt, warum er da nicht steht.

Nein, nicht ganz.

W16-FPDC.Horstkemper.de * PDC *[192.168.1.3:123]:
NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de

Hinter "RefID:" sollte die Auflösung der externen Zeitquelle stehen.

Edit: Fehler korrigiert.

Moin,

Zitat von @emeriks:

RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]

Hier sollte der PDC stehen. Die Frage ist jetzt, warum er da nicht steht.

Nein, nicht ganz.

W16-FPDC.Horstkemper.de * PDC *[192.168.1.3:123]:
NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de

Hinter "RefID:" sollte die Auflösung der externen Zeitquelle stehen.

Da hast Du natürlich recht. Ohne externe Zeitquelle steht da allerdings irgendwas wie "LOCAL". "nicht angegeben/nicht synchronisiert" ist irgendwie schlecht.

Liebe Grüße

Erik

Was könnte ich wohl unternehmen, dass dort das richtige steht?

Moin,

führe mal auf folgenden Befehl aus, damit er eine externe Quelle hat:

w32tm /config /computer:pdc.domain.local /manualpeerlist:time.windows.com /syncfromflags:manual /update

pdc.domain.local ersetzt Du mit dem FQDN Deines PDC.
time.windows.com kannst Du mit jedem Dir genehmen Zeitserver aus dem Netz ersetzen.

hth

Erik

Habe ich gemacht.

Jetzt zeigt w32tm /monitor das an:

C:\WINDOWS\system32> w32tm /monitor
W08-DATA.Horstkemper.de[192.168.1.11:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.1006108s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1
HV16-SERVER.Horstkemper.de[192.168.1.2:123]:
    ICMP: 0ms Verzögerung
    NTP: -0.0149958s Offset von W16-FPDC.Horstkemper.de
        RefID: (nicht angegeben / nicht synchronisiert) [0x00000000]
        Stratum: 0
W16-FPDC.Horstkemper.de *** PDC ***[192.168.1.3:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1
[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.

w32tm /monitor

Das führst Du am Client aus, ja?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\InputProvider

Ist dieser Wert bei Euch auf "1" ?

Moin,

sieht immer noch nicht gut aus. Ich würde jetzt erst einmal auf allen NICHT PDC Folgendes ausführen:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time

Und dann mal schauen, ob sie sich die Zeit vom PDC holen.

Liebe Grüße

Erik

Zitat von @emeriks:

w32tm /monitor

Das führst Du am Client aus, ja?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\InputProvider

Ist dieser Wert bei Euch auf "1" ?

beides ja

Zitat von @erikro:

Moin,

sieht immer noch nicht gut aus. Ich würde jetzt erst einmal auf allen NICHT PDC Folgendes ausführen:

net stop w32time
> w32tm /unregister
> w32tm /register
> net start w32time
> w32tm /config /syncfromflags:domhier /update
> net stop w32time
> net start w32time

Und dann mal schauen, ob sie sich die Zeit vom PDC holen.

Liebe Grüße

Erik

Jetzt sieht's so aus:

C:\WINDOWS\system32> w32tm /monitor
W08-DATA.Horstkemper.de[192.168.1.11:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.2170695s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1
HV16-SERVER.Horstkemper.de[192.168.1.2:123]:
    ICMP: 0ms Verzögerung
    NTP: -0.0137831s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1
W16-FPDC.Horstkemper.de *** PDC ***[192.168.1.3:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1
[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.

w32tm /query /status gibt das zurück auf einem Client:

C:\WINDOWS\system32> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 2 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0012292s
Stammabweichung: 17.8709802s
Referenz-ID: 0xC0A8010B (Quell-IP:  192.168.1.11)
Letzte erfolgr. Synchronisierungszeit: 22.05.2018 16:18:48
Quelle: W08-DATA.Horstkemper.de
Abrufintervall: 10 (1024s)

Das sieht schon viel besser aus.

Jetzt brauchst Du nur noch die Klients kontrollieren. Innerhalb der naechsten Stunden sollten die synchron mit der Domanenzeit sein.

Warum?
Laut Eurer Zeiterfassung waren die ja dann um 7:58 eingebucht und nicht erst um 8:00.

Stundenmaessig also kein Verlust fuer die "Schreier". Die kursive Aussage stammt uebrigens von einer Schlichtungskommision, wo es genau darum ging, dass eine Zeit sich um 3 Minuten von der "Handyzeit" unterschieden hat.

BFF

Moin,

Zitat von @BassFishFox:

Das sieht schon viel besser aus.

Das sehe ich auch so. Fehlt eigentlich nur noch, dass der PDC gegen eine externe Quelle synchronisiert. Das sieht noch nicht danach aus:

W16-FPDC.Horstkemper.de *** PDC ***[192.168.1.3:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1

Warum?
Laut Eurer Zeiterfassung waren die ja dann um 7:58 eingebucht und nicht erst um 8:00.

Stundenmaessig also kein Verlust fuer die "Schreier".

Bei manchen Anwendungen ist das schon wichtig, dass die Zeit genau stimmt. Das Beispiel mit dem Radio ist gar nicht schlecht. Da ist das schon wichtig, dass die Uhr um 12.00 auch 12.00 anzeigt und der Sprecher weiß, dass er anfangen muss.. ;)

Liebe Grüße

Erik

Zitat von @erikro:

Moin,

Zitat von @BassFishFox:

Das sieht schon viel besser aus.

Das sehe ich auch so. Fehlt eigentlich nur noch, dass der PDC gegen eine externe Quelle synchronisiert. Das sieht noch nicht danach aus:

Das wäre natürlich am schönsten.
Aber das klappt irgendwie noch nicht.

Dafür zeigt der Client jetzt das richtige an:

C:\WINDOWS\system32> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 2 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0011904s
Stammabweichung: 18.5781891s
Referenz-ID: 0xC0A80103 (Quell-IP:  192.168.1.3)
Letzte erfolgr. Synchronisierungszeit: 23.05.2018 09:23:17
Quelle: W16-FPDC.Horstkemper.de
Abrufintervall: 10 (1024s)

Aha, Löfkenfeld 65 in Rietberg

Anonymisieren wäre sicher angebrachter hier !

Moin,

Zitat von @Vanillakop:

Zitat von @erikro:
Das sehe ich auch so. Fehlt eigentlich nur noch, dass der PDC gegen eine externe Quelle synchronisiert. Das sieht noch nicht danach aus:

Das wäre natürlich am schönsten.
Aber das klappt irgendwie noch nicht.

Was hat denn

w32tm /config /computer:pdc.domain.local /manualpeerlist:time.windows.com /syncfromflags:manual /update

zurückgegeben?

Liebe Grüße

Erik

Zitat von @erikro:

Moin,

Zitat von @Vanillakop:

Zitat von @erikro:
Das sehe ich auch so. Fehlt eigentlich nur noch, dass der PDC gegen eine externe Quelle synchronisiert. Das sieht noch nicht danach aus:

Das wäre natürlich am schönsten.
Aber das klappt irgendwie noch nicht.

Was hat denn

w32tm /config /computer:pdc.domain.local /manualpeerlist:time.windows.com /syncfromflags:manual /update

zurückgegeben?

Liebe Grüße

Erik

Der Befehl wurde erfolgreich ausgeführt.

Ist doch alles gut.
Der PDC ist doch verbunden mit einer Zeitquelle. Das "stratum 1" in der Ausgabe von "w32tm /monitor" sagt das doch.

BFF

Moin,

Zitat von @BassFishFox:

Ist doch alles gut.
Der PDC ist doch verbunden mit einer Zeitquelle. Das "stratum 1" in der Ausgabe von "w32tm /monitor" sagt das doch.

Die externe Zeitquelle steht da nicht drin.

W16-FPDC.Horstkemper.de *** PDC ***[192.168.1.3:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von W16-FPDC.Horstkemper.de
        RefID: 'LOCL' [0x4C434F4C]  
        Stratum: 1

Das sollte so aussehen:

pdc.domain.local *** PDC ***[[fe80::d049:ded7:78aa:ecf5%17]:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von pdc.domain.local
        RefID: ns.tu-berlin.de [130.149.7.7]
        Stratum: 3

Wie Du siehst, steht da bei mir die externe Zeitquelle und nicht 'LOCL'.

Liebe Grüße

Erik

Es passt aber so im Moment.
Die nächsten zwei Wochen werden es zeigen, ob die Uhrzeit sich nochmal verstellt.

Weiterhin lasse ich jetzt die Pausenhupe mit dem PDC synchronisieren. Dann sind die Zeiten schonmal gleich.

Frage Microsoft Windows Netzwerk

Mehr von Vanillakop

HCW8064 OAuth konnte nicht eingerichtet werdenVanillakop

Routen zwischen zwei Netzwerken geht nur in eine RichtungVanillakop - 42 Kommentare

Zwei lokale IPs über bestimmten WAN Anschluss routen - DigitialisierungsboxVanillakop - 13 Kommentare

Gruppenmitglieder verschwinden aus Active Directory GruppenVanillakop - 8 Kommentare

Heiß diskutiert