Packaging knowledge
Understanding Deploy-Application.ps1
Inside the PSADT script: pre-install, install, post-install, uninstall and where custom logic belongs.
The four phases
A PSADT package has a fixed sequence: pre-install, install, post-install, uninstall. Each phase has one job and should not take over another's.
Pre-install prepares: stop processes, remove the previous version, check prerequisites. Install runs the installer. Post-install applies configuration and verifies the result. Uninstall removes the product and cleans up what the package itself created.
What belongs where
The most common structural mistake is an install block that does everything. Stopping processes ends up between installer call and configuration, and on uninstall exactly that part is missing.
The mapping is simple once answered: anything that must happen before the installer belongs in pre-install. Anything the installer does belongs in install. Anything afterwards belongs in post-install. Anything that reverses belongs in uninstall.
Variables and return values
A package should define its values in one place: product name, version, paths, log path. Hard-code the same string in five places and you will update four of them at the next release.
The return value is the contract with Intune. The script must return a code Intune can interpret: success, success with restart, failure. A script that always returns 0 reports success even when nothing was installed.
Logging
The package log is the only trace after a failed rollout. It should record which command ran, with which arguments, which code it returned and how long it took.
A log that only says “start” and “end” is useless for troubleshooting. A log that writes passwords or licence keys is a security problem.
Typical structural errors
Four repeat offenders: uninstall inside the install block, missing error handling after the installer call, hard-coded paths, and a return code that is not passed through. All four are invisible when the test only covers the happy path.
How PilotDeploy defines it
PilotDeploy produces the classic structure with launcher, script, Files/Source and PackageInfo. The phases exist; the decisions stay visible: silent parameters, detection, uninstall and return codes remain review points.
---