Home > Blogs > VMware ThinApp Blog

Invalid MSI and Why

Some people have mentioned getting an “Invalid MSI” error when attempting to incorporate ThinApp package MSIs into their View environment via the View Management Console. As there are a various causes to the generation of this error, I wanted to go over some of the more common reasons why this is seen and how to resolve each of these.

“Invalid MSI” – What does that mean and why am I seeing it?

While I admit, this error is somewhat obtuse in it’s explanation, essentially what is happening is the ThinApp SDK code residing within View is looking at the ThinApp package MSI and getting an error – then reporting to the View Management Console as such. This is what kicks out the error we see here.

Invalid MSI

What causes this and how can I resolve it?

To date, there are three major causes for this error:

  1. The ThinApp package MSI was created with MSIStreaming=1 (or MSIUseCabs=0 for ThinApp 4.5 and older) but the EXEs/DAT do not reside in the folder with the MSI where View is being directed to look at for a ThinApp repository.
    • To resolve this, ensure you copy the EXEs/DAT along with MSI and ensure the MSI and EXEs/DAT all reside in the same folder. For more information specific to this scenario, see VMware KB 1028385.
  2. While this second scenario isn’t specifically around the “Invalid MSI” error, incorrect Security Settings have been known to cause a variety ThinApp deployment issues within View along with the “Invalid MSI” error in discussion here. Specific issues lie around the following:
    • File Share security where the EXEs/DAT/MSI reside. For this to work properly, Users must have both READ and EXECUTE permissions. This is especially pertinent when the customer is using a non-SMB type of share such as a NetApp Filer as it uses CIFS while Windows uses SMB. The “READ” and “EXECUTE” permissions in a CIFS environment are two separate settings while in SMB it is one and the same. Often times Network Administrators more familiar with Windows environments can overlook this as it’s somewhat of an obscure setting.
    • Default View Manager service accounts are being used. This second security type of cause is the View Management Console Services install using the Local System account by default. This is not due to any issues in code or packages, but rather due to unawareness of default settings as, when combined with restrictive file share security (discussed in the above example), this can cause unforeseen issues for the View/ThinApp Administrators. Modifying the View Manager services from the default settings and configuring the services to use Domain credentials of accounts which have been given proper access to the ThinApp repository share resolves this.

  3. This third cause is somewhat more involved and is looking more like limitation in the ThinApp SDK. Apparently a ThinApp package built with ThinApp 4.5 or higher, which contains an entry point or data container with a source not residing inside the ThinApp package, and being deployed via the View Management Console will likely experience the “Invalid MSI” issue.
  4. Why is that? Well, keep in mind the ThinApp SDK is looking inside the ThinApp package. When it goes looking for a SOURCE of an entry point to register, it prefers to see said source within the ThinApp package it is looking in. When it doesn’t find the defined source, it responds with an error to the View Management Console – which in turn gives out the “Invalid MSI” response to the View Administrator

    Item 3 Resolutions:

    • Within the ThinApp project’s PACKAGE.INI ensure each Entry Point or Data Container have a valid SOURCE value defined to a file within said ThinApp project. Change any Entry Point/Data Container SOURCE value which is not pointing to a file within the ThinApp project/package to a file which is residing within the ThinApp project/package.
    • Additional Info:

      It should be noted, VMware ThinApp Product Development is aware of this and plans are underway to enhance the ThinApp SDK to help make ThinApp package deployment through View as easy as possible. Some people have asked, “Why not allow the ThinApp SDK to search outside the package?” – but remember where the ThinApp SDK is running (in the View Management Console on the system where the View Management Console is installed) and that this Windows OS (potentially a server OS) may not be the same as the desktop Windows OS which the ThinApp package was captured on or which the ThinApp package will be executed on. Therefore, it cannot be assumed the source file will be the same, or even exist (based upon what was determined by the application packager as a Clean PC for capture and build purposes).

      Special Thanks to Andrew Bull of IVOXY Consulting for doing the research on this and posting on the VMware Communities site as well as providing me the image above.

For any customers having any questions around this specific topic, around ThinApp in general, or around any other VMware products, or experiencing any issues requiring technical assistance, please do not hesitate to contact VMware Support. Our support team is top-notch and their number one goal is customer satisfaction!

To contact VMware Support, please see our Support Home Page for the various ways which you can request support.

This entry was posted in Tips, Troubleshooting and tagged , , on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.