14
Zeitserver soll Zeit an alle Clients verteilen
Hallo zusammen,
Problemstellung:
Wir haben ein Rechner (XP Pro) der empfängt von ca. 20 Clients Informationen zur Betriebsdatenerfassung (Zeit,Personalnummer,Produktionsnummer...)
Es gibt Probleme wenn die Systemzeit der Clients zu weit von der Serverzeit entfernt ist.
Meine Überlegung:
Der Domain-Controler arbeitet als Zeitserver und syncronisiert alle Client und Arbeitsplätze
mehrmals am Tag.
Am DC habe ich bereits in der Gruppenrichtlinie einige Einstellungen (NTP) vorgenommen.
Kann ich via Gruppenrichtlinie allen Rechnern im Netz sagen das sie sich mit dem DC abgleichen sollen?
Oder gibt es eine andere Lösung?
Grüße
Ralph
Problemstellung:
Wir haben ein Rechner (XP Pro) der empfängt von ca. 20 Clients Informationen zur Betriebsdatenerfassung (Zeit,Personalnummer,Produktionsnummer...)
Es gibt Probleme wenn die Systemzeit der Clients zu weit von der Serverzeit entfernt ist.
Meine Überlegung:
Der Domain-Controler arbeitet als Zeitserver und syncronisiert alle Client und Arbeitsplätze
mehrmals am Tag.
Am DC habe ich bereits in der Gruppenrichtlinie einige Einstellungen (NTP) vorgenommen.
Kann ich via Gruppenrichtlinie allen Rechnern im Netz sagen das sie sich mit dem DC abgleichen sollen?
Oder gibt es eine andere Lösung?
Grüße
Ralph
Danke schon mal vorab ++
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 90659
Url: https://administrator.de/contentid/90659
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
14 Kommentare
Neuester Kommentar
servus,
du mußt "normalerweise" nicht täglich mehrmals die Zeit synchronisieren.
ein Ausweg (einer von vielen) - ist z.B.
Als startupscript bei den Computern in der AD einzutragen - aber "normalerweise" machen die das von alleine, wenn der NTP läuft.
du mußt "normalerweise" nicht täglich mehrmals die Zeit synchronisieren.
ein Ausweg (einer von vielen) - ist z.B.
Net time %logonserver% /set /yes
Wär ja schön, wenn das so wäre. Leider habe ich auch die bittere Erfahrung gemacht, dass weder AD-integriert noch mit GPOs den miserabel funktionierenden Zeitdiensten von Microsoft nicht auf die Beine zu helfen ist. Ich habe jedoch mit GPOs NTP-Client aktiviert und als Quelle einen IPCOP angegeben, der sich seinerseits täglich einmal über einen Internet-Zeitdienst synchronisiert. Das klappt auch recht zuverlässig. Zumindest zuverlässig genug, um keine Netzwerkprobleme zu haben.
Gruß,
TC
Timo's Idee finde ich auch ok, könnte aber zu Berechtigungsproblemen führen. Hierzu eine GPO erweitern und die Zeitumstellungsberechtigung an eine Benutzergruppe Deiner Wahl anvertrauen. Oder eine eigene domänenlokale Sicherheitsgruppe anlegen und die zu berechtigenden User da hinein legen.
nochmals Gruß
Gruß,
TC
Timo's Idee finde ich auch ok, könnte aber zu Berechtigungsproblemen führen. Hierzu eine GPO erweitern und die Zeitumstellungsberechtigung an eine Benutzergruppe Deiner Wahl anvertrauen. Oder eine eigene domänenlokale Sicherheitsgruppe anlegen und die zu berechtigenden User da hinein legen.
nochmals Gruß
und die zu berechtigenden User da hinein legen.
Ähem...Als startupscript bei den Computern nicht bei den Usern - war des TimoBeils idee
Wenn Du eine Windows-Domäne am laufen hast, brauchst Du definitiv nichts zu tun. Der PDC-Emulator der Domäne synchronisiert die Systemzeit mit den Clients von ganz alleine.
Wenn die Zeit auf den Clients nicht mit dem Server übereinstimmt, hast du ganz andere Probleme. Wir haben ca. 11000 Clients laufen und die Zeit passt überall.
Wenn die Zeit auf den Clients nicht mit dem Server übereinstimmt, hast du ganz andere Probleme. Wir haben ca. 11000 Clients laufen und die Zeit passt überall.
Hallo,
was könnten das für Probleme sein?
Die Zeutproblematik war meine erste Überlegung, vieleicht bin ich total falsch...
was könnten das für Probleme sein?
Die Zeutproblematik war meine erste Überlegung, vieleicht bin ich total falsch...
@ Warze69
pauschal gesehen ist deine Antwort "sowas" von pauschal
Der PDC-Emulator der Domäne synchronisiert im Idealfall die Systemzeit mit den Clients von ganz alleine.
Deine 11000 Clients sind bestimmt nicht an einem einzigen Standort - bei euch ist dann in jedem Router auf jeder Firewall der Port 123 offen usw usf.
Ich hab Standorte - da klappt das wunderbar - ich hab Standorte - da klappt es nicht - und alle Standorte habe ich selber eingerichtet ;-/
(Daher habe ich normalerweise auch schön in Hochkommas gesetzt.)
Vertrauen ist gut - Kontrolle ist besser
pauschal gesehen ist deine Antwort "sowas" von pauschal
Der PDC-Emulator der Domäne synchronisiert die Systemzeit mit den Clients von ganz alleine.
sollte besser heißen:Der PDC-Emulator der Domäne synchronisiert im Idealfall die Systemzeit mit den Clients von ganz alleine.
Deine 11000 Clients sind bestimmt nicht an einem einzigen Standort - bei euch ist dann in jedem Router auf jeder Firewall der Port 123 offen usw usf.
Ich hab Standorte - da klappt das wunderbar - ich hab Standorte - da klappt es nicht - und alle Standorte habe ich selber eingerichtet ;-/
(Daher habe ich normalerweise auch schön in Hochkommas gesetzt.)
Vertrauen ist gut - Kontrolle ist besser
Klingt komisch, ist aber so.
Also eine Möglichkeit wäre folgende:
In den Gruppenrichtlinien den Usern das Ändern der Systemzeit erlauben.
Und wie Du schon beschrieben hast, im Anmeldescript "net time %logonserver% /set /yes.
Das mit dem Startscript für Computer würde ich nicht machen. Erfahrungsgemäß hat der Client oft noch keine Netzverbindung, dadurch funktioniert das Script nicht.
Ansonsten würde ich mir die Ereignisprotokolle genauer ansehen. Der Fehler kann auch durch einen falsch konfigurierten DNS-Server hervorgerufen werden.
Also eine Möglichkeit wäre folgende:
In den Gruppenrichtlinien den Usern das Ändern der Systemzeit erlauben.
Und wie Du schon beschrieben hast, im Anmeldescript "net time %logonserver% /set /yes.
Das mit dem Startscript für Computer würde ich nicht machen. Erfahrungsgemäß hat der Client oft noch keine Netzverbindung, dadurch funktioniert das Script nicht.
Ansonsten würde ich mir die Ereignisprotokolle genauer ansehen. Der Fehler kann auch durch einen falsch konfigurierten DNS-Server hervorgerufen werden.
Die Terminals sind 24h/Tag in Betrieb.
Teils sind es PC´s teils ThinClients via TS.
Erst habe ich vermutet das die ThinClients die Zeitverschiebung verursachen.
Diese arbeiten über RDP und werden durch die GP nach 15 min getrennt und nach weiteren 15 min abgemeldet.
Das habe ich gemacht weil wir 10 Lizenzen für die Terminals haben. Wenn dass Programm beendet wird - ist wieder eine Lizenz frei.
Aber wie gesagt, das Problem taucht immer wieder an verschiedenen PC´s auf.
Ich werde morgen erst mal die Vorschläge testen.
Teils sind es PC´s teils ThinClients via TS.
Erst habe ich vermutet das die ThinClients die Zeitverschiebung verursachen.
Diese arbeiten über RDP und werden durch die GP nach 15 min getrennt und nach weiteren 15 min abgemeldet.
Das habe ich gemacht weil wir 10 Lizenzen für die Terminals haben. Wenn dass Programm beendet wird - ist wieder eine Lizenz frei.
Aber wie gesagt, das Problem taucht immer wieder an verschiedenen PC´s auf.
Ich werde morgen erst mal die Vorschläge testen.
Moin,
"Dann" und nur deswegen - funktioniert das mit dem Startupscript der Rechner natürlich nicht...
Denn dieses Skript - wird nur beim starten durchexerziert.
Jetzt ist also die Frage, nach den ThinClients - was für ein OS läuft da und sind das echte Thinclients?
Die Terminals sind 24h/Tag in Betrieb.
"Dann" und nur deswegen - funktioniert das mit dem Startupscript der Rechner natürlich nicht...
Denn dieses Skript - wird nur beim starten durchexerziert.
Das mit dem Startscript für Computer würde ich nicht machen.
Erfahrungsgemäß hat der Client oft noch keine Netzverbindung, dadurch funktioniert das Script nicht.
Da hab ich andere Erfahrungen gesammelt - WSUS / Office und sonstige Gruppenrichtlinien bekommen die Computer / User "mehr" oder weniger über den gleichen Weg - ergo -natürlich haben die eine Netzverbindung Erfahrungsgemäß hat der Client oft noch keine Netzverbindung, dadurch funktioniert das Script nicht.
Jetzt ist also die Frage, nach den ThinClients - was für ein OS läuft da und sind das echte Thinclients?
- Sind Die in der Domain?
wenn ja - notfalls per psexec das " Net time computername-IP /set /yes laufen lassen
- Läuft die Uhr des Terminalservers (irgendwann) falsch oder die der Clients?
Morgen zusammen,
die Terminalserver sind in der Domäne, die ThinClients läufen unter Win CE4.0
Die Zeit auf den TS ist ok.
am besten wäre es wenn ich alle paar Stunden ein Zeitabgleich erzwingen könnte.
Im gesamten Netzwerk.
grübel
die Terminalserver sind in der Domäne, die ThinClients läufen unter Win CE4.0
Die Zeit auf den TS ist ok.
am besten wäre es wenn ich alle paar Stunden ein Zeitabgleich erzwingen könnte.
Im gesamten Netzwerk.
grübel
*grübel*
...nicht zu lange, besorg dir Psexec - lass es laufen (/nolicpromt kann es nicht) und bestätige die Eula.
Wenn dein Netz 192.168.0.0 ist - kannst du das script so in einen Ordner kopieren - andernfalls die Zeile
Das script sucht zuerst mal alle Systeme (xxx.xxx.xxx.2 - xxx.xxx.xxx.254) im Netz heraus, die an sind - schreibt diese in die log Datei, die das Psexec dann später als Grundlage für das net time /set /yes nimmt.
Den kladderadatsch kannst du dann auch als geplanten Task auf einem Server/deinem Rechner alle x Stunden laufen lassen.
Gruß
...nicht zu lange, besorg dir Psexec - lass es laufen (/nolicpromt kann es nicht) und bestätige die Eula.
Wenn dein Netz 192.168.0.0 ist - kannst du das script so in einen Ordner kopieren - andernfalls die Zeile
SET ip=192.168.0.
an dein Netz anpassen.@ECHO off
cls
SET ip=192.168.0.
SET log=netz.txt
IF EXIST %log% DEL %log%
FOR /L %%i IN (2,1,254) DO (
ping -n 1 -w 5 %ip%%%i|find "TTL=" && ECHO %ip%%%i >> %log% || echo %ip%%%i nicht erreichbar
)
:psexec
psexec @%log% -u domain\administrator -p password -i cmd.exe /c net time %logonserver% /set /yesDas script sucht zuerst mal alle Systeme (xxx.xxx.xxx.2 - xxx.xxx.xxx.254) im Netz heraus, die an sind - schreibt diese in die log Datei, die das Psexec dann später als Grundlage für das net time /set /yes nimmt.
Den kladderadatsch kannst du dann auch als geplanten Task auf einem Server/deinem Rechner alle x Stunden laufen lassen.
Gruß
Ja Hammer...
heute schaffe ich es leider nicht mehr es zu testen.
Vielen Dank schon mal....
RAlph
heute schaffe ich es leider nicht mehr es zu testen.
Vielen Dank schon mal....
RAlph
Yupp mach das
Vielleicht sollte das Script noch etwas verfeinert werden - derzeit findet er von 2 -254 alle Systeme - vielleicht solltest du einzelne Systeme (zumindestens den Zeitgebenden) herausnehmen, oder nur einen Bereich - denn er findet jetzt auch alle Netzwerkdrucker und evtl. Switche.
Den Bereich kannst du anpassen, wenn du in Zeile 6
Bastla oder Biber würden sicher in der For Schleife etwas drehen, um ein einzelnes System auszugrenzen
Ich würde es so (uneleganter) lösen (um die 192.168.0.111 auszugrenzen):
Vielleicht sollte das Script noch etwas verfeinert werden - derzeit findet er von 2 -254 alle Systeme - vielleicht solltest du einzelne Systeme (zumindestens den Zeitgebenden) herausnehmen, oder nur einen Bereich - denn er findet jetzt auch alle Netzwerkdrucker und evtl. Switche.
Den Bereich kannst du anpassen, wenn du in Zeile 6
(2,1,254) [fange bei 2 an und höre bei 254 auf]
änderst.(10,1,200) [fange bei 10 an und höre bei 200 auf]
Bastla oder Biber würden sicher in der For Schleife etwas drehen, um ein einzelnes System auszugrenzen
Ich würde es so (uneleganter) lösen (um die 192.168.0.111 auszugrenzen):
findstr /v 192.168.0.111 %log% >>%log%.ini
:psexec
psexec @%log%.ini -u domain\administrator -p password -i cmd.exe /c net time %logonserver% /set /yes
Ich habe geschrieben, dass ich Deine Idee gut finde. Ich habe das so gemeint, dass aufgrund der Berechtigungsprobleme, die ich da sehe, ich den Weg über die User gehen würde.
Obs mit einem Startskript für Computer funktioniert, bleibt halt zu testen.
Gruß,
TC
Obs mit einem Startskript für Computer funktioniert, bleibt halt zu testen.
Gruß,
TC
