frankschierle.de
Um Platz auf meinem virtualisierten Domänen-Controller zu sparen, wollte ich die vom WSUS verwalteten Updates auf ein Netzlaufwerk auslagern. Die Einstellungen waren schnell getätigt, die Clients waren jedoch nicht mehr in der Lage, Updates herunterzuladen.
Als Vorbereitung habe ich auf meiner Diskstation zunächst ein neues Netzlaufwerk bereitgestellt. Bei der Installation der WSUS-Serverrolle fragt der Installationsassistent nach dem Verzeichnis, in dem die Updates gespeichert werden sollen. Hier kann der UNC-Pfad des neuen Netzlaufwerks angegeben werden. Der Assistent akzeptiert diesen und fährt mit der Installation fort. Nach dem diese abgeschlossen ist, scheint zunächst auch alles zu funktionieren: WSUS synchronisiert sich mit den Microsoft Upstream Servern, Updates werden heruntergeladen und auf dem Netzlaufwerk abgelegt, die Clients melden sich beim WSUS, suchen nach Updates und finden auch welche.
Als nächstes versuchen die Clients allerdings, die gefundenen Updates herunterzuladen. Und dass wird plötzlich nur noch mit dem kryptischen Fehlercode 0x80244019 quittiert.
Ein Blick in die Windows Update-Protokolldatei zeigte, dass der Download der Updates mittels BITS fehlschlug. BITS gab dabei den nicht weniger kryptsichen Fehlercode 0x80190194 aus. Microsoft stellt hier aber glücklicherweise eine Übersicht aller BITS Fehlercodes inkl. Beschreibung zur Verfügung. Daraus geht hervor, dass BITS beim Versuch, das Update herunterladen, einen HTTP Status 404 vom Server empfangen hat. D.h. die angeforderte Datei wurde auf dem Server nicht gefunden.
Das legte die Vermutung nahe, dass das Problem weniger bei WSUS als bei IIS zu suchen ist, das von WSUS zur Auslieferung der Updates benutzt wird. Dafür wird bei der Installation der WSUS-Serverrolle beim IIS eine eigene Website registriert. Ein Blick in die Konfiguration (mittels IIS Manager) zeigt, dass bei dieser Website ein virtuelles Verzeichnis Content angelegt ist. Mit einem Rechtsklick auf dieses Verzeichnis öffnet sich ein Kontextmenü und über dessen Menüpunkte Manage Virtual Directory > Advanced Settings lässt sich ein Dialog mit weiteren Informationen öffnen. In diesem wurde die Fehlerquelle dann ersichtlich.
Eigenschaften des virtuellen Content-Verzeichnisses: Im Feld „Physical Path“ fehlen die führenden Backslashs.
Entweder der Installationsassistent der WSUS-Serverrolle oder IIS selbst, irgendeiner der beiden war der Meinung, dass die führenden Backslashs im UNC-Pfad des Netzlaufwerks nicht wichtig wären und entfernte sie. In Folge dessen versuchte der IIS die angeforderten Updates aus einem Verzeichnis zu laden, das so natürlich nicht existiert. Resultat: HTTP 404.
Lösung: Die beiden führenden Backslashs hinzufügen, den Dialog mittels OK schließen und schon werden die Updates gefunden und heruntergeladen. In der Theorie zumindest. In der Realität meldeten die Clients jetzt aber einen anderen Fehler: 0x80244017.
Dieser Fehlercode lies sich (wieder über die Windows Update-Protokolldatei und BITS) zu fehlenden Zugriffsrechten zurückverfolgen. IIS suchte die Updates nun zwar im korrekt Verzeichnis, die Diskstation, auf der das Netzlaufwerk liegt, verweigerte ihm jedoch den Zugriff darauf.
Glücklicherweise lassen sich im oben schon angesprochenen Dialog aber Zugangsdaten angeben, die der IIS beim Zugriff auf das Verzeichnis verwenden soll. Hierbei ist zu beachten, dass es sich dabei um einen Benutzeraccount der lokalen Domäne handeln muss. Um das Problem zu lösen, habe ich also einen neuen Domänenbenutzer wsus angelegt und diesem auf der Diskstation Zugriffsrechte auf das Netzlaufwerk gewährt (die Diskstation muss dazu Mitglied der Domäne sein). Anschließend müssen dem IIS im obigen Dialog noch Name und Kennwort des Benutzers mitgeteilt werden (bei einem Klick in das Eingabefeld öffnet sich ein Dialog, der diese Daten abfragt).
Die finale Konfiguration des virtuellen Verzeichnisses.
Nach diesen Anpassungen waren die Clients wieder in der Lage, ihre Updates herunterladen und zu installieren.