This post has been republished via RSS; it originally appeared at: Intune Customer Success articles.
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 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:
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