Welcome to today’s post titled Intune Management Extension Deep Dive Level 300.
In this post, I will show you in detail how Intune Management Extension (IME) a.k.a Intune Sidecar handles win32 app deployment on a managed Windows 10 endpoint.
This post intends to help you to easily identify the reason why a particular win32 app deployment from Intune ends up in an error state. The post includes the below list of errors that I have encountered related to Intune win32 app deployment.
- Access is denied.(0x80070005)
- Error downloading content.(0x87D30067)
- Error unzipping downloaded content.(0x87D30065)
- Failed to retrieve content information.(0x87D30065)
- The Application was not detected after installation completed successfully(0x87D1041C)
- The content Delivery network used for downloading application content times out(0x87D33006A)
- The system cannot find the file specified(0x80070002)
- The unmonitored process is in progress, however it may timeout(0x87D300C9)
- The user logged off while the app policy was being processed(0x87D300CD)
However, the above list is not exhaustive and there is a good chance that you can encounter a different error. The aim is to help you relate to the error source and determine the cause.
Before we start with the actual content, and since this post targets Level 300 knowledge, let’s understand first how an application is packaged to be deployed as a win32 app from Intune.
Get to know the .INTUNEWIN package
Intune natively supports the deployment of Windows applications with extensions MSI, MSIX, APPX and APPXBUNDLE as Line-of-Business (LOB) applications to the managed Windows 10 endpoints.
However, Intune cannot deploy an application a .EXE app package to an endpoint natively. From my understanding, this is probably for the same reason as why you can’t send/receive an EXE file directly as an email attachment (security risk!).
This is where the Intune Management Extension (IME) a.k.a Intune Sidecar comes into the picture and with it comes the new app package extension “.INTUNEWIN“.
.INTUNEWIN is basically a wrapper to contain the application executable source file (.EXE) along with its INSTALL and UNINSTALL commands (and other dependent files if any)
- Arrange the application source file (.EXE) and the Install/Uninstall commands (VB script/PS script/CMD/Batch) to a single folder. This will be specified as the Source folder.
- Get the Intune Win32 Content Prep Tool and run it.
- Specify the path to the Source folder.
- Specify the application source (.EXE) file.
- Specify the path to Output folder. [This is where you will find the prepared .INTUNEWIN file]
PS D:\App Package> .\IntuneWinAppUtil.exe Please specify the source folder: D:\App Package\Source Folder Please specify the setup file: GoogleChrome-8604240193-x64-100.exe Please specify the output folder: D:\App Package\Output Folder Do you want to specify catalog folder (Y/N)?N INFO Validating parameters INFO Validated parameters within 14 milliseconds INFO Compressing the source folder 'D:\App Package\Source Folder' to 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin' INFO Calculated size for folder 'D:\App Package\Source Folder' is 71372729 within 1 milliseconds INFO Compressed folder 'D:\App Package\Source Folder' successfully within 2390 milliseconds INFO Checking file type INFO Checked file type within 3 milliseconds INFO Encrypting file 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin' INFO 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin' has been encrypted successfully within 228 milliseconds INFO Computing SHA256 hash for C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\58b1fa89-ea9a-4f94-9aaf-e0024c48387d INFO Computed SHA256 hash for 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\58b1fa89-ea9a-4f94-9aaf-e0024c48387d' within 758 milliseconds INFO Computing SHA256 hash for C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin INFO Computed SHA256 hash for C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin within 765 milliseconds INFO Copying encrypted file from 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\58b1fa89-ea9a-4f94-9aaf-e0024c48387d' to 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin' INFO File 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Contents\IntunePackage.intunewin' got updated successfully within 128 milliseconds INFO Generating detection XML file 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage\Metadata\Detection.xml' INFO Generated detection XML file within 43 milliseconds INFO Compressing folder 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage' to 'D:\App Package\Output Folder\GoogleChrome-8604240193-x64-100.intunewin' INFO Calculated size for folder 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage' is 70215616 within 0 milliseconds INFO Compressed folder 'C:\Users\JoymalyaBasuRoy\AppData\Local\Temp\5798cbc1-a8ad-4d83-b2fe-8748b42c113a\IntuneWinPackage' successfully within 561 milliseconds INFO Removing temporary files INFO Removed temporary files within 8 milliseconds INFO File 'D:\App Package\Output Folder\GoogleChrome-8604240193-x64-100.intunewin' has been generated successfully [=================================================] 100% INFO Done!!!
A simple process isn’t it?
If you look into the output of the IntuneWinAppUtil as above, you would see that the tool is actually doing the below steps.
- Creates a folder named IntuneWinPackage in the Output folder as specified.
- Compresses the contents of Source folder as specified to create a .intunewin file and encrypts it using SHA256 algorithm.
- Creates a subfolder named Contents under the IntuneWinPackage folder to store the compressed and encrypted file (.intunewin) as created in the above step.
- Creates another subfolder named Metadata under the IntuneWinPackage folder where it stores the encryption info to Detection.xml file.
- Compresses the IntuneWinPackage folder as a whole to create the final outcome as a .intunewin package.
Creating Win32 App in Intune – Know the backend activities performed by Intune
As we create the application in Intune, what happens in background? You can see the high-level steps below:
- The .intunewin app package gets uploaded to the Azure Storage account of the tenant
- Intune decompresses the package to retrieve the Detection.xml from the Metadata folder of the IntuneWinPackage as obtained
- The actual app content which is present as an encrypted .intunewin within the Contents folder is submitted to the CDN
- The decryption info (as retrieved from Detection.xml) is tagged to the app
When a request for the app comes (user-initiated for Available deployment, Intune initiated for Required deployment), the download URL to the encrypted .intunewin is delivered to the endpoint. The IME agent creates a download job to get the file downloaded to the endpoint. Intune also sends down the decryption info for the IME agent to be able to decrypt and unzip the contents.
GET CONTENT INFO FROM SERVICE,RET =
"DOWNLOADURL\": "LINK TO CDN"
If you would want to retrieve the source contents from a win32 app package uploaded to Intune, check this awesome blog post on the same by Oliver Kieselbach.
Overview of how the Intune Management Extension (IME) agent handles Win32 app deployment
In a nutshell, the activity as performed by the intune Management Extension (IME) agent to handle a win32 app deployment can be summarized as below.
The IME agent on the managed Windows endpoint polls the Intune service to check for any active app deployment, and if found, starts processing the application as per the conditions (Applicability) and criteria (Detection) as set by Admin while creating the app package. IME agent retrieves the .INTUNEWIN package file from service, unwraps it to recover the original application .EXE file and executes it using the provided INSTALL command. IME agent post executing the application monitors the installer process and post install, checks the install success as per criteria (Detection) to report back to the service.
The above is only to help understand the process easily as we will dive deeper into the details below.
Deep Dive into IME Agent Win32 App Deployment Backend Process
IME Agent has to go through the following phases to process a Win32 app deployment on the endpoint.
- Polling Phase Start
- Retrieve Content Metadata
- Pre-Install Detection
- Extended Requirements
- Integrity Check and Unzip
- Post-Install Detection
- Set Compliance
- Report Status
- Polling Phase
You can easily see this by going through the Intune Management Extension logs located at
A summarized steps of action is given as below.
- IME agent initializes.
- IME agent discovers Intune endpoint https://fef.msuc##.manage.microsoft.com/SideCar/StatelessSideCarGatewayService
- IME agent fetches AAD token via impersonating logged in user account.
- IME agent starts application polling to query available/required Win32 app.
- IME agent gets application policy (detection/applicability/extended requirement check details).
- IME agent checks if the application as queried has any dependencies declared.
- IME agent post dependency check, if the app is standalone, starts running the Detection Logic
- For MSI code based detection, SideCar will run a WMI query against the MSI code defined.
- For Path-based detection, SideCar will traverse the PATH as defined to check the presence.
- For Registry-based detection, SideCar will check the specified reg_path for the presence of the reg_key and its value.
- For a custom script based detection, SideCar ExecManager will trigger the script, and based on the exit status of the script will determine the result.
- Only if pre-install detection is determined as False, IME agent will check the applicability and extended requirements.
- If all parameters are satisfied, the IME agent will proceed with the download of the package. A corresponding BITS job gets created for the same.
- Once the download job is complete, it will check the package integrity, decrypt the package using the encryption info as provided in the content response, and unzip the content to IMECache.
- IME agent creates the installer process in Machine/User session based on app deployment context.
- Post execution of installer process, IME agent runs the Detection rules once more to confirm the installation.
- Only if post-install detection is determined as True, the app install is deemed a success by the IME agent.
- Based on the post-install detection result, IME sets the compliance state and creates app report to be sent back to service.
- The report is sent and locally saved to cache.
- IME agent stops the current app polling session.
Relating errors to each phases of IME in which it handles a win32 app
The error that you get from the Intune portal for a Win32 app deployment can be due to an error in the win32 app handling by the IME agent at any of the phases as discussed above. As such, it is important to relate the displayed error to its source in order to identify if the error is due to
- The app package itself (problems with the source), or
- Any configuration issues while creating the app in Intune (problem with detection or other config), or
- Network related issues (problem with delivery and download of the package).
So let’s start and see what all probable errors you might get in each phase of the Intune Management Extension while the IME agent processes a Win32 app deployment on the endpoint.
IME Win32 SideCar Agent Polling Phase Start
In order for IME to work, it needs to get the token. It fetches the same by querying the current logged on user profile.
With the AAD token, IME then proceeds to the next phase where it reaches out to the service to get the application policies as made available to the user/device
As you can understand, the most common error that can occur in this phase is due to IME unable to get the token. In such case, you can expect to see a log entry like below
Or, if you have AAD joined post OOBE setup from Settings, unless you switch user and log-in with your AAD account, you would expect to get this
Retrieve App Metadata
Once IME has got the token, it checks the current proxy and sends a network request to the service to fetch the Win32 apps (policies)
The result as received is used by IME to get the detection methods, applicability checks and requirements checks as configured for this app.
Error that can occur in this phase is due to network connectivity resulting Failed to retrieve content information(0x87D30065)
Pre-Install Detection Check
Detection can be based on Registry, MSI Product code or File Path as configured while creating the app in Intune portal
It can also be a custom script as well, where the IME will trigger the script and the detection result will be based on the exit status of the script.
Error that can occur in this phase is caused due to improper detection logic which will cause IME to skip further processing the app. Sample error in log show like this
This is when IME processes the settings as specified in the app policy to check if the system meets the requirements.
Error that can occur is when IME fails to query the requirements which can be due to generic system issues
In such cases, it will might report back with error Unknown (0x87D30000). The other common errors you can get are
- Device architecture (e.g. x86/amd64) is not applicable for the application.
- OS version on the target device is less than the configured minimum.
Extended Requirements Check
If any additional requirements has been specified in app, IME checks if the system satisfies the same.
Error in this phase depends if the IME encounters any System Exception while querying the specified rules or if a custom script is used for the purpose, then the exit code of the script.
Most common error in this phase would be RegistryRequirementNotMet. In both Applicability check and Extended Requirement check, if the specified requirement is not met, you can expect a log entry like this
This is the phase where IME downloads the app package (.intunewin) from the Intune CDN to the device. The download is done to path C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming
Error that can occur in this phase is usually due to network and dependency on the BITS service which handles the download job as created, resulting in errors not limited to
- Unknown (0x87D30000) – the error which is reported when the last step is defined as success but the current step has no defined output
- Incorrect function (0x80070001) – generally related to invalid tasks
- The unmonitored process is in progress, however it may timeout. (0x87D300C9)
- Error downloading content. (0x87D30068)
- The content delivery network used for downloading application content timed out. (0x87D3006A)
- The physical resources of this disk have been exhausted (0x8007013A)
Integrity Check and Unzip the package
Post download the file is moved to the path C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Staging\ where the IME checks the integrity of application package as downloaded.
At this point, you can encounter the error The system cannot find the file specified. (0x80070002) which happens due to AV. It is recommended to exclude the locations as used by IME to be monitored by an AV as it may interfere in the process.
Post successful integrity check and decryption, the file (this is the .intunewin file as present within the Contents subfolder of the IntuneWinPackage folder) is unzipped to location C:\Windows\IMECache\
Error that can occur during this phase are
- Error unzipping downloaded content. (0x87D30067)
- The physical resources of this disk have been exhausted (0x8007013A)
- Incorrect function (0x80070001)
- Unknown (0x87D30000)
IME starts the execution and sets the retry count (there is a total of 3 retry with 5 minutes interval).
Flow for app in User Context
It creates the installer process by fetching an elevated token for the current user if the app is in User Context. Not very common, but if IME fails to get an elevated token for the user, can result in Access is denied. (0x80070005)
Before IME could create the installer process, if a change in session is detected like log-off, it will cause an error like below resulting The user logged off while the app policy was being processed. (0x87D300CD)
Flow for app in Device Context
You can safely ignore that StatusService warning.
The installer process as created by IME has a predefined timeout of 60 mins. If the process fails to install the application during this time, which may be due to system activity (high CPU utilization), in such case results
- Unknown (0x87D30000)
- The unmonitored process is in progress, however it may timeout. (0x87D300C9)
In general, the errors that can occur in this phase are directly related to the application and is usually thrown by the IPExitCode or lastHResult. For example, if the installation is triggered via a script, then the IPExitCode will define Success or Error.
This is where you will mostly see the undefined errors as thrown by LastHResult like this
If the installer process fails, IME has a retry check of 3 – it tries 3 times to get the app installed if it encounters any failure during a processing cycle. The retry interval is 5 mins from the last failure. However, for each retry, IME will start from the beginning of the app processing phase, as such the detection, applicability, extended requirements will again be checked. When it comes to the download phase, it will not again initiate a download but will find the app package from Cache itself.
This is because the contents of the C:\Windows\IMECache\ folder is cleaned up post successful install only. At this point, you are most likely to encounter the error The system cannot find the file specified. (0x80070002) which happens due to AV.
Post-Install Detection Phase
This is the phase where IME triggers the detection manager to execute the detection rules once more to confirm the app install status. Even if the installation is actually done but the detection rule is not capable of checking the right place, will result in IME report the same as a failure.
Error in this phase is caused again due to improper detection logic
A change in session at this stage will cause IME to report back as The application was not detected after installation completed successfully (0x87D1041C).
Set Compliance State
This is the phase where IME sets the compliance for the app policy as based on the outcome of Installation phase and Post-Install Detection phase results, cleans the contents from IMECache folder and creates the app report.
Same as above, if a change in session is detected, will result The application was not detected after installation completed successfully (0x87D1041C). If the install is success but the post install detection result is false, it will still report as an error as below.
Report Status to Service
The last phase of app processing where IME sends the result to the service and saves the results locally.
IME can fail to send the report and save it for below reasons
- Network connectivity issue
- User logs off before IME can send the final app results or any Session change detected
- System goes to sleep due to inactivity
which all points to the same error The application was not detected after installation completed successfully (0x87D1041C)
In case where the IME client itself faces some error, it might cause the Client error occurred (0x87D300CA)
and requires evaluation of the ClientHealth.log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
The Client Health evaluation is performed every 8 hours.
Since in Available app flow, the application is not enforced by Intune but depends on the user, hence IME does not re-evaluates the app status again if it fails in the 1st instance. In case of Required app flow, IME will continue to re-evaluate each app result in each cycle.
As such even if the application was installed but due to any issues as mentioned reported as “The application was not detected after installation completed successfully (0x87D1041C)”, IME won’t re-evaluate to correct it in the subsequent sync cycles.
But for a required application, even if it reported as an error (unless an error which is related to the package itself), there is a good chance that it will be corrected in the subsequent sync cycles.
That was all. Hope you would find this post useful.
Starting 1st Jan 2021, I have started my own blog site. You will find all my latest posts on Intune here at joymalyabasuroy.com
- Intune Standalone – Win32 app management
- Convert MSI package to IntuneWin
- Intune Win32 App Troubleshooting Client Side Process Flow
- Intune Application Model Deployment Guide