7
WSUS zieht von Blech auf neue VM und bekommt eine SQL-DB
Guten Morgen,
mir wurde gerade das Thema WSUS auf den Tisch gelegt. Der läuft aktuell auf einer Maschine dessen Performance
ohnehin schon unterirdisch ist und zudem auch noch auf einem Domain-Controller.
Alte Maschine
IBM x346, Xeon Dual 3 GHz, 2 GB RAM
Windows Server Standard 2008 SP2 x64
WSUS 3.2.7600.226 (aktuell)
WID mit rund 6 GB
Content 38 GB
Neue Maschine
VMware Hardware Version 10,
Windows Server 2012 R2 Standard
Anleitungen gibt es ja zum Glück hinreichend. Umzug WSUS (WID-WID) und Migration WID-SQL auch. Aber so richtig was zur Reihenfolge,
wenn man beides machen will - nicht.
A) Hat meine Recherche ergeben, dass das WSUS-Setup es NICHT hergibt, direkt einen SQL Server anzugeben????! Ernsthaft?!
B) Habe ich so die Befürchtung, wenn ich die alte WID in eine SQL-DB migriere, dann den neuen WSUS installiere und in der Registry auf die SQL-DB umbiege, dass er die dann nicht schluckt, weil das vielleicht irgendwie auf die alte Maschine "gemünzt" ist. Hat da jemand Erfahrung mit? Würde dann ja bedeuten ich muss erst den WSUS umziehen und dann die umgezogene WID in die SQL-DB migrieren. Beides noch nicht gemacht, aber klingt nach "mehr" Aufwand, als es in einem Abwasch zu machen ...
Was meint ihr dazu?
mir wurde gerade das Thema WSUS auf den Tisch gelegt. Der läuft aktuell auf einer Maschine dessen Performance
ohnehin schon unterirdisch ist und zudem auch noch auf einem Domain-Controller.
Alte Maschine
IBM x346, Xeon Dual 3 GHz, 2 GB RAM
Windows Server Standard 2008 SP2 x64
WSUS 3.2.7600.226 (aktuell)
WID mit rund 6 GB
Content 38 GB
Neue Maschine
VMware Hardware Version 10,
Windows Server 2012 R2 Standard
Anleitungen gibt es ja zum Glück hinreichend. Umzug WSUS (WID-WID) und Migration WID-SQL auch. Aber so richtig was zur Reihenfolge,
wenn man beides machen will - nicht.
A) Hat meine Recherche ergeben, dass das WSUS-Setup es NICHT hergibt, direkt einen SQL Server anzugeben????! Ernsthaft?!
B) Habe ich so die Befürchtung, wenn ich die alte WID in eine SQL-DB migriere, dann den neuen WSUS installiere und in der Registry auf die SQL-DB umbiege, dass er die dann nicht schluckt, weil das vielleicht irgendwie auf die alte Maschine "gemünzt" ist. Hat da jemand Erfahrung mit? Würde dann ja bedeuten ich muss erst den WSUS umziehen und dann die umgezogene WID in die SQL-DB migrieren. Beides noch nicht gemacht, aber klingt nach "mehr" Aufwand, als es in einem Abwasch zu machen ...
Was meint ihr dazu?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 254029
Url: https://administrator.de/contentid/254029
Printed on: April 19, 2024 at 16:04 o'clock
7 Comments
Latest comment
Hi,
Du könntest den neuen WSUS als VM parallel zum alten aufsetzen. Bevor Du ihn integrierst, stellst Du in auf SQL-Server um. Dann kämgst Du ihn in die vorhandene Umgebung rein, replizierst die Daten rüber, nimmst den alten Server raus und verteilst den neuen WSUS per GPO an die Clients.
Sollte doch so gehen.
E.
Du könntest den neuen WSUS als VM parallel zum alten aufsetzen. Bevor Du ihn integrierst, stellst Du in auf SQL-Server um. Dann kämgst Du ihn in die vorhandene Umgebung rein, replizierst die Daten rüber, nimmst den alten Server raus und verteilst den neuen WSUS per GPO an die Clients.
Sollte doch so gehen.
E.
Mahlzeit,
vorweg, deine ?-Taste klemmt.
zu A) Du hast unrecht. Du kannst beim Setup des WSUS deinen SQL-Server angeben. Wenn keiner da ist, wird die WID mitinstalliert.
zu B) Du kannst den WSUS sehr einfach von einem auf den anderen Server migrieren. Dazu musst du auch nichts in der Registry umbiegen. Oder willst du auf dem neuen Server erst die WID mit WSUS und anschließend einen vollwertigen SQL-Server installieren?
Emeriks hat dir ja schon beschrieben, wie die Migration funktioniert. Ist eigentlich sehr einfach und selbst für Teilzeitadmins durchführbar.
vorweg, deine ?-Taste klemmt.
zu A) Du hast unrecht. Du kannst beim Setup des WSUS deinen SQL-Server angeben. Wenn keiner da ist, wird die WID mitinstalliert.
zu B) Du kannst den WSUS sehr einfach von einem auf den anderen Server migrieren. Dazu musst du auch nichts in der Registry umbiegen. Oder willst du auf dem neuen Server erst die WID mit WSUS und anschließend einen vollwertigen SQL-Server installieren?
Emeriks hat dir ja schon beschrieben, wie die Migration funktioniert. Ist eigentlich sehr einfach und selbst für Teilzeitadmins durchführbar.
Zitat von @emeriks:
Du könntest den neuen WSUS als VM parallel zum alten aufsetzen. Bevor Du ihn integrierst, stellst Du in auf SQL-Server um.
Eine gute Beschreibung von Microsoft gibt es dazu auch noch.Du könntest den neuen WSUS als VM parallel zum alten aufsetzen. Bevor Du ihn integrierst, stellst Du in auf SQL-Server um.
Gruß,
Dani
Guten Morgen nochmal,
ich habe jetzt schon eine ganze Weile erfolglos daran gefeilt.
Die Migrations-Anleitung WID-SQL Express funktioniert und ich bekomme die SUSDB auch auf unseren Haupt-SQL Server umgezogen,
aber ich kann dann weder vom alten Blech-Server, noch von der neuen VM auf die SUSDB zugreifen.
Die WSUS MMC meldet: Es kann keine Verbindung mit "VMmitWSUS-Rolle" hergestellt weren. SQL Server wird auf dem Server möglicherweise nicht ausgeführt.
Alle Schritte aus der How to migrate WID to SQL Express- und der How to move WSUS Database-Anleitung habe ich penibel abgearbeitet.
Den Registry-Key habe ich bereits mit und ohne Angabe des Instanz-Namens ausprobiert (VM bzw. VM\MSSQLSERVER)
Danach habe ich nochmal diese Anleitung entdeckt und die 2 Registry-Keys ausprobiert, die es bei mir nicht gab. Fehlanzeige.
Tja, was soll ich sagen. Seitdem ich das Computerkonto vom WSUS auf die SUSDB berechtigt habe (stand im SQL-Log, dass der da ran möchte), meckert der SQL Server nicht mehr. Aber in der WSUS MMC bleibt es bei der selben Meldung.
Neugestartet ... WSUS-Rolle neu installiert ...
Weiss nicht mehr weiter ... hat jemand noch Ansätze?
ich habe jetzt schon eine ganze Weile erfolglos daran gefeilt.
Die Migrations-Anleitung WID-SQL Express funktioniert und ich bekomme die SUSDB auch auf unseren Haupt-SQL Server umgezogen,
aber ich kann dann weder vom alten Blech-Server, noch von der neuen VM auf die SUSDB zugreifen.
Die WSUS MMC meldet: Es kann keine Verbindung mit "VMmitWSUS-Rolle" hergestellt weren. SQL Server wird auf dem Server möglicherweise nicht ausgeführt.
Alle Schritte aus der How to migrate WID to SQL Express- und der How to move WSUS Database-Anleitung habe ich penibel abgearbeitet.
Den Registry-Key habe ich bereits mit und ohne Angabe des Instanz-Namens ausprobiert (VM bzw. VM\MSSQLSERVER)
Danach habe ich nochmal diese Anleitung entdeckt und die 2 Registry-Keys ausprobiert, die es bei mir nicht gab. Fehlanzeige.
Tja, was soll ich sagen. Seitdem ich das Computerkonto vom WSUS auf die SUSDB berechtigt habe (stand im SQL-Log, dass der da ran möchte), meckert der SQL Server nicht mehr. Aber in der WSUS MMC bleibt es bei der selben Meldung.
Neugestartet ... WSUS-Rolle neu installiert ...
Weiss nicht mehr weiter ... hat jemand noch Ansätze?
?! ...
und integrieren heisst an der Stelle genau was? ihn als Downstream-Server konfigurieren?
Nochmal von vorne:
Der alte Server: Windows 2008, WSUS mit WID SUSDB und dem Updaterepository lokal
Aufgabe 1: WSUS auf der VM installieren (erledigt)
Aufgabe 2: die WID/SUSDB vom alten Server mit dem Katalog / Status zu allen Updates, Genehmigungen etc. auf den SQL-Server umziehen (erledigt)
Aufgabe 3: den neuen WSUS/die VM umbiegen, dass er nicht mehr seine neue/leere WID-SUSDB lokal, sondern die Remote-SUSDB auf dem SQL-Server nutzt (nach Anleitung erledigt)
Problem: beim Start der WSUS MMC kommt eben dieser Fehler, dass SQL Server nicht ausgeführt wird blah ...
Im Event-Log kommt 7053 und man soll den MMC-Cache löschen - bringt leider nichts.
Vielleicht ist mein Ansatz ja Quatsch, die alte SUSDB zu übernehmen?!?
Kann ich den WSUS als Downstream-Server einrichten und er übernimmt vom "Master" den Katalog/Datenbank-Inhalt?
Ich dachte der holt sich "nur" die Update-Pakete und synct das Repository ...
und integrieren heisst an der Stelle genau was? ihn als Downstream-Server konfigurieren?
Nochmal von vorne:
Der alte Server: Windows 2008, WSUS mit WID SUSDB und dem Updaterepository lokal
Aufgabe 1: WSUS auf der VM installieren (erledigt)
Aufgabe 2: die WID/SUSDB vom alten Server mit dem Katalog / Status zu allen Updates, Genehmigungen etc. auf den SQL-Server umziehen (erledigt)
Aufgabe 3: den neuen WSUS/die VM umbiegen, dass er nicht mehr seine neue/leere WID-SUSDB lokal, sondern die Remote-SUSDB auf dem SQL-Server nutzt (nach Anleitung erledigt)
Problem: beim Start der WSUS MMC kommt eben dieser Fehler, dass SQL Server nicht ausgeführt wird blah ...
Im Event-Log kommt 7053 und man soll den MMC-Cache löschen - bringt leider nichts.
Vielleicht ist mein Ansatz ja Quatsch, die alte SUSDB zu übernehmen?!?
Kann ich den WSUS als Downstream-Server einrichten und er übernimmt vom "Master" den Katalog/Datenbank-Inhalt?
Ich dachte der holt sich "nur" die Update-Pakete und synct das Repository ...
LÖSUNG WSUS MIGRATION UMZIEHEN SUSDB SQL EXPRESS WID
Migrate Windows Server Update Services to Windows Server 2012
1. Binaries (Update-Verzeichnis) umziehen
Für's Server-Migration Tool hätte ich auf dem 2008er Quellserver Powershell von 2.0 auf 3.0 upgraden müssen, dann doch auf irgend einem 2008 R2 Server die Migrations-Verzeichnisse anlegen und auf den 2008er kopieren müssen etc. - riesen Aufriss und die c:\windows\system32\robocopy.exe tut's auch prima:
2. Datenbank umziehen
WSUS verwendet in der Regel eine Windows Internal Database an: SUSDB.mdf. Der Umzug in eine SQL Express Instanz, wie in den schnell ergoogelten Anleitungen beschrieben, sorgt dafür dass man remote auf die DB zugreifen kann. Sei es weil die WSUS-Rolle auf einen anderen Server zieht oder weil die DB auf einen anderen Server umzieht. In meinem Fall sollte beides umziehen. Um an die WID Instanz heranzukommen braucht man das SQL Mgmt Studio. Ich nehme hier 2008 R2 und connecte auf
Entgegen der vielen Anleitungen in denen es sich um SQL Express Instanzen dreht, muss ich bei meinem vollwertigen SQL Server nicht NT-Authorität\Netzwerk Dienste als Anmeldung hinzufügen, sondern das Computerkonto des neuen WSUS-Server:
3. WSUS-Rolle installieren
Auf dem neuen WSUS die Rolle hinzufügen und am Ende des Setups Datenbank (nicht WID) auswählen und den Namen des SQL-Servers angeben. Der Server Manager kommt danach mit einer Nachinstallations-Aufgabe an, in der die eigentliche Verbindung zum SQL-Server aufgebaut wird. Wenn's keine SUSDB gibt, legt er (Rechte vorausgesetzt) eine an. Ist eine vorhanden auf die er Zugriff hat, verwendet er diese auch (weiter).
4. GPOs, DNS, Downstream-Server
Wir haben einen CNAME im DNS: wsus.domain.local - der auf den richtigen WSUS verweist. In den GPOs für die WSUS-Client-Zuordnung stand teilweise noch explizit der alte WSUS-Servername drin. Das habe ich auch ebenso wie die Quell-Server-Option auf den Downstream-Servern auf wsus.domain.local angepasst. Beim nächsten Umzug muss man dann nur noch den CNAME umbiegen und alles passt.
Hoffe der MS-Link in Zusammenhang mit meiner persönlichen Beschreibung erspart euch einiges an Recherche und Herumprobieren. Die Namen und Pfade müssen natürlich auf eure Umgebung angepasst werden ...
Migrate Windows Server Update Services to Windows Server 2012
1. Binaries (Update-Verzeichnis) umziehen
Für's Server-Migration Tool hätte ich auf dem 2008er Quellserver Powershell von 2.0 auf 3.0 upgraden müssen, dann doch auf irgend einem 2008 R2 Server die Migrations-Verzeichnisse anlegen und auf den 2008er kopieren müssen etc. - riesen Aufriss und die c:\windows\system32\robocopy.exe tut's auch prima:
robocopy.exe "D:\WSUS\WsusContent" "\\zielserver\d$\WSUS\WsusContent" /E /COPY:DAT /DCOPY:T /MIR /V /FP /R:3 /W:3 /LOG:"D:\robocopy_WsusContent.log"2. Datenbank umziehen
WSUS verwendet in der Regel eine Windows Internal Database an: SUSDB.mdf. Der Umzug in eine SQL Express Instanz, wie in den schnell ergoogelten Anleitungen beschrieben, sorgt dafür dass man remote auf die DB zugreifen kann. Sei es weil die WSUS-Rolle auf einen anderen Server zieht oder weil die DB auf einen anderen Server umzieht. In meinem Fall sollte beides umziehen. Um an die WID Instanz heranzukommen braucht man das SQL Mgmt Studio. Ich nehme hier 2008 R2 und connecte auf
\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query - am besten mit dem Benutzer/Admin der hier die WSUS-Rolle installiert hat, der hat jedenfalls Zugriffsrechte. SUSDB sichern (Aufgaben / Sichern ...) und das <SUSDB>.bak-File auf den neuen Datenbank-Server kopieren. Dort im SQL Mgmt Studio eine neue Abfrage/Query öffnen:RESTORE DATABASE [SUSDB] FROM DISK = N'D:\Pfad-zur-SUSDB.bak' WITH FILE = 1, MOVE N'SUSDB' TO N'D:\Pfad-zum-DB-Ordner-des-SQL-Servers\SUSDB.mdf', MOVE N'SUSDB_log' TO N'E:\Pfad-zum-Log-Ordner-des-SQL-Server\SUSDB_log.ldf', NOUNLOAD, STATS = 10Entgegen der vielen Anleitungen in denen es sich um SQL Express Instanzen dreht, muss ich bei meinem vollwertigen SQL Server nicht NT-Authorität\Netzwerk Dienste als Anmeldung hinzufügen, sondern das Computerkonto des neuen WSUS-Server:
domain\servername$ Dieses Konto muss auch der SUSDB unter Benutzerzuordnung zugeordnet und der Datenbankrolle webService hinzugefügt werden.3. WSUS-Rolle installieren
Auf dem neuen WSUS die Rolle hinzufügen und am Ende des Setups Datenbank (nicht WID) auswählen und den Namen des SQL-Servers angeben. Der Server Manager kommt danach mit einer Nachinstallations-Aufgabe an, in der die eigentliche Verbindung zum SQL-Server aufgebaut wird. Wenn's keine SUSDB gibt, legt er (Rechte vorausgesetzt) eine an. Ist eine vorhanden auf die er Zugriff hat, verwendet er diese auch (weiter).
4. GPOs, DNS, Downstream-Server
Wir haben einen CNAME im DNS: wsus.domain.local - der auf den richtigen WSUS verweist. In den GPOs für die WSUS-Client-Zuordnung stand teilweise noch explizit der alte WSUS-Servername drin. Das habe ich auch ebenso wie die Quell-Server-Option auf den Downstream-Servern auf wsus.domain.local angepasst. Beim nächsten Umzug muss man dann nur noch den CNAME umbiegen und alles passt.
Hoffe der MS-Link in Zusammenhang mit meiner persönlichen Beschreibung erspart euch einiges an Recherche und Herumprobieren. Die Namen und Pfade müssen natürlich auf eure Umgebung angepasst werden ...
