This is the Software Updates page on the System Center WIKI at System Center Central.  

This information courtesy of Jason Sandys, MVP and member of the SCCM Unleashed authoring team. This information originally appeared in Jason's technical interview in "Ask the Expert". Read his full interview HERE.

Software Updates Administration and Best Practices in SCCM 2007

Software Updates in ConfigMgr uses the following five nodes in the console tree:

Update Package – The actual update files. There is no correspondence between Update Packages and Deployments. As long as the update is in an accessible package, the client will be able to use it. Clients only pull updates that they need from a package. The only best practice with regard to packages is to limit the number of updates per package to 500. Typical usage of packages is to contain all patches for a single calendar year, regardless of OS or other criteria. There is no real reason to separate updates into separate packages except for the 500 update limit.

Update Repository – The update repository is an organized listing of all updates available as reported by WSUS. WSUS in turn synchronizes its catalog from the Microsoft update servers.  Search folders can also be created in the Update Repository to specify custom criteria for organizing updates.  Note that these search folders are based on queries which are dynamically updated.

Update Lists – Updates can be added to an Update List for further organization.  Update Lists are containers for updates; they facilitate downloading and deploying updates.  Once updates are added to an update list, they can be downloaded by right-clicking on the list and selecting Download Software Updates.  This initiates a wizard which allows the user to specify where to store the updates, which package to add them to, and which languages to download.  Additionally, deploying updates in a list involves right-clicking on the list and selecting Deploy Software Updates.  A separate wizard is launched to create a deployment; this wizard is used to select a Deployment Template and schedule the deployment.

Adding updates to a list can be thought of as “approving updates for deployment”. Although technically acceptable, new updates should not be added to existing lists; new lists should be created for every patch cycle.

 Deployment Template – Deployment Templates store many of the deployment settings and are used to automatically populate these settings when creating deployments such as which collection the deployment applies to, notification settings, restart settings, download settings, and scheduling.

Deployments – Deployments are what tell a collection which updates are available to the systems that are members of that collection and when those updates become mandatory. Deployments define the following information:

·         Target collection

·         Included updates

·          Schedule

·         Restart settings

·         Notification settings

Individual deployments should be created from each update list using a deployment template. This applies all of the settings defined in the template to the updates referenced in the update list; the best way to accomplish this is to drag the update list to a template and complete the wizard. Note that although deployments are created from update lists, there is hard-link between these two objects. Updates references are simply copied from the list to the deployment.

 Deployment Packages – As with all other files deployed by ConfigMgr, updates used with Software Updates must be stored in a package. These packages are specific to Software Updates however. Actual location of updates in packages is unimportant as long as the update is available in a package accessible by the client.

Updates should be added to the appropriate package as they are downloaded. A new package should be created every calendar year. The only recommended limitation on packages is to limit the number updates per package to 500. Once updates are added to a package, ensure that the package is updates on all applicable DPs.

Philosophy - Although flexible, the configuration of Software Updates can quickly become cumbersome if the process is not planned correctly. 

The recommended path to follow for configuration is as follows:

                        Figure 1 - Decision Tree for Update Management in SCCM 2007

1.       Determine Applicable Updates – Use search folders and the update repository for this step every time new updates are available or applicable.

2.       Create New Update Lists – Create new lists for the patch cycle (typically the month the patches are released) for each type of update: one for server 2003 and one for 2008.

3.       Download Updates – Use an existing update package unless it is a new calendar year, then create two new packages: one for server 2008 and one for server 2003.

4.       Create Deployments – Drag and drop each update list to the appropriate Deployment Template. Verify the information in the deployment.

The end result is a new update list and new deployment for each update type (server 2003 and server 2008) and every patch cycle.

In general, every update cycle (usually monthly), do the following:

ü  Create Update list with new updates. Download updates when creating list and add to package.

ü  Drag Update list to template(s) to create new deployment. Verify deadline.