- Organize installers and resources in separate folders to avoid conflicts
- Use orchestrator scripts to manage multiple installations automatically
- Deploy silent installations with appropriate parameters and transform MSI files if necessary
- Validate that the application appears correctly installed and without errors or unwanted restarts
Automate software installation on systems Windows It is a fundamental practice for both system administrators and technicians responsible for mass installations. When we talk about installers with .msi or .exe extensions, the automation possibilities vary depending on the file type, but both options allow for a high degree of customization as long as the appropriate parameters are known.
In this article, we explain in detail how to automate this type of installation, from preparing the environment to silently executing scripts. If you need to include multiple packages in a single process, we'll also cover how to create orchestrator scripts and package everything into a single file. All of this is explained with practical examples that you can easily adapt to your environment.
Preparing the installation files
Before starting any automation, it's key to properly organize your installers and resources. Each executable or file must have a unique name, since if we work with multiple pieces within the same temporary directory, they could overwrite each other.
A good practice is to create a separate folder structure for each applicationFor example, you can create subdirectories named “App1,” “App2,” etc., within the root directory of your installation package.
Compression in .cab files
One of the most effective ways to package multiple resources is through the use of .cab files. To create them, you need a DDF (Diamond Directive File) that specifies the files to include and certain compression settings.
Here's a basic DDF file template that you can adapt to your environment:
.Set CabinetNameTemplate=tt.cab
.Set DiskDirectory1=.
Once you have the DDF ready, just run:
makecab -f ruta_del_archivo.DDF
Creating installation scripts
Once you have the resources organized, the next step is to generate the scripts that will be responsible for installing the packages. You can choose to have a script per application or a single orchestrator script that manages them all.
Basic registration example
set LOGFILE=%SystemDrive%\HelloWorld.log
echo Hello, World >> %LOGFILE%
Silent installation of an .exe file
set LOGFILE=%SystemDrive%\Fiddler_install.log
echo Installing Fiddler.exe >> %LOGFILE%
fiddler4setup.exe /S >> %LOGFILE%
echo result: %ERRORLEVEL% >> %LOGFILE%
Silent installation of an .msi file
set LOGFILE=%SystemDrive%\MSI_Install.log
echo Installing MyApp.msi >> %LOGFILE%
msiexec /i MyApp.msi /quiet >> %LOGFILE%
echo result: %ERRORLEVEL% >> %LOGFILE%
Run PowerShell script
set LOGFILE=%SystemDrive%\PowershellScript.log
echo Ejecutando PowerShell >> %LOGFILE%
PsExec.exe -accepteula -i -s cmd.exe /c 'powershell.exe my_script.ps1' >> %LOGFILE%
echo result: %ERRORLEVEL% >> %LOGFILE%
Management of multiple facilities
If you need to install multiple applications, The most efficient way is to use an orchestrator script that is responsible for running the installers. This script will be invoked from a single line of commands and can call other scripts or installers as needed.
For example:
@echo off
call install_app1.bat
call install_app2.bat
call my_script.ps1
Configuration in Windows Configuration Designer
When the script is ready, you'll need to add it to the package from the Windows Configuration Designer. In the field CommandLine
, the main command will be indicated, such as:
cmd /c InstallMyApp.bat
Then in CommandFiles
, additional files that the script needs are included: installers, log files, individual scripts, etc.
Execution considerations
- No user interaction is allowed during installation. No pop-ups, no assistants, no pauses. Everything should run in the background.
- Provisioning occurs before the user is configured in the system., so You should use installers that do not depend on the user context..
- Avoid visually modifying the system during script execution.
- Files are saved to a unique temporary location per package. For example,
%WINDIR%\system32\config\systemprofile\appdata\local\Temp\ProvisioningPkgTmp\{GUID}
Using Parameters with .msi Installers
To fully automate an MSI installation, it is important to master the most common parameters on the table:
- / quiet: installation without windows
- /qn: silent mode
- PROPERTY=VALUE: set custom properties
Silent installation and validation
A properly automated installation should install the software without displaying anything to the user and record a valid entry in the control panel. Verify that:
- The application appears in Programs and Features
- The product and manufacturer name are correct.
- No unnecessary multiple entries (bundleware) are installed
Using transform files (.mst)
If the MSI requires a lot of customization, you can use an .mst file. This file allows you to preconfigure properties of the installer and avoid errors like the famous 1603 code indicating failure during installation.
Some installers provide tools to generate these files, although you can also use tools like Orca to create your own transformations.
Handling automatic restarts
Depending on the behavior of the installer, a system reboot may be required. Ideally, control this from the distribution manager or through properties such as:
- REBOOT=ReallySuppress: prevents any reboot
- / norestart: prevents reboot after installation
- /forcerestart: Forces the system to reboot after installation
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.