This article introduces several procedures for troubleshooting Windows Server Update Service (WSUS).
Verify the prerequisites
- If you are using WSUS 3.0 SP2 on Windows Server 2008 R2, you must have update KB 4039929 or a later-version update package installed on the WSUS server.
To verify the server version, follow these steps:
- Open the WSUS console.
- Click the server name.
- Locate the version number under "Overview, Connection, Server Version."
- Check whether the version is 3.2.7600.283 or a later version.
If you are using WSUS on Windows Server 2012 or a later version, you must have one of the following Security Quality Monthly Rollups or a later-version rollup installed on the WSUS server:
Note If you're using System Center Configuration Manager and the Software Update Point is installed on a remote site system server, the WSUS Administration console must be installed on the site server. For WSUS 3.0 SP2, KB 4039929 or a later update must also be installed on the WSUS Administration console. After you install 4039929 (remotely or locally), a server restart is required. After the restart, check whether the issue persists.
Troubleshoot connection failures
To troubleshoot connection failures, follow these steps:
- Verify that the Update Services service and the World Wide Web Publishing Service are running on the WSUS server.
- Verify that the default website or WSUS Administration website is running on the WSUS server.
- Review the IIS logs for the WSUS Administration website (c:\inetpub\logfiles), and check for errors.
The following table defines common error codes. For more information about HTTP status code in IIS, see The HTTP status code in IIS 7.0, IIS 7.5, and IIS 8.0.
Authorization: OK if followed by 200
Access failure: Certificate issues or incorrect IIS configuration.
Not found: Missing Virtual directory or IIS configuration
Service not available
Busy: This can be caused by a WSUS application pool memory issue or just too many client connections. To fix the issue, increase the WSUS Application Pool Private memory limit to 4–8 GB. Some environments may require more than 8 GB; adjust this setting as needed.
Note Accessing most WSUS URLs in a browser will return a "403" error.
"503" errors in IIS may be accompanied by "xxxx2ee2" errors in the c:\windows\windowsupdate.logs file on clients.
To resolve "503" IIS errors, a client time-out, or a large number of roundtrip errors, see the following WSUS maintenance blog entry:
If a client’s IP address doesn't appear in the IIS logs, verify that the client is set to connect to the correct WSUS server. This situation may also occur because of network blocking or because the server logs a special error.
- On the WSUS server, check the C:\windows\system32\logfiles\httperr logs for errors.
- On the client, check the following registry subkey to determine whether the correct FQDN of the WSUS server is set:
Note For Configuration Manager clients, check the ccm\logs\locationservices.log for a WSUS entry to verify that the client is getting the correct server URL. You may have to force the Configuration Manager client to run another scan by using the Software Updates Scan Cycle from the agent in order for the service to log this entry.
Troubleshooting High CPU usage on WSUS server
The issue can occur if the SUSDB is not "clean." After the server runs for a while, there can be too many updates for the WSUS server to provide to the clients.
In this situation, if a failure occurs or a new WSUS server is installed or an unrelated issue prevents clients from scanning for a few days, all the clients might start scanning and continue to scan constantly and never actually complete a scan or install updates.
To fix the issue, you have to clean up the WSUS server and decline superseded updates. Follow the steps in the order below as a monthly cleanup routine. However, if you are troubleshooting "high CPU" issues, we recommend that you do step 4 first and then step 3. You should defer steps 1 and 2 until the CPU usage level decreases.
Step 1. Back up the WSUS database
Backing up the WSUS database can improve the performance slightly.
Step 2. Run the WSUS Server Cleanup Wizard
Running the WSUS Server Cleanup Wizard can improve database performance. However, it does not reduce the number of updates that the clients are scanning. Additionally, it can take many hours or days for the wizard to run without necessarily resolving the issue.
Step 3. Re-index the WSUS database
Re-indexing the WSUS database can improve database performance if it's fragmented. To do this, run the following commands.
- Update the statistics by using the FULLSCAN option.
Use <dbname>GoExec sp_msforeachtable 'update statistics ? with fullscan'Go
- Rebuild the indexes.
Use <dbname>GoExec sp_msforeachtable 'DBCC DBREINDEX (''?'')'Go
Step 4. Decline superseded updates
Declining superseded updates immediately reduces the number of updates that are being scanned.
To decline superseded updates or perform any WSUS actions in a situation where the WSUS application pool recycles too quickly, you can first stop the clients from connecting to the WSUS application pool. To do this, connect to the WSUS server by using the WSUS console, and then synchronize the WSUS server with the upstream server and with Configuration Manager (if it is used). If you are using Configuration Manager, it is important to synchronize to the latest version of the update in the Configuration Manager console so that clients will see that WSUS has current and valid updates.
To disconnect the clients, use one of the following methods.
Method 1: Create a test application pool
- Right-click Application pools in the Internet Information Services (IIS) Manager area, and then select Add Application Pool to create a test application pool.
- Select Client web service > Manage application > Advanced settings, and then change the application pool to the test application pool which you created.
Method 2: Change the port for the WSUS website
- Select WSUS Administration Web Site > Edit Bindings.
- Change the WSUS console to connect to the new port, run the script, and synchronize with USS.
Note This method will cause syncing with Configuration Manager to fail.
Method 3: Use Firewall rules to block all client IP addresses or allow only USS and site server incoming connections
After the clients are disconnected from the WSUS server, you can run the PowerShell script by using the -skipdecline (and -exclusion period, if required) parameters to determine the total number of superseded updates that can be declined. Then, run the script again by using -skipdecline to actually decline the updates.
In extreme cases in which the PowerShell script can't run because of timeouts, you can add the supersedence column to the WSUS console when all updates are displayed, and then decline the updates manually. See the section "Cleaning up WSUS from the WSUS console" in Support Tip: ConfigMgr 2012 update scan fails and causes incorrect compliance status.
The performance issue can normally be resolved after the valid update is reduced to fewer than 7,000 connections (but fewer than 5,000 is preferred). You might have to restrict connections to the WSUS Administration website for a few days to let the clients complete all scans. We also recommend that you reindex the database after you decline superseded updates. If you're using Configuration Manager, also perform a sync between WSUS and Configuration Manager while the clients are not connecting.
After you complete these steps, you should limit connections if the CPU usage is still too high. To do this, follow these steps:
- Open Internet Information Services (IIS) Manager > WSUS Administration Web Site > Manage web site > Advanced settings > Limits > Maximum concurrent connections.
- Set the value to 50 or 100.
- Monitor the W3Wp process in Task Manager and the total CPU on the server.
- Open Task Manager > Resource Monitor, and note the PID for the WSUS application pool. If you are unsure which w3wp process is running the WSUS application pool, you can use appcmd (Method 2) to identify the PID easily.
By default, the PID should change only one time every 29 hours. If it changes more often, your connection limit may be too high for the current CPU and memory setting for the WSUS application pool.
Monitor for stable w3wp memory and stable overall CPU use of less than 90 percent. As the steady state CPU and memory use decrease, you can slowly increase connection limits to the WSUS administration website. Depending on what kind of situation you are in, the memory usage may take several days to return to a stable state. Increasing the connection limits might need to occur in small increments and over the course of several days.