Windows Server Update Services (WSUS) auf einen anderen Server migrieren

Es ist Best-Practice, den WSUS-Dienst auf dem Quell-Server vor der Migration zu beenden. Dies funktioniert über das MMC-Tool für Dienste, alternativ reicht aber auch ein kurzer PowerShell-Befehl:

Stop-Service WSUS-Service

Eine letzte Voraussetzung ist, dass auf beiden Rechnern der Port 7000 UDP/TCP geöffnet sein muss, da die Windows-Server-Migration-Tools, auf welche wir im Folgenden zurück­greifen, diesen zwingend benötigen.

Migrationsschritte

Der Umzug von WSUS auf einen anderen Server besteht aus folgenden Schritten:

• Migration der Update-Dateien (optional)
• Migration der Security Groups
• Backup und Restore der WSUS-Datenbank
• Abschließende Schritte

Migration der Update Binaries (optional)

In vielen Unter­nehmen wird die Verwaltung der vorhandenen Update-Dateien eher stiefmütterlich behandelt. Ein WSUS-Server läuft im Schnitt mehrere Jahre bis zur nächsten Migration. Daher sollte man überlegen, ob man sämtliche Update-Altlasten übernehmen möchte oder ob man lieber die benötigen Updates neu herunterladen will.

Für den Fall, dass Updates auf dem Quell-Server gepflegt wurden oder der Aufwand für eine Neubewertung zu hoch erscheint, lassen sich die Update-Files mit den Windows Server Migration Tools (WSMT) übertragen (ein Kopieren per Robocopy ist ebenfalls möglich).

Im ersten Schritt installiert man die WSMT über den Windows Server Manager auf dem Ziel-Server, wo man sie unter Features findet.

Nach der Installation stellt der Ziel-Server die WSMT auf dem Quell-Server bereit. So gewährleistet man, dass beide Server über dieselbe Version verfügen. Dazu öffnet man auf dem Ziel-Server eine Eingabe­aufforderung mit erhöhten Rechten. Dort wechselt man in das WSMT-Directory und stellt anschließend die WSMT bereit:

"cd %Windir%\System32\ServerMigrationTools\"

"SmigDeploy.exe /package /architecture amd64 /os WS12R2 /path C:\WSMT"

Der OS-Parameter muss man natürlich an das jeweilige Betriebs­system des Quell-Servers anpassen. Die Files befinden sich nun im Ordner C:\WSMT. Diesen kopiert man auf dem Quell-Server in ein beliebiges Verzeichnis.

Nun wechselt man in der CMD auf dem Quell-Server zum WSMT-Verzeichnis und öffnet das Tool mit Smigdeploy.exe (Hinweis: Es benötigt .NET 3.5 auf dem Quell-Server).

Über die Windows-Suche startet man auf dem Quell-Server nun die Windows Server Migration Tools und führt diesen Befehl aus:

Send-SmigServerData -ComputerName 10.0.1.4 -SourcePath C:\Updates -DestinationPath C:\Updates -Include All -Force -Recurse

Die IP-Adresse bzw. den Hostname für ComputerName und das Verzeichnis für die Updates muss man natürlich an seine Umgebung anpassen. Anschließend vergibt man ein Passwort.

Der Quell-Server ist nun bereit für die Migration und wartet auf das Signal von der Gegenstelle.

Auf dem Ziel-Server startet man die WSMT nun ebenfalls und gibt folgendes Kommando ein:

Receive-SmigServerData

Nach der Eingabe des Passworts startet die Migration.

Migration der Security Groups

Die WSMT können auch die Sicherheits­gruppen synchronisieren. Dazu wechselt man auf den Quell-Server, öffnet die WSMT-Shell und führt folgenden Befehl aus:

Export-SmigServerSetting -User Enabled -Group -Path \\10.0.1.4\C$\WSMT\SecGroups

