Brief notes on NetScaler and Citrix StoreFront

I spent the last two days intermittently trying to set up NetScaler and Citrix StoreFront in my home lab. It was a mixed bag partly due to my nature of just jumping into something and figuring it out as I go along :) but compounded by the fact that while there’s a lot of documentation on the Internet they seem to be either outdated or don’t explain the big picture of what we are trying to achieve. (Or maybe I am just slow in picking it up – wouldn’t put that possibility aside!)

Anyways. Here’s a couple of stuff in no particular order. 

This PDF is the official documentation on setting up NetScaler with Citrix StoreFront. It’s a good one – lots of screenshots etc. Page 19 onwards seems to be outdated though with the latest version of NetScaler that I have – 11.1 53.11. 

When I started this exercise though I was on a much older version of NetScaler – 10.5 56.22. I started setting up the NetScaler as a gateway (e.g. http://ctxstorefront.myfqdn) to my internal StoreFront servers (http://data01.myfqdn and http://data02.myfqdn), and my steps were more or less along the lines of the PDF above which I discovered later. That wasn’t a success though coz when I’d connect to the NetScaler gateway it gave some errors (I forget what now). Digging into this I realized that the wizard also creates a load balanced virtual server on the NetScaler and that was showing as down. Dug into that a bit and found out that the underlying monitor probes to the two StoreFronts were failing. If I separately created services representing my StoreFronts and attach the same monitor (basically, a monitor of type STOREFRONT, with the correct StoreName etc) it fails. 

That was good to know coz I learnt a bit about the monitor probes. :) I found the following in my NetScaler logs:

That’s same as what the GUI was telling me but I was additionally able to find what error code was being generated (thanks to this KB article):

So it runs a Perl script basically. Nice. Went through that script and here’s the relevant section:

So it tries to access http(s)://<my delivery controller>/Citrix/<my Store>/discovery and gets a 200 error. Odd that it gets it, because if I try to probe that URL via cURL from NetScaler, I get a 404 error (which is sort of correct; I get a 403 error via IE and that’s the correct one I think):

Anyhoo, that stumped me for a while until I found forum/ blog post where they said upgrading to a newer version of NetScaler supposedly fixes this. So I went down that route, and yes, it helped. 

After upgrading though my UI changed. :)

The new UI is very different. But that’s good I think, coz it forced me think at least on what exactly am I trying to achieve here; and to take a step backward and understand what is going on. So here’s my understanding:

  • We have StoreFronts. :) That’s the thing you actually connect to. 
  • We can have a group of StoreFronts for High Availability. You can configure each of these independently or you can keep them in sync from the UI itself. 
  • For each StoreFront we need to specify a base URL.
    • For a single StoreFront it’s easy – http://data01 or whatever (where data01 is my StoreFront server name in this case).
    • But what about when I have a group of StoreFronts? If I am keeping them in sync via the UI itself, the base URL I define on one of them will be pushed out to all. So all my StoreFronts will have a base URL of http://data01 even though they might be called data01, data02, etc. That’s a problem coz all my clients will only connect to the first one as that’s where DNS will point clients to.
  • To avoid the above situation for multiple StoreFronts we need a common base URL which can be load balanced across all. A regular DNS round-robin situation won’t work coz we also need clients to stick on with whichever StoreFront they connect to, and also some form of monitoring to ignore StoreFronts that are down would be good to. So this is where the NetScaler first comes in!
  • Create a Virtual Server on the NetScaler that will load balance the various StoreFront services we define on it. Simple stuff – just HTTP or HTTPS services that are load balanced. Add the STOREFRONT type monitor. And a Persistence of type COOKIEINSERT. That’s all. (Oh, and add SSL certs etc if you are using HTTPS). 
    • I haven’t gone through this link but am putting it here as a reference to my future self – pretty sure I must have missed something when setting up things now. Also, that link goes into some scenarios such as where we do SSL termination at the NetScalers. 

What I realized as I thought about this is that this Virtual Server I create above is the main thing. Going by my URLs above, I should have http(s)://ctxstorefront.myqdn load balance among http(s)://data01 and http(s)://data02. Forget about the whole external access stuff for now. 

Once I do this and ensure things are working (they do), now I can think about external access. What does the NetScaler need to do there? It doesn’t need to do any load balancing coz that’s already setup; so all it needs to do is provide a VPN gateway sort of service for external clients to connect to! So that means a new Virtual IP on the NetScaler. Create this using the wizard in the “Integrate with Citrix Products” > “XenApp and XenDesktop”. This will basically create a Virtual Server in the NetScaler Gateway section (note: not in the Load Balancing section). As part of configuring, we have to point this Virtual Server to a StoreFront. Here use the Load Balanced StoreFront Virtual Server that we created on the NetScaler above – this is where it all ties in! 

I could use the same internal URL for the external access too I guess and use split DNS – not sure, because I do have to specify this on the StoreFronts and I haven’t tried/ thought of any side effects – but in my case I simply decided to go with a different URL for the external access. Specify that for the certificate and Virtual Server etc, add that to DNS, and now I can access the StoreFronts externally too via the NetScaler. 

If I were to go to the Virtual Server in the Gateway section there’s no obvious mapping from this one to the internal load balance Virtual Server. But there is. It’s in the policies section. That has a Published Application pointing to the load balanced URL (including the Store name (actually, there’s two policies – one for the Web another for the Receiver, to capture the different names)) so that’s how the traffic flow works. Users hit the gateway, the gateway does the authentication etc and checks its policies, finds one that offers uses the StoreFront published application at such and such URL, and it looks that up (it is with itself) and thus hits the load balanced Virtual Server, and so on … 

Finally! I have some idea of how this all ties in together. :)