Migrating WSUS

Updated: July 19, 2011

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Essentials

The Windows Server Update Services (WSUS) 3.0 SP2 migration phase involves several steps. The following table summarizes the tasks required to complete the migration phase. These procedures apply to all supported source and destination server operating systems. See Supported operating systems section for more information.

Summary of migration tasks

Migrate WSUS update binaries from the source server to the destination server

Use your preferred method (Windows Server Migration Tools, Windows Explorer, Xcopy, or Robocopy, for example) to copy WSUS update binaries in the WSUS folder from the source server to the destination server. If you decide to use Windows Server Migration Tools to migrate WSUS update binaries to a destination server that is running Windows Server 2008 R2, see Appendix B: Migrate WSUS Update Binaries from the Source Server to the Destination Server Using Windows Server Migration Tools.

Migrate WSUS server local security groups from the source server to the destination server

You have the option of manually migrating only the WSUS Administrators and WSUS Reporters local security groups. Or, you can use Windows Server Migration Tools to migrate all local users and groups (including the WSUS Administrators and WSUS Reporters local security groups) from the source server to the destination server.

To manually migrate local users and groups, use the Local Users and Groups Microsoft Management Console (MMC) snap-in.

To manually migrate local users and groups

1. Click Start, click Run, type lusrmgr.msc in the Open box, and then click OK, or press ENTER.

2. In the Local Users and Groups MMC snap-in, in the console tree, double-click Users.

3. Manually create the local users that you collected in the Worksheet, if they do not already exist.

4. In the Local Users and Groups MMC snap-in, in the console tree, double-click Groups.

5. Manually add the users that you collected in the Worksheet from the source server to the WSUS Administrators and WSUS Reporters groups.

Or, you can migrate local users and groups by using Windows Server Migration Tools. You can use Windows Server Migration Tools to migrate all local users and groups. This includes the WSUS Administrators and WSUS Reporters groups, from the source server to a destination server that is running Windows Server 2008 R2 in the same subnet.

For more information about local user and group migration, see the Local User and Group Migration Guide.

To migrate local users and groups by using Windows Server Migration Tools

1. Open a Windows PowerShell session on both the source and destination servers.

   • On computers that are running Windows Server 2003, open a Windows PowerShell session, click Start, point to Administrative Tools, open the Windows Server Migration Tools folder, and then click Windows Server Migration Tools.

   • On computers that are running Windows Server 2008 or Windows Server 2008 R2, open a Windows Server Migration Tools custom Windows PowerShell session, click Start, point to Administrative Tools, open the Windows Server Migration Tools folder, right-click Windows Server Migration Tools, and then click Run as administrator.

2. Export local users and groups. In the Windows PowerShell session on the source server, export local users and groups to a migration store. Type the following command, and then press Enter, in which MigrationStorePath represents the path of the location where you want to store migrated data.

   Use one of the following values with the -User parameter:

   • Enabled   Export only enabled local users

   • Disabled   Export only disabled local users

   • All   Export both enabled and disabled local users

   Export-SmigServerSetting -User <Enabled | Disabled | All> -Group -Path <MigrationStorePath> -Verbose
   

3. Import local users and groups. In the Windows PowerShell session on the destination server, import local users and groups from the migration store that you created in step 2. Type the following command, and then press Enter, in which MigrationStorePath represents the path of the location from which you want to import migrated data.

   Use one of the following values with the -User parameter:

   • Enabled   Import only enabled local users

   • Disabled   Import only disabled local users

   • All   Import both enabled and disabled local users

   Import-SmigServerSetting -User <Enabled | Disabled | All> -Group -Path <MigrationStorePath> -Verbose
   

Backup WSUS database on the source server and restore it to the destination server

WSUS servers can be configured to use Windows® Internal Database, the database software that is included with WSUS, or the full version of SQL Server. Regardless of which database option the source server is running, perform the following procedures to back up the WSUS database on the source server and restore the database to the destination server.

For an overview of backup and command-line syntax, see the following articles on SQL Server TechCenter:

• Backup Overview.

• BACKUP (Transact-SQL).

For an overview of restore and command-line syntax, see the following articles on SQL Server TechCenter:

• Restore and Recovery Overview.

• RESTORE (Transact-SQL).

