The

20
Commandments
of
Software Packaging
PRACTICAL IMPLEMENTATION OF SOFTWARE PACKAGING BEST PRACTICES

Nelson Ruest & Danielle Ruest

Sponsored by
Table of Contents

Introduction............................................................................................ 1
Working with the 20 Commandments................................................... 2
1. Prepare your Packaging Environment....................................... 2
2. Use Proper Workflows ................................................................ 3
3. Collect all Project Data before Beginning .................................. 6
4. Package for Windows Installer................................................... 6
5. Know When to Package ............................................................. 7
6. Repackage or Customize all of Your Software Installations ..... 7
7. Start with a Clean System......................................................... 8
8. Leverage Virtual Machines ........................................................ 9
9. Use Installation Monitoring to Repackage ................................ 9
10. Use a Custom Package Template ............................................ 10
11. Use a Global Exclusion List..................................................... 11
12. Know Your Packages................................................................ 12
13. Use a System Construction Model .......................................... 13
14. Create Package Catalogs.......................................................... 15
15. Perform Conflict Detection....................................................... 16
16. Test as a User .......................................................................... 20
17. Perform Deployment Testing ................................................... 21
18. Document Your Changes......................................................... 22
19. Patch Your Packages................................................................ 23
20. Manage Packaging as a Project ............................................... 25
Conclusion............................................................................................ 27

The 20 Commandments of Software Packaging White Paper Page ii

Abstract
Most system administrators have discovered that when it comes to software delivery in their
network, they’re much better off creating a new, company-specific (repackaged) image of an
application before releasing it. Unfortunately, not everyone uses the same set of rules for software
packaging and, evidently, not everyone gets the same results. Macrovision, makers of
AdminStudio—a comprehensive integrated packaging environment (IPE)—and authors Danielle
Ruest and Nelson Ruest, both independent packaging consultants, have come up with the 20
commandments of software packaging. This is specific, practical advice on how to best package
software. This white paper will take you through each step in the packaging process and provide
practical advice on how to create your packages according to the principles outlined here. You’ll
come away with a complete process that can help ensure the quality of your packages. This white
paper aims to answer your questions and make sure that you learn how to gain the full benefits
proper software packaging can bring.  In addition, you can view an accompanying Webcast on the
topic for further information.

About the Authors

Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migration
planning, software management and architecture design. They are authors of multiple books, notably
two books published by McGraw-Hill Osborne, “Windows Server 2003: Best Practices for Enterprise
Deployments”, ISBN 0-07-222343-X and “Windows Server 2003 Pocket Administrator”, ISBN 0-07-
222977-2 as well as “Preparing for .NET Enterprise Technologies”, published by Addison Wesley, ISBN
0-201-73487-7. They have extensive experience in software packaging and managing large packaging
projects.

Copyright (c) 1990-2005 Macrovision Europe Ltd. and/or Macrovision Corporation. All Rights
Reserved. AdminStudio and InstallShield are registered trademarks of Macrovision Corporation in the
United States of America and/or other countries. All other brand and product names mentioned
herein are the trademarks and registered trademarks of their respective owners.

The 20 Commandments of Software Packaging White Paper Page iii

Introduction
System administrators have been packaging software ever since there
have been microcomputers. That’s because most system administrators
have discovered that they’re much better off creating a new, company-
specific (repackaged) image of an application before releasing it into the
network. Unfortunately, not everyone uses the same set of rules for
software packaging and, evidently, not everyone gets the same results.
One thing is certain, if you manage your software packaging processes
in the right way, you will enjoy a lower total cost of ownership for your
PCs. But how can you guarantee this result?
Macrovision, makers of AdminStudio—a comprehensive integrated
packaging environment (IPE)—and authors Danielle Ruest and Nelson
Ruest, both independent packaging consultants, have come up with
the 20 commandments of software packaging:
1. Prepare your Packaging Environment
2. Use Proper Workflows
3. Collect all Project Data Before Beginning
4. Package for Windows Installer
5. Know When to Package
6. Repackage or Customize all of Your Software Installations
7. Start with a Clean System
8. Leverage Virtual Machines
9. Use Installation Monitoring to Repackage
10. Use a Custom Package Template
11. Use a Global Exclusion List
12. Know Your Packages
13. Categorize Your Packages
14. Use a System Construction Model
15. Perform Conflict Detection
16. Test as a User
17. Perform Deployment Testing
18. Document Your Changes
19. Patch Your Packages
20. Manage Packaging as a Project
If you use these rules, you’ll learn to gain the full benefits proper
software packaging can bring.

The 20 Commandments of Software Packaging White Paper Page 1

