Export (0) Print
Expand All

Migrating WSUS

Published: February 11, 2010

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

Task Description

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

Use your preferred method (Windows Server Migration Tools, Robocopy, or Xcopy, for example) to move WSUS update binaries from the source server to the destination server.

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

Migrate local users and groups manually or by using Windows Server Migration Tools.

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

Use SQL Server Management Studio to back up and restore the WSUS database, computer groups, update approvals, and WSUS settings.

Change the WSUS server identity

The WSUS server identity on the destination server must be changed. Performing this step will make sure that there is no effect on WSUS-managed clients during the migration process.

Apply security settings to the destination server

Configure security settings on the new server. This includes configuring any security settings that you were using on 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.

ImportantImportant
Migrating WSUS update binaries is unnecessary if update files are stored on Microsoft Update.

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.

  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.

noteNote
Before you perform the procedure that is described here, verify that the destination server can resolve the names of domain users who are members of the local group during the import operation. If the source and destination servers are in different domains, the destination server must be able to contact a global catalog server for the forest in which the source domain user accounts are located.

If the source server is a domain member server, and the destination server is a domain controller: Imported local users are elevated to domain users, and imported local groups become Domain Local groups on the destination server.

If the source server is a domain controller, and the destination server is not: Domain Local groups are migrated as local groups, and domain users are migrated as local users.

  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
    
    noteNote
    You are prompted to provide a password to encrypt the migration store. Remember this password, because you must provide the same password to import data from the migration store on the destination server.

    If the path is not a shared location to which the destination server has access, you must copy the migration store to the destination server manually, or to a location that this destination server can access as it runs the Import-SmigServerSetting cmdlet.

  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
    
    noteNote
    After you enter the Import-SmigServerSetting cmdlet, you are prompted to provide the same password to decrypt the migration store that you created during the export process.

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:

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

ImportantImportant
SQL Server Management Studio must be run with elevated administrator permissions throughout this guide.

To run SQL Server Management Studio with elevated administrator permissions in Windows Server 2008 and Windows Server 2008 R2, click Start, point to All Programs, point to SQL Server 2005 or SQL Server 2008, right-click SQL Server Management Studio, and then click Run As Administrator.

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

    noteNote
    If the source server is using Windows Internal Database, the database name is \\.\pipe\mssql$microsoft##ssee\sql\query

  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.

    ImportantImportant
    During the restore process, the destination server must be able to connect to the backup destination.

  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.

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

    noteNote
    If the source server is using Windows Internal Database, the database name is \\.\pipe\mssql$microsoft##ssee\sql\query

  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)

      noteNote
      Choose this option only if you are restoring all the necessary backups now.

  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
    
noteNote
When a database is restored to a different server, it contains a set of users and permissions, although there may be no corresponding logins, or the logins may not be associated with the same users. This condition is known as having "orphaned users." See Microsoft Support article Troubleshooting Orphaned Users Topic in Books Online for instructions on resolving orphaned users.

After you restore a SQL Server 2005 database to SQL Server 2008, the database becomes available immediately and is then automatically upgraded.

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.

  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
    
noteNote
Keep this Windows PowerShell session open because it will be used in the following section, Apply security settings to the destination server.

In the Post-migration Tasks for WSUS section, you will perform the steps to Point the WSUS clients to the new WSUS 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.



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

      ImportantImportant
      For security reasons, you should export only the public key, not the private key.

      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:

    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.

    ImportantImportant
    Follow the steps in Configure the Firewall Between the WSUS Server and the Internet to configure your firewall only if the destination server is going through a different firewall than the source server.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft