Jump to content

w32tm Issue - Timedrifting


Go to solution Solved by jimmyone,

Recommended Posts

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 :D  Hat ja gut geklappt.

 

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

 

LG

Jimmyone

Link to post

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 :D  Hat ja gut geklappt.

 

War der fehlerhafte DC mal der PDC? ;)

  • Thanks 1
Link to post
  • Solution
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. :aha: Was solls, vielen Dank für den Tipp. :thumb1:

 

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

Auszuschließen ist das allerdings nicht.

 

VG

Jimmyone

Link to post
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. :cool:

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...