Posts Tagged ‘sfttray’

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

September 1, 2012 2 comments

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 ( – 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:


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:


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:


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

Categories: Uncategorized Tags: , , , ,

App-V: Beyond Trust unable to Trigger SFTTRAY /REFRESHALL under different user context

September 15, 2011 Leave a comment

I recently dealt with an issue where a customer had several machines attempting to perform a non-interactive DC Refresh via a third-party program. This program called Beyond Trust was failing with the following error in the SFTLOG.TXT:

[03/23/2011 13:52:50:127 SRVC ERR] {tid=1654:usr=steveth}
Failed to open connecting process handle to track process termination (PID 7604, error 5).

NOTE: This does not have to happen with just this particular program. This could also occur with any program that attempts to process this command under the context of a user account (with or without UAC disabled.)

ALSO NOTE: This is not to be confused with the similar process termination error (997.)

Simple elevation to the user’s context will not suffice. The call to refresh against the server will still need to be called from the credentials of the targeted user account in which it must be able to also call SFTDCC at the same time.

The best resolution to this issue would likely be to use something such as the built-in Scheduled Tasks within Windows to achieve offline non-interactive refreshes against the App-V server. Then simply create and distribute the *.job file for this.

Specific information related to the SchTasks command is found here:

Yes, Trusteer Rapport does break App-V

August 18, 2011 1 comment

You may have encountered problem with slow logons, slow startups, and slow access to applications when using App-V in conjunction with security software known as Trusteer Rapport. The Trusteer Rapport issue is timing related. It also appears to have a signficant effect on Windows XP machines (since the App-V Client service cannot be set to a delayed start.)

For information on Trusteer Rapport, this is their own support page:

According to their FAQ, it is currently listed as not being compatible with App-V and that they’re working with the vendor to resolve it.

From their FAQ, as it’s not entirely easy to find:

There’s a section under there about “are there any known conflicts” which leads to the app-v page:

and here:

Why is it happening?

There is contention when you startup as this software is preventing SFTLIST from completing initialization. This is the SFT Listener process which is a primary component of the App-V Client service. If you combine this with  SFTTRAY launching at startup (within the “Run” registry key) as well as combining this with SFTDCC loading in USERINIT (to support DC Refresh upon login if configured) –  the resulting negative user experience ranges extremely slow logons to virtual applications never being available.

So What are your Options?

You can uninstall Trustee Rapport or you can try to get them working together by leveraging KB 973756 which takes SFTTRAY /autostart out of the run key.

Step two in this article may turn you off as it requires putting the App-V client service in manual startup mode.

Also note – some customers have gotten success with the delayed start feature on Windows 7 for the App-V client service.

– Steve Thomas

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:


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:

RTSPS Channels

We recently also came across another cause of this issue and it is outlined here:

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:
  • 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:
  • 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.)
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

Categories: App-V, RDS Tags: , , , , , , , , , ,

Additional Considerations for Using App-V With TSRemoteApps

August 1, 2011 4 comments

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:

Location: %SYSTEMDRIVE%\Windows\CCM\VAppLauncher.exe

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

Description and Explanation of the “Failed unregistering callback tracking connected process termination” Error 997 in App-V

April 11, 2011 8 comments

Have you ever noticed that periodically you may see the following error in the SFTLOG.TXT and/or the Windows Application event log:

Failed unregistering callback tracking connected process termination (error: 997).

You will also see the following in the Event Log:

Log Name:      Application
Source:        Application Virtualization Client
Event ID:     
Task Category: (3)
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <name>
Failed unregistering callback tracking connected process termination (error: 997).
Event Xml:
<Event xmlns=”“>
    <Provider Name=”Application Virtualization Client” />
    <EventID Qualifiers=”16384″>3219</EventID>
    <TimeCreated SystemTime=”2010-09-18T19:34:05.000000000Z” />
    <Security />

Here is the following explanation of situations where this event may occur:

When one of the App-V client’s front-end component (i.e. UI or SFTTRAY) connects to the SFT Listener, the Listener opens a process handle to that front-end component, and will call a system API that will automatically monitor for that process handle being signaled (i.e. the process exited), and invoke a callback function in the Listener if that occurs.  If the front-end component disconnected normally, the monitoring of the handle is canceled. It appears to the App-V front end component that when the unregistration of the callback function was tried – in this case, the callback function had already been queued up or was in the process of executing which caused this warning to be reported.

In most cases this message is benign. This will often happen when the SFTDCC processes overlap with publishing refreshes and will also happen often on TS/RDS logoffs – especially with Server 2008 and beyond. You will also see this paired with User Profile Service registry closure events.