Lesson 2: Updating Infrastructure

---

Deploying updates to all the computers in an enterprise is a daunting task. Even if you manage only a dozen computers, you need to put some thought into the updating infrastructure that you use to store, test, and deploy updates. Depending on the configuration, your updating infrastructure might require the addition of several new computers, or you might be able to add the additional load to existing resources.

This lesson describes the various components that make up an enterprise updating infrastructure, and provides you information with which to design an updating infrastructure for an enterprise.

After this lesson, you will be able to

• Assemble a team of individuals to manage updating responsibilities for an enterprise.

• Asses the updating needs of your organization.

• Identify the components of an updating infrastructure.

• Describe the various methods that can be used to deploy updates in an enterprise.

• Explain the importance of having a lab environment with which to test updates.

Estimated lesson time: 40 minutes

The Updating Team

Identifying individuals with the right mix of technical and project management skills for deploying updates is one of the first decisions that you, and your management, will make. Even before staffing can begin, however, you need to identify the team roles, or areas of expertise, required for update management. Microsoft suggests using the Microsoft Solutions Framework (MSF) team model, which is based on six interdependent multidisciplinary roles: product management, program management, development, testing, user experience, and release management.

• Product management. Product management is responsible for identifying the organization’s business needs and the needs of the end users, and for making sure those needs are supported by the updating process.

• Program management. The program management team’s goal is to deliver updates within project constraints. Program management is responsible for managing the updating schedule and budget, and for reporting status, managing project-related risk factors (such as staff illnesses), and managing the design of the updating process.

• Development. The development team builds the updating infrastructure according to specification. The team’s responsibilities include specifying the features of the updating infrastructure, estimating the time and effort required to deploy the updating infrastructure, and preparing the infrastructure for deployment.

• Testing. The testing team ensures that updates are released into the production environment only after all quality issues have been identified and resolved. The team’s responsibilities include developing the testing strategy, designing and building the updating lab, developing the test plan, and conducting tests.

• User experience. The user experience team ensures that the updating process meets the users’ needs. The team gathers, analyzes, and prioritizes user requirements and complaints.

• Release management. The release management team is responsible for deploying the updates. In large environments, the release management team also designs and manages a pilot deployment of an update to ensure that the update is sufficiently stable for deployment into the production environment.

The MSF team roles are flexible; they can be adapted to your organization’s own processes and management philosophy. In a small organization or a limited deployment, one individual might play multiple roles. In larger organizations, a team might be required to perform all of the tasks assigned to each role.

For more information about the MSF team model, see the MSF Team Model white paper at http://www.microsoft.com/technet/itsolutions/tandp/innsol/msfrl/MSFTM31.asp.

Assessing Your Environment

The first step in planning your strategy to deploy updates is to assess your current environment. Specifically, you need to know what operating systems and applications you have installed in order to identify updates that need to be deployed. You also need to understand the security requirements for each computer system, including which computers store highly confidential information, which are connected to the public Internet, and which will connect to exterior networks.

For each computer in your environment, gather the following information:

• Operating system.Document the operating system version and update level. Also document which optional components, such as IIS, are installed.

• Applications.Document every application installed on the computer, including versions and updates.

• Network connectivity.Document which networks the computer connects to, including whether the computer is connected to the public Internet, whether it connects to other networks across a VPN or dial-up connection, and whether it is a mobile computer that might connect to networks at other locations.

• Vulnerability-limiting factors.Firewalls and virus checkers might protect a computer against a known vulnerability, making the update unnecessary. For firewalls, document which ports are open.

• Site.If your organization has multiple sites, you can choose to deploy updates to computers from a server located at each site to optimize bandwidth usage. Knowing which site a computer is located in allows you to efficiently deploy the updates.

• Bandwidth.Computers connected across low-bandwidth links have special requirements. You can choose to transfer large updates during nonbusiness hours. For dial-up users, it might be more efficient to bypass the network link and transfer updates on removable media, such as CD-ROMs.

• Administrator responsibility.You must understand who is responsible for deploying the updates, and who will fix a problem if a computer fails during the updating process. If others are responsible for individual applications or services, make note of that as well.

