w32tm Issue - Timedrifting

[jimmyone 15]

Moin,

 

vielleicht hat jemand einen heißen Tipp, wie ich dem folgenden Problem weiter begegnen könnte...

Es fing damit an, dass ein SQL Server nicht mehr per SSMS erreichbar war. Wir nutzen Kerberos an dieser Stelle. Die Untersuchungen zeigten, das Problem entsteht durch Timedrifting.

Eigentlich dürfte es das gar nicht geben. Wir haben in der Vergangenheit über zwei GPOs eine Festlegung Domänenweit definiert. Auf Basis der Doku von damals, haben zu dieser Zeit alle DCs die richtigen Zeitdaten empfangen.

Dabei wird u.a. per WMI die PDC Rolle erfasst und diese erfragt bei pool.ntp.org die aktuellen Zeitdaten. Eine zweite GPO gibt diese an alle Systeme weiter bzw. legt die Art des Sync fest.

Bisher klappte das prima. Ein DC empfängt jedoch keine Zeitdaten mehr. Ein Resync Befehl meldet das entsprechend.

Ein Query auf den peer vermeldet, dass er keinen entsprechenden Host mehr zur Abfrage hat. Die anderen DCs orientieren sich jedoch an der PDC Rolle sprich haben diesen als Zeitgeber.

Eine RSOP Auswertung liefert für diesen fehlerhaften DC den Hinweis, dass er das GPO Objekt zieht und auch entsprechend synchronisieren sollte.

Ein FSMO Query meldet auf dem betreffenden DC auch das richtige System als PDC. Die Vererbung der GPOs auf dem DC Container passt ebenfalls. Die Netzwerker melden, dass es keinen Firewall Blocker gibt.

Wir haben das damals so gemacht, weil wir mit dem Thema nie wieder etwas zu tun haben wollten   Hat ja gut geklappt.

 

Hat jemand eine Idee, wie wir dem Thema weiter begegnen könnten?

 

LG

Jimmyone

[NorbertFe 2.034]

Auf dem DC, der fehlerhaften Sync hat, mal den Timeservice de-registrieren und wieder registrieren.

 

net Stop W32time
W32tm.exe /unregister
W32tm.exe /register
net Start W32time

 

Danach mal ein w32tm /resync und schauen was zurückkommt.

vor 8 Minuten schrieb jimmyone:

Wir haben das damals so gemacht, weil wir mit dem Thema nie wieder etwas zu tun haben wollten   Hat ja gut geklappt.

 

War der fehlerhafte DC mal der PDC? ;)

[jimmyone 15]

vor 24 Minuten schrieb NorbertFe:

Auf dem DC, der fehlerhaften Sync hat, mal den Timeservice de-registrieren und wieder registrieren.

 

net Stop W32time
W32tm.exe /unregister
W32tm.exe /register
net Start W32time

 

Danach mal ein w32tm /resync und schauen was zurückkommt.

War der fehlerhafte DC mal der PDC? ;)

 

Prima, das hat geklappt. Danke NorbertFe.

Tatsächlich hätte ich darauf ja auch noch kommen können. Insbesondere weil ich diese Möglichkeit kannte.  Was solls, vielen Dank für den Tipp. 

 

Ich kann aktuell nicht sagen, ob der fehlerhafte DC mal die PDC Rolle hatte.

Auszuschließen ist das allerdings nicht.

 

VG

Jimmyone

[NorbertFe 2.034]

vor 19 Minuten schrieb jimmyone:

Auszuschließen ist das allerdings nicht.

 

Tja für solche Fälle müßte man sein GPO Konstrukt mal "anpassen". Muss ich wohl mal bei GElegenheit noch ins How To dazuschreiben ;)

[jimmyone 15]

vor 2 Stunden schrieb NorbertFe:

Tja für solche Fälle müßte man sein GPO Konstrukt mal "anpassen". Muss ich wohl mal bei GElegenheit noch ins How To dazuschreiben ;)

 

Also laut Doku war das System niemals PDC oder sonst wie FSMO Owner.

Aus Interesse: Von welchem How-to ist hier die Rede? Ich weiß heute ehrlich gesagt nicht mehr wirklich, wo wir die Lösung damals her hatten.

Ich weiß noch, das rum gekrebse mit dem Zeitgeber war irgendwann so nervig, dass wir eine Domänenweite Lösung gesucht haben. Vielleicht basiert diese Lösung sogar auf dem von Dir genannten How to. 

[chrismue 96]

Ich denke er meint das How-To von gruppenrichtlinien.de

 

Gruß

chrismue

[NorbertFe 2.034]

vor 8 Minuten schrieb jimmyone:

Vielleicht basiert diese Lösung sogar auf dem von Dir genannten How to. 

Möglich, klingt aber nicht so, denn bestimmte Formulierungen lassen irgendwie anderes vermuten. Den Link hat Chris ja schon gepostet.