In this series we will be blogging about some of our best practices using System Center Configuration Manager for updates deployment. I work on managing updates to 280k clients at Microsoft, so I have a lot of interest in this space. To start with I have divided this blog in two parts. The first blog will walk you through the process of how a system becomes compliant for a particular update and in the second blog I’ll share what we’ve learned about the Unknown bucket. The goal is to share how you can improve overall compliance by using the different views/tables and weeding out the false negatives from your environment.

Part 1 - How does a system becomes compliant in ConfigMgr?

To follow how compliance of a bulletin ID is reported at the Central Site, let’s take an example of bulletin ID MS011-19. Let’s also assume that this Bulletin ID has multiple versions applicable for different OS types, as in table below. These versions are internally referred as Configuration Items (CIs).

For this discussion let’s also take a client TEST1 which is a Windows 7 x64 OS machine. Based on the details known about this bulletin, and TEST1 machine being a Windows 7 x64 system, it will only install update with CI_ID 207819, and ignore the rest of CI_IDs.

Note: Instead of taking all the 15 CIs for MS11-19, I will take 3 CIs from the list of 15, which has all possible statuses in the view. But be aware that some Bulletin ID may have more than one CI applicable, especially the .NET bulletins. 

Now let’s see where and how this data is stored in ConfigMgr SQL database views.

All of the ConfigMgr Compliance related status reports uses one or more of the above views to report different statuses for updates targeted to a collection.

Now let’s see how this TEST1 client scans and reports compliance for bulletin ID MS11-019 (TechNet Article).

At a high level the ConfigMgr client agent performs these 2 client actions to scan, install and report status of any targeted updates.

                Software Updates Scan Cycle

                Software Update Deployment Evaluation Cycle

Software Update Scan Cycle:

During this process Client will start scanning against the Software Update Point (SUP) and populate the local Software Update related WMI classes with status of each Applicable CIs for the BulletinID as Required. The status or information about non-applicable CIs will not be stored locally by the client. Upon completion of scan cycle, the client will send a state message to Management Point, which in turn is processed at the site server and forwarded upstream until it reaches the Central Site Server. This scan cycle is run as per the preset interval in the Software Update Component configuration of your site.

Details about the state message on completion of successful scan cycle are reported with state message ID as 501 and the data is stored in Update_ScanStatus table. The key fields in the table are as noted below:

Note: This information is available in the Update_ScanStatus table for every client in the site. This information is the last status received from the client and may not be the actual data on client itself in some cases.

Going back to the client TEST1, let’s assume that the scan state message is sent to the servers. The data will look like the table below along with the view details.

Software Update Deployment Evaluation Cycle:

After the Software Update deployment is targeted and the evaluation cycle is triggered, the client will download and install the required updates. Upon successful completion of installation, the client sends the state message (ID: 301) to the Management Point.  Like the scan state message, this message is also processed at the site server and replicated up the hierarchy.

As a result of the installation of the updates, the data that is now seen in ConfigMgr DB views will look like below:

Note that the client TEST1 has successfully reported status for the applicable CI (CI ID: 207819) as Installed, and it shows as Not Applicable for the other 15 CI IDs.

The scenario we have seen so far is when a client has scanned and installed the required updates successfully, at the same time also have reported status for not applicable CIs.

In the next post, we shall take a look at a different scenario where the status of CI is seen as Unknown in the ConfigMgr DBs for some clients. We will dig into this a little deeper to understand the possibilities and ways to mitigate Unknowns. In the process we will also discover that not all unknowns are True Unknowns, and indeed there are some False Unknowns in the mix.

Feedback/Comments are welcome. If you want to know about any other topic please let us know and we will be happy to blog about it.

-JitenRK