App-V: Refresh “On-login” and Slow Startups in Windows 7

When you configure App-V’s desktop configuration refresh feature (i.e. DC Refresh, Publishing/Refresh) you have the option of setting this to occur “on login” and/or using a periodic interval. This configuration can be controlled at the client end or, in the case of an environment using the traditional App-V management server environment, can also be controlled via the provider policy.

The “On-Login” option is partially facilitated by registering the desktop configuration controller (SFTDCC.exe) into USERINIT under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon key.  A default installation of both the desktop and RDS App-V clients will do this and start SFTDCC on login. This option is always generally recommended for startup if the publishing configuration for applications is coming from an App-V management server. If you want to remove the on-login behavior, it is best recommended to do this through the client user interface or through a provider policy. Removing the SFTDCC entry from the USERINIT registry entry will simply result in the entry getting re-registered the next time the App-V client service restarts.

The “on login” behavior is a good thing because it ensures all of the user initialization, application asset caching, publishing (Icons, OSDs) and other setup is facilitated around the same time the user’s desktop becomes available. It also corrects potential problems.  For example, if another user had previous logged onto that desktop and for some reason deleted an application while you were logged out, this will re-provision your application.

In addition, if your access to an application was revoked while you were logged out, this is the process that hides your shortcuts, and essentially hides the application from you. This occurs even if the
applications assets were previously fully cached. If the SFTDCC component were not configured to start on login, or worse yet, the SFT Listener process were not engaged (most common if the App-V Client services is set to manual) the
shortcuts and assets would still be there, but they would not work. 

Slow Startups

A common misconception is that sometimes this “on-login” feature causes slow startups in Windows 7. While true, there have been issues where the presence of the App-V client has been a factor in slow startups, there is more to the story than that simple statement. Common troubleshooting steps that have been employed have involved setting the App-V Client service to manual (and thus devising some workflow to start the service post user login) or even removal of SFTDCC from USERINIT. I would advise against either of the above steps as this issue could be one of a few known bugs that have been fixed on both the App-V side as well as the Windows 7 side.

First and foremost, all of the major App-V startup bugs have been isolated and fixed as of App-V 4.6 Service Pack 1 hotfix 3. If you do not have hotfix 3 installed, please install it. You can download this via (http://support.microsoft.com/kb/2571168.) Of course, I would always recommend installing the latest hotfixes for App-V 4.6 SP1 but this one is essential for clearing up a lot of the slow startup problems.

In addition, I would also advise ensuring the following hotfixes have been installed for Windows 7 or Windows Server 2008 R2 to alleviate slow startup problems:

Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7

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

The desktop does not load and only displays a black or blue background after you log on to a computer that is running Windows 7 or Windows Server 2008 R2

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

And of course, don’t forget, it could be other software causing the slow startup and App-V may just be an innocent victim. Remember this? – https://madvirtualizer.wordpress.com/2011/08/18/yes-trusteer-rapport-does-break-app-v/

 

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

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

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
Date:         
Event ID:     
Task Category: (3)
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <name>
Description:
{tid=1C3C}
Failed unregistering callback tracking connected process termination (error: 997).
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event“>
  <System>
    <Provider Name=”Application Virtualization Client” />
    <EventID Qualifiers=”16384″>3219</EventID>
    <Level>3</Level>
    <Task>3</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime=”2010-09-18T19:34:05.000000000Z” />
    <EventRecordID>834</EventRecordID>
    <Channel>Application</Channel>
    <Computer>COMPUTERNAME</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{tid=1C3C}
</Data>
    <Data>997</Data>
  </EventData>
</Event>

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.