System Center

New Software Update Management Tools

Steve Rachui

At a Glance:

• Update management the old way
• The new process in SCCM 2007
• Custom configuration and flexibility
• Finely tuned update scheduling

Software update management was first introduced in Systems Management Server (SMS) 2.0 with the security and Office updates scan tools. These tools have undergone multiple revisions: the extended

security update inventory tool was revised to support scanning of additional products; the Inventory Tool for Microsoft® Updates to combine the security and Office tools into a single product; and the Inventory Tool for Dell Updates. The Custom Updates Publish Tool was also introduced to support patching third-party products. The Inventory Tool for Microsoft Updates (ITMU) has seen three revisions of its own. Each of these tools has its own catalogs, scanning infrastructure, and unique requirements and challenges. Over time, the catalogs for these systems became notably large, so large, in fact, that older updates were removed in favor of new ones due to size constraints.

With the array of options, deploying updates with these tools could be challenging. Clearly, there was a need to simplify the process. The next release of SMS—System Center Configuration Manager 2007 (SCCM) makes great strides in that direction. With SCCM, the software updates mechanism is built to ensure better bottom-line results. With a completely different approach to update management operations, old catalogs and scan engines are a thing of the past. Update status, historically reported via hardware inventory, uses a new mechanism—the state message—to ensure better determination of compliance as well as enforcement on each client. I think you'll see that the new approach to update management in SCCM 2007 represents a significant improvement.

SCCM 2007 introduces two new components that I'll discuss before we delve into the update management functionality.

Software Update Point (SUP) As I mentioned, catalogs no longer exist in SCCM. Instead, SCCM works directly with a dedicated Windows Server® Update Services (WSUS) server, which will act as a Software Update Point (SUP) to provide metadata downloads and client scanning. In SCCM, the update binary delivery features of the WSUS are disabled to allow focus on the scanning process. With this adjustment, WSUS scales to handle scanning for up to 25,000 clients per SUP on a dedicated server. SCCM also allows configuring the SUP behind a Network Load Balancing (NLB) cluster for increased availability and scale, enabling up to four SUPs for a total of 100,000 possible clients per primary site.

Configuration Items (CI) A configuration item is a new approach used in SCCM to define specific configurations that should exist on target systems. SCCM update management now uses this infrastructure. Updates should no longer be thought of in terms of normal software distribution—although there are still similarities. Instead, updates reside in their own node in the administrator console and use this completely unique CI mechanism. On the client side, updates are selectively downloaded and stored locally.

Configuring Update Management

Setting up update management falls into three general areas—enabling the client agent, configuring the SUP and configuring updates for distribution.

The SCCM client agent (as shown in Figure 1) is similar to other client agents and is configured in the same node of the administrative console. The properties page of the Software Updates Client Agents node is where administrators enable this agent and configure update installation and Deployment Re-evaluation settings. The setting to enable the Software Updates Client Agent is site-wide, meaning every SCCM client assigned to the site where this function is turned on will have this role enabled. If some systems in an environment should not have this function enabled, you can override the site-wide setting on a per-system basis using local policy override settings.

Figure 1** Client agent properties **

The settings here also allow the administrator to specify how to handle update deadlines. Assume, for example, you have four updates pending installation, one (update A) with a deadline a day ahead of the other three. But suppose it's preferable to install all four updates at the same time—even those whose deadline hasn't yet been reached. The option on this tab to Enforce all mandatory deployments lets you configure this choice. Further, the settings here allow administrators to specify that all notifications and visible indications of the updating process should be suppressed. These options are shown in Figure 1.

The settings on the Deployment Re-evaluation tab allow administrators to schedule when deployments are reevaluated. SCCM clients will be evaluated according to this schedule to see if updates that have been previously installed are still required and, if they are missing, reinstall them.

Configuring the SUP

As mentioned previously, the SUP is the component responsible for downloading all available update information on a schedule and for interacting directly with SCCM clients to perform compliance scans based on its database of updates. Before a SUP is configured, a WSUS 3.0 or greater server must be installed as the SUP process does not actually install WSUS—it just configures WSUS for SCCM use. Additionally, the WSUS Administrator Console must be installed on the Site Server to enable connectivity with the WSUS Server. Once SCCM takes over the WSUS server for the SUP role, the WSUS server is dedicated to SCCM and can only be used by SCCM clients.

The SUP is a new site system role in SCCM. To begin configuration, navigate to the site systems node of the administrator console and add a new site system. The next step is to select Software Update Point and proceed through the wizard, which will collect the following information:

• Proxy configuration
• Port and SSL information
• How this SUP should sync updates—from Microsoft Update, via an upstream SUP, or manually
• Synchronization schedule
• Update classifications of interest, such as Critical Updates, Drivers, Security Updates, Update Rollups, and so forth
• Update products available—Windows®, Exchange, SQL Server™, and so on (shown in Figure 2)
• Language

Figure 2** Product settings in the site role wizard **(Click the image for a larger view)

When the wizard is complete, the SUP will be installed and internal configurations will be adjusted to support SCCM requirements. It's a good idea to confirm that the installation succeeded by reviewing the SUPSetup.log located in the logs folder where SCCM was installed.

Once the SUP is installed, synchronization must be performed to cause the SUP to retrieve updates and store them in the SUP and SCCM database. The synchronization may either be run manually or on a schedule configured when the SUP setup wizard runs. Manual update synchronization may be initialized at any time and it's a good idea to ensure the synchronization happens after the SUP is installed the first time. Figure 3 shows how to do this.

Figure 3** Running synchronization manually **(Click the image for a larger view)

The synchronization process has two steps. First, the SUP (WSUS) server is configured to match the SCCM settings and configured updates are synchronized to the SUP (WSUS) server itself. When this is complete, the update information from the SUP (WSUS) is synchronized into the SCCM database and made available for update deployment. This second step creates the required CIs (one for each software update) in the SCCM database and may be time-consuming. It is not unusual for the initial synchronization to take several hours. The synchronization process may be reviewed in the WSyncMgr log, an excerpt of which is shown inFigures 4 and 5. Specifically, Figure 4 shows the sync process requesting that the SUP (WSUS) server update its list of updates from Microsoft Update. Figure 5 shows the start of the process for synchronizing the SUP inventory to the SCCM database.

Figure 4** Synchronizing update list **(Click the image for a larger view)

Figure 5** Synchronizing the updates as CIs in the SCCM database **(Click the image for a larger view)

Once a WSUS server is configured as a SUP, any required administration can be accomplished via the SCCM Admin console. If configuration changes are made directly to the WSUS server, SCCM could be adversely affected. Further, these configurations will be reset hourly when SCCM checks its SUP to ensure configurations are correct.

In a multitiered hierarchy, you need to have at least one SUP at each primary site where software updates will be deployed. These SUPs will work together in a hierarchy with only one SUP, generally the one highest in the hierarchy, synchronizing with Microsoft Updates. The remaining SUPs will synchronize from a configured upstream SUP replication partner.

Configuring Update Deployment

Once the client agent is configured and the SUP configured and synchronized, you are ready to prepare an actual deployment. First, let's review the various nodes of the SCCM admin UI. Basically, there are five main nodes of interest—Update Repository, Update Lists, Deployment Templates, Deployment Management and Deployment Packages.

The Update Repository is where all of the synchronized updates are stored and available for deployment. Updates may be deployed by selecting one or more updates and launching the Deploy Software Updates wizard, which performs two tasks: configuring the deployment template (or selecting one that already exists) and configuring the deployment itself. I'll discuss this process shortly. The list of updates can get quite large and search folders, a new feature in SCCM 2007, can help greatly in finding updates of interest based on 28 update-related criteria, including Severity, Classification, Product, Date Released, and Supersendence.

Update lists allow admins to create a fixed set of updates to be managed. They can be used for compliance reporting, creating deployments, and administration delegation. Once built, these update lists are replicated down the hierarchy for reuse at child sites—just like packages or advertisements. Update lists are not tied to any particular deployment when replicated; they are just lists of updates. Once the list is complete and replicated, the updates within it may be deployed as a unit by selecting the list and choosing to deploy the updates.

Deployment Templates

