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_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 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.
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
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
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/