Zeitabgleich mit lokalem Server als Dienst einrichten

#1 Tach zusammen,

wir haben hier bei Clients einer W2K-Domäne ein Problemchen. Die Clients machen Mist, denn deren Zeit verstellt sich hin und wieder. Je nach dem verweigert dann der Client die Anmeldung beim Server, weil die Zeit zu stark abweicht. Wir haben mittlerweile keine Lust mehr nach dem Fehler zu suchen, sondern wollen, dass sich jeder Client beim Booten die Serverzeit abholt und bei sich setzt.
Nun gut, das ginge mit ner Batch, wo drinsteht "net time \\servername /set /yes".
Aber: Die Batch muss VOR der Anmeldung, eben beim Hochfahren, ausgeführt werden, aber natürlich erst nachdem der Client mit dem Server verbunden ist.

Wir sind im Moment noch am experimentieren mit der Registry HKLM...RUN. Am liebsten würden wir diese Batchdatei als Dienst eintragen, aber ich weiß leider nicht, wie das geht.
Eine andere theoretische Möglichkeit wäre doch dem DHCP beim Server beizubringen, immer dann, wenn eine neue IP vergeben wurde, die aktuelle Zeit hinterher zu schicken.

Hat einer so am Wochenende nen Tip parat, sodass wir am Montag schneller zum Ziel kommen? Google ist schon heißgelaufen, hat aber bisher noch keinen richtigen Tip ausgespuckt.

Gruß Reinhart

P.S. Dann fehlt mir so ganz allgemein mal ne Information, in welcher Reihenfolge die verschiedenen Dienste ausgeführt werden: Dienste, Autostart, Netzwerkverbindeungen, HKLM..RUN

#2 Moin Reinhart,

der Dienst dafür ist bereits vorhanden. Er nennt sich "Windows Zeitgeber" und zeichnet dafür verantwortlich,
dass sich in deinem konkreten Fall die Clients in einer Domäne mit dem DC zeitmässig per default synchronisieren.
Vorausgesetzt natürlich, dieser Dienst ist aktiv und wurde nicht manuell oder durch Siff-Programme wie XPAntiSpy
disabled.
In der Theorie sehe es also so aus, dass der DC sich die genaue Uhrzeit von einen NTP Server aus dem WAN holt
und sich die Clients bei ihm abgleichen. Per Registry Eintrag kannst du optional die Häufigkeit und die Quelle für
das Update spezifizieren[1].
Soweit ich das an einem W2K AS und einem 2K Client feststellen konnte, erfolgt die erste Synchronisation
lt. Ereignisprotokoll ungefähr zu dem Zeitpunkt des Erscheinens des Anmeldebildschirms (bei den Clients).
Der Server war zwar kein DC, ich denke aber das dies bei dem Test unerheblich war.

These: Wenn die Zeitsynchronisation sowohl auf dem Server als auch bei den Clients konfiguriert und etabliert ist
verzögere einfach die Anmeldung bei den defekten Maschinen. Lasse den Anmeldebildschirm 2-5 Minuten so wie
er ist und versuche erst dann den Login.
Klappt es nicht, checke mal das Ereignisprotokoll bei den Clients. Ohne Gewähr, Versuch macht klug.

DHCP: Netter Ansatz. Trotz vieler Optionen, die du bei einem 2K Server per DHCP übermitteln kannst, habe ich keine
gefunden, die die Uhrzeit bei den Clients synchronisiert. Wäre natürlich ideal, wenn dies nach einem DHCP Request
geschehen könnte.

Reihenfolge:
- Dienste
-> jetzt folgt Login/Authentifizierung, danach...
- HKLM..RUN
- Autostart

Die Netzwerkverbindungen werden/können während des gesamten Bootvorgangs konfiguriert und gestartet
werden. Die elementar wichtigen sind beim Anmeldescreen bereits abgeschlossen, optionale (bspw. gemappte LW)
werden danach realisiert.

[1]http://support.microsoft.com/kb/223184/de

Gruß,

Sepia

#3 Hallo Sepia,

erstmal danke für die Infos, genau den Supportartikel kann ich gut brauchen.
Ich selber habe auch schon eine andere schöne Lösung gefunden. Du nimmst das Batch von oben und schreibst es in die geplanten Tasks rein, und schon gleicht der Client die Zeit VOR der Anmeldung ab. Zumindest geht das hier zuhause bei meiner Workgroup. Dieses Verfahren scheint mir auf den ersten Blick bequemer zu sein.

Wir müssen jetzt mal morgen bei den Clients in die Registry kucken, was da so steht. Serverseitig haben wir w23time abgeschaltet, weil die Zeit von unserem eigenen Proxy geholt wird (ntp0.fau.de, Uni Erlangen). Aber das dürfte auf das Verhalten der Clients keinen Unterschied machen.
Eine serverseitige Lösung würde nur einen Bruchteil der Zeit kosten, danach suche ich weiter.

Woher hast du die Reihenfolge? Ich würde nämlich bezweifeln, dass HKLM/RUN erst nach der Anmeldung abgeht. Denn wozu heisst der Zweig HKLM im Unterschied zu HKCU? Außerdem tragen sich da Firewall und AVscanner ein, die sähen echt alt aus, wenn sie erst dann gestartet würden. NeNe, da brauch ich schon eine offizielle Quelle, auch genauer. Beispielsweise wo klinken sich die Gruppenrichtlinien ein?

Danke für deine Recherchen

R

#4

Zitat

Woher hast du die Reihenfolge?

Dozent in 2002, MCT. Hab's auch schwarz auf weiß als Kopie aus irgendeiner Literatur.

Zitat

Außerdem tragen sich da Firewall und AVscanner ein, die sähen echt alt aus, wenn sie erst dann gestartet würden.

Jein, Ja!
Jein: Ein Virenkiller oder eine Firewall die *ausschliesslich* über die RUN Einträge aktiviert wird sollte
fachgerecht entsorgt werden! Häufig jedoch werden DIENST *und* weitere RUN Startoptionen gemeinsam von
der Software benutzt. Dies ist bei AO so, beim KAV und wird bestimmt für viele weitere Programme so sein.
Ja: Ja, das wäre so wenn obiges nicht zutreffen würde.

Zitat

Beispielsweise wo klinken sich die Gruppenrichtlinien ein?

Benutzergebundene Policies logischerweise erst nach der Anmeldung, globale oder System Policies vorher.

Zitat

NeNe, da brauch ich schon eine offizielle Quelle, auch genauer.

Nihilist? Ok, ich schaue mal.

Edit: Für Nt 4.0: http://www.winfaq.de/faq_html/tip0266.htm
Für XP: http://www.jasik.de/tipps%20&%20tricks/tipp76.htm


Gruß,

Sepia

#5 Klar und deutlich, ich danke. Komme bei der Reihenfolge jetzt selber weiter.

Nihilist - einer der alle Werte, Ziele und Ordnungen verneint. So einer soll ich sein? Ich bezweifle vieles und bin genau

Gruß Reinhart

#6 Ha, @sepia, ich antworte mir schon selber
Ich denk mal mit den Gruppenrichtlinien könnte es gehen. Du kannst nämlich bei Computerkonfiguration Scripts (also auch ein Batch) einfügen. Wenn dieser Teil der GPOs vor der Anmeldung verarbeitet wird - wie du sagst -, dann wär's das.