Understanding Software Updates in SCCM 2007

Configmgr 2007 comes with a totally new way of deploying software updates. The new method offers some great advantages over the old one(s) available in Sms 2003. It didn't take me too long to see the benefits the new architecture brings, but it did take me quite some effort in understanding how I could create a working operational process to maximize these benefits, it actually took a fellow mvp (Thanks Pannu) and Wally to set things straight in my head (Thanks Wally). This 2 -series post will try to give you some insight in how the Configmgr 2007 solution stacks up with the sms 2003 implementation. The second portion will explain the objects involved and will guide you through a potential implementation of Software updates in Sccm 2007.

Let's start by briefly explaining how the sms 2003 infrastructure operates, followed by the currently known issues. Later in this post we'll review what the Sccm 2007 architecture looks like, and how this new architecture deals with the known issues of the past.

In sms 2003 the backend infrastructure relied on software distribution packages and advertisements to initiate the sofware catalog download, the software update scan and patch installation processes. The scan process itself, using the final scan engine itmu, was based on the Windows automatic update agent. The scan engines prior to that were sms specific engines like the software update inventory scan tool, the office update inventory scan tool or the extended software update inventory tool. Clients have always reported their software update compliance state based on hardware inventory regardless of the scan engine used.

One of the downsides of the sms 2003 infrastructure was the fact that multiple scan engines were necessary, which complicated the software update management quite a bit. And no matter what engine you used, all engines first downloaded the catalog locally and cached it in a specific folder prior to starting the scan. This caching of the catalog files didn't always work flawlessly resulting in clients scanning with an old catalog which obviously didn't report the expected information. Another issue was the fact that the reporting process relied on hardware inventory to do its reporting, this resulted in a slower and not very flexible reporting process.

Now let's look at how this all works in sccm 2007. Sofware updates now integrates/relies on a Wsus 3.0 server. The Wsus server is used to download the catalog and to serve as the "scan point" for the Configmgr2007 clients. This eliminates the problem that the sms 2003 engines had with caching the catalog, because the clients now scan directly from a wsus server. Another benefit of this integration is the increased content that can be deployed. The sms 2003 engines only supported security updates whereas wsus 3.0 supports a wide variety of updates ranging from security updates over critical updates, feature pack, service packs, drivers and more. All these benefits come at a fairly low cost, yes you now need to install a wsus server but all management of this wsus server is done from the Sccm 2007 admin console. (This is why you need to install the wsus admin console on the site server if you want to use a remote wsus server).

Another major change afaic is that clients now report their software update compliance state based on state messages. This allows for faster more flexible and more detailed status reporting from the clients to flow up to the server.

The above view is presented by Kim oppalfenss (My one of the favourite SMS Expert).