XDAdminGuide PDF

Citrix XenDesktop Administrators Guide
Citrix XenDesktop 3.0

Citrix XenDesktop
Copyright and Trademark Notice

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are
fictitious unless otherwise noted. Other than printing one copy for personal use, no part of this document may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of
Citrix Systems, Inc.
Copyright 2009 Citrix Systems, Inc. All rights reserved.
Citrix, ICA (Independent Computing Architecture), and Program Neighborhood are registered trademarks, and XenDesktop,
Citrix XenApp, Citrix Presentation Server, Citrix Access Gateway, Citrix XenServer, Citrix Provisioning Server, SpeedScreen
and GoToAssist are trademarks of Citrix Systems, Inc. in the United States and other countries.
This product includes software developed by The Apache Software Foundation (http://www.apache.org/).
Adobe, Reader, and PostScript are trademarks or registered trademarks of Adobe Systems Incorporated in the U.S. and/or other
countries.
Internet Explorer, Microsoft, MS-DOS, Windows, Windows Server, Windows NT, Windows XP, Win32, Access, Visual J#, and
Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
Java is a trademark of Sun Microsystems, Inc. in the United States and other countries.
VMware is a trademark of VMware Inc.
All other trademarks and registered trademarks are the property of their owners.
Last Updated: January 9, 2009 (SC)
Contents
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
How to Use This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Getting Support and Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Planning Your Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

New Features in this Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Planning Your Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Using Active Directory with Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . . .15
Using the Web Interface with Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . .18
Security Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Security Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Managing User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Deployment Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Upgrading from Previous Versions of XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Planning the User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Your Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Desktop Connection Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Scenario A: Connecting from an Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Scenario B: Connecting from a Domain-Joined or Repurposed Computer. . . . . . . . . . .30
Scenario C: Connecting from a Fat Client Device on a LAN . . . . . . . . . . . . . . . . . . . . .31
Scenario D: Connecting from Remote Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Using Smart Cards with XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Smart Card Types and Readers Supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Endpoint Device Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Secure Use of Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Configuring Smart Card Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Managing Smart Card Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Removing Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Installing XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
XenDesktop Installation Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Whats on the Installation Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Creating the Farm Data Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Installing Desktop Delivery Controller on a Single Server . . . . . . . . . . . . . . . . . . . . . . . . . .47
To install Desktop Delivery Controller and create a farm . . . . . . . . . . . . . . . . . . . . . . . .48
Configuring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Using a Separate Database Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Adding Controllers to Your Farm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
To add a controller to a farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Installing the Management Consoles Separately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
To install the management consoles on a separate computer . . . . . . . . . . . . . . . . . . . . . .52
Starting the Access Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
To configure and run discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Installing VM Infrastructure Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
To install XenServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Replacing the Default XenServer SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Installing Citrix Provisioning Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Installing the XenDesktop Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Installing the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
To install the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
To configure firewalls manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Installing the Citrix Desktop Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Upgrading to XenDesktop 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
To upgrade Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
To upgrade the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Upgrading to a Different Edition of XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Removing XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
To remove the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Removing Desktop Delivery Controller Components . . . . . . . . . . . . . . . . . . . . . . . . . . .64
To remove the XenDesktop Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Contents
Preparing and Provisioning Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
To create a base desktop VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
To create a vDisk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
To add the base desktop VM to the Provisioning Server database . . . . . . . . . . . . . . . . . . . .71
To install a target device for the x86 Platform on the base desktop VM. . . . . . . . . . . . . . . .71
To image the base desktop VM to the Provisioning Server vDisk . . . . . . . . . . . . . . . . . . . .72
To set the vDisk access mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
To create a Provisioning Server VM template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Creating and Updating Desktop Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
To create a VM-based pooled desktop group using the XenDesktop Setup Wizard . . . . . .76
To enable logging on the XenDesktop Setup Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . .79
To enable Pool Management logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
To create a VM-based desktop group using the Access Management Console . . . . . . . . . .79
Using More than One XenServer Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
To create multiple pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
To create a PC- or blade-based desktop group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Configuring Advanced Settings for Desktop Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Configuring Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Setting Up an Idle Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Configuring Logoff Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Specifying Client Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Importing and Exporting Desktop and User Assignment Data . . . . . . . . . . . . . . . . . . . . . . .87
To export data to a file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
To import data from a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Updating Desktop Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
To update a desktop group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
To configure user-driven desktop restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
To delete a desktop group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Customizing Your Desktop Delivery Controller Environment. . . . . . . . . . . . . . . . . . . . . . . . . 93

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Creating Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Delegating Active Directory Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Delegating Desktop Delivery Controller Administration Tasks . . . . . . . . . . . . . . . . . . .94
Configuring USB Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

To configure USB support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Support for USB Mass Storage Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Optimizing the User Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Configuring Time Zone Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Configuring Connection Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Disabling RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Removing the Shut Down Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Managing Your Desktop Delivery Controller Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Putting Desktops into Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
To put a desktop into maintenance mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
Managing Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
To view sessions for a desktop group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
To view all sessions for a particular user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
To disconnect or log off a session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
To send a message to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Manually Controlling Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
To start virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
To shut down and restart virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Migrating Controllers to Other Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
To migrate a controller to another farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Migrating Desktops to Other Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Updating License Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
To specify a license server for the farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
To specify a license server for an individual controller . . . . . . . . . . . . . . . . . . . . . . . . .109
10 Using XenApp for Virtual Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Why Use XenApp with XenDesktop? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Application Streaming Versus Hosting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Before Installing XenApp in a XenDesktop Environment . . . . . . . . . . . . . . . . . . . . . . . . .113
Server Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Management Console Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Installing XenApp from the Product Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Licensing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Contents
Optimizing Application Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Installing the XenApp Plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Setting up Pass-through Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Mapping Network Drives Using a Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Pre-caching Streamed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Smart Card Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
User Profile Manager Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
11 Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Installing and Removing Controllers Using Setup.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Installing and Removing the Virtual Desktop Agent Using XdsAgent.msi . . . . . . . . . . . .122
Configuring Active Directory Using ADSetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Introduction
This section describes how to use this document and provides details of the other
sources of information about Citrix XenDesktop.
How to Use This Document

The Citrix XenDesktop Administrators Guide is for system administrators
responsible for installing, configuring, and maintaining XenDesktop. It is part of
the Citrix XenDesktop documentation set; you can download documentation for
XenDesktop and its components from
http://support.citrix.com/product/xd/v3.0/#tab-doc/.
This document assumes knowledge of basic Windows server administration, and
knowledge of Active Directory. You can find useful references to Active
Directory documentation at http://www.microsoft.com/windowsserver2003/
technologies/directory/activedirectory/default.mspx/.
Some of the procedures you follow to administer XenDesktop are the same as
those used to administer Citrix XenApp. Most of these procedures are not
repeated in this document; instead, cross-references are made to the Citrix
Presentation Server 4.5 document set, which you can download from http://
support.citrix.com/. You must refer to this version of the XenApp documentation,
rather than later versions, because the functionality in later versions may not
correspond to XenDesktop functionality.
Finding More Information

More information about using XenDesktop is available from the sources listed
below. You can download all the documents from http://support.citrix.com/
product/xd/v3.0/#tab-doc/.
For information on the new features and enhancements in this release,

details of the contents of each edition, and a general overview of
XenDesktop, see the Citrix XenDesktop Overview.
10
The Citrix XenDesktop Readme contains information about last-minute

updates and any known issues. Citrix advises you to read this document
before installing the product.
For step-by-step instructions on how to set up a sample pilot deployment,

see the Citrix XenDesktop Evaluators Guide.
For details of the system requirements (hardware and software) for

XenDesktop, see Citrix XenDesktop System Requirements.
For information about installing and using the Citrix Desktop Receiver (the
Windows 32 client software supplied with XenDesktop), see the Citrix
Desktop Receiver Administrators Guide.
For information about installing and using Citrix User Profile Manager, see
Using Citrix User Profile Manager with XenDesktop.
A document is available for each third-party hosting infrastructure plug-in

supported by XenDesktop.
Getting Support and Training

The Citrix Knowledge Center (http://support.citrix.com/) offers a variety of
technical support services, tools, and developer resources.
Information about Citrix training is available at http://www.citrix.com/edu/.
To get additional support for XenDesktop, visit the XenDesktop Support forum at
http://forums.citrix.com/category.jspa?categoryID=37/. This forum contains upto-date information for Citrix customers and partners. Note that on Citrix forums,
you can set up a forum watch to receive email updates about the latest postings.
Planning Your Deployment
Before you install the various components of XenDesktop you need to plan your
deployment to ensure that it meets all your organizations 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
Described in......
Smart card authentication
Using Smart Cards with XenDesktop on page 37
User-driven desktop restart
To configure user-driven desktop restart on page

92
USB support
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.
12
The essential elements you need to have in place for a working XenDesktop farm
are:
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.
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.
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.
Endpoint devices running the Citrix Desktop Receiver to enable your users
to access desktops.
13
An initial deployment might consist of the following:
This figure shows a single controller configuration of XenDesktop.

Note that this single controller configuration forms a single point of failure for
administration and session brokering.
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.
14
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:
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.
15
You can use XenApp for Virtual Desktops 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 for Virtual Desktops,
see Using XenApp for Virtual Desktops on page 111.
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.
Information on using Citrix Access Gateway, Edgesight for Endpoints,

WANScaler, GoToAssist, and EasyCall is provided in their own productspecific documentation, which you can download from
http://support.citrix.com/.
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:
Active Directorys inbuilt security infrastructure is used by desktops to

check that incoming communications from controllers come from
authorized controllers in the appropriate farm. Active Directorys 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 Microsofts product documentation.
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.
16
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.
Note: Only standard Active Directory objects are created and used by Desktop
Delivery Controller. 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

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.
A Service Connection Point (SCP) object that contains meta-information

about the farm, such as the farms name.
Note: If you use the Active Directory Users and Computers
administrative tool to inspect a farm 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 farms

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
17
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:
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
farms 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 groups access control list (ACL)
Only authorized administrators and the respective controller can

change the information in the controllers SCP
Depending on your Active Directory infrastructure, you should be aware of

replication and its impact on a Desktop Delivery Controller
implementation. Refer to Microsofts documentation to understand the
concepts of replication and associated delays. This is particularly important
if you create the farms 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.
Desktop Delivery Controller uses some of the standard computer object

attributes in Active Directory to manage desktops. Depending on your
setup, the machine objects fully qualified domain name, as stored in the
desktops Active Directory record, can be included as part of the connection
18
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.
Using the Web Interface with Desktop Delivery Controller

Three Web sites are installed on all servers on which you install Desktop Delivery
Controller. These sites are provided through the Citrix Web Interface, which is
also installed automatically. This topic provides details about the additional
options you have in relation to the Web Interface and the default Web sites. To
make best use of the information provided here, you should be familiar with the
Web Interface and have access to the Web Interface documentation.
The default sites are typically created in the following locations when the Web
Interface is installed:
The desktop appliance connector site, for XenDesktop-ready desktop

appliances, 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 connector site, you must edit the configuration
files as described in the Web Interface Administrators Guide.
The other default sites are standard Web Interface sites and you can modify them
through the Access Management Console Web Interface extension. This
extension is not installed as part of a XenDesktop installation. It is provided on
the Desktop Delivery Controller installation media for you to install manually if
necessary.
If you do not want to install the Web Interface and the default sites when you
install XenDesktop, perhaps because you already have Web Interface set up in
your environment, you must carry out the installation through the command line,
using Setup.exe with the -nosites option, as described in Installing and
Removing Controllers Using Setup.exe on page 119.
19
For remote access through Access Gateway, you need to create a new Web
Interface site. To do this, you must install the Web Interface and the Access
Management Console Web Interface extension. Both are available on the Desktop
Delivery Controller installation media:
The Web Interface is at:

\Web Interface\WebInterface.exe
The Web Interface Access Management Console extension is at:

\Administration\Access Management Console\ Setup\
ASC_WebInterface.msi
For information about installing the Web Interface and creating sites, see the Web
Interface Administrators Guide. To modify the user interface of the site to refer
to desktops rather than applications, edit the configuration files as described in
the Web Interface Administrators Guide.
Security Planning
This topic describes:
General security best practices when using XenDesktop, and any securityrelated 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 https://www.citrix.com/security/, or
contact your Citrix representative.
Note: Citrix Secure Gateway is not a component of Citrix XenDesktop.
However, Citrix XenDesktop supports delivering desktops within a deployment
that includes Secure Gateway.
20
Security Best Practices

Keep all computers in your environment up to date with security patches. One
advantage of XenDesktop is that you can use desktop appliances 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
enclave boundaries as appropriate.
If you are migrating a conventional environment to XenDesktop, you may need to
reposition an existing perimeter firewall or add new perimeter firewalls. For
example, suppose there is a perimeter firewall between a conventional client and
database server in the data center. When XenDesktop is used, that perimeter
firewall must instead be placed so that the desktop and endpoint device are on one
side of it, and the database servers and delivery controllers in the data center are
on the other side. You should, therefore, consider creating an enclave within your
data center to contain the servers and controllers used by XenDesktop.
All computers in your environment should be protected by a personal firewall on
the computer. When the Virtual Desktop Agent is installed, it prompts for consent
to adjust the configuration of the Microsoft Windows Firewall to add any
necessary program exceptions or port exceptions so that the Virtual Desktop
Agent will operate correctly. These exceptions are displayed by Windows
Firewall in the usual way. The exceptions are removed if the Virtual Desktop
Agent is uninstalled. If you are using a personal firewall other than Windows
Firewall, you must adjust the firewall configuration manually. For further details
about configuring firewalls, see To configure firewalls manually on page 60.
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
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 endpoint 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 a desktop group; see
Creating and Updating Desktop Groups on page 75. For further information on
SecureICA settings, see the Citrix Presentation Server Administrators Guide.
21
Managing User Privileges

You should grant users only the capabilities they require. Microsoft Windows
privileges continue to be applied to desktops in the usual way: configure
privileges through User Rights Assignment and group memberships through
Group Policy. One advantage of XenDesktop is that it is possible to grant a user
administrative rights to a desktop without also granting physical control over the
computer on which the desktop is stored.
When planning for desktop privileges, note:
By default, when nonprivileged users connect to a desktop, they see the

time zone of the system running the desktop instead of the time zone of
their own endpoint device. For information on how to allow users to see
their local time when using desktops, see Configuring Time Zone
Settings on page 98.
A user who is an administrator on a desktop has full control over that

desktop. If a desktop is a pooled desktop rather than an assigned 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
is equivalent to the security of an ordinary computer: the users of a
computer must trust the administrators of that computer. This consideration
does not apply to assigned 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. Again, this is equivalent to the security of an ordinary computer.
22
Deployment Scenarios
Your user environment can consist of either endpoint devices that are unmanaged
by your organization and completely under the control of the user, or of endpoints
that are managed and administered by your organization. The security
considerations for these two environments are generally different.
Managed Endpoint Devices

Managed endpoint devices are under administrative control; they are either under
your own control, or the control of another organization that you trust. You may
configure and supply endpoints directly to users; alternatively, you may provide
terminals on which a single desktop runs in full-screen-only mode (XenDesktopready desktop appliances). You should follow the guidelines described in
Security Best Practices on page 20 for all managed endpoints. XenDesktop has
the advantage that minimal software is required on an endpoint.
A managed endpoint device can be set up to be used in full-screen-only mode or
in window mode:
If an endpoint 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 an endpoint is configured so that users see their desktop in a window,

users first log on to the endpoint, then log on to XenDesktop through the
XenDesktop Web site supplied with XenDesktop.
Unmanaged Endpoint Devices

Endpoint 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 endpoints, 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 endpoints.
These endpoints should still have basic antivirus protection that will defeat
keylogger and similar input attacks.
Pooled or Assigned Desktops

When using XenDesktop, you can prevent users from storing data on endpoint
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 pooled desktops or assigned desktops:
Users should never store data on pooled desktops.
23
If users store data on an assigned desktop, that data should be removed if

the desktop is later made available to other users. Further advice about this
is provided in To update a desktop group on page 90.
Upgrading from Previous Versions of XenDesktop

You can upgrade from XenDesktop 2.0 or XenDesktop 2.1 to XenDesktop 3.0.
For instructions on how to do this, see Upgrading to XenDesktop 3.0 on page
61.
You cannot upgrade servers running earlier versions of XenDesktop, Desktop
Delivery Controller, or Desktop Server. You must uninstall the old version, then
install Version 3.0.
Citrix does not support mixed farms of servers running more than one version of
XenDesktop. The only exception to this is that support is provided for the period
during which you are upgrading a farm from one version to another.
You cannot upgrade from XenApp to XenDesktop.
After you have installed XenDesktop 3.0 you can import data from earlier
versions of XenDesktop and from Desktop Server 1.0. For information about
importing and exporting data, see Importing and Exporting Desktop and User
Assignment Data on page 87.
24
Planning the User Experience
This section describes how users experience connecting to virtual desktops and
the factors that can affect this experience. Administrators should examine each
factor while planning their deployment.
Read this section in conjunction with the Citrix Desktop Receiver Administrators
Guide, which contains full instructions for installing, configuring, and using the
Desktop Receiver to connect to virtual desktops.
This section includes information about:
The characteristics of your environment that affect the user experience
A set of typical connection scenarios covering most deployments
Your Environment
This topic describes the user types supported by XenDesktop deployments and
aspects of your network that you should consider while planning. Both sets of
characteristics directly affect your configuration decisions and the user
experience when connecting to virtual desktops.
User Types
How users need to access and interact with virtual desktops is an important
consideration. For the purposes of desktop access and interaction, there are two
key user types:
Task workers. These users need access to a single, conventional virtual

desktop to connect to standardized resources with which they perform
repetitive tasks. For example, these users may be call-center workers,
branch workers, or other task-based staff.
Knowledge workers. These users need access to one or more personalized

virtual desktops with the control to perform non-repetitive, complex tasks.
For example, these users may be office workers, software developers, or
traders.
26
Task workers require a user experience that mimics as closely as possible the
familiar interaction with a local desktop and a minimum of new concepts that
they must learn before they access their resources. Virtual desktops presented in
full-screen-only mode are ideal for task workers. In full-screen-only-mode, the
virtual desktop effectively replaces the local desktop, allowing the user to interact
with the virtual desktop as if it is their local desktop.
Full-screen-only mode is also useful for knowledge workers who need access to
just one virtual desktop. If knowledge workers require access to more than one
virtual desktop, or need to be able to switch between their virtual and local
desktops, presenting those desktops in separate windows is a better alternative.
Network Environment
The endpoint features available across all supported environments are broadly
similar. For example, full-screen-only desktops are available from endpoints
running Windows or Linux; virtual desktops running in separate windows can be
used through a local area network (LAN) or remotely; and these features can be
used on a variety of hardware. However, your hardware and software
environment affects the details of how users connect to desktops created with
Desktop Delivery Controller. Factors that you may want to consider include:
Endpoint hardware. Does your organization use XenDesktop-ready

desktop appliances, thin clients, or more powerful endpoint devices?
Operating system.Which of the supported operating systems do your

endpoints run?
Browser availability. Will users have access to a browser?
Endpoint location. Is the endpoint domain-joined? Is the user local or

remote?
The following table summarizes a variety of network environments as a set of

scenarios. For each, the recommended user experience and access point used to
achieve it are given. The recommended access points are Web sites that are
created when you install Desktop Delivery Controller.
Note that the recommended access points do not apply to environments where
users log on using smart cards. For more details, see Using Smart Cards with
XenDesktop on page 37.
Scenario Typical Endpoint

Configurations
Endpoint
Location
Recommended
User Experience
Recommended Use if
Access Point
Appliances and other non- On a LAN

domain-joined endpoints
running Windows XP
Embedded, Windows CE,
or Linux
Full-screen-only
mode
Desktop
appliance
connector
Your existing
hardware does not
support Windows
operating systems or
you have existing
endpoint devices
which you do not
want to include in
your domain.
Domain-joined Windows
XP Embedded or
repurposed Windows XP
Professional endpoints
On a LAN
Full-screen-only
mode
XenDesktop
Services site
You have existing

hardware that can be
re-purposed to
support connections
to virtual desktops or
you want to manage
endpoint devices
using Active
Directory Group
Policy.
All supported Windows

operating systems with a
Web browser; Mac OS X
On a LAN
Citrix Desktop
Receiver window
and toolbar
XenDesktop
Web site
Users in your
environment require
access to more than
one virtual desktop.
All supported Windows

operating systems with a
Web browser; Mac OS X
Remote
through
Access
Gateway
Citrix Desktop
Receiver window
and toolbar
XenDesktop
Web site
Users in your
environment require
access to more than
one virtual desktop.
27
Note that the Citrix Desktop Receiver window and toolbar are not available on
endpoints running Mac OS X. Users connecting to multiple virtual desktops from
endpoints running Mac OS X can use Spaces to display those desktops. Each
virtual desktop is displayed in a separate space and users switch between those
desktops using the Dock. Users can also use Spaces to switch between a virtual
desktop and the local desktop.
Desktop Connection Scenarios

This topic contains a set of typical scenarios designed to help you understand how
users interact with virtual desktops in a number of environments. The end-to-end
experience of connecting to, using, and logging off from a virtual desktop is
described.
In each case, the following prerequisites apply:
28
The appropriate client software must be installed on the endpoint (except

for scenarios involving XenDesktop Web sites, which can prompt the user
to download the software when it is needed)
Virtual desktop groups must be created correctly, using the instructions in

Creating and Updating Desktop Groups on page 75
Note that the scenarios do not contain information about logging on using smart
cards. For more details, see Using Smart Cards with XenDesktop on page 37.
Scenario A: Connecting from an Appliance

This scenario is suited to task workers and knowledge workers who require
access to a single virtual desktop. The desktop is presented to users in full-screenonly mode. Typical hardware for this scenario includes XenDesktop-ready
desktop appliances and non-domain-joined computers.
XenDesktop-ready desktop appliances are devices that, while having limited
functionality compared to computers with a full operating system and set of
applications, are preinstalled with software designed for accessing virtual
desktops created with XenDesktop. XenDesktop-ready desktop appliances run on
Windows XP Embedded, Windows CE, and Linux.
For more information about administering these desktop appliances, consult the
manufacturers documentation. For more general information about XenDesktopready desktop appliances, see http://www.citrix.com/citrixready/.
The user experience in this scenario is as follows. Depending on the appliance
manufacturer and any customization that is performed, the screen appearance
may vary:
1.
The user turns on their local appliance and a connection is established to a

desktop appliance connector (or a load-balanced address) on a server
running Desktop Delivery Controller.
2.
After the startup sequence on the appliance is complete, a Please Wait

screen appears while a customized shell loads.
3.
The Welcome screen appears.
29
This figure shows the logon screen for a full-screen-only desktop accessed from a
XenDesktop-ready desktop appliance running Windows.
4.
The user enters their credentials and logs on. Any errors (for example, if an
incorrect password is entered) appear at the bottom of the logon screen.
5.
A Please Wait screen appears while the virtual desktop starts and a
connection to it is established.
The system keeps the user informed of connection progress at each stage.
6.
If the desktop is taking a long time to appear, the user can restart it by
clicking the Restart button on the Please Wait screen. The desktop restarts
automatically. Note that the Restart button is available only if the
administrator has enabled user-driven desktop restart when creating the
desktop group.
7.
When the virtual desktop becomes available, it appears as a local one

because it is not displayed in a window but instead it automatically fits to
the size of the local monitor. This is the virtual desktop in full-screen-only
mode.
The user can create and save work normally on the virtual desktop, use the
mouse and keyboard in the usual way, and access network resources and
most types of external device. Almost all input is directed to the virtual
desktop. The user never interacts directly with the local desktop except for
a few reserved key combinations (which may vary between operating
systems). For more information about these key combinations in Windows
environments, see the Citrix Desktop Receiver Administrators Guide.
If USB support is enabled, when a user plugs in a USB device it is
automatically remoted to the virtual desktop. The virtual desktop is
responsible for controlling the USB device and displaying it in the user
30
interface. For more details, see Configuring USB Support on page 95 and
the Citrix Desktop Receiver Administrators Guide.
The user is in full control of the virtual desktop, just as if they were using it
locally. The only exceptions that the user may notice are:
Resizing. The user is prevented from resizing the virtual desktop.

This avoids the difficulty of choosing unsuitable screen resolutions,
resulting in distorted images and the appearance of scrollbars (neither
of which would normally occur on the users physical screen). The
user can, however, change other desktop properties such as font size.
Screen locking. For security reasons, on some operating systems the

key combinations that lock the local screen (CTRL+ALT+DELETE
and Windows logo key+L on Windows) are not sent to the virtual
desktop.
8.
If the desktop becomes unresponsive, the user can restart it by pressing

CTRL+ALT+DELETE and clicking Restart. The user enters their
credentials on the Restart screen and clicks OK to restart the desktop. Any
unsaved data is lost during the restart operation. Note that the Restart
button is available only if the administrator has enabled user-driven desktop
restart when creating the desktop group.
9.
When the user completes their work, they log off in the standard way (for
example, from the Start menu on Windows). The shell automatically logs
the user off from the local computer as well as the virtual desktop. This
leaves their monitor displaying the logon screen. In this way, the user
experiences the logoff as a local operation.
Scenario B: Connecting from a Domain-Joined or

Repurposed Computer
This scenario is suited to task workers and knowledge workers in a Microsoft
Windows environment who require access to a single desktop. The desktop is
presented to users in full-screen-only mode. Typical setups for this scenario
include repurposed Windows XP Professional computers or domain-joined
computers running Windows XP Embedded.
Repurposed computers are computers you may have in your existing environment
that can be locked down to provide access only to virtual desktops.
A prerequisite to this scenario is that you must install the Citrix Desktop Receiver
Embedded Edition on the endpoint device.
The user experience in this scenario is as follows:
1.
The user turns on their local computer and after the startup sequence on the
computer is complete, the Log On to Windows dialog box appears.
31
2.
The user enters their domain credentials and logs on. They should not log
on as a local administrator.
3.
A customized shell starts and a connection is established to the XenDesktop

Services site (or a load-balanced address) on a server running Desktop
Delivery Controller.
4.
A Please Wait screen appears while the virtual desktop starts and a
connection to it is established.
The system keeps the user informed of connection progress at each stage.
5.
If the desktop is taking a long time to appear, the user can restart the
desktop by clicking the Restart button on the Please Wait screen. The
desktop restarts automatically. Note that the Restart button is available
only if the administrator has enabled user-driven desktop restart when
creating the desktop group.
6.
When the virtual desktop becomes available, it appears as a local one

because it is not displayed in a window but instead it automatically fits to
the size of the local monitor. This is the virtual desktop in full-screen-only
mode. The user experience is identical to that described in Scenario A.
7.
If the desktop becomes unresponsive, the user can restart the desktop. To
do so, the user logs off in the standard way. When the Log On to Windows
dialog box appears, the user enters their domain credentials and logs back
on. When the Please Wait screen appears, the user clicks the Restart
button to restart the desktop. Any unsaved data is lost during the restart
operation. Note that the Restart button is available only if the administrator
has enabled user-driven desktop restart when creating the desktop group.
8.
When the user completes their work, they log off in the standard way (for
example, using the Start menu on Windows). The shell automatically logs
the user off from the local computer as well as the virtual desktop. This
leaves their monitor displaying the Log On to Windows dialog box.
Scenario C: Connecting from a Fat Client Device

on a LAN
This scenario is suited to knowledge workers in a Microsoft Windows
environment who require access to one or more desktops. Desktops are presented
to users in separate windows, allowing the user to switch between virtual
desktops and the local desktop. Access to more than one desktop mandates the
use of this user interface rather than full-screen-only mode, which can be used
only when access to a single desktop is required. Typical hardware for this
scenario includes fat clients connected to a LAN.
32
Unlike Scenario B, the Citrix Desktop Receiver Embedded Edition does not need
to be installed on the endpoint as a prerequisite. Instead, users can be prompted to
download it when they need it.
1.
The user is already logged on to Windows from their local computer. They
decide to connect to one of their virtual desktops.
2.
The user opens a browser window, and browses (for the first time) to a
XenDesktop Web site (or a load-balanced address) on a server running
Desktop Delivery Controller. For convenience, they bookmarked the site
address that you sent them when they were set up as a XenDesktop user.
3.
A Please Wait screen appears while a connection to the site is established.
4.
The Welcome screen appears.
This figure shows the Web-based logon screen for desktops accessed through a
XenDesktop Web site. Depending on your configuration settings, the user may also have
to select an authentication method on this screen.
5.
Because this is the first time the user is logging on to the site, it
automatically detects that the required client is not present on the endpoint
and prompts the user to download and install the required software.
6.
After the install is complete, the user is presented with a site which contains
a Desktops tab showing the set of desktops to which they have access.
The user can also access virtual applications from this site if any were
published with Citrix XenApp.
33
If desired, administrators can configure the AutoLaunchDesktop setting in

Web Interface to skip this step if the user has been assigned only one
desktop (and no published applications). For instructions on configuring
that setting, see the Web Interface Administrators Guide.
This figure shows the set of desktops available to the user on the XenDesktop Web site.
7.
With the software installed, the user accesses a virtual desktop by clicking
the appropriate icon on the page.
8.
If the desktop is taking a long time to appear, the user can restart it by
clicking the Restart button for that desktop, on the Desktops tab. The
desktop restarts automatically. Note that the Restart button is available
only if the administrator has enabled user-driven desktop restart when
creating the desktop group.
9.
A new window appears. Progress messages appear inside the window

before the desktop is displayed.
34
This figure shows a desktop displayed in a separate window.

10.
The user interacts with the desktop in the usual way and can control its size,
position, and other settings, using the controls on the toolbar. For
instructions about using the controls, see the Citrix Desktop Receiver
Administrators Guide.
This figure shows the controls on the toolbar. Users can customize the desktop using the
buttons or a drop-down menu located next to the Citrix logo on the left.
11.
If USB support is enabled, a list of devices available for remoting to the

virtual desktop is displayed by clicking the USB Preferences button on the
toolbar. The user can customize how and when devices are remoted to the
virtual desktop by clicking the USB Preferences button on the toolbar and
changing the settings in the USB Preferences dialog box.
12.
If the desktop becomes unresponsive, the user can restart it by clicking the
Restart button for that desktop, on the Desktops tab in the browser
window.The desktop restarts automatically and appears in a separate
window. Any unsaved data is lost during the restart operation. Note that the
Restart button is available only if the administrator has enabled userdriven desktop restart when creating the desktop group.
13.
When the user completes their work, they can click the Close button on the
toolbar, which, after prompting the user to confirm, disconnects the virtual
desktop session and returns them to their local desktop. The user can
resume the session later when they want to work on the virtual desktop
35
again. Alternatively, if they want to log off, they can do so from the virtual
desktops Start menu.
Note: Users working with fat client devices may find they can access the
toolbar in other ways depending on how you installed the client: from the
Desktops folder (available by right-clicking the Citrix XenApp icon in the
notification area), or from shortcuts on their local desktop.
Scenario D: Connecting from Remote Computers

This scenario is suited to knowledge workers with any supported Microsoft
Windows operating system who are working remotely, outside your LAN, and
need secure access to virtual desktops that are inside it. Typically, connections
are routed from fat client devices through Citrix Access Gateway and Web
Interface. These two components can be configured in a variety of ways. This
scenario uses one of the standard configurations in which the Web Interface
server is located in the Demilitarized Zone (DMZ).
In this scenario, desktops are always presented to users in separate windows.
1.
The user browses to the external XenDesktop Web site that was secured
using Access Gateway.
This figure shows the Web-based logon screen created for remote access. Depending on
your configuration settings, the user may also have to select an authentication method on
this screen.
36
2.
The user logs on to the site.
3.
The remaining steps are identical to Scenario C. The user selects a desktop
from the Desktops tab on the site and the desktop appears in a new
window.
4.
When the user completes their work, they can click the Close button on the
toolbar, which, after prompting the user to confirm, disconnects the virtual
desktop session and returns them to their local desktop. The user can
resume the session later when they want to work on the virtual desktop
again. Alternatively, if they want to log off, they can do so from the virtual
desktops Start menu.
Using Smart Cards with XenDesktop
Overview
XenDesktop users can use smart cards for:
Authenticating to XenDesktop sessions
Digitally signing or encrypting documents
Authenticating to locally installed or virtualized applications
Virtual desktops must be running Microsoft Windows XP 32-bit with Service

Pack 2 or later.
Smart Card Types and Readers Supported

The following are supported:
Smart cards, including Common Access Card (CAC)
USB smart card tokens
All the above must be Microsoft-compatible.

Only one reader per endpoint is supported, and, for roaming, all readers across
endpoints must be identical.
You must obtain a device driver for the smart card reader and install it on the
endpoint device. Many smart card readers comply with the Chip/Smart Card
Interface Devices (CCID) standard and can use the CCID device driver supplied
by Microsoft.
You must also obtain a device driver (a Cryptographic Service Provider in the
case of Windows) for the smart card and install it on both the endpoint device and
the virtual desktop. Citrix recommends that you:
Install drivers and CSPs on the virtual desktop before installing any Citrix
software on it
38
Install and test the drivers on a physical computer before installing Citrix
software
After the Virtual Desktop Agent has been installed on a computer, you can no
longer use locally connected smart cards for any purpose, including logon.
Smart card support also involves components available from Citrix partners.
These will be updated independently by the partners, and are not described in this
document. Refer to the Citrix Ready program at http://www.citrix.com/ready/ for
more information.
Endpoint Device Requirements

The following types of endpoint support smart card authentication:
Domain-joined and non-domain joined desktop appliances. Desktop

appliances are devices that can connect only to virtual desktops; all other
services are obtained through the virtual desktop. They can support only
one connection at a time.
Domain-joined fat client computers. These are computers that can connect
directly to virtual desktops, applications, and other services. They can run
local applications and support simultaneous connections.
Endpoints must have the following installed:
Microsoft Windows XP or XPe (depending on device type) 32-bit with

Service Pack 2 or 3.
Citrix Desktop Receiver 11.1. For further details about installing the
Desktop Receiver, see the Citrix Desktop Receiver Administrators Guide.
Microsoft Internet Explorer 7, if users need to access desktops from a

browser.
Appropriate device drivers for the smart cards and readers.
XenDesktop-ready desktop appliances may also support smart card

authentication: consult your supplier for further details about this.
Secure Use of Smart Cards

Your organization may have specific security policies concerning the use of smart
cards. These policies may, for example, state how smart cards are issued and how
users should safeguard them. Some aspects of these policies may need to be
reassessed in a XenDesktop environment:
39
Tasks performed by smart card administrators (for example smart card

issuance) may be inappropriate for carrying out through XenDesktop.
Usually these functions are performed at a dedicated smart card station, and
may require two smart card readers.
Infrequent and sensitive tasks, such as unblocking a smart card or resetting

a PIN, may also be inappropriate for carrying out through XenDesktop.
Security policies often forbid users to perform these functions; they are
carried out by the smart card administrator.
Note: Citrix recommends that you carry out these tasks locally on the
endpoint if possible, rather than using XenDesktop.
Highly sensitive applications that require strict separation of duties or

tamper-resistant audit trails may entail additional special-purpose security
control measures. These measures are outside the scope of XenDesktop.
Configuring Smart Card Authentication

To allow users to authenticate with smart cards, you must use the Web Interface to
reconfigure the relevant default Web site provided with XenDesktop, or create
new Web sites, as follows:
You can reconfigure the following default Web sites to incorporate a smart
card authentication method:
The XenDesktop Services site, which is for full-screen-only use with

domain-joined Windows XP and XPe computers.
The XenDesktop Web site, which is for users of fat client devices,
who need to be able to access desktops from a browser.
The desktop appliance connector Web site installed as part of XenDesktop

does not support smart cards. To enable smart card authentication for
desktop appliances you must use XenApp Web sites. For further details, see
http://support.citrix.com/article/CTX119227/.
If you need to support more than one authentication method, Citrix recommends
that you maintain a separate Web site for each method to ensure the best user
authentication experience.
Pass-through authentication with smart cards is supported for domain-joined
computers. For further details, see http://support.citrix.com/article/CTX119227/.
40
For details of where on the installation media to find the Web Interface and the
Web Interface Access Management Console extension, and the locations of the
default Web sites, see Using the Web Interface with Desktop Delivery
Controller on page 18. For information on how to create and configure Web
sites, see the Web Interface Administrators Guide.
Managing Smart Card Use

Keep the following points in mind when managing the use of smart cards in your
organization:
Every time a user logs on with a smart card to a non-domain-joined

Windows XP desktop appliance, the certificate contained on the smart card
is copied from the smart card into the desktop appliances personal
certificate store. All these certificates are displayed when the user attempts
to logon. You should either ensure that the user knows which certificate to
select, or manually delete the certificates from the certificate store.
To use smart cards for digitally signing and encrypting streamed

applications in a XenDesktop session, you must create an Ignore rule in the
relevant profile and add the following named objects to the rule:
\??\Pipe\CtxSmartCardSvc\*
\\.\Pipe\CtxSmartCardSvc\*
You need to create this Ignore rule only for profiles created using
Streaming Profiler 1.2.
For details of creating and updating streaming application profiles, see the
Citrix Application Streaming Guide.
Removing Smart Cards

When the user removes their smart card, the XenDesktop behavior depends on
the smart card removal policy setting on the virtual desktop:
Windows Server 2003 policy
setting
XenDesktop behavior
No action
No action.
Lock workstation
The XenDesktop session is disconnected and the

virtual desktop is locked.
Force logoff
The user is forced to log off. If the network connection

is lost and this setting is enabled, the session may be
logged off and the user may lose data.
Windows Server 2003 policy

setting
XenDesktop behavior
Disconnect if a remote
Terminal Services session
The XenDesktop session is disconnected and the

virtual desktop is locked.
41
There may also be an endpoint smart card removal behavior policy if the endpoint
is domain-joined. In this case the endpoint has the default Windows behavior.
42
Installing XenDesktop
Overview
This section describes how to install the components of XenDesktop, and how the
XenDesktop installation media are structured and organized. It also provides
details of how to upgrade from earlier versions of XenDesktop, how to move to a
different edition, and how to remove XenDesktop.
For a new installation of XenDesktop, Citrix recommends that you carry out the
following tasks in the order shown below. Each task is described in more detail in
subsequent topics.
1.
Licensing.
2.
Creating the farm data store.
3.
Installing Desktop Delivery Controller on a single server and creating a

farm.
4.
Configuring Active Directory.
5.
Adding controllers to your farm.
6.
Installing the management consoles separately, for remote management of

your system.
7.
Starting the Access Management Console and running discovery.
8.
Installing VM infrastructure hosting software such as Citrix XenServer and

XenCenter.
9.
Installing Citrix Provisioning Server for Desktops. Provisioning Server is

available with XenDesktop Advanced, Enterprise, and Platinum editions.
If you install Provisioning Server, you can then install and use the
XenDesktop Setup Wizard.
10.
Installing the Virtual Desktop Agent.
11.
Installing the Citrix Desktop Receiver on endpoint devices.
For installation instructions for User Profile Manager, see Using Citrix User
Profile Manager with XenDesktop.
44
For installation instructions for XenApp for Virtual Desktops, see Before
Installing XenApp in a XenDesktop Environment on page 113, and the Citrix
XenApp Installation Guide, which you can download from
http://support.citrix.com/pages/docs/.
Command-line tools are also available for Desktop Delivery Controller and
Virtual Desktop Agent installation tasks and for configuring Active Directory.
For information on these tools, see Command-Line Tools on page 119.
Important: Citrix supports installation of XenDesktop components only
through the procedures described in Citrix documentation.
When you have installed the necessary components, you can prepare and
provision desktops, create desktop groups, and customize aspects of your
deployment. For more information, see Preparing and Provisioning Desktops
on page 67, Creating and Updating Desktop Groups on page 75, and
Customizing Your Desktop Delivery Controller Environment on page 93.
XenDesktop Installation Media

The installation media and downloads you receive are determined by the edition
you have purchased.
Physical media and downloads
Editions
Medium
Label
Exp/Std Adv
Ent
Plat
DVD
Desktop Delivery Controller
CD
Virtual Machine Infrastructure

powered by Citrix XenServer
CD
Virtual Desktop Provisioning

powered by Citrix Provisioning
Server for Desktops
Download
Citrix User Profile Manager
CD
Integrated App Delivery powered

by Citrix XenApp for Virtual
Desktops for Microsoft Windows
Server 2008
CD

Server 2003
Physical media and downloads
Editions
Medium
Label
Exp/Std Adv
CD
45
Ent
Plat

Server 2003x64
CD
XenApp Components Disc
Subscriptio
n service
GoToAssist
Download
WANScaler Client
Download
EasyCall Agent
Download
Edgesight for Endpoints
Y = Included with this product edition.
Whats on the Installation Media

Use the media listed below to install the various XenDesktop components,
subject to the licenses you have purchased.
Desktop Delivery Controller. Use this disc to install Desktop Delivery

Controller, the Virtual Desktop Agent, the XenDesktop Setup Wizard, the
Citrix Desktop Receiver, and the Client for Macintosh.
Virtual Machine Infrastructure powered by Citrix XenServer. Use this

disc to install XenServer.
Virtual Desktop Provisioning powered by Citrix Provisioning Server

for Desktops. Use this disc to install Provisioning Server. An SQL
database is a prerequisite for installing Provisioning Server, so Microsoft
SQL Server 2005 Express Edition is also provided on this disc. The
XenDesktop Setup Wizard must be installed on the same computer as
Provisioning Server and is available on the Desktop Delivery Controller
Disc.
Integrated App Delivery powered by Citrix XenApp for Virtual

Desktops for Microsoft Windows Server 2008. Use this disc to install
both the 32-bit and 64-bit versions of XenApp for Virtual Desktops for
Microsoft Windows Server 2008.

Desktops for Microsoft Windows Server 2003. Use this disc to install the
32-bit version of XenApp for Virtual Desktops for Microsoft Windows
Server 2003. After installing XenApp, use the XenApp Components Disc
to upgrade to the latest version.
46

Desktops for Microsoft Windows Server 2003x64. Use this disc to install
the 64-bit version of XenApp for Virtual Desktops for Microsoft Windows
Server 2003. After installing XenApp, use the XenApp Components Disc
to upgrade XenApp to the latest version.
XenApp Components Disc. After installing either the 32-bit or 64-bit

version of XenApp for Microsoft Windows Server 2003, use this disc to
upgrade XenApp to the latest version. The Web Interface and the full range
of XenApp plugins can also be installed from the XenApp Components
Disc.
Licensing
After purchasing XenDesktop, you receive two emails with instructions specific
to your license(s).
The following components require the use of a Citrix License Server:
Provisioning Server for Desktops
Access Gateway
EdgeSight
EasyCall
XenApp
Licensing for the remaining components is as follows:
XenServer hosts must be individually licensed (download from My Citrix).
WANScaler is delivered fully licensed for immediate use. This includes the
appliance server license and an unlimited client license.
GoToAssist is a subscription-based service that is activated by the Citrix

Online team. Licensing is based on the number of XenDesktop Platinum
licenses purchased.
For details of User Profile Manager licensing, see Using Citrix User Profile
Manager with XenDesktop.
47
You can either run Citrix Licensing on the server on which you install Desktop
Delivery Controller, or you can run it on a separate server. If your organization
uses other Citrix products, for example, it may be more convenient for you to
download your XenDesktop licenses to the license server that you are already
using. You must configure the license server and install valid licenses before
using XenDesktop. After you point the product to a valid license server, you have
a 96-hour out-of-box grace period to ensure that a valid license is present on the
license server. This grace period allows two concurrent connections.
For details of the editions and licensing options available for XenDesktop, see the
Citrix XenDesktop Overview. For details of how to install and run Citrix
Licensing, see the Getting Started with Citrix Licensing Guide, which you can
download from http://support.citrix.com/pages/licensing/.
If you need to update your license server settings at any stage, see Updating
License Server Settings on page 108.
Creating the Farm Data Store

If you are creating a new farm and plan to use Microsoft SQL Server, SQL Server
2005 Express Edition, or Oracle for the farm data store, you must create the data
store before installing Desktop Delivery Controller.
For more information, see the topics about planning and setting up the farm data
store in the Citrix Presentation Server Administrators Guide.
Installing Desktop Delivery Controller on a Single Server

This topic describes how to install Desktop Delivery Controller on a single server
and how to create a farm. Adding controllers to your farm is described in Adding
Controllers to Your Farm on page 51.
The first server you install in the farm automatically becomes the data collector.
This server manages all user launch requests and all requests to start and stop
desktops. If this server fails, one of the other controllers in the farm takes over
this functionality.
You cannot install Desktop Delivery Controller on a domain controller.
Citrix recommends that Desktop Delivery Controller installation be carried out
by a domain user with local administrator rights. Before you start the installation
process, ensure that you read Using Active Directory with Desktop Delivery
Controller on page 15, and that the necessary Active Directory permissions are
in place.
48
Citrix recommends that you do not install Desktop Delivery Controller through
RDP. If you have to use RDP, use a console session to avoid reconnection issues
if your session becomes disconnected.
If you have created the farm data store on a separate database server, ensure that
you know:
The server name and database name for the data store, because you have to
specify these during the installation process
The user name and password of an account that Desktop Delivery

Controller will use to access the farm data store
Note: The Citrix Web Interface is installed automatically on all servers on

which you install Desktop Delivery Controller. If you do not want to install the
Web Interface you must install Desktop Delivery Controller through the
command line using Setup.exe with the -nosites option, as described in
Installing and Removing Controllers Using Setup.exe on page 119.
To install Desktop Delivery Controller and create a

farm
1.
Insert the Desktop Delivery Controller installation media in the appropriate

drive.
If the Welcome page does not appear automatically, use Windows Explorer
to open Autorun.exe.
2.
On the Welcome page, click Install Server Components.

The End User License Agreement appears.
3.
Select I accept the license agreement, then click Next.

You cannot click Back on this page. To change the installation option you
chose, you must click Cancel, then restart the installation.
4.
On the Select Components page, to install all the components on this

server, leave all the check boxes selected.
If you are running or plan to run Citrix Licensing on a separate server, clear
the Citrix Licensing check box.
Click Next.
5.
On the Create or Join a Farm page, select Create new farm.
6.
Type a name for the farm. Click Next.
7.
On the Specify Farm Edition page, select the XenDesktop edition for
which you have licenses, then click Next.
8.
On the Optional Server Configuration page, you can configure:
49
Using an existing database server. If you have chosen to create a

farm, by default an Access database for the farm data store is created
locally. If you want to use a separate database server instead, select
Use an existing database server.
Licensing. This option appears only if you cleared the Citrix

Licensing check box on the Select Components page. To specify a
separate server for Citrix Licensing, select Configure license server
now.
If you have selected to use a separate database server, you are then
prompted for the details. For more information, see Using a Separate
Database Server on page 50.
If you have selected to use a separate license server, you are then prompted
for the license servers name or IP address and port number.
If you have selected to use both a separate database server and a separate
license server, you are first prompted for the database server details, then
for the license server details.
Click Next.
9.
On the Start Installation page, click Next. A progress indicator page

appears showing you the installation progress for each component.
Note: Near the end of the installation, you may be prompted to restart
your server. To complete the installation, the user who started the
installation must log on to the server. If you are installing from a network
share, you may need to connect to your network share after restarting for
the installation to continue.
When installation is complete, click Next.
10.
On the Setup complete page, ensure that the Configure an Active

Directory OU now check box is selected, then click Finish. Configuring
Active Directory is described on page 50.
If no valid licenses are installed, an option to start the License Management
Console is also provided. If you select this check box, the Licence
Management Console opens in a separate window and you can install
licenses after configuring Active Directory.
50
Configuring Active Directory

Before you can create desktop groups, you need to create and configure the
Active Directory Organizational Unit (OU) for the farm. Citrix provides a wizard
to assist you with this. The wizard is integrated with the Desktop Delivery
Controller installation process, and guides you through the following steps:
1.
On the first page of the Active Directory Configuration Wizard, click Next.
2.
To select an existing OU for this farm, browse to the relevant OU, select it,
then click Next.
To create a new OU for the farm, browse to the OU that you want to be its
parent, select it, then select the Create the farm OU within the OU
selected above check box. You must have CreateChild permissions on the
parent OU to do this. You can create the OU in any domain in the forest
that contains your computers.Type a name for the new OU, then click Next.
3.
The final page of the wizard provides a summary of the configuration you
set up. To change it, click Back. To apply the configuration, click Finish.
The progress and outcome of the configuration is then displayed.
4.
Click Close.
After you install Desktop Delivery Controller, you can also run the wizard from
the Windows Start menu by selecting All Programs > Citrix > Administration
Tools > Active Directory Configuration Wizard.
Alternatively, you can use the command-line tool that corresponds to this wizard.
The tool is described in Configuring Active Directory Using ADSetup on page
122.
Using a Separate Database Server

When installing Desktop Delivery Controller, you can choose to use a separate
database server to host the farm data store.
The connection you configure must be to an existing database to be used as the
farm data store.
To use a separate database server for the farm data store

1.
When the Optional Server Configuration page of the installation wizard

appears, select Use an existing database server.
2.
On the Database Configuration page, select the database server type, then
click Configure.
3.
The dialog boxes that follow are the standard Microsoft user interface for
configuring ODBC settings. Refer to Microsoft documentation for details
about these. When you complete them, you are returned to the Database
51
Configuration page, which displays the name of the database you have
selected for the farm data store.
4.
Click Next.
5.
If you selected Windows NT authentication when you were configuring

ODBC settings, the Database Credentials page appears. Enter the details
of the user account that will be used to manage the databases. Click Next.
If you did not select to use Windows NT authentication, continue to the
next step.
6.
If, on the Optional Server Configuration page, you also chose to use a
separate license server, you are now prompted for the license server details.
Otherwise, the Start Installation page appears, as in Step 9 on page 49, and
the installation continues as normal.
Adding Controllers to Your Farm

After you install your first controller and create a farm, as described in Installing
Desktop Delivery Controller on a Single Server on page 47, you can add
controllers to the farm.
Before you start adding a controller to a farm, ensure that you know the details of
the farm data store, because you have to specify these during installation.
Citrix recommends that Desktop Delivery Controller installation be carried out
by a domain user with local administrator rights. Before you start the installation
process, ensure that you read Using Active Directory with Desktop Delivery
Controller on page 15, and that the necessary Active Directory permissions are
in place.
To add a controller to a farm

1.

drive.
2.
On the Welcome page, click Install Server Components.

3.

4.
On the Select Components page, clear the check boxes for any
components you do not want to install on this server. As a guideline, if
52
licensing and the management consoles are already installed on at least one
other controller in the farm, you do not need to install them again.
5.
On the Create or Join a Farm page, select Join existing farm.
6.
Type the name of any controller that is already in the farm. This must be the
NetBIOS name, not the DNS name; for example, serversc, rather than
serversc.eng.glarox.net.
Click Next.
7.
On the Optional Server Configuration page, you must specify where the
farm data store is.
If the farm data store is on a controller in the farm, leave the check box
cleared.
If the farm data store is on a separate database server, select the check box.
You are prompted for the servers details; make sure you specify the same
database server for all controllers in the farm.
Click Next.
8.

appears that shows you the installation progress for each component.
Note: Near the end of the installation, you may be prompted to restart
your server. To complete the installation, the user who started the
installation must log on to the server. If you are installing from a network
share, you may need to connect to your network share after restarting for
the installation to continue.
9.
On the Setup Complete page, click Finish.
Installing the Management Consoles Separately

You can manage your deployment remotely by installing the Access
Management Console and the Presentation Server Console separately from the
controllers. You must install both consoles on the same computer.
To install the management consoles on a separate

computer
1.

drive.
53
2.
Click Install Optional Components.
3.
On the next page, click Install Management Consoles.

4.

5.
On the Select Components page, ensure that Citrix Management Consoles

is selected, then click Next.
6.

appears that shows you the installation progress for each component. When
installation is complete, click Next.
7.
On the Setup Complete page, if you do not want to start the Access
Management Console, clear the check box.
8.
Click Finish. If you chose to start the Access Management Console, the
console appears and the discovery process starts. For further details about
this, see Starting the Access Management Console on page 53.
You can use the Access Management Console to manage both XenApp and
XenDesktop farms. However, XenDesktop and XenApp cannot use the same
Presentation Server Console (renamed Advanced Configuration in XenApp); you
must use separate consoles for XenApp and for XenDesktop and you must install
these on separate machines. For further information, see Using XenApp for
Virtual Desktops on page 111.
Starting the Access Management Console

To run the Access Management Console, click Start > All Programs > Citrix >
Management Consoles > Access Management Console.
The first time you start the console after installing it, the Configure and Run
Discovery wizard starts automatically. The discovery process checks your Citrix
environment for the addition or removal of objects and devices.
To configure and run discovery

1.
On the Welcome page of the wizard, click Next.
2.
On the Select Products or Components page, click Next.
54
3.
On the Select Controllers page, add the name of one of the controllers in
the farm or click Add Local Computer. Click Next.
4.
On the Preview Discovery page, ensure that the correct information

appears, then click Next.
5.
When discovery is complete, click Finish. The Access Management

Console can now display all the contents of your farm and is ready for you
to begin any XenDesktop management tasks you need to carry out.
Installing VM Infrastructure Software

If you are intending to host your desktops on virtual machines (VMs), then before
creating the VMs you must install the relevant infrastructure software. Citrix
recommends that you use XenServer, which is provided as part of XenDesktop.
XenDesktop also supports Microsoft System Center Virtual Machine Manager
2008 and VMware Infrastructure 3.
When you use XenServer as part of XenDesktop, you are licensed to use it only
for virtualizing desktops and the infrastructure servers used for delivering
desktops. For further details of any limitations that depend on the edition of
XenDesktop you are licensed to use, see the Citrix XenDesktop Overview.
Any computer on which you install XenServer software must have a CPU that
supports hardware virtualization.
To install XenServer
Ensure that you have the XenServer Installation Guide and the XenServer
Administrators Guide available. You can download them from http://
support.citrix.com/pages/docs/.
1.
Install and configure the XenServer host on the dedicated server(s) that will
host the VMs.
2.
Install XenCenter on a Windows computer.
3.
Use the XenCenter management console to connect to a XenServer host

and install your XenEnterprise licenses.
4.
Create a new resource pool and add the XenServer hosts to that resource
pool.
Replacing the Default XenServer SSL Certificate

Citrix recommends using HTTPS to secure communication between Desktop
Delivery Controller and XenServer. To use HTTPS you must replace the default
SSL certificate installed with XenServer with one from a trusted certificate
authority.
55
To replace the default XenServer SSL Certificate

1.
Modify /etc/pki/tls/openssl.cnf as follows:

A.
Request extensions by uncommenting the following line:

req_extensions = v3_req
B.
Modify the section for requested sections to read as follows:

[v3_req]
basicConstraints = CA:FALSE
keyUsage = keyEncipherment
extendedKeyUsage = serverAuth
2.
Generate a certificate request:

openssl genrsa -out [servername].private 2048
openssl req -new -outform PEM -out [servername].request -keyform
PEM -key [servername].private -days 365
where [servername] is the name of the XenServer host.
This generates a request for a 1 year (365 day) certificate in the file called
[servername].request.
3.
Have the certificate request contained in [server name].request signed by a

certificate authority. This can be either a commercial certificate authority or
an internal corporate certificate authority such as Microsoft Certificate
Services.
4.
After the new certificate has been signed, move the existing certificate:
mv /etc /xensource/ xapi -ssl.pem /etc/xensource/xapi -ssl.pem_orig
5.
Add the new signed certificate to the XenServer host and tighten the access
rights:
cat [servername].public [servername].private > [servername].pem
install -m 0400 [servername].pem /etc/xensource/xapi-ssl.pem
6.
Edit the file /etc/init.d/xapissl, using the line:

PEMFILE=/etc/ssl/certs/[servername].pem
7.
Restart the XenServer communications service by entering the following

command:
/etc/init.d/xapissl restart
If you are using a private certificate authority you may need to install your root
certificate on the delivery controller.
56
To install a certificate on the delivery controller

1.
Locate the root certificate file in Windows Explorer.
2.
Right-click the root certificate file and select Install Certificate. The
Certificate Manager Install Wizard appears.
3.
On the Welcome page, click Next.
4.
On the Certificate Store page, select Place all certificates in the

following store.
5.
Click Browse.
6.
Select Show physical stores.
7.
Select Local Computer.
8.
Click OK.
9.
Follow the instructions in the wizard to complete the install.
Installing Citrix Provisioning Server

If you are licensed to use the Advanced, Enterprise, or Platinum editions of
XenDesktop, you can install Provisioning Server and use it to create a single
desktop operating system image (vDisk) that you can stream to multiple desktops
hosted in the VM infrastructure.
Provisioning Server requires a database in which to store configuration
information. Before you install Provisioning Server, ensure that an instance of
Microsoft SQL Server 2005 is available. This can be an existing database on the
network (provided it can communicate with the Provisioning Server VM) or it
can be a fresh installation. Microsoft SQL Server 2005 Express Edition is
provided on the XenDesktop installation media if you need to create a new
database server.
Note: Although it is possible to install the Provisioning Server database on the
same server as Provisioning Server, Citrix does not recommended doing so
because this configuration can cause poor distribution during load balancing.
For instructions on installing and configuring Provisioning Server, see the
Provisioning Server documentation, which you can download from
http://support.citrix.com/pages/docs/. Note the following points when installing
Provisioning Server for use with XenDesktop and the XenDesktop Setup Wizard:
Citrix recommends that you do not install Provisioning Server on a server

that is running Desktop Delivery Controller.
57
If you are intending to use the XenDesktop Setup Wizard, log on as a

domain user to install Provisioning Server.
Although Provisioning Server does not require that you restart the server
after installing the product software, in some instances, a Microsoft
message may appear requesting a restart. If this message appears, complete
the Configuration wizard before restarting the server.
To use Provisioning Server to provision desktops, Citrix recommends that you

configure an appropriate Dynamic Host Configuration Protocol (DHCP) scope
and address range on the domain controller. You should also enable the DHCP
066 Boot Server Host Name and 067 Bootfile Name options. Alternative
configurations are available; for more information, see the Provisioning Server
documentation. For more information about DHCP, refer to the relevant
Microsoft documentation.
Installing the XenDesktop Setup Wizard

The XenDesktop Setup Wizard automates the creation of pooled desktop groups
of virtual machines, and the maintenance of large installations of desktops of this
type. You use it in combination with Provisioning Server, and it is therefore
available only if you are licensed to use the Advanced, Enterprise, and Platinum
editions of XenDesktop.
You must install the Setup Wizard on the server running Provisioning Server.
This server must also have Microsoft .NET Framework 3.5 installed on it. The
XenDesktop installation media includes .NET Framework in the folder
win2k3\en\Support\DotNet35.
To install the Setup Wizard, copy the files SetUp.exe,
XenDesktopSetupWizard.msi, and XenDesktopSetupWizard_64.msi from the
XenDesktop Components installation media to the machine running Provisioning
Server. Run SetUp.exe and follow the steps provided in the installation wizard.
Installing the Virtual Desktop Agent

This topic describes how to install the desktop-side components of XenDesktop,
known collectively as the Virtual Desktop Agent. This set of components consists
of:
The Citrix Desktop Service, which manages communication between the

delivery controller and the desktops. It handles initial brokering of
connections, settings for connections, and interaction with sessions from
the Access Management Console.
58
The Citrix ICA Service, which manages communication between the

endpoint device and the desktop. It handles the remoting of graphics from
the desktop to the endpoint device and the remoting of input from the
endpoint device to the desktop. Several drivers are associated with this
service for handling the remoting of display, keyboard, and mouse.
Supporting services: additional services help with other features such as

auto-reconnection, printing, and encryption.
For the Virtual Desktop Agent to operate correctly, desktops need to determine
which farm they belong to. You can provide this information in either of the
following ways:
By default, when you are installing the Virtual Desktop Agent, the Farm
Selection page appears. Provided you are a domain user and have local
administration rights, you can select the farm here.
You can manage desktops farm membership through Group Policy. The
Desktop Delivery Controller Farm Globally Unique Identifier (GUID)
policy enables you to use a generic desktop image with multiple
XenDesktop deployments. The administrative template (ADM) file is
supplied on the Desktop Delivery Controller installation media:
platform\lang\support\configuration\FarmGUID.adm
If this policy is applied before the Virtual Desktop Agent is installed, the
Farm Selection page does not appear during installation.
For information about how to use ADM files, consult your Active Directory
documentation.
The farm GUID is one of the farm properties displayed in the Access
Management Console.
You can install the Virtual Desktop Agent manually, using the installation
procedure below. Alternatively, you can perform an unattended install, for
example using Active Directory Group Policy or a third party software
deployment tool. See Installing and Removing the Virtual Desktop Agent Using
XdsAgent.msi on page 122 for details on the MSI properties of the Virtual
Desktop Agent package.
If you are using Provisioning Server and the XenDesktop Setup Wizard to create
your desktops, you need to install the Virtual Desktop Agent on the base desktop
image. For further information, see To create a base desktop VM on page 68.
You must create a farm by installing Desktop Delivery Controller on at least one
server before installing the Virtual Desktop Agent on any computer.
59
Note: Microsoft .NET Framework 3.5 is a prerequisite when installing the

Virtual Desktop Agent through Group Policy.
To install the Virtual Desktop Agent

1.
Log on to the computer as a local user with local administration rights. To

select a farm to join, you also need to be a domain user.
2.

drive.
3.
On the Welcome page, click Install Virtual Desktop Components.

If Microsoft .NET Framework 3.5 is not installed, you are prompted to
install it now. You are returned to the Virtual Desktop Agent installer when
the .NET Framework install is complete. If .NET Framework requires a
restart, you have to restart the Virtual Desktop Agent installer after this.
The Citrix Virtual Desktop Agent Setup Wizard starts.
4.
5.
When the End User License Agreement appears, select I accept the license
agreement, then click Next.
6.
On the Port Number page, type a valid TCP/IP port number in the range 1
to 65535 if you do not want to use the default number, which is 8080. This
port number is used by the delivery controllers to communicate with the
desktop.
Important: To change the port number after installation, you must
uninstall then reinstall the Virtual Desktop Agent.
Note: The standard session reliability and ICA ports are used by the
endpoint device to connect to the desktop; you cannot configure these ports
as part of the installation process.
Click Next.
7.
If the computer has a standard Windows firewall set up, the Windows
Firewall Configuration page appears:
60
To configure the required ports automatically, ensure that the

Automatically configure Windows firewall check box is selected,
then click Next.
If you want to configure the firewall yourself, clear the

Automatically configure Windows firewall check box, then click
Next.
If the computer does not have a standard Windows firewall set up, this page
does not appear. If another firewall is enabled, you must configure this
appropriately.
For information about configuring firewalls manually, see To configure
firewalls manually on page 60.
8.
If the Farm Selection page appears, select the farm to contact.

Note: If there is more than one farm with the same name, the GUIDs of
the relevant Active Directory OUs are appended to the duplicate farm
names in the list.
If the farm name is going to be configured later, click Configure the farm
later.
Click Next.
9.
On the Ready to Install page, click Install. A progress indicator page

appears.
10.
When the installation is complete, click Finish. You are prompted to restart
the computer for the configuration changes to take effect.
To configure firewalls manually

To enable users to connect to desktops, you must configure your firewall as
follows:
For communication between endpoint devices and desktops:
%Program Files%\Citrix\ICAService\picaSvc.exe requires inbound TCP

on port 1494. Because this connection uses a kernel driver, you may need to
configure this setting as a port exception rather than a program exception,
depending on your firewall software. If you are running Windows Firewall,
you must configure this setting as a port exception.
%Program Files%\Citrix\ICAService\CitrixCGPServer.exe requires

inbound TCP on port 2598
61
Note: Citrix recommends that you do not use TCP ports 1494 and 2598 for
anything other than ICA and CGP, to avoid the possibility of inadvertently
leaving administrative interfaces open to attack. Ports 1494 and 2598 are
correctly registered with the Internet Assigned Number Authority (see http://
www.iana.org/.
For communication between controllers and desktops:
%Program Files%\Citrix\XenDesktop\WorkstationAgent.exe requires inbound
HTTP (http.sys) on the TCP/IP port you configured at installation time. The
default port is 8080. Because this connection uses a kernel driver, you may need
to configure this setting as a port exception rather than a program exception,
depending on your firewall software. If you are running Windows Firewall, you
must configure this setting as a port exception.
Installing the Citrix Desktop Receiver

For information on the client options available for XenDesktop, see Planning the
User Experience on page 25. For information on how to install the Desktop
Receiver, see the Desktop Receiver Administrators Guide.
Upgrading to XenDesktop 3.0

To upgrade to XenDesktop 3.0 from XenDesktop 2.1 or XenDesktop 2.0:
1.
Upgrade Desktop Delivery Controller and the Virtual Desktop Agent as

described in this topic. Citrix recommends that you upgrade Desktop
Delivery Controller first, then upgrade the Virtual Desktop Agent.
2.
If you installed an earlier version of the XenDesktop Setup Wizard, remove

this as described in To remove the XenDesktop Setup Wizard on page 65,
then install the new version of the Setup Wizard, as described in Installing
the XenDesktop Setup Wizard on page 57.
3.
Upgrade to the Desktop Receiver 11.1 as described in the Citrix Desktop

Receiver Administrators Guide.
4.
If you use XenServer as your hosting infrastructure, Citrix recommends

that you upgrade to XenServer 5.0, which is included with the XenDesktop
installation media. Upgrade instructions are provided in the XenServer
documentation.
5.
If you are licensed to use the Advanced, Enterprise, or Platinum editions of

XenDesktop, Citrix recommends that you upgrade to Provisioning Server
62
5.0, which is included with the XenDesktop installation media. Upgrade

instructions are provided in the Provisioning Server documentation.
To upgrade Desktop Delivery Controller

1.

drive.
2.
On the Welcome page, click Upgrade Server Components.

3.
4.
On the Select Components page, components that are already installed on

this server are selected by default. These will be upgraded automatically.
To install other components, select them.
Click Next.
5.
On the Start Installation page, click Next. A progress indicator page then
appears showing you the installation progress for each component.
6.
On the Setup Complete page, click Finish.
To upgrade the Virtual Desktop Agent

1.
Log on to the computer as a local user with local administration rights.
2.

drive.
3.
On the Welcome page, click Upgrade Virtual Desktop Components.

The Citrix Virtual Desktop Agent Setup Wizard starts.
4.
5.
When the End User License Agreement appears, select I accept the license
agreement, then click Next.
6.
On the Ready to Install page, click Install. A progress indicator page

appears.
7.
When the installation is complete, click Finish. You are prompted to restart
the computer for the configuration changes to take effect.
63
Upgrading to a Different Edition of XenDesktop

To upgrade to a different edition of XenDesktop, use ProductEdition.exe, which
is supplied with the Desktop Delivery Controller installation media in the default
install path C:\Program Files\Citrix\Desktop Delivery Controller.
To display the current edition for the farm, type:
ProductEdition GETEDITION
To change the edition, type:
ProductEdition SETEDITION EDITION=editionString
where editionString can be any of the following:
STD (Standard edition)
ADV (Advanced edition)
ENT (Enterprise edition)
PLT (Platinum edition)
For further information about this utility and examples of how to use it, see http:/
/support.citrix.com/article/CTX118295/.
Removing XenDesktop
This topic describes how to remove Desktop Delivery Controller, the Virtual
Desktop Agent, and the XenDesktop Setup Wizard. For advice on how to remove
other XenDesktop components, see the relevant product documentation.
Citrix recommends that you remove XenDesktop components in the following
order:
1.
Virtual Desktop Agent.
2.
Desktop Delivery Controller.
3.
Provisioning Server.
4.
XenServer.
To remove the Virtual Desktop Agent

1.

drive.
2.
On the Welcome page, click Remove Virtual Desktop Components.
64
3.
On the Welcome page of the Citrix Virtual Desktop Agent Setup Wizard,
click Next.
4.
On the Modify, Repair, or Remove Installation page, click Remove.
5.
On the Remove Citrix Virtual Desktop Agent page, click Next. A

progress indicator appears.
6.
When removal is complete, you are prompted to restart your system.
Removing Desktop Delivery Controller

Components
This topic describes how to remove Desktop Delivery Controller components
through the installation media. You can also remove them through the command
line; for information on how to do this, see Installing and Removing Controllers
Using Setup.exe on page 119.
Note: If a server has the license server or the management consoles installed,
but not Desktop Delivery Controller, you cannot remove these components
through the installation media. Instead, open the Windows Control Panel and use
the Add or Remove Programs option.
To remove all components

1.
Remove the controller entry from the farm OU. To do this, use the
ADSetup command-line tool as described in Configuring Active Directory
Using ADSetup on page 122.
2.

drive.
3.
On the Welcome page, click Remove Server Components.
4.
On the Remove Options page, select to remove all components, then click
Next.
5.
On the Start Removal page, click Next.

A progress indicator page appears. This lists the installed components and
displays progress as each one is removed.
6.
During the removal process you are prompted to restart the computer.
7.
After all components are removed, the Setup Complete page appears. A
list of prerequisite items that were not removed appears. Note any items
that you want to remove manually, then click Finish.
65
Note: To remove a controller that is not available (for example, one that
experienced a hardware fault), run ADSetup on another controller to remove the
unavailable controller from the farm, then remove the controller using the Access
Management Console.
To remove selected components

1.

drive.
2.
On the Welcome page, click Remove Server Components.
3.
On the Remove Options page, select to remove selected components, then

click Next.
4.
The Select Components page appears. The components present on your

controller are listed, with a cleared check box next to each one. To remove
a component, select the relevant check box.
After you select all the components you want to remove, click Next.
5.
On the Start Removal page, click Next.

A progress indicator page appears. This lists the installed components and
displays progress as each one is removed.
6.
During the removal process you are prompted to restart the computer.
7.
After all components are removed, the Setup Complete page appears. A
list of prerequisite items that were not removed is displayed. Note any items
that you want to remove manually, then click Finish.
To remove the XenDesktop Setup Wizard

1.
On the Windows Control Panel Add or Remove Programs page, select

Citrix XenDesktop Setup Wizard, then click Remove.
2.
Confirm that you want to remove the wizard by clicking Yes. A progress
indicator appears.
3.
When removal is complete, you are prompted to restart your system.
66
Preparing and Provisioning

Desktops
Overview
This section is intended for administrators who are delivering desktops through
virtual machines (VMs). It describes how to use XenServer and Provisioning
Server to build a base desktop VM, a vDisk, and a template, which can then be
used by the XenDesktop Setup Wizard to create and populate pooled desktop
groups.
This section assumes that you are using XenServer as your hosting infrastructure.
XenServer is provided on the XenDesktop installation media. XenDesktop also
supports Microsoft SCVMM 2008 and VMware Infrastructure 3. You can
download documents describing how to use third-party hosting infrastructures
with XenDesktop from
http://support.citrix.com/product/xd/v3.0/#tab-doc/. When you use a third-party
hosting infrastructure, Provisioning Server, Desktop Delivery Controller, and the
virtual desktops you create all work in the same way as they would on XenServer.
Certain features, such as XenMotion (dynamic swapping of VMs between
servers), are not available without XenServer.
To use Provisioning Server, you must have licenses for the Advanced, Enterprise,
or Platinum editions of XenDesktop.
This section is not intended to replace the core documentation provided with
XenServer and Provisioning Server. You should have this documentation
available while you are carrying out the tasks described in this section. You can
download the documentation from http://support.citrix.com/pages/docs/.
Note: XenDesktop does not support the use of Provisioning Server Difference
Disk Mode.
68
To enable you to use the XenDesktop Setup Wizard to create desktop groups and
populate them with desktops, as described in To create a VM-based pooled
desktop group using the XenDesktop Setup Wizard on page 76, carry out the
following tasks in the order shown below. Details of the tasks are provided in the
subsequent topics.
1.
Create the base desktop image, using XenCenter. To simplify and reduce
the number of unique desktops, the base image should contain only a
minimal set of options.
2.
Set up the infrastructure to provision the base desktop image, by creating a

vDisk on Provisioning Server.
3.
Add the VM containing the base desktop image to the Provisioning Server
database.
4.
Install a Provisioning Server target device on the base desktop VM.
5.
Image the base desktop VM to the vDisk.
6.
Set the vDisk access mode to Standard. When you create desktop groups
using the XenDesktop Setup Wizard, only Standard vDisks are listed in the
wizard, so you must ensure that this access mode is selected.
7.
Create a template using XenCenter. This template is a diskless VM

template that you associate with a Provisioning Server vDisk when creating
multiple desktops. It provides a guide to how the VMs should be allocated;
for example RAM, CPU, and optimization settings.
Note: If you are using WANScaler (available only with XenDesktop Platinum
edition), you must install the Provisioning Server target device on the base
desktop VM before creating the vDisk.
If you encounter any issues when using Provisioning Server, refer to the
following logs that are on the machine running Provisioning Server:
%ALLUSERSPROFILE%\Citrix\Provisioning Server\mcli.log
%ALLUSERSPROFILE%\Citrix\Provisioning Server\soapserver.log
To create a base desktop VM

1.
In XenCenter, use the New VM wizard to create a VM in the relevant

resource pool, ensuring that Start VM automatically is selected on the
final page of the wizard.
2.
When the VM starts, use your operating system installation media to install
either Windows XP or Vista.
Preparing and Provisioning Desktops
69
3.
When prompted, configure a dynamic IP address so that the base desktop

VM receives its IP address from the DHCP server running on the domain
controller.
4.
Install XenServer Tools into the image to provide optimal performance and
functionality. To install XenServer Tools, select VM > Install XenServer
Tools.
5.
Restart the VM.
6.
Apply any recommended operating system updates to the VM.
7.
Log on to the VM and add it to the Active Directory domain. For more
information about this procedure, see the relevant Microsoft
documentation.
8.
Add the DNS suffix to the VM:

A.
On the VM, open the Windows Internet Protocol (TCP/IP)

Properties dialog box, click Advanced, and select the DNS tab in
the Advanced TCP/IP Settings dialog box.
B.
Type the DNS suffix for the domain and click OK.
C.
Restart the VM and ensure that it is running.
9.
Install the Virtual Desktop Agent on the VM as described in To install the

Virtual Desktop Agent on page 59.
10.
Restart the VM.
11.
Customize the VM to meet your users requirements. For example, if you

have the Enterprise or Platinum editions of XenDesktop, you can install the
XenApp plugins to the base desktop VM to allow users to log on to
XenApp for Virtual Desktops automatically and access virtual applications.
For more information, see Installing the XenApp Plugins on page 115.
You can also pre-cache streamed applications at logon from XenApp to
optimize performance; see Pre-caching Streamed Applications on page
116 for more information.
Note: On the Storage tab in XenCenter, ensure that the optical drive setting for
the VM is set to <empty>. You cannot physically eject a disc from the XenServer
host if the drive is mounted on any VM running on XenServer. If the disc does not
eject, select the XenServer host that contains the disc, click the Console tab and
type eject cd or eject dvd, as necessary.
70
To create a vDisk
1.
In the Provisioning Server Console, right-click the Stores folder and select
Create store.
2.
Select the General tab and specify a name and, optionally, a description for
the new store.
3.
Select the Paths tab and specify the path for the new store. This can be a
local drive on the machine running Provisioning Server or a network share.
4.
Click the Servers tab and select a site from the list. Select the relevant
server under Servers that provide this store and click OK.
5.
In the left pane of the console, right-click the new store you just created and
select Create vDisk.
6.
In the Create vDisk dialog box, specify the requested values and click
Create vDisk.
If you intend to use the XenDesktop Setup Wizard, your vDisk name and
description must contain only standard, printable ANSI characters.
The Vdisk size should match the VM disk size.
7.
Enable Active Directory machine account password management by

editing the properties of the vDisk you have just created.
8.
Enable automatic password management on the server.
9.
In the details pane of the console, right-click the new disk you created and
select Mount vDisk.
A.
On the Provisioning Server machine, open the My Computer folder

(the Computer folder on Windows Vista).
B.
Under Devices with Removable Storage, right-click the entry for

removable disk and select Format.
C.
Format the vDisk as an NTFS disk.

Caution: Format only the removable disk. Do not format any drive
listed in the Hard Disk Drives section.
10.
In the details pane of the Provisioning Server Console, right-click your new
vDisk and select Unmount vDisk.
71
To add the base desktop VM to the Provisioning Server

database
1.
In XenCenter, right-click the base desktop VM and select Edit.
2.
Select the Startup Options tab, move Network to the top of the Boot
Order list, and click OK.
3.
Select the Network tab and make a note of the MAC address for the base
desktop VM.
4.
In Provisioning Server, navigate to the Device Collections folder for the

site, right-click the collection, and select Create Device.
5.
Specify the device name and a description.
6.
Type the MAC address of the base desktop VM and click Add device.
7.
In the left pane of the console, right-click the new device and select
Properties.
8.
Select Hard Disk from the Boot from list.
9.
Select the vDisk tab, click Add, and select the vDisk you created. Click
OK and then click OK again.
To install a target device for the x86 Platform on the base

desktop VM
1.
In XenCenter, restart the base desktop VM.
2.
Insert the Provisioning Server installation media into the optical drive. If
the installation window does not appear, run PVSSRV_Device.exe.
3.
On the product installation window, click Install Target Device for 32 bit
Platform, and follow the instructions provided in the wizard.
When you have completed the wizard, the vDisk is mapped to the base
desktop VM and a vDisk icon appears in the Windows notification area
4.
Double-click the vDisk icon and confirm that the vDisk status is Active.
Note: If the vDisk status is Not Active, it is likely that the target device
cannot resolve the name of the machine running Provisioning Server. To
resolve this issue, check the network settings of the base desktop VM and
the machine running Provisioning Server, then check the DNS server to
ensure that both have been correctly registered.
72
5.
In My Computer, check the label assigned to the new drive (typically, this
is E) and make a note of it.
Note: If you are using WANScaler (available only with XenDesktop Platinum
edition), you must install the Provisioning Server target device on the base
desktop VM before you install the WANScaler client. If you install the
WANScaler client first, the Provisioning Server target device cannot connect to
the vDisk.
To image the base desktop VM to the Provisioning

Server vDisk
1.
On the base desktop VM, click Start > All Programs > Citrix >
Provisioning Server > Provisioning Server Image Builder.
2.
In the Device Image Builder dialog box, click Optimize.
3.
In the Provisioning Server Device Optimization Tool dialog box, ensure

that all the options are selected and click OK.
4.
In the Device Image Builder dialog box, ensure that the destination drive is
set to the letter denoting the new drive (typically E:) and click OK.
The destination drive maps to the vDisk you created.
Note: In the My Computer folder (the Computer folder on Windows
Vista) on BaseDesktop1, the vDisk appears as a disk under Hard Disk
Drives in My Computer, and as a device under Devices with Removable
Storage.
5.
Ensure that the Delete all files and folders in destination path before
building image check box is selected and click Build.
6.
On the Confirm Build details page, click Yes.
7.
When the client image build is complete, click OK.
8.
Click Close.
9.
Shut down the base desktop VM.

Note: You can restart the base desktop VM at any time, for example, to
add new patches or software, and rebuild your vDisk in the same way.
73
To set the vDisk access mode

1.
In the Provisioning Server Console, navigate to the vDisk, select

Properties, and click Edit device properties.
2.
In the vDisk File Properties dialog box, select the Mode tab and, under
Access Mode, select Standard Image. Click OK and then click OK again.
Tip: If the disk is locked, right-click it in the details pane of the console,
select Manage Locks, click Remove Locks, and then click Close.
To create a Provisioning Server VM template

1.
In XenCenter, select New VM.
2.
In the New VM wizard, specify appropriate values for your deployment.

On the Virtual Disks page, do not assign a vDisk to this VM.
3.
On the Finish page, clear the Start VM automatically check box and click
Finish.
4.
In XenCenter, right-click PvS VM Template, select Convert to Template,

and click OK.
Important: The conversion of a VM to a template is a one-way process after

which you can no longer use the template as a VM.
This is the final task in the process of preparing and provisioning desktops. You
are now ready to start the XenDesktop Setup Wizard, as described in To create a
VM-based pooled desktop group using the XenDesktop Setup Wizard on page
76.
74
Creating and Updating Desktop

Groups
Overview
This section describes how to create and update the desktop groups that you want
to deliver to your users. Desktop groups consist of desktops that are pooled, preassigned, or assigned on first use. Each group can contain only one type of
desktop.
Desktops in pooled groups are allocated to users on a per-session, first-comefirst-served basis. You can configure pools of VMs so that any change that the
user makes to the desktop during a session is lost when the user logs off from the
desktop; for information about how to do this, see the documentation for the
relevant VM plug-in.
Desktops in pre-assigned groups are permanently assigned to an individual user
as soon as the group is created. Whenever a user requests a desktop, they are
always connected to the same one. As a result, the user can safely customize the
desktop to suit his or her own needs.
Desktops in assigned-on-first-use groups are permanently assigned to the first
user to connect to them. As with pre-assigned desktops, the user can then safely
customize the desktop.
Desktops can run on PCs, blades, or virtual machines (VMs) provided through a
virtualization infrastructure. The process of creating desktop groups is very
similar in all cases, but for VM-based groups, the following steps and features are
added to the process:
You have to specify the details of the server that hosts the VMs and the
credentials to use when connecting to it.
You can maintain an idle pool of pooled desktops. A defined number of

VMs is kept in a powered-on state ready for users to connect. Other VMs
that are not in use, and not in maintenance mode, are kept powered off.
Maintenance mode is a state you can enable from the Access Management
Console: connections to a desktop are temporarily prevented so that you
76
can carry out maintenance tasks on it. See Putting Desktops into
Maintenance Mode on page 104 for further information.
You can configure what happens to VMs when a user logs off. Depending
on the type of desktop, VMs can be made available immediately to other
users, restarted, shut down, or suspended. You can also configure what
happens if an assigned VM is disconnected.
You can enable users to restart their desktops themselves. They may need to
do this if a desktop fails to connect or becomes unresponsive. This feature
is disabled by default. To enable it, see To configure user-driven desktop
restart on page 92. For details of how users restart their desktops, see the
scenarios described in Planning the User Experience on page 25.
The quickest way to create VM-based pooled desktop groups and populate them
with desktops is to use Provisioning Server in combination with the XenDesktop
Setup Wizard. These components are available in the Advanced, Enterprise, and
Platinum editions of XenDesktop. Alternatively, you can create all types of
desktop group using the Access Management Console. Both methods are
described in this section.
All tasks described in this section are available only to full administrators. For
information about the differences between full and delegated Desktop Delivery
Controller administrators, and how to create administrators, see Delegating
Desktop Delivery Controller Administration Tasks on page 94.
To create a VM-based pooled desktop group using the

XenDesktop Setup Wizard
The instructions in this topic assume that you have already installed Provisioning
Server and the Setup Wizard, created a VM template, and created a Provisioning
Server virtual disk (vDisk).
1.
If you are logged on to an account that does not have full domain
administrator access rights, ensure that you meet the following
requirements:
Local administrator rights on the server hosting Provisioning Server.
Account operator permissions in Active Directory.
Full access permissions for the computers OU and child objects in

Active Directory. Alternatively, full control permissions for any
custom OU used in place of the default OU.
Full administrator rights to Desktop Delivery Controller. For more

information, see Creating Administrators on page 94.
Creating and Updating Desktop Groups
77
Membership of the local Distributed COM Users group on every

delivery controller in the farm.
2.
If your hosting infrastructure is VMware, ensure that you have permission

to clone VMs.
3.
On the machine on which you are running Provisioning Server and the
Setup Wizard, select Start > All Programs > Citrix > Administration
Tools > XenDesktop Setup Wizard.
4.
On the Welcome to XenDesktop Setup Wizard page, click Next.
5.
On the Farm page, select the relevant farm name from the list, then click
Next.
6.
On the Hosting Infrastructure page, select the hosting infrastructure you

are using, type the IP address or URL of the server on which it is running,
then click Next.
7.
Specify the user credentials for the hosting infrastructure, then click OK.
8.
On the Virtual Machine Template page, select the VM that you want to
use as a template for the desktops you are going to create.
If your hosting infrastructure is XenServer and you are using multiple
pools, only templates that have the same name in every pool are listed. For
more details of using multiple pools, see Using More than One XenServer
Pool on page 81.
If your hosting infrastructure is Microsoft SCVMM 2008, running and
stopped VMs are listed, not templates.
Click Next.
9.
On the Virtual Disk (vDisk) page, select the vDisk from which to create
your desktops. Only Standard mode vDisks are listed.
If you select to specify a target device collection, you are given the option
of creating a new collection and specifying a name for it. This name can be
up to 50 characters in length. If you choose not to specify a name, the
desktop group name you specify on the Desktop Group page will be used
for the collection name. If, however, the desktop group name is more than
50 characters, the collection will be named XenDesktop.
The list of existing device collections contains only the device collections
that belong to the same site as the vDisk you selected.
Click Next.
10.
On the Virtual Desktops page:

A.
Type the number of desktops to create.
78
B.
Type the common name to use for all the desktops. This must be less
than 16 characters long, including the index digits. It must be a valid
Active Directory name and a valid Provisioning Server device name.
C.
Type the start number for the identifying numbers for the desktops.
D.
Click Next.
11.
On the Organizational Unit Location page, select the OU to which the

desktops will be added. Click Next.
12.
On the Desktop Group page, specify the group to which to add the
desktops. You can either create a new group or select an existing one.
If you select to use an existing desktop group, only pooled desktop groups
for the hosting infrastructure and connection address you specified on the
Hosting Infrastructure page are listed. For example, if you created a
desktop group in the Access Management Console using an IP address, but
in the Setup Wizard you specify the connection using an FQDN, that group
is not listed.
New groups are enabled by default, so that users have immediate access to
them. To create a disabled group, clear the Allow immediate access
(enable desktop group) check box. You can enable the group later by
updating its properties using the Access Management Console, as described
in To update a desktop group on page 90.
Click Next.
13.
On the Desktop Group Creation page, ensure that the details for your
desktops are correct, then click Next to create the desktops.
14.
When the Summary page appears, check the results, then click Finish.
During the desktop creation process, if some desktops fail to be created, all the
other desktops are created successfully; the overall process does not fail. If no
desktops are created, the desktop group is not created.
If the desktop group was created, the desktops are added to the domain; they
appear under the Computers container in the relevant Active Directory OU and
are visible in both the hosting infrastructure console and as devices in the
Provisioning Server Console. The desktop group appears in the Access
Management Console.
The idle pool settings are automatically optimized for the number of desktops you
created. To modify the settings, use the Modify desktop group properties task.
79
To enable logging on the XenDesktop Setup

Wizard
To help troubleshoot problems in the Setup Wizard, you can enable logging as
follows:
1.
Navigate to the installation location for the Setup Wizard, typically

C:\Program Files\Citrix\XenDesktop Setup Wizard\, and open the file
SetupToolApplication.exe.config using a text editor.
2.
In the AppSettings section, uncomment the following line and add suitable
values:
<add key=logFileName value=c:\logs\log.txt/>
where c:\logs\log.txt is the name and location of the log file.
To enable Pool Management logging

To troubleshoot issues when using the XenDesktop Setup Wizard to create the
desktop group, enable Pool Management logging:
1.
On the delivery controller, stop the Pool Management Service.
2.
Ensure the logs directory has been created in c:\.
3.
In Program Files\Citrix\VmManagement\CdsPoolMgr.exe.config, in the

appSettings node, add the line:
<add key=LogFileName value=c:\logs\poolMgr.log/>
4.
Restart the Pool Management Service.
To create a VM-based desktop group using the Access

Management Console
1.
Ensure that you are logged on to an account with full Desktop Delivery
Controller administrator permissions.
2.
In the Access Management Console tree, select Desktop Groups.
3.
From Common Tasks, select Create desktop group.

The Create Desktop Group Wizard guides you through the process of
creating a desktop group.
4.
5.
On the Assignment Type page, select the type of desktops this group will
consist of: pooled or assigned. If you select assigned, you must then select
80
whether the desktops will be assigned on first use or pre-assigned to a

specific user. Click Next.
Note: You cannot change the assignment type of a group after you create
it.
6.
On the Hosting Infrastructure page, select the hosting infrastructure for

your desktops. Click Next.
Note: There is a document for each third-party hosting infrastructure
plug-in supported by XenDesktop. You can download these documents
from http://support.citrix.com/product/xd/v3.0/#tab-doc/.
7.
On the Logon Information page, specify the address and user credentials
for logging on to the server in your hosting infrastructure. Click Next.
8.
The page that appears depends on the desktop groups assignment type.
For pooled or assign-on-first-use desktop groups, the Virtual Desktops
page appears, prompting you to select the VMs whose desktops will be
delivered to your users. For pre-assigned groups, the Virtual Desktops and
Users page appears, prompting you to both select VMs and assign users to
them.
You can add information by:
Selecting VMs from the hosting infrastructure. To do this, click Add

and select VMs from the list that appears. Where possible, the system
then maps VM names to Active Directory computer accounts. If this
is not possible, you must add the Active Directory computer account
yourself. To do this, select the relevant line, click Edit, then from the
Active Directory browser, select the correct account.
Importing data from a file. For further details of importing data, see
To import data from a file on page 88.
If you do not select any VMs or users, the desktop group is disabled.
9.
For pooled and assign-on-first-use desktop groups, the Users page then
appears. Add the user groups that will have access to this desktop group,
then click Next. If you do not select any user groups, the desktop group is
disabled.
For pre-assigned desktop groups, the wizard continues at the next step.
10.
On the Desktop Group Name page, type the name and, optionally, a
description that you want to be displayed to users of this group. Click Next.
81
11.
On the Icon page, the current icon for this desktop group appears. If you
want users to see a different icon, click Change Icon and select a new icon.
Click Next.
12.
On the Publishing Options page, if you do not want the desktop group to
be available to users immediately, select the Disable desktop group
initially check box. You can enable it later by updating the desktop groups
property page; the relevant check box is on the Desktop Group Name
page.
13.
To view and select advanced options, select the Configure advanced

desktop settings now check box. You can also modify the advanced
settings using the desktop group properties described in the following
topics:
Configuring Access Control on page 83.
Setting Up an Idle Pool on page 84.
Configuring Logoff Behavior on page 85.
Specifying Client Options on page 86.
Using More than One XenServer Pool

If you are using XenServer and you create a desktop group containing a large
number of desktops, you may need to use more than one XenServer pool to host
the VMs. A tool is provided with XenDesktop that allows several XenServer
pools to be used by one desktop group. This tool is installed at:
%ProgramFiles%\Citrix\VmManagement\XenMultiPool.exe.
Note: All XenServer hosts must have the same user name and password to
configure them for use with one desktop group.
To create multiple pools

1.
Run XenMultiPool.exe.
2.
On the XenServer Connection Details page, enter the details of the

XenServer pool master you specified on the Logon Information page of
the Create Desktop Group Wizard.
3.
On the Citrix XenServer Pool Configuration page, click Add.
4.
Add the address of the new XenServer host and click Add host.
82
5.
Repeat Steps 3 and 4 until all the required XenServer hosts have been
added.
6.
Click Update.
To create a PC- or blade-based desktop group

1.
Ensure that you are logged on to an account with full administrator

permissions.
2.
In the console tree, select Desktop Groups.
3.
From Common Tasks, select Create desktop group.

The Create Desktop Group Wizard guides you through the process of
creating a desktop group.
4.
5.
On the Assignment Type page, select the type of desktops this group will
consist of: pooled or assigned. If you select assigned, you must then select
whether the desktops will be assigned on first use or pre-assigned to a
specific user. Click Next.
Note: You cannot change the assignment type of a group after you create
it.
6.
On the Hosting Infrastructure page, select None, then click Next.
7.
The page that appears depends on the desktop groups assignment type.
For pooled or assign-on-first-use desktop groups, the Virtual Desktops
page appears. You can select the computers that will provide the desktops
for the group either by clicking Add and using the Active Directory object
picker, or by importing data from a file. For further details of importing
data, see To import data from a file on page 88.
For pre-assigned desktop groups, the Virtual Desktops and Users page
appears. You can select both computers and the users to assign to them
either through the Active Directory object picker or by importing data from
a file as above.
If you do not select any computers or users, the desktop group is disabled.
8.
For pooled and assign-on-first-use desktop groups, the Users page appears.
Add the users that will have access to this desktop group, then click Next. If
you do not select any users, the desktop group is disabled.
For pre-assigned desktop groups, the wizard continues at the next step.
83
9.
On the Desktop Group Name page, type the name and, optionally, a
description that you want to be displayed to users of this group. Click Next.
10.
On the Icon page, the current icon for this desktop group appears. If you
want users to see a different icon, click Change Icon and select a new icon.
Click Next.
11.
On the Publishing Options page, if you do not want the desktop group to
be available to users immediately, select the Disable desktop group
initially check box. You can enable it later by updating the desktop groups
property page; the relevant check box is on the Desktop Group Name
page.
12.
To view and select advanced options, select the Configure advanced

desktop settings now check box. You can also modify the advanced
settings using the desktop group properties described in the following
topics:
Configuring Access Control on page 83.
Specifying Client Options on page 86.
Configuring Advanced Settings for Desktop Groups

You can configure advanced settings such as access control, idle pool settings,
logoff behavior, and client options using the Advanced Settings pages of the
Create Desktop Group Wizard.
Configuring Access Control

If Access Gateway Advanced Edition is installed as part of your environment, use
the Access Control page of the Create Desktop Group Wizard to specify the types
of connections that can be used to access desktops. By default, all connections
made through the Access Gateway Advanced Edition are allowed.
To configure access controlled by Access Gateway

1.
To access desktops using connections made through Access Gateway

Advanced Edition, select the Allow connections made through Access
Gateway Advanced Edition (version 4.0 or later) check box. Go to Step
3.
2.
To access desktops using connections other than those made through

Access Gateway Advanced Edition, select the Allow all other connections
check box.
3.
If you selected Allow connections made through Access Gateway

Advanced Edition (version 4.0 or later), choose one of the following:
84
To restrict allowed connections to those that meet the criteria of

specified filters, select Any connection that meets any of the
following filters.
To allow all connections, select Any connection.
Note: XenDesktop does not automatically check the validity of Access

Gateway farm and filter names, so always verify the names with the Access
Gateway administrator.
Setting Up an Idle Pool

You can use the Idle Pool Settings page of the Create Desktop Group Wizard to
configure how many idle desktops you want in your pool at certain times of the
day. You can also configure a peak period to cover the time at which most users
will be logging on to their desktops. This period starts at the beginning of your
business day.
The desktops in this pool are kept in a powered-on state, ready for users to
connect. When a user logs on, they are immediately presented with a desktop.
You can modify idle pool settings after creating a desktop group, using the
Modify desktop group properties task.
Note: This page is available only for VM-based desktop groups.
If you used the XenDesktop Setup Wizard to create desktops, the idle pool
settings are automatically optimized for the number of desktops you created. To
modify the settings, use the Modify desktop group properties task.
To set up an idle pool

1.
Select your normal business days.
2.
Select your time zone from the Time zone list.
3.
Enter a start and end time for your normal business hours in the Start time
and End time boxes.
4.
Enter a time period to cover the peak period for users logging on, in hours,
in the Peak period box. This peak period starts at the time you specify in
the Start time box.
5.
Enter the number of idle desktops you want available during business
hours, in the Business hours box.
6.
Enter the number of idle desktops you want available during your peak
period, in the Peak time box.
7.
85
Enter the number of idle desktops you want available out of business hours,
in the Out of hours box.
To keep the same number of desktops in the pool at all times, enter the same time
in both the Start time and End time boxes or an identical value for the number of
desktops to keep in the idle pool in the Business hours, Peak time, and Out of
hours boxes.
Configuring Logoff Behavior

You can configure what happens to a desktop when a user logs off, using the
Logoff Behavior page of the Create Desktop Group Wizard. For assigned
desktops, you can also configure what happens if a session is disconnected.
For pooled desktops, by default, the desktop becomes available to other users as
soon as the current user logs off. Any change made to the system by the most
recent user is retained, so this option is usually appropriate only for desktops that
users cannot customize. Alternatively, you can choose to restart the desktop
before making it available to other users.
For assigned desktops, by default, when the user logs off, the desktop is left
powered-on and ready for the user to reconnect to. Alternatively, you can suspend
the desktop until the next time the user tries to reconnect to it or shut down the
desktop and restart it the next time the user tries to reconnect to it. If you specify
that an assigned desktop should be suspended or shut down when the user logs
off, you can also choose to suspend the desktop if the session is disconnected. By
default, the desktop is left powered-on if the session is disconnected.
You can modify logoff behavior settings after creating a desktop group, using the
Modify desktop group properties task.
Note: These settings are available only for VM-based desktop groups.
To configure logoff behavior for pooled desktops

1.
If you want to stop and restart the desktop before making it available to
other users, select Restart the virtual desktop.
2.
If you want to make the desktop available to other users immediately, select
Do nothing.
To configure logoff behavior for assigned desktops

1.
If you want to leave the desktop powered on and ready for the user to
reconnect, select Leave powered on.
2.
If you want to suspend the desktop until the next time the user connects,
select Suspend.
86
3.
If you want to shutdown the desktop and restart it the next time the user
connects. select Shut down.
4.
If you selected Suspend or Shut down as the logoff behavior and you want
to suspend the desktop when a session disconnects, select the Suspend
virtual desktop when session disconnects check box.
Note: There is a five minute grace period following user logoff before the
desktop goes into suspended mode or shuts down.
Specifying Client Options

You can use the Clients page of the Create Desktop Group Wizard to specify the
level of encryption you want a client to use when connecting to desktops in a
group. You can also set the color depth used by desktops in a group.
To specify client options

1.
Set the color depth for desktops in the group. Choose from 16 colors, 256
colors, High Color (16-bit), or True Color (24- bit). True color (24-bit) is
the default and maximum supported color depth.
2.
Set the encryption level for client connections. Choose from the following,
but note that the first four options have been deprecated and Citrix
recommends that you do not use them:
Basic. Encrypts the ICA connection using a non-RC5 algorithm. It

protects the data stream from being read directly, but is susceptible to
decryption.
128-Bit Login Only (RC5). Encrypts the logon data with RC5 128bit encryption and the ICA connection using basic encryption.
40-Bit (RC5). Encrypts the ICA connection with RC5 40-bit

encryption.

encryption.

encryption. This is the default.
87
Importing and Exporting Desktop and User Assignment

Data
You can assign desktops and users by importing data from a file. This file can
contain data from any previous version of XenDesktop or from Desktop Server
1.0. You can also export desktop and user assignment data to a file. These files
must have the following characteristics:
They must be .csv files.
The first line in the file must contain the column headings, which can be:
[ADComputerAccount],[AssignedUser],[VirtualMachine],[HostId] for a
XenDesktop file
or
[WorkstationName],[IsWorkstationEnabled],[Pre-AllocatedUser] for a file
exported from Desktop Server 1.0
The column headings can be in any order, but they must be commaseparated.
The subsequent lines contain the appropriate data, also comma-separated:
The ADComputerAccount entries (or workstation names, for

Desktop Server 1.0) can be any of the following:
Common names (for example computer01)
IP addresses (for example 10.50.10.80)
Distinguished names (for example

computer01.mydomain.com)
Domain and computer name pairs (for example

mydomain\computer01)
The contents of the IsWorkStationEnabled column are ignored. This

column contains data if the file is created by exporting data from
Desktop Server 1.0, but this data is not used by XenDesktop.
The AssignedUser column entries (or Pre-AllocatedUser column, for

Desktop Server 1.0) can be any of the following:
Common names (for example user01)
Distinguished names (for example user01.mydomain.com)
Domain and user name pair (for example mydomain\user01)
88
The VirtualMachine and HostId columns are required only for data
about VM-based groups.
You can find sample files on the XenDesktop installation media in

\support\ImportExport.
Note: Desktop Server 1.0 data can be used only to update PC- or blade-based
desktop groups.
To export data to a file

1.

permissions.
2.
Expand the Desktop Groups node in the console tree and select the
relevant desktop.
3.
From Common Tasks, select Modify desktop group properties > Modify
all properties.
The Properties page for the desktop group appears. From the list of
properties in the details pane, select Virtual Desktops for a pooled or
assign-on-first-use desktop, or Virtual Desktops and Users for a preassigned desktop.
4.
Click Export to File.
5.
Specify the path to which you want to save the file, then click Save.
To import data from a file

The instructions below describe how to import data into an existing desktop
group. For information about how to import data when you are creating a desktop
group, see Step 8 of To create a VM-based desktop group using the Access
Management Console on page 79, or Step 7 of To create a PC- or blade-based
desktop group on page 82.
1.

permissions.
2.
relevant desktop.
3.
all properties.
The Properties page for the desktop group appears. From the list of
properties in the details pane, select Virtual Desktops for a pooled or
89
assign-on-first-use desktop, or Virtual Desktops and Users for a preassigned desktop.

4.
Click Import from File.
5.
Browse to the file you want to import, then click Open.

If there is more than one entry with the same desktop name or host name,
only the first entry is loaded. If the import file contains entries that are
already in the desktop list for this group, the listed desktops are overwritten
with the data from the file.
6.
To import all the data from the file, click OK.
Updating Desktop Groups

After you create a desktop group, you can update it in the following ways:
Update its name and description
Disable or enable the desktop group, and hide disabled desktop groups from
users
Add or remove associated desktops
Update user assignment for desktops associated with a pre-assigned

desktop group
Add or remove users for a pooled or assign-on-first-use desktop group
Update the icon for the desktop group that is displayed to the user
Update the advanced settings, which are as follows:
Access control settings
Color depth
Client encryption setting
Allow users to restart the desktops in this group themselves.
Delete the desktop group
Additionally, for VM-based groups, you can update the hosting server connection
details, the idle pool settings, and the logoff behavior.
You cannot update:
The user assignment type
The hosting system infrastructure
90
To update a desktop group

1.

permissions.
2.
relevant group.
3.
all properties.
The Properties page for the desktop appears. From the list of properties in
the details pane, select as follows.
Update
Property to select
Name of the desktop group Desktop Group Name
If you have set up Citrix policies that filter by desktop

group name, you must update the policy details with
the new name.
Enable/disable the desktop Desktop Group Name
group
If you disable the desktop group and want to prevent

it from appearing in users lists of desktops, select the
Hide disabled desktop check box.
If you are using the idle pool settings to manage
desktops, note that if a group is disabled, the idle
count of its desktops is still managed. To manually
control desktops, put them into maintenance mode as
described in Putting Desktops into Maintenance
Mode on page 104.
Add/remove desktops
Virtual Desktops (for pooled and assign-on-first-use

groups) or Virtual Desktops and Users (for pre-assigned
groups)
If you remove a desktop that is assigned to a user, it

may contain personal data. You need to manage this
appropriately if the desktop is likely to be assigned to
another user (for example, by reimaging it).
Citrix recommends that you add or remove desktops
only while they are either idle or shut down.
To temporarily stop users from connecting to a
desktop without removing it from the group, put the
desktop into maintenance mode as described in
Putting Desktops into Maintenance Mode on page
104.
Update
Property to select
Add/remove users for a

pooled or assign-on-firstuse desktop group
Users
91
If you remove users that are assigned to desktops, be

aware that if these users saved data to their desktops,
you need to manage this appropriately before making
the desktops available to other users (for example, by
reimaging them).
If a user is assigned to a desktop in an assign-on-firstuse group, removing the user from the group does not
stop them from being able to access their desktop. To
do this, select the desktop in the Virtual Desktops
view, then from the Tasks list, select Remove
assigned user.
Add/remove users for a

Virtual Desktops and Users
pre-assigned desktop group
When you remove users (by clicking Unassign), this

only removes the users assignment to the desktop; it
does not change the data stored on the desktop itself.
If a user has saved data to that desktop, you need to
manage this appropriately before reassigning the
desktop to another user (for example, by reimaging
it).
Icon for the desktop group Icon

Access control settings
Access Control
Color depth
Client Options
Client encryption setting
Client Options
Connection settings for

VM hosting servers
Connection Settings
Idle pool settings for VMs
Idle Pool Settings
If there are a large number of VMs (~1000) in the

group, the Access Management Console may pause if
you change the idle count. The delay depends on the
number of VMs and may last for a minute or longer.
Logoff behavior for VMs
Logoff Behavior
Disconnection behavior for Logoff Behavior

assigned VMs
92
To configure user-driven desktop restart

You can configure desktop groups to allow users to restart their own desktops
locally if they fail to start or take too long to connect. Note that user-driven
desktop restart may result in loss of data. Ensure that all users who have access to
this option are aware that their work is not saved if they select to restart their
desktop.
1.
In the Access Management Console tree, select the group for which you
want to configure user-driven desktop restart. This option is available only
for VM-based desktop groups.
2.
From Common Tasks, select Enable user-driven desktop restart. If userdriven desktop restart is currently enabled, the Disable user-driven
desktop restart task appears instead.
To delete a desktop group

1.
In the console tree, select the group you want to delete.
2.
From Common Tasks, select Delete desktop group.
When you delete a desktop group, all the desktops are removed from the group.
The desktops themselves are not deleted, and no data stored on them is deleted
automatically: ensure that you manage this data appropriately before making the
desktops available to other users. If users were assigned to the desktops, the links
between the users and the desktops are deleted.
Customizing Your Desktop Delivery

Controller Environment
Overview
After completing the initial setup tasks, you can customize and optimize your
Desktop Delivery Controller deployment:
Create additional administrators for the farm, if necessary. See Creating

Administrators on page 94 for details.
Set up any general Citrix policies that you require, using the Presentation
Server Console. See the Citrix Presentation Server Administrators Guide
for details of configuring policies. Note the following points in relation to
XenDesktop:
You can set up policies that filter on desktop group name. If you
rename the desktop group, you must update the policy with the new
name.
You cannot filter polices on server name.
Configure USB support. See Configuring USB Support on page 95.
Optimize the user experience by ensuring that settings for desktops and
users are appropriate. See Optimizing the User Experience on page 98.
Set up printers, using the Presentation Server Console. See the Citrix
Presentation Server Administrators Guide for details of setting up and
managing printers. In XenDesktop, the following XenApp printer
management features are not available:
Driver replication, compatibility, and mapping
Support for legacy Windows CE and DOS clients that cannot

correctly report which printers are attached to the endpoint device
Control of the total bandwidth limit of all printing connections to a

particular controller
94
Note: Citrix policy rules and features that are specific to XenDesktop are
documented in this document. They are not documented in the Help system for
the Presentation Server Console.
Creating Administrators
To manage your Desktop Delivery Controller environment efficiently, you may
need to create additional administrators. You may also need to delegate Active
Directory permissions to these administrators.
Delegating Active Directory Access Control

Active Directory is used to store information about the controllers in a farm. To
add or remove controllers, administrators need certain Active Directory rights.
For further information about this, see Using Active Directory with Desktop
Delivery Controller on page 15.
Delegating Desktop Delivery Controller

Administration Tasks
When you install Desktop Delivery Controller, the account you use to log on is
automatically granted full administration rights, with authority to manage and
administer all areas of Desktop Delivery Controller farm management. Using this
account, you can then start the Access Management Console and create further
full or delegated administrators.
Delegated administrators can view all information in the Desktop Delivery
Controller extension of the console and they can also:
Send messages to users
Disconnect users
Log off users
Put desktops into maintenance mode and remove them from maintenance
mode
Start, stop, suspend, and resume virtual machines
Delegated administrators cannot:
Create, modify, or delete desktop groups
Add, modify, or delete administrators
Customizing Your Desktop Delivery Controller Environment
95
Administrators who will run the Access Management Console remotely must
have DCOM remote launch permissions. For information about this, see
http://support.citrix.com/article/CTX109977/.
To create a new Desktop Delivery Controller administrator

1.
In the left pane of the Access Management Console, under the farm, select
the Administrators node.
2.
From the Action menu, select Add administrator.
3.
On the Select Users page, click Add.
4.
Click OK to add the user as an administrator.

Use the Active Directory object picker to select your user or group. Note
that:
You can only browse account authorities and select users and groups
that are accessible from the computer running the Access
Management Console.
You should not select users and groups outside the trust intersection
of the farm. If you do this, errors will occur.
5.
Continue selecting the administrators you want to add, then click OK.
6.
Click Next.
7.
On the Privileges page, choose one of the following options:
8.
Select Delegated Administration to delegate specific, limited tasks

to the selected administrators.
Select Full Administration to give the selected administrators full

access to all areas of farm management.
Click Finish.
Configuring USB Support

You can enable users to interact with a wide range of USB devices during a
XenDesktop session. USB support is available on endpoints running the Desktop
Receiver 11.1 or later, or the Client for Linux 11.0 or later.
By default, certain types of USB device are not supported for remoting through
XenDesktop. For example, a user may have a network interface card attached to
the system board by internal USB. Remoting this would not be appropriate. The
following types of USB device are not supported by default for use in a
XenDesktop session:
Keyboards
96
Mice
Bluetooth dongles
Integrated network interface cards
Smart cards
USB hubs
For more detailed information about the devices included in each class or type of
device and whether or not USB support is provided for them, see the relevant
client documentation.
Note: Isochronous features in USB devices are not supported.
To configure USB support
Enable the USB policy rule, which is located in the USB subfolder of the
Client Devices Resources folder in the Presentation Server Console.
Enable USB support when you install the client on endpoint devices. For
information about how to do this, see the Citrix Desktop Receiver
Administrators Guide or the Client for Linux Administrators Guide.
If necessary, update the range of USB devices supported. To do this:
Edit the Desktop Receiver registry (or the .ini files in the case of the
Client for Linux). For information about how to do this, see the Citrix
Desktop Receiver Administrators Guide or the Client for Linux
Edit the administrator override rules in the Virtual Desktop Agent

registry on the machine(s) hosting the desktops. The range specified
in the Virtual Desktop Agent must correspond exactly to the range
specified on the client; if it does not, then only the devices disallowed
in both ranges are disallowed.
The product default rules are stored in
HKLM\SOFTWARE\Citrix\PortICA\GenericUSB Type=String
Name=DeviceRules
Do not edit the product default rules.
The administrator override rules are stored in
HKLM\SOFTWARE\Policies\Citrix\PortICA\GenericUSB
Type=String Name=DeviceRules
97
For details of the rules and their syntax, see http://support.citrix.com/

article/CTX119722/.
ADM files are included on the installation media to allow you to make
changes to the Desktop Receiver and the Virtual Desktop Agent through
Active Directory Group Policy. The file for the Desktop Receiver is:
dvd root\os\lang\Support\Configuration\icaclient_usb.adm
and the file for the Virtual Desktop Agent is:
dvd root\os\lang\Support\Configuration\vda_usb.adm
For further information on setting up policies, see the Presentation Server
If you are using XenApp for Virtual Desktops, see USB Drive Mapping
Limitations on page 116.
Support for USB Mass Storage Devices

For mass storage devices only, remote access is also available through client drive
mapping, which you configure by enabling the Citrix Mappings rule. When this
rule is applied, the drives on the endpoint device are automatically mapped to
drive letters on the virtual desktop when users log on. The drives are displayed as
shared folders with mapped drive letters. The Mappings rule is in the Drives
subfolder of the Client Devices Resources folder in the Presentation Server
Console.
The main differences between the two types of remoting policy are:
Feature
Mappings rule
USB rule
Rule enabled by
default
Yes
No
Read-only access
configurable
Yes
No
Safe to remove
device during a
session
No
Yes, provided users

follow operating system
recommendations for
safe removal.
If both rules are enabled, then if a mass storage device is inserted before a session
starts, it will be redirected using client drive mapping first, before being
considered for redirection through USB support. If it is inserted after a session
has started, it will be considered for redirection using USB support before client
drive mapping. Automatic support of devices upon insertion, however, depends
on the type of client being used and the individual user preferences; for further
information, see the relevant client documentation.
98
Optimizing the User Experience

This topic describes how to:
Configure time zone settings to allow users to see their local time when
using desktops.
Configure connection timers to provide appropriate durations for

uninterrupted connections, idle sessions, and disconnected sessions.
Disable RDP, because the use of RDP can interfere with the operation of
ICA.
Remove the Shut Down command to prevent users from powering off their
desktops, which would then require a manual restart by an administrator.
This is not necessary for VM-based desktop groups.
For the best user experience, consider preinstalling frequently used software, such
as a Flash player or other browser plug-ins in your desktops. Also consider
enabling Microsoft ClearType or other font-smoothing technologies by default in
users profiles.
Configuring Time Zone Settings

By default, when non-privileged users connect to Windows XP desktops, they see
the time zone of the system running the desktop instead of the time zone of their
own endpoint device. To allow them to see their local time when using these
desktops you need to give them rights to:
Change the time on the system on which the desktop is running. To do this,
set up a Group Policy with rights given to non-privileged users to change
system time settings. For further information about how to do this, see
http://msdn2.microsoft.com/en-us/library/ms813808.aspx.
Change the time zone registry area. For information about how to do this,
see http://support.microsoft.com/kb/300022/.
After you do this, users who connect to Windows XP desktops see their local time
zone reflected in the desktop. When they log off or disconnect, the time zone of
the desktop is reset to what it was before they logged on.
Note: Users who want to see their local time when using Windows Vista
desktops must have the Change the time zone privilege. This privilege is granted
by default.
99
You can configure time zone settings through Citrix policies. If you want
endpoint devices to use the time zone of the virtual desktop to which they are
connected, enable the rule Do not use Clients local time, which is in the Time
Zones subfolder of the User Workspace folder in the Presentation Server
Console.
Configuring Connection Timers

You can configure three connection timers:
A maximum connection timer. This setting determines the maximum

duration of an uninterrupted connection between an endpoint device and a
desktop. By default, this setting is disabled.
A connection idle timer. This setting determines how long an uninterrupted

endpoint device connection to a desktop will be maintained if there is no
input from the user. By default, this is set to 1440 minutes (24 hours).
A disconnect timer. This setting determines how long a disconnected,

locked desktop can remain locked before the session is logged off. By
default, this setting is disabled for pre-assigned or assigned-on-first-use
desktop groups and enabled for pooled desktop groups. The default setting
is 1440 minutes (24 hours).
If you need to update any of these settings, ensure that settings are consistent
across your deployment.
Caution: These settings are configurable only through registry keys on the
computer hosting the desktop. Using Registry Editor incorrectly can cause
serious problems that can require you to reinstall the operating system. Citrix
cannot guarantee that problems resulting from incorrect use of Registry Editor
can be solved. Use Registry Editor at your own risk. Make sure you back up the
registry before you edit it.
After you update any of these settings, you must restart the computer hosting the
desktop for the new setting to take effect.
To enable the maximum connection timer, create the following registry key
(DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\
ConnectionTimer\enabled
and set the key to 1. To disable the timer, set the key to 0.
To update the maximum connection timer, create the following registry key
(DWORD):
100
ConnectionTimer\MaxConnectionTime
and set the maximum connection time in minutes.
To enable the connection idle timer, create the following registry key
(DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\IdleTimer\
\enabled
To update the connection idle timer, create the following registry key
(DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\IdleTimer\
\MaxIdleTime
and set the maximum idle time in minutes.
To enable the disconnect timer, create the following registry key (DWORD):
DisconnectTimer\enabled
To update the disconnect timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session
DisconnectTimer\MaxDisconnectTime
and set the maximum time in minutes to wait before logging off a disconnected
session.
Disabling RDP
If a user makes an RDP connection to a desktop, an ICA connection is not
possible until either a user logs on interactively on the console of the computer
hosting the desktop or the computer is restarted. Disconnecting the RDP session
or logging off from RDP is not sufficient. To avoid this issue, consider disabling
RDP as described in
http://technet.microsoft.com/en-us/library/bb457106.aspx.
Removing the Shut Down Command

Citrix recommends that you apply this Microsoft policy to all XenDesktop users.
This prevents users from selecting Shut Down within a XenDesktop session and
powering off the desktop, which would require manual intervention from the
system administrator.
101
Locate this policy under User Configuration\Administrative Templates\Start

Menu & Taskbar\Remove and prevent access to the Shut Down command and set
it to Enabled.
102
Managing Your Desktop Delivery

Controller Deployment
Overview
This section describes how to carry out the following tasks:
Putting desktops into maintenance mode.
Managing sessions. You can view, disconnect, and log off sessions. You can
also send messages to users.
Manually controlling VMs.
Migrating controllers to other farms.
Migrating desktops to other farms.
Updating license server settings.
The details of all these tasks are described in the following topics.
Other general management tasks, such as configuring connections and securing
farms, are described in detail in the Citrix Presentation Server Administrators
Guide.
Note: To be able to interpret security identifiers (SIDs) for either machines or
users, you need the appropriate rights to read this information in Active Directory.
If you run the Access Management Console as a user without these rights, only
SIDs appear in the console, not machine or user names. You are not prompted to
enter alternative credentials.
104
Putting Desktops into Maintenance Mode

If you want to temporarily stop connections to a desktop so that maintenance
tasks can be carried out, you can put the desktop into maintenance mode. If the
desktop is in a group that uses the idle pool settings, note that it will be entirely
under manual control until you take it out of maintenance mode again.
To put a desktop into maintenance mode

1.
Select the relevant desktop group.
2.
Select the Virtual Desktops view so that all the desktops for that group are
listed.
3.
Select the relevant desktop.
4.
From the task pane, select Enable maintenance mode.
No user can now log on to that desktop. If a user is logged on when you select
maintenance mode, maintenance mode takes effect as soon as that user logs off. If
a user tries to connect to an assigned desktop while it is in maintenance mode, a
message appears telling them that the desktop is currently unavailable and to try
reconnecting.
When a desktop is in maintenance mode, the Disable maintenance mode task
becomes available. To take a desktop out of maintenance mode, select the
desktop, then select Disable maintenance mode.
Managing Sessions
To view sessions for a desktop group
1.
Select the relevant desktop group in the console tree.
2.
Select the Virtual Desktops In Use view.
To view all sessions for a particular user

1.
From the Search options in the tasks pane, select Advanced search.
The Advanced Search dialog box appears.
2.
From the Find list, select Session by user.
3.
Type the user name.
4.
Select the relevant node of the console tree (for example, Desktop
Groups).
5.
Click Search.
Managing Your Desktop Delivery Controller Deployment
105
To disconnect or log off a session

1.
From the Virtual Desktops In Use view, select the session.
2.
From the task pane, select Disconnect or Logoff respectively.
If you log off a session, it closes and the desktop becomes available to other users,
unless it is assigned to a specific user.
If you disconnect a session, the users applications continue to run and the
desktop remains assigned to that user. If the user reconnects, the same desktop is
assigned. You can configure a time-out to ensure that disconnected sessions are
logged off automatically after a certain number of minutes; for further
information about this, see Configuring Connection Timers on page 99.
To send a message to users

1.
From the task pane, select Send message.
2.
In the dialog box that appears, type your message, then click OK to send
the message to all selected users.
Manually Controlling Virtual Machines

For VM-based desktop groups, you can manually control VMs through the
Access Management Console.
If you want to manually control the power state of a VM in a group that uses the
idle pool settings, put it into maintenance mode as described in To put a desktop
into maintenance mode on page 104.
To start virtual machines

1.
2.
From the Virtual Desktops view, select the relevant desktops.
3.
To start powered-off or suspended VMs, from the Tasks list, select Start.
The VMs are powered-on or resumed and the list of desktops is refreshed to
show the new state.
Note: If the hosting infrastructure does not support the power-on
function, the Start task is not available.
106
To shut down and restart virtual machines

1.
2.
From the Virtual Desktops view, select the relevant desktops.
3.
From the Tasks list, select Shutdown/suspend.

The Shutdown/Suspend Virtual Machine dialog box appears.
4.
Select from the following options. Depending on the state of the machine,
some of these options may not be available:
Shutdown. Requests the VMs operating system to shut down.

Note: If the machine does not shut down within 10 minutes, it is
powered off. If Windows attempts to install updates during shutdown,
there is a risk that the machine will be powered off before the updates
are complete.
Power off. Forcibly powers off the VM and refreshes the list of
desktops.
Shutdown and Restart. Requests the VMs operating system to shut

down and then start the VM again. If the operating system is unable
to do this, the VM remains in its current state.
Power off and Restart. Forcibly restarts the VM.
Suspend. Pauses the VM without shutting it down and refreshes the

list of desktops.
Migrating Controllers to Other Farms

If, for example, you want to move a controller from a test or pilot farm into
production, you may need to migrate it to another farm. To do this, you need
Active Directory permissions over the OU structure of both the controllers
existing farm and the controllers new farm.
If you remove all the controllers from a farm, Citrix recommends that you delete
the farm OU.
Citrix recommends that you do not move controllers to a farm created using an
earlier version of XenDesktop, Desktop Delivery Controller or Desktop Server; if
you do this your farm may become unusable.
107
To migrate a controller to another farm

1.
Remove the controller from the old farm OU. To do this, use the ADSetup
tool with the REMOVECONTROLLER parameter, as described in
Configuring Active Directory Using ADSetup on page 122.
2.
Use the chfarm utility to either create a new farm (if this is the first
controller in the farm) or move the controller to the new farm (if this is the
second or subsequent controller in the farm). For further information on
chfarm, see the Citrix Presentation Server Administrators Guide.
When using chfarm to move a controller to a new farm, make sure you
configure the zone name, zone preference, and license server details
correctly, because you cannot easily change these later.
3.
Add the controller to the new farm OU. To do this, use the ADSetup tool
with the ADDCONTROLLER parameter, as described in Configuring
Active Directory Using ADSetup on page 122.
4.
Restart the controller to make the new farm settings take effect.
Migrating Desktops to Other Farms

1.
Remove the desktops from the desktop group in the old farm. For details of
how to do this, see To update a desktop group on page 90.
2.
Note the farm GUID of the new farm. This is one of the read-only farm
properties in the Access Management Console.
3.
In the new farm, add the desktops to an existing or new desktop group.
There are various ways in which you can do this; for details, see Creating
and Updating Desktop Groups on page 75.
4.
Apply the new farms GUID to the desktops. To do this, use Group Policy.
The Desktop Delivery Controller Farm GUID policy enables you to use a
generic desktop image with multiple XenDesktop deployments. The
administrative template (ADM) file is supplied on the Desktop Delivery
Controller installation media:
platform\lang\support\configuration\FarmGUID.adm
For information about how to use ADM files, consult your Active Directory
documentation.
5.
Check the registry to ensure that the group policy has propagated to the
desktop computer, then restart the computer. This registers the desktop with
a controller in the new farm. Until you do this, the desktop is not available
to users.
108
Updating License Server Settings

During installation you specify the name of the license server your farm accesses
to check out licenses and the port number the license server uses to communicate.
You may want to change these settings in the following instances:
You rename your license server
The default port number (27000) is already in use
You have a firewall between the license server and the computers running
your Citrix products, and you must specify an alternative Citrix vendor
daemon port number
Use the License Server page of the farms properties to change the name of the
license server or port number that the license server uses to communicate. You
can apply the changes to either an individual server or an entire farm. You must
also take the following actions:
If you decide to change the license server name, first ensure that a license
server with the new name already exists on your network. Because license
files are tied to the license servers host name, if you change the license
server name, you must download a license file that is generated for the new
license server. This may involve returning and reallocating the licenses. To
return and reallocate your licenses, go to www.mycitrix.com. For
additional information, see Licensing: Migrating, Upgrading, and
Renaming, which you can download from
http://support.citrix.com/pages/licensing/.
If you change a port number, you must specify the new number in all
license files on the server. For additional information, see Licensing:
Firewalls and Security Considerations, which you can download from
http://support.citrix.com/pages/licensing/.
To specify a license server for the farm

1.
In the left pane of the Access Management Console, select the farm.
2.
From the Action menu, select Modify farm properties > Modify all
properties.
3.
From the Properties list, select License Server.
4.
Enter the name or IP address of the license server in the Name box.
5.
Enter the license server port number in the Port number (default 27000)
box.
6.
Click Apply to implement your changes.
109
To specify a license server for an individual

controller
1.
In the left pane of the Access Management Console, select the controller.
2.
From the Action menu, select Modify controller properties > Modify
license server properties.
3.
Clear the Use farm settings check box.
4.
Enter the name or IP address of the license server in the Name box.
5.
Enter the license server port number in the Port number (default 27000)
box.
110
10
Using XenApp for Virtual Desktops
This section explains how to use Citrix XenApp for Virtual Desktops in a
XenDesktop deployment to deliver applications to end users. It outlines the
benefits of using XenApp and factors to consider when deciding between
application streaming and hosting. It also explains how to configure your
deployment to provide the optimum end-user experience.
This section covers the use of XenApp for Virtual Desktops in a XenDesktop
environment. For information about using Citrix XenDesktop alongside an
existing Citrix XenApp deployment, in which XenApp is licensed separately,
refer to the Citrix Knowledge Center at http://support.citrix.com/.
Why Use XenApp with XenDesktop?

Using XenApp with XenDesktop allows you to separate applications from the
desktop, thus reducing the overall number of virtual desktop images that must be
managed. With XenApp you can place a single copy of an application on a
centralized XenApp server, rather than having multiple copies of the application
running on desktops.
In addition to increasing application and network performance, hosting an
application on a XenApp server greatly simplifies Windows application delivery.
Consider, for example, how much easier it is to patch just one copy of an
application running on a XenApp server, rather than patch multiple copies of an
application running on desktops.
Application Streaming Versus Hosting

Using XenApp, you can deliver an application to users either by streaming it to
the users virtual desktop or by hosting it on the XenApp server.
Application streaming simplifies delivery by allowing you to install and
configure an application on one file server for delivery to desktops. To upgrade or
patch the application, you make the updates only in the location where you stored
the application.
112
Application hosting makes applications available to users from the XenApp

server, instead of from their desktop. When a user runs an application that is
published on XenApp, the application is virtualized on the desktop and so appears
to the user to run locally. However, the application is running on the XenApp
server in a separate protected ICA session, which keeps application processing on
the endpoint device to a minimum. You can also publish content, such as
documents, media clips, and graphics on a XenApp server.
The following diagram shows the three main options for application deployment
in a XenDesktop environment. In the first desktop, the application is installed on
the virtual desktop image; in the second desktop, the application is streamed from
XenApp to the virtual desktops local hard-drive; in the third desktop, the
application is available as a published (hosted) application from XenApp.
Diagram showing the three main application deployment options in a XenDesktop

environment.
When deciding whether to stream or host applications using XenApp in a
XenDesktop environment, there are particular considerations to be aware of.
Network connectivity may factor in your decision whether to stream or host
applications. If the servers running XenDesktop are near to the XenApp server or
file share from where applications are streamed, the resulting good connectivity
makes application streaming an ideal option because of the amount of data that
must be streamed to the virtual desktop. Streamed applications also tend to
behave in a familiar way, similar to applications that run locally.
10
113
However, it may be more cost-effective and efficient, in terms of computing

resources, to host an application on a XenApp server, rather than having multiple
desktops run the same application. With XenApp, computing resources are shared
more efficiently and a higher density of running applications can be achieved.
The type of application may also be a factor. For example, you may want to
install a browser on the virtual desktop image so that the browser runs natively
and interacts seamlessly with other local applications, but host a CPU-intensive
application on XenApp to avoid stressing the virtual desktops. Office
productivity applications used by the majority of users, such as Microsoft Office,
are ideal for streaming.
If users access any USB drives plugged into their endpoint devices, or smart card
support for data encryption and digital signing is required within applications
delivered by XenApp in your deployment, see USB Drive Mapping Limitations
on page 116 or Smart Card Support on page 117 for other considerations to be
aware of.
Before Installing XenApp in a XenDesktop Environment

This topic outlines points to consider before you install XenApp in your
XenDesktop deployment. It assumes that the XenDesktop environment has
already been set up and that you are familiar with XenApp administration
concepts. For more information about XenApp, see Getting Started with Citrix
XenApp and the Citrix XenApp Administrator's Guide.
Server Considerations
Do not install XenApp and XenDesktop on the same server. The Desktop
Delivery Controller cannot co-exist on the same computer as XenApp.
Use separate databases. XenDesktop and XenApp cannot share the same
database for the farm data store. You must use a separate database for XenApp
and for XenDesktop; however, these databases can reside on the same database
server. For more information about setting up a farm data store, see the Citrix
XenApp Administrators Guide.
Management Console Considerations

Co-hosting the Access Management Console. You can install the Desktop
Delivery Controller and XenApp Access Management Console snap-ins on the
same computer or on separate computers.
Use separate Presentation Server Consoles. XenDesktop and XenApp cannot
use the same Presentation Server Console (renamed Advanced Configuration in
XenApp). You must use separate consoles for XenApp and for XenDesktop and
you must install these on separate machines.
114
Note: You must install the XenDesktop Presentation Server Console on the
same computer as the XenDesktop Access Management Console.
Installing XenApp from the Product Media

Citrix XenApp for Virtual Desktops is supplied with both the Enterprise Edition
and Platinum Edition of XenDesktop. For information about the different editions
of XenApp and the XenApp plugins supplied with XenDesktop, see
XenDesktop Installation Media on page 44. For more information about
installing XenApp, see the Citrix XenApp Installation Guide.
Licensing Considerations
A XenApp license is included with the XenDesktop Enterprise Edition and
Platinum Edition. You can install the XenApp license on the same license server
as your XenDesktop licenses or you can use a different license server. For details
of how to install and run Citrix Licensing, see the Getting Started with Citrix
Licensing Guide, which you can download from http://support.citrix.com/pages/
licensing/.
Important: When using XenApp as a component of XenDesktop Enterprise
Edition or Platinum Edition, you may use XenApp only to provide presentation
services to physical or virtual machines running in the XenDesktop environment.
Citrix XenApp, as so provided, may not be used to publish desktops or
applications directly to client devices.
Optimizing Application Delivery

This topic describes how to optimize the user experience so that, for the user, this
is as familiar as running applications locally.
For the most seamless user experience, Citrix recommends that you:
Install the XenApp Plugin for Hosted Apps and configure applications to
appear in the Start menu
Install the XenApp Plugin for Streamed Apps
Set up pass-through authentication
Configure a policy to map network drives
Pre-cache streamed applications at logon
10
115
These recommendations are discussed in more detail below.
Installing the XenApp Plugins

Install the Citrix XenApp Plugin for Hosted Apps (the new name for the Citrix
Presentation Server client) on the virtual desktop image, so that when users
connect to their desktop, they automatically get the XenApp Plugin.
Set up Citrix XenApp (the new name for Program Neighborhood Agent) so that
applications appear in the users Start menu. To the user, these applications
appear to behave as if they are installed locally, although the applications are
running on the XenApp server. This avoids users having to visit a Web site to start
their applications. For more information, see the XenApp Plugin for Hosted Apps
for Windows Administrators Guide.
For optimal flexibility, also install the XenApp Plugin for Streamed Apps (the
plugin needed for client-side application virtualization, formerly known as the
Streaming Client) on the virtual desktop image. This allows you to stream
applications from XenApp as well as host them. For information about installing
and configuring this plugin, see the Citrix Application Streaming Guide.
Setting up Pass-through Authentication

Pass-through authentication allows the XenApp Plugin to access a users local
Windows user name, password, and domain information and pass it to the
XenApp server. This means that users are not prompted to log on to XenApp
separately.
To enable pass-through authentication, you must configure both the XenApp
server and the XenApp Plugin.
To enable pass-through authentication in the XenApp Plugin, during installation,
choose Enable Pass-Through Authentication. For more information, see the
XenApp Plugin for Hosted Apps for Windows Administrators Guide.
To enable pass-through authentication on the XenApp server, see Configuring
Pass-through Client Authentication in the Citrix XenApp Installation Guide.
Mapping Network Drives Using a Policy

To ensure users can see their local drives when running applications hosted on
XenApp, you must configure a policy on XenApp to map network drives.
When a user connects to a virtual desktop, their local drives are mapped; for
example, C:(\\Client) (U:). However, when the user then connects to an
application hosted on XenApp, these local drives are not re-mapped, so the user
does not see them. This is because XenApp does not map network drives by
default.
116
To ensure your users local drives are mapped, configure a policy on the XenApp
server.
To map network drives in XenApp

1.
On the XenApp server, launch Advanced Configuration (the new name for
the Presentation Server Console), then from Policies either create a new
policy or amend an existing policy.
2.
Select the policy and choose Properties > Client Devices > Resources >
Drives > Mappings.
3.
Set Mappings to Enabled.
4.
Ensure Turn off Remote drives is cleared.
5.
Click OK.
To apply the policy, you must create a filter for it so the server can apply it to
matching connections. For more information about how to create and apply
policies, see the Citrix XenApp Administrator's Guide.
USB Drive Mapping Limitations

Some USB devices may not be accessible to users when running applications
hosted on XenApp. Although users can see and access USB devices within their
virtual desktops, some devices may not be mapped on the XenApp server.
Some USB devices will be mapped into applications hosted on XenApp,

including printers, PDAs, and scanners. USB drives inserted before the
connection to the virtual desktop is established are also mapped into
applications hosted on XenApp.
Other USB devices, as well as devices inserted after the hosted application
has been launched from within the virtual desktop, will not be visible to
hosted applications.
To address this limitation, stream the application from XenApp, rather than host
it, so that users can access any USB drives plugged into their endpoint devices.
Pre-caching Streamed Applications

In XenDesktop environments that use a Provisioning Server private virtual disk
(vDisk), consider pre-caching streamed applications at logon. Pre-caching
applications at logon means that the application is streamed from the XenApp
server to the endpoint device when the user logs on. This provides better
performance because the application is streamed across the network before the
user launches it. Pre-caching applications at logon is the default streaming
behavior.
10
117
Important: Ensure the vDisk access is set to Private, rather than Standard,
before pre-caching streamed applications. Only when vDisk access is Private will
the application be written and saved; in Standard mode, any changes will be lost.
For more information about pre-caching applications at logon, see the Citrix
Application Streaming Guide.
Smart Card Support

If you require smart card support for data encryption and digital signing within
applications delivered by XenApp in your XenDesktop environment, stream
applications from the XenApp server.
Once a user has authenticated to their XenDesktop session, the smart card on the
endpoint device allows digital signing within streamed applications, such as
Microsoft Outlook, and also data encryption.
For more information about using smart cards within your XenDesktop
environment, see Using Smart Cards with XenDesktop on page 37. For
information about configuring application streaming, see the Citrix Application
Streaming Guide.
User Profile Manager Considerations

User Profile Manager is the ideal profile solution to manage user personalization
settings when using XenApp in a XenDesktop environment.
If you are administering XenApp in a XenDesktop environment and you are
using Citrix User Profile Manager, you may need to use separate Organizational
Units for each published application that creates Citrix user profile data. For more
information, see Using Citrix User Profile Manager with XenDesktop.
118
11
Command-Line Tools
Tools are provided to enable you to install and remove controllers and the Virtual
Desktop Agent using the command line. You can also use a command-line tool to
configure Active Directory.
Installing and Removing Controllers Using Setup.exe

The Setup.exe file supports several command-line options for controlling the
installation and removal of Desktop Delivery Controller.
If you control the installation through the command line, you must also configure
Active Directory from the command line. For further information, see
Configuring Active Directory Using ADSetup on page 122. You have to
configure Active Directory not only when you create a new farm, but also when
you add a controller to a farm.
Option
Description
-quiet
No user interface is presented. This is intended to

support unattended installs.
When you are using the -quiet option, the only
evidence that the product is being installed is that the
Setup.exe process can be seen running if you look in
Windows Task Manager.
-showui
Shows every dialog box in the user interface for every

subinstall. This option is most useful when you need
to deviate from the deployment scenarios supported
by the user interface.
-passive
Shows only the progress user interface. No user

interaction is required if you use this option.
If you are installing through a network share that
requires authentication, the authentication process
must not require the share to be explicitly mounted or
credentials to be entered.
-createfarm <farm_name>
Creates a new farm with the specified farm name.
120
Option
Description
-edition <edition_name>
The edition of XenDesktop for which you have

licenses. Use this option when you are creating a new
farm. Must be one of the following, in either
uppercase or lowercase:
STD (Standard edition)
ADV (Advanced edition)
ENT (Enterprise edition)
PLT (Platinum edition)
-components <component_list>
The components to install.

<component_list> must be a comma-separated list of
one or more of the following:
DDC (the core Desktop Delivery Controller
component)
CONSOLES (the management consoles)
LIC_SERVER (Citrix Licensing)
-joinfarm <controller>
Adds this controller to an existing farm.

<controller> is the name of a controller already in the
farm. It must be the NetBIOS name, not the DNS
name.
-licenseserver <server>
The license server to use.
-dsnfilepath <path>
The path to an ODBC DSN database configuration

file. Use this option when you are specifying an
existing SQL database.
-dbusername <user>
The user name for accessing the database specified in

-dsnfilepath.
-dbpassword <password>
The password for accessing the database specified in

-dsnfilepath.
-nosites
Prevents the Web Interface and the default sites from

being installed automatically when you select
Desktop Delivery Controller for installation either
through the command line or through the GUI menu.
-installdir <location to install>
Installs the Desktop Delivery Controller component in

the specified location, which should be an existing
empty directory.
-remove
Removes the Desktop Delivery Controller

component.
11
121
Examples
The -passive option is an efficient way to install a large number of controllers
compared with using the Installation wizard on individual controllers.
Example 1: Installing a Single Component

setup.exe -passive -components CONSOLES
where CONSOLES (the management consoles) is the component you are
installing.
Example 2: Installing all the Desktop Delivery Controller

Components on a Single Server
setup.exe -passive -createfarm MyFarm
-components DDC,LIC_SERVER,CONSOLES
-edition STD
where:
MyFarm is the farm you are creating, DDC, LIC_SERVER, and CONSOLES
are the components you are installing on the server, and you are licensed to use
XenDesktop Standard Edition.
Example 3: Creating a New Controller and Adding it to a Farm

The following example shows how to create a new controller, installing only the
core Desktop Deliver Controller component, and then add that controller to an
existing farm that is using an external database on a separate server:
setup.exe -passive -joinfarm ele1985 -components DDC
-dsnfilepath c:\MF20.dsn -dbusername alexco -dbpassword libby02
where:
ele1985 is an existing controller in the farm, DDC is the component you want to
install, c:\MF20.dsn is the path to the dsn file, alexco is the user name for
accessing the database, and libby02 is the password for accessing the database.
In this example the MF20.dsn file was copied to the server before the installation
process started.
122
Installing and Removing the Virtual Desktop Agent Using

XdsAgent.msi
The Virtual Desktop Agent installer (XdsAgent.msi) supports the standard
msiexec command-line options. For details of these options, go to:
http://msdn2.microsoft.com/en-us/library/aa367988.aspx
You can set the following properties as msiexec property arguments:
Property
Description
CONFIGURE_WINDOWS_FIREWALL Values:
0 = Do not adjust Windows firewall
1 = Adjust Windows firewall (default)
WCF_PORT
The port number used by the controller to

connect to the desktop.
Default = 8080
SHOW_FARM_PAGE
Flag indicating whether or not the farm

selection page should be displayed.
1 = Yes (default)
0 = No
FARM_GUID
The Globally Unique Identifier (GUID) of the

farm Active Directory OU. This is used to
associate a desktop with a farm.
The farm GUID is one of the farm properties
displayed in the Access Management Console.
Default = Blank
You must ensure that Microsoft .NET Framework 3.5 has already been installed
before you install the Virtual Desktop Agent.
Configuring Active Directory Using ADSetup

ADSetup is a command-line tool that provides scriptable Active Directory
configuration. You can use it to start the wizard described in Configuring Active
Directory on page 50. You can also run it using any of the other parameters
described in the table below.
Note: If you need to relocate or rename the farm OU, Citrix recommends that
you use standard Active Directory management tools to do this.
11
123
Several of the options described in the table below refer to OU distinguished

names. For more information about character-handling in these names, refer to:
http://msdn2.microsoft.com/en-us/library/aa366101(VS.85).aspx
and
http://www.ietf.org/rfc/rfc2253.txt
Option
Description
RUNGUI
Starts the Active Directory Configuration Wizard,

which guides you through a set of pages that
correspond to the parameters described below.
RUNGUI [SETOU]
Starts the Active Directory Configuration Wizard, but

does not prepopulate the Select Farm OU field. Runs
the wizard without the Select Controllers page; the
controller on which you are running the tool is added
automatically to the farm.
INITIALIZEOU
OU=<OUDistinguishedName>
[NEWOU=<OUName>]
Populates the farm OU.

The optional NEWOU parameter creates an OU with
the specified name. The OU specified in the OU
parameter is the parent in which to create the new OU.
Enter this parameter as a name only; for example,
MyFarm, not OU=MyFarm.
The farm OU is set in the Citrix IMA Service and the
controller on which you are running the tool is added
to the farm.
ADDCONTROLLER
CONTROLLERLIST=
<ControllersList>
[OU=<OUName>]
Adds a controller to the farm.

<ControllersList> is a list of controller names
separated by semicolons. The names can be security
identifiers, DNS names, or Active Directory
distinguished names.
OU is an optional parameter that forces the controllers
to be added to the specified farm OU. If you do not
specify this parameter and the farm OU cannot be
determined, the command fails.
After you add a controller to the farm, you must
restart that controller. If, however, you ran the tool on
the controller you were adding, the controller is
restarted automatically.
REMOVECONTROLLER
CONTROLLERLIST=
<ControllersList>
[OU=<OUName>]
Removes a controller from the farm.

<ControllersList> is a list of controller names
separated by semicolons. The names can be security
identifiers, DNS names, or Active Directory
distinguished names.
OU is an optional parameter that forces the controllers
to be removed from the specified farm OU. If you do
not specify this parameter and the farm OU cannot be
determined, the command fails.
124
Index
Index
A
access control
configuring 83
Access Gateway
creating Web sites for remote access 19
Access Management Console 12
starting 53
access mode
setting for vDisk 73
Active Directory
configuring 50
configuring using ADSetup 122
containers 16
delegating access control 94
Organizational Units 16
replication 17
security groups 16
Service Connection Points 16
using with Desktop Delivery Controller 15
administrator permissions
configuring 94
administrators
creating 95
ADSetup command-line tool 122
advanced settings
configuring for desktop groups 83
appliances
connecting from 28
assigned-on-first-use desktops
definition 75
B
base desktop VM
adding to Provisioning Server database 71
creating 68
imaging to Provisioning Server vDisk 72
installing target device 71
blade-based desktop groups

creating 82
C
Citrix Desktop Receiver
installing 61
Citrix Desktop Service 57
Citrix ICA Service 58
Citrix policies
creating 93
Citrix products
licensing 46
Citrix XenApp 111
client drive mapping 97
client options
configuring 86
command-line parameters for Setup.exe 119
connection timers
configuring 99
connections to desktops
preventing temporarily 104
controllers
adding to farms 51
migrating to other farms 106
D
default Web sites
modifying 18
delegated administration
configuring 94
removing 64
upgrading 62
desktop group types
overview 75
125
126
desktop groups
creating 75
creating using XenDesktop Setup Wizard 76
deleting 92
updating 89
desktop privileges
planning 21
desktops
migrating to other farms 107
user-driven restart 92
discovery
running 53
documentation 9
domain-joined computers
connecting from 30
downloads 44
E
editions 44
edition, upgrading 63
endpoint devices
security planning 22
exporting desktop and user data 87
F
farm
creating 47
planning 11
farm data store
creating 47
hosting on separate server 50
fat client devices
connecting from 31
firewalls
configuring manually 60
planning 20
I
idle pool
configuring 84
importing desktop and user data 87
installation command-line parameters 119
installation media 44
installing Desktop Delivery Controller on a single server
47
IPSec 20
L
license server settings
updating 108
licensing 4647
updating license server settings 108
logoff behavior
assigned desktops 85
configuring 85
pooled desktops 85
logs
Pool Management 79
Provisioning Server 68
XenDesktop Setup Wizard 79
M
maintenance mode
desktops 104
management consoles 12
installing separately 52
messages
sending to users 105
mixed farm support 23
multiple pools
creating 81
O
Oracle database
using 50
Organizational Unit
creating 50
P
PC-based desktop groups
creating 82
permissions
configuring 94
planning
network environment 26
user types 25
policies
creating 93
Pool Management logging
enabling 79
pooled desktops
definition 75
pre-assigned desktops
definition 75
Presentation Server Console 12
Index
ProductEdition.exe 63
Provisioning Server
installing 56
logs 68
Provisioning Server database
adding base desktop VM 71
Provisioning Server template
creating 73
R
RDP
disabling 100
remote computers
connecting from 35
replication, effects of 17
repurposed computers
connecting from 30
restarting desktops 92
S
Secure Gateway 19
SecureICA 20
security planning 19
sessions
disconnecting 105
logging off 105
viewing for desktop groups 104
viewing for user 104
Setup.exe command-line parameters 119
Shut Down command
removing 100
smart cards 37
configuring authentication methods 39
endpoint requirements 38
readers supported 37
removing 40
types supported 37
SQL Server
using 50
support and training 10
T
target device
installing on base desktop VM 71
template
creating 73
time zone settings
configuring 98
training and support 10
127
U
unattended install 119
updating
license server settings 108
upgrading 23, 61
to different edition 63
USB policy rule 96
USB support
configuring 95
user privileges
planning 21
user-driven desktop restart 92
users
planning user experience 25
V
vDisk
creating 70
imaging 72
setting access mode 73
Virtual Desktop Agent
installing 57
installing using XdsAgent.msi 122
removing 63
upgrading 62
virtual machines
creating using XenCenter 68
installing target device 71
restarting 106
shutting down 106
starting 105
VM-based desktop groups
creating using Access Management Console 79
creating using Setup Wizard 76
W
Web Interface
using with Desktop Delivery Controller 18
Web sites
modifying 18
X
XdsAgent.msi
properties 122
XenApp 111
128
XenDesktop Setup Wizard 76

enabling logging 79
installing 57
removing 65
XenMultiPool.exe 81
XenServer
installing 54
pools 81
replacing default SSL certificate 54

XDAdminGuide PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

XDAdminGuide PDF

Caricato da

Copyright:

Formati disponibili

Citrix XenDesktop Administrators Guide

Citrix XenDesktop 3.0

Copyright and Trademark Notice

Planning Your Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Planning the User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Using Smart Cards with XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Citrix XenDesktop Administrators Guide

Secure Use of Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Preparing and Provisioning Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Creating and Updating Desktop Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Customizing Your Desktop Delivery Controller Environment. . . . . . . . . . . . . . . . . . . . . . . . . 93

Citrix XenDesktop Administrators Guide

Configuring USB Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

Managing Your Desktop Delivery Controller Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . 103

10 Using XenApp for Virtual Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Optimizing Application Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

11 Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Citrix XenDesktop Administrators Guide

How to Use This Document

Finding More Information

For information on the new features and enhancements in this release,

Citrix XenDesktop Administrators Guide

The Citrix XenDesktop Readme contains information about last-minute

For step-by-step instructions on how to set up a sample pilot deployment,

For details of the system requirements (hardware and software) for

A document is available for each third-party hosting infrastructure plug-in

Getting Support and Training

Planning Your Deployment

Planning your farm

Using Active Directory with Desktop Delivery Controller

Using the Web Interface with Desktop Delivery Controller

Upgrading from previous versions of XenDesktop

New Features in this Release

Smart card authentication

Using Smart Cards with XenDesktop on page 37

User-driven desktop restart

To configure user-driven desktop restart on page

Configuring USB Support on page 95

Planning Your Farm

Citrix XenDesktop Administrators Guide

The main delivery controller component.

Citrix Licensing. By default, this is installed when you install

A farm data store. This is where persistent information about the

Management consoles to enable you to create desktop groups and

A domain controller running Active Directory. Active Directory is required

VMs or physical computers hosting the desktops you want to deliver to

Planning Your Deployment

An initial deployment might consist of the following:

This figure shows a single controller configuration of XenDesktop.

Citrix XenDesktop Administrators Guide

A more distributed deployment might consist of the following:

This figure shows a distributed components configuration of XenDesktop.

Provisioning Server enables you to stream a single desktop image to create

Planning Your Deployment

Information on using Citrix Access Gateway, Edgesight for Endpoints,

Using Active Directory with Desktop Delivery Controller

Active Directorys inbuilt security infrastructure is used by desktops to

Active Directory is used by desktops to discover the controllers that

Citrix XenDesktop Administrators Guide

When you create a farm, a corresponding Organizational Unit (OU) must be

A Controllers security group. The computer account of all controllers in the

A Service Connection Point (SCP) object that contains meta-information

A container called RegistrationServices, which is created within the farms