More Software Packaging Rules to Live By
The final part in a series of articles on ways to guarantee a smooth deployment of software and applications across your enterprise.
Most system administrators who have been packaging software will have
realized that 10 commandments are not enough to cover software packaging.
That’s why we bring you 10 more commandments. Along
with the first set
, these commandments will help you make sure that
your packages work the first time, every time. If you want to reach this
goal, then read on and see what Macrovision, makers of AdminStudio—a
comprehensive integrated packaging environment (IPE)—and Nelson and
Danielle Ruest, independent packaging consultants, suggest to make both
your packages and your packaging experience better.
1. 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 as you create them. This global exclusion list
will complement the packaging templates you use to generate your packages.
2. Know Your Packages
When preparing a package, you should extract as much information from
the package as possible. IPEs 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 part of the package, but were not collected during the standard
repackaging process. SmartScan will add these files in a color coded format
so you know what other files can optionally be included. It also includes
the Setup Intent Wizard which will also help identify files that are related
to the package through file dependencies but are not included in it. Both
tools let you discover more information about your package.
3. 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.
Once applied, it must be managed and maintained as a single object. In
real life, three comprehensive updates per year are sufficient. Of course,
you also have to provision for emergency update deployments.
Want to get more tips on software packaging?
Attend a FREE Web Seminar
"The 20 Commandments of Software Packaging:
Practical Application of Software Packaging Best Practices"
When: February 16 at 1 p.m. Central Standard
Time, hosted by Nelson Ruest and Macrovision's Steve
Registrants will also receive the "20 Commandments
of Software Packaging" whitepaper for Free!
For information and registration CLICK HERE:
4. Create Package Catalogs
Once you have your system stack in place, you can them move on to create
collections or catalogs of applications that can be deployed to groups
of users that can be identified through the role they play in your organization.
For example, one group could be financial analysts who require special
financial software along with the generic office automation capabilities
provided by the core system stack.
Using this type of system construction model will help reduce the time
it takes to create packages because it reduces the number of applications
with which each package must coexist on a system.
5. 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 against
cross-application conflict evaluator (ACE) rules. By using the IPE to
build application catalogs and group applications within this catalog,
the time it takes to detect conflicts will be reduced.
6. 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.
7. 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 send the test results back to a central web
site—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.
8. Document Your Changes
It’s very important to document how packages are made, but
as you know, documentation is often not 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.
9. 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
10. 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.
There you have it: Another 10 commandments that tally up to a
total of twenty. Altogether, they will go a long way towards helping you
make clean packages that always work. Include all 20 into your everyday
packaging approaches and begin to reap the benefits of proper packaging.
Make sure the IPE you use lets you take advantage of each and every one
of these commandments.
Danielle Ruest and Nelson Ruest, both Microsoft MVPs, are IT professionals focused on technologies futures. They are authors of multiple books, including "Microsoft Windows Server 2008: The Complete Reference" (McGraw-Hill Osborne Media, 2008), which focuses on building virtual workloads with Microsoft's new OS.