Packaging knowledge

Software packaging for Windows and Intune

From MSI to a verifiable Win32 package: silent parameters, detection and choosing the source for Windows deployments.

What the source type tells you about effort

An MSI is a contract: install database, properties, documented return codes. An EXE is a black box that sometimes accepts arguments and sometimes does not. A DSM package is an older format with its own script logic. The source type does not decide whether packaging is hard, but it decides where you start reading.

Silent parameters

Without silent parameters a package sits in the background waiting for a click nobody sees. Parameters live in vendor documentation, in MSI properties, or in the EXE's help output. If nothing is documented, only systematic testing with logging helps — not guessing.

Detection

Detection answers one question: is the package installed? Registry, file or script are the three routes. The most common mistake is a version check that is not updated with the next release — the package then counts as missing and gets deployed again.

Choosing the source

If a DSM package exists, migration is often faster than rebuilding. If only an EXE exists, there is no way around a wrapper. If an MSI with properties exists, the direct route is shortest. That decision belongs before the first click, not after.

Testing before rollout

A package is finished only after it has been installed, uninstalled and installed again on a clean device. Testing on your own workstation proves little: it already has dependencies no other device has.

---

03

MSI, EXE or DSM: where to start

Three source types, three routes into a package: what can be wrapped directly, what needs analysis and when migration is faster.