English 
Vietnamese Hello and happy new year everyone !
4 years I haven’t posted any message on the Citrix blogs.. many changes occured since 2007 ! I hope those changes were as good for you as they were for me..
Today, I wanted to provide a real life experience about using virtual IP addresses with XenApp 6.x as very few articles exist on the web since Microsoft released Windows 2008 R2. Citrix therefore changed the way the virtual IPs work since this new Windows release.
If you don’t know what a virtual IP is, let’s start with a quick explanation : some applications require an unique IP address when running. As you can guess, such application is by definition “not terminal services aware” as we all use to say. In a multi-user environment such as Citrix XenApp, the IP address used by this application will be the server’s IP and as soon as the second user will open a new session on the very same server, this application may refuse to work, since another instance of the application is already running and using the server’s IP. Citrix introduced Virtual IPs (VIP) in Citrix Presentation Server 4.0 back in 2005 by hooking into the Winsock APIs to provide a different IP address per session or application running on the server (have a look at http://support.citrix.com/article/CTX111898 if you want to know more about implementation and troubleshooting). The VIPs in XenApp 5.0 (W2K3 and W2K8 versions) are sharing the same technology with CPS4.0.
Microsft implemented VIPs in RDS and Citrix, since the XenApp 6.0 release, rely on the RDS implementation and is providing additional benefits (virtual loopback IP for example) to the RDS VIPs. Configuring VIPs in XenApp is therefore very different as it was in the older releases of XenApp and CPS : it requires a configuration at RDS level as well as XenApp level : VIP must be configured on the server (or via GPO) and within the XenApp policies.
Anyone starting to play with VIPs with RDS (and XenApp!) should read the very good articles from Mayuri Kandra, a Microsoft engineer from the Terminal Services (RDS) team. The 3 articles explain how to configure VIP in RDS at the server level, GPO level and using PowerShell.
http://blogs.msdn.com/b/rds/archive/2009/07/15/configuring-remote-desktop-ip-virtualization-ii.aspx
http://blogs.msdn.com/b/rds/archive/2009/07/20/configuring-remote-desktop-ip-virtualization-iii.aspx
Recently, I was involved in a XenApp design for a customer who needed VIPs in his environment in order to use an Intranet application accessed over Internet Explorer 8.0 within a XenApp session. Believe me or not, VIPs proved to be harder to configure (and troubleshoot) than expected !! So, I wanted to share our findings which would, I hope, save your time.
As explained in the Microsoft blogs, a DHCP is required to provide the VIPs, so we implemented one for this purpose and configured the GPO to enable the VIPs in RDS for Internet Explorer. Then, we configured the VIP in the XenApp policies for the XenApp servers that will provide this application.
Note: Use per program VIP in case of a multihomed XenApp server (as explained on TechNet and in eDocs) is the only supported configuration. Per session VIP are not supported on a server with multiple NICs.
Below is the list of the different issues we experienced and their solutions :
1. VIP and VMWare vSphere:
My customer’s environment was virtualized on VMWare vSphere 4.x which has a known issue with VIPs and RDS (see this VMWare forum). To solve this first issue, the VMCI drive from the VMWare tools must be disabled as well as IP v6 using the below registry key :
HKLM\CurrentControlSet\services\TCPIP6\Parameters\DisabledComponents DWORD 0xFFFFFFFF
The forum post indicates that a VMXNet3 adapter is required but we tested on several VMs with both the E1000 and the VMXNet3 with the same positive results. By the way, VIPs work out of the box with XenServer 
2. Routers’ ARP Tables :
When using a DHCP server to provide the VIPs, a very specific MAC address is “seen” by the DHCP server for each of the VIP provided : a mix of an added number at the begining of the NIC’s MAC and an unique number at its end. The more logon and logoff processing are done in your environment, the more VIPs will be assigned (and released!) causing those MAC address to be created (note : those MAC addresses aren’t re-used until the DHCP Server service is restarted). Consequence: the routers’ ARP tables were out of sync quite quickly : during our tests as low as 10 sessions opened and closed on a single server caused a lost of connectivity for the VIPs : Internet Explorer wasn’t able to reach any website.
The solution: bypass the DHCP. It took us some time to find the correct registry settings to make it work correctly !
This behaviour is close to what was used in previous XenApp/CPS releases. VIP configuration is simply included in each server’s registry as below :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TSAppSrv\VirtualIP]
« EnableVirtualIP »=dword:00000001
« ComponentDLL »= »%SystemRoot%\\system32\\TSVIPSrv.dll »
« VirtualMode »=dword:00000000
« AdapterAddress »= »00-13-21-09-DD-AE » DO NOT FORGET to update this value with the target NIC’s MAC on the XenApp server !
« IPPool »= »%SystemRoot%\\system32\\TSVIPool.dll »
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TSAppSrv\VirtualIP\IPPool]
« Start »= »10.10.62.1″
« End »= »10.10.62.20″
« SubnetMask »= »255.248.0.0″
The DHCP can now be stopped for this vLAN. Yes, the vLAN was quite huge, but the VIPs must be in the same subnet as the RDS/XA servers…
3. Loosing VIP…
So, to fix the issue 2, VIPs were added into each XA server’s registry. We had therefore a mix of registry configuration and GPOs, the DHCP was also stopped. Randomly, the VIPs disaperead for the connected XenApp sessions, at different times of the day and on one or many servers.. This was caused by the automatic GPO refresh which updated the VIP GPO and caused the VIP mechanism to refresh itself (clearly visible in the RDS VIP event log (Applications and Services Logs\Microsoft\Windows\TerminalServices-TSAppSrv-T SVIP\Admin). Without DHCP, the VIPs were not provided as they were allocated from the registry at logon time.
Solution: configure everything within the registry, removing all configuration from the GPOs. Some scripting is required in order to automate the registry configuration…
As you can see, we experienced some issues with the VIPs, but after all were corrected, everything works like a charm !
Last but not least, I want to take the opportunity of this blog post for a BIG THANK YOU to Nicolas H. and Nicolas D. for the hard work troubleshooting those issues after hours…
I hope you will benefit from those workarounds and they will help you in your XenApp deployments !
Source: CitrixAuthor: Frederic
