This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.
First published on TECHNET on May 02, 2011In 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).
BulletinID |
CI_ID |
Title |
Applicable OS |
MS11-019 |
207750 |
Security Update for Windows Embedded Standard 7 (KB2511455) |
Windows 7 Embedded |
MS11-019 |
207756 |
Security Update for Windows Server 2008 R2 for Itanium-based Systems (KB2511455) |
Windows Server 20008 R2 for Itanium-based System |
MS11-019 |
207787 |
Security Update for Windows Server 2008 for Itanium-based Systems (KB2511455) |
Windows Server 2008 for Itanium-based Systems |
MS11-019 |
207815 |
Security Update for Windows Vista for x64- based Systems (KB2511455) |
Windows Vista for x64 |
MS11-019 |
207819 |
Security Update for Windows 7 for x64- based Systems (KB2511455) |
Windows 7 for x64 |
MS11-019 |
207856 |
Security Update for Windows Server 2008 x64 Edition (KB2511455) |
Windows Server 2008 x64 |
MS11-019 |
207860 |
Security Update for Windows Vista (KB2511455) |
Windows Vista |
MS11-019 |
207941 |
Security Update for Windows Server 2003 x64 Edition (KB2511455) |
Windows Server 2003 x64 |
MS11-019 |
207966 |
Security Update for Windows XP (KB2511455) |
Windows XP |
MS11-019 |
207977 |
Security Update for Windows Server 2008 (KB2511455) |
Windows Server 2008 |
MS11-019 |
207979 |
Security Update for Windows Server 2008 R2 x64 Edition (KB2511455) |
Windows Server 2008 R2 x64 |
MS11-019 |
208071 |
Security Update for Windows Server 2003 for Itanium-based Systems (KB2511455) |
Windows Server 2003 For Itanium-based Systems |
MS11-019 |
208102 |
Security Update for Windows Server 2003 (KB2511455) |
Windows Server 2003 |
MS11-019 |
208213 |
Security Update for Windows Embedded Standard 7 for x64-based Systems (KB2511455) |
Windows Embedded Standard 7 for x64- based Systems |
MS11-019 |
208549 |
Security Update for Windows 7 (KB2511455) |
Update for Windows 7 |
MS11-019 |
208566 |
Security Update for Windows XP x64 Edition (KB2511455) |
Windows XP x64 |
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.
BulletinID |
CI_ID |
Title |
Machine |
Status Name |
MS11-019 |
207815 |
Security Update for Windows Vista for x64-based SystemsKB2511455) |
Test1 |
Not Applicable/Unknowns |
MS11-019 |
207819 |
Security Update for Windows 7 for x64-based Systems (KB2511455) |
Test1 |
Required/Installed/ Unknowns |
MS11-019 |
207856 |
Security Update for Windows Server 2008 x64 Edition (KB2511455) |
Test1 |
Not Applicable/Unknowns |
Now let’s see where and how this data is stored in ConfigMgr SQL database views.
View Name |
Description |
Status values |
v_UpdateComplianceStatus |
Stores information about Required/Installed CIs for clients |
Required: 2 |
Installed: 3 |
||
v_UpdateComplianceStatus_ NotApplicable |
Stores information about Not Applicable CIs for Clients |
Not Applicable: 1 |
v_UpdateComplianceStatus_ Unknown |
Stores information about CIs for which status is Unknown from clients |
Unknown: 0 |
v_Update_ComplianceStatusAll |
Consolidated view of data from above 3 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:
Name |
Sample Data |
Remarks |
ResourceID |
1 |
|
ScanPackageVersion |
1234 |
Version of SUP catalog |
LastScanPackageLocation |
|
Name of the SUP where the client scanned against. |
LastScanState |
3 |
Scan Status result as reported by the client |
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.
BulletinID |
CI_ID |
Title |
Machine |
SQL View |
Status Name |
MS11-019 |
207815 |
Security Update for Windows Vista for x64-based Systems (KB2511455) |
Test1 |
v_ UpdateComplianceStatus _NotApplicable |
Not Applicable(1) |
MS11-019 |
207819 |
Security Update for Windows 7 for x64-based Systems (KB2511455) |
Test1 |
v_ UpdateComplianceStatus |
Required(2) |
MS11-019 |
207856 |
Security Update for Windows Server 2008 x64 Edition (KB2511455) |
Test1 |
v_ UpdateComplianceStatus _NotApplicable |
Not Applicable(1) |
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:
BulletinID |
CI_ID |
Title |
Machine |
SQL View |
Status Name |
MS11-019 |
207815 |
Security Update for Windows Vista for x64-based Systems (KB2511455) |
Test1 |
v_ UpdateComplianceStatus _NotApplicable |
Not Applicable(1) |
MS11-019 |
207819 |
Security Update for Windows 7 for x64- based Systems (KB2511455) |
Test1 |
v_ UpdateComplianceStatus |
Installed(3) |
MS11-019 |
207856 |
Security Update for Windows Server 2008 x64 Edition (KB2511455) |
Test1 |
v_ UpdateComplianceStatus _NotApplicable |
Not Applicable(1) |
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