Installation von WSUS auf Server 2016 planen: Systemvoraussetzungen, Storage-Optionen, Workgroups

Den Angaben von Microsoft zufolge benötigt die WSUS-Rolle 2GB zusätzliches RAM. In einer VM mit Server Core und aktiviertem Dynamic Memory steigt der Speicherverbrauch aber ohne Weiteres auf über 10GB an.

Hinsichtlich CPU und Netzwerk­adapter (mind. 100 Mbit/s) sind die Voraus­setzungen moderat. Der Speicherbedarf hängt natürlich stark davon ab, wie viele Produkte in welchen Sprachen über WSUS aktualisiert werden sollen.

Der erforderliche Plattenplatz beträgt 10GB, die Empfehlung des Herstellers lautet aber auf mindestens 40GB. Der tatsächliche Bedarf hängt jedoch von den gewählten Storage-Optionen und dem Modus ab, nach dem die Updates auf die Clients geladen werden.

Datenbank für Metadaten

Bei der Speicher­konfiguration sollte man bedenken, dass WSUS zwei verschiedene Ablagen verwenden. Alle Verwaltungs­informationen, also im Prinzip nur Metadaten, landen in der Datenbank. Dazu gehören die WSUS-Konfiguration, die beschreibenden Infor­mationen für jedes Update und solche zu den Clients sowie die Interaktion mit ihnen. Die eigentlichen Updates bleiben indes im Dateisystem.

WSUS nutzt standard­mäßig die mit Server 2012 eingeführte Windows Internal Database (WID), kann aber auch einen SQL Server verwenden. Letzterer wird in der Regel auf einer separaten Maschine laufen. Betreibt man mehrere Installationen von WSUS, dann benötigt jede davon eine eigene Instanz von SQL Server.

Daher könnte man in sich in dieser Situation eine hybride Konfiguration erwägen, bei welcher der Root-Server seine Daten in einer SQL-Datenbank ablegt, aber die davon abhängigen sekundären Server die WID nutzen.

Der Wechsel der Datenbank oder des WID-Speicherorts ist nachträglich zwar möglich, allerdings nicht über die WSUS-Konsole. Somit bereitet etwa der Umstieg von der WID zu SQL Server einigen Aufwand. Daher sollte man hier gleich vorausschauend agieren.

Cache für Updates nur optional

Während WSUS eine Datenbank zwingend erfordert, ist ein Ablageort für die Updates nur optional. Der Dienst lässt sich nämlich so konfigurieren, dass der Administrator darüber nur die Freigabe von Updates verwaltet, die Clients diese aber dann direkt von Microsoft herunterladen.

Dieses Szenario verzichtet auf den Zwischen­speicher und eignet sich etwa für Außenstellen, wo die Anbindung an einen zentralen WSUS-Server langsamer ist als die Verbindung ins Internet. Bei der Wahl dieses Modus verringert sich der Platzbedarf entsprechend.

Diese Einstellung lässt sich nachträglich recht einfach ändern, aber sie passt dann möglicher­weise nicht mehr zur gewählten WSUS-Topologie, weil dafür am betreffenden Standort etwa die Voraussetzungen beim Netzwerk nicht gegeben sind.

Systemlaufwerk als Speicherort

Bei der Konfiguration der Storage-Optionen sollte man nicht nur auf den Platzbedarf achten, sondern auch auf den Speicherort. Der Best Practice Analyzer bemängelt, wenn sich die WID-Datenbank oder die Dateiablage für die Updates auf dem System­laufwerk befinden.

Bei einem virtuellen WSUS lässt sich für die Speicherung der Updates noch während der Installation recht einfach eine VHD oder VMDK hinzufügen.

Dagegen ist die Situation beim WID-Speicherort schizophren. Die WSUS-Installation lässt dem Benutzer hier keine Wahl und verwendet immer das Systemlaufwerk, worüber sich dann der BPA beschwert. Man kann die WID aber nachträglich auf ein anderes Volume verschieben, was aber wieder mit einigem Aufwand verbunden ist.

WSUS in einer Workgroup oder auf DC

Die Windows Server Update Services setzen keine Mitgliedschaft in einer Domäne voraus, sie lassen sich auch in einer Workgroup betreiben. Allerdings erschwert dies die Organisation von Verteilerringen, weil die Clients dann durch lokale Gruppen­richtlinien oder Registry-Einträge konfiguriert werden müssen. Hilfreich ist hier der kostenlose WSUS Client Manager for Workgroups.

In kleineren Umgebungen könnte man auf die Idee kommen, WSUS mit auf einen Domänen-Controller zu packen. Davon ist jedoch abzuraten, diese Konfiguration wird nicht unterstützt und garantiert Probleme.

WSUS im Verbund

Bei größeren Umgebungen empfiehlt es sich oft, mehrere WSUS-Server zu betreiben. Ein Vorteil solcher verteilter Update-Server besteht darin, dass man sie im Netzwerk jeweils näher an den Clients platzieren kann, etwa in Außenstellen. Dabei lässt sich das Herunterladen der Updates aus dem Internet auf einen Server beschränken, alle anderen beziehen sie dann von diesem.

Bei der Planung einer Topologie empfiehlt Microsoft, hierarchische Anordnungen zu vermeiden, bei denen sekundäre Server ihre Updates an WSUS in einer dritten oder vierten Ebene weitergeben. Vielmehr sollten alle Server am primären WSUS hängen (Hub and Spoke).

Beim Einsatz mehrerer WSUS-Server kann man sich zwischen zwei Modi entscheiden, bei denen die sekundären Server eigenständig verwaltet werden (autonomous mode) oder wo sie Freigabe- und Gruppen-Informationen automatisch vom übergeordneten Server erhalten (replica mode).