Software Update Management

Transcription

1 Software Update Management Using SMS 2003 Prepared by Microsoft First published 15 March 2007

2 Copyright This document and/or software ( this Content ) has been created in partnership with the National Health Service (NHS) in England. Intellectual Property Rights to this Content are jointly owned by Microsoft and the NHS in England, although both Microsoft and the NHS are entitled to independently exercise their rights of ownership. Microsoft acknowledges the contribution of the NHS in England through their Common User Interface programme to this Content. Readers are referred to for further information on the NHS CUI Programme. All trademarks are the property of their respective companies. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft Corporation and Crown Copyright 2007 Disclaimer At the time of writing this document, Web sites are referenced using active hyperlinks to the correct Web page. Due to the dynamic nature of Web sites, in time, these links may become invalid. Microsoft is not responsible for the content of external Internet sites. The example companies, organisations, products, domain names, addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organisation, product, domain name, address, logo, person, places, or events is intended or should be inferred. Page ii

3 TABLE OF CONTENTS 1 Executive Summary Introduction Value Proposition Knowledge Prerequisites Skills and Knowledge Training and Assessment Infrastructure Prerequisites Audience Assumptions Using This Document Document Structure Plan Planning Where to Install ITMU Planning a Software Updates Package Strategy Single Package Strategy Base (Rollup) Package and Weekly or As-Needed New Updates Package Strategy Single or Multiple Package Strategy Additional Considerations for SMS Clients in Remote Roaming Boundaries Planning Software Update Management Collections Planning Pilot Computers for Software Updates Planning Software Updates Installation Options Develop Preparing an SMS Infrastructure for Software Update Management Creating a Package Source Location Choosing the Synchronisation Host Site Settings Hardware Inventory Software Distribution Settings Installing ITMU Installation Prerequisites ITMU Installation Procedure Configuring ITMU Create Collections Add Extra Pilot Computers Configure Advertisements Stabilise Page iii

4 6.1 Verifying Catalogue Synchronisation Testing Software Updates Using Pilot Computers Testing Software Update Reporting Data Flow Verifying SMS Client Scanning Functionality Viewing Software Update Compliance Data Deploy Deploying the Scan Tools to Windows Clients Operate Using the DSUW to Create a New Deployment Package Running the DSUW to Create a New Package Verifying Distribution Points Creating Advertisements Verifying Updates are Successfully Installed Using the DSUW to Update an Existing Deployment Package Running the DSUW to Update an Existing Package Updating and Verifying Distribution Points Verifying Updates are Successfully Installed Removing Packages Securing SMS Packages APPENDIX A Skills and Training Resources PART I Training and Skills Assessment Resources Available PART II Supplemental Training Resources APPENDIX B Configuring the Synchronisation Host for Unattended Mode PART I Configuring Credentials for Firewalls APPENDIX C Troubleshooting PART I Viewing SMS Log Files PART II Flowcharts APPENDIX D Document Information PART I Terms and Abbreviations PART II References Page iv

5 1 EXECUTIVE SUMMARY This document follows on from Preparing SMS for Software Distribution and Update Management 1 and aims to guide the healthcare IT professional through the steps and decision processes required for using Systems Management Server (SMS) 2003 for software update management. These documents along with Software Distribution Using SMS form the Software Distribution and Update Management Using SMS 2003 guidance. The goal of this guidance is to take the healthcare IT professional through the necessary steps to perform software update management using existing SMS 2003 sites within the healthcare organisation s environment and the Systems Management Server (SMS) 2003 Inventory Tool for Microsoft Updates (ITMU). The guidance brings together the wealth of information available for SMS 2003 and ITMU into a concise and easy to follow implementation guide. Links to supporting information are also provided together with training references. This guidance builds on the existing SMS 2003 Deployment Guide Initial Site Deployment 3 and the SMS 2003 Deployment Guide Extending to Other Locations 4 guidance. 1 Preparing SMS for Software Distribution and Update Management {R1}: 2 Software Distribution Using SMS 2003 {R2}: 3 SMS 2003 Deployment Guide Initial Site Deployment {R3}: 4 SMS 2003 Deployment Guide Extending to Other Locations {R4}: Page 1

6 2 INTRODUCTION This document is one in a series of documents that make up the SMS Software Distribution and Software Update Management using SMS guidance. The individual documents within this guidance are listed below: Preparing SMS for Software Distribution and Update {R1} Software Distribution Using SMS 2003 {R2} (this document) This guidance has been created to reduce the amount of time the healthcare IT professional needs to implement software distribution and software update management using an existing SMS 2003 infrastructure. This infrastructure may have been created using the guidance in the SMS 2003 Deployment Guide Initial Site Deployment {R3} and SMS 2003 Deployment Guide Extending to Other Locations {R4} or may have been separately installed and configured. 2.1 Value Proposition This guidance,, will take the healthcare IT professional through the necessary steps to successfully utilise an SMS 2003 Service Pack 2 (SP2) site, or sites, within the healthcare organisation s environment for software update mangement, using SMS 2003 and ITMU. The guide consolidates and brings together the vast amount of public information available for SMS 2003 and ITMU into a modular step-by-step document. The areas covered in this guidance are critical to ensuring that SMS and ITMU are installed and utilised in the best way, providing a functional software update management solution and making best use of available network resources. The guidance covers the concepts and configuration steps that are required, and the key decisions that need to be made in order to ensure a successful deployment. 2.2 Knowledge Prerequisites To implement the recommendations made throughout this document effectively, a number of knowledge-based and environmental infrastructure prerequisites should be in place. This section outlines the knowledge and skills required to use the Software Update Management Using SMS 2003 guidance, while section 2.3 details the necessary infrastructure prerequisites. Section details the prerequisite skills and knowledge, and section details the information and suggested training resources of skill assessment Skills and Knowledge The technical knowledge and minimum skills required to use this guidance are discussed in the following sections SMS Software Distribution The SMS software distribution feature automates the distribution of programs to SMS clients. These programs are used by ITMU for distributing software updates to SMS clients. Using software distribution eliminates the inefficient and costly process of an IT Professional visiting every location where the software is required, and manually installing it. The automated process of program distribution eliminates errors such as entering incorrect values in prompts, running incorrect programs, or entering incorrect arguments. By using software distribution, SMS clients can successfully run programs and install software without needing to know how to run these programs or which setup options are best for them. Software distribution allows the Page 2

7 healthcare organisation to centrally define and control how and when programs run on client computers. The healthcare IT Administrator can choose how little, or how much users manage. Central management of the software distribution in the healthcare organisation allows IT Administrators to monitor the distribution process from beginning to end. SMS generates detailed status messages that allow the monitoring of individual SMS clients. This also allows the healthcare IT Administrator to provide assistance to those SMS clients that are having difficulties running a program Using SMS Collections The healthcare IT Administrator can make software updates available to as many computers as required. The SMS clients that need to receive the program must be members of a collection (referred to as the target collection). The target collection can, for example, contain a single SMS client, all the SMS clients that are assigned to a specific site, or any subset of SMS clients. When the program is distributed to the target collection, all the SMS clients that are members of that collection receive the program. This allows the healthcare organisation to distribute programs to specific users, specific user groups, and any group of SMS client computers that share a common set of hardware or software attributes. If Active Directory is implemented in the healthcare organisation, a target collection can be created that is based on Active Directory containers. Collections can be created that target systems based on organisational units, domains, site, and/or group membership, or collections can be created that target users based on domains, organisational units, and/or group membership. To target systems for software distribution, using Active Directory containers, the Active Directory System and Active Directory System Group discovery methods must be enabled in the site and must have been run at least once. Section 4.3 provides more information on planning collections. Collections, in which membership rules are based on queries, are dynamic. After the initial membership list is created, if the collection has been configured with an update schedule, SMS clients are automatically added to, or removed from the collection, as appropriate. SMS client computers that initially did not meet the collection's criteria, but meet the criteria now, automatically become members of the collection. SMS clients that initially meet the collection's criteria, but then no longer meet the criteria, are automatically removed from the collection (this does not result in the SMS clients being uninstalled). In a dynamic environment, SMS keeps collections current, thus ensuring that only the appropriate SMS clients receive distributed programs. The following scenario illustrates the benefits of this behaviour: 1. A program is distributed to the All Windows XP Systems collection. 2. Only SMS client computers running Windows XP receive the program. 3. A few SMS client computers running Windows 2000 upgrade to Windows XP. 4. The newly upgraded SMS clients automatically become members of the All Windows XP Systems collection. 5. The program that was distributed to the All Windows XP Systems collection automatically becomes available to the newly upgraded SMS clients (along with any other programs that are available to the All Windows XP Systems collection) SMS Programs The purpose of using the software distribution feature is to automate the process of making a program available to target SMS clients. A program can be a file name (SMS uses file association to run such programs) or anything else that can run from a command line, such as a batch file or a Windows Installer command line. Page 3

8 Programs have a wide range of configurable options such as security context, supported platforms, and environment requirements. The program's command line can be anything from setup programs to simple batch command lines. Programs often need to download files to the SMS client when they run, for example, installation programs must download installation files. The files that a program requires when it runs are called package source files. Sometimes, more than one program can be associated with the same set of source files. For example, there can be several variations of a setup program that install the same software by using the same source files. However, each setup program runs differently and provides different setup options, such as running without user intervention or performing an upgrade rather than a full installation. To provide SMS clients with all these setup options, several programs for the same set of source files need to be defined. A copy of the source files must be distributed to one or more servers, accessible to SMS clients, so that when the program runs on SMS client computers, it can access the files that it requires. The Distribution Point (DP) is an SMS site system that has that role. See Preparing SMS for Software Distribution and Update Management {R1} for more information on DPs. The administrative task of copying the package source files to DPs is called package distribution. Some programs are not associated with source files. In this case, either the programs use files that are already stored on the SMS client computers or access to the required files is coordinated outside of the SMS software distribution. For example, the command line Defrag.exe c: might not be associated with source files. In this case, when the program runs on SMS client computers, a local copy of Defrag.exe runs SMS Packages Programs, source files, and source file paths are the main components that make up a software distribution package. An SMS package is the basic unit of software distribution. Packages vary widely, depending on their purpose. A package might have source files associated with it. A package typically has at least one program, and can have as many programs as needed. Section 4.2 provides information on planning SMS packages for software update distribution and section 8 contains information on creating SMS software updates packages using the Distribute Software Updates Wizard (DSUW) SMS Advertisements Another object that is associated with software distribution is the advertisement. Advertisements are the objects that make programs available to SMS clients. The advertisement links the program and package to a collection. A program must be advertised before SMS clients can run it. A variation of an advertisement is an assignment, which is a mandatory advertisement that must run on the SMS client. Advertised programs appear at the SMS client both in the SMS user interface and in Add or Remove Programs in Control Panel. For information on creating advertisements, see section Software Distribution Security SMS software distribution is a powerful feature that can be used as a major point of attack if not secured properly. When installing packages, SMS can use elevated rights in either the user or the system context, even if the user does not have administrative rights. This allows an attacker to effectively run any attacks that require elevated rights. Security guidance specific to the use of ITMU has been included, where appropriate, throughout this guidance. Page 4

9 How Software Distribution Works To distribute software to SMS clients, a software distribution package and programs need to be created and then advertised to the relevant SMS clients. Advertising the program makes a program available to a specified target collection. The advertisement contains the name of the program, the name of the target collection, and the scheduling configuration (such as when to run the program or when will the program expire). However, the site's SMS clients will not be able to receive advertised programs until the software distribution client agent is enabled on the site's SMS clients. This primarily allows SMS clients to receive and run programs that are advertised. When the feature is enabled, packages, programs, and advertisements can be created to deliver the programs that SMS clients need. Refer to Preparing SMS for Software Distribution and Update Management {R1} for information on enabling software distribution. Figure 1 shows a high-level overview of the software distribution process in SMS Figure 1: Software Distribution Overview Table 1 shows the steps involved in the software distribution process. Step Description 1. The SMS site server copies the package source files to the DPs according to the package configuration. Note If a package has no source files then this step does not take place. 2. For each advertisement, details of the collection, package and program are made available on the Management Point (MP). 3. The SMS site server forwards any package, program and advertisement data to any child sites; this includes the package source files if a DP has been specified for that site, or any of its child sites. Page 5

