Endpoint Manager Win32 App Deployment (MSI and EXE)

HOW TO: deploy Win32 application using Enpoint Manager.

With Endpoint Manger you can deploy a variety of different applications to Windows clients.  I have made blog posts about using MSIX packages to provide a modern way to distribute applications. Sometimes MSIX might not be the right solution for you. This blog is about deploying Win32 applications using the Windows App (Win32) capabilities. This form of distributing gives you a lot of control on how and when an application should be installed.

A note of caution, if you start to use Windows App (Win32) app deployment for your environment it is highly recommended that you do not combine Windows App (Win32) with Line-of-Buisiness app installations. Especially if you are planning to use Microsoft Autopilot, the combination of Win32 apps and Line-of-Business apps will cause installations to fail. So, if you decide to use Windows App (Win32), use it for all your applications.

Before you can upload a Win32  application to Endpoint Manager you will need to prepare the application. Essentially you repackage the application and all the dependent files into an .IntuneWin package, which can then be uploaded to Endpoint Manger. To package an application you will need to download the Win32 Content Prep Tool from GitHub.

You will then need to gather all required media to install the application and place them into one folder. I have created two examples, one for .exe applications and one for .msi application. For both types of installations, it is recommended to create two batch files, one for installation and one for the uninstallation. This will provide better control when deploying the application.

For the Citrix Workspace, which is an .exe I have created the following batch files: install.cmd and uninstall.cmd and placed them in a folder togheter with the exe installation file.


PUSHD "%~dp0"
"CitrixWorkspaceApp.exe" /silent /noreboot /forceinstall


PUSHD "%~dp0"
"CitrixWorkspaceApp.exe" /silent /uninstall
Citrix Workspace package content

For Acrobat Reader, which is an .msi I have also created the following batch files: install.cmd and uninstall.cmd. These files are added to the installation files.

msiexec /i "%~dp0AcroRead.msi" ALLUSERS=1 /qn /norestart
msiexec /x "%~dp0AcroRead.msi" /q
Acrobat Reader package content

Once you have gathered all the necessary installation media and you have validated that your batch files are working, by running the install.cmd and uninstall.cmd files you are ready to package. To package the applications run IntuneWinAppUtil.exe from an elevated PowerShell prompt. You are prompted for the source folder, which is the folder that contains all the installation files. The setup file is the actual executable and you need to specify an output folder where the .IntuneWin  file will be saved. At this point we do not need a Catalog folder. After the Utillity is ready you will end up with an .IntuneWin file.

Endpoint Manager

Now its time to distribute the application using Endpoint Manger. Login to endpoint.microsoft.com and select Apps and all Apps to Add a new application. Make sure to choose Windows app (Win32) as an app type. The first step is to select your .IntuneWin file and to provide information about the application. I will first start with Citrix Workspace and then add Acrobat Reader.

Application information

The second step specifies how to install the application. For the install and uninstall commands you will need to enter the batch files you created in the beginning. In my case the Install command is install.cmd and the uninstall command is uninstall.cmd. For installation behavior you can choose between system and user. This will determine where the application will be installed, either in the system context or in the user profile, this depends on your application.

Application installation controls

Choosing a restart behavior after the application is installed. Of course, this all depends on your application and whether it requires a reboot. Depending on your needs the following actions are explained:

Determine behavior based on return codes – The device will restart bases on the configured return code.
No specific action – Will suppress a restart during the installation of Win32 apps.
App install may force a device restart – This option means that the Win32 app installation can complete without suppressing restarts. With this configuration a Hard reboot return code will notify the user that a restart of the device will be triggered in 120 minutes. A Soft reboot return code will notify the user that a restart is required to finish the installation.
Intune will force a mandatory device restart – After a successful Win32 app installation the device will be rebooted immediately with no notification.

You get several default return codes. In most cases these return codes will work for you application . . The code configures the post-installation behavior of the Win32 app. If your application uses different access codes, you can use them here. The actions are explained:

Failed – The Failed return code indicates that the Win32 app installation failed.
Hard reboot – The Hard reboot return code indicates that the device is required to restart to complete the installation. Additional Win32 apps cannot be installed on the device without restart. The user will be notified about the required restart.
Soft reboot – The Soft reboot return code indicates that the next Win32 app can be installed without requiring a restart, but a restart is necessary to complete the installation of the installed Win32 app. The user will be notified about the restart.
Retry – The Retry return code indicates that the Win32 app installation is retried three times. The installation will wait for 5 minutes between each attempt.
Success – The Success return code indicates the Win32 app installation was successful.

The third step in the process is to specify the requirements. For the most part these are self-explanatory. You can however use custom requirement types such as specific files, registry settings or even scripts to determine whether an application should be installed or not. I will not be going into detail in this blog. For now, I only choose to install on 64-bit machines with a minimum operating system of Windows 10 1903.

Installation requirements

The fourth step are the detection rules. The detection rules are used to check if the application is present on the device. If the rules are not met Endpoint Manager will try to install the application on the device.

For .exe installations you might decide to just validate if the application is present. In my case I just check if SelfService.exe is present, in the path C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\.

EXE Application detection rule

The fifth step is to create dependency rules. Software dependencies are applications that must be installed before this application can be installed.  Specifically, the device must install the dependent apps before it installs the Win32 app. You can add Win32 app dependencies only after your Win32 app has been added and uploaded to Intune. After your Win32 app has been added, you will see the Dependencies option on the pane for your Win32 app. Any Win32 app dependency needs to also be a Win32 app. It does not support depending on other app types, such as single MSI LOB apps or Microsoft Store apps.

Since this is the first Win 32 app there is no option to create any dependencies. After Citrix Workspace is added a dependency will be created with Acrobat Reader. So, I just select next and I assign the application to a user group, as required.

For Acrobat Reader the steps are the same with a few exceptions. For the detection rules I will use a MSI rule type instead of a file location. Normally the MSI product code is filled in automatically. If this is not the case, you can check your registry settings. For 64-bit machines browse to HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. Here you will find an overview of all the installed applications. In my case for Acrobat Reader I can find the MSI GUID.

MSI application detection rule
Find the MSI GUID in the Registry settings

Since Citrix Workspace has been added to Endpoint Manger this can be used as a dependency. Acrobat Reader and Citrix are do not require each other to function, this is purely for demonstration purposes. To add a dependency simply select to add a dependency and select the application, in this case CitrixWorkspace.exe. By creating dependencies means that before Acrobat Reader is installed the Citrix Workspace application must be present. If Citrix Workspace is not present Endpoint Manager will install it first.

Application dependencies

Now the configuration is ready, and the applications start deploying to the clients. What happens on the client? Well first the Intune Management Extensions is installed on the client. This extension is used for the installation as well as the deployment of custom PowerShell scripts on devices. You can use the extension for troubleshooting purposes. The log file IntuneManagementExtension.log can be found in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

User notification

MSIX App Attach on Windows Virtual Desktop

Windows Virtual Desktops App Attach has just gone into Public Preview. A new major step in delevering and optimizing Windows Virtual Desktop application management. This blog will cover to steps on how to set it up.

Wndows Virtual Desktop, Fslogix and App Attach

But first what is MSIX App Attach and why it’s going to help you with your WVD environment. When maintaining your environment there are generally three components that you manage. Namely the OS, User Profiles and Applications. On a laptop for example all these components are on a single device and the components stored on a single disk. This works fine for the laptop but if you have non-persistent environments you have a challenge. In an ideal situation you want to separate the user data, application data and OS data.


Separating the user information is something that has long been used and is especially handy when you work on non persistent environments. With Fslogix there is no need anymore for the User Profile Disk, which comes with all its limitations and performance issues. It works great for non persistent environments. This way the user data is seperated from the OS and the Application data and is stored seperatly.

MSIX App Attach

With MSIX App Attach you can separate the applications from the Operating System, the same way that you would use Fslogix to separate the user data from the OS. This way you will have three different entities that you can mange independently of each other. So if you would have to update an application you wouldn’t have to create a new golden image for example, but would only modify or create a new application package. This makes the deployment and updates management of your environment much easier.

Let`s get started

Here’s what I’ll be covering:

  • Create Share
  • Convert MSIX to VHDX
  • Configure MSIX App attach

There are a couple of thing you will need:

  1. A certificate to sign your MSIX package, this certificate also needs to be installed on the WVD session hosts. Check out my previous blog on how to to this; Deploy MSIX with Intune.
  2. Applications that are already packaged in the MSIX format. Also check out Deploy MSIX with Intune on how to set this up.
  3. For now your subscription needs to be white listed for MSIX app attach. Fill out the Microsoft form, with your subscription ID. Approval of request can take up to 24 hours.
  4. A Windows Virtual Desktop environment with session hosts which are based on Windows version 2004. Make sure that you set this host pool to an evaluation environment.

Create Network Share

To deploy the MISX packages to the Session hosts you will need a network share. This network share needs to be accessible for users AND to computers. So create two groups, one containing your users, one containing your WVD session hosts. All is needed are Read rights.

Prepare WVD hosts

First the automatic updates for MSIX app attach applications needs to be disabled. In a elevated command prompt run:

rem Disable Store auto update:

reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t REG_DWORD /d 0 /f
Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Automatic app update" /Disable
Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /Disable

rem Disable Content Delivery auto download apps that they want to promote to users:

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v PreInstalledAppsEnabled /t REG_DWORD /d 0 /f

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug /v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f

rem Disable Windows Update:

sc config wuauserv start=disabled

Furthermore Hyper-V needs to be enabled on the VM. To install Hyper-V run

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Convert MSIX to VHDX

Before you can use the MSIX package, you will need to convert them to VHD(x) files (or .Cim but we won’t cover this today). Using the Microsoft docs, this is how you convert the MSIX.

  1. You will need the Hyper-V management tools. Install them by using
    Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
  2. Download the msixmgr tool.
  3. Unzip the files
  4. Run the following Powershell commands to create a VHDx. Adjust the command s to your needs
New-VHD -SizeBytes 1000MB -Path c:\temp\chrome.vhdx -Dynamic -Confirm:$false
$vhdObject = Mount-VHD c:\temp\chrome.vhdx -Passthru
$disk = Initialize-Disk -Passthru -Number $vhdObject.Number
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber $disk.Number
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

5. Create a parent folder. In my case I will name it GoogleChrome
6. Run the msixmgr to expand the MSIX package.
.\msixmgr.exe -Unpack -packagePath “C:\Temp\Appattach\GoogleChrome_68.46.88.0_x64__v1hrd262mcs5e.msix” -destination “D:\GoogleChrome” -applyacls
The destination is the folder you created in step 4 and 5
7. Detach the VHDX and your are ready to place the VHDX to your packages location

WVD Portal

With the preparations in place we can now add the MSIX packages to our hosts pool. Because the feature is still in preview you will need to use the following link to access MIX package feature https://preview.portal.azure.com/?feature.msixapplications=true#home. Go to your WVD app attach host pool, here you will see a new option, MSIX packages.

MSIX app attach

Select MSIX packages and Add to add a new package.
– Enter the UNC path to the VHDX file
– Enter a display name
– Set the state to Active

Add msix package
Add MSIX package

Now that the package is added you will need to assign the application to users. In you Host pool select Application groups. By default there should be at least one application group named after your host pool name followed by -DAG. To assign the application group to users go to assignment and add the users that need access to the host pool.

To add the MSIX package to the host pool go to Applications and select add:
– For MSIX Package select your added package
– Provide a Name
– Select Save

Add MSIX application

To check your work log in to the WVD host pool as a user and you should see the application that was added via MSIX app attach!

MSIX app attach final result

More info

Hopefully the information provided was helpful to you. You can also checkout the following sites for additional information: