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.

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.

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:

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}

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 Share rights

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.

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 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

R:\Excel\Exce;.exe

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.