WSUS Datenbank von Windows Internal Database auf SQL-Server umziehen

Wie wohl viele Admins in Unternehmen setze ich bei meinen betreuten Firmen WSUS zur Firmeninternen Verteilung von Microsoft Patches ein. Als ich den aktuellen WSUS Server auf der Windows Server 2012 R2 Kiste installierte, nutzte ich die Installationsoption mit der Windows Internal Database (WID). Jetzt, nach gut 2 Jahren Betrieb des WSUS, gehen mit die Geschwindigkeitseinbußen wg. der WID auf den Keks (aber eigentlich fand ich die Performance mit WID immer schon grenzwertig).
Also habe ich mich auf die Suche nach einer Migrationstrategie für die Migration WID -> SQL Server gemacht und es finden sich eine Vielzahl von Anleitungen. Nur beziehen diese sich größten Teils noch auf WSUS 3.x (Windows Server 2008) oder es fehlt eine Essentielle Information, weshalb ich das Szenario in Eigenregie in meiner Testumgebung auf eigene Faust umgesetzt habe.

Bevor man beginnen kann, muss auf dem WSUS Server das SQL Management Studio installiert werden. Ein Drops, den ich nur ungern gelutscht habe, aber ohne geht es leider nicht. Das SQL Management Studio wird benötigt um sich auf dem WSUS Server mit der WID verbinden zu können und die SUSDB zu trennen.

WSUS beenden

Zur Sicherheit sollte man bevor man mit der ganzen Aktion beginnt, WSUS beenden. Dazu habe ich auf dem WSUS-Server den IIS-Verwaltungsdienst (IISADMIN) und den WSUS-Dienst (WsusService) beendet.

WSUS Rollendienste entfernen und einen anderen hinzufügen

Seit Windows Server 2012 kann man zwar Rollen und Features über den Servermanager installieren, aber nicht mehr deinstallieren. Für die Deinstallation von Rollen oder Features zwingt Microsoft den Administrator  in die PowerShell. Aber keine Angst, das geht ohne große Probleme. Zunächst lassen wir uns die Windows Features bzgl UpdateServices anzeigen:

Genau das ist die Stelle, die mir an anderen Anleitungen gefehlt hat: Die Migration klappt nur, wenn die Rolle/Feature UpdateServices-DB installiert ist. Diese lässt sich allerdings nur installieren, wenn die Rolle/Feature UpdateServices-WidDB deinstalliert ist. Ergo wird über die folgenden beiden Befehle erst das eine deinstalliert und anschließend das andere installiert:

WID Datenbank trennen

Um sich mit der WID zu verbinden muss folgender String im SQL Management Studio für den Servernamen angegeben werden:

WID

Danach findet man im Objektexplorer auf der Linken Seite unter „Datenbanken“ die SUSDB. Damit diese Datenbank auf einen SQL Server verschoben werden kann, sollte man die SUSDB trennen. Dazu macht man einen Rechtsklick auf die SUSDB und wählt im Kontextmenü Tasks -> Trennen. Im „Datenbank trennen“ Dialog den Haken bei „Verbindungen löschen“ setzen und dann mit OK bestätigen.

SUSDB-trennen

Nachdem die Datenbank erfolgreich getrennt wurde, verschwindet sie links aus dem Objektexplorer.

Datenbank kopieren

Im nächsten Schritt muss die Datenbank auf den SQL Server kopiert werden. Ich habe mich dazu entschlossen die Datenbank auf unseren zentralen SQL Server zu kopieren und keine eigenständige SQL Server Instanz auf dem WSUS-Server zu installieren.
Die Datenbankdateien der SUSDB finden sich auf dem WSUS-Server im Verzeichnis C:\Windows\WID\Data\:

SUSDB-dir

Auf dem Ziel SQL-Server werden die beiden Dateien in folgende Verzeichnisse kopiert:

Datenbank verbinden

Jetzt verbindet man sich mit dem SQL Management Studio mit dem SQL Server, der die SUSDB zukünftig hosten soll. Nachdem die Datenbankdateien im Schritt zuvor schon in Place kopiert wurden, muss die DB jetzt verbunden werden. Und das geht genauso einfach wie das trennen:

Rechtsklick auf Datenbanken -> Anfügen. Über den Knopf „Hinzufügen“ im Bereich „Anzufügende Datenbanken“ die zuvor kopierte SUSDB.mdf auswählen und mit OK bestätigen (ggf. in den richtigen Pfad navigieren). Im unteren Bereich „Datenbankdetails“ ist jetzt die Datenbankdatei und die Logdatei zu sehen; bei der Logdatei ist ggf. in der Spalte Meldung ein „Nicht gefunden“ stehen und in der Spalte daneben (Aktueller Pfad) der alte Pfad der Logdatei stehen (C:\Windows\WID\DATA\SUSDB.ldf). Hier muss noch der Pfad für die Logdatei angepasst werden, indem über die drei Punkte die richtige Datei ausgewählt wird.

Datenbank Berechtigungen

Nachdem die Datenbank verbunden ist, müssen noch Berechtigungen gesetzt werden. Zunächst muss der WSUS-Server selbst Zugriff auf den SQL Server erhalten. Dazu unter Sicherheit -> Anmeldungen einen neuen Account für den WSUS-Server anlegen:

Allgemein\Anmeldename: Domäne\WSUSSERVERNAME$ (das ist der Computeraccount, wg. dem $, wissen schon)
Serverrollen -> Public
Benutzerzuordnung -> SUSDB -> Domäne\WSUSSERVERNAME$ -> dbo

SUSDB-permission

Jetzt sollte die Datenbank für den WSUS-Server verfügbar sein.

WSUS-Server Neukonfiguration

Zu guter letzt muss der WSUS-Server noch neu Konfiguriert werden. Dies erledigt man mit dem Kommandozeilenbefehl C:\Program Files\UpdateServices\Tools\WsusUtil.exe mit folgendem Aufruf:

SQLSERVERNAME und INSTANCENAME muss natürlich an die Gegebenheiten angepasst werden. Wenn die Meldungen wie im nachfolgenden Screenshot aussehen hat alles funktioniert. Im Fehlerfall bietet die Protokolldatei hilfreiche Hinweise.

WSUS-reconfig

 

Ob schlussendlich wirklich alles funktioniert hat, sieht man, wenn sich die WSUS Adminkonsole starten lässt.

That’s it folks!

Veröffentlicht in Admin Kram, Windows Server Getagged mit: , ,
10 Kommentare zu “WSUS Datenbank von Windows Internal Database auf SQL-Server umziehen
  1. Ralf sagt:

    Vielen Dank für deine Anleitung.
    Es gibt einen kleinen Schreibfehler in deinem Verbindungsstring für das SQL-Managementstudio:
    Dort sollte der ‚\‘ zwischen Microsoft und Raute weg.
    Der Punkt am Ende nach query sollte natürlich auch nicht sein.
    \\.\pipe\MICROSOFT##WID\tsql\query
    Im Screenshot stehts korrekt.
    Grüße,
    Coyo

  2. Flavio sagt:

    Bedanke mich für die Anleitung.
    Wollte mich informieren ob bezüglich Geschwindigkeit ein deutlicher Unterschied spürbar ist?

    Grüße
    Flavio

    • Carsten sagt:

      Hallo Flavio,

      definitiv! Das freigeben/ablehnen von Updates war bei Nutzung der Windows Internal Database doch sehr zäh. Pro zu verarbeitenden Update dauerte das ganze schon gern mal 4-5 Sekunden, jetzt mit einer ordentlichen DB dahinter sind 20 oder mehr Updates in kürzerer Zeit verarbeitet. Es ist kein Vergleich zu vorher. Endlich flüßig mit WSUS arbeiten.

      Auch das Auswählen von Produkten/Klassifizierungen (Optionen -> Produkte und Klassifizierungen) ist jetzt flott. Mit der WID dauerte es gefühlte Ewigkeiten bis die Produktliste aufgebaut war. Heute dauert es einen kurzen Moment und dann kann schon mit der Selektion begonnen werden.

      Grüße Carsten

  3. Boffystar sagt:

    Guten Tag,

    hat abei mir alles super geklappt!

    Danke für die Anleitung.

    Was bei mir nicht auf Anhieb funktionierte, die Datenbank SUSDB war schreibgeschützt.

    Somit ist der erste Versuch die Datenbank mit dem Wsus zu verbínden in die Hose gegangen.

    Also rein ins Management Studio, schreibschutz entfernt und danach funzte alles!

  4. Joachim Klemm sagt:

    Hallo,
    nachdem es mit der WID unseres WSUS ein Problem gab, haben wir SQL Server 2014 Express installiert und versucht, die Migration durchzuziehen.
    Aktuell hängen wir an dem letzten Punkt: wsusutil.exe postinstall SQL_INSTANCE_NAME=“\WSUS“

    Es erscheint folgende Meldung:
    Schwerwiegender Fehler: Die Schemaversion der Datenbank stammt von einer neueren WSUS-Version
    als der zurzeit installierten Version. Sie müssen den WSUS-Server mindestens auf
    diese Version aktualisieren oder die Datenbank löschen.

    Was läuft hier schief?
    Danke für eine baldige Rückinfo.

    • Carsten sagt:

      Wurde der Befehl so wie er hier im Kommentar angegeben ausgeführt? Hier fehlt mir der Datenbankhost, also mal so versuchen:

      wsusutil.exe postinstall SQL_INSTANCE_NAME=“DB_SERVERNAME\WSUS“

      Der WSUS Host hat sich nicht geändert, dem soll nur die SQL DB statt der WID untergeschoben werden? Oder gab es hier noch zusätzliche Migrationen (z.B. WSUS gleichzeitig von W2k8R2 auf W2k12R2 o.ä.)? Gibt es nur einen WSUS Server, oder mehrere (Upstream, Downstreamserver)? Wenn Ja, auf welchem wurde der Befehl ausgeführt?

      Meine 2ct, so ins blaue hinein…

      Viel Erfolg!

  5. Martin sagt:

    Hatte ein Problem mit SQL Express und WID gleichzeitig und konnte den WID nicht mehr neu nachinstallieren (Fehlermeldung vom Server-Manager). Daher Umzug der bestehenden DB von WID auf SQL Express 2012 mit deiner Anleitung. Funktionierte auf Anhieb. Jetzt haben wir wieder einen funktionierenden WSUS. Top!

  6. MysterioM sagt:

    Hat funktioniert.

    Vielen Dank.

    MysterioM

  7. Basti sagt:

    Vielen Dank für die Anleitung, hat super im ersten Anlauf geklappt! 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*