Within the Citrix Consulting organization, many of our customers are in the midst of transitioning from Web Interface to StoreFront or building new with StoreFront, which means there are a common set of configuration questions coming in from the field about how to design StoreFront. By now we should all know it is not the same as Web Interface, right? So the purpose of this article is to start putting some of these common design guidelines we have developed out there to try to answer questions like how many Stores should I have?, how do I divide my servers into server groups?, what are subscriptions?, why do I care about subscriptions?, and whatever happened to that database…?.
The first most obvious way that StoreFront is different than Web Interface is the whole notion of “subscriptions” – those favorite icons that users can either select on their own or administrators can push to the home screen for them via keywords in the published application (or desktop) properties. Web Interface had nothing like this: users either saw the icons or they did not; there was no user preference. So what are these things and why do we care?
First as to the what: subscriptions are why StoreFront 1.x required a database. In StoreFront 2.x, we got rid of the database and moved this data into a flat file, leveraging the Windows Extensible Storage Engine, called “PersistentDictionary.edb” that is stored on each StoreFront server in either the %ProgramFiles%\Citrix\Receiver StoreFront\Services\SubscriptionsStoreService\<Store Name> folder for versions previous to 2.6 or in the C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Citrix\SubscriptionsStore\<#_Citrix_Store Name>\PersistentDictionary.edb folder starting with version 2.6 (remember that for your antivirus exclusions). Based on the path, clearly subscriptions are per Store (StoreFront website) by default. If you export the subscription data from a Store and open it up, we can see that each subscription consists of a string that includes:
- User SID
- Site/Farm name (as defined in the StoreFront store)
- Application/Desktop name
- Unique, per subscription GUID
- “subscribeddazzle:position#” with the number related to the application/desktop icon position on the screen so that the icons maintain their order
So not only are the subscriptions stored in a per-Store directory, but they include the Site name in the metadata. This brings us to the why we care:
- Subscriptions are not shared between Stores with different names by default. This means that if you define multiple Stores on a StoreFront server, subscription data will be unique for each. Replication schedules between Stores with different names also cannot be configured.
- Therefore, within a StoreFront server group, limit the number of Stores that a given user community will access, with one being optimal, to provide a consistent user experience. This helps guarantee consistent subscription data and is very different from most Web Interface deployments, which usually included separate internal and external access websites (usually multiple external access websites: one for each Gateway). Having one Store also simplifies the native Receiver experience when users are prompted to add the available Store(s).
- While subscriptions are automatically synced per Store on write between servers in the same server group, nothing is synced by default between StoreFront servers in different server groups. If you unify multiple StoreFront server groups behind a GSLB’d URL (why you would have more than one server group we will get to in a minute), you will want to share subscription data between the server groups to provide a consistent user experience.
- Synchronization of subscription data between server groups is accomplished via a replication schedule, which can be set to occur either at set times every day or on a repeating schedule. What schedule is used should be based on how frequently users may move between servers in different server groups, since the only purpose is to keep the user experience consistent. Replication is a one-way pull action (from one server group to another) and only deltas are synched. This schedule is configured per Store, must be configured on all server groups participating in the synchronization separately to accomplish bidirectional synchronization (at alternating times so there is no risk that two servers groups will try to pull updates from each other at same time and cause corruption), and can only be set via PowerShell. In order for the replication to work, the Stores must be named identically between the server groups and the Sites defined within those Stores must be named identically within the “Manage Controllers” window based on what we know about the data in the subscription file.
- Subscription replication between server groups uses TCP port 808. When you configure the replication schedule, you are prompted to enter a “cluster address” which can be anything that will get you to a StoreFront server in the partner server group. Although you can specify a single StoreFront server, generally we recommend specifying a load balanced VIP address for high availability. Since any existing VIP you have for user access to the StoreFront sites will be on port 80 or 443, you will need a new VIP for this on TCP 808.
That covers the subscription portion of this article and brings us to the related topic of server group delineations. A server group is a set of StoreFront servers that share the same base URL and all configuration data. They all appear in the same StoreFront console and you share configuration changes you make on one of the servers via the “propagate changes” option. All servers in a server group also automatically share subscription data per Store as was mentioned previously. So there is consistency and ease of management to be gained by deploying your servers in a single server group. Sounds awesome, right?
Well right now, we only support up to five servers in a server group, so there is a scalability limit. StoreFront, similar to Web Interface, scales well, so five servers will go a long way and this number may change with future release so keep an eye out. Additionally, sometimes you do not want to share configurations between StoreFront servers – the prime example being multi-datacenter deployments, for which we are generally sticking to the server-group-per-datacenter guideline. When you have StoreFront servers split across multiple datacenters, you likely do not want that auto-replication of configurations since (1) latency could be an issue and (2) the sites/farms enumerated may vary. Think of a multi-zone XenApp 6.5 or earlier environment where you will want to specify the XML brokers local to the StoreFront servers at the top of the list (differing by datacenter). Also, independent geographies or business units that maintain their own XenApp farms / XenDesktop sites. Or StoreFront multi-site settings (more on these in a future article), which can be used to prefer users to one XenDesktop site over another, which will likely vary across datacenters.
So to summarize the takeaways:
- Subscriptions are stored in a “PersistentDictionary.edb” file, per Store by default
- Within a server group, keep to a single Store as much as possible per user community
- You cannot configure subscription replication between Stores with different names
- The Site name as defined within StoreFront matters when replicating subscriptions since the subscription includes the Site name
- Use a separate load balancing VIP (on TCP 808) for subscription replication between server groups
- Datacenters should be a server group boundary
Update October 31, 2014: Note that StoreFront 2.6 does allow multiple Stores to share the same subscription datastore by changing config files as described here after the Stores are created. This is not the original design of the product and has only been tested with up to three Stores, but is a functional workaround for customers who require more than one Store and want to share subscription data. The Stores sharing subscriptions must enumerate the same XenDesktop sites and XenApp farms. It is still recommended that the number of Stores be kept to a minimum to provide a consistent user experience.
