My name 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 log||Explanation|
|Step 1||Intune Management Extension gets initialized||EMS Agent Started|
|Step 2||S Mode is checked|
|Step 3||Content manager starts|
|Step 4||Deviceid and os version is noted|
|Step 5||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|
|Step 6||Impersonation for the user happens and token is requested/granted|
|Step 7||PUT request is sent|
|Step 8||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|
|Step 9||ExecManager identifies the app name/appid/app installation intent|
|Step 10||Dependency is checked for the apps discovered above||If dependencies are discovered, then the dependent app is downloaded and installed first|
|Step 11||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|
|Step 12||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|
|Step 13||Download starts with toast notification||User can see an intuitive prompt in the device notifying that the app is downloading/installing|
|Step 14||Download job is created/timer is set|
|Step 15||Content downloaded to C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1.bin|
|Step 16||Download job completes, time taken is noted, bytes download is noted job closed|
|Step 17||Verifying encrypted hash, Decryption starts|
|Step 18||Unzipping starts from “Content\Staging” to C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1|
|Step 19||Cleaning up staging content|
|Step 20||Installer execution starts|
|Step 21||Prepare msi cmdline for system context|
|Step 22||msiexec /i “7zip.msi” /q /qn ALLUSERS=1 REBOOT=ReallySuppress /norestart||Command specified by the admin for the app in the portal|
|Step 23||Installation completes,collecting result|
|Step 24||lpExitCode 0, determines if its a success|
|Step 25||DeviceRestartBehavior: 2, (checks , device restart behavior), handle is closed||Device restart action as per the policy defined by the admin in the portal|
|Step 26||Now detection Rule starts by SideCarFileDetectionManager||The Detection rule evaluated above in ‘Step 11’ is evaluated again, post app installation|
|Step 27||Checked under Path: C:\Temp, filePath:C:\Temp\7zip, agent was checking under expanded: C:\Temp\7zip, applicationDetected: True|
|Step 28||Set ComplianceStateMessage with application detected after execution|
|Step 29||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)|
|Step 30||Cleaning up staged content C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1|
|Step 31||Start reporting app results …|
|Step 32||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.