This article introduces several procedures for troubleshooting Windows Server Update Service (WSUS).
If you are using WSUS 3.0 SP2, you must have KB 2734608 or a later version update package installed on the WSUS server. We recommended you install update 2828185 together with update 2938066.
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.256 or later version.
When 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 2734608 or later update must also be installed on the WSUS Administration console. After you install KB 2734608 (remotely or locally), a server restart is required. After the restart, determine whether the issue still exists.
To troubleshoot the connection failures, follow these steps:
Verify that the Update Services service is 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 the various error codes.
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 WSUS app pool memory issue or just too many client connections. To fix the issue, increase WSUS App Pool Private memory to 4–8 GB.
Note Accessing most WSUS URL with a browser returns a "403" error for most WSUS URLs
"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 amount of roundtrip errors, see the following WSUS maintenance blog entry:
If a client’s IP address does not appear in the IIS logs, the client is not set to connect to this WSUS server. This situation may 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:
For Configuration Manager clients, check the ccm\logs\location services log for a WSUS entry to verify that the client is getting the correct server URL. You may have to restart the smsagenthost service in order for the service to log this entry.
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 couple of days, all clients might start scanning and continue to scan constantly and never actually completing a scan or installing updates.
To fix the issue, you have to clean up the WSUS server and decline the superseded updates. Follow the steps in the given order 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 may 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 this situation, you must first stop the clients from connecting the WSUS app 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. 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 app pool
- Right-click Application pools in the Internet Information Services (IIS) Manager area, and then select Add Application Pool.
- Select Client web service > Manage application > Advanced settings, and then change the app pool to the test app pool.
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 clients 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, you can run the script again by using -skipdecline to actually decline the updates.
In extreme cases in which the PowerShell script can not run, you can add the supersedence column to the WSUS console when all updates are displayed. See 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 (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 re-index the database after you decline superseded updates, and then do a sync between USS and Configmgr while the clients are not connecting.
After you complete these steps, you should limit the connections. 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.
The PID should change only one time in every 29 hours. If it changes more often, your connection limit is too high for the current CPU and memory setting for the WSUS app pool.
Monitor for stable w3wp memory and stable overall CPU of less than 90 percent. As the steady state CPU and memory decrease, you can slowly increase the connection limits to the WSUS administration website. Make sure that the customer understands that returning all operational levels to their usual status may take several days.
ID do Artigo: 4025764 - Última Revisão: 06/07/2017 - Revisão: 23