Hi, and welcome to today’s post, “Easily track Windows 10 Intune App deployments from the Endpoint – Support Help #2.“
This is a continuation of my previous post, Easily track Windows 10 Intune MDM policies—Support Help #1, in which I explained how to use the Windows registry and events to troubleshoot Windows 10 Intune MDM policy deployment issues.
Today, we will continue on the same journey, exploring how to troubleshoot Intune app deployment issues using the Windows 10 registry and events.
Let’s get started.
- New Corporate Device Identifiers for Windows in Intune
- Install SysInternals Suite on Windows Device using Intune
- How to Easily Disable Local Drive Redirection with Intune
- Microsoft Introduces New Windows Enrollment Attestation Feature in Intune
- Intune MAM Benefits Available for Windows 365 and AVD
- New Appearance for Intune Company Portal App for Windows
Types of Intune-Supported App Deployment for the Windows 10 Platform
As highlighted below, Intune supports various app types and deployment scenarios for the Windows 10 platform.
- Weblink for internal web apps
- MSfB Online/Offline Apps [Store Apps]
- M365 Apps (O365 Pro Plus package)
- Microsoft Edge
- LOB app (.msi, .appx, .appxbundle, .msix, and .msixbundle)
- Win32 (.exe wrapped as .intunewin)
However, all would agree that, as Intune IT Pros, we must deal with issues related to LOB and Win32 app deployments on the Windows 10 platform daily.
Since I have already covered the troubleshooting of the Win32 app deployment on my blog, Management Extension Level 3 Troubleshooting Guide Intune Win32 App, I thought of keeping the focus of this article on the support of the Windows 10 LOB app deployment from Intune.
Understanding Intune Windows 10 App Deployment High-level Flow
I always believe that for effective troubleshooting, an engineer should grasp the overall flow to understand the breakpoints involved and determine the cause of the fix accordingly. – Joymalya Basu Roy
So first, let us understand the high-level flow of Windows 10 app deployment from Intune.
Consider an application created in Intune for Windows 10. Regardless of the type of app being developed, Store app, LOB app, or weblink, Intune will create an Application object identifiable via a GUID.
The Application Object is stored in the Azure Blob Storage, which every Intune tenant comes with. It stores all policy configuration settings and serves the Intune CDN for delivery and deployments.
If the app object is a Microsoft Store App, the object content is a deep link to the respective Store app, and the Store services handle the app’s deployment.
For a Microsoft Store for Business app,
- If the app type is offline and free of charge, Intune will handle the deployment.
- If the app type is Online, the Store services handle the deployment.
For more info on the above, check here.
If it is a LOB app, the object content will contain the app package uploaded during creation. Intune will handle the app deployment, and the Intune CDN will serve the app.
Now, an app can be deployed as an available or required app.
The flow of actions below provides an overview of the process depending on the deployment type.
Application Deployed as Available
- The user opens the Company Portal app on the endpoint (or can be accessed via the web: https://portal.manage.microsoft.com/)
- User searches for the app
- The user initiates the app installation by clicking the Install button, which triggers the DownloadInstall action.
Application Deployed as Required
- Intune will initiate a Push Notification to invoke the DM Client of the endpoint.
- Push Notification Provider (WNS) will notify the DM client on the target device to initiate a connection to the service.
- DM client then initiates a connection to the management server. An OMA-DM session starts.
- Intune sends the app instruction with the intent DownloadInstall or StoreInstall [Trigger the application installation depending on whether the app is a LOB or a Store app]
The DM client knows if the app install instruction as sent is for a Store App or LOB app by reading the LocURI Element of the SyncML instruction.
- If it is a Store app, the DM client invokes the EnterpriseModernAppManagement CSP, which handles the rest.
This is what the SyncML instruction from Intune looks like, which the endpoint receives.
<Add> <CmdID>xx</CmdID> <Item> <Target> <LocURI>./User/Vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/Microsoft.Office.Sway_8wekyb3d8bbwe</LocURI> </Target> </Item> </Add> <Exec> <CmdID>xx</CmdID> <Item> <Target> <LocURI>./User/Vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/Microsoft.Office.Sway_8wekyb3d8bbwe/StoreInstall</LocURI> </Target> <Meta> <A:Format>xml</A:Format> <A:Type>text/plain</A:Type> </Meta> <Data><Application id="9WZDNCRD2G0J" flags="1" skuid="0016" /></Data> </Item> </Exec>
As an overview, the request is redirected to the respective Store via the deep link, and the Store handles the rest of the delivery mechanism and installation.
- If it is a LOB app (as shown above), the DM client invokes the EnterpriseDesktopAppManagement CSP, which handles the rest.
This is what the SyncML instruction from Intune looks like when received by the endpoint.
<Atomic>
<CmdID>xx</CmdID>
<Add>
<CmdID>xx</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/DownloadInstall</LocURI>
</Target>
</Item>
</Add>
<Exec>
<CmdID>xx</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/DownloadInstall</LocURI>
</Target>
<Meta>
<A:Format>xml</A:Format>
<A:Type>text/plain</A:Type>
</Meta>
<Data><MsiInstallJob id="{D3BC954F-D661-474C-B367-30EB6E56542E}"><Product Version="2.1.8.105"><Download><ContentURLList><ContentURL>https://fef.msuc02.manage.microsoft.com/ContentService/DownloadService/GetAppActive/WinRT?contentGuid=8edd097e-6f04-4919-a211-2ed5476240bd&amp;fileNameHash=e35b30c2-e68a-4cd8-aa5d-7ef8bb798cbc.msi.bin&amp;api-version=1.0</ContentURL></ContentURLList></Download><Validation><FileHash>C73D373275519DE5545824FF20E886E4C2D76770CB77F8B685C0B52A1C07E97D</FileHash></Validation><Enforcement><CommandLine>/qn</CommandLine><RetryCount>5</RetryCount><RetryInterval>3</RetryInterval></Enforcement></Product></MsiInstallJob></Data>
</Item>
</Exec>
</Atomic>
As an overview, a BITS download job is created to download the package from the Intune CDN, followed by an Exec operation during which the app is installed.
The difference in how the app deployments are handled on the endpoint based on the app type can be further understood by the difference in the Exec command that Intune sends for the two different app types.
- For an MSI LOB app, the
EXECinstruction isDownloadInstall - For a Store app, the
EXECinstruction isStoreInstall
Windows 10 Intune App Deployment Issues – LOB (MSI) Application
As stated above, MSI App deployment from Intune is taken care of by the EnterpriseDesktopAppManagement CSP on the endpoint, which the DM Client will invoke when it receives instructions from Intune to install a LOB app.
Tracking Intune Windows 10 LOB App Deployment via Windows Events
You can track LOB app deployments (for both Available and Required) using Windows events as shown below.
Event 1901, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: A node instance of was created successfully. MSI ProductCode: {D3BC954F-D661-474C-B367-30EB6E56542E}, MSI UpgradeCode: null, User SID: (S-0-0-00-0000000000-0000000000-000000000-000).
As seen in Intune, MSI app deployment on the endpoint is tracked against the MSI product code, not the App GUID.
Event 1904, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: MDMAppInstaller task has started.
A LOB (MSI) app deployment is a two-phase process on the endpoint –
- The download of the app package to the local storage on the endpoint
- Execution of the app package for the actual install
As such, once the app instance node is created, you will see a corresponding BITS job being created to get the MSI package downloaded from Intune CDN to the endpoint.
Event 1905, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: Application content download started. MSI ProductCode: {D3BC954F-D661-474C-B367-30EB6E56542E}, User SID: (S-0-0-00-0000000000-0000000000-000000000-000), BITS job: (9274a627-e068-4323-a9f1-528080e7ba72).
You will get information on the corresponding BITS jobs from the BITS-Client events, which can help you trace any errors you may have faced during the download phase.
If the download phase has encountered no errors and the BITS job is completed successfully, you will receive the corresponding. DM-Ent-Diag-Prov event as below
Event 1906, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: Application content download completed. MSI ProductCode: {D3BC954F-D661-474C-B367-30EB6E56542E}, User SID: (S-0-0-00-0000000000-0000000000-000000000-000), BITS job: (9274a627-e068-4323-a9f1-528080e7ba72).
However, if there are any errors in the download phase, the BITS-Client events for the download job would help you understand the issue.
Once the package download is complete, the next phase starts: Executing the app package for the installation.
To which path is the MSI app package downloaded to the local storage on the endpoint?
The MSI app package is downloaded to the local storage path. C:\Windows\system32\config\systemprofile\AppData\Local\mdm
The above path is a temporary cache location.
Once the installation is successful, the downloaded app package file is purged. If only the installation fails, you will find the downloaded app package file here with the MSI product code as the file name.
How do we know that this is the location to which the app package is downloaded?
Well, the answer is there in the MsiInstaller events [Application Events].
Event 1040, MsiInstaller [Application Events]
Beginning a Windows Installer transaction: C:\Windows\system32\config\systemprofile\AppData\Local\mdm\{D3BC954F-D661-474C-B367-30EB6E56542E}.msi. Client Process Id: 5596.
Note the location from where the app install is being triggered!
If the installation is successful, you would get a Success event as below.
Event 11707, MsiInstaller [Application Events] Product: Microsoft Garage Mouse without Borders - - Installation completed succesfully.
And the end of the process.
Event 11707, MsiInstaller [Application Events]
Ending a Windows Installer transaction: C:\Windows\system32\config\systemprofile\AppData\Local\mdm\{D3BC954F-D661-474C-B367-30EB6E56542E}.msi. Client Process Id: 5596.
Else you would be seeing an Error event for the MsiInstaller process, using which you can further diagnose why the app package failed the install.
One of the most common causes of MSI app install failure is an issue with the command line provided to trigger the silent install, or the package itself does not support silent install as it requires user input to continue with the setup.
The MSI app package must be able to install silently for Intune to successfully deploy it on the endpoints.
For success, you would get the corresponding event in DM-Ent-Diag-Prov Events
Event 1922, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: An application install has succeeded. MSI ProductCode: {D3BC954F-D661-474C-B367-30EB6E56542E}, User SID: (S-0-0-00-0000000000-0000000000-000000000-000), Result: (The operation completed successfully.).
Whether the Execution exit status is a Successor or an Error, a Status Alert is sent to Intune to update the management service regarding the final deployment status for the current iteration.
Intune, as a management service, queries the endpoint on the current transaction status for the app deployment.
<Get> <CmdID>xx</CmdID> <Item> <Target> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/Status</LocURI> </Target> </Item> </Get> <Get> <CmdID>xx</CmdID> <Item> <Target> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/LastError</LocURI> </Target> </Item> </Get> <Get> <CmdID>xx</CmdID> <Item> <Target> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/LastErrorDesc</LocURI> </Target> </Item> </Get>
And this is how the DM Client responds.
<Results> <CmdID>xx</CmdID> <MsgRef>xx</MsgRef> <CmdRef>xx</CmdRef> <Item> <Source> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/Status</LocURI> </Source> <Meta> <Format xmlns="syncml:metinf">int</Format> </Meta> <Data>70</Data> </Item> </Results> <Results> <CmdID>xx</CmdID> <MsgRef>xx</MsgRef> <CmdRef>xx</CmdRef> <Item> <Source> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/LastError</LocURI> </Source> <Meta> <Format xmlns="syncml:metinf">int</Format> </Meta> <Data>0</Data> </Item> </Results> <Results> <CmdID>20</CmdID> <MsgRef>5</MsgRef> <CmdRef>11</CmdRef> <Item> <Source> <LocURI>./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7BD3BC954F-D661-474C-B367-30EB6E56542E%7D/LastErrorDesc</LocURI> </Source> <Data>The operation completed successfully.</Data> </Item> </Results>
SyncML messages are thanks to SyncML Viewer by Oliver Kieselbach.
The corresponding events in the DM-Ent-Diag-Prov
Event 1927, DeviceManagement-Enterprise-Diagnostics-Provider
EnterpriseDesktopAppManagement CSP: An application status alert was sent to the device management service. LocURI: (./Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/{D3BC954F-D661-474C-B367-30EB6E56542E}/DownloadInstall), Alert Data: (0x0).
Event 1912, DeviceManagement-Enterprise-Diagnostics-Provider EnterpriseDesktopAppManagement CSP: The MDMAppInstaller process is terminating with no errors.
Tracking Intune Windows 10 LOB App Deployment via Windows Registry
DM-Ent-Diag Provider Event ID 1901 states that the app instance node creation creates the Registry’s app entry. All the information provided above can also be easily tracked using the Registry to trace deployment issues.
LOB app deployment details can be checked from the following registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement
There will be two sub-keys corresponding to the
- system SID (all zeros) [will list all device context MSI deployments]
- user SID [will list all user context MSI deployments]
Under those subkeys, you will find the MSI app deployments from Intune listed using the package’s MSI Product ID.
The essential keys within an app entry are below.
AssignmentTypeSignifies the deployment, whether the assignment is Required or AvailableBITSJobIdpoints to the download job created to download the app packageCurrentDownloadUrlPoints to the Intune CDN from where the package will be downloadedCommandLineshows the install command defined while creating the app package in IntuneStatusShows the enforcement status, whether Successful or Failed.
The table below shows the possible values that you may encounter for Status
| Meaning | Value |
|---|---|
| Meaning | Value |
| Initialized | 10 |
| Download In Progress | 20 |
| Pending Download Retry | 25 |
| Download Failed | 30 |
| Download Completed | 40 |
| Pending User Session | 48 |
| Enforcement In Progress | 50 |
| Pending Enforcement Retry | 55 |
| Enforcement Failed | 60 |
| Enforcement Completed | 70 |
The Registry will also give you more critical information if you work with a failure scenario.
EnforcementRetryCountSignifies the number of times the enforcement will be retried or re-attemptedEnforcementRetryIndexsignifies the current retry valueEnforcementRetryIntervalSignifies the time in which the successive retry will be attempted (in minutes)EnforcementTimeoutIs the time till which it will wait for the installer process to complete and report Status (30 mins default)LastErrorShows the Status of the last retry attempt
Suppose the install fails to download the LOB app package successfully. In that case, the install execution is attempted thrice for the current enforcement before the Global Re-evaluation Scheme (GRS) kicks in and blocks any further retry attempts for the next 24 hours. [Applicable for Required assignment]
To manually re-trigger the enforcement again for a LOB deployed with the Required intent, you need to
- clear the values for
LastErrorandStatus - Reset values of
EnforcementRetryCountandEnforcementRetryIndexto 0
If you need further help troubleshooting MSI app deployment, read this excellent blog, which is available on the Microsoft Tech Community blogs.
Windows 10 Intune App Deployment Issues – Store Application
As stated earlier, the EnterpriseModernAppManagement CSP on the endpoint takes care of Store App deployment from Intune, which the DM Client invokes when it receives instructions from Intune to install a Store app.
Intune, as a management service, only invokes the endpoint’s DM Client to start the transaction. However, it is just a deep link to the Store. The Store services and the OS platform take care of the delivery and installation.
When it comes to tracking Store app deployments, I was only able to get to see the apps being deployed from Intune here at reg_path HKLM\Software\Microsoft\EnterpriseResourceManager\Tracked\{Enrollment GUID}\
I was also able to view deployment-related events from under.
Application and Services Logs > Microsoft > Windows > AppXDeployment-Server/Operational
Application and Services Logs > Microsoft > Windows > Store/Operational
Intune Sidecar deployments (Win32 and PS Scripts)
Win32 application deployments from Intune are via the Intune Sidecar, a.k.a Intune Management Extension.
The IME agent is an MSI app package that gets deployed to the endpoints automatically if Intune evaluates that there is a PS script or Win32 app deployment and that the endpoint meets the prerequisites of Intune Sidecar.
As such, in issues related to the IME agent installation, you can check the status above using information from the Registry and events.
As I last checked, support of PS script (IME agent as such) for Azure AD registered devices (which means BYOD, yeah!) is a feature in development, documented here in the Microsoft post.
PowerShell Scripts Information from Registry
- User Targeted – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\{UserGUID}\{ScriptGUID}
- Device Targeted – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\{0000}\{ScriptGUID}
You can refer to this blog post from Oliver Kieselbach for further troubleshooting help on PS script deployment issues.
Win32 Apps Information from Registry
- User Targeted – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\{UserGUID}\{AppGUID}
- Device Targeted – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\{0000}\{AppGUID}
You can collect IME logs from the location-C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
For more detailed troubleshooting help related to Win32 apps, refer to my article here.
In my article on Endpoint Analytics, I already covered how you can track Health Scripts, a.k.a. Proactive Remediation script packages since they utilize the same IME architecture on the endpoint. Please Give it a read!
If you have yet to use Endpoint Analytics or are planning to use it but have doubts, I would recommend giving it a try. Endpoint Analytics is in GA and not in preview anymore!
The End
I hope the information above will help you with Windows 10 Intune App deployment issues.
Well, that was all for today. Continue staying safe!
Additional articles you may want to check:
- Intune Win32 App Troubleshooting Client-Side Process Flow
- Troubleshoot Intune Deployments – Applications Policies Profiles Intune Issues
- Intune Win32 App Failure Log Collection Backend Secrets
- Intune Management Extension Level 3 Troubleshooting Guide Intune win32 App
- Windows 10 MDM Log Checklist – Ultimate Help Guide for ITPro #1
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost five years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect at Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his blog site, MDM Tech Space, at https://joymalya.com
Excellent Post
Hermitcraft 6: Completing My INSANE Idea
Brilliant! M365 app showed as not installed, though it was. Tried re-installing but just showed “downloading” forever. The Bits log had the entry to repair the installation. Did that and all fixed!
Nice Post ! As you have shared the syncML instruction for an app installation from windows app store, I wanted to know what would be the syncML instruction to uninstall a windows app store app?
Thanks for sharing. For the #Store-Application part, the order of the second image and the third image needs to be changed