Migrate the Windows Server Update Services version you use with Configuration Manager
Updated: September 12, 2016
Applies To: System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager SP1
When you change the server operating system on a software update point (SUP), we recommend that you migrate your existing Windows Server update Services (WSUS) infrastructure to minimize the effect on your clients and network. This topic explains the steps required to perform the migration, which depend on your environment and configuration.
Important
There are client and network performance costs that are associated with switching to a new software update point or upgrading the version of WSUS you use. When a client switches to a new SUP and then scans for software updates, the result is an increase in the catalog size and associated client-side and network performance demands.
When you use System Center Updates Publisher 2011
When you use System Center Updates Publisher (SCUP) 2011 with Configuration Manager, you must complete the steps in the following sections before you migrate WSUS to a new version.
Scenario 1: SCUP is installed on the software update point
Before migrating WSUS, complete the following three steps on the server that hosts the software update point (SUP):
Step 1 - Back up the SCUP database
Browse to the Updates Publisher 2011 database file (Scupdb.sdf) in %USERPROFILE%\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.000, and then copy the database file to a backup destination.
Note
There is a different database file for each user that runs Updates Publisher 2011.
When there is more than one database file on a computer, consider storing the file in a subfolder that indicates the user profile in which the database file is associated. For example, you could have one database file in E:\ConfigMgr_Backup\SCUP2011\User1 and another database file in E:\ConfigMgr_Backup\SCUP2011\User2
Step 2 - Back up the WSUS certificate used to sign custom updates
Use the following procedure to export the WSUS certificate:
On the WSUS server, open the Certificates snap-in for the computer account on the local computer.
In the console tree under the WSUS store, click Certificates
In the details pane, click the WSUS certificate that is used to sign custom updates.
On the Action menu, point to All Tasks, and then click Export.
In the Certificate Export Wizard, click Yes, export the private key.
On the Export File Format page, select the defaults.
In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.
In File name, type a file name and path for the PKCS #7 file that will store the exported certificate and private key. Click Next, and then click Finish.
Step 3 - Back up the local source publishing folder (optional)
Use the following procedure to back up the local source publishing folder, if the (advanced) option is enabled.
On the software update point server that runs Updates Publisher, browse to the local source publishing folder. The default location is %USERPROFILE%\Documents\LocalSourcePublishing. If you selected the option to Use a custom local source path, browse to the location that you defined.
Copy the local source publishing folder to your backup destination.
After migrating WSUS, complete the following three steps on the new software update point:
Step 1 - Restore the SCUP database
Use the following procedure to restore the Updates Publisher 2011 database:
Install Updates Publisher 2011 on the new software update point.
Copy the database file (Scupdb.sdf) from your backup destination to the following location on the new software update point: %USERPROFILE%\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.0000.
Copy the database files for each additional user that ran Updates Publisher 2011 on the original software update point to the new software update point if they will continue to use Updates Publisher. Each database file must be copied to the correct user profile location.
Step 2 - Restore the SCUP database
Restore the WSUS certificate used to sign custom updates Use the following procedure to restore the WSUS signing certificate:
On the WSUS server, open the Certificates snap-in for the computer account on the local computer.
In the console tree under the WSUS store, click Certificates.
On the Action menu, point to All Tasks, and then click Import to start the Certificate Import Wizard.
Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.). Click Next.
Type the password used to encrypt the private key, and then click Next.
Select Place all certificates in the following store, and make sure the WSUS certificate store is listed.
Click Next, and then click Finish.
Use the following procedure to copy the WSUS signing certificate to the Trusted Publishers store and the Trusted Root Certification Authorities store (optional):
On the WSUS server, open the Certificates snap-in for the computer account on the local computer.
In the console tree under the WSUS store, click Certificates.
Right click the WSUS certificate that was just imported, then select Copy.
In the console tree under the Trusted Publishers store, click Certificates. Right click and select Paste.
If you’re using a self-signed certificate, also copy the WSUS certificate to the Trusted Root Certification Authorities store.
Step 3 - Restore the local source publishing folder (optional)
Do the following to restore the local source publishing folder, if that the (advanced) option is enabled:
Copy the local source publishing folder contents from your backup destination to the default location: %USERPROFILE%\Documents\LocalSourcePublishing.
If you selected the option to Use a custom local source path, create that custom source path and restore the contents.
Scenario 2: SCUP is installed on an operating system that doesn't support publishing to the new version of WSUS
The WSUS local publishing APIs enforce a version match between the caller and remote WSUS server. For the required steps, see the following:
Migrate to a new version of Windows Server Update Services
The information in the following sections will help you successfully migrate the WSUS version for your software update points. If you use SCUP 2011 with Configuration Manager, use the information from When you use System Center Updates Publisher 2011 before you begin.
Scenario 1: Stand-alone primary site with local or remote SUP
Create a new remote software update point site system role
Setup a new remote WSUS server following the steps from Migrate Windows Server Update Services in the Windows Server documentation. Repeat this step for each additional SUP that you need to update with a new version of WSUS.
Migration step 3.1. Migrate WSUS update binaries is only required if you install the Configuration Manager client by using software update points or when you integrate System Center Updates Publisher (SCUP) with your Configuration Manager infrastructure.
Migration steps 3.3 Back up the WSUS database and 3.4 Change the WSUS server identity are the only required steps for Configuration Manager.
See Prepare for your WSUS Deployment for more information about the minimum requirements for the WSUS server role. Also, review Plan for WSUS Installation for additional permissions required for WSUS 4.0 and greater.
In the Configuration Manager console, navigate to Administration > Site Configuration > Servers and Site System Roles.
On the Home tab, in the Create group, click Create Site System Server.
On the General page, specify the general settings for the site system, and then click Next.
On the Proxy page, specify settings for a proxy server if site system roles that run on this site system server require a proxy server to connect to locations on the Internet, and then click Next.
On the System Role Selection page, select the Software update point site system role, and then click Next.
Complete the wizard.
Repeat steps 3-7 for any additional servers added in step 1.
Remove the software update point site system role from the old WSUS server
Use the Configuration Manager console to remove the software update point site system roles. When this role is removed from a server, client policy updates to remove the software update point from the list of available servers.
Starting with Configuration Manager SP1, when you have more than one software update point at a primary site and you remove the one that is configured as the synchronization source for all software update points at that site, you will be prompted to specify a new WSUS server as a new synch source.
Use the following procedure to remove each applicable software update point:
In the Configuration Manager console, navigate to Administration > Site Configuration > Servers and Site System Roles.
Select the site system server with the software update point you want to remove, and then in Site System Roles, select Software update point.
On the Site Role tab, in the Site Role group, click Remove Role, and then confirm that you want to remove the software update point.
Repeat these steps for additional software update points you want to remove.
Important
Do not remove WSUS 3.2 or the WSUS 3.2 admin console from the site server.
Secondary sites with a SUP
Secondary sites do not support the SUP role on remote servers. If you desire to change the server operating system on your secondary site servers that are also SUPs, you will need to back up necessary WSUS data and then restore that data after the secondary site server is replaced (rebuilt). Clients that use the SUP located at a secondary site will fall back to a SUP at the primary site when the secondary site is removed.
Scenario 2: Multi-site hierarchies
The process is similar to the first scenario. However, when a central administration site is involved, use a top-down sequence, starting at the central administration site. After the central administration site is complete, move to a child primary site. Repeat the process until all child sites (including secondary sites) are migrated.
Known Issues
Problem: Installing Configuration Manager clients using SUP based installation no longer works with remote SUPs.
Root Cause: The WSUS local publishing APIs enforce a version match between the caller and remote WSUS server. If the Configuration Manager site server runs a different version of the WSUS admin console, publishing of the client install package will fail. For example, If the Configuration Manager site server runs Windows Server 2008 or Windows Server 2008 R2 (thus using the WSUS 3.2 admin console and local publishing APIs), any attempts to locally publish to a remote WSUS 4.0 server will fail with a version mismatch error.
Resolution: Download this script and run it on the remote WSUS 4.0 server to publish the Configuration Manager client for SUP based installation.
Problem: When System Center Updates Publisher (SCUP) 2011 is installed on a Configuration Manager site server, Updates Publisher fails to publish updates to a remote WSUS server.
Root Cause: The WSUS local publishing APIs enforce a version match between the caller and remote WSUS server. This is similar to the previous problem.
Resolution: See Publishing Updates to WSUS on Windows Server 2012. SCUP will need to be installed on a computer running Windows 8.1, Windows Server 2012, or Windows Server 2012 R2.