XenDesktop (ICA Client) experiences long logon delay and also freezes when minimizing and maximizing or when locking and unlocking local PC

A client of mine experienced some slowness/freezing of XenDesktop 3.0 sessions when used from India.  The slowness is experienced during logon, but also during a minimize/maximize of the XenDesktop session or during an unlock of the local PC.  Here is the background of this issue and what was done to mitigate the issue.

Background: Client uses folder redirection of Application Data folder. That AppData folder is currently redirected across the WAN because of lack of infrastructure in India. Yes, I realize this is an extremely bad practice, but it’s what they decided to do and it’s what I currently have to deal with. Client PCs are in India. XenDesktop VMs are in Chicago. Circuit is 9MB bandwidth and approximately 270 ms of round trip latency.

Issue: Desktop Receiver takes approximately 90 seconds to complete the logon to a hosted desktop. However, this delay is a one time daily expense so was workable, however the bigger problem is that any time the hosted desktop was minimized and maximized or if the local PC was locked and unlocked the screen would freeze for 30-60 seconds before allowing the user to interact with their desktop. This issue was much more frustrating for the India staff.

Root cause: Through WAN emulation and some Wireshark traces both problems were identified to be caused by the AppData Folder redirection. Specifically it was the Desktop Receiver client attempting to read/write to the various INI/Log files from the ICA Client folder (Appsrv.ini, UIState.ini, Wfcwin32.log).  This is NOT a XenDesktop issue, but is related to the ICA Client itself.

Solution 1: Shut off AppData redirection across the WAN. While this is definitely the best case solution, it wasn’t practical to do at this time. There are over 3,000 desktops at this site (not all through that single circuit of course) and there is not sufficient infrastructure for local folder redirection at this moment. In addition, folder redirection policy is tied to file server-based GPOs. Since the India resources logon to both local PCs that are receiving GPO as well as remote hosted desktops that receive GPO, there isn’t an easy way to solve this folder redirection solution unless we perform loopback policy and restrict it to the local machines which causes issues since there are some people that hotel the same machines that require localized folder redirection. Ultimately this issue will be resolved, but it’s going to take some effort to fix.

Solution 2: Find a workaround until the AppData redirection can be localized. In pursuit of a workaround, a Wireshark trace of the traffic was taken and I found multiple redundant QUERY_PATH_INFO calls to the file system structure of the redirected ICA Client folder in AppData. In researching the redundant QUERY_PATH_INFO calls, it appears that there is an optimization for Windows Explorer where Windows Explorer can cache the contents of a directory/file listing in order to prevent multiple QUERY_PATH_INFO calls to the same remote file server. Microsoft made a change in Windows XP to no longer cache long file name paths whereas in Win2k and below, the cached both 8.3 names as well as LFNs. Since Application Data resolves to a long file name (LFN), it is not cached and causes repetitive QUERY_PATH_INFO calls across the network every time that file system data is requested. Explorer also tends to walk the directory path in order to seek desktop.ini files which compounds the problem. The solution to the issue is to get Windows Explorer to cache the long file name paths which dramatically reduces the multiple redundant QUERY_PATH_INFO calls. The ICA Client still needs to go across the WAN to read the INI files, but there’s a dramatic impact on the total time required to do so. After making the modification to the local XP workstations, the logon time dropped from 90 seconds to 60 (which is still high of course, but is a once per day delay). More importantly, when minimizing/maximizing or unlocking the local PC, the desktop refresh is subsecond whereas it was 30-60 seconds of freeze beforehand. The specific optimization is named InfoCacheLevel and is found under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MrxSmb\Parameters. The value needs to be set 10 decimal or A hex. More information on this registry setting can be found here:


I’ve sent this info to Citrix so perhaps it’ll make it’s way to a KB article.  It’s certainly a niche situation, but perhaps someone else might run into this.  To re-iterate, this is NOT a XenDesktop problem but is an ICA Client issue.  It just happens that the client was using XenDesktop when the issue was discovered.

Agree? Disagree? Let me know with a comment...