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

Consider these scenario’s

1. You have an application that has its main executable located on a network share but it also requires files installed on the local computer. You want to use App-V 5 to create a virtual package/sequence of the locally installed files and launch the network executable while making use of the created sequence.

2. You already have an App-V 5 sequence of an application and want to run another executable located on a network share while making use of this sequence.

This post has been revised. Please See Launching a network executable inside an App-V 5 virtual environment (Revised)

The standard way to launch an executable that is not part of a sequence inside a virtual environment is to use the /appvve:%PackageId%_%VersionId% switch. Where %PackageId% and %VersionId% are the PackageId and VersionId of the App-V 5  package you want to launch the executable in.

For example:

C:\Windows\System32\cmd.exe /appvve:5CA2D187-D935-48F7-B4FE-95120DDEDAA2_A503FFC6-C553-447D-9DDC-203FB84598B0

Any shortcut made using the App-V 5 sequencer that points to an executable outside of the sequence also uses this /appvve switch

For more information about /appvve see:

The problem

Using /appvve works fine as long as the called executable is located on the local computer.
However when the executable is located on the network you may find that the application fails to launch. It may produce an error like the following:

Application Error

In the windows eventlog for App-V you will find the following error:
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-0x5}

App-V Error Virtual Shell

This is because the computer account of the computer from which the executable is launched with the /appvve switch must (at least) be able “see” the content of the folder the executable resides in. Exactly why this is necessary I do not know. You’ll have to ask Microsoft.

Setting up NTFS rights to remedy the problem

This post has been revised. Please See Launching a network executable inside an App-V 5 virtual environment (Revised)

The easiest and in most cases secure enough way to allow the executable to be started is to grant the “Domain Computers” group the “list folder contents” right to the folder containing the executable.

List folder contents NTFS security

To restrict the rights for Domain Computers further  you can instead only set the special right “List folder / read data” and apply it to “This folder only”.

Special NTFS security

To increase security even further you may choose to only grant this right to the required computers, but this can easily become unmanageable.

Setting up Share rights

This post has been revised. Please See Launching a network executable inside an App-V 5 virtual environment (Revised)

If you have specific security rights configured at share level (i.e. you do not use the default Everyone read or full control) you must make sure that the required computer accounts (Domain Computers) has at least read rights to the share in addition to the required NTFS rights.

Share security

Final Notes

If giving computer accounts rights to shares is unacceptable in your network, I would suggest logging a support call with Microsoft. If enough people do this and the impact is high enough they may change it (if possible) in a future release.

Thanks to the guys in this forum post for pointing me in the right direction:

Tags: , , , , ,

About Casper van der kooij

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

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

  1. George Joseph says :

    Hi Casper,

    thanks for the article. From my experiance, i could find a resonable workaround for the network applications. The appvve parameter is geting added to the sortcut if it points anywhere other than the local installation directory (PVAD)and VFS. Hence we cannot avoid this parameter in the installation because the internal logic of appv installer does it.

    i found a workaround for the same like create a CMD file in the installation directory and put the remote application path in the CMD file.

    for examle , my excel.exe is residing in R drive, i make and entry in cmd file like


    So while sequencing, the shortcut will point to the CMD file, which in tiurn present in PVAD hence no APPVVE parameter.

    This solved most of my issues related to network shortcut applications.

    Its just a workaround till microsoft resolve this issue.

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: