Section 1.6: Deploying Software Applications

1.6.1: Software Installation and Maintenance Technology

The software installation and maintenance technology in Windows Server 2003 uses Group Policy in conjunction with Windows Installer to automate and manage software installations, updates and removal from a centralized location. Group Policy can be used to assign the software application to a group of users that are members of an OU, and allows you to manage the various phases of software deployment.

There are four phases of software life cycle:

• Preparation: preparing the files that allows you to use Group Policy to deploy the application software. This involves copying the Windows Installer package files to a software distribution point. The Windows Installer application files can be obtained from the application's vendor or can be created through the use of third-party utilities.

• Deployment: the administrator creates a Group Policy Object (GPO) that installs the software on the target computers and links the GPO to the appropriate Organizational Unit. During this phase the software is installed.

• Maintenance: the software is upgraded with a new version or redeployed with a patch or a service pack.

• Removal: to remove software that is no longer required, you must remove the Windows installer package from the GPO that was used to deploy the software. The software is then automatically removed when a user log on or when the computer restarts.

Windows Installer consists of Windows Installer service, which is a client-side service, and Windows Installer package. Windows Installer package uses the .msi file extension that replaces the Setup.exe file and contains all the information that Windows Installer services requires to install the software. The software developer provides the Windows Installer package with the application. If a Windows Installer package does not come with an application, you can create a Windows Installer package or repackage the application, using a third-party utility. Alternatively you could create an application file (.zap) that uses the application's existing setup program. A .zap file is not a native Windows Installer package.

Advantages of using Native Windows Installer packages:

• Automatic File Repair when a critical application file becomes corrupt. The application automatically returns to the installation source to retrieve a new copy of the file.

• Clean Removal without leaving orphaned files and without deleting shared files used by another application.

• Transformable. You can customize a Windows Installer package to meet the requirements set by your company by using authoring and repackaging tools. Transformed Windows Installer packages are identified by the .mst file extension.

• Patches. Patches and upgrades can be applied to the installed applications. These patches use the .msp file extension.

Note: A .zap file is not a native Windows Installer package and does not offer the same benefits as Windows Installer packages. It therefore does not support automatic repairing and cannot be transformed.
1.6.1.1: Acquiring and Modifying Software Packages

The preparation phase involves two key processes: package acquisition and package modification. The Software Installation and Maintenance technology can only deploy and manage Windows Installer package files. Thus, you must have a package file for an application before that application can be deployed using Group Policy. Administrators have the following three options for acquiring package files:

• Obtain a package file from the software vendor;

• Repackage an application by create a package file using repackaging software; and

• Create a text file with the .zap extension.

Package modifications are similar to Windows Installer package files but have an .mst file extension. Modifications allow you to take one software application, such as Microsoft Office, and create any number of custom installations. You can then create GPOs, assign these different versions to different users, and install the software.

1.6.1.2: Deploying Software Packages

When you deploy software packages, you can assign the package to a user or computer, or you can publish the software package. In addition, you can also deploy .zap files.

1.6.1.3: Assigning Software Packages

Software packages can be assigned to users or computers.

• When you assign a software package to a user, the program is advertised when the user logs on, but is not installed until the first time the user starts the application. The user can start the installation of the application by selecting it from the Start menu or by document invocation, i.e., by double-clicking an icon or a file type associated with the application. By initially only advertising applications, you can minimize the impact on the local hard disk while keeping applications available to the user at all times.

To assign an application to users, do the following:

• Click on the START button

• Point to PROGRAMS

• Click on ADMINISTARTIVE TOOLS

• Click on ACTIVE DIRECTORY USERS AND COMPUTERS

• Expand the domain containing the users to whom you want to assign an application

• In the list of Group Policy Object Links, select the appropriate GPO (if no GPO exists, create one)

• Then click EDIT

• Expand the User Configuration node

• Expand the Software Settings node

• Then right-click the Software Installation node

• On the pop-up menu, point to NEW

• Then click PACKAGE

• In the File Name text box, enter the path to the package

• Then click OPEN

• In the Deploy Software dialog box, click assigned

• Then click OK

• When you assign a software package to a computer, you ensure that certain applications will be available on that computer regardless of who logs on to the computer. When you assign an application to a computer, the software is installed automatically when the computer is next turned on.

The steps for assigning an application to computers are almost identical to the steps for assigning an application to users. To assign an application to computers, do the following:

• Click on the START button

• Point to PROGRAMS

• Click on ADMINISTARTIVE TOOLS

• Click on ACTIVE DIRECTORY USERS AND COMPUTERS

• Expand the domain containing the computer to which you want to assign an application

• In the list of Group Policy Object Links, select the appropriate GPO (if no GPO exists, create one)

• Then click EDIT

• Expand the Computer Configuration node

• Expand the Software Settings node

• Then right-click the Software Installation node

• On the pop-up menu, point to NEW

• Then click PACKAGE

• In the File Name text box, enter the path to the package

• Then click OPEN

• In the Deploy Software dialog box, click assigned

• Then click OK

1.6.1.4: Publishing Software Packages

When an application is published to a user, it is not installed. The advertisement is stored in Active

Directory directory services, so the software is readily available. A user can install the application by using

Add/Remove Programs or by using document invocation.

• To use Add/Remove Programs, the user would start Control Panel and double-click the Add/Remove Programs icon. When he or she clicks Add New Programs, the set of programs available to the user is displayed in user friendly names. The user can then select the desired program and install the software.

• The user will install the application by document invocation when he or she double-clicks an unknown file type. When the user does this, the computer sends a query to Active Directory directory services to see if there are any applications associated with the file extension. If Active Directory directory services contain such an application, the computer then checks if this application has either been published or assigned to the user. If the application has been published or assigned to the user, the computer then checks if the application is set for Auto-Install This Application By File Extension Activation. If the administrator has set the application to Auto-Install, the application is installed.

1.6.1.5: Deploying .zap Files

Software Installation normally works only with Windows Installer package files. However, you can get around this requirement by creating a .zap file that provides instructions for deploying the application. You should only use .zap files to publish applications when it is not feasible to use repackaging software to repackage an application and when a Windows Installer package file from a software vendor is unavailable.

A .zap file is a text file that can be parsed and executed by Software Installation. These files allow you to publish non-Windows Installer applications with the following limitations:

• The applications cannot be assigned to either users or computers. They can only be published.

• The applications do not automatically repair themselves when key files have been deleted or become

corrupted. Instead, the application will invoke and rerun its setup program any time it is unable to start.

• The applications are rarely able to install without user intervention. These applications run the software's original setup program, and few of these programs support an unattended installation.

• The applications cannot install with elevated privileges. If you intend to deploy .zap files, users must

have permission to install software on their local computers. Native package files install using the

privileges assigned to the Windows Installer. This allows package files to be installed on computers regardless of the user's privileges. In other words, security is based on the GPO that deployed the application rather than on the individual user's security rights.

A .zap file can be created with Notepad or any other text editor. The file itself has two primary sections: [Application], which is the Application section and [Ext], which is the File Extensions section.

1.6.2: Upgrading Software

You must be able to upgrade users' software to ensure that users' computers have the most current version of an organization's software. There are two types of upgrades: mandatory and optional.

1.6.2.1: Mandatory Upgrades

Mandatory upgrades automatically replace an older version of a program with the upgraded version. To deploy a mandatory upgrade, right-click the new version in Software Installation, and then click Properties. In the package file's Properties dialog box, select the Upgrades tab. In the Packages That This Package Will Upgrade section, click Add, and then select the older version of the program that you want to upgrade. If both versions of the program are native Windows Installer packages, this step will be done automatically. If the older version has been installed, it will be replaced with the newer version the next time that the user activates the program. You can use this same strategy to change from one vendor's product to another.

1.6.2.2: Optional Upgrades

Optional upgrades allow users to use either the old or the new version of a program. After an optional upgrade, users can also install and use both versions of the application simultaneously. To deploy an optional upgrade, right-click the new version in Software Installation and click Properties. Then select the Upgrades tab in the package file's Properties dialog box. In the Packages That This Package Will Upgrade section, click Add, and then select the older version of the program. If both versions of the program are native Windows Installer packages, this step will be done automatically. Clear the Required Upgrade For Existing Packages check box, and then click ok.

If the older version has been installed, existing shortcuts will still launch the older version. The next time the user logs on, the user can install either version from Add/Remove Programs. Document invocation will only install the newer version if the GPO deploying the newer version has the highest order of precedence.

If the older version has not yet been installed, the next time that the user logs on, advertised shortcuts will start an installation of the newer version. The user can install either version from Add/Remove Programs, and document invocation will only install the later version if the GPO deploying the later version has the highest order of precedence.

If you want new users to install the newer version of the program but don't want to uninstall the application for people who are currently using the older version of the program, deploy the newer version as an optional upgrade, and then disable the older version.

1.6.2.3: Redeploying Software

Windows Server 2003 simplifies the deployment of service packs and software patches. When you mark a package file for redeployment, the application is re-advertised to everyone who has been granted access to the program, either through assigning or publishing. Then, depending on how the original package was deployed, one of the following happens:

• If the application was published and installed, the Start menu, desktop shortcuts, and registry settings relevant to that application will be updated the next time that the user logs on. The first time that the user starts the application, the service pack or software patch will be automatically applied.

• If the application was assigned to a user, the Start menu, desktop shortcuts, and registry settings relevant to that application will be updated the next time that the user logs on. The first time that the user starts the application, the service pack or software patch will be automatically applied.

• If the application has been assigned to a computer, the service pack or software patch will be automatically applied the next time that the computer is turned on. The application does not need to be activated for this to occur.

To redeploy a software package, obtain the service pack or software patch from the application vendor and place the files in the appropriate installation folders. The service pack must include a new .msi file. If it does not, you will be unable to redeploy the software because the original package file will contain instructions for deploying the new files added by the service pack or software patch. Open the GPO that originally deployed the application. In Software Installation, right-click the package filename, point to All Tasks, and click Redeploy Application. In the Redeployment dialog box, click Yes.

1.6.2.4: Removing or Disabling Software

Windows Server 2003 allows you to automatically remove software you no longer want deployed in your organization. To remove software, right-click the package file name in Software Installation, point to All Tasks, and then click Remove. In the Remove Software dialog box, select Immediately Uninstall The Software From Users And Computers (Forced Removal) to automatically delete the application from the computer, either the next time the computer is turned on or the next time a user logs on; or select Allow Users To Continue To Use The Software, But Prevent New Installations (Optional Removal).

Note: Only software that has been installed from a Windows Installer package file can be removed using Group Policy. Any software that was installed without using Windows Installer must be removed manually.
1.6.3: Deploying Service Packs and Hotfixes

Between operating system version releases, Microsoft releases regular updates to correct bugs and security vulnerabilities. These updates are distributed in two basic forms:

• Service Packs, which are packages that contain a large number of updates; and

• Hotfixes, which are small, incremental updates released between service packs.

A service pack contains all of the updates for an operating system over a period of time, and all the updates found in previously released hotfixes. Service packs are eventually rolled into the distribution of the operating system and become a stable part of the operating system. Fixes in service packs continue to work as you uninstall and reinstall other components, unless you uninstall the service pack. Hotfixes, on the other hand, can be overridden by the installation of new software. Thus, if you install a hotfix and then later update a component affected by the hotfix, you will need to reinstall the hotfix.

You can use the Qfecheck.exe program to check the current service pack and hotfix status of a computer. The Qfecheck.exe program is available for download from the Microsoft support Web site. To display a Qfecheck report, run Qfecheck.exe from the command prompt. The report includes the current service pack level of the operating system and a list of installed hotfixes. Qfecheck indicates whether each hotfix is current on the system or needs to be reinstalled.

1.6.3.1: Installing Service Packs and Hotfixes

You can download the latest service packs for your operating system from the Microsoft Web site. These service packs are distributed in two downloadable forms:

• Express Installation, which you can use when you do not need the software for additional computers. This option scans the computer and downloads and installs only the updates that are needed.

• Network Installation, which you can use when you need to install the service pack on other computers or deploy it across a network. This option includes the entire service pack in a single .exe file.

For enterprise deployment of service packs, you need the network installation download or a service pack CD. The service pack is distributed in the form of an .exe file. You can execute this file directly to install the service pack on the current computer. This extracts the files to a temporary directory and runs the Update.exe program, which performs the update. Instead of installing a downloaded service pack on the local computer, you can extract the files to a directory by specifying the -x option with the service pack executable at a command prompt. This will prompt you for a destination directory for the service pack files and allows you to make the service pack available over the network or to specify options to Update.exe.

Hotfixes are distributed as .exe files, similar to service packs, but they are smaller in size. Microsoft uses a standard naming convention for hotfixes beginning with the Microsoft Knowledge Base article number describing the hotfix.

To install a hotfix on a local computer, run the executable file. Because the changes made by hotfixes are usually rolled into a service pack, the hotfix verifies that you have the correct service pack level. If you have a newer service pack, the hotfix is not required, and the installer exits without making any changes. The hotfix installation is performed by an Update.exe program located within the self-extracting archive. As with service pack distributions, you can use the -x option with a hotfix to extract its files into a directory for later use.

1.6.3.2: Removing a Service Pack or Hotfix

If a service pack or hotfix causes incompatibilities with software or causes other issues, you can remove it. The current service pack and any installed hotfixes are listed with other installed software in the Add/Remove programs control panel. Hotfixes are listed with the Microsoft Knowledge Base article number that uniquely identifies each hotfix. To uninstall a service pack or hotfix, select its entry from the list and click the Change/Remove button.

1.6.3.3: Slipstreaming Service Packs and Hotfixes

Windows 2000, Windows Server 2003 and Windows XP support the integration of service packs and hotfixes with the Windows 2000, Windows Server 2003 or Windows XP installation files. This is called slipstreaming and allows you to create an installation image of the operating system with the service packs and hotfixes applied to it. You can then use this image to install the operating system with the service packs and hotfixes already applied during the deployment of new computers. You can also apply a service pack to computers that are already running Windows 2000, Windows Server 2003 or Windows XP by running the update. exe program.

To apply a new service pack to an existing installation image of the operating system, run the update.exe program from the service pack with the /slip switch. This will replace the existing installation files with the appropriate files from the service pack.

Note: You cannot uninstall service packs or hotfixes that were installed from a slipstream installation of the operating system.
1.6.3.4: Adding Service Packs and Hotfixes to a Network Installation Share

The Update.exe program included with each service pack includes an option to update a network installation share with the service pack files. To use this option, you must first extract the service pack files to a folder using the -x option on the distributed .exe file. After the files are extracted, you can update the network share. From the i386Update folder of the service pack files, execute the following command:

update.exe -s:<folder>

where folder is the folder where the installation files were extracted to.

Adding a hotfix to a network installation share is a more complex. To add a hotfix, extract its files using the -x option to the .exe file, and then copy the catalog file (.cat) and the .exe file for the hotfix into the i386svcpack folder. You must create this directory if it does not exist. Then copy the hotfix binary files into the network installation folder and create a Svcpack.inf file describing the additional hotfix to be installed.

1.6.3.5: Installing Multiple Hotfixes

When a large number of hotfixes have been released, especially critical security updates, you might find it inconvenient to install multiple hotfixes at each computer in the network, especially when a reboot is required after each installation. You can use Qchain.exe or a batch file to simplify this process and install several hotfixes at once.

• The Qchain.exe utility configures the computer after you install several hotfixes so that a single reboot can correctly install all the hotfixes. You can obtain Qchain.exe from the http://support.microsoft.com/ Web site by searching for Knowledge Base article #Q296861. To use Qchain.exe, first run the .exe file for each hotfix. Then use the -z option to prevent the hotfix from rebooting the computer after installation.

• You can combine several hotfixes and the Qchain.exe program, if necessary, into a batch file to install multiple hotfixes in a single operation. Use the -m option with each hotfix .exe file to suppress its output, along with the -z option to prevent rebooting. If Qchain.exe is required, include it as the last command in the batch file.

1.6.4: Microsoft Software Update Services

Windows server 2003 also supports automated methods to download and install hotfixes and service packs. These include the following methods:

• Windows Update, which is a Web-based interface that displays updates for a computer and allows users to install their choice of updates.

• Automatic Updates, which is a feature of Windows Update that notifies users of critical updates and optionally installs updates automatically.

• Software Update Services (SUS), which provides a service similar to Windows Update for enterprises and allows administrators to manage the installation of available updates.

1.6.4.1: Windows Update

Windows Update is a Web-based service that scans the local computer, determines which updates have not been installed, and then displays potential updates and provides a convenient interface for installing them. You can access the Windows Update site with the shortcut installed by default in the Start menu, or by going to the Windows Update site at http://windowsupdate.microsoft.com/.

Once the site is displayed, you click the Scan For Updates link to scan the computer. After the scan completes, Windows Update displays a list of available updates. Critical updates and new service packs are listed first, followed by non-critical operating system updates and updated hardware drivers. Click the Add button next to an update description to add the update to the list of updates to install. After you are finished adding items, click the Review And Install Updates link to install the updates.

1.6.4.2: Windows Update Catalog

Windows Update is a convenient service for computers that have Internet connections, it is not useful for a computer that does not have an Internet connection. To service computers that are not connected to the Internet, you can use the Windows Update Catalog, which provides local copies of the available updates.

Once you have local copies of the updates on a computer that is connected to the Internet, you can distribute those updates to computers that are not connected to the Internet by using a local network or removable media such as CD-R. The Windows Update Catalog can then be configured on those computers to use the local sources for installation rather than connect to the Internet.

1.6.4.3: Automatic Updates

In computers with Windows Server 2003, Windows 2000 Service Pack 3 or Windows XP Service Pack 1 installed, Critical Update Notification, a utility that periodically checked the Windows Update Web site for critical updates to a computer, has been replaced by Automatic Updates. This service expands the original concept of the Critical Update Notification utility by not only notifying users of updates, but also downloading and installing them automatically if desired.

Automatic Updates downloads updates directly from the Microsoft web site and stores them in a temporary directory on each computer until they are installed. For large enterprises or for those that do not have a direct connection to the Internet, this default behavior is not always desirable. Automatic Updates can also act as a client for Microsoft Software Update Services (SUS), which allows administrators to establish a local server that can distribute updates.

1.6.4.4: Software Update Services

Microsoft Software Update Services (SUS) provides the same benefit on local servers as the Windows Update servers provide on the Internet. It allows you to make your choice of updates available to clients using Automatic Updates. The SUS server synchronizes with the Windows Update server to obtain the latest updates, and multiple SUS servers can synchronize with each other.

SUS requires at least a Windows 2000 Server computer with Service Pack2 configured as a stand-alone server or member server. It cannot be installed on a domain controller. It also requires Internet Information Services (IIS). To install SUS, first download the server software from the Microsoft Web site. SUS is provided as a file, Sussetup.msi, that uses the Windows Installer to install the service. Run this program to begin the installation. A wizard guides you through the installation process.

When using SUS, you must configure each client to use the SUS server and you must approve updates before they will be made available to clients. This approval process allows you to pre-test updates before deploying them across the enterprise. The updates you approve will be installed by clients running Automatic Updates on their next scheduled connection to the SUS server.

Note: You can remove approval from updates that have been previously approved. However, this does not remove them from any clients that have already installed the update.