Move or migrate WSUS to a new server

Move or migrate WSUS to a new server

    (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

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

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

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

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

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

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

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

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

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

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

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

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

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