Working with the 20 Commandments
Each of the commandments deals with a particular aspect of
packaging. Taken as a whole, they cover the entire packaging process
and address each of the most important parts of this process.

1. Prepare your Packaging Environment

Too many people don’t take the time to properly prepare the packaging
environment itself. Keep in mind that a software packaging
environment or laboratory should be architected, just like any other
environment in your network. This means you’ll need to put the proper
tools in place—tools such as an installation repository for all source
software installations, a software repository for all packaged
installations as well as proper troubleshooting tools. In addition, use a
proper database system to store all package information. Most software
packaging tools come with the Microsoft SQL Server Desktop Engine
(MSDE) or Microsoft Access runtime databases, but these tools have
limitations that can impact your packaging environment in a negative
Macrovision’s manner. The most important of these is the size limitation on the
AdminStudio database. If your packaging database exceeds these size limitations,
Try a fully functional, you could stand a chance of losing all packaging data. You certainly
free evaluation of
don’t want to find yourself in this situation. Treat your packaging data
AdminStudio at
www.installshield.com/
as corporate data and implement a commercial database system with
products/adminstudio/ proper backup strategies.
eval.asp Finally, use representative systems to prepare and test your packages
and implement proper re-imaging mechanisms to restore these
machines to pristine states.
Figure 1 outlines the tools and structure you should use in your
packaging laboratory. This addresses only a single packaging lab. If you
use distributed packaging teams, you’ll want to replicate the same
architecture in each location and ensure your software packaging
databases are replicated to each location. This lab includes:
• Microsoft SQL Server 2000 with Service Pack 3a
• At least one server running multiple roles:
o Database storage
o File storage for all software installation sources
o File storage for all repackaged software
o File storage for machine images or virtual machines
o Central repository for the integrated packaging
environment, in this case Macrovision’s AdminStudio®
o Software deployment technologies for deployment testing
o Directory services which emulate your production
network
• Operator workstations aimed at documentation and
research—these workstations are connected to the Internet

The 20 Commandments of Software Packaging White Paper Page 2

 • Workstations, called clean machines, that are used for package
preparation
• Testing workstations that are representative of the machines in
your production network
• Virtual machine technology that can be used to replace the
physical clean machines
• Packaging utilities such as SysInternals Regmon—a tool
designed to monitor changes to the registry—and Filemon—a
tool designed to monitor file activity when programs are
running; both tools are free
• Package Quality Control utilities such as iTripoli Package
Cleaner—a tool that verifies package contents and acts as an
internal knowledge base telling you if and why you should or
shouldn’t include specific components in the package
• A machine imaging tool that lets you restore physical machines
to a pristine state each time a project is complete
• Backup software and a tape library to protect your packaging
data

Figure 1. The Packaging Environment

As you can see, preparing for packaging is a serious business. Make
sure you implement a scalable and customizable solution. You’ll be
packaging for quite some time; make sure your packaging environment
is reliable and stable.

2. Use Proper Workflows

There’s a lot to be said for getting the right people to do the right job
during the packaging and testing process. Even if your packaging team
is a team of one, you’ll need to make sure you use a step-by-step
process for packaging and that you follow it to a tee.
If your team includes more than one person, all the better, but then
you’ll need to assign a lab coordinator to oversee all preparation
activities. In addition, you’ll want to make sure that your testers are not

The 20 Commandments of Software Packaging White Paper Page 3

 the same as your packagers. This will help improve testing processes.
There’s nothing like a fresh pair of eyes to catch omissions and
unexpected items.
The best way to make sure you have the right people performing the
right tasks is to look at the packaging process itself. In the packaging
process (see Figure 2), you begin with a request for a new or upgraded
product. This request comes into the packaging lab and is processed by
the lab coordinator and the packaging project manager. The former
assigns resources to the project and the latter manages the project
activities. The package is assigned to a team member who may even be
a junior packager since this process is fairly simple and repetitive. The
packager will begin by discovering package features. Once this is done,
the next step is preparing the package itself. When the initial package is
ready, it moves to testing and conflict detection. If your team is large
enough, you might consider separating the testing and conflict
detection position from packaging and dedicating this role to someone
with more experience, since testing is more complex and requires more
knowledge, a sort of packaging subject matter expert, if you will. The
same goes for quality assurance (QA). Since it is a key part of the
process, assigning the role to someone else also gives you better results.
In fact, this role is often best met by expert users who are familiar with
the software product itself. There’s nothing like a fresh pair of
knowledgeable eyes when it comes to QA. The package is then released
from the laboratory. This is usually the responsibility of the project
manager. The release is passed on to the deployment team and once
deployed, the package moves on to the maintenance team until it is
retired from the network. The retirement may also be cause for a new
request to be initiated by users. The packaging process then comes full
circle.

