Microsoft Intune offers various application deployment types—including Microsoft Store apps, line-of-business apps, and Windows (Win32) apps—each with distinct advantages and limitations. Win32 apps often provide the most flexibility via features like dependencies and supersedence, but regardless of the deployment type you choose, following best practices in packaging and scripting will ensure smooth installations and trouble-free upgrades.
Selecting the appropriate deployment type early can also prevent problematic (and unnecessary) future redeployments. Switching to another deployment type can require full uninstallation and reinstallation of the application, which can have a negative impact on the user experience.
Microsoft Store App
People often believe that using the Microsoft Store App deployment type is the simplest and best solution if the application you are trying to deploy is available in the Microsoft Store. While it may be the simplest to deploy, it isn’t necessarily the best solution for a few reasons. First, if you need to control the version of the application being deployed—such as testing releases manually, for example—the Microsoft Store App deployment route isn’t a good option. This approach will immediately upgrade the app to the newest release available in the store.
Second, you lose the granular control of options during installation. Things like system vs. user installation and install arguments to control the application (enable/disable auto update, customizations for features, etc.) are also not available when deploying through the store.
Despite those negatives, there are some benefits to deploying from the store. For those applications that have no installation customizations and should always be kept current—like Company Portal, Microsoft Edge, or Power BI Desktop—store app deployment is a great option. It is also useful to use store apps to remove native Windows applications rather than writing a remediation script, such as Quick Assist.
Line-of-business App Deployment
A line-of-business app (LOB app) uses an MSI installer. This is easier than creating the next app type of Windows app (Win32), but there are drawbacks to utilizing this method.
The first is that while a vendor may package an application as an MSI, it may not truly be built correctly. Firefox is a great example of this as it is released as an MSI but has constant problems when treated as such. The exe-based installer for Firefox is embedded into their MSI as is, so the functionality that an MSI provides for installation options and appropriate return codes does not exist.
The next is if you have a transform or other files required for the installation that must be included. The MSI deployment utilizes only a single file being uploaded into Intune.
Finally, two of the most beneficial features within Intune app management— dependencies and supersedence—are not supported with this method.
Upgrading an MSI is very simple. Whether assigned as required or available, once you upload a new version to Intune, that app will be deployed to all users or devices it has been targeted to. This could be useful for some applications, but as you will see in the section below for Win32 deployments, there is a better way.
Windows App (Win32) Deployment
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
While this application type may seem daunting and more complex, it is the most versatile application deployment type. The only negative for this type is that it can be complex and has a larger learning curve. However, the benefits outweigh those negatives. By creating a Win32 package, you have full control of every file included as well as providing customized scripts to control all actions. This allows for installation of a simple MSI or an extremely complex application that requires substantial scripting with some examples listed below
- Example 1: App released as an msi or exe
- Example 2: App released as an msi but requires the inclusion of a transform file (mst)
- Example 3: App that requires multiple files and customized scripts for installation (E.g. deploying a license file with the installation)
- Example 4: Any script you would like to deploy and have more control over. This can be something as simple as a script to set a registry value. While this can be done with a Remediation Script, having it as a Win32 package allows you to uninstall it easily as well.
Outside of the customization options when using a Win32 package, there are two useful deployment options—dependencies and supersedence—available for this deployment type that make it superior to other deployment types.
Dependencies are what they sound like: App A can require App B (a dependent app), even installing it automatically if needed. App B does not need assignment to a user or device if automatic installation is enabled, as it is a dependency for App A to complete its installation.
Supersedence allows you to create a new package for the application and require either an upgrade or a replacement. App A v1.0 may have a new version, so App A v2.0 is released. App A v2.0 can either replace (force an uninstall of App A v1.0) or upgrade the older version. The replace option also allows you to assign App B v1.0 to replace App A v1.0 (E.g., WinZip replaces a previous deployment of 7-Zip).
I go into more detail about supersedence in my previous article Win32 App Deployment with Intune Supersedence Rules.
Note: Both dependencies and supersedence require all applicable applications to be Win32 packages. You cannot mix a Line-of-business app with a Windows app (Win32).
Examples showing both options are shown below (version numbers are presented here just for the sake of example).
- Azure Monitor Agent v1.0 is deployed to a workstation
- Dependency: Microsoft Visual C++ Redistributable v1.0 (Automatic install)
- Azure Monitor Agent v2.0 is released and deployed to the same workstation
- Supersedence: Upgrade Azure Monitor Agent v1.0
- Dependency: Microsoft Visual C++ Redistributable v1.0 (Automatic install)
In the examples above, the workstation would receive the upgrade to Azure Monitor Agent v2.0. However, you still have the old application available in Intune (this allows for a staged upgrade for Pilot testing or rollbacks). A slight modification of the example would be to also upgrade to a newer version of Microsoft Visual C++ redistributable at the same time by updating the dependency assigned.
NOTE: Be very careful with dependency and supersedence configurations as you can very easily find yourself building a circular loop causing conflicts. This is when two or more apps require each other, preventing either installation from successfully completing.
Windows App (Win32) Packaging Best Practices
Any time you create a custom installation package, there are a few best practices to follow that, while making the initial creation more complex, will make your life easier in the long run.
You can create either PowerShell or batch scripts to complete the installations, but whichever you use, you will need to include return codes. The return code is a critical part of Intune interpreting if the installation is successful, a reboot is required or recommended, or if you want to ignore any reboot requests.
When creating your scripts, always be mindful of various use cases. If you are trying to create a folder, you should check if it exists first. If it does exist, should you remove it and recreate it? Once you attempt to create it, was there a failure or was it successfully created? In some cases, you can use simple one-line commands, but if you add these various use cases to the code, it becomes much easier to troubleshoot.
Your scripts should always include an installation and an uninstallation option. For supersedence or upgrade to function you need a working uninstallation script.
Lastly and most importantly, for any installation script, second only to the return codes, always write log files somewhere to the local system. Should there be an installation failure, the error codes and feedback in Intune are not always going to be enough to understand where that failure happened. Writing a log file is always going to be beneficial for troubleshooting. NOTE: Be cognizant of where that log file is written, making sure that the path is writable.
Conclusion
Intune application deployments are often assumed to be simple and don’t require much forethought or resource planning. However, without adequate planning, future application upgrades or even replacements can become a task that has been made substantially more complex. Whether you’re deploying applications as a managed app through an Intune policy, managing enrolled devices through Microsoft Entra ID, or handling device management across your Windows device fleet, the approach you choose impacts long-term maintainability. Integration with Microsoft Entra ensures proper identity and access management throughout the deployment lifecycle. The experts at Ravenswood Technology Group have the expertise to assist with this process.
If you need assistance, we can work with you to develop an Intune Application deployment architecture that serves your needs. Contact us today for more information!
