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.

4x WD RE4 2 TB eingetroffen – mit gemischten Gefühlen

Heute sind meine 4 bei Mindfactory.de bestellten WD RE4 mit 2 TB bei mir eingetroffen.

Also gleich ausgepackt und den Garantiestatus bei WD auf der Homepage überprüft.
Soweit kein Problem, alle Platten haben volle 5 Jahre Herstellergarantie. Nur bei einem Exemplar fiel mir auf, dass die Festplatte als „Recertified“ gekennzeichnet ist.

Das heißt die Festplatte war evtl. schon in fremden Händen und wurde (defekt) an WD zurück geschickt, ist aber eigentlich kein Problem, da entsprechende Ware bei WD auch erst nach entsprechender Qualitätskontrolle wieder das Haus verlässt.

Was mir nicht so gut gefiel war, dass die Festplatten unterschiedliche Firmware-Versionen aufwiesen.

3 der Festplatte wurden vom RAID Controller als WDC WD2003FYYS-02W0B0 mit der Firmwareversion 01.01D01 erkannt, eine als WDC WD2003FYYS-01T8B0 mit der Firmware 01.00D02.

Da ich erst vor ca. einem Jahr Probleme bei 2 WD Raptor 74 GB im RAID 1 hatte, von denen eine beim booten vom Controller regelmäßig nicht erkannt wurde was ein „degraded“ für den RAID-Verbund zur Folge hatte das dann jedes Mal rebuilded werden musste habe ich bei WD direkt eine Supportanfrage gestellt in der ich um eine Empfehlung über den Umgang mit den unterschiedlichen Firmware-Versionen bitte.

Den größten Missgefallen jedoch rief eine der Platten hervor, die bei der Initialisierung des RAID 5 aus allen 4 Platten aus dem RAID geflogen ist und vom Controller anschließend nicht mehr erkannt wurde.

Diese Festplatte wird auch an anderen Ports des Controllers und in meiner Zockkiste am SATA Port des ICH10R des Asus P5Q PRO nicht erkannt, weshalb ich sie in jedem Fall umtauschen lassen werde.

Das erinnert mich jetzt doch leider ein wenig an mein Debakel mit 6 Hitachi Deskstar mit 2 TB (7k2000), von denen 2 Stück innerhalb der ersten Woche massive Probleme bereiteten (defekte Sektoren und mehrfache Controller-Resets), aber irgendwann muss Schluss sein. Aufgrund meiner bisher in erster Linie sehr guten Erfahrungen mit WD – besonders was die Langzeitzuverlässigkeit betrifft – werde ich die RE4 wohl behalten.

Jetzt bin ich auf die Antwort des WD Supports gespannt.
Mein RAID 5 baue ich jetzt zuerst einmal mit 3 Festplatten um zu sehen ob während der Initiailisierung Probleme auftreten.

Schluss mit den Platzproblemen – 4x WD RE4 2 TB bestellt

Nachdem es auf meinem Fileserver (RAID 5 aus 6x 750 GB = 3,4 TB) jetzt doch langsam etwas eng wird habe ich mir jetzt 4x die WD RE4 mit 2 TB bestellt.

Verschickt hat sie der Händler schon, ankommen müssen sie erst noch.
Dann wird erstmal der Garantiestatus gecheckt und anschließend eingebaut & ein RAID 5 über alle 4 Platten erstellt was dann letztendlich ein Array von ca. 5,4 TB ergibt.

Jetzt ergibt sich natürlich die Frage, was mit dem alten Array passiert.
Eigentlich könnte ich es komplett auflösen und hätte dann 7 Platten übrig (incl Hotspare).
Gleichzeitig bestünde aber auch die Möglichkeit meinen Datenbestand nach Zweck, Umfang und Wachstumsrate auf 2 oder gar 3 Arrays zu verteilen.

Aktueller Stand:

RAID 1, 2x WD Raptor 74 GB:
C: (System, ca. 20 GB), D: (Daten 1, ca. 50 GB)

RAID 5, 6x WD RE2/3 750 GB:
E: (Daten 2, 3,4 TB)

Option 1:

RAID 1, 2x WD Raptor 74 GB:
C: (System, ca. 20 GB), D: (Daten 1, ca. 50 GB)

RAID 5, 4x WD RE4 2 TB:
E: (Daten 2, 5,4 TB)

Option 2:

RAID 1, 2x WD Raptor 74 GB:
C: (System, ca. 20 GB), D: (Daten 1, ca. 50 GB)

RAID 5, 4x WD RE2 750 GB:
E: (Daten 2, 2,04 TB)

RAID 5 4x WD RE4 2 TB:
F: (Daten 3, 5,4 TB)

Option 3:
RAID 1, 2x WD Raptor 74 GB:
C: (System, ca. 70 GB)

RAID 1, 2x WD RE2 750 GB:
D: (Daten 1, ca. 700 GB)

RAID 5, 4x WD RE2/3 750 GB:
E: (Daten 2, 2,04 TB)

RAID 5 4x WD RE4 2 TB:
F: (Daten 3, 5,4 TB)

Jede der Optionen hat natürlich ihre Vor- und Nachteile.
Betrachtet man Energie- und Kühlungsbedarf ist eine Lösung mit möglichst wenigen Platten natürlich immer vorzuziehen, was für Option 1 spricht.

Eine flexible Datenorganisation spricht auch eher für wenige große Volumes als mehrere kleinere, die Performance eher für eine möglichst großflächige Verteilung der Daten auf mehrere unabhängige RAID Arrays.

Mal sehen welche Lösung das Rennen macht, ich denke ein klares richtig oder falsch gibt es in diesem Fall nicht.