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


    Tags: ,

    WSUS-Datenbank migrieren mit SSMSAufgrund ihrer Schlüssel­funk­tion sollten WSUS-Server auf einem aktu­ellen Host-System laufen. Spätes­tens das Support-Ende einer Ver­sion von Windows Server, wie kürz­lich bei 2008 R2, ist ein zwin­gender Grund für den Wechsel. Diese An­leitung zeigt, wie man WSUS auf eine neue Maschine um­zieht.

    Die Migration setzt natürlich voraus, dass ein funktions­fähiger Quell-Server vorhanden ist, der die aktuellen WSUS-Daten enthält, und der migriert werden soll. Des Weiteren sollte der Ziel-Server schon bereit sein und die WSUS-Rolle installiert haben. Nach der WSUS-Installation sollte hier aber keine Erst­konfiguration erfolgen.

    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.

    Windows Server Migration Tools über den Assistenten im Server Manager auf dem Ziel-Server hinzufügen

    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.

    Windows Server Migration Tools für das Deployment auf den Quell-Server vorbereiten

    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.

    Übertragung der Daten auf dem Quell-Server starten

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

    Der Quell-Server wartet auf den Befehl des Ziel-Servers, mit der Übertragung zu beginnen.

    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.

    Der Update-Ordner auf dem Ziel-Server füllt sich nun mit den Updates.

    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.

    Export der Security Groups mit den WSMT

    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 in der Registry herausfinden. Der Eintrag

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

    enthält 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

    In SQL-Server Management Studio mit der internen Windows-Datenbank verbinden

    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.

    SUSDB auf dem Quell-Server mit dem SSMS in eine Datei sichern

    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):

    SUSDB auf dem Ziel-Server über SQL-Script löschen

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

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

    WSUS-Datenbank auf dem Ziel-Server mit dem SSMS wiederherstellen

    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

    Post-Installation auf dem Ziel-Server ausführen

    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()

    ServerID für den neuen WSUS-Server ändern

    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.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Keine Kommentare