WSUS Update Content auf Netzwerkfreigabe speichern
Da mein letzter Beitrag eine Weile her ist und es sowieso mal wieder Zeit für einen kleinen Artikel aus der Microsoft Welt wird, im Folgenden ein kurzer Beitrag zum Thema WSUS und die Speicherung der Update-Daten. Ich werde in diesem kurzen Beitrag nicht genauer auf die Installation oder Bereitstellung eines WSUS-Servers eingehen.
Wie auch seine Vorgänger hat auch der Windows Server 2016 weiterhin die bekannte und oft verwendete Serverrolle „Windows Update Dienst“ an Bord. Ein WSUS-Server ist einfach einzurichten und kann gerade in größeren IT-Umgebungen Bandbreite und Verwaltungszeit einsparen. Doch ein kleines Leiden bringt der Server leider mit sich. Wohin mit all den Updatedaten? Die Updatebestände werden dateibasiert in einer WSUS-eigenen Ordnerstruktur organisiert (WSUS Content). Die Größe der Struktur richtet sich nach der Anzahl der eingesetzten Betriebssystemversionen sowie Microsoft Software-Installationen wie etwa Office, Exchange oder gar die nativen Server-Rollen/Features. Die ausgewählten Updatetypen, also Updates, Upgrades oder Sicherheitspatches spielen ebenfalls eine tragende Rolle bei der Auslastung des Speicherplatz.
Eine Möglichkeit um die Updatedateien möglichst schlank zu halten, ist also ein kleineres Portfolio an Betriebssystem-Versionen und Microsoft Produkten vorzuhalten. Die Datenbereinigung kann außerdem dabei helfen, dem Speicherhunger des WSUS-Server Einhalt zu gebieten. Doch das alles hilft leider nur geringfügig gegen die vielen hunderte Megabytes die monatlich hinzukommen. Vorzugsweise wird vermieden, die Daten gar im teuren Produktivspeicher abzulegen, da schnell ein Datenvolumen von 500-700Gbyte erreicht ist.
Daher möchte ich heute eine Möglichkeit vorstellen, den Schmerz des Speicherplatzverlustes etwas zu mildern. Ganz nebenbei wird mit dieser Methode auch erreicht die Updatedaten aus der täglichen Datensicherung fernzuhalten (Egal ob SnapShot-Technik oder agentenbasierte Datenkopien). Sprechen wir über einen virtuell betriebenen WSUS-Server, so wäre auch das Verschieben etwa in ein neues Datestore/CSV so viel schneller zu realisieren, da lediglich das System und nicht die gesamten Updatedaten bewegt werden müssen.
Es geht also darum die Update-Dateien (WSUS Content) nicht wie gewohnt in einem Servereigenen Datenträger abzulegen, sondern in einer externen Netzwerkfreigabe zu speichern. In meinem Beispiel ist es eine Freigabe auf einem sekundären NetApp-System, dass genau für solche Zwecke herhalten darf, ohne teure wie leistungsstarke SSD oder SAS-Festplatten in Beschlag zu nehmen.
Vorab möchte ich sagen, dass unbedingt nur das Mindestmaß an Berechtigungen auf die vorgesehene Freigabe angewendet wird, da sonst die Gefahr einer Manipulation der Update-Dateien besteht. Auch wenn jedes durch Microsoft veröffentlichte Update signiert wurde. Die benötigten Berechtigungen bestehen aus:
- Computerkonto des WSUS-Servers
- Spezifisches Dienstkonto (IIS – Virtual Directory)
Ist die Freigabe entsprechend vorbereitet, kann bereits mit der Installation der WSUS-Rolle oder, bei einer bereits existierenden Installation, mit dem verschieben der WSUS-Verzeichnisse begonnen werden. Wichtig ist, dass bei beiden Verfahren im späteren Verlauf die Anpassung des IIS virtuellen Verzeichnisses „Content“ notwendig ist. Bei der Konfiguration der WSUS-Rolle wird entsprechend ein UNC-Pfad als Ziel für die Updatedateien angegeben. Das Zurückgreifen auf ein Netzlaufwerk ist an dieser Stelle nicht nötig. Der WSUS-Content bei einer bestehenden Installation kann mittels WSUSUTIL.exe (Standardpfad – C:\Program Files\Update Services\Tools) verschoben werden. Anstelle eines Datenträgers wird auch hier ein UNC-Pfad angegeben.
Sind die Daten heruntergeladen bzw. verschoben, sollten noch einmal die Berechtigungen der Freigabe überprüft werden. Im Anwendungs-Eventlog des Servers wird nun der Fehler mit der ID – 12072 vermerkt werden. Dieser weißt daraufhin, dass der WebAccess auf das neue WSUS-Content Verzeichnis nicht bzw. noch nicht gegeben ist. Dieser Meldung können wir wie folgt Abhilfe schaffen. Erst dann sind auch Clients in der Lage Update-Pakete vom WSUS-Server abzurufen.
Im IIS-Manager muss zum virtuellen WSUS-Verzeichnis „Content“ navigiert werden:
Dort angekommen, werden über das Kontextmenüpunkt „Virtuelles Verzeichnis verwalten“ – die „Erweiterten Einstellungen“ geöffnet. An dieser Stelle wird neben dem spezifischen Dienstkonto das Vollzugriff auf die genannten Freigabe benötigt, der Pfad für die Update-Dateien/WSUS-Content vervollständigt. Denn weder im Setup noch beider Migration der Updatedateien wurden der doppelte Backslash „\\“ übernommen.
Nach Neustart der WSUS-Dienste sowie dem IIS, sollte die Meldung mit der ID 12072 verschwunden sein und der indirekte Webzugriff auf die Inhalte wieder funktionieren.
Moin,
stehe gerade auch vor der Herausforderung den WSUS Content auf ein Network Share zu verschieben.
Welche Dienste muss ich denn dann mit spezifischen Dienstkonto laufen lassen? Nur den WSUS Dienst, oder ist da noch mehr?
Danke schonmal vorweg
Hallo Sven,
die Anmeldung für den WSUS-Dienst muss nicht geändert werden und sollte auf „Lokales System“ verbleiben. Wichtig ist das entsprechende Dienstkonto welches im IIS für den WSUS-Content-Pfad angegeben wird. Weiterhin viel Erfolg!
Hat funktioniert!!
Danke :)