Packaging Pitfalls, Part 13: Handling Custom Exit Codes in Application Packaging

One of the more confusing situations in enterprise software deployment is when an application installs successfully, but the deployment platform reports it as failed.

The application is present on the device, the detection rule confirms the installation, and the user can launch it without any issues. From every practical perspective, the deployment was successful. Yet Microsoft Intune, Configuration Manager, or another deployment solution still displays a failed status.

In many cases, the problem is not the package itself.

It is the installer’s exit code.

Understanding Installer Exit Codes

Every installer returns an exit code after it finishes running. Deployment solutions use these return codes to determine whether the installation was successful, requires a reboot, or failed.

The most common exit codes are familiar to every packaging engineer:

  • 0 – Installation completed successfully.
  • 3010 – Installation completed successfully, but a restart is required.

These codes are recognized by deployment platforms and processed correctly without any additional configuration.

However, not every installer follows these conventions.

The challenge with custom exit codes

Software vendors are free to define their own exit codes.

Instead of returning 0, an installer may return a vendor-specific value even though the installation completed successfully. For that installer, the exit code represents an expected outcome rather than an error.

The deployment platform, however, has no way of knowing that.

Unless it has been explicitly configured otherwise, any unknown non-zero exit code is typically interpreted as a failed installation.

This creates a misleading situation. For administrators, this often means unnecessary troubleshooting, repeated deployment attempts, and time spent investigating an issue that does not actually exist.

How we handle custom exit codes

Handling installer exit codes is an important part of the application packaging process.

Before finalizing a package, we verify how the installer behaves and which exit codes it returns. This includes reviewing the vendor’s documentation, validating installation logs, and confirming the actual installation result rather than relying solely on the deployment status.

When using PSAppDeployToolkit v4, the most common approaches are -SuccessExitCodes and -IgnoreExitCodes.

If an installer returns a vendor-specific exit code that has been verified as a successful installation result, it can be explicitly added to the list of accepted success codes:

Start-ADTProcess -FilePath "$($adtSession.DirFiles)\Setup.exe" -ArgumentList "/S" -SuccessExitCodes 1,2

This tells PSAppDeployToolkit to treat exit codes 1 and 2 as successful process results instead of reporting them as failures.

PSAppDeployToolkit also supports the -IgnoreExitCodes parameter. Unlike -SuccessExitCodes, it allows ignoring not only specific exit codes, but also all exit codes by using an asterisk (*):

Start-ADTProcess -FilePath "$($adtSession.DirFiles)\Setup.exe" -ArgumentList "/S" -IgnoreExitCodes '*'

This prevents any installer exit code from failing the wrapper and should therefore be used with caution.

Always verify custom exit codes through testing and vendor documentation before treating them as successful or ignoring them. Because every installer behaves differently, assumptions can easily lead to incorrect deployment results.

Accurate reporting is part of a successful package

A deployment package should do more than install an application silently. It should also communicate the installation result accurately to the deployment platform.

Properly handling custom exit codes eliminates false deployment failures, improves reporting accuracy, and reduces unnecessary troubleshooting for IT administrators. It also ensures that deployment dashboards reflect the actual state of the environment, allowing teams to focus on genuine installation issues instead of investigating misleading deployment results.

Sometimes, the difference between a successful deployment and a reported failure is not the installation itself.

It’s simply how the installer’s exit code is interpreted.


Author

Liudmyla Boldak


More News from Apptimized

Stale Policy Sync: Why Online Devices Still Miss Patches

Why does a device show as online but still miss…

PSAppDeployToolkit v4 in Apptimized Care

Earlier, the release of PSAppDeployToolkit v4 introduced significant improvements for…

Apptimized H1 2026 Release Notes

Enterprise application management keeps becoming more complex. IT teams need…

PSAppDeployToolkit v4 in Apptimized Care

Earlier, the release of PSAppDeployToolkit v4 introduced significant improvements for application deployment workflows. The update modernized one of the most widely used packaging frameworks in Windows application management.

Now, PSADT v4 has been fully integrated into Apptimized Care.

This means that Apptimized Care now automatically wraps newly created packages using PSADT v4, without requiring customers to manually rebuild packages, modify deployment logic, or change existing operational processes.

What’s New in PSADT v4

