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-
|Message in the log
|Intune Management Extension gets initialized
|EMS Agent Started
|S Mode is checked
|Content manager starts
|Deviceid and os version is noted
|IME discovers the Endpoint of Intune (CDNs)
|These need to be whitelisted in the firewall (if blocked)as per the network pre-reqs listed earlier
|Impersonation for the user happens and token is requested/granted
|PUT request is sent
|We 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
|ExecManager identifies the app name/appid/app installation intent
|Dependency is checked for the apps discovered above
|If dependencies are discovered, then the dependent app is downloaded and installed first
|Detection 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
|Applicability 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
|Download starts with toast notification
|User can see an intuitive prompt in the device notifying that the app is downloading/installing
|Download job is created/timer is set
|Content downloaded to C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1.bin
|Download job completes, time taken is noted, bytes download is noted job closed
|Verifying encrypted hash, Decryption starts
|Unzipping starts from “Content\Staging” to C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1
|Cleaning up staging content
|Installer execution starts
|Prepare msi cmdline for system context
|msiexec /i “7zip.msi” /q /qn ALLUSERS=1 REBOOT=ReallySuppress /norestart
|Command specified by the admin for the app in the portal
|Installation completes,collecting result
|lpExitCode 0, determines if its a success
|DeviceRestartBehavior: 2, (checks , device restart behavior), handle is closed
|Device restart action as per the policy defined by the admin in the portal
|Now detection Rule starts by SideCarFileDetectionManager
|The Detection rule evaluated above in ‘Step 11’ is evaluated again, post app installation
|Checked under Path: C:\Temp, filePath:C:\Temp\7zip, agent was checking under expanded: C:\Temp\7zip, applicationDetected: True
|Set ComplianceStateMessage with application detected after execution
|EnforcementStateMessage– determines the output after detection process, toast message of the installation status again
|User is able to see an intuitive prompt in the device notifying that the app is installed successfully/failed (As applicable)
|Cleaning up staged content C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1
|Start reporting app results …
|Sending 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.