Silent

Most modern installation packages support the silent installation mode. In this mode, software is installed without user interaction: all processes are performed automatically.

In most cases, this mode is enabled by adding parameters to the command line of the executable. The installation package accepts these parameters, and the program is installed without user interaction.

Creating a method

Go to the Silent tab. Click Create command file under the method selection bar.

TSD tries to automatically determine the type of the installer and, if successful, inputs a set of parameters required for silent installation into the Parameters field. If TSD could not determine the type of the installer automatically, you can manually select it from the Installer type drop-down list.

The Redetermine the installer type

button automatically re-detects the type of the installer. The available parameters will be then refreshed, but the Parameters field will not be filled.When the type of the installer has been selected, all available parameters for this installer type will be displayed in the area under the Parameters field. Clicking one of the parameters will add it to the end of the Parameters field. Parameters can be edited manually.

A parameter can contain a value. In such a case the parameter and the value’s macro (highlighted for editing) will be added to the Parameters field.

The Set default command line for the silent install button fills the Parameters field with the basic parameters required for the selected installer type.

Ticking Use empty command line erases the contents of the Parameters field, disables its editing and disables the Installer type drop-down list. The method is considered ready for deployment.

The method is saved after every edit to the Parameters field.

The Silent method does not fully support:
Online downloaders may have parameters that allow the downloader to operate without user intervention, but at the same time the downloadable installation package is either run without any options or the downloader’s parameters are not compatible with it;
Self-extracting archives may have parameters that allow the downloader to extract the contents without user intervention, but at the same time they may not be designed to make the installation package run with the required parameters;
Installation packages where silent installation is either not supported or intentionally disabled during package creation.

If the target computer is in a domain, take care when using network paths in parameters, because the installer process will be started by a service with local system rights, and local system may not have access to these paths. If you need to use network paths, make sure that either at least one of the following user groups has access to them: Authenticated Users, NETWORK, This Organization, Everyone, or the target computer as a whole has access.
If the target computer is not in a domain, refrain from using network paths in parameters, because the installer process will be started by a service with local system rights, and local system will not have access to these paths. If you need to use files located on the network, add them to the Software storage along with the installer by ticking Installer consists of more than one file.

Configuration files for installers

Certain installer types involve the use of configuration files that allow to modify installation settings. Currently, TSD supports deployment of one such type of installer: Microsoft Office Click-to-Run.

Microsoft provides MS Office Click-to-Run installers separately from MS Office as Office Deployment Tools. At this time, the version of Click-to-Run supports Office 2013 and 2016. TSD does not support deployment of any other MS Office installation files. Pay attention to the Silent installation information panel and, if necessary, follow the instructions.

Only multi-file software can work with configuration files.

When you edit the method, and the configuration file is not present in the Software storage folder, then the default configuration file will be created. It’s also possible to import an external configuration file.To import the file, press

The configuration file editor has two modes: standard and advanced.

Standard mode shows configuration file contents necessary for silent installation in simplified, user-friendly form.

If you need to install multiple languages or exclude multiple applications from Office installation, you can do so by using comma as a delimiter.

To switch to Advanced mode, press

Advanced mode allows to manually edit the configuration file from a special text editor directly in TSD. For more information about the structure of the configuration file, see Microsoft Office documentation.

The changes to the configuration file must be confirmed by clicking Apply Changes.

If the .xml configuration file becomes invalid after manual editing, only editing in Advanced mode and external file importing will be available, but not standard mode. If the configuration file is valid, but lacks necessary data, then the missing lines will automatically be added with default values for display in standard mode.

While using the configuration file edited from TSD, you don’t have to specify the path to it from the command line. Both during the test run and during deployment, this file will be used automatically. However, at the same time, you can set the parameter to point to another file; in this case, the file from the specified path will be used.

Timeout

During remote deployment, certain factors (e.g. wrong command line or installer without silent installation support) can hang software deployment, and there would be no end to waiting for the installer to close. To solve this problem, we introduced installer Timeout to the TSD service. When the timeout period elapses, the service interrupts the wait for the installer to close and aborts its process.