Figure 2. The Packaging Process

This means that your packaging team should include the following
roles:
• Lab coordinator
• Project manager
• Packaging subject matter expert

The 20 Commandments of Software Packaging White Paper Page 4

 • Packager
• Tester and conflict detection specialist
• QA specialist or expert users
• Deployment specialist
The latter is not necessarily in the packaging team, but should have a
solid relationship with the team. Of course, depending on the size of
your team and the number of packages to manage, you may add roles
such as administration and research. Make sure you document and
publish this workflow for all team members to see.
Within AdminStudio, packaging steps can be outlined to establish
standards (see Figure 3).

Figure 3. AdminStudio Lets You Use the Packaging Process as You

Prepare Packages
For larger projects, a centralized Web-based workflow system such as
Macrovision’s AMS can be layered on top of the AdminStudio
functionality to enhance the level of coordination (see Figure 4).

The 20 Commandments of Software Packaging White Paper Page 5

 Figure 4. Macrovision’s AMS Lets You Control the Request Process
and the Packaging Workflow While Reporting Status to Users

3. Collect all Project Data before Beginning

Now that you’re ready to sit down and prepare packages, make sure
you have all the information about the package in hand before you
start. This includes information such as the basic installation
instructions, the manufacturer, support telephone numbers for the
manufacturer, target machines the package will be deployed to, items to
include or exclude in the package, and, of course, your own corporate
standards for packaging and package preparation.
A lot of this information is easily found on the Web from manufacturer
Web sites. Some of it will be included on the package request form you
create and some may come from expert users who are familiar with
what the software product can do. Knowing which machines will be
targeted will also help in later packaging stages since it will provide
information about the products the package will coexist with. Finally,
your corporate standards for packaging should be well documented and
should be part of basic training for all new packaging trainees.
One good source of information on generic and sometimes not so
generic software product packages is the Appdeploy.com Web site. This
site includes a wealth of information on packaging but perhaps its most
useful part is the packaging knowledge base. This knowledge base
includes information on more than 350 products to date.
Armed with the right information, you’ll be able to create your package
on the first try.
Using AMS, application requesters in an organization can submit
information via a centralize web interface. The interface can include
required as well as optional fields. Upload of supporting files, such as

The 20 Commandments of Software Packaging White Paper Page 6

 license agreements, templates, and instructions, can also be performed
(see Figure 5).

Figure 5. Preparing a Package Request in AMS

4. Package for Windows Installer

We’re lucky. Today, we have a standard installation system that can be
used to support the installation of all packages and all software on your
Windows systems. This standard, the Windows Installer format (also
known as MSI), provides enhanced installation management features.
A major advantage of this system is that while not all vendors have
begun to move their own installations to this format, many have and
more are moving in this direction every day. Another advantage is that
even if a software product does not adhere to this standard, it is
relatively easy to use tools such as AdminStudio to repackage
installations into this format. Finally, using this standard means your
staff only needs to be familiar with a single installation format.
Windows Installer or MSI packages provide a whole series of features:
self healing, standardization of file versioning rules, standard
customization approaches to installations, advertising through Active
Directory, and much more. In addition, if you’re running Service Pack 2
for Windows XP, you have access to version 3.0 of the Windows Installer
service. Version 3.0 is all about patching and patching support for
installed software. One great feature this brings is that you no longer
need to have access to source installations to be able to patch
applications, since Windows Installer now uses the local installation
database for the patching process.
You’ll soon find that working with MSI packages brings quite a series of
advantages to installations. Since all of your software will be self-
healing, you should have fewer help desk calls related to non-functional
software once deployed. In addition, you’ll be working with a single,

The 20 Commandments of Software Packaging White Paper Page 7

 integrated installation mechanism greatly simplifying the packaging
process overall.

5. Know When to Package

There are a lot of things you shouldn’t package—drivers, system
components, Internet Explorer installations, hotfixes, service packs,
and so on. That’s because they are either core operating system
components or they use a format that is already packaged.
Driver installations for example perform modifications at a low level on
the operating system and therefore should not be repackaged into an
MSI format. Internet Explorer also uses its own engine for installation
and customization; therefore, it should not be repackaged into an MSI
format. Hotfixes and service packs also have their own installation
format. Some of these will already be in the form of a Windows Installer
patch or MSP and need to be applied to an existing MSI to work. These
should never be repackaged into an MSI because you’ll lose access to
the original MSI features.
This doesn’t mean that you can’t include a driver installation into an
MSI as part of a complex installation, it just means that if you do, you
need to use a scripted solution that will install along with the MSI but
will not use the MSI process to support the installation.
Document and publish all exclusions to your packaging process.

6. Repackage or Customize all of Your Software Installations

Don’t rely on vendor-provided installs because defaults don’t
necessarily apply to the standards you apply in your network. Make
sure you customize all your packages. Use the proper process for this. If
the package is already in Windows Installer format, you should
customize it, but only through transforms (MSTs) that are applied to
the original commercial installation. If it isn’t in Windows Installer
format, then use a capture process to repackage it to this format.
Packages fall into three categories:
• Native Windows Installer software — This software includes any
product that includes an original MSI or meets the Designed for
Windows specification. Part of the requirement for this program is
integration with the Windows Installer service. The installation of
these products must be transformed to custom configurations for
your network. That’s because it is highly recommended to leave
original MSI installations as is and apply the modifications and
customization you require through an MST file, which applies your
own settings to the default installation during deployment.
• MSI-integrated corporate applications — New or upgraded
versions of corporate applications should be integrated with and
designed to work with the Windows Installer service. Your internal
developers must learn to work with this format. Note that these
MSIs may not require customization since they are designed for
your own environment and may therefore include all custom
settings in the original installation.

The 20 Commandments of Software Packaging White Paper Page 8

Macrovision’s • Repackaged commercial software and corporate applications —
AdminStudio Editor can All commercial software products that are not or cannot be
work with both native upgraded should be repackaged to integrate their installation with
MSI files as well as Windows Installer. You can expect that 99% of these legacy software
modify and create products can be repackaged to take advantage of Windows Installer.
MSTs. Only products such as device drivers, programs which install device
drivers or programs which make low-level changes to the operating
system will resist Windows Installer integration. In addition,
corporate applications that do not require recoding, are not being
upgraded, or cannot be reprogrammed should also be repackaged to
the Windows Installer format. In these cases, you will not require
transforms since you will use an installation capture process to
convert the legacy installation into a configured deployment using a
single MSI.
Another key factor is that software packages are no longer only for PCs;
you can and you should apply the same software packaging principles
you use for PCs to servers as well.
Make sure your packaging team follows these standards.

7. Start with a Clean System

The last thing you want to do is package garbage. The only way to
guarantee that your packages include only the contents they should is
to use clean systems to both prepare and test the package. Clean
systems give the best results because they only capture what is relevant
and do not include any untoward components.
In fact, your lab should include one copy of each target machine in the
network. It should also include disk imaging technology to speed the
process of returning the target systems to a pristine state for each test.
Clean systems give the best results because they only capture what is
relevant. Clean systems should be applied in the following manner:

The AdminStudio • Package Building — The original machines used to build

Repackager tool can be packages should be as clean as possible. This often means that
installed separately and all you need on these machines is the operating system, proper
even better, can be run OS patches and the required components from the packaging
remotely. This means tool you use. These machines should be as powerful as possible
that the packager can to help speed the creation of packages. Once a machine is
map a drive from the prepared, it should be imaged to save its pristine state. Then,
clean system to the
after each package is created and saved, the machine should be
network location with
the copy of Repackager reimaged to return it to a pristine state.
and launch it from • Package Testing — The target machines for package testing
there. In this way, the
should be as similar as possible to the actual machines the
package building
system does not have package will be running on in the network. This means
any part of including the OS, all core generic software, and any particular
AdminStudio installed software that would be residing on target systems. Once the
and stays as clean as machine is ready, it should be imaged to conserve the pristine
possible. state. It should be returned to this state each time you complete
the battery of tests on a package.
This means that you will require vast amounts of disk space on your
packaging lab server to store these hardware images and a high-speed
network to upload and download these images during packaging.

The 20 Commandments of Software Packaging White Paper Page 9

 8. Leverage Virtual Machines
Virtual machine technologies such as Microsoft Virtual PC 2004 and
Virtual Server 2005 or VMware Workstation 4.5 and GSX Server 3.1
should be part of every packaging toolkit. Virtual machines emulate
standard PCs and servers in most every way and are a lot easier to reset
to a clean state. Virtual machines even include the ability to undo
changes to their hard disks, making it very simple to return the
machine to a pristine state.
Ideally, virtual machines should be used to replace the original package
building machines. That’s because virtual machines are generic
machines, they emulate the most basic type of machine and will fully
support the package building process. In addition, they can be used to
perform initial package testing, but to fully test packages for operation
in your network, you should use real package testing machines.

Using the VMware There are two ways to use virtual machines. The first lets you use the
Repackaging Wizard in undo capability each vendor offers to simply not save any of the
AdminStudio, you can changes you may have applied to a virtual machine hard disk file. This
select an available is very easy and lets you create a package, save the package, and
VMware virtual simply close the machine removing any disk changes. The second is
machine, and then based on the very nature of virtual machines. VMs are in reality only
Repackager files on your hard disk drive. That means that before you perform a
automatically launches
test, you can copy these files to a new folder to save a copy of the
the selected operating
system within a pristine machine. Then, you prepare the package, save it, and simply
VMware session. For delete the files making up the machine you just used. Copy the original
the Repackager to files again to create another package. This is often the simplest way to
work, both VMware and use VMs.
VMware virtual
machines have to be But as you can see, VMs will also require a lot of disk space since each
found on the packaging virtual machine can be an average of 4 GB in size. They should be
workstation. stored on the server. High-speed networking should be in place to help
speed the machine copying process. In addition, the machines used to
run these VMs for packaging should have lots of RAM (at least 1 GB)
and lots of disk space.
AdminStudio also includes special hooks that let you take advantage of
virtual machines directly through the IPE.

9. Use Installation Monitoring to Repackage

There are several ways to repackage products. One of the most popular
is the snapshot approach. Basically, this technique inventories what is
on a system before and after an installation, capturing system
modifications performed by the installation by identifying the
differences.
A second and much more powerful approach is installation monitoring.
This is a fast and accurate technique that actually monitors what the
system does during the installation. Because of this, it is more efficient
and can ensure better results than the before and after snapshot.
In AdminStudio, you have the option to choose the method you would
like to use in one of the first panels in the Repackaging Wizard (see
Figure 6).

The 20 Commandments of Software Packaging White Paper Page 10

 Figure 6. Choosing the Repackaging Method in AdminStudio

10. Use a Custom Package Template

As you work through packages, you’ll see that they mostly fit into a
series of categories. Each category will include repetitive tasks and will
require the application of corporate packaging standards. The best way
to ensure these standards are always applied is to capture them into a
packaging template—a model that is applied to the package at the onset
of its creation. Templates are powerful tools because they allow you to
capture and include expert packaging knowledge into them, facilitating
the initial packaging process for junior packagers and freeing expert
packagers for more complex packaging tasks.
To use an Application Template when repackaging applications in
AdminStudio:

1. Launch AdminStudio Editor and create a project that includes

the desired default properties, dialogs, features, and
components.

2. Save the project as an InstallShield Template (*.ist).

3. Use the Repackager to capture the information about an

application and at the build step, point to the template
previously created (see Figure 7).

The 20 Commandments of Software Packaging White Paper Page 11

 Figure 7. Using a Custom Template in AdminStudio

11. Use a Global Exclusion List

There are a lot of components that should never be included in any
package—temporary files, system files, INI files, registry keys and so on.
These components must be part of an exclusion list that is applied to all
packages as they are created. If you use a proper and complete global
exclusion list, it will help reduce the time you’ll spend removing
unwanted and unnecessary data from the packages you create.
To use a Repackaging Exclusion List when repackaging applications
with AdminStudio:
1. Launch the Repackager
2. Select Tools | Global Exclusions Editor and edit the list of files
and registry entries to be excluded during the capture process
(see Figure 8).

Figure 8. Adding Exclusions Through the Global Exclusions Editor

The 20 Commandments of Software Packaging White Paper Page 12

 While the exclusions that are already part of AdminStudio are
comprehensive, there are always some particularities that are directly
related to how your network environment, workstation builds and
packages are set up that must be taken into consideration.
In addition, one of the best tools that can be used in support of
exclusion lists is iTripoli Package Cleaner (see Commandment number
1 above). Package Cleaner is a product that is designed to examine
package contents and clearly identify if components or settings should
be included in a package. The best part of Package Cleaner is that it
outlines why you would not or should not include these components in
your package. Using Package Cleaner is like having a packaging expert
on the premises. In addition, any exclusion it identifies can be added to
the exclusions you work with in AdminStudio making your future
packages even better.

12. Know Your Packages

When preparing a package, you should extract as much information
from the package as possible. Integrated packaging environments will
include special tools that are designed to help you gain a lot more
information from a package as you prepare it. For example,
AdminStudio includes two tools that can help in this situation.
SmartScan is a tool that will automatically identify any files that are
required for the package to operate but are not included in the package.
SmartScan will add these files in a color coded format so you know
what is required for the package to function properly. It also includes
the Setup Intent Wizard which will also help identify files that are
related to the package but are not included in it. Both tools let you
discover as much information about your package as possible.
AdminStudio’s SmartScan will become visible at the end of a
repackaging process if additional information can be collected from the
InstallScript-based setup files. At that time, the packager will have the
option to include additional files and feature hierarchy information (see
Figure 9).

