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.

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:

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:

cd %Windir%\System32\ServerMigrationTools\
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:

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:

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:

Export-SmigServerSetting -User Enabled -Group -Path \\10.0.1.4\C$\WSMT\SecGroups

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:

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

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\SqlServerName

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:

\\.\pipe\MICROSOFT##WID\tsql\query

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):

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:

RESTORE DATABASE [SUSDB] FROM DISK = N'C:\wsusbackup' 
WITH FILE = 1, MOVE N'SUSDB' 
TO N'c:\Windows\WID\Data\susdb.mdf', 
MOVE N'SUSDB_log' 
TO N'c:\Windows\WID\Data\SUSDB_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:

cd "C:\Program Files\Update Services\Tools"
.\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:

$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.

+1
avatar
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account