Packaging knowledge

PSADT: basics and structure

What the PowerShell App Deployment Toolkit does, how a package is structured and where the limits are.

The problem PSADT solves

A Windows installer is built for a person sitting in front of it. In a managed fleet nobody sits there. It has to run silently, not wait for input, return a code, and leave nothing behind on uninstall.

That is what the PowerShell App Deployment Toolkit provides: a shell around the installer that handles order, error handling and return values. It does not install anything itself. It runs, checks and reports.

Anatomy of a package

A PSADT package has four parts: the entry script, the source files, a log area and the toolkit helpers. The entry script is the contract. It contains pre-install, install, post-install and uninstall phases. Everything the package does lives there, not in a hidden batch file.

The script name differs between PSADT versions. In the classic structure it is Deploy-Application.ps1; PilotDeploy produces exactly that structure with launcher, script, Files/Source and PackageInfo.

When a plain installer is enough

An MSI with documented silent properties does not need a toolkit. One command, one detection rule, one test. Adding PSADT here creates a layer to maintain without solving anything.

The same applies to simple EXE installers with documented arguments: if the call is reliable and uninstall exists, the direct route is shorter and has fewer failure points.

Where PSADT adds cost

The shell is code, and code can be wrong. A package that kills processes it should not touch, or an uninstall that deletes too much, is more dangerous than a plain MSI call. The effort pays off only when the logic is genuinely needed.

Cost also comes from inconsistency: different script structures, different return codes, different logs. Then the time goes into missing conventions, not into the toolkit.

Decision guide

Four honest questions:

1. Does something need to be stopped or removed before install? 2. Is there more than one install step? 3. Should the user see or confirm anything? 4. Does something need checking or configuration after install?

One “yes” is enough. If all four are “no”, the plain package is the better choice.

---

03

Reading PSADT exit codes

0, 3010, 1641, 1603: what the return codes mean, how Intune interprets them and when a restart is triggered.