Imprivata is pleased to announce general availability of OneSign 4.6 SP1! This release contains product enhancements such as support of Citrix XenDesktop 5.5/5.6, Citrix XenApp 6.5 and more… Read more >>
A common complaint I hear when working with customers who deploy applications and shared desktops in a Windows Server environment is the long length of time it can take for a user to log into the environment. When troubleshooting, most administrators verify that all of the Citrix policy settings are correct, and even investigate the servers hardware for possible issues. While all of these could cause this problem, something that most technicians fail to check are the Windows Group Policy settings that control the user’s profile.
Most Citrix environments with this problem use roaming profiles to manage their employees files and folders. While this is a good practice, using folder redirection along with roaming profiles typically yields the best results. Folder redirection settings in Windows Server 2008 can be found in User Configuration\Polices\Windows Settings\Folder Redirection.
When using folder redirection along with roaming profiles, be sure to exclude the redirected folder from roaming by enabling the setting User Configuration\Administrative Templates\System\User Profiles\Exclude directories from roaming profile. In the Prevent the following directories from roaming with the profile box type the list of folders that were set in the Folder Redirection policy.
I have visited numerous customer sites where System Administrators struggle with correctly sizing and configuring their XenApp servers to run in a vSphere environment. The most common issue I find with virtual XenApp servers is over-allocated resources. Most of these servers were converted (P2V’d) from existing hardware, where quad-core processors and 10-20 GB of memory was not uncommon. When approaching the question of designing the a XenApp environment, I too struggle at times with “how much of (enter resource here) is enough?”. Today, while browsing through various white papers, I stumbled upon a very helpful document put together by VMware that serves as a baseline for determining the answer to this question. The technical document can be found here: http://www.vmware.com/files/pdf/solutions/vmware-citrix-xenapp-best-practices-EN.pdf
While slightly dated, this article still provides valuable information for anyone constructing their XenApp environment on the vSphere hypervisor. The key point described in the white paper is that it is much better to create numerous servers with smaller amounts of dedicated resources, as apposed to building a few “larger” virtual machines. Typically, several servers with only 2-4 GB of vRAM and 1-2 vCPUs will perform much better (and provide better availability) than a few servers with 8-10 GB of vRAM and 4-8 vCPUs.
I ran across an issue this week where one of our customers was reporting that a Terminal Server License error was being thrown when attempting to launch a published XenApp application. The error stated the following: “The remote session was disconnected because there are no Terminal Server License Servers available to Provide a license.” The odd element of this problem was that this was only occurring on single machine. We could never reproduce the error on another computer, and no other users were reporting any issues.
After some investigation a colleague of mine pointed me to following Citrix forum discussion: http://forums.citrix.com/thread.jspa?threadID=93566. To resolve the problem, the effected employee simply removed the Registry subkeys under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store”.
One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user (and I say it this way because it doesn’t “technically” load them faster… well, read on).
In order to configure session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you right click that application and choose “Pre-Launch Application”, which automatically creates and enables pre-launch capabilities for that specific app. In the console, it creates a new application object with the prefix “Pre-Launch”, and inherits the same settings you’ve configured on the original application.
When a user logs in to the Citrix Receiver, the configured application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles, etc. This is all transparent to the user– they don’t even see the application. But if they click on the application that was originally created, it opens in the pre-launch session and in what appears to the user to be record time.
Read more >>
