Load Balancing VMware view with Citrix Netscaler

Citrix netscaler vmware


Load balancing VMware view with Citrix Netscaler provides a resiliant basis for your virtual desktop deployments.

Firstly why would you want to add Citrix Netscalers into a VMware view environment. Well its because neither connection servers nor security servers provide any sort of load balancing options making a VMware view installation brittle at the entry points. Without load balancing any failure of a connection or security server will translate into downtime for the environment, depending on how you carve up the view environment this may affect all or some of your user base. Either way someone is not going to be happy and this will mean either your job mobile going off at an inconvenient time or some angry faces peering through your office door.

Load balancing VMware view with Citrix Netscaler allows you to not only load balance your connection servers but also provides the high availability feature that is currently lacking within the native VMware connection and security servers.

There are other options for load balancing connection servers and yes there is a free Netscaler VPX you could use for load balancing however you should not use the free VPX for anything other than very small environments as the throughput limit of 1 Mbps could cause you issues.



UPDATE 18/06/2015: I’ve created a new blog post for load balancing security servers for external use which includes a PDF document document which includes all the below content plus a few tweaks I’ve made. Both the below instructions and the linked PDF document will work fine I’ve just tidied it up a bit.

You can find the latest version HERE



We will be using SSL_Bridging on the netscaler so the Correct SSL certificates must be present on the VMware View security servers if not you can follow this guide for more information on how to do it.

In order to load balance VMware view with Netscalers we firstly need to know a little bit about the ports that view uses to provide its virtual desktops.

Port 443 is used by view to communicate authentication requests.

Port 4172 is the actual desktop traffic so screen updates mouse and keyboard actions sound we will need both UDP and TCP traffic for this one.

For this because we are setting up multiple VIP’s to the same backend servers we will also be using persistency groups to ensure that a View request is always redirected to the same backend server no matter which VIP the traffic is hitting So without further ado lets get cracking. I’ll assume in this blog post you are familiar with the basics of a Netscaler..

1/ Create the back end server connections by clicking on Traffic Management\Load Balancing\Servers and hit ADD. Add a connection for each security server that you have in your environment making sure the IP you enter is that of the VMware View security server.

Screen Shot 2013-11-22 at 22.50.03


1b/ Once You’ve enter your VMware View security server details the Servers node on the Netscaler should look like this.

Screen Shot 2013-11-22 at 22.50.42


2/ Now we need to create the SSL bridge and View traffic services so navigate to Traffic Management\Load Balancing\Services. Click add and give the Service a name and choose SSL_bridge from the protocol. With SSL bridging the port will be pre-populated for you. Then choose the First security server in your Server list.

From the monitors tab choose a service monitor you think appropriate which for me is both tcp and https. This will continually ensure that both a tcp connection and a valid https connection is possible with the backend server and if one of those fails traffic will be not be routed to the failed service.

Screen Shot 2013-11-22 at 23.06.49

Once you have all that in place hit Ok to create the service then repeat the steps for the other security servers you have. If you have quite a few security servers to configure the Netscaler with I would use service groups instead but in this case services will do us just fine.

Now we have the SSL_bridge configured its time to create the services for the PCOIP traffic. For that the steps are very similar. Hit Add on the services menu to create a new service. Give it a sensible name and choose your first security server from the drop down server list.

From the Protocol menu choose UDP and manually enter the PCOIP port of 4172. Again you need to add a monitor so that the Netscaler can poll the server to ensure the service is up. For me ping is adquate and then hit OK to create the service. Repeat the steps again for all the required security servers.


Screen Shot 2013-11-22 at 23.18.23


Now you need to create the last service for the PCOIP TCP traffic. The steps are the same as above so I won’t repeat myself but heres a screenshot of what the TCP service should look like.

Screen Shot 2013-11-22 at 23.24.12



Penultimately we need to create the virtual IP’s that the your VMware View clients will actually use to connect to and receive their beautifully crafted virtual desktops. To create those click on Traffic Management\Load Balancing\Virtual Servers and hit Add.

Again give the Virtual Server a sensible name and also you need to give it an IP address. This IP address will be the same across all the Virtual Servers we create and should be the IP that is resolvable by a DNS name (something like View.vhorizon.co.uk for example).

Choose the first protocol that we created SSL_Bridge and from the services tab hit Add and add each security server that we have configured previously (if you have a lot of security servers and have used service groups then you’ll need to do this on the service group tab). Because we are using persistency groups we do not need to specify a persistence method here. Click Ok and your done for this protocol.

Screen Shot 2013-11-22 at 23.34.32


We need to create 2 more virtual servers for the TCP and UDP PCOIP traffic. Again hit Add and configure each virtual server to look like the screen shots below.


UDP Virtual Server

Screen Shot 2013-11-22 at 23.42.55


TCP Virtual Server

Screen Shot 2013-11-22 at 23.43.12


Once you have the Virtual Servers configured your Virtual Server page should look like this.

Screen Shot 2013-11-22 at 23.46.30



Finally we configure persistency groups for our virtual servers. This ensures that the server that is load balanced too and replies to the VMware View client is the same one that receives traffic to it from the View client on the other ports/Virtual Servers.

To do this navigate to Traffic Management/Load Balancing/Persistency Groups and again hit Add.

Again give the Group a name and choose SourceIP as the persistence. You can then config the net mask if you want the persistence to apply to a group of machines in a subnet or more typically keep it at the default which is per client. Click Add under the Virtual Server Name and add the 3 Virtual Servers you have already created. Click OK and you are done.

Screen Shot 2013-11-22 at 23.51.20


If you have configured all the components correctly then you should now be able to launch the VMware View client and open a desktop. Using the DNS name that resolves to the Virtual Server IP on the Netscaler.




Heres a brief bit of added extra on NetScaler monitors to provide a more fault tolerant VMware View platform. The big issue with VMware View is its reliance on one to one relationships between a security server and a connection server, and the issue arrives when your security server remains up but the connection server is down. Without creating custom monitors within the NetScaler config the Netscaler will be unaware of the failure because the standard monitor will still show the security server as being up and will continue to try and send requests to the security server with the failed connection server.

To resolve the issue click on the monitors node and click Add. Then configure a monitor per connection server with the desired settings remembering to set the Destination IP address to be that of the connection server, for me a TCP monitor would cover most situations.

NetScaler VMware Monitor



Once enough monitors have been created bind each one to the services you have created. For example if you have 3 separate services for a security server (SS01) PCOIP, UDP and TCP and the security server is linked to CS01 bind the TCP monitor for CS01 to all 3 services for SS01. This will have the effect of monitoring the general health of the associated connection server as well as the security server itself. If the connection server goes down then the SS01 services will be marked as down and the NetScaler will load balance to the remaining security servers.



Below is a brief video showing the steps I took above and finishing off by using VMware View client to a XP desktop.



Author: Dale Scriven


19 thoughts on “Load Balancing VMware view with Citrix Netscaler

  1. Hi. Why have you configured the 4172 UDP/TCP services on the load balancer? The only protocol getting load balanced is 443. After that the View security server returns it’s PCoIP external URL and the View client communicates directly with the security server. So, the load balancer is never balancing PCoIP traffic. Just a little confused why the 4172 rules are on the load balancer.

    1. Hi, thanks for the comment, there are several different ways to load balance VMware View and indeed exposing each security server to the internet each with its own nat’d public IP and only load balancing 443 is definitely an option. But thats not what this configuration does, by setting each security server to the same URL and PCOIP external address means that you can load balance the traffic through a single IP address and only have minimum holes poked into your DMZ firewall. It also means you do not necessarily have to have the security servers within the DMZ.

  2. Hi, note that you need to define persistency groups or else a client might be redirect to different backend servers, based upon different protocols 🙂

  3. We like only to load balance connection servers without security servers because users placed “insite” any diffence between your description and this configuration?
    Any comment of that?

    1. Yes typically the configuration would be different internally, you could get the connection servers to act a secure gateways in which instance the steps outlined would match. However you would really want to only load balance 443/8443 traffic from the connection servers but that provides a problem that the source IP is incorrect. You would have to use DSR or USIP to correct that problem. I’m working on a blog post on that very subject.

      Kind Regards
      Dale Scriven

      1. To kind of take the question a little further. What would you set up in a scenario where the connection servers are just using for authentication? In our environment after authentication the thin client communicates directly to the VM. When setting up the VIP in netscaler with our networking team, we noticed that the connection drops once authentication completes. Essentially netscaler is a fancy RR right now. Any insight on what to monitor? Ping (current setup) is not sufficient (after an overnight resource performed unscheduled work on our production server rendering LDAP unusable). Lo and behold, Monday morning everyone trying to authenticate through this particular connection server was getting not entitled errors.

        1. Great question and thank you for it. Its actually something I’m working through at the moment because when you authenticate through the netscaler directly with connection servers by default the connection servers are told the SNIP of the netscaler is the source of the request and as you rightly put it the view client wants to connect directly with the desktop (again by default) this presents a problem because the source IP is wrong and the desktop refuses the connection.

          Now theres 2 ways to get round this and I’m currently trying to figure out which one I like best. First is to enable Secure Tunnel to desktop within the Connection server settings, This then makes the all the PCOIP traffic flow back through the connection server in the way it would proxy if it were a security server. This is the most simplistic approach however obviously the connection servers will need to be carefully sized so that as little performance degradation occurs as possible.

          The other method is to enable use source IP on the netscaler which instead of passing requests to back end servers telling them the SNIP is the source it will insert the actual client source within the transmission. This means then that the connection server and PCOIP traffic will flow as it would without a load balancer however requires more configuration on the netscaler side and possibly seperate nestlers for external and internal load balancing.

          As I say I’ve not decided which I think is best at the moment and this blog post really needs an update to match the white paper I’ve written but I will shortly be writing a load balancing connection server post and will probably outline both methods and let you decide.

          Thanks for the comment

          1. What about monitoring the health of a connection server on the netscaler side? Any input is appreciated.

          2. Sure, What I would do now is actually create a custom monitor to check for the presence of the favicon so from a putty session copy and paste this and bind it to the SSL 443 (and 8443) service groups.

            add lb monitor Connection_server HTTP -respCode 200 -httpRequest “HEAD /favicon.ico” -LRTM DISABLED -secure YES

  4. this is great!! I am very new so excuse my question if it seems stupid. one question, I don’t see where you mentioned the outside IP address or URL that bother security servers are mapped too, is this because you setup the netscaler to listen on 443 and 4172?

    1. Thanks for the comment, I’m not too clear on what you mean but within the view console and on he security servers page you can edit each security server to input the load balanced IP address and also the external url you have chosen (for example view.company.com). You can also do this for the blast protocol. I do have a VMware white paper being released soon which goes into more detail and I’ve tidied up the config a little. In the meantime this configuration will work perfectly.

  5. I can’t reply to your last comment, so i’m adding a new one. So in essence, when you check for the favicon, you’re making sure that the view admin page is running properly which in turn SHOULD mean that the connection server is up and running.

  6. Nice write up. I’m curious how you setup the certs. Did you use a SAN cert with the names of your security servers and the name the users will use to connect to the view environment?

    1. Thanks for the comment for the security server certs I basically used IIS to generate a csr for say view.company.com then sent it off to my external certificate authority. Once thats come back you complete the certificate request in IIS and then export the certificate as a PFX (exporting the private keys in the process).
      Next you just need to import these into the local computer personal store of the security servers and give them the friendly name of “vdm” without the quotes.
      Lastly rename the self generated certificates friendly name (such as security.domain.local) to remove the vdm install the external CA’s intermediate and root certs and restart the security server.

  7. I hope you are still monitoring this…We are running View 6 and Using a Netscaler to Loab balance Security servers for remote access to View Desktops and to load balance Connection servers (with no security servers) for internal View desktop access.

    We chose not to use Security servers for internal View desktop connections or to tunnel internal View desktop connections through connection servers due to the fact if we have desktops tunneling through a connection server and lose connectivity to that particular connection server either planned or unplanned, users on that connection server will lose connectivity to their View desktops. Not tunneling internal connections through the connection servers allows us to lose a connection server and/or perform maintenance on them during normal hours.

    We are also using CPA (Cloud Pod Architecture) so users can have access to a desktop in either of our Datacenters.

    We have 2 Connection servers in Site A and 2 Connection servers in Site B. Our Netscaler for internal connections is like this –

    Servers tab – All 4 Site A and Site B Connections servers listed with their IP addresses.

    Service Groups tab – “Site A Connection Servers group” with 2 Site A Connection servers listed in Configured Members and HTTPS (443) Monitor configured and “Site B Connection Servers group” with 2 Site B Connection servers listed in Configured Members and HTTPS (443) Monitor configured.

    Service Tab – Site A Connection server 1-Configured Monitors Https(443), Site A Connection server 2-Configured Monitors Https(443), Site B Connection server 1-Configured Monitors Https(443), Site B Connection server 2-Configured Monitors Https(443)

    Virtual Servers tab – Name-view.myorg.interal – Protocol SSL – Service Groups – Site A Connection Servers group and Site B Connection Servers group.

    So, a View client who connects to view.myorg.interal hits the Netscaler VIP with all 4 Connection servers and in turn will authenticate with one of the 4 connection servers. After authentication the Client with have direct access to the View Desktop at either Site A or Site B depending on the connection server it authenticates to. Using CPA should insure all connection servers in both sites should have knowledge of each other connections.

    At least I think that is how it all works 🙂

    Any recommendations? I saw an above poster doing the same thing with load balancing the Connection servers internally without Security servers but without CPA and had mentioned receive Non Entitled Errors. We are not using Persistency Groups for the internal connections but are using them for the external connections where remote users connect through Security servers

    1. Hi Thanks for the comment. TBH, I’ve not run it in the configuration you are describing in a while, I suspect that any errors will mostly likely centre around the fact that when you authenticate through the netscaler in that fashion the desktop see’s the Subnet IP of the NetScaler as the source address. Let me have a play with it and I’ll get back to you shortly. Otherwise the design you have said is sound.


Leave a Reply