To back up the WSUS database on the source server by using SQL Server Management Studio

1. After you connect to the appropriate instance of the database in Object Explorer, click the server name to expand the server tree.

2. Expand Databases, and select the SUSDB database.

3. Right-click the database, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

4. In the Database list, verify the database name.

5. In the Backup type list, select Full.

6. Select Copy Only Backup to create a copy-only backup. A copy-only backup is a SQL Server backup that is independent of the sequence of conventional SQL Server backups.

7. For Backup component, click Database.

8. Either accept the default backup set name suggested in the Name text box, or enter a different name for the backup set.

9. Optionally, in the Description text box, enter a description of the backup set.

10. Specify when the backup set will expire and can be overwritten without explicitly skipping verification of the expiration data:

    • To have the backup set expire after a specific number of days, click After (the default option), and enter the number of days after set creation that the set will expire. This value can be from 0 to 99999 days; a value of 0 days means that the backup set will never expire.
      The default value is set in the Default backup media retention (in days) option of the Server Properties dialog box (Database Settings Page). To access this, right-click the server name in Object Explorer and select properties. Then, select the Database Settings page.

    • To have the backup set expire on a specific date, click On, and enter the date on which the set will expire.

11. Choose the backup destination by clicking Disk.

    To remove a backup destination, select it and then click Remove. To view the contents of a backup destination, select it and then click Contents.

12. To view or select the advanced options, click Options in the Select a page pane.

13. Select an Overwrite Media option, by clicking one of the following:

    • Back up to the existing media set For this option, click either Append to the existing backup set or Overwrite all existing backup sets. Optionally, select Check media set name and backup set expiration to cause the backup operation to verify the date and time at which the media set and backup set expire. Optionally, enter a name in the Media set name text box. If no name is specified, a media set with a blank name is created. If you specify a media set name, the media (tape or disk) is checked to see whether the actual name matches the name that you enter here.

    • Back up to a new media set, and erase all existing backup sets For this option, enter a name in the New media set name text box, and, optionally, describe the media set in the New media set description text box.

14. In the Reliability section, optionally check:

    • Verify backup when finished.

    • Perform checksum before writing to media, and, optionally, Continue on checksum error.

15. SQL Server 2008 Enterprise and later versions support backup compression. By default, whether a backup is compressed depends on the value of the backup-compression default server configuration option. However, regardless of the current server-level default, you can compress a backup by checking Compress backup, and you can prevent compression by checking Do not compress backup.

To restore the WSUS database backup on the destination server by using SQL Server Management Studio

1. After you connect to the appropriate instance of the database in Object Explorer, click the server name to expand the server tree.

2. Click New Query and type the following SQL command to drop the WSUS database (SUSDB):

   USE master
   GO
   ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   GO
   DROP DATABASE SUSDB
   GO
   

3. Click Execute to run the query.

4. Right-click Databases, and then click Restore Database to open the Restore Database dialog box.

5. On the General page, enter the name of the restoring database (SUSDB) in the To database list.

6. To specify the source and location of the backup sets to restore, click one of the following options:

   • From database Enter a database name in the list.

   • From device Click the browse button to open the Specify Backup dialog box. In the Backup media list, select one of the listed device types. To select one or more devices for the Backup location list, click Add. After you add the devices that you want to the Backup location list, click OK to return to the General page.

7. In the Select the backup sets to restore grid, select the backups to restore. This grid displays the backups available for the specified location. By default, a recovery plan is suggested. To override the suggested recovery plan, you can change the selections in the grid. Any backups that depend on a deselected backup are deselected automatically.

8. To view or select the advanced options, click Options in the Select a page pane.

9. You can restore the database to a new location by specifying a new restore destination for each file in the Restore the database files as grid.

10. The Recovery state panel determines the state of the database after the restore operation. The default behavior is as follows:

    • Leave the database ready to use by rolling back the uncommitted transactions. Additional transaction logs cannot be restored. (RESTORE WITH RECOVERY)

11. If you are migrating to a Windows Internal Database: verify that you are connected to the appropriate instance of the database and run the following script after the database is restored:

    %ProgramFiles%\Update Services\Database\WSUSSignDb.sql
    

Change the WSUS server identity

The WSUS server identity on the destination server must be changed. Performing this step guarantees that WSUS-managed clients are not affected during the migration process. If both source and destination servers run with the same identity and any change is made to one of the servers, then client/server communications will fail.

To change the WSUS server identity

1. Open a Windows PowerShell session with elevated user rights on the destination server:

2. To do this, click Start, click All Programs, click Accessories, click Windows PowerShell, right-click Windows PowerShell, and then click Run as administrator.

3. In the Windows PowerShell session on the destination server, run the following script to change the server identity of the destination server:

   [Reflection.Assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
   $updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
   $config = $updateServer.GetConfiguration()
   $config.ServerId = [System.Guid]::NewGuid()
   $config.Save()
   

4. As soon as the server identity is changed, run StartServer.exe (located in %ProgramFiles%\Update Service\Setup\) to create a new encryption key:

   .\StartServer.exe /Installmode=1
   

In the Post-migration Tasks for WSUS section, you will perform the steps to Point the WSUS clients to the new WSUS server.

Apply security settings to the destination server

Refer to the settings that you recorded on Appendix A: Migration Data Collection Worksheet.

Complete the following tasks to apply any security settings that you were using on the source server to the destination server.

• SMTP server settings

  If you are using an authenticating proxy, the e-mail notification feature to an SMTP server that requires a password, or both, you have to manually configure proxy and e-mail notification to the SMTP server and enter the password on the new destination server.

  Enter the SMTP password if you are using e-mail notification.

• Code signing certificate

  Copy the code signing certificate if you are using an advanced management tool that exposes local update publishing, such as Microsoft® System Center Essentials 2007 or Microsoft System Center Configuration Manager 2007.

  The following steps must be performed in order to initialize a trust relationship between the update server and its clients.

  To set up the update server for locally-published content

  1. Export the public key for the certificate into a .cer file:

    1.  Click **Start**, then **Run**, and type **mmc**.  
          
    2.  In Microsoft Management Console (MMC), click **File**, click **Add/Remove Snap-in**, and then select **Add**.  
          
    3.  Add the **Certificates** snap-in, and set it to manage certificates for the local computer account.  
          
    4.  Browse to the **WSUS** node in the snap-in, and then find the certificate that you added in step 1.  
          
    5.  Right-click the certificate and select **All Tasks**, then **Export**.  
          

2.  To install a self-signed certificate, use the Windows PowerShell session opened in the previous section, Change the WSUS server identity:
    
    1.  Call `SetSigningCertificate` and use the `IUpdateServerConfiguration.SetSigningCertificate Method (String, String)` overload to install the existing certificate exported in step1.  
          
    2.  Call `IUpdateServerConfiguration.Save Method ()` to add this information to the configuration.  
          
    
    For example:
    
        $config.SetSigningCertificate("<Path to pfxFile>", "<PFX file password>")
        $config.Save()
    
    For more information about these methods, see the following on MSDN:
    
      - [IUpdateServerConfiguration.SetSigningCertificate Method (String, String)](https://go.microsoft.com/fwlink/?linkid=163415)  
          
      - [IUpdateServerConfiguration.Save Method ()](https://go.microsoft.com/fwlink/?linkid=163420)  
          

3.  Configure your destination server to trust this certificate by installing the public key for this certificate in your trusted publisher store.
    
    1.  In the **Certificates** snap-in, select **Trusted Root Certification Authorities**, then right-click **Certificates**, select **All Tasks**, then **Import**, and import the certificate that you just exported.  
          
    2.  Select **Trusted Publishers**, then right-click **Certificates**, select **All Tasks**, then **Import**, and import the certificate.  
          

• Firewall settings

  If there is a corporate firewall between the WSUS server and the WSUS clients or the Internet, enter the firewall configuration settings or configure your firewall to let WSUS obtain updates and allow clients to access the WSUS server. For more information, see Windows Firewall.

See Also

Concepts

Windows Server Update Services 3.0 SP2 Migration Guide
Preparing to Migrate WSUS
Verifying the WSUS Migration
Post-migration Tasks for WSUS
Appendix A: Migration Data Collection Worksheet
Appendix B: Migrate WSUS Update Binaries from the Source Server to the Destination Server Using Windows Server Migration Tools