WSUS 3.0: „Selbstupdate funktioniert nicht“ in der Ereignisanzeige unter Windows Server 2008 / IIS7

Vor kurzem installierte ich meinen Server neu nachdem ich meine SQL Server Konfiguration dermaßen zerschossen hatte dass sich keine Version mehr richtig installieren aber auch keine mehr richtig deinstallieren ließ.

Schuld war ich natürlich selbst weil ich mir eingebildet hatte von SQL Server 2008 auf SQL Server 2008 R2 updaten zu müssen obwohl keine Not bestand.

Nun aber zum eigentlichen Problem um das es hier gehen soll. Ich finde es so erwähnenswert da zwar viel darüber im Internet zu finden ist, ein Fall wie meiner war in meiner halbtägigen Recherche gestern aber keiner dabei.

Es ist mir letztendlich tatsächlich gelungen das Problem zu lösen, aber ich will am Anfang beginnen:

Das Problem

Der Stein des Anstoßes war im Windows-Anwendungsprotokoll der Ereignisanzeige zu finden. Dort prangte – mehrfach – der Fehler mit der ID 1111 und der Beschreibung „Selbstupdate funktioniert nicht“.

Was macht Selfupdate eigentlich auf dem WSUS?

Selfupdate ist auf dem WSUS ein virtuelles Verzeichnis auf der Standard-IIS-Site auf Port 80 in dem der jeweils aktuelle Windows Update Client für alle WSUS-Clients verfügbar ist. Benötigt ein Windows-PC der sich vom WSUS Updates holen will eine aktuellere Version der Windows Update Software dann bekommt er sie aus dem Verzeichnis /Selfupdate auf dem WSUS und zwar immer auf Port 80.

Die Suche nach der Nadel im Heuhaufen

Nun habe ich gemacht was ich immer mache wenn ich ein Problem habe mit dem ich nichts oder wenig anfangen kann: Google bemüht.

Ich bin dabei auch auf äußerst zahlreiche Lösungsvorschläge gestoßen die sicherlich meistens ins schwarze treffen was die vielen Forenbeiträge auf die ich dabei gestoßen bin letztendlich auch dokumentiert haben, leider nichts für mich passendes. Hier mal ein kleiner Auszug was im groben dabei war:

  • Existiert das virtuelle Verzeichnis /Selfupdate auf Port 80 auf dem WSUS
  • Sind die Berechtigungen im Verzeichnis /Selfupdate (auch im Dateisystem des Servers, der Ordner befindet sich im Installationsverzeichnis von WSUS) korrekt eingestellt?
  • „SSL benötigt“ ist auf dem virtuellen Verzeichnis „/Selfupdate“ deaktiviert?
  • Die IP-Bindung vom IIS ist korrekt
  • Port und SSL-Status sind in der Registry korrekt eingetragen
  • Namen werden im Netzwerk richtig aufgelöst?

Ich gehe jetzt bewusst nicht auf jede einzelne Problemlösung ein, da findet sich bei Google mehr als genug brauchbares und an dieser Stelle möchte ich auch an WSUS.DE verweisen, wo jeder mit beliebigen WSUS-Problemen kompetente Hilfe finden dürfte.

Mir war nach etlichem herumprobieren klar geworden dass ich per Browser von einem Client aus absolut Problemlos auf den Inhalt von „/Selfupdate“ auf dem Server zugreifen konnte, nach etwas längerem Experimentieren fiel mir dabei aber eins auf: Vom Server selbst aus ging es nicht.

Versionskonflikte

Es ging über die IP aber nicht über „server“ und auch nicht über „localhost“. Nslookup bescheinigte mir eine korrekte IPv4 Namensauflösung, mein Ping an „server“ ging an die IPv6 Adresse (IPv6 ist seit Windows Server 2008 obligatorisch) und kam auch an.

Halt! IPv6? Genau! Der IIS war nur dummerweise darüber eben nicht erreichbar, da es hier bei mir eine kleine aber entscheidende Besonderheit gibt:

