Dark_Kain Geschrieben 7. April 2009 Teilen Geschrieben 7. April 2009 Hallo liebe Benutzer, ich habe ein Update des WSUS vorgenommen. Vorherige Version war eine 2.0 und es hat ein Update auf 3.0 stattgefunden. Durch das Update wurde eine MMC installiert, das den WSUS verwaltet. Was jedoch beim 2.0 eine Weboberflaeche war.. meine Frage hierzu: Wie bringe ich den Clients bei die Updates erneut an zu fodern bzw. Berichte zu erstellen. Zur Zeit ist alles stehen geblieben und kein einziger Client meldet sich. Die Konfiguration laeuft ueber die Gruppenrichtlinien. Ich hoffe mir kann Jmd helfen.. Danke!! Bei weiteren Fragen, einfach drauf los Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
keil Geschrieben 7. April 2009 Teilen Geschrieben 7. April 2009 Hi, schau Dir mal "wuauclt.exe" an. Muss vom Client aufgerufen werden, dort gibt es u.a. die Option "/reportnow" und "/detectnow". Allerdings wird dies auch nicht sofort gemacht. Hilft das? Gruß Marcel Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 7. April 2009 Autor Teilen Geschrieben 7. April 2009 Das ist richtig, aber bei mir ist immer noch die alte Adresse vom 2.0er eingetragen. Sprich unter der Gruppenrichtline die Adresse zur Weboberflaeche (z.B. http://w-updates.de o.ae.) Muss ich diese jetzt aendern und die IP-Adresse des Server eintragen, da es keine Weboberflaeche ist, sondern ein SnapIn? Die oben genannten Moeglichkeiten habe ich bereits getestet. Jedoch bringt es keinen Erfolg.. Muss der Gruppenrichtlinie nicht klar sein was zu machen ist? Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
keil Geschrieben 7. April 2009 Teilen Geschrieben 7. April 2009 Du trägst es ganz normal ein, auch mit http://name. Hast du mal an einem anderen Rechner probiert, der nicht in der Domäne ist, über den neuen WSUS Updates zu beziehen? Bei der Gruppenrichtlinie kann ich Dir nicht wirklich helfen, da kenne ich mich noch nicht so aus. Mal mit einem gpupdate probiert? LG Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 7. April 2009 Teilen Geschrieben 7. April 2009 Hallo, in der Gruppenrichtlinie schreibst nach wie vor den DNS Namen oder die IP Adresse des WSUS. Eventuell noch den Port. Bei 3.0 ist jetz ja per Default 8350 wenn ich mich richtig erinnere. Warum sollen sich denn jetzt alle Rechner beim WSUS melden und Updates ziehen? Vor allem welche Updates? Die Rechner melden sich periodisch in der Regel alle 24 Stunden und prüfen auf neue Updates. Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 9. April 2009 Autor Teilen Geschrieben 9. April 2009 Hallo, entschuldigt meine verspaetete Antwort, aber ich kam nicht dazu das WSUS weiter zu verfolgen. Die Einstellungen in den gruppenrichtlinien habe ich vorgenommen. Die ehemalige Interne Seite wurde mit der IP-Nr des Rechner + Port ersetzt. Jedoch passiert wieder nichts.. :confused: Woran koennte das noch liegen? Das Problem gab es bei dem WSUS 2.0 nicht, aber seitdem das SnapIn da ist, ist einiges durch den Wolf gedreht worden. Gibt es weitere Ansaetze, die ich verfolgen kann? Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 9. April 2009 Teilen Geschrieben 9. April 2009 Ich glaube Du hängst dich an ein paar Worten auf. Das Snapin hat nichts mit der Patchanforderung durch die Clients zu tun. Im Snapin gibst Du die Patche frei und das wars (Bei 2.0 über den Browser). Die Clients holen sich weiterhin über den IIS die Patchinformationen. Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 9. April 2009 Autor Teilen Geschrieben 9. April 2009 Okay, ist mir auch klar gewesen das das SnapIn die Verwaltung der Updates erledigen soll. Jedoch wurde an der Machine nichts anderes um- bzw. eingestellt als das das WSUS 2.0 auf 3.0 erweitert worden ist. Keine Eintraege in den Gruppenrichtlinien oder jegliche anderen Moeglichkeiten. Seit dem Tag an melden sich die Clients nicht mehr beim WSUS. .. Wo ist der Fehler, wenn an der Konfiguration nichts geaendert worden ist? Deshalb wollte ich auch gerne wissen, ob das Update iwas zerschossen hat. Im INet z.B. die Weltberuehmte Gruppenrichtlinien-Seite weist auch auf nichts weiteres hin.. zumindestens hab ich nach 3x durchlesen nichts brauchbares finden koennen. Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 9. April 2009 Teilen Geschrieben 9. April 2009 Was sagt denn windowsupdate.log auf den Clients? Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 (bearbeitet) Hier mal der Ausschnitt des heutigen Tages, was die Log-Datei auf dem Client erzaehlt: http://home.arcor.de/united-dk/WSUSLOG.txt Desweiteren moechte ich erwaehnen das ich die Gruppenrichtlinien geaendert habe. Sprich die fruehere Adresse zur WebOberflaeche (z.B. http://WSUS-abc.de) in die IP-Adresse des Verteilers geaendert (z.B. http://172.16.14.1 [Anmerkung: Muss/Kann die Portnr. dahinter?!) Wenn die Portnr. dahinter muss, so sollte ich eine klare Portnr. haben. Die obige entspricht einem anderem Ergebnis aus Google. Kann es vllt. moeglich sein das du die 3 mit der 5 verwechselt hast? Gruß, DK~ Bearbeitet 15. April 2009 von Dark_Kain Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
ChHawk Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Nein, du gibst effektiv nur den DNS/Computernamen von deinem WSUS Server ein. Wieso rufst du den Bericht nicht auf deinem WSUS Server auf? Client auswählen, Bericht erstellen und anschauen? Der Nachteil beim neuen WSUS ist halt das dieser keine Weboberfläche mitliefert. Mir gefällt diese Variante aber persönlich besser =) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Auf welchem Port läuft denn dein WSUS? Bei mir steht z. B. sowas im Logfile. http://dns_name:8530/SimpleAuthWebService/SimpleAuth.asmx Irgendwie sieht das so aus als wenn deine Clients den WSUS nicht finden. Was sagt denn das Client Diagnostic Tool? http://download.microsoft.com/download/9/7/6/976d1084-d2fd-45a1-8c27-a467c768d8ef/WSUS%20Client%20Diagnostic%20Tool.EXE Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 (bearbeitet) Ich werde es jetzt sofort mit dem DNS Namen ausprobieren. Woher weiß ich auf welchen Port der WSUS lauschen tut? Es wurden keine Aenderungen diesbzgl. vorgenommen. Gibt es eine Moeglichkeit den Port heraus zu finden? Wenn ja, wie mache ich das? Das Tool zum Ueberpruefen auf den Clients werde ich anwerfen, wenn die Portnr. meines WSUS's korrekt eingetragen bzw. herausgefunden worden ist. Ansonsten bringt es denke ich relativ wenig.. @ ChHawk Davor war der DNS name eingetragen. Lediglich der Port nicht, aber da wollte ging es mit dem Melden der CLients auch nicht.. warum?! Gruß, DK~ Bearbeitet 15. April 2009 von Dark_Kain Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Woher weiß ich auf welchen Port der WSUS lauschen tut? WSUS Konsole - auf den Server klicken und rechts steht dann sowas wie Connection Port: 8530 User role: Administrator usw. Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Das ist wunderbar! Der Port ist auf "80" festgelegt. Stoert die Einstellung nicht den normalen HTTP Port? Ich habe die Einstellungen vorerst Manuell in der Reg. vorgenommen und den Port eingetragen. Jedoch kam folgendes bei raus: Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
cyberax Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Ich hatte mal, das Problem, dass der WSUS die Namens auflösung nicht richtig hinbekommt. Besonders wenn man mit unterschiedlichen Suffixen arbeitet. Daher habe ich die IP-Addresse des WSUS eingetragen und nicht den Namen. Dann lief alles bestens. Eventuell hilft auch ein Reset des Updates Dienstes. Dazu gibt es das Tool "bitsadmin.exe" Downloaddetails: Windows XP SP2 Supporttools für fortgeschrittene Benutzer einfach mit den Optionen - bitsadmin.exe /RESET /ALLUSERS einmal ausführen. Du solltest davor allerdings den Dienst - wuauserv beenden und nach der Aktionen neustarten und dann mit wuauclt /detectnow eine sofortige Rückmeldung auslösen. Fals die Regwerte lieber sind, steht das unter HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update "NextDetectionTime" "ScheduledInstallDate" "LastSuccessTime" "LastError" nicht vergessen, den Dienst davor zu stoppen...regwerte auf einen Wert in der Vergangeheit ändern...dienst starten...fertig und dann die Log-Files analysieren WindowsUpdat.log im Windows-Verzeichnig und die ReportingEvents.log im SoftwareDistribution-Ordner Gruß Cyberax Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Danke fuer deine Informationen! Ich habe die Support Tools auf dem Client installiert (wenn ich richtig gedeutet habe). Desweiteren habe ich den Befehl ausgefuehrt und dort kam eine Ausgabe in der folgendes Stand (nicht 1 zu 1): 0 Jobs gefunden - 0 Jobs beendet (o.ae. in der Art) Zumindestens konnte man dort deutlich raus entnehmen, dass keine Aktion durchlaufen worden ist. Der Dienst "wuauserv" ist bei mir ueberhaupt nicht vertreten. Woran kann das liegen? Demnach hat es auch nicht mit "wuauclt.exe /detectnow" funktioniert. Wenn vorher nichts geht, geht nacher definitiv garnichts.. :confused: PS: Das Problem aergert mich wirklich sehr. Notfalls werde ich die alte virt. Maschine mit WSUS 2.0 zum leben erwecken. Da hat alles zu 100% funktioniert.. werde mich aber diesbzgl. nochmal melden und was dazu sagen. Somit haette man einen anderen Ansatz um dem Problem entgegen zu tretten, wenn ich es Updaten sollte auf 3.0. Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
cyberax Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Der Dienst "wuauserv"...exisitert vermutlich als "Automatische Updates" in der Diensteliste ? (aufrufen mit services.msc) Dieser sollte auf automatisch stehen und laufen...sonst hast du ein Problem. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Das ist richtig. Der Dienst laeuft unter dem Namen und war auch gestartet sowie automatisch gesetzt. Dienst beendet -> bitsadmin.exe /... ausgefuehrt -> Dienst gestartet -> wuauclt.exe /... ausgefuehrt -> .. nichts aendert sich .. Es kann doch nicht wahr sein das das Update von 2.0 auf 3.0 sovieles veraendert. Wie zuvor schon erwaehnt werde ich mir jetzt eine Kopie des WSUS 2.0 (virt. Maschine) erstellen und das austesten. Wenn dort das Melden funktionieren sollte, so weiß ich auch nicht mehr weiter. >> ein hoffnungsloser Fall?! :eek Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
cyberax Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Klares nein... ich habe das selbst auch schon gemacht. Die Einstellung sind nur auf dem Server und ob man nun den WSUS per MMC oder WEB-Interface nutzt hat rein gar nix mit den Clients zu tun. Könntest du mal die ReportingEvents.log posten und die Windowsupdat.log in aktueller Version ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
cyberax Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 zusatz.... eventuell auch noch die Einstellungen in den Gruppenrichtlinien, vielleicht hast du dort was übersehen ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Werde ich in ca. 1 Stde melden, da ich jetzt erst einmal Mittag esse Der Beitrag wird hierfuer editiert und dir schreibe ich persoenlich noch eine PN. *EDIT* Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Beitraege editieren nicht moeglich?! Das hab ich ja nun wirklich noch nie erlebt Hier sind die beiden Logs, die du gewuenscht hast: http://home.arcor.de/united-dk/RepEv.txt http://home.arcor.de/united-dk/WinUp.txt Wenn iwas unklar ist kann ich auch gerne den Rest des Logs herausgeben. Gruß, DK~ Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
cyberax Geschrieben 15. April 2009 Teilen Geschrieben 15. April 2009 Das ist ein Rechteproblem vom Client aus, der kann sich nicht am Server melden. Bitte kontrollieren: Auf dem Server gibt es ein Verzeichnis: - UpdateServicesPackages und - WsusContent auf beide hat JEDER lesenden Zugriff in der Webfreigabe und im NFTS der Netzwerkdienst mit VOLLZUGRIFF auf den Ordner - WsusContent und Lese / Schreibzugriff auf den Ordner - UpdateServicesPackages Dann in den Lokalensicherheitsrichtlinien brauchen die User -IUSR_* und der - IWAN_* das Recht: "Auf diesem Computer vom Netzwerk aus zugreifen" Den IIS so konfigurieren, dass der Anonyme Zugriff aktiviert ist und der IUSR_* drin steht incl. dem Hacken der Integrierten Windows Authentifizierung. Nen Proxy haben deine Clients nicht oder ? Eventlog des Server mal prüfen.. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Dark_Kain Geschrieben 15. April 2009 Autor Teilen Geschrieben 15. April 2009 Also die obigen Ordner habe ich geprüft und Rechte vergeben. Jedoch stehe ich bei den lokalen Sicherheitsrichtlinien auf dem Schlauch.. Wo sollen die beiden Einstellungen zu finden sein? Ein Proxy haben die Clients meines wissens nicht eingestellt jedoch will ich es nicht beschwoeren. Mit Eventlog meinst du die ReportingEvent.log Datei auf dem Server? Wenn ja, dann steht doch auch nichts weiteres wie auf dem Client. "Windows Update Client failed to detect with error 0x80244017." Gruß, DK~ 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.