Planning a XenDesktop Deployment

Planning a XenDesktop Deployment

2013-05-22 15:28:53 UTC

2013 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement

Contents

Planning a XenDesktop Deployment ...................................................................... 3High Availability Planning....................................................................... 9Active Directory Considerations ............................................................... 12

Web Interface Considerations.................................................................. 15

Delegated Administration....................................................................... 16Security Planning for XenDesktop ............................................................. 18User Access and Experience .................................................................... 21

High Availability of the Virtual Desktop Agent .............................................. 24

2

3Planning a XenDesktop Deployment

XenDesktop allows you to grow your deployment at a rate that best suits your organization.You can start with a simple default configuration, which you release to additional usergroups at a later time. It is important to think about your deployment in terms of userneeds and focus your pilot on the users who will see the most immediate benefit.

If you are not ready to transition your users to virtual desktops, you can start with aRemote PC deployment that enables them to access their office PCs and take advantage ofCitrix HDX features, and then add traditional virtual desktops and application deploymentslater.

In addition to the essential elements listed here, Project Accelerator is a web applicationthat relays Citrix Consulting Services best practices for a XenDesktop deployment project.Accelerator provides you with:

Step-by-step instructions for a fast, successful XenDesktop deployment

Sizing plan with detailed storage and other hardware needs.

The latest Citrix best practices to help you make informed decisions based onreal-world,XenDesktop installations

An architecture that you can use to plan your deployment

The following are examples of sizing and architecture plans you can produce throughAccelerator.

For more information and to get started, see the Project Accelerator pages.

Figure 1. Project Accelerator sizing plan example

Figure 2. Project Accelerator architecture plan example

The essential elements you need to have in place for a working XenDesktop site are:


4

A server to host:

The Controller

The License Server. By default, this is installed when you install XenDesktop, butyou can choose to use a separate server for licensing. For further information onlicensing, see: Licensing.

The database. By default, a database is created locally when you installXenDesktop, but you can choose to use a database on a separate server.

Important: If you intend using an external database created manually, notcreated using Desktop Studio, ensure your database administrator uses thefollowing collation setting when creating the database: Latin1_General_CI_AS_KS(where Latin1_General varies depending on the country; for exampleJapanese_CI_AS_KS). If this collation setting is not specified during databasecreation, subsequent creation of the XenDesktop service schemas within thedatabase will fail, and an error similar to ": schema requires acase-insensitive database" appears (where is the name of the servicewhose schema is being created).

For further information on setting up the site database, see To configure aXenDesktop site.

Desktop Studio. The console used to configure and manage your XenDesktopdeployment. By default, this is installed on servers on which you install theController, but you can install it on a separate computer if you want to manageyour deployment remotely.

Desktop Director. The console for level-1 and level-2 IT Support staff to monitor aXenDesktop deployment and perform day-to-day maintenance tasks. By default, thisis installed on servers on which you install the Controller, but you can choose toinstall it on a separate computer.

A domain controller running Active Directory. Active Directory is required forXenDesktop. Do not install either XenDesktop or the SQL Server database on a domaincontroller. For more information on Active Directory, see Active DirectoryConsiderations.

Consider the potential implications of the domain name you select. Domain names thatmay have a duplicate meaning can cause issues in your environment. For example, thestring 'client' is also used to access client drive mapping.

VMs or physical computers hosting the desktops you want to deliver to your users. Youinstall the Virtual Desktop Agent on these machines to manage communications andbroker connections.

User devices running the appropriate client to enable your users to access desktops.

Example DeploymentsThis topic shows examples of typical XenDesktop deployments, from a simple defaultconfiguration to a complex one involving multiple sites.

Simple Default Configuration


5

Figure 3. A single controller configuration of XenDesktop, typical of an initial deployment

Note that this configuration forms a single point of failure for administration and sessionbrokering.

Distributed Components Configuration

You can distribute the components of your deployment among a greater number of servers,or provide greater scalability and failover by increasing the number of controllers in yoursite. You can install the management consoles on separate computers to enable you tomanage your deployment remotely. A distributed deployment is also necessary for aninfrastructure based on remote access through Access Gateway.


6

Figure 4. A distributed components configuration of XenDesktop

Further components available with XenDesktop to enhance your deployment include:

XenServer, which is a host used for scalable and cost-effective hosting of desktops.

XenApp to deliver applications to your users either by streaming them to virtualdesktops or hosting them on a XenApp server. For information on using XenApp withXenDesktop, see Using XenApp with XenDesktop.

Profile management to ensure that your users get a consistent experience every timethey log on by managing user personalization settings. For more information, see theProfile management documentation.

For more information about Citrix Access Gateway for secure remote access, Edgesightperformance monitoring, Branch Repeater for WAN optimization, Workflow Studio andStorageLink, see XenDesktop Features and Editions and the product-specific documentation.

Multiple Site Configuration

If you have multiple regional sites, for example one in Europe and one in the US, you canuse Citrix NetScaler to direct user connections to the most appropriate site and the WebInterface to deliver desktops and applications to users.

In the following example, each site is split into two data centers, with the databasemirrored or clustered between the data centers to provide a high availability configuration.Having two sites globally, rather than just one, minimizes the amount of unnecessary WANtraffic. A separate Desktop Studio console is required to manage each site; sites cannot bemanaged as a single entity. Desktop Director can be used to support users across sites.


7

Citrix NetScaler accelerates application performance, load balances servers, increasessecurity, and optimizes the user experience. In the example below, two NetScalers are usedto provide a high availability configuration. The NetScalers are configured for Global ServerLoad Balancing and positioned in the DMZ to provide a multi-site, fault-tolerant solution.

Figure 5. A configuration consisting of multiple regional sites and data centers


8

9High Availability Planning

This topic outlines ways in which you can increase the level of fault tolerance in aXenDesktop deployment to ensure that business-critical applications and desktops arealways available. It also provides pointers to further information and products.

Note: For information about configuring the Virtual Desktop Agent to operate in highavailability mode, see High Availability of the Virtual Desktop Agent.

Configuring Database Fault ToleranceIn XenDesktop, all information is stored on the database; controllers communicate only withthe database and not with each other. A controller may be unplugged or turned off withoutthis affecting other controllers in the site. This means, however, that the database forms asingle point of failure. If the database server fails, existing connections to virtual desktopswill continue to function until the user either logs off or disconnects from their virtualdesktop; new connections cannot be established if the database server is unavailable.

Citrix recommends that you backup the database regularly so that you can restore from thebackup if the database server fails. In addition to this good practice, there are three otherhigh availability solutions to consider for ensuring automatic failover. The benefits anddisadvantages of each of these solutions are outlined below:

1. SQL Mirroring. This is the recommended solution. Mirroring the database ensures that,should you lose the active database server, the automatic failover process happensquickly in a matter of seconds, so users are generally unaffected. This method,however, is more expensive than alternative solutions because full SQL server licensesare required on each database server; you cannot use SQL Express.

2. Using the hypervisor's high availability features. With this method, you deploy thedatabase as a virtual machine and use your hypervisor's high availability features. Thissolution is less expensive than mirroring as it uses your existing host software and youcan also use SQL Express. However, the automatic failover process is slower as it cantake time for a new machine to start for the database, which may interrupt the serviceto users.

3. SQL Clustering. Microsoft's SQL clustering technology can be used to automatically allowone server to take over the tasks and responsibilities of another server that has failed.However, setting up this solution is more complicated, and the automatic failoverprocess typically slower than with alternatives such as SQL Mirroring.

Note: If you want to mirror the XenDesktop database, ensure that the database uses the full recovery model and not the simple model. When Desktop Studio is used to create a database on an external SQL server, the database is configured to use the simple model by default; this means the transaction log cannot be backed up and the database cannot be mirrored. To ensure the database is configured to use the full recovery model, create the database manually and then use Desktop Studio to generate the necessary setup scripts to be run on the database. For more information about configuring XenDesktop for use with a mirrored database, see http://support.citrix.com/article/ctx127359. For more information about reconfiguring an existing XenDesktop site to use a mirrored database,

see http://support.citrix.com/article/ctx127538.

Configuring Site FailoverYou can specify XenDesktop sites for emergency use when users cannot access theirproduction sites; for example, due to a power failure or network outage. This allows you tomake provisions to deal with loss of access to production servers, and to ensure criticalapplications and desktops are always available.

To specify alternate XenDesktop sites, you use the Web Interface to direct users to a list ofrecovery sites when none of their normal sites can be reached. To do this, configure theWeb Interface RecoveryFarm setting with a list of alternate sites. Should no primary sitesbe available, the sites in the RecoveryFarm list are tried one after another until a workingsite is found. For more information about configuring the RecoveryFarm setting, see theWeb Interface documentation.

To further increase the level of fault tolerance, Citrix recommends you use the intelligentload balancing features of NetScaler. In addition to providing users with a single accesspoint, NetScaler can validate that Web Interface and XML services are functioning properlybefore directing user requests to Web Interface servers. This prevents users from beingdirected to servers with inactive services and ensures failover occurs promptly when thereis a disruption.

Fault tolerance can be increased yet further by using the Global Server Load Balancing(GSLB) features of NetScaler. With GSLB in front of Web Interface, you can route users toan alternative site that is still running and reachable. For more information, see theNetScaler Administration Guide and the NetScaler High Availability and GSLB knowledgebase articles available on the Citrix Web site.

To ensure users always access their own virtual desktops and data, regardless of where theyconnect from, you can use the site roaming feature of Web Interface. For example, if youhave users who travel between Europe and the US, or connect from home using laptops, youcan ensure that they always connect to their own virtual desktops and user data fromdifferent sites. To enable site roaming support, you configure the Web Interface, using theFarmGroups parameter, to direct users to the appropriate data center for their virtualdesktops. For more information, see the topic about configuring XenDesktop user roamingin your Web Interface documentation.

ExampleThe following example shows a high availability configuration consisting of a primary siteand a disaster-recovery site. Each site is split into two data centers, with the databasemirrored to provide a fault-tolerant configuration. In the event of an outage in the primarysite, NetScalers configured for Global Server Load Balancing, positioned in the DMZ in frontof the Web Interface, load balance and route user connections to the disaster-recovery site.NetScalers are also positioned between the Web Interface and the XenDesktop sites todetermine if a site is working properly.

High Availability Planning

10

Figure 1. High Availability Configuration

High Availability Planning

11

12

Active Directory Considerations

Active Directory is required in a XenDesktop deployment for authentication andauthorization. Active Directory can also be used for controller discovery, if you decide notto use the default registry-based discovery mechanism. This topic explains how XenDesktopuses Active Directory, how to employ Active Directory-based discovery, and it outlines theActive Directory environments that are supported.

XenDesktop uses the services provided by Active Directory for two main purposes:

Security. Active Directory's inbuilt security infrastructure is used by desktops to verifythat communications from controllers come from authorized controllers in theappropriate site. Active Directory's security infrastructure also ensures that the dataexchanged by desktops and controllers is confidential. XenDesktop uses ActiveDirectory's inbuilt Kerberos infrastructure to guarantee the authenticity andconfidentiality of communication. For more information about Kerberos, refer toMicrosoft's product documentation.

Discovery. Active Directory is optionally used by desktops to discover the controllersthat constitute a site. This means you can add a new controller to a site without havingto reconfigure all desktops in the site. Instead, desktops determine which controllersare available by referring to information that controllers publish in Active Directory.This feature is available only if the desktops are in the same Active Directory forest asthe controllers.

Note: By default, controller discovery is registry-based, and XenDesktop requires noobjects to be created in Active Directory. For more information about the registry entriesused by registry-based discovery, see: http://support.citrix.com/article/ctx118976.

Active Directory-based Controller DiscoveryDuring installation of the Virtual Desktop Agent, you can choose to use ActiveDirectory-based discovery rather than the default registry-based discovery. ActiveDirectory-based discovery requires that all computers in a site are members of a domain,with mutual trusting relationships between the domain used by controller and thedomain(s) used by desktops.

Note: If your organizational structure means that you need a deployment where thecontrollers are in a separate Active Directory forest from the desktops for your users, seehttp://support.citrix.com/article/ctx122417 for details of how to configure a supportedsolution.

When you create a site, a corresponding Organizational Unit (OU) must be created in ActiveDirectory if you want desktops to discover the controllers in the site through ActiveDirectory. The OU can be created in any domain in the forest that contains your computers.As best practice, the OU should also contain the controllers in the farm, but this is notenforced or required. A domain administrator with appropriate privileges can create the OUas an empty container. The domain administrator can then delegate administrativeauthority over the OU to a XenDesktop administrator.

If the XenDesktop administrator has CreateChild permissions on a parent OU, thisadministrator can create and populate the site OU by running a PowerShell script, called'Set-ADControllerDiscovery.ps1'. You can use the standard Active Directory Users andComputers MMC snap-in to configure these permissions. Also, to runSet-ADControllerDiscovery.ps1, the administrator must have full administration rights onXenDesktop.

A small number of objects that are essential for the operation of the farm are created inthe OU.

Note: Only standard Active Directory objects are created and used by XenDesktop. It isnot necessary to extend the schema.

The set of objects created includes:

A Controllers security group. The computer account of all controllers in the site must bea member of this security group. Desktops in a site accept data from controllers only ifthey are members of this security group.

Ensure that all controllers have the 'Access this computer from the network' privilege onall virtual desktops running the Virtual Desktop Agent. You can do this by giving theControllers security group this privilege. If controllers do not have this privilege, virtualdesktops will fail to register.

A Service Connection Point (SCP) object that contains information about the site, suchas the site's name.

Note: If you use the Active Directory Users and Computers administrative tool toinspect a site OU, you may have to enable Advanced Features in the View menu tosee SCP objects.

A container called RegistrationServices, which is created within the site's OU. Thiscontains one SCP object for each controller in the site. The SCP is created when theSet-ADControllerDiscovery.ps1 script is run. Each time the controller starts, it validatesthe contents of its SCP and updates them if necessary.

If multiple administrators are likely to add and remove controllers after the initialinstallation is complete, they need permissions to create and delete children on theRegistrationServices container and Write properties on the Controllers security group (thesepermissions are granted automatically to the administrator who creates or populates the OUby running the Set-ADControllerDiscovery.ps1 script). Either the domain administrator orthe original installing administrator can grant these permissions, and Citrix recommendssetting up a security group to do this.

The following points are important to bear in mind when you are using a site OU withXenDesktop:

Information is written to Active Directory only when installing or uninstallingXenDesktop, or when a controller starts and needs to update the information in its SCP(for example, because the controller was renamed or because the communication portwas changed). By default, the Set-ADControllerDiscovery.ps1 script sets up permissionson the objects in the site's OU appropriately, giving controllers Write access to theirSCP. The contents of the objects in the site OU are used to establish trust betweendesktops and controllers. You should ensure that:


13

Only authorized administrators can add or remove computers from the Controllerssecurity group, using the security group's access control list (ACL)

Only authorized administrators and the respective controller can change theinformation in the controller's SCP

Depending on your Active Directory infrastructure, you should be aware of replicationand its impact on a XenDesktop implementation. Refer to Microsoft's documentation tounderstand the concepts of replication and associated delays. This is particularlyimportant if you create the site's OU in a domain that has domain controllers located inmultiple Active Directory sites. Depending on the location of desktops, controllers, anddomain controllers, changes that are made to Active Directory when you are initiallycreating the OU for the site, installing or uninstalling controllers, or changing controllernames or communication ports may not be visible to desktops until that information isreplicated to the appropriate domain controller. The symptoms of such replicationdelay include desktops that cannot establish contact with controllers and are,therefore, not available for user connections.

XenDesktop uses some of the standard computer object attributes in Active Directory tomanage desktops. Depending on your setup, the machine object's fully qualified domainname, as stored in the desktop's Active Directory record, can be included as part of theconnection settings that are returned to the user to make a connection. It is, therefore,important to ensure that this information is consistent with information held in yourDNS environment.

Supported Active Directory EnvironmentsXenDesktop supports deployments in which the user accounts and computer accounts existin domains in a single Active Directory forest. User and computer accounts can exist inarbitrary domains within a single forest. All domain functional levels and forest functionallevels are supported in this type of deployment.

XenDesktop also supports deployments in which user accounts exist in an Active Directoryforest that is different from the Active Directory forest containing the computer accountsof the controllers and virtual desktops. In this type of deployment, the domain(s) containingthe controller and virtual desktop computer accounts must trust the domain(s) containinguser accounts. Forest trusts or external trusts can be used. All domain functional levels andforest functional levels are supported in this type of deployment.

Additionally, XenDesktop supports deployments in which the computer accounts forcontrollers exist in an Active Directory forest that is different from one or more additionalActive Directory forests that contain the computer accounts of the virtual desktops. In thistype of deployment a bi-directional trust must exist between the domain(s) containing thecontroller computer accounts and all domain(s) containing the virtual desktop computeraccounts. In this type of deployment, all domains containing controller or virtual desktopcomputer accounts must be at "Windows 2000 native" functional level or higher. All forestfunctional levels are supported. For more information about enabling this type ofdeployment, see http://support.citrix.com/article/ctx122417.


14

15

Web Interface Considerations

Citrix Web Interface is installed by default on all servers on which you install the controller,together with three Web sites. This topic provides details about the additional options youhave in relation to the Web Interface and the default Web sites.

The default sites are typically created in the following locations when the Web Interface isinstalled:

The desktop appliance site, for XenDesktop-ready thin clients, is:\Inetpub\wwwroot\Citrix\DesktopAppliance

The XenDesktop Services site, for full-screen-only use with domain-joined Windows XPand XPe appliances, is: \Inetpub\wwwroot\Citrix\PNAgent

The XenDesktop Web site, for window view mode users who need to be able to accessmultiple desktops or to access desktops from a browser, is:\Inetpub\wwwroot\Citrix\DesktopWeb

This is the default site that users are presented with if they browse just to thecontroller address.

To modify the desktop appliance site, you must edit the configuration files as described inthe Web Interface documentation.

The other default sites are standard Web Interface sites and you can modify them throughthe Web Interface Management Console.

For remote access through Access Gateway, you need to create a new Web Interface site.For information about creating sites, and details of how to modify the site's user interfaceto refer to desktops rather than applications, see the Web Interface documentation.

16

Delegated Administration

This topic describes the different XenDesktop administration roles and responsibilities.

Citrix administrators are not set up automatically during XenDesktop installation. Afterinstallation, only local administrators on the server running the Controller have fulladministrative privileges, with authority to manage and administer all areas of theXenDesktop site. Only an administrator with full rights can create additional full ordelegated administrators.

Note: Local administrators on the Controller always have full administrative privileges;these privileges always take precedence, regardless of delegated privileges that maylater be explicitly assigned by Citrix administrators. However, Citrix recommends that fornormal operation, you create Citrix administrators with the appropriate rights, ratherthan use the Local administrators account.

Granting local administrators on the Controller full rights allows these administrators toconfigure the XenDesktop deployment and prevents a deployment from unintentionallybeing rendered unmanageable should all explicit administrators be removed.

XenDesktop Administration RolesThere are five types of XenDesktop administrator:

Full administrator. This administrator has full administration rights with authority tomanage and administer the entire XenDesktop site. Full administrators can perform anyof the roles listed below, such as that of the machine or assignment administrator.Following XenDesktop installation, only local administrators on the server running theController have this role and can create further full or delegated administrators. Notethat, to configure hosts, you must be a full administrator.

Read-only administrator. This administrator can see all aspects of the XenDesktop sitebut has no authority to change any settings; any attempted edits will not be saved.

Machine administrator. This administrator owns the catalogs and is responsible forbuilding the virtual desktops. The machine administrator can specify which assignmentadministrators can consume the images created. This administrator can also see otheraspects of the XenDesktop site.

Assignment administrator. This administrator takes the virtual desktops created by themachine administrator, wraps these in one or more desktop groups and assigns them tousers. The assignment administrator can specify which help desk administrators arepermitted to support these users; for example, based on geographical roles. Thisadministrator can also see other aspects of the XenDesktop site.

Help desk administrator. This administrator performs day-to-day monitoring andmaintenance tasks. Help desk administrators can perform the following actions ondesktop groups:

Send messages

Session controls: Disconnect; Logoff

Power controls (XenServer; this may differ on other hosts): Suspend; Restart; Forcerestart; Shut down; Force shutdown; Start

Note: For more information about displaying administration rights and creating additionaladministrators, see Delegating Administration Tasks. For more information about DesktopDirector administration roles, see the Desktop Director documentation.

Delegated Administration

17

18

Security Planning for XenDesktop

This topic describes:

General security best practices when using XenDesktop, and any security-relateddifferences between XenDesktop and a conventional computer environment

Managing user privileges

Deployment scenarios and their security implications

Your organization may need to meet specific security standards to satisfy regulatoryrequirements. This document does not cover this subject, because such security standardschange over time. For up-to-date information on security standards and Citrix products,consult Security and Compliance Information, or contact your Citrix representative.

Security Best PracticesKeep all computers in your environment up to date with security patches. One advantage ofXenDesktop is that you can use thin clients as terminals, which simplifies this task.

Protect all computers in your environment with antivirus software.

Protect all computers in your environment with perimeter firewalls, including at enclaveboundaries as appropriate.

If you are migrating a conventional environment to XenDesktop, you may need to repositionan existing perimeter firewall or add new perimeter firewalls. For example, suppose thereis a perimeter firewall between a conventional client and database server in the datacenter. When XenDesktop is used, that perimeter firewall must instead be placed so thatthe virtual desktop and user device are on one side of it, and the database servers andcontrollers in the data center are on the other side. You should, therefore, considercreating an enclave within your data center to contain the servers and controllers used byXenDesktop. You should also consider having protection between the user device and thevirtual desktop.

All computers in your environment should be protected by a personal firewall on thecomputer. When the Virtual Desktop Agent is installed, it prompts for consent to adjust theconfiguration of the Microsoft Windows Firewall to add any necessary program exceptions orport exceptions so that the Virtual Desktop Agent will operate correctly. These exceptionsare displayed by Windows Firewall in the usual way. The exceptions are removed if theVirtual Desktop Agent is uninstalled. If you are using a personal firewall other than WindowsFirewall, you must adjust the firewall configuration manually. For further details aboutconfiguring firewalls, see To configure firewalls manually.

Note: TCP ports 1494 and 2598 are used for ICA and CGP and are therefore likely to be open at firewalls so that users outside the data center can access them. Citrix recommends that you do not use these ports for anything else, to avoid the possibility of inadvertently leaving administrative interfaces open to attack. Ports 1494 and 2598 are officially registered with the Internet Assigned Number Authority (see

http://www.iana.org/).

All network communications should be appropriately secured and encrypted as appropriateto match your security policy. You can secure all communication between MicrosoftWindows computers using IPSec; refer to your operating system documentation for detailsabout how to do this. In addition, communication between user devices and desktops issecured through Citrix SecureICA, which is configured by default to 128-bit encryption. Youcan configure SecureICA when you are creating or updating an assignment; see To securedesktop groups.

Managing User PrivilegesYou should grant users only the capabilities they require. Microsoft Windows privilegescontinue to be applied to desktops in the usual way: configure privileges through UserRights Assignment and group memberships through Group Policy. One advantage ofXenDesktop is that it is possible to grant a user administrative rights to a desktop withoutalso granting physical control over the computer on which the desktop is stored.

When planning for desktop privileges, note:

By default, when non-privileged users connect to a desktop, they see the time zone ofthe system running the desktop instead of the time zone of their own user device. Forinformation on how to allow users to see their local time when using desktops, seeConfiguring Time Zone Settings

A user who is an administrator on a desktop has full control over that desktop. If adesktop is a pooled desktop rather than a dedicated desktop, the user must be trustedin respect of all other users of that desktop, including future users. All users of thedesktop need to be aware of the potential permanent risk to their data security posedby this situation. This consideration does not apply to dedicated desktops, which haveonly a single user; that user should not be an administrator on any other desktop.

Note: For information about how to use standard Windows procedures to grant usersadministrative privileges only over the desktop to which they are connected, seehttp://support.citrix.com/article/ctx116942/.

A user who is an administrator on a desktop can generally install software on thatdesktop, including potentially malicious software. The user can also potentially monitoror control traffic on any network connected to the desktop.

Deployment Scenario Security ImplicationsYour user environment can consist either of user devices that are unmanaged by yourorganization and completely under the control of the user, or of user devices that aremanaged and administered by your organization. The security considerations for these twoenvironments are generally different.

Managed User Devices

Managed user devices are under administrative control; they are either under your owncontrol, or the control of another organization that you trust. You may configure and supplyuser devices directly to users; alternatively, you may provide terminals on which a singledesktop runs in full-screen-only mode (XenDesktop-ready thin clients). You should follow


19

A managed user device can be set up to be used in full-screen-only mode or in windowmode:

If a user device is configured to be used in full-screen-only mode, users log on to it withthe usual Log On To Windows screen. The same user credentials are then used to log onautomatically to XenDesktop.

If a user device is configured so that users see their desktop in a window, users first logon to the user device, then log on to XenDesktop through the XenDesktop Web sitesupplied with XenDesktop.

Unmanaged User Devices

User devices that are not managed and administered by a trusted organization cannot beassumed to be under administrative control. For example, you might permit users to obtainand configure their own devices, but users might not follow the general security bestpractices described above. XenDesktop has the advantage that it is possible to deliverdesktops securely to unmanaged user devices. These devices should still have basicantivirus protection that will defeat keylogger and similar input attacks.

Data Storage Considerations

When using XenDesktop, you can prevent users from storing data on user devices that areunder their physical control. However, you must still consider the implications of usersstoring data on desktops. It is not good practice for users to store data on desktops; datashould be held on file servers, database servers, or other repositories where it can beappropriately protected.

Your desktop environment may consist of various types of desktops, such as pooled anddedicated desktops:

Users should never store data on desktops that are shared amongst users, such aspooled desktops.

If users store data on dedicated desktops, that data should be removed if the desktop islater made available to other users.


20

21

User Access and Experience

This topic outlines the user experience, depending on how users access their virtualdesktops, such as the logon page displayed, whether sessions appear in full screen orwindow mode, and whether a toolbar is available or not. Understanding the implications ofuser access helps you determine how accessible the local operating system is to users. Forexample, you may wish to restrict some users to virtual desktops only, while allowing othersaccess to their local operating system as well as their virtual desktops.

The main user access scenarios supported for XenDesktop are:

Using a non-domain-joined thin client to access a single virtual desktop (Scenario A inthe tables below)

Using a domain-joined thin client or repurposed computer to access a single virtualdesktop (Scenario B in the tables below)

Using a client computer to access multiple virtual desktops (Scenario C in the tablesbelow)

The following table shows the requirements for each scenario:

Scenario User deviceOS

Browserrequired

Web Interfacesite

Client Client install

A Windows XP,Windows XPEmbedded

Yes DesktopAppliance

DesktopApplianceLock in Citrixonline plug-in12.1

Preinstalledbyadministrator

Linux CitrixReceiver forLinux 11.100

B Windows XP,Windows XPEmbedded

No XenDesktopServices

See manufacturer's documentation forthe relevantthin client

Preinstalledbyadministrator

C Windows 7,WindowsVista,Windows XP

Yes XenDesktopWeb

DesktopViewer inCitrix onlineplug-in 12.1

Preinstalledbyadministratoror throughauto clientdetection oruser prompt

Windows CE Client forWindows CE10.x

Macintosh OSX

Citrix onlineplug-in forMacintosh11.2

The table below summarizes the user experience for each scenario:

Scenario

Logon Virtual desktop display Toolbar[1]

A XenDesktop logon pagefollowed by automaticlaunch of virtual desktop 2

Full screen virtual desktop. No userdevice OS access.

No

B Windows OS logon pagefollowed by automaticlaunch of virtual desktop 2

Full screen virtual desktop. No userdevice OS access.

No

C After users click on theURL that provides accessto XenDesktop:

On first use: If the Citrixonline plug-in is installed,the XenDesktop logon pageappears followed either bya list of available virtualdesktops or automaticlaunch if only one isavailable;

If the Citrix online plug-inis not installed, the user isprompted to download andinstall the plug-in. TheXenDesktop logon pageappears followed either bya list of available virtualdesktops or automaticlaunch if only one isavailable.

On subsequent use: TheXenDesktop logon pageappears followed either bya list of available virtualdesktops or automaticlaunch if only one isavailable.

On first use: the virtual desktopappears in window mode.

On subsequent use: the virtualdesktop appears in either windowor full-screen mode, depending onthe display mode of the user's lastvirtual desktop session.

User device OS access available.

Yes3

[1] A toolbar is available that allows users to switch between different virtual desktops andto customize desktops.

[2] The first time users connect, a Welcome screen appears followed by the XenDesktoplogon page.

[3] You can disable the toolbar using the Web Interface.conf parameter "ShowDesktopViewer"; for more information, see the Web Interface documentation. If window size mustbe constrained to a fixed size, disabling the toolbar allows Web Interface settings to takeeffect.

For full XenDesktop 5 functionality, use the Desktop Viewer in the Citrix online plug-in 12.1. Other clients provide differing levels of functionality: see the specific client documentation


22

for details. Citrix also recommends that you regularly checkhttp://www.citrix.com/English/ss/downloads/for new versions of the clients, which mayoffer further enhancements.


23

24

High Availability of the Virtual DesktopAgent

If all controllers in a XenDesktop site fail, you can configure the Virtual Desktop Agent tooperate in high availability mode so that users can continue to access and use theirdesktops. In high availability mode, the Virtual Desktop Agent will accept direct ICAconnections from users, rather than connections brokered by the controller.

Note: This feature is for use only on the rare occasion that communication with allcontrollers fails; it is not an alternative to other high availability solutions, such asconfiguring database fault tolerance and site failover. Before using this feature, refer tothe list of limitations below as these have security implications.

If communication with the controller fails, high availability mode is initiated only after aset period of time has elapsed. By default, this is 300 seconds (5 minutes), but you canconfigure the time period.

Once in high availability mode, the Virtual Desktop Agent attempts to register with acontroller for up to 30 days, while the user continues to use the desktop in this mode. Whenthe controller later becomes available, the desktop registers and the user's sessioncontinues uninterrupted, but any subsequent connection is brokered by the controller asnormal. If, after 30 days, the desktop is unable to register with the controller, the desktopstops listening for connections and is no longer available. This means the administrator has30 days to repair the controller infrastructure and should not rely on high availability mode.

High availability mode is suitable only for use with dedicated desktops, where the mappingbetween the user and the Virtual Desktop Agent is known. You cannot configure highavailability mode for use with pooled desktops.

To enable high availability mode, you:

1. Set the HighAvailability and HaRegistrarTimeout registry keys.

2. Provide users with an ICA launch file that enables them to make direct ICA connections.Create an ICA file for each user who requires this feature; Citrix does not create ordistribute ICA files for this purpose.

Setting the Registry Keys

To configure the Virtual Desktop Agent so that it operates in high availability mode whennecessary, add the following registry key or keys. Do this after the Virtual Desktop Agenthas been installed.

Caution: Editing the Registry incorrectly can cause serious problems that might requireyou to reinstall your operating system. Citrix cannot guarantee that problems resultingfrom incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.Be sure to back up the registry before you edit it.

1. Add the following registry entry (of type REG_DWORD) toHKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent: HighAvailability.

Set this to 1 to enable high availability mode; 0 (zero), to disable it.

2. To change the time period that the Virtual Desktop Agent tries to register with thecontroller before initiating high availability mode, add the following registry entry (oftype REG_DWORD): HaRegistrarTimeout.

Specify the number of seconds. The default is 300 seconds.

3. Restart the virtual desktop.

Preparing an ICA Launch File

To establish a direct ICA connection to desktops, provide users with an ICA launch file thatthey can use of communication with the controller fails. Create an ICA launch file for eachuser who requires this feature; Citrix does not create or distribute ICA files for this purpose.For information on how to create ICA files, seehttp://support.citrix.com/article/CTX127392.

Tell your users when it is appropriate to use this ICA launch file and where they can accessit from.

High Availability Mode Limitations

High availability mode is suitable for use only with dedicated desktops; you cannotconfigure this for use with pooled desktops.

In high availability mode, some features are unavailable, including those in the followinglist:

User roaming. If a client device is already connected to the desktop, users are unableto connect from a different client device.

Power management. When the desktop powers up, it attempts to register, fails and,after the timeout, enters high availability mode.

Controller-originated policies. Policies originating on the controller, such as thosegoverning client drive mapping and access to the clipboard, will not function becausethere is no connection to the controller. Policies originating from the Domain Controllerand Local Group Policy are unaffected.

Access Gateway and Remote Access

High availability mode persists for up to 30 days only, after which the desktop is no longeravailable.

High Availability of the Virtual Desktop Agent

25

Planning a XenDesktop DeploymentHigh Availability PlanningActive Directory ConsiderationsWeb Interface ConsiderationsDelegated AdministrationSecurity Planning for XenDesktop User Access and ExperienceHigh Availability of the Virtual Desktop Agent

Documents

Planning a XenDesktop Deployment