Zeitsynchronisierung funktioniert nicht

[Gu4rdi4n 58]

Hi,

 

ich habe drei DCs.

Zwei der drei sind aktuell Zeitsynchron und zeigen auch die korrekte Zeit an.

Der Dritte im Bunde (bzw. der erste DC, der auch alle FSMO Rollen, außer dem PDC Emulator, inne hat) weicht ab

 

PS C:\Users\administrator.EK> w32tm /monitor
ADSRV.EK.de[10.10.10.10:123]:
    ICMP: 0ms Verzögerung
    NTP: -75.4066869s Offset von ADSRV3.EK.de
        RefID: 'LOCL' [0x4C434F4C]
        Stratum: 1
ADSRV3.EK.de *** PDC ***[[fe80::ebc5:59fd:70e4:29f%13]:123]:
    ICMP: 0ms Verzögerung
    NTP: +0.0000000s Offset von ADSRV3.EK.de
        RefID: time1.uni-paderborn.de [131.234.220.231]
        Stratum: 2
ADSRV2.EK.de[10.10.10.11:123]:
    ICMP: 0ms Verzögerung
    NTP: -0.0104353s Offset von ADSRV3.EK.de
        RefID: ADSRV3.EK.de [10.10.10.12]
        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.

 

Ausgabe auf dem DC, der falsch läuft (ADSRV)

 

PS C:\Users\Administrator> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 1 (Primärreferenz - synchron. über Funkuhr)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname:  "LOCL")
Letzte erfolgr. Synchronisierungszeit: 20.02.2024 10:01:49
Quelle: Free-running System Clock
Abrufintervall: 6 (64s)

PS C:\Users\Administrator> w32tm /query /peers
Anzahl Peers: 1

Peer:
Status: Ausstehend
Verbleibende Zeit: 684.6799506s
Modus: 0 (Reserviert)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)
HostAbrufintervall: 0 (nicht angegeben)

 

Ausgabe auf dem PDCE

 

PS C:\Users\administrator.EK> 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.0242381s
Stammabweichung: 0.0153879s
Referenz-ID: 0x83EADCE7 (Quell-IP:  131.234.220.231)
Letzte erfolgr. Synchronisierungszeit: 20.02.2024 10:06:49
Quelle: de.pool.ntp.org
Abrufintervall: 7 (128s)

PS C:\Users\administrator.EK> w32tm /query /peers
Anzahl Peers: 1

Peer: de.pool.ntp.org
Status: Aktiv
Verbleibende Zeit: 7.8532854s
Modus: 1 (Symmetrisch aktiv)
Stratum: 1 (Primärreferenz - synchron. über Funkuhr)
PeerAbrufintervall: 7 (128s)
HostAbrufintervall: 7 (128s)
PS C:\Users\administrator.EK>

 

 

Ich habe schon versucht folgenden Befehl zu setzen:

 w32tm /config /update /manualpeerlist:ADSRV3 /syncfromflags:manual /reliable:yes

Das quittiert er auch mit ok, aber er ignoriert es dann einfach und bleibt weiterhin auf local

 

Wie kann ich den DC dazu bringen die Zeit vom PDC zu ziehen?

[zahni 554]

Einfach als TYPE NT5DS  eintragen und fertig. Wie bei jedem anderen Client.

In einer Domäne braucht nur (!) der PDC-Emulator eine externe Zeitquelle.

Neustart des Dienstes nicht vergessen.

bearbeitet 20. Februar von zahni

[testperson 1.677]

Hi,

vor 31 Minuten schrieb Gu4rdi4n:

(bzw. der erste DC, der auch alle FSMO Rollen, außer dem PDC Emulator, inne hat)

 

nur aus Interesse: Was hat das für einen Hintergrund?

 

Ansonsten für die Zeit Synchronisation in der Domäne: Zeitsynchronisation der Domäne - w32time - Zeitserver per GPO - Gruppenrichtlinien

 

Gruß

Jan

[Gu4rdi4n 58]

Hi

 

@testperson 

Das weiß ich ehrlich gesagt nicht mehr so wirklich. Es gab damals ein Problem mit der Zeit und da hatte ich rum experimentiert und mit der Konfig lief es dann.

 

Die GPO ist schon so konfiguriert wie in der Anleitung

 

Ich hab das schon richtig verstanden, dass die Clients ihre Zeit vom DC bekommen, an dem sie sich anmelden, richtig?

Deswegen steht bei meinem Client auch "ADSRV" und nicht "ADSRV3" beim query

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.0019048s
Stammabweichung: 11.0863704s
Referenz-ID: 0x0A0A0A0A (Quell-IP:  10.10.10.10)
Letzte erfolgr. Synchronisierungszeit: 20.02.2024 11:29:22
Quelle: ADSRV.EK.de
Abrufintervall: 11 (2048s)

 

Problem ist halt, dass ADSRV2 im Gegensatz zu ADSRV seine Zeit von ADSRV3 bezieht.

 

@zahni

Die NT5DS wird in der GPO bereits geliefert

 

Was ich halt nicht verstehe ist, warum lässt sich ADSRV nicht auf den ADSRV3 umstellen, so wie der ADSRV2?

bearbeitet 20. Februar von Gu4rdi4n

[zahni 554]

vor 2 Stunden schrieb Gu4rdi4n:

 

Die NT5DS wird in der GPO bereits geliefert

 

