Windows XP Domänen Client aktualisieren Ihre Zeit nicht mehr
Hallo an Alle,
leider habe ich mal wieder ein mysteriöses Problem bei mir im Netzwerk.
Kurzbeschreibung:
Alle Windows XP Domänenclients aktualisieren Ihre Zeit nicht mehr mit der Domäne automatisch bei der Anmeldung.
Infrastruktur:
1 x Genua Firewall (fungiert als Zeitserver)
2 x ADC Server (Windows Server 2003 SP1)
50 x Windows XP SP3 PCs
Problembeschreibung:
Die Client Rechner habe nicht mehr die gleiche Zeit wie der ADC sie übernehmen immer die Bios Zeit und die weicht mehr oder minder
bei den verschiedenen Rechner von der richtigen Zeit etwas ab. Wenn ich nach der Anmeldung ein "net time /set" durchführe ist die Welt wieder in Ordnung
bis zum nächsten Neustart dann ist wieder die Bios Zeit gesetzt. Betrifft nur die Clients
da die Server virtualisiert sind und die ESX Server sich ohne Probleme per NTP die Zeit vom ADC sich holen.
Info: der ADC bekommt seine Zeit von der Genua Firewall (diese fungiert als Zeitserver)
Zwar könnte ich alle Domänenbenutzer zu lokalen Hauptbenutzern machen und dann im Startskript eine "net time /set /yes" durchführen
aber das wäre nur meine Schlusslösung wenn ich es mit euch auch nicht hinbekomme.
Folgende Tests habe ich durchgeführt:
- wie gesagt mit net time /set funktioniert es bis zum nächsten Neustart dann holt er sichs wieder vom Bios
- net time /setsntp:<serverip> habe ich auch nochmal gesetzt falls diese nicht stimmte -> keine Änderung
- Ich habe mal die Protokollierung eingeschaltet am Client mit folgendem Auswurf:
Habt Ihr mir noch ein paar Tips wo ich noch suchen kann oder mit welchen Befehlen ich weitere Analysen machen kann??
Danke schonmal im vorraus für eure Zeit und Mühe.
Gruss
leider habe ich mal wieder ein mysteriöses Problem bei mir im Netzwerk.
Kurzbeschreibung:
Alle Windows XP Domänenclients aktualisieren Ihre Zeit nicht mehr mit der Domäne automatisch bei der Anmeldung.
Infrastruktur:
1 x Genua Firewall (fungiert als Zeitserver)
2 x ADC Server (Windows Server 2003 SP1)
50 x Windows XP SP3 PCs
Problembeschreibung:
Die Client Rechner habe nicht mehr die gleiche Zeit wie der ADC sie übernehmen immer die Bios Zeit und die weicht mehr oder minder
bei den verschiedenen Rechner von der richtigen Zeit etwas ab. Wenn ich nach der Anmeldung ein "net time /set" durchführe ist die Welt wieder in Ordnung
bis zum nächsten Neustart dann ist wieder die Bios Zeit gesetzt. Betrifft nur die Clients
da die Server virtualisiert sind und die ESX Server sich ohne Probleme per NTP die Zeit vom ADC sich holen.
Info: der ADC bekommt seine Zeit von der Genua Firewall (diese fungiert als Zeitserver)
Zwar könnte ich alle Domänenbenutzer zu lokalen Hauptbenutzern machen und dann im Startskript eine "net time /set /yes" durchführen
aber das wäre nur meine Schlusslösung wenn ich es mit euch auch nicht hinbekomme.
Folgende Tests habe ich durchgeführt:
- wie gesagt mit net time /set funktioniert es bis zum nächsten Neustart dann holt er sichs wieder vom Bios
- net time /setsntp:<serverip> habe ich auch nochmal gesetzt falls diese nicht stimmte -> keine Änderung
- Ich habe mal die Protokollierung eingeschaltet am Client mit folgendem Auswurf:
149636 07:56:19.5937500s - ---------- Log File Opened -----------------
149636 07:56:19.5937500s - Entered W32TmServiceMain
149636 07:56:19.5937500s - CurSpc:15625000ns BaseSpc:15625000ns SyncToCmos:Yes
149636 07:56:19.5937500s - PerfFreq:3158390000c/s
149636 07:56:19.5937500s - Time zone OK.
149636 07:56:19.6093750s - ReadConfig: Found provider 'NtpClient':
149636 07:56:19.6093750s - ReadConfig: 'Enabled'=0x00000001
149636 07:56:19.6093750s - ReadConfig: 'DllName'='C:\WINDOWS\system32\w32time.dll'
149636 07:56:19.6093750s - ReadConfig: 'InputProvider'=0x00000001
149636 07:56:19.6250000s - ReadConfig: Found provider 'NtpServer':
149636 07:56:19.6250000s - ReadConfig: 'Enabled'=0x00000001
149636 07:56:19.6250000s - ReadConfig: 'DllName'='C:\WINDOWS\system32\w32time.dll'
149636 07:56:19.6250000s - ReadConfig: 'InputProvider'=0x00000000
149636 07:56:19.6250000s - ReadConfig (policy): Found provider 'NtpClient':
149636 07:56:19.6250000s - ReadConfig (policy): 'Enabled'=0x00000001
149636 07:56:19.6250000s - ReadConfig: 'PhaseCorrectRate'=0x00000001
149636 07:56:19.6250000s - ReadConfig: 'UpdateInterval'=0x00007530
149636 07:56:19.6250000s - ReadConfig: 'FrequencyCorrectRate'=0x00000004
149636 07:56:19.6250000s - ReadConfig: 'PollAdjustFactor'=0x00000005
149636 07:56:19.6250000s - ReadConfig: 'LargePhaseOffset'=0x00138800
149636 07:56:19.6250000s - ReadConfig: 'SpikeWatchPeriod'=0x0000005A
149636 07:56:19.6250000s - ReadConfig: 'HoldPeriod'=0x00000005
149636 07:56:19.6250000s - ReadConfig: 'MinPollInterval'=0x0000000A
149636 07:56:19.6250000s - ReadConfig: 'MaxPollInterval'=0x0000000F
149636 07:56:19.6250000s - ReadConfig: 'AnnounceFlags'=0x0000000A
149636 07:56:19.6250000s - ReadConfig: 'LocalClockDispersion'=0x0000000A
149636 07:56:19.6250000s - ReadConfig: 'MaxNegPhaseCorrection'=0xFFFFFFFF
149636 07:56:19.6250000s - ReadConfig: 'MaxPosPhaseCorrection'=0xFFFFFFFF
149636 07:56:19.6250000s - ReadConfig: 'EventLogFlags'=0x00000002
149636 07:56:19.6250000s - ReadConfig: 'MaxAllowedPhaseOffset'=0x0000012C
149636 07:56:19.6250000s - DomainHierarchy: LSA role change notification. Redetecting.
149636 07:56:19.6250000s - ClockDisciplineThread: Starting:149636 07:56:19.6250000s - LI:3 S:0 RDl:0 RDs:0 TSF:0x0
149636 07:56:19.6250000s - Starting Providers.
149636 07:56:19.6250000s - Starting 'NtpClient', dll:'C:\WINDOWS\system32\w32time.dll'
149636 07:56:19.6250000s - NtpTimeProvOpen("NtpClient") called.
149636 07:56:19.6250000s - sysPrecision=-6, systmeClockResolution=156250
149636 07:56:19.6250000s - NtpProvider: Created 2 sockets (1 listen-only): 172.16.5.34:123, (127.0.0.1:123)
149636 07:56:19.6250000s - PeerPollingThread: waiting forever
149636 07:56:19.6250000s - ReadConfig: 'AllowNonstandardModeCombinations'=0x00000001
149636 07:56:19.6250000s - ReadConfig: 'CompatibilityFlags'=0x80000000
149636 07:56:19.6250000s - ReadConfig: 'SpecialPollInterval'=0x00000E10
149636 07:56:19.6250000s - ReadConfig: 'ResolvePeerBackoffMinutes'=0x0000000F
149636 07:56:19.6250000s - ReadConfig: 'ResolvePeerBackoffMaxTimes'=0x00000007
149636 07:56:19.6250000s - ReadConfig: 'EventLogFlags'=0x00000000
149636 07:56:19.6250000s - ReadConfig: 'CrossSiteSyncFlags'=0x00000002
149636 07:56:19.6406250s - PeerPollingThread: waiting 0.000s
149636 07:56:19.6406250s - NtpClient started.
149636 07:56:19.6406250s - Starting 'NtpServer', dll:'C:\WINDOWS\system32\w32time.dll'
149636 07:56:19.6406250s - PeerPollingThread: PeerListUpdated
149636 07:56:19.6406250s - Resolving domain hierarchy
Habt Ihr mir noch ein paar Tips wo ich noch suchen kann oder mit welchen Befehlen ich weitere Analysen machen kann??
Danke schonmal im vorraus für eure Zeit und Mühe.
Gruss
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150779
Url: https://administrator.de/contentid/150779
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
6 Kommentare
Neuester Kommentar
Also,
bei mir kam die Serverzeit immer wegen der VMware-Tools durcheinander.
Die VMs synchronisieren sich beim Start standardmäßig über die VMware-Tools mit dem ESX. (So ist es jedenfalls bei meinen ESXi 4.1 Servern)
Da die Zeit am ESX nicht stimmte, habe ich deswegen auch Probleme mit der Zeit im LAN gehabt.
Nur so als kleiner Tip.
Ansonsten wüßte ich nicht, was so schlecht daran sein sollte die Uhrzeit per Script zu synchronisieren und wie sich das alternativ bewerkstelligen lässt.
bei mir kam die Serverzeit immer wegen der VMware-Tools durcheinander.
Die VMs synchronisieren sich beim Start standardmäßig über die VMware-Tools mit dem ESX. (So ist es jedenfalls bei meinen ESXi 4.1 Servern)
Da die Zeit am ESX nicht stimmte, habe ich deswegen auch Probleme mit der Zeit im LAN gehabt.
Nur so als kleiner Tip.
Ansonsten wüßte ich nicht, was so schlecht daran sein sollte die Uhrzeit per Script zu synchronisieren und wie sich das alternativ bewerkstelligen lässt.
Was sagt das Ereignisprotokoll des betroffenen Clients unter W32Time ?
Der DC liefert normalerweise die Zeit für sein Netz, wenn die Zeitdifferenz zwischen DC und Client zu groß wird (ich habs grad ned im Kopf) funktioniert die Domänenanmeldung über Kerberos nicht mehr.
Wenn DNS und AD ok ist gibt eigentlich erst mal keinen Grund warum NTP ned gehen sollte..
Der DC liefert normalerweise die Zeit für sein Netz, wenn die Zeitdifferenz zwischen DC und Client zu groß wird (ich habs grad ned im Kopf) funktioniert die Domänenanmeldung über Kerberos nicht mehr.
Wenn DNS und AD ok ist gibt eigentlich erst mal keinen Grund warum NTP ned gehen sollte..
Hallo,
@ChrisIO
Unsere Client sind nicht Virtualisiert und habe deswegen auch keine VMWare Tools installiert. Bei den Server die Virtualisiert sind ist das Zeitproblem nicht vorhanden.
Ich müssten den user Hauptbenutzer Rechte geben was ich eigentlich nicht möchte.
@Karo
Nein die Clients sollen Ihre Zeit vom ADC übernehmen. Die Clients holen doch Standardmäßig die Zeit von AD wenn die Kommunikation mit Kerberos aufgebaut wird, oder
habe ich da was falsch verstanden?
@moebelwachs
Das komische ist ja das im Ereignisprotokoll keine einziger NTP (W32tm Fehler) auftaucht also ob alles Supi wäre. Sobald ein der Rechner 5 - 10 min vor geht klappt
dann auch die Anmeldung nicht mehr. Ach so DNS und AD melden keine Fehler. Und deswegen finde ich es ja mysteriös! grins
@ChrisIO
Unsere Client sind nicht Virtualisiert und habe deswegen auch keine VMWare Tools installiert. Bei den Server die Virtualisiert sind ist das Zeitproblem nicht vorhanden.
Ich müssten den user Hauptbenutzer Rechte geben was ich eigentlich nicht möchte.
@Karo
Nein die Clients sollen Ihre Zeit vom ADC übernehmen. Die Clients holen doch Standardmäßig die Zeit von AD wenn die Kommunikation mit Kerberos aufgebaut wird, oder
habe ich da was falsch verstanden?
@moebelwachs
Das komische ist ja das im Ereignisprotokoll keine einziger NTP (W32tm Fehler) auftaucht also ob alles Supi wäre. Sobald ein der Rechner 5 - 10 min vor geht klappt
dann auch die Anmeldung nicht mehr. Ach so DNS und AD melden keine Fehler. Und deswegen finde ich es ja mysteriös! grins