CHAPTER 8 Deploying Applications
254
n
Storage costs Storage costs include storage of the deployment shares, disk images,
migration data, and backup images. Storage costs can be significant, depending on the
number of disk images, number of computers in each deployment run, and so on.
n
Network costs Network costs include moving disk images to deployment shares and
to desktops.
As the size of image files increases, costs increase. Large images have more updating, test-
ing, 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 8-1. To date, most organizations that use disk imaging to deploy operating
systems are building thick images.
Image Engineering Image Deployment
Thick
Image
Windows 7
Applications Destination Computers
FIGURE 8-1
The thick image process
The advantage of thick images is deployment speed and simplicity. You create a disk im-
age 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
Destination Computers
Image Deployment
Applications
FIGURE 8-2
The thin image process
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 8 Deploying Applications
256
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 configura-
tion 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 infrastruc-
ture 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.
Hybrid Images
Hybrid images mix thin- and thick-image strategies. In a hybrid image, you configure the disk
image to install applications on first run, giving the illusion of a thick image but installing
the applications from a network source. Hybrid images have most of the advantages of thin
images. However, they aren’t as complex to develop and do not require a software distribu-
tion infrastructure. They do require longer installation times, however, which can raise initial
deployment costs.
An alternative is to build one-off thick images from a thin image. In this case, you build a
reference thin image. After the thin image is complete, you add core applications and then
Unattended Package Installation
PACKAGE TYPE COMMAND FOR UNATTENDED INSTALLATION
Windows Installer
msiexec.exe /i package.msi /qn ALLUSERS=2
InstallShield Windows
Installer
setup.exe /s /v"/qn"
Optionally, you can extract the Windows Installer database
from the compressed file and use the command msiexec.exe /i
setup.msi ISSETUPDRIVEN=1 /qn to install it.
Legacy InstallShield
setup.exe /s /sms
To create the Setup.iss file necessary to run setup silently, type
setup.exe /r to create a Setup.iss from your responses to the
setup program’s dialog boxes and then copy Setup.iss from
%SystemRoot% to the folder containing the package.
Legacy InstallShield
PackageForTheWeb
setup.exe /a /s /sms
To create the Setup.iss file necessary to run setup silently, type
setup.exe /a /r to create the Setup.iss based on your responses
and then copy Setup.iss from %SystemRoot% to the folder
containing the package.
Legacy Wise
Installation System
setup.exe /s
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 8 Deploying Applications
258
Useful Deployment Web Sites
/aa372796.aspx.
Windows Installer 5.0 is compatible with User Account Control (UAC) in Windows 7. By us-
ing elevated installation, an administrator can authorize Windows Installer to install applica-
tions or security updates on behalf of users who aren’t members of the Administrators group.
For more information about UAC, see Chapter 24, “Managing Client Protection.”
Windows Installer packages provide the following to enable flexible application deployment:
n
Command-line options You use command-line options to specify options, file
names, and path names, as well as control the action of the installation at run time.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Automating Installation CHAPTER 8
259
n
Properties (variables) on the command line Properties are variables that Windows
Installer uses during an installation. You can set a subset of these, called public proper-
ties, on the command line.
n
Transforms A transform is a collection of changes you can apply to a base Windows
Installer package (.msi) file. You can customize applications by using Windows Installer
transform (.mst) files. You configure transforms to modify a Windows Installer package
to dynamically affect installation behavior according to your requirements. You associ-
ate transforms with a Windows Installer package at deployment time. Transforms for
Windows Installer package files are similar to answer files that you might have used to
automate the installation of an operating system such as Windows Vista.
The number of applications packaged as Windows Installer databases is multiplying rapidly.
Nearly all software vendors are packaging their applications using this technology. And what
often looks like a self-contained, self-extracting setup program with a file name such as Setup.
exe is often a file that decompresses to a Windows Installer database. You can usually extract
the database by using a tool such as WinZip (from WinZip Computing at http://www.winzip.com)
or by running the setup program and looking in %UserProfile%\Local Settings\Temp for the
double quotation marks. For example, the following command installs the application
silently and passes the /qn option.
setup.exe /s /v"/qn"
n
Deploy the InstallShield Script Engine separately as part of your core applications
before any setup files that require it. You may then safely bypass running Setup.exe
by installing the Windows Installer setup database with Msiexec.exe and including the
ISSETUPDRIVEN public property. You can extract the embedded Windows Installer
setup database by looking in the %Temp% folder after the welcome message for the
installation wizard is displayed. Then, use the following command to install it.
msiexec.exe /i setup.msi ISSETUPDRIVEN=1 /qn
Legacy InstallShield
Packages created using legacy InstallShield technologies usually have the file name Setup.exe.
To create an unattended installation for a legacy InstallShield package, you need to create an
InstallShield script, which has the .iss file extension. Many applications come with such a file,
but they are also easy to create.
To create an InstallShield response file, perform the following steps:
1.
Run the setup program using the /r command-line option. This creates a Setup.iss file
based on how you configure the installation as you step through the setup program.
The result is the file Setup.iss in %SystemRoot%.
2.
Copy Setup.iss from %SystemRoot% to the folder containing the package.
3.
Run the setup program using the /s command-line option. The setup program runs
silently using the responses provided by the Setup.iss file.
iMpoRtAnt
Packages created by InstallShield will spawn a separate process and then
return immediately to the calling program. This means that the setup program runs
asynchronously, even if you start the setup program using start /wait. You can add the
on the keyboard to install the application. If a user can complete the installation by using only
the keyboard, you can automate the installation by creating a script (a series of text com-
mands) that simulates keystrokes. This technique is called screen scraping.
You can screen scrape by using Windows Script Host. Specifically, you use the SendKeys()
method to send keystrokes to an application. For more information about the SendKeys()
method and an example that you can use to quickly create your own screen-scraping scripts,
see http://windowssdk.msdn.microsoft.com/en-us/library/8c6yea83.aspx.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 8 Deploying Applications
262
on tHe CoMpAnion MediA
The companion media contains the sample script
Sendkeys.vbs, which provides a shell for using the SendKeys() method without having
to write your own script. It accepts two command-line options: sendkeys.vbs program
textfile, where program is the path and file name of the program you want to drive,
and textfile is the path and file name of the text file containing the keystrokes, one
keystroke per line, to send to the program. See http://windowssdk.msdn.microsoft.com
/en-us/library/8c6yea83.aspx for a list of key codes. If you need to pause before send-
ing more keystrokes, add a line to the file that contains sleep. Each line that contains
sleep will pause for 1 second. The file Sendkeys.txt is a sample textfile you can use
with Sendkeys.vbs; for example, type sendkeys.vbs notepad.exe sendkeys.txt and
watch what happens.
Repackaging Legacy Applications
Some legacy installers don’t support silent installations, and some that do support silent
installations don’t provide a way to script settings. No legacy installers provide the manage-
ment capabilities that Windows Installer provides.
If you have an application that is not designed for Windows Installer and does not support
another automated installation technique, you can repackage it into the Windows Installer
setup database so that you can use the features of Windows Installer to distribute and man-
age the application. A repackaged application combines the entire feature set of the appli-
Create a package that contains the differences between the two snapshots. The re-
packaging tool detects all of the differences between the two snapshots, including all
changes to the registry and file system. Because numerous processes are running in
Windows 7 at any time, the package file will likely contain settings and files related to
processes outside of the application.
5.
Clean the package to remove noise (unnecessary files and settings).
WARning
Don’t let the simplicity of these five steps trick you into believing that re-
packaging is easy. Application repackaging is very often the most expensive part of any
deployment project. When you undertake the repackaging of an organization’s applica-
tions, you can count on a labor- and resource-intensive effort, particularly in organizations
with thousands of applications, many of which the organization must repackage. Budget,
plan, and schedule accordingly.
Repackaging Tools
You must use tools that are not included with Windows Installer to create Windows Installer
packages. The following list includes some of the variety of tools available:
n
AdminStudio Available in multiple versions, including a free download, AdminStudio
is a powerful and flexible repackaging tool. The following versions are available:
•
AdminStudio Configuration Manager Edition This free download from
Microsoft integrates with System Center Configuration Manager 2007 to simplify
repackaging. AdminStudio Configuration Manager Edition prepares legacy
Setup.exe packages for deployment by converting them to Windows Installer
.msi packages. To download AdminStudio Configuration Manager Edition, see
http://technet.microsoft.com/en-us/configmgr/bb932316.aspx.
•
AdminStudio Professional Edition This full version of AdminStudio is a
complete solution for packaging, customizing, testing, and distributing applications.
This chapter does not describe how to start or use Deployment Workbench. For
more information about using Deployment Workbench, see Chapter 6, “Developing Disk
Images.”
diReCt FRoM tHe SoURCe
Infrastructure
Doug Davis, Lead Architect
Management Operations & Deployment, Microsoft Consulting Services
O
ne question I hear repeatedly regarding deployment space concerns the
amount of infrastructure required. Even with a moderately large (thick) image,
customers still need to deploy additional applications. I typically suggest dynamic
application distribution—applications that the user had before are dynamically
reinstalled on the new configuration before the user logs on to the computer.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Injecting in a Disk Image CHAPTER 8
265
However, this requires a stable infrastructure. On average, three applications will
need to be added for each computer—three applications not already included in
the thick image. On average, 4,805 files per computer will be migrated by using the
User State Migration Tool (USMT), and 900 megabytes (MB) will be transferred per
computer. Therefore, a 1,000-computer deployment would require the following
infrastructure:
n
Computers: 1,000
n
Applications: 2,952
n
Files: 4,805,594
n
Gigabytes: 977.60
“Creating Dependencies” later in this chapter.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 8 Deploying Applications
266
3.
On the Details page, provide the following information about the application and then
click Next:
a.
In the Publisher box, type the name of the application’s publisher (optional).
b.
In the Application Name box, type the name of the application.
c.
In the Version box, type a version label for the application (optional).
d.
In the Languages box, type the languages supported by the application (optional).
4.
On the Source page, type the path of the folder containing the application you want
to add and then click Next. If you’ve chosen to copy the application source files to the
deployment share, Deployment Workbench copies everything in this folder to the
deployment share; otherwise, it adds this path to the application’s metadata as the
application’s installation path.
note
If you select the Move The Files To The Deployment Share Instead Of Copying
Them check box, the New Application Wizard will move the source files instead of copy-
ing them. Use this option if you want to stage applications on the local hard disk before
moving them into the deployment share.
5.
On the Destination page, type the name of the folder to create for the application
within the deployment share and then click Next. The default value is the publisher,
application name, and version label concatenated.
then click OK. Deployment Workbench only displays applications in this list that
you’ve already added to the deployment share.
n
To remove an application from the dependencies list, select an application in the
dependencies list and then click Remove.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 8 Deploying Applications
268
n
To reorder the applications in the dependencies list, select an application in the
dependencies list and then click Up or click Down. MDT 2010 installs the dependent
applications in the order specified by the dependencies list.
Installing Applications
In MDT 2010, the task sequence specifies the tasks that run during deployment and their
order. You can install applications during the imaging process by adding a step to the task
sequence that installs the application at the appropriate time. For more information about
customizing the task sequence, see Chapter 6. Although this approach is useful for injecting
applications into a disk image, using the MDT 2010 database or CustomSettings.ini is more
appropriate during deployment in production. For more information, see Chapter 12,
“Deploying with Microsoft Deployment Toolkit.”
Without creating additional groups in the task sequence, the best place to add application
installs is to the Custom Tasks group, which MDT 2010 creates in each task sequence’s default
task sequence. The instructions in this section show you how to install an application as a step
under this group.
note
If you add an application to the deployment share without installing it via the task
sequence, the Windows Deployment Wizard will allow the user to install the application
optionally during deployment. Also, you can choose applications to install automatically
during a Zero Touch Installation by configuring the deployment share to install the applica-
tion automatically.
categorize, and document the installation of each application. MDT 2010 and ACT provide
tools that help with this step.
Another key planning step is determining the right type of deployment strategy for your
organization. Thick images are monolithic images that contain core applications and other
files. They are large and costly to maintain and deploy. Thin images are bare images. You
install applications post-deployment using a systems-management infrastructure, such as
System Center Configuration Manager 2007. Hybrid images use a combination of both
strategies. The deployment strategy you choose determines how you build images.
After careful planning, you repackage the applications that don’t provide an automated
installation and document the installation commands for those that do. Then add applica-
tions to your MDT 2010 deployment share and add steps to the task sequence that installs the
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Additional Resources CHAPTER 8
271
application when you build the disk image (thick image) or when you deploy the disk image
(hybrid image).
note
If you’re not using MDT 2010 to deploy Windows 7, see Chapter 4 to learn why
using MDT 2010 is a better way to deploy Windows 7 than using the Windows AIK alone. If
you’re not using MDT 2010, see Windows Automated Installation Kit User’s Guide to learn
how to install applications by using an answer file.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
n
Chapter 2, “Security in Windows 7,” includes more information about how Windows 7
security features affect applications.
n
Chapter 5, “Testing Application Compatibility,” describes how to use ACT 5.5 to create
an application inventory, analyze it, and then mitigate compatibility issues.