Decision: Folder Redirection

Decision: Folder Redirection

While redirecting profile folders, such as user documents and favorites, to a network share is a good practice to minimize profile size, architects need to be aware that applications may frequently read and write data to profile folders such as AppData, causing potential issues with file server utilization and responsiveness. It is important to thoroughly test profile redirection before implementation in production to avoid these issues. Therefore, it is important to research profile read / write activities and to perform a pilot before moving to production. Microsoft Outlook is an example of one application that regularly performs profile read activities as the user signature is read from the user profile every time an email is created.

Decision: Folder Exclusion

Excluding folders from being persistently stored as part of a roaming of hybrid profile can help to reduce profile size and logon times. By default Windows excludes the Appdata\Local and Appdata\LocalLow folders, including all subfolders, such as History, Temp and Temporary Internet Files. In addition, the downloads and saved games folders should also be excluded.

Decision: Profile Caching

Local caching of roaming or hybrid user profiles on a server or virtual desktop is default Windows behavior and can reduce login times and file server utilization / network traffic. With profile caching,

the system only has to download changes made to the profile. The downside of profile caching is that it can consume significant amounts of local disk storage on multi-user systems, such as a hosted shared desktop server.

Citrix recommends not deleting locally cached profiles for the following scenarios:

For optimizing logon times:

• Hosted VDI – Dedicated / Existing / Physical

• Hosted VDI – Static with PVD

• Hosted VDI – Remote PC

• Local VM

For optimizing logoff times:

• Non-persistent virtual desktops and Hosted Shared Desktop servers, with reboot on logoff or daily reboot.

Citrix recommends deleting locally cached profiles on logoff for the following scenarios to avoid the proliferation of stale profiles:

• Hosted shared provided by persistent hosted shared desktop servers.

• Hosted VDI pooled without immediate reboot on logoff.

Configuring the “Delay before deleting cached profiles” Citrix policy sets an optional extension to the delay before locally cached profiles are deleted at logoff. Extending the delay is useful if a process keeps files or the user registry hive open during logoff. This can also reduce logoff times for large profiles.

Decision: Profile Permissions

For security reasons, administrators, by default, cannot access user profiles. While this level of security may be required for organizations that deal with very sensitive data, it is unnecessary for most environments and can complicate operations and maintenance. Therefore, consider enabling the “Add the Administrators security group to roaming user profiles” policy setting. The configuration of this policy should be aligned with the security characteristics of the user groups captured during the

assess phase. For more information on the permissions required for the file share, please refer to Microsoft TechNet - Deploying Roaming Profiles.

Decision: Profile Path

Determining the network path for the user profiles is one of the most significant decisions during a user profile design process. In general it is strongly recommended to leverage a redundant and high performance file server or NAS device.

There are three topics that must be considered for the profile share:

• Performance – File server performance will effect logon times. For large virtual desktop infrastructures, a single file server cluster may not be sufficient to handle periods of peak activity.

In order to distribute the load across multiple file servers, the file server address and share name will need to be adjusted.

• Location – User profiles are transferred over the network by means of the SMB protocol, which does not perform well on high latency network connections. Furthermore, WAN connections are typically bandwidth constrained, which can add additional delay to the profile load process. Therefore, the file server should be located in close proximity to the servers and virtual desktops to

minimize logon times.

• Operating system platforms – User profiles have a tight integration with the underlying operating system and it is not supported to reuse a single user profile on different operating systems or different platforms like 64-Bit (x64) and 32-Bit (x86). For more information, please refer to the Microsoft knowledge base article KB2384951 – Sharing 32 and 64-bit User Profiles. Windows 2008 and Windows Vista introduced a new user profile structure, which can be identified by .V2 profile directory suffix, which makes older user profiles incompatible with newer operating systems such as Windows 2012, 7 and 8. In order to ensure that a separate profile is used per platform, the profile

directory has to be adapted.

There are two methods that can be used to address these challenges that are based on Windows built-in technology:

• User object – For every user object in Active Directory, an individual profile path, which contains file server name and profile directory, can be specified. Since only a single profile path can be specified per user object, it is not possible to ensure that a separate profile is loaded for each operating system platform.

• Computer group policy or system variables – The user profile path can also be configured by means of computer specific group policies or system variables. This enables administrators to ensure that a user profile is dedicated to the platform. Since computer specific configurations affect all users of a system, all user profiles will be written to the same file server. To load balance user profiles across multiple servers dedicated XenDesktop delivery groups have to be created per file server.

Note: Microsoft does not support DFS-N combined with DFS-R for actively used user profiles. For more information, please refer to the Microsoft articles:

• Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario 

• Microsoft’s Support Statement Around Replicated User Profile Data

When using Citrix Profile Management, a third option is available to address these challenges:

User object attributes and variables – Citrix Profile Management enables the administrator to configure the profile path by means of a computer group policy using attributes of the user object in Active Directory to specify the file server dynamically. In order to achieve this, three steps are required:

1. Create a DNS alias (for example, fileserver1) which refers to the actual file server

2. Populate an empty LDAP attribute of the user object (for example, l or UID) with the DNS Alias

3. Configure Citrix Profile Management by means of GPO to use a profile path which refers to the LDAP attribute (for example, If attribute UID is used the profile path becomes \\#UlD#\Profiles\

profiledirectory)

In addition, Citrix Profile Management automatically populates variables to specify the profile path dynamically based on the operating system platform. Valid profile management variables are:

• !CTX_PROFILEVER! – Expands to v1 or v2 depending on the profile version.

• !CTX_OSBITNESS! – Expands to x86 or x64 depending on the bit-level of the operating system.

• !CTX_OSNAME! – Expands to the short name of the operating system, for example Win7

By combining both capabilities of Citrix Profile Management, a fully dynamic user profile path can be created, which can be load balanced across multiple file servers and ensure profiles of different

operating system platforms are not mixed. An example of a fully dynamic user profile path is shown below: \\#UlD#\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_ OSNAME!!CTX_OSBITNESS!

Simplified SmartAccess Decision Logic

Simplified SmartAccess Decision Logic

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.

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 OS based), or mobile (such as iOS or Android). Therefore a decision on whether to provide support for mobile devices, nonmobile 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:

• Mobile devices – The expression is set to REQ.HTTP.HEADER User-Agent CONTAINS Citrix Receiver 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 Datacenter

Enterprises often have multiple active datacenters 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 datacenter. Therefore, the initial NetScaler Gateway that a user authenticates to in a multi-active datacenter environment may not be within the preferred datacenter

corresponding to the user’s virtual desktop resources. StoreFront is able to determine the location of the user’s assigned resources and, direct the HDX session to those resources.

There are static and dynamic methods available to direct HDX sessions to their virtual desktop resources in their primary datacenter. 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.

Note: For more information on configuring the static and dynamic methods of GSLB, please refer to Citrix eDocs – Configuring GSLB for Proximity.

• Static Direct – The user may be given a FQDN mapped to an A record that is dedicated to the primary datacenter 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 datacenter outage is limited to the Internet access infrastructure.

• Dynamic Internet – For most dynamic environments, the initial datacenter 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, the HDX session may be redirected through a NetScaler Gateway to the preferred datacenter by assignment in StoreFront accordingly. However, a significant portion of the HDX session would likely be forced to travel over the best effort Internet without QoS guarantees.

For example, a user with a dedicated desktop in the United States, traveling in Europe may be directed to a NetScaler Gateway hosted in a European datacenter. 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 datacenter in the United States.

Typical StoreFront Architecture

Typical StoreFront Architecture

For more information, please refer to Citrix eDocs:

• Use the SSL Relay (XenApp 6.5 & Below Only)

• Use SSL on XenDesktop & XenApp 7.5 Controllers

• Secure your StoreFront environment

Decision: Routing Receiver with Beacons

Citrix Receiver uses beacon points (websites) 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. It is possible to control what a user sees by restricting applications due to which beacon they have access to.

The internal beacon should not be a site that is resolvable externally. By default, the internal beacon is the StoreFront service URL. The external beacon can be any external site that will produce 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 will first verify 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.

It is necessary to specify at least two highly available external beacons that can be resolved from public networks.

Decision: Resource Presentation

StoreFront displays resources differently than Web Interface. Instead of having all accessible resources appear on the home screen, first time users are invited to choose (subscribe) to the

resources they want to regularly use after they logon. Before a user can launch an application, they must first choose which resources should be placed on their home screen. 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 so that they can be displayed on the Citrix Receiver home screen from any device that the user connects from.

Administrators should determine which applications should always be displayed to users on their home screen or the featured tab. These applications will vary for each deployment and should be

defined during the Assess Phase of a Citrix Assessment. In general, these applications are common applications such as Microsoft Word and any other applications that every user in an environment

may need. StoreFront can filter/present these resources using Keywords.

Using Keywords is a very simple way to prepopulate a user’s home screen. To add applications to the home screen, add KEYWORDS:Auto to the application or desktop description in XenApp or XenDesktop. Another option that can be used to organize resources is using the keyword KEYWORDS:Featured. Unlike the Auto keyword, which places certain resources on the home screen, the Featured keyword only places resources in the Featured category

The resource 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 more information please refer to Citrix eDocs – Optimize the user experience and Configure application delivery.

Decision: Scalability

The number of Citrix Receiver users supported by a single StoreFront server depends on the resources assigned and level of user activity:

For an optimal user experience, Citrix recommends that no more than ten XenDesktop, XenApp, App Controller and VDI-in-a-Box deployments are aggregated into a single store.

Synchronization Database – If users connect to multiple StoreFront servers within an environment, their personalized settings (application subscriptions) are immediately stored on the StoreFront server and replicated to other StoreFront servers. The Synchronization Database on each StoreFront server needs to be large enough to accommodate user and application subscriptions, about 3 KB per user per app.

Decision: Multi-site App Synchronization

Moving between multiple locations would benefit from synchronization of their application subscriptions between multiple deployments. For example, a user based in Location 1 can log on to the StoreFront deployment in Location 1, access the store, and subscribe to some applications. If same user would travel to Location 2 and accessed a similar store provided by the Location 2 StoreFront deployment, the user would have to re-subscribe to all of their applications once again.

Each StoreFront deployment maintains details of users’ application subscriptions separately by default. By configuring subscription synchronization between the stores, it is possible to ensure that users only need to subscribe to applications in one location. The interval for the subscription synchronization will vary from site to site due to the distance between sites. The recommended interval should be less than the time needed for a user to travel from one site to another. For more information on how to use PowerShell with StoreFront 2.5, please refer to the Citrix eDocs article – To configure subscription synchronization.