Zeitprobleme im AD nach Umzug

Hallo zusammen,
ich habe hier leider nach einem Umzug am letzten Wochenende (während der Sommerzeitumstellung) ein Problem mit den Zeiten im AD.

Leider hatten wir aufgrund von diversen Versäumnissen zunächst kein Internet am neuen Standort zur Verfügung. Warum nun die Uhren eine Stunde vorgehen ist mir leider auch nicht ganz klar.

Ich habe vor allem Angst, dass mir nun das hier vorhandene Setup "um die Ohren fliegt", wenn ich am FSMO-Inhaber wieder gegen eine Internetuhr synchronisiere weil mir nicht klar ist, ob die anderen Server erstmal aus dem AD "rausfliegen" bzw. sich zumindest nicht mehr authentifizieren können, sobald da ja zunächst eine grosse Abweichung von ca. 1 Stunde entsteht ?
Macht es Sinn zuvor die Kerberos-Richtlinie "Max. Toleranz für die Synchronisation des Computertakts" unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kerberos-Richtlinie auf z.B. 75 Minuten zu stellen??

Folgendes Setup ist hier vorhanden:

Windows Server 2003 R2 als DC (Blech)
Windows SBS 2011 als DC mit der FSMO-Rolle (virtualisiert)
Windows Server 2008 R2 als Mitgliedsserver mit MS-SQL (virtualisiert)

2 x HyperV 2008 R2 im Failovercluster (ebenfalls Mitglied in der Domäne)

Im Eventlog des SBS wird der bekannte Fehler mit der ID 50 geloggt:
Der Zeitdienst hat eine Zeitdifferenz von mehr als 5000 ms auf 900 Sekunden festgestellt. Die Zeitdifferenz wurde möglicherweise durch die Synchronisation mit einer ungenauen Zeitquelle oder durch schlechte Netzwerkbedingungen verursacht. Von nun an wird der Zeitdienst nicht mehr synchronisiert, die Zeit keinem weiteren Client mehr zur Verfügung gestellt und die Systemuhr nicht mehr synchronisiert. Sobald ein gültiger Zeitstempel von einem Zeitdienstanbieter empfangen wird, wird der Zeitdienst sich selbst korrigieren.

Würde mich über sachdienliche HInweise freuen, wie ich das am besten wieder geradebiegen kann.

Danke,
Manne,

Hier noch ein paar weitere Infos:

Ausgabe von w32tm /query / configuration

[Konfiguration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 5 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 3600 (Lokal)
MaxPosPhaseCorrection: 3600 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)

FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)

[Zeitanbieter]
NtpClient (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Lokal)
ResolvePeerBackoffMaxTimes: 7 (Lokal)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 1 (Lokal)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 900 (Lokal)
Type: NTP (Lokal)
NtpServer: ptbtime1.ptb.de,ptbtime2.ptb.de,ptbtime3.ptb.de (Lokal)

NtpServer (Lokal)
DllName: C:\Windows\system32\w32time.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)

VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)

Ausgabe von w32tm /query /status

Sprungindikator: 3(die letzte Minute umfasst 61 Sekunden)
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: 06.04.2014 19:15:34
Quelle: Local CMOS Clock
Abrufintervall: 6 (64s)

Ausgabe von netdom query fsmo

Schemamaster ABC-SBSSRV.my_local_domain.local
Domänennamen-Master ABC-SBSSRV.my_local_domain.local
PDC ABC-SBSSRV.my_local_domain.local
RID-Pool-Manager ABC-SBSSRV.my_local_domain.local
Infrastrukturmaster ABC-SBSSRV.my_local_domain.local

ABC-SBSSRV ist wie oben erwähnt der virtualisierte SBS2011. ("ABC" und "my_local_domain" sind hier natürlich Platzhalter)

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

Content-ID: 234712

Url: https://administrator.de/forum/zeitprobleme-im-ad-nach-umzug-234712.html

Ausgedruckt am: 23.12.2024 um 11:12 Uhr

3 Kommentare

Neuester Kommentar

N'Abend.

"Rausfliegen" wird mit Sicherheit keine Maschine aus dem AD, auch ohne die GPO anzupacken.
Bestenfalls lässt du mal deinen PDC-Emulator die Zeitsynchronisation ausführen und stellst sicher, dass die dann auch passt. Danach kannst du auf allen anderen Servern und Clients einfach den Zeitdienst neu starten oder schlicht die komplette Maschine - beim Booten synchronisieren die sich dann gegen den PDC (immer innerhalb eines AD, sofern nicht anders konfiguriert).

Cheers,
jsysde

Hmm ... habe es jetzt mal versucht mit w32tm /resync mit folgendem Ergebniss:

Der Zeitdienst hat festgestellt, dass die Systemzeit um -3750 Sekunden geändert werden muss.
Die Systemzeit kann durch den Zeitdienst um maximal 3600 Sekunden geändert werden.
Stellen Sie sicher, dass die Uhrzeit und Zeitzone richtig sind und dass die Zeitquelle ptbtime1.ptb.de,ptbtime2.ptb.de,ptbtime3.ptb.de (ntp.m|0x0|0.0.0.0:123->192.53.103.108:123) ordnungsgemäß ausgeführt wird.

Ausserdem lese ich hier z.B., dass man die Zeit auf einem PDC nie in die vergangenheit zurückstellen soll.
http://www.mcseboard.de/topic/179845-zeitdienst-w32tm-resync-rediscover ...

Auf dem PDC habe ich jetzt lediglich die oben erwähnte Toleranz in der Default Domain Policy auf 90 Minuten gestellt. Ansonsten gab es keine (mir bekannten) Änderungen am AD. Ich muss die Zeit ja zurückstellen um wieder "in time" zu sein .... also was nun?

Mit leicht gerunzelter Stirn,
Manne.