Die IP bzw. der Hostname sollten natürlich wieder angepasst werden. Das Verzeichnis muss außer­dem auf dem Ziel-Server bereits existieren. Hier fordert das Tool wieder ein Passwort an, das beim Empfangen benötigt wird.

Auf dem Ziel-Server holt man die Daten ebenfalls über die WSMT-Shell mit folgendem Kommando ab:

Import-SmigServerSetting -User Enabled -Group -Path \\10.0.1.4\C$\WSMT\SecGroups -Verbose

Backup und Restore der WSUS Datenbank

WSUS kann entweder die interne Windows Datenbank (WID) oder einen SQL Server nutzen, wobei Erstere am geläufigsten ist. Wenn man nicht sicher ist, welche von beiden man für WSUS konfiguriert hat, dann kann man das Registry mit folgendem PowerShell-Befehl entnehmen:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Update Services\Server\Setup"|
Select-Object -ExpandProperty SqlServerName

Damit enthält man den Wert MICROSOFT##WID oder den Namen der SQL-Datenbank. Bei Zweiterer müssen wir nichts mehr weiter tun, weil der neue WSUS einfach wieder auf die Datenbank zugreift.

Für die Migration einer internen WSUS-DB hat sich ein Backup-Restore-Verfahren mit dem SQL-Server Management Studio (SSMS) als Best Practice erwiesen. Diese Software erhält man hier von Microsoft.

Nach der Installation auf beiden Maschinen wechselt man auf den Quell-Server und öffnet das Tool. Im Connect-Dialog geben wir als Server ein:

\\.\pipe\MICROSOFT##WID\tsql\query

Nachdem die Verbindung erfolgreich hergestellt ist, finden wir unter Databases auch SUSDB. Dort wählen wir aus dem Kontextmenü Tasks => Backup.

Im Backup-Wizard müssen wir nichts anpassen, lediglich der Pfad, unter dem wir das Backup auf der Disk speichern wollen, muss angegeben werden.

Je nach Größe der Datenbank läuft das Backup schneller oder langsamer durch. Die gespeicherte Datei kopieren wir nun auf den Ziel-Server, auf dem man sich auf die gleiche Weise im SSMS auf die SUSDB verbindet.

Hier muss nun die bestehende SUSDB gelöscht werden. Dies kann man mit folgender Query erreichen (Rechtsklick auf SUSDB und dann New Query):

USE master GO ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO DROP DATABASE SUSDB

Im Anschluss kann man das Backup des Quell-Servers mit folgender Abfrage importieren:

RESTORE DATABASE [SUSDB] FROM DISK = N'C:\wsusbackup' WITH FILE = 1, MOVE N'SUSDB' TO N'c:\Windows\WID\Data\susdb.mdf', MOVE N'SUSDB_log' TO N'c:\Windows\WID\Data\SUSDB_log.ldf', NOUNLOAD, STATS = 10

Der Pfad in der ersten Zeile muss natürlich angepasst werden.

Hiermit ist die Migration der Datenbank abgeschlossen.

Letzte Schritte

Zum Abschluss sollte noch die Post-Installation durchgeführt werden. Dies lässt sich am einfachsten in einer Admin-PowerShell mit folgenden Befehlen erledigen:

cd "C:\Program Files\Update Services\Tools"
.\WsusUtil.exe postinstall

Um spätere Probleme zu vermeiden, sollte man noch die ServerID des neuen WSUS anpassen. Dies geht ebenfalls mittels PowerShell. Hierzu greift man direkt auf die WSUS-Konfiguration zu und generiert eine neue GUID:

$conf = (get-wsusserver).getConfiguration()
$conf.ServerID = [System.Guid]::NewGuid()
$conf.Save()

Falls der neue WSUS-Server über einen neuen Hostnamen oder eine neue IP verfügt, muss man je nach Umgebung auch die Infos an die Clients, welche ihre Updates von dem neuen WSUS beziehen, übertragen. In der Regel existiert dafür ein GPO, welche angepasst werden muss.