Migrating WSUS from 3.0 SP2 to Server 2012 r2
Migrating Windows Server Update Services from Windows Server 2008 R2 (WSUS 3.0 SP2) to Windows Server 2012 R2. This guide is applicable to WSUS installations using the Windows Internal Database.
Install the WSUS role on the destination server and run through the Windows Server Update Services Configuration Wizard.
Backup Binaries and SUSDB from the WSUS Source Server
On the source 2008 R2 server, we need to backup the existing SUSDB. I don't want to go to the lengths of installing SQL Express Management Studio. Instead I'll rely on SQLCMD.
Prior to backing the WSUS Source Server, it's probably beneficial to run the WSUS Cleanup Wizard. Open the Windows Server Update Services snapin, select 'Options' from the left-hand pane and then choose 'Server Cleanup Wizard' from the right-hand pane. You can most probably leave all the default options selected and continue with the wizard. Be aware this may take some time, particularly if your original WSUS installation is quite old.
We need to stop the IISADMIN and any services which are dependent upon it. In my case, the WSUS server is also running the SMPT service. That means I will need to ensure the SMTP service is installed, configured and tested on an alternative member server with the appropriate DNS records in place. Once I've done this, I can remove the appropriate 'mail' DNS records, waitout the TTL on those records and then continue with the steps below.
On the source 2008 R2 server, open an administrative Command Prompt and stop IIS Admin/Windows Update Services
sc stop WSUSService sc stop SMTPSVC sc stop IISADMIN
Before we backup the WSUS Windows Internal Database (SUSDB), we can copy the WSUS binaries to an intermediate location, for example:
xcopy <WSUSPATH>\WsusContent <TempLocation>\WsusContent /E/I/Q/H/Y
Download and install Microsoft® ODBC Driver 11 for SQL Serer
Download and install Microsoft Command Line Utilities 11 for SQL Server
Detatch the WSUS Internal Database
sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query 1>use master 2>go 1>alter database SUSDB set single_user with rollback immediate 2>go 1>sp_detach_db SUSDB 2>go 1>exit
Copy <WSUSPath>\UpdateServicesDbFiles\SUSDB.mdf and <WSUSPath>\UpdateServicesDbFiles\SUSDB_log.ldf to new location accessible by both source and target WSUS servers. I'm testing the restore in a lab first thus I'm using Robocopy with /IPC:XX as not to saturate the VPN
mkdir <TempLocation>\UpdateServicesDbFiles robocopy <WSUSPath>\UpdateServicesDbFiles\ <TempLocation>\UpdateServicesDbFiles\. SUSDB* /Z /R:200 /W:180 /IPG:500
Precautionarly post-copy, compare the MD5 checksums of both files
fciv.exe <WSUSPath>\UpdateServicesDbFiles\SUSDB.mdf /MD5 fciv.exe <TempLocation>\UpdateServicesDbFiles\SUSDB.mdf /MD5 fciv.exe <WSUSPath>\UpdateServicesDbFiles\SUSDB_log.ldf /MD5 fciv.exe <TempLocation>\UpdateServicesDbFiles\SUSDB_log.ldf /MD5
The resultant MD5 checksum for each pair of files should be identical. It's possible too to do this with PowerShell, for example:
Get-FileHash -Path <WSUSPath>\UpdateServicesDbFiles\SUSDB.mdf -Algorthm MD5
If the MD5 checksums of both source and destination files match, continue.
On the source server, if appropriate, reattach the WSUS database
sqlcmd.exe -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query 1>use master 2>go 1>sp_attach_db @dbname = 'SUSDB', @filename1 = '<WSUSPath>UpdateServicesDbFiles\SUSDB.mdf', @filename2 = '<WSUSPath>UpdateServicesDbFiles\SUSDB_log.ldf' 2>go 1>exit
Restart the stopped services
sc start IISADMIN sc start SMTPSVC sc start WSUSService
And if appropriate, re-add the DNS 'A' and 'MX' records for the mail server.
Restore Binaries and SUSDB to the WSUS Target Server
On the target Windows Server 2012 R2 server, open an administrative Command Prompt and stop IIS Admin/Windows Update Services
sc stop WSUSService sc stop IISADMIN
Copy the WSUS binaries archived off from the source server to the target server:
xcopy <TempLocation>\WsusContent <WSUSPATH>\WsusContent /E/I/Q/H/Y
On the Windows Server 2012 R2 target, again as per the source server, install the ODBC Driver and Command Line Utilities for SQL Server
Connect to the WSUS Windows Internal Database:
sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query 1> use master 2> go Changed database context to 'master'. 1> alter database susdb set single_user with rollback immediate 2> go 1> drop database susdb 2> go 1> exit
Copy the WSUS database archived off from the source server to the target server:
xcopy <TempLocation>\UpdateServicesDbFiles\* <WSUSPATH>\UpdateServicesDbFiles /E/I/Q/H/Y
Give the NT Service\MSSQL$MICROSOFT##WID principal read/write access to the .mdb and .ldb files:
icacls C:\wsus\UpdateServicesDbFiles\* /grant:r "NT Service\MSSQL$MICROSOFT##WID":F /T processed file: C:\wsus\UpdateServicesDbFiles\SUSDB.mdf processed file: C:\wsus\UpdateServicesDbFiles\SUSDB_log.ldf Successfully processed 2 files; Failed processing 0 files
Attach the copied in WSUS database using SQLCMD
sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query 1>use master 2>go 1>sp_attach_db @dbname = 'SUSDB', @filename1 = '<WSUSPATH>\UpdateServicesDbFiles\SUSDB.mdf', @filename2 = '<WSUSPATH>\UpdateServicesDbFiles\SUSDB_log.ldf' 2>go 1>exit
Ignore any feedback advising schema verification failure. You should see the following output returned:
Msg 3605, Level 16, State 1, Server WIN2K12R2-DC1\MICROSOFT##WID, Line 1 Schema verification failed for database 'SUSDB'. Converting database 'SUSDB' from version 611 to the current version 706. Database 'SUSDB' running the upgrade step from version 611 to version 621. Database 'SUSDB' running the upgrade step from version 621 to version 622. Database 'SUSDB' running the upgrade step from version 622 to version 625. . . . Database 'SUSDB' running the upgrade step from version 705 to version 706.
Run WSUS Post Installation Tasks on the Target Server
Run the WSUS command line post-install:
"%programfiles%\Update Services\Tools\WsusUtil.exe" postinstall content_dir=<WSUSPATH>
"%programfiles%\Update Services\Tools\WsusUtil.exe" postinstall content_dir=d:\wsus
Almost there. Generate a new identity for the target WSUS installation. Open a PowerShell session and run the following script:
$updateServer = get-wsusserver $config = $updateServer.GetConfiguration() $config.ServerId = [System.Guid]::NewGuid() $config.Save()
And finally, run the post install one last time to regenerate the WSUS Encryption Keys:
"%programfiles%\Update Services\Tools\WsusUtil.exe" postinstall
- It's well worth trying the migration in a lab environment first so that you become familiar with the process.
- If anything goes wrong during this migration, you can just start again from scratch. The migration does modify the source WSUS server.
- Before decomissioning your source WSUS server, test the new server with a select group of clients. Use the "Specify intranet Microsoft update service location" GPO.