Deploying Citrix Branch Repeater VPX is challenging when it comes to high availability
Yesterday Citrix annouced the free availability of Branch Repeater VPX (any model) for every new and existing Citrix XenDesktop Platinum customer. While this is a big addition for existing and new customers, implementing Branch Repeater VPX can be technical challanging.
Let my explain why:
First you need a physical server running Citrix XenServer or VMware ESX. This isn’t a big deal. But while the physical Branch Repeater appliances have file-to-wire network cards your virtualization host doesn’t. This means when your Repeater VPX or physical virtualization host are running into any trouble your connection which before was featured by Citrix Reapter is now offline.
What are the alternatives:
- Using the Repeater High-availability mode? No, you’re out of luck. This feature isn’t supported if you’re deploying Repeater as VPX.
- Using the high-availability features (NIC bonding, Restart HA) of the hypervisor? Again, you’re out of luck because it doesn’t help you if your Repeater VPX is crashing.
- Using Repeater WCCP or Virtual Inline mode? There you are.
In fact if you’re deploying Repeater in WCCP mode or Virtual Inline mode both have health checking capabilities. So if your Repeater isn’t available anymore your router is bypassing the Repeater and is sending the traffic another way.
For implementing WCCP or Virtual Inline mode you need to do some changes to your router, which in most cases shouldn’t be a problem but can also be very challenging when it’s managed by your ISP. 
Anyhow now you know how to deploy a fail-proof Repeater VPX in your environment and you now can enjoy all the advantages of having Citrix Branch Repeater around.
For more information about the product announcement visit:
http://community.citrix.com/pages/viewpage.action?pageId=160366748
For details on how to deploy Branch Repeater VPX in WCCP or Virtual Inline mode take a look at the admin guide:
http://support.citrix.com/article/CTX126633
Citrix released XenDesktop 5 FAQ
Citrix released the XenDesktop 5 FAQ which contains answers to things you always wanted to know about XenDesktop 5.
For example:
- What happens if the database is unavailable?
- Which tasks require administrative access to the Data Store?
- Why does the XenDesktop Setup Wizard not seem to work with XenDesktop 5?
And much more interesting details. Grab it while it is hot: http://support.citrix.com/article/CTX128328
AppSense Environment Manager and Citrix Provisioning Services
Using AppSense Environment Manager with Citrix Provisioning Services is a killer combination. In fact in combination with an application virtualization solution it’s a true layer cake.
Unfortunately the AppSense Environment Manager and Citrix Provisioning Services aren’t working to good with each other if you doesn’t keep the following step in mind.
- Every change you do inside the Environment Manager policy trigger “Computer Start up” needs to be baked into the vDisk itself.
- If you’re using PVS to stream VHDs to client systems, not XenApp servers or virtual desktops, every configuration change needs to be baked directly into the vDisk.
Why you have to do this? It’s easy:
If you’re using the AppSense Management Center to deploy and manage AppSense configurations normally every configuration change is almost immediately deployed to the agents. In a classic desktop or XenApp environment thats fine but not if you use Provisioning services and here is why:
If you make changes inside the Computer start up trigger there is no problem deploying the new configuration. But as soon as you restart your target devices, which is deployed as vDisk in standard mode, the new configuration is gone. When the system now reboots the AppSense Environment Manager runs the Comptuer start up triggers from the old configuration which is baked into the vDisk. After this is done the AppSense deployment system actual starts to update the configuration again but now it’s to late. The updated configuration is not used as the Computer start up trigger was already triggered. In a XenApp / XenDesktop environment that’s the only thing you have to be concerned about. Normally the Environment Manager configuration is deployed before users can log on and so every change to the user section works, even if this configuration change isn’t baked into the vDisk.
For physical target devices, like client computers, that isn’t the case as the user is able to log on to the system much earlier as in a XenApp / XenDesktop environment. In this case the old baked in configuration is used for the user section of Environment Manager or, if the timing is very bad, the user gets absolutely no configuration as the Environment Manager configuration is updated exactly when the user logs on.
But if you keep both points mentioned above in mind you should be got to go.
By the way, maybe some at AppSense is reading this, it would be awesome if it would be possible to change the location where the AppSense configurations are saved. Then we could choose a persistent location for the configuration and wouldn’t need to update the vDisk in almost every case when an update to the Environment Manager configuration is done. Also it would be nice if AppSense configuration updates would be done before the Computer start up trigger gets processed and also before the user is able to log on.
XenApp and XenDesktop progressive compression feature causes Internet Explorer pages to flicker
Many of our customers currently experiecing an issue that Internet Explorer pages are flickering if IE is published as application or even running inside a published desktop.
Every experienced Citrix guy will instantly think of the “Force Offscreen Composition” key for Internet explorer. But this key unfortunately doesn’t solve the problem.
In this case the root of all evil is the Citrix progressive compression feature which causes the flickering. This issue exists in every XenApp or XenDesktop release which contains the progressive display feature.
There are currently three workarounds available.
1. Disable progressive compression through Citrix policies. In XenApp 6 and XenDesktop 5 this is done by setting the progressive compression level to None.
2. Disable the EnableOSS feature on client side through a registry key. To disable the OSS feature open the registry (regedit.exe) navigate to HKEY_CURRENT_USER\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Thinwire Graphics and change the EnableOSS data from “*” to “FALSE”.
3. Disable the EnableOSS feature through modification of your web interface instance. For this workaround open the default.ica of your specific web interface site (e.g. c:\inetpub\wwwroot\citrix\xenapp\conf\default.ica) using your favorite text editor and add the EnableOSS=False in the [Application] section.
For more information what exactly the EnableOSS setting just look at the Citrix eDocs library.
This issue is currently investigated by Citrix technical support so hotfixes for this issue should be available to a later date.
How to upgrade to Citrix XenClient Service Pack 1 (SP1)
Doug Brown posted a very detailed article about upgrading XenClient and Synchronizer to SP1.
How to Upgrade to Citrix XenClient Service Pack 1 (SP1)
In combination with my little hint how to copy the upgrade package for Synchronizer you should be good to go.