Was ich halt nicht verstehe ist, warum lässt sich ADSRV nicht auf den ADSRV3 umstellen, so wie der ADSRV2?

bearbeitet vor 51 Minuten von Gu4rdi4n

Weil es egal ist. Leider kann ich auch nicht sagen, woran  das festgemacht wird. Vermutlich ist es aber AD-Standortbezogen.

[daabm 1.354]

Stimmen die AnnounceFlags? 5 darf nur der PDCe haben, alle anderen haben 10. Wenn andere DCs auch 5 haben, halten sie sich für "always reliable" und ignorieren NT5DS...

Edit: Warum ich das vermute? Weil Du schreibst, daß einer alle FSMO-Rollen außer PDCe hat - also hat da mal wer den PDCe verschoben...

bearbeitet 20. Februar von daabm

[Gu4rdi4n 58]

vor 14 Stunden schrieb daabm:

Stimmen die AnnounceFlags? 5 darf nur der PDCe haben, alle anderen haben 10. Wenn andere DCs auch 5 haben, halten sie sich für "always reliable" und ignorieren NT5DS...

Edit: Warum ich das vermute? Weil Du schreibst, daß einer alle FSMO-Rollen außer PDCe hat - also hat da mal wer den PDCe verschoben...

 

Ding Ding Ding Ding

 

Dankeschön! Das war's :)

[NorbertFe 2.035]

Immer wenn ich diese Probleme lese, muss ich dran denken, dass ich das im How To noch mit einpflegen will (seit Jahren), damit nach einer Verschiebung des PDC-e die Announceflags des bisherigen PDC-e wieder korrigiert werden. Es bleibt aber weiterhin die Frage, warum dein PDC-e nicht mit allen anderen FSMO auf einem DC liegt. :p

[Gu4rdi4n 58]

vor 5 Minuten schrieb NorbertFe:

Immer wenn ich diese Probleme lese, muss ich dran denken, dass ich das im How To noch mit einpflegen will (seit Jahren), damit nach einer Verschiebung des PDC-e die Announceflags des bisherigen PDC-e wieder korrigiert werden. Es bleibt aber weiterhin die Frage, warum dein PDC-e nicht mit allen anderen FSMO auf einem DC liegt. :p

 

Weil halt

 

Ich wollte erstmal die Zeit jetzt fixen, weil die Replikation der DHCP server Probleme gemacht hat. 

 

Warum der PDCe damals verschoben wurde kann ich nicht mehr genau sagen ;)

Aber die DCs werden sowieso bald mal geupgraded und in dem Zug dann die FSMO Rollen auf den Server übertragen, der jetzt den PDCe beherbergt 

[Nobbyaushb 1.471]

vor 25 Minuten schrieb Gu4rdi4n:

Aber die DCs werden sowieso bald mal geupgraded und in dem Zug dann die FSMO Rollen auf den Server übertragen, der jetzt den PDCe beherbergt 

Warum warten?

[Gu4rdi4n 58]

vor 4 Minuten schrieb Nobbyaushb:

Warum warten?

 

Weil ich alleine bin und gerade keine Zeit habe (ERP und Zeiterfassung upgrade) mich um eventuelle Fehler die Auftreten zu kümmern.

 

Oder empfiehlst du einen 2012er DC mit der Windows upgrage funktion einfach hoch zu ziehen?

Bisher hieß es immer neu installieren und rollen übertragen

[testperson 1.677]

vor 5 Minuten schrieb Gu4rdi4n:

Oder empfiehlst du einen 2012er DC mit der Windows upgrage funktion einfach hoch zu ziehen?

Bisher hieß es immer neu installieren und rollen übertragen

Das ist vom Aufwand nahezu egal. Aber ja, machen und (vorher) gleich noch einen weiterer DC dazu. DCs sind Rudeltiere. ;)

[Nobbyaushb 1.471]

vor 4 Minuten schrieb testperson:

Das ist vom Aufwand nahezu egal. Aber ja, machen und (vorher) gleich noch einen weiterer DC dazu. DCs sind Rudeltiere. ;)

Den Spruch muss ich mir merken

Aber ja, wenn der DC nur ein DC ist, kann man nichts schneller neu machen

Ich habe bei den meisten meiner Kunden (und bei mir) eine gesyspreppte exportierte VM vorbereitet, dann dauert das 20 Minuten

(egal für was man die dann braucht - wobei bei manchen Kunden mit nVMe im Server auch nicht mehr brauchst...)

[daabm 1.354]

vor 10 Stunden schrieb NorbertFe:

Immer wenn ich diese Probleme lese, muss ich dran denken, dass ich das im How To noch mit einpflegen will (seit Jahren), damit nach einer Verschiebung des PDC-e die Announceflags des bisherigen PDC-e wieder korrigiert werden. Es bleibt aber weiterhin die Frage, warum dein PDC-e nicht mit allen anderen FSMO auf einem DC liegt. :p

 

Dann mach das mal. Unsere Universal-GPO mit w32tm-Config für Member, DC und PDCe hat das inzwischen für alle 3 Varianten komplett (also alle Regwerte). Hatte das am Anfang nämlich auch vergessen, daher waren mir Ursache und Lösung quasi sofort präsent

[NorbertFe 2.035]

vor 28 Minuten schrieb daabm:

Dann mach das mal.

Sobald ich Lust und Zeit finde: