In December 2012, I blogged about best practices for deploying applications using System Center Configuration Manager, and while many of those recommendations are still valid I thought it was worthwhile to update my recommendations for today’s world, deploying applications using Microsoft Intune.

Best practices for deploying applications within a ConfigMgr 2012 Task Sequence

My Modern Workplace Application Vision

Source: A framework for Windows endpoint management transformation – Microsoft Community Hub

My vision (a.k.a North Star) for the Modern Workplace on Windows would be a workplace where minimal applications are installed, users mainly interact with SaaS based applications which they access through the web browser, or access using application add-ins in their browser or the Microsoft 365 apps. For this reason, I’m against installing big and complex applications on the Modern Workplace, for the following reasons:

• Microsoft Intune is not really on equal functionality compared to ConfigMgr when it comes to application installations
• Apps that you install, today need to be updated as well, the days of deploy once and never look at it again are over in my opinion (I see the opposite still though, which opens a major attack vector if applications are not patched)
• Apps which have client/server connectivity might perform better when hosted on a RDS/AVD solution, where the app runs near the backend. Als updating apps on RDS/AVD is usually easier to do since they are central
• I’m not in favor of using VPN solutions in order to give Modern Workplaces access to resources on-premises, especially when they are always on. There most probably the Microsoft Entra Private Access, where we can use the App Proxy functionality to access on-premises resources but governed by Conditional Access will probably change my opinion on this.

Anyway, in some cases you need to make applications available to your Modern Workplace and if you must, I hope this article will give you some guidance on how to set this up.

Challenges while dealing with Applications

When dealing with Applications on our Modern Workplace we have to deal with a couple of challenges:

• Applications which are assigned, are randomly installed during autopilot
• Even though we can control which Applications must be installed during the Enrollment Status Page, we cannot control when those applications get installed. Say that for example you need to install 20 applications during AutoPilot enrollment, and only 2 of those applications are specified in the ESP, in the most ideal situation these applications are installed first and second and the ESP finishes, but in the least ideal situation those applications are installed last and the ESP takes a very long time or even times out. I therefore recommend to keep the assigned applications to a minimum, and make the rest of your applications available for users to install using the Company Portal application
• Mixing different installation techniques for application installation can cause AutoPilot to fail. The reason for this, is that installations are handled by different services which don’t interact with each other. Line of Business Apps (.msi, .appx, .appxbundle, .msix, and .msixbundle) which are installed by the native MDM while Windows App (Win32) are handled by the Intune Management Extension. Say for example that due to the non-interaction between these two techniques, two installations based on Windows Installer technique (MSI) are started, one of the two will fail, since only one MSI installer can run at a time.
• Extensions for Browsers, Apps installed using the App Store by users, Add-ins installed in the Microsoft 365 Apps or within Teams are applications as well and should be governed (by blocking this by default, and working with whitelisting)

Based on this, my recommendation for application installations on Modern Workplace devices using Microsoft Intune would be to:

1. Use Windows Store apps (Winget) if available, for the main reason that these apps are automatically updated as well
2. Use Windows Apps (Win32) second, but be aware that you have the responsibility to keep them updated by either configuring the app to update itself (if possible) or by regularly checking if new versions of those apps are available and if so package them and distribute them in a controlled manner
3. Make applications which are not really needed right after deployment “Available” to be installed from the Company Portal app and instruct your users on how to find those applications.

Of course there are solutions available to automate the b) part, like Patch My PC/Scappman, Liquit Release & Patch Management or the newly announced Advanced App Management as part of the Intune Suite licensing among others. This also means that I don’t use the built in installers for Microsoft Edge and the Microsoft 365 Apps.

High level working of Application Installation and the importance of logging

When it comes to unattended application installation, Microsoft Intune only facilitates the installation. Intune agent checks if the software is already installed (the detection method(s)), if not downloads the installation files, kicks of the installation, monitors the process and picks up the returncode of that process to determine whether the application installation was successful, whether or not a reboot is required etc.. And last but not least, it checks if the application is installed by using the detection method(s) defined

Everything happening in-between kicking off the command line and ending of the process is basically a black box for Microsoft Intune. And that is exactly the reason why logging is a must have. Because you need to be able to determine why an installation failed, and trust me return codes in most cases don’t give you an exact reason.

And if you enable logging, make sure to store it in one of the locations where it can be picked up by the Collect Diagnostics process which you can trigger from Microsoft Intune, as described here: Collect diagnostics from a Windows device – Microsoft Intune | Microsoft Learn

So for example, while you would normally install an .msi file using the msiexec /I “filename.msi” /qn command line, my suggestion would be to include /l*v “%ProgramData%\Microsoft\IntuneManagementExtension\Logs\logfile-application-version.log to the command line.

An even better option would be to start using the PowerShell App Deployment Toolkit (ADT), which is a PowerShell framework which you can use to install applications. Some of the advantages that ADT brings to the table are:

• Standarized methods to install applications
• Standarized logging
• User interaction possible, f.e. to ask user to close an application in order for the installer to update, or install an add-in which can only be installed/updated while application closed
• And much more, please look at the website for all functionality

Some tips and lessons learned

Some other tips, which I advise you to adopt:

Test your application installation first

Make sure you can install the application truly unattended, test on a clean computer so that you make sure that you test if there are any dependencies needed.

• Try to run the installation from the command line first and once that works
• Install the application using a command prompt running as system (using the psexec -s option), since Microsoft Intune will install under the system context as well.

*psexec is part of the SysInternals tools collection provided by Microsoft. Also keep in mind that when the ASR rule “Block process creations originating from PSExec and WMI commands” is active, you might need to exclude cmd.exe from the machines that you are testing with. See: Enable attack surface reduction rules | Microsoft Learn

Store your application sources in a Definitive Media Library (DML)

Within the DML a.k.a. Definitive Software Library (DSL) you store all the information related to the application. That includes original installation files, documentation, screenshots, notes. Also make sure that your include this location in your backup, you’ll need this data in case the shit hits the fan and you need to rebuilt your environment.

Only include the files you really need when creating your IntuneWin file.

When using the Windows Apps (Win32) application type, you must upload a .intunewin file which you can create using the Microsoft Win32 Content Prep Tool, when using this tool you need to specify a folder and the executable which will be executed. This will eventually result in one file with the .intunewin extension.

A misconception is that included in the .intunewin file is only the installer file, but this is not the case, all the information included in the folder is added to the .intunewin file. Needs to be uploaded to Microsoft Intune, but more important downloaded by the Microsoft Intune client when needed for application installation. So get rid of files you don’t need before starting this process.

Did you know b.t.w. that there is also a nice GUI wrapper for this Microsoft Win32 Content Prep Tool written by 

Alexandru Radu Marin, which you find here: https://www.alexandrumarin.com/downloads/

Create good detection methods

Just as with ConfigMgr Applications, your detection methods should be well thought off. Check for existence of a file or folder might do the trick in order to make the application installation work, but I will bite you if you then want to update your application to a newer version, since the detection method will then think that the application is already installed.

If available and using Windows Installer (MSI) installations, always use the MSI rule type detection method, where you provide the MSI Product Code. This MSI product code should be unique, but be careful I have seen cases where an update of the MSI file was using the same product code.

If MSI is not available I always recommend to at least check for a version (which is very specific) and preferably in the following locations under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ or HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ in case you are installing 32 bit application on a 64-bit OS.

For example in the screenshot below, I would create a detection method checking for DisplayVersion equals 12.0.21005

Be careful with custom install scripts

I have seen some very nice install scripts used to install applications, there scripts usually perform several actions, like for example take care of some prerequisites, install the application, do some logging and probably some actions afterwards. What people creating those scripts usually don’t realize or forget to implement is to properly return the return code of the installation back to Microsoft Intune. If for example in the script the last action is writing the logfile, and this is successful, then Microsoft Intune will be returned a return code (usually 0) which makes Microsoft Intune think that the installation was successful. And if also your detection method is not that good you might risk Microsoft Intune reporting that the application is installed, while in reality the application didn’t even install on the device.

Conclusion

Make sure that you have a clear strategy on how to handle application on your Modern Workplace devices managed by Microsoft Intune. If you do, and are consistent you will save a lot of time making the applications install stable, you are quite certain that it will install since you already tested the installation in a similar environment (running as system) and you have a well-structured way of storing sources, documentation and all other information relevant to the application.