The of 20 Commandments 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, companyspecific (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. Macrovision s AdminStudio Try a fully functional, free evaluation of AdminStudio at www.installshield.com/ products/adminstudio/ eval.asp 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 manner. The most important of these is the size limitation on the database. If your packaging database exceeds these size limitations, you could stand a chance of losing all packaging data. You certainly don t want to find yourself in this situation. Treat your packaging data as corporate data and implement a commercial database system with proper backup strategies. 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 o o o o o o Database storage File storage for all software installation sources File storage for all repackaged software File storage for machine images or virtual machines Central repository for the integrated packaging environment, in this case Macrovision s AdminStudio Software deployment technologies for deployment testing 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 selfhealing, 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 AdminStudio Editor can work with both native MSI files as well as modify and create MSTs. The AdminStudio Repackager tool can be installed separately and even better, can be run remotely. This means that the packager can map a drive from the clean system to the network location with the copy of Repackager and launch it from there. In this way, the package building system does not have any part of AdminStudio installed and stays as clean as possible. Repackaged commercial software and corporate applications All commercial software products that are not or cannot be upgraded should be repackaged to integrate their installation with Windows Installer. You can expect that 99% of these legacy software products can be repackaged to take advantage of Windows Installer. 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: Package Building The original machines used to build packages should be as clean as possible. This often means that all you need on these machines is the operating system, proper OS patches and the required components from the packaging tool you use. These machines should be as powerful as possible to help speed the creation of packages. Once a machine is prepared, it should be imaged to save its pristine state. Then, after each package is created and saved, the machine should be reimaged to return it to a pristine state. Package Testing The target machines for package testing should be as similar as possible to the actual machines the package will be running on in the network. This means including the OS, all core generic software, and any particular software that would be residing on target systems. Once the machine is ready, it should be imaged to conserve the pristine 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
Using the VMware Repackaging Wizard in AdminStudio, you can select an available VMware virtual machine, and then Repackager automatically launches the selected operating system within a VMware session. For the Repackager to work, both VMware and VMware virtual machines have to be found on the packaging workstation. 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. There are two ways to use virtual machines. The first lets you use the undo capability each vendor offers to simply not save any of the changes you may have applied to a virtual machine hard disk file. This is very easy and lets you create a package, save the package, and simply close the machine removing any disk changes. The second is based on the very nature of virtual machines. VMs are in reality only files on your hard disk drive. That means that before you perform a test, you can copy these files to a new folder to save a copy of the pristine machine. Then, you prepare the package, save it, and simply delete the files making up the machine you just used. Copy the original files again to create another package. This is often the simplest way to use VMs. But as you can see, VMs will also require a lot of disk space since each virtual machine can be an average of 4 GB in size. They should be 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
Figure 11. A System Stack Example, in this case, the Accounting Stack 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 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
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. AdminStudio lets you group packages according to audience when detecting and repairing conflicts. 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 The 20 Commandments of Software Packaging White Paper 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