Understanding the flow behind Deployment, Delivery and Working of a Win32 application via Intune

My name is Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel ‘EverythingAboutIntune’ and you can subscribe to the same to learn more about Microsoft Intune.


  • Microsoft released the preview of Win32 app deployment via Intune back in October 2018 and ever since its release, this has been an enormous enabler for the modern management scenario.
  • The ability to deploy a Win32 application from Intune is a much-used feature because it enables us to achieve many uses cases. In this article I wanted to highlight and explain the flow associated with a Win32 app during its deployment via Intune, delivery as well as its processing.
  • I would suggest referencing our below documentation for understanding the basic admin tasks behind Win 32 application deployment via Intune.

The entire demonstration of this post can be found in my below Youtube video-

Advantages of deploying a Win32 application:

The ability of deploying Win32 app from Intune has been a much awaited and helpful feature because of its below major advantages-

  • We can now deploy .exe files (by converting it to .intunewin format) which was earlier not possible
  • We can use detection logic which will ensure that an app will only be downloaded in the device and installed if it is not detected as per set rule.
  • We can setup requirement rules which ensures that the app is applicable and downloaded/installed in the device if it meets a specific criterion
  • Natively from Intune UI we donot have the ability of deploying a single patch to a Windows 10 device. If we have a critical patch that needs to be deployed to devices, we can use the Win32 app deployment approach.
  • And most importantly we can set dependencies for a Win32 app (This is important as this enables us to determine the sequence in which the app would be installed/priority of apps)

Flow behind deployment of a Win32 application from Intune

Below is the architectural flow behind deployment of a Win32 app via Intune

The pre-requisite for a Win32 app deployment via Intune can be found below-
The Win32 Content Prep tool can be found below-

I would strongly suggest installing the Win32 file manually on a device first(without Intune) so as to ensure that the application supports silent install, and that the install commands are correct and we are sure of the installation folder(which can be used in detection logic)

Flow behind delivery of a Win32 app to the client-

The below diagram explains the flow behind the delivery of a Win32 app to a device via Intune

  • As we are using Intune to deploy Win32 apps, we will also need to grant access to endpoints in which our tenant currently resides.

The complete documentation for the same (which enlists our tenant’s ASU and the relevant CDN) can be found below-

  • Once the .intunewin file is created, we can rename its extension to .zip if we wish to see the contents of the .intunewin file
  • On doing so we will see that the .intunewin file contains 2 folders, viz Contents and Metadata
  • These folders contain the application package(which would be the installer) and the Detetection.xml file(which contains the file encryption information) respectively.

Flow behind processing of a Win32 app at the device end-

Now lets take a closer look and understand each setp that occurs during the life cycle of a Win32 app at the client’s end.

  • As illustrated above, the processing of a Win32 app from Intune down to the device can be broken down widely into 12 steps.
  • As discussed in the next section of this post, the logging by the IME for each of these steps is very verbose


Below is the location for the log file of Intune Management Extension

This location primarily contains 3 log files which tracks the below information-

  • AgentExecutor.log—> The logfile tracks powershell script executions (deployed by Intune)
  • ClientHealth.log—>This logfile tracks the sidecar agent-client health activities.
  • IntuneManagementExtension.log—>This is the IME log which tracks all the flow illustrated in steps below

Detailed flow in IME Logs: (Breakdown in sequence of occurrence)

Now let’s understand the detailed flow behind processing of a Win32 app at the device end as viewed in the IME logs-

Step No.Message in the logExplanation
Step 1Intune Management Extension gets initialized EMS Agent Started
Step 2S Mode is checked 
Step 3Content manager starts 
Step 4Deviceid and os version is noted 
Step 5IME discovers the Endpoint of Intune (CDNs)These need to be whitelisted in the firewall (if blocked)as per the network pre-reqs listed earlier
Step 6Impersonation for the user happens and token is requested/granted 
Step 7PUT request is sent 
Step 8We see a “Get Policies” response, which has the entire policy body (as configured by admin in the portal)We can check and ensure that the policy received by IME is in accordance with the policy configured
Step 9ExecManager identifies the app name/appid/app installation intent 
Step 10Dependency is checked for the apps discovered aboveIf dependencies are discovered, then the dependent app is downloaded and installed first
Step 11Detection rules is checked for the apps Detection rule as set in the policy is evaluated. If the app is detected in the device at this stage, the download/installation attempt of the app (in the below step) is skipped
Step 12Applicability is checked for the app (requirement and extended requirement) We can use a Powershell script as well(needs to be uploaded to the Intune portal) to run this requirement check
Step 13Download starts with toast notificationUser can see an intuitive prompt in the device notifying that the app is downloading/installing
Step 14Download job is created/timer is set 
Step 15Content downloaded to C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1.bin 
Step 16Download job completes, time taken is noted, bytes download is noted job closed 
Step 17Verifying encrypted hash, Decryption starts 
Step 18Unzipping starts from “Content\Staging” to C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1 
Step 19Cleaning up staging content 
Step 20Installer execution starts 
Step 21Prepare msi cmdline for system context 
Step 22msiexec /i “7zip.msi” /q /qn ALLUSERS=1 REBOOT=ReallySuppress /norestartCommand specified by the admin for the app in the portal
Step 23Installation completes,collecting result 
Step 24lpExitCode 0, determines if its a success 
Step 25DeviceRestartBehavior: 2, (checks , device restart behavior), handle is closedDevice restart action as per the policy defined by the admin in the portal
Step 26Now detection Rule starts by SideCarFileDetectionManager The Detection rule evaluated above in ‘Step 11’ is evaluated again, post app installation
Step 27Checked under Path: C:\Temp, filePath:C:\Temp\7zip, agent was checking under expanded: C:\Temp\7zip, applicationDetected: True 
Step 28Set ComplianceStateMessage with application detected after execution 
Step 29EnforcementStateMessage– determines the output after detection process, toast message of the installation status againUser is able to see an intuitive prompt in the device notifying that the app is installed successfully/failed (As applicable)
Step 30Cleaning up staged content C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1 
Step 31Start reporting app results … 
Step 32Sending results to service.The Intune admin can view the status of App deployment for the device in the Intune portal

Experience at the user end:

  • Below is what the end user experience is, during the Win32 app installation life cycle.
  • The Dependent app(s) get downloaded/installed first followed by the download/installation of the parent application.


I hope this article has been useful in understanding the flow that happens under the hood during the life cycle of a Win32 app deployment and processing from Intune.