PSADT v4 introduces a broader modernization of the framework. The update brings improvements not only to deployment workflows, but also to performance, security, compatibility, and long-term maintainability.

One of the major changes in PSADT v4 is the transition from a large script-based framework to a fully digitally signed PowerShell module. This change helps organizations ensure code integrity and comply with enterprise security policies. It also reduces risks related to code tampering or unauthorized modifications. The module-based architecture also improves maintainability, version control, and deployment consistency across environments.

From the technical perspective, the PSADT team extensively rewrote and optimized the toolkit. The new version removes legacy VBScript dependencies and improves performance across the framework. PSADT v4 additionally introduces PowerShell strict mode support, standardized function naming conventions, and improved error handling. These changes help make deployments more predictable and easier to maintain over time.

What Changed in Apptimized Care

The transition to PSADT v4 was implemented directly within the Care packaging workflow.

The transition does not require customers to redesign deployment processes, maintain separate PSADT versions internally, or introduce additional migration activities into existing operations. Existing deployment workflows continue to function as usual while Care delivers new packages aligned with the updated PSADT version.

Visibility in the Apptimized Portal

To make the transition transparent, the Versions page now clearly indicates packages wrapped using PSADT v4.

This allows teams to easily identify which application packages use the newer PSADT version directly from the UI, without additional manual verification or package inspection.

No Additional Migration Effort

The adoption of PSADT v4 in Care is another step in keeping the service aligned with current application packaging and deployment standards.

As Care continues delivering new application updates, it now consistently builds packages on the latest PSADT framework version.

Conclusion

The integration of PSADT v4 into Apptimized Care reflects the ongoing evolution of modern application packaging and deployment management. As deployment environments continue to become more complex, maintaining consistency, security, and operational stability across application updates becomes increasingly important for IT teams.

PSADT v4 integration represents only one part of the broader functionality available within Apptimized Care.

To learn more about how Apptimized Care can support your application management processes, read more about the available capabilities on the Apptimized Care page or book a demo with our specialist.


Author

Liudmyla Boldak


More News from Apptimized

Why IT Teams Shouldn’t Miss PSAppDeployToolkit v4.1.0 Enhancements

IT teams have trusted PSAppDeployToolkit for years to deliver consistency,…

Application Rationalization: How to Keep Your Environment Manageable

How many applications are running in your environment right now…

Application Testing in Sandbox Environments: How to Validate Software Without Risk

How confident are you when introducing a new application into…

Application Testing in Sandbox Environments: How to Validate Software Without Risk

How confident are you when introducing a new application into your environment? For many IT teams, application testing is a constant balancing act between speed and safety. One wrong installation can disrupt systems, introduce vulnerabilities, or create compatibility issues that ripple across the entire infrastructure.

That’s why modern testing strategies rely on isolation. Instead of validating software directly in production – or even staging environments – teams increasingly turn to sandbox environments to minimize risk.

In this article, we’ll explore how sandbox-based application testing works, why it’s essential for secure IT operations, and how organizations can validate software without compromising stability or security.

Why Application Testing Needs Isolation

At first glance, testing an application may seem straightforward: install it, run it, and verify functionality. In reality, it’s rarely that simple.

Applications interact with operating systems, dependencies, network policies, and other software. Even a seemingly harmless update can:

  • Break compatibility with existing tools
  • Override critical system configurations
  • Introduce hidden vulnerabilities
  • Trigger unexpected behavior in production

This is where traditional testing approaches fall short. Testing in shared environments often leads to unreliable results because conditions are not controlled.

Application testing in isolation solves this problem. By separating the test environment from production systems, IT teams can safely simulate real-world usage scenarios, validate application behavior across different configurations, detect conflicts before deployment, and analyze unknown or untrusted software—all without risking the stability of their live environment.

This approach is also reflected in industry guidance. The National Institute of Standards and Technology (NIST) emphasizes that testing and validation should be performed in isolated environments to avoid unintended impacts on operational systems and to ensure accurate results – particularly when working with third-party or untrusted software.

In other words, isolation turns testing from a risky necessity into a controlled, repeatable process.

How Sandbox Environments Improve Application Testing

A sandbox environment is a fully isolated space where applications can run without affecting the rest of the IT infrastructure. Think of it as a sealed testing lab – what happens inside stays inside.

When applied to application testing, sandbox environments introduce several key advantages.

