Support Tip: Troubleshooting MSI App deployments in Microsoft Intune

Published 03-04-2019 09:32 AM 35.4K Views

Hello everyone, today we have an article from Intune Support Engineer Leon Zhu. In this post, Leon talks about deploying MSI installer packages and how you can troubleshoot problems if the app fails to be installed on targeted devices. Leon has some really great tips in here so even if you’re like most people and never had an issue, I’d suggest giving it a quick read regardless. It will help with understanding how the overall process works, and if you do happen to run into a problem in the future, his tips will put you well down the path of getting them resolved quickly and easily.  




Intune is a great way to deploy Windows LOB apps to PCs in your environment, and today I want to talk a little bit about how that process works and share some tips you can use to help resolve any issues you might run into.


Here in support, when we talk to someone having an issue deploying an MSI package it usually goes something like this: An app deployment profile was created for a Line of Business (LOB) app using an MSI installer package, however after assigning the profile to a group of users you find that some devices fail to install the app. When we see an issue like this, it’s usually caused by one of two things:


  • The MSI failed to download
  • The setup process for the MSI failed

With that in mind, if you find yourself in this situation the first thing to do is check whether the MSI has been downloaded. Downloaded MSI packages are stored in C:\Windows\System32\config\systemprofile\AppData\Local\mdm so take a look in there and see if you can find your MSI. Typically the size and date are good ways to determine which one is the package you’re looking for.


If you cannot see the MSI file, start with the section titled MSI Fails to Download below. If you can see the file, go to the section titled MSI Fails to Install further down the page.


MSI fails to download

If the MSI is failing to download, the first thing to check is whether the job for the MSI has been created in the Registry:


  • For MSIs targeted to devices, look in HKLM\SOFTWARE\Microsoft\EnterpriseDesktopManagement\S-0-0-00-0000000000-00000000000-00000000000-0000000000-00\MSI\<MSIProductID>
  • For MSIs targeted to users, look in HKLM\SOFTWARE\Microsoft\EnterpriseDesktopManagement\<UserSID>\MSI\<MSIProductID>

Here is an example showing what we might see for an MSI targeted to a user:




As you can see, there is some pretty useful information contained in these values, such as:

  • CurrentDownloadUrl: URL to the MSI install file.
  • EnforcementRetryCount: The number of times the download and installation operation will be retried before the installation will be marked as failed.
  • EnforcementRetryIndex: The current number of retry.
  • EnforcementRetryInterval: Amount of time, in minutes between retry operations.
  • EnforcementStartTime: Start time of enforcement.
  • EnforcementTimeout: Amount of time, in minutes that the installation process can run before the installer considers the installation may have failed and no longer monitors the installation operation.
  • LastError: Error after last execution.
  • Status:

70 = Successfully installed/uninstalled

10 = Initialized

20 = DownloadInProgress

25 = PendingDownloadRetry

30 = DownloadFailed

40 = DownloadCompleted

48 = PendingUserSession

50 = EnforcementInProgress

55 = PendingEnforcementRetry

60 = EnforcementFailed

70 = EnforcementCompleted


NOTE For the complete list of values see this doc.


Depending on the specifics of your issue and what you’ve tried already, you may want to try triggering the installation again. To do so, set EnforcementRetryCount and EnforcementRetryIndex to (0) and set LastError and Status to an empty string.


The next thing to look at is the BITS job. The MSI download uses BITS, so if the job was successfully created we can verify that by finding the BITS job ID in the Registry. Once you find it make a note of it as we’ll use it later.




We can also verify the BITS job by looking in the Event Log. The BITS Event Log is found under Applications and Services logs -> Microsoft -> Windows -> Bits-Client -> Operational.


If the BITS job was created, you will see that in an Event ID 3:




You should also see an Event ID 4 which tells us that the download completed.




Here’s an example where the BITS download failed. Our first clue is that we can see an error in the BITS event log where the job was cancelled:




By searching for other events and errors you can usually gain some insight into why the job has failed. Here we find an Event ID 204 telling us that the BITS job failed because of a network authentication problem (the credentials were rejected).




Armed with this information, we can then check our network or proxy settings to identify the cause of the issue. Your error may differ but this should give you a good idea where to look.


MSI Fails to Install

In this example we can see our MSI installation package in the path C:\Windows\System32\config\systemprofile\AppData\Local\mdm.

This tells us that Intune has successfully delivered the package to the device, so now the question is why did the install fail.



The first step in answering that question is to run the following command from a Command Prompt on the PC:


msiexec /I <packagename>.msi /l*v %temp%\msiverbose.txt /qn


This command will try to install the MSI package silently and generate verbose logging for us to use when investigating the failure.


NOTE For more information about command line installation, see


Going through all of the potential issues you may encounter when analyzing a verbose MSI log is beyond the scope of this article, however if you scroll to the end you can usually get some sort of an idea where to look next when doing your troubleshooting.


IMPORTANT For Intune to deploy an MSI package, the MSI must be able to install silently. If the MSI package requires any user interaction the deployment will fail. It can be difficult to tell which packages support a truly silent install, so it is always a good idea to test with the /qn switch manually before deploying your package.


Assuming the command works and our package can be installed silently, we can then check the MDM event log (Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin) and see if it contains any useful information for why the installation failed.


Let’s say for example that we tried deploying the PowerBI MSI package and we found following error in the event log:


Product: Microsoft Power BI Desktop (x64) -- EULA has not been accepted while executing the installation in reduced UI mode. Please add the flag ACCEPT_EULA=1 to the command line.

Windows Installer installed the product. Product Name: Microsoft Power BI Desktop (x64). Product Version: 2.61.5192.601. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.


Based on this information we can see that the MSI was unable to install silently because the setup process prompted to accept the EULA. Using that, we can update the command-line arguments in the app deployment profile to confirm our acceptance of the End-User Licensing Agreement which will allow the PowerBI package to be installed successfully:




Once that change is made, setup for our MSI package now completes silently and the app is successfully deployed.



When troubleshooting software deployment problems with MSI packages, break your troubleshooting down into two parts: downloading the package and installing the package. First make sure that the download is successful by ensuring that the package reaches the targeted device. If the package is downloaded but the installation is failing, you then focus on why the setup process for the app fails to complete.


Leon Zhu

Intune Support Engineer






Very nice post :thumbs_up: and indeed very helpful for a lot of people dealing with Intune imho. I did a similar post series in the past covering all related information about the Intune Management Extension (aka Sidecar) including the installation via MDM CSP:


Deep dive Microsoft Intune Management Extension – PowerShell Scripts


Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts


Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps


keep writing and publishing good posts like this. 



Occasional Contributor

Wow nice post thanks!

You mention 'Downloaded MSI packages are stored in C:\Windows\System32\config\systemprofile\AppData\Local\mdm ' does MSI always have a GUID in the downloaded folder and does it not have the name as we upoad it ?




Hey RKast :-),


yes it has always the GUID, actually it's not only a GUID it's the ProductCode of the MSI file you are deploying.




Occasional Contributor

Hey Oliver,

Good to see you here too :)

Thanks, the productcode is something we know/can find easily and thus we can identify the MSI more quickly cause we have customers where multiple MSI apps are being deployed.

Funny thing is that we encountered a failed MSI deployment today so this is more than welcome.


PS. also big thanks for you blog posts and articles!


Awesome blog!!


This is great stuff!!

Occasional Visitor



I had an issue with an app installation because I used the wrong installation parameters. I fixed the install paramaters but the installation status is already failed. How can I reset this status so it will retry installation? Or will it retry indefinitely?


kind regards,


Not applicable
Great Article. I'm a bit confused about the BITS Id though, shouldn't the transfer be using Delivery Optimization ?
Occasional Visitor

We are evaluating Intune and ran into an issue with a MSI, no transform, with advertised shortcuts and HKCU registry settings.  Normally on first use of the HKCU registry settings get populated with an MSI self repair but with an Intune install it cannot find the MSI to perform the repair.  It's looking in the folder C:\Windows\System32\config\systemprofile\AppData\Local\mdm folder for the MSI but it is no longer there.  Looing at the Uninstall registry key that was the source location during the install.  Is there a setting we are missing to leave the MSI there for these kind self repairs?

Senior Member

@Daniel_Reynard I was having the exact same issue today and it took me half a day to even understand the root cause. Thanks to this article and you identifying advertised shortcuts as a possible source of the problem, I came across this uservoice request: Alas, there seems to be no solution in sight. It looks like deleting the msi from the mdm folder after install was deliberately introduced by MSFT a while ago, and they don't consider self-repairing packages relevant.

Anyway, I was able to solve the problem by editing the msi with the free edition of Master Packager. All it took was making the program shortcuts not advertised, and it immediately worked when deploying the updated package with Intune. Only downside is that editing the msi breaks the signature of the package, but that's something I can live with. 



Version history
Last update:
‎Mar 04 2019 09:37 AM
Updated by: