Product Documentation

Design methodology user layer

Jan 30, 2018

The top layer of the design methodology is the user layer, which each unique user group defines.

The user layer appropriately sets the overall direction for each user group’s environment. This layer incorporates the assessment criteria for business priorities and user group requirements in order to define effective strategies for endpoints and Citrix Receiver. These design decisions affect the flexibility and functionality for each user group.  

Endpoint Selection
 
There are a variety of endpoints devices available, all with differing capabilities, including:
 
  • Tablet based
  • Laptop
  • Desktop PC
  • Thin client
  • Smartphone

The user’s primary endpoint device must align with the overall business objectives as well as each user’s role and associated requirements. In many circumstances, multiple endpoints may be suitable, each offering differing capabilities.

Decision: Endpoint Ownership

In many organizations, endpoint devices are corporate owned and managed. However, more and more organizations are now introducing bring your own device (BYOD) programs to improve employee satisfaction, reduce costs and to simplify device management. Even if BYOD is a business priority, it does not mean that every user should be allowed to use a personal device in the corporate environment.

Certain user requirements, which were identified during the user segmentation, can greatly impact the suitability of personal devices: 

  • Security – Users requiring a high-level of security might not be able to bring a personal device into the secured environment for risk of data theft. 
  • Mobility – Users operating in a disconnected mode might not be able to use a personal device, as the local VM desktop VDI model associated with this type of requirement can have specific hardware requirements, or special maintenance requirements.
  • Desktop loss criticality – Users with a high desktop loss criticality rating might require redundant endpoints in the event of failure. This would require the user to have an alternative means for connecting in the event their personal device fails, likely making these users poor candidates for a BYOD program. 
  • VDI models – A personal device should not be recommended for user groups utilizing a local VDI model like a local streamed desktop, local VM desktop or Remote PC Access. These VDI models typically require a specific hardware configuration or installation that will restrict device selection.

The following diagram provides guidance on when user owned devices could be used:  

localized image

Decision: Endpoint Lifecycle

Organizations may choose to repurpose devices in order to extend refresh cycles or to provide overflow capacity for contract workers. Endpoints now offer more capabilities allowing them to have longer useful lifespans. In many cases, these hardware capabilities vastly outstrip the needs of a typical user. When coupled with the ability to virtualize application and desktop workloads, this provides new options to administrators such as repurposing existing workstations. These options go well beyond the simple three-year PC refresh cycle. However, the benefits of repurposing or reallocating a workstation should be balanced against the following considerations.  

  • Minimum standards – While cost factors of repurposing existing workstations may be compelling, certain minimum standards should be met to guarantee a good user experience. At a minimum, it is recommended that repurposed workstations have a 1GHz processor, 1GB of RAM, 16GB of free disk space and a GPU that is capable of supporting HDX features.  
  • Business drivers – Priorities underpin the success of any major project. Those organizations that have prioritized reducing capital expenditure by means of prolonging the hardware refresh cycle can benefit from repurposing hardware. Conversely, if an organization’s business drivers include reducing power consumption as part of an overall green initiative, purchasing newer endpoints may be beneficial in order to take advantage of the latest generation of power management capabilities available in the most modern devices.  
  • Workload – The type of work and VDI model for an end user can determine whether they are a good candidate for a repurposed endpoint, or may be better served with a new device. If the work performed by the individual involves locally installed applications, the individual may be best served by a new endpoint that offers the most powerful and recently updated processor and graphics architecture. However, if a user is largely performing tasks associated with virtualized applications that do not involve the latest multimedia capabilities such as webcams, VoIP and media redirection, then a repurposed workstation should be a viable alternative. 

The following planning matrix outlines considerations when repurposing existing hardware:

Endpoint provisioning criteria Repurpose existing Procure new

Capital restrained environment 

X

High number of virtualized applications 

X

Desire to prolong hardware refresh cycle

X

High failure rate among existing desktops 

X

Outmoded client-side feature set

X

Power consumption or green initiative(s)

X

Decision: Unified Endpoint Management (UEM)

VDI allows users to work on any device from any location while still getting access to their apps and data. With distributed users accessing the environment across multiple devices, including mobile devices, administrators need to be able to centrally secure and support the mobile devices. Administrators need to: 

  • Selectively wipe a device if the device is lost, stolen, or out of compliance.
  • Require passcode security standards.
  • Define geo-location device restrictions. 
  • Simplify Exchange ActiveSync configuration. 
  • Define WiFi parameters for office locations. 
  • Integrate certificates to secure communications.

Managing the distributed endpoints is only part of the challenge. Administrators need to define levels of access. Administrators need to secure and control access to the apps and data. Security becomes a greater concern when users have access to corporate XenApp and XenDesktop resources from personal devices. A few things to consider when delivering XenApp and XenDesktop apps to mobile devices: 

  • What resources can a jailbroken device access? 
  • Can users copy/paste between personal apps and XenApp and XenDesktop apps?
  • Can a device with no configured passcode get access to corporate resources? 
  • Can users continue to use a native or untrusted third party email client? 
  • Can mobile device users access Intranet sites with a browser optimized for mobile devices or with a published desktop browser?

UEM Solutions, like Citrix XenMobile, protects app data and lets admins control app data sharing. UEM also allows for the management of corporate data and resources, separately from personal data.

Decision: Mobile Device Management (MDM)

VDI allows users to work on any device from any location while still getting access to their apps and data. With distributed users accessing the environment across multiple devices, including mobile devices, administrators need to be able to centrally secure and support the mobile devices, which is knows as Mobile Device Management (MDM).
 
MDM solutions, like Citrix XenMobile, enables organizations to protect devices and data on devices at a system level. For example, 
 
  • Selectively wipe a device if the device is lost, stolen, or out of compliance. 
  • Require passcode security standards.
  • Define geo-location device restrictions. 
  • Simplify Exchange ActiveSync configuration. 
  • Define Wi-Fi parameters for office locations. 
  • Integrate certificates to secure communications.

MDM is typically suitable for corporate-owned mobile devices because most users with personal devices do not want to give the IT team that much control over their personal devices.  

Decision: Mobile Application Management (MAM)

With a distributed workforce accessing the XenApp and XenDesktop environment across numerous devices, administrators need to secure and control access to the apps and data. Security becomes a greater concern when users have access to corporate XenApp and XenDesktop resources from personal devices. A few things to consider when delivering XenApp and XenDesktop apps to mobile devices: 
 
  • What resources can a jailbroken device access? 
  • Can users copy/paste between personal apps and XenApp and XenDesktop apps? 
  • Can a device with no configured passcode get access to corporate resources? 
  • Can users continue to use a native or untrusted third party email client? 
  • Can mobile device users access Intranet sites with a browser optimized for mobile devices or with a published desktop browser?

MAM solutions, like Citrix XenMobile, protects app data and lets admins control app data sharing. MAM also allows for the management of corporate data and resources, separately from personal data.

MAM is often suitable for bring-your-own (BYO) devices because, although the device is unmanaged, corporate data remains protected.  

Decision: Endpoint Form Factor

The capabilities of endpoints have grown along with efficiencies offered in thin client form factors. Even mid-range thin clients now have graphics capabilities that allow utilization of HDX features such as multi-monitor support while offering management and power efficiency benefits. Citrix has developed a three-tiered classification for thin clients based on their HDX capabilities: HDX Ready, HDX Premium, and HDX 3D Pro, which can be used to help narrow the field of appropriate thin client devices based on the use case requirements. This expansion of capabilities has given IT administrators more options and flexibility than ever before.

Most organizations will likely deploy a mixture of fully featured clients as well as thin clients. However, certain endpoint devices are more appropriate when used in combination with certain VDI models as explained in the following table.  

In the table:

  • Yes indicates recommended.
  • No indicates not recommended.
  • o indicates viable. 
VDI model Thin clients Desktop PC Laptop Tablet Smartphone

Hosted Windows Apps

Yes

Yes

Yes

Yes

Yes

Hosted Browser Apps

Yes

Yes

Yes

Yes

Yes

Hosted Shared Desktop

Yes

Yes

Yes

o

o

Hosted Pooled Desktop

Yes

Yes

Yes

o

o

Hosted Personal Desktop

Yes

Yes

Yes

o

o

Hosted Pro Graphics Desktop

Yes

Yes

o

o

o

Local Streamed Desktop

No

Yes

No

No

No

Local VM Desktop

No

o

Yes

No

No

Remote PC Access

No

Yes

Yes

o

o

Experience from the Field

  • Large systems integrator – A large systems integrator recommended that a customer deploy a single type of low-end, limited capability endpoint for all users. Upon deployment to production, users immediately complained that they received a poor user experience when viewing multimedia content over the WAN. At great cost, the systems integrator and customer re-assessed the environment and chose to deploy endpoints that supported HDX MediaStream. The mistake caused a schism between systems integrator and the customer, resulting in lost time, capital and the end of a business relationship that was fostered over many years. It is critical that the endpoints assigned to each user group can support their requirements. 

Receiver Selection

Citrix Receiver is an easy-to-install software client that provides access to applications, desktops and data easily and securely from any device, including smartphones, tablets, PCs and Macs.

The following section provides a series of design decisions that should be considered when deploying Citrix Receiver.  

Decision: Receiver Type

While most organizations should simply deploy the latest Citrix Receiver compatible with their endpoint, it is important to recognize that there are certain differences between editions. The following table should be referenced to determine the most appropriate edition of Citrix Receiver for each user group. For the latest feature matrix, please refer to Receiver Feature Matrix.

Decision: Initial Deployment

There are several deployment options available for delivering Citrix Receiver to an endpoint. Although it is usually a best practice to have a full version of Citrix Receiver deployed to an endpoint to provide the greatest level of functionality, it is important to consider fallback options such as the HTML5 Receiver for those situations where the installation of Citrix Receiver is simply not possible. Note that although the HTML5 Receiver can be used as a fallback option, like the Java client was with Web Interface, it is not generally recommended as the primary Receiver for enterprises to standardize on due to the limited feature set and common browser restrictions around unsecured WebSockets connections (see CTX134123 for more information).  

Experience from the Field

  • Furniture distributor – A furniture distributor maintains a configurator application for various furniture options. The configurator application is accessed via a limited functionality kiosk that is deployed at various furniture outlets, including small, independent retailers with little to no IT staff present. The kiosks are completely locked down in many situations, to the point where even the running of Java applications is limited. The kiosks do feature a modern browser (Google Chrome), and therefore, are able to utilize the HTML5 Receiver in order to provide access to the configurator application.
  • County government – A government IT organization provides services to all agencies operating in the county. A mixture of full desktops are applications are deployed to both Windows based desktops and iPads. Since the desktops are joined to the Active Directory domain, GPOs are utilized to deploy and configure Citrix Receiver. Mobile users accessing the Citrix environment via an iPad install and configure Receiver from the App Store. To allow for seamless provisioning, email based discovery was configured. This allows users to configure Receiver for both internal and external access through NetScaler Gateway by entering in their email address.

The following mechanisms are commonly used to deploy and update Citrix Receiver: 

  • StoreFront – If Citrix StoreFront is available, administrators can deploy Citrix Receiver via a Receiver for Web site by enabling the “Client Detection” feature. When deployed, a Receiver for Web site enables users to access StoreFront stores through a web page. If the Receiver for Web site detects that a user does not have a compatible version of Citrix Receiver, the user is prompted to download and install Citrix Receiver. The Receiver clients can be hosted on the StoreFront server, or users can be directed to citrix.com for the latest Receiver files. 
  • Internal download site – Users may be prevented from downloading software from the Internet, even if they have permission to install applications. Administrator can create an internal website for supported Citrix Receivers or host them on a common software distribution point for a more seamless user experience. This could be an alternative to enabling Client Detection on the StoreFront Receiver for Web site, which can result in an inconsistent user experience depending on browser’s ActiveX settings. 
  • Markets and stores –Citrix Receiver is available on the Windows, Android and iOS stores.
  • Enterprise software deployment – Many organizations employ an enterprise software deployment (ESD) or Mobile Application Management (MAM) solution. ESD/MAM solutions can be used to deploy Citrix Receiver to managed endpoint devices. Employee-owned devices can only be managed if the user successfully registered the device with the management tool.   
  • Master image – Most organizations have a group of master desktop images, which are deployed to each business owned desktop, laptop, server, or virtual desktop. A common mechanism to ensure access to virtual desktops and applications is to include a supported version of Citrix Receiver in the master image. Subsequent updates to Citrix Receiver are handled either by enterprise software deployment tools or manually.  
  • Group policy – For customers without a robust ESD solution, it is possible to deploy and configure Citrix Receiver via Microsoft Group Policy. Sample start-up scripts that deploy and remove Citrix Receiver are available on Citrix XenApp and XenDesktop media:
            Citrix Receiver and Plugins\Windows\Receiver\Startup_Logon_Scripts
 
  • Manual install – All supported versions of Citrix Receiver are available from the Citrix Receiver Download site. Upon landing on this site, client detection is performed and a platform and operating system specific link is provided to allow users to download an appropriate edition of Citrix Receiver. It is important to note that no configuration will be accomplished via this download, so users will receive the first time use prompt to enter a server URL or email address. This option is likely to be utilized in a BYOD environment.

Selecting the appropriate deployment method is based on the type of Citrix Receiver selected. The following table should be referenced to help identify the appropriate deployment options for Citrix Receiver.

In the table,

  • Y indicates "recommended.
  • N equals "not recommended.
Deployment options Thin clients Desktop PC Laptop Tablet Smartphone

Base image

Y

Y

Y

N

N

EDS/MAM

N

Y

Y

N

N

Group Policy

N

Y

Y

N

N

Receiver for Web site

N

Y

Y

N

N

Internal download site

N

Y

Y

N

N

App store

N

N

N

Y

Y

Decision: Initial Configuration

Citrix Receiver must be configured in order to provide access to enterprise resources. The method of configuration varies by Citrix Receiver edition, the form factor of the device, and lastly the access method (local or remote) that is involved. Several methods may be viable for an organization. The method utilized is contingent on the resources (people, systems, time) available as well as larger organizational initiatives such as BYOD programs.

The following methods can be used to configure Citrix Receiver: 

  • Email based discovery – The latest releases of Citrix Receiver can be configured by entering an email address. Email based discovery requires Citrix StoreFront as well as an SRV DNS record which points to the FQDN of the StoreFront server.

    Note: Any DNS platform should support email-based discovery, however only Windows DNS has been explicitly tested.

  • For remote access, NetScaler Gateway must be utilized with the corresponding SRV record in external DNS. A valid server certificate on the NetScaler Gateway appliance or StoreFront server must be present in order to enable email-based account discovery. This configuration assumes that the portion of the email address after the “@” is the DNS namespace that should be queried for this SRV record. This can be challenging for customers with different external and internal namespaces or email addresses that are different from DNS namespaces. 
  • Group policy – Microsoft Group Policy can be used to configure Citrix Receiver. This can be done via start up scripts used to deploy Receiver by ensuring there is a value for the SERVER_LOCATION=Server_URL parameter or by using the ADMX/ADML template files included with the installation of Citrix Receiver to set the StoreFront Account List option in conjunction with another Receiver deployment method. Provide the URL of the server running Citrix StoreFront in the format https://baseurl/Citrix/storename/discovery. 
  • Provisioning file – For environments running StoreFront, it is possible to provide users with a provisioning file that contains store information. Provisioning files are exported from the StoreFront console. The file is saved with a “*.cr” extension and can then be placed on a shared network resource, a Receiver for Web site, or other web based resource or emailed to users. The file can then be launched from an endpoint, which automatically configures Citrix Receiver to use the store(s). If users browse to the Receiver for Web site and select the “Activate” option under their username, this also automatically downloads this same “.cr” file and configure the Receiver client for users. 
  • Manually – If allowed, it is usually possible to configure Citrix Receiver manually by entering the server URL. This method should be reserved for administrators or users that have advanced knowledge. 
  • Studio – In addition to the above methods, in order to configure Receiver deployed on a virtual desktop or server image (within a XenDesktop or XenApp environment), it is possible to set the StoreFront address via the properties of the Delivery Group.  

Decision: Updates

Citrix Receiver is in active development. As such, periodic updates are released that provide enhanced functionality or address user issues. As with any actively developed product, the latest version of these products should be deployed to the endpoints so that users benefit from the latest functionality and to maintain compliance with product support lifecycles. There are multiple methods available to update Citrix Receiver and, if applicable, associated plug-ins.  

  • Auto-Update – Receiver for Windows 4.8+ and Receiver for Mac 12.6+ includes an autoupdate capability that automatically checks for newer versions of Receiver.  The autoupdate service can be configured to allow users to defer updates as well as to skip any updates that are not long-term service release (LTSR) versions. Receiver for iOS and Android are automatically updated through their appropriate store.  
  • Enterprise software deployment – ESD tools provide an organization with direct control over the time/frequency of Receiver updates to managed devices. Additional thought must be given to updating unmanaged devices and endpoints outside of the corporate firewall.  
  • Manual updates – When no automated solution is available, manual methods can be used to update Citrix Receiver. Whether deployed on Receiver for Web site, StoreFront, an internal Citrix Receiver site, or an external site, these options will require user involvement in updating Citrix Receiver. Due to the involved nature of manual updates coupled with the opportunity for a user mistake, this option should only be considered as a last resort.