Das Upgrade von Windows Servern findet häufig nicht als in-place Upgrade statt. Stattdessen wird der neue Server eine Zeit lang parallel betrieben und die einzelnen Rollen werden nach und nach migriert. In diesem Blogeintrag beschäftigen wir uns mit der Migration des Windows Server Update Services (WSUS) von einem Windows Server 2012 R2 zu einem Windows Server 2016.

Aktuelle Konfiguration ermitteln

Die aktuelle Konfiguration des Quellservers kann am einfachsten aus der Registry ausgelesen werden. Hierzu muss zunächst der Registry Editor geöffnet werden:

[Windows-Taste] + [r] drücken und regedit eingeben.

Im Registry Editor navigieren wir anschließend zum Pfad:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup

Abb. 1: Konfiguration Quellserver - Registry

Wichtig sind hierbei die folgenden drei Schlüssel und deren zugehörigen Werte:

ContentDir: D:\
SqlServerName: MICROSOFT##WID
SqlDatabaseName: SUSDB

Der Schlüssel ContentDir gibt das Verzeichnis an, in welchem sich die vom WSUS genutzten Ordner WsusContent und UpdateServicesPackages befinden. Im Schlüssel SqlServerName steht entweder MICROSOFT##WID, wenn die Windows Internal Database genutzt wird, oder der Name des SQL-Servers, falls ein externer SQL Server genutzt wird. Der Schlüssel SqlDatabaseName gibt den Namen der genutzten Datenbank an. Diese heißt standardmäßig SUSDB.

Installation der WSUS Rolle auf Zielserver

Auf dem Zielserver muss vor der Migration die Rolle Windows Server Update Services installiert werden. Beim Konfigurieren der Rolle mit dem Server Manager ist zu beachten, dass der SQL Server genauso wie beim Quellserver konfiguriert sein muss. Das heißt hier wird entweder WID gewählt, oder der bereits existierende SQL Server angegeben. Unter Content location selection sollte nach Möglichkeit der gleiche Pfad wie bei dem Quellserver gewählt werden.

Abb. 2: Installation WSUS Rolle auf Quellserver – ContentDir

Installation Windows Server Migration Tools

Um die Windows Update Installationsdateien und Sicherheitsgruppen zu migrieren, installieren wir zunächst über den Server Manager das Feature Windows Server Migration Tools auf dem Zielserver. Anschließend stellen wir die Tools für den Quellserver bereit. Dazu werden in der Kommandozeile folgende zwei Befehle ausgeführt:

cd %Windir%\System32\ServerMigrationTools\

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

Abb. 3: Windows Server Migration Tools bereitstellen

Die Tools befinden sich im Ordner C:\SMIG. Diesen kopieren wir auf den Quellserver. Auf dem Quellserver öffnen wir eine Kommandozeile und navigieren zum Unterordner SMT_ws12R2_amd64 des kopierten SMIG-Ordners. In meinem Fall befinden sich dieser unter C:\Users\bechtle\Downloads\SMT_ws12R2_amd64. Anschließend installieren wir die Migration Tools mit folgendem Befehl:

.\Smigdeploy.exe

Abb. 4: Installation der Windows Server Migration Tools auf Quellserver

Sollte es hierbei zu einer Fehlermeldung kommen, müssen zunächst die bereits installierten Windows Server Migration Tools über den Server Manager deinstalliert werden.

Stoppen des WSUS-Dienstes auf dem Quellserver

Bevor wir mit der eigentlichen Migration starten können, muss zunächst der WSUS-Dienst auf dem Quellserver gestoppt werden. Damit verhindern wir, dass während der Migration neue Daten vom WSUS geschrieben werden.

Auf dem Quellserver öffnen wir die PowerShell mit erweiterten Berechtigungen (als Administrator) und führen folgenden Befehl aus:

Stop-Service WsusService

Migration der WSUS-Dateien

Auf dem Quellserver wird über Administrative Tools\Windows Server Migration Tools die Windows Server Migration Tools Shell mit erweiterter Berechtigung geöffnet und folgender Befehl ausgeführt:

Send-SmigServerData -ComputerName *ZielComputerName* -SourcePath *ContentDir Quelle* -DestinationPath *ContentDir Ziel* -Include All -Force -Recurse

Hierbei müssen die Werte für die Parameter ComputerName, SourcePath und DestinationPath an die eigene Umgebung angepasst werden. Die Verzeichnisse entsprechen den Werten des Schlüssels ContentDir der jeweiligen WSUS-Server.

Auf dem Zielserver öffnen wir ebenfalls die SMIG-Shell und führen den folgenden Befehl aus:

Receive-SmigServerData

Hierbei muss jeweils dasselbe Passwort gewählt werden.

Migration der Sicherheitsgruppen

Die Sicherheitsgruppen werden ebenfalls mit Hilfe der Windows Server Migration Tools migriert. Hierzu wird außerdem ein geteilter Ordner benötigt, in welchem die Sicherheitsgruppen zwischengespeichert werden können.

Auf dem Quellserver geben wir in der SMIG-Shell folgenden Befehl ein:

Export-SmigServerSetting -User Enabled -Group -Path \\FileShare\SMIG\SecurityGroups -Verbose

Der Parameter Path muss hierbei angepasst werden.

Abb. 8: Export-SmigServerSetting - Sicherheitsgruppen

Auf dem Zielserver werden die Sicherheitsgruppen mit folgendem Befehl, der in der SMIG-Shell ausgeführt wird, importiert:

Import-SmigServerSetting -User Enabled -Group -Path \\FileShare\SMIG\SecurityGroups -Verbose

Abb. 9: Import-SmigServerSetting – Sicherheitsgruppen

Migration der Datenbank

Bei der Migration der Datenbank muss man zwischen zwei Szenarien unterscheiden. Wird ein vollwertiger SQL Server verwendet, so muss hier zunächst nichts migriert werden, da die Datenbank des SQL Servers auch für den neuen WSUS genutzt werden kann.

Benutzt man die Windows Internal Database (WID), so muss im ersten Schritt ein Backup der Datenbank erstellt werden. Dies geschieht am komfortabelsten mit dem SQL Server Management Studio [1].

Wir öffnen das SQL Server Management Studio auf dem Quellserver und geben im sich öffnenden Fenster unter Server folgenden String ein:

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

Anschließend starten wir einen Backup-Task indem wir einen Rechtsklick auf Database\SUSDB machen und Task > Backup auswählen. Dieser wird in Abb. 10 konfiguriert. Als Destination wählen wir Disk und fügen über die Schaltfläche Add… den Pfad für den Speicherort des Backups hinzu.

Auf dem Zielserver muss dieses Backup der Datenbank nun wiederhergestellt werden. Dazu öffnen wir auch auf dem Zielserver das SQL Server Management Studio und verbinden uns zum Server

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

Danach führen wir die folgende Query aus, um die bereits existierende SUSDB Datenbank zu löschen:

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

Im Anschluss können wir die alte SUSDB importieren. Diese habe ich in diesem Beispiel in das Verzeichnis C:\ des Zielservers kopiert. Die folgende Query importiert das Backup das unter C:\SUSDB liegt:

RESTORE DATABASE [SUSDB] FROM DISK = N'C:\SUSDB' 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 hierbei auftretende Fehler kann ignoriert werden.

Ändern der WSUS Identität

Nun muss noch die WSUS Identität geändert werden. Dazu öffnen wir die PowerShell mit erweiterten Rechten und geben folgende Befehle ein:

$updateServer = get-wsusserver
$config = $updateServer.GetConfiguration()
$config.ServerId = [System.Guid]::NewGuid()
$config.Save()

Sollte hierbei eine Fehlermeldung erscheinen, die besagt, dass kein WSUS-Server gefunden werden konnte, wurden bei der Installation der Rolle die Post-Installation-Steps nicht durchgeführt. In diesem Fall muss zunächst folgendes ausgeführt werden:

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

Anschließend können die obigen Befehle erfolgreich ausgeführt werden. Im letzten Schritt wird ein neuer Encryption Key erstellt. Dies geschieht ebenfalls mit den Befehlen

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

Sollte ein vollwertiger SQL Server im Einsatz sein und nicht die Windows Internal Database, so lautet der letzte Befehl stattdessen

.\WsusUtil.exe postinstall SQL_INSTANCE_NAME=”ComputerNameDesSQLServers”

wobei die Anführungszeichen nicht entfernt werden.

Alten WSUS stilllegen

Damit ist die Migration prinzipiell abgeschlossen. Sofern ein vollwertiger SQL Server genutzt wird, sollte in der Registry des Quellservers der Schlüssel SqlServerName unter Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup angepasst werden, damit der alte WSUS nicht mehr in die SUSDB Datenbank auf dem SQL Server schreibt.

Bevor der alte WSUS Server stillgelegt wird, sollte überprüft werden, dass sich die Clients korrekt beim neuen WSUS Server melden und Updates beziehen können. Je nach Umgebung muss hier beispielsweise eine bestehende Gruppenrichtlinie angepasst werden.

Damit ist die Migration der Windows Server Update Services Rolle erfolgreich abgeschlossen.

[1] https://go.microsoft.com/fwlink/?linkid=2014306 - SQL Server Management Studio

WSUS Migration von Windows Server 2012 R2 zu Windows Server 2016