Professional Documents
Culture Documents
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 ...................................................................... High Availability Planning....................................................................... Active Directory Considerations ............................................................... Web Interface Considerations .................................................................. Delegated Administration....................................................................... Security Planning for XenDesktop ............................................................. User Access and Experience .................................................................... High Availability of the Virtual Desktop Agent ..............................................
3 9 12 15 16 18 21 24
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 on real-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 through Accelerator. For more information and to get started, see the Project Accelerator pages. Figure 1. Project Accelerator sizing plan example
The essential elements you need to have in place for a working XenDesktop site are:
A server to host:
The Controller The License Server. By default, this is installed when you install XenDesktop, but you can choose to use a separate server for licensing. For further information on licensing, see: Licensing. The database. By default, a database is created locally when you install XenDesktop, but you can choose to use a database on a separate server. Important: If you intend using an external database created manually, not created using Desktop Studio, ensure your database administrator uses the following collation setting when creating the database: Latin1_General_CI_AS_KS (where Latin1_General varies depending on the country; for example Japanese_CI_AS_KS). If this collation setting is not specified during database creation, subsequent creation of the XenDesktop service schemas within the database will fail, and an error similar to "<service>: schema requires a case-insensitive database" appears (where <service> is the name of the service whose schema is being created). For further information on setting up the site database, see To configure a XenDesktop site.
Desktop Studio. The console used to configure and manage your XenDesktop deployment. By default, this is installed on servers on which you install the Controller, but you can install it on a separate computer if you want to manage your deployment remotely.
Desktop Director. The console for level-1 and level-2 IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. By default, this is installed on servers on which you install the Controller, but you can choose to install it on a separate computer. A domain controller running Active Directory. Active Directory is required for XenDesktop. Do not install either XenDesktop or the SQL Server database on a domain controller. For more information on Active Directory, see Active Directory Considerations.
Consider the potential implications of the domain name you select. Domain names that may have a duplicate meaning can cause issues in your environment. For example, the string 'client' is also used to access client drive mapping.
VMs or physical computers hosting the desktops you want to deliver to your users. You install the Virtual Desktop Agent on these machines to manage communications and broker connections. User devices running the appropriate client to enable your users to access desktops.
Example Deployments
This topic shows examples of typical XenDesktop deployments, from a simple default configuration to a complex one involving multiple sites. Simple Default Configuration
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 session brokering. 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 your site. You can install the management consoles on separate computers to enable you to manage your deployment remotely. A distributed deployment is also necessary for an infrastructure based on remote access through Access Gateway.
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 virtual desktops or hosting them on a XenApp server. For information on using XenApp with XenDesktop, see Using XenApp with XenDesktop. Profile management to ensure that your users get a consistent experience every time they log on by managing user personalization settings. For more information, see the Profile management documentation.
For more information about Citrix Access Gateway for secure remote access, Edgesight performance monitoring, Branch Repeater for WAN optimization, Workflow Studio and StorageLink, 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 can use Citrix NetScaler to direct user connections to the most appropriate site and the Web Interface to deliver desktops and applications to users. In the following example, each site is split into two data centers, with the database mirrored 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 WAN traffic. A separate Desktop Studio console is required to manage each site; sites cannot be managed as a single entity. Desktop Director can be used to support users across sites.
Planning a XenDesktop Deployment Citrix NetScaler accelerates application performance, load balances servers, increases security, and optimizes the user experience. In the example below, two NetScalers are used to provide a high availability configuration. The NetScalers are configured for Global Server Load Balancing and positioned in the DMZ to provide a multi-site, fault-tolerant solution.
Example
The following example shows a high availability configuration consisting of a primary site and a disaster-recovery site. Each site is split into two data centers, with the database mirrored to provide a fault-tolerant configuration. In the event of an outage in the primary site, NetScalers configured for Global Server Load Balancing, positioned in the DMZ in front of 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 to determine if a site is working properly.
10
11
Security. Active Directory's inbuilt security infrastructure is used by desktops to verify that communications from controllers come from authorized controllers in the appropriate site. Active Directory's security infrastructure also ensures that the data exchanged by desktops and controllers is confidential. XenDesktop uses Active Directory's inbuilt Kerberos infrastructure to guarantee the authenticity and confidentiality of communication. For more information about Kerberos, refer to Microsoft's product documentation. Discovery. Active Directory is optionally used by desktops to discover the controllers that constitute a site. This means you can add a new controller to a site without having to reconfigure all desktops in the site. Instead, desktops determine which controllers are 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 as the controllers.
Note: By default, controller discovery is registry-based, and XenDesktop requires no objects to be created in Active Directory. For more information about the registry entries used by registry-based discovery, see: http://support.citrix.com/article/ctx118976.
12
Active Directory Considerations If the XenDesktop administrator has CreateChild permissions on a parent OU, this administrator can create and populate the site OU by running a PowerShell script, called 'Set-ADControllerDiscovery.ps1'. You can use the standard Active Directory Users and Computers MMC snap-in to configure these permissions. Also, to run Set-ADControllerDiscovery.ps1, the administrator must have full administration rights on XenDesktop. A small number of objects that are essential for the operation of the farm are created in the OU. Note: Only standard Active Directory objects are created and used by XenDesktop. It is not 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 be a member of this security group. Desktops in a site accept data from controllers only if they are members of this security group. Ensure that all controllers have the 'Access this computer from the network' privilege on all virtual desktops running the Virtual Desktop Agent. You can do this by giving the Controllers security group this privilege. If controllers do not have this privilege, virtual desktops will fail to register.
A Service Connection Point (SCP) object that contains information about the site, such as the site's name. Note: If you use the Active Directory Users and Computers administrative tool to inspect a site OU, you may have to enable Advanced Features in the View menu to see SCP objects.
A container called RegistrationServices, which is created within the site's OU. This contains one SCP object for each controller in the site. The SCP is created when the Set-ADControllerDiscovery.ps1 script is run. Each time the controller starts, it validates the contents of its SCP and updates them if necessary.
If multiple administrators are likely to add and remove controllers after the initial installation is complete, they need permissions to create and delete children on the RegistrationServices container and Write properties on the Controllers security group (these permissions are granted automatically to the administrator who creates or populates the OU by running the Set-ADControllerDiscovery.ps1 script). Either the domain administrator or the original installing administrator can grant these permissions, and Citrix recommends setting up a security group to do this. The following points are important to bear in mind when you are using a site OU with XenDesktop:
Information is written to Active Directory only when installing or uninstalling XenDesktop, 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 port was changed). By default, the Set-ADControllerDiscovery.ps1 script sets up permissions on the objects in the site's OU appropriately, giving controllers Write access to their SCP. The contents of the objects in the site OU are used to establish trust between desktops and controllers. You should ensure that:
13
Only authorized administrators can add or remove computers from the Controllers security group, using the security group's access control list (ACL) Only authorized administrators and the respective controller can change the information in the controller's SCP
Depending on your Active Directory infrastructure, you should be aware of replication and its impact on a XenDesktop implementation. Refer to Microsoft's documentation to understand the concepts of replication and associated delays. This is particularly important if you create the site's OU in a domain that has domain controllers located in multiple Active Directory sites. Depending on the location of desktops, controllers, and domain controllers, changes that are made to Active Directory when you are initially creating the OU for the site, installing or uninstalling controllers, or changing controller names or communication ports may not be visible to desktops until that information is replicated to the appropriate domain controller. The symptoms of such replication delay 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 to manage desktops. Depending on your setup, the machine object's fully qualified domain name, as stored in the desktop's Active Directory record, can be included as part of the connection 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 your DNS environment.
14
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 XP and XPe appliances, is: \Inetpub\wwwroot\Citrix\PNAgent The XenDesktop Web site, for window view mode users who need to be able to access multiple 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 the controller address.
To modify the desktop appliance site, you must edit the configuration files as described in the Web Interface documentation. The other default sites are standard Web Interface sites and you can modify them through the 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 interface to refer to desktops rather than applications, see the Web Interface documentation.
15
Delegated Administration
This topic describes the different XenDesktop administration roles and responsibilities. Citrix administrators are not set up automatically during XenDesktop installation. After installation, only local administrators on the server running the Controller have full administrative privileges, with authority to manage and administer all areas of the XenDesktop site. Only an administrator with full rights can create additional full or delegated administrators. Note: Local administrators on the Controller always have full administrative privileges; these privileges always take precedence, regardless of delegated privileges that may later be explicitly assigned by Citrix administrators. However, Citrix recommends that for normal operation, you create Citrix administrators with the appropriate rights, rather than use the Local administrators account. Granting local administrators on the Controller full rights allows these administrators to configure the XenDesktop deployment and prevents a deployment from unintentionally being rendered unmanageable should all explicit administrators be removed.
Full administrator. This administrator has full administration rights with authority to manage and administer the entire XenDesktop site. Full administrators can perform any of the roles listed below, such as that of the machine or assignment administrator. Following XenDesktop installation, only local administrators on the server running the Controller have this role and can create further full or delegated administrators. Note that, to configure hosts, you must be a full administrator. Read-only administrator. This administrator can see all aspects of the XenDesktop site but has no authority to change any settings; any attempted edits will not be saved. Machine administrator. This administrator owns the catalogs and is responsible for building the virtual desktops. The machine administrator can specify which assignment administrators can consume the images created. This administrator can also see other aspects of the XenDesktop site. Assignment administrator. This administrator takes the virtual desktops created by the machine administrator, wraps these in one or more desktop groups and assigns them to users. The assignment administrator can specify which help desk administrators are permitted to support these users; for example, based on geographical roles. This administrator can also see other aspects of the XenDesktop site. Help desk administrator. This administrator performs day-to-day monitoring and maintenance tasks. Help desk administrators can perform the following actions on desktop groups:
Send messages
16
Delegated Administration
Session controls: Disconnect; Logoff Power controls (XenServer; this may differ on other hosts): Suspend; Restart; Force restart; Shut down; Force shutdown; Start
Note: For more information about displaying administration rights and creating additional administrators, see Delegating Administration Tasks. For more information about Desktop Director administration roles, see the Desktop Director documentation.
17
General security best practices when using XenDesktop, and any security-related differences 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 regulatory requirements. This document does not cover this subject, because such security standards change over time. For up-to-date information on security standards and Citrix products, consult Security and Compliance Information, or contact your Citrix representative.
Security Planning for XenDesktop http://www.iana.org/). All network communications should be appropriately secured and encrypted as appropriate to match your security policy. You can secure all communication between Microsoft Windows computers using IPSec; refer to your operating system documentation for details about how to do this. In addition, communication between user devices and desktops is secured through Citrix SecureICA, which is configured by default to 128-bit encryption. You can configure SecureICA when you are creating or updating an assignment; see To secure desktop groups.
By default, when non-privileged users connect to a desktop, they see the time zone of the system running the desktop instead of the time zone of their own user device. For information on how to allow users to see their local time when using desktops, see Configuring Time Zone Settings A user who is an administrator on a desktop has full control over that desktop. If a desktop is a pooled desktop rather than a dedicated desktop, the user must be trusted in respect of all other users of that desktop, including future users. All users of the desktop need to be aware of the potential permanent risk to their data security posed by this situation. This consideration does not apply to dedicated desktops, which have only 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 users administrative privileges only over the desktop to which they are connected, see http://support.citrix.com/article/ctx116942/.
A user who is an administrator on a desktop can generally install software on that desktop, including potentially malicious software. The user can also potentially monitor or control traffic on any network connected to the desktop.
A managed user device can be set up to be used in full-screen-only mode or in window mode:
If a user device is configured to be used in full-screen-only mode, users log on to it with the usual Log On To Windows screen. The same user credentials are then used to log on automatically to XenDesktop. If a user device is configured so that users see their desktop in a window, users first log on to the user device, then log on to XenDesktop through the XenDesktop Web site supplied with XenDesktop.
Unmanaged User Devices User devices that are not managed and administered by a trusted organization cannot be assumed to be under administrative control. For example, you might permit users to obtain and configure their own devices, but users might not follow the general security best practices described above. XenDesktop has the advantage that it is possible to deliver desktops securely to unmanaged user devices. These devices should still have basic antivirus 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 are under their physical control. However, you must still consider the implications of users storing data on desktops. It is not good practice for users to store data on desktops; data should be held on file servers, database servers, or other repositories where it can be appropriately protected. Your desktop environment may consist of various types of desktops, such as pooled and dedicated desktops:
Users should never store data on desktops that are shared amongst users, such as pooled desktops. If users store data on dedicated desktops, that data should be removed if the desktop is later made available to other users.
20
Using a non-domain-joined thin client to access a single virtual desktop (Scenario A in the tables below) Using a domain-joined thin client or repurposed computer to access a single virtual desktop (Scenario B in the tables below) Using a client computer to access multiple virtual desktops (Scenario C in the tables below)
The following table shows the requirements for each scenario: Scenario A User device OS Windows XP, Windows XP Embedded Browser required Yes Web Interface site Desktop Appliance Client Desktop Appliance Lock in Citrix online plug-in 12.1 Citrix Receiver for Linux 11.100 No XenDesktop Services See manufact urer's docume ntation for the relevant thin client Desktop Viewer in Citrix online plug-in 12.1 Client for Windows CE 10.x Citrix online plug-in for Macintosh 11.2 Preinstalled by administrator Client install Preinstalled by administrator
Linux
Yes
XenDesktop Web
Macintosh OS X
21
User Access and Experience The table below summarizes the user experience for each scenario: Scenari o A Logon XenDesktop logon page followed by automatic launch of virtual desktop Windows OS logon page followed by automatic launch of virtual desktop After users click on the URL that provides access to XenDesktop: On first use: If the Citrix online plug-in is installed, the XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available; If the Citrix online plug-in is not installed, the user is prompted to download and install the plug-in. The XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available. On subsequent use: The XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available. [1] A toolbar is available that allows users to switch between different virtual desktops and to customize desktops.
[2]
Virtual desktop display Full screen virtual desktop. No user device OS access. Full screen virtual desktop. No user device OS access. On first use: the virtual desktop appears in window mode. On subsequent use: the virtual desktop appears in either window or full-screen mode, depending on the display mode of the user's last virtual desktop session. User device OS access available.
Toolbar[1] No
No
Yes3
The first time users connect, a Welcome screen appears followed by the XenDesktop logon page.
[3]
You can disable the toolbar using the Web Interface.conf parameter "ShowDesktop Viewer"; for more information, see the Web Interface documentation. If window size must be constrained to a fixed size, disabling the toolbar allows Web Interface settings to take effect. 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
User Access and Experience for details. Citrix also recommends that you regularly check http://www.citrix.com/English/ss/downloads/for new versions of the clients, which may offer further enhancements.
23
24
High Availability of the Virtual Desktop Agent 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 the controller before initiating high availability mode, add the following registry entry (of type 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 that they can use of communication with the controller fails. Create an ICA launch file for each user who requires this feature; Citrix does not create or distribute ICA files for this purpose. For information on how to create ICA files, see http://support.citrix.com/article/CTX127392. Tell your users when it is appropriate to use this ICA launch file and where they can access it from. High Availability Mode Limitations High availability mode is suitable for use only with dedicated desktops; you cannot configure this for use with pooled desktops. In high availability mode, some features are unavailable, including those in the following list:
User roaming. If a client device is already connected to the desktop, users are unable to 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 those governing client drive mapping and access to the clipboard, will not function because there is no connection to the controller. Policies originating from the Domain Controller and 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 longer available.
25