Get Docy

Preparing to create a package

Configuring the environment

Software installation is greatly affected by the environment in which it is run. Its success may rely on a number of factors:

  • Compatibility with the operating system (system version, bitness, installed service pack): most relevant when picking which version of the program to create the deployment package from. For example, after a certain version of a program, an old OS version may no longer be supported. Also, programs are usually available for both the 32-bit and 64-bit operating systems. Their installers may be able to install the program for either bitness or for just one – and in the latter case, it may be necessary to have two installers for each bitness.
  • Whether the program is already installed on the computer (is it a clean installation). The degree to which it affects the creation of a deployment package depends on the selected deployment method. Most installers, when run manually, will offer to modify, repair, or remove an already installed program. This is critical when using the Macro method because the step featuring this option will be recorded and then played back on the target computer, where this step may be missing in case of the clean installation. Therefore, when choosing the Macro method, you must take into account that the installer may ask for such actions and that the program may already be installed on the target computer.

    Reinstallation on top of an already installed program when recording a system shot may result in almost all of the program files not being included in the package. If the files on the drive are not changed, TSD will not be able to detect the differences in the snapshots taken before and after installation. The package may also be incomplete if the program is currently not installed, however used to be. This is due to the fact that some programs leave residual files after uninstallation. Thus, some program files will already be on the drive before the first system shot is taken and will not be included in the deployment package.

    The Silent method is mostly unaffected by this factor both when the deployment package is created and when deployed. Even then, it’s advisable to perform a test run because some silent installations can still terminate with an error if the program is already installed.

  • Meeting library requirements (.NET Framework, Visual C ++ Redistributable, etc.): some software checks for additional required libraries during installation, and if the libraries are not installed, then the installation terminates with an error. Therefore, before creating the deployment package, you should keep in mind that some necessary libraries may not be installed on the remote computer and ensure their presence.

A general recommendation that helps take care of each of these factors is using one or more virtual machines. Creating and preparing virtual machines allows to refrain from unnecessary installations on your main OS, to record packages on different OS versions, to always perform a clean installation (when taking system snapshots) and to check if software requires libraries during installation.

Installation context

When creating a deployment package, another important thing that should be taken into account is the installation context. Programs can be installed in either of the two installation contexts: per-machine (for all users) or per-user (for the current user).
  • Per-machine installation allows all users of the computer to use the installed program. If the program supports this context, then the creation of the deployment package and the deployment itself must be performed with local system privileges. An average program will not require an active user session during deployment, but there are exceptions, so it’s recommended to make sure that the program will be correctly installed without the current user is not active.

If you have the choice, always install software per-machine (for all users). Thus, the risk of deployment errors will be minimized.

Per-user installation is intended for a single user. In this case, the program requires the corresponding user environment for correct installation. That may still not be enough, and the installer will also have to be run on behalf of the currently active user. Moreover, if the installer is run under the network administrator, then a variety of problems may occur for the local user: shortcuts not created on the desktop, installer errors during deployment or issues when using the installed program.

Because of these limitations, we do not recommend using per-user installation for deployment. Also, Microsoft doesn’t recommend performing per-user installations because the administrator then loses the option to uninstall the software afterwards (this also applies to TSD).

TSD supports another installation context: Administrator. This option should only be chosen to execute scripts that require network administrator privileges (for example, to gain access to a network share). The command interpreter will be run under the user whose credentials were used to connect to this computer.

We strongly recommend not to use the Administrator installation context to deploy standard programs, as this may result in the program being installed for this administrator instead of the local user, or lead to other installation errors.

Contents