the20 commandments - jira – atlassian20... · figure 1 outlines the tools and structure you...

Nelson Ruest & Danielle Ruest

Sponsored by

20The

CommandmentsSoftware Packaging

of

PRACTICAL IMPLEMENTATION OF SOFTWARE PACKAGING BEST PRACTICES

20The

CommandmentsSoftware Packaging

of

PRACTICAL IMPLEMENTATION OF SOFTWARE PACKAGING BEST PRACTICES

The 20 Commandments of Software Packaging White Paper Page ii

Table of Contents

Introduction............................................................................................ 1

Working with the 20 Commandments................................................... 21. Prepare your Packaging Environment....................................... 22. Use Proper Workflows ................................................................ 33. Collect all Project Data before Beginning .................................. 64. Package for Windows Installer................................................... 65. Know When to Package ............................................................. 76. Repackage or Customize all of Your Software Installations ..... 77. Start with a Clean System......................................................... 88. Leverage Virtual Machines ........................................................ 99. Use Installation Monitoring to Repackage ................................ 910. Use a Custom Package Template ............................................ 1011. Use a Global Exclusion List..................................................... 1112. Know Your Packages................................................................ 1213. Use a System Construction Model .......................................... 1314. Create Package Catalogs.......................................................... 1515. Perform Conflict Detection....................................................... 1616. Test as a User .......................................................................... 2017. Perform Deployment Testing ................................................... 2118. Document Your Changes......................................................... 2219. Patch Your Packages................................................................ 2320. 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 theirnetwork, they’re much better off creating a new, company-specific (repackaged) image of anapplication before releasing it. Unfortunately, not everyone uses the same set of rules for softwarepackaging and, evidently, not everyone gets the same results. Macrovision, makers ofAdminStudio—a comprehensive integrated packaging environment (IPE)—and authors DanielleRuest and Nelson Ruest, both independent packaging consultants, have come up with the 20commandments of software packaging. This is specific, practical advice on how to best packagesoftware. This white paper will take you through each step in the packaging process and providepractical advice on how to create your packages according to the principles outlined here. You’llcome away with a complete process that can help ensure the quality of your packages. This whitepaper aims to answer your questions and make sure that you learn how to gain the full benefitsproper software packaging can bring. In addition, you can view an accompanying Webcast on thetopic for further information.

About the Authors

Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migrationplanning, software management and architecture design. They are authors of multiple books, notablytwo books published by McGraw-Hill Osborne, “Windows Server 2003: Best Practices for EnterpriseDeployments”, 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, ISBN0-201-73487-7. They have extensive experience in software packaging and managing large packagingprojects.

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

i

The 20 Commandments of Software Packaging White Paper Page 1

Introduction

System administrators have been packaging software ever since therehave been microcomputers. That’s because most system administratorshave discovered that they’re much better off creating a new, company-specific (repackaged) image of an application before releasing it into thenetwork. Unfortunately, not everyone uses the same set of rules forsoftware packaging and, evidently, not everyone gets the same results.One thing is certain, if you manage your software packaging processesin the right way, you will enjoy a lower total cost of ownership for yourPCs. But how can you guarantee this result?

Macrovision, makers of AdminStudio—a comprehensive integratedpackaging environment (IPE)—and authors Danielle Ruest and NelsonRuest, both independent packaging consultants, have come up withthe 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 propersoftware packaging can bring.


Working with the 20 Commandments

Each of the commandments deals with a particular aspect ofpackaging. Taken as a whole, they cover the entire packaging processand 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 packagingenvironment itself. Keep in mind that a software packagingenvironment or laboratory should be architected, just like any otherenvironment in your network. This means you’ll need to put the propertools in place—tools such as an installation repository for all sourcesoftware installations, a software repository for all packagedinstallations as well as proper troubleshooting tools. In addition, use aproper database system to store all package information. Most softwarepackaging tools come with the Microsoft SQL Server Desktop Engine(MSDE) or Microsoft Access runtime databases, but these tools havelimitations that can impact your packaging environment in a negativemanner. The most important of these is the size limitation on thedatabase. If your packaging database exceeds these size limitations,you could stand a chance of losing all packaging data. You certainlydon’t want to find yourself in this situation. Treat your packaging dataas corporate data and implement a commercial database system withproper backup strategies.

