UNDERSTANDING SOFTWARE UPDATE DEPLOYMENT STATUS IMPROVEMENT

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.

UNDERSTANDING SOFTWARE UPDATE DEPLOYMENT STATUS - CLIENT AND SCAN ISSUES

SUMMARY

This is part 2 of a 6 part series where I 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.

Here is the breakout of the series:

In part 1, I covered the Importance of WSUS Maintenance, AKA “The Care and Feeding of WSUS”.

In this post, I will be cover 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.

HERE WE GO AGAIN….

Sometimes managing software update deployments via SCCM can be a harrowing, repetive, experience.

Have you ever lived through the following traumatic scenario:

• Patch Tuesday arrives and Microsoft releases a batch of new updates to secure their products.

• The list of updates are reviewed and a decision is made on what to deploy in your environment. This could be done by a team within your organization, or it could just be you deciding what you should patch this month.

• You deploy the designated updates to a small test group of devices just to be sure there are no ill affects.

• Assuming all went well with your testing, you deploy the updates to the rest of your environment.

• You let the updates bake for a little while, and move on to other tasks.

• You come back and review the Compliance data for your updates, eager to be able to declare that your deployment was successful and that all is good and right in the world again.

• During the process of reviewing your results, you see that things don’t look as you expected.

• You sigh, and begin to look at which systems failed which patches and why.

In this installment of “Understanding Software Update Deployment Status” we will cover what happens up to the point you deploy the software updates, and what you can do to verify those steps.

UNDER THE HOOD

Figuring out what is keeping your software updates from deploying and installing on your client devices can be a daunting task. To really understand what is going wrong, it is important that you understand exactly what is supposed to happen behind the scenes when you deploy updates. Let’s walk through the main steps of the process. As we step through the process, I’ll mention things that could possible go wrong and where to look to determine what may be going wrong.

1) Patch Tuesday. Microsoft releases new software updates. When this happens, Microsoft publishes data about the new updates to Windows Update.

Note: Unless you work at Microsoft and are on the Windows Update Team, this step is out of your hands.

2) The WSUS server that is leveraged as a Software Update Point in SCCM connects to Windows Update and retrieves any new metadata for updates that match the classification, product, and language settings you have specified.

If WSUS is not healthy, or fails to syncronize with Microsoft Update, your deployment process dies here. An easy way to troubleshoot this step is to open the WSUS admin console and do the following:

•  Ensure that the last Syncronization with Windows Update was successful, and took place after the new updates were released by Microsoft.
• Look at the list of updates in WSUS and verify the updates you care about are listed.

If you suspect this step is failing, look at the Change.log and SoftwareDistribution.log files under C:\Program Files\Update Services\LogFiles on your WSUS server.

3) WSUS publishes this data for clients to retrieve.

4) SCCM performs a syncronization with WSUS, and imports the new metadata into SCCM.

If this step is failing, you will not see the new updates listed in the All Updates node in SCCM. To troubleshoot this issue, look at the following logs on your SCCM Server under [Configuration Manager Installation Folder]\Logs\:

• WSUSCtrl.log
• wsyncmgr.log

5) The windows update agent on your SCCM clients polls the WSUS server and obtains the metadata for the latest updates. This is called the Windows Update Redistribution Catalog.

If clients don’t have the most current metadata, they will not be aware of new updates, and will likely show up as “Unknown” for those updates.

If you run the following SQL query, you can see get the latest cab version from SCCM:

1 2	Select SyncCatalogVersion, LastSuccessfulSyncTime from vSMS_SUPSyncStatus

Make sure the Last Sync Date is after the updates were released and take note of the catalog version.

6) The windows update agent on your SCCM clients performs a local software update scan to determine the status of all updates. When completed, it uploads the scan results back to the WSUS server indicating whether each update is Not Applicable, Installed, or Needed.

Several things could go wrong here. The first place to start is by running the following query (You’ll need to know the ResourceID of the client you are wanting to check):

1 2	Select REsourceID, LastScanTime, LastScanState, LastErrorCode, LastScanPackageLocation, ScanPackageVersion, LastLocalChangeTime from v_UpdateSyncStatus

Here’s how this data should look.

• Last Scan Time should be after the updates were released.
• Last Scan State should be equal to 3. 5 indicates an error.
• Last Error Code lists the error number returned if the last scan failed. Look this error up in CMTrace.
• Scan Package Version should be equal to the version you got in the query for step 5 above. The number increments each time you sync, so if this is a few numbers behind, it’s probably ok.
• Last Scan Package Location should be a http url for your WSUS server/SUP.Last Local Change Time indicates when the client last updated the status of an update or added new updates. This should be after the date new updates were released.

To troubleshoot errors here, look at the following logs:

• C:\Windows\WindowsUpdate.log
• C:\Windows\CCM\Logs\WUAHandler.log
• C:\Windows\CCM\Logs\UpdatesStore.log

7) SCCM Syncronizes the client scan data via WSUS, and provides the nice summary numbers you see in the software update node for each update.

If this step was successful, you should see either an “Installed”, “Needed” or “Not Applicable” status for the update against clients. “Unknown” would indicate that we didn’t get to this point without an issue.
8) You deploy the software updates to clients.

Verify that the updates you care about are showing Deployed = Yes and Downloaded = Yes in the SCCM console, and look at the collections they are deployed to. Ensure the clients you care about are actually in those collections.

UNTIL NEXT TIME…

That’s all for this installment. In the next section, “Viewing Update Compliance in the SCCM Console”, we will cover what happens once the deployment has started and how we can verify all is going well.

UNDERSTANDING SOFTWARE UPDATE DEPLOYMENT STATUS, - VIEWING COMPLIANCE IN THE SCCM CONSOLE

SUMMARY

This is part 3 of a 6 part series where I 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.

Here is the breakout of the series:

In part 1, I covered the Importance of WSUS Maintenance, AKA “The Care and Feeding of WSUS”.

In part 2, I covered Software Update Client and Scan Issues that can contribute to low compliance.

In this post, 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.

Sometimes managing software update deployments via SCCM can be a harrowing, repetive, experience.

LAST TIME ON “UNDERSTANDING SOFTWARE UPDATE DEPLOYMENT STATUS”…..

In Part 2, we discussed the steps that take place between Microsoft releasing a new update up until the update is deployed via SCCM. We also talked about how to determine if your clients are scanning properly, and how to verify WSUS is working.

Once your deployment is active, the real action begins.

VIEWING DEPLOYMENT STATUS

In my opinion, the best place to view the status of your deployment (at least at first) is on the Monitoring Node.

In the SCCM console go to:

Monitoring -> Deployments

Select your update deployment in the top pane, and the bottom pane will populate with some information. Note the “Last Update” time. This is the last time that SCCM ran a summarization on this deployment. Any progress or issues that were encountered since that time will not be reflected here.

If you want to force a refresh of this information, click “Run Summarization” on the Ribbon. Wait a few minutes, click refresh and the “Last Update” time should change.

If you click the “View Status” link in the bottom pane and you’ll get a nice view of clients organized by deployment status.

A couple of hidden gems in this view are:

• If you Double-click on a Status in the top pane, SCCM will open the devices as a psuedo-collection, where you can dig in deeper.
• If you select a client in the bottom pane and select properties, you can get per update status for that client. This can help you determine which patch has an issue.

BEHIND THE CURTAIN…

Once your deployment is live, the following items take place:

1. Clients receive information on which updates are being deployed as Client policy from the Management Point.This ensures that the clients will respond to your request to install any needed updates that are part of your deployment. If clients are failing to see this, it’s likely that they are offline or broken. Clients who have not yet received policy will show in the “Unknown” tab.
2. When the “Available” time for the deployment is reached, SCCM clients ask SCCM for a list of distribution points where the files can be found.When this takes place, you should see clients move to the “In Progress” tab with a status of “Waiting for Content”
3. The SCCM client downloads files for any updates that are “Needed” and stores them in the SCCM Client Cache.When this takes place, you should see clients move to the “In Progress” tab with a status of “Downloaded update(s)”
4. When the mandatory deployment time is reached, the SCCM clients begin the process of installing any updates that are “Needed”.Clients status should change on the “In progress” tab to show the installation status.Any clients with issues encountered during installation will be present on the “Error” tab with a description of the error.
5. Once the “Needed” updates are installed, SCCM clients perform another software update scan and send the latest status for each update to WSUS. SCCM again imports this information from WSUS and displays compliance status in the console.At this point, you should see the clients move to the “Compliant” tab, which is where you want them to be.

When viewing update compliance in the SCCM console, there are some things you need to keep in mind:

• SCCM Treats “Not Applicable” clients as “Compliant”
• Unless you are viewing the status of the actual Deployment, the numbers shown are the overall numbers for your site.

One of the common issues I see with software update deployment is when a deployment targets what the admin thought were all the devices that needed the update, but missed some. It can be confusing if your deployment status shows all good, but your compliance numbers show you still have some clients that need the update.

That’s all for this installment of “Viewing Update Compliance in the SCCM Console”.

Tune in next time when we will discuss the deep question: “Enforcement Status – What does it mean?”

Link Source: http://model-technology.com/understanding-software-update-deployment-status-part-3-viewing-compliance-in-the-sccm-console/

http://model-technology.com/understanding-software-update-deployment-status-part-2-client-and-scan-issues/

http://model-technology.com/understanding-software-update-deployment-status/

---