Introduction
I have recently come across multiple customers that are having issues with a High IIS Worker Process, causing the Servers to flatline, so I wanted to take some time here to run you through all of the steps that you can follow to remediate this issue.
So what is the Issue exactly?
Even though it may seem daunting trying to figure out what is causing the headaches, the issue and solutions are quite easy
It is important to understand that it is usually a combination of 2 things:
- Regular WSUS Maintenance is not being done, in particular declining of Superseded Updates
- Incorrect Configuration on the SCCM Server hosting the SUP Role (we will get into that a bit below)
Important Considerations
It is important to understand that even though the Server is showing to be flatlining on CPU, this is not a CPU issue. Adding more coresProcessors will not resolve the issue that you are experiencing. We need to delve deeper into the issue, to resolve the underlying issue.
1.Regular WSUS Maintenance not being done.
This is a Large part of the issue that customers are experiencing. It is important that we understand what we mean with this.
(Have a read through This amazing Blog from Meghan Stewart | Support Escalation Engineer to help you setup your WSUS Maintenance. It has all the required information on When, Why and How to implement your WSUS Maintenance, as well as having a great PowerShell script to help..)
Superseded Updates - Update that has been replaced by another newer update, and is no longer relevant. Yes these updates to report that they are "needed" however, they have been replaced by a newer update and are just taking up spaceCPU time.
Example:
Let us take an example of a 1000 Client small network, running Multiple versions of ServerClient OS (Windows 7, Windows 8.1, Windows 10, Server 2012 R2, Server 2016), having 1 or more SUP's
Each client will scan against the SUP (Software Update Point) Catalog regularly, to determine what updates are available, how compliant it is, and if any Updates are needed.
When clients scan against WSUS they scan all updates that are not declined or obsolete. If 25% of your updates are superseded (for instance) that is 25% wasted CPU time from the client's machine as well as on the Server that they are scanning against.
So you need to ensure that you are regularly cleaning up the WSUS Server as per the Article above.
2. Incorrect Configuration on the SCCM Server hosting the SUP Role
An important Step is missed by a lot of customers, that is configuring your WSUS AppPool Correctly.
The AppPool memory in a lot of cases is left at the Default 1.9GB of memory. This is not sufficient if you are managing a large amount of clients, and will need to be increased.
Note: This is reserved memory that you are allocating, so ensure that you have catered for it in your planning
Open your IIS Manager App - Expand Server name - Application Pools.
Right-Click on the WsusPool - Advanced Settings
First thing you can do is to change your Queue Length from 1000 to 2000 (environment depending. Queue length is Maximum number of HTTP.sys requests that will queue for the App Pool, before the system will return 503 - Service Unavailable Error)
Secondly the Private Memory needs to be changed to a Minimum of 4GB instead of the 1.9GB default.
Once Completed Recycle the AppPool.
My Server may be flatlining so bad that I cannot open WSUS, or WSUS Cleanup is being done, so what now?
The last step that you can take in an extreme situation is to temporarily kick the clients off the WSUS Server, so that you can complete the Modifications to the WsusPoolPerform WSUS Cleanup.
Temporarily kick the clients
We are going to be creating a new AppPool and changing the website bindings so that we can access the WSUS in order to perform the cleanup.
Note: During this step, your clients will not be able to connect to your WSUS instance.
Open your IIS Manager App - Expand Server name - Application Pools.
Right-Click on the Application Pools - Add Application Pool
Once you have created the AppPool, we need to change the Website over to the Pool First
Now our Next Step is to change the Bindings and assign a different port number to the HTTP Connection for WSUS, so that the clients are unable to scan against it, thereby freeing up the memory for us.
Under IIS Manager App - Expand Server name - Sites - WSUS Administration
Right click - Edit Bindings
Now Assign a different Port Number (i.e. 1234 )
Once this is done, you will need to restart the Website
While still in IIS Manager App - Expand Server name - Sites - WSUS Administration - Restart Website
Now when you connect to WSUS, select the custom new port
That should allow you now to be able to run the Cleanup and re-indexing of the DB for WSUS.
Once you have completed this, make sure to change the BindingsPool back to what it was before so that the clients can now start scanning again.
Conclusion
As long as the correct configuration is applied in the environment, and the regular maintenance in place, you should not have any further WSUS Performance issues.
オープニング スピーチ (午前中)
