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/

 

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

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:

http://msdn.microsoft.com/en-us/library/bb736357(VS.85).aspx