VMware ThinApp Deployment Error 0x80070005 Access is Denied

After spending almost an entire day troubleshooting a single error I thought it worthy of posting – if for no other reason to save some other poor soul their entire Saturday tracking down something so inconsequential.

Background:

In trying to push out a number of ThinApps via VMware View 5.2 ThinApp Management I ran in to a problem where the ThinApps would not actually deploy. The VMware View Admin Interface showed a return of “Error details. HRESULT hr = 0x80070005. Access is denied.”. In tracking down the error in the VDM logs (%ALL_USERS%\Application Data\VDM\logs\debug*.txt) I didn’t see a whole lot of additional information except that the VDM agent was trying to open the MSI and failing:

Problem:

2013-09-21T19:57:45.902-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] ThinApp Install applications called for 1 applications
2013-09-21T19:57:46.104-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] Application ID: app1
2013-09-21T19:57:46.104-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] ThinAppMgmt: Application Details:    APP_CN = "fb6c4dd1-6368-4911-88e3-a0bde551fd78"
   INSTALL_FLAGS = "0"
   OPERATION = "INSTALL"
   INSTALL_TYPE = "STREAM"
   APP_DISPLAYNAME = "Patterson EagleSoft"
   APPLICATION_PATH = "\\fileclus1.fothcorp.com\thinapps\Patterson Eaglesoft v15\Patterson EagleSoft.msi"
2013-09-21T19:57:46.104-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] ThinAppMgmt: Opening application Patterson EagleSoft package at path: \\fileclus1.fothcorp.com\thinapps\Patterson Eaglesoft v15\Patterson EagleSoft.msi
2013-09-21T19:57:46.104-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] ThinApp: OpenPackage
2013-09-21T19:57:49.346-07:00 ERROR (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] OpenPackage failed, path = \\fileclus1.fothcorp.com\thinapps\Patterson Eaglesoft v15\Patterson EagleSoft.msi. Error details. HRESULT hr = 0x80070005. Access is denied.
2013-09-21T19:57:49.455-07:00 DEBUG (0494-0530) <MessageFrameWorkDispatch> [ws_thinappmgmt] ThinAppMgmt: Success, returning Application Response:    APPLICATION_COUNT = "1"
   app1 = 
      APP_CN = "fb6c4dd1-6368-4911-88e3-a0bde551fd78"
      OPERATION = "INSTALL"
      RESULT = "FAILED"
      SkippedErrorContext = "OpenPackage"
      SkippedErrorCode = "-2147024891"
      SkippedError = "Error details. HRESULT hr = 0x80070005. Access is denied."

After an entire day (which admittedly is sad I couldn’t figure this out faster) I finally figured out that the error was being caused because the VDM agent runs as a Local System account. When it reaches out to the SMB fileshare it doesn’t pass any authentication info.

Fix:

  1. ThinApp Deployment ErrorModify the (Local Security Settings > Security Options > Network Security: Shares that can be accessed anonymously) to include the share that you are serving your ThinApps out of.
  2. Set the SMB Share permission to include “Read” for “ANONYMOUS LOGON”
  3. Set the NTFS permissions to include “Read & Execute” for “ANONYMOUS LOGON”

 

That’s it. Once I did that on all of my fileservers I was successfully able to deploy ThinApps on demand from my VMware View 5.2 Administration Interface.

Hopefully this helps save you many hours of troubleshooting!

Posted in Technical Tagged with: , , ,
2 comments on “VMware ThinApp Deployment Error 0x80070005 Access is Denied
  1. Chris says:

    You should only need to specify “Domain Computers” for the share and NTFS permissions.

    Page 285 of the View Admin guide:

    You must configure the file and sharing permissions on the network share that hosts the MSI packages to
    give Read access to the built-in Active Directory group Domain Computers. If you plan to distribute
    ThinApp applications to domain controllers, you must also give Read access to the built-in Active
    Directory group Domain Controllers.

    • T.C. Ferguson says:

      Chris, appreciate the comment. I read the same verbiage in the admin guide. I believe that is why it took all day to figure put this particular problem. I don’t know if it had something to do with my setup, but the above posting is what was required to get this working. Domain Computer as part of the smb permissions and or the security access permission wasn’t enough.

Leave a Reply