Beyond the MSI: Why Your Intune App Strategy Might Be Holding You Back

If you've spent any time in the Intune console, you know that deploying an application is rarely as simple as "upload and forget." Between conflicting installers, reboot prompts, and the ever-elusive detection logic, it's easy to get bogged down in the weeds.

But after years of building modern workplaces, I've realized that most of the pain comes from picking the wrong deployment path. Here's how I approach app management in the wild.

The Windows Hierarchy: Offloading the Maintenance

For Windows, the game has changed. We're finally moving away from the "Golden Image" era into something much more modular.

1. Winget & The New Microsoft Store

The "New Microsoft Store" (Winget) is my first stop for 90% of internal apps.

The Win: You don't manage the binary. If Zoom releases an update, the store handles it. No more packaging every two weeks.
The Catch: It's only as good as the community repository. For custom or strictly version-locked apps, you'll need to step up.

2. Win32: The Reliable Workhorse

If it's not in the store, it becomes a Win32 app (.intunewin). I almost never use the older "Line of Business" (LOB) MSI path anymore—it's too inflexible and often conflicts with Autopilot.

Personal Rule: If it takes more than 5 minutes to package, I use a PowerShell wrapper to handle custom logging and exit codes.
Tip: I built my Intune App Utility precisely to automate this step.

The Mac Side: Apple's Way or the Highway

Deploying apps to macOS in an enterprise setting used to be a nightmare. Today, it's significantly cleaner if you play by Apple's rules.

1. VPP (Volume Purchase Program)

If you aren't using ABM and VPP for your Mac App Store apps, you're making life hard for yourself. VPP allows you to push apps silently without requiring a user to sign in with an Apple ID. It is, by far, the most seamless experience for the end-user.

2. Shell Scripts: When PKGs aren't enough

Sometimes you need to deploy an app that only provides a .dmg or a web download. Instead of wrapping it into a messy PKG, I often use a shell script that pulls the latest version directly from the vendor.

My "Go-To" DMG Install Script This is a snippet I use frequently for non-VPP apps like Google Chrome or Docker. It's clean, handles the mount points, and cleans up after itself.

#!/bin/bash <h1>Define the target</h1> APP_URL="https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg" APP_NAME="Google Chrome.app" MOUNT_POINT="/Volumes/ChromeInstall" echo "Downloading $APP_NAME..." curl -L "$APP_URL" -o "/tmp/installer.dmg" echo "Mounting image..." hdiutil attach "/tmp/installer.dmg" -mountpoint "$MOUNT_POINT" -nobrowse -quiet echo "Copying to Applications..." cp -R "$MOUNTPOINT/$APPNAME" "/Applications/" echo "Cleaning up..." hdiutil detach "$MOUNT_POINT" -quiet rm "/tmp/installer.dmg"

echo "Installation finished successfully."

The Bottom Line

Don't be a "packaging factory." Your goal as an engineer is to provide a working tool to the user with the least amount of technical debt. Prioritize the platform-native stores (Winget/VPP) first, and save your custom scripting for the edge cases that actually need it.

Created by Thomas Robb - Solutions Engineer