Maximize the Power of SMS with New Tools for Managing Updates
At a Glance:
- Install and configure the SMS 2003 scanning tools
- Deploy software updates to large numbers of computers using SMS 2003
- Ensure compliance using SMS 2003 reporting
The Automatic Updates service built into Windows will
definitely help you keep machines up to date. And
Microsoft Windows Server Update Services (WSUS) goes
further by helping you control which computers receive which updates and by providing some basic reporting information. But what if you need to update thousands of computers of different types, in different geographies, and with different requirements? And what if your boss wants proof that the updates were actually installed on every system?
The solution: the Software Update Management features in Systems Management Server (SMS) 2003. Unlike Automatic Updates and WSUS, the SMS 2003 software update management features allow you to do controlled, phased deployments of updates to a large number of computers and prove compliance through status messages and reporting.
This article assumes you already understand the SMS Software Distribution process and the associated objects: collections, packages, programs, and advertisements. For background information on the SMS Software Distribution process, see the SMS Web site
. This article also assumes that you are already using SMS 2003 SP1 to collect hardware inventory, distribute software to your SMS clients, and run reports.
Software Updates in SMS consist of two parts: the scanning tools and the Distribute Software Updates Wizard. The wizard is built in, but the scanning tools must be downloaded from the SMS Web site. Before using the Distribute Software Updates Wizard, you should install and advertise the scanning tools.
The primary scanning tool you’ll need is the SMS 2003 Inventory Tool for Microsoft® Updates, or ITMU. The ITMU scans each client computer to detect whether updates are needed for each client, and reports that information back to the SMS site server.
If you still have Windows NT® 4.0 clients or Windows® clients that don’t have SP3, then you’ll want to continue to use the Security Update Inventory Tool and the Microsoft Office Inventory Tool for updates.
Because these scanning tools are modular, rather than being built into SMS itself, the framework exists for third parties to develop additional scanning tools for their own products. In fact, Dell has already released the SMS 2003 Inventory Tool for Dell Updates, which scans for needed driver, firmware, and BIOS updates for their server products and then reports that information back to SMS.
Installation and Use
You can download these scanning tools directly from the SMS Web site (SMS 2003 Inventory Tool for Microsoft Updates
). Once the files have been downloaded, you should review the release notes; a number of post-SP1 updates are necessary before installing the ITMU. Once you have the prerequisites in place, run the installation on your site server. The installation file not only expands the scanning tool and its support files, but also, by default, creates a new package and a few new collections, programs, and advertisements. The new package is given a name that you specify when you run the installation file, and the setup process verifies that you don’t already have a package with that name.
During the installation, you can also specify the computer that will be your Sync Host, and another computer for testing. The Sync Host is the computer that will download the latest Security Update catalog from Microsoft. (By default, it does this on a weekly basis.) Typically, the Sync Host is your SMS site server. The test computer is an SMS client that you will use for testing the scan tools and, later, for security updates.
Figure 1 Programs Created by the ITMU
Suppose you select the default name "Microsoft Updates Tool" for the ITMU package. As shown in Figure 1, a package named Microsoft Updates Tool is created along with three programs, Microsoft Updates Tool, Microsoft Updates Tool (expedited), and Microsoft Updates Tool Sync. (A package for deploying the Windows update agent is also created by default, in case any of your client computers don’t already have it.) Three collections are also created, called Microsoft Updates Tool Sync, Microsoft Updates Tool, and Microsoft Updates Tool (preproduction). Finally, two advertisements are created, called Microsoft Updates Tool and Microsoft Updates Tool Sync, as shown in Figure 2.
Figure 2 Advertisements Created by the ITMU
The Sync Host collection contains the Sync Host computer that you specified during installation. The preproduction collection contains the test client that you specified. Both collections are defined by direct membership rules. The third collection, which matches the name of the package (Microsoft Updates Tool, in this case), is initially limited to the members of the preproduction collection. This is to ensure that the scan tool doesn’t start running on your production computers right away. Later, when you’re ready, you can add other computers to the collection by using additional direct membership rules or query-based rules, by adding subcollections, or by linking to one or more existing collections.
The Microsoft Updates Tool package contains the scan tool itself, the application for downloading the latest security catalog, and a library for downloading the security updates themselves, which I’ll get to later. The Sync program (Microsoft Updates Tool Sync, in this case) is the program that downloads the latest catalog of security updates from the Microsoft Web site. The Microsoft Updates Tool program runs the scan tool, scanwrapper.exe, which scans the computer for applicable updates listed in the updates catalog and records the status for each update in Windows Management Instrumentation (WMI). That’s why software updates appear under Hardware Inventory in Resource Explorer. The Microsoft Updates Tool (expedited) program runs scanwrapper.exe with the /kick option, which forces the client to report hardware inventory immediately after completing the scan.
Generally, the expedited program is most useful in your pre-production environment to ensure timelier inventory reporting when testing new updates. Be careful if you chose to run the expedited program in a production environment. The first time the /kick option is used, it may cause a significant increase in network traffic, even if clients are only reporting delta hardware inventory. Network impact should decrease if the program is run regularly.
The Microsoft Updates Tool and Microsoft Updates Tool Sync advertisements do pretty much what you’d expect: each advertises the program of the same name in the Microsoft Updates Tool package to the collection with the corresponding name. These advertisements recur every seven days, so the scanning process is an ongoing one.
After installation, all you need to do to start gathering information on needed updates is to advertise the expedited program to the preproduction collection. This will work for your own testing purposes. When you’re ready for the real thing, add your production computers to the production collection to which the regular (non-expedited) program is advertised.
So, you’ve got your scanning tools installed, they’re advertised to the test and production computers, and you’re starting to get information about necessary updates in your hardware inventory. Now what?
If you select Software Updates in the SMS Administrator Console, you should find a number of updates listed, as shown in Figure 3. These are the updates listed in update catalog. You should use the Compliance by product report to determine which updates are not already fully deployed in your environment. Once you’ve determined which updates are necessary, and thoroughly tested them, the Distribute Software Updates Wizard will walk you through the process of building the packages, programs, and advertisements needed for deploying the updates to your client systems.
Figure 3 Updates Available in the Administrator Console
You can launch the Distribute Software Updates Wizard by right-clicking on Software Updates, pointing to All Tasks, and then clicking on Distribute Software Updates. After clicking Next on the Welcome page, you select the scanning tool associated with the update you want to distribute (Microsoft Update, in this case), as shown in Figure 4. On the next page of the wizard, you select whether to add the updates you’re planning to distribute to an existing Software Updates package or create a new one. If you have not distributed any updates using SMS yet, you have to create a new package.
Figure 4 Selecting an Update Type
Next, you assign a name to your software update package. In Figure 5, I typed the name Security Updates for simplicity, but you should always give your packages meaningful, descriptive names. Notice that because Microsoft Update was selected as the scanning tool, the name Microsoft Update— Security Updates is automatically assigned to the program that will install the updates distributed in this package.
Figure 5 Specifying a Name
On the Customize the Organization page of the wizard, you can specify the name of the organization that is deploying the updates (see Figure 6). This allows you to inform users as to who is updating their computers, and record in SMS who authorized which updates. To provide users with additional information about the update deployment, you can use Microsoft Word or WordPad to create a Rich Text Format (RTF) document with further details. You can then use the buttons on this page of the wizard to import and preview the document.
Figure 6 Identifying the Update Source
On the Select an Inventory Scanning Program page of the wizard, you specify the scanning tool package and program that should be used to detect whether the updates in this package are needed. Simply select the appropriate package and program from the dropdown lists.
The next page of the wizard, Add and Remove Updates, is where you make the all important decision regarding which updates to include in the package (see Figure 7).
Figure 7 Selecting Updates
From my own experience in updating systems using a variety of methods, I’ve found that it is best to group your updates by installation requirements. In other words, if you have a large group of machines that all need the same updates, put all of those updates in the same package. However, if the updates needed by your computers are not consistent—for example, if your users have been manually updating their computers by using Windows Update via the Internet—then you should probably use several small or single-update packages instead of fewer large packages. Note that Service Pack 1 for SMS 2003 adds the option to filter the available updates on this page, so you don’t have to select from the entire list.
You then go to the Specify a Source Directory for Files page. Here you specify a source location for your package; this is where the package will be stored and updated before being sent to your distribution points. On this page, you also select the package priority and whether to automatically download the updates that you selected on the previous page. If you have already downloaded the updates for manual testing, you can select the I will download the source files myself option; one of the later pages will then let you import the files. Otherwise, you should allow the wizard to download the updates, which it will do by default when you click Next.
The Software Updates Status page indicates the readiness of each update. On this page, shown in Figure 8, the list of updates selected on the Add and Remove Updates page is displayed.
Figure 8 Status of Downloaded Updates
If you elected to download the updates manually, you will need to view the Properties page for each update and use the Import button to add the updates to the package (as shown in Figure 9). After you update the properties for an update, the Software Updates Status page will show that the update is ready. Once all the updates in the package are listed as ready, you can move on and finish the package.
Figure 9 Update Properties
After you select distribution points for the package on the following page of the wizard, you will move to the Configure Installation Agent Settings page where you configure the post-installation operations, such as whether to force hardware inventory collection or create a client template (both of these operations are probably best suited for test deployments rather than production deployments). On this page, you can also configure whether to postpone reboots for workstations or servers, and whether to force any open programs to close in order to reboot.
There are actually two Configure Installation Agent Settings pages. On the first, shown in Figure 10, you can configure other installation options, such as unattended installation, countdown time, and maximum runtime. The second Configure Installation Agent settings page lets you configure options such as Advanced Client notification and whether users can delay installation of the updates.
Figure 10 Installation Agent Settings
On the Advertise Updates page of the wizard, you can elect to create an advertisement for the package and program, select the target collection, and specify how often the advertisement should recur. For testing purposes, select your preproduction collection or another collection that contains only test computers. For actual deployment, you may want to specify an empty collection and then link to existing collections or add subcollections in order to phase in your roll-out. After a final success page, the wizard ends and the updates are scheduled for deployment.
As new updates become available, you can use the Distribute Software Updates Wizard to add those updates to your existing package or create new update packages.
After scanning for and distributing necessary updates, you will need to ensure that those updates were successfully deployed, and possibly even provide proof that your computers are compliant. In the SMS Administrator Console, you can use Package Status and Advertisement Status under System Status to verify the update package distribution status and deployment status, respectively.
Of course, the SMS 2003 Reporting feature is where you’ll find the most complete information regarding update distribution status. The Distribution status summary of software updates report shows the status of all software updates that you have deployed while the Compliance by product report shows the number of compliant and non-compliant computers for each update. To identify the software updates that were not fully deployed, use the Summary of software updates that failed to deploy report.
As you can see, SMS provides you with a comprehensive framework for distributing software updates throughout your organization. It also provides that extra measure of confidence through comprehensive and detailed status reporting on update distribution and success.
Bob Lawler is a network infrastructure and security consultant, a Microsoft Certified Trainer, and the president of XPO-NET Corporation. He can be reached at firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited