Planning Your Deployment

Planning Your Deployment

Before you install the various components of XenDesktop you need to plan your deployment to ensure that it meets all your organization’s needs. This section provides information about:

• New features in this release and where to find information about how to configure them

• Planning your farm

• Using Active Directory with Desktop Delivery Controller

• Using the Web Interface with Desktop Delivery Controller

• Security planning

• Upgrading from previous versions of XenDesktop

New Features in this Release

The Citrix XenDesktop Overview contains a complete list of new features at this release. The following are new features that require configuration and that are described in this guide:

Feature:

Smart card authentication
User-driven desktop restart
USB support

Described in......

“Using Smart Cards with XenDesktop” on page 37
“To configure user-driven desktop restart” on page 92
“Configuring USB Support” on page 95

Planning Your Farm

XenDesktop allows you to grow your deployment at the rate that best suits your organization. You can start with a simple default configuration that provides you with a working deployment on a minimum number of computers. You can then add further controllers and components to the farm as necessary.

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

1. A server to host:

• The main delivery controller component.

• Citrix Licensing. By default, this is installed when you install Desktop Delivery Controller, but you can choose to use a separate server for licensing. For further information on licensing, see “Licensing” on page 46.

• A farm data store. This is where persistent information about the farm, such as configuration information and administrator account information, is stored. By default, a database for this is created locally when you create your server farm, but you can choose to use a database on a separate server. For further information on farm data stores, see “Creating the Farm Data Store” on page 47.

• Management consoles to enable you to create desktop groups and manage your deployment. These are installed by default on servers on which you install Desktop Delivery Controller, and you can also install them on separate computers if you want to manage your deployment remotely. You carry out most management tasks using the Access Management Console; the Presentation Server Console is used only for configuring printing and policies.

2. A domain controller running Active Directory. Active Directory is required for XenDesktop, but you cannot install XenDesktop on a domain controller. For more information on using Active Directory, see “Using Active Directory with Desktop Delivery Controller” on page 15.

3. 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.

4. Endpoint devices running the Citrix Desktop Receiver to enable your users to access desktops.

An initial deployment might consist of the following:

This figure shows a single controller configuration of XenDesktop.

You can distribute the components of your deployment among a greater number of servers, or to provide greater scalability and failover by increasing the number of controllers in your farm. 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.

A more distributed deployment might consist of the following:

This figure shows a distributed components configuration of XenDesktop.

You can also use XenServer, which is provided with all editions of XenDesktop, for scalable and cost-effective hosting of desktops, as described in “Preparing and Provisioning Desktops” on page 67.

The Advanced, Enterprise, and Platinum editions of XenDesktop provide further components to enhance your deployment:

1. Provisioning Server enables you to stream a single desktop image to create multiple virtual desktops on one or more servers in a data center, and then to manage images on an ongoing basis. This greatly reduces the amount of storage required compared to other methods of creating virtual desktops. For information on using Provisioning Server, see “Preparing and Provisioning Desktops” on page 67.

2. You can use XenApp for Virtual Desktops to deliver applications to your sers either by streaming them to virtual desktops or hosting them on a XenApp server. For information on using XenApp for Virtual Desktops, see “Using XenApp for Virtual Desktops” on page 111.

3. Ensure that your users get a consistent experience every time they log on by managing user personalization settings with Citrix User Profile Manager. For information on using Citrix User Profile Manager with XenDesktop, see Using Citrix User Profile Manager with XenDesktop.

4. Information on using Citrix Access Gateway, Edgesight for Endpoints, WANScaler, GoToAssist, and EasyCall is provided in their own productspecific documentation.

Using Active Directory with Desktop Delivery Controller

Desktop Delivery Controller uses the services provided by Active Directory. It requires that all computers in a farm are members of the same domain, or of mutually trusting domains in a single Active Directory forest. It is important to understand how Desktop Delivery Controller uses Active Directory to appreciate the implications for your Active Directory environment.

Desktop Delivery Controller uses Active Directory for two main purposes:

1. Active Directory’s inbuilt security infrastructure is used by desktops to check that incoming communications from controllers come from authorized controllers in the appropriate farm. Active Directory’s security infrastructure also ensures that the data exchanged by desktops and controllers is confidential. Desktop Delivery Controller 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.

2. Active Directory is used by desktops to discover the controllers that constitute a farm. This means you can add a new controller to a farm without having to reconfigure all desktops in the farm. Instead, desktops determine which controllers are available by referring to information that controllers publish in Active Directory.

When you create a farm, a corresponding Organizational Unit (OU) must be created in Active Directory. The OU can be created in any domain in the forest that contains your computers. As best practice the OU should also contain the delivery controllers in the farm, but this is not enforced or required. A domain administrator with appropriate privileges can create the OU as an empty container. This administrator can then delegate administrative authority over the OU to the Desktop Delivery Controller administrator. If, however, the installing administrator has CreateChild permissions on a parent OU, this administrator can create the farm OU through the Active Directory Configuration wizard during installation. You can use the standard Active Directory Users and Computers MMC snap-in to configure these permissions. For further information about how to create the OU, see “Configuring Active Directory” on page 50.

During the Desktop Delivery Controller installation process, a small number of objects that are essential for the operation of the farm are created in the OU.

The set of objects created includes:

1. A Controllers security group. The computer account of all controllers in the farm must be a member of this security group. By default, this is done as part of installing Desktop Delivery Controller on a server. Desktops in a farm 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.

2. A Service Connection Point (SCP) object that contains meta-information about the farm, such as the farm’s name.

3. A container called RegistrationServices, which is created within the farm’s OU. This contains one SCP object for each controller in the farm. The SCP is created when Desktop Delivery Controller is installed on a server. 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 installs the farm.) 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 Desktop Delivery Controller:

1. Information is written to Active Directory only when installing or uninstalling Desktop Delivery Controller, 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 installation routine sets up permissions on the objects in the farm’s OU appropriately, giving controllers Write access to their SCP. The contents of the objects in the farm OU are used to establish trust between desktops and controllers. You should ensure that:

• Only authorized Desktop Delivery Controller 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

2. Depending on your Active Directory infrastructure, you should be aware of replication and its impact on a Desktop Delivery Controller implementation. Refer to Microsoft’s documentation to understand the concepts of replication and associated delays. This is particularly important if you create the farm’s OU in a domain that has domain controllers located in multiple Active Directory sites. Depending on the location of desktops, delivery controllers, and domain controllers, changes that are made to Active Directory when you are initially creating the OU for the farm, 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.