4
Problem bei Zeitservern innerhalb einer Domäne
Wer kann mit fundiert (mit Quellenangabe) beantworten, was bei der Synchronisation mit einem Zeitgeber bzw allgemein bei der Zeitsynchronisation innerhalb einer Domäne geschieht?
Hallo zusammen,
wir haben (jetzt schon zum zweiten Mal) das Problem, dass einer, zwei oder alle drei DCs von uns verrückt spielen.
Bei einem wurde die zeit plötzlich auf den 01.01.1900 umgestellt. Der andere hat den 07.02.2036 als Datum vorzuweisen. (also 2^32 Sekunden später
)
Dass es hierbei z.B. zu Anmeldeproblemen kommt, muss man glaub ich nicht erwähnen.
Ich konnte bis jetzt in Erfahrung bringen, dass der Zeitgeber der PDC Emulator innerhalb einer Domäne ist. Dieses ist bei uns der "server.domaene.local"
find_fsmo.vbs Ausgabe hierzu:
Die anderen Server lauten: dc02 und dc03. (allesamt W2K Server in einer W2K-Domäne)
Möchte ich die Zeit mit z.B.
auf einem Client setzen, so wird IMMER mit dem DC03 synchronisiert. Warum?!
Dies ist meines Wissens nach auch unabhängig vom "Logonserver" innerhalb der Domäne
Selbst wenn ich die Zeitserver manuell festlege, bleibt es bei diesem Ergebnis.
Es wird immer
Hat jemand Ideen, warum es zu solchen Problemen kommen kann? Oder wie ich das Problem weiter eingrenze? Bin ziemlich ratlos mittlerweile...
Die Suche auf den Seiten MSXFAQ (http://www.msxfaq.de/verschiedenes/timesync.htm) ) und YUSUFs Blog (http://blog.dikmenoglu.de/PermaLink,guid,5aee4b82-3dd9-4480-a35c-c3d0b0 ...) ) hab ich ergebnislos abgebrochen.
Danke für jeden Tipp!!! Falls weitere Infos benötigt werden, bitte schreiben!
Gruß
Markus
wir haben (jetzt schon zum zweiten Mal) das Problem, dass einer, zwei oder alle drei DCs von uns verrückt spielen.
Bei einem wurde die zeit plötzlich auf den 01.01.1900 umgestellt. Der andere hat den 07.02.2036 als Datum vorzuweisen. (also 2^32 Sekunden später
)Dass es hierbei z.B. zu Anmeldeproblemen kommt, muss man glaub ich nicht erwähnen.
Ich konnte bis jetzt in Erfahrung bringen, dass der Zeitgeber der PDC Emulator innerhalb einer Domäne ist. Dieses ist bei uns der "server.domaene.local"
find_fsmo.vbs Ausgabe hierzu:
The PDC FSMO is: server.DOMAENE.local
The RID FSMO is: server.DOMAENE.local
The Infrastructure FSMO is: server.DOMAENE.local
The Schema FSMO is: server.DOMAENE.local
The Domain Naming FSMO is: server.DOMAENE.localMöchte ich die Zeit mit z.B.
net time /Set /yesDies ist meines Wissens nach auch unabhängig vom "Logonserver" innerhalb der Domäne
Selbst wenn ich die Zeitserver manuell festlege, bleibt es bei diesem Ergebnis.
Es wird immernet time /setsntp:"ptbtime1.ptb.de ptbtime2.ptb.de" Hat jemand Ideen, warum es zu solchen Problemen kommen kann? Oder wie ich das Problem weiter eingrenze? Bin ziemlich ratlos mittlerweile...
Die Suche auf den Seiten MSXFAQ (http://www.msxfaq.de/verschiedenes/timesync.htm) ) und YUSUFs Blog (http://blog.dikmenoglu.de/PermaLink,guid,5aee4b82-3dd9-4480-a35c-c3d0b0 ...) ) hab ich ergebnislos abgebrochen.
Danke für jeden Tipp!!! Falls weitere Infos benötigt werden, bitte schreiben!
Gruß
Markus
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: 151377
Url: https://administrator.de/contentid/151377
Printed on: April 25, 2024 at 08:04 o'clock
4 Comments
Latest comment
Ich habe das bei uns recht einfach gelöst:
EIN DC wird auf einen Public NTP eingestellt (also synchronisiert sich mit z.B. pool.ntp.org) und alle anderen synchronisieren sich mit dem, der sich die Zeit von außen holt.
Hat bei uns einwandfrei geklappt.
Kann es ein das ein User durch Zufall/weil übersehen admin-Rechte hat? Werden bei eiuch extra Programme zum Synchronisieren der Zeit benutzt?
als workarround könnte man ein timesync-Tool installieren das die Server jede minute wieder "in den Takt" bringt, aber das is auch nur eine Behandlung des Problems und nicht der Ursache.
Was sagt das Systemlog?
Gruß
Arsimael
EIN DC wird auf einen Public NTP eingestellt (also synchronisiert sich mit z.B. pool.ntp.org) und alle anderen synchronisieren sich mit dem, der sich die Zeit von außen holt.
Hat bei uns einwandfrei geklappt.
Kann es ein das ein User durch Zufall/weil übersehen admin-Rechte hat? Werden bei eiuch extra Programme zum Synchronisieren der Zeit benutzt?
als workarround könnte man ein timesync-Tool installieren das die Server jede minute wieder "in den Takt" bringt, aber das is auch nur eine Behandlung des Problems und nicht der Ursache.
Was sagt das Systemlog?
Gruß
Arsimael
Servus,
ich kann dir auch nicht sagen, warum sich die Zeit deiner DCs so kurios verstellt. Da du aber Windows 2000 erwähnst (du weißt das es dafür keinen Support mehr gibt?),
könnte es evtl. an der veralteten Hardware, genauer an der Batterie auf dem Mainboard vielleicht liegen?
Zumindest kann ich dir die Funktionsweise der Zeitsynchronisation näher bringen.
Dann wollen wir Mal.
So wie du es bereits richtig geschrieben hast, ist der für die Zeit verantwortliche DC einer Gesamtstruktur, der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat!
Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen.
Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll.
Der PDC-Emulator *muss* aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig.
Sie *muss*(!) nur innerhalb einer Gesamtstruktur synchron sein, da es ansonsten zu massiven Problemen mit dem Authentifizierungsprotokoll "Kerberos" kommt!
Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem --> Anmeldeserver <--,
also von dem DC, bei dem sich der Client anmeldet/authentisiert und dieser muss nicht zwingend der PDC-Emulator ihrer Domäne sein.
Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne.
Wie bereits geschrieben, ist der PDC-Emulator der Root-Domäne die maßgebliche Zeitquelle für die Gesamtstruktur.
Führe auf dem Windows 2000 PDC-Emulator das hier durch:
1. "net time /setsntp:ptbtime1.ptb.de"
2. Danach ein "net stop w32time"
3. Danach ein "w32tm -once"
4. Danach erneut ein "net start w32time"
Nun solltest du einiges in der Kommandozeile angezeigt bekommen. In einer Zeile sollte sowas in der Art stehen: "Recieved from server 48 Bytes".
Um den Zeitserver auf dem DC zu überprüfen reicht ein "net time /querysntp". Dadurch sollte der DC dann den "ptbtime1.ptb.de" als Zeitquelle angeben.
Doch bevor du die Befehle ausführst, stelle von Hand auf allen DCs die Zeit korrekt ein.
Viele Grüße
/ > Yusuf Dikmenoglu
ich kann dir auch nicht sagen, warum sich die Zeit deiner DCs so kurios verstellt. Da du aber Windows 2000 erwähnst (du weißt das es dafür keinen Support mehr gibt?),
könnte es evtl. an der veralteten Hardware, genauer an der Batterie auf dem Mainboard vielleicht liegen?
Zumindest kann ich dir die Funktionsweise der Zeitsynchronisation näher bringen.
Dann wollen wir Mal.
So wie du es bereits richtig geschrieben hast, ist der für die Zeit verantwortliche DC einer Gesamtstruktur, der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat!
Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen.
Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll.
Der PDC-Emulator *muss* aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig.
Sie *muss*(!) nur innerhalb einer Gesamtstruktur synchron sein, da es ansonsten zu massiven Problemen mit dem Authentifizierungsprotokoll "Kerberos" kommt!
Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem --> Anmeldeserver <--,
also von dem DC, bei dem sich der Client anmeldet/authentisiert und dieser muss nicht zwingend der PDC-Emulator ihrer Domäne sein.
Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne.
Wie bereits geschrieben, ist der PDC-Emulator der Root-Domäne die maßgebliche Zeitquelle für die Gesamtstruktur.
Führe auf dem Windows 2000 PDC-Emulator das hier durch:
1. "net time /setsntp:ptbtime1.ptb.de"
2. Danach ein "net stop w32time"
3. Danach ein "w32tm -once"
4. Danach erneut ein "net start w32time"
Nun solltest du einiges in der Kommandozeile angezeigt bekommen. In einer Zeile sollte sowas in der Art stehen: "Recieved from server 48 Bytes".
Um den Zeitserver auf dem DC zu überprüfen reicht ein "net time /querysntp". Dadurch sollte der DC dann den "ptbtime1.ptb.de" als Zeitquelle angeben.
Doch bevor du die Befehle ausführst, stelle von Hand auf allen DCs die Zeit korrekt ein.
Viele Grüße
/ > Yusuf Dikmenoglu
Erst einmal herzlichen Dank,
selbst ein Guru wie Yusuf Dikmenoglu findet noch Zeit für die liebe Community ;) Find ich prima und schon einmal herzlichen Dank!!!
Natürlich gilt dies auch für den ersten Beitrag!
Dass der Support für Win2K abgelaufen ist, ist uns bewusst. (wird geändert, aber dafür muss bzw sollte die Domäne sauber laufen zum Jahresende )
Den Befehl habe ich für den PDC-Emulator ausgeführt und warte jetzt ab, wie es sich weiterhin auswirkt. Hierzu melde ich mich dann morgen wieder.
Ausgabe des Befehls w32tm -once:
Sehe ich das richtig, dass ich bei den anderen DC's, Memberserver, Clients dann net time /setsntp:"pdc-emulator.domaene.local" setzen muss/könnte/sollte?
Weitere Frage:
Warum bekomme ich für "net time" und "W32tm /query /status" zwei unterschiedliche Server zur Synchronisation vorgeschlagen? (Einmal ist es der DC03 bei net time und bei w32tm ist es der PDC-Emulator, mit der sich zuletzt synchronisiert worden ist)
Oder spielt zukünftig nur noch w32tm eine Rolle, da es z.B. glaub ab Windows Vista kein "net time /setsntp" mehr gibt?
Im Voraus herzlichen Dank für Eure Mühe!
Lieben Gruß
Markus
selbst ein Guru wie Yusuf Dikmenoglu findet noch Zeit für die liebe Community ;) Find ich prima und schon einmal herzlichen Dank!!!
Natürlich gilt dies auch für den ersten Beitrag!Dass der Support für Win2K abgelaufen ist, ist uns bewusst. (wird geändert, aber dafür muss bzw sollte die Domäne sauber laufen zum Jahresende
)Den Befehl habe ich für den PDC-Emulator ausgeführt und warte jetzt ab, wie es sich weiterhin auswirkt. Hierzu melde ich mich dann morgen wieder.
Ausgabe des Befehls w32tm -once:
C:\Dokumente und Einstellungen\Administrator>w32tm -once
W32Time: BEGIN:InitAdjIncr
W32Time: Adj 156250 , Incr 156250 fAdjust 0
W32Time: END:Line 2503
W32Time: BEGIN:TsUpTheThread
W32Time: END Line 1407
W32Time: TimeMMInit()
W32Time: Kernel timer : using default maximum resolution
W32Time: MaximumTime = 156250
W32Time: CurrentTime = 156250
W32Time: Timer calibrated, looped 1 times
W32Time: BEGIN:InitTmCfg
W32Time: END:Line 807
W32Time: BEGIN:InitTmCli
W32Time: END:Line 2596
W32Time: BEGIN:InitTmData
W32Time: END:Line 2618
W32Time: AvoidTimeSyncOnWan 0
W32Time: ntpserver - ptbtime1.ptb.de
W32Time: BEGIN:CMOSSynchSet
W32Time: Setting adjustment 156250 - Bool 0
W32Time: BEGIN:SetTSTimeRes
W32Time: END:Line 1295
W32Time: END:Line 864
W32Time: BEGIN:InitializeDC
W32Time: BEGIN:GetRole
W32Time: Role is 'PDC'
W32Time: END Line 672
W32Time: BEGIN:FetchParentDomainName
W32Time: NetLogonGetTimeServiceParentDomain() returned 54b with ptr 0
W32Time: END:Line 782
W32Time: END:Line 704
W32Time: Server: Binding to 1 NIC.
W32Time: Advertising that I'm a Time Service Provider
W32Time: timeBeginPeriod: setting resolution 9
W32Time: BEGIN:TimeSync
W32Time: BEGIN:FGetType
W32Time: END Line 254
W32Time: BEGIN:FDoTimeNTPType
W32Time: BEGIN:ChooseNTPServer
W32Time: END Line 2178
W32Time: BEGIN:GetSocketForSynch
W32Time: NTP: ntpptrs - PTBTIME1.PTB.DE
W32Time: rgbNTPServer PTBTIME1.PTB.DE
W32Time: BEGIN:TsUpTheThread
W32Time: END Line 1407
W32Time: NTP(S): waiting for datagram...
W32Time: Port Pinging to - 123
W32Time: Connecting to "PTBTIME1.PTB.DE" (192.53.103.108)
W32Time: END:Line 1170
W32Time: BEGIN:GetDefaultRid
W32Time: END Line 2359
W32Time: BEGIN:ComputeDelay
W32Time: BEGIN:NTPTry -- init
W32Time: END Line 1683
W32Time: BEGIN:NTPTry -- try
W32Time: BEGIN:ComputeInterval
W32Time: END Line 2479
W32Time: Sending to server 48 bytes...
W32Time: Recv'ed from server 48 Bytes...
W32Time: END Line 1885
W32Time: BEGIN:NTPTry -- delay
W32Time: END Line 2012
W32Time: Round trip was 16ms
W32Time: BEGIN:NTPTry -- gettime
W32Time: BEGIN:Fgmtimetonttime
W32Time: END Line 2563
W32Time: END Line 1998
W32Time: one-way delay is 8ms
W32Time: END Line 1645
W32Time: END Line 368
W32Time: BEGIN:TimeDiff
W32Time: ClockError --30
W32Time: END Line 2542
W32Time: BEGIN:FCheckTimeSanity
W32Time: Adjusting time by 30 ms. No eventlog messages since time differen
ce is 0 <1 minute
W32Time: END Line 570
W32Time: BEGIN:SetTimeNow
W32Time: Time 9/20/2010 13:53:23:557
W32Time: *****SetSystemTime()*****
W32Time: END Line 1280
W32Time: Time was 53min 23.527s
W32Time: Time is 53min 23.557s
W32Time: Error -30ms
W32Time: BEGIN:CheckLeapFlag
W32Time: END:Line 606
W32Time: BEGIN:ComputePostTimeData
W32Time: BEGIN:ComputeInterval
W32Time: END Line 2479
W32Time: BEGIN:ComputeSleepStuff
W32Time: Computed stagger is 0ms, bias is 0ms
W32Time: Time until next sync - 2699.960s
W32Time: END:Line 816
W32Time: END:Line 221
W32Time: END:Line 196
W32Time: BEGIN:TermTime
W32Time: NTP(S): received shutdown notification.
W32Time: TimeMMCleanup()
W32Time: BEGIN:FinishCleanup
W32Time: BEGIN:TsUpTheThread
W32Time: END Line 1407
W32Time: Inform NetLogon That you are not a TS Provider
W32Time: BEGIN:UnInitializeDC
W32Time: Ptrs 0 - 0
W32Time: END:Line 727
W32Time: Time service stopped.
W32Time: END:Line 407Sehe ich das richtig, dass ich bei den anderen DC's, Memberserver, Clients dann net time /setsntp:"pdc-emulator.domaene.local" setzen muss/könnte/sollte?
Weitere Frage:
Warum bekomme ich für "net time" und "W32tm /query /status" zwei unterschiedliche Server zur Synchronisation vorgeschlagen? (Einmal ist es der DC03 bei net time und bei w32tm ist es der PDC-Emulator, mit der sich zuletzt synchronisiert worden ist)
Oder spielt zukünftig nur noch w32tm eine Rolle, da es z.B. glaub ab Windows Vista kein "net time /setsntp" mehr gibt?
Im Voraus herzlichen Dank für Eure Mühe!
Lieben Gruß
Markus
So... Guten Morgen erst einmal,
wir haben jetzt das Problem, dass diverse Clients sich nicht anmelden können.
Sobald man versucht sich anzumelden, erscheint ein Dialog mit der Meldung:
Im Ereignisprotokoll steht einmal die Meldung. (zeitlich gesehen die jüngste Meldung)
davor steht dann
und
Genau die gleichen Meldungen existieren am Client für den DC03. (also scheinbar immer für den DC , an dem sich der Client versucht anzumelden...)
Ich weiß nicht, woran das liegt... Es gibt keine Vertrauensstellungen und nur diese eine Domäne...
Dies bezieht sich auf NT-Server, allerdings ist die Symptomatik genauso...
http://support.microsoft.com/kb/150518/de
Jemand noch Ideen?
Gruß
Markus
wir haben jetzt das Problem, dass diverse Clients sich nicht anmelden können.
Sobald man versucht sich anzumelden, erscheint ein Dialog mit der Meldung:
Das System kann Sie nicht bei dieser Domäne anmelden, da das Computerkonto des Systems in seiner primären
Domäne fehlt, oder das Kennwort für dieses Computerkonto falsch ist.Die Authentifizierung mit \\dc02.DOMAENE.local, einem Windows NT- oder Windows 2000-Domänen Controller für die Domäne DOMAENE, ist fehlgeschlagen. Der NTP-Server \\dc02.DOMAENE.local hat nicht reagiert. Die Signatur des vom Domänencontroller \\dc02.DOMAENE.local (193.102.227.134) in DOMAENE.local zurückgegebenen Zeitstempels ist ungültig. Wenn dieser DC aus der übergeordneten Domäne des Computers stammt, dann muss die Vertrauensstellung eventuell neu hergestellt werden. Wenn der DC aus der Domäne dieses Computers stammt, dann ist das Computerkennwort für diesen Computer falsch und sollte korrigiert werden. Genau die gleichen Meldungen existieren am Client für den DC03. (also scheinbar immer für den DC , an dem sich der Client versucht anzumelden...)
Ich weiß nicht, woran das liegt... Es gibt keine Vertrauensstellungen und nur diese eine Domäne...
Dies bezieht sich auf NT-Server, allerdings ist die Symptomatik genauso...
http://support.microsoft.com/kb/150518/de
Jemand noch Ideen?
Gruß
Markus