Each newly created method has the default timeout value in minutes, which can be changed in Options Deployment methods . Timeout is used during test runs and during deployment. For smaller programs, where the installation process will not take much time, the timeout value can be reduced so that, if unforeseen happens, you’re not forced to wait for the process to close for much longer than necessary. If you’re deploying a large size application, or know that the program will take longer to install, increasing the timeout value is recommended to give the software enough time to deploy on the target machine. Otherwise, deployment will be interrupted prematurely before all its activities are performed.

Remote software deployment may take longer than normal local installation depending on software size and internal operations during installation, as well as external factors.

Changes to the default timeout value will not affect timeout values that have been set manually, even if their values match.

In order to default the timeout value in the editor, clear the field and press Enter.

If a value is outside the acceptable range, the closest possible will be set.

Test run

The installer that uses correct silent parameters should not interact with the user in any way.

To verify correct behavior of the installer with set parameters, use the Test run (local) option located under the Installer type drop-down list. A test run is considered successful if the user wasn’t prompted during installation.

TSD monitors the tested installer and displays its status in Silent section header.

Specify the Installation context in the Software passport before a test run.

The installation doesn’t have to be “silent”, but automatic.

Monitoring installer processes

It’s important for TSD to know when the installer completes its operation in order to provide all the necessary automatization during test run and to know when to start deploying the next program when deploying several programs. That’s why the main installer process is monitored during a test run or Silent deployment. If the main installer leaves behind any child processes, a list of all the monitored child processes will be displayed.

Such a scenario may occur if, for example, the installer finished by opening the developer’s website page in the browser or if the basic process was a self-extracting archive, and installation will be performed by a child process. Test run will stop automatically when all the processes from this list close, or by pressing the Installation is complete, stop monitoring button. Child processes which have not closed before the button is pressed will be ignored during deployment.

Given the nature of the silent installation, verification of installation should be carried out by running the program.

Add-ons

If add-ons have been attached to the main installer, a separate command line is created for each of them.

If any of the command lines is not filled and the box is unticked, the method is not considered ready for deployment.

Silent execution of script files

If you need to run a set of commands after the main software installer, it’s possible to work with batch files (.bat, .cmd) and the automation tool PowerShell. It’s recommended to use batch files as Add-ons to software installers.

In most cases, if a software publisher provides an installer in the form of a batch file, silent installation parameters will not be required. If however they are, please contact the software support and ask for instructions on silent installation.

If you need to pass parameters to the script file, make sure that all parameter values that contain spaces are in quotes (for PowerShell scripts, use single quotes). You can verify the command line by executing the script using Test run (locally) and confirming the result. However, to verify the script itself, it’s better to use cmd.exe or Windows PowerShell ISE, depending on the type of your script file.

We strongly recommend not to run software installers through script files. Software deployment using script files will not finish correctly in some cases, because it will be impossible to fully control the installation progress by monitoring the installer process, which can lead to unforeseen consequences on the remote computer. To deploy a program as well as carry out certain commands, add installers and script files separately using the list of Add-ons.

Pay Attention
If you address shared resources in script files and their parameters, we recommend using the Administrator installation context. Make sure that the user assigned to the computer in the Deployment target list has access to the shared resource. However, if the script must be run under a local user and use files located on the network during the execution process, then add these files to the Software storage along with the script file as a multi-file installer. Then correct the script so that it uses these files locally, as they will be put next to it on the target computer. The Local system privileges context is not recommended for deploying script files, since it restricts the script’s access to shared resources and has no advantages.

By default, the execution of Powershell scripts in Windows is not allowed for security reasons. During deployment, TSD uses a mechanism that bypasses this protection without changing the security settings. This mechanism is provided by Microsoft since Powershell 2.0. Therefore, if the version of Powershell installed on the remote computer is 1.0, then before starting the deployment, make sure that the execution of scripts is allowed on this system or install Powershell 2.0.