Deploying .exe Applications with Microsoft Endpoint Manager

Moving from ConfigMgr to Intune

Over the past few years, the trend around managing users’ corporate devices has grown exponentially and continues to evolve along with recent global shifts in the way business is conducted. Many organizations have already or are starting to move away from joining devices to on-premises Active Directory Domain Controllers, as well as using Group Policies and ConfigMgr (formerly known as SCCM) – and are moving toward modern management using Microsoft Endpoint Manager to ensure data in the cloud (and on-premises) is protected and properly secured.

Countless organizations have relied on ConfigMgr for many years as a product that did a bit of everything for endpoint devices, from imaging devices to delivering applications to whole organizations. Now, these organizations are facing the cumbersome task of having to package dozens, if not hundreds, of applications into the new world of modern management.

So, what do we have to do when we make the switch to use Intune instead of ConfigMgr to deploy applications? While Intune offers both Microsoft 365 Apps and Microsoft Edge right out of the box, .MSI or .EXE applications both must be packaged differently.

This article will focus on packaging .exe applications and the best practices you can implement to ensure these applications can be managed effectively in the future.

Read More: Taking Control of Your Unmanaged PCs with Intune

Prerequisites

The following are basic prerequisites for deploying applications via Intune:

• You must be assigned to at least the Application Manager role within Azure AD.
• A Windows 10 device that is enrolled in Intune via Azure AD Join or Hybrid Azure AD Join.
• A Microsoft 365 license or bolt-on that includes Intune such as Microsoft 365 E3 or E5 is required.

Step 1 – Preparing the App

First, we will need to download the Microsoft Win32 Content Prep Tool here.

Once downloaded, we will create 3 folders (Figure 1):

• \Application Name\ – A folder named after the application you are going to create; this doesn’t have to be exact, but it should be easily recognizable, so you remember it in the future. This is where the IntuneWinAppUtil.exe will reside.
• \Application Name\Input – This folder is where the nuts and bolts of the application will go. All application files and config files will be moved or created here.
• \Application Name\Output – This folder is where the .IntuneWin file will be created.

Once these folders have been created, we need to move the .exe into the Input folder. I’ll be using an old VPN client called Shrew Soft as an example.

*Note: My main advice for packaging any application is to install it manually on your device first – this will enable you to see how the device installs within your environment.

You will also need to find and make note of the following information:

• Installation Location – Where is the application installed?
• Application Launch – What is the main executable of the installed application?
• Application’s File Version – What is the version of the installed application? To find this, right-click the installed .exe file, go to Properties then Details.
• Any installation parameters – Some applications will have a ‘Read Me’ or ‘Administrator’s Guide,’ which can be very handy for silent installation, uninstall options, or understanding if there are other options for customizing an install.

Step 2 – Creating the application

Once we have this information, we can create the application. For this, we need to create two .CMD files, one for installing and the other for uninstalling the application. I’ve provided the base of both .CMD files below:

@ECHO OFF
SET SOURCE=%~dp0
SET SOURCE=%SOURCE:~0,-1%

This is followed by the application line, and below is what I used for the Shrew Soft VPN:

@ECHO OFF
SET SOURCE=%~dp0
SET SOURCE=%SOURCE:~0,-1%
vpn-client-2.2.2-release.exe /S /standard

The /S and /standard are specific to this application, but it ensures that the application will be installed silently and without user interaction.

For the uninstall file, I created the same but with the uninstall commands. I named the files “Install-Shrewsoft-London.CMD” and “Uninstall-Shrewsoft-London.CMD” respectively.

Once we have completed the previous steps, we load PowerShell, change the directory to the folder created in Step 1, then run the IntuneWinAppUtil.exe. You’ll then need to input the following details manually:

• Source Folder – The Input folder we created earlier.
• Setup File – The Install file we created earlier.
• Output Folder- The folder we created earlier for the IntuneWin file.

Within PowerShell you will be asked to specify a catalog folder, press N then enter:

After pressing enter, the .Intunewin application will be created. The PowerShell output should appear like this:

The application that we have just created will now be viewable in the Output file we created earlier (Figure 2):

Step 3 – Publishing the Application in MEM (Microsoft Endpoint Manager)

Now that the application has been packaged, we need to publish it. So, head over to Microsoft Endpoint Manager, click on Apps on the left-hand side, go to Windows then press Add. App Type will be Windows App (Win32). Now we can install the application in eight simple steps!

Step 1 – App Information

Here is where we specify the application that we created previously. (Figure3):

We then need to provide some additional information; the following details are required:

• Name – The name of the file.
• Description – A valid description that will be displayed to both admins and users.
• Publisher – The name of the company that distributes the application. This will be visible in the company portal.

Step 2 – Program

We are now presented with two required options; I usually leave the rest as default:

• Install Command – Here you’ll enter the install filename we created and packaged into the .IntuneWin file.
• Uninstall Command – Here you’ll enter the uninstall filename we created and packaged into the .IntuneWin file.

Step 3 – Requirements

At this point, we need to enter the OS and Hardware requirements that devices must meet before the application is installed. Below are the following two requirements:

• Operating system architecture – Select 32 or 64 bit, or both.
• Minimum operating system – Select the minimum Windows 10 OS level i.e., Windows 10 21H1.

You can also set requirements such as Disk space required, physical memory required, minimum number of logical processors, and Minimum CPU speed required. It’s good to set these parameters if you have a resource-heavy application with a high number of minimum requirements.

Step 4 – Detection Rules

This step will let MEM know that the application has been installed correctly and that the app is present. So, remember at the beginning of the article I said to note down the installation location, the executable name, and version? This is where we need it!

Under Rules format, go to Manually configure detection rules. Fill in the information that you gathered earlier:

Step 5 – Dependencies

If the application you are creating is dependent on another application, this ensures that the other app is installed beforehand. I’ve found this particularly useful in the past for simple tasks such as installing a network printer – I was able to install the drivers in system context, then create another application to push the network driver to the user in user context.

It should be noted there is a maximum of 100 dependencies, which includes the dependencies of any included dependencies, as well as the app itself. If your application does not have any dependencies, then you can continue onto the next step without having to configure anything.

Step 6 – Supersedence

Supersedence is currently an option that is in preview, and it allows you to directly replace another application with the application that we have just created. There is a maximum number of 10 apps that can be updated or replaced and three different scenarios in which you can utilize supersedence:

1. If the superseded application exists on the device and Uninstall Previous Version is set to Yes. The superseded app will be uninstalled, and the superseding app will be installed.
2. If the superseded app exists on the device and Uninstall Previous Version is set to No. The superseding app will be installed on the device, the superseded app will be uninstalled depending on the superseding app’s installer.
3. If the superseded app does not exist on the device, only the superseding app will be installed.

Again, if this application deployment doesn’t meet the three scenarios mentioned above, skip the additional configuration needed in this step and move on to the last step, assignments.

Step 7 – Assignments

Our final step is to target the applications to the devices we want the application deployed to. This can be done by group, all users, or all devices. However, it’s recommended that applications are deployed by groups to test and manage the deployment.

First, we’ll want to make sure that the device is Required (installed automatically) or Available for enrolled devices. This will confirm that the application is available for enrolled devices in the Company Portal app. Once assigned to users, the process is finished after reviewing the configuration; the application is then deployed to the devices specified in Step 7.

Summary

Upon successful completion of the steps above, you now have:

• Created an .Intunewin application ready to be imported into Intune.
• Created an application in Intune with all the necessary configurations including a detection rule and any dependencies.
• Deployed the application to a group of users to begin testing.

Please keep in mind that each application is different, which means that creating the IntuneWin application in Step 1 will involve different switch parameters than the examples presented in this article. And as mentioned at the beginning of this article, installing the application locally and understanding the installation process should be your biggest takeaway from this article.