Configure StoreFront Multi-Site configurations

StoreFront Multi-Site configurations are still fairly unknown. I guess this has something to do with XenDesktop 7 still being relatively new (I know, it’s actually a StoreFront 2.0 feature) and with this I mean, the addition of the XenApp functionality. Since zones are no longer part of XenDesktop 7, or the Flex Management Architecture (they’ve disappeared together with the Local Host cache) you’ll have to, in most cases, create separate Sites to achieve similar results. Especially if Sites are geographically separated. When using StoreFront Multi-Site configurations we can still add in load balance and failover capabilities, even when using geographically ‘Dispersed’ Sites, just like we are (or were) used to with zones. No NetScaler required, although it’s probably a good idea to implement one anyway.

Another approach

With FMA your central SQL database is probably one of the most important components of your infrastructure, if it’s down, your Site won’t accept any new connections (due to the lack of LHC) and you won’t be able to make any configuration changes as well. Of course there are ways to implement additional SQL stability, like: Clustering and mirroring for example, but what if that doesn’t function as well?! And lets be honest, it often doesn’t. Then an alternative, or extra, Site would be a good thing to have in place, to say the least. What if you have two active Sites, A & B, and Site A or B, for whatever reason, becomes unreachable? Or perhaps you’d like a way to load balance your traffic between Site A & B (like we do (or did) with zones).

You may also want to point, or map, your users as close to their data (center) or Site as possible, like we can do with the IMA (XenApp) zone preference policies for example. Perhaps you’d like to configure and assign a (non active) recovery Site? Because of the added functionality, and at the same time, change in architecture as far as the RDSH solutions (formar XenApp) are concerned, we’ll need to rethink our designs when it comes to FMA vs IMA and the replacement of WebInterface with StoreFront. But don’t worry, it’s all (still) there, even without multiple WebInterfaces / StoreFronts and or NetScaler(s) configured, although this is probably a setup which we won’t see that often, but still.

Default StoreFront behaviour

By default StoreFront will enumerate all apps and desktops it can find from all Sites and Farms configured, these can come from: XenDesktop, XenApp and or VDI-in-a-Box Controllers. So when we add in an extra set of (Delivery) Controllers from another (load balance, failover or recovery) Site it will automatically enumerate any resources your users will have access to. Not a bad thing per se but this will also mean that if an application and or desktop is available from multiple Sites your users will see an icon for each resource, meaning double icons, assuming you have proper permissions on both Sites that is. Here’s where Multi Site configurations come in. During this article I assume we are using at least two sites or more, I’m mentioning this because some of the features discussed can also be applied on single Site / Farm configurations, or deployments, as Citrix likes to call them.

Multi Site features

With a StoreFront Multi Site configuration, when a desktop or application is available from multiple Sites and or Farms, StoreFront will aggregate all instances of that particular resource and presents it with a single icon. For this to work, deployments do not need to be identical per se, but the desktops and or applications do need to have the exact same name and path on each server, all other configured characteristics need to  match as well. Due note that App Controller applications cannot be aggregated. This comes from the E-Docs website: When a user starts an aggregated resource, StoreFront determines the most appropriate instance (Delivery Controller) of that resource for the user on the basis of server availability, whether the user already has an active session, and the ordering you specified in your configuration. Now that’s smart right? Check out some more details here.

User Mapping and failover

Multi Site StoreFront configurations also lets us set up highly available deployments. We can configure load balancing, failover or a (non active) disaster recovery site. You also have the ability to set up something called User Mapping. This basically means you can set up access to a specific deployment based on certain user memberships of Microsoft Active Directory groups, zone preference policies if you will. This allows you to create multiple Sites, or deployments, offering different resources, still all aggregated through the same Store(Front), simply by adding in multiple (Delivery) Controllers. However, your users will only see what their permissions allow them to. Another example would be to create two (can be more of course) identical Sites and configure one group of users to always connect to Site A and another group of users to always connect to Site B. This way Site A can also function as a failover Site for Site B and vice versa. Preferably you’ll use at least two separate StoreFront servers, one (or more) per Site. Again, all users will need to have permissions on the same apps and or desktops at both Sites, see my notes on this earlier under Multi Site features.

Load balance

Remember that in a multi site configuration StoreFront will aggregate all instances of a particular resource, from all configured Sites / deployments, and will present this to the user in the form of one single icon, so no issues there. Of course this setup would also work without user mapping configured, although then it would be active / passive instead of active / active, unless you have 2 or more StoreFront servers in combination with a NetScaler configured. Active / passive would also mean you can do with just one StoreFront server if you like. This same setup (although configured differently) could also be used to load balance connections between multiple Sites. Instead of contacting one of the ‘extra’ Controllers for redundancy purposes, connections will be randomly spread across the configured controllers, evenly distributing the load, again using just one StoreFront server, although you could, and probably should, use more. This is all done by configuring certain attributes within the so called web.config file on StoreFront, a bit more on this in the conclusion.

Subscription synchronization

If your users connect to multiple StoreFront servers residing in different StoreFront deployments, or server groups, and they are able to access similar applications and or desktop within these deployments than you might want to consider implementing something called subscription synchronization. This will ensure that all StoreFront servers in both, or multiple, deployments will exactly know which apps and or desktops the user is subscribed to, so they won’t need to subscribe to an application again when logging on to one of the other deployments. You can configure periodic synchronization of users’ application subscriptions between stores in different server groups. However, for this to work all stores need to have the same name and all server groups must reside within the Active Directory domain containing your users accounts or within a domain that has a trust relationship with the user accounts domain. The Citrix E-Docs website  will tell you more about it.

Optimal NetScaler Gateway

If your deployments each do have a separate NetScaler configured, then StoreFront enables you to define the optimal, or preferred, appliance for users to access each of the deployments. Here is a good example taken from the E-Docs website: If you create a store that aggregates resources from two geographical locations, each with a NetScaler Gateway appliance, users connecting through an appliance in one location can start a desktop or application in the other location. However, by default, the connection to the resource is then routed through the appliance to which the user originally connected and must therefore traverse the corporate WAN. With ‘Optimal NetScaler’ routing we can change this. Besides the above you can also use NetScaler to load balance the connection made from your StoreFront server to, for example, your delivery controllers within your Site, and load balance those as well. The same can be done from your NetScaler to multiple StoreFront servers you might have, the combinations are endless, so to speak, out of scope for now though.

The web.config file

That’s where all the magic happens. All of the above configurations, including disaster recovery Sites not mentioned, need to be configured within the web.config file. By default it’s located here: C:inetpubwwwrootCitrixstorename directory, where ‘storename’ is the name specified for the store when it was created. Be aware, that after making configuration changes to the file, that some tasks become unavailable in the Citrix StoreFront GUI to prevent misconfiguration (why not build this functionality into the GUI instead?). Once the web.config file is updated and saved its effective immediately, if it’s configured incorrectly then StoreFront simply won’t work. At least you’ll know what caused it right?!

Conclusion

We briefly talked about editing the web.config file in general, and some of the added functionality Multi Site configurations have to offer. I also thought about showing you a thing or two, for example, how, and where, to configure load balancing or failover Multi Site StoreFront configurations and configure a disaster recovery Site which will then only be used when all other Sites are down. But, to be honest, it has already been described clearly on the Citrix E-Docs website, so I won’t even bother, since I’ll probably won’t be able to top it anyway. The main focus of this article is to raise some extra awareness towards some of the ‘hidden’ but powerful features StoreFront has to offer. So without further ado, if you want to know more about configuring failover and load balanced multi Site configurations, user mapping, optimal NetScaler routing, Recovery Sites and StoreFront subscription synchronization, have a look here. The topics discussed are all listed at the bottom of the page. I hope this has been somewhat helpful. If you have any questions and or remarks, please let me know, it’s easy to miss a step or two along the way. Thanks!

Bas van Kaam ©

Reference materials used: The Citrix E-Docs website.

Join [displaycount list=”Bas van Kaam”] other subscribers !

[optinform]

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.