With Server Based Computing and consolidation becoming increasing prevalent along with the enormous buzz of VDI, I think it is worth debunking some of common myths of XenApp and Terminal Server. Below are the most common misconceptions that I continue to hear from IT folks today on the limitations of XenApp/Terminal servers that I have debunked from real world experience supporting and working with different terminal server environments.
Myth 1: Application compatibility is a huge problem on Terminal Servers.
There might have been some truth to this myth a decade ago, but in reality this is just not a big problem in the 2003/2008 world. From my first hand experience, I can say that an application that works on XP will work on 2003, what works on Vista, will work on 2008, etc. Are there some exceptions? Of course. However, these applications are few and far between, yet the “application compatibility” myth continues to circulate. This myth was probably true in the NT/2000 OS where applications did not do a good job of differentiating between “user” and “computer” parts of an installation. Since Windows XP, application developers have done a better job writing “user” specific information in the user profile and “machine” specific information in Program Files, or HKLM. I would probably attributed to the “Fast User Switching” feature introduced in XP. Whatever the reason, this is just not a problem anymore.
Myth 2: Printing is a BIG problem on XenApp.
Historically, printing in XenApp was a big pain. Managing driver versions, ensuring the appropriate client printer drivers are installed, distorted print jobs, crashing print spoolers. It was difficult for a very long time… I guess this myth still has legs because of the bad taste left by those old versions of Metaframe and Metaframe XP. However, since Citrix released the Universal Print Driver (UPD) in Presentation Server 4.0, there is less and less hard evidence that printing is still a “BIG” problem in XenApp. Furthermore, with updates to the UPD in XenApp 4.5 and 5.0, Citrix has all but stamped out printing/driver problems in XenApp. Do problems with the Citrix Print Manager service crashing and the print spooler still happen from time to time? Yes, but not often enough to be concerned about.
Myth 3: The user experience on a Terminal server cannot be configured with the look and feel of a “desktop” OS.
This one is just unequivocally false. I am not sure where this one started, especially because most IT administrators know that Windows Server 2003 is built on the same code base as Windows XP, Windows Server 2008 is built on Vista, and now Windows 2008 R2 is built on Windows 7. With that out of the way, the “look and feel” of the desktop OS is controlled by the Windows “Themes” service. This service is disabled by default on Windows Server OS (for obvious reasons). However, there is nothing preventing an administrator to configure Windows Server 2003 with the Windows XP “Luna” Theme once this “Themes” service is started. And both Windows Server 2008 and 2008 R2 can be configured with the Aero theme by enabling the “Desktop Experience” Windows component. Of course these visual upgrades would result in more resources being consumed by the Terminal Server and a slightly lower user density, but it is possible to do. I have seen this done first hand in a production environment without error.
Myth 4: A crashing process for a user, will impact other users on the Terminal Server.
This myth still gets kicked around a lot. Specifically, when decision makers are comparing the benefits of VDI over Terminal Servers. It is typically described or understood to the administrator that “a program or process crashing for one user, will impact the other users running that application on the Terminal Server”. I am going to say from firsthand experience, this is just not true, at least in the sense it is described above. And if this was any thread of truth to this, I don’t think anyone would be running Terminal Servers. Windows isolates processes for users running in their session, so that they don’t impact other users on the server when some process crashes. For example, if I am logged into a terminal server and kill the Outlook.exe process running under my user context, no other users on the Terminal Server running Outlook.exe would be impacted. So where does this myth originate from? I think it is most likely stirred up from situations in which a specific Windows system service crashes or if a BSoD is generated by a kernel mode driver on the XenApp server, which would impact everyone on the server. These can typically be averted by ensuring hardware drivers/firmware, Windows Server and XenApp are fully updated and patched.