Summary
We’ve all been there before… The monthly software updates are released and you diligently deploy them to your environment. At some point your manager, IT Security or Auditor asks why certain systems are not compliant. Depending on your environment, it can be hard to find answers for all of their questions.
In this series of posts, I will talk through common issues I have seen that skew the numbers for software updates, or make it difficult to explain the results.
Once we are done, hopefully you will be able to look at the SCCM Software Update process in much the same way as Neo saw the Matrix… except you’ll actually know what is going on instead of a bunch of green 1s and 0s floating everywhere you look.
This is part 1 of the “Understanding Software Update Deployment Status” (or “U-SUDS”, which is much more fun to say).
Here is the breakout of the series:
In part 1, I will be covering the Importance of WSUS Maintenance, AKA “The Care and Feeding of WSUS”.
In part 2, I will be covering Software Update Client and Scan Issues that can contribute to low compliance.
In part 3, I will be covering Viewing Update Compliance in the SCCM Console, what it means, and what it doesn’t mean, and what it really means to tell you if only you listen.
In part 4, I will be covering Enforcement status of Update Deployments (which is much different than compliance).
In part 5, I will be covering How Clients Report Compliance Status, giving you a peek into the insanity of the unknown.
Finally, in part 6, I will be covering How to Unmask the Real Culprits behind your “unknown” and “non-compliant” clients.
U-SUDS PART 1: THE CARE AND FEEDING OF WSUS
SOFTWARE UPDATE POINT SETTINGS
As part of your configuration for your Software Update Points, you had to configure the Classifications, Products and Languages you want WSUS to synchronize with Microsoft Update. SCCM will only contain information on the updates that WSUS is actively synchronizing. This means that any updates that apply to items you have not selected to synchronize via WSUS won’t show up as needing patched. Not only that, but if a new product is added to the list, it will not be automatically selected. This means that new version of Windows or Office can often go unpatched early in the rollout at an organization.
A common approach to this is just to select all Classifications, all Products, and the languages you need. The idea is that you will not have to worry about missing data. This approach can cause many issues of its own. Definition Updates and Drivers represent a large number of items with high turnover, which can easily overwhelm an install of WSUS and bring it to its knees.
The approach I recommend is as follows:
Products: Enable all products. This ensures that you have data no matter what you are asked to patch. It also means that you will have compliance visibility on any product from Microsoft. As new products or product groups are released, they will be added to the list and selected for you.
Classifications: Enable Critical Updates, Security Updates, Service Packs, Update Rollups, and Updates for sure. Only enable Drivers if you actually plan on using SCCM to deploy drivers from Microsoft Update. Only enable Definition Updates if you are actually using Microsoft Forefront or managing the Windows Defender client on Windows 10 devices via SCCM.
Languages: Only enable the languages you actually need.
WSUS MAINTENANCE
WSUS is a senior citizen among other Microsoft products. Over the years, it has been adapted to handle changes as needed, but it still basically works the same way it did when it was first released. One common issue I’ve seen is that many administrators don’t realize that WSUS needs to be actively maintained. Even worse, is that in many cases no one is even checking the status to see if there are issues until there is an actual problem, and by then the solution can be painful. Without maintenance and monitoring, WSUS can stop working, which effectively “puts the brakes” on anything software update related.
WSUS has a maintenance wizard that you can step through manually to clean obsolete updates, decline superseded updates, decline expired updates, and remove unneeded content. One gotcha is that if you already have an issue with WSUS, you probably cannot connect long enough to run the wizard.
The Microsoft Scripting Guys have posted an excellent PowerShell script that can be used to automate the cleanup for you. I recommend running it at least monthly via Scheduled Task. Not only that, but make sure you monitor the status of the scheduled task to be sure it is working properly.
One more critical thing is to be sure and re-index the WSUS database on a regular basis. The database has a lot of churn due to the constant release of updates, and it doesn’t take long for it to start to become fragmented and slow down. The Scripting Guys also have an excellent script to handle this issue for you. Even though it is marked as Visual Basic, it is actually a TSQL script.
An Easy Knockout: SQL vs Windows Internal Database
One last thing I want to cover here is the differences between using SQL or the Windows Internal Database (WID) to host your WSUS instance.
Let me make this easy: Windows Internal Database is not the solution you are looking for [Todd waves like a Jedi master, your mind softens, and you see the truth in my words].
Yes, it is true that WSUS offers the option of using the Windows Internal Database during installation, and it is easy to setup compared to SQL, but the fun ends right there.
Even with aggressive maintenance, WID will soon grind to a halt. It just isn’t cut out to handle the number of updates and the amount of client data that WSUS has evolved to use. Yes, it saves you a SQL license, but it will turn your hair gray and cost you years of your life. So take my word for it: don’t go gray, live long, and host your WSUS database on an actual instance of SQL Server.
In Closing
That is all for this entry in the series. Just remember that maintaining WSUS is one of the most important tasks that an SCCM admin needs to perform.
