- Secure domain controllers with LDAP channel binding and LDAP signing - Tue, Jul 13 2021
- Use case for action cards: Send low storage space alert to Microsoft Teams and start WAC to fix the problem - Mon, Jun 21 2021
- Move or migrate WSUS to a new server - Wed, Dec 16 2020
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
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
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
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:
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:
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
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
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):
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:
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
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
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
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.