• Uptime requirements.Understand any service level agreements or service level guarantees that apply to a particular computer, and whether scheduled downtime counts against the total uptime. This will enable you to prioritize computers when troubleshooting and testing updates.

• Scheduling dependencies.Applying updates requires planning systems to be offline. This can be a disruption for users, even if the computer only requires a quick reboot. Understand who depends on a particular computer so that you can clear downtime with them ahead of time.

Deploying Updates

To meet the needs of various types of organizations, Microsoft provides several different methods for applying updates. The preferred method for deploying updates is Software Update Services (SUS). Large organizations currently using Group Policy objects to distribute software might prefer to use Group Policy objects for deploying updates as well, because it allows them to deploy the update to many systems simultaneously. Group Policy objects can be used to automatically install updates on computers, or to make them available to users through the Add/Remove Programs tool. Finally, enterprises that use Microsoft Systems Management Server (SMS) can use SMS to deploy updates. You can even avoid manually installing updates on new systems by integrating the update directly into the Windows Server 2003 setup files.

Smaller organizations that cannot allocate computing resources to an updating infrastructure can choose to deploy updates manually by using the express or network installations. Small organizations can take advantage of automated update deployment without adding any infrastructure servers by using the Automatic Update client and the Windows Update server.

Table 5.1 lists the advantages and disadvantages of each of the update distribution methods described here.

Table 5.1: Comparison of Update Distribution Methods

Update distribution method	Advantages	Disadvantages
Windows Update	Does not require that any infrastructure be deployed.	Does not allow administrators to test or approve updates. Wastes Internet bandwidth in large organizations.
Software Update Services	Allows administrators to test, approve, and schedule updates. Reduces Internet bandwidth usage.	Requires an infrastructure server.
Group Policy	Provide granular control over which clients receive updates. Can be used to distribute other types of software.	Requires Active Directory. Other than service packs, updates must be manually added to a Windows Installer package.
Add/Remove Programs	Gives end users control over which updates are applied, and when. Can be used to distribute other types of software.	Requires Active Directory, and requires end users to choose to install updates.
Systems Management Server	Provides highly customizable, centralized control over update deployment, with the ability to audit and inventory client systems. Can be used to distribute other types of software.	Requires infrastructure servers and additional licenses.

Automatic Update client

Both Windows Update and Software Update Services use the same client to download and install updates: the Automatic Update client. The Automatic Update client can automatically notify users of critical updates and security updates available either at Windows Update or at a specified Software Update Services server.

Available in Windows 2000 Service Pack 3, Windows XP Home Edition, and Windows XP Professional, the Automatic Update client is a proactive “pull” service that allows for automatic detection, notification, download, and optionally the installation of important updates. The Automatic Update client will even reboot a computer at a scheduled time to ensure that updates take effect immediately.

The Automatic Update client provides for a great deal of control over its behavior. You can configure individual computers by using the System Control Panel utility. Networks that use Active Directory directory service can specify the configuration of each Automatic Update client by using Group Policy settings. In non-Active Directory environments, you can configure computers by changing a set of registry values.

IT administrators can configure Automatic Updates to automatically download updates and schedule their installation for a specified time. If the computer is turned off at that time, the updates can be installed as soon as the computer is turned on. Downloading updates won’t affect a user’s network performance either, because the client downloads the updates by using the Background Intelligent Transfer Service (BITS), an innovative bandwidth-throttling technology that uses only idle bandwidth.

Tip 

This book won’t cover BITS in detail, but you can administer it by using the bitsadmin.exe support tool. You can install the support tools by running \Support\Tools\Suptools.MSI from the Windows Server 2003 CD-ROM.

If complete automation is not acceptable, you can also give users control over when updates are downloaded and installed. As shown in Figure 5.2, the Automatic Update client can be configured by using Group Policy settings to only notify the user that updates are available. The updates are not downloaded or applied until the user clicks the notification balloon and selects the desired updates.

Figure 5.2: The Automatic Update client configured to prompt the user to download

