Share this post

Citrix StoreFront, which is the successor to Citrix Web Interface, authenticates users to XenDesktop sites and XenApp farms (as well as all other products like: App Controller (SaaS Apps), and VDI-in-a-Box) enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver. StoreFront is an integral component of XenDesktop 7 but can be used also with XenApp and XenDesktop 5.5 and up deployments. When planning your StoreFront deployment, consider the following recommendations:

  • Citrix recommends hosting StoreFront on a dedicated instance of IIS. Installing other Web applications on the same IIS instance as StoreFront could have security implications for the overall StoreFront infrastructure.
  • In a production environment, Citrix recommends using HTTPS to secure communications between StoreFront and users’ devices. To use HTTPS, StoreFront requires that the IIS instance hosting the authentication service and associated stores is configured for HTTPS. In the absence of the appropriate IIS configuration, StoreFront uses HTTP for communications.
  • StoreFront servers must reside within the same Microsoft Active Directory forest as the XenDesktop or XenApp servers hosting users’ resources. All the StoreFront servers in a group must reside within the same domain. To enable smart card and user certificate authentication, users’ accounts must be configured within the Active Directory forest containing the StoreFront servers.
  • Consider implementing multiple StoreFront servers to ensure high availability if the primary server hosting StoreFront fails.
  • Configure the external load balancer to fail over between the servers to ensure users have uninterrupted access to their applications and desktops.

For more information about StoreFront, see the StoreFront documentation in Citrix eDocs.

Key features

Web Interface was written in J# and Microsoft announced end of life for this technology. As the result StoreFront has been developed from scratch using more flexible and powerful framework than Web Interface that enables StoreFront to provide next generation features, such as:

  • Unified StoreFront for XenApp and XenDesktop resources that can also deliver SaaS & Native Mobile applications (through App Controller)
  • Simplified Account Provisioning, which enables users to connect to assigned desktops and applications by simply entering their email or server address, or by opening a Provisioning File in Receiver
  • Access from any Receiver with a consistent user experience, including automatic fallback to Receiver for HTML5 on Receiver for Web sites if a native client isn’t available locally and can’t be installed
  • Synchronization of resource subscriptions across all platforms and devices (Follow-me Apps & Data)
  • Cross-farm aggregation and de-duplication, that aggregates and delivers a unique set of applications from multiple farms across different sites
  • Farm-Based Optimal HDX Connection Routing, which enables the use of the nearest NetScaler Gateway for HDX traffic routing independent of the NetScaler Gateway used for initial authentication.

StoreFront Architecture

A typical StoreFront infrastructure for environments without XenMobile is shown in Figure 1. For further information about XenMobile deployments please refer to CTX138635 – Citrix Reference Architecture for XenMobile 8.5

Figure 1

Figure 1

 

StoreFront consists of the following components:

  • Authentication service – This service, which is an integral part of StoreFront, authenticates users to XenDesktop sites, XenApp farms, and App Controller (for SaaS apps). The authentication service ensures that users only need to log on to StoreFront/Receiver once.
  • Store – The store retrieves user credentials from the authentication service to authenticate users to the components providing the resources. The store also enumerates and aggregates the resources currently available from XenDesktop sites, XenApp farms, and App Controller (SaaS Apps). Users access the store through Citrix Receiver or a Receiver for Web site.
  • Application Subscription Store (Data Store) – This store saves and indexes the application or desktop subscriptions of the users on a per-StoreFront Store basis. In contrast to older versions of StoreFront, where an external Microsoft SQL database was required, the new Application Subscription Store uses the built-in Microsoft Windows Extensible Storage Engine to store details of users’ app subscriptions locally on StoreFront servers. When joining a StoreFront server to a Server Group the replication of data between all members is configured automatically.
  • Receiver for Web site – This site enables users to access stores through a webpage. Furthermore, this site can verify the version of Receiver installed locally on the endpoint and guide the user through an upgrade or installation procedure if required. In scenarios where Receiver cannot be installed locally, Receiver for HTML5 can be enabled for the Receiver for Web sites so that users can access resources directly within HTML5-compatible web browsers.
  • Desktop Appliance site – Desktop Appliance sites provide users of non-domain desktops with an experience similar to that of users with domain-joined desktops. The web browsers on desktop appliances are configured to start in full-screen mode displaying the logon screen for a Desktop Appliance site. When a user logs on to a site, by default, the first desktop (in alphabetical order) available to the user in the store for which the site is configured starts automatically. Desktop Appliance sites are only created by default when StoreFront is installed and configured as part of a XenDesktop installation.
  • XenApp Services site – Users with older Citrix clients that cannot be upgraded can access stores by configuring their clients with the XenApp Services URL for a store. This site can also be used from domain-joined desktop appliances and repurposed PCs running the Citrix Desktop Lock.
  • NetScaler Gateway – Citrix NetScaler Gateway is a physical or virtual appliance, which provides secure remote access to internal resources. The appliance is typically located within the DMZ and exposed to the Internet. When a user connects to NetScaler Gateway they will need to authenticate before any access to internal resources is granted. The access can be controlled by the admin by means of granular application-level policies and action controls.

Users connect to StoreFront using three different methods:

  • Receiver for Web – This component allows users to access their stores from a web browser. Desktops and applications are launched using the locally installed Receiver or Receiver for HTML5 for clientless access.
  • Native Receiver – To take full advantage of the features StoreFront has to offer, users should connect into the Citrix environment using Citrix Receiver on their desktop or mobile device. Citrix Receiver is available for Android, iOS, Mac, Window 8/RT, Windows Phone, and soon Linux.
  • XenApp Services Site (PNAgent) – By default, StoreFront creates a XenApp Services site to provide access from legacy devices to the XenApp and XenDesktop resources available in a store. Even though XenApp and XenDesktop resources can be accessed through the PNAgent site, resources from App Controller are not visible. This site enables access from a variety of thin clients, Receiver for Enterprise for specific use cases such as as a seamless desktop experience, Fast Connect, and Desktop Lock for repurposed PCs.

StoreFront Planing Guidelines

Decision: Web Interface or StoreFront

As outlined earlier Web Interface and StoreFront are two different solutions, whose feature sets overlap in many areas, but also offer a variety of distinct features. Therefore it is very important to review the capabilities of each product against their requirements. In general, Citrix strongly recommend to build new solutions based on StoreFront, since new features will not be added to Web Interface and end of life has been announced for Web Interface. Furthermore it is important to understand that officialy Web Interface does not support XenDesktop 7 – it is possible to add XenDesktop 7 controlers to Web Interface config but this is not recomended. The good news is that Citrix officially announced that Web Interface support is extended for XenDesktop 7.5.

The Web Interface features that are not currently available in StoreFront are shown in Table 1:

AreaFeature
Deployment OptionsWeb Interface on NetScaler (StoreFront is deployable as an application behind NetScaler but runs on separate servers)
AuthenticationDelegated Kerberos Authentication
Active Directory Federation Services (ADFS) 1.0 integration
Account self-service (SSPR) (reset/unlock with security questions)
Smart card authentication via browser (Native Receivers required)
Domain pass through authentication via browser (Native Receiver for Windows required)
Support for Novell NDS
Anonymous authentication
OtherMessaging (user notifications)
Settings per location (IP Subnet)
Client proxy settings configuration
Offline Apps (Users cannot access offline applications or App-V sequences through Receiver for Web sites. Native Receiver is required)
Compact/Low graphics Mode and embedding

Decision: High Availability

If the server hosting StoreFront or the respective web service is unavailable, users will not be able to launch new virtual desktops, published applications or manage their subscriptions. Therefore at least two StoreFront servers should be deployed to prevent this component from becoming a single point of failure. The load balancing technique should be used to distribute users across multiple StoreFront servers. The list of available solutions includes, but is not limited to:

  • Citrix NetScaler – an intelligent load balancing appliance, which is capable of verifying the availability of the StoreFront service
  • Windows NLB – less sophisticated load balancing mechanisms, can perform very basic availability checks only (e.g. server up / down) but cannot determine the status of individual services. This could result in users being forwarded to StoreFront servers that cannot process new requests (e.g. server up but web service down).
  • DNS round robin – provides rudimentary load balancing across multiple servers without performing any checks on availability. If one server fails, only a portion of user requests will be affected.

Recommendation: At least two StoreFront servers should be deployed for redundancy reasons and Citrix NetScaler or another intelligent load balancing solution should be used for load balancing and fault tolerance. To simplify management of the StoreFront infrastructure, both servers should be member of the same StoreFront Server Goup.

Decision: Security – Inbound Traffic

Communications from the web browser or Receiver and StoreFront server include user credentials, resource sets, and session initialization files. This traffic is typically routed over networks outside the datacenter boundaries or on completely untrusted connections (such as the Internet). Therefore Citrix strongly recommends that this traffic is encrypted using SSL.

Note: By default, Citrix Receiver requires SSL to connect to StoreFront. This means email-based account discovery or the manual configuration of a StoreFront store in Receiver will not work unless a valid and trusted SSL certificate has been implemented on the StoreFront server and/or the respective external load balancer.

Decision: Security – Backend Traffic

User credentials are sent between StoreFront and the XenApp Controllers, XenDesktop Controllers and the App Controller virtual appliance. In a typical session with a XenDesktop Controller, the StoreFront server passes user credentials to the Citrix XML Service for user authentication and the Citrix XML Service returns resource set information. A TCP/IP connection and the Citrix XML protocol is used to pass the information between the StoreFront server and the XenDesktop site. The XML protocol uses clear text to exchange all data, with the exception of passwords, which are transmitted using obfuscation.

Note: The user logon workflow in StoreFront is different to Web Interface. For detailed description see the following post: Web Interface vs StoreFront logon process

Recommendation: For Citrix environments with high security requirements, encrypt StoreFront to XenApp, XenDesktop and App Controller communications. For further information how to secure XenDesktop environment please refer to Citrix eDocs

Decision: Delivery Controllers

To provide users with desktops and applications, StoreFront must be configured with the IP address or DNS name of at least one Controller in each XenDesktop site and/or XenApp farm. For fault tolerance, multiple Controllers should be entered for each site and/or farm specified. StoreFront will automatically failover to the second server in the list in case the first server becomes unavailable (This is called active/passive configuration). For large infrastructures or environments with a high logon load an active distribution of the user load active/active configuration is recommended. This can be achieved by means of an industry proven load balancer with built-in XML monitors and session persistency, such as Citrix NetScaler.

Recommendation: At least two Controllers should be specified per XenApp farm / XenDesktop site.
Recommendation: For large environments, active/active load balancing of the delivery controllers is recommended.

Decision: Beacons

Citrix Receiver uses beacon points (web sites / urls) to identify whether a user is connected to an internal or external network. Internal users are connected directly to resources while external users are connected via Citrix NetScaler Gateway. Citrix Receiver continuously monitors the status of network connections (e.g. link up / link down or change of the default gateway). When a status change is detected, Citrix Receiver will first check that the internal beacon points can be accessed before moving on to check the accessibility of external beacon points. StoreFront provides Citrix Receiver with the http(s) addresses of the beacon points during the initial connection process and provides updates as necessary.

Recommendation: Configure as least two highly available external beacons that can be resolved from public networks so that Citrix Receiver can determine whether users are located behind an Internet paywall, such as in a hotel or Internet café. It is strongly recommended that highly available websites are specified as beacons.

Decision: Auto Provisioned Apps (Keywords)

StoreFront displays applications differently to Web Interface. Instead of having all accessible applications appear on the home screen, first time users are invited to choose (subscribe) to the applications they want to regularly use after they logon. Before a user can launch an application, they must first choose which applications should be placed on their home screen. This approach, deemed “Self-Service” apps, allows users to restrict the applications that they see on their home screen to the ones that they use on a regular basis. The applications chosen by every user for each store are recorded by the subscription store service so that they can be displayed on the Receiver home screen from any device that the user connects from (Follow me Apps).

To avoid users from having a blank screen when they first logon, it is recommended that administrators automatically subscribe users to a few core applications. To do this, add KEYWORDS:Auto to the application or desktop description in XenApp or XenDesktop. Another option that can be used to organize applications is KEYWORDS:Featured. Unlike the Auto keyword which places certain apps on the home screen, the Featured keyword only places apps in the Featured category. The app will also appear in another category if a Client Application folder has been specified.

In addition the string KEYWORDS:prefer=”application” can be used to specify that the locally installed version of an application should be used in preference to the equivalent delivered instance if both are available.

For further information please refer to eDocs – Optimize the user experience.

Decision: Scalability

 The number of Citrix Receiver users supported by a single StoreFront server depends on the hardware specifications and on the level of user activity. Early testing results indicate that, a single StoreFront 2.0 server with twin 2 GHz quad-core CPUs and 8 GB RAM supports up to 25,000 user connections per hour in a light usage scenario (users log on, enumerate their resources, and access existing subscribed resources) or up to 6000 user connections per hour in an intensive usage scenario (users log on, enumerate their resources, and then subscribe and unsubscribe to a resource.)

For the optimum user experience, Citrix recommends that not more than 10 XenDesktop, XenApp, App Controller, and VDI-in-a-Box deployments are aggregated in a single store.

Sample StoreFront Deployment Scenarios

Scenario 1 – 500 Users

In this scenario 500 users should be supported. The users logon to StoreFront in the morning over a period of 2 hours and connect to their virtual desktop. Users typically they keep their sessions open all-day and occasionally access StoreFront after the initial login.

The load on the StoreFront servers in this scenario can be considered very light. Therefore two StoreFront servers have been chosen for redundancy reasons only. Both StoreFront servers are equipped with 2 CPUs and 2GB of RAM to allow for future growth without requiring changes to the access infrastructure. A pair of NetScaler appliances provide load balancing, SSL offloading and availability monitoring for the StoreFront servers. The XenDesktop Controllers are configured in failover order (active/passive) within StoreFront for simplicity reasons. An active/active load balancing of the XenDesktop Controllers is not required due to the small number of users. The example of StoreFront design is shown in Figure 2.

Figure 2

Figure 2

Scenario 2 – 5,000 Users

In this scenario, 5,000 users should be supported. As opposed to scenario 1, the users logon to StoreFront in the morning over a very short period of time. Furthermore, users tend to disconnect and reconnect to their desktops multiple times a day.

Due to the high logon load in the morning, three StoreFront servers need to be implemented. All three StoreFront servers are equipped with 2 CPUs and 4GB of RAM to ensure sufficient capacity. A pair of NetScaler appliances provide load balancing, SSL offloading and availability monitoring for the StoreFront servers. Furthermore, these appliances are leveraged to load balance the XML requests sent from the StoreFront servers to the XenDesktop Controllers. This ensures an even distribution of the load among the XenDesktop Controllers and avoids a potential bottleneck. StoreFront is configured to connect to a NetScaler vServer rather than the XenDesktop Controllers directly. The example of StoreFront design is shown in Figure 3.

Figure 3

Figure 3

Scenario 3 – 10,000 Users

In this scenario 10,000 users should be supported. Similar to scenario 2, users logon to StoreFront in the morning over a very short period of time and typically disconnect and reconnect to their desktops multiple times a day. As opposed to scenario 1 and 2 the infrastructure needs to be distributed across two datacenters for disaster recovery reasons. The environment should provide 100% tolerance to a full datacenter outage.

To cope with the high logon load in the morning and the constant load during the day three StoreFront servers with 4CPUs and 4GB of RAM are required. Alternatively, two servers with 8CPUs and 8GB of RAM could be implemented. However, to minimize the impact from a single server outage and to have more management and maintenance flexibility a three-server solution is recommended. Because of the 100% tolerance requirement, the same number of StoreFront servers should be implemented in each datacenter.

Users can access the environment by means of the FQDN example.mycompany.lab. The incoming user requests are distributed by means of Global Server Load Balancing (GSLB). This means the NetScaler HA pairs located in both of the datacenters are configured as authoritative DNS servers for the aforementioned FQDN. When a user initiates a connection to the example.mycompany.lab FQDN, one of the NetScaler HA pairs (selected randomly) will determine which datacenter is best suited to serve the request. This decision can be based on proximity, home IP subnet or similar properties of the user. Session persistence is achieved using a client side cookie automatically set by NetScaler.

Since a user can be forwarded to both datacenters, it is required to synchronize the application subscriptions. This can be achieved be means of PowerShell Commandlets as outlined in eDocs – To configure subscription synchronization.

In addition, the NetScaler appliances within each datacenter also provide load balancing, SSL offloading and availability monitoring for the StoreFront servers. These appliances are also leveraged to load balance the XML requests sent from the StoreFront servers to the XenDesktop Controllers. This ensures an even distribution of load amongst the XenDesktop Controllers and avoids a potential bottleneck. StoreFront needs be configured to connect to the NetScaler vServers in both datacenters rather than the XenDesktop Controllers directly. The example of StoreFront design is shown in Figure 4.

Figure 4

Figure 4

 

 

Related Posts:

XenDesktop 5 – logon process and communication flow

How to migrate a XenApp 6.5 Data Store to a new SQL server

XenDesktop 7 – missing features

XenDesktop 7 – Editions and Licensing explained

XenDesktop 7 – Desktop Director explained