For years, the mantra for Intune administrators was simple: “Just wrap it as a Win32 app.” It was the reliable path. If you could get a .exe or .msi to run on a test machine, you could wrap it with the Win32 Content Prep Tool, upload it, and call it a day.
But the landscape has shifted. We are now in an era where maintaining a library of 200+ .intunewin files is a full-time job that provides zero business value. Every time Chrome or Zoom updates, you’re back in the packaging lab, wrapping a new version and updating detection rules. It is a treadmill that never stops.
The goal in 2026 is to move away from manual packaging and toward “declared” state management. This means picking the right tool for the specific app, rather than forcing everything into the Win32 mold.
The Workhorse: Win32 (IntuneWin)
Win32 apps remain the most flexible deployment method in Intune. When you wrap an application into an .intunewin file, you are essentially telling Intune: “Run this command in the SYSTEM context and check this registry key to see if it worked.”
When to Use Win32
Win32 is the correct choice for applications that require deep OS integration or complex installation logic. If an app needs a specific sequence of registry changes, folder creations, and multiple installer launches, a PowerShell wrapper script inside a Win32 package is still the gold standard.
Use Win32 for:
- Legacy software that doesn’t support modern standards.
- Apps requiring custom configuration files to be dropped into
%ProgramData%. - Complex software suites where the installer needs to be triggered with specific, non-standard flags.
The Maintenance Trap
The downside is the maintenance. Every version update requires a new wrap. If you are still manually packaging common 3rd party apps like 7-Zip or Notepad++, you are wasting time.
Pro Tip: Fix Your Detection Rules
Many engineers rely on the “MSI product code” detection. While easy, it’s brittle. For Win32 apps, prefer “File” detection pointing to the version of the main .exe. This ensures that if an app auto-updates itself, Intune doesn’t think the app is missing and try to reinstall it.
The Modern Standard: MSIX
MSIX was designed to be the “one ring to rule them all.” It combines the best of MSI (clean installs/uninstalls) and App-V (containerization).
When to Use MSIX
MSIX is best for internal Line-of-Business (LOB) apps or simple utilities that don’t need to touch the rest of the system. Because MSIX apps are containerized, they don’t leave “junk” in the registry or file system. When you uninstall an MSIX app, it is actually gone.
Use MSIX for:
- Simple internal tools developed in-house.
- Apps that are prone to crashing the OS or leaving remnants.
- Scenarios where you need a guaranteed clean uninstall.
The Reality Check
The hurdle is the packaging. Converting a legacy .exe to MSIX often requires the MSIX Packaging Tool, which can be finicky. If the app requires absolute paths to specific system folders, the MSIX container will block it. For most enterprise desktop engineers, MSIX is a great goal, but a difficult daily reality for a large portfolio.
The Game Changer: Winget
The Windows Package Manager (Winget) has fundamentally changed the packaging game. Instead of you hosting the installer, Winget points to a community-maintained manifest that knows where the latest version lives and how to install it.
The “Winget Wrapper” Workflow
You cannot simply “assign” a Winget package in Intune. Instead, you create a tiny Win32 package that contains a PowerShell script. This script executes winget install --id <App.ID> --silent --accept-package-agreements.
This is the most efficient way to handle 3rd party software.
Why This Wins
Once the “Winget Wrapper” is deployed, you stop packaging that app. When a new version of Chrome comes out, Winget handles the update logic. You no longer need to wrap a new .intunewin file every month.
Use Winget for:
- All standard 3rd party utilities (Browsers, PDF readers, Media players).
- Any app found in the official Winget community repository.
- Rapid deployment of tools during a project.
The SYSTEM Context Gotcha
Winget was built for users, not for the SYSTEM account. To make this work in Intune, your wrapper script must call Winget using the full path to the executable and often requires specific environment variables to be set so that it doesn’t try to launch a UI.
The 2026 Decision Matrix
To simplify your workflow, use this logic for every new app request:
-
Is it in the Winget repository?
- Yes $ ightarrow$ Use a Winget Wrapper.
- No $ ightarrow$ Go to step 2.
-
Is it a simple, internal LOB app that can be containerized?
- Yes $ ightarrow$ Use MSIX.
- No $ ightarrow$ Go to step 3.
-
Does it require complex scripts, legacy installers, or deep OS changes?
- Yes $ ightarrow$ Use Win32 (.intunewin).
Limitations and Caveats
No tool is perfect. Here is what to watch for:
- Winget Version Drift: While Winget handles updates, you have less control over exactly when a version hits a machine unless you specify a version in the command.
- MSIX Container Isolation: If your app needs to write to a specific folder on the C: drive for a legacy reason, MSIX will fail. You will have to use a “virtual” folder, which can confuse some old software.
- Win32 Detection Flapping: If an app auto-updates but your detection rule is too specific (e.g., checking for version 1.2.3), Intune will report the app as “Failed” or “Missing” the moment 1.2.4 is released.
Conclusion
Stop the packaging treadmill. The goal of a senior desktop engineer in 2026 is to manage the state of the device, not the files on the device.
Shift as much as possible to Winget. Use MSIX for the clean-up. Save Win32 for the difficult cases. By reducing the number of manual wraps you perform, you free up time for higher-value work like security hardening and automation.