Support Tip: Troubleshooting MSI App deployments in Microsoft Intune
Published Mar 04 2019 09:32 AM 88.8K Views
Microsoft

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.

98445-1.jpg

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\EnterpriseDesktopAPPManagement\S-0-0-00-0000000000-00000000000-00000000000-0000000000-00\MSI\<MSIProductID>
  • For MSIs targeted to users, look in HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAPPManagement\<UserSID>\MSI\<MSIProductID>

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

 

98445-2.png

 

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.

 

98445-3.png

 

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:

 

98445-4.png

 

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

 

98445-5.png

 

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:

 

98445-6.jpg

 

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).

 

98445-7.jpg

 

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.

 

98445-8.jpg

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 https://docs.microsoft.com/windows/desktop/Msi/command-line-options

 

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:

 

98445-9.png

 

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

 

Summary

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

 

Post updates

9/1/21 - Updated "EnterpriseDesktopManagement" to include "EnterpriseDesktopAPPManagement".

14 Comments

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
https://oliverkieselbach.com/2017/11/29/deep-dive-microsoft-intune-management-extension-powershell-s...

 

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

https://oliverkieselbach.com/2018/02/12/part-2-deep-dive-microsoft-intune-management-extension-power...

 

Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps
https://oliverkieselbach.com/2018/10/02/part-3-deep-dive-microsoft-intune-management-extension-win32...

 

keep writing and publishing good posts like this. 

best,

Oliver

Brass 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 ?

 

Greets,

RKast

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.

 

best,

Oliver

Brass 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!

Microsoft

Awesome blog!!

Copper Contributor

This is great stuff!!

Copper Contributor

Hi,

 

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,

Ramon.

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

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?

Copper Contributor

@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: https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/20017999-retain-intune-cached-.... 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. 

 

 

Copper Contributor

This is great already.  One section I'd like to see added is diagnosing "Download Pending...Your device is syncing" stalled installation.  In my case for 2 win32 apps on a company device that is compliant, with a main user who is licensed, this happens and I don't see any entries in HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAPPManagement

Iron Contributor

When I navigate to the 'config' folder, I have to take admin access to look in it.  I never like doing this because it means I'm breaking some form of "security" Microsoft has implemented.  Any way around that?

Steel Contributor

My issue is that the MSI package is downloading daily, sits at "Install Pending" and never stops.  There are now 9 x1Gb files locally and InTune never removes them.  I've found the MSI BITSJobId in the registry yet it's not in event viewer so I have nothing to go on.  Microsoft support closed my case and even our Microsoft Partner cannot figure it out.

 

The Status in the registry is a 50 which doesn't help.  The MSI command runs fine from command prompt so there is no issue with it.  

Copper Contributor

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

 

That is msiexec /i

and the /l*

 

is an lower case L

Co-Authors
Version history
Last update:
‎Sep 01 2021 09:18 AM
Updated by: