Every product has his oddities, which can be time consuming if you are not familiar with those characteristics of the product. Also XenApp 6.5 has some of those characteristics which are not well-known or not documented well in the Citrix documentation or specific situations I have encountered at customers environment. In this article I will write down situations encountered at XenApp implementations at customers including a solution, work around or the way you should work with it.
Look further than Citrix / Eliminate possible root causes
Actually this is the best tip you will even get from me. On a regular basis I’m hired to investigate an issue that nobody can solve. When I just arrived at the customer I always ask what they are already tried and have investigated and often I notice that did not have a clue where need to start the research. The first thing I always do is eliminating products, roles and features. Think off: is the issue there when using an administrator account, is the issue there when using a RDP session only, is the issue there without the UEM product active, is the issue there when there no machine and/or policies active, is the issue there when specific software is not active (for example anti-virus, monitoring products). In many cases the issue is not related to a Citrix product, but one of the other products or (mostly) based on specific configuration settings. I have cases it even cost me a couple of days to understand where the issue is caused by, so don’t give up to quickly. Using this methodology we can find the root cause more easily and then it’s just a matter of googling the issue or contacting support of the product causing the issue.
Be careful with limiting Citrix session bandwidth
In the article RDS or Citrix: Which Do You Need? Greg Shields is quoting me that Citrix adds additional functionality by managing the amount of bandwidth and the bandwidth within the protocol in comparison with Microsoft RDS. I definite think that this is one of the features that RDP is lacking; however configuration the Citrix bandwidth policies should be done with care and good understanding. The story that a Citrix session is using 20Kbps per user is really really (did I already mentioned really) outdated. The ICA protocol can be very efficient with limited bandwidth available, but it is not specifically build to limit the bandwidth usage. Especially with current possibilities of displaying video, multimedia and 3D applications bandwidth requirements are pretty different than 20 Kbps. But also when this is not in the vision of the company limiting the bandwidth of the Citrix session should be carefully considered. I had a case we limited the total bandwidth of the Citrix session and also configured limit for the different virtual channels based on percentages. While running the pilot we got complaints that copying from and to the USB disk was too slow. Quickly we determined that our bandwidth policy was causing this complaint. Most of the users were working on a Fat Client before our project, so they were used to full speed copying (as quick as the network allowed). The customer demanded that USB stick should operate as in the old infrastructure. To accomplish that demand we needed to reconfigure our bandwidth policies to 50000 kbs per session, while the USB device redirection bandwidth percentage was set to 60%.
Check Applies to in Citrix Policies thoroughly
With the further development of XenDesktop Citrix decided to combine the policies both for XenApp and XenDesktop. The result is that all policies are shown in both products. Especially when you configure a new version for the first time you can think that is a useful policy setting, but it is never applied. After an additional check you see Applies to XenDesktop x.x or later, in other words not applicable for XenApp. I stumbled over the Session Limits settings in my first XenApp 6.5 implementation, where some real good options are available in the XenDesktop implementation.
This tip still applies to the XenDesktop 7.x product, where there are still differences for Session Hosts and VDI systems.
Workspace Control within a Citrix session
Workspace Control within Citrix XenApp is a lovely feature for the end-user, but is often a nightmare implementing and maintaining. I have been at several customers troubleshooting Workspace Control issues. For a correct functioning Workspace Control there is pretty large list of requirements and you cannot use several Web Interface add-ons. Bram Wolfs already wrote an excellent article about this topic called A Deeper look into Workspace Controls and its challenges. However there is another requirement that is not mentioned in the official documentation and I found somewhere on the Citrix Forums mentioned by a Citrix engineer once. It was a pity that I found that after two full days of troubleshooting, because my testing method was not supported. Workspace Control does not function when you are starting the Citrix session within another Citrix session. In my case it was working in a Citrix XenDesktop VDI session and starting an application via the Web Interface or PNAgent functionality to a Citrix XenApp farm, which is a possible use case scenario. So when users are connected they will start a new Citrix XenApp session when they did not disconnect the Citrix session on another machine (for example a ThinClient or another VDI session).
Citrix Policies defined in multiple MS GPO’s
When I initially wrote this article I thought there was an issue with using multiple GPO’s on the same OU level with different Citrix policies defined. The additional policy I created did not get applied, however when I moved it one OU lower in the hierarchy it was working as expected. At first I was convinced this was by design and added to this blog article (before it was released fortunately) Because some asked about it and did not totally believed me (and that’s a good thing in my opinion), I contacted some other people. As they also thought it should be functioning, I started the troubleshooting process again. Actually it was really logical and one of the other suggested taking a look at the link order of the MS GPOs. Basic knowledge but you should never forget. Of course the issue was there I created the additional GPO later, so it had a larger link number (so lower priority). Changing the link order in such way the additional GPO has a higher priority caused that the additional settings were applied. As I forgot you can forget it, so I decided to keep this one in (showing my own stupidity to the world).
Conclusion
In this article I described several tips and trick regarding XenApp 6.5 environments based on implementations I have done at customers. I also shared by default troubleshooting trick, eliminating products/features when searching for the root cause of the issue/problem. If you have some additional tips and tricks, let me know so I can add those to an upcoming article (logically I will mention that the tip/trick is provided by you).