Design methodology access layer
The second layer of the design methodology is the access layer, which is defined for each user group.
Creating an appropriate design for the access layer is an important part of the desktop virtualization process. This layer handles user validation through authentication and orchestrates access to all components necessary to establish a secure virtual desktop connection.
The access layer design decisions are based on the mobility requirements of each user group as well as the endpoint devices used.
Getting access to resources is based on the user’s identity. Defining the authentication strategy takes into account the user’s entry point into the environment as well as how the user will authenticate.
Decision: Authentication Provider
Traditionally, users required an Active Directory username and password to get access to their XenApp and XenDesktop resources. As most organizations standardized on an on-premises Active Directory deployment, this particular requirement was simple to achieve.
Organizations are using external contractors, which requires an account to get access to the XenApp and XenDesktop resources. Organizations are investigating the use of a third party identity provider (IdP) like Azure Active Directory, Google, LinkedIn, etc., instead of managing their own.
With the implementation of Citrix Federated Authentication Service, XenApp and XenDesktop supports the use of a third party IdP. An administrator can have a contractor use their Google account to gain access to their approved applications and desktops, simplifying onboarding.
Decision: Authentication Point
Before a user connects to a virtual resource, they must first authenticate. The place of authentication is often determined by the user group’s mobility requirements, which were defined during the user segmentation process. There are two authentication points available in XenDesktop:
- StoreFront – Citrix StoreFront provides authentication and resource delivery services for Citrix Receiver, enabling centralized enterprise stores to deliver desktops, applications and other resources.
- NetScaler Gateway – NetScaler Gateway is an appliance providing secure application access and granular application-level policy controls to applications and data while allowing users to work from anywhere.
The following table lists preferred authentication points according to user group mobility requirements:
|User Group’s Mobility Requirement||Preferred Authentication Point|
Authentication for user groups with a mobility requirement of remote or mobile may occur directly on StoreFront where required. For example, DMZ security policies may prohibit access from the NetScaler Gateway to the domain, which is required to support Smartcard client certificate authentication. Access to StoreFront for authentication may then be delivered via a NetScaler SSL_BRIDGE virtual server, which provides a conduit for https traffic. Typically, the virtual server would be hosted alongside a NetScaler Gateway on the same NetScaler configured to provide HDX Proxy access to the virtual desktop environment. Although such a use case may sometimes be necessary, the recommended best practice is to authenticate external users via NetScaler Gateway.
Decision: Authentication Policy
Once the authentication point has been identified, the type of authentication must be determined. The following options are the primary methods available:
StoreFront – Supports a number of different authentication methods, although not all are recommended depending on the user access method, security requirements and network location. Note that by default StoreFront authenticates users directly with Active Directory, not via XML as Web Interface did. StoreFront 3.0+ can be optionally configured to delegate authentication to XML if required (such as if the StoreFront servers are in a domain that does not trust the user domains).
- User name and password – Requires users to logon directly to the site by entering a user name and password.
- Domain pass-through – Allows pass-through of domain credentials from users’ devices. Users authenticate to their domain-joined Windows computers and are automatically logged on when they access their stores.
- NetScaler Gateway pass-through – Allows pass-through authentication from NetScaler Gateway. Users authenticate to NetScaler Gateway and are automatically logged on when they access their stores.
- Smart card – Allows users to authenticate using smart cards and PINs through Citrix Receiver for Windows and NetScaler Gateway. To enable smart card authentication, user accounts must be configured either within the Microsoft Active Directory domain containing the StoreFront servers or within a domain that has a direct two-way trust relationship with the StoreFront server domain. Multi-forest deployments involving one-way trust or trust relationships of different types are not supported.
- Anonymous – Allow users to access applications and desktops without presenting credentials to StoreFront or Citrix Receiver. Local anonymous accounts are created on demand on the Server VDA when sessions are launched. This requires a StoreFront store configured for unauthenticated access, a Server OS based VDA, and a XenApp Delivery Group configured for unauthenticated users.
NetScaler Gateway – The NetScaler Gateway supports several authentication methods. The list below includes those primarily used in virtual desktop environments. Each may be used individually, but are often combined to provide multi-factor authentication.
- LDAP – The lightweight directory access protocol (LDAP) is used to access directory information services such Microsoft Active Directory. NetScaler Gateway uses LDAP to authenticate users and extract their group membership information.
- RADIUS (token) - Remote authentication dial in user service (RADIUS) is a UDP based network security protocol that provides authentication, authorization and accounting. A network access server (NetScaler Gateway in this case) forwards credentials to a RADIUS server that can either check the credentials locally, or check them against a directory service. The RADIUS server could then accept the connection, reject the connection, or challenge and request a second form of authentication such as a token.
- Client certificate – Users logging on to a NetScaler Gateway virtual server can also be authenticated based on the attributes of a client certificate presented to the virtual server. Client certificates are usually disseminated to users in the form of smartcards or common access cards (CACs) that are read by a reader attach to each user’s device.
The authentication type for a user group is often determined based on security requirements as well as the authentication point used. The following table helps define the appropriate solution for each user group based on the level of security required:
|Authentication Point||Security Requirement||Authentication Type|
|StoreFront||Low, Medium, High||Low: LDAP user name and password; Pass-through. Medium: LDAP user name and password; Pass-through. High: LDAP and/or Smartcard|
|NetScaler Gateway||Low, Medium, High||Low: LDAP user name and password. Medium: LDAP user name and password. High: LDAP and Token; LDAP and Smartcard; Token and Smartcard|
Experience from the Field
- Retail – A small private retail company provides virtual desktop users with access to non-sensitive data such as marketing catalogs and email. They are not required to adhere to security regulations such as Sarbanes Oxley. Therefore, LDAP authentication has been implemented based on user name and password.
- Financial – A medium financial enterprise provides their virtual desktop users with access to confidential data such as banking transaction records. They are governed by security regulations such as the Statement on Accounting Standards (SAS) 70 and are required to utilize multi-factor authentication for remote access users. LDAP authentication has been implemented based on user name and password along with RADIUS authentication using tokens.
- Government – A large federal institution provides virtual desktop users with access to highly confidential data such as private citizens’ personal records. They are subject to regulation by Department of Defense (DOD) security standards. LDAP authentication has been implemented based on user name and password, along with Client Certificate authentication using CAC cards.
- Healthcare - A hospital is using XenApp to deliver their EMR application to users. ThinClient devices on stationary and mobile carts are being used by doctors and nurses to capture and retrieve patient data. Unauthenticated access has been configured to prevent medical staff from having to authenticate to the domain as well as the EMR application.
Citrix StoreFront authenticates users to XenApp and XenDesktop resources. StoreFront enumerates and aggregates available desktops and applications into a single interface that users access through Citrix Receiver for Windows, iOS, Android, or the StoreFront website.
Decision: High Availability
If the server hosting StoreFront 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. By implementing a load balancing solution, users will not experience an interruption in their service. Options include:
- Hardware load balancing – An intelligent appliance, which is capable of verifying the availability of the StoreFront service and actively load balance user requests appropriately. Citrix NetScaler is a great example of a hardware load balancer. Citrix NetScaler is an ideal load balancer, coming pre-configured with StoreFront health checks.
- DNS round robin – Provides rudimentary load balancing across multiple servers without performing any checks on availability. If a StoreFront server becomes unavailable, DNS round robin would still route users to the failed server. Because of this, DNS round robin is not recommended by Citrix.
- Windows network load balancing – A Windows service capable of performing rudimentary checks to verify the server is available but cannot determine the status of individual services. This can cause users to be forwarded to StoreFront servers which are not able to process new requests. The user would then not be able to access applications or desktops.
Decision: Delivery Controller Reference
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 and XenApp site. For fault tolerance, multiple controllers should be entered for each site and/or farm specified. By default, StoreFront treats a list of servers in failover order (active/passive).
For large deployments or environments with a high logon load an active distribution of the user load (active/active) is recommended. This can be achieved by means of a load balancer with built-in XML monitors, such as Citrix NetScaler or by configuring StoreFront to load balance the list of Controllers instead of treating them as an ordered list.
Citrix Receiver uses beacons (websites) to identify whether a user is connected to an internal or external network. Internal users are connected directly to StoreFront for authentication while external users are connected via Citrix NetScaler Gateway. It is possible to control what a user sees by restricting applications due to which beacon they have access to.
The internal beacon should be a site that is not resolvable externally. By default, the internal beacon is the StoreFront base URL. This will have to be adjusted if the same external and internal URL is configured. The external beacon can be any external site that produces an HTTP response. Citrix Receiver continuously monitors the status of network connections (for example, link up, link down or change of the default gateway). When a status change is detected, Citrix Receiver first verifies 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/configuration download process and provides updates as necessary. It is necessary to specify at least two highly available external beacons that can be resolved from public networks.
Decision: Resource Presentation
By default, StoreFront allows users to choose (subscribe) to the resources they want to regularly use after they logon (favorites). This approach, deemed “Self-Service,” allows users to restrict the resources that they see on their home screen to the ones that they use on a regular basis. The resources chosen by every user for each store are recorded by the subscription store service and stored locally on each StoreFront server (synced automatically between servers in the same server group) so that they can be displayed on the Citrix Receiver home screen from any device that the user connects from. Although by default subscriptions are per store and per server group, administrators can configure two stores within a server group to share a subscription database and/or sync subscriptions between two identically named stores in two separate server groups on a defined schedule if required.
Administrators should determine which applications should always be displayed to users on their home screen or the featured tab. In general, these applications are common applications such as the Microsoft Office Suite and any other applications that every user in an environment may need. StoreFront can filter/present these resources using Keywords defined within the published application properties Description field.
The following table explores the Keyword options:
|Auto||Automatically subscribes all users of a store to an application. When users log on to the store, the application is automatically provisioned without users needing to manually subscribe to the application. Users can choose to subsequently remove this subscription if desired.|
|Mandatory||New in StoreFront 2.5, the Mandatory keyword will make applications automatically be subscribed to users of the store. However, users will not have the option to remove the application. This setting is useful when creating a core set of applications which must always be presented to all users.|
|Featured||Advertise applications to users or make commonly used applications easier to find by listing them in the Receiver Featured list.|
|Prefer||Specify a locally installed application should be used instead of an application available in Receiver. Receiver searches for the specified name/path to determine if the application is installed locally. If it is, Receiver subscribes the application and does not create a shortcut. When the user starts the application from the Receiver window, Receiver starts the locally installed (preferred) application. If a user uninstalls a preferred application outside of Receiver, the application is unsubscribed during the next Receiver refresh. If a user uninstalls a preferred application from the Receiver window, Receiver unsubscribes the application but does not uninstall it.|
|TreatAsApp||By default, XenDesktop VDI desktops and XenApp hosted shared desktops are treated like other desktops by Receiver for websites. By using the keyword “TreatAsApp,” the desktop will be displayed in the application views of Receiver for websites rather than the desktop views. Users are required to subscribe before they can access the desktop.|
|Primary||When in a multi-site deployment, using this keyword ensures that an application is delivered from a designated site. If an application is available from multiple sites, with the same name, the application from the secondary site will only be displayed if the application is not available from the primary site.|
|Secondary||A same property as the “Primary” keyword, except it designates an application in the secondary site.|
Decision: Aggregation Groups
If the XenApp and XenDesktop solution includes multiple delivery sites, StoreFront merges the available resources together so the user has a single interface for all published resources. However, if multiple sites publish the same resources, the user might experience confusion as a single application appears multiple times.
StoreFront aggregation groups define how the resources in multiple sites merge to provide the user with a single, easy to understand view. StoreFront aggregates duplicate published resources into a single icon.
The administrator must determine how to load balance users across the different XenApp and XenDesktop Sites when the icon is an aggregation. The options are:
- Load Balancing – Used when the duplicate sites are created based on capacity recommendations. StoreFront distributes user requests across all configured sites.
- Failover – Used when geographies need to have resources available in the event of an outage or when migrating users from one site to another site (like a XenApp migration project).
It is advisable to document the users, stores and aggregation methods during the design phase.
|User Group||Available Store(s)||Load Balancing Stores||Failover Stores|
|NA_FinanceUsers||NA_West_Store, NA_East_Store, EMEA_Store||NA_West_Store, NA_East_Store||EMEA_Store|
The number of Citrix Receiver users supported by a single StoreFront server depends on the resources assigned and level of user activity. Note that Receiver for Web users will consume more RAM on average than native Receiver users, but a minimum of 4 GB of RAM is recommended per StoreFront server in all cases as a baseline. Additionally, more sites/farms enumerated per store will increase both CPU utilization and server response time, with XenApp IMA farms having a greater scalability impact than XenApp and XenDesktop FMA site.
|StoreFront deployment||CPU Usage||Simultaneous activities|
|Standalone deployment: 4CPUs, 4 GB RAM, Heavy Usage (logon, enumerate, subscribe, unsubscribe, logoff)||75%||291 per second|
|Standalone deployment: 4CPUs, 4 GB RAM, Heavy Usage (logon, enumerate, subscribe, unsubscribe, logoff)||90%||375 per second|
|Cluster StoreFront deployment. 2 Nodes each with: 4 CPUs, 4 GB RAM, Heavy Usage (logon, enumerate, subscribe, unsubscribe, logoff)||75%||529 per second|
|Cluster StoreFront deployment. 2 Nodes each with: 4 CPUs, 4 GB RAM, Heavy Usage (logon, enumerate, subscribe, unsubscribe, logoff)||90%||681 per second|
Tests have shown diminishing returns after a single StoreFront deployment grows beyond 3-4 StoreFront nodes with a maximum of 5-6 servers supported in a single server group.
User groups utilizing NetScaler Gateway as their authentication point have additional design decisions to consider. These design decisions are not applicable for non-NetScaler Gateway authentication points.
Selection of the network topology is central to planning the remote access architecture to ensure that it can support the necessary functionality, performance and security. The design of the remote access architecture should be completed in collaboration with the security team to ensure adherence to corporate security requirements. There are two primary topologies to consider, each of which provides increasing levels of security:
- 1-Arm (normal security) – With a 1-arm topology, the NetScaler Gateway utilizes one physical or logical bonded interface, with associated VLAN and IP subnet, to transport both front end traffic for users and back-end traffic for the virtual desktop infrastructure servers and services.
- 2-Arm (high security) – With a 2-arm topology, the NetScaler Gateway utilizes two or more physically or logically bonded interfaces, with associated VLANS and IP subnets. Transport of the front-end traffic for users is directed to one of these interfaces. The front end traffic is isolated from back-end traffic, between the virtual desktop infrastructure servers and services, which is directed to a second interface. This allows the use of separate demilitarized zones (DMZs) to isolate front-end and back-end traffic flows along with granular firewall control and monitoring.
Decision: High Availability
If the NetScaler Gateway is unavailable, remote users will not be able to access the environment. Therefore at least two NetScaler Gateway hosts should be deployed to prevent this component from becoming a single point of failure.
When configuring NetScaler Gateway in a high availability (active/passive) pair, the secondary NetScaler Gateway monitors the first appliance by sending periodic messages, also called a heartbeat message or health check, to determine if the first appliance is accepting connections. If a health check fails, the secondary NetScaler Gateway tries the connection again for a specified amount of time until it determines that the primary appliance is not working. If the secondary appliance confirms the health check failure, the secondary NetScaler Gateway takes over for the primary NetScaler Gateway.
Note that in firmware 10.5 and above, clustering is also possible with multiple NetScaler Gateway instances to provide high availability, although support for spotted versus stripped configurations varies by firmware and Gateway configuration (full SSL VPN versus ICA Proxy). (https://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html)
In order to identify an appropriate NetScaler platform to meet project requirements, the key resource constraints must be identified. Since all remote access traffic will be secured using the secure sockets layer (SSL), transported by Hypertext Transfer Protocol (HTTP) in the form of HTTPs, there are two resource metrics that should be targeted:
- SSL throughput – The SSL throughput is the gigabits of SSL traffic that may be processed per second (Gbps).
- SSL transactions per second (TPS) – The TPS metric identifies how many times per second an Application Delivery Controller (ADC) may execute an SSL transaction. The capacity varies primarily by the key length required. TPS capacity is primarily a consideration during the negotiation phase when SSL is first setup and it is less of a factor in the bulk encryption / decryption phase, which is the majority of the session life. While TPS is an important metric to monitor, field experience has shown that SSL throughput is the most significant factor in identifying the appropriate NetScaler Gateway.
The SSL bandwidth overhead average is often considered negligible relative to the volume of virtual desktop traffic and is not typically accounted for as part of required SSL throughput. However, making provisions for SSL bandwidth will help ensure the total throughput estimated is sufficient. The fixed bandwidth added to packet headers can vary according to the encryption algorithms used and the overall percentage of bandwidth may vary widely according to packet size. Ideally, the overhead should be measured during a proof of concept or pilot. However, in the absence of such data incrementing the workload bandwidth by 2% is a reasonable rule of thumb. Therefore, to determine the SSL throughput required by a NetScaler platform, multiply the maximum concurrent bandwidth for a data center by 1.02:
SSL Throughput = Maximum Concurrent Bandwidth x 1.02
For example, assuming 128 Mbps maximum concurrent bandwidth, the appropriate NetScaler model can be determined as follows:
~130 Mbps = 128 Mbps x 1.02
The SSL throughput value should be compared to the throughput capabilities of various NetScaler platforms to determine the most appropriate one for the environment. There are three main platform groups available, each of which provides broad scalability options.
- VPX – A NetScaler VPX device provides the same full functionality as hardware NetScaler. However, NetScaler VPXs can leverage ‘off the shelf’ servers for hosting and are suitable for small to medium sized environments. Typically, organizations create a baseline cap for the VPX instances at 500 users.
- MPX – A NetScaler MPX is the hardware version of the NetScaler devices. The MPX device is more powerful than the virtual NetScaler and can support network optimizations for larger scale enterprise deployments, particularly when SSL offload will be configured as this is done in software on the VPX versus dedicated SSL chips on the MPX.
- SDX – A NetScaler SDX is a blend between the virtual and physical NetScaler devices. An SDX machine is a physical device capable of hosting multiple virtual NetScaler devices. This consolidation of devices aids with reducing required shelf space and device consolidation. NetScaler SDXs are suitable for handling network communications for large enterprise deployments and/or multitenant hosting providers.
SSL throughput capabilities of the NetScaler platforms may be found in the Citrix NetScaler data sheet. Therefore, based on the example calculation above, a NetScaler MPX 5550 appliance would be sufficient to handle the required load. However, actually scalability will depend on security requirements. NetScaler SSL throughput decreases with the use of increasingly complex encryption algorithms and longer key lengths. Also, this calculation represents a single primary NetScaler. At a minimum, N+1 redundancy is recommended which would call for an additional NetScaler of the identical platform and model.
The Citrix NetScaler data sheet typically represents throughput capabilities under optimal conditions for performance. However, performance is directly affected by security requirements. For example, if the RC4 encryption algorithm and a 1k key length are used, a VPX platform may be able to handle more than 500 HDX proxy connections. However, if a 3DES encryption algorithm and 2k key length are used (which are becoming more common), the throughput may be halved.
Decision: Pre-Authentication Policy
An optional pre-authentication policy may be applied to user groups with NetScaler Gateway as their authentication point. Pre-authentication policies limit access to the environment based on whether the endpoint meets certain criteria through Endpoint Analysis (EPA) Scans.
Pre-authentication access policies can be configured to test antivirus, firewall, operating system, or even registry settings. These policies can be used to prevent access entirely or can be used by XenDesktop to control session features such as clipboard mapping, printer mapping and even the availability of specific applications and desktops. For example, if a user device does not have antivirus installed, a filter can be set to hide sensitive applications.
The following figure provides an overview of how multiple policies can be used to customize the features of a virtualization resource:
Experience from the Field
- Retail – A small private retail company use EPA to scan for the presence of updated antivirus definitions prior to allowing access.
- Financial – A medium financial enterprise use EPA scans of the Domain SID to verify that users are members of the enterprise domain prior to allowing access.
- Government – A large federal institution use EPA to scan endpoint devices to ensure that a specific certificate (or set of certificates) has been installed on the device prior to allowing access.
Decision: Session Policy
User groups with NetScaler Gateway as their authentication point must have corresponding session policies defined. Session policies are used to define the overall user experience postauthentication.
Organizations create sessions policies based on the type of Citrix Receiver used. For the purpose of session policy assignment, devices are commonly grouped as either non-mobile (such as Windows, Mac and Linux OS based), or mobile (such as iOS or Android). Therefore, a decision on whether to provide support for mobile devices, non-mobile devices, or both should be made based on client device requirements identified during the assess phase.
To identify devices session policies, include expressions such as those discussed in this article.
- Mobile devices – The expression is set to REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver which is given a higher priority than the non-mobile device policy to ensure mobile devices are matched while non-mobile devices are not.
- Non-mobile devices – The expression is set to ns_true which signifies that it should apply to all traffic that is sent to it.
An alternative use of session policies is to apply endpoint analysis expressions. These session policies are applied post authentication yet mimic the previously mentioned pre-authentication policies. Use of session policies is an option to provide a fallback scenario to endpoints that do not meet full security requirements such read-only access to specific applications.
Decision: Session Profile
Each session policy must have a corresponding session profile defined. The session profile defines details required for the user group to gain access to the environment. There are two primary forms of session profiles that determine the access method to the virtual desktop environment:
- SSLVPN – Users create a virtual private network and tunnel all traffic configured by IP addresses through the internal network. The user’s client device is able to access permitted intranet resources as if it were on the internal network. This includes XenDesktop sites and any other internal traffic such as file shares or intranet websites. This is considered a potentially less secure access method since network ports and routes to services outside of the virtual desktop infrastructure may be opened leaving the enterprise susceptible to risks that may come with full VPN access. These risks may include denial of service attacks, attempts at hacking internal servers, or any other form of malicious activity that may be launched from malware, Trojan horses, or other viruses via an Internet based client against vulnerable enterprise services via routes and ports.
Another decision to consider when SSLVPN is required is whether to enable split tunneling for client network traffic. By enabling split tunneling, client network traffic directed to the intranet by Citrix Receiver may be limited to routes and ports associated with specific services. By disabling split tunneling, all client network traffic is directed to the intranet, therefore both traffic destined for internal services as well as traffic destined for the external services (Internet) traverses the corporate network. The advantage of enabling split tunneling is that exposure of the corporate network is limited and network bandwidth is conserved. The advantage of disabling split tunneling is that client traffic may be monitored or controlled through systems such as web filters or intrusion detection systems
- HDX proxy – With HDX Proxy, users connect to their virtual desktops and applications through the NetScaler Gateway without exposing internal addresses externally. In this configuration, the NetScaler Gateway acts as a micro VPN and only handles HDX traffic. Other types of traffic on the client’s endpoint device, such as private mail or personal Internet traffic do not use the NetScaler Gateway.
Based on the endpoint and Citrix Receiver used, a decision must be made as to whether this method is supported for each user group. HDX Proxy is considered a secure access method for remote virtual desktop access since only traffic specific to the desktop session is allowed to pass through to the corporate infrastructure. Most Citrix Receivers support HDX Proxy and it is the preferred method:
Decision: Preferred data center
Enterprises often have multiple active data centers providing high availability for mission critical applications. Some virtual desktops or applications may fall into that category while others may only be accessed from a specific preferred data center. Therefore, the initial NetScaler Gateway that a user authenticates to in a multi-active data center environment may not be within the preferred data center corresponding to the user’s VDI resources. StoreFront is able to determine the location of the user’s assigned resources and direct the HDX session to those resources; however, the resulting path may be sub-optimal (WAN connection from the NetScaler Gateway to the virtual desktop/application resources as opposed to LAN connection).
There are static and dynamic methods available to direct HDX sessions to their virtual desktop resources in their primary data center. The decision regarding which method to select should be based on the availability of technology to dynamically assign sites links such as Global Server Load Balancing (GSLB) along with the network assessment of intranet and Internet bandwidth as well as Quality of Service (QoS) capabilities.
For more information on configuring the static and dynamic methods of GSLB, please refer to Citrix Product Documentation - Configuring GSLB for Proximity.
- Direct – The user may be given an FQDN mapped to an A record that is dedicated to the primary data center NetScaler Gateway(s) allowing them to access their virtual desktop directly wherever they are in the world. This approach eliminates a layer of complexity added with dynamic allocation. However, it also eliminates fault tolerance options such as the ability to access the virtual desktop through an alternative intranet path when a primary data center outage is limited to the access infrastructure.
- Intranet – For most dynamic environments, the initial data center selected for authentication is the one closest to the user. Protocols such as GSLB dynamic proximity calculate the least latency between the user’s local DNS server and the NetScaler Gateway. Thereafter, by default, the HDX session is routed through the same NetScaler Gateway to whichever data center is hosting the user’s virtual desktops and applications. The advantage of this approach is that the majority of the HDX session would traverse the corporate WAN where quality of service may be used.
- Internet - Alternatively, the HDX session can be re-routed through an alternate NetScaler Gateway proximate to the backend VDI desktop / XenApp server, resulting in most of the HDX session traveling over the Internet. For example, a user with a dedicated desktop in the United Stated, traveling in Europe may be directed to a NetScaler Gateway hosted in a European data center based on proximity. However, when the user launches their desktop, an HDX connection will be established to the virtual desktop via a NetScaler Gateway hosted in the preferred data center in the United States.
This conserves WAN network usage (at the cost of QoS) and is recommended in cases where the user’s Internet connection may provide a more reliable experience than the corporate WAN.
Some customers will use a combination of these methods, such as geo-specific dynamic URLs such that fault tolerance is provided within a geographic area (such as North America) without incurring the complexity of global GSLB.
A XenApp and XenDesktop Site is capable of spanning multiple locations. In order to successfully implement a multi-site solution, the design must take into account the site-to-site links and XenApp and XenDesktop session routing between locations in order to provide the best user experience.
Decision: HDX Optimized Routing
In a multi-site XenApp and XenDesktop solution, certain criteria, like fastest response time or closest proximity, routes users to the optimal site. These algorithms do not take into account the resources a user wants to access.
Improper routing of a user’s session results in the following:
- User routed to the most preferred site, based on proximity or response time
- NetScaler Gateway proxies the ICA traffic to the correct resource, which could be across the corporate WAN.
Ideally, optimized routing should resemble the following:
- User routed to the most preferred site, based on proximity or response time
- Based on the selected resource, NetScaler Gateway reroutes the session to a NetScaler Gateway in the preferred site.
- NetScaler Gateway proxies the ICA traffic to the correct resource, which stays on the local LAN.
Using the optimized HDX routing option within StoreFront offloads traffic from the corporate WAN and places it on the public network
Decision: Virtual WAN
In branch office scenarios, a XenApp and XenDesktop design must evaluate the branch office’s connection to the data centers hosting the application and desktop resources. If the WAN connection between the branch office and data center is not able to meet the user requirements, the overall user experience degrades. Organizations have a couple of options on their WAN connections:
- Scale Up – Organizations can simply increase the size of the WAN pipe connecting the branch offices to the data center, typically at a sizable cost.
- Scale Out – Organizations can maintain their current WAN connection and augment it with multiple low-cost alternatives. The integration of all connections between the branch office and data center creates a software defined virtual WAN, like NetScaler SD-WAN. The appliance sends duplicate network packets across all WAN connections defined within the virtual WAN. The appliance on the other end of the WAN uses the first arriving packet, discarding all subsequent packets. As the conditions of the multiple links change throughout the day, this approach guarantees the best experience possible.