Controlled and Repeatable Testing

Sandbox environments allow teams to create standardized conditions. Whether you’re testing packaging scripts, updates, or new software versions, you always start from a known baseline.

This consistency is critical for reliable validation. Instead of guessing whether an issue is environment-related, you can isolate variables and identify root causes faster.

Safe Testing of Unknown Software

Not all applications come from trusted sources. Even legitimate software can contain vulnerabilities or unexpected behaviors.

Sandbox-based validation enables teams to run suspicious or unverified software safely, monitor behavior without exposing internal systems, and evaluate risks before approval.

This is especially important when dealing with third-party applications, legacy tools, or software outside standard catalogs.

Prevention of Application Mismatches

One overlooked benefit of sandboxes is their ability to prevent application mismatches.

In complex IT environments, different applications may depend on specific versions of libraries, frameworks, or configurations. Testing in isolation helps identify dependency conflicts, version incompatibilities, packaging errors, and deployment issues before they impact production.

Instead of discovering these problems after deployment, teams can resolve them early – saving time and avoiding disruptions.

Faster Validation Cycles

Traditional testing environments often require manual setup, configuration, and cleanup. Isolated test environments streamline this process.

With features like snapshots and reusable environments, teams can:

  • Instantly reset testing conditions
  • Run parallel tests
  • Accelerate validation workflows

This makes validation not only safer but also significantly faster.

Key Use Cases for Application Testing in Sandboxes

Sandbox environments move beyond theory when they are applied to real IT workflows. This is where application testing becomes practical – embedded into daily processes rather than treated as a separate step.

Application Packaging Validation

Packaging is often where small errors turn into large deployment issues. In an isolated environment, teams can validate installation behavior end-to-end, making sure scripts execute correctly, silent installs work as intended, and configurations don’t introduce inconsistencies across systems. It’s a controlled way to confirm that a package is truly deployment-ready.

Patch and Update Testing

Updates introduce change – and with it, risk. Instead of reacting to issues after deployment, teams use isolated environments to observe how updates behave before release. This includes checking installation success, verifying that existing functionality remains stable, and identifying any unintended side effects that could impact users.

Legacy Application Testing

Legacy software rarely aligns cleanly with modern environments. Testing it safely allows teams to understand how it behaves under new operating systems and security constraints, without jeopardizing current infrastructure. This makes it easier to decide whether an application can be maintained, needs adjustment, or should be replaced.

Apptimized Insight: Simplifying Application Testing with SafeBox

All of these scenarios – from packaging validation to update testing – rely on one thing: having a reliable, isolated environment that doesn’t require constant setup or maintenance.

In practice, this is where many teams run into friction. Building and managing isolated environments internally takes time, resources, and ongoing effort, which can slow down testing instead of supporting it.

Apptimized SafeBox removes that barrier by providing ready-to-use, fully isolated environments in the cloud. Instead of setting up infrastructure, teams can immediately start validating applications, testing updates, or assessing risks in a controlled space that stays consistent across workflows.

Because SafeBox operates entirely outside of your internal environment, even unknown or high-risk software stays fully contained. At the same time, persistent environments and snapshot capabilities make it easy to repeat tests, compare outcomes, and move from validation to deployment with confidence.

The result is simple: testing becomes faster, safer, and far less disruptive – without the overhead that usually comes with it.

Conclusion

As application environments continue to grow in size and complexity, the way software is tested needs to evolve with them. What used to be a technical step in the deployment process has become a critical control point for stability, security, and consistency across the entire IT landscape.

Isolation makes that control possible. It allows teams to move faster without increasing risk, to validate changes without uncertainty, and to introduce new software with confidence rather than caution.

The real advantage, however, comes when this approach is no longer a workaround – but a built-in part of how testing is done.

Book a demo with our specialist to see how you can start testing applications in fully isolated environments – and turn validation into a consistent, reliable part of your deployment workflow.


Author

Maryna Semesenko


More News from Apptimized

Container Security in AKS: From Image to Runtime (Part 1 - Build & Registry)

This article focuses on container security in Azure Kubernetes Service…

What Happens to Application Packaging in Mergers and Acquisitions?

Mergers and acquisitions are often discussed in terms of financial…

How to Prove Patch Compliance in Audits

Patch compliance often appears straightforward at first glance. You deploy…