Deployment templates contain common settings (such as schedule and target collection information) used during software update deployment and were developed to decrease the administrative time involved with deploying updates. Templates may be created to address multiple deployment conditions in an environment and they can be used in the deployment wizard by simply selecting the appropriate template. Settings prepopulated by the deployment template include the target collection, update deadline settings (as shown in Figure 6), restart settings, and maintenance windows. When large numbers of updates are in a deployment, the target system performance can be impacted as each updates deadline arrives simultaneously. Moreover, note that settings within the template are applied to the deployment when the deployment is created. Those settings remain in force on the deployment unless manually modified within the deployment. It's important to remember that simply modifying the template settings themselves at a later time will not cause the modified settings to be changed on existing deployments that use the modified template.

Figure 6** Setting deployment schedules in the wizard **(Click the image for a larger view)

The options in Figure 6 may be configured while running either the deployment template wizard or the deploy software updates wizard (if a new template is being created). Notice that the duration setting in this screen is set to 0. The default value for this setting is two weeks. If this setting is set to a value other than 0, there will be a delay on the client of up to the length of that value before updates are deployed. In the time between when the deployment is made available and the configured deadline is enforced, the update will be available for manual install by end users for pre-deadline scheduled installations. At deadline time, the update will be enforced and installed. If you encounter delays in update deployment, ensure this setting is configured correctly per your needs.

Deployment Management

After a software update deployment is configured, it may be accessed in the Deployment Management node. Note that a configured software deployment is not the same as a deployment package. The settings related to the deployment, as well as the updates included in the deployment, may be viewed and manipulated on this node but not the package itself. The deployment settings found here reflect those settings that come from the software updates wizard as well as those that are inherited from the chosen template.

Deployment Packages

Deployment Packages are similar to standard SMS packages in that they define the specifics of the update—source directory, distribution point, and so forth. Deployment packages are independent of the actual deployment used to distribute the updates and are essentially a store location for updates. If more than one deployment package contains the updates needed for a deployment, SCCM agents will determine the best location from which to retrieve the update and may use any available deployment package that contains the update.

The Deploy Software Updates wizard is used to deploy updates in SCCM. This wizard may either be used with individual updates or update lists. Figure 7 shows how to start the wizard.

Figure 7** Starting the Deploy Software Updates Wizard **(Click the image for a larger view)

This wizard proceeds by asking for a name for the deployment, whether to use existing or new template settings (if a new template is chosen the wizard will prompt for the template settings described earlier), deployment package settings (either existing or new), distribution point settings, location options for download, update languages to download and deployment schedule information.

With configuration complete, policy will be updated to notify the clients of the targeted updates and the updates will be installed to the client systems. The client processes are quite different from previous releases and are beyond the scope of this article. A key difference, however, is that the update scans are no longer performed locally—the SUP handles all scanning—but the detail on update compliance is stored in the local Windows Management Instrumentation (WMI) repository, similar to previous versions.

Unlike previous versions, however, hardware inventory is no longer used to send update status to the site server. Instead, state messages (a new kind of streamlined status message) are sent to the site server via the management point. State messages supply data about each and every managed client for compliance scans and to track the progress of deployments. There are number of new reports in SCCM for Software Updates Management, including overall per-machine compliance for all deployed updates to each client, deployment enforcement state per client, and client error reports for scans and deployments that give a stack-ranked list of the biggest issues to resolve.

In addition to the traditional scheduled/mandatory enforcement of update deployments, SCCM lets you install approved updates prior to the installation deadline on a schedule very similar to what is in place today with Automatic Updates. This useful addition will do even more to increase the number of compliant systems prior to the deployment deadline.

If custom updates are of interest to you, SCCM allows for this as well. The custom updates publishing tool from SMS 2003 R2 has been modified for use with SCCM 2007 as the System Center Updates Publisher—so any custom updates may be deployed in the same manner as described.

The changes to update management are vast in SCCM, but from an administrative perspective they should be easier to use and are a welcome improvement over previous versions. Though some of the conceptual changes may be challenging at first for users accustomed to SMS 2003, the new approach is definitely worth the effort. Enjoy!

Steve Rachui is a Manageability Support Escalation Engineer in the Product Support Services group at Microsoft. He has supported SMS since version 1.2. Steve can be reached at steverac@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.