XenDesktop Bandwidth: The Complete Set
Part 5 – Do It Yourself: Starter Kit
In my last post, I compared bandwidth requirements for XenApp and XenDesktop. In previous posts, I discussed the importance of network related optimizations and also provided baseline numbers to help get you started with your own WAN deployments. In this post, I’ll share the optimizations that I used during my bandwidth testing.
The following sections refer to an attachment detailing the policies and registry changes that I used during my testing. This attachment is available for download via Citrix ShareFile – Here
Editing the Registry
Serious problems might occur if you modify the registry incorrectly. For added protection, back up the registry before you modify it. See more about backing up and editing the registry here.
When planning for a WAN deployment, it is usually best to have a separate WAN optimized policy. By separating the WAN policy from the baseline Citrix policy, users in the LAN can enjoy a completely unhindered desktop. For more on setting Citrix policies refer to the Policy section of the Citrix Virtual Desktop Handbook.
In the testing mentioned earlier, two Citrix WAN policies were created for each of the optimized configurations. The first policy was created as a baseline WAN policy to reduce bandwidth consumption without significantly impacting user experience. The second policy was created to maximize bandwidth savings regardless of user experience. The main differences between the two policies are summarized below.
- Reduce maximum frames per second to 15 (Default is 24)
- Enable Extra Color Compression
- Disable Menu animation
- Disable Wallpaper
- Disable View windows contents while dragging
Max Optimized Policy
- Reduce maximum frames per second to 10
- Lossy Compression Level: High
- Minimum Image Quality: Low
- Heavyweight Compression: Enabled
- Audio Quality: Low
- Disable all redirection (Printer, drives, ports, USB, TWAIN)
- Maximum allowed color depth: 16 Bits Per Pixel
The full list of Citrix policies is available for download via the ShareFile link at the beginning of this blog post.
Additionally, the default Login VSI policies were applied as detailed in the Login VSI documentation to help ensure that the scripted workloads completed successfully.
The visual settings for the desktop can be set through a graphical user interface located in the “Advanced System Settings” dialog. These settings control the look and feel of a Windows desktop including animations, shadows, and font smoothing. Some of these effects require additional HDX bandwidth and are barely noticeable to users when disabled.
There are many ways to control these settings, however they can become difficult to apply depending on the profile type and image delivery solution chosen. For example, these settings can be changed in the registry by updating the HKCU or HKLM hives. Starting off, I changed all settings using Group Policy Preferences (GPP) on the HKCU hive. However, when booting up the machine for the first time, not all settings took effect because some required a reboot after they were changed. Since I was testing with a local profile and a pooled desktop to ensure consistency, a reboot was not possible. By changing the HKLM defaults I was able to overcome this challenge and all changes took effect on first logon.
Another way to make these changes is to call up a Microsoft MVP and ask for a script that can do this no matter the profile or image type. Luckily Martin Zugec here at Citrix was able to help and created such a script. The script, which runs via PowerShell, can change the visual settings on demand without requiring a reboot or a preexisting profile.
Note: These scripts are being provided as is and are not supported by Citrix or myself in any way. Use them at your own risk. They have not been tested for performance and may or may not have an effect during logon peaks. You should thoroughly test them prior to deployment if you plan on using them.
The registry keys for both HKCU and HKLM and the scripts, along with a description can be downloaded through the ShareFile link at the beginning of this blog post.
Application Specific Settings
Optimizing the operating system can save bandwidth for all users, but optimizing specific applications can have a significant effect as well, especially when that application is widely used. An example of this is Adobe Reader. When setting the specific optimizations as noted in this article along with the OS changes, the bandwidth usage dropped by as much as 70%. Other changes performed for our testing included changes to Microsoft Office applications such as removing the splash screens. All registry and group policy changes can be downloaded through the ShareFile link at the beginning of the blog post.
Note that custom applications that are not optimized for virtualization can be especially bandwidth intensive and should be tested prior to deployment, especially if they will be delivered over the WAN. Small changes to the application UI can make a big difference in performance over the WAN and a developer may create a very animated GUI to appease the eyes but at the same time also create a headache for the virtualization team.
There are a couple of client-side changes that I recommend which help to reduce bandwidth requirements over WAN connections. These optimizations change the speed which Citrix Receiver updates the mouse and keyboard position respectively. I recommend increasing the mouse timer to 30ms and keyboard to 50ms and test to make sure that users cannot notice it. For graphic artists and designers, changing the mouse timer may not be recommended as it can affect the ability to draw (circles for paint may not be perfectly curved for example). These settings can be changed through Group Policy, with a customized installation package, or through a custom launch.ica file. If the end points are domain joined, I would recommend testing Group Policy as a first step.
Neither change was implemented during the Login VSI testing because keyboard and mouse clicks were not actually transferred over the network due to the scripted nature of the testing, although they can significantly reduce the number of packets from the WAN side of the network. In a deployment scenario, these settings will reduce the number of packets that the end point must send over the WAN which can help with high-latency and low-bandwidth connections by allowing faster processing of end point acknowledgments. The reduced packets sent from the client will also correspond to a reduced bandwidth usage from the client side over the WAN.
Stay tuned for my last post in the series where I will be discussing XenDesktop 7 and the many changes that come with it as related to bandwidth.
Thanks For Reading,