Packaging knowledge for Windows and Intune

Why packages fail in testing, not in the builder

A package takes minutes to create. Whether it works shows up on the second device. Most failures are not clicking errors; they are decisions made earlier: which source, which silent parameters, how installation is detected, and what uninstall is supposed to remove. Answer those four and you have a package. Skip them and you have a file that happens to work on your test machine.

From vendor file to verified package

It starts with an installer from the vendor: MSI, EXE, or an older DSM package. That becomes a Win32 package for Intune, with install command, uninstall command, detection rule and a set of return codes Intune understands. Then comes the part nobody can skip: install, uninstall, install again — on a machine that is not already full of test leftovers.

Five topic areas

PSADT basics explain what the toolkit does and when a plain installer is enough. Software packaging covers silent parameters, detection and choosing the source. Migration describes the move from DSM and SCCM. Production is about versions, logs and bandwidth. Team covers standards, workspaces, API and audit.

What PilotDeploy checks — and what stays manual

PilotDeploy reads sources locally in the browser, without uploading installers. It produces a PSADT package with a fixed structure: launcher, PowerShell script, sources under Files/Source, reports under PackageInfo. What remains visible are the decisions a tool cannot make for you: silent parameters, detection, uninstall, return codes and the manual test on Windows.

Continue to the product

If you know the workflow and just want to build a package, the builder starts without a credit card. If you want to know whether the effort is worth it, start with “What is PSADT”.

---