After the Automatic Update client downloads updates, the client checks the digital signature on the updates before applying them to prevent an attacker from sneaking in a Trojan horse. To verify that updates were installed, you can specify the address of a Web server to which the Automatic Update client should send statistics about updates that have been downloaded, and whether the updates have been installed. These statistics appear in the IIS usage log file of the Web server.

See Also 

To learn more about the Automatic Update client, and to download the software, visit http://www.microsoft.com/windowsserversystem/sus/.

Windows Update

Windows Update is a free Microsoft service for keeping computers running Windows up-to-date with the latest software updates. Windows Update is made up of three components: the Windows Update Web site, the Automatic Update client, and the Windows Update Catalog. Millions of people use the Windows Update Web site each week as a way to keep their Windows-based systems current. When a user connects to the Windows Update site, Windows Update evaluates the user’s computer to check which software updates and updated device drivers should be applied to keep the system secure and reliable.

The Windows Update Web site includes a catalog of all software update installation packages for downloading by administrators. These software update installation packages can then be stored on CD, distributed, and installed through other means, such as SMS or non-Microsoft software distribution tools, or they can be used when installing new computers.

Software Update Services

SUS is like a copy of Windows Update inside your corporate firewall for critical updates and security updates. SUS connects to the Windows Update site, downloads critical updates, security updates, and service packs, and adds them to a pipeline for administrator approval. SUS will then notify administrators by e-mail that new updates are available. After an administrator has approved and prioritized these updates, as illustrated in Figure 5.3, SUS will automatically make them available to all computers running Windows 2000 Server, Windows 2000 Professional, Windows XP, or Windows Server 2003. The client-side components on these computers will then check the SUS server and automatically download and install updates as configured by the administrators.

Figure 5.3: Approval of updates using Software Update Services

SUS is designed to be used in large organizations. Almost every aspect of the behavior can be customized. For example, the SUS server can download updates from Microsoft automatically, manually, or on a schedule specified by an administrator. SUS servers can be tiered as shown in Figure 5.4, with multiple SUS servers synchronizing updates between each other. This optimizes the use of your Internet connection by only requiring each update to be downloaded once for the entire organization. It also optimizes traffic on your wide area networks by allowing clients to download updates from a local SUS server.

Figure 5.4: Tiered Software Update Services architecture

You can take advantage of the ability to approve updates for internal users without storing updates locally. Administrators can configure SUS to direct the Automatic Update client to retrieve approved downloads directly from Microsoft. This reduces the storage requirements on the SUS server, and can be more efficient for large networks spread over geographically disparate sites.

To install Software Update Services on a server, that computer must already have IIS 5.0 (for Windows 2000 Servers) or IIS 6.0 (for Windows Server 2003 computers) installed, because the Automatic Update client retrieves updates by using Web requests. Because this is a service that only clients on the internal network or across a VPN should be connecting to, you should protect this computer from the public Internet by using a firewall.

See Also 

To learn more about SUS, and to download the software, visit http://www.microsoft.com/windowsserversystem/sus/.

Group Policy

Any software contained in a Windows Installer package can be delivered to computers by using the Software Installation node of a Group Policy object. Windows Installer is a Windows component that standardizes and simplifies the way you install and manage software programs such as updates. You can use Windows Installer to manage the installation, modification, repair, and removal of software programs. Windows Installer facilitates consistent deployment, which enables you to manage shared resources, customize installation processes, and solve configuration problems.

Typically, the only updates Microsoft releases with Windows Installer packages are service packs. But it is possible to package other updates within an .msi file if you determine that Group Policy software installation is the best way to deploy updates in your organization. Because service packs are applied across organizations to computers rather than to specific users, you should deliver the package by using a computer-level Group Policy deployment.

To deploy a service pack or other update by using a Windows Installer file, first identify one or more shared folders in which to locate the files. Service packs, in particular, can be very large. To optimize network utilization in enterprises with multiple locales, identify shared folders at each location. Then apply separate Group Policy objects (GPOs) to each location by linking GPOs to location-based organizational units, by linking the GPOs to Active Directory sites, or by using security to allow only the computers in a specific location to apply that location’s GPO. Use Windows Management Instrumentation (WMI) filtering to ensure that the update is applied only to computers with software that requires the update.

