Robi-Wan 10 Geschrieben 27. April 2012 Melden Teilen Geschrieben 27. April 2012 Hallo zusammen, ich stehe hier vor einem Problem, das droht, mir das Wochenende zu versauen und hoffe nun auf eine zündende Idee von euch… Folgende Ausgangslage: Unternehmens WSUS -> Replika WSUS -> A-Clients | V B-Clients Die A-Clients, die am Replika WSUS hängen, können seit einer Woche nicht mehr mit dem Replika Server kommunizieren (laut WSUS Management Konsole). Diese A-Clients und der Replicaserver sind im gleichen Subnetz ohne Firewalls dazwischen. Der Replikaserver selbst hat laut der Management Konsole ebenfalls keine Verbindung zu sich selbst. Der Replikaserver synchronisiert erfolgreich mit dem Unternehmensserver. Die B-Clients am UnternehmensWSUS können normal mit diesem kommunizieren. Alle Systeme sind Windows 2003 R2 Standard SP2. Meine bisherigen Lösungsversuche: Namensauflösung des Replikaservers an den A-Clients i.O. Telnet Replikaserver 80 i.O. Networkmonitor zeigt keine Kommunikationen an den A-Clients zum Replikaserver Lokale Firewall ist deaktiviert Das Problem tritt auch auf einem neu installierten System auf. Reset des Windows Update Agents nach How do I reset Windows Update components? Mehrere Reboots aller möglichen Systeme Antivirus Symantec EP deinstalliert Mir gehen allmählich die Ideen aus. Wisst ihr noch eine Möglichkeit? Grüße, Robert Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 27. April 2012 Melden Teilen Geschrieben 27. April 2012 Wie teilst Du den Clients denn mit, wo sie die Updates abholen sollen? Per Gruppenrichtlinie? Welche Daten hast Du denn dort genau hinterlegt? Der WSUS lauscht ja vermutlich auf Port 80. Schau mal im IIS nach, ob es damit einen Konflikt gibt. Gibt es das virtuelle Verzeichnis selfupdate noch? EDIT: Gibt es Einträge im Ereignisprotokoll? Zitieren Link zu diesem Kommentar
Robi-Wan 10 Geschrieben 27. April 2012 Autor Melden Teilen Geschrieben 27. April 2012 Hallo, Danke für Deine Antwort. Wie teilst Du den Clients denn mit, wo sie die Updates abholen sollen? Per Gruppenrichtlinie? Welche Daten hast Du denn dort genau hinterlegt? Per Gruppenrichtlinie. Hier die Details: Configure Automatic Updates: 4, Every Day, 13:00 Uhr Specify intranet Microsoft update service location: http://FQDN.des.Replika.Servers/ Enable Client-Side targeting: Target_Group_der_A_Clients No autostart with logged on users: Enabled Allow automatic updates immediate installation Allow nonadmins to receive notifications: Enabled Do not display "Install Updates & Shut Down": Enabled Do not adjust default option to "Install Updates & Shut Down": Enabled Da es bis vor einer Woche noch funktioniert hat, gehe ich mal davon aus, dass es nicht daran liegt. Des Weiteren sind die Einstellungen analog zu den B-Clients. Der WSUS lauscht ja vermutlich auf Port 80. Schau mal im IIS nach, ob es damit einen Konflikt gibt. Gibt es das virtuelle Verzeichnis selfupdate noch? Auf dem IIS ist sonst nichts anderes. Ein Vergleich mit dem IIS auf dem UnternehmensWSUS ergab keine Unterschiede. Ich kann das iuident.cab ohne Fehler herunterladen. In den IIS Logs sind keine Unterschiede zwischen vor einer Woche und jetzt feststellbar. EDIT: Gibt es Einträge im Ereignisprotokoll? Einträge sind dort zur Genüge :D Zum Beispiel alle paar Stunden, dass WSUS korrekt funktioniert. Nur keine Fehler oder Warnings, die weiterhelfen könnten. Ich vermute, dass die Kommunikation von dem Windows Update Agent irgendwie geblockt wird. Wie könnte ich sowas prüfen? Grüße, Robert Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 27. April 2012 Melden Teilen Geschrieben 27. April 2012 Mit tcpview auf dem Server solltest Du sehen können, welcher Dienst auf 80 lauscht. Bist Du Dir denn sicher, dass die Clients die Gruppenrichtlinie auch übernehmen? Was sagt denn gpresult? Zitieren Link zu diesem Kommentar
Robi-Wan 10 Geschrieben 27. April 2012 Autor Melden Teilen Geschrieben 27. April 2012 Hallo, gpresult und rsop.msc sehen gut aus, alle Werte dazu stehen drin. tcpview kannte ich bisher noch nicht, werde ich ausprobieren und berichten. Grüße, Robert Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 27. April 2012 Melden Teilen Geschrieben 27. April 2012 Und es wurde nix am System verändert? Auch kein Prgramm-Update (z.B. SEP)? Welche Websites gibts denn im IIS? Und welche Ports benutzen sie? Zitieren Link zu diesem Kommentar
Robi-Wan 10 Geschrieben 28. April 2012 Autor Melden Teilen Geschrieben 28. April 2012 Hallo, Und es wurde nix am System verändert? Auch kein Prgramm-Update (z.B. SEP)? Welche Websites gibts denn im IIS? Und welche Ports benutzen sie? Es wurden am Replikaserver keine Änderungen vorgenommen. Es gab SEP Updates, die liegen aber zeitlich etwas weiter weg. Der Replikaserver macht nur WSUS, sonst nix. Es wurde an der Portkonfiguration nichts abgeändert. Wie gesagt, was mich stutzig macht, ist die Tatsache, dass die Clients laut Netzwerk Monitor gar keine Verbindung zum Repikaserver aufbauen. Daher meine Vermutung, dass mit denen etwas nicht stimmen könnte. Wie kann man soetwas testen? Grüße, Robert Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 2. Mai 2012 Melden Teilen Geschrieben 2. Mai 2012 Welche Fehlermeldungen werden in der %windir%\WindowsUpdate.log auf den Clients protokolliert? Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 2. Mai 2012 Melden Teilen Geschrieben 2. Mai 2012 Wie gesagt, was mich stutzig macht, ist die Tatsache, dass die Clients laut Netzwerk Monitor gar keine Verbindung zum Repikaserver aufbauen. Daher meine Vermutung, dass mit denen etwas nicht stimmen könnte. Wie kann man soetwas testen? Ganz einfach: Nimm einen Client aus der WSUS-Gruppenrichtlinie raus, sodass der versucht, sich über's Internet zu aktualisieren. Wenn das klappt, wird's wohl am Server liegen oder die lokale Serveradresse bzw. der Port wird am Client geblockt (doch Firewall?). Wenn das auch nicht klappt, liegt es wohl am Client. Oder gibt es einen Router oder eine Hardwarefirewall zwischen Clients und dem Server? Um die Anfrage der Clients an WSUS zu beschleunigen, kannst Du folgende Befehle verwenden (sofern Du die nicht schon kennst): wuauclt.exe /detectnow wuauclt.exe /reportnow Ganz nützlich ist auch der undokumentierte Parameter "/demoui". Damit kannst Du testen, ob der Update-Dienst grundsätzlich funktionsfähig ist. Kurz nach dessen Ausführung sollte unten rechts in der Taskleiste ein Update-Symbol erscheinen. Zitieren Link zu diesem Kommentar
Robi-Wan 10 Geschrieben 4. Mai 2012 Autor Melden Teilen Geschrieben 4. Mai 2012 Hallo, so, neuer Stand: auf dem Replikaserver habe ich WSUS de- und wiederinstalliert, jetzt läuft die Sache wieder. Vielen Dank an iDiddi für Deine Unterstützung! Grüße, Robert Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 4. Mai 2012 Melden Teilen Geschrieben 4. Mai 2012 Freut mich für Dich. Danke für Deine Rückmeldung :) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.