Archive
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
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:
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
Setting the online registry key wrong for App-V RDS Client Users in Full Infrastructure Mode will cause new users to not get Applications after Publishing/Refresh
Users may find when running AppV Remote Desktop Services Client (Terminal Services Client) that precached applications do not appear for new logged on users to the RDS/TS server although existing users still have access to the applications.
This happens even though the new users are members of the same groups previously given authorization to the application in the App-V Management Server console.
This can happen on Terminal Servers (RDS) if the following registry keys are set at the same time:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\<Current Version>\Client\Network
Value:
Online – Set to 0
AllowDisconnectedOperation – Set to 1
The other users had previously refreshed against the server and gained access to the application prior to the “Online” key being set to 0. Once this was done, there is no refreshes against the server and as a result, new users never get an application list from the server.
madvirtualizer
The Mad Virtualizer at Microsoft 