See Also 

For more information about using security and WMI filtering to filter GPOs, refer to Chapter 3, “Deploying and Troubleshooting Security Templates.”

If you have to troubleshoot a problem with an update, or any other Windows Installer package, you might need to move the affected computers out of the scope of the Group Policy object and then back into the scope. Therefore, you should use the Uninstall This Application When It Falls Out Of The Scope Of Management option when deploying updates by using a Group Policy object, as shown in Figure 5.5. Using this option causes the update to be removed if you move a computer out of the scope of the Group Policy object.

Figure 5.5: Selecting Uninstall This Application When It Falls Out Of The Scope Of Management

Add/Remove Programs

In some circumstances, you might want to make an update available to users without actually requiring them to apply the update. This is an ideal way to encourage other administrators, developers, and power users to update their own machines, without forcing them to apply an update. Development and lab environments often require that the administrators manually apply updates to avoid conflicts with other work that the administrator or developer is using the system for. Additionally, users who access the network across a dial-up link might want to choose to manually apply updates when they are not going to be using the network connection for several minutes.

If you want to advertise an update by using the Add/Remove Programs tools instead of forcibly installing the update, you can use a .zap file to allow the update to be published. Updates don’t include .zap files, but they can be easily created. Installations that use .zap files require the user to be logged on as the local administrator because the update process will run under the current user’s context.

See Also 

For more information about using .zap files, refer to Microsoft Knowledge Base article 231747 at http://support.microsoft.com/?kbid=231747.

If low disk space causes the service pack installation to fail, the update might appear as installed in the Add/Remove Programs tool but not appear as installed with Winver.exe. If this occurs on a portion of the deployment, move the affected computers out from under the scope of the managed program (for example, you might move them to another organizational unit). Create enough free space for the service pack to be installed, and then return the computers to the organizational unit with the service pack deployment. You must reboot the computers to accomplish both the removal and the reinstallation of the service pack.

Tip 

Winver.exe is more accurate than the Add/Remove Programs tool, so always use Winver.exe to verify that an update has successfully installed.

Systems Management Server

Though simply applying updates is not reason enough to deploy Systems Management Server (SMS), if you already use SMS, it is an excellent way to keep your network’s computers up-to-date. SMS provides a variety of tools to help you deploy updates in your organization. With the software distribution feature of SMS, you can automatically update all of the SMS client computers in your organization with the new update. You can allow your users to run the update installation whenever they like, or you can schedule the update installation to run at a specific time. You can also schedule it to run on SMS client computers at a time when your users are not logged on.

If you are still using SMS 2.0, you should evaluate the SUS Feature Pack. With SMS 2.0 and the SUS Feature Pack, administrators are able to easily manage security updates throughout the enterprise. SMS has always been able to distribute any type of software, but the SUS Feature Pack adds functionality that streamlines the security patch management process. The SUS Feature Pack for SMS 2.0 is designed to quickly and effectively assess and deploy security patches for Windows, Microsoft Office, and other products scanned by the Microsoft Baseline Security Analyzer (MBSA). The Feature Pack provides the following new tools for SMS:

• Security Update Inventory Tool. This adds MBSA-style updating inventory capabilities to the existing hardware inventory capabilities of SMS.

• Microsoft Office Inventory Tool for Updates. This provides inventory capabilities for Office updates.

• Distribute Software Updates Wizard. This component provides a tool that reliably installs updates on end-user computers without forcing the computer to restart before the user is ready.

• Web Reports Add-in for Software Updates. This provides administrators with reports describing the current status of deployed updates in the enterprise.

The Update Test Environment

There are two primary ways you can test an update: in a test environment and in a pilot deployment. A test environment consists of a test lab or labs and includes test plans that detail what you will test and test cases that describe how you will test each component. Organizations that have the resources to test updates in a test environment should always do so, because it will reduce the number of problems caused by update incompatibility with applications. Even if your organization does not have the resources to test critical updates and security updates, you should always test service packs before deploying them to production computers.