Mein Server hat 2 Netzwerkkarten (1 GBit/s PCI + 100 Mit/s onboard) und dementsprechend 2 IPs im LAN (192.168.1.2, 192.168.1.3).
Per DNS wird nur die „192.168.1.2“ im LAN mit „Server“ aufgelöst, die „192.168.1.3“ mit meinem auch extern erreichbaren DynDNS-Namen (<Beispiel>.homelinux.net).
Sinn der Sache ist, dass im Prinzip alles über die 192.168.1.2 laufen soll, die per Portforwarding auch von außen erreichbare IIS-Instanz sich von intern genauso verhält wie von extern (eben dass sie über Port 80 und den DynDNS-Namen erreichbar ist wie von außen auch).

Der Hase im Pfeffer

Genau hier liegt das Problem: Ein häufig gegebener (und logischerweise funktionierender) Tip ist, darauf zu achten dass eine Bindung vom Webserver auf Port 80 auf *, also sämtliche IPs des Servers vorhanden ist. Das ist idr. auch kein Problem weil auf den wenigsten Servern die WSUS ausführen eine zweite IP vorhanden sein dürfte auf der auf Port 80 ein zweiter Webserver (oder anderer Dienst) läuft.

Die Lösung bestand letztendlich darin der Standard-IIS-Instanz mit dem Selfupdate-Verzeichnis auch eine Bindung zur IPv6 Adresse zu verpassen.

Die Alternative wäre wohl IPv6 zu deaktivieren, allerdings soll es dabei unter einigen Umständen zu Problemen kommen (insbesonderes bei Exchange, was ich allerdings nicht einsetze). Noch habe ich mich zu diesem drastischen Schritt nicht durchringen können.
Natürlich stelle ich mir die Frage was nun ist wenn ich einen Dienst habe der gar nicht IPv6 fähig ist und vom Server selbst aus über den Hostnamen erreichbar sein soll? Vermutlich ist er dann eben nicht erreichbar und ich muss IPv6 doch abschalten.

Ich lasse das jetzt an dieser Stelle so stehen, mein Fehler in der Ereignisanzeige ist weg und ich bin für’s erste zufrieden.

Letztendlich bestätigt mir das aber meine Einstellung pro Server nur so wenig Dienste wie möglich laufen zu lassen damit sich nichts gegenseitig in die Quere kommen kann. Ohne die zweite IIS-Instanz auf der zweiten IP-Adresse wäre das Problem so nicht aufgetreten da die Bindung der Standardwebseite – wie standardmäßig vorgegeben – schlicht auf allen IPs bestanden hätte.

Es geht auch anders

Nachdem ich mich insbesondere unter http://www.msxfaq.de/konzepte/ipv6.htm noch ein wenig über IPv6 unter Windows Server 2008 / Vista aufwärts belesen habe ist mir noch ein alternativer Lösungsvorschlag eingefallen, ohne IPv6 auf die Holzhammermethode komplett deaktivieren zu müssen:

Setzt man den Registrywert unter

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:0xffffffff

auf den Wert 0x20 wird IPv4 bevorzugt vor IPv6 verwendet.
IPv6 bleibt dann aktiv, kommt einem sofern nicht explizit verwendet jedoch nicht in die Quere.

HP ProCurve V1810G-24

Zu Weihnachten gab’s einen neuen Switch – den HP V1810G-24.

Dabei handelt es sich um ein sog. „Smart Managed“ Modell das ausschließlich über ein Webinterface verwaltet werden kann und Features wie Trunking, QoS und VLANs bietet.

Der Switch hat 24x 10/100/1000 Base-T Ports sowie 2 Mini-GBIC Slots bei deren Verwendung allerdings jeweils ein Kupferport (23 und 24) deaktiviert wird.

Der V1810G-24 ersetzt jetzt den HP ProCurve 2524 der bisher vorn im Rack montiert war und alle Geräte die ohnehin nur 100 MBit/s schaffen versorgt hat und zugleich den HP ProCurve 1800-8G der bisher hinten im Rack auf dem Einlageboden stand und alle Gigabit-fähigen Geräte versorgt hat.

Der 1800-8G ist dafür in mein Zimmer unter den Schreibtisch gewandert wodurch ich mir ein LAN Kabel in den „Serverraum“ spare.

So sieht’s jetzt aus:

HP V1810G-24 vorn im Rack

So sah’s vorher aus:

HP 2524 vorn im Rack

HP 1800-8G hinten im Rack