rantanplan

Unser WSUS-Server ist nach der Installation vom Service-Pack 1 abgschmiert und seither auch nach einer Neuinstallition nicht mehr richtig funktionstüchtig. Im Ereignislog findet sich die relativ bekannte Fehlermeldung: Ereignistyp: Fehler Ereignisquelle: Windows Server Update Services Ereigniskategorie: Dienst "Update Services" Ereigniskennung: 421 Datum: 14.06.2006 Zeit: 11:17:53 Benutzer: Nicht zutreffend Computer: WUS Beschreibung: Die Verbindungsherstellung mit der Datenbank ist fehlgeschlagen. Ursache=Cannot open database requested in login 'SUSDB'. Login fails. Login failed for user 'NT-AUTORITÄT\NETZWERKDIENST'.. Verbindungszeichenfolge: Data Source=WUS\WSUS;Initial Catalog=SUSDB;Connection Timeout=60;Application Name=WSUS SQL Connection;Trusted_Connection=Yes;Pooling='true'; Max Pool Size = 100 Im WindowsUpdate.log der Clients erscheint folgende Fehlermeldung: 2006-06-14 12:24:11 1144 118 Misc WARNING: Send failed with hr = 80072efd. 2006-06-14 12:24:11 1144 118 Misc WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <> 2006-06-14 12:24:11 1144 118 PT + Last proxy send request failed with hr = 0x80072EFD, HTTP status code = 0 2006-06-14 12:24:11 1144 118 PT + Caller provided credentials = No 2006-06-14 12:24:11 1144 118 PT + Impersonate flags = 0 2006-06-14 12:24:11 1144 118 PT + Possible authorization schemes used = 2006-06-14 12:24:11 1144 118 PT WARNING: GetAuthorizationCookie failure, error = 0x80072EFD, soap client error = 5, soap error code = 0, HTTP status code = 200 2006-06-14 12:24:11 1144 118 Report WARNING: Reporter failed to upload events with hr = 80072efd. Alle Lösungsansätze die ich bisher gefunden und probiert habe (Update Services als lokalen Dienst eintragen, den DTC-Netzwerkzugriff ohne Autorisierung zulassen) Der Fehler tritt nicht permanent auf, manchmal springt die Datenbank auch an (selbst nach einem Error 421). Er ist also nicht recht reproduzierbar. Ich hab den WSUS neu aufgesetzt (Datenbank, Betriebssystem W2k3 und IIS 6 beibehalten), was aber nicht viel geholfen hat. Ich glaube fast, dass es ein Problem des IIS im Zusammenspiel mit der Datenbank ist. Hat jemand ähnliche Probleme gehabt und sie in den Griff bekommen?

So, jetzt hab ich zumindest ansatzweise ne Lösung: Ich hab den Registry-Schlüssel (bzw. den ganzen Ordner) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv gelöscht, neu gebooted dann den die Datei %SystemRoot%\inf\au.inf per rechttsklick => installieren ausgeführt und siehe da, der Automatische Updates Service installierte sich neu und ließ sich auch unter Dienste starten. Falls der Autostarttyp auf Automatisch gesetzt ist, sollte er beim nächsten Neustart auch selbstständig starten - hat er jedenfalls bei mir getan. :) Das einzige Problem, das ich jetzt noch sehe, ist diesen Ablauf so weit wie möglich zu automatisieren, bzw Benutzerfreundlich zu gestalten. Ich hab keine Lust den Mist an zig Workstations zu betreiben. Und erst recht nicht, den Leuten Admin-Rechte zu verleihen, damit sie es selber machen ... Hat jemand ne Idee? Gruß R.

Ne, der Dienst meldet sich als LOkales System an und sollte somit über alle notwendigen Rechte verfügen. Ich hab jetzt noch mal ein zweites Testsystem aufgesetzt und der Fehler war wieder derselbe: Der Dienst AUtomatsiche Updates steht zwar auf Automatisch starten, läuft aber nicht. Wenn man ihn anschieben will, kommt kurz nach dem Start die Meldung, dass der Dienst wieder angehalten wurde. Mit dem Verweis das einige Dienste angehalten werden, wenn sie sich im Leerlauf befinden (was die Fehlersuche viel einfacher macht). Ich hab auch mal den den neuen Update Client auf ein XPSP1-System aufgespielt. Das funktiert leider. Der Dienst legt allerdings wie auch beim SP2 ein zweites Windows Update.LOg an (mit Leerzeichen). Das scheint allerding in erster Linie eine Art Debug-Log zu sein. Na ja, ich schau mal weiter... Gruß R.

Hi, danke für die Antworten. Sorry, dass ich jetzt erst antworte. War letzte Woche unterwegs. :| Der Kollege, der sich mit dem SP2-Problem in der Zeit rumgeschlagen hat, ist auch nicht viel schlauer geworden. Hoffe, ich hab Morgen mal Zeit das BITS-Update zu testen. Danke für den Tipp mit der Registry. Ich denke wir werden hier aber trotzdem noch mit dem systematischen SP2-Update warten. Die Nummer ist einfach noch zu buggy. @Jolly: Warst du vielleicht mal ein recht begabter RTCW-Medic?Falls du die Frage nicht verstehst, vergiss sie einfach. :-) Gruß R.

Hi erstma, bin zwar schon ne Weile registriert, hatte aber in letzter Zeit irgendwie keine Luft zum Posten. Ich teste gerade das XP SP2. Die meisten Progs liefen auf meinem Testsystem auch relativ problemfrei. Tiny, ZA, Norton FW, Antivir, Xwin, Fsecure, Teraterm, Putty, Pegasus machten zumindest in den Standartfunktionen einen soliden Eindruck. Einzig eine Software für Videokonferenzen war ein Totalausfall. Beim Versuch den Testclient mit einem SUS-Server upzudaten ging dann gar nix mehr. Im WindowsUPdate.log steht der Fehlercode 0x80004015, den eigentlich nur bei W2K-Maschinen mit DCOM-Probs geben sollte. :D Auch ein Update über die Microsoft-Seite funktioniert nicht. Pfiffig wie ich bin, hab ich vermutet, dass es am Automatischen Update Client liegt. Aber ich hab keine aktuellere Version als wuau22 gefunden -also Fehlanzeige. Als nächstes hab ich die lokalen Richtlinien (gpedit.msc) editiert und festgestellt das da noch einiges an Konfigurationsmöglichkeiten unter dem Punkt Windows-Updates hinzugekommen ist. Aber auch nachdem ich die entsprechenden Karteireiter geändert hab, trat keine Besserung ein. Lange Rede kurzer Sinn: * Hat einer von euch ähnliche Erfahrungen mit Updates bei SP2 gemacht oder weiß vielleicht sogar ne Lösung? * Kann jemand meine Test-Ergebnisse bestätigen oder habt ihr andere Erfahrungen gemacht? Ich sag schon mal danke im Voraus.