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:

 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/forum/windows-xp-domaenen-client-aktualisieren-ihre-zeit-nicht-mehr-150779.html

Ausgedruckt am: 24.12.2024 um 01:12 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.

Hi,

also hier gleicht jeder Client seine Zeit Nicht mit dem DC ab, sondern mit einer externen Quelle?
Ich würde eher den DC als NTP Server konfigurieren und den Clients dies per GPO eintrichtern.

Karo

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..

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

Wer hat auf den Clients die Berechtigung die Zeit zu ändern ?

Hier sollte auf jeden Fall "JEDER" die Berechtigung haben.

Via GPO oder durch ntrights.exe (+r SeSystemtimePrivilege -u Jeder ) kannst Du das entsprechende einstellen.