Summary:

As you begin to use any one of the New Boundary Technologies software deployment products, you’ll find that it’s extremely easy to create Packages to install anything from complex applications to simple registry tweaks. Yet the Packager is also surprisingly powerful. In this tech note, we provide you with a list of Best Practices to follow when creating deployment Packages. These suggestions preview some

Solution:

• Use the Expert to lead you through the correct steps in Package creation.
  For nearly all situations, the Expert makes the right choices, so we recommend that you use the Expert when you’re first learning one of the New Boundary Technologies products. Once you become familiar with the product, you can experiment with custom settings, take custom pictures, create Packages manually, etc.
• Build Packages on a “clean” machine.
  This is important because the New Boundary Technologies' software deployment products use differencing technology (what’s different about this system since the baseline picture was taken?). A clean machine ensures that the Expert pulls all the necessary files, folders, shortcuts and settings into the Package. This also means that you should not rely on simply uninstalling software in order to simulate a “clean” machine. Uninstall programs rarely remove all traces of a program. For example, if you want to build a Package for an office suite, be sure to build it on a system that doesn’t already have the office suite installed (or previously installed). Otherwise, the Expert won’t detect all the changes that the suite installs to your system, so the Package will be incomplete.
• Build OS-specific packages when necessary.
  Many Packages will work fine on any version of Windows. Others contain platform-specific changes. For example, Windows 7, Windows Vista, and Windows XP Packages often contain .dll files that are specific to a particular Windows platform. Often we see a setup program run on an XP system put objects down that might have newer versioning available when it is installed on a Windows 7 system. Also some installers for the same applications require a specific bitness level (32-bit vs. 64-bit) for the OS.  Most packages built on a Windows OS that is 32bit will apply and function on a 64bit version of the same OS.  Others will require you to have two package versions of the same software application - one that is geared for 32bit and one for 64bit operating systems.  Remember you can apply a 32-bit package to a 64-bit machine, but you cannot apply a 64-bit package to a 32-bit machine.
• Be mindful of reboots.
  - If you’ve run a setup program in preparation for capturing its changes with Prism Deploy Packager and the setup program prompts you to reboot, you should reboot before capturing the changes.
  - Add reboot options to Package to match the behavior of the native setup program. If the program’s native setup prompted you to reboot after installing the software, that’s an indication that the Package should also be configured with a reboot property.
• Launch and Configure the Application before Finding Changes.
  Launch the program to ensure that it is installed properly and runs to your satisfaction. Configure any settings such as responding to licensing or registration prompts, entering your name (use variables later to customize), configuring a default Save As... location, etc. Sometimes, however, launching the application will tie the application license to the specific hardware you’ve installed it on, making note of items like CPU serial numbers, hard drive serial numbers and so on.  If you find you have an application that preforms such license tie-ins to the hardware you installed it on. uou would NOT want to launch the application before finalizing the building of the package.
• Stop newly installed services before finding changes.
  If the software for which you are building a Package installs one or more services, it is recommended that you stop the newly installed services before finding changes and building the Package. Prism may not be able to capture the contents of a file that is in use because of a loaded service. The resulting Package will contain a reference to the file but since the file contents are not stored, the file will not be copied to the target computer when the Package is installed.
• Check the paths embedded in the Package by using the Edit Paths window in the Package editor.
  With the Package open in the Editor, choose the C: button on the toolbar. This will show you every path that is referenced anywhere in the Package (including targets of shortcuts, registry data, INI file entries, etc.) Sometimes you’ll discover there’s a path that needs to be changed. For example, the system where you built the Package may have pointers to a D: drive even though target systems will only have a C: drive. Change the reference from D: to C: in one step using the Paths editor. Prism will update all file/folder locations and references to that path within the Package.
• Set variables as necessary to customize the deployment on each target system.
  Use Prism variables to resolve unique information such as a user’s name, computer name, drive letter, etc. There are numerous ways to use the powerful variables found in all of the New Boundary Technologies packaging and deployment products. Please refer to the product's User’s Guide for details.
• Clean extraneous entries out of your Package before distributing.
  You may notice that a Package contains an entry for a virus scanning log file. Or perhaps you mapped a network drive between the time you took your baseline picture and when you captured changes. The log file and the network mapping are included in the Package, but these items can (and should) be deleted. With time, you’ll get a sense for which entries are relevant and which aren’t. If you find you’re deleting the same entries over and over, there’s a way to configure all of the Prism Deploy Packager to always ignore certain files, folders, and settings. Please refer to the Related Articles section below for a link to another knowledge base article.
• Always use Prism's uninstall files in your testing environment.
  Uninstall files (referred to as rollback files) give you a quick and easy way to recover from situations that aren’t handled the way you’d like them to be. If your tests involve using Prism's self-installing .exe files, be sure to configure them to add an entry to Add/Remove Programs. Likewise, during the test phase don’t use the /NoRollback or /NoRollbackInfo options when you’re installing Packages.
• Test, Test, Test!
  Always do some testing with your Packages in a non-production environment to make sure you understand how the Packages interact, how they function on different operating systems, how the prompting messages are displayed, etc. If you’re trying to build and deploy one Package that will work on all OS platforms, be sure to test it on all OS platforms and bitness versions!