Move or migrate WSUS to a new server
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
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
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:
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) ^
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
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.
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:
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.
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:
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.
The source server is now ready for migration and is waiting for the signal from the remote machine.
On the target server, you now start WSMT and enter the following command:
After entering the password, the migration will start.
Move the security groups ^
WSMT can also synchronize the security groups. To do this, switch to
the source server, open the WSMT shell, and execute the following
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.
On the target server, the data is also fetched via the WSMT shell using the following command:
Back up and restore the WSUS database ^
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
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:
After the connection has been successfully established, SUSDB is located under Databases. There, select Tasks > Backup from the context menu.
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.
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
The existing SUSDB must first be deleted here. You can do this with the following query (right click on SUSDB and then New Query):
You can then import the backup of the source server with the following query:
The path on the first line must of course be adjusted to your needs.
This completes the migration of the database.
Final steps ^
post-installation should be carried out. The easiest way to do this is
in PowerShell with admin rights executing the following commands:
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:
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.