Finally, use representative systems to prepare and test your packagesand implement proper re-imaging mechanisms to restore thesemachines to pristine states.

Figure 1 outlines the tools and structure you should use in yourpackaging laboratory. This addresses only a single packaging lab. If youuse distributed packaging teams, you’ll want to replicate the samearchitecture in each location and ensure your software packagingdatabases 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 packagingenvironment, in this case Macrovision’s AdminStudio®

o Software deployment technologies for deployment testing

o Directory services which emulate your productionnetwork

• Operator workstations aimed at documentation andresearch—these workstations are connected to the Internet

Macrovision’sAdminStudioTry a fully functional,free evaluation ofAdminStudio atwww.installshield.com/products/adminstudio/eval.asp

http://www.installshield.com/products/adminstudio/


• Workstations, called clean machines, that are used for packagepreparation

• Testing workstations that are representative of the machines inyour production network

• Virtual machine technology that can be used to replace thephysical clean machines

• Packaging utilities such as SysInternals Regmon—a tooldesigned to monitor changes to the registry—and Filemon—atool designed to monitor file activity when programs arerunning; both tools are free

• Package Quality Control utilities such as iTripoli PackageCleaner—a tool that verifies package contents and acts as aninternal knowledge base telling you if and why you should orshouldn’t include specific components in the package

• A machine imaging tool that lets you restore physical machinesto a pristine state each time a project is complete

• Backup software and a tape library to protect your packagingdata

Figure 1. The Packaging Environment

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

2. Use Proper Workflows

There’s a lot to be said for getting the right people to do the right jobduring the packaging and testing process. Even if your packaging teamis a team of one, you’ll need to make sure you use a step-by-stepprocess for packaging and that you follow it to a tee.

If your team includes more than one person, all the better, but thenyou’ll need to assign a lab coordinator to oversee all preparationactivities. In addition, you’ll want to make sure that your testers are not

http://www.sysinternals.com/ntw2k/source/regmon.shtml

http://www.sysinternals.com/ntw2k/source/filemon.shtml

http://www.itripoli.com/ipc.asp

http://www.itripoli.com/ipc.asp


the same as your packagers. This will help improve testing processes.There’s nothing like a fresh pair of eyes to catch omissions andunexpected items.

The best way to make sure you have the right people performing theright tasks is to look at the packaging process itself. In the packagingprocess (see Figure 2), you begin with a request for a new or upgradedproduct. This request comes into the packaging lab and is processed bythe lab coordinator and the packaging project manager. The formerassigns resources to the project and the latter manages the projectactivities. The package is assigned to a team member who may even bea junior packager since this process is fairly simple and repetitive. Thepackager will begin by discovering package features. Once this is done,the next step is preparing the package itself. When the initial package isready, it moves to testing and conflict detection. If your team is largeenough, you might consider separating the testing and conflictdetection position from packaging and dedicating this role to someonewith more experience, since testing is more complex and requires moreknowledge, a sort of packaging subject matter expert, if you will. Thesame goes for quality assurance (QA). Since it is a key part of theprocess, 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 withthe software product itself. There’s nothing like a fresh pair ofknowledgeable eyes when it comes to QA. The package is then releasedfrom the laboratory. This is usually the responsibility of the projectmanager. The release is passed on to the deployment team and oncedeployed, the package moves on to the maintenance team until it isretired from the network. The retirement may also be cause for a newrequest to be initiated by users. The packaging process then comes fullcircle.

Figure 2. The Packaging Process

This means that your packaging team should include the followingroles:

• Lab coordinator• Project manager• Packaging subject matter expert


• 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 asolid relationship with the team. Of course, depending on the size ofyour team and the number of packages to manage, you may add rolessuch as administration and research. Make sure you document andpublish this workflow for all team members to see.

Within AdminStudio, packaging steps can be outlined to establishstandards (see Figure 3).

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

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


Figure 4. Macrovision’s AMS Lets You Control the Request Processand 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 sureyou have all the information about the package in hand before youstart. This includes information such as the basic installationinstructions, the manufacturer, support telephone numbers for themanufacturer, target machines the package will be deployed to, items toinclude or exclude in the package, and, of course, your own corporatestandards for packaging and package preparation.

A lot of this information is easily found on the Web from manufacturerWeb sites. Some of it will be included on the package request form youcreate and some may come from expert users who are familiar withwhat the software product can do. Knowing which machines will betargeted will also help in later packaging stages since it will provideinformation about the products the package will coexist with. Finally,your corporate standards for packaging should be well documented andshould be part of basic training for all new packaging trainees.

One good source of information on generic and sometimes not sogeneric software product packages is the Appdeploy.com Web site. Thissite includes a wealth of information on packaging but perhaps its mostuseful part is the packaging knowledge base. This knowledge baseincludes information on more than 350 products to date.

Armed with the right information, you’ll be able to create your packageon the first try.

Using AMS, application requesters in an organization can submitinformation via a centralize web interface. The interface can includerequired as well as optional fields. Upload of supporting files, such as

http://www.appdeploy.com/packages/index.asp


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 beused to support the installation of all packages and all software on yourWindows systems. This standard, the Windows Installer format (alsoknown as MSI), provides enhanced installation management features.

A major advantage of this system is that while not all vendors havebegun to move their own installations to this format, many have andmore are moving in this direction every day. Another advantage is thateven if a software product does not adhere to this standard, it isrelatively easy to use tools such as AdminStudio to repackageinstallations into this format. Finally, using this standard means yourstaff 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, standardcustomization approaches to installations, advertising through ActiveDirectory, and much more. In addition, if you’re running Service Pack 2for Windows XP, you have access to version 3.0 of the Windows Installerservice. Version 3.0 is all about patching and patching support forinstalled software. One great feature this brings is that you no longerneed to have access to source installations to be able to patchapplications, since Windows Installer now uses the local installationdatabase for the patching process.

You’ll soon find that working with MSI packages brings quite a series ofadvantages to installations. Since all of your software will be self-healing, you should have fewer help desk calls related to non-functionalsoftware once deployed. In addition, you’ll be working with a single,


integrated installation mechanism greatly simplifying the packagingprocess overall.

5. Know When to Package

There are a lot of things you shouldn’t package—drivers, systemcomponents, Internet Explorer installations, hotfixes, service packs,and so on. That’s because they are either core operating systemcomponents or they use a format that is already packaged.

Driver installations for example perform modifications at a low level onthe operating system and therefore should not be repackaged into anMSI format. Internet Explorer also uses its own engine for installationand customization; therefore, it should not be repackaged into an MSIformat. Hotfixes and service packs also have their own installationformat. Some of these will already be in the form of a Windows Installerpatch or MSP and need to be applied to an existing MSI to work. Theseshould never be repackaged into an MSI because you’ll lose access tothe original MSI features.

This doesn’t mean that you can’t include a driver installation into anMSI as part of a complex installation, it just means that if you do, youneed to use a scripted solution that will install along with the MSI butwill 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’tnecessarily apply to the standards you apply in your network. Makesure you customize all your packages. Use the proper process for this. Ifthe package is already in Windows Installer format, you shouldcustomize it, but only through transforms (MSTs) that are applied tothe original commercial installation. If it isn’t in Windows Installerformat, then use a capture process to repackage it to this format.

Packages fall into three categories:

• Native Windows Installer software — This software includes anyproduct that includes an original MSI or meets the Designed forWindows specification. Part of the requirement for this program isintegration with the Windows Installer service. The installation ofthese products must be transformed to custom configurations foryour network. That’s because it is highly recommended to leaveoriginal MSI installations as is and apply the modifications andcustomization you require through an MST file, which applies yourown settings to the default installation during deployment.

• MSI-integrated corporate applications — New or upgradedversions of corporate applications should be integrated with anddesigned to work with the Windows Installer service. Your internaldevelopers must learn to work with this format. Note that theseMSIs may not require customization since they are designed foryour own environment and may therefore include all customsettings in the original installation.


• Repackaged commercial software and corporate applications —All commercial software products that are not or cannot beupgraded should be repackaged to integrate their installation withWindows Installer. You can expect that 99% of these legacy softwareproducts can be repackaged to take advantage of Windows Installer.Only products such as device drivers, programs which install devicedrivers or programs which make low-level changes to the operatingsystem will resist Windows Installer integration. In addition,corporate applications that do not require recoding, are not beingupgraded, or cannot be reprogrammed should also be repackaged tothe Windows Installer format. In these cases, you will not requiretransforms since you will use an installation capture process toconvert the legacy installation into a configured deployment using asingle MSI.

