Yes, Trusteer Rapport does break App-V

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:

http://www.trusteer.com/support

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:

http://www.trusteer.com/support/faq/supported-platforms

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

http://consumers.trusteer.com/appv

and here:

http://consumers.trusteer.com/compatibility-other-security-software

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.

http://support.microsoft.com/kb/973756

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

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