Udostępnij za pośrednictwem


Launching an App-V virtualized application on a Remote Desktop Web Access server launches the wrong virtualized application

hotfixHere’s another KB article we published today. This one tells you how to fix an issue where trying to launch a virtualized application on a Remote Desktop Web Access server ends up launching a different one:

=====

Symptoms

When users login to a Remote Desktop Session Host server using a Remote Desktop Connection, all of the Microsoft Application Virtualization (App-V) applications work properly, however when users launch the same App-V applications on a Remote Desktop Web Access server the wrong virtualized app is launched. For example, the users receive App-V application B when App-V application A is selected even though the icon and the application names are displayed correctly.

Cause

When the RemoteApps are configured using the RemoteApp configuration wizard, an Alias parameter is configured automatically. Since sfttray.exe is the application for all App-V virtualized apps, once the 2nd App-V application is added, the Alias parameter cannot be same name as another application therefore the Wizard increments the file name with a (1), (2) etc. An example of this is below:

image

You will notice that the Alias is different for each one of the applications on each server. For example, the Alias for App1 on Server 1 is Sfttray, on Server 2 it is Sfttray1, and on Server 3 it is Sftray3. This is the source of the problem as the Aliases need to be identical for each application on each server.

Resolution

To resolve this issue, edit the RemoteApp parameters for the App-V application so that the Alias parameters are the same for each application across all Remote Desktop Session Host servers. It is recommended that the application name referenced after the /launch switch of the sfttray command be used for the Alias.

Example where the App-V launch commands are:

App1 -sfttray.exe /launch "App1 1.1.1.1"
App2 -sfttray.exe /launch "App2 1.1.1.1"
App3 -sfttray.exe /launch "App3 1.1.1.1"
App4 -sfttray.exe /launch "App4 1.1.1.1"

Change the App1,2,3,4 RemoteApp configurations as follows:

image

Make this change on all Remote Desktop Session Host servers.

More Information

The most common scenario in which this can happen is when you have multiple Remote Desktop Session Host servers and Remote Desktop Web Access servers that are load balanced. When the App-V applications are manually installed on each Remote Desktop Session Host server, they may or may not have not been installed in exactly the same order. Also, the Applications configured in the RemoteApp Program wizard may or may not have not been configured in exactly the same order on the 3 Remote Desktop Session Host servers, thus the Alias names may not be in sync and in the same order on each server.

Application Virtualization 4.6 for Windows Server 2008 R2 Remote Desktop Services - whitepaper -
https://blogs.technet.com/b/appv/archive/2010/05/27/the-app-v-4-6-for-rds-whitepaper-is-now-available.aspx

=====

For the most current version of this article please see the following:

2638538: Launching an App-V virtualized application on a Remote Desktop Web Access server launches the wrong virtualized application

J.C. Hornbeck | System Center Knowledge Engineer

App-V Team blog: https://blogs.technet.com/appv/
AVIcode Team blog: https://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
DPM Team blog: https://blogs.technet.com/dpm/
MED-V Team blog: https://blogs.technet.com/medv/
OOB Support Team blog: https://blogs.technet.com/oob/
Opalis Team blog: https://blogs.technet.com/opalis
Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: https://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: https://blogs.technet.com/mdm/
SCVMM Team blog: https://blogs.technet.com/scvmm
Server App-V Team blog: https://blogs.technet.com/b/serverappv
Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: https://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: https://blogs.technet.com/sus/

clip_image001 clip_image002