If you are an executive or an employee of a company using Citrix XenApp/XenDesktop technology and find yourself struggling to understand why your company is not achieving the desired outcomes Citrix was purchased to achieve, or why this Citrix-thing seems to be hindering your ability to get your job done, this post is for you.
The first and most important thing you need to know is that if you are not experiencing a consistently good Citrix environment or achieving the outcomes Citrix was bought to provide, stop tolerating it. We manage and guarantee Citrix performance for onsite, hybrid, and cloud deployments for several thousand Citrix users, every day. Average login time: 17 seconds. Longest? 22 seconds.
While the diagram above may be overly simplistic, the point it conveys is none the less pertinent. Citrix customers often don’t realize the functionality gap between what is possible and what they have been able to achieve for themselves, represented by the hashed lines above, often blaming the product itself.
From our own files, 50% of the environments we encounter are not built properly. Lack of proper design, lack of Citrix knowledge, and lack in proper supporting infrastructure are the top three reasons.
Dissecting data gathered from working with Microsoft Terminal Services, now called Remote Desktop Services and Citrix in all its forms (MetaFrame, Presentation Server and now XenApp & XenDesktop) approaching two decades, seeing hundreds if not thousands projects, we have identified some consistent patterns that I want to share to provide some insight into why you may be experiencing some of these challenges, and more importantly, what steps to take to get to the desired outcomes Citrix makes possible for organizations.
Mind you, a lot of this is anecdotal, not a scientifically rigorous study of a fixed data set mined from our data.
Generally speaking, assuming Citrix XenApp or XenDesktop were deployed well initially, there are three different overall experiences organizations experience from post-deployment over time. No matter your path, no matter the brand, any application or desktop virtualization project almost always exposes the foundational weaknesses and IT shortcuts in the design and deployment of the existing network:
Green Line: Initial build quality is typically around 80% of the way to exceptional (Exceptional involves automatic incident response, self-healing capabilities, patch identification & automation, self-documentation, etc.). From the initial build the environment begins to degrade typically because of two common reasons that typically reach a maximum pain threshold at 12-14 months.
The spike straight up represents a Citrix consulting firm being brought in to remediate the environment and leaving upon project completion, starting the degradation all over again, culminating in a parallel Citrix rebuild and upgrade between year 3 and year 5. The hashed lines represent when the quality of the environment degrades to the point that some form of Citrix support is engaged.
Incidentally, stopping this see-saw is one of the reasons Whitehat Virtual Technologies was founded to begin with.
Red Line: The red line follows a similar path to the green line, typically being a better initial build but degrading at a similar rate. The rate of decay is sometimes steeper than that experienced on the green line if the local team can’t help but tinker and explore the environment, or sometimes slower with more experienced talent. The following waves of improvement and decay represent new ideas, applications and feature rollouts that may or may not go as planned. The hashed lines represent when the quality of the environment degrades to the point that some form of Citrix support is engaged.
Grey Line: The grey line is the path we want every customer to achieve. That typically begins with a solid initial deployment with additional automation and optimizations introduced over time continuously improving the environment.