I found out recently (after a 4-hour call with Microsoft Premier Support) that you must take care of the WSUS database and instance just as much as the ConfigMgr database and instance. This post is on how keep your WSUS database and instance clean of old updates and optimized to serve your environment. All the strategies discussed here came from Premier Support, so while some of them are not 100% supported, the method did come from someone at Microsoft.
I would still extend the queue length and increase the private memory limit on the IIS AppPool, as discussed in this post. The CPU throttling part of this post is not required if you keep the WSUS components cleaned up.
General Recommendations
I recommend that you run your SUP on its own server. This process may require server reboots to refresh WSUS. It’s also just good practice for environments of any decent size. Just as note, if you run the SUP on a separate server, you must install the WSUS tools on your primary site server (the PSS needs the WSUS API to communicate). Also, your primary site server and WSUS/SUP server must be the same OS version.
Second, if you’re using ConfigMgr in a production environment, be sure the WSUS database is running in SQL Server Standard or Enterprise. No WID or SQL Express. I know it costs money, but you’ll probably save that money in soft costs (such as your time). It’s perfectly fine to run the WSUS database in the same instance as your ConfigMgr database, or on a SQL cluster.
Issue
Over time, WSUS will become polluted with superseded updates. These superseded updates do not get declined. ConfigMgr will expire the updates per this screen when you’re installing your SUP:
This, however, does not actually decline the updates in WSUS. If an update is not declined, clients will still check to see if they need that update. This created a situation in my environment where there were approximately 114,000 possible updates that clients had to scan through to determine if it need updates. This caused severe backlog on the SUP, and the IIS AppPool would eventually crash. The SUP at this point is unusable.
Resolution
To resolve this issue, you must cleanup and optimize WSUS once per month. I recommend the week before patch Tuesday (no real basis for this, but it’s when I run it). There are several steps to do this, which I will detail.
The steps in this post instructs you to decline superseded updates from the WSUS MMC console. To know if an update has been superseded, you’ll need to sort by and look at the superseded column:
This screenshot shows the two icons that tell you if an update is superseded. To decline the updates, select all of the superseded updates, right-click, and select “Decline”.
Be careful, there’s one more icon where the blue box is on top – those are updates the supersede another update, so don’t decline those. Here’s an example of the 3rd icon:
The directions also say to decline Itanium updates and language packs. To find those, use the Search option. Highlight all of them, right-click, and select Decline. Be careful with the language packs. Searching “language pack” will also return English (or the language that you’re actually running). Be sure to not decline those.
Cleanup Steps
You will need the WSUS re-index SQL script, available from the TechNet Gallery here and the SQL database cleanup script that is at the bottom of this post.
Note that the first time you do this, it could take hours upon hours to complete. Just be patient and let the process work. Subsequent times should take about an hour to complete, but most of that is processing time on the server.
I’m going to go over the steps with assumption that you have an upstream WSUS server on your network that ConfigMgr syncs against. If you don’t have an upstream server and you sync directly with Microsoft, ignore everything about the upstream server.
Some steps will be downstream first, then upstream, while others will be opposite.
Steps:
- BACKUP WSUS DATABASE ON BOTH SERVERS! (can’t stress it enough to have good backups, just in case)
- Using SQL Server Management Studio (either remote or on the servers):
- Run the re-index script on the downstream server
- Run the re-index script on the upstream server
- Run the SQL database cleanup script on the downstream server
- Run the SQL database cleanup script on the upstream server
- Using the WSUS MMC Console on the upstream server:
- Decline superseded Critical Updates
- Decline superseded Security Updates
- Decline all Itanium updates (UNLESS you actually have Itanium servers)
- Decline language packs and language pack updates for languages that you do not need
- Repeat step 3 on the downstream server
On your first run at this, declining the updates may cause the WSUS console to crash. That is fine, just re-launch it and continue until you get through all of the updates. You may need to restart the server (or the IIS Application Pool) once or twice as well to clean out the backlog in IIS.
That’s it. I would suggest restarting both the upstream and downstream server after this process. It’s not a hard requirement, but it will give WSUS and IIS a chance to restart.
Disclaimer
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.
