Using PowerShell Script as the Installer for Win32 Apps

Intune now allows a PowerShell script to be the actual installer for a Win32 app. Instead of calling setup.exe, Intune runs your script directly and evaluates success by its exit code. This changes how far you can go with custom app deployments.

What it enables / Why this matters

This removes the need for wrapper tools when the installer logic is more complex than a single command line. You can check prerequisites, download additional files, modify the system, install, then clean up in one controlled flow.

In real tenants this solves common problems. Legacy installers without silent switches, apps that require pre configuration, or packages that must detect existing versions before continuing. You get one deployment object with full control over install and return status.

It also improves reliability. Intune evaluates the script exit code directly, so you can explicitly define success, reboot required, or failure instead of parsing vendor behaviour.

If you already use a third party patch or packaging solution like Robopack, this might feel familiar. These platforms already provide visual pre and post script builders where you can inject your own logic, handle licences, or chain actions without writing a full wrapper yourself.

Note There is currently a UI glitch in the Intune admin center. When creating a new Win32 app, the installer type dropdown may be disabled. As soon as you enter any character in the command line field, the dropdown becomes selectable.

When to use it

Use this for complex installs that need logic. Examples are multi step installs, prerequisite frameworks, in place upgrades, license injection, or post install hardening. It is especially useful for internal tools and badly behaving legacy software.

When NOT to use it

Do not use this for simple MSI or EXE installers that already work silently. You lose vendor logging and native repair behaviour. Troubleshooting becomes your responsibility and poor error handling will cause false failures or endless retries.

Example scenario

You deploy a screenshot tool where the installer never changes, but the licence expires every year. Traditionally this means rebuilding the Win32 package just to update a single licence value.

With a script installer, the binary stays untouched. The installer.ps1 installs the app and writes the current licence key into the registry.

When the licence is renewed next year, IT only updates the licence string in the script and re uploads the same package. (and detection rule) No repackaging, no new detection logic, no testing of a “new” installer that is actually identical.

This turns a yearly packaging task into a one line script update, while keeping the same Win32 app and assignments.

Recommendation

Use script installers selectively for packages that cannot be handled cleanly otherwise. If you already run a packaging platform like Robopack, you often do not need this feature at all. Robopack already provides visual custom settings like pre and post scripting, license injection, and chaining logic in a much safer and more maintainable way. For standard software, keep using native installers and detection rules.

References 🔗 Win32 App Management in Microsoft Intune – Microsoft Intune | Microsoft Learn

Script installers give you maximum control, but also move packaging quality and support fully into your own hands.