Windows 7 : Designing an Application Deployment Strategy (part 3) - Deploying Applications - Selecting an Application Deployment Method

A local—or client-based—installation is one in which you install the application on the workstation’s hard disk. The simplest way to do this is the manual installation method, in which an installer starts the application’s setup program from a CD or DVD or a network drive. As with a manual operating system installation, this is generally the slowest method and the one that requires the most interaction from the installer. For small deployments, however, manual installations might require less time and effort than designing and implementing an elaborate automated deployment.

Another element to consider when evaluating the manual deployment option is how many applications you have to install on each workstation and how complex those installations are. Deploying an office suite that uses one setup program to install five different applications is quicker and easier than installing five separate products, each with its own installation procedure.

For most desktop administrators, the manual installation option is not a practical solution for applications, just as it is not practical for the operating system. There are other ways to deploy applications locally, however.

Three basic types of system images you can create from your reference computers. One of these, the thick image, incorporates all of the applications that you plan to deploy in a particular workstation configuration. By installing and configuring all of the applications on the reference computer prior to capturing an image of it, you eliminate the need for an application deployment process after the operating system deployment.

Package-based deployment methods enable administrators to install applications on workstations with a minimum of interaction. A package is essentially a database file with an .msi extension that contains everything a computer needs to install and run a particular application. Packages contain the application files themselves, as well as registry settings, installation instructions, and other application components. Windows Installer, the installation engine incorporated into Windows 7 and all other Windows versions since Windows 2000, reads the instructions from the package and installs the application on the computer without needing an interactive setup program.

Windows 7 associates the .msi file extension with Windows Installer, so you can simply execute an MSI package manually to begin the installation process. However, you also can automate the deployment of package files, using Group Policy or SCCM 2007.

By creating software installation policies in a Group Policy object and associating them with Active Directory Domain Services (AD DS) domains, sites, or organizational units, you can deploy packages to users or computers throughout the enterprise. Group Policy is a part of AD DS, so this deployment method is free and relatively simple to configure. The primary complication is that, in most cases, applications do not come packaged as .msi files, and administrators must use a third-party product to create the packages. 

Deploying packages to computers throughout an enterprise is the primary function of System Center Configuration Manager. However, although you can use SCCM to deploy the same MSI packages as Group Policy, and with greater flexibility, it has other capabilities as well.

SCCM uses the term “package” to describe a software element that it distributes to clients on the network, but the definition is not the same as the Windows Installer package described earlier. Using SCCM’s Configuration Manager console, you create your own packages that can consist of virtually any materials needed to install software on a client computer. If you have a Windows Installer package in MSI format, you can use SCCM to deploy it, but you can also install an application using the source files, without a third-party packaging utility.

As with an operating system deployment, if you already have SCCM on your network, you should definitely use it to perform your local application deployments. The same corollary also holds true: if you do not have SCCM, it is probably not worth installing it just for application deployments. However, when you consider that SCCM can deploy your operating systems, your applications, and the updates for both, many administrators might begin to see it as a viable solution.

If you opt for server-based applications, you have several ways of configuring Remote Desktop Services (RDS) to deploy them. RDS, known as Terminal Services in Windows Server 2008 and earlier, is a collection of services that enables administrators to publish individual applications or entire desktops to workstations on the network. By electing to deploy your applications using RDS, you are committing to much greater hardware requirements for your servers, but you eliminate the need for a complex application installation process on the workstations.

The Remote Desktop Connection client is built into all Windows versions, including Windows 7, but the license needed to access an RDS server is not. By selecting this deployment method, you are also committing to the additional expense of an RDS client access license (CAL) for each user that accesses applications from your servers.

Compared to a local workstation deployment, deploying applications on your RDS servers is a relatively simple process. After installing the Remote Desktop Services role, you simply install the application—just once—in the usual manner. The application does not need any special capabilities or configuration; RDS is responsible for the client sharing. If you have a large number of clients and plan to use multiple RDS servers, you can automate the installation of the applications, just as you would for client workstations.

With RDS, the application runs on the server; the only information transmitted to and from the client is that needed for the interface: keystrokes, mouse movements, and display data. The network traffic generated by a single client is therefore minimal, although scale is critical, as with any network application. The traffic for hundreds of clients can conceivably flood a network, just as with any other client/server application.

Microsoft Application Virtualization—also known as App-V—is a technology that enables Windows servers to virtualize applications, much in the way that Hyper-V virtualizes operating systems. With App-V, servers supply applications to a client running on the workstation, and the client executes them locally. However, the client does not install the application first; instead, it runs the application in a virtual environment that is completely isolated from the client operating system.

App-V can cache applications on a workstation for improved performance, but App-V never writes application files to the workstation’s file system, nor does it add settings to the workstation’s registry. The environment in which the application runs is sometimes known as a sandbox because it is isolated from all other applications running on the workstation.

Because App-V runs applications in a virtualized environment, there are no compatibility issues with operating systems or between applications. You can use App-V to deploy applications directly to workstations or to RDS servers, the latter of which makes it possible for a single server to run multiple versions of a single application.

When App-V deploys applications directly to the workstation, the applications run using workstation, not App-V server, resources. When you deploy the applications to RDS, the applications run on the RDS server, which in turn serves them to the Remote Desktop Connection clients on the network.

Because a self-taught student cannot be expected to have access to a System Center Configuration Manager server, the practice for this lesson consists of SCCM videos produced by Microsoft.

EXERCISE 1 Viewing a “Using Asset Intelligence” Video

On a Windows computer with Internet access, you can view a video demonstration of the SCCM Asset Intelligence feature.

EXERCISE 2 Viewing an “Inventory Reporting” Video

On a Windows computer with Internet access, you can view a video demonstrating how to view the information gathered by the Asset Intelligence feature in SCCM.