I’ve spent the last day or so decommissioning my old domain controller, which also doubled up as a DNS, WINS, DHCP, print, RIS, anti-virus and WSUS server (okay… so a bit more than doubled up then!). Migrating Active Directory/DNS/WINS services was straightforward – it just involved setting up the new server, replicating the data, updating client settings (via DHCP) then removing the old services. DHCP was similarly straightforward (I’ve blogged before about migrating DHCP databases between servers) and RIS just needed to be installed on the new server, the images copied across, and the remote installation services setup wizard run. I recreated my single print queue manually but I could just as well have used the Microsoft Windows Server 2003 Print Migrator. That left just left my anti-virus management console (reinstall the console and reconfigure the clients) and WSUS.

I could just have installed WSUS, resynchronised with Microsoft Update and approved the necessary updates; however that would have involved downloading more than 10GB of updates (which could have taken my bandwidth usage for the month to a level that would result in my Internet connection being throttled under my ISP’s sustainable usage policy).

One potential WSUS migration option would have been to backup and restore the WSUS configuration but I wasn’t convinced about how that would work in a migration scenario involving a change of servername. Then I found a blog post from Nathan Winters about migrating WSUS between servers which helped me to import the content without going out to the Internet and downloading it again. Nathan suggests that the approvals database gets imported too, but that’s not the case – the wsusutil import command only imports the update metadata (not the file, approvals, or server settings). Similarly wsusutil migratesus migrates approvals from a SUS server (not WSUS) and wsusutil movecontent is for moving the content within the local file system. More details on managing WSUS from the command line can be found in the Microsoft Windows Server TechCenter.

By chance, I’d installed my new WSUS server as a replica of the original one so I could synchronise with the old server as my upstream source, leaving the new server with the content (from a a manual file copy followed by a metadata import) and the approvals information (from the synchronisation with the old server). All that remained was to finalise the server settings (synchronisation options etc.) and update group policy so that my clients went to the new server.

I hit a problem when I found that WSUS 2.0 doesn’t allow replica servers to be converted to standalone mode (that’s expected when WSUS 3.0 is released later this year), effectively preventing me from repointing WSUS to download updates from Microsoft Update. Luckily, Mohammed Athif Khaleel’s PatchAholic blog features a post on changing the mode of a WSUS server and a follow-up comment from SpJam includes a script to switch a server from replica to standalone mode (modified here to reflect subsequent comments):

rem Restore values after exec spEnableReplica stored procedure
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB UPDATE dbo.tbConfigurationA SET SyncToMU = ‘1′ UPDATE dbo.tbConfigurationB SET AutoRefreshDeployments = ‘1′ UPDATE dbo.tbConfigurationC SET ReplicaMode = ‘0′ UPDATE dbo.tbConfigurationC SET AutoDeployMandatory = ‘1′ UPDATE dbo.tbAutoDeploymentRule SET Enabled = ‘0′”

rem Add removed values in tables
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbTargetGroupInAutoDeploymentRule(AutoDeploymentRuleID, TargetGroupID) values (1, ‘A0A08746-4DBE-4a37-9ADF-9E7652C0B421′)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbTargetGroupInAutoDeploymentRule(AutoDeploymentRuleID, TargetGroupID) values (2, ‘A0A08746-4DBE-4a37-9ADF-9E7652C0B421′)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (1, 1)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (1, 5)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (2, 1)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (2, 5)”

It looked as if the script worked as advertised (except that automatic approval options were still not available) until I started to encounter the following error message when running reports or attempting to view update information:

Windows Server Update Services error

Error connecting to the Windows Server Update Services database
There was an error connecting to the Windows Server Update Services database. Either the database is not available or you do not have the correct privileges to access the database.

If you believe you have received this message in error, please check with your system administrator.

Click here to reload the site: Windows Server Update Services

Thinking that I had corrupted the database and that I might need to go back and start the WSUS migration from scratch, I decided to restart the server “just in case”. After the restart, everything seemed to be working (including the previously-missing automatic approval options). I’ve since approved some more updates and run various reports and (so far) there have been no problems administering WSUS.

The final step was to edit the group policy that I use to control automatic update options on my clients – a minor edit to change the server which clients should contact for updates.

So, to summarise, my WSUS migration process was:

1. Install BITS 2.0 (a fully-patched Windows Server 2003 server should already have this).
2. Install WSUS (in replica mode) and WMSDE.
3. Export the update metadata on the old server using %programfiles%\Update Services\Tools\wsusutil export filename.cab logfilename.txt.
4. Copy filename.cab (created above) and the contents of the WsusContent folder to the new server (e.g. using an external disk to network connectivity issues).
5. Import the update metadata using %programfiles%\Update Services\Tools\wsusutil import filename.cab logfilename.txt (note that this takes a long time – it was just over three hours in my case).
6. Synchronise WSUS with an upstream server.
7. Save the script above as filename.cmd and execute it from the command line. The output will detail each command followed by the number of affected rows in the database.
8. Reboot the server.
9. Configure server settings (e.g. set Microsoft Update as the update source) and administer WSUS as normal.

I’d be interested to hear if anyone has any variations on this approach – for example, I don’t really recommend installing WSUS in replica mode and then hacking the database (and this wouldn’t be an option if there was any network segregation in place). Indeed, since I completed the exercise I found reference to a tool called WSUSMigrate which is part of the WSUS API samples and tools and can be used to migrate the approvals data – that looks like a much better approach.