Launching a network executable inside an App-V 5 virtual environment (Revised)

*As of App-V 5 SP2 HF4 this article is no longer applicable*

About a year ago I wrote an article about launching a network executable inside an App-V 5 Virtual Environment (VE). This article unfortunately contained an error with regards to the required rights. So here’s the a revised version of that article with also some extra info.

The problem is that when running an executable that is on a networkshare inside a VE using the /appvve parameter you may get the following error. ‘The application was unable to start correctly (0xc0000142). Click OK to close the appliction.’

Application Error

In the eventviewer the error looks like this: The virtual application ‘\\Server\Share\Folder\Application.exe’ could not be started because the App-V Subsystem ‘Virtual Shell’ could not be initialized. {error: 0x8DC02125-0×5}

App-V Error Virtual Shell

This situation occurs for any sequenced application that contains a shortcut to an executable on a networkshare. So what’s going on? The App-V client starts the App-V virtual environment using the ‘Microsoft App-V Client’ service. This services runs under the ‘NT AUTHORITY\SYSTEM’ (Local System) account. It appears that the App-V client service needs to have access to the executable to pull it into the VE. This can be clearly seen when running a ProcMon trace. In this example I’ve put Notepad.exe on a network share and launch it in into an App-V VE.

ProcMon Trace of Network Application

The App-V Service (AppVClient.exe) performs operations to \\server\share\Folder\Notepad.exe with the desired access ‘Read attributes, Synchronize’. As you can see in the screenshot this process runs under ‘NT AUTHORITY\SYSTEM’ (Local System) If the Local System account does not have access to the executable the application process is terminated and you get the above mentioned error. In ProcMon you can see the highlighted Acces Denied after which the Notepad Process Thread is exited. The actual application is running under the user account of the interactive user. As you can again see from the screenshot, allthough the accoutname is removed. So how can we solve this problem?

Granting NTFS Access rights

What needs to be done is to grant the computer account access to the executable(s) on the network. This can be done in the following ways:

  1. The first and easiest option is to add the Domain Computers group to the Usergroup that you use to grant the application users access to the folder (and executables). This may however not be desired as this may give Domain Computers (much) more than the required access rights.
  2. Another option is to give Domain Computers Read rights for Folder and Files directly to the folder containing the application executable(s).
  3. If you want to restrict the rights even more you can create a Specific group voor the Computers Requiring access to the folder/executable(s). The may be an option for an SBC environment, but can easily become unmanageble in large desktop environments.

Personally I would go for option 2. As this is easy to manage and still secure enough in most cases. If you want to retrict the rights even further, here’s what I found out:
It appears the the minimum NTFS rights required for Local System on the Network folder and application executable(s) are:

List Folder/ Read Data on only the folder containing the executable.


Read Attributes on the executable. (This one was unfortunately not reported in my previous post)

This is the most secure option as it does not allow the computer account to read any (sensitive) data from files (apart maybe from the filename).

Granting Share Rights

Besides the NTFS rights the Computer account also needs to be able to access the exe through the share. For this reason you should give the computer account at least the Read permission on the share. The easiest way of course is to give everyone (at least) read permissions at share level. Or you can reduce this by only granting Domain Computer Read rights of even only a specific group with the appropriate computer accounts.

Using a CMD or VBS file

Some people claim that another way to work around this problem is to create a CMD or VBS file for starting the network executable and add that to your sequence. Then point you’re application shortcut to that CMD of VBS file. I’ve not found this to be a reliable sollution. Maybe it does work in some cases, but I did not get this to work without also granting the computer account access.

Drive mappings

Using a shortcut that points directly to an executable on a mapped Network Drive does NOT work. This is because the Drive mapping only exists for the User, so the Local System account can’t access the executable even if has been granted the appropriate rights to the folder and exe. Point to the UNC path instead.
However if you really want to use the Drive Mapping, I did find a way in which you can point to an exe on a mapped drive. This still requires the computer account to have the appropriate access rights though. Here’s how:

Change the shortcut of your application to:  Cmd.exe /C “Start X:\Folder\Application.exe” /appvve:<PackageGUID>_<VersionGUID>

X: can of course be replaced by the Drive mapping that you use.
Also change the Icon as it may automatically change to the CMD.exe Icon.

Still having problems?

Start out with the following:

  • Grant everyone read rights at the share level
  • Grant Domain Computer Read rights to the Network Application folder (and possibly even parent folders, although during my tests this was not necessary.)
  • Use UNC path to executable, NOT Drive mappings.
  • Gradually reduce the rights until it still works with acceptable rights.

Is there a definitive sollution?

At this point no. But I attended the European App-V Usergroup event in March this year. And someone from Microsoft reported that Microsoft is aware of the problem and is looking into a sollution. So who knows, this problem may be solved in a (near) future release. In the mean while I suggest you report this issue to Microsoft. The more people that are affected by it the higher the priority it will recieve at Microsoft.

About Casper van der kooij

Technical Lead Application Packaging @ Conclusion Future Infrastructure Technologies, Utrecht, The Netherlands.

5 responses to “Launching a network executable inside an App-V 5 virtual environment (Revised)”

  1. Johan Parlevliet says :

    Thx a lot for this info.
    Only in the latest version it still does not work without work around.

    Re: *As of App-V 5 SP2 HF4 this article is no longer applicable*
    That is version 5.0.3400.0 (App-V 5.0 SP2 HF04 )
    Why is that ?
    I have just installed the latest hotfix for APP-V 5.1 => version 5.1.123
    and I am still experiencing this problem.
    If i give list and read right to Domain Computers on the share where the package resides it works.

    • Casper van der kooij says :

      HI Johan,
      I find is strange that you are stil experiencing this issue.I have not encountered this issue anymore since 5.0 SP2HF4.
      Below is what is mentioned in the 5.0 SP2HF4 release notes.
      Issue 6

      Virtual application packages that contain shortcuts to executable (.exe) files on a network share cannot start those executables if the system account does not have access to the network share.

      After this hotfix package is applied, user credentials are used to access and start executable (.exe) files.

      • Johan Parlevliet says :

        Hi Casper
        Thx for the response.
        Then it is the question which users credentials are used
        We use APP-V scheduler 2.2 which runs under a domain service account who has access to that share.
        I remove the package and run deploy now and than it reads the package. I can than already see that it does not works as it is not loaded correctly.
        The service “Microsoft App-V Client” is responsible for reading in the package, but that service runs under a system account

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: