Package creation guidelines

Question

How do I ensure a package will work when rolled out to other machines?

Symptoms

N/A

N/A

Cause

N/A

Resolution

N/A

Instructions

Ranger RollOut is able to produce distributable packages for most software applications. Some applications may be copy protected, hardware dependent or use specific system components that the package building process cannot detect and copy.

RollOut does not produce complete machine images like Ghost, but instead provides a powerful "machine-snapshot-before-and-after" method of capturing disk, registry and system changes made to a machine during application installation.

For best results follow the guidelines below, understand how packages are created and test packages thoroughly.

• Create packages on a "virgin" machine (recently built with only the operating system). By doing this an application should install all files and settings because they do not exist. For example, if an application that uses Quicktime to play movies is installed onto a machine with Quicktime already installed, the application's Setup program may not install Quicktime. This means that the package will not include the required component.
  
  
• Install packages using a user that has a new registry. Many applications use the user's registry for storing user and application information. If the registry already contains keys set by the application during a previous installation they will not be modified during the installation process. This will mean that the changes will not be detected as being added or modified when building a package. As a rule, when using roaming profiles, ensure this user does not have a USER.DAT or NTUSER.DAT in their server home directory before logging on.
  
  
• Ensure the user creating the package has sufficient machine and network rights to install and configure software. In general, use an account with Domain Admins or Supervisor access. Test the package when deployed onto another machine using a "standard" user.
  
  
• Perform full installations when running Setup routines. This should ensure all required components are installed and captured in the package.
  
  
• Avoid opening Explorer, running other applications or performing system changes whilst building a package. This will avoid the capture of unnecessary system changes in the final package.
  
  
• Packages should be created on and distributed to the same types of machines using the same Operating System. This is because registries and disk directories are structured differently between NT and 9x based systems and can contain different data types. Many applications will run on both types of system, but more complex applications that depend on specific OS features may not be transferable. If you wish to build a single package for different systems, it is recommended that packages are tested before large scale use.
  
  
• Be aware when installing applications from CD that when in use the application may try to access the CD to load data files or additional required components (such as sample files or macros). Encyclopaedias for example often access data from their CD during use. It may be necessary to copy the CD to a network server and install from there either directly or via a mapped drive letter. Be aware that some CDs contain copy protection that prohibits use from a non CDFS drive.

• Packages produced from software installed from copy protected CDs (such as Red Alert 2).

• Packages produced from applications that install and control hardware.

• Applications that have Operating System specific features?.

• Applications that are dependent on specific hardware (e.g. scanners and graphics cards).

• Applications that are not designed to run on specific machine types or configurations.

• Applications that have minimum hardware requirements not met by destination machines.

• Applications that rely on other applications?, software or machine configurations (such as mapped drives) that are not installed on target machines and were not added during package creation.

• Applications that use additional system components (such as database engines) that are not unique applications but add extra functionality to Windows.

• Applications that rely on Visual Basic, C or other runtime DLLs that may not be installed on target machines and were not added during package creation.?

• Applications that utilise different versions of Internet browsers?, virtual machines, web page components or plug-ins (such as Flash and Shockwave players) that may not be installed on target machines and were not added during package creation.

For these reasons successful package creation and deployment cannot be guaranteed. Many problems can be avoided by using a "virgin" machine and user when creating an application package. Test a package thoroughly after creation on different machines to ensure all features function correctly. Advanced users can edit packages after creation.

Packages that cannot be created or deployed successfully using RollOut should be installed manually onto target machines.

• RollOut allows target Operating System types and versions to be set when creating a package. This can either prohibit installation on incompatible machines or provide a warning during installation.

• RollOut allows such application dependencies to be set when creating a package. This can either prohibit installation on incompatible machines or provide a warning during installation.

• RollOut allows a number or component dependencies to be set when creating a package (VB runtime version, IE version etc). This can either prohibit installation on incompatible machines or provide a warning during installation.

Testing

Logon and ensure the package runs correctly