Distributing Software Using Microsoft Management Technologies

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Rod Trent

Published April 2003

Click here to download a copy of this paper.

Abstract

Microsoft Systems Management Server (SMS) 2.0 and 2003, Windows Server 2003, and Windows 2000 Group Policies give organizations the tools to distribute software in a cost-effective manner. The size, budget, and experience of the organization determine which Microsoft tool, or combination of tools, offers the best overall coverage and value for the environment.

On This Page

Introduction
Company Profiles
Technology Overview
The Case for Automated Software Distribution
Distribution with SMS 2.0
Distribution with SMS 2003
Distribution with Group Policy
Application Deployment with Terminal Services
Patch Management—Distribution with SUS
Summary
For More Information
Appendix A

Introduction

Microsoft offers several technologies to allow companies to manage their Windows computers. Some of these technologies are built into the operating system, while others deliver more extensive services as separate applications. One of the more critical aspects to managing a Windows environment is the ability to deploy new applications, application updates and upgrades, fixes to the operating system, and patches vital to the security of the organization.

Distributing new or updated software can be a time-consuming event for any size organization. Moreover, an organization without a specific management strategy for distributing software translates into the loss of time, resources, and revenue. Many companies have employed various products that are patched together to provide solutions that have high overhead costs to implement and maintain. Microsoft has developed several solutions that help lower the overall cost of owning and maintaining technology that can effectively replace the existing patchwork and automate the management of computer systems. This paper gives an overview of each technology as well as real-world examples to help better understand not only what tools are available to Microsoft customers but also to determine which tool works best in a given scenario.

In this paper, you’ll find the following sections.

This Section:	Describes:
Company Profiles	Suggested software distribution technologies for various sizes of organizations
Technology Overview	An overview of Microsoft management products and technologies
The Case for Automated Software Distribution	Software distribution needs for different size environments
Distribution with Microsoft Systems Management Server (SMS) 2.0	Using SMS 2.0 to distribute software
Distribution with Microsoft SMS 2003	Software Distributions changes and additions to SMS
Distribution with Group Policy	Using Windows 2000 and Windows Server 2003 Group Policy to keep applications up-to-date
Application Deployment with Terminal Services	Deploying applications by using Terminal Services methods
Patch Management—Distribution with Microsoft Software Update Services (SUS)	Using Microsoft technologies to manage distribution of operating system patches and hotfixes

Company Profiles

Software distribution needs can differ depending on a number of factors, but the need for specific technologies can be generalized into three separate categories of companies: small, medium, and large. Although the size is generally defined by the number of employees in the organization, that’s not always true. Companies tend to hire a minimum of IT staff to support the environment, despite its size and complexity. Minimal support staff can stretch the bounds of adequate support services, and these types of situations actually make the best case for employing automated solutions for software distribution services.

When IT staff is required to co-manage all of the company’s technologies, such as email servers, network infrastructures, data backups, and disaster recovery, other critical functions may fall by the wayside. Keeping the company’s servers and desktops up-to-date with hotfixes and patches for stability and security may be pushed further down the task list, despite its importance. To better understand the technologies that should be considered for each company size, the following company profiles discuss the appropriate choices, depending on IT staff and the size of the network environment, for automating software distribution through Microsoft technologies.

Small Company Profile

A small company is any company in which one or two people can easily manage the number of desktop computers and servers. Companies with smaller numbers of workstations generally rely on a standard but knowledgeable employee, instead of a dedicated IT staff person, for supporting the company’s technologies. This type of company is generally centrally housed, with workstations and servers connected to a LAN. The network is usually not very complex, with connections located within a small radius, as Figure 1 shows, though some employees may work remotely via dial-in modems or high-speed Internet connections.

Figure 1: Small Company Environment Example

Software distribution requirements for small companies depend on the type of support available and the size of the company budget. Companies with 10 or fewer workstations may not need a software distribution mechanism, as the IT staff can manage the workstation software upgrades by making personal visits to each computer, or use a remote control utility to manage the workstations remotely.

Even small companies with a limited budget face specific requirements for keeping workstations up-to-date and secure. One vulnerability, or point of entry into the company network, can cause loss of revenue and employee productivity.

Microsoft Technologies Suitable for Small Companies

Although all of the software distribution options from Microsoft are viable for small companies, some are better suited to fit the budget and size of the company. Those technologies are:

Group Policy. With Active Directory receiving more acceptance in the workplace, any company employing this technology has the ability to utilize Group Policy within the organization as part of the installation. Group Policy is a key benefit when moving from the Windows NT environment to Windows 2000 as part of the upgrade process, because small companies can benefit immediately without incurring any additional costs.

Terminal Services. Terminal Services is another component that’s available with the installation of a Windows 2000 or Windows Server 2003 environment. As noted in the section “Application with Terminal Services,” applications can be centralized on a single server and shared to participating workstations. For smaller companies, this fact can be an economical advantage because only the minimum requirements are needed for the participating workstations.

Software Update Services. SUS is the free Microsoft download to provide internal management of the updates made available through Windows Update services. SUS can assist small companies in keeping the technology environment safe, secure, and updated.

Windows Update Web site. Smaller companies may do well providing operating system updates simply by enabling the workstations to receive updates from the Windows Update Web site.

Note: These technologies can also be utilized together to provide a complete solution for small companies.

Medium-size Company Profile

A medium-size company is any organization with enough technological resources to require full-time IT staff. As a guideline, the IT staff can consist of 3 to 10 members, sometimes more depending on the staffing budget and environment requirements. The network can become more complex in medium-size companies, with multiple offices or locations connected through WANs, as Figure 2 shows. As the number of managed workstations grows, it becomes harder to maintain software updates without injecting more automated systems into the environment.

Figure 2: Medium-size Company Environment Example

Microsoft Technologies Suitable for Medium-size Companies

As the complexities of managing a larger number of servers and workstations grow, additional Microsoft technologies can be employed to ease the management burden. These technologies include:

Group Policy. As with small companies, Group Policy lets medium-size companies take advantage of the benefits of utilizing the built-in features of Active Directory.

Terminal Services. In conjunction with other technologies, Terminal Services provides benefits for medium-size companies. A lot of manufacturing sites fit into the medium-size category, where workstations on the plant floor require specifications that allow for continued existence and usability in an adverse computing environment. Terminal Services allows for less interaction with the remote workstations.

Software Update Services. In addition to Group Policy and Terminal Services, SUS allows medium-size organizations the ability to manage updating and securing servers and workstations.

Windows Update Web site. In some cases, for one-off workstations, updating the operating system via the Windows Update Web site could make sense. This allows workstations that exist outside of the company network to still receive updates.

Systems Management Server. SMS provides the best solution for companies that need the ability to automate, track, and schedule software distributions. Medium-size companies can benefit greatly from SMS, particularly those with complex networking environments in which SMS provides bandwidth management. Coupled with the SUS Feature Pack for SMS 2.0, SMS can provide both software deployment and patch and security hotfix management, eliminating the need for SUS.

Large Company Profile

A large company is any organization with a large base of employees, with the majority utilizing a computer. Large companies employ IT staff teams that are separated by geography, as well as areas of expertise. The company network can span geographic locations across a country or even across the globe, with each location connected by medium- to high-speed connections, as Figure 3 shows. This diverse environment makes management of servers and workstations difficult. However, through the use of Microsoft technologies, the complexity can be minimized by making administration a central process with steps to provide a defined, easy-to-manage solution.

Large companies also deal with political issues that factor into the overall planning for software distribution. Certain locations in the company may have different policies than the overall corporate design that would influence how software is delivered, as well as which software pieces are deployed. The technologies put into place should be flexible to address these political issues. More than one Microsoft technology may be needed to provide a complete solution and, at the same time, address differences in policies and requirements. Larger companies tend to centralize a large support team that addresses overall company concerns, while leaving office support of end users, computers, and servers to local staff. In such a scenario, it might be beneficial to set a company standard for approved technologies for software distribution but allow the local offices to utilize those from the list that provide the most benefit.

Figure 3: Large Company Environment Example

Microsoft Technologies Suitable for Large Companies

Technologies suitable for large companies include the following.

Group Policy. Group Policy can be utilized in large organizations as a way to provide software installations and updates. Using Group Policy in a large company may be the best solution to provide the software deployment services to local memberships. Distribution through Group Policy is not bandwidth sensitive and may not be conducive to deploying applications throughout the enterprise without network performance costs.

Terminal Services. In large companies, Terminal Services provides a good solution to those end users with old or inadequate equipment. However, the organization may not benefit from Terminal Services as a total solution, as the environment may require additional solutions. Terminal Services can also be used to help minimize impact on the network by reducing the number of disconnects.

Systems Management Server with the SUS Feature Pack. SMS is the best choice for larger companies because it provides the best practices for software deployment, tracking, and reporting that large companies need to reduce the costs associated with supporting a large computer base. Software administration and deployment can be centralized, enabling large companies to supply ultimate value. And, with the SUS Feature Pack for SMS 2.0, SMS provides a mechanism to retrieve and distribute hotfixes and patches to make the servers and workstations secure. In large organizations, SUS can work, but there are limitations that may prohibit its use. For example, SUS supports only 15,000 clients per SUS server.

Technology Overview

Microsoft offers several key technologies to aid organizations with deploying new software and software upgrades or updates, as wells as configuration updates. This paper describes each of the technologies listed below, gives an outline of customer concerns for software distribution, and provides customer scenarios for using the various Microsoft technologies.

• Systems Management Server 2.0. SMS 2.0 delivers cost-effective, scalable change and configuration management for Microsoft Windows-based desktop and server systems. Built on industry-standard management protocols, SMS 2.0 is compatible with complementary management tools from Microsoft and other companies. Moreover, SMS 2.0 fully integrates with Microsoft SQL Server and the Windows NT, Windows 2000 Server, and Windows Server 2003 operating systems—making it easy to install, configure, and maintain in any size network.

• Systems Management Server 2003. SMS 2003 is the next generation of Microsoft’s full-spectrum desktop and server management technology. The feature set of SMS 2003 is based on customer requirements and suggestions. One of the key features of SMS 2003 is full mobile client management, including software delivery to mobile clients with bandwidth-sensitive requirements.

• Windows 2000 and Windows Server 2003 Group Policy. The Windows 2000 platform provides software distribution through Group Policy, which is built on top of the management infrastructure services in the platform. Group Policy is targeted toward Windows 2000 and Windows XP and requires Active Directory.

  The Windows Server 2003 (formerly .NET Server) platform is the next generation of Windows server operating systems. Windows Server 2003 builds on the successes of the Windows 2000 Group Policy and provides an enhanced software distribution mechanism for organizations by using Windows Server 2003 Active Directory.

• Terminal Services. Terminal Services are built-in services in Windows 2000 Server and Windows Server 2003 that present the application’s interface to users on their local machines while the binaries of the application are executed on the server.

• Software Update Services. SUS builds on the success of the Windows Update Web service to provide a solution for small and medium-size enterprises to manage and distribute critical Windows patches. This solution updates Windows 2000 and later operating systems and is a particularly powerful update-management tool for Active Directory service-based networks. Although SUS is well suited to an Active Directory environment, it’s not a requirement.

The Case for Automated Software Distribution

Software distribution is a critical aspect of an organization that intends to stay current and secure with its licensed technologies. Many companies employ different technologies and methods for getting software installation, updates, and upgrades to each computer that the company owns. Without the ability to provide “full-coverage” distribution, specific computers could go without critical updates, potentially causing productivity loss, as well as risking opening potential security holes.

Because so many different tools and processes are available, each company assesses its own needs and then determines the best tools for the environment. In the majority of cases, companies utilize a technical lead, IT staff person, or entire technical team to determine the technologies that they should use. IT staff without adequate business service training can find the wide variety of choices overwhelming and will sometimes opt instead to build solutions based on their own technical abilities and history of comfort with familiar technologies. Despite what processes are in place to determine which technologies should be used, deployment technologies need to be integrated into overall technology planning.

One of the key reasons for implementing a software distribution technology is to lower the cost of owning company computers. Because application installations, upgrades, and configurations are critical aspects of the business process, companies can leverage software distribution technologies to reduce costs and increase productivity as changes occur.

Automated Distribution System Requirements

Before delving into manual distribution methods, it helps to understand what makes up an automated software distribution solution. An automated distribution solution contains any or all of the following:

• Central location to create distribution instructions. The automation of software distribution greatly benefits from a mechanism that can be managed from a central location. Creating standard distributions across the enterprise gives organizations control over what applications and application components are available for use. Distribution instructions consist of a detailed plan of which parts of an application will be available for distribution to the organization’s computers. For example, you can distribute the entire Microsoft Office package, or you configure the distribution mechanism to distribute only a single application, such as Microsoft Word. You can even make distribution more granular by creating instructions to install Microsoft Word but leave out certain fonts to save hard disk space on the workstations. By managing the type of installation you’re distributing, you can better plan for the types of services that you’ll need to support end users. If the user base has something installed that the Help desk is familiar with, it will save the company time and money because there will be fewer issues to troubleshoot.

• Central location to initiate delivery of software. After you create the installation instructions, you must be able to distribute the software. By using a central location for pushing the installation to the organization’s computers, you have complete control over when the distribution is initiated. And because there is a central location to initiate the distribution, delivery must follow defined paths for clients to receive software in an efficient manner. Even though delivery is centrally controlled, mechanisms should be sensitive to network bandwidth by giving clients the ability to retrieve software from local or geographically close distribution points. The distribution mechanism must also be sensitive to roving systems that may be on high-speed connections one day and low-speed connections the next.

• Decentralized options. Some organizations have different structural and political needs, which can also relate to how software distribution is managed and how software is deployed. For example, a company with several offices in multiple cities might need a system that can be managed at each location. An enterprise distribution system needs to have flexibility to work in the majority of situations and environments.

• Scheduling system. An enterprise-wide distribution system should have a scheduling mechanism. Being able to manage when a distribution is made available for the employee population provides a flexibility that benefits the entire organization. For example, if you know that users leave their computers connected to the network, and you want to minimize the end user’s downtime, you can distribute a patch or hotfix at 2:00 A.M. so that the installation is completed by the time each user arrives to work the following morning.

• Distribution targeting. Being able to target a computer or groups of computers based on specific criteria is a key to deploying the right applications. For example, if a critical patch for Windows XP is ready to distribute, you won’t want the patch to be received and installation attempted on Windows 98 computers. If the patch is large, you also don’t want the installation of the patch attempted on Windows XP computers that have less-than-adequate hard disk space. A targeting mechanism allows the organization to minimize end-user headaches and provides a support environment that’s manageable.

  The ability to target installations also helps manage the costs associated with software licensing. If you’ve purchased five licenses of a certain application, you need to identify only those computers for which you purchased the licenses. In addition to saving costs, this ability also keeps the company in compliance with piracy laws.

  The ability to target distributions is also important when software installations need to be phased across the company computers due to LAN and WAN constraints, or even due to company policy.

• Bandwidth management. A software distribution mechanism is preferably sensitive to LAN and WAN bandwidth issues. It may have the ability to “throttle” the amount of bandwidth available to the software distribution mechanism. Bandwidth management lets software distribution be sensitive to network activity during business hours, forcing the transfer of bits across the network to a specific percentage of overall bandwidth available.

  In addition to LAN and WAN issues, you should take workstations using slower connections into account. End users connecting from a remote location via a dial-up modem or DSL, but still needing critical updates, need the functionality of a system that’s sensitive to the minimal speed and size of the connection channel.

• Delivery status. After the software distribution is initiated, it’s useful to have a notification system in place to verify that the targeted workstations received the software. Understanding whether delivery of the installation was successful provides the ability to quickly identify steps to troubleshoot a failed delivery. Automated delivery systems give detailed information about the delivery path, helping to isolate the exact problem point.

• Ability to install without making the user an administrator. One issue with many patch deployment mechanisms is that they require the user to perform privileged actions. This requires the user to run as a high-privileged user, maybe even as an Administrator, which is highly undesirable for security and stability reasons. An automated deployment mechanism should be usable even by users who are not running with elevated privileges.

• Installation status. In addition to knowing whether the distribution arrived successfully, an automated system should be able to provide information about the installation status. A notification system needs to answer questions critical to the software’s distribution success. For example:

  • Did the installation succeed?

  • If not, where did the problems occur?

  • If the installation failed, was it a problem with the workstation, the end user, or the distribution mechanism?

  • Was there an issue with the installation instructions or the package itself?

• Distribution and installation reporting. An automated software delivery system should be able to provide statistical data. Having information about the history of successes and failures of the delivery system allows for planning. If the failures were due to the distribution process, you might need a hardware or infrastructure upgrade or you might need to research another delivery system to replace the current solution. In addition to statistical data, you can provide distribution reports to give management the comfort of knowing that their investment in the delivery mechanism is being utilized and is providing value.

• Distribution types. A distribution mechanism must be able to distribute any or all of the following types of installations:

  • Application and operating system hotfixes

  • Security patches

  • New applications

  • Upgraded applications

  • Application and operating system service packs

  • Stock or custom scripts

Manual Software Distribution Processes

Companies using manual means to install software rely on tasks that must be managed constantly to achieve successes. The manual processes include:

• Login scripts. This process is one in which you modify the network login scripts to include commands for installing software. The method generally connects to each computer that logs in to the company network. Once the installation has been successful on the majority of computers, you remove the commands from the login scripts. Though this method can touch a large number of computers, it doesn’t ensure success. There is no ability to know whether the application installed correctly or which computers received the installation, and it doesn’t address remote computers (those computers that didn’t log in to the network during the installation’s availability). When using login scripts for software installation, you can’t target specific computers without great pains and additional pre-installation research. For example, installing a patch that was developed specifically for Windows NT computers could cause Windows 98 computers to crash, resulting in a loss of productivity for the end users and the Help desk staff.

  Another big issue with the login script method is for those end-users who rarely log on to the network. And in relation to this issue, when a critical patch is made available, getting all end users into the office to log on to the network everyday can become a task in itself.

• Computer visits. One of the ultimate manual methods for software distribution is when an IT staff member makes visits to the company’s computers when an installation or update is required. This method is a common practice for small companies with 25 or fewer computers. Carrying the application installation media, the technician manually installs the application or update. In a small company, this method may be a positive and cost-effective process. However, even in a small company, a centralized software distribution technology can free the IT technician to focus on more critical technology management concerns.

• End-user visits. Some companies manually inventory their computers and record the data in a database or spreadsheet. When it needs to distribute software, the company reviews the list, contacts end users whose computers meet specific criteria, and schedules appointments for the end users to drop off their computers to the IT staff. This process results in downtime for the end user, which in turn results in loss of productivity and ultimately loss of company revenue. And, despite the results on the end-user, this method is still very time restrictive to the IT staff who have to keep appointments while managing the rest of the organization’s technology infrastructure.

• Email. Almost every company utilizes some type of email system, and email is generally available for every user in the company. Email is also one of the most critical technologies for doing business, so companies invest a considerable amount of effort and resources to keep email flowing 24 hours a day, 7 days a week. The theory is that because email has high availability, it’s thus a logical transport for software installations. Software installations are delivered as email attachments for end users to execute from within their email.

  However, while email might seem like a perfect distribution mechanism, there are several caveats. If the compressed file is small, distribution via email may indeed be a solution for distribution. On the other hand, if the majority of the user base is mobile or must dial in to receive email, this may not be a convenient option if a package is over 2MB. For the distribution to be successful, the vehicle cannot be something that pains the user to install—otherwise the user won’t install the package. Another drawback to email distribution is that there is no notification mechanism to report whether the user installed the package or whether the installation was a success or a failure. There is, at least, a notification through Return Receipt that the user received and read the email. But if you’re distributing via email to a large enterprise organization, you could expect to be swamped with Return Receipts when users receive their messages. Furthermore, distribution via email assumes that (1) the user is capable of installing the software and (2) the user is running with a high enough privilege level to allow the installation to succeed. Although the first assumption is often not the case, the second is undesirable in most cases.

  Another concern with email is the fact that end users can easily ignore email messages. If the end user is too busy, it doesn’t matter how critical the installation is or how well the importance is communicated, there isn’t a method to make the installation mandatory. You also can’t determine if the end user might have already installed the software through another delivery mechanism.

