Defining Installation Steps for a Software Package

Steps tab overview (Software Packages)

The Steps tab is where you define how a Software Package is installed during a build.
Steps run in sequence and allow you to fully automate application installation as part of an operating system deployment.

You can think of steps as similar to a task sequence used in other deployment tools: each step performs a specific action, and together they form a complete, unattended application install.

Using steps for silent and unattended installs

All steps should be designed to run silently, without requiring user interaction.

When creating steps, ensure that:

Installers use silent or unattended switches (for example, /quiet, /silent, or /qn)
No prompts, dialogs, or user confirmations are expected
The install can complete without user input from start to finish

If an installer cannot run silently, it is not suitable for use in an automated OS build and may cause the build to fail or hang.

Combining multiple steps to build a complete install

Most applications require more than a single action to install correctly.
The Steps tab allows you to combine multiple step types to create a reliable and repeatable installation.

Common examples include:

Copying files or folders before installation
Installing prerequisites
Running an EXE or MSI installer
Applying registry settings
Running PowerShell or CMD scripts for configuration or cleanup

Steps are processed in order, so the sequence you define is important.
By breaking the install into logical steps, you can tailor the application install exactly to your requirements.

For example, you could craft a single Software Package with three steps that:

Runs a setup.exe installer with a /silent command-line parameter
Copies in a .config file to control the application behaviour
Applies a license key in the form of a Registry key

Software Package tips

Avoiding reboots during software installation

Reboots should be avoided during software install steps.

Best practice is to:

Use installer switches that suppress reboots
Prevent installers from forcing a restart
Allow the build process to control when reboots occur

Unexpected reboots during application installation can interrupt the build and lead to incomplete or failed deployments.

Network and external resource considerations

Some application installs may attempt to access:

The internet
Internal servers
File shares
External repositories or license servers

These dependencies can reduce install reliability if they are not carefully considered.

When crafting steps, ask the following:

Will the device have internet access at the time this step runs?
If accessing a file share or server, will authentication be available?
Are credentials required to reach the external resource?
What happens if the resource is unavailable?

Where possible:

Bundle all required files within the Software Package
Avoid relying on live downloads during deployment
Avoid steps that depend on interactive authentication

The more self-contained the Software Package is, the more reliable the installation will be.

User context during installation

Software install steps run using a local administrator account created for the build process.

Important considerations:

This account is temporary and is deleted at the end of the build
Anything installed into C:\Users\<ProfileFolder> for this account will not be available to end users
Registry changes written to HKCU apply only to this temporary account

If settings need to apply to all users or future users:

Avoid installing to user-specific profile paths
As part of an automated build, you should never manually create folders inside C:\Users for future users
Prefer system-wide install locations
Use registry locations that apply at the machine level where appropriate

Other best practices for reliable installs

When designing steps, keep the following in mind:

Test installers outside of OneDeploy using the same silent switches
Keep steps focused and simple
Avoid unnecessary scripts or logic where possible
Log output where supported to aid troubleshooting
Ensure prerequisite software is installed before dependent applications
Be consistent in how steps are structured across software packages

Common pitfalls to avoid

Using installers that require user interaction
Allowing installers to reboot the device
Relying on internet access without verifying connectivity
Writing critical settings to user-specific locations
Assuming credentials or network access will be available
Combining too many actions into a single step instead of separating them

Carefully designed steps result in faster, more reliable builds and fewer deployment issues.

Testing installation steps before deployment

Testing software installation steps outside of a full build can save a significant amount of time and frustration.

Rather than discovering issues late in a build process, it is strongly recommended to validate each step manually before adding it to a Software Package.

Manual testing approach

A practical and effective approach is to:

Run installer commands manually from a command prompt or PowerShell on a test machine (or even better, a VM you can revert to a previous checkpoint/snapshot)
Use the exact same silent switches planned for automation
Execute steps in the same order they will run during deployment

This simulates what OneDeploy will do during an automated build, without needing to wait for a full OS deployment to complete.

Benefits of manual testing

Manual testing helps to:

Catch typos in file paths or command-line switches
Identify installers that are not truly silent
Detect unexpected prompts or dialogs
Discover installers that force or request reboots
Validate prerequisite ordering between steps

Finding these issues early avoids failed builds that may only surface problems 20–30 minutes into deployment.

Recommended testing workflow

Before adding steps to a Software Package:

Test each installer or script manually
Confirm it completes silently and without reboot
Verify the expected outcome (files, services, registry entries)
Only then add the step into the Steps tab

This approach results in faster iteration, more predictable installs, and far more reliable automated builds.

Software Packages overview
Creating EXE install steps
Creating MSI install steps
Creating script-based install steps

Introduction

Using OneDeploy

Reference