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:

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):

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.