In Part 1, I introduced the three manifestations of timeout errors in a WSUS environment, and identified the four practices that will help eliminate them. In this article we’re going to talk specifically about the practice of removing unnecessary update approvals. This is a practice that all WSUS administrators should adopt, whether timeout errors are an issue, or not -- it’s just good practice.
Why do approvals matter?
Update approvals collect up over time, to the point where eventually they achieve critical mass and start interfering with efficient database operations within the WSUS database. WSUS was never intended to be a run-it-and-forget-it type of application, and it does require regular administration and maintenance.
How do approvals impact performance?
In WSUS, there are four entities of interest that are impacted by approvals: Updates, Groups, Computers, and Approvals. As the counts of each of those entities increase, the combinations increase exponentially. This causes longer processing times within the database when returning queries to the console or providing synchronization event data to a downstream server. Eventually the result doesn’t come back fast enough, and the console or downstream server gets tired of waiting.
One of the ways we can control this performance behavior – and in an amazingly significant manner – is by managing the number of approvals that exist on the WSUS server. Generally speaking, a well-maintained WSUS server will rarely have more than a few hundred approved updates. So, as a starting point, if a WSUS server has more than 500 approved updates, it’s a candidate for a review of the approvals.
Updates that should have approvals removed
There are three classes of updates that we can target for update approval removals:
- Products that no longer exist in the environment. If you’ve upgraded all of your Windows XP systems to Internet Explorer 8, and retired all of your Windows 2000 systems, then you really have no use for any updates for IE5, IE6, or IE7, or for Windows 2000. Decline them.
- Any update that has been superseded by a Service Pack that has been fully deployed to your organization. Updates superseded by a service pack that is installed everywhere have no useful value. Decline them.
- Any other superseded update that is reported as 100% Installed/Not Applicable on the WSUS console. If superseded updates are 100% Installed/NA, then they will never be used (read: deployed) to any system ever again. Decline them.
This third group is usually the most difficult to identify. One way to do this is to:
- Filter the All Updates view with Approval=”Approved” and Status=”Installed/NotApplicable”.
- Enable the Supersedence column display
- Sort by the “Installed/Not Applicable Percentage” column. Alternatively, you can also sort by the Supersedence column. You may prefer one method over the other, and either will serve the purpose.
- Select the updates reported as 100% Installed/NotApplicable that are identified as superseded.
Note: If you are using SolarWinds Patch Manager, you can build a permanent update view with these settings, and then do a Select All on the list of updates. I describe how to do this in a Geekspeak Blog Post.
Having identified the updates to be declined:
- If you do not have downstream replica servers, you can Decline these updates directly.
- If you have one or more downstream replica servers, do NOT perform a mass decline of hundreds of updates on your upstream server. This is also a known cause of downstream replica server synchronization timeout errors. Rather, in this case, you’ll need to spread this activity out over several sessions so as to not overload the number of approval events that need to be synchronized to the replica servers.
This procedure should then be performed on a regular basis. Monthly would be optimal, but you may find that removing approvals on a quarterly basis is sufficient to maintain performance of your WSUS server.