Software Packaging Best Practices

Software Packaging Best Practices

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:

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

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

Related articles

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