Move or migrate WSUS to a new server
Move or migrate WSUS to a new server
from Philip Lorenz (https://4sysops.com/archives/migrate-windows-server-update-services-wsus-to-a-new-server/)
Since
Windows Server Update Services (WSUS) is an important part of the IT
infrastructure it should run on a current operating system. The end of
support for a version of Windows Server, as recently as 2008 R2, is a
compelling reason for a migration. This guide shows how to move WSUS to a
new machine.
Contents of this article
- Migration steps
- Migrate the update binaries (optional)
- Move the security groups
- Back up and restore the WSUS database
- Final steps
The
migration process assumes, of course, that there is a functioning
source server that contains the current WSUS data to be migrated. The
target server should be ready and have the WSUS role installed. After
the WSUS installation, however, you should skip the initial
configuration.
The best practice is to stop the WSUS service on the source server before migrating. This can be done using the MMC tool for Services; alternatively, a short PowerShell command will do the job:
| 1 | Stop-Service WSUS-Service |
One
last requirement is that port 7000 UDP/TCP must be open on both
computers, since the Windows server migration tools we will use in the
following section will require it.
Migration steps ^
Moving WSUS to another server comprises the following steps:
- Migration of the update files (optional)
- Migration of security groups
- Backup and restore of the WSUS database
- Final steps
Migrate the update binaries (optional) ^
In
many companies, the management of existing update files is rather
neglected. A WSUS server runs on average for several years until the
next migration. Therefore, you should consider whether you want to keep
all the legacy updates or whether you prefer to download the required
updates again.
In
the event that updates have been maintained on the source server or the
effort for a re-evaluation seems too extensive, you can transfer the
update files using the Windows Server Migration Tools (WSMT) (copying
via robocopy is also possible).
The first step is to install the
WSMT via the Windows Server Manager on the target server, where it can
be found in the wizard for adding roles under Features.
Adding Windows Server Migration Tools to the target server via the wizard in the Server Manager
After
the installation, the target server provisions the WSMT on the source
server. This ensures that both servers have the same version. To do
this, open a prompt with elevated rights on the target server. Change to
the WSMT directory, and enter the following commands:
|
1 2 |
cd %Windir%System32ServerMigrationTools SmigDeploy.exe /package /architecture amd64 /os WS12R2 /path C:WSMT |
The
OS parameter must match the operating system of the source server. The
files are now located in the following folder: C:WSMT. Copy this
directory to the source server.
Preparing Windows Server Migration Tools for deployment on the source server
On the command line of the source server, change to the WSMT directory and open the tool by starting Smigdeploy.exe (note: .NET 3.5 is required on the source server).
Using Windows Search, start the Windows Server Migration Tools on the source server and execute this command:
| 1 | Send-SmigServerData -ComputerName 10.0.1.4 -SourcePath C:Updates -DestinationPath C:Updates -Include All -Force -Recurse |
The IP address or the hostname for the ComputerName and the directory for updates must, of course, be adapted to your environment. Once this is done, assign a password.
Start transferring the data from the source server
The source server is now ready for migration and is waiting for the signal from the remote machine.
The source server is waiting for the command from the destination server to start the transfer
On the target server, you now start WSMT and enter the following command:
| 1 | Receive-SmigServerData |
After entering the password, the migration will start.
The update folder on the target server will now be filled with the updates
Move the security groups ^
The
WSMT can also synchronize the security groups. To do this, switch to
the source server, open the WSMT shell, and execute the following
command:
| 1 | Export-SmigServerSetting -User Enabled -Group -Path \10.0.1.4C$WSMTSecGroups |
The
IP or hostname should, of course, be adjusted again. The destination
directory must also already exist on the target server. Here, the tool
again requests a password, which is needed for receiving.
Export of the security groups with the WSMT
On the target server, the data is also fetched via the WSMT shell using the following command:
| 1 | Import-SmigServerSetting -User Enabled -Group -Path \\10.0.1.4\C$\WSMT\SecGroups -Verbose |
Back up and restore the WSUS database ^
WSUS
can use either the internal Windows database (WID) or a SQL Server, the
former being the most common. If you are not sure which one you have
configured for WSUS, you can find out in the registry. The entry
| 1 | ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftUpdate ServicesServerSetupSqlServerName |
contains
the value MICROSOFT##WID or the name of the SQL database. With the
latter, we don’t have to do anything else because the new WSUS simply
accesses the same database again.
For the migration of an internal
WSUS-DB, a backup-restore procedure with the SQL Server Management
Studio (SSMS) has proven to be best practice. This software is available
here from Microsoft.
After installing it on both machines, switch to the source server and open the tool. In the Connect to Server dialog box, enter the Server name:
\.pipeMICROSOFT##WIDtsqlquery
Connect to the internal Windows database in SQL Server Management Studio
After the connection has been successfully established, SUSDB is located under Databases. There, select Tasks > Backup from the context menu.
You
don’t have to adjust anything in the backup wizard; only the path under
which we want to save the backup on the disk has to be specified.
Saving SUSDB to a file on the source server using SSMS
The
speed of the backup depends on the size of the database. You now copy
the saved file to the target server, where you connect to the SUSDB
using SSMS.
The existing SUSDB must first be deleted here. You can do this with the following query (right click on SUSDB and then New Query):
|
1 2 3 4 5 |
USE master GO ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO DROP DATABASE SUSDB |
Deleting SUSDB on the target server via SQL script
You can then import the backup of the source server with the following query:
|
1 2 3 4 5 6 |
RESTORE DATABASE [SUSDB] FROM DISK = N’C:wsusbackup’ WITH FILE = 1, MOVE N’SUSDB’ TO N’c:WindowsWIDDatasusdb.mdf’, MOVE N’SUSDB_log’ TO N’c:WindowsWIDDataSUSDB_log.ldf’, NOUNLOAD, STATS = 10 |
The path on the first line must of course be adjusted to your needs.
Restore WSUS database to the target server using SSMS
This completes the migration of the database.
Final steps ^
Finally,
post-installation should be carried out. The easiest way to do this is
in PowerShell with admin rights executing the following commands:
|
1 2 |
cd “C:Program FilesUpdate ServicesTools” .WsusUtil.exe postinstall |
Performing post installation on the target server
To
avoid problems later, you should adjust the ServerID of the new WSUS.
This can also be done with PowerShell by accessing the WSUS
configuration directly and generating a new GUID:
|
1 2 3 |
$conf = (get-wsusserver).getConfiguration() $conf.ServerID = [System.Guid]::NewGuid() $conf.Save() |
Change the ServerID for the new WSUS server
If
the new WSUS server has a new hostname or IP, depending on your
environment, you may also need to update this information on the clients
so that they can get their updates from the new WSUS. There is usually a
GPO for this, which has to be adapted.
Link
