Additional Considerations for Using App-V With TSRemoteApps
Some of the most common problems App-V users have when configuring App-V virtualized applications for TSRemoteApps (RemoteApp in RDS) fall into two categories:
1.) Applications not launching properly and/or the incorrect application is launching instead: Do not Use *.ico paths of virtual applications as icon paths. This is outlined in the following documentation:
Even if the App-V packages are distributed to the terminal servers via SCCM, the remote application would still have to be published within the RemoteApp Manager using the following modification:
Command line argument: /launch “App Name”
Like with SFTTRAY, VAPPLAUNCHER will need to locate the EXE or DLL file to map icons so you should not use the .ico file but instead use a .DLL or .EXE for the icon.
2.) File Type Associations will require SFTTRAY and/or VAPPLAUNCHER published separately as a RemoteApp
The reason for this is because published RemoteApps are entered in an “white-list” on the server.
When an application has required command-line parameters, they are also checked. Chances are you will have more than one published virtual application, so you do not want SFTTRAY (or in the case of SCCM integration, VAPPLAUNCHER) limited to that one use. When you associate a file type association with a RemoteApp, that could easily happen. When a document that has an FTA associated with a RemoteApp is opened, the shell API used to launch the document with the RemoteApp does not accept command-line arguments as an input. Instead it just runs the application as it is associated in the registry on the RDS server. When the RDS service performs the white-list check to see whether the executable that will open the document is allowed, it only checks the executable, and not the command-line arguments that will not be used. If SFTTRAY or VAPPLAUNCHER is not published on its own, this will happen.
– Steve Thomas