The 20 Commandments of Software Packaging White Paper Page 13

 Figure 9. Using SmartScan to Provide Additional Information on
the Package
To work with the Setup Intent Wizard, select the “Scan for setup intent”
link in the Repackager integrated development environment (IDE). The
wizard will scan for additional file dependencies that may not have been
installed and display the results (see Figure 10).

Figure 10. Using the Setup Intent Wizard to identify additional file
dependencies

The 20 Commandments of Software Packaging White Paper Page 14

 13. Use a System Construction Model
Another key method to help reduce the complexity of creating packages
is to use a system construction model. This means that you build a core
system and add all generic capabilities to this system. This image or
“system stack” is then applied to all PCs or servers. From then on, you
create groups of applications that can be deployed to groups of users
identified through the role they play in your organization.
The system stack basically identifies the components, common and
particular, that you’ll find on different systems in your network. This
means a couple of things. First, you have to find the common elements
to all systems, either servers or PCs, and fit them together. This should
include the operating system, service packs, utilities, office automation
products, graphics file viewers, antivirus, document viewers, and so on.
Once this is done, you can package this common stack into images that
can be deployed as a blob through the network.
AdminStudio supports the system stack concept through the capture of
Operating System images:
1. Launch the OS Snapshot Wizard and name the image to be
captured (see Figure 12).
Figure 11. A System Stack
Example, in this case, the
Accounting Stack

Figure 12. Capturing an Operating System

2. The data on the system will be captured and saved (see Figure
13). The OS Snapshot Wizard can be run remotely, so no pieces
of AdminStudio are required on the clean reference system
being captured. After it is saved, it can be imported to the
Application Catalog.

The 20 Commandments of Software Packaging White Paper Page 15


AdminStudio lets you group
packages according to audience
when detecting and repairing
conflicts.
The 20 Commandments of Software Packaging White Paper
Figure 13. An Operating System Capture in Progress
Once you have the system stack in place, you’ll have to learn to manage
and maintain it as a single object. In real life, three comprehensive
updates per year are sufficient. Of course, you’ll also have to provision
for emergency update deployments. Remember that each time you
change the system stack, you’ll have to re-capture it with AdminStudio.
14. Create Package Catalogs
Once you’re using the system stack concept, you’ll also need to identify
special collections or catalogs of software packages that target specific
operational groups within your network. For example, accountants may
require a given set of tools over and above the common set, while sales
staff will require another. Within the accounting department, you may
have employees that focus on reports and others that focus on data
collection, so these users will need additional tools over and above the
accounting stack. An example of the complete system stack approach is
displayed in Figure 11 above.
If you do this, you’ll soon discover that constructing systems based on
such a strategy greatly reduces packaging efforts because it reduces the
number of programs that must coexist on any system. That’s because a
good portion of systems only require the common stack. This makes
these systems the easiest to manage. In addition, by combining other
programs into groups, you should be able to reduce the complexity of
each system. These groups often include no more than 5 to 30
individual programs depending on the target audience.
It is most likely that you’ll end up with certain programs that have very
small target audiences or that have audiences that cannot be grouped
together. These will not properly fit into any stack, but their number
Page 16
 should be small and include no more than five (5) percent of the
software in your networks. They should still be packaged properly to
enable centralized distribution and automated installation as well as
proper documentation.
Using a system stack construction method along with application
catalogs will help your packaging and software management efforts in
several ways. First, it simplifies system support because you know what
to expect on each system. Second, it simplifies new machine
deployments because the common stack is captured in a disk image.
Third, it simplifies software deployment since you can group the
software stack for any particular audience and send it off as one single
deployment to target machines. Fourth, it simplifies the quality control
of your packages since you only need to test packages on the stack it is
part of, not with all the software in your network.
AdminStudio supports this concept in the Application Catalog.
Applications can be imported to the database directly into the desired
group, or they can be moved from one group to another as though in a
file system (see Figure 14).

Figure 14. Working with Application Catalogs in AdminStudio

15. Perform Conflict Detection

One of the major reasons why you should package software with the
MSI format is because the Windows Installer service includes special
features that can manage software conflicts “on the fly”. But, this does
not eliminate the need to test all packages for conflicts against all of the
other software that will coexist on a system.
When testing for conflicts, you should use the internal validation tests,
check against internal consistency evaluation (ICE) rules, and check
cross-application consistency evaluator (ACE) rules. By using the IPE to

The 20 Commandments of Software Packaging White Paper Page 17

 build application catalogs and group applications within this catalog
(see #14) the time it takes to detect conflicts will be reduced.
A well-designed IPE will automatically resolve conflicts through the use
of rules. It should therefore include a comprehensive set of built-in
rules, but because the purpose of software packaging is to configure
software according to corporate standards that may or may not be the
same as everyone else’s, it should support the creation of custom rules.
This way you can control every idiosyncrasy of the packaging process.
Conflict detection should cover every aspect the package and should
compare each of the elements that make it up. This includes:
• Product Components — each product component is designed
to support the individual features of the product.
• Product Files — the individual files that make up the product;
in many cases, this focuses on dynamic link libraries (DLL) and
executable (EXE) files.
• Registry Entries — the registry settings that support the
operation of the product.
• Shortcuts and INI Files — the tools to access the product once
installed, and the settings that are applied at product launch,
though most Windows Installer products rarely use initialization
files.
• ODBC Resources — the components that link the product to
back-end databases if required.
• NT Services — the integrated services that are designed to
operate in the background; these apply mostly to server
applications, though “NT” is an outdated moniker.
• File Extensions — the elements that link files created by the
product to the product itself; for example, early versions of
Microsoft Systems Management Server used the PDF extension
for package definition files, when Adobe Acrobat used the same
extension for the portable document format.
• Product Properties — the settings that identify the product on
the machine where it is installed.
While some of these can cause minor irritations—shortcuts, INI files,
and properties—others can cause major conflicts and even damage
existing products on the target systems. This is why conflicts must be
detected and repaired. Figure 15 illustrates the conflict detection
process.

The 20 Commandments of Software Packaging White Paper Page 18

 Figure 15. Detecting Conflicts against a System Stack

By testing packages against the groups of products that should coexist

on a target system, and only those products, you can improve the
quality of your packages without having to overly increase the
packaging workload. This greatly reduces the impact of conflict
detection and resolution on the packaging process because there is no
requirement to verify or test the cohabitation of programs contained in
different groups since they are not likely to ever coexist on the same
system. For example, an accounting reporting utility should be tested
against the accounting stack, but there is no reason to test it against
the IT administration stack since there should never be any reason to
install it in this stack.
To detect conflicts in AdminStudio, you’ll need the Conflict Wizard.
1. The Conflict Wizard can be launched for any application inside
or outside the Application Catalog.
2. it gives you the ability to select the Groups or individual
applications in the System Stack that you want to test against
(see Figure 16).

The 20 Commandments of Software Packaging White Paper Page 19

 Figure 16. Identifying Which Packages to Detect Conflicts Against
in AdminStudio
3. You then select the specific tests you would like to run against
the chosen System Stack elements.

Figure 17. Identifying the Tests to Run

The 20 Commandments of Software Packaging White Paper Page 20

 The results of all conflict detection tests are preserved in the
Application Catalog for that application and can be used for further
application testing as the number of packages you prepare grows.

16. Test as a User

Too many people forget that they are administrators with full rights on
a machine when they prepare a package. Because of this, a lot can go
wrong when it gets to the user. Make sure you always work with two
accounts, one with administrative rights and another with normal user
rights. Then use both the Run As command in Windows to test the
application and the IPE’s capability to test for behavior in locked-down
environment before you deploy the package to users with limited rights.
In addition, AdminStudio’s QualityMonitor tool provides this
functionality.
1. Launch QualityMonitor and select an application to test from
the list of installed MSI packages.
2. Choose the “Lockdown and Runtime Tests” option, pick an EXE
to test, then click on “Run As” (see Figure 18).

Figure 18. Using QualityMonitor to Test as a User

3. Enter credentials to test as a common user, rather than as an
administrator (see Figure 19).
This will let you ensure that the application will run properly when
operated by people who only have common user rights and
permissions.

The 20 Commandments of Software Packaging White Paper Page 21

 Figure 19. QualityMonitor Calls Upon the Generic Windows Run As
Feature to Perform the Tests

17. Perform Deployment Testing

Installing a package in a laboratory environment—the environment
where you prepare the package—often means pulling the package from
a network share. Yet, when a package is delivered to users, it tends to
be deployed by a remote software delivery system. A lot can go wrong
when this deployment isn’t tested before the package goes live.
Deployed packages are most often installed in the background through
a silent installation. In addition, deployed packages require specific
conditions to be met on target systems for the deployment to work
properly. With an IPE such as AdminStudio, you can create
instrumented packages—packages that include all of the behavior of an
installation, but which do not modify target systems—and test them
with small sample target groups. This way, you’ll know whether target
computers are ready for the package or not and increase the success
rate or your deployments.
In AdminStudio, the Predeployment Test feature creates test packages
that will run tests on the target system, but will not install anything.
1. Once a package has been selected, a number or tests can be
included. The tests you include are at your discretion (see
Figure 20).

The 20 Commandments of Software Packaging White Paper Page 22

 Figure 20. Choosing the Tests to Run in Predeployment Test
2. The instrumented package can be deployed to any number of
live, end-user systems in the field, and the results of the tests
are reported back to a central location for viewing through a
Web interface (see Figure 21).

Figure 21. Viewing the Results of Predeployment Testing

18. Document Your Changes

It’s very important to document how packages are made, but as you
know, documentation is often not one of the strongest points of your
technicians. Nevertheless, you need to document changes in packages
as they are prepared, otherwise your packagers may well be repeating
the same tasks or worse, performing conflicting tasks as they prepare
packages. If your team hates writing, use the IPE’s capabilities to
capture all of the packaging operations and testing data. This will
greatly reduce the amount of documentation your technicians actually
need to perform.

The 20 Commandments of Software Packaging White Paper Page 23

 Once all testing and conflict detection is done, you need to perform a
final quality assurance on the package. Ideally, the person performing
this final QA activity will be different from the person who originally
packaged the product. This will provide you with a better and more
thorough verification. Don’t forget to complete all documentation about
this package at this stage. Too many organizations try to save time by
leaving documentation until after the product is deployed only to find
out some critical component was missed and they have no means to
find out how to repair it.

19. Patch Your Packages

Patching is a fact of life today. Few software products can avoid being
patched. Make sure you identify any required patches for the packages
you prepare and if possible, make sure they are applied before the
package is deployed. You’ll find that it’s a lot easier to patch in the
packaging lab than it is to patch once a package is deployed.
Use your IPE to help determine the impact of patches before you apply
them. Include the patches you intend to deploy inside your application
catalogs. This will let you quickly identify which applications can be
affected by the patch and greatly reduce the time require to test a patch
before deployment.
AdminStudio integrates with Macrovision’s Patch Impact Manager, a
tool that lets you identify available patches and test them against
products you have packaged. It does so through the following process:
1. Collect all the latest Microsoft patch data using the patch
retrieval functionality.
2. Import the patches of interest into the Application Catalog (see
Figure 22).

Figure 22. Importing Selected Patches into the Application Catalog

in AdminStudio

The 20 Commandments of Software Packaging White Paper Page 24

 3. Select one or more patches, run the Patch Analysis Wizard, and
then select the applications and OS Snapshots to use in the
analysis (see Figures 23 and 24).

Figure 23. Selecting the Patches to Test

4. The contents of the patches are compared to the contents of the
chosen applications and OS Snapshots, as well as with the
static file dependencies that are automatically pulled from the
applications.

Figure 24. Identifying the Applications and OS Snapshots Against

Which to Run the Patch Tests

The 20 Commandments of Software Packaging White Paper Page 25

 5. The results are displayed and saved in Web-based reports (see
Figure 25).

Figure 25. Viewing the Patch Testing Reports

The great advantage of a patch impact testing tool like Patch Impact
Manager is that it helps you target which applications are impacted by
the patch. You can then perform additional patch testing on those
applications that share file or registry information with the new patch,
making the patch testing process much more efficient.

20. Manage Packaging as a Project

Software packaging is a process that moves through specific steps, one
after the other. Like all processes, this activity should be managed as a
project with sound project management practices. Your IPE should offer
strong project management support and should help you keep track of
project status at all times. This way, you’ll not only create solid
packages that require little post deployment support, but you’ll do it as
efficiently as possible.
AdminStudio, combined with Macrovision’s AMS provide key features in
support of packaging project management. The first relies on the
reports you can generate with AdminStudio. These reports relate to
each package and provide comprehensive information on the package
(see Figure 26).

The 20 Commandments of Software Packaging White Paper Page 26

 Figure 26. Create and Archive Application Reports in AdminStudio
In addition, AMS supplements AdminStudio’s capabilities by tracking
the status of each package as it goes through the preparation process.
This helps view each and every packaging request as a project. AMS lets
you generate reports on the progress of all applications in each project
(See Figure 27).

Figure 27. Use AMS Along with AdminStudio to Track Project

Status Throughout the Packaging Process

The 20 Commandments of Software Packaging White Paper Page 27

Conclusion
There you have it: 20 Commandments that should go a long way
towards making your packages cleaner and more stable, reducing the
issues and problems that may arise when they are deployed. Use this
practical advice to make your packages better, cleaner, and more stable.
Many of the commandments are directly supported by Integrated
Packaging Environments as outlined in this paper. Others are simply
standards you need to put in place.
Learn them all and make them part of your packaging strategy today.
You’ll see that together with the proper IPE—in this case
AdminStudio—these commandments will help you gain complete
control over the total cost of ownership of software in your network.

The 20 Commandments of Software Packaging White Paper Page 28