Another key factor is that software packages are no longer only for PCs;you can and you should apply the same software packaging principlesyou 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 toguarantee that your packages include only the contents they should isto use clean systems to both prepare and test the package. Cleansystems give the best results because they only capture what is relevantand do not include any untoward components.

In fact, your lab should include one copy of each target machine in thenetwork. It should also include disk imaging technology to speed theprocess of returning the target systems to a pristine state for each test.

Clean systems give the best results because they only capture what isrelevant. Clean systems should be applied in the following manner:

• Package Building — The original machines used to buildpackages should be as clean as possible. This often means thatall you need on these machines is the operating system, properOS patches and the required components from the packagingtool you use. These machines should be as powerful as possibleto help speed the creation of packages. Once a machine isprepared, it should be imaged to save its pristine state. Then,after each package is created and saved, the machine should bereimaged to return it to a pristine state.

• Package Testing — The target machines for package testingshould be as similar as possible to the actual machines thepackage will be running on in the network. This meansincluding the OS, all core generic software, and any particularsoftware that would be residing on target systems. Once themachine is ready, it should be imaged to conserve the pristinestate. It should be returned to this state each time you completethe battery of tests on a package.

This means that you will require vast amounts of disk space on yourpackaging lab server to store these hardware images and a high-speednetwork to upload and download these images during packaging.

Macrovision’sAdminStudio Editor canwork with both nativeMSI files as well asmodify and createMSTs.

The AdminStudioRepackager tool can beinstalled separately andeven better, can be runremotely. This meansthat the packager canmap a drive from theclean system to thenetwork location withthe copy of Repackagerand launch it fromthere. In this way, thepackage buildingsystem does not haveany part ofAdminStudio installedand stays as clean aspossible.


8. Leverage Virtual Machines

Virtual machine technologies such as Microsoft Virtual PC 2004 andVirtual Server 2005 or VMware Workstation 4.5 and GSX Server 3.1should be part of every packaging toolkit. Virtual machines emulatestandard PCs and servers in most every way and are a lot easier to resetto a clean state. Virtual machines even include the ability to undochanges to their hard disks, making it very simple to return themachine to a pristine state.

Ideally, virtual machines should be used to replace the original packagebuilding machines. That’s because virtual machines are genericmachines, they emulate the most basic type of machine and will fullysupport the package building process. In addition, they can be used toperform initial package testing, but to fully test packages for operationin your network, you should use real package testing machines.

There are two ways to use virtual machines. The first lets you use theundo capability each vendor offers to simply not save any of thechanges you may have applied to a virtual machine hard disk file. Thisis very easy and lets you create a package, save the package, andsimply close the machine removing any disk changes. The second isbased on the very nature of virtual machines. VMs are in reality onlyfiles on your hard disk drive. That means that before you perform atest, you can copy these files to a new folder to save a copy of thepristine machine. Then, you prepare the package, save it, and simplydelete the files making up the machine you just used. Copy the originalfiles again to create another package. This is often the simplest way touse VMs.

But as you can see, VMs will also require a lot of disk space since eachvirtual machine can be an average of 4 GB in size. They should bestored on the server. High-speed networking should be in place to helpspeed the machine copying process. In addition, the machines used torun 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 ofvirtual machines directly through the IPE.

9. Use Installation Monitoring to Repackage

There are several ways to repackage products. One of the most popularis the snapshot approach. Basically, this technique inventories what ison a system before and after an installation, capturing systemmodifications performed by the installation by identifying thedifferences.

A second and much more powerful approach is installation monitoring.This is a fast and accurate technique that actually monitors what thesystem does during the installation. Because of this, it is more efficientand can ensure better results than the before and after snapshot.

In AdminStudio, you have the option to choose the method you wouldlike to use in one of the first panels in the Repackaging Wizard (seeFigure 6).

Using the VMwareRepackaging Wizard inAdminStudio, you canselect an availableVMware virtualmachine, and thenRepackagerautomatically launchesthe selected operatingsystem within aVMware session. Forthe Repackager towork, both VMware andVMware virtualmachines have to befound on the packagingworkstation.


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 aseries of categories. Each category will include repetitive tasks and willrequire the application of corporate packaging standards. The best wayto ensure these standards are always applied is to capture them into apackaging template—a model that is applied to the package at the onsetof its creation. Templates are powerful tools because they allow you tocapture and include expert packaging knowledge into them, facilitatingthe initial packaging process for junior packagers and freeing expertpackagers for more complex packaging tasks.