The test lab can be made up of a single lab or of several labs, each of which supports testing without presenting risk to your production environment. In the test lab, members of the testing team can verify their deployment design assumptions, discover deployment problems, and improve their understanding of the changes implemented by specific updates. Such activities reduce the risk of errors occurring during deployment and allow the members of the test team to rapidly resolve problems that might occur while deploying an update or after applying an update.

Many organizations divide their testing teams into two subteams: the design team and the deployment team. The design team collects information that is vital to the deployment process, identifies immediate and long-term testing needs, and proposes a test lab design (or recommends improvements to the existing test lab). The deployment team completes the process by implementing the design team’s decisions and then testing new updates on an ongoing basis.

During the beginning of the lifetime of the updating test environment, the deployment team will test the update deployment process to validate that the design is functional. Later, after your organization has identified an update to be deployed, the deployment will test the individual updates to ensure that all the updates are compatible with the applications used in your environment.

An updating test environment should have computers that represent each of the major computer roles in your organization, including desktop computers, mobile computers, and servers. If computers within each role have different operating systems, you should have each operating system available either on a dedicated computer or in a multi-boot configuration.

Planning 

It can be tough to convince management to allocate budget for a lab. To help justify that cost, calculate the potential cost of an update that causes widespread problems and the likelihood of that problem occurring, and determine how long it will take to recoup the investment.

After you have a set of computers that represent each of the various types of computers in your organization, connect them to a private network. You will also need to connect test versions of your updating infrastructure computers. For example, if you plan to deploy updates by using Software Update Services, you should connect an SUS server to the lab network.

Load every application that users will use onto the lab computers, and develop a procedure to test the functionality of each application. For example, to test the functionality of Internet Explorer, you could visit both the Microsoft Web site and an intranet Web site. Later, when testing updates, you will repeat this test. If one of the applications fails the test, it is possible that a problem was caused by the update you are currently testing.

Tip 

If you will be testing a large number of applications, you should identify ways to automate the testing of updates by using scripting.

The server update testing process is not complete unless the test servers are tested under a heavy load. To facilitate this, Microsoft provides several tools for testing applications under an artificial load. For testing updates to IIS, use the Web Application Stress (WAS) tool to simulate load on the server. For testing Exchange Server computers, use the Exchange Stress And Performance Tool. For Microsoft SQL Server computers, use the SQLIOStress Utility. Each of these tools can be downloaded from http://www.microsoft.com/downloads/.

Practice: Evaluating Your Updating Infrastructure

In this practice, you will think about the updating infrastructure that your current work environment is, and should be, using. Use the following questions to guide your thoughts.

1. How does your current organization deploy updates to computers on the network?

2. How long does it take for updates to be delivered to computers on your network? Is the current delay acceptable, or does it leave your network vulnerable to attack?

3. Who decides on whether an update should be deployed? In retrospect, have updates been deployed unnecessarily, or have important updates been skipped? Is the same group responsible for both identifying and deploying updates, and, if so, is this a conflict of interest?

4. If you had the opportunity to perform an overhaul of your organization’s updating infrastructure, which deployment method would you use?

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

1. Which of the following deployment methods gives administrators the opportunity to approve updates before releasing them to clients? (Choose all that apply.)

   1. Windows Update

   2. Software Update Services

   3. Group Policy

   4. Add/Remove Programs

   5. Systems Management Server

2. Which of the following deployment methods can be used to automatically deploy all security updates that Microsoft releases to client computers, without administrator intervention? (Choose all that apply.)

   1. Windows Update

   2. Software Update Services

   3. Group Policy

   4. Add/Remove Programs

   5. Systems Management Server

Lesson Summary

• The Automatic Update client connects to either the public Windows Update server or a private SUS server to download, and optionally install, updates.

• Systems Management Server is capable of working closely with SUS to deliver updates to an enterprise.

• Group Policy can be used to deliver updates, though it is not the preferred method.

• A lab environment is required for detailed testing of updates. The more testing you perform on an update, the fewer problems you will experience when you deploy that update to the production computers on your network.

---