• Web pages. Most of the user population is very familiar with the experience on the Internet, and almost everyone knows how to download files and install them. The Internet has made software distribution easy for the user to understand—almost too easy. Many companies have experienced the woes of diagnosing computer problems related to the freedom of downloading software from the Internet. Organizations have written policies against this, and some have gone so far as to put technology in place to keep the user base from being able to download files.

  An organization can use Internet technology to its advantage for package distribution by placing packages on an intranet (internal Internet) page for download and installation. And since most people are already familiar with the way the Internet works, they should have little trouble downloading and installing the distributions.

  The other caveat with intranet distribution is how will you notify the user that a package is available for installation? Email communication, at least, gives an up-front communication with an attached file. More technology would have to go into place to give the intranet technology a notification system.

• Network share. Most companies have a network, and placing the software installation on the network is easy to do. You first create a network share and then give the appropriate security rights to the share. You can install the package on the client computer by a notification through some communication method such as email, or you can offer it for installation through login scripts.

  Distribution via the network share is a good method for LAN-locked users but is a poor distribution method for mobile or remote users. It is also a problem for remote sites that connect through a slow link or modem line to the local network. And, again, there is the problem of not automatically providing a status system.

  Also, making applications available via a network share creates additional administration overhead. Any time a distribution is available, you have to create the share, assign the rights, and then revoke the rights once you’ve completely deployed the application. Do you want users to be able to install the application at any time? If so, server disk space could become an issue. Eventually, you’ll have to remove these packages should low server space become a critical concern.

• Media loans. You can distribute the package by burning the package information to a CD, and you can then hand the CD to an individual to run. Using the CD as the distribution mechanism, you can also send the package to a client location where several employees are stationed, which allows all employees to insert the CD and run the installation. You can include an AutoRun feature on the CD so that the installation starts automatically when the employees place the CD into the CD drive.

  However, as with the previous options, CD distribution doesn’t provide a status system for success or failure. Another issue might be that not all mobile PCs or laptops have the luxury of a CD drive. Lastly, this method suffers from the same problems with respect to user capabilities and privilege level as does email distribution.

  Burning CDs for package distributions is a continuing cost. Depending on how many software distributions you conduct each year, this cost could be considerable. There is also the cost of software license violation should an offsite employee give the CD to a client to install.

• Computer images. Many companies employ some type of imaging process to distribute updated standard computer images. As patches and hotfixes are made available for operating systems and applications, the company incorporates these into a new computer image that it will use to refresh each computer in the company. The imaging process requires that the end user back up any personal and company data that resides on the computer and that the operating system and applications be wiped out so that the new image can be installed. A new image replaces everything on the computer.

  Companies that perform this procedure generally schedule the process yearly. While this process allows a company to get all of the computers into compliance at once, critical hotfixes and patches, such as security vulnerability patches, aren’t installed until the scheduled imaging process. The result is that the company is left open to cyber attacks, computer virus infections, and the potential loss of data valuable to the operation of the business.

  In addition to creating the potential for losing data and having out-of-date computers, the imaging process requires a large amount of IT staff resources. Large companies still employing this method for refreshing desktops should see significant gains in cost savings and better protection against vulnerabilities if they reevaluate and change their current method.

  As outlined by the list of manual processes for software distribution, these methods can cost the company money, time, and resources. Employing an automated mechanism allows companies to maximize technology investments. Manual processes, while able to provide solutions for unique situations, degrade the ability to manage the entire technology process.

Distribution with SMS 2.0

SMS 2.0 provides a complete feature set for coordinating the distribution process. Each SMS 2.0 package can have any number of distribution points (typically, individual servers) assigned to it, as Figure 4 shows, and SMS 2.0 provides replication services to ensure the package bits are installed on each distribution point.

These replication services are the same as those used for all communication between SMS 2.0 sites and therefore include:

• Automatic compression

• Bandwidth-sensitive transfers from site to site to allow operation over poor or intermittently connected communication links

• Bandwidth profiling to control the amount of network resources used for SMS 2.0 operations

• A priority/scheduling scheme to control when the link is considered available for use by SMS 2.0 operations

• Status reporting on the package distribution process

• Package version tracking

  

Figure 4 SMS 2.0 Distribution Points

The distribution features are integrated with the rest of the deployment features to ensure that clients don’t receive installation instructions until a distribution point in their site contains the package bits and also to control how clients select the distribution point to use when multiple distribution points are available in the client’s site. SMS 2.0 supports inter-site communication over LAN, asynchronous RAS, ISDN RAS, X.25 RAS, SNA RAS, and out-of-band links.

SMS 2.0 is a complete automation system for software deployment. It provides all of the Automated Distribution System Requirements outlined previously.

SMS 2.0 Capabilities

Table 1 details how SMS 2.0 stacks up to the Automated Distribution System Requirements.

Table 1 SMS 2.0 Automated Distribution System Adherence

Requirement	Supported?	Details
Central location to create distribution instructions	Yes	SMS 2.0 works from a top-down hierarchy model in which there is a central site where all management is performed and changes and additions are filtered down throughout the hierarchy.
Central location to initiate delivery of software	Yes	SMS 2.0 manages the distribution of software packages to distribution points where the client computers find the packages available to them and initiate the installation.
Scheduling system	Yes	SMS 2.0 has the most robust scheduling system of all of the Microsoft technologies. For example, you can schedule an application to deliver the second Tuesday this month, at 7:45 A.M.
Distribution targeting	Yes	SMS 2.0 uses the concept of Collections to perform its targeting. Collections are based on membership rules, which can be either direct or query-based. The query criteria are based on any attributes SMS 2.0 maintains for managed resources, from basic properties such as name and IP address, to hardware and software inventory information such as specific network cards in use or installed software.
Bandwidth management	Yes	SMS 2.0 provides a built-in feature that allows administrators to configure the amount of bandwidth available between SMS sites.
Installation status	Yes	SMS 2.0 incorporates a status reporting mechanism that is close to real time.
Distribution and installation reporting	Yes	SMS 2.0 provides comprehensive querying of the data that it collects. You can mine this data by using any enterprise-class report application, database applications such as Microsoft Access, and Microsoft’s own Web Reporting tool.
Distribution of hotfixes	Yes
Distribution of service packs	Yes
Distribution of critical patches	Yes
Distribution of new applications	Yes
Distribution of upgraded applications	Yes

SMS 2.0 Example: Distributing Office XP

Distributing Microsoft's newest Office package is easy, providing you know where to start. For organizations that have implemented SMS 2.0, Office XP can be quickly deployed to all computers in the company.

To read through the steps involved for deploying Office XP through SMS 2.0, see the white paper, “Using SMS 2.0 to Deploy Microsoft Office XP” (https://www.microsoft.com/technet/sms/20/smsoffxp.mspx).

Distribution with SMS 2003

SMS 2003 is the next generation of desktop and change-management services. Building on the successes of SMS 2.0, SMS 2003 incorporates a slew of new features. Microsoft didn’t develop SMS 2003 as a complete code rewrite (as much as the company did between SMS 1.2 and SMS 2.0). SMS 2003’s improvements are based on feedback from Microsoft customers.

Some of the most customer-requested new features in SMS 2003 are centered on software delivery. SMS 2.0’s software delivery feature set is robust, but in a mobile environment, you might need third-party add-ons or special procedures. SMS 2003 addresses the mobile workforce by using special technologies to allow distribution to remote users who are connected by slower-speed connections. By taking advantage of the rich manageability infrastructure in the Windows operating system, industry-standard Internet technologies such as HTTP, and the technology and best practices of Windows Update—which enterprises use today to implement millions of software updates per month—SMS 2003 provides an enterprise-scalable solution for all mobile PC needs. SMS 2003 includes:

• Client-sensitive bandwidth throttling. SMS 2003 allows both traditional desktops and mobile PCs to download software in a bandwidth-sensitive manner—ensuring bandwidth usage doesn’t impact the business users’ productivity for accessing business applications—when connected over a limited-bandwidth connection.

• Checkpoint/restart. Should a connection be terminated during a transmission, SMS 2003 provides a restart capability for resuming transfer where it left off instead of resending the entire package—ensuring transfer of the minimal amount of software to mobile workers.

• Location awareness. As users move from location to location, SMS 2003 determines the physical location and can provide download of critical software from the closest source. This feature can dramatically lessen traffic impact on expensive and slow WANs in organizations that meet the requirements.

Microsoft also developed SMS 2003 to interoperate with the more common and emerging Windows technologies, making it completely compatible with installed Windows infrastructures. For example, SMS 2003 incorporates infrastructure management components and capabilities such as Windows Management Instrumentation (WMI), Active Directory, and the Windows Installer service. SMS 2003 uses these key elements to provide an increased level of manageability for Windows-based clients, above and beyond the level of manageability available for other products or platforms.

The following are some of the ways in which SMS 2003 takes advantage of platform services:

• Active Directory integration. With the increased deployment and adoption of Active Directory as the key business directory, Microsoft has extended SMS 2003 to take advantage of the components of Active Directory. This includes targeting software at Active Directory sites, domains, organizational units, security groups, and non-security groups.

• Rich distribution targeting. You can finely target software distribution and other management tasks to machines and users by using a wide variety of properties, including network and hardware configuration, the Active Directory organizational unit, or group membership and software installation status. You can deploy software based on business organization, not just the properties of the network infrastructure.

• Dynamic distribution targeting. If a new user joins a user group, SMS 2003 automatically sends software to the user according to predefined administrative settings for that group. Likewise, new computers that match predefined targeting policies (such as IP subnet, Active Directory organizational unit, or installed video card) automatically receive specified packages or driver updates. When you add a new computer or user to an organization, it can automatically receive the software it requires without any administrative intervention.

• Add/Remove Programs integration. Microsoft specifically designed this powerful user interface included in Windows 2000 Professional and Windows XP Professional for users to install or uninstall software for the business desktop. SMS 2003 enables users to manage business applications through the same familiar interface, reducing training and support costs while increasing the success rate and timeliness of installation of business applications on corporate desktops.

• Elevated-rights installation. With the pronounced move of the corporate desktop to Windows 2000 Professional and Windows XP Professional, the need for providing business users with the authority to execute installation tasks without needlessly endangering the integrity or security of the desktops has become more pressing. SMS 2003 provides simple and specific delegation of authorization capabilities in relation to Windows Installer technology (Microsoft Software Installation—MSI), empowering the business user to perform the software installations required without compromising security. In SMS 2.0, this feature is unavailable as part of SMS, but you can obtain it by employing a special wrapper program that’s part of a feature pack.

• Security update rollout. SMS 2003 can automatically check the Windows systems (both servers and desktops) against an updated database of available critical patches and fixes (maintained on the Microsoft.com Web site). Alternatively, this same database can be downloaded and maintained locally within the company firewall. SMS 2003 generates a simple Web report showing which patches each computer requires. Under administrator control, the required patches can then be downloaded and deployed automatically to those PCs that require them. In SMS 2.0, this ability was available only through the installation of the SUS Feature Pack (outlined later in this paper).

Distribution with Group Policy

Windows 2000 introduced the ability to deploy applications from within the server operating system itself. The primary management solutions provided with the Windows 2000 platform that address traditional systems and desktop management are Remote Operating System (OS) Installation and Group Policy. Group Policy is a set of features that provide user settings management, user data management, and software deployment. Remote OS Installation is used for automating the deployment of new installations of the Windows 2000 Professional and Windows XP Professional operating systems.

One of the key differences between Windows 2000 services and SMS 2.0 is that SMS 2.0 still supports older operating systems. If your organization must support the older operating systems such as Windows 95, Windows 98, and Windows NT 4.0, you need to look at SMS 2.0. You should also note that SMS 2.0 doesn’t require Active Directory. SMS 2003 will also not need this requirement, but SMS 2003 will be the first SMS version that integrates with Active Directory, further narrowing the differences between Group Policy and SMS.

Note: SMS 2003 will no longer support Windows 95 clients. Also, Microsoft has officially discontinued support for Windows 95 as of December 31, 2002.

There are additional marked differences between Group Policy and SMS 2.0 features that are outlined in Appendix A.

Group Policy Capabilities

Table 2 details how Windows 2000 Group Policy stacks up against the Automated Distribution System Requirements.

Table 2 Windows 2000 Group Policy Automated Distribution System Adherence

Requirement	Supported?	Details
Central location to create distribution instructions	Yes	Windows 2000 administrators create the packages and configure the details of the packages that are published to the Active Directory participants.
Central location to initiate delivery of software	Yes	By using Group Policy configurations, software is made available to computers and users that are part of the Active Directory hierarchy.
Scheduling system	No	Group Policy doesn’t provide a scheduling system for making software available at specific times and dates.
Distribution targeting	Partial	Software deployment uses the Active Directory and Group Policy infrastructure services that are built into the Windows 2000 platform to perform its targeting.
Bandwidth management	Partial	Group Policy utilizes the bandwidth management built into the Active Directory replication technologies. Although Active Directory distributes instructions throughout the domain hierarchy in an efficient manner, it doesn’t allow the ability for the bandwidth to be managed by the administrator.
Installation status	No	Windows 2000 Group Policy doesn’t offer centralized status on the installation of applications published to Active Directory participants. You can find installation error reporting on the workstation in the Event Viewer and installation log files.
Distribution and installation reporting	No	Because Group Policy doesn’t collect data on software installations, there is no way to provide reports for statistical data.
Distribution of hotfixes	No
Distribution of service packs	No
Distribution of critical patches	No
Distribution of new applications	Yes
Distribution of upgraded applications	Yes

Group Policy Software Distribution Technologies

Advertising—also known as install-on-demand—is a feature of the Windows Installer technology that announces the availability of an application without actually having the application installed on the PC. Announcing the application is performed by using a couple different methods. First, the application can be designated to be installed completely on specified computers, and second, it can be configured to appear as an icon in the computer’s START | Programs menu and installed when the end user attempts to access the application. Advertising can be used for an entire application or for individual features such as a spellchecker or clip art.

There are two types of advertising: assigning and publishing.

• Assigning. Assigning makes an application available, and it appears to a user as if it has been installed without it actually having been installed. The application’s icon shows up in the START | Programs folder and can be installed when the end user attempts to execute the application’s program. Assigning (as opposed to publishing) an application forces it to be automatically installed for all specified accounts or for a single user.

• Publishing. Publishing an application advertises it to the members of a group specified in the Group Policy setting by adding the application to the list of available programs in Add/Remove Programs. The next time the members of the group open Add/Remove Programs, they have the option to install the new applications.

Group Policy allows only specific file formats to be distributed through the software distribution mechanism. These file types are based on the Microsoft Windows Installer technology, which is a groundbreaking service that allows applications to be managed automatically. In the past, applications followed no known standard for installing and caused problems for other applications and other functions of the operating system. For example, there are a number of applications that rely on specific versions of system files to operate correctly. An installation would install its own required version without any regard to existing files. This procedure would break other applications and also cause the operating system to stop functioning properly. And when the application was uninstalled, those same share files would be removed even if other applications required their existence.

Group Policy uses MSI files for distribution to clients. The Windows Installer service recognizes the following file types:

• MSI. An MSI file is a database that contains the installation information of an application. All information about that installation is contained within the database, such as registry modifications, file installs, file registrations, user interface, and installation options.

• Transform. A transform is a collection of changes applied to an installation. By applying a transform to a base installation package, the installer can add or replace data in the installation database. The installer can apply transforms only during an installation. This allows an organization to modify how an application is installed so that the default installation contains different options than what the CD-based installation would contain.

Note: Non-MSI programs can be published only to users and are installed by using their existing Setup programs. To publish a non-MSI application, you must first create a ZAP (Zero Administration for Windows—ZAW—downlevel applications package) file. The ZAP file is a reference file that Active Directory uses to create non-MSI publications. Because non-MSI programs use their existing Setup programs, these programs lose the ability to take advantage of the following MSI features:

• Elevated privileges for installation

• Installation on the first use of the software

• Installation of a feature on the first use of the feature

• Rollback support for an unsuccessful operation (install, modify, repair, or removal)

• Software resiliency (missing or corrupted applications files or library files)

For more information about ZAP files, see https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexnt00/html/ewn0085.asp.

Group Policy Example: Distributing Office XP

You can use Group Policy Objects (GPOs) to assign Office XP programs to users or computers in Active Directory. When users first log on to their computers after you’ve assigned the Office XP programs, the programs are made available to the users.

You can use Group Policy to deploy and manage Office XP programs by using a GPO. After you set a policy for Office XP programs, they’re applied automatically.

Assigning Office XP to users ensures that they’ll have access to the same Office XP programs and features no matter which computer they log on to. Once you’ve assigned Office XP to users, information about the software is displayed on the users’ desktop or Start menu the first time they log on. Clicking a shortcut starts the Windows Installer service, which then automatically installs the program according to policy settings.

For more information about performing this operation, see the article, “Use IntelliMirror in Windows 2000 to Deploy Office XP Programs by Using a Group Policy Object” (https://support.microsoft.com/default.aspx?scid=kb;en-us;312972&sd=tech).

Windows Server 2003 Group Policy

In conjunction with Windows Server 2003, Microsoft is releasing a new Group Policy management solution that unifies management of Group Policy. The Microsoft Group Policy Management Console (GPMC) provides a single solution for managing all Group Policy-related tasks. GPMC lets administrators manage Group Policy for multiple domains and sites within a given forest, all in a simplified user interface with drag-and-drop support. Highlights include new functionality such as backup, restore, import, copy, and reporting of GPOs. These operations are fully scriptable, which lets administrators customize and automate management. Together, these advantages make Group Policy much easier to use and help you manage your enterprise more cost-effectively.

In addition to the new console to improve management of Group Policy, Microsoft has improved specific areas in relation to software distribution. Although the additions don’t represent a full rewrite of Group Policy, they do signify some improvements. Windows Server 2003 offers:

• Improved behavior. Windows Server 2003 includes a full install at Logon option. This improvement forces a full installation of an application and helps avoid the risk of needing to fault-in a component while not online.

• Security. The option Remove previous installs of this product from computers, if the product was not installed by Group Policy-based Software Installation is no longer present. Now previously installed versions are always completely removed before any attempts are made to install software.

• New feature. Administrators can now specify or customize the Support URL that appears with an application in the Add/Remove Programs Control Panel applet.

Application Deployment with Terminal Services

Microsoft Windows NT 4.0 Terminal Server and Terminal Services-enabled Windows 2000, Windows XP, and Windows Server 2003 servers provide a thin-client solution for Windows-based programs—that is, they run on the server and display an application's user interface on a client computer. For example, users who have computers with limited disk space, memory, or processing speed can connect to a Terminal Services computer and use Office XP applications as if the applications were running on the local computer. Terminal Services is a technology that’s more a “deployment avoidance” mechanism than a true application deployment technology. With Terminal Services, you can install a single copy of Office XP on a Terminal Services-enabled server. Then, instead of running Office locally on a single user's computer, multiple users connect to a server and run Office from there. This method is generally considered a “thin-client” solution and is recommended for companies with outdated computers, computers with minimal hardware resources, or applications that aren’t written in such a way as to support efficient use over a slow link. Typically a company can save money by reusing older hardware and still make an application available as long as the computer meets the application’s recommended minimum hardware requirements.

Terminal Services saves money for software distribution services by:

• Minimizing client hardware requirements

• Minimizing administration of software applications

• Improving access to hosted applications across the WAN

• Lowering network utilization, allowing for the layering of additional application services into the enterprise without incurring costly infrastructure upgrades

• Improving support response time by giving tools to manage client applications remotely

Terminal Services Capabilities

Table 3 details how Terminal Services stacks up against the Automated Distribution System Requirements.

Table 3 Terminal Services Automated Distribution System Adherence

Requirement	Supported?	Details
Central location to create distribution instructions	Yes	Applications are installed on a single Windows 2000 server or Windows Server 2003 and shared from the server for those clients using Terminal Services.
Central location to initiate delivery of software	No	Applications aren’t delivered to the workstations but are shared from the server.
Scheduling system	No	Terminal Services doesn’t have a scheduling system for delivery of software.
Distribution targeting	No	There is no targeting mechanism made available to Terminal Services.
Bandwidth management	No	Terminal Services doesn’t incorporate a bandwidth management system to minimize LAN/WAN activity.
Installation status	No	Terminal Services doesn’t provide a status reporting system for availability of applications.
Distribution and installation reporting	No	Because Terminal Services doesn’t gather data for application deployment, there is no mechanism available for reporting.
Distribution of hotfixes	No
Distribution of service packs	No
Distribution of critical patches	No
Distribution of new applications	Yes
Distribution of upgraded applications	Yes

Terminal Services Example: Deploying Office XP

Microsoft developed Office XP with the ability to be run in a Terminal Services environment. This capability ensures that minimal computer configurations can still take advantage of the most current Office suite without upgrading hardware insufficient for running the entire suite locally.

Overview of How Office XP Works with Terminal Services

Making software available through Terminal Services is a relatively simple procedure. The process for any application is similar to the following steps.

1. The administrator installs a single copy of Office XP on the Terminal Services computer by using Application Server mode. (If Terminal Services isn’t enabled for this mode, you can change it through the Windows Components section in the Add/Remove Programs Control Panel applet on the Terminal Services server.)

2. Users install Windows Terminal Services Client on their computers (Windows XP includes the Terminal Services Client. For others, you can download the client from https://www.microsoft.com/downloads/details.aspx?FamilyID=26f11f0c-0d18-4306-abcf-d4f18c8f5df9&DisplayLang=en).

3. Users log on to the Terminal Services computer remotely through the Terminal Services Client software and run Office as though it were running on their own computer.

The Office applications run on the Terminal Services computer, and only the user interface is transmitted to users’ computers across the network.

To understand the complete process, see “Deploying Office XP in a Terminal Services Environment”

(https://www.microsoft.com/technet/community/events/officexp/tnt1-53.mspx).

Note: Terminal Services has two modes: Application Server mode and Remote Administrator mode. As described, Application Server mode allows sharing of applications to multiple workstations. Remote Administrator mode allows multiple administrators to manage the server remotely. When the server has this mode enabled, the server’s screens are transmitted to the administrator’s workstation verbatim, allowing access to the server remotely, as if the administrator were physically sitting at the server’s console.

Windows Server 2003 Terminal Services

Windows Server 2003 introduces some enhancements and increased functionality for Terminal Services and represents a major update. While Terminal Services for Windows Server 2003 offers new features in almost every aspect, there are some new characteristics that improve the overall experience for sharing applications. These characteristics include:

• Increased scalability. Terminal Services supports more users on each high-end server than does Windows 2000.

• Software restriction policies. Terminal Services provides the ability to restrict entire software packages or only specific components.

• Roaming profile enhancements. User profile roaming is both easier to manage and easier to configure.

• New application compatibility modes. Terminal Services provides the capability to manage the application through configuration for different client operating systems.

Patch Management—Distribution with SUS

Microsoft designed Software Update Services (SUS) to greatly simplify the process of keeping IT systems up-to-date with the latest critical updates. SUS enables administrators to quickly and reliably deploy critical updates to their Windows 2000-based servers as well as desktop computers running Windows 2000 Professional or Windows XP Professional. SUS provides a version of the popular Windows Update Web site for installation inside your corporate firewall. You can locate Microsoft’s SUS Web site at /windows2000/windowsupdate/sus/default.asp. SUS is a free download for companies using Windows 2000 and also supports Windows Server 2003.

SUS consists of a server component and a thin-client process. The server component installs on a computer running Windows 2000 Server or Windows Server 2003 inside the corporate firewall. It synchronizes with the Windows Update site to retrieve all critical updates for Windows 2000 and Windows XP. The synchronization to clients can then be automatic or completed manually by the administrator. When you download the updates, you can test them in your environment and then decide which updates to approve for installation throughout your organization. Figure 5 shows how the SUS structure functions inside the corporate firewall.

Figure 5: Providing Windows Update Functionality Internally with SUS

Note: You cannot install the server component of SUS on a domain controller. The minimum requirements for the server piece are an Intel x86 or compatible P700-level processor, 512MB of RAM, and 6GB of available hard disk space.

The client component is the Windows feature for installation on all of your Windows 2000 SP2 or later-based desktops and servers as well as computers running Windows XP Professional. This feature enables your Windows servers and Windows client computers to connect to a server running SUS and receive any updates. You can control which server each Windows client should connect to as well as schedule when the client should perform all installations of critical updates—either manually or via Group Policy.

SUS currently supports only the updating of Windows Critical Updates, Windows Critical Security Updates, and Windows Security Roll-ups. Although it’s not a solution for distributing any type of application, such as Microsoft Office XP, it does provide a solution for companies concerned with keeping their computer population secure and up-to-date.

SUS Capabilities

Table 4 details how SUS stacks up against the Automated Distribution System Requirements.

Table 4 SUS Automated Distribution System Adherence

Requirement	Supported?	Details
Central location to create distribution instructions	No	Distribution instructions aren’t created—only those instructions available in the downloaded files are viable. You can’t customize installations beyond the command-line switches built into each download.
Central location to initiate delivery of software	Yes	The SUS server gathers downloads from the Windows Update site and stores them locally so that an administrator can approve or reject software that’s made available to the workstations the SUS server manages.
Scheduling system	Yes	SUS has a limited scheduling system, but software can be distributed to Windows Update servers and configured to be available at a specific time.
Client targeting	Yes	You can install SUS by using a hierarchy model in which different SUS servers are spread across a geographical region. By utilizing this model, you can target software to a specific server to service a specific group of computers.
Bandwidth management	Yes	SUS utilizes Microsoft Internet Information Services (IIS) for management of distributions. This includes the ability for checkpoint-restart technology, which allows you to stop and restart distributions where they were halted instead of forcing the download to start from scratch.
Installation status	No	SUS doesn’t have an automated installation status mechanism. Instead, SUS records the distribution of files in IIS log files. Microsoft offers a parser tool for the IIS logs. It can be downloaded from the following Microsoft Web page at https://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en. However, an administrator could use the Microsoft Baseline Security Analyzer (MBSA) to analyze machines across a network and determine whether patches are installed on them.
Distribution and installation reporting	No	Delivery to the workstation isn’t recorded. For information about whether the distribution reached the workstation and installed, you need access to the computer event logs.
Distribution of hotfixes	Yes
Distribution of service packs	No
Distribution of critical patches	Yes
Distribution of new applications	No
Distribution of upgraded applications	No

SUS for SMS 2.0

It should be noted that Microsoft released a Systems Management Server 2.0 Software Update Services Feature Pack (SMS 2.0 SUS Feature Pack) in the third quarter of 2002. The Feature Pack provides the same functionality of SUS for users of SMS 2.0. When organizations require more than hotfix distribution, SMS 2.0 with the Feature Pack makes an optimum solution.

Table 5 highlights the differences between SUS and SMS with the Feature Pack.

Table 5 SUS and SMS 2.0 with SUS Feature Pack Feature Comparison

Installation and Distribution Features	SUS	Microsoft SMS with SUS Feature Pack
Content	Built-in synchronization service can automatically download the latest critical updates from Microsoft.	Automatic downloading of necessary updates.
Targeting	Basic targeting in which machines receive all applicable patches from the SUS server that they’re assigned to.	Granular targeting based on criteria such as inventory, groups/organizational units, and subnets.
Geographical Distribution	Can schedule SUS to automatically synchronize content with the list of approved updates from other SUS servers or a distribution point within your network.	Site-site distribution that you can schedule and is sensitive to WAN links.
Installation	Manual or simple scheduling. Controllable via Group Policy. Client downloads that are sensitive and fault tolerant to network availability and bandwidth. You can schedule installs.	Manual or advanced scheduling. Controllable based on any of the targeting criteria mentioned above.
Status	Status reported via IIS logs.	Status available via built-in filters and reports, using SQL Server which is a very powerful and flexible reporting technology.

For more information about the Feature Pack for SMS 2.0, see the following Microsoft Web page: https://www.microsoft.com/smserver/evaluation/overview/featurepacks/suspack.asp.

SMS 2.0 SUS Feature Pack Capabilities

Because the SMS 2.0 SUS Feature Pack utilizes the SMS system, it allows the same Automated Distribution System Requirements as SMS to be utilized. This transfer of abilities gives the self-hosted Windows Update Web site the full capability of a true enterprise software distribution technology.

Table 6 details how the SMS 2.0 SUS Feature Pack stacks up against the Automated Distribution System Requirements.

Table 6 SUS Feature Pack for SMS 2.0 Automated Distribution System Adherence

Requirement	Supported?	Details
Central location to create distribution instructions	Yes	The Feature Pack utilizes the same hierarchy available to SMS.
Central location to initiate delivery of software	Yes	Because the Feature Pack incorporates with SMS, it takes advantage of the instruction creation feature.
Scheduling system	Yes	SUS on its own provides a scheduling feature, but when used with SMS, can use the robust scheduling component built into SMS.
Client targeting	Yes	Incorporating SUS into SMS allows greater flexibility for targeting computers. Computers can be targeted by hard disk space, RAM, etc., as well as targeted for hotfix requirement concerns.
Bandwidth management	Yes	The Feature Pack takes advantage of SMS’s built-in bandwidth throttling features, as well as its ability to distribute hotfixes to locations closest to the workstation.
Installation status	Yes	Used in the SMS environment, SUS can take advantage of the unlimited amount of information on software installation that SMS provides.
Distribution and installation reporting	Yes	SMS records an enormous amount of data on hotfix distribution that can be filtered and queried.
Distribution of hotfixes	Yes
Distribution of service packs	Yes
Distribution of critical patches	Yes
Distribution of new applications	Yes
Distribution of upgraded applications	Yes

Summary

Software distribution is a critical management piece for the majority of organizations. Without the ability of an organization to distribute software, managed computers can quickly become outdated and less secure. Managing the software distribution process through manual, piecemeal solutions triples the cost of owning technology. Further, the cost of managing computers through manual processes continues to rise because of the frequency of updates and the constant bombardment of vulnerabilities, viruses, and cyber terrorism.

Microsoft provides different options for delivering software to the workstations and servers managed in an organization. Microsoft technologies lower the cost of managing systems considerably by providing automated mechanisms for delivering patches, software upgrades, and hotfixes. Determining which Microsoft software delivery solution is right for your company depends on many factors, but employing an automated solution will save costs associated with managing today’s technology.

For More Information

• Microsoft Systems Management Server Web Site

• Guide to Using the SMS SUS Feature Pack to Manage Security Updates

• Microsoft Solutions for Management

• Microsoft Software Update Services (SUS)

• Technical Information on Group Policy

• SMS Software Update Services Feature Pack

• Windows Server 2003

• Enterprise Software Update Management Using Systems Management Server 2.0 Software Update Services Feature Pack

• Terminal Services Advanced Client FAQ

• Software Distribution Overview (Microsoft Solutions for Management)

• Patch Management, Security Updates, and

• Microsoft Systems Management Server 2.0 Product Operation Guide

• Microsoft Management Web Site

Appendix A

Product Functionality at a Glance

This paper is decidedly positioned to communicate the distribution features of Microsoft technologies. Organizations tend to make decisions about technology implementation based on a number of factors instead of a single component. To better understand the overall picture, review Table A that outlines the additional components featured in each technology that can help dictate a decision.

Table A Microsoft Management Product Comparison

Feature Area	Windows GPO	Terminal Services	SMS 2.0 with SUS Feature Pack	SUS
Application deployment
Patch/hotfix deployment
User settings management
User data management
New OS deployment
OS upgrade/OS update deployment
Hardware/software inventory
Remote control and diagnostic tools
Software metering
Network analysis/diagnosis
Health monitoring
Supports Windows 2000 and Windows XP clients
Supports Windows 95, Windows 98, and Windows NT 4.0 clients

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

© 2003 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows Logo and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.