App-V 4.6: Oldie but Goodie! Using URL Shortcuts to Simply User Experience when Running Virtualized IE Plug-ins (Plus a Bonus Tip!!)

We know how to bring Internet Explorer into the App-V bubble. It’s as simple as creating a special shortcut that points to an OSD file that allows the local instance of Internet Explorer to interact inside the virtual bubble of an App-V package (http://support.microsoft.com/kb/931986) – But there has always been the issue of ensuring the user is clicking on the correct shortcut. This is essential to proper functionality when leveraging App-V to virtualize plugins and add-ons for customized webapps. So, one of the most common question I get from customers that I have always assumed the answer was readily out there is:

How do I launch Internet Explorer configured to run inside the Virtual Environment from a simple URL Shortcut?

This is a great question because placing a direct shortcut to the website/webapp provides a direct point of access for end-users. You can create a shortcut that will launch the IE shortcut configured ot run inside the bubble. There are several ways to create the shortcut but the easiest way I have found to do this is to:

1.) Launch the Application Virtualization Client management console.
2.) From the Applications node, look for your published instance of Internet Explorer. For example, you may have customized it i.e. “Internet Explorer inside Office 2020 package.”
3.) Right-click the application and select “New Shortcut.”
4.) In the next screen customize your shortcut name. Click Next.
5.) Place the shortcut in your desired location. I usually place it on the desktop.

Once you have placed the shortcut on the desktop, then right-click the shortcut and select properties. In the target field you will want to add the argument for the website URL you will want to use for this customized shortcut. The syntax you will use will vary depending on platform and management methodology:

32-bit clients using SFTTRAY as Launcher (Traditional App-V Infrastructure, Stand-Alone implementation)
C:Program FilesMicrosoft Application Virtualization ClientSFTTRAY.EXE /launch “<APPNAME>” <URL>

64-bit clients using SFTTRAY as Launcher (Traditional App-V Infrastructure, Stand-Alone implementation)
C:Program Files (x86)Microsoft Application Virtualization Client SFTTRAY.EXE /launch “<APPNAME>” <URL>

32-bit clients using VAPPLAUNCHER as Launcher (Config Manager 2007 Integration)
C:WindowsCCMVAppLauncher.exe /launch “<APPNAME>” <URL>

64-bit clients using VAPPLAUNCHER as Launcher (Config Manager 2007 Integration)
C:WindowsCCMVAppLauncher.exe /launch “<APPNAME>” <URL>

– Where <APPNAME> is the name of the application published (Internet Explorer) and <URL> is the URL to the website.

To take this further, if you have Internet Explorer configured to launch via an App-V application (i.e. with Office, or running a virtual web application) you can modify the registry to point the shell-open shortcut function for the http object to the OSD instead of the local instance of Internet Explorer.
To make this modification:

1.) Navigate to the following Registry Key:

 HKEY_LOCAL_MACHINESoftwareClasseshttpshellopencommand

The default value is normally the path to iexplore.exe, like “C:Program FilesInternet Exploreriexplore.exe”.

2.)    Modify the value to have the sftdde.exe process launch the virtual version of IE, using the syntax:

<PATH TO APPV DDE LAUNCHER>  “<APPNAME>”  IExplore –nohome

for example:

“C:Program FilesMicrosoft Application Virtualization Clientsftdde.exe” “IE in Microsoft Office 2010” IExplore –nohome

– Would work on 32-App-V clients running with SFTDDE.EXE as the DDE launcher. You can find this out by looking at the DDELaunchCommand in the following key:

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5ClientUserInterface

(or HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5ClientUserInterface if 32-bit clients.)

NOTE: IExplore is the DDE name for Internet Explorer (if you don’t get that right, when you try to launch a URL you get an error from the shell about being unable to pass the parameter to the app). -nohome is the same parameter I found on the original IE command line.

This will require the user to log off and log back on. A full reboot will be better especially on terminal services clients.
One final note: The registry change will have to be pushed out and I have found that customers find the fact that it (the shell modification) cannot be turned on or off with app availability via refresh/publishing frustrating. It’s a good work-around in my opinion though if you are planning to continue to use App-V 4.6 for time being.

The Case of the Three Second Delay (a.k.a What is SFTDDE?)

A while back I encountered an issue that forced me to become introduced to the DDE Launcher used by App-V (SFTDDE.)  A customer was encountering an issue where, no matter how much they tuned their terminal servers, even with pre-cached virtual applications; Office applications appeared to always have a three second delay when they double-clicked on an Office document associated with a virtualized instance of Office. Regular launches of these applications (from the shortcut) did not encounter this delay.

What is DDE?

DDE (Dynamic Data Exchange) is one of the oldest IPC (Interprocess Communication) mechanisms in Windows. Since it relies on using the Windows message layer for functionality it still works even though it has been superceded by many far superior technologies. The factor involved in this particular App-V scenario is whether DDE (Dynamic Data Exchange) has been enabled for the application. The main difference between double-clicking a document or launching the application then loading the document when DDE is enabled is that SFTDDE.EXE is used as a DDE launcher instead of SFTTRAY.EXE.

Investigating the customer’s issue found that there was indeed a three-second delay and a Process Monitor trace revealed it:

Double-clicking and triggering the SFTDDE.EXE process:

0              7:47:03.3683129 AM        sftdde.exe          848         Process Start                      SUCCESS              Parent PID: 2844

Then the SFTTRAY Start:

3007       7:47:06.1107902 AM        sfttray.exe          3408       Process Start                      SUCCESS              Parent PID: 848

By default in App-V when sequencing Office, DDE is enabled. When setting up a file type association that requires DDE support, the client uses a DDE Launcher command. It pulls the command based on the value specified in the following registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface

Value: DDELaunchCommand

The default value is “C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe” “<APP>” <DDE>

If present, the strings <APP> and <DDE> will be replaced with the app’s name and version and the DDE app name, respectively.

When virtualizing Office with App-V, the sequencer enables DDE functionality by using the SFTDDE launcher for each application. One important item to consider is that when double-clicking on a file where the association is with SFTDDE rather than SFTTRAY, App-V will act as a DDE client and sends DDE message broadcast to all open windows. If an instance of word is open, then it will reply back and that instance of WinWord will open the file – regardless of the version of the winword.exe process running.  If not, it will trigger the SFTRAY command to launch.

Is this why my Custom File Type Associations Don’t Work Sometimes?

Yes. This explains why in some cases you may have a local or virtualized instance of Microsoft Word 2003 running side by side with Microsoft Word 2010 running local or virtualized. Let’s say you have the .DOC extension associated with Microsoft Word 2003 and the .DOCX extension is associated with Microsoft Word 2010. If Microsoft Word 2010 is currently running and you double-click on .DOC file, it will still open in the existing Winword.exe process (which in this case would be Microsoft Word 2010.)

Why sometimes a delay?

The delay occurs when there is one or more hung top-level windows on the system. When using ShellExecute or ShellExecuteEx to open a document in its associated application and the file is registered to use DDE, the shell will first try to establish a DDE conversation with a running instance of the application by broadcasting a DDE initiation message to all top-level windows.

The DDE initiation message is broadcasted by calling SendMessageTimeout with a 3 second timeout. When there is a hung top-level window when the DDE message is sent, SendMessageTimeout will be blocked until the message is handled by the hung window or the timeout expires. Once the timeout expires, the shell will launch the application associated with the document.

Should I remove this?

For Office, it would be a bad idea. Every trigger of a document double-click will spawn an SFTTRAY launch of the Office application chosen. I have had many customers remove the DDE section, and have %1 as the only option. The DDE message broadcast does not happen and a new instance of the application opens the file. Eventually they restore the functionality and live with the DDE delay.

Steve Thomas

Is it the “System” that’s really too busy to complete the request or is it App-V?

Chances are, if you have deployed App-V in a large-scale TS/RDS environment, you may have come across this intermittent error message:

Application Virtualization Error – The System is too busy to complete the request.  If the problem persists, please report it to your system administrator

Sometimes it is followed by a specific error code.

Error code 1690140A-200001CD

The error may even follow another error such as:

The Application Virtualization client could not be started. The Application Virtualization Service is not running. Report the following error code to your System Administrator: Error Code: 4602847-0FA10612-00006003.

Normally, when we get messages about the “System” being too busy to complete the request it is misleading. What is really too busy to complete the request is the App-V front end component.

When The SFTTRAY command launches, if it sees another instance of itself running, it tries to pass off whatever it was supposed to do to the existing sfttray process. If it sees that other instance but the handoff times out because the other instance isn’t responsive, it will return with this message. The error message really is telling you that SFTTRAY (or another front end component such as VAPPLAUNCHER or SFTDDE) is unable to complete the request because an App-V client component is too busy to complete the request.

There could be many underlying causes to this resulting from the SFTLIST.EXE (client service) being too busy or even the desktop configuration controller component (SFTDCC.EXE) not being responsive. If this is tied to a global DC refresh, or periodic DC refresh we could have a known issue with SFTDCC not releasing handles.

The 6th Hotfix for 4.6.0 addresses this and is available:
http://support.microsoft.com/kb/2517187

RTSPS Channels

We recently also came across another cause of this issue and it is outlined here:
http://blogs.technet.com/b/appv/archive/2011/07/28/clients-encounter-error-code-xxxxxx0a-200001cd-when-streaming-rtsps-in-microsoft-app-v.aspx

In this case, the RTSPS protocol was the culprit. RTSPS (RTSP over SSL) is limited to 255 channels and each package takes two channels.  If the total number of channels exceeds this value then the error above is generated. To resolve the issue, decrease the maximum number of channels in use at any given time by scaling out the number of RTSPS servers.

RTSP Scaling

Along that line, even if you are using RTSP, this could also be tied to scaling issues. If your DC/publishing refresh intervals are set to frequently (especially for terminal servers) you may be putting too much of a load on the SFTDCC process. Try reducing the frequency of periodic refreshes and/or increase the number of App-V Management servers for load-balancing purposes.

If you are running Citrix XenApp on a Terminal Server/RDS Server, you could be waiting on another seamless session to logoff. A good thing to verify is that the Citrix WFSHELL process releases SFTDCC properly:

• On the Citrix server, start Registry Editor.
• Locate and then click the following registry key:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI
• Right-click LogoffCheckSysModules, and then click Modify.
• In the Value data box, type sftdcc.exe, and then click OK.
  Note If multiple values exist, separate the values by using a comma. For example, use the following format:
  ctfmon.exe,sftdcc.exe
• Exit Registry Editor.

And finally, as always, try to follow the guidelines as recommended in the following KB article (if you are running Windows 2003 x86 – all of them.)
http://support.microsoft.com/kb/973366
Under the section, “General Terminal Server Recommendations when running the App-V client” some applicability varies depending on the operating system platform and version.

• “Pre-cache all applications 100%. “(Applies to all operating systems and platforms.)
• “If you use Windows Server 2003 or older, implement a reboot cycle of the Terminal Servers . . .” (Should not need to do this on Windows Server 2008 and later.)
• “Implement UPHClean on the Terminal servers.” (not needed on Windows Server 2008 and later.)
• “Implement the following registry changes and reboot the servers” (Page Pool Memory settings not needed on Server 2008 X64 and later)
• “Verify that none of the App-V Application packages have following Virtual services if so remove them or set them to disabled.” (Still a good idea for all TS/RDS servers.)

What about the 00006003 error?

Ah yes, I alluded to that earlier. Often when this is happening, a third part filter driver is preventing the App-V Client service (SFTLIST.EXE) from starting. Check for encryption, or storage security-related applications.

Steve Thomas