One of the biggest advantages to using Configuration Manager to manage software updates is the ability to integrate them into the OS deployment process, enabling delivery of a more secure, up-to-date image to the end user. When managing a Windows XP image, integrating software updates into your image meant a complete rebuild of the image. Otherwise, you had to rely on the Install Software Updates task to apply available updates to the Operating System with the OS booted and online. Moving to Windows 7 and leveraging MDT integration in SCCM 2007, we could use the Apply Updates Offline task to apply these security updates before the OS ever booted, making it a faster and more secure option. The same Deployment Package used to distribute updates to existing clients could be used to apply the updates to the offline image, or a separate Deployment Package could be created in the Software Updates node and specifically managed for OSD support.
With the introduction of the Content Library in Configuration Manager 2012, the integration for offline updates becomes a little more complicated. When you add the Install Updates Offline task to the Task Sequence and go to select your Update Deployment Package, all you see are the standard packages.
Why is this? Well, normal Packages have a file in the PkgLib directory of the Content Library that in turn references a corresponding package directory in the DataLib folder containing information about the content files (The chain actually goes much further to include hash files and so forth, but you get the picture with how ConfigMgr stores content).
However, Software Updates each have their own individual corresponding folder in the DataLib directory, so the PkgLib file for an Update Deployment Package references all of the individual updates in the DataLib directory. Among other things, this allows for the single instance storage that makes the Content Library more efficient by eliminating the need to keep multiple copies of the same Software Update files.
The Update Deployment Package also appears as a different PackageType in the ConfigMgr database:
The result is that it will not show up on the v_SMSPackages view (which itself is a select * from the vPackage view) as this view only shows Packages with PackageType = 0.
Great. Fascinating. So….how do we leverage MDT integration in ConfigMgr 2012 to perform the offline updates using our Software Updates Deployment Packages? We do a little slight of hand!
Since the Install Updates Offline task looks for a standard Package, we’ll give it a standard Package. When an Update Deployment Package is created (either through the Deploy Software Updates Wizard or the Download Software Updates Wizard), a share location must be created and specified for the updates to be stored. The updates are downloaded to individual subfolders in that location. As it turns out, this will suit our purpose nicely for creating a standard Package and works fine for the ZTIPatches.wsf script (the actual MDT script that does all the work for the Install Updates Offline task). Simply point the source folder to the package source of the Update Deployment Package*…
…distribute your content, and you now have a usable Package for the Install Updates Offline task!
While this presents a little extra initial work over and above what was required with SCCM 2007, consider the fact that you can now leverage the advanced features in ConfigMgr 2012 to streamline your processes. For example, you could set up an Automatic Deployment Rule which runs on the second Tuesday of every month (Patch Tuesday) to pull down the latest updates for Windows 7 with Severity of “Critical” and Classification of “Critical Updates” or “Security Updates.” When the rule evaluates it will add the updates to the existing Deployment Package. By setting your standard Package, pointed to the same source location, to update Distribution Points on a corresponding schedule, you can then automate the inclusion of Critical updates in your OS deployment process. Out-of-band critical patches are handled as simply as running the ADR, then updating the DPs for the Package. While I would advise caution with this approach and recommend implementing a review and testing policy to ensure this type of auto-approval of patches doesn’t cause major problems in your environment, you can see the type of process automation and streamlining that can be gained from this new functionality.
*One important caveat: You’ll need to create the Software Update Deployment Package FIRST and only create the standard Package after that. If you try to specify a path for the Software Update Deployment Package that already has content, it will generate an error:
The package source has already been used. Specify an alternative source directory.
(Thanks to Michael Niehaus and Andrew Berges for the initial discussions on this one)