The release of System Center Configuration manager has seen a vast improvement in security update management. The improvements have introduced new ways of doing familiar tasks
No Security updates compliance at the parent site without a SUP:
Prior to Config Mgr 2007 software update compliance information propagated up the SMS hierarchy following a parent child connection. No additional configuration was required once the parent child relationship was established. Each child site could manage software updates with no dependency on components at the parent site. The new version of SMS has removed this functionality. In order for a parent site to receive software updates compliance information a new component setting has to be enabled (Software Updates Point –SUP). The new SUP role forms its own hierarchy where only the highest SUP in the hierarchy synchronises directly with the internet for new software updates availability. Child site SUPs will not be updated until the parent site SUP is updated.
The ability to use a central site for consolidated reporting is no longer possible without adding this additional layer in you Config Mgr design. Another challenge is the ease of creating summary reports on security update compliance. The new state message based reports though excellent will present challenges for seasoned SMS administrators tasked with creating management summary reports.
How to get compliance information at a parent reporting site without a SUP:
This is how to get summary security update status to your parent sites without creating a SUP hierarchy. The solution uses the hardware inventory process to collect summary security update information. This is basic security update information and ideal for creating your management reports. This does not remove the requirement for a SUP at the client’s assigned site.The status of an update is either installed or missing. The information also depends on the old time lag required to receive hardware inventory information from clients.
Steps are as follows:
Edit the SMS_DEF.MOF file and append the reporting class data at the end of this article
Stop sms_executive on parent site
Change sms_def.mof file in: %ConfigMgrInstallDir%inboxesclifiles.scrhinv (Append the class CCM_UpdateStatus at the end of the file.)
Start sms_executive on the parent site
Repeat steps 2-4 for child site where the SUP is installed
Make sure policy is updated on clients assigned to child site
Run scan/install updates on the clients
Run HINV cycle on client (or wait for cycle to run per schedule)
Check dataldr.log on the child site, once HINV is received; Software_Updates_V4_DATA table is created in the database with all the info as per the class below.
Same table gets created on the parent site’s database as well
NB: There is no need to compile the SMS_DEF.MOF as this is now done by the site server and clients updated through policy changes. Test this on a lab instance before applying to production sites.This has been tested on Config Mgr 2007 SP1. Append this to the SMS_DEF.MOF:
//————————————-
// SMS – Software Update Status
//————————————-
[SMS_Report(TRUE),
SMS_Group_Name(“Software Updates v4”),
SMS_Class_ID(“MICROSOFT|UPDATESTATUS|1.0”),
Namespace(“\\.\root\ccm\SoftwareUpdates\UpdatesStore”)]
class CCM_UpdateStatus : SMS_Class_Template
{
[SMS_Report(TRUE), Key]
string UniqueId;
[SMS_Report(TRUE)]
string Title;
[SMS_Report(TRUE)]
string Bulletin;
[SMS_Report(TRUE)]
string Article;
[SMS_Report(TRUE)]
string Language;
[SMS_Report(TRUE)]
string SourceUniqueId;
[SMS_Report(TRUE)]
DateTime ScanTime;
[SMS_Report(TRUE)]
uint32 SourceVersion;
[SMS_Report(TRUE)]
uint32 RevisionNumber;
[SMS_Report(TRUE)]
string Status;
[SMS_Report(FALSE)]
CCM_SourceStatus Sources[];
};
In my next article I will provide details of reports which can be created using data from this class, including an SQL view.