To use an Application Template when repackaging applications inAdminStudio:

1. Launch AdminStudio Editor and create a project that includesthe desired default properties, dialogs, features, andcomponents.

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

3. Use the Repackager to capture the information about anapplication and at the build step, point to the templatepreviously created (see Figure 7).


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 anypackage—temporary files, system files, INI files, registry keys and so on.These components must be part of an exclusion list that is applied to allpackages as they are created. If you use a proper and complete globalexclusion list, it will help reduce the time you’ll spend removingunwanted and unnecessary data from the packages you create.

To use a Repackaging Exclusion List when repackaging applicationswith AdminStudio:

1. Launch the Repackager

2. Select Tools | Global Exclusions Editor and edit the list of filesand registry entries to be excluded during the capture process(see Figure 8).

Figure 8. Adding Exclusions Through the Global Exclusions Editor


While the exclusions that are already part of AdminStudio arecomprehensive, there are always some particularities that are directlyrelated to how your network environment, workstation builds andpackages are set up that must be taken into consideration.

In addition, one of the best tools that can be used in support ofexclusion lists is iTripoli Package Cleaner (see Commandment number1 above). Package Cleaner is a product that is designed to examinepackage contents and clearly identify if components or settings shouldbe included in a package. The best part of Package Cleaner is that itoutlines why you would not or should not include these components inyour package. Using Package Cleaner is like having a packaging experton the premises. In addition, any exclusion it identifies can be added tothe exclusions you work with in AdminStudio making your futurepackages even better.

12. Know Your Packages

When preparing a package, you should extract as much informationfrom the package as possible. Integrated packaging environments willinclude special tools that are designed to help you gain a lot moreinformation 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 arerequired for the package to operate but are not included in the package.SmartScan will add these files in a color coded format so you knowwhat is required for the package to function properly. It also includesthe Setup Intent Wizard which will also help identify files that arerelated to the package but are not included in it. Both tools let youdiscover as much information about your package as possible.

AdminStudio’s SmartScan will become visible at the end of arepackaging process if additional information can be collected from theInstallScript-based setup files. At that time, the packager will have theoption to include additional files and feature hierarchy information (seeFigure 9).


Figure 9. Using SmartScan to Provide Additional Information onthe Package

To work with the Setup Intent Wizard, select the “Scan for setup intent”link in the Repackager integrated development environment (IDE). Thewizard will scan for additional file dependencies that may not have beeninstalled and display the results (see Figure 10).

Figure 10. Using the Setup Intent Wizard to identify additional filedependencies


13. Use a System Construction Model

Another key method to help reduce the complexity of creating packagesis to use a system construction model. This means that you build a coresystem and add all generic capabilities to this system. This image or“system stack” is then applied to all PCs or servers. From then on, youcreate groups of applications that can be deployed to groups of usersidentified through the role they play in your organization.

The system stack basically identifies the components, common andparticular, that you’ll find on different systems in your network. Thismeans a couple of things. First, you have to find the common elementsto all systems, either servers or PCs, and fit them together. This shouldinclude the operating system, service packs, utilities, office automationproducts, graphics file viewers, antivirus, document viewers, and so on.Once this is done, you can package this common stack into images thatcan be deployed as a blob through the network.

AdminStudio supports the system stack concept through the capture ofOperating System images:

1. Launch the OS Snapshot Wizard and name the image to becaptured (see Figure 12).

Figure 12. Capturing an Operating System

2. The data on the system will be captured and saved (see Figure13). The OS Snapshot Wizard can be run remotely, so no piecesof AdminStudio are required on the clean reference systembeing captured. After it is saved, it can be imported to theApplication Catalog.

Figure 11. A System StackExample, in this case, theAccounting Stack


Figure 13. An Operating System Capture in Progress

Once you have the system stack in place, you’ll have to learn to manageand maintain it as a single object. In real life, three comprehensiveupdates per year are sufficient. Of course, you’ll also have to provisionfor emergency update deployments. Remember that each time youchange 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 identifyspecial collections or catalogs of software packages that target specificoperational groups within your network. For example, accountants mayrequire a given set of tools over and above the common set, while salesstaff will require another. Within the accounting department, you mayhave employees that focus on reports and others that focus on datacollection, so these users will need additional tools over and above theaccounting stack. An example of the complete system stack approach isdisplayed in Figure 11 above.

If you do this, you’ll soon discover that constructing systems based onsuch a strategy greatly reduces packaging efforts because it reduces thenumber of programs that must coexist on any system. That’s because agood portion of systems only require the common stack. This makesthese systems the easiest to manage. In addition, by combining otherprograms into groups, you should be able to reduce the complexity ofeach system. These groups often include no more than 5 to 30individual programs depending on the target audience.

It is most likely that you’ll end up with certain programs that have verysmall target audiences or that have audiences that cannot be groupedtogether. These will not properly fit into any stack, but their number

AdminStudio lets you grouppackages according to audiencewhen detecting and repairingconflicts.


should be small and include no more than five (5) percent of thesoftware in your networks. They should still be packaged properly toenable centralized distribution and automated installation as well asproper documentation.

Using a system stack construction method along with applicationcatalogs will help your packaging and software management efforts inseveral ways. First, it simplifies system support because you know whatto expect on each system. Second, it simplifies new machinedeployments because the common stack is captured in a disk image.Third, it simplifies software deployment since you can group thesoftware stack for any particular audience and send it off as one singledeployment to target machines. Fourth, it simplifies the quality controlof your packages since you only need to test packages on the stack it ispart 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 desiredgroup, or they can be moved from one group to another as though in afile 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 theMSI format is because the Windows Installer service includes specialfeatures that can manage software conflicts “on the fly”. But, this doesnot eliminate the need to test all packages for conflicts against all of theother 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 checkcross-application consistency evaluator (ACE) rules. By using the IPE to


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 useof rules. It should therefore include a comprehensive set of built-inrules, but because the purpose of software packaging is to configuresoftware according to corporate standards that may or may not be thesame 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 shouldcompare each of the elements that make it up. This includes:

• Product Components — each product component is designedto 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) andexecutable (EXE) files.

• Registry Entries — the registry settings that support theoperation of the product.

• Shortcuts and INI Files — the tools to access the product onceinstalled, and the settings that are applied at product launch,though most Windows Installer products rarely use initializationfiles.

• ODBC Resources — the components that link the product toback-end databases if required.

• NT Services — the integrated services that are designed tooperate in the background; these apply mostly to serverapplications, though “NT” is an outdated moniker.

• File Extensions — the elements that link files created by theproduct to the product itself; for example, early versions ofMicrosoft Systems Management Server used the PDF extensionfor package definition files, when Adobe Acrobat used the sameextension for the portable document format.

• Product Properties — the settings that identify the product onthe 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 damageexisting products on the target systems. This is why conflicts must bedetected and repaired. Figure 15 illustrates the conflict detectionprocess.


Figure 15. Detecting Conflicts against a System Stack

By testing packages against the groups of products that should coexiston a target system, and only those products, you can improve thequality of your packages without having to overly increase thepackaging workload. This greatly reduces the impact of conflictdetection and resolution on the packaging process because there is norequirement to verify or test the cohabitation of programs contained indifferent groups since they are not likely to ever coexist on the samesystem. For example, an accounting reporting utility should be testedagainst the accounting stack, but there is no reason to test it againstthe IT administration stack since there should never be any reason toinstall 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 insideor outside the Application Catalog.

2. it gives you the ability to select the Groups or individualapplications in the System Stack that you want to test against(see Figure 16).


Figure 16. Identifying Which Packages to Detect Conflicts Againstin AdminStudio

3. You then select the specific tests you would like to run againstthe chosen System Stack elements.

Figure 17. Identifying the Tests to Run


The results of all conflict detection tests are preserved in theApplication Catalog for that application and can be used for furtherapplication 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 ona machine when they prepare a package. Because of this, a lot can gowrong when it gets to the user. Make sure you always work with twoaccounts, one with administrative rights and another with normal userrights. Then use both the Run As command in Windows to test theapplication and the IPE’s capability to test for behavior in locked-downenvironment before you deploy the package to users with limited rights.

In addition, AdminStudio’s QualityMonitor tool provides thisfunctionality.

1. Launch QualityMonitor and select an application to test fromthe list of installed MSI packages.

2. Choose the “Lockdown and Runtime Tests” option, pick an EXEto 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 anadministrator (see Figure 19).

This will let you ensure that the application will run properly whenoperated by people who only have common user rights andpermissions.


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

17. Perform Deployment Testing

Installing a package in a laboratory environment—the environmentwhere you prepare the package—often means pulling the package froma network share. Yet, when a package is delivered to users, it tends tobe deployed by a remote software delivery system. A lot can go wrongwhen this deployment isn’t tested before the package goes live.Deployed packages are most often installed in the background througha silent installation. In addition, deployed packages require specificconditions to be met on target systems for the deployment to workproperly. With an IPE such as AdminStudio, you can createinstrumented packages—packages that include all of the behavior of aninstallation, but which do not modify target systems—and test themwith small sample target groups. This way, you’ll know whether targetcomputers are ready for the package or not and increase the successrate or your deployments.

In AdminStudio, the Predeployment Test feature creates test packagesthat will run tests on the target system, but will not install anything.

1. Once a package has been selected, a number or tests can beincluded. The tests you include are at your discretion (seeFigure 20).


Figure 20. Choosing the Tests to Run in Predeployment Test

2. The instrumented package can be deployed to any number oflive, end-user systems in the field, and the results of the testsare reported back to a central location for viewing through aWeb 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 youknow, documentation is often not one of the strongest points of yourtechnicians. Nevertheless, you need to document changes in packagesas they are prepared, otherwise your packagers may well be repeatingthe same tasks or worse, performing conflicting tasks as they preparepackages. If your team hates writing, use the IPE’s capabilities tocapture all of the packaging operations and testing data. This willgreatly reduce the amount of documentation your technicians actuallyneed to perform.


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

19. Patch Your Packages

Patching is a fact of life today. Few software products can avoid beingpatched. Make sure you identify any required patches for the packagesyou prepare and if possible, make sure they are applied before thepackage is deployed. You’ll find that it’s a lot easier to patch in thepackaging lab than it is to patch once a package is deployed.

Use your IPE to help determine the impact of patches before you applythem. Include the patches you intend to deploy inside your applicationcatalogs. This will let you quickly identify which applications can beaffected by the patch and greatly reduce the time require to test a patchbefore deployment.

AdminStudio integrates with Macrovision’s Patch Impact Manager, atool that lets you identify available patches and test them againstproducts you have packaged. It does so through the following process:

1. Collect all the latest Microsoft patch data using the patchretrieval functionality.

2. Import the patches of interest into the Application Catalog (seeFigure 22).

Figure 22. Importing Selected Patches into the Application Catalogin AdminStudio


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

Figure 23. Selecting the Patches to Test

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

Figure 24. Identifying the Applications and OS Snapshots AgainstWhich to Run the Patch Tests


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

Figure 25. Viewing the Patch Testing Reports

The great advantage of a patch impact testing tool like Patch ImpactManager is that it helps you target which applications are impacted bythe patch. You can then perform additional patch testing on thoseapplications 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, oneafter the other. Like all processes, this activity should be managed as aproject with sound project management practices. Your IPE should offerstrong project management support and should help you keep track ofproject status at all times. This way, you’ll not only create solidpackages that require little post deployment support, but you’ll do it asefficiently as possible.

AdminStudio, combined with Macrovision’s AMS provide key features insupport of packaging project management. The first relies on thereports you can generate with AdminStudio. These reports relate toeach package and provide comprehensive information on the package(see Figure 26).


Figure 26. Create and Archive Application Reports in AdminStudio

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

Figure 27. Use AMS Along with AdminStudio to Track ProjectStatus Throughout the Packaging Process


Conclusion

There you have it: 20 Commandments that should go a long waytowards making your packages cleaner and more stable, reducing theissues and problems that may arise when they are deployed. Use thispractical advice to make your packages better, cleaner, and more stable.Many of the commandments are directly supported by IntegratedPackaging Environments as outlined in this paper. Others are simplystandards 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 caseAdminStudio—these commandments will help you gain completecontrol over the total cost of ownership of software in your network.

the20 commandments - jira – atlassian20... · figure 1 outlines the tools and structure you...

Documents