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

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}

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.

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:

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.

Another option is to give Domain Computers Read rights for Folder and Files directly to the folder containing the application executable(s).

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.

AND

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:

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.

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