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


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.
Deploying .exe Applications with Microsoft Endpoint Manager
Figure 1: Creating the proper folder structure to prepare the app.

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:


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


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:

Deploying .exe Applications with Microsoft Endpoint Manager

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

Deploying .exe Applications with Microsoft Endpoint Manager

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

Deploying .exe Applications with Microsoft Endpoint Manager
Figure 2: The IntuneWin application created using the IntuneWinAppUtil tool.

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):

Deploying .exe Applications with Microsoft Endpoint Manager
Figure 3: The first step to adding an application in Intune.

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:

Deploying .exe Applications with Microsoft Endpoint Manager
Figure 4: The Detection rule which enables Intune to see if the application exists already or has been installed correctly.

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.


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.

About the Author

Jon Jarvis

Jon Jarvis is a Microsoft 365 Principal Consultant at CDW. Jon has been working within Office 365 for over a decade having first learnt how to do an Exchange Online migration using articles from Practical 365! Jon enjoys working on the whole of the Microsoft 365 product range and has a passion for learning new skills, which has led to him passing 19 Microsoft exams. Outside of work, Jon is a Brazilian Jiu Jitsu Black Belt who has trained for over 11 years!


  1. Dean

    Hi Jon,
    As mentioned above, would it be possible to let us know why the CMD file was used, instead of just pointing to the .exe file?
    I’m trying to package the latest version of Adobe Reader (free), but they do not supply a MSI file, just the .exe.

    1. Cindy

      Hey Dean,
      You can extract the exe, there is the MSI included. There is also a nice Youtube video that explains how to customize Adobe Reader beforehand and how too deploy it.

  2. Zaheed Hassan

    I had doubt here, if in case i have deployed the app to a device group and it happens 1 of the devices in the group is a spare pc and has not checked-in from a long time. Will the app be deployed to this pc when the pc checks-in the next time?

  3. Serpentbane

    Would be nice if you also said why you use those CMD files, and also how ppl determine install and uninstall commands for EXE files since this might not be apparent for those new to this.

Leave a Reply