Background

Migrating Windows Server Update Services from Windows Server 2008 R2 (WSUS 3.0 SP2) to Windows Server 2012 R2 (WSUS 4.0). This guide is applicable to WSUS installations using the Windows Internal Database.

Pre-requisite Steps

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 http://www.microsoft.com/en-us/download/details.aspx?id=36433

Download and install Microsoft Command Line Utilities 11 for SQL Server http://www.microsoft.com/en-us/download/details.aspx?id=36434

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>

e.g.

"%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

Further Considerations

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