Marius1990 Geschrieben 25. Februar 2014 Teilen Geschrieben 25. Februar 2014 (bearbeitet) Hallo zusammen, ich habe in der Firma ein Problem, welches mich jetzt schon seit Donenrstag wahnsinnig macht. Wir haben in unserer 2003er Domäne den Domaincontroller mit einem NTP Server synchronisiert, welcher bei uns auf dem Dach steht und sich per GPS die Uhrzeit holt. Dann wurde eine Gruppenrichtlinie angelegt, welche die Clients anweist über w32time die Uhrzeit vom Domaincontroller zu holen. Das Ganze für ca 3000 Clients (hautsächlich noch XP SP3) - verteilt auf 9 Standorte. Jetzt tritt an genau einem Standort an eingien Rechnern (aktuell ca. 20) das Problem auf, dass sie beim Booten bei "Computereinstellungen werden geladen" hängen bleiben. Im Anwendungslog steht dann Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1054 Datum: 25.02.2014 Zeit: 09:49:24 Benutzer: NT-AUTORITÄT\SYSTEM Computer: XX-0120 Beschreibung: Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen. Die automatische Zertifikatregistrierung für "lokaler Computer" konnte keine Verbindung zum Active Directory (0x8007054b) herstellen. Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. Die Registrierung wird nicht durchgeführt. und im Systemlog Ereignistyp: Fehler Ereignisquelle: NETLOGON Ereigniskategorie: Keine Ereigniskennung: 5719 Datum: 25.02.2014 Zeit: 09:48:24 Benutzer: Nicht zutreffend Computer: XX-0120 Beschreibung: Es steht kein Domänencontroller für die Domäne XXX aus folgendem Grund zur Verfügung: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. . Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist, und versuchen Sie es erneut. Wenden Sie sich an den Domänenadministrator, wenn das Problem weiterhin besteht. Ereignistyp: Warnung Ereignisquelle: W32Time Ereigniskategorie: Keine Ereigniskennung: 14 Datum: 25.02.2014 Zeit: 09:49:38 Benutzer: Nicht zutreffend Computer: XX-0120 Beschreibung: Der Zeitanbieter "NtpClient" konnte keinen Domänencontroller als Zeitquelle finden. Der Vorgang wird in 15 Minuten wiederholt. Ereignistyp: Fehler Ereignisquelle: W32Time Ereigniskategorie: Keine Ereigniskennung: 29 Datum: 25.02.2014 Zeit: 09:49:38 Benutzer: Nicht zutreffend Computer: XX-0120 Beschreibung: Der Zeitanbieter "NtpClient" wurde für die Zeiterfassung von mehreren Zeitquellen konfiguriert. Es ist jedoch Keine der Quellen verfügbar. Innerhalb der nächsten 14 Minuten wird kein Versuch unternommen, eine Verbindung mit der Quelle herzustellen. Der NtpClient verfügt über keine Quelle mit genauer Zeit. Ich verstehe einfach nicht warum die den Domänecontroller nicht erreichbar sind. Und vor allem tritt das Problem nur an einem Standort auf - an dem wo die Domänecontroller stehen. 1 Rechner habe ich durch Patches wieder zum laufen gebarcht, aber eben nur einen. Kennt jemand von euch das Problem? Bearbeitet 25. Februar 2014 von Marius1990 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Tiro Geschrieben 25. Februar 2014 Teilen Geschrieben 25. Februar 2014 Normalerweise holen sich die Clients, die Zeit automatisch von einem DC, die sich alle wiederum die Zeit vom DC mit der PDC Emulator Rolle holen, der sich die Zeit irgendwo im Netz besorgt. Daher hätte ich auf die GPO verzichtet. Prüfe daher mal auf einem dieser Rechner, ob alle GPOs überhaupt verarbeitet werden. Da würde ich zuerst einhaken. *nachdenk* unter XP mit dem Befehl rsop.msc Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Marius1990 Geschrieben 25. Februar 2014 Autor Teilen Geschrieben 25. Februar 2014 Das Problem ist, dass wir die Richtlinie schon wieder gelöscht haben, da es eben zu Problemen geführt hat und wir Angst hatten, dass sich übers Wochenende noch mehrere Rechner damit "anstecken". - Die Probleme treten immernoch auf. Habe an besagten Rechnern nun den Windows Zeitdienst deaktiviert, dann geht es. Eine zufriedenstellende Lösung ist das aber leider nicht. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Marius1990 Geschrieben 26. Februar 2014 Autor Teilen Geschrieben 26. Februar 2014 So jetzt nicht ganz so müde wie gestern Abend noch ein zusatz für die o.g. Antwort Ich habe bei der umstellung des Zeitservers am Donnerstag zusätzlich auf allen Rechnen den K9-Time-Service entfernt, mit dem haben wir früher die Zeitddinge auf den Clients geregelt. Der Windows Zeitdienst war bis dahin immer deaktiviert wesshalb wir wahrscheinlich keine Probleme hatten. Seit dann am Donnerstag eben der Windows Zeitdienst aktiviert wurde, tritt dieses Problem auf. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
paperdoll Geschrieben 26. Februar 2014 Teilen Geschrieben 26. Februar 2014 Es macht schon sinn eine GPO für die Clients zu erstellen um den Zeitdienst generell zu aktivieren und auf NT5DS einzustellen. Mehr muss an den Clients eigentlich nicht gemacht werden. Eine weitere GPO sollte den NTP Server auf dem PDC-Emulator konfigurieren. Vermutlich ist an den Clients noch eine merkwürdige config des Windows Zeitdienstes aktiv, das solltest du prüfen - zur not Beispielhaft manuell den Zeitdienst konfigurieren und dann die Synchronisation testen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Marius1990 Geschrieben 26. Februar 2014 Autor Teilen Geschrieben 26. Februar 2014 Naja ich habe die Registry und die w32time.dll bereits mit einem funktionierenden Rechner verglichen, da war alles identisch. Mir ist sonst kein Ort bekannt wo ich noch ne config dafür finde. Das Syncronisieren ist nicht das Problem, das klappt... wenn man den Rechner ohne Netzwerkkabel gebootet hat und es nach dem Bootvorhgang wieder anschließt. Das Problem tritt nur beim Bootvorgang mit Netzwerkkabel auf. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Nordblock Geschrieben 26. Februar 2014 Teilen Geschrieben 26. Februar 2014 Moin Marius, lese Dir mal die Tipps von Microsoft zu dem Event 5719 durch: Ereignis-ID 5719 wird protokolliert, wenn Sie Mitglied einer Domäne starten Vielleicht hilft es ja weiter. Frohes Schaffen & Gruß Nordblock :-) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
da_doni Geschrieben 1. März 2014 Teilen Geschrieben 1. März 2014 Gibts denn an dem problematischen Remotestandort einen DC oder sollen sich die Clients die Zeit übers WAN holen? Stimmen Datum und Zeit auf den PCs am Remotestandort mit den Daten am DC überein? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Marius1990 Geschrieben 4. März 2014 Autor Teilen Geschrieben 4. März 2014 (bearbeitet) Der Standort an dem das Problem auftritt ist der Hauptstandort, da steht der PDC von dem sich die Clients auch die Zeit holen. Die Tips von Nordblock haben mir bisher noch nix gebracht, habe zwar noch nicht alle durch, aber die die mir am plausibelsten erscheinen schon. Bearbeitet 4. März 2014 von Marius1990 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
da_doni Geschrieben 9. März 2014 Teilen Geschrieben 9. März 2014 Wir haben in unserer 2003er Domäne den Domaincontroller mit einem NTP Server synchronisiert, welcher bei uns auf dem Dach steht und sich per GPS die Uhrzeit holt. Dann wurde eine Gruppenrichtlinie angelegt, welche die Clients anweist über w32time die Uhrzeit vom Domaincontroller zu holen. Das Ganze für ca 3000 Clients (hautsächlich noch XP SP3) - verteilt auf 9 Standorte. Ist dieser DC gleichzeitig der NTP-Server oder sind das 2 verschiedene Server? Wenn sie unterschiedlich sind, musst du auf dem DC (der hoffentlich auch PDC ist - nachzuprüfen auf der Kommandozeile mit dem Befehl "netdom query fsmo") die Eventlogs prüfen, um nachzusehen, ob die Zeitsynchronisierung dort läuft. Wenn auf dem PDC alles OK ist, schaust du mittels "netstat -ano" nach, ob der Server auch den NTP-Port 123 abhört. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.