• High High-priority applications are most likely mission-critical or core applications. These are applications that are pervasive in the organization or are complex and must be addressed first. Examples of high-priority applications include virus scanners, management agents, Microsoft Office, and so on.

• Medium Medium-priority applications are nice to have but not essential. These are applications that are not as pervasive or complex as high-priority applications. For example, a custom mailing-list program might be a medium-priority application, because you can replicate the functionality in another application. To test whether an application is indeed a medium priority, answer this question: What's the worst that would happen if all the high-priority applications are deployed, but not this application? If you foresee no major consequences, the application is a medium priority.

• Low Low-priority applications are applications that deserve no attention in the process. Examples of low-priority applications are duplicate applications, applications that users have brought from home and installed themselves, and applications that are no longer in use. When prioritizing an application as low, record the reason for that status in case you must defend the decision later.

• Core applications Core applications are applications common to most of the computers in the organization (typically 80 percent or more) or applications that must be available the first time you start a computer after installing the operating system. For example, virus scanners and security software are usually core applications because they must run the first time you start the computer. Mail clients are core applications because they are common to all users and computers. The following list contains specific examples of what most organizations might consider core applications:

  • Adobe Acrobat Reader

  • Corporate screen savers

  • Database drivers and connectivity software

  • Macromedia Flash Player

  • Macromedia Shockwave

  • Microsoft Office

  • Network and client management software, such as OpenManage clients

  • Terminal emulation applications, such as TN3270

  • Various antivirus packages

  • Various Windows Internet Explorer plug-ins

  • Various Microsoft Office Outlook plug-ins

• Supplemental applications Supplemental applications are applications that aren't core applications. These are applications that are not common to most computers in the organization (department-specific applications) and aren't required when you first start the computer after installing a new operating system image. Examples of supplemental applications include applications that are department specific, such as accounting software, or role specific, such as dictation software. The following list contains examples of what most organizations consider supplemental applications:

  • Microsoft Data Analyzer 3.5

  • SQL Server 2005 Client Tools

  • Microsoft Visual Studio 2005 and Visual Studio 2008

  • Various Computer-Aided Design (CAD) applications

  • Various Enterprise Resource Planning (ERP) systems

• Automatic installation Most applications provide a way to install automatically. For example, if the application is a Windows Installer package file (with the .msi file extension), you can install the application automatically. 

• Repackaged application If an application does not provide a way to install automatically, you can repackage it to automate and customize installation by using one of the packaging technologies . Repackaging applications is a complex process and is quite often the most costly and tedious part of any deployment project. Make the decision to repackage applications only after exhausting other possibilities. Doing so requires technical experience with repackaging applications or using third-party companies to repackage the application for you.

• Screen scraping You can automate most applications with interactive installers by using a tool that simulates keystrokes, such as Windows Script Host Understand that this method is more of a hack than a polished solution, but sometimes you're left with no other choice. Occasionally, the installation procedure may require the user to use the mouse or otherwise perform some complex task that cannot be automated easily. In these circumstances, automating the installation process may not be feasible.

• The location of the installation media. Often, the SME is the best source of information about the location of the source media, such as CDs, disks, and so on.

• Settings that differ from the application's default settings that are required to deploy the application in a desired configuration.

• External connections. For example, does the application require a connection to a database, mainframe, Web site, or other application server?

• Constraints associated with the application.

• Deployment compatibility. Is the application compatible with disk imaging and Sysprep? Is the application compatible with 32-bit systems? 64-bit systems?

• Application dependencies. Does the application depend on any patches or other applications?

3. Choosing a Deployment Strategy

Most companies share a common goal: create a corporate-standard desktop configuration based on a common image for each operating system version. They want to apply a common image to any desktop in any region at any time and then customize that image quickly to provide services to users.

In reality, most organizations build and maintain many images—sometimes even hundreds of images. By making technical and support compromises and disciplined hardware purchases, and by using advanced scripting techniques, some organizations have reduced the number of images they maintain to between one and three. These organizations tend to have the sophisticated software distribution infrastructures necessary to deploy applications—often before first use—and keep them updated.

Business requirements usually drive the need to reduce the number of images that an organization maintains. Of course, the primary business requirement is to reduce ownership costs. The following list describes costs associated with building, maintaining, and deploying disk images:

As the size of image files increases, costs increase. Large images have more updating, testing, distribution, network, and storage costs associated with them. Even though you update only a small portion of the image, you must distribute the entire file.

Thick Images

Thick images are monolithic images that contain core applications and other files. Part of the image-development process is installing core applications prior to capturing the disk image, as shown in Figure 1. To date, most organizations that use disk imaging to deploy operating systems are building thick images.

Figure 1. The thick image process

The advantage of thick images is deployment speed and simplicity. You create a disk image that contains core applications and thus have only a single step to deploy the disk image and core applications to the destination computer. Thick images also can be less costly to develop, as advanced scripting techniques are not often required to build them. In fact, you can build thick images by using MDT 2010 with little or no scripting work. Finally, in thick images, core applications are available on first start.

The disadvantages of thick images are maintenance, storage, and network costs, which rise with thick images. For example, updating a thick image with a new version of an application requires you to rebuild, retest, and redistribute the image. Thick images require more storage and use more network resources in a short span of time to transfer.

Thin Images

The key to reducing image count, size, and cost is compromise. The more you put in an image, the less common and bigger it becomes. Big images are less attractive to deploy over a network, more difficult to update regularly, more difficult to test, and more expensive to store. By compromising on what you include in images, you reduce the number you maintain and you reduce their size. Ideally, you build and maintain a single, worldwide image that you customize post-deployment. A key compromise is when you choose to build thin images.

Thin images contain few if any core applications. You install applications separately from the disk image, as shown in Figure 2. Installing the applications separately from the image usually takes more time at the desktop and possibly more total bytes transferred over the network, but spread out over a longer period of time than a single large image transfer. You can mitigate the network transfer by using trickle-down technology that many software distribution infrastructures provide, such as Background Intelligent Transfer Service (BITS).

Figure 2. The thin image process

Thin images have many advantages. First, they cost less to build, maintain, and test. Second, network and storage costs associated with the disk image are lower because the image file is physically smaller. The primary disadvantage of thin images is that postinstallation configuration can be more complex to develop initially, but this is offset by the reduction in costs to build successive images. Deploying applications outside the disk image often requires scripting and usually requires a software distribution infrastructure. Another disadvantage of thin images is that core applications aren't available on first start, which might be necessary in high-security scenarios.

If you choose to build thin images that do not include applications, you should have a systems-management infrastructure, such as Microsoft System Center Configuration Manager 2007, in place to deploy applications. To use a thin image strategy, you will use this infrastructure to deploy applications after installing the thin image. You can also use this infrastructure for other postinstallation configuration tasks, such as customizing operating system settings.