xdadminguide

Citrix XenDesktop 3.0Citrix® XenDesktop™

Citrix XenDesktop Administrator’s Guide

Copyright and Trademark NoticeInformation 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)

http://www.apache.org/

Contents 3

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9How to Use This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Finding More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Getting Support and Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

2 Planning Your Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11New Features in this Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Planning Your Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Using Active Directory with Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . . .15Using the Web Interface with Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . .18Security Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Security Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Managing User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Deployment Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Upgrading from Previous Versions of XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

3 Planning the User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Your Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Desktop Connection Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Scenario A: Connecting from an Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Scenario B: Connecting from a Domain-Joined or Repurposed Computer . . . . . . . . . . .30Scenario C: Connecting from a Fat Client Device on a LAN . . . . . . . . . . . . . . . . . . . . .31Scenario D: Connecting from Remote Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

4 Using Smart Cards with XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Smart Card Types and Readers Supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Endpoint Device Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

4 Citrix XenDesktop Administrator’s Guide

Secure Use of Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Configuring Smart Card Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Managing Smart Card Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Removing Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

5 Installing XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43XenDesktop Installation Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

What’s on the Installation Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Creating the Farm Data Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Installing Desktop Delivery Controller on a Single Server . . . . . . . . . . . . . . . . . . . . . . . . . .47

To install Desktop Delivery Controller and create a farm . . . . . . . . . . . . . . . . . . . . . . . .48Configuring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Using a Separate Database Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Adding Controllers to Your Farm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51To add a controller to a farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Installing the Management Consoles Separately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52To install the management consoles on a separate computer . . . . . . . . . . . . . . . . . . . . . .52

Starting the Access Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53To configure and run discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53

Installing VM Infrastructure Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54To install XenServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Replacing the Default XenServer SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Installing Citrix Provisioning Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Installing the XenDesktop Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Installing the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

To install the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59To configure firewalls manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

Installing the Citrix Desktop Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Upgrading to XenDesktop 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

To upgrade Desktop Delivery Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62To upgrade the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

Upgrading to a Different Edition of XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Removing XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

To remove the Virtual Desktop Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Removing Desktop Delivery Controller Components . . . . . . . . . . . . . . . . . . . . . . . . . . .64To remove the XenDesktop Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

Contents 5

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

7 Creating and Updating Desktop Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75To create a VM-based pooled desktop group using the XenDesktop Setup Wizard . . . . . .76

To enable logging on the XenDesktop Setup Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . .79To enable Pool Management logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

To create a VM-based desktop group using the Access Management Console . . . . . . . . . .79Using More than One XenServer Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

To create multiple pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81To create a PC- or blade-based desktop group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82Configuring Advanced Settings for Desktop Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Configuring Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Setting Up an Idle Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Configuring Logoff Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85Specifying Client Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

Importing and Exporting Desktop and User Assignment Data . . . . . . . . . . . . . . . . . . . . . . .87To export data to a file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88To import data from a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

Updating Desktop Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89To update a desktop group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90To configure user-driven desktop restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92To delete a desktop group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

8 Customizing Your Desktop Delivery Controller Environment. . . . . . . . . . . . . . . . . . . . . . . . . 93Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93Creating Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Delegating Active Directory Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94Delegating Desktop Delivery Controller Administration Tasks . . . . . . . . . . . . . . . . . . .94


Configuring USB Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95To configure USB support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96Support for USB Mass Storage Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

Optimizing the User Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98Configuring Time Zone Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98Configuring Connection Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99Disabling RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100Removing the Shut Down Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

9 Managing Your Desktop Delivery Controller Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . .103Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103Putting Desktops into Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

To put a desktop into maintenance mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104Managing Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

To view sessions for a desktop group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104To view all sessions for a particular user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104To disconnect or log off a session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105To send a message to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105

Manually Controlling Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105To start virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105To shut down and restart virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

Migrating Controllers to Other Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106To migrate a controller to another farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107

Migrating Desktops to Other Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Updating License Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

To specify a license server for the farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108To specify a license server for an individual controller . . . . . . . . . . . . . . . . . . . . . . . . .109

10 Using XenApp for Virtual Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Why Use XenApp with XenDesktop? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111

Application Streaming Versus Hosting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Before Installing XenApp in a XenDesktop Environment . . . . . . . . . . . . . . . . . . . . . . . . .113

Server Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Management Console Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Installing XenApp from the Product Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114Licensing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Contents 7

Optimizing Application Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114Installing the XenApp Plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Setting up Pass-through Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Mapping Network Drives Using a Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Pre-caching Streamed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Smart Card Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117User Profile Manager Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

11 Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Installing and Removing Controllers Using Setup.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Installing and Removing the Virtual Desktop Agent Using XdsAgent.msi . . . . . . . . . . . .122Configuring Active Directory Using ADSetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

1

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 DocumentThe Citrix XenDesktop Administrator’s 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 fromhttp://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 InformationMore 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.

http://support.citrix.com/


http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx/

http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx/

http://support.citrix.com/product/xd/v3.0/#tab-doc/




• 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 Evaluator’s 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 Administrator’s 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 TrainingThe 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 up-to-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.

http://forums.citrix.com/category.jspa?categoryID=37/


http://www.citrix.com/edu/

2

Planning Your Deployment

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

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

• Planning your farm

• Using Active Directory with Desktop Delivery Controller

• Using the Web Interface with Desktop Delivery Controller

• Security planning

• Upgrading from previous versions of XenDesktop

New Features in this ReleaseThe 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:

Planning Your FarmXenDesktop 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.

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


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.

2 Planning Your Deployment 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.


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.


• 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 product-specific documentation, which you can download fromhttp://support.citrix.com/.

Using Active Directory with Desktop Delivery ControllerDesktop 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 Directory’s inbuilt security infrastructure is used by desktops to check that incoming communications from controllers come from authorized controllers in the appropriate farm. Active Directory’s security infrastructure also ensures that the data exchanged by desktops and controllers is confidential. Desktop Delivery Controller uses Active Directory's inbuilt Kerberos infrastructure to guarantee the authenticity and confidentiality of communication. For more information about Kerberos, refer to Microsoft’s product documentation.

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



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

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

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 farm’s 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 farm’s OU. This contains one SCP object for each controller in the farm. The SCP is created when Desktop Delivery Controller is installed on a server. Each


time the controller starts, it validates the contents of its SCP and updates them if necessary.

If multiple administrators are likely to add and remove controllers after the initial installation is complete, they need permissions to create and delete children on the RegistrationServices container and Write properties on the Controllers security group. (These permissions are granted automatically to the administrator who installs the farm.) Either the domain administrator or the original installing administrator can grant these permissions, and Citrix recommends setting up a security group to do this.

The following points are important to bear in mind when you are using Desktop Delivery Controller:

• Information is written to Active Directory only when installing or uninstalling Desktop Delivery Controller, or when a controller starts and needs to update the information in its SCP (for example, because the controller was renamed or because the communication port was changed). By default, the installation routine sets up permissions on the objects in the farm’s OU appropriately, giving controllers Write access to their SCP. The contents of the objects in the farm OU are used to establish trust between desktops and controllers. You should ensure that:

• Only authorized Desktop Delivery Controller administrators can add or remove computers from the Controllers security group, using the security group’s access control list (ACL)

• Only authorized administrators and the respective controller can change the information in the controller’s SCP

• Depending on your Active Directory infrastructure, you should be aware of replication and its impact on a Desktop Delivery Controller implementation. Refer to Microsoft’s documentation to understand the concepts of replication and associated delays. This is particularly important if you create the farm’s OU in a domain that has domain controllers located in multiple Active Directory sites. Depending on the location of desktops, delivery controllers, and domain controllers, changes that are made to Active Directory when you are initially creating the OU for the farm, installing or uninstalling controllers, or changing controller names or communication ports may not be visible to desktops until that information is replicated to the appropriate domain controller. The symptoms of such replication delay include desktops that cannot establish contact with controllers and are, therefore, not available for user connections.

• Desktop Delivery Controller uses some of the standard computer object attributes in Active Directory to manage desktops. Depending on your setup, the machine object’s fully qualified domain name, as stored in the desktop’s Active Directory record, can be included as part of the connection


settings that are returned to the user to make a connection. It is, therefore, important to ensure that this information is consistent with information held in your DNS environment.

Using the Web Interface with Desktop Delivery ControllerThree 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 Administrator’s 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.


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 Administrator’s 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 Administrator’s Guide.

Security PlanningThis topic describes:

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

• Managing user privileges

• Deployment scenarios and their security implications

Your organization may need to meet specific security standards to satisfy regulatory requirements. This document does not cover this subject, because such security standards change over time. For up-to-date information on security standards and Citrix products, consult 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.

https://www.citrix.com/security/


Security Best PracticesKeep 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 Administrator’s Guide.

http://www.iana.org/


Managing User PrivilegesYou 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.

http://support.citrix.com/article/CTX116942/


Deployment ScenariosYour 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 DevicesManaged 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 (XenDesktop-ready 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 DevicesEndpoint 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 DesktopsWhen 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.


• 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 XenDesktopYou 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.

3

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 Administrator’s 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 EnvironmentThis 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 TypesHow 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.


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

3 Planning the User Experience 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 ScenariosThis 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:

Scenario Typical Endpoint Configurations

Endpoint Location

Recommended User Experience

Recommended Access Point

Use if

A Appliances and other non-domain-joined endpoints running Windows XP Embedded, Windows CE, or Linux

On a LAN 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.

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

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

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


• 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 ApplianceThis 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-screen-only 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 manufacturer’s documentation. For more general information about XenDesktop-ready 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.

http://www.citrix.com/citrixready/


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 Administrator’s 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


interface. For more details, see “Configuring USB Support” on page 95 and the Citrix Desktop Receiver Administrator’s 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 user’s 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 ComputerThis 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.


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


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.


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 Administrator’s 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.


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 Administrator’s 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 user-driven 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


again. Alternatively, if they want to log off, they can do so from the virtual desktop’s 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 ComputersThis 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.


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 desktop’s Start menu.

4

Using Smart Cards with XenDesktop

OverviewXenDesktop 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 SupportedThe 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


• 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 RequirementsThe 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 Administrator’s 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 CardsYour 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:

http://www.citrix.com/ready/

4 Using Smart Cards with XenDesktop 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 AuthenticationTo 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/.




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 Administrator’s Guide.

Managing Smart Card UseKeep 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 appliance’s 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 CardsWhen 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.

4 Using Smart Cards with XenDesktop 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.

Disconnect if a remote Terminal Services session

The XenDesktop session is disconnected and the virtual desktop is locked.

Windows Server 2003 policy setting

XenDesktop behavior

5

Installing XenDesktop

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


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 fromhttp://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 MediaThe 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 Y Y Y Y

CD Virtual Machine Infrastructure powered by Citrix XenServer

Y Y Y Y

CD Virtual Desktop Provisioning powered by Citrix Provisioning Server for Desktops

Y Y Y

Download Citrix User Profile Manager Y Y Y

CD Integrated App Delivery powered by Citrix XenApp for Virtual Desktops for Microsoft Windows Server 2008

Y Y

CD Integrated App Delivery powered by Citrix XenApp for Virtual Desktops for Microsoft Windows Server 2003

Y Y

http://support.citrix.com/pages/docs/

5 Installing XenDesktop 45

What’s on the Installation MediaUse 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.

• Integrated App Delivery powered by Citrix XenApp for Virtual 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.

CD Integrated App Delivery powered by Citrix XenApp for Virtual Desktops for Microsoft Windows Server 2003x64

Y Y

CD XenApp Components Disc Y Y

Subscription service

GoToAssist Y

Download WANScaler Client Y

Download EasyCall Agent Y

Download Edgesight for Endpoints Y

Y = Included with this product edition.

Physical media and downloads Editions

Medium Label Exp/Std Adv Ent Plat


• Integrated App Delivery powered by Citrix XenApp for Virtual 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.

LicensingAfter purchasing XenDesktop, you receive two emails with instructions specific to your license(s).

The following components require the use of a Citrix License Server:

• Desktop Delivery Controller

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


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 StoreIf 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 Administrator’s Guide.

Installing Desktop Delivery Controller on a Single ServerThis 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.

http://support.citrix.com/pages/licensing/


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 farm1. 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:

• 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 server’s 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.


Configuring Active DirectoryBefore 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 ServerWhen 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 store1. 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


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 FarmAfter 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 farm1. Insert the Desktop Delivery Controller installation media in the appropriate

drive.


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




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


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 server’s details; make sure you specify the same database server for all controllers in the farm.

Click Next.

8. On the Start Installation page, click Next. A progress indicator page 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 SeparatelyYou 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 computer1. Insert the Desktop Delivery Controller installation media in the appropriate

drive.



2. Click Install Optional Components.

3. On the next page, click Install Management Consoles.




5. On the Select Components page, ensure that Citrix Management Consoles is selected, then click Next.

6. On the Start Installation page, click Next. A progress indicator page 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 ConsoleTo 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 discovery1. On the Welcome page of the wizard, click Next.

2. On the Select Products or Components page, click Next.


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 SoftwareIf 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 XenServerEnsure that you have the XenServer Installation Guide and the XenServer Administrator’s 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 CertificateCitrix 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.




To replace the default XenServer SSL Certificate1. 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:FALSEkeyUsage = keyEnciphermentextendedKeyUsage = 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.


To install a certificate on the delivery controller1. 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 ServerIf 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 fromhttp://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.



• 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 WizardThe 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 AgentThis 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.


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


Note: Microsoft .NET Framework 3.5 is a prerequisite when installing the Virtual Desktop Agent through Group Policy.

To install the Virtual Desktop Agent1. 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. Insert the Desktop Delivery Controller installation media in the appropriate 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.


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:


• 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 manuallyTo 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


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 ReceiverFor 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 Administrator’s Guide.

Upgrading to XenDesktop 3.0To 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 Administrator’s 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




5.0, which is included with the XenDesktop installation media. Upgrade instructions are provided in the Provisioning Server documentation.

To upgrade Desktop Delivery Controller1. Insert the Desktop Delivery Controller installation media in the appropriate

drive.


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



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 Agent1. Log on to the computer as a local user with local administration rights.



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

The Citrix Virtual Desktop Agent Setup Wizard starts.


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.


Upgrading to a Different Edition of XenDesktopTo 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=editionStringwhere 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 XenDesktopThis 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 Agent1. Insert the Desktop Delivery Controller installation media in the appropriate

drive.


2. On the Welcome page, click Remove Virtual Desktop Components.




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 ComponentsThis 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 components1. 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.



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.


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 components1. Insert the Desktop Delivery Controller installation media in the appropriate

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

6

Preparing and Provisioning Desktops

OverviewThis 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 fromhttp://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.




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

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


To create a vDisk1. 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.


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.


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.


To set the vDisk access mode1. 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 template1. 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.

7

Creating and Updating Desktop Groups

OverviewThis 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, pre-assigned, 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-come-first-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


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 computer’s 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.

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


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.


To enable logging on the XenDesktop Setup WizardTo 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 loggingTo 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.


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 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 group’s 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.



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 group’s 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 PoolIf 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 pools1. 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.


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


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 group’s 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.


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 group’s 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 GroupsYou 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 ControlIf 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 Gateway1. 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:


• 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 PoolYou 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 pool1. 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. 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 BehaviorYou 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 desktops1. 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 desktops1. 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.


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 OptionsYou 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 options1. 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 128-bit encryption and the ICA connection using basic encryption.

• 40-Bit (RC5). Encrypts the ICA connection with RC5 40-bit encryption.

• 56-Bit (RC5). Encrypts the ICA connection with RC5 56-bit encryption.

• 128-Bit (RC5). Encrypts the ICA connection with RC5 128-bit encryption. This is the default.


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 comma-separated.

• 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)


• 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 file1. Ensure that you are logged on to an account with full administrator

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 pre-assigned 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 fileThe 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. Ensure that you are logged on to an account with full administrator permissions.

2. Expand the Desktop Groups node in the console tree and select the relevant desktop.


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 pre-assigned 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 GroupsAfter 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


To update a desktop group1. Ensure that you are logged on to an account with full administrator

permissions.

2. Expand the Desktop Groups node in the console tree and select the relevant group.


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 group

Desktop Group Name

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.


Add/remove users for a pooled or assign-on-first-use desktop group

Users

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-first-use 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 pre-assigned desktop group

Virtual Desktops and Users

When you remove users (by clicking Unassign), this only removes the user’s 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 assigned VMs

Logoff Behavior

Update Property to select


To configure user-driven desktop restartYou 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 user-driven desktop restart is currently enabled, the Disable user-driven desktop restart task appears instead.

To delete a desktop group1. 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.

8

Customizing Your Desktop Delivery Controller Environment

OverviewAfter 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 Administrator’s 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 Administrator’s 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


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 AdministratorsTo 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 ControlActive 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 TasksWhen 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

8 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, seehttp://support.citrix.com/article/CTX109977/.

To create a new Desktop Delivery Controller administrator1. 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:

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

8. Click Finish.

Configuring USB SupportYou 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



• 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 Administrator’s Guide or the Client for Linux Administrator’s 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 Administrator’s Guide or the Client for Linux Administrator’s Guide.

• 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”


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 Administrator’s Guide.

If you are using XenApp for Virtual Desktops, see “USB Drive Mapping Limitations” on page 116.

Support for USB Mass Storage DevicesFor 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:

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.

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.




Optimizing the User ExperienceThis 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 SettingsBy 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.

http://msdn2.microsoft.com/en-us/library/ms813808.aspx

http://support.microsoft.com/kb/300022/


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 TimersYou 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):


HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\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):

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\DisconnectTimer\enabled


To update the disconnect timer, create the following registry key (DWORD):

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\SessionDisconnectTimer\MaxDisconnectTime

and set the maximum time in minutes to wait before logging off a disconnected session.

Disabling RDPIf 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 inhttp://technet.microsoft.com/en-us/library/bb457106.aspx.

Removing the Shut Down CommandCitrix 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.

http://technet.microsoft.com/en-us/library/bb457106.aspx


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.

9

Managing Your Desktop Delivery Controller Deployment

OverviewThis 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 Administrator’s 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.


Putting Desktops into Maintenance ModeIf 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 mode1. 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 SessionsTo view sessions for a desktop group1. Select the relevant desktop group in the console tree.

2. Select the Virtual Desktops In Use view.

To view all sessions for a particular user1. 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.

9 Managing Your Desktop Delivery Controller Deployment 105

To disconnect or log off a session1. 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 user’s 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 users1. 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 MachinesFor 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 machines1. Select the relevant desktop group in the console tree.

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.


To shut down and restart virtual machines1. Select the relevant desktop group in the console tree.

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 VM’s 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 VM’s 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 FarmsIf, 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 controller’s existing farm and the controller’s 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.


To migrate a controller to another farm1. 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 Administrator’s 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 Farms1. 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 farm’s 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.


Updating License Server SettingsDuring 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 farm’s 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 server’s 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 fromhttp://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 fromhttp://support.citrix.com/pages/licensing/.

To specify a license server for the farm1. 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.


www.mycitrix.com

www.mycitrix.com

www.mycitrix.com



To specify a license server for an individual controller1. 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.

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 HostingUsing XenApp, you can deliver an application to users either by streaming it to the user’s 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.



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 desktop’s 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 Using XenApp for Virtual Desktops 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 ConsiderationsDo 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 Administrator’s Guide.

Management Console ConsiderationsCo-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.


Note: You must install the XenDesktop Presentation Server Console on the same computer as the XenDesktop Access Management Console.

Installing XenApp from the Product MediaCitrix 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 ConsiderationsA 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 DeliveryThis 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




These recommendations are discussed in more detail below.

Installing the XenApp PluginsInstall 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 user’s 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 Administrator’s 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 AuthenticationPass-through authentication allows the XenApp Plugin to access a user’s 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 Administrator’s 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 PolicyTo 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.


To ensure your users’ local drives are mapped, configure a policy on the XenApp server.

To map network drives in XenApp1. 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 LimitationsSome 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 ApplicationsIn 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.


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 SupportIf 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 ConsiderationsUser 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.

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


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

Option Description

11 121

ExamplesThe -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 Componentsetup.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 Serversetup.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 FarmThe 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.


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:

You must ensure that Microsoft .NET Framework 3.5 has already been installed before you install the Virtual Desktop Agent.

Configuring Active Directory Using ADSetupADSetup 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.

Property Description

CONFIGURE_WINDOWS_FIREWALL Values:0 = Do not adjust Windows firewall1 = 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

http://msdn2.microsoft.com/en-us/library/aa367988.aspx

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.

http://msdn2.microsoft.com/en-us/library/aa366101(VS.85).aspx

http://www.ietf.org/rfc/rfc2253.txt

Index 125

Index

Aaccess control

configuring 83Access Gateway

creating Web sites for remote access 19Access Management Console 12

starting 53access mode

setting for vDisk 73Active Directory

configuring 50configuring using ADSetup 122containers 16delegating access control 94Organizational Units 16replication 17security groups 16Service Connection Points 16using with Desktop Delivery Controller 15

administrator permissionsconfiguring 94

administratorscreating 95

ADSetup command-line tool 122advanced settings

configuring for desktop groups 83appliances

connecting from 28assigned-on-first-use desktops

definition 75

Bbase desktop VM

adding to Provisioning Server database 71creating 68imaging to Provisioning Server vDisk 72installing target device 71

blade-based desktop groupscreating 82

CCitrix Desktop Receiver

installing 61Citrix Desktop Service 57Citrix ICA Service 58Citrix policies

creating 93Citrix products

licensing 46Citrix XenApp 111client drive mapping 97client options

configuring 86command-line parameters for Setup.exe 119connection timers

configuring 99connections to desktops

preventing temporarily 104controllers

adding to farms 51migrating to other farms 106

Ddefault Web sites

modifying 18delegated administration

configuring 94Desktop Delivery Controller

removing 64upgrading 62

desktop group typesoverview 75


desktop groupscreating 75creating using XenDesktop Setup Wizard 76deleting 92updating 89

desktop privilegesplanning 21

desktopsmigrating to other farms 107user-driven restart 92

discoveryrunning 53

documentation 9domain-joined computers

connecting from 30downloads 44

Eeditions 44edition, upgrading 63endpoint devices

security planning 22exporting desktop and user data 87

Ffarm

creating 47planning 11

farm data storecreating 47hosting on separate server 50

fat client devicesconnecting from 31

firewallsconfiguring manually 60planning 20

Iidle pool

configuring 84importing desktop and user data 87installation command-line parameters 119installation media 44installing Desktop Delivery Controller on a single server

47IPSec 20

Llicense server settings

updating 108licensing 46–47

updating license server settings 108logoff behavior

assigned desktops 85configuring 85pooled desktops 85

logsPool Management 79Provisioning Server 68XenDesktop Setup Wizard 79

Mmaintenance mode

desktops 104management consoles 12

installing separately 52messages

sending to users 105mixed farm support 23multiple pools

creating 81

OOracle database

using 50Organizational Unit

creating 50

PPC-based desktop groups

creating 82permissions

configuring 94planning

network environment 26user types 25

policiescreating 93

Pool Management loggingenabling 79

pooled desktopsdefinition 75

pre-assigned desktopsdefinition 75

Presentation Server Console 12

Index 127

ProductEdition.exe 63Provisioning Server

installing 56logs 68

Provisioning Server databaseadding base desktop VM 71

Provisioning Server templatecreating 73

RRDP

disabling 100remote computers

connecting from 35replication, effects of 17repurposed computers

connecting from 30restarting desktops 92

SSecure Gateway 19SecureICA 20security planning 19sessions

disconnecting 105logging off 105viewing for desktop groups 104viewing for user 104

Setup.exe command-line parameters 119Shut Down command

removing 100smart cards 37

configuring authentication methods 39endpoint requirements 38readers supported 37removing 40types supported 37

SQL Serverusing 50

support and training 10

Ttarget device

installing on base desktop VM 71template

creating 73time zone settings

configuring 98training and support 10

Uunattended install 119updating

license server settings 108upgrading 23, 61

to different edition 63USB policy rule 96USB support

configuring 95user privileges

planning 21user-driven desktop restart 92users

planning user experience 25

VvDisk

creating 70imaging 72setting access mode 73

Virtual Desktop Agentinstalling 57installing using XdsAgent.msi 122removing 63upgrading 62

virtual machinescreating using XenCenter 68installing target device 71restarting 106shutting down 106starting 105

VM-based desktop groupscreating using Access Management Console 79creating using Setup Wizard 76

WWeb Interface

using with Desktop Delivery Controller 18Web sites

modifying 18

XXdsAgent.msi

properties 122XenApp 111


XenDesktop Setup Wizard 76enabling logging 79installing 57removing 65

XenMultiPool.exe 81XenServer

installing 54pools 81replacing default SSL certificate 54

xdadminguide

Documents