Powershell Script To Report MS Updates Compliance Status on SCCM Client

I have recently been working on writing a Server Build Audit in Powershell. One of the difficult things to validate was whether or not a server had applied all of the required Microsoft Security Updates. We use SCCM 2007 for our Microsoft Patch deployment, and I have created SQL reports that put all of this information together from the database. I knew that most of the database structure and content also resides in the Site Systems WMI repository (root\sms\site_[sitecode]). After digging around, I eventually found this information and decided to post it here.

-----------------------------------------------------
param ($siteSystem, $siteCode)
#Get the Client Name
$system = Get-WmiObject Win32_ComputerSystem
$systemName = $system.Name

#Query the Site Systems WMI for the Clients ResourceID
$sccmSystem = Get-WmiObject -computerName "$siteSystem" -namespace "root\sms\site_$siteCode" -class "SMS_R_System" -Filter "NetbiosName = '$systemName'"
$sccmID = $sccmSystem.ResourceID

#Query for the compliance status of the Client
$CIs = Get-WmiObject -computerName "$siteSystem" -namespace "root\sms\site_$siteCode" -class "SMS_UpdateComplianceStatus" -Filter "MachineID = '$sccmID'"

#Match the various Updates the client has reported to the details of the update
Foreach ($CI in $CIs) { $currCI = $CI.CI_ID
$update = Get-WmiObject -computerName "$siteSystem" -namespace "root\sms\site_$siteCode" -class "SMS_SoftwareUpdate" -Filter "CI_ID = '$currCI'"

#I have filtered for only security updates, hence the -like MS*
if ($update.BulletinID -like 'MS*')
{ if ($CI.Status -eq '3') { $tf = "Installed" }
else { $tf = "Applicable" }

$msNum = $update.BulletinID
$item = $update.LocalizedDisplayName

write-host $msNum
write-host $item
write-host $tf
write-host "-*-*-*-*-*-*-*-*-*-*-*-*-*-*-"
}
}

-----------------------------------------------------

To use this script, simply copy the text between the "------", paste it in to a text file (Notepad), and save it as "msUpdates.ps1". To run the script,
Open PowerShell

1. Make sure that you have set the execution policy to at least remoteSigned
2. cd to the directory where you've saved msUpdates.ps1
3. Run the following: ./msUpdates "[SCCM Site System]" "[SCCM Site Code]"
   

I have provided variables so that you can output the results however you wish. Here, I have simply printed the output to the console.

SCCM Client Log Error: Error retrieving manifest (0x80070003)

The last several days I have noticed that our SCCM clients were not installing a particular set of Software Updates. It was consistently the same Deployment Package. I noticed in the DataTransferService.log file the following error:

Error retrieving manifest (0x80070003). Will attempt retry 1 in 30 seconds.

The retry attempts as well as the retry time frame continued to grow with each iteration. None of the recommendations I found through my googling proved successful. Finally, today, I decided to look at the actual package itself on my Distribution Points. I noticed that only a portion of the updates in the Deployment Package were actually there. My fix turned out to be selecting all of the Software Updates in my Deployment Package, right-click, and select Content Refresh. This downloaded all the Software Updates again. I then updated my Distribution Points and our clients began installing the Software Updates.

SCCM Deployments With Maintenance Windows : Part III

As stated previously, Microsoft System Center Configuration Manager (SCCM) 2007, with the introduction of Maintenance Windows, has made recurring scheduled maintenance a much easier task. In Part I, I provided a basic overview of SCCM Maintenance Windows with some key points. In Part II, I provided several not-so-obvious pitfalls and how to avoid them. In this section, Part III, I will provide some strategies that I have found extremely useful.

Protecting Clients (and yourself...)

The very first thing that I would recommend is to set a Maintenance Window in the past, with "Recurrance pattern" set to None, on an All Client Systems Collection. I would use 12/25/2006, from 6:00PM to 6:01PM. This will ensure that all clients are participating in Maintenance Window-style deployment and a client won't inadvertently execute a deployment. As I stated in Part I and Part II, if a client does not have a Maintenance Window defined a 24x7 Maintenance Window is implied.

The Implimentation

Once all clients are protected from a 24x7 Maintenance Window, a maintenance schedule and strategy must be defined. A very common strategy that I've seen for creating the Collections that Maintenance Windows will be defined is to create a Query-based Collection leveraging Active Directory Security Group Membership. This provides a flexible way to group Clients. Workstations can be grouped by department, etc. Servers can be grouped by role or function and spread out across multiple windows for uptime.

The design will most likely be the most complex part of the process. The implimentation is actually very simple. Once the Collections have been created and populated, simply right-click the Collection and select Modify Collection Settings and define your Maintenance Window. Keep in mind that the Maintenance Window duration must be long enough to accomodate the desired deployment(s).

Now that everything has been set up, it's time to trust the application to do what it is supposed to. A Software Updates deployment containing all of Microsoft's Security Updates (those with MS numbers) is a great place to start. If one has not previously been created, create a Software Updates List, and Deployment containing all of the MS07 Security Updates (if desired, remember to change the 20 min Maximum Runtime) and deploy it against the All Client Systems Collection. The following settings should be in place on the Deployment:

• Advertisement Start Time should be set for the current time
• Mandatory Assingment Deadline should be set for the current time (allowing clients to download prior to their scheduled Maintenance Window)
• Do NOT Ignore Maintenance Windows
• Do NOT allow System Restarts outside of Maintenance Windows

Since all of our Clients are protected by the Maintenance Window defined for one minute on Christmas day of 2006, only the Clients in our newly defined Collections with the defined Maintenance Windows will ever deploy, and according to their defined Maintenance Window.

More Deployment Techniques Utilizing This Strategy

The Immediate Baseline Approach:
At times, say during a new Workstation or Server build, the deployment of a desired baseline must take place in a prompt fashion. Utilizing the concepts discussed previously, if the desired baseline is advertised to the All Client Systems Collection, all that is required is to create a 24x7 Collection (I would personally label it as such to keep it obvious) with a 24 hour Maintenance Window defined with a Daily "Recurrance pattern". Now, in order to deploy the desired baseline immediately, simply add the client to the 24x7 Collection. The Client will pick up its baseline as soon as it becomes a part of the All Client Systems Collection and then pick up its Maintenance Window from the 24x7 Collection. This process can be expedited by initiating a Machine Policy Refresh and (if applicable) a Software Updates Evaluation Cycle on the Client system. Remember to Remove the Client from the 24x7 Collection as soon as it reaches compliance.

Deploying To A Subset of Clients While Abiding By Their Respective Maintenance Windows:
Recently, I created a Task Sequence containing Adobe Reader and Acrobat Updates that was to be deployed during our normal, scheduled Maintenance Windows. The Task Sequence was set to reboot the Clients at the completion of the Update(s) installation, so I only wanted to advertise this to Clients that actually required the Updates. I created a Query-based Collection containing all of the clients I wanted to Advertise my package to and then Advertised my Task Sequence to that Collection. The Advertisement settings did not "Override Maintenance Windows", was set to "Always Re-run" (as it is now part of our desired baseline), and I did not set an Expiration. Now, this subset of Clients that require Adobe Updates will install them during their normal, scheduled Maintenance Windows.

SCCM Deployments With Maintenance Windows : Part II

Microsoft System Center Configuration Manager (SCCM) 2007 provides a very powerful means of deployment in an enterprise environment. One of the canned tools that has made my deployment experience in SCCM 2007 worlds easier than in SMS 2003 are Maintenance Windows. In Part I, I gave a brief overview of Maintenance Windows in SCCM. To follow that up, I am providing some of the not-so-obvious pitfalls I've discovered while using them.

Maintenance Window Is Not Defined

In SCCM 2007, if a Maintenance Window is not defined for a particular client, a 24x7 Maintenance Window is inferred. When an Advertisement or Software Updates Deployment is created, if the "Override Maintenance Windows" checkbox is not checked and, assuming there is a "Mandatory Assignment", a client without a Maintenance Window will execute at the Mandatory Assignment Deadline.

Maintenance Window's Are Cummulative

My initial understanding was that if I define a Maintenance Window for a particular collection and advertise to that collection utilizing Maintenance Windows, the Advertisement/Software Updates Deployment would abide by the Maintenance Window defined for that particular collection. This is not necessarily true. In SCCM 2007, Maintenance Windows are cummulative, meaning that if a client is a part of two collections, and each have their own defined Maintenance Window, both windows apply to any Advertisement/Software Updates Deployment to that client. As I stated previously, the only way to avoid this type of behavior is to select the "Override Maintenance Windows" checkbox.

Maintenance Window Duration

By default, all Software Updates are set with a Maximum Runtime of 20 minutes. Anytime I see that a client has downloaded my deployment to its Cache folder and that the ServiceWindowManager.log says "Program can run! Setting *canProgramRun to true", however, my Software Updates are not running, the first thing I check is the Maintenance Window duration and the Maximum Runtime on the Software Updates. Upon creating a Software Updates package, I always try to remember to change the Maximum Runtime to 5 minutes (in the Properties for a particular deployment).

SCCM Deployments With Maintenance Windows : Part I

Maintenance Windows in SCCM 2007 can provide a powerful means of deployment management. However, as with all power, it can be used for evil and/or good. A thorough understanding of Maintenance Windows is critical prior to implementation in a production environment. One mishap can potentially cause a serious outage, and have Change Management looking for you. My hope is that between Part I, Part II and Part III, I'll help fellow SCCM Admins better understand Maintenance Windows, and, hence, avoid some of the pit-falls that most texts seem to leave out.

The idea behind Maintenance Windows is that you can create a Collection of Clients and apply a "window", during which those Clients can be brought into compliance with a certain baseline. In order to utilize a Maintenance Window, you create Advertisements and/or Software Updates Deployments that do not have an expiration. Assuming the mandatory assignment is in the past, once the Maintenance Window begins, the Clients will begin executing the various Programs and/or Software Updates that have been assigned. Sounds simple enough, right? Well, they're tricky.

The first thing to understand is that Maintenance Windows are not per Collection, but, rather, per Client. What this means is that while you set the Maintenance Window at the Collection level, it applies to the Clients in that Collection. A simple example will help illustrate this. Say we have three Clients, Client1, 2 and 3, and three Collections, Collection1, 2 and 3.

• Client1 is in Collection1 and Collection2


• Client2 is in Collection1 and Collection3


• Client3 is in Collection1


• Collection1 does not have a defined Maintenance Window


• Collection2 has a Maintenance Window defined as the 1st of every month from 3AM to 5AM


• Collection3 has a Maintenance Window defined as every Saturday from 3AM to 5AM

So, what happens if I create an Advertisement with a mandatory assignment of 8:00PM on June 30, 2009 (a Tuesday) and send it against Collection1 and do not set it to "Override Maintenance Windows"?

• Client1 will execute at 3AM on July 1, 2009 because of the Maintenance Window defined for Collection2.


• Client2 will execute at 3AM on Saturday, July 4th because of the Maintenance Window defined for Collection3.


• Client3 will execute at 8:00PM on June 30, 2009, because it is only in Collection1, which does not have a Maintenance Window defined.

What happens if while creating the Advertisement above, I set an Advertisement expiration to 12:00AM on July 1, 2009? Client1 and Client2 never execute the advertised program, while Client3 executes at the mandatory assignment time of 8:00PM on June 30, 2009.

In conclusion, the following points should be noted:

• Maintenance Windows are per Client, not per Collection


• A deployment advertised to a particular collection does not abide solely by the Maintenance Window defined for that collection


• A Client with an undefined Maintenance Window will execute at the Mandatory Assignment


• The duration of your Maintenance Window must be long enough to cover the accumulative Maximum Run Time

Continue to Part II...