When deploying legacy EXEs via Microsoft Intune, enterprise IT infrastructure teams face a clear architectural fork: wrap the installer in the PSAppDeployToolkit (PSADT) framework or convert it directly into a native MSI package.
Historically, this has been a strict trade-off between complex script maintenance and restricted deployment capabilities. This guide breaks down the core operational, security, and maintenance trade-offs of both methodologies to help you choose the right approach for your support model.
The Fast Verdict: Scannable Comparison
| Deployment Metric | PSAppDeployToolkit (PSADT) | Native MSI Conversion |
|---|---|---|
| Architecture | PowerShell Script Wrapper (.intunewin) | Native Windows Installer (.msi) |
| Setup Time | High (Manual scripting per application) | Low (Seconds via automation) |
| Detection Rules | Complex (Custom registry/file scripts) | Simple (Native Product GUID) |
| User Interaction | Built-in UI prompts & deferrals | Limited to native vendor switches |
| Maintenance | High (Script maintenance over versions) | Low (Simple version replacement) |
When to use PSAppDeployToolkit (PSADT)
You are deploying a highly volatile, proprietary enterprise application that absolutely requires interactive user prompts, complex service stoppages, or deep pre-install environment validation.
When to use MSI Conversion
You want a clean, standardized, script-free deployment that utilizes native Intune Line-of-Business (LOB) or Win32 detection rules and completely eliminates long-term script maintenance.
The Third Path: Eliminating the Scripting Overhead
Choosing a standard MSI conversion previously meant sacrificing the ability to handle complex vendor silent arguments, often dropping custom actions or background services.
Modern automation utilities like InstallMage completely bridge this gap. Instead of forcing you to write lines of PowerShell wrapper code just to pass non-standard switches, InstallMage automatically analyzes the underlying installer logic before compile-time. It embeds the vendor's native non-standard silent arguments directly into the MSI database table structure.
You get the clean, lightweight footprint of a native MSI — meaning fast Intune uploads, native product GUID detection, and zero dependency on execution policies — with the exact execution control of a script wrapper.
Technical Deep Dive: Integration & Capabilities
1. Deployment Methodology & Packaging
PSADT Framework: Uses a standardized PowerShell structure (Deploy-Application.ps1) to break deployments into Pre-Install, Install, and Post-Install phases. It must be wrapped into an .intunewin package using the Microsoft Win32 Content Prep Tool.
MSI Fundamentals: Relies entirely on the built-in Windows Installer service. It contains native product and upgrade codes, handles uninstalls cleanly, and passes standard parameters like /qn or /norestart.
2. Execution Control and Context
PSADT Permissions: Runs within the Intune Management Extension context. It provides robust capabilities to block unsupported OS versions or check disk space natively via script logic before burning bandwidth on the install.
MSI Permissions: Relies on standard Windows Installer privilege elevation rules. Modifying its internal execution sequence or adding conditional checks requires manually editing tables with advanced tools like Orca.
3. Logging, Auditing, and Troubleshooting
PSADT Logging: Generates structured, predictable logs on the local endpoint by default. This makes it incredibly easy to parse exact failure points, though administrators must manage both the toolkit logs and the underlying vendor logs.
MSI Logging: Standard MSI logs show explicit installer actions and return codes (such as 3010 for soft reboots), but tracking down legacy child-process failures requires manually enabling verbose command-line switches.
Frequently Asked Questions
When should I wrap an MSI with a script instead of deploying it directly?
Deploy an MSI directly if it installs silently out-of-the-box without prerequisites. Wrap it if you must force applications to close, handle complex upgrades, or present custom UI deferrals to live users.
What are the correct Intune commands for a tool-wrapped script?
When deploying a wrapped script as an Intune Win32 app, use the following syntax:
Install: powershell.exe -ExecutionPolicy Bypass -File .\Deploy-Application.ps1 -DeploymentType Install -DeployMode Silent
Uninstall: powershell.exe -ExecutionPolicy Bypass -File .\Deploy-Application.ps1 -DeploymentType Uninstall -DeployMode Silent
What detection rules work best for these deployments?
For native MSIs, always use the built-in MSI Product Code detection. For wrapped packages, avoid detecting the wrapper directory itself; instead, target a specific registry key, file version, or use a custom PowerShell verification script to confirm the actual application state.
Related reading: .intunewin vs MSI: which to use for Intune and the Intune Win32 best-practices guide.