Knowledge Base

Overview

This section provides guidance on Ferroque Systems’ baseline standards for deploying Citrix StoreFront. Ferroque personnel must adhere to these standards for all deployments, and deviations should be documented in design parameters. Supplemental design considerations from field experience are also included, which are to be considered additive to design considerations found in vendor documentation.

Reference Links

• https://community.citrix.com/tech-zone/build/tech-papers/citrix-vdi-handbook/
• https://docs.citrix.com/en-us/storefront/current-release
• https://www.citrix.com/blogs/2015/06/30/storefront-scalability-update/
• https://community.citrix.com/tech-zone/design/design-decisions/storefront-gateway-integration/
• https://www.carlstalhood.com/storefront-cr/

Sizing Guidelines

Sizing Principles

• Production (and DR) sizing may vary based on environment size. Customers can scale out the quantity of servers vs. scaling up for large environments
• Although Citrix documentation indicates 8 GB RAM as sufficient, field experience has shown this to be an occasional bottleneck. If RAM is tight, we would recommend no less than 12 GB for production workloads
• Non-production sizing assumes few concurrent users and limited OS took stack agents (security/monitoring/management). For load testing, heavy OS tool stacks, high-use development, and QA environment scenarios, use production sizing
• Each Site or zone typically has two Delivery Controllers for n+1 resiliency. Access patterns and performance targets during logon storms determine the required number of servers. Adding more or larger servers can improve XML enumeration, VDA registration, and logon performance. Larger enterprise environments may perform best with three or four Delivery Controllers per Site or zone

Sizing Table

The following table outlines sizing for this component based on field experience and vendor recommendations. Specifications assume Windows Server 2019 or above is used.

Production

Parameter	On-Prem*	Azure	AWS	GCP
Instance Type	N/A	D4s_v5	M5.xlarge	N4-standard-4
CPU	4	4 (Inherited)	4 (Inherited)	4 (Inherited)
RAM (GB)	16	16 (Inherited)	16 (Inherited)	16 (Inherited)
OS Disk (Min.)	100 GB	P10 (128 GB)	100 GB GP2	100 GB Balanced

Non-Production

Parameter	On-Prem*	Azure	AWS	GCP
Instance Type	N/A	A2_v2	C5.large	N4-highcpu-2
CPU	2	2 (Inherited)	2 (Inherited)	2 (Inherited)
RAM (GB)	4	4 (Inherited)	4 (Inherited)	4 (Inherited)
OS Disk (Min.)	60 GB	S6 (64 GB)	60 GB GP2	60 GB Balanced

*CPU and RAM should not be overcommitted. On VMware, provide RAM a full reservation.

Build Standards Checklist

Hypervisor

On-Prem

• Configure cluster anti-affinity rules to place redundant servers on opposing hosts
• Avoid overcommitting compute resources of the servers (2:1 max if necessary)
• Provide full RAM reservation to servers if hypervisor supports this
• Use paravirtualized NIC for optimal performance, if available (VMXNET3, etc.)

Public Cloud

• Deploy redundant servers across different availability zones (AZs)
• If AZs are unavailable or not feasible, configure redundant servers into an availability set (Azure), placement group (AWS), or managed instance group (GCP)

Baseline Component Configuration

• Disable NETBIOS over TCP/IP on network adapters within each server OS
• Install StoreFront software (latest CU for LTSR, latest release for CR) on each server
• Ensure NT SERVICECitrixConfigurationReplication and NT SERVICECitrixClusterService are present in the local admins group of each server
• Create new deployment in StoreFront console with initial store
• Set base URL to the address users will enter into browser or Workspace app
• Join additional StoreFront servers to Server Group
• Configure beacons
• Configure default site via StoreFront Console
• Configure base store and Receiver for Web settings for use case needs
  • Store visibility [Advertise/Hide]
  • Authentication methods
    • Allow password changes [Yes/No]
  • Citrix Sites  / XML Brokers (add as HTTPS load balanced VIPs)
  • Favorites (Subscriptions) [Enable/Disable]
  • Custom session timeout (default 20 minutes)
  • Configure Workspace Control
  • Configure Client Interface Settings
  • Citrix Workspace app behavior
    • Deployment option [client + HTML5, client only, HTML5 only]
    • Allow users to download or upgrade Citrix client [Enabled/Disabled]
    • Source of Citrix Client if allowed [StoreFront/Citrix Website]
  • Ensure Loopback Processing remains On (reliance on OnHTTP indicates improper SSL/TLS certificate configuration)
  • Disable Protocol Handler (Not recommended)
  • Enable advanced health check (Multi-zone deployments only)
  • Enable Federated Authentication Service via PowerShell (FAS only)
  • Implement CTX227673 if permissible (FAS or Smartcard only)
  • Favorites (Subscriptions) Replication (Favorites + Multi-Server Group only)
• Add Citrix Gateway objects and bind to stores as required (Optional)
  • Use two to four STAs and match what is configured on Gateway vServer
  • Configure requesting of two STAs
  • Add multiple Gateways with unique VIPs if StoreFront will service multiple Gateways that use the same URL
  • Configure call-back address (requires firewall rule to Gateway vServer)
• Update Workspace app HTML5 client to latest release on each server (Optional)
• Customize StoreFront UI (Optional)
• Configure Optimal HDX Routing (Optional)
• Configure User Mapping and Multi-Site Aggregation (Optional)
• Propagate changes to Server Group

Baseline Security Configuration

• Install TLS SAN certificate containing base URL and each StoreFront server in the Server Group into Computer>Personal certificate store and ensure private key is present
• Add HTTPS 443 binding in IIS on each server
• Remove HTTP 80 binding in IIS on each server
• Create load balancing VIP for StoreFront servers
  • VIP and service group of type SSL, not SSL_BRIDGE
  • COOKIEINSERT persistence with timeout matching that of StoreFront
  • Set client IP address header of X-Forwarded-For on service group
  • Bind STOREFRONT monitor with Secure option enabled to service group
  • Bind HTTPS monitor (configure to accept 302 status) to service group
  • Bind a certificate to the VIP issued from a CA trusted by all internal endpoints
  • Harden VIP to accept TLS 1.2+ only, secure ciphers, HSTS (Reference for HSTS and ciphers)
  • Create internal DNS entry for StoreFront VIP (should match base URL)
• Disable ICA file downloads (2402+ only. Requires protocol handler remain enabled so Workspace Launcher can function and/or Workspace app web extensions installed. Does not support mobile clients)

Design Considerations

The following list is not comprehensive but is intended to cover many key design considerations for Delivery Controllers.

Internal vs. External Authentication Points

In most Citrix deployments, internal users authenticate directly through StoreFront, while external users authenticate via Citrix Gateway (also known as NetScaler Gateway). When using Citrix Gateway, client connections to Citrix are securely proxied through Citrix Gateway and not directly from endpoint to Citrix VDA. When using StoreFront only, the endpoint must have a line of sight to the Citrix VDA as it will attempt to connect directly to the Citrix VDA at session launch.

However, some customers choose to route both internal and external access through Citrix Gateways (usually using separate appliances for external vs. internal use for security). Others may restrict external access entirely, using StoreFront solely for internal access or requiring client VPN connections, though the latter is generally discouraged due to performance concerns.

Some customers want to ensure single sign-on (SSO) to Citrix resources from their domain-joined internal devices, avoiding a second login from their endpoints. However, they also require HDX traffic to be proxied through Citrix Gateways for security reasons. In this setup, users authenticate at StoreFront, and Citrix sessions are launched via the Gateway. Endpoints never connect directly to the Citrix VDA in this scenario.

Use of Subscriptions (Favorites)

By default, a StoreFront Store is enabled with the subscriptions feature. This allows users to “Favorite” their most commonly used apps and desktops in StoreFront to reduce clutter when they may have access to dozens of applications but may themselves only use a handful. This is a helpful feature in enterprise environments where the likelihood for high volumes of applications granted through broad or nested AD security groups may be commonplace.

Subscriptions replicate in real-time between servers of the StoreFront Server Group which requires very low latency between them in order to avoid database corruption. By default, the database is locally stored in a flat file format on each StoreFront server. Customers who will use subscriptions in very large Citrix deployments may prefer to store the subscriptions in a SQL database. This can enhance performance and open up more availability options.

For customers with few Citrix resources or tighter management of the rights assignments of their Citrix resources, it is often prudent to disable this feature on the store. In doing so, instead of users landing on a “favorites” tab by default at login, they are presented with their App/Desktop resource tabs only.

In multi-datacentre environments, the use of favorites becomes more complicated. If the deployment of StoreFront Server Groups spans datacentres above a few ms of latency between them, the risk of corruption increases in which case disabling subscriptions is recommended. Multi-datacentre deployments typically result in multiple StoreFront Server Groups being used regardless of the use of subscriptions.

If subscriptions are in use and multi-datacentres are involved, administrators will need to set up periodic replication schedules between equivalent stores in each Server Group. This is done using PowerShell and a load-balanced VIP for StoreFront servers listening on TCP 808. For Active/Passive deployments, a one-way synchronization schedule, perhaps running once a day, may be sufficient. In Active/Active environments, where StoreFront Server Groups at different datacenters simultaneously provide access to the same resources, staggered bi-directional synchronization schedules will be needed more frequently, possibly every few hours. Each synchronization event could take up to 15 minutes, and care must be taken to avoid overlapping schedules to prevent corruption.

Alternatively, leveraging SQL’s cross-datacenter availability features may offer a simpler and more robust solution, especially in large environments when subscriptions are in use.

Additionally, if users are likely to interact with multiple stores in their workflows and need to retain subscriptions (favorites) across stores, it is possible for multiple Stores to share the same subscription database within the StoreFront Server Group.

Authentication Initiator

Will the authentication occur via browser or via Citrix Workspace app? The former is often favoured for external access, while internal access workflows may prefer the Citrix Workspace app to allow for the integration of file type associations and application shortcuts with the endpoint OS.

Authenticating at Citrix Workspace app has additional security advantages such as native support for App Protection, Service Continuity (if using Workspace service instead of StoreFront), and eliminating dependency on ICA files. While these can be accommodated with browser access as well, they require browser extensions.

If using the Citrix Workspace app internally and using Citrix Gateways, both internal and external for access, customers need to specify a fake “internal” beacon in StoreFront to prevent the Citrix Workspace app from trying to connect directly to StoreFront.

When using the same URL for both internal and external Citrix Gateways, it is also important to specify on the StoreFront Citrix Gateway configurations the IP address of the VIP so StoreFront knows which Citrix Gateway is in use when there are multiple with the same name, for a given session.

Internal and External Access URLs

Will internal users access Citrix using the same URL as external users? Many customers prefer this approach to simplify the user experience, but it has certain implications. When using the same URL for both internal and external access, the internal beacon in the StoreFront configuration should be adjusted to something other than the base URL (which, by default, is the same for both). Beacons are only relevant for authentication through the Workspace app; browser-based authentication does not rely on them.

Citrix Gateway Integration

When configuring StoreFront to support access via Citrix Gateway, several considerations arise. First, decide whether the Citrix Gateway(s) will handle both authentication and HDX proxy or if different Gateways will serve different purposes. Additionally, it is essential to determine which Secure Ticket Authorities (STAs) will be used by both StoreFront and Citrix Gateway. Ideally, two to four STAs should be configured, and both StoreFront and Gateway must be able to reach the STA servers, which are either Delivery Controllers or Cloud Connectors.

Administrators will also need to define the callback URLs, which we recommend configuring even if not strictly required. These URLs only need to exist in internal DNS. Moreover, consider whether the Citrix Gateway’s IP needs to be specified in the configuration if multiple Gateways using the same URL will interface with StoreFront (such as when the same URL is used for both internal and external access via Citrix Gateway). In cases where StoreFront is servicing requests from Citrix Gateways fronted by GSLB, we recommend that only the local StoreFront servers interface with their local NetScalers to avoid overcomplicating the solution.

If Citrix FAS is used on the Store that Citrix Gateway directs users to after authentication, or the Citrix Gateway will be supporting Smart Card authentication, the Citrix Gateways configured in StoreFront must also be configured within StoreFront to fully delegate authentication to NetScaler. Additionally, if Optimal Gateway Routing is part of the solution, the Citrix Gateways capable of handling HDX traffic must be mapped in StoreFront to the appropriate Citrix Site or Resource Location (zone). This allows StoreFront to configure the ICA file to direct users to the Citrix Gateway nearest the resource they are launching.

Authentication Methods

StoreFront supports multiple authentication methods on a per-store basis, with the most common being the default username and password. However, if StoreFront is only servicing access through Citrix Gateways and not directly authenticating users, this method should be disabled for security reasons.

 Domain pass-through allows users from domain-joined endpoints on the WAN to single sign-on (SSO) into Citrix without manually logging into StoreFront, whether through a browser or Citrix Workspace app. To enable this feature, Citrix Workspace app must be installed with the /IncludeSSON switch enabled if it will be used for authentication. Additionally, the StoreFront URL must be added to the Intranet zone of Internet Explorer properties (typically via GPO), and the associated User Authentication settings should be set to “Automatic logon with current user name and password.” Trust XML requests must also be enabled on the Citrix Site (on-prem or DaaS), as this is disabled by default.

While domain pass-through can technically work through Citrix Gateway, it requires enabling HTTP Basic authentication on the Store and configuring Citrix Gateway for single-factor authentication only. These limitations make this option unsuitable for most deployments, including internal ones. HTTP Basic, incidentally, is required for some third-party integrations, such as Imprivata.

Pass-through from Citrix Gateway is required when Citrix Gateway handles the initial authentication before passing the user to StoreFront.

Password Changes

By default, StoreFront does not allow password changes, either at any time or upon expiry. This setting applies to the “User name and password” method as well as the “Pass-through from Citrix Gateway” method (if an LDAP factor is in use). Customers can choose to enable password changes, but there are some caveats.

StoreFront does not support fine-grained Active Directory (AD) password policies. Additionally, when evaluating password expiry, StoreFront creates a small local profile (typically under 1MB) for the user on the StoreFront server as part of the validation process. In very large environments, this may require periodic monitoring of StoreFront server disk space.

Due to these factors, and potential security compliance requirements, some customers may prefer to handle password changes through one standard platform for all users. However, in environments where Citrix is the only entry point into the environment, enabling password changes through StoreFront may help reduce support desk calls.

Quantity of Stores

For most deployments, a single StoreFront Store is sufficient, as it can service users authenticating both at StoreFront and through Citrix Gateway. It also supports multiple Receiver for Web (RfWeb) sites, allowing customization for different use cases, and enables the aggregation of Citrix Sites (user farm mapping) to optimize XML enumeration for different user groups.

However, there are cases where creating multiple individual Stores may be preferable. For example, if a customer needs to enumerate a reduced set of Citrix Sites for external users accessing via Citrix Gateway, mask certain resource types from being visible within the store, maintain distinct authentication configurations, or implement other store-level customizations that require isolation, provisioning another StoreFront Store may be appropriate.

1. This is the first item
2. This is the second item
   1. Here is a sub-item
   2. Here is another sub-item
3. This is the third item

1. A different style for this list
2. This should be teal coloured markers
   1. The subitem can be changed to an even different colour
   2. These ones are fuscia
3. This is the third item

Aggregation of Citrix Sites and Resource Locations

Within each store, administrators can configure user farm mapping and multi-site aggregation. In large environments with multiple on-prem (non-DaaS) Citrix sites, user farm mapping allows administrators to group Citrix Sites and present them to specific user groups. This optimizes XML enumeration and improves login performance by preventing users from enumerating sites that are irrelevant to them, eliminating the need for multiple stores.

Farm aggregation enables administrators to define farm sets hosting identical or similar resources and designate primary or secondary farm sets. In on-prem Citrix environments using pod architecture, Active/Active, or Active/Passive designs, this feature prevents duplicate icons with identical names from appearing in StoreFront and manages failover between Citrix Sites.

These options are not relevant for purely Citrix DaaS deployments unless aggregating multiple Citrix DaaS tenants or combining Citrix DaaS and on-prem Citrix Sites within a single store.

Multi-Site or Single-Site Deployment

Is StoreFront being deployed in a single datacenter or multiple datacenters? In the context of public cloud, the use of multiple Availability Zones within a region is generally considered a single logical datacenter rather than multiple datacenters. If multiple datacenters are required, each should ideally have its own StoreFront Server Group. A single StoreFront Server Group should not span multiple datacenters in disaster recovery (DR) architectures. Instead, each datacenter or cloud region should have its own Server Group.

There are limited cases where spanning a StoreFront Server Group across datacenters is appropriate, such as high availability designs using multiple Availability Zones within the same region on public cloud platforms or between closely located on-prem datacenters.

When accommodating for multi-datacentre StoreFront deployments, assume a Server Group per location, and accommodate for subscription synchronization between Server Groups.