10 Step Description 4. The SMS client will periodically request new policies from the Management Point. The policies contain information on which software is required to be installed including any scheduling data, along with any other SMS client side settings. 5. When software is scheduled to be installed, the SMS client makes a content location request to the Management Point and waits for a response. The content location request tells the SMS client which DP to connect to install the software, and if those locations are local or remote to the SMS client. 6. If the package has package source files, the source files are either executed from the DP or downloaded to the SMS client cache and executed locally. Table 1: Software Distribution Overview Steps Note To reduce the load on the WAN, it is possible to specify a DP as a Protected DP. When specifying boundaries for a Protected DP, access to that DP from SMS clients roaming outside the specified boundaries is prevented. Using this configuration can conserve bandwidth and protect a DP from being overloaded. For more information on Protected DPs, see Preparing SMS for Software Distribution and Update Management {R1} Software Update Management Operational Processes Microsoft recommends using a four-phase approach for the testing, deployment and management of software updates when using SMS This approach provides control over the deployment of software update releases into the healthcare organisation s production network environment. The four-phase approach works as follows: Plan and Assess This phase starts with an assessment of what is in the healthcare organisation s production network environment, what security threats and vulnerabilities may be applicable, and whether the healthcare organisation is prepared to respond to new software updates. Identify The goal during the Identify phase is to discover new software updates in a reliable way, determine whether they are relevant to the healthcare organisation s production network environment, and determine whether an update represents a normal or emergency change. Evaluate and Review The goal during the Evaluate and Review phase is to make a go/no-go decision to deploy the software update, determine what is needed to deploy it, and test the software update in a production-like environment to confirm that it does not compromise business critical systems and applications. Deploy The goal during the Deploy phase is to successfully roll out the approved software update into the healthcare organisation s production network environment so that all the requirements of any deployment Service Level Agreements (SLAs) that are in place, are met. An additional phase, Manage Security Updates, deals with learning how to successfully manage security updates using SMS For detailed information about the software update management process and each phase of the four-phase approach, refer to Update Management 5. 5 Updated Management {R5}: Page 6

11 Inventory Tool for Microsoft Updates Overview of ITMU ITMU comprises a set of components that are installed on an SMS server and used to determine the security update compliance of SMS clients and then distribute software updates to those SMS clients. These tools provide functionality above that which is provided by the SMS 2003 Software Update Scanning Tools that are included with SMS. These tools also provide integration with updates offered by Windows Update and Microsoft Update. ITMU can be installed on an SMS 2003 SP2 server with no additional hotfix requirements. ITMU shares the same security update, update rollup and service pack data as offered by Windows Server Update Services (WSUS) and utilises the Windows Update Agent (WUA), (which is included with Windows 2000 SP3 and higher) for scanning SMS clients, thereby providing improved security update detection. The following components are included with ITMU: Scan tool for Microsoft updates. Enables the scanning of Windows desktops and servers for installed and missing Microsoft updates similarly to how Microsoft Baseline Security Analyser (MBSA) determines compliance for Microsoft security updates. Synchronisation of the Windows Updates Catalog. Downloads the WSUS scan catalogue on a recurring schedule. The latest Windows Update Agent. The Windows Update Agent version is installed on the Windows operating system to support Windows Update detection and deployment. New SMS Advanced Client release and updated Distribute Software Update Wizard. Note At the time of publication of this document, ITMU does not determine compliance for non-security related updates. ITMU deploys security updates released through Microsoft Security Response Center (MSRC), update roll-ups, and service packs only. ITMU synchronises its catalogue with Windows Update and Microsoft Update. Windows Update and Microsoft Update (and therefore SMS with ITMU) provide updates for the following products: Microsoft Windows 2000 Service Pack 4 (SP4) and later Microsoft Windows 64-bit edition (based on Windows Server 2003 SP1 code) Microsoft Windows XP Embedded All Windows components (such as MSXML, MDAC, and Microsoft Virtual Machine) Microsoft Office XP and Office 2003 Microsoft Exchange 2000 and Exchange 2003 Microsoft SQL Server 2000 SP4 and later Additional products as published to Microsoft Update and Windows Update Note To update products that are not supported by Microsoft Update and Windows Update, use the SMS 2003 Software Update Scanning Tools that are included with SMS. These tools use MBSA 1.2, UpdateScan.exe, and Office detection scan engines for assessing update compliance. Support for additional Microsoft products will be added to Microsoft Update and Windows Update over time. By using a single scan tool, the Windows Update Agent, the administration costs associated with ITMU are greatly reduced in comparison to the SMS 2003 Software Update Scanning Tools. This results in fewer SMS packages, and therefore fewer deployments of security updates and potentially fewer client reboots. Page 7

12 ITMU also simplifies the deployment of packages by automating the command line settings for implementing silent installs and unattended reboots, when installing security updates. Overview of the Software Update Process The process of updating SMS Advanced Clients using ITMU works as follows: 1. ITMU is installed on SMS Advanced Clients. This is not performed automatically by the ITMU setup but by the creation of the necessary SMS objects (packages, programs, collections and advertisements). If the WUA requires installing or updating, a program dependency ensures this software is installed before the scan agent. 2. After running the inventory tool program, the SMS Advanced Clients must complete a hardware inventory cycle for SMS to collect the results of the scan and send them to the site server. 3. After the site server has processed the inventory results and placed them in the SMS site database, that information is available for running reports and using the DSUW to create the relevant SMS objects (packages, programs, collections and advertisements) for distributing missing software updates. 4. An administrator runs the DSUW and authorises the software updates that have been chosen for distribution. The DSUW creates the packages, programs, collections and advertisements which distribute the software updates to the SMS clients. Additional Set Up Information During the setup process, the ITMU wizard creates a directory named PkgSource under the destination folder specified in the wizard. This folder contains various files, libraries and executables that are used in the software update process. The folder is shared by setup as \\siteserver\packagesrc, and the local Administrators group and the SMS Admins group are granted Full Control share and NTFS permissions to the folder. Note If there is already a shared folder with the name PackageSrc, ITMU setup creates the folder as PackageSrc_x, where x is the next available number that will create a unique share name. One of the files in the PkgSource folder is the catalogue file containing the list of available software updates. This file must be synchronised before a newly released software update can be detected as required on an SMS client. For catalogue synchronisation, if the synchronisation host does not have a connection to the Internet, it is possible to specify a local catalogue location and ITMU setup will look there for the Windows Update Catalog. The Windows Update Catalog must be manually copied to this location. Consequently, when a new catalogue is released it must be manually copied again to this location. If the synchronisation host does have an Internet connection, ITMU setup will connect to the Internet and copy the latest catalogue to the PkgSource folder. Important It is not essential for the synchronisation host to have a connection to the Internet to synchronise the Windows Update Catalog. Consider the security implications of allowing the synchronisation host to access the Internet, bearing in mind that the account used to run synchronisation must have local Administrator privileges, increasing the security risk to the healthcare organisation. The ITMU Setup Wizard asks for the hostname of one computer to be specified as the synchronisation host. The synchronisation host can be any SMS Advanced Client. After setup is complete, the synchronisation host runs a program that updates the PkgSource folder, either from the Internet or from the local catalogue location. Page 8

13 Overview of the ITMU Objects Created by the ITMU Setup Wizard The ITMU Setup Wizard installs components on a site server, and creates SMS objects to install the ITMU on SMS clients, run inventory collection and synchronise the security update catalogue. By default the ITMU Setup Wizard creates the following objects: Packages Programs Advertisements Collections The ITMU Setup Wizard requires a base name for the objects that SMS will create. The default base name is Microsoft Updates Tool. If a different name is chosen, it must be different from the names of any existing SMS objects, and from any objects that are created later in the setup process. Important If ITMU is reinstalled, the same package names must be chosen. Failure to do so will result in any packages previously created by DSUW to use the obsolete package names, causing incorrect results. The Microsoft Updates Tool package obtains its source files from the PkgSource directory. The package does not update DPs on a schedule because the synchronisation host automatically updates the DPs with new catalogues as needed, following an automatic synchronisation. During the setup process, it is possible to configure whether or not to copy the package to all DPs in the site, and to all child sites. Alternatively, it is possible to manually configure the DPs for the Microsoft Updates Tool package after setup is complete. This can be performed when it is preferable to limit the number of DPs to which the package should be copied. Table 2 shows the packages and programs that are created by the ITMU setup, when using the default names. Package Program Description Microsoft Updates Tool Microsoft Updates Tool This program runs ScanWrapper.exe, the ITMU scan agent on x86 based systems. This program is configured to run the Windows Update Agent x86 ( ) before ScanWrapper.exe. Windows Update Agent IA64 Microsoft Updates Tool (expedited) Microsoft Updates Tool IA64 Microsoft Updates Tool IA64 (expedited) Microsoft Updates Tool Sync Microsoft Updates Tool x64 Microsoft Updates Tool x64 (expedited) Windows Update Agent IA64 ( ) This program runs ScanWrapper.exe, the ITMU scan agent on x86 based systems, and additionally forces a full hardware inventory on completion of the scan. This program is configured to run the Windows Update Agent x86 ( ) before ScanWrapper.exe. Same as the Microsoft Updates Tool program, but for IA64 based computers. Same as the Microsoft Updates Tool (expedited) program, but for IA64 based computers. This program runs sycnxml.exe to connect to the catalogue source to download the latest software update catalogue. Same as the Microsoft Updates Tool program, but for x64 based computers. Same as the Microsoft Updates Tool (expedited) program, but for x64 based computers. This program runs the Windows Update Agent version 5.8 setup program for IA64 based systems. Page 9

14 Package Program Description Windows Update Agent x64 Windows Update Agent x64 ( ) Windows Update Agent x86 Windows Update Agent x86 ( ) This program runs the Windows Update Agent version 5.8 setup program for x64 based systems. This program runs the Windows Update Agent version 5.8 setup program for x86 based systems. Table 2: ITMU Setup Packages and Programs Note The Microsoft Updates Tool programs with the (expedited) parameter run an additional command line switch, /kick, which causes a hardware inventory cycle to complete immediately following software update installation. This enables the information generated by the scan tool to be available more quickly on the site server, allowing the generation of reports and the use of DSUW for distributing software. However, the first time the expedited program runs, it might cause an increase in network traffic. When the expedited program is run regularly, the amount of data sent over the network should decrease. The Microsoft Update Tool programs listed in Table 2 are configured with the following property settings: Run hidden Do not reboot the computer after running Can run only on Windows XP. Windows Server 2003, Windows 2000 Service Pack 3 (SP3), and Windows 2000 SP4 (except the sync program which can run on any platform) Run once for the computer (sync job only) Can run whether or not a user is logged on Run with administrative rights Suppress program notifications Runs the relevant Windows Update Agent program and package first The Windows Update Agent programs listed in Table 2 are configured with the following property settings: Run hidden Do not reboot the computer after running Can run on any platform Can run whether or not a user is logged on Run with administrative rights Suppress program notifications Table 3 shows the advertisements that are created by the ITMU set up when using the default names. Advertisement Microsoft Updates Tool Microsoft Updates Tool Sync Description This advertisement advertises the Microsoft Updates Tool package and the Microsoft Updates Tool program to the Microsoft Updates Tool collection. The assignment occurs every 7 days, effective from the time of creation. This advertisement advertises the Microsoft Updates Tool package and the Microsoft Updates Tool Sync program to the Microsoft Updates Tool Sync collection Table 3: ITMU Setup Advertisements Page 10

15 During ITMU setup, an option is given on whether to create an advertisement called Microsoft Update Tool, which sends the Microsoft Update Tool package and program to the Microsoft Update Tool collection. This program will be downloaded by Advanced Clients from either a local DP (if available) or a remote DP (if no local DP is available) and will then be run from the local client cache. Important It is not recommended to change this program to run directly from a DP. If the option to create an advertisement during ITMU setup is chosen, collections are created to assist in deploying the Microsoft Updates Tool package to SMS clients. Table 4 shows the collections that are created by ITMU setup, when using the default names. Collection Microsoft Updates Tool Microsoft Updates Tool (preproduction) Microsoft Updates Tool IA 64 Microsoft Updates Tool Sync Microsoft Updates Tool x64 Description This collection is used for organising computers to which the scan agent will be deployed. This collection is populated by running a WQL query that selects x86 based computers with the SMS client installed and that meet the minimum operating system and service pack level requirements for ITMU clients. Initially, the scope of this collection is limited to the Microsoft Updates Tool (pre-production) collection. This collection is used for testing updates before they are authorised for distribution to the wider network desktop infrastructure. This collection is populated using a direct membership rule which selects the computer that is chosen for testing during ITMU setup. Same as the Microsoft Updates Tool collection, but the WQL query selects IA64-based computers. This collection is used by the Microsoft Updates Tool Sync program for selecting the computer that will run the synchronisation job that downloads the latest software updates catalogue. Same as the Microsoft Updates Tool collection, but the WQL query selects x64 based computers. Table 4: ITMU Setup Collections The packages, programs, collections and advertisements created by ITMU setup are useful for ongoing use, but may require some modification. Further details of how to use these objects, and configuration changes that may be required are detailed later in this document. The default configuration of these objects will result in the scan tool being deployed to the computers chosen for testing during ITMU setup only. Therefore, the default configuration will not result in any software being distributed to computers in the larger desktop infrastructure Deploying Microsoft Office Updates ITMU can be used for installing software updates for Microsoft Office XP and Office However, there are several issues that need to be considered when using ITMU for installing Microsoft Office updates: The software update inventory tools can only be used on Microsoft Office applications that are installed in per computer mode, not in per user mode At least one Office Administrative Installation Point must be configured on the site before it is possible to distribute Microsoft Office updates using the DSUW There are two types of Microsoft Office installations: client installations and administrative installations. The same software update file cannot be used to update both types of installations. If a computer that is hosting a client installation of an Office product is ever updated from an administrative installation, then that computer must be updated from the administrative update files from then on In an update to an administrative installation, the software update installation files must have access to the product code and installation source files of the original installation share, in order for the software update to successfully install on SMS client computers Page 11

16 Although most Microsoft Office Update files can be downloaded automatically by using the DSUW, many of them are not ready to deploy without further manual steps. These steps can include decompressing the files, and downloading and configuring a special tool, Ohotfix.exe For more information on deploying updates, see Managing Software Updates 6 in the Systems Management Server 2003 Operations Guide Training and Assessment Guidelines on the basic skill sets that are required in order to make best use of this guidance are detailed in APPENDIX A. These represent the training courses and other resources available. However, all courses mentioned are optional and can be provided by a variety of certified training partners. 2.3 Infrastructure Prerequisites The following are prerequisites for using SMS 2003 for software update management: An existing SMS 2003 SP2 infrastructure Microsoft Windows XP Professional x86 (SP1 or SP2), or Windows 2000 Professional SP4 or above required for all desktop clients SMS 2003 SP2 Advanced Client deployed to clients SMS 2003 Software Distribution feature enabled for SMS clients 2.4 Audience The guidance contained in this document is targeted at a variety of roles within the healthcare IT organisations. Table 5 provides a reading guide for this document, illustrating the roles and the sections of the document that are likely to be of most interest. The structure of the sections referred to is described in section 3.1. Role Document Usage Executive Summary Plan Stabilise Deploy Operate IT Manager Review the relevant areas within the document to understand the justification and drivers, and to develop an understanding of the implementation requirements IT Architect Review the relevant areas within the document against local architecture strategy and implementation plans T Professional/ Administrator Detailed review and implementation of the guidance to meet local requirements Table 5: Document Audience 6 Managing Software Updates {R6}: 7 Systems Management Server 2003 Operations Guide {R7}: Page 12

17 2.5 Assumptions The guidance provided in this document assumes that healthcare organisations that want to share services and resources between sites already have suitable Internet Protocol (IP) addressing schemes in place to enable successful site to site communication, that is, unique IP addressing schemes assigned to each participating healthcare organisation and/or location with no overlap. Active Directory and the underlying Domain Name System (DNS) require the use of unique IP addressing schemes at adjoining sites in order for cross site communication to function successfully. The use of Network Address Translation (NAT) within an Active Directory environment is neither recommended nor supported by Microsoft. The use of NAT is also not supported within an SMS infrastructure. The guidance assumes that the administrator will read the important concepts discussed in section 2.2 and that an existing SMS 2003 SP2 infrastructure is in place. The guidance also assumes that the administrator has reviewed the document entitled Preparing SMS for Software Distribution and Update Management {R1}, and has implemented any required changes. Page 13

18 3 USING THIS DOCUMENT This document is intended for use by healthcare organisations and IT administrators who wish to use SMS 2003 and ITMU for software update management. The document should be used to assist with the planning and implementation of SMS 2003 ITMU and as a reference guide for the most common tasks involved with its use within an existing SMS environment. The flowchart in Figure 2 shows the main tasks involved in installing and using ITMU. Figure 2: Quick Start Flowchart Table 6 breaks down the tasks into the sections of this document that should be read and understood in order to perform the tasks involved in using SMS 2003 and ITMU for software update management. Task Plan for software update management Prepare the environment for ITMU Install and configure ITMU Perform testing and verification procedures Deploy the scan tools to clients Create, modify and secure software updates packages Section Section 4, Plan Section 5.1, Preparing an SMS Infrastructure for Software Update Management Section 5.2, Site Settings Section 5.3, Installing ITMU Section 5.4, Configuring ITMU Section 6, Stabilise Section7, Deploy Section 8 Operate Table 6 Quick Start Reference Page 14

19 3.1 Document Structure This document contains five sections that deal with the project lifecycle, as illustrated in Figure 3: Plan Develop Stabilise Deploy Operate Each section is based on the Microsoft IT Project Lifecycle as defined in the Microsoft Solutions Framework (MSF) Process Model, and the Microsoft Operations Framework (MOF). The IT Project Lifecycle is described in more detail in MSF Process Model Whitepaper 8 and MOF Executive Overview 9. The MSF Process Model and MOF describe a high-level sequence of activities for building, deploying and managing IT solutions. Rather than prescribing a specific series of procedures, they are flexible enough to accommodate a broad range of IT projects. Plan Planning Where to Install ITMU Planning a Software Updates Package Strategy Planning Software Update Management Collections Planning Pilot Computers for Software Updates Planning Software Updates Installation Options Develop Preparing an SMS Infrastructure for Software Update Management Site Settings Installing ITMU Configuring ITMU Stabilise Verifying Catalogue Synchronisation Testing Software Updates Using Pilot Computers Testing Software Update Reporting Data Flow Deploy Deploying the Scan Tools to Windows Clients Operate Using DSUW to Create a New Deployment Package Using DSUW to Update an Existing Deployment Package Removing Packages Securing SMS Packages Figure 3: MSF Process Model Phases and Document Structure 8 MSF Process Model Whitepaper {R8}: 9 MOF Executive Overview {R9}: Page 15

20 4 PLAN The Plan phase is where the bulk of the implementation planning is completed. During this phase the areas for further analysis are identified and a design process commences. Figure 4 acts as a high-level checklist, illustrating the sequence of events which the IT Manager and IT Architect need to determine when planning for software update management using SMS 2003 within a healthcare organisation. Figure 4: Sequence for Planning 4.1 Planning Where to Install ITMU In environments with a hierarchy of SMS sites, it is important to plan which site ITMU is installed on. In general, ITMU should be installed and maintained at the highest level in the SMS hierarchy from which software updates need to be managed. This will allow packages to be created and maintained at the highest level, ensuring that there is uniformity in software update detection and authorisation time throughout the site. Package deployment can then be controlled at a more granular level by creating advertisements for the packages at child sites. Page 16

21 In the example shown in Figure 5, ITMU would be installed on an SMS server in the Central Site in Location A: Central Site Location A Secondary Site 1 Location B Primary Site Location C Secondary Site 2 Location D Figure 5: Example SMS Hierarchy Important If ITMU is installed on a lower site in the hierarchy, such as in Location C in the example shown in Figure 5, it would not be possible to deploy software updates to SMS clients assigned to any sites that are higher in the hierarchy, or at the same level in the hierarchy, such as to the SMS clients in the SMS sites in Location A or Location B. This is because the objects created by ITMU setup (packages, programs, advertisements and collections) will only flow down a hierarchy. The SMS server on which the installation program is run on in the chosen site will become the location where the PkgSource folder is located. This server can be any SMS server in the chosen site that meets the prerequisites for ITMU installation. For more information on the PkgSource folder, see section , and for more information on the ITMU installation prerequisites, see section Planning a Software Updates Package Strategy The ITMU uses SMS packages and programs to distribute software updates for installation on SMS clients. These packages and programs are advertised to SMS collections. Planning a strategy for configuration of these packages and programs will help save time in creating, maintaining and deploying software updates in the healthcare organisation. Package strategies can be considered individually for each SMS site in a hierarchy of SMS sites, or a single strategy can be used for the entire SMS deployment. The following principles should be considered when planning a software updates package strategy: Create the packages at the highest level in the SMS hierarchy from which software updates are to be managed. It is then possible to control package deployment at a more granular level by creating advertisements for the packages at child sites. A single package can contain multiple software updates, and these updates can be for multiple operating systems, versions, and client locales. At installation time, the Software Updates Installation Agent determines which software updates are applicable to a given client computer, and installs only those updates. Existing packages can be modified to add newly authorised software updates, remove authorisation for a software update, or change installation options. The number of software updates that need to be distributed can be minimised, and thus the package size, by keeping client computers current with the latest service pack. Page 17

22 The dynamic Package Configuration feature of SMS 2003 allows multiple programs to be specified for a single package, and includes the ability to attach multiple authorisation lists. This means, for example, that a phased rollout of newly authorised software updates can be performed, distributing them first to a test collection, next to a small group of early adopters, and only then to the healthcare organisation at large, all from the same package. Another way this feature can be used is to create a separate program for one set of computers that specifies no automated system restarts, and another program for a separate set of computers that require automated system restarts at installation time. Table 7 lists some potential strategies for software update packages, and their respective benefits and drawbacks. Package Strategy Detail Benefit Drawback Single package containing all authorised software updates Create a single package for all security updates Modify the package periodically by approving newly released software updates to add to the package Less overhead in creating a single package Can be useful for organisations with standardised environments, such as most SMS clients running the same operating system versions and service pack levels Cannot easily be used to retire product versions or service pack levels Can result in large packages potentially causing performance problems (especially for mobile SMS clients over slow WAN links) Multiple packages organised by operating system version or service pack level Create a package for each operating system version and service pack level Create a corresponding collection for each package Easily accommodates retiring product versions or service pack levels Smaller packages being distributed to each SMS client Accommodates nonstandardised environments with multiple client operating system versions More administrative overhead in creating and managing packages Need to mirror operating system-based collections in test environment Base (rollup) package and weekly or asneeded new updates package(s) Administer and maintain the base package that contains all authorised updates for update type. The program is configured not to run when no local DP is available Weekly or as dictated, the administrator also creates dated packages containing only new software updates. Program properties are set to Download and Execute when no local DP is available Easily accommodates a phased deployment process Minimises size of packages in most active use Maintains single Definitive Software Library package for new resources coming online Can be an efficient way of maintaining mobile SMS clients More administrative overhead in creating and managing SMS clients Multiple update packages can lead to multiple system restarts if systems have been offline Potential for overloading local software cache on mobile SMS clients Packages organised by criticality of software update Critical security updates Non-critical mandatory updates Optional updates Recommended by the MSF Administrative overhead caused by Microsoft not having a listing that contains all critical security updates Requires multiple advertisements for same users Table 7: Software Update Package Strategies: Benefits and Drawbacks Page 18

23 4.2.1 Single Package Strategy The simplest package configuration is to have a single package that contains all the software updates that are relevant to the healthcare organisation s network environment. However, there are drawbacks to this configuration as described in Table 7, most notably the considerations around mobile SMS clients connected over slow WAN links. It may, therefore, be necessary to use another package strategy or to consider increasing the size of the client cache. The considerations around mobile SMS clients are based on computers that connect to the network periodically from remote locations, connected by slow links that do not contain DPs. These SMS clients can cause large amounts of network traffic over slow WAN links. The main considerations for mobile SMS clients are: When a package is run from a DP the SMS client will evaluate which updates in the package are required and only download those updates. However, the connection between the SMS client and server will be over a normal file sharing Server Message Block (SMB) connection and it will not be possible to take advantage of Background Intelligent Transfer Service (BITS) bandwidth throttling to control network bandwidth usage. When a package is run from a DP and SMS clients are only connected to the network for short periods of time, larger update downloads may not have time to complete. If a download does not complete, it will start again from the beginning the next time the SMS client is connected. When a package is downloaded to the SMS client, any modifications to the package will cause the SMS client to re-download the entire package again. See section for additional considerations around SMS clients in remote roaming boundaries. The settings in the Advanced Client tab of the Advertisement Properties dialog box determine whether a program is run from a DP, or downloaded into the local SMS client s cache and run locally. These settings can be configured differently for local DPs and for remote DPs. Figure 6 shows the Advanced Client tab settings. Figure 6: Advertisement Properties Advanced Client Tab Settings Page 19

24 To address these issues of mobile SMS clients, it is possible to apply different advertisement settings for computers that fall into local or remote boundaries. These settings can be defined on the advertisements to separate packages when using the Base (rollup) package and weekly or asneeded new updates packages package strategy described in Table Base (Rollup) Package and Weekly or As-Needed New Updates Package Strategy The Base (rollup) package and weekly or as-needed new updates package strategy works as follows: Create one main package that contains all the relevant software updates for the healthcare organisations Microsoft Windows client operating system infrastructure. Add new software updates to this package on a regular basis. Advertise this package to a collection that includes all Microsoft Windows client operating systems. Configure the Advanced Client tab settings (Figure 6) for this package to: When a DP is available locally: Run program from distribution point When no DP is available locally: Do not run program Each week, or as-needed authorise new updates in the main package and create a new package that contains only that month/week s updates. Advertise this package to the same collection as the main package. Configure the Advanced Client tab settings (Figure 6) for this package to: Note When a DP is available locally: Run program from distribution point When no DP is available locally: Download program from a remote distribution point Using this package strategy in environments with Windows 2000 Professional and Windows XP, mobile computers will result in mobile SMS clients of each operating system version unnecessarily downloading the other operating system versions updates across WAN links when downloading from a remote DP. To mitigate the bandwidth wastage associated with this package configuration, two packages can be created with each package containing updates for only one of the operating system versions. Configure the Requirements tab of the program in each of the packages so that the program can only run on the relevant platform Windows 2000 or Windows XP. These packages can then be advertised to the same collection as the main package and with the properties defined on the Advanced Client tab of the Advertisement Properties dialog box (Figure 6). Warning Each new package creates an additional instance of the scan engine running on SMS clients and an additional package in the local software cache. To decrease the overhead on the SMS client, cycle the deletion of the monthly/weekly update packages based on the frequency with which they are created whilst ensuring that required software updates are made available to SMS clients. Note When a program is downloaded from a DP, the amount of network bandwidth used between the server and SMS client can be regulated using BITS. BITS must be configured using Group Policy or Registry entries on client operating systems. Using this package configuration results in mobile SMS clients running the package from a DP when there is a local DP present, or downloading the updates (and therefore being able to take advantage of BITS bandwidth throttling) when connected to a remote DP. Page 20

25 4.2.3 Single or Multiple Package Strategy When determining which package strategy to use, strive for the simplest configuration that is applicable to the healthcare organisation s network environment. In the first instance, determine whether a single or a multiple package strategy is required and then determine if there are additional requirements that need further consideration. To determine whether to use a single package strategy or a multiple package strategy use the flowchart in Figure 7. Figure 7: Single or Multiple Package Strategy Flowchart For information on creating and updating packages, see sections 8.1 and Additional Considerations for SMS Clients in Remote Roaming Boundaries This section deals with additional considerations that should be made for SMS clients in remote roaming boundaries that fit into the following two categories: SMS clients that reside permanently in remote roaming boundaries, such as SMS clients in GP surgeries SMS clients that reside temporarily in remote roaming boundaries, such as mobile SMS clients Important For remote clients that are connected over an external network, and not via a Virtual Private Network (VPN), (for example, connected via the Internet using only TCP port 80), it is important that the healthcare IT Administrator reviews the Managing Computers Outside the Active Directory Forest section of the SMS 2003 Deployment Guide Extending to Other Locations {R4}. This provides information for the healthcare IT Administrator on how to configure SMS clients that are in: disconnected domains, forests, or workgroups that are only able to communicate on port 80 with the SMS infrastructure. SMS clients that reside permanently in remote roaming boundaries In certain instances, SMS clients may reside permanently in remote roaming boundaries, such as GP surgeries. In these cases it may be necessary to employ a multiple package strategy, such as the Base (rollup) package and weekly or as-needed new updates package strategy (described in Table 7). This package strategy configures SMS clients in remote roaming boundaries to download Page 21

26 software updates from a DP and enables the use of BITS bandwidth throttling to minimise the network burden on slow WAN links. However, using this strategy in this environment causes the following issue: Newly built or re-imaged computers in remote roaming boundaries will never install the software updates in the main (rollup) package because this package is configured to not run the program for SMS clients in remote roaming boundaries. Only the monthly update packages will be downloaded and installed. A resolution to this issue is to ensure that newly built and re-imaged computers are brought up to a baseline of software update compliance before they are added to the network. This removes the need to install the software updates in the main (rollup) package and results in the computers only requiring the updates in the monthly update packages. Recommendation In this scenario the install procedures and images for computers will need to be modified periodically to update the baseline of software update compliance of computers. Determine a time interval that is maintainable for updating the procedures and images and keep the monthly update packages for this period of time. For instance, if it is practical to update images every 6 months, keep the monthly update packages for 6 months before they are removed. SMS clients that reside temporarily in remote roaming boundaries For environments with mobile SMS clients that temporarily reside in remote roaming boundaries, the choice of whether to use a single or multiple package strategy depends largely on the frequency with which these SMS clients are connected to local roaming boundaries. For example, if a mobile SMS client connects to a local roaming boundary once every 2 months and this is considered too long an interval to allow a computer to not be updated, a multiple package strategy such as the Base (rollup) package and weekly or as-needed new updates packages package strategy (described in Table 7) may be required. This package strategy uses a configuration that allows SMS clients in remote roaming boundaries to download software updates from a DP and enables the use of BITS bandwidth throttling to minimise the network burden on slow WAN links. 4.3 Planning Software Update Management Collections Collections are used by ITMU for targeting the Microsoft Updates Tool scan agents, the catalogue synchronisation job, and for distributing authorised security updates to the right computers. By default the ITMU setup creates a number of collections. For more information on the default collections, see section Recommendation It is recommended to use criteria that are unlikely to change regularly to create collections for software update inventory and distribution. This will help to simplify all of the stages of the software update management process. Stable criteria can include the installed client operating system version and service pack level, system role, or target organisation. The scope of this guidance is limited to delivering software updates for compatible Microsoft Windows desktop operating systems (Windows 2000 SP4 and higher and Windows XP) and applications. Therefore, it is recommended to create a single customised collection for controlled targeting of both the Microsoft Updates Tool agent and the distribution of authorised security updates to these operating system versions. Further collections can be created where additional targeting requirements exist. For information on creating collections, see section Note Though this document focuses on updating Microsoft Windows desktop operating systems, the procedures detailed could also be used for updating server operating systems and server products. When updating server operating systems and server products, be sure to carefully consider the impact of the updates including the potential for reboots following installation. Page 22

27 4.4 Planning Pilot Computers for Software Updates During the installation of ITMU, the ITMU setup wizard requests the host name of a computer which will be used for piloting software updates. This computer is placed in the Microsoft Updates Tool (pre-production) collection by a direct membership query. It is recommended to add additional computers to this collection that represent the desktop operating system versions and builds in the healthcare organisation s network infrastructure. These additional test computers can be organised into the Microsoft Updates Tool (pre-production) collection by using direct membership queries or other WQL query. Recommendation It is recommended to use direct membership rules to populate the Microsoft Updates Tool (preproduction) collection. This reduces the risk of SMS clients inadvertently falling into the scope of the query. When choosing computers to add to the Microsoft Updates Tool (pre-production) collection for testing, use the following guidelines: Use at least one computer of each client operating system version and service pack level that will receive software updates from SMS in the network environment Install software applications on the test computers that would be used in the live network environment 4.5 Planning Software Updates Installation Options When running the DSUW, a number of options are provided on the Configure Installation Agent Settings pages for controlling the way the Software Updates Installation Agent installs updates on SMS client computers. These options define the configuration settings that determine the user experience. These settings include the specification of: whether or not to suppress reboots, whether the installation is run in unattended mode, and whether users are notified about software update activity. There are 3 pages in the DSUW where these settings are be specified. The settings that are specified on these pages should be determined by: The degree of criticality of the software updates in the package The role of the SMS client computers that are the destination of the program that is being defined The enforcement requirements of the healthcare organisation, or of the SMS client computers in the destination collection for the package Page 23

28 Figure 8, Figure 9 and Figure 10 show the three pages of the DSUW where the Configure Installation Agent Settings are configured, and Table 8, Table 9 and Table 10 provide detailed information about these settings. Figure 8: DSUW Configure Installation Agent Settings Page 1 Setting Collect client inventory immediately (may increase system activity) Details When this setting is enabled, the /kick switch is added to the command line. This switch forces the SMS client to perform a hardware inventory cycle following the installation of software updates. Caution This setting causes a hardware inventory cycle to occur which could generate an increase in network traffic. In large environments use this option with care. Create client templates for reference computer desired state Postpone restarts for Close running programs and discard unsaved When this setting is enabled, the /x switch is added to the command line. This switch is used to define an authorisation list for a standard image baseline. This setting allows restarts to be postponed for either no computers, only workstations, only servers or both servers and workstations. When this setting is enabled, running programs will be forced to end before system shutdown, instead of asking users to save data. Caution Enabling this setting could result in data loss on SMS client computers. Table 8: Details of Configure Installation Agent Settings Page 1 Page 24

29 Figure 9: DSUW Configure Installation Agent Settings Page 2 Setting Perform unattended installation of software updates (recommended) Countdown (minutes) Details When this setting is enabled, the software update installation will be performed in unattended mode. This prevents the users from being aware of system activity and can increase security. When this setting is not enabled, end users can receive notifications. The nature of the notifications and the actions that are available to the end user depend on the type of SMS client (Legacy Client or Advanced Client) that is running on the user's computer and the other software update installation settings specified in the wizard. Available when the Perform unattended installation of software updates (recommended) setting is enabled. Recommendation Specify a user countdown of at least 30 minutes. This gives the user time to save documents and review the list of software updates that are being installed. After countdown If the setting Perform unattended installation of software updates (recommended) is enabled, specify whether a computer is restarted or not after installation. (If Postpone restarts for has been selected for Both servers and workstations on the previous screen then this setting will be unavailable). Caution Ensure that it is possible to restart the SMS client computers after installation when not postponing restarts. If the setting Perform unattended installation of software updates (recommended) is not enabled, specify whether, if a user has not started the installation, to install updates after the countdown or postpone the installation. Recommendation When performing an attended install, in After countdown specify the default action as Postpone installation for less urgent updates and Install updates for urgent updates. Maximum run time (minutes) Specify a time value after which an unresponsive installation will be cancelled. Table 9: Details of Configure Installation Agent Settings Page 2 Page 25

30 Figure 10: DSUW Configure Installation Agent Settings Page 3 Setting Notify users about update activity (Advanced Client only) Require updates to be installed as soon as they are advertised Users can postpone indefinitely Allow users to postpone for Details When this setting is enabled, users will be notified about update activity through a balloon tip in the notification area. This should be used for high priority, critical updates. This setting makes update installation mandatory. This should be used for low-priority updates. This setting allows users an infinite amount of time to install updates. This should be used for intermediate priority updates. This setting allows the creation of a customised installation schedule. Table 10: Details of Configure Installation Agent Settings Page 3 Page 26

31 5 DEVELOP During the Develop phase the solution components are built based on the planning and designs completed during the earlier phases. Further refinement of these components will continue into the stabilisation phase. Figure 11 acts as a high-level checklist, illustrating the sequence of events which the IT Manager and IT Architect need to determine when planning for software update management using SMS 2003, within a healthcare organisation. Preparing an SMS Infrastructure for Software Update Management Creating a Package Source Location Choosing a Synchronisation Host Site Settings Hardware Inventory Software Distribution Settings Installing ITMU Installation Overview Prerequisites Installing Design ITMU Configuring ITMU Create Collections Add Extra Pilot Computers Configure Advertisements Figure 11: Sequence for Developing 5.1 Preparing an SMS Infrastructure for Software Update Management Creating a Package Source Location When software updates are distributed in SMS by using the DSUW, it is necessary to specify a package source location for storing the source files for the updates in the package. This location is used by SMS for copying the files to DPs; SMS clients do not use the files in this location. The location must be specified as a UNC path to a share on a server. Typically, the package source location will be a share on an SMS site server. The folder used for the package source location is important for a number of reasons: It contains the definitive, tested versions of the software updates that have been authorised for distribution in the healthcare organisation. It contains information about security vulnerabilities that are known to exist in the network environment. Page 27

32 For these reasons, it is important that the folder is protected. Create a directory in which to store the package source files and share that directory as a hidden share. The share and NTFS permissions on of the folder should be set as follows: Grant Write permissions to SMS domain administrators only. Grant Read and Execute permissions to the security context for the SMS executive on the site server. Note The SMS executive is run under either the user account that is used to run SMS in Standard Security mode or the Local System account when SMS is running in Advanced Security mode. To determine which account is being used for the SMS executive, open the SMS Administrator Console, right-click the root of the SMS site under Site Hierarchy and click Properties. On the Accounts tab check the account name specified under SMS Service account or SQL Server Account. Do not grant Read permissions to users of lower credentials. In particular, do not grant Read permissions on the folder to the Everyone group. Note Ensure that the folder is backed up according to a regular schedule, as determined by the backup policy for the healthcare organisation. When choosing the location for the package source folder, ensure that the location has adequate available storage space for the files it will hold. The amount of storage space required depends on the number and the diversity of software updates that are chosen for distribution in the healthcare organisation s network environment. The total size of these files can amount to many gigabytes in size Choosing the Synchronisation Host The synchronisation host is an SMS Advanced Client computer that is responsible for updating the PkgSource folder containing the catalogue file. The catalogue file provides the list of released software updates. This computer runs a program which connects to the Internet or to a local catalogue location to update the PkgSource folder with the latest catalogue file. Recommendation The synchronisation component advertisement should run once a week. It is recommended to schedule the time of the day at which it occurs to the release of the security catalogue update on the Microsoft Downloads Center. This ensures that the latest catalogue file is downloaded as soon as it is released. The security update catalogue is typically released on a Tuesday; configure the synchronisation component advertisement to run on Wednesday mornings. The computer that is used for catalogue synchronisation must be an SMS Advanced Client. If the synchronisation host does not have a connection to the Internet, it is possible to specify a local catalogue location and the synchronisation program will look there for the Windows Update Catalog. The Windows Update Catalog must be manually copied to this location. Subsequently, when a new catalogue is released it must be manually copied again to this location. If the synchronisation host has an Internet connection, then ITMU setup will connect to the Internet and copy the latest catalogue to the PkgSource folder. Important It is not essential for the site server to have a connection to the Internet to synchronise the Windows Update Catalog. The security implications of allowing the site server to access the Internet should be carefully considered, bearing in mind that the account used to run synchronisation must have local Administrator privileges, thereby increasing the security risk to the healthcare organisation. Page 28

33 When the catalogue is downloaded manually, updates to DPs are not performed automatically and will need to be manually run. The ITMU Setup Wizard requests that the hostname of one computer is specified as the synchronisation host. After ITMU setup is complete, the synchronisation host runs a program that updates the PkgSource folder, either from the Internet or from the local catalogue location. Recommendation Where possible, use a remote workstation as the synchronisation host. Ensure this machine is fully updated and secured and can be left switched on at all times. In order for this machine to have the necessary permissions to synchronise the catalogue, follow the procedures in APPENDIX A to configure the synchronisation host to run in unattended mode. If a remote workstation is not available, use the site server on which the ITMU tools are installed as the synchronisation host, bearing in mind the security considerations mentioned above. 5.2 Site Settings Hardware Inventory The ITMU uses hardware inventory to create an inventory of installed and applicable software updates on SMS client computers. By default, the hardware inventory function is disabled on the SMS primary site to reduce system overheads. The hardware inventory function must be enabled, and the inventory frequency configured in order to use ITMU. The default frequency for SMS hardware inventory is an interval of 7 days. For initial testing purposes, to speed the process of becoming familiar with the software update inventory tools, it can be useful to increase the frequency of the inventory, perhaps running it daily, or even every few hours. Note These hardware inventory setting suggestions are for test purposes only. The actual frequency with which the hardware inventory is run in a full-scale deployment to the larger desktop infrastructure depends on the number of SMS clients in the healthcare organisation s network environment that are to be updated, the frequency with which software updates are deployed, and performance considerations associated with the generation of additional hardware inventory data. Recommendation Do not configure a complex schedule for the hardware inventory and then attempt to schedule the scan component to run shortly before this. For normal operations use a simple schedule for hardware inventory once a week or once every two weeks. For more information about configuring the Hardware Inventory settings, see the SMS 2003 Deployment Guide Initial Site Deployment {R3}. For more information about specific performance issues associated with these tools, see Managing Software Updates {R6} in the Systems Management Server 2003 Operations Guide {R7} Software Distribution Settings The SMS software distribution settings defined in the Advertised Programs Client Agent Properties dialog box allows the SMS client to receive advertisements from the SMS administrator. There are a number of options available to configure how often the SMS client will check for new advertisements and how the SMS client will interact with the logged-on user. Page 29

34 The default frequency with which the software distribution system on an SMS client computer checks for software distribution activity is every hour. For initial test purposes, to avoid unnecessary delays, the Advertised Program Client Agent polling interval can be increased to an interval of 5 minutes, or 10 minutes. Note In a test environment, a short polling interval causes very few system resource usage problems. However, when deploying the tools to the larger desktop infrastructure, the polling interval should be increased, for example, increase to an interval of 4 hours to prevent performance issues. For more information about configuring the SMS software distribution settings, see the SMS 2003 Deployment Guide Initial Site Deployment {R3} and Preparing SMS for Software Distribution and Update Management {R1}. For more information about specific performance issues associated with these components, see Managing Software Updates {R6} in the Systems Management Server 2003 Operations Guide {R7}. 5.3 Installing ITMU SMS 2003 ITMU 3.0 is the latest version, and is available as a download from the following location: This section details the installation prerequisites and installation and verification procedures for installing ITMU. Recommendation It is recommended to install the latest version to ensure access to the most current software updates offered by Microsoft. If a previous version of ITMU is already installed on a site server, it is recommended to upgrade to the latest version Installation Prerequisites Microsoft provides a comprehensive list of hardware and software configuration requirements for installing SMS 2003 ITMU in the SMS 2003 SP2 Supported Configurations 10. Use this information to determine the minimum requirements for SMS site servers and SMS client computers Minimum Hard Disk Space Requirements SMS Site Server To install SMS 2003 ITMU, there must be a minimum of 10 MB of available hard disk space for the installation directory. The installation directory must be formatted with NTFS, must be on a local drive, and must not be encrypted. SMS Clients To install the inventory tool on the SMS 2003 SP1 clients, each SMS client must have an additional 5 MB of available hard disk space for the inventory tool, and 2 MB for the log files Microsoft XML Microsoft XML (MSXML) 3.0 or later must be installed on the SMS site server and on SMS client computers. All SMS client computers capable of running SMS 2003 ITMU should already have a supported version of MSXML installed. If not, MSXML can be downloaded SMS 2003 Supported Configurations {R10}: 11 Microsoft Core XML Services (MSXML) 6.0 Service Pack 1 {R11}: Page 30

35 Update Requirements Windows Installer The Windows Installer is required on Advanced Clients for MSI updates that have an.msp file extension, such as Microsoft Office. The latest version of the Windows Installer, (3.1) should be distributed to SMS clients that do not already have it installed. The version of Windows Installer that is installed on a computer can be determined by checking the file version number of the msi.dll file which is located under %systemroot%\system32, or by running msiexec and noting the version number in the first line of the Windows Installer dialog box. The Windows Installer 3.1 Redistributable package 12 can be downloaded and distributed using standard SMS software distribution. Windows Update Agent The WUA is required on SMS clients for use with ITMU. The software required for installation is provided by ITMU setup, which creates packages and programs for WUA for x86, x64 and IA64 platforms. The relevant version of WUA is then installed once, as a dependant program for the inventory tool. However, if WUA is missing or downgraded on SMS clients, it can be installed separately with the program and package created by the ITMU installation ITMU Installation Procedure Once the latest version of ITMU has been downloaded and the prerequisite hardware and software requirements have been satisfied, then ITMU can be installed. To install ITMU, verify installation and perform a catalogue synchronisation, follow the procedures in this section. To install ITMU: 1. From the directory in which the ITMU setup files were extracted, run SMSITMU.msi, and, when prompted, click Next. 2. Click I accept the licence agreement, and then click Next. 12 Windows Installer 3.1 Redistributable (v2) {R12}: Page 31

36 3. Click Browse to choose the location to install ITMU, or click Next to install to the default location of %programfiles%\microsoft Updates Inventory Tool. Note The installation location must be on a partition that is formatted with the NTFS file system and to which the user account being used to run setup has write permissions. 4. In Synchronisation host computer, enter the name of the SMS Advanced Client computer that has been chosen to retrieve the latest Windows Update Catalog. Note If there is not always a user logged onto the synchronisation host computer with sufficient credentials to download the catalogue file, it may be necessary to configure the synchronisation component for unattended mode. To configure unattended mode, see APPENDIX B. If the synchronisation host computer is able to download the Windows Update Catalog from the Internet, click Next. If the synchronisation host computer will obtain the Windows Update Catalog from a local source, click I will download the catalogue and the synchronisation host will copy it from a folder and then click Browse and select the location in which the latest Wsusscan.cab file is located. Click Next. 5. In Enter a name for the SMS Objects, use the default object name of Microsoft Updates Tool. In Enter the name of a computer to use for testing, enter the name of the SMS Advanced Client computer that has been chosen as the first test computer. Under Distribution Options choose whether the inventory tool package should be copied to all DPs and whether it should be advertised to the Microsoft Updates Tool collection. Click Next. Important If ITMU is reinstalled, the same package names must be chosen. Failure to do so will result in any packages previously created by DSUW to use the obsolete package names causing incorrect results. Page 32

37 6. In Enter a name for the Windows Update Agent SMS Objects, use the default object name of Windows Update Agent. Under Distribution Options choose whether the WUA package should be copied to all DPs and whether a program should be created for installing WUA on SMS clients. This program will be configured as a dependency which will be run before running the inventory tool program. Click Next. 7. Click Next to complete the installation. 8. Click Finish. Table 11: ITMU Installation Steps Page 33

38 To verify the successful installation of ITMU: 1. Open the SMS Administrator Console. 2. In the console tree, expand Site Database and click Collections. Verify that these collections are created: Microsoft Updates Tool, Microsoft Updates Tool (preproduction) Microsoft Updates Tool Sync, Microsoft Updates Tool x64 Microsoft Updates Tool IA64 3. In the console tree, expand Packages. Verify that these packages are created: Microsoft Updates Tool Windows Update Agent x86 Windows Update Agent x64 Windows Update Agent IA64 4. In the console tree, click Advertisements. Verify that these advertisements are created: Microsoft Updates Tool Microsoft Updates Tool Sync Table 12: ITMU Installation Verification Steps 5.4 Configuring ITMU Create Collections In order to target software updates to computers that have compatible Microsoft Windows client operating systems only (Windows 2000 SP4 and higher and Windows XP), it is recommended that a new collection is created that will use a WQL query to list these computers. To create the collection and corresponding WQL query, perform the following procedure: Warning The collection created in the following procedures will contain all SMS client machines running Windows XP and Windows 2000 SP4 and higher. Software updates distributed to this collection will be installed on all of these machines. If this is not ideal, the scope of distribution can be tailored by creating collections that use other customised WQL queries. Page 34

39 To create a collection to list all Windows XP and Windows 2000 SP4 and higher SMS clients: 1. Open the SMS Administrator Console. 2. Right-click Collections and select New > Collection. 3. In Name, type Microsoft Update Windows Clients. 4. Select the Membership Rules tab. Click the button to create a new query rule. Page 35

40 5. In Name, type Windows Clients Query. 6. Click Edit Query Statement. 7. Click Show Query Language. Page 36

41 8. Copy the following WQL query into the Query statement area. Click OK twice. select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_ System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_Sy stem.client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM as o on o.resourceid = SMS_R_System.ResourceId inner join SMS_G_System_PROCESSOR on SMS_G_System_PROCESSOR.ResourceID = SMS_R_System.ResourceId where SMS_R_System.Client = 1 and SMS_R_System.ClientType = 1 and (o.version >= " " and SMS_G_System_PROCESSOR.AddressWidth = 32 or o.version = " " and o.csdversion like "%4%") and SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 5.0" or SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 5.1" Table 13: Creating a Collection Add Extra Pilot Computers After the installation of ITMU, the computer that was chosen for the pilot computer during setup should appear in the Microsoft Updates Tool (pre-production) collection. This computer is added to the collection by a direct membership rule. To add additional computers to this collection for testing software updates, a number of methods can be used: Additional direct membership rules for each computer to be added WQL queries can be created to enable the selection of computers, based on any of a number of different criteria, such as: Active Directory Organisational Unit membership Membership of an Active Directory group The administrator should choose the most appropriate method of adding additional pilot computers to the Microsoft Updates Tool (pre-production) collection, and then add the computers that were chosen for testing in section 4.4. To create a direct membership rule: 1. Open the SMS Administrator Console. Page 37

42 2. Navigate to Collections, and click Microsoft Updates Tool (pre-production). 3. On the Action menu, click Properties. 4. Select the Membership Rules tab. Click the button to create a direct membership rule. 5. Click Next. Page 38

43 6. Select the following: System Resource from the Resource class drop-down list Name from the Attribute name drop-down list In Value, enter the hostname of the computer that is to be added. Note A % sign can be used as a wildcard when the whole hostname is not known. Click Next. 7. In Search in this collection, click Browse to select a collection name in which to search for resources, or leave the box empty to search for resources in all collections. Click Next. 8. Enable the resource to which the direct membership rule is to be added, and then click Next. 9. Click Finish to add the direct membership rule. Note The collection may need to be updated and refreshed before the new computer is added to the collection. Table 14: Creating a Direct Membership Rule Page 39

44 5.4.3 Configure Advertisements The ITMU setup creates advertisements for the Microsoft Updates Tool and Microsoft Updates Tool Sync programs. By default, these advertisements are scheduled to run once a week starting from the date and time of creation. It may be useful to modify these default schedules to more suitable days and/or intervals. When modifying the default schedules, consider the following recommendations: Modify the advertisement schedule of the synchronisation component to run once a week, on the day that the new security update catalogue is released on the Microsoft Download Center 13. Modify the advertisement schedule of the scan component to run once a week on a suitable day and time. Consider when the SMS client computers will be switched on. Do not configure a complex schedule for the hardware inventory and then attempt to schedule the scan component to run shortly before this. Use a simple schedule for hardware inventory, such as once a week or once every two weeks. Create an advertisement that is scheduled to run the scan program on the test computers (in the pre-production collection) daily, optimised to follow the updates to DPs. Use the expedited scan program for the pre-production collection. Warning Be careful when running the expedited scan program. This program causes an immediate hardware inventory cycle to run on completion of the scan program. For large environments, this could cause a significant amount of network traffic. For instructions on how to create new advertisements, see section To modify an existing advertisement: 1. Open the SMS Administrator Console. 2. Navigate to Advertisements. 3. In the right pane, select an advertisement. 4. On the Action menu, click Properties. 13 Microsoft Download Center {R13}: Page 40

45 5. In Name, modify the name of the advertisement. (Optional) Enter a comment in the Comment box. In Package and Program, select the relevant package and program names from the drop-down lists. In Collection, click Browse and select the target collection. Click Include members of subcollections to configure the advertisement to run on members of subcollections. 6. Select the Schedule tab. To modify the current mandatory assignment, click the button. 7. Select Assign to the following schedule and click Schedule. 8. Configure the start time, and recurrence pattern and click OK. Page 41

46 9. Select the Advanced Client tab. Configure the When a distribution point is available locally and When no distribution point is available locally settings. For more information on these settings, see section Select the Security tab. To create a new security right for this advertisement: Under Instance security rights, click the button Enter a user name and select the relevant permissions to assign to the user Click OK. 11. Click OK to save the changes. Table 15: Modifying an Advertisement Page 42

47 6 STABILISE The Stabilise phase involves testing the solution components whose features are complete, resolving and prioritising any issues that are found. Testing during this phase emphasises usage and operation of the solution components under realistic environmental conditions. This involves testing and acceptance of the software update management solution using SMS Figure 12 acts as a high-level checklist, illustrating the critical components which an IT professional responsible for stabilising the implementation of the software update management solution using SMS 2003 needs to determine. Figure 12: Sequence for Stabilising the Software Update Management Solution 6.1 Verifying Catalogue Synchronisation During the ITMU installation (section 5.3.2), a synchronisation host computer was selected. This computer will be responsible for running a program that downloads the latest catalogue file from the Microsoft Download Center. It is important to verify that the synchronisation host has successfully synchronised the catalogue, to ensure that the latest software updates are available. This verification process is described in the following procedure. Page 43

48 To verify that the synchronisation host has successfully synchronised the catalogue: 1. Open the SMS Administrator Console. 2. Navigate to Advertisement Status. 3. Click Advertisement Status, and then on the Action menu, click Refresh. 4. In the console tree, click Microsoft Updates Tool Sync. 5. In the right pane verify that the synchronisation host has received the advertisement, started the program, and successfully completed the advertised program. 6. In the right pane, click the local site., and then On the Action menu, select Show Messages > All. The SMS Status Message Viewer for <site code> window displays. Page 44

49 7. Review the status messages. Note In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 10002, and should appear. These status messages show that the SMS client received, started, and successfully completed running the synchronisation program for the first time. A status message with message ID may also appear, indicating that the program has not started because a request to download the content was initiated. Using the default schedule of running the program daily, message IDs and should then be logged each day. 8. Close the SMS Status Message Viewer <site code> window. Table 16: Verify Successful Synchronisation 6.2 Testing Software Updates Using Pilot Computers Before software updates are installed to the larger desktop infrastructure, they should be tested in a controlled environment using test computers that are representative of the desktop computers used in the healthcare organisation. To test software updates, authorise the updates to be tested and distribute them to the pilot computers that have been chosen for testing. These are listed in the Microsoft Updates Tool (pre-production) collection. When testing software updates, follow a test plan that contains testing objectives. Some example test objectives are as follows: Verify that the update installation command-line syntax and installation behaviour is as expected Verify that the user experience (as configured with the Software Updates Distribution Wizard) is as expected. If the installation contains both Legacy Clients and Advanced Clients, verify that the behaviour is acceptable for each SMS client type Verify that the software update performance is as expected, and that it does not adversely affect the performance of any other enterprise application software When testing software updates, follow a defined process for testing pilot computers to ensure that no adverse effects are experienced. Refer to section for an overview of Microsoft s recommended software update management testing and deployment process. Page 45

50 6.3 Testing Software Update Reporting Data Flow Verifying SMS Client Scanning Functionality During the ITMU installation (section 5.3.2), a pilot host computer was selected; this computer was added by the ITMU setup to the Microsoft Updates Tool (pre-production) collection. Additional pilot computers may also have been added when following the procedures in section Once these computers have been successfully added to the Microsoft Updates Tool (pre-production) collection, and after they have next checked in with a MP, the pilot computers will find the advertisement for the Microsoft Updates Tool program. This program will run the scan tools on SMS clients. Check that the SMS client computers have successfully run the Microsoft Updates Tool program, as described in the following procedure. To verify that the SMS client computer has successfully run the Microsoft Updates Tool program: 1. Open the SMS Administrator Console. 2. Navigate to Advertisement Status. 3. Click Advertisement Status, and then on the Action menu, click Refresh. 4. In the console tree, click Microsoft Updates Tool. 5. In the right pane, verify that the SMS client that has received the advertisement, started the program, and successfully completed the advertised program. Note Notice that two programs were started and successfully installed for each system that ran the program. This is because the dependant program to install the Windows Update Agent was run before running the inventory tool program. Page 46

51 6. In the right pane, click the local site, and then on the Action menu, select Show Messages > All. The SMS Status Message Viewer for <site code> window displays. 7. Review the status messages. Notes If the expedited action with the Microsoft Updates Tool (expedited) is not being used, a hardware inventory on the SMS client computer will need to be initiated or it will be necessary to wait for the next hardware inventory cycle to complete before checking to see which updates are required and before running DSUW. In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 10002, and should appear. These status messages show that the SMS client received, started, and successfully completed running the ITMU program for the first time. When the inventory tool runs again, the message ID will be replaced with message ID A status message with message ID may also appear, indicating that the program has not started because a request to download the content was initiated. 8. Close the SMS Status Message Viewer for <site code> window. Table 17: Verifying Successful Scanning Viewing Software Update Compliance Data Software update compliance data can be enumerated using SMS reporting. Custom reports can be created to gather information around the software update management process or the built-in reports can be used. Note To use SMS reporting, at least one server in an SMS site needs to be configured with the Reporting Point (RP) role. For procedures for installing an RP, see SMS 2003 Deployment Guide Initial Site Deployment {R3}. Page 47

52 Table 18 details the built-in reports used for verifying software update compliance data. Report Name Software update advertisement status by software update ID Software update distribution status by software update ID Software update health Software update status messages for a specific computer within a specified number of days Software updates for a specific computer Comment This report lists all software distribution advertisements for the selected update. For each advertisement, it also shows the advertisement state and count of machines in that state. This report also covers additional advertisement states available for software update advertisements. This report displays the distribution status of a particular software update with the percentage of computers reporting each distribution state. This helps identify the current distribution status for a particular software update. This report will allow an administrator to assess the health of the software update infrastructure by assessing failures across the update lifecycle. The report will provide a list of failures for catalogue synchronisation, scanning, or patch installation agent. This report will help an administrator retrieve all software update status messages including catalogue synchronisation (where applicable), scan, and software update installation on a per client basis. The report will provide data for a user defined timeline. This report displays a list of software updates for a particular computer. Note This report is only as accurate as the most recent hardware inventory data. Software updates not yet authorised This report lists all software updates that have been detected but not yet authorised, ordered by the number of SMS clients reporting the issue as applicable. Note This report is only as accurate as the most recent inventory data. Software updates with count of applicable and installed computers This report displays a list of all installed or applicable software updates along with information about the software update. In addition, the report lists the number of computers for which each software update is missing, and the number of targeted computers on which the software update is already installed. Table 18: Built-in Software Update Compliance Reports To run a built-in report: 1. Open the SMS Administrator Console. 2. Navigate to Reports. Page 48

53 3. In the right pane, click the report name. On the Action menu, select All Tasks > Run. Click the name of the Reporting Point server on which to run the report. 4. In the left pane, click on a category to expand the view and then select a report from the list. For example, to view software update compliance for a specific computer, click Software Update - Compliance and then Software updates for a specific computer. In the right pane, click Values to choose from a list of SMS Advanced Clients. Note Each report requires various fields to be filled. For each field, click Values to see a list of available values and make a selection. Alternatively, to narrow the search, enter text in the relevant box using the wildcard %, where applicable, and then click Values. 5. Click the Display icon: Table 19: Running a Built-in Report To create a customised report: 1. Open the SMS Administrator Console. 2. Navigate to Reports. Page 49

54 3. On the Action menu, select New > Report. 4. Enter a name for the report in the Name field. 5. Select a category from the Category drop-down list. 6. In Comment, enter a comment to describe the report. Click Edit SQL Statement. Page 50

55 7. Create an SQL statement: Select criteria from the Views and Columns lists to populate the SQL statement box. 8. Click OK twice. Table 20: Creating a Customised Report Page 51

56 7 DEPLOY During the Deploy phase, the core solution components are deployed for more widespread application and use, and the deployment is stabilised through ongoing monitoring. The solution is then transitioned to operations and support. Figure 13 acts as a high-level checklist, illustrating the critical components which an IT Professional responsible for deploying software update management using SMS 2003 needs to determine. Figure 13: Sequence for Deploying 7.1 Deploying the Scan Tools to Windows Clients During the Develop phase (in section 5.4.1) a collection was created that uses a WQL query to list Windows client operating systems. This collection can be used for targeting the installation of the Windows Update Agent, scan tools and software updates. In order to target the installation of the Windows Update Agent and the scan tools to the new collection, a modification needs to be made to the Microsoft Updates Tool collection. If the Automatic Updates service is configured on SMS clients, it will continue to function when using SMS and ITMU for software update management. Depending on the configuration settings, this could result in the automatic download and/or installation of software updates. To prevent this from happening, turn off Automatic Updates on SMS clients. This can be performed by using one of the following techniques: Warning Do not disable the Automatic Updates service. This service is required by ITMU for software update installation. Centrally through Group Policy in an Active Directory environment by setting the Configure Automatic Updates setting to Disabled Manually using local Group Policy on individual machines by setting the Configure Automatic Updates setting to Disabled Manually by setting the option Turn off Automatic Updates from the Automatic Updates properties in the Control Panel on individual machines Manually through the registry by deleting the REG_DWORD value AUOptions from the HKLM\Software\Policies\Microsoft\windows\WindowsUpdates\AU key For more information on configuring Automatic Updates on Windows XP, see the Microsoft knowledge base article How to configure and use Automatic Updates in Windows XP 14. For more information on configuring Automatic Update through Group Policy and the registry, see the Microsoft knowledge base article How to configure Automatic Updates by using Group Policy or registry settings How to configure and use Automatic Updates in Windows XP {R14} : 15 How to configure Automatic Updates by using Group Policy or registry settings {R15}: Page 52

57 Note The Group Policy setting Remove access to use all Windows Update features can be used to prevent users from using the Windows Update Web site to download and install software updates. For more information on configuring this setting, see Controlling Windows Update and Automatic Updates to Limit the Flow of Information to and from the Internet 16. To modify the Microsoft Updates Tool collection: 1. Open the SMS Administrator Console. 2. Navigate to Collections, and then click Microsoft Updates Tool. 3. On the Action menu, click Properties. 4. Select the Membership Rules tab. Click the button. 16 Using Windows 2000 with Service Pack 4 in a Managed Environment, Controlling Windows Update and Automatic Updates to Limit the Flow of Information to and from the Internet {R16}: Page 53

58 5. Under Collection limiting, click Browse and select the collection created in section Click OK three times. Table 21: Modifying the Microsoft Updates Tool Collection Page 54

59 8 OPERATE During the Operate phase, the deployed solution components are proactively managed to ensure they provide the required levels of solution reliability, availability, supportability, and manageability. Figure 14 acts as a high-level checklist, illustrating the critical components for which an IT professional is responsible for ensuring in a managed and operational software update management using SMS Figure 14: Sequence for Operating 8.1 Using the DSUW to Create a New Deployment Package The DSUW is used to create a deployment package containing software updates that are needed by SMS clients in the healthcare organisation s network environment. The procedures in this section assist with the following tasks: Running the DSUW to create a new package Verifying that the DPs chosen during the running of the DSUW have successfully received a copy of the package Creating advertisements for the new software updates package Verifying that the software updates have been installed on SMS clients Page 55

60 8.1.1 Running the DSUW to Create a New Package To run the DSUW to create a new package: 1. Open the SMS Administrator Console. 2. Navigate to Software Updates. 3. On the Action menu, select All Tasks > Distribute Software Updates. 4. Click Next. 5. Ensure that the Select an update type option is selected and the drop-down box is set to Microsoft Update. Click Next. Page 56

61 6. Under SMS packages, select New. Click Next. 7. Under Package name, enter a name for the package. Recommendation Use a name that describes the purpose of the package. For example, when using a multiple package strategy, name the main package that contains all updates All Updates and the monthly package for January Monthly Updates Jan. 8. Modify the text under Organisation accordingly. (Optional) To display a message to users when installing software updates, create a Rich Text Format (.rtf) document and enter the text to be displayed. Save the file. (Optional) Click Import to import an.rtf file, where available. Click Next. 9. If an.rtf file was imported in step 8, click Preview to view the message as it will appear to users. Click Close and then click Next. Page 57

62 10. Ensure that Inventory Scan Tool package and Program name are both set to Microsoft Updates Tool. Click Next. 11. Enable each one of the software updates that are to be authorised for distribution in this package. On completion, click Next. Note To view software updates that are missing on SMS client operating systems (that have been scanned and that have subsequently completed a hardware inventory cycle), sort the list by clicking on the Requested column header. 12. Under Package source directory, choose the directory location for storing the package source files, as specified in section If Internet access is available from the server, leave Download any available update source files for me automatically selected or, alternatively, select I will download the source files myself. Note If updates are not downloaded automatically, they can be downloaded separately and imported from the Properties tab of the update, which can be accessed in step 13. Select a sending priority from the Package sending priority drop-down list. Click Next. Page 58

63 13. To view the properties of an update, or to make modifications to an update: Click to select the update Click Properties Click Next. 14. Enable the DPs to copy the package to. Click Next. 15. Configure page 1 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. Page 59

64 16. Configure page 2 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. Note If the Enforce start time and maximum installation time (Advanced Client only) setting is enabled, the option to create an advertisement for the program (in step 18) will not be presented. In this case, an advertisement will need to be manually created. For more information on creating advertisements, see section Configure page 3 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. 18. Enable Advertise. Under Collection, click Browse and select the collection that was created in section Set Recur every to the recurrence interval. Click Next. Page 60

65 19. Click Finish. Table 22: Creating a New Package Verifying Distribution Points The SMS Status Viewer shows status messages that enable the administrator to verify that the package has been successfully processed and copied to a DP, including any child sites, where appropriate. To verify that the DPs have successfully received the package: 1. Open the SMS Administrator Console. 2. Navigate to Package Status. Expand the relevant package, and click the local site. 3. In the right pane, select a distribution point server. 4. On the Action menu, select Show Messages > All. Page 61

66 5. Click Select date and time, select a time interval between which the package in section was created. Click OK. The SMS Status Message Viewer for <site code> window displays. 6. Review the status messages. Note In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 2300, 2311, 2342, 2329, 2330, 2335 and 2301 should appear. These status messages show that the package has been successfully processed and copied to a DP. If DPs exist in child sites and were chosen to hold a copy of the package during package creation, additional message IDs including 2333, 2235 and 2339 should appear for each child site. These messages show that the package has been successfully copied to the DPs in the child sites. 7. Close the SMS Status Message Viewer for <site code> window. Table 23: Verifying Distribution Points Creating Advertisements When an advertisement has not been created during the creation of a package, or when an additional advertisement is required, for example, to specify different distribution options, use the following procedure: To create advertisements for the new software updates package: 1. Open the SMS Administrator Console. 2. Navigate to Advertisements. Page 62

67 3. On the Action menu, select New > Advertisement. 4. In Name, enter a name for the advertisement that describes its purpose, such as Microsoft Update All Updates. In Package and Program select the relevant package and program names from the drop-down lists. In Collection, click Browse and select the collection created in section Select the Schedule tab. Enter a suitable recurring schedule for the advertisement. 6. Select the Advanced Client tab. When using a multiple package strategy, change the When no distribution point is available locally option to: Do not run program for the main package, and Download program from a remote distribution point for the monthly update packages. Table 24: Creating Advertisements Page 63

68 8.1.4 Verifying Updates are Successfully Installed To verify that software updates are installed on SMS clients: 1. Open the SMS Administrator Console. 2. Navigate to Advertisement Status. 3. Click Advertisement Status, and then on the Action menu, click Refresh. 4. In the console tree, click the relevant advertisement name. 5. In the right pane, verify that the SMS clients have received the advertisement, started the program, and successfully completed the advertised program. 6. In the right pane, select the local site. On the Action menu, select Show Messages > All. The SMS Status Message Viewer for <site code> window displays. 7. Review the status messages. Note In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 10002, and should appear. These status messages show that the SMS client received, started, and successfully completed running the advertised program. A status message with message ID may also appear, indicating that the program has not started because a request to download the content was initiated. Page 64

69 8. Close the SMS Status Message Viewer for <site code> window. Table 25: Verifying Software Update Installation 8.2 Using the DSUW to Update an Existing Deployment Package Packages are updated when new software updates need to be authorised for distribution or when distribution settings need to be modified. For more information on planning a strategy for creating packages, see section 4.2. The DSUW is used to modify an existing deployment package with additional software updates that are needed by SMS clients in the healthcare organisation s network environment. The procedures in this section assist with the following tasks: Running DSUW to update an existing package Updating DP s with the latest copy of the package and verifying that the updates are successfully processed on the DP s Verifying that the software updates have been installed on SMS clients Running the DSUW to Update an Existing Package To run the DSUW to update an existing package: 1. Open the SMS Administrator Console. 2. Navigate to Software Updates. 3. On the Action menu, select All Tasks > Distribute Software Updates. Page 65

70 4. Click Next. 5. Ensure that Select an update type is selected and the dropdown box is set to Microsoft Update. Click Next. 6. Under SMS packages, click a package to modify. Click Next. Page 66

71 7. Under Program name, select the relevant program name. 8. If required, modify the text in Organisation accordingly. (Optional) To display a message to users when installing software updates, create a Rich Text Format (.rtf) document and enter the text to be displayed. Save the file. (Optional) Click Import to import an.rtf file, where available. Click Next. 9. If an.rtf file was imported in step 8, click Preview to view the message as it will appear to users. Click Close and then click Next. 10. Ensure that Inventory Scan Tool package and Program name are both set to Microsoft Updates Tool. Click Next. Page 67

72 11. Enable the additional software updates that are to be authorised for distribution in this package. On completion, click Next. Note To view software updates that are missing on SMS client operating systems (that have been scanned and that have subsequently completed a hardware inventory cycle) sort the list by clicking on the Requested column header. 12. If Internet access is available from the server, leave Download any available update source files for me automatically selected or, alternatively, click I will download the source files myself. Note If updates are not downloaded automatically they can be downloaded separately and imported from the Properties tab of the update, which can be accessed in step 13. Select a sending priority from the Package sending priority drop-down list. Click Next. 13. To view the properties of an update, or to make modifications to an update: Click to select the update Click Properties Click Next. Page 68

73 14. Enable the DPs to copy the package to. Click Next. 15. Configure page 1 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. 16. Configure page 2 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. Page 69

74 17. Configure page 3 of the Configure Installation Agent Settings, as determined in the Plan phase (see section 4.5). Click Next. 18. Click Next if Advertise is already selected (the program is already being advertised) OR Click Advertise Under Collection, click Browse and select the collection that was created in section Set Recur every to the recurrence interval. Click Next. 19. Click Finish. Table 26: Updating an Existing Package Page 70

75 8.2.2 Updating and Verifying Distribution Points The Update Distribution Points option allows the administrator to update all sites and DPs with the latest version of the package. The SMS Status Viewer shows status messages that enable the administrator to verify that the package has been successfully processed and copied to a DP, including any child sites, where appropriate. To update DPs with the package: 1. Open the SMS Administrator Console. 2. Navigate to Packages and select the relevant package. 3. On the Action menu, select All Tasks > Update Distribution Points. 4. Click Yes. Warning Updating DPs over slow WAN links could cause a significant increase in network activity. Table 27: Updating Distribution Points To verify that the distribution points have been updated: 1. Open the SMS Administrator Console. 2. Navigate to Package Status, select the relevant package, and click the local site. 3. In the right pane, select a distribution point server. Page 71

76 4. On the Action menu, select Show Messages > All. 5. Click Select date and time, then select a time interval between which the package was created. Click OK. The SMS Status Message Viewer for <site code> window displays. 6. Review the status messages. Note In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 2300, 2311, 2342, 2329, 2330, 2335 and 2301 should appear. These status messages show that the package has been successfully processed and copied to a DP. If DPs exist in child sites and were chosen to hold a copy of the package during package creation, additional message IDs including 2333, 2235 and 2339 should appear for each child site. These messages show that the package has been successfully copied to the DPs in the child sites. Table 28: Verifying Distribution Points Page 72

77 8.2.3 Verifying Updates are Successfully Installed To verify that software updates are installed on SMS clients: 1. Open the SMS Administrator Console. 2. Navigate to Advertisement Status. 3. Click Advertisement Status, and then on the Action menu, click Refresh. 4. In the SMS Administrator Console, click the relevant advertisement name. 5. In the right pane, verify that SMS clients have received the advertisement, started the program, and successfully completed the advertised program. 6. In the right pane, select the local site. On the Action menu, select Show Messages > All. The SMS Status Message Viewer for <site code> window displays. 7. Review the status messages. Note In the SMS Status Message Viewer for <site code> window, status messages with message IDs of 10002, and should appear. These status messages show that the SMS client received, started, and successfully completed running the advertised program. A status message with message ID may also appear, indicating that the program has not started because a request to download the content was initiated. 8. Close the SMS Status Message Viewer for <site code> window. Table 29: Verifying Software Update Installation Page 73

78 8.3 Removing Packages When a package is no longer required it can be deleted from the SMS Administrator Console. When a package is deleted, all programs, advertisements and access rights for the package will also be deleted. In addition, all copies of the package, on all DPs that have been configured to hold a copy of the package, will be deleted. To remove a package: 1. Open the SMS Administrator Console. 2. Navigate to Packages and click the relevant package. 3. On the Action menu, click Delete. The Delete Package Wizard starts. 4. Click Next. 5. Either: Select Yes, I want to see more information to be presented with further screens confirming the consequences of deleting this package, or Select No, I know that I want to delete this package Click Next. 6. Follow the prompts to complete the Delete Package Wizard. Click Finish to permanently delete the package. Table 30: Removing a Package Page 74

79 8.4 Securing SMS Packages The SMS packages that contain software updates should be secured to ensure that only administrative users have permissions to modify the contents of the package. Use the procedures below to check the current permissions and modify permissions where necessary. To secure a package: 1. Open the SMS Administrator Console. 2. Navigate to the relevant package and click Access Accounts. 3. Check the current access rights for the package. Note By default, Administrators have Full Control permissions and Users have Read permissions. 4. On the Action menu click New. Either: Select Windows User Account (then follow steps 5 to 7), or Select Generic Access Account (then follow steps 8 to 10) Note When Windows User Account is selected, a local user or group, or an Active Directory user or group can be added. When Generic Access Account is selected only Users, Guests or Administrators can be added, which provides the ability to define more generic permissions. Page 75

80 5. Click Set. 6. Under Account type, click either User or Group and then enter the name of the user or the group in the User name box. Click OK. 7. Select the access rights to assign to the Windows User Access Account from the Permissions drop-down list. Click OK. 8. Click Set. Page 76

81 9. Click Users, Guests or Administrators and then click OK. 10. Select the access rights to assign to the Generic Access Account from the Permissions drop-down list. Click OK. Table 31: Securing a Package Page 77

82 APPENDIX A SKILLS AND TRAINING RESOURCES The tables in PART I of this appendix list the suggested training and skill assessment resources available. This list is not exhaustive; there are many third-party providers of such skills. The resources listed are those provided by Microsoft. PART II lists additional training resources that might be useful. A full list of the SMS documentation provided by Microsoft is available at: PART I Training and Skills Assessment Resources Available SMS Training Courses Skill or Technology Area Resource Location Description Managing Microsoft Systems Management Server asp Course 2596: Five days instructor-led training. Planning and Deploying Microsoft Systems Management Server asp Course 2597: Three days instructor-led training Table 32: Resources for SMS Training Courses SMS Concepts Skill or Technology Area Resource Location Description SMS 2003 Concepts, Planning and Deployment Guide Read online: ms2003/cpdg/default.mspx?mfr=true A core document for SMS Provides valuable information about planning to deploy SMS 2003, important SMS concepts, and directions to install SMS This resource is a key to understanding SMS. Table 33: Resources for SMS Concepts SMS Planning and Design Skill or Technology Area Resource Location Description Scenarios and Procedures for SMS 2003: Planning and Deployment Download: milyid=e0644bb a18-9bc180713f7e Provides three layers of detail to accommodate the expert administrator, the experienced administrator, and the new administrator of Microsoft Systems Management Server Table 34: Resources for SMS Planning and Design Page 78

83 Operating an SMS Environment Skill or Technology Area Resource Location Description SMS 2003 Operations Guide Scenarios and Procedures for SMS 2003: Maintenance, Backup and Recovery Download: milyid=bd2b c19-a00b- 628E65F6F826&displaylang=en Read online: ms2003/opsguide/default.mspx Download: milyid=d2562e2b-640b-4ab7-ab5a acf2458&displaylang=en Read online: A core document for SMS Provides advanced, in-depth technical information, targeted to SMS administrators, about how to configure and use SMS 2003 in a production environment. Describes how to maintain, backup and recover the SMS site. Table 35: Resources for Operating an SMS Environment SMS Reporting Skill or Technology Area Resource Location Description SMS 2003 Operations Guide Download: milyid=bd2b c19-a00b- 628E65F6F826&displaylang=en Read online: ms2003/opsguide/default.mspx A core document for SMS Provides advanced, in-depth technical information, targeted to SMS administrators, about how to configure and use SMS 2003 in a production environment. Also contains information on the SMS reporting feature. Using SMS 2003 SQL Views to Create Custom Reports Read online: Provides an overview of the WMI and SMS SQL view schemas, an overview of typical SQL statements that are used when creating reports, an overview of the built-in reports and associated components for creating reports, a demonstration of how the views can be joined to other views to retrieve the desired data, and detailed information about the SMS views and view categories. Table 36: Resources for SMS Reporting Deploy Software Updates Skill or Technology Area Resource Location Description Scenarios and Procedures for SMS 2003: Software Distribution and Patch Management SMS Technical FAQ: Software Updates milyid=32f2bb4c-42f8-4b8d-844f- 2553fd78049f&displaylang=en chfaq/tfaq09.mspx This guide explains the processes for both software distribution and software updates. FAQ page for Software Updates. Page 79

84 Skill or Technology Area Resource Location Description SMS 2003 Software Update Management to Mobile Computers Desktop Patch Management with SMS 2003 Deploying Software Updates Using the SMS Software Distribution Feature Video: Using the SMS 2003 Inventory Tool for Microsoft Updates SMS 2003 Inventory Tool for Microsoft Updates Microsoft Systems Management Server 2003 Inventory Tool for Microsoft Updates Pre- Installation Guide milyid=16851abc-fe04-4c19-87dd- 7d2170f4191c&displaylang=en mspx date.mspx w/ asx milyid=6eabbde3-a169-4b ea76c74&displaylang=en This whitepaper describes best practices from Microsoft for managing software updates to mobile computers using Systems Management Server Best practices and experiences from Microsoft IT that give a unique, inside view into how Microsoft plans for, deploys, and manages its own enterprise solutions. Article on using the built-in software update management tools in SMS Technical video on using ITMU. Home page for ITMU. This guide covers the requirements needed to prepare your SMS 2003 environment to install and use the SMS 2003 Inventory Tool for Microsoft Updates. The guide includes information related to installing the following updates; KB900257, KB900401, KB901034, KB899512, KB and Microsoft Windows Installer. Table 37: Resources for Software Update Management SMS Security Skill or Technology Area Resource Location Description Scenarios and Procedures for SMS 2003: Security Download: milyid=3d81b520-a a72dfd34a6c4a44c&displaylang=en Established best practices to create the most secure SMS environment possible, along with guidance to maintain the most secure environment possible. Table 38: Resources for SMS Security Frequently Asked Questions Skill or Technology Area Resource Location Description SMS 2003 Technical Frequently Asked Questions Read online: FAQs covering all areas of SMS. Table 39: Resources for Frequently Asked Questions PART II Title Supplemental Training Resources Link SMS 2003 Webcast Series Table 40: Supplemental Training Resources Page 80

85 APPENDIX B CONFIGURING THE SYNCHRONISATION HOST FOR UNATTENDED MODE The default configuration of the Microsoft Updates Tool Sync program that is created during ITMU installation, results in the program running with the rights of the user that is logged on. This means that a user with the appropriate permissions must be logged on when the synchronisation program runs. If it is not possible to leave the Advanced Client that runs the Microsoft Updates Tool Sync program logged in, it is possible to configure the program to run in unattended mode. When configured to run in unattended mode, the program will run under the Local System context. In order to run the program in unattended mode using the Local System context, a number of permissions must be granted to the synchronisation host computer. Credentials can also be configured for any firewall or proxy servers that require authentication and through which web traffic must pass. This appendix details how to perform the following tasks: Share the package folder for unattended mode Set the NTFS security permissions on the package source folder for unattended mode Set the WMI permissions for unattended mode Provide access for the synchronisation host to the SMS Provider computer Grant permissions to the software updates object, for the synchronisation host Grant permissions on the Microsoft Updates Tool package Update distribution points for the Microsoft Updates Tool package s permissions Configure credentials for firewalls that do no allow anonymous access Re-run the Microsoft Updates Tool Sync advertisement To share the package source folder for unattended mode: 1. Open Windows Explorer. Right-click the PkgSource folder in C:\Program Files\Microsoft Updates Inventory Tool\PkgSource (default location) and click Properties. Page 81

86 2. Select the Sharing tab and then click Permissions. 3. Click Add. 4. Click Object Types. 5. Under Object types, click Computers. Click OK. Page 82

87 6. Under Enter the objects names to select, type domain\synchostcomputer. Click OK. 7. Under Allow, click Full Control. Click OK. Table 41: Sharing the Package Source Folder To set the NTFS security permissions on the package source folder for unattended mode: 1. Select the Security tab. Click Add. 2. Click Object Types. Page 83

88 3. Under Object Types, click Computers. Click OK. 4. Under Enter the objects names to select, type domain\synchostcomputer Click OK. 5. Under Allow, click Full Control. Click OK. Table 42: Setting Permissions on the Package Source Folder To set WMI permissions for unattended mode: 1. On the SMS Provider computer, right-click the My Computer shortcut on the desktop and then click Manage. Note The SMS Provider computer is either the site server or the SMS site database server. The SMS Provider computer was determined when SMS was installed. If the site server is not installed on the SMS site database server, the computer with the SMS Admins local group is usually the SMS Provider. In the Computer Management dialog box, under Services and Applications, right-click WMI Control and then click Properties. Page 84

89 2. Select the Security tab, expand Root, click the SMS node, and then click Security. 3. Click Add. 4. Click Object Types. 5. Under Object Types, click Computers. Click OK. Page 85

90 6. Under Enter the objects names to select, type domain\synchostcomputer$ Click OK. 7. Under Group or user names, select domain\synchostcomputer$. 8. Under Allow in Permissions for domain\synchostcomputer$, click the check boxes to select the following allow permissions: Execute Methods Full Write Partial Write Provider Write Enable Account Remote Enable Click OK. 9. Under Root click SMS. Page 86

91 10. Expand the SMS folder then click <Site_sitecode>. Click Security. 11. Click Add. 12. Click Object Types. 13. Under Object Types click Computers. Click OK. Page 87

92 14. Under Enter the objects names to select, type domain\synchostcomputer$. Click OK. 15. Under Group or user names, select domain\synchostcomputer$. 16. Under Allow in Permissions for domain\synchostcomputer$, click the check boxes to select the following permissions: Execute Methods Full Write Partial Write Provider Write Enable Account Remote Enable 17. Click OK twice. Table 43: Setting WMI Permissions To provide access to the SMS Provider for the synchronisation host: 1. On the SMS Provider computer, at the command prompt, type the following: net localgroup "sms admins" /add domain\synchostcomputer$ Table 44: Providing Access to the SMS Provider Page 88

93 To grant permissions for the synchronisation host computer to the Software Updates object: 1. Open the SMS Administrator Console. 2. Navigate to Software Updates. 3. Right-click Software Updates and select Properties. 4. Select the Security tab. Click the button to add new class security rights. Page 89

94 5. In the User name box, type domain\synchostcomputer. 6. Under Permissions, click all check boxes. 7. Click OK twice. Table 45: Setting Permissions on the Software Updates Object To grant permissions on the Microsoft Updates Tool package: 1. Open the SMS Administrator Console. 2. Navigate to Packages and select the Microsoft Updates Tool package. Page 90

95 3. Right-click Microsoft Updates Tool and select Properties. 4. Select the Security tab. Click the button next to Class security rights. 5. In the User name box, type domain\synchostcomputer. Page 91

96 6. Under Permissions, click all check boxes. 7. Click OK twice. Table 46: Setting Permissions on the Microsoft Updates Tool Package To update distribution points for the Microsoft Updates Tool package s modified permissions: 1. Open the SMS Administrator Console. 2. Navigate to Packages and then select the Microsoft Updates Tool package. 3. On the Action menu select All Tasks > Update Distribution Points. 4. Click Yes. Table 47: Updating Distribution Points Page 92

97 To modify the Microsoft Updates Tool Sync program: 1. Open the SMS Administrator Console. 2. Navigate to the Microsoft Updates Tool package and click Programs. 3. In the right pane, select the Microsoft Updates Tool Sync program and on the Action menu, click Properties. 4. Select the General tab Modify the Command line text by adding /unattend after /s. 5. Select the Environment tab. Change the Program can run setting from Only when a user is logged on to Whether or not a user is logged on. Click OK. Table 48: Modifying the Microsoft Updates Tool Sync Program Page 93