Citrix eDocs product documentation library http://edocs.citrix.com 2011, Citrix Systems, Inc. All rights reserved.

XenDesktop 5 Contents 1. XenDesktop Technology Preview 1.1. What's New 1.2. Known Issues 1.3. Install and Set Up 1.4. Using the new HDX features and enhancements 1.4.1. Configuring HDX MediaStream Flash Redirection 1.4.1.1. Configuring HDX MediaStream Flash Redirection on the Server 1.4.1.2. Configuring HDX MediaStream Flash Redirection on the User Device 1.4.2. Configuring Audio 1.4.2.1. Avoiding Echo During Multimedia Conferences With HDX RealTime 1.4.3. Video Conferencing with HDX RealTime Webcam Video Compression 1.4.4. Redirecting Aero Functionality 1.4.5. Increasing 2D and 3D Application Scalability and Performance 1.4.6. Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors 1.4.7. Assigning Priorities to Network Traffic 1.5. HDX 3D Pro 1.5.1. System Requirements 1.5.2. Plan 1.5.3. Install and Set Up 1.5.4. Manage 1.5.5. HDX 3D Pro User Experience 1.6. New and Updated Policy Settings 1.6.1. Flash Redirection Policy Settings 1.6.2. Audio Policy Settings 1.6.3. Bandwidth Policy Settings 1.6.4. Desktop UI Policy Settings 1.6.5. Caching Policy Settings 1.6.6. Multimedia Policy Settings 1.6.7. Multi-Stream Connections Policy Settings 1.6.8. TWAIN Devices Policy Settings 1.6.9. Visual Display Policy Settings 2. XenDesktop 5 Service Pack 1 2.1. Installing and Upgrading to XenDesktop 5 Service Pack 1 2.2. Managing Licensing 2.3. Using IntelliCache with XenDesktop 3. About This Release 3.1. Key Features 3.2. XenDesktop Components 3.3. What's New 3.4. XenDesktop Features and Editions 3.4.1. Features in XenDesktop VDI Edition 3.4.2. Features in XenDesktop Enterprise Edition 3.4.3. Features in XenDesktop Platinum Edition 3.5. Information for Customers of Previous Versions 3.6. Known Issues 4. System Requirements 4.1. Requirements for Controllers 4.2. Database Requirements 4.3. Separate Component Requirements 4.4. Active Directory Requirements 4.5. Virtual Desktop Agent Requirements 4.6. Host Requirements

4.7. Requirements for Machine Creation Services 5. Plan 5.1. High Availability Planning 5.2. Active Directory Considerations 5.3. Web Interface Considerations 5.4. Delegated Administration 5.5. Security Planning for XenDesktop 5.6. User Access and Experience 5.7. High Availability of the Virtual Desktop Agent 6. Quick Deploy 7. Evaluate 7.1. Installing and Configuring the Evaluation Deployment 7.2. XenDesktop User Experience 8. Install and Set Up 8.1. XenDesktop Installation Media and Downloads 8.2. Installing and Removing XenDesktop Server Components 8.3. Installing and Removing the Virtual Desktop Agent 8.3.1. To configure firewalls manually 8.4. To use Windows XP virtual desktops with Single Sign-on 8.5. Installing and Removing Wyse Xenith 8.6. To configure a XenDesktop site 8.6.1. To replace the default XenServer SSL certificate 9. Upgrade and Migrate 9.1. Upgrading XenDesktop Components 9.2. Data Import and Export Details 9.3. Exporting Data from a XenDesktop 4 Farm 9.4. Editing the Migration Tool XML File 9.5. Importing Data into a XenDesktop 5 Site 9.6. Post-Migration Tasks 9.7. Migrating from XenDesktop 4 to XenDesktop 5: an Example 10. Manage 10.1. Creating and Provisioning Desktops 10.1.1. Creating Machine Catalogs 10.1.1.1. Choosing the Machine Type 10.1.1.2. Preparing a Master VM 10.1.1.3. Providing Active Directory Computer Accounts 10.1.1.4. To create a new machine catalog 10.1.2. Managing Machine Catalogs 10.1.2.1. Updating User Desktops 10.1.2.2. Adding More Machines to a Catalog 10.1.2.3. To manage Active Directory computer accounts 10.1.2.4. To delete a machine catalog 10.2. Allocating and Managing Desktops 10.2.1. About Desktop Groups 10.2.1.1. Examples of Desktop Groups 10.2.2. To create a desktop group 10.2.3. To find desktops, sessions, and desktop groups 10.2.4. To import and export user data 10.2.5. To secure desktop groups 10.2.6. To change the display properties of desktops 10.2.7. To power manage machines 10.2.8. To restrict access to machines 10.2.9. To reallocate desktops 10.2.10. To shut down and restart desktops 10.2.11. To remove desktops from desktop groups 10.2.12. To delete desktops from catalogs 10.2.13. To enable or disable maintenance mode 10.2.14. To manage desktop sessions 10.3. Managing Your Controller Environment 10.3.1. About Controller Discovery 10.3.2. To add a controller 10.3.3. To remove a controller

10.3.4. To move a controller to another site 10.3.5. To configure SSL on XenDesktop controllers 10.4. Configuring Hosts 10.4.1. To create a host 10.4.2. Editing a Host 10.4.3. To edit a connection 10.4.4. To put a connection into maintenance mode 10.4.5. Managing Machines 10.4.6. To delete a host 10.4.7. To delete a connection 10.5. Using Smart Cards with XenDesktop 10.5.1. Smart Card Types and Readers Supported 10.5.2. User Device Requirements for Smart Cards 10.5.3. Secure Use of Smart Cards 10.5.4. Configuring Smart Card Authentication 10.5.5. Managing Smart Card Use 10.5.6. Removing Smart Cards 10.6. Working with XenDesktop Policies 10.6.1. Navigating Citrix Policies and Settings 10.6.2. Creating Policies 10.6.3. Configuring Policy Settings 10.6.4. Applying XenDesktop Policies 10.6.4.1. To apply a policy 10.6.5. Using Multiple Policies 10.6.5.1. Prioritizing Policies and Creating Exceptions 10.6.6. Determining Which Policies Apply to a Connection 10.6.6.1. To simulate connection scenarios with Citrix policies 10.6.6.2. Troubleshooting Policies With No Configured Settings 10.6.7. Applying Policies to Access Gateway Connections 11. Monitor 12. Customize 12.1. Delegating Administration Tasks 12.2. Printing with XenDesktop 12.3. Configuring USB Support 12.4. Support for USB Mass Storage Devices 12.5. Optimizing the User Experience 12.5.1. Enhancing the User Experience With HDX 12.5.1.1. Configuring HDX MediaStream Flash Redirection 12.5.1.1.1. Configuring HDX MediaStream Flash Redirection on the Server 12.5.1.1.2. Configuring HDX MediaStream Flash Redirection on the User Device 12.5.1.2. Configuring Audio 12.5.1.2.1. Avoiding Echo During Multimedia Conferences With HDX RealTime 12.5.1.3. HDX RealTime Webcam Video Compression for Video Conferencing 12.5.1.4. Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors 12.5.2. Configuring Time Zone Settings 12.5.3. Configuring Connection Timers 12.5.4. Workspace Control in XenDesktop 12.5.5. Removing the Shut Down Command 13. Integrate 13.1. Using Microsoft System Center Virtual Machine Manager 2008 with XenDesktop 13.2. Using VMware with XenDesktop 13.3. Using XenApp with XenDesktop 13.3.1. Application Streaming Compared to Hosting 13.3.2. Before Installing XenApp in a XenDesktop Environment 13.3.3. Optimizing Application Delivery 13.3.3.1. Installing the Online and Offline Plug-ins 13.3.3.2. Setting up Pass-through Authentication 13.3.3.3. Mapping Network Drives Using a Policy 13.3.4. USB Drive Mapping Limitations 14. Reference 14.1. About the XenDesktop SDK 14.2. XenDesktopServerSetup.exe

14.3. XenDesktopVdaSetup.exe 14.4. Policy Settings Reference 14.4.1. Policy Settings: Quick Reference Table 14.4.2. ICA Policy Settings 14.4.2.1. Audio Policy Settings 14.4.2.2. Auto Client Reconnect Policy Settings 14.4.2.3. Bandwidth Policy Settings 14.4.2.4. Desktop UI Policy Settings 14.4.2.5. End User Monitoring Policy Settings 14.4.2.6. File Redirection Policy Settings 14.4.2.7. Graphics Policy Settings 14.4.2.7.1. Image Compression Policy Settings 14.4.2.8. Keep Alive Policy Settings 14.4.2.9. Multimedia Policy Settings 14.4.2.9.1. HDX MediaStream for Flash (client side) Policy Settings 14.4.2.9.2. HDX Multimedia for Flash (server side) Policy Settings 14.4.2.10. Ports Policy Settings 14.4.2.11. Printing Policy Settings 14.4.2.11.1. Client Printers Policy Settings 14.4.2.11.2. Drivers Policy Settings 14.4.2.11.3. Universal Printing Policy Settings 14.4.2.12. Session Limits Policy Settings 14.4.2.13. Session Reliability Policy Settings 14.4.2.14. USB Devices Policy Settings 14.4.3. Server Session Settings 14.4.4. Virtual Desktop Agent Settings 14.4.4.1. CPU Usage Monitoring Settings 14.4.4.2. ICA Latency Monitoring Settings 14.4.4.3. Profile Load Time Monitoring Settings XenDesktop 5 Updated: 2011-05-10 This section of the library provides up-to-date product information about installing, configuring, and administering a XenDesktop 5 deployment: Introduction Licensing Your Product

XenDesktop 5 System Requirements XenDesktop Scalability Guidelines Planning a XenDesktop Deployment Evaluating XenDesktop 5 Known Issues in XenDesktop 5 Issues Fixed in XenDesktop 5

Documentation is also available for XenDesktop 5 Service Pack 1. Other XenDesktop Features Citrix XenDesktop includes additional features in each edition to help enhance the user experience. This table includes links to the product documentation located in Citrix eDocs or in the Citrix Knowledge Center describing these features. Branch optimization powered by Citrix Branch Repeater XenServer SmartAccess powered by Citrix Access Gateway

XenApp

XenClient StorageLink EdgeSight for Virtual Desktops Workflow Studio orchestration

Provisioning services Profile management XenVault Single sign-on

Cant find what youre looking for? If youre looking for documentation for previously released versions of this product, go to the Citrix Knowledge Center. For a complete list of links to all product documentation in the Knowledge Center, visit http://support.citrix.com/productdocs/. 1. XenDesktop Technology Preview Updated: 2011-05-20 Disclaimers This document is furnished "AS IS." Citrix Systems, Inc. disclaims all warranties regarding the contents of this document, including, but not limited to, implied warranties of merchantability and fitness for any particular purpose. This document may contain technical or other inaccuracies or typographical errors. Citrix Systems, Inc. reserves the right to revise the information in this document at any time without notice. This document and the software described in this document constitute confidential information of Citrix Systems, Inc. and its licensors, and are furnished under a license from Citrix Systems, Inc. This document and the software may be used and copied only as agreed upon by the Beta Agreement. XenDesktop Technology Preview consists of: HDX-related new features and enhancements, including second generation Flash Redirection, Windows Media Redirection, and 3D Pro Enhancements. HDX Monitor 2.0. An interactive graphical dashboard that enables you to monitor and analyze HDX performance throughout your domain. When potential problems are detected, solutions are suggested. To download HDX Monitor, go to http://hdx.citrix.com/sites/default/files/hdx-monitoring2.0/setup.exe. Full details about the new features and enhancements, and how to use them, are provided in this section. For all other XenDesktop features, continue to use the documentation provided for XenDesktop 5. The following table provides links to the documentation for all updated components, and to the list of issues that have been fixed in this feature pack: Note: These topics may not have been fully reviewed yet and are not considered complete at this time. What's new in XenDesktop Technology Preview Installing XenDesktop Technology Preview

Using the new HDX features and enhancements XenDesktop Technology Preview New and Updated Policy Settings XenDesktop 5 Service Pack 1 Known Issues in XenDesktop Technology Preview Citrix Receiver 3.0 Issues fixed in XenDesktop Technology Preview

1.1. What's New in XenDesktop Technology Preview Updated: 2011-05-19 XenDesktop Technology Preview includes the following new features and enhancements: HDX MediaStream Second Generation Flash Redirection. Adobe Flash content can be redirected to the user device for local rendering in many more cases than before, resulting in even higher server scalability and a

great user experience. Flash Redirection now supports WAN-connected users. Good results with video playback have been observed, even at high latency. Server-Rendered Video. For multimedia content that is rendered server-side, the need to configure complex policies for best performance under different network conditions has been eliminated. HDX MediaStream automatically adjusts to the effective network bandwidth to use the level of compression that delivers the best video experience (image quality and frame rate) while displaying non-video regions, such as text, at full clarity. On challenging network connections, where the Session Reliability feature helps to provide the best possible user experience, it should no longer be necessary to configure two virtual CPUs for the virtual desktop. The CGP Service that supports Session Reliability is now optimized to consume much less CPU than before. Windows Media Redirection. A new end-to-end flow control and frame dropping capability has been introduced. This improves the user experience when the bandwidth available for viewing a Windows media video (WMV, MPEG, AVI, DivX, etc.) is less than what is required by the bit rate of the video, an issue increasingly experienced by customers as videos are recorded at higher resolution. This technology allows multimedia redirection to be used in more access scenarios, further reducing server CPU consumption. Priority is given to smooth audio playback and audio-video synchronization at the expense of the video, so video frames are dropped when the available bandwidth is too low. In Citrix's own comparison testing, this technology delivered a better-than-local user experience under the same bandwidth constraints. Multi-Stream ICA including UDP for Audio. XenDesktop Technology Preview introduces the option of delivering ICA over multiple streams: four TCP/IP streams and one UDP/RTP stream (for audio). This gives full flexibility for QoS routing over the network and provides superior audio quality when there is packet loss or congestion. Citrix Receiver for Windows. Various enhancements in Citrix Receiver (formerly the Citrix online plugin) offer benefits to users of softphones and unified communications clients: UDP and RTP (Real-time Transport Protocol) support Improved multi-tasking with real-time applications Smoother audio when network latency fluctuates ("jitter") Improved echo cancellation when using speakers and a microphone HDX Broadcast When running a typical office user workload, as represented by the standard Login Virtual Session Indexer (VSI) "Medium" knowledge worker test, Citrix expects customers to see a 12 to 25% reduction in bandwidth consumption along with reduced CPU consumption on the server (leading to higher server scalability) and improved desktop image quality on low bandwidth connections. In addition, RDP protocol support in HDX Broadcast has been enhanced to support RDP 7.1 with RemoteFX. For more information, see HDX RichGraphics. HDX RichGraphics Microsoft RemoteFX Support. Microsoft RemoteFX, a feature of Windows Server 2008 R2 SP1 HyperV, uses server-side graphics hardware acceleration to deliver the full Windows 7 Aero and multimedia experience over a LAN-like connection. XenDesktop Technology Preview supports RemoteFX using enhancements to RDP protocol support in HDX Broadcast and to Citrix Receiver for Windows. This is the first phase of a vision and collaboration announced by Citrix and Microsoft in March 2010. For more information about using Microsoft RemoteFX with XenDesktop, see: http: //support.citrix.com/article/ctx129509/. Windows 7 Aero Redirection. Aero Redirection leverages client-side graphics hardware acceleration to deliver the full Windows 7 Aero experience (including glass effects, Flip 3D, and Aero Peek) over a LAN-like connection. Using the DirectX 9 graphics processing capabilities of the user's rich client device (Windows XP/Vista/7 PC or higher-end thin client), Aero Redirection delivers an outstanding user experience that truly feels "like local", if not better. This is the first phase of a powerful new HDX technology based on DirectX graphics command remoting. Note: This feature is disabled by default. To use it, expand the HDX Policy node and click Users. In the ICA options select Desktop UI, and in the Settings area select Aero Redirection. If Aero Redirection has been enabled, click Edit; otherwise, click Add. From here, you can enable or

disable Aero Redirection. 3D Pro Enhancements. The key enhancement to HDX 3D Pro in XenDesktop Technology Preview is true multi-monitor support. This extends Citrix's powerful solution for high-end 3D graphics applications and very large models from being best-in-class for remote access to enabling also full desktop replacement. Other enhancements include deep compression support for NVIDIA's new Fermi architecture graphics cards, animated cursor support on Windows 7, and administrator control of the configuration tool for end users. Software installation and upgrade are also simplified through integration with the standard XenDesktop Virtual Desktop Agent. Citrix also plan to test XenDesktop Technology Preview extensively with the Multi-GPU Passthrough feature of XenServer, currently available for Tech Preview with Citrix XenServer "Project Boston" Beta release on the Citrix Downloads Web site. HDX 3D Pro supports the Microsoft WDDM display driver model, enabling users to access their multi-monitor Windows 7 office PC from home or a remote location over a high speed Internet connection. The software intelligently collapses applications from the multiple monitors on the host machine to the available monitors on the remote device, and blanks the host monitors for data security. HDX Plug-n-Play New HDX Plug-n-Play capabilities include support for WAN-connected scanners (via the TWAIN standard) and Japanese and Korean keyboards. Usability of removable storage devices has been improved and Client Drive Mapping now supports read-only access as well as Universal Naming Convention (UNC) path support. 1.2. Known Issues in XenDesktop Technology Preview Updated: 2011-05-23 Windows 7 Aero Redirection can be installed only on virtual machines hosted on XenServer 5.6 and VMware ESX. If you want to install it on Hyper-V, at a command prompt, type msiexec /i XdsAgent_x86. msi CITRIXWDDMONHYPERV=1 ENABLE_HDX_PORTS=1 /l*v ".\xdsagent.log" /qb+. This feature cannot be installed on virtual desktops hosted on physical machines. The Windows Media Player available on the Windows 7 and Windows XP operating environments might not play files encoded in the following formats: mpeg, mpg, avi (MPEG4-V2), Divx. No workaround currently exists. [#256418] When the Virtual Desktop Agent for HDX 3D Pro is installed on a Windows 7 computer, Windows Aero functionality is disabled for all users of that computer, including local users. Using a Remote Desktop Connection (RDP) to connect to a virtual desktop running Windows Vista or Windows 7 may cause the system to stop responding and an error message to appear on a blue screen. If this occurs, attempt to connect again. [#259314] Sluggish performance may occur on user devices using a Windows Display Driver Model (WDDM) driver with Windows Aero disabled locally, but enabled remotely. This configuration causes bitmaps to be rendered in the Graphics Processing Unit (GPU) video memory and then copied into the GDI system memory for display, consuming a great deal of resources. If this condition occurs, either enable Windows Aero on the user device, or disable Windows Aero on the remote device. [#260765] Microsoft PowerPoint 2010 may not behave as expected in a multi-monitor XenDesktop session connected using Citrix Systems WDDM driver. If a user launches a session from a pooled desktop and attempts to run a slideshow from a streamed or locally-installed PowerPoint 2010 application on a non-primary monitor, the monitor may display a black screen on a Windows 7 desktop session. To prevent this from happening, run the slideshow on the primary monitor. [#261123] If HDX MediaStream Multimedia Acceleration is disabled, for example by setting SpeedScreenMMA=off, and a user plays a movie file in a XenDesktop session, video may not play as expected and only audio may be heard, or Windows Media Player may display an error message stating the video cannot be played. [#257853] Mapped client drives may not display properly or be accessible after a user logs back on to a session that they previously logged out of. This issue affects only private desktops, not shared desktops. If this occurs, restart the Citrix ICA Service and ask the user to log back on again. [257363] Hardware acceleration may be unavailable for 3D applications when users first connect to a Windows 7

host computer. To work around this issue, users must disconnect from the session and then reconnect. [#258836] When connecting to a Windows XP host computer with the Virtual Desktop Agent for HDX 3D Pro installed, users may experience slow responses to input when CPU-based compression is used. [#260182] The "Server Execution Failed " error message may appear intermittently after the Microsoft Windows Media Player is closed. If this occurs, use Windows Task Manager to end the wmplayer.exe process and replay the media file. [#261560] Video playback may be heavily distorted when the video player switches from full screen mode to normal mode. If this happens, disable Windows Aero on the user device and use Windows 7 Basic. [#261295] Virtual desktop agents upgraded from Citrix XenDesktop 5 to this Technology Preview release fail to launch. Rather than upgrade, uninstall the virtual desktop agents from XenDesktop 5 and install a new virtual desktop agent from the Technology Preview release. [#261644] On a multi-monitor host computer with the Virtual Desktop Agent for HDX 3D Pro installed and where the primary monitor is attached with a DisplayPort connector, switching the primary monitor off and then on again while a user is connected causes monitor blanking to fail on the host computer. [#260099] When dragging or expanding a window in a Windows 7 or Windows XP multiple monitor environment, the window may not respond to mouse movements as expected. The window may lag behind the mouse pointer or jump to a new position. When released, the window may continue to follow the mouse movement. [#261609] Audio quality may be poor in user devices running Windows XP with the Audio quality policy set to Medium - optimized for speech. To avoid this, set the Audio quality policy to High - high definition audio. [#261649] Audio volume for Flash content played on a user device when Flash Redirection is used does not correspond to the volume control in the notification area in the server desktop. As a result, the audio may play louder than expected. Users' should adjust the volume through the Flash player's control or, if available, a physical volume control on the user device. 1.3. Installing and Upgrading to XenDesktop Technology Preview Updated: 2011-05-18 You can perform either a new installation or an upgrade to XenDesktop Technology Preview. If XenDesktop is not installed already, you can perform a single installation that incorporates the latest XenDesktop server components and Virtual Desktop Agent. If XenDesktop 5 or XenDesktop 5 Service Pack 1 is installed already, you can install XenDesktop Technology Preview as an upgrade. This upgrades the Virtual Desktop Agent but you can also choose to upgrade to the latest XenDesktop server components, including the latest Citrix Policy settings. Note: Although you can use the Virtual Desktop Agent in this Technology Preview release with both XenDesktop 5 and XenDesktop 4 controllers, the policies used to configure the HDX features are available only with XenDesktop 5 controllers running the latest Citrix Policy settings; Citrix therefore recommends you upgrade to the latest Policy settings to take advantage of the new HDX features and enhancements included in this Technology Preview. Planning your Installation XenDesktop Technology Preview is provided on disc or as a web download. It consists of 2 images: an upgrade image and a full image. The upgrade image consists of Virtual Desktop Agent updates only The full image consists of Virtual Desktop Agent updates and server component updates The following table explains which image to use. To perform: A new installation of XenDesktop Use this image: Read these sections: Full imageInstalling and upgrading XenDesktop 5 Technology Preview Server Components; Installing and upgrading the Virtual Desktop Agent

An upgrade of the Virtual Desktop Agent only An upgrade from XenDesktop 5 or XenDesktop 5 Service Pack 1, and upgrade of the Virtual Desktop Agent System Requirements

Upgrade image Installing and upgrading the Virtual Desktop Agent Full imageInstalling and upgrading XenDesktop 5 Technology Preview Server Components; Installing and upgrading the Virtual Desktop Agent

For information about system requirements see XenDesktop 5 System Requirements and XenDesktop 5 Service Pack 1 documentation. Note the following updates to these requirements: Virtual Desktop Agent Requirements - Virtual machines can run Windows 7 32-bit or 64-bit. Host Requirements - XenDesktop also lets you manage virtual desktops supported on Citrix XenServer 6. Unless you intend using the Multi-GPU Passthrough feature of HDX 3D Pro, Citrix recommends you do not upgrade to XenServer 6. For more information, see the XenServer documentation. For information about system requirements for HDX 3D Pro, see System Requirements for HDX 3D Pro. About the Virtual Desktop Agent The Virtual Desktop Agent can be installed in one of two modes in this Technology Preview release. Before you install or upgrade, decide which mode you require: Virtual Desktop Agent. Select the standard Virtual Desktop Agent to take advantage of the new features and enhancements available with XenDesktop Technology Preview, including HDX features such as Second Generation Flash Redirection, audio, and Windows Media Redirection. For more information about the new features and enhancements, see What's New in XenDesktop Technology Preview. Virtual Desktop Agent for HDX 3D Pro. Select the Virtual Desktop Agent for HDX 3D Pro if you intend using the HDX 3D Pro feature of XenDesktop Enterprise and Platinum editions to deliver desktops and applications that use a graphics processing unit (GPU) for hardware acceleration. To install the Virtual Desktop Agent for HDX 3D Pro, you require a key file which you can obtain from: www.citrix.com/desktopvirtualization/earlyrelease. The key file is required for licensing purposes; during download of the key file, you are prompted for the number of users. Store the key file on a suitable place on the network that you can later access during installation. For more information about installing and configuring HDX 3D Pro, including installing from the command prompt, see About HDX 3D Pro. You can upgrade from a previous version of the standard Virtual Desktop Agent to the XenDesktop Technology Preview standard Virtual Desktop Agent. You cannot upgrade from the standard Virtual Desktop Agent to the Virtual Desktop Agent for HDX 3D Pro. To do this, you must uninstall the standard Virtual Desktop Agent and then install the Virtual Desktop Agent for HDX 3D Pro. You cannot upgrade from an earlier Virtual Desktop Agent for HDX 3D Pro to the XenDesktop Technology Preview Virtual Desktop Agent for HDX 3D Pro. You must uninstall the earlier Virtual Desktop Agent and any add-ons, and then install the XenDesktop Technology Preview Virtual Desktop Agent for HDX 3D Pro. Installing and upgrading the Virtual Desktop Agent If you require the Virtual Desktop Agent for HDX 3D Pro, ensure you have obtained the key file before you begin installation. Read Planning your Installation and the HDX 3D Pro topics for more information. The Virtual Desktop Agent must be present on the virtual machines (VMs) to which your users will connect. It enables machines to register with controllers and manages the HDX connection between the machines and the user devices. If you are using XenDesktop or Provisioning services to provision VMs, you need to install and configure the Virtual Desktop Agent only once; if you are using separate stand-alone virtual or physical machines you must install it on each of the machines so they can register with the controller to allow user connections. You can install the Virtual Desktop Agent from a console session or from an RDP session. Note that installing from an ICA session is not supported.

To install the Virtual Desktop Agent, insert the XenDesktop installation media in the appropriate drive or mount the ISO in the appropriate virtual machine (VM), and double-click Autoselect.exe. Caution: Citrix recommends you launch the Virtual Desktop Agent MSI (XdsAgent.msi) only through Autorun, not in standalone mode by double-clicking it. This is because the installation requires you to provide configuration information which the Virtual Desktop Agent needs to function correctly. Also, the MSI may not revert any changes that you make manually. However, if you do decide to launch the Virtual Desktop Agent MSI in standalone mode, see Launching the Virtual Desktop Agent MSI in Standalone Mode for guidance. The following is a summary of the steps you are prompted to complete: 1. On the Installation page, select Install Virtual Desktop Agent. 2. On the next page, select Advanced Install unless you are setting up a proof of concept evaluation deployment, in which case you should select Quick Deploy; setting up an evaluation deployment is described in Evaluating XenDesktop 5. The rest of this procedure describes only the steps to follow when you are carrying out an advanced installation. 3. Read and accept the End-User Licensing Agreement, and click Next. 4. Select Virtual Desktop Agent or Virtual Desktop Agent for HDX 3D Pro. If you select Virtual Desktop Agent for HDX 3D Pro, specify the key file you downloaded or navigate to its location; see the HDX 3D Pro topics for more information. Click Next. 5. On the Select Components to Install page, select the components you want to install and where you want to install them. 6. On the Controller Location page, specify the controllers in the XenDesktop site to which the Virtual Desktop Agent will connect, either by manually entering the locations or by selecting controllers from Active Directory. Alternatively, select Configure at a later time if you plan to specify controller locations later using Group Policy or by rerunning the Virtual Desktop Agent installer. Important: Ensure you specify the locations of all the controllers in the site, otherwise some user connections may be refused. For load balancing, the Virtual Desktop Agent automatically distributes connections evenly across the controllers. 7. 8. On the Virtual Desktop Configuration page, specify whether or not you want to enable user desktop shadowing and real time monitoring. Configure the agent as follows: Reconfigure the firewall. If the Windows firewall is detected, the necessary ports can be opened automatically for you. If another firewall is detected, you are told which ports you need to open manually for XenDesktop to operate successfully. You can also request to have the necessary ports opened for Windows Remote Assistance and Windows Remote Management. For information about configuring firewalls manually, see To configure firewalls manually. If this installation is running in a VM on a hypervisor, you can select to have the VM automatically optimized for use with XenDesktop. Optimization involves actions such as disabling offline files, disabling background defragmentation, and reducing the event log size. For full information on the optimization tool, see http://support.citrix.com/article/ctx125874/ 9. 10. Review the installation summary before clicking Install. When installation begins, progress is displayed on the screen. When installation is complete the default is to restart the machine; you must do this for the changes to take effect.

You can also install the Virtual Desktop Agent through a command-line utility; see: XenDesktopVdaSetup.exe. To deploy the Virtual Desktop Agent through Active Directory Group Policy, see http://support. citrix.com/article/ctx127301/. Note: When you install the Virtual Desktop Agent, a new local user group for authorized RDP users is automatically created. The group is called Direct RDP Access Administrators. For further information on using protocols other than ICA, see http://support.citrix.com/article/ctx121657/. XenDesktop requires desktops and controllers to have synchronized system clocks. This is required by the underlying Kerberos infrastructure that secures the communication between the machines. You can use normal Windows domain infrastructure to ensure that the system time on all machines is correctly synchronized. To add or remove components, select the Windows option for adding or removing programs, then select Citrix Virtual Desktop Agent. You can then select to add, remove, or reconfigure components, or remove the Virtual Desktop Agent completely. The Reconfigure the VDA option enables you to update the site selection and port numbers. Launching the Virtual Desktop Agent MSI in Standalone Mode Citrix recommends you launch the Virtual Desktop Agent MSI (XdsAgent.msi) only through Autorun, not in standalone mode by double-clicking it. However, if you decide to launch the MSI in standalone mode, you must provide the following configuration information or the Virtual Desktop Agent may not operate as expected: Add controller information or site details to the Windows registry. If the VM is to be optimized for XenDesktop performance, optimization steps must be carried out manually. For more information about the optimization tool, see http://support. citrix.com/article/ctx125874/ If the Windows Firewall is enabled, perform the following additional steps: Open firewall ports for ICA, Workstation Agent and CGP (TCP ports 1494, 80, 2598) For user desktop shadowing configuration, enable Remote Assistance and open the firewall port (TCP port 3389) For Real time monitoring, enable and secure Remote Management For HDX RealTime for Audio, open UDP ports 16500-16509. For more information about configuring firewalls manually, see To configure firewalls manually.

Caution: Not all of these port numbers are IANA registered and may be in use for other purposes. Installing and Upgrading XenDesktop 5 Technology Preview Server Components For a fresh installation of XenDesktop Technology Preview on a machine that does not already have XenDesktop installed, follow the same steps as for installing XenDesktop 5 server components. The installation process automatically detects which components require upgrade and these are shown in the Summary screen before installation proceeds. If XenDesktop 5 or XenDesktop 5 Service Pack 1 is installed already and you want to upgrade the server components, follow the same steps as for installing and upgrading XenDesktop 5 Service Pack 1. This upgrades the server components to include XenDesktop 5 Service Pack 1 together with the latest Citrix Policy updates. The installation process automatically detects which components require upgrade and these are shown in the Summary screen before installation proceeds. 1.4. Using the new HDX features and enhancements Updated: 2011-05-18 Citrix HDX includes a broad set of technologies that provide a high-definition user experience for today's media-rich user environments. XenDesktop Technology Preview includes many new HDX features and enhancements. The following topics explain how to configure and use the new HDX features and enhancements.

Quick Links Configuring HDX MediaStream Flash Redirection Configuring Audio Video Conferencing with HDX RealTime Webcam Video Compression Redirecting Aero Functionality Increasing 2D and 3D Application Scalability and Performance Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors Assigning Priorities to Network Traffic

1.4.1. Configuring HDX MediaStream Flash Redirection Updated: 2011-05-17 HDX MediaStream Flash Redirection allows you to move the processing of most Adobe Flash content to LANand WAN-connected users' Windows devices rather than using server resources. This processing includes animations, videos, and applications. By moving the processing to the user device, Flash Redirection helps reduce server and network load, resulting in greater scalability while ensuring a high definition user experience. Note: Two types of Adobe Flash Players are required to use Flash Redirection. One type is used with Windows Internet Explorer and is identified by Adobe as Flash Player for Windows Internet Explorer. This player is sometimes referred to as an ActiveX player. The second type is used with non-Internet Explorer browsers and is identified by Adobe as Flash Player for Windows - Other Browsers. This player is sometimes referred to as an NPAPI (Netscape Plugin Application Programming Interface) Flash Player.

System Requirements for Flash Redirection For user devices: The version of Citrix Receiver (formerly called the online plug-in) included with this Technical Preview is required on the user device to use the second generation Flash Redirection features. Online plug-in 12.1 is supported on the user device for the original, or legacy, Flash Redirection features only. A network connection exists and is enabled. To use XenDesktop Virtual Desktop Agents, establish a network connection between the user's Windows device and the agent. Adobe Flash Player 10.1 or above for Windows - Other Browsers is installed on the user device. Note: If an earlier version of the Flash Player is installed on the user device, or the Flash Player cannot be installed on the user device, Flash content is rendered on the server.

For servers running the Citrix XenApp Technical Preview and Citrix XenDesktop Technical Preview: Flash Player 10.1 or above for Windows Internet Explorer is installed on the servers running XenApp and XenDesktop's Virtual Desktop Agents. Internet Explorer 8 and Internet Explorer 7.

Caution: Flash Redirection requires significant interaction between the user device and server components. Therefore, this feature should be used only in environments where security separation between the user device and server is not needed. User devices should be configured to use the Flash Redirection feature only with trusted servers. Flash Redirection requires the Flash Player to be installed on the user device. Therefore, Flash Redirection should be enabled only if the Flash Player itself is secured.

Second Generation Flash Redirection Flash Redirection has been revised for use with: Citrix XenApp Technical Preview Citrix XenDesktop Technical Preview

The version of Citrix Receiver included with this Technical Preview New second generation Flash Redirection features include: WAN-connected user support. The second generation and legacy versions of Flash Redirection are complete and run in separate virtual channels. Intelligent Fallback, which allows Flash sessions, on a per-instance basis, to be determined to be more efficient when rendered on the server. The Flash URL Compatibility List replaces the original Flash URL Blacklist setting. Listed URLs can now be blocked or specified for rendering on the user device or the server.

1.4.1.1. Configuring HDX MediaStream Flash Redirection on the Server Updated: 2011-05-17 You can configure HDX MediaStream Flash Redirection settings on the server through the Policies node of Citrix Desktop Studio or Citrix AppCenter. You control the Flash Redirection features through the following Citrix User Policy settings: Flash backwards compatibility Flash default behavior Flash intelligent fallback Flash latency threshold Flash server-side content fetching URL list Flash URL compatibility list Flash event logging Flash acceleration Flash background color list

To enable backward compatibility The second generation of Flash Redirection can be configured to be backward compatible with its legacy features, supporting user devices with earlier versions of the online plug-in (now the Citrix Receiver). Those devices can access the legacy Flash Redirection features only. This is done by providing two separate virtual channels, one for each generation of Flash Redirection, on the servers and user devices. The following table shows the resulting level of functionality when using a mix of Flash Redirection modes. Connection Second generation on a user device and second generation on a server Legacy mode on a user device and second generation on a server Second generation on a user device and Legacy mode on a server Result Second generation Legacy mode Legacy mode

The Enable HDX MediaStream Flash Redirection on the user device setting on the user device must also be enabled. To use the backward compatibility feature: On the server running Desktop Studio or AppCenter, enable the Citrix User Policy setting Flash backwards compatibility. On the user device, enable the Enable HDX MediaStream for Flash on the user device setting, selecting the Always or Ask options. Note: Backwards compatibility is not available if the Only with Second Generation option is selected.

To establish the Flash acceleration default behavior The Citrix User Policy setting Flash Default Behavior lets you establish the default behavior of Flash acceleration. The default behavior can be overridden for individual Web pages and Flash instances based on the configuration of the Flash URL Compatibility List. In addition, on the user device, enable the Enable HDX MediaStream Flash Redirection on the user device setting. Three options are available in this second generation feature. Option Block Flash player Disable Flash acceleration Enable Flash acceleration Behavior The user cannot view any Flash content. Second generation and Legacy mode Flash Redirection, and server-side rendering are not used. The user can view server-side rendered Flash content if Flash Player for Windows Internet Explorer compatible with the content is installed on the server. Second generation and Legacy mode Flash Redirection is not used. Flash Redirection is used. Second Generation is available where its requirements are met. Legacy mode is available when backwards compatibility is enabled.

Enable Flash acceleration is the default and will be used if no option is selected. To set Flash intelligent fallback Use this setting if you do not want all instances of Flash content to be redirected for rendering on the user device. Typically, small Flash movies are frequently used to play advertisements. Flash intelligent fallback detects these instances and renders the content on the server. Using this Citrix User Policy setting causes no interruption or failure in the loading of the Web page or the Flash application. Configure the Flash intelligent fallback setting by selecting Enabled, which is the default, or Disabled. To set the Flash latency threshold The Flash latency threshold policy setting only applies to Legacy mode features. This Citrix User Policy is only applicable if Flash backwards compatibility is enabled. Flash Redirection Legacy mode measures the round trip latency between the server and user device the first time an individual browser or browser tab accesses an embedded Flash Player. This measurement includes both the latency of the network connection and any other latency in the data path. If the latency is determined to be within an acceptable threshold, Flash Redirection Legacy mode is used to render Flash content on the user device. If the latency is above this threshold, the Flash content is rendered on the network server if a Flash player is available there and delivered over the virtual channels. The default threshold setting is 30 milliseconds. Increasing the value over 30 milliseconds may result in a degraded user experience. For typical use, it is best practice not to increase the latency threshold setting. Configure the Flash latency threshold setting by typing a value between 0 and 30 in the Value field. To identify Web sites for server-side content fetching Flash Redirection downloads Flash content to the user device where it is played. The Flash server-side content fetching URL list setting allows you to specify Web sites whose Flash content can be downloaded to the server then sent to the user device. This setting works with the Enable server-side content fetching setting on the user device. This setting is frequently used when the user device does not have direct access to the Internet. The XenApp or XenDesktop server provides that connection. Consider the following when configuring the Flash server-side content fetching URL list setting: Add the URL of the Flash application; not the top-level .html page that instantiates the Flash Player to the list. Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list. Use a trailing wildcard to allow all child URLs, for example http://www.sitetoallow.com/*.

The prefixes https:// are used when present, but they are not required. Configure the Flash server-side content fetching URL list setting by clicking New to add new URLs to the list. Important: You must enable the Enable server-side content fetching setting on the user device for the Flash server-side content fetching URL list on the server to work. To specify where Flash content renders The second generation of Flash Redirection lets you specify whether Flash content from listed Web sites is: Rendered on the user device. Rendered on the server. Blocked from rendering. Consider the following when configuring the Flash URL compatibility list setting: Prioritize the list with the most important URLs, actions, and rendering locations at the top. Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list. Use a trailing wildcard to refer to all child URLs, for example http://www.sitetoblock.com/*). The prefixes https:// are used when present, but they are not required. Add sites containing Flash content that does not render correctly on the user device to the list, using the Render on Server or Block options. To configure the Flash URL compatibility list setting: 1. Click New to open the Add Flash URL Compatibility list entry dialog box. 2. Select an action (Render on Client, Render on Server, or Block). 3. In the URL Pattern box, type the URL of the Web site upon which you want to act. 4. Select the Flash instance you want to serve as a trigger. Select Any: The action occurs any time any Flash instance connects with the listed Web site. Select Specific: Type the Flash player ID. The action occurs only when this specific Flash instance connects with the listed Web site.

To enable server-side event logging Flash Redirection uses Windows event logging on the server to log Flash events. You can review the event log to determine whether Flash Redirection is being used and to gather details about any issues. The following are common to all events logged by Flash Redirection: Flash Redirection reports events to the Application log. The Source value is Flash. The Category value is None. In addition to the Windows event log, on computers with Windows 7 or Windows Vista, a Flash Redirection-specific log appears in the Applications and Services Logs node. Flash Redirection-specific log is also available on Windows Server 2008 R2 computers running this Early Release version of XenApp. If Windows XP is used, Flash Redirection log information is found only in the Windows application event log. Configure the Flash event logging setting for Legacy mode by selecting Enabled, which is the default, or Disabled. Configuration is not available for Second Generation Flash Redirection. To enable and disable the Legacy mode HDX MediaStream Flash Redirection from the server Legacy mode Flash Redirection is enabled on the server for client-side rendering by default. You can enable and disable Legacy mode Flash Redirection from the server through the Citrix User Policy setting Flash acceleration, in the Flash Redirection category.

Configure the Flash acceleration setting by selecting Enabled, which is the default, or Disabled. When Enabled is selected, all Flash content from sites not blocked by the Flash URL compatibility list is rendered on the user device using Legacy mode. If Disabled is selected, all Flash content is rendered on the server. To enable matching between the Web page and Flash instances Using the Flash background color list Citrix User Policy setting, you can match the colors of Web pages and Flash instances. This can improve the appearance of the Web page when using Flash Redirection. Click New and type the Web site URL followed by the appropriate 24-bit Web color hexadecimal number. For example, you can use: http://www.sitetomatch.com/* FF0000. 1.4.1.2. Configuring HDX MediaStream Flash Redirection on the User Device Updated: 2011-05-16 You can change the default settings on the user device with the Group Policy Object Editor. To configure HDX MediaStream Flash Redirection on the User Device with Group Policy Objects 1. Create or select an existing Group Policy Object. 2. Import and add the HDX MediaStream Flash Redirection - Client administrative template (HdxFlashClient.adm), available in: For 32-bit computers: %Program Files%\Citrix\ICA Client\Configuration\language. For 64-bit computers: %Program Files (x86)%\Citrix\ICA Client\Configuration\language.

Note: For details on creating Group Policy Objects and importing and adding templates, see the Microsoft Active Directory documentation at http://www.microsoft.com.

To enable Flash Redirection on the user device Configure Enable HDX MediaStream Flash Redirection on the user device to determine whether Flash Redirection is enabled on your users' Windows devices. If no configuration is set, one of the following will occur, based on your users' environment: Desktop Lock is used: Flash Redirection is enabled by default. All other conditions: The user receives a dialog box the first time they access Flash content in each session in which the user can enable HDX MediaStream Flash Redirection.

1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. 2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream Flash Redirection - Client. 3. From the Setting list, select Enable HDX MediaStream Flash Redirection on the user device and click policy setting. 4. Select Not Configured, Enabled, or Disabled. 5. If you selected Enabled, from the Use HDX MediaStream Flash Redirection list, select Always, Ask, Never, or Only with Second Generation. Note: Selecting Ask results in users receiving the Citrix Receiver - Flash dialog box the first time they access Flash content in each session in which the user can enable Flash Redirection. If the user does not enable Flash Redirection, the Flash content is played on the server. Selecting Always, Never , and Only with Second Generation does not result in this dialog box. Select Always to always use Flash Redirection to play Flash content on the user device. Select Never to never use Flash Redirection and have Flash content play on the server. Select Only with Second Generation to use the latest Flash Redirection functionality when the required configuration is present and revert to server-side rendering when the required configuration is not present.

6. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

Controlling the Citrix Receiver - Flash Dialog Box Display specific choices for the user in the Citrix Receiver - Flash dialog box based on how you configure Flash Redirection on the user device. The following all refer to configuring Enable HDX MediaStream Flash Redirection on the user device: If Citrix Receiver detects the user device does not have the required version of the Adobe Flash Player ( Flash Player for Windows - Other Browsers, sometimes referred to as an NPAPI (Netscape Plugin Application Programming Interface Flash Player), the Citrix Receiver - Flash dialog box offers the user the opportunity to obtain and install a copy of the correct player. Before downloading, an explanation of why the player is needed appears. If Enabled and Ask are selected, the Citrix Receiver - Flash dialog box appears. At this point, the user can choose whether or not to optimize Flash content for the rest of their session. Don't ask me again is not visible. The dialog box appears the first time the user encounters Flash content each session. XenApp only: If Not Configured is selected, the Citrix Receiver - Flash dialog box appears the first time the user accesses Flash content in each session. At this point, the user can choose whether or not to optimize Flash content for the rest of the session. If the user selects Don't ask me again, the optimization choice will be used in future sessions. The dialog box does not appear in the future. Changing this setting requires editing the user device registry. XenDesktop only: If the user opens the Citrix Receiver - Desktop Viewer Preferences dialog box and selects the Flash tab, a page with contents similar to the Citrix Receiver - Flash dialog box appears. The user can choose whether or not to optimize Flash content in future sessions on this page. If the user selects Ask me later, the Citrix Receiver - Flash dialog box appears the first time the user encounters Flash content each session. Don't ask me again is not visible. The user can change this setting at the Citrix Receiver - Desktop Viewer Preferences dialog box.

To synchronize client-side HTTP cookies with the server-side Enable synchronization of the client-side HTTP cookies with the server-side in order to download HTTP cookies from the server. These HTTP cookies are then used for client-side content fetching and are available to be read, as needed, by sites containing Flash content. Client-side cookies are not replaced during the synchronization; they remain available if the synchronization policy is later disabled. 1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. 2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream Flash Redirection - Client. 3. From the Setting list, select Enable synchronization of the client-side HTTP cookies with the server-side and click policy setting. 4. Select Not Configured, Enabled, or Disabled. 5. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

To enable server-side content fetching By default, HDX MediaStream Flash Redirection downloads Adobe Flash content to and plays the content on the user device. Enabling server-side content fetching causes the Flash content to download to the server and then be sent to the user device. Unless there is an overriding policy, such as a site blocked through the Flash URL compatibility list policy setting, the content will play on the user device.

This setting is frequently used when: The user device does not have direct access to the Internet. The user device connects to internal sites through Citrix Access Gateway. The second generation of Flash Redirection introduces three new enabling options as described in the following table. Two of these options include the ability to cache server-side content on the user device. This improves performance because content that is reused is already available on the user device for rendering. Note: The contents of this cache are stored separately from other HTTP content cached on the user device. Also introduced in the second generation is server-side content fetching fallback. When one of the three Enabled options is selected, server-side content fetching automatically begins if client-side fetching of .swf files fails. Option Disabled Description Disables server-side content fetching, overriding the Flash server-side content fetching URL list setting on the server. Server-side content fetching fallback is also disabled. Enables server-side content fetching for Web pages and Flash applications identified in the Flash server-side content fetching URL list. Server-side content fetching fallback is available. Flash content is not cached. Enables server-side content fetching for Web pages and Flash applications identified in the Flash server-side content fetching URL list. Server-side content fetching fallback is available. Content obtained through server-side fetching is cached on the user device and stored from session to session.

Enabled

Enabled (persistent caching)

Enabled (temporary caching) server-side content fetching for Web pages and Flash applications identified in the Enables Flash server-side content fetching URL list. Server-side content fetching fallback is available. Content obtained through server-side fetching is cached on the user device and deleted at the end of the session. Important: The Flash server-side content fetching URL list setting on the server must be enabled and populated with target URLs for server-side content fetching to work. 1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. 2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream Flash Redirection - Client. 3. From the Setting list, select Enable server-side content fetching and click policy setting. 4. Select Not Configured, Enabled, or Disabled. 5. If you enabled this setting, choose an option: Disabled Enabled Enabled (persistent caching) Enabled (temporary caching) 6. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

To redirect user devices to other servers for client-side content fetching You can redirect an attempt to obtain Flash content using the URL rewriting rules for client-side content fetching setting which is a second generation Flash Redirection feature. When configuring this feature, you provide two URL patterns using Perl regular expression. If the user device attempts to fetch

content from a Web site matching the first pattern (the matching pattern) , it is redirected to the Web site specified by the second pattern (the replacement pattern). You can use this setting to compensate for content delivery networks (CDN). Some Web sites delivering Flash content use CDN redirection to enable the user to obtain the content from the nearest of a group of servers containing the same content. When using the Flash Redirection client-side fetching feature, the Flash content is requested from the user device, while the rest of the Web page on which the Flash content resides is requested by the server. If CDN is in use, the server request is redirected to the closest server and the user device request follows to the same location. This may not be the location closest to the user device, however. Depending on distance, a delay between the loading of the Web page and Flash content can occur. 1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. 2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream Flash Redirection - Client. 3. From the Setting list, select URL rewriting rules for client-side content fetching and click policy setting. 4. Select Not Configured, Enabled, or Disabled. 5. If you enabled this setting, click Show and using Perl regular expression syntax, type the matching pattern in the Value name box and the replacement pattern in the Value box. 6. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

1.4.2. Configuring Audio Updated: 2011-05-18 You can configure audio through the Policies node of Citrix Desktop Studio (Citrix XenDesktop) or Citrix AppCenter (Citrix XenApp). You control the settings for the audio features through the following Citrix User Policy settings: Audio Plug-n-Play (XenApp only) Audio quality Client audio redirection Client microphone redirection Audio redirection bandwidth limit Audio redirection bandwidth limit percent Audio over UDP Real-timeTransport (XenDesktop only) Audio UDP Port Range (XenDesktop only) Most audio features are transported using the ICA stream and are secured in the same way as other ICA traffic. User Datagram Protocol (UDP) audio uses a separate, unsecured, transport mechanism. To set audio quality Generally, higher sound quality requires more bandwidth and greater server CPU utilization. You can use sound compression to balance sound quality and overall session performance. Use policy settings to configure the compression levels you want to apply to sound files. Consider creating separate policies for groups of dial-up users and for those who connect over a LAN or WAN. Over dial-up connections, where bandwidth typically is limited, users likely care more about download speed than sound quality. For such users, create a policy for dial-up connections that applies high compression levels to sound and another for LAN or WAN connections that applies lower compression levels. Configure the Audio quality setting by choosing from these audio quality levels: Low - for low-speed connections for low-bandwidth connections. Sounds sent to the client

are compressed up to 16Kbps. This compression results in a significant decrease in the quality of the sound but allows reasonable performance for a low-bandwidth connection. Select Medium - optimized for speech for delivering Voice over IP applications. Audio sent to the client is compressed up to 64Kbps. This compression results in a moderate decrease in the quality of the audio played on the client device, but provides low latency and consumes very low bandwidth. Currently, Real-time Transport (RTP) over UDP is only supported when this audio quality is selected. Use this audio quality even for delivering media applications for the challenging network connections like very low (less than 512Kbps) lines and when there is congestion and packet loss in the network. Select High - high definition audio when delivering media applications. This setting provides high fidelity stereo audio but consumes more bandwidth than the Medium quality setting. Use this setting when network bandwidth is plentiful and sound quality is important. Note: High definition increases bandwidth requirements by sending more audio data to user devices and increases server CPU utilization.

Important: You must also enable audio on Client audio settings on the user device. To redirect audio reception You can allow users to receive audio from an application on a server through speakers or other sound devices, such as headphones, on their user devices. Client audio mapping may cause more load on the servers and the network than is preferred. Configure the Client audio redirection setting by choosing Allowed, the default, or Prohibited. Important: When Client audio redirection is disabled, all audio functionality is disabled. When using XenApp, the Audio Plug-n-Play setting must be enabled to use multiple audio devices. Important: You must also enable audio on Client audio settings on the user device. To activate user device microphones You can allow users to record audio using input devices such as microphones on the user device. To record audio, the user device needs either a built-in microphone or a device that can be plugged into the microphone jack or USB port. If audio is disabled on the client software, this setting has no effect. The Client audio redirection setting must be enabled for an enabled Client microphone redirection to work. For security, users are alerted when servers that are not trusted by their user devices try to access microphones. Users can choose to accept or reject access prior to using the microphone. Users can disable the alert on the Citrix Receiver, formerly the Citrix online plug-in. Configure the Client microphone redirection setting by choosing Allowed, the default, or Prohibited. When using XenApp, the Audio Plug-n-Play setting must be enabled to use multiple input devices. Important: You must also enable audio on Client audio settings on the user device. To set audio redirection bandwidth limits You can set limits on the allowed bandwidth in kilobits for playing and recording audio. Use the Audio redirection bandwidth limit setting to identify a specific maximum kilobit per second bandwidth for a session. Use the Audio redirection bandwidth limit percent to identify the maximum percentage of the total available bandwidth to be used. If both settings are configured, the one with the lowest bandwidth limit is used. Configure the Audio redirection bandwidth limit and Audio redirection bandwidth limit percent by typing a number in the Value field.

Important: You must also enable audio on Client audio settings on the user device. To send and receive audio with UDP XenDesktop allows you to send and receive lossy audio with UDP using RTP. Important: Audio data transmitted with UDP is not encrypted. If Voice over IP (VoIP) quality is unsatisfactory at medium quality on the Audio quality setting, you can enable the Audio over UDP Real-time Transport user policy setting. By default, UDP audio on XenDesktop uses two consecutive ports within the range of ports 16500 to 16509 to pass through the Windows firewall. To use other ports, configure the Audio UDP Port Range machine policy setting by typing the port number or range into the Value field. UDP is not available on XenApp. Important: You must also enable audio on Client audio settings on the user device. To configure audio on the user device 1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. 2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select Citrix Component > Citrix Receiver > User Experience. 3. From the Setting list, select Client Audio Settings and click policy setting. 4. Select Not Configured, Enabled, or Disabled. 5. If you selected Enabled, select Enable audio. 6. Select a High, Medium, or Low sound quality. For UDP audio, use Medium only. 7. For UDP audio only, select Enable Real-Time Transport. 8. For UDP audio only, set the range of ports to use to pass through the Windows firewall. This range must be consistent with the range set in the Audio UDP Port Range machine policy. 1.4.2.1. Avoiding Echo During Multimedia Conferences With HDX RealTime Updated: 2011-05-16 When users take part in audio or video conferences, they may hear an echo in their audio. Echoes usually occur when speakers and microphones are too close to each other. For that reason, Citrix recommends the use of headsets for audio and video conferences. HDX RealTime provides an echo cancellation option, enabled by default, which minimizes echo during a conference. For echo cancellation to be most effective, the user should select either Medium - optimized for speech or Low - for low-speed connections audio quality. The High - high definition audio setting is intended for music playback, rather than conference speech and should be avoided for conferences. The effectiveness of echo cancellation is sensitive to the distance between the speakers and the microphone. These devices must not be too close to each other or too far from each other. Echo cancellation is available with the version of Receiver for Windows included with this Technical Preview and Citrix Online Plug-in 12.1 for Windows, as well as Web Interface 5.3. To enable or disable echo cancellation

1. For 32-bit computers: On the user device, open the registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancel

For 64-bit computers: On the user device, open the registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAu

Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 2. In the Value data field, type TRUE or FALSE to enable or disable echo cancellation. 1.4.3. Video Conferencing with HDX RealTime Webcam Video Compression Updated: 2011-05-18 HDX RealTime provides a webcam video compression option to improve bandwidth efficiency during video conferencing. Users receive a dialog box the first time their desktops access the webcam or microphone during a session. Users can permit or deny access for the rest of the session. If the user selects the Do not ask me again for this virtual desktop check box, the permission or denial is used for future sessions. The user then makes future changes on the Mic & Webcam tab of the Citrix Receiver - Desktop Viewer Preferences dialog box. System Requirements for HDX RealTime Webcam Video Compression To use the HDX RealTime webcam video compression feature: Install Citrix Receiver for Windows, formerly Citrix online plug-in, included with the Technical Preview or Citrix Online Plug-in 12.1 for Windows on the user device. For Microsoft Office Communicator: Install Microsoft Office Communications Server 2007 on the XenDesktop site. Install Microsoft Office Communicator 2007 on the Virtual Desktop Agent. For Skype: Install Skype 5.3 on the Virtual Desktop Agent. Optionally, set up a web-based Skype Manager account. Ensure the user device has the appropriate hardware to produce sound. Use the web camera default settings. Install drivers for web cameras on the user device. Where possible, use drivers obtained from the camera manufacturer, rather than from a third party. Note: Only one web camera is supported at a time. If a device has multiple web cameras attached, the cameras are tried in succession until a connection is made. Enable the following Citrix Policy settings in the Citrix Desktop Studio: Client audio redirection Client microphone redirection Windows Media Redirection

Configuring Client Audio Redirection Client audio redirection is a Citrix Uses Policy setting. It allows or prevents the redirection of sound from a hosted application to a sound device on the user device. Client audio redirection is enabled by default. Configuring Client Microphone Redirection Client microphone redirection is a Citrix Users Policy setting. It allows or prevents the redirection of microphones. Client microphone redirection is enabled by default. Configuring Windows Media Redirection Windows Media Redirection is a Citrix Machine Policy setting. Use this setting to allow or prohibit the delivery

of streaming audio and video to users. Windows Media Redirection is enabled by default. 1.4.4. Redirecting Aero Functionality Updated: 2011-05-17 Aero Redirection allows remote desktops to use the Windows Aero interface by utilizing the graphics processing unit (GPU) of the host user device rather than that of the server. The following Windows Aero preview options are available to XenApp users: Taskbar Preview When the user hovers over a window's taskbar icon, an image of that window appears above the taskbar. Windows Peek When the user hovers over a taskbar preview image, a full-sized image of the window appears on the screen. Flip When the user presses ALT+TAB, small preview icons are shown for each open window. Flip 3D When the user presses TAB+Windows logo key, large images of the open windows cascade across the screen.

Requirements User Device Hardware Windows Aero capable DirectX 9-class GPU that supports: Pixel Shader 2.0 32 bits per pixel 128MB memory 1.5 GHz non-mobile central processing unit (CPU) Software DirectX 9.0c runtime (Windows 7, Windows Vista, or Windows XP)

Note: If a user device does not meet these requirements, Windows 7 Basic is used in place of Windows Aero.

Server Hardware A peripheral component interconnect (PCI) display card with an interrupt request (IRQ) line Software Aero-capable operating system (Windows 7) Hypervisor: XenServer 5.6 or VMWare ESX Note: Physical machines are not supported.

Bandwidth Minimum available: 2 Mbps Recommended: 5 Mbps

The Available and Recommended Mbps incorporate end-to-end latency. If bandwidth is not able to sustain Windows Aero, Aero Redirection is terminated and Windows 7 Basic is delivered. To configure Aero Redirection 1. In User settings, open the Aero Redirection Add Setting dialog box. 2. Select Enabled, which is the default, or Disabled. 3. Open the Aero Redirection Graphics Quality Add Setting dialog box. 4. From the Value list, select Lossless, High, which is the default, Medium, or Low. 1.4.5. Increasing 2D and 3D Application Scalability and Performance Updated: 2010-10-01 HDX 3D allows graphics-heavy applications running on XenApp on a physical server to render on the server's graphics processing unit (GPU). By moving DirectX, Direct3D and Windows Presentation Foundation (WPF) rendering to the server's GPU, the server's central processing unit (CPU) is not slowed by graphics rendering. Additionally, the server is able to process more graphics because the workload is split between the CPU and GPU. This feature is only available on servers with a GPU that supports a display driver interface (DDI) version of 9ex, 10, or 11. DirectX and Direct3D require no special settings. To enable WPF applications to render using the server's GPU, in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook subkey in the registry of the server running XenApp, create the EnableWPFHook key with a key type of REG_DWORD and set its value to 1. Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 1.4.6. Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors Updated: 2011-05-17 By default, Citrix's HDX features provide a high quality graphics experience in Windows 7 desktops with an efficient use of bandwidth. If you experience low bandwidth, you can improve responsiveness by enabling extra color compression. This compression results in lower quality graphics, however. When you enable this compression, you also set a bandwidth threshold at which extra color compression occurs. High quality images are delivered as long as the bandwidth remains above the threshold. If the bandwidth drops below the threshold, extra color compression occurs, reducing graphic quality and improving responsiveness. The extra color compression ends and high quality graphics resume when the bandwidth rises above the threshold again. The two extra color compression settings, which you configure on the server through the HDX Policies node of the Citrix Desktop Studio, are: Extra Color Compression Extra Color Compression Threshold

To improve responsiveness by compressing colors Extra color compression is disabled by default in order to provide high quality graphics to Windows 7 desktops. You can enable and disable extra color compression from the Desktop Studio through the Citrix User Policy setting Extra Color Compression. When Enabled is selected, extra color compression begins, reducing the bandwidth needed to present graphics, while concurrently reducing the quality of those graphics. If Disabled is selected, high quality graphics are delivered and more bandwidth is consumed. After configuring Extra Color Compression set the bandwidth threshold with the Extra Color Compression Threshold setting.

To set a threshold to activate extra color compression After changing the Extra Color Compression setting to Enable, specify a threshold at which the compression occurs. If the bandwidth is below the threshold, extra color compression occurs. If the bandwidth is above the threshold, extra color compression does not occur and high quality graphics are delivered to the users' Windows 7 desktops. Set the Extra Color Compression Threshold setting by typing a kbps rate in the Value field. Alternatively, click Use default value to use 2,000 kbps. 1.4.7. Assigning Priorities to Network Traffic Updated: 2011-05-18 With XenApp and XenDesktop, priorities are assigned to network traffic across multiple connections for a session with quality of service (QoS)-supported routers. Four Transmission Control Protocol (TCP) connections are available to carry ICA traffic between the user device and the server (XenDesktop provides an additional User Datagram Protocol (UDP) connection). Each virtual channel is associated with a specific priority and transported in the corresponding TCP connection. You can set the channels independently, based on the TCP port number used for the connection. The four priorities are: Very High: for realtime activities, such as webcam conferences. High: for interactive elements, such as the screen, keyboard, and mouse. Medium: for bulk processes, such as Client Drive Mapping (CDM). Low: for background activities, such as printing. XenDesktop supports multiple channel streaming connections only for Virtual Desktop Agents installed on Windows 7 environments. Work with your company's network administrator to ensure the Common Gateway Protocol (CGP) ports configured in the Multi-Port Policy setting are assigned correctly on the network routers. Quality of service is supported only when multiple session reliability ports, or the CGP ports, are configured. Caution: Use transport security when using this feature. Citrix recommends using Internet Protocol Security (IPsec).

To assign priorities to network traffic To set quality of service for multiple streaming connections, you must configure: Multi-Stream, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer Policy setting in XenApp. Multi-Port Policy, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer Policy setting in XenApp. Multi-Stream Connections, a Citrix Users Policy setting in XenDesktop and a Citrix User Policy setting in XenApp.

1. In Machine settings (XenDesktop) or Computer settings (XenApp), open the Multi-Port Policy Add Setting dialog box. 2. From the CGP default port priority list, select a priority. 3. Type additional CGP ports in CGP port1, CGP port2, and CGP port3, as needed, and identify priorities for each. 4. In Machine settings (XenDesktop) or Computer settings (XenApp), open the Multi-Stream Add Setting dialog box and select Enabled or Disabled. 5. In Users settings (XenDesktop) or User settings (XenApp), open the Multi-Stream Connections Add Setting dialog box and select Enabled or Disabled. For the policies to take effect, users must log off and then log on to the network.

1.5. About HDX 3D Pro Updated: 2011-05-19 HDX 3D Pro is a feature of XenDesktop Enterprise and Platinum editions that enables you to deliver desktops and applications that use a graphics processing unit (GPU) for hardware acceleration, including 3D professional graphics applications based on OpenGL and DirectX. With HDX 3D Pro, you can use XenDesktop to deliver complex interactive graphics over wide area network (WAN) connections with bandwidths as low as 2 Mbps. On local area network (LAN) connections, HDX 3D Pro enables you to replace complex and expensive workstations with much simpler user devices, moving the graphics processing into the data center for centralized management. You can use HDX 3D Pro to virtualize, for example, tools for computer-aided design, manufacturing, and engineering (CAD/CAM/CAE), geographical information system (GIS) software, and picture archiving and communication system (PACS) workstations for medical imaging. In addition to specialist graphical applications, HDX 3D Pro also enables you to deliver computationally-intensive nongraphical applications that use NVIDIA compute unified device architecture (CUDA) GPUs for parallel computing. Key Features of HDX 3D Pro New in This Release Multi-monitor support. HDX 3D Pro supports user devices with multiple monitors. Users have the freedom to arrange their monitors in any configuration they choose and can mix monitors with different resolutions and orientations. The number of monitors is limited only by the capabilities of the server GPU, the user device, and the available bandwidth. Support for XenServer VMs. In addition to physical host computers, HDX 3D Pro supports XenServer VMs with Multi-GPU Passthrough. The XenServer Multi-GPU Passthrough feature enables you to create VMs with exclusive access to dedicated graphics processing hardware. You can install multiple GPUs on the hypervisor and assign VMs to each of these GPUs on a one-to-one basis. Client-side hardware decoding. Where available, HDX 3D Pro can leverage H.264 hardware decoding on Linux user devices. This reduces the load on the CPU, enabling you to deliver graphically intensive applications more effectively to user devices with less powerful processors. HDX 3D Pro policies. You can use policies in XenDesktop to set the range of image quality adjustment available to users in the image quality configuration tool and to specify whether users can manually enable or disable lossless compression. Other Features Lossless compression. HDX 3D Pro supports lossless compression, which enables you to deliver pixel-perfect images for applications such as medical imaging. GPU-accelerated encoding. Where a compatible NVIDIA CUDA-enabled GPU is available, HDX 3D Pro can leverage the GPU to accelerate the encoding of images. GPU-based compression is particularly efficient at minimizing bandwidth usage for organic images such as textured data, video, and geographical images. If a compatible GPU is not available, HDX 3D Pro falls back to CPUbased compression. Automatic codec selection. On platforms where both GPU and CPU-based compression is available, HDX 3D Pro optimizes the user experience by automatically switching between CPU and GPU codecs according to the capabilities of the user device and the server, and the available bandwidth. High resolution monitor support. HDX 3D Pro supports high resolution monitors. Although all resolutions over 800 x 600 pixels are supported, for optimum performance over LAN connections Citrix recommends a maximum resolution of 1920 x 1200 pixels. Citrix recommends a maximum resolution of 1280 x 1024 pixels for the best results on WAN connections. Best user experience over any bandwidth. On LAN connections with bandwidths of 100 Mbps, HDX 3D Pro delivers a user experience equivalent or better than that of a local desktop. Additionally, the performance optimizations in HDX 3D Pro enable you to deliver an interactive user experience over WAN connections with bandwidths as low as 2 Mbps. Real-time image quality configuration tool. HDX 3D Pro includes an image quality configuration tool that enables users to adjust in real time the balance between image quality and responsiveness to optimize their use of the available bandwidth. Desktop or VM hosted apps. With HDX 3D Pro and XenDesktop, you can deliver graphically

intensive applications as part of a complete virtual desktop or as a VM hosted app, according to the requirements of your users.

1.5.1. System Requirements for HDX 3D Pro Updated: 2011-05-18 This topic describes the requirements for installing and using HDX 3D Pro. It is assumed that your servers and users' devices meet the minimum hardware requirements for the installed operating system. The current release of HDX 3D Pro is only compatible with XenDesktop Technology Preview. Host Requirements The Virtual Desktop Agent for HDX 3D Pro is supported for installation on the following versions of Windows. Windows 7 64-bit Editions with Service Pack 1 Windows 7 32-bit Editions with Service Pack 1 Windows XP Professional x64 Edition with Service Pack 2 Windows XP Professional with Service Pack 3 HDX 3D Pro can be used to deliver any application that is compatible with the supported host operating systems, but is particularly suitable for use with DirectX and OpenGL-driven applications, and with rich media such as video. The computer hosting the application can be either a physical machine or a XenServer VM with MultiGPU Passthrough. The Multi-GPU Passthrough feature is currently available for technology preview with the Citrix XenServer "Project Boston" Beta release on the Citrix Downloads Web site. Citrix recommends that, at minimum, the specification of the host computer include at least 4 GB of RAM and a dual core CPU (or two virtual CPUs) with a clock speed of 2.3 GHz or higher. If you plan to enable Aero on Windows 7, a quad core physical CPU or a minimum of three virtual CPUs are recommended. Graphical Processing Unit Requirements For CPU-based compression, including lossless compression, HDX 3D Pro supports any display adapter on the host computer that is compatible with the application that you are delivering. To use GPUaccelerated encoding, HDX 3D Pro requires that the computer hosting the application is equipped with a NVIDIA CUDA-enabled GPU with at least 96 CUDA cores and NVIDIA CUDA 2.1 or later display drivers installed. For optimum performance, Citrix recommends using a GPU with at least 128 parallel CUDA cores. User Device Requirements To access desktops or applications delivered with XenDesktop and HDX 3D Pro, users must install the latest version of Citrix Receiver for Windows or Citrix Receiver for Linux. For more information on Citrix Receiver system requirements, see Receiver and Plugins. Users' devices must be equipped with a monitor with a resolution of at least 800 x 600 pixels. For optimum performance, Citrix recommends maximum monitor resolutions of 1920 x 1200 pixels for users with LAN connections and 1280 x 1024 pixels for users with WAN connections. Citrix recommends that, at minimum, the specification of users' devices include at least 1 GB of RAM and a CPU with a clock speed of 3 GHz or higher. For optimum performance, Citrix recommends that users' devices are equipped with at least 2 GB of RAM and a dual core CPU or better. Users' devices do not need a dedicated GPU to access desktops or applications delivered with HDX 3D Pro. 1.5.2. Planning an HDX 3D Pro Deployment Updated: 2011-05-19 HDX 3D Pro integrates with your existing XenDesktop infrastructure. You can deliver graphical applications either as part of a complete virtual desktop or as a VM hosted app. To enable users to connect to the physical machine or XenServer virtual machine (VM) hosting the application, you install the Virtual Desktop

Agent for HDX 3D Pro. Then, to assign the desktop or VM hosted app to a user, you create a catalog and a desktop group containing the computer hosting the graphical application. The host computer must reside within the same Active Directory domain as your XenDesktop controller. Users access the desktop or VM hosted app through a Windows device or a XenDesktop-compatible Linux thin client running the appropriate Citrix Receiver. When a user logs on to Citrix Receiver and accesses the desktop or VM hosted app, the controller authenticates the user and contacts the Virtual Desktop Agent for HDX 3D Pro to broker a connection to the computer hosting the graphical application. The Virtual Desktop Agent for HDX 3D Pro uses the appropriate hardware on the host to compress views of the complete desktop or just of the graphical application. These views, and the user's interactions with them, are transmitted between the host computer and the user device through a direct HDX connection between Citrix Receiver and the Virtual Desktop Agent for HDX 3D Pro. The figure shows how HDX 3D Pro integrates with XenDesktop and interacts with other components.

HDX 3D Pro supports both physical host computers, including desktop, blade, and rack workstations, and XenServer VMs with Multi-GPU Passthrough. The XenServer Multi-GPU Passthrough feature enables you to create VMs with exclusive access to dedicated graphics processing hardware. You can install multiple GPUs on the hypervisor and assign VMs to each of these GPUs on a one-to-one basis. To optimize the delivery of graphically intensive applications, HDX 3D Pro uses different compression technologies than the standard Virtual Desktop Agent. Where a compatible NVIDIA CUDA-enabled GPU with at least 96 CUDA cores is available on the host computer, HDX 3D Pro employs a codec that uses the GPU on the host to encode data. User devices require the decoder for the codec to receive GPU-encoded data, but they do not need a dedicated GPU. If the GPU on the host computer is not supported for GPU-based compression, HDX 3D Pro uses CPUbased compression. The CPU codec is also used when lossless compression is required to support applications where pixel-perfect graphics are necessary, such as medical imaging. In deployments where the appropriate GPU hardware is available on the host computer, HDX 3D Pro uses GPU-based compression by default, but automatically switches to CPU-based compression when required. For example, when the user device does not have the decoder for the GPU codec or when lossless compression

is enabled. GPU-based compression makes optimum use of the available bandwidth: you can deliver complex interactive graphics over WAN connections with bandwidths as low as 2 Mbps. On LAN connections, the bandwidth consumed by graphically intensive applications can be reduced dramatically without compromising the high definition user experience. CPU-based compression requires at least 3 Mbps of network bandwidth to deliver an interactive user experience, although when lossless compression is enabled this rises to 10 Mbps. 1.5.3. Installing and Configuring HDX 3D Pro Updated: 2011-05-19 To enable users to connect to the physical machine or XenServer VM hosting the graphical application, you install the Virtual Desktop Agent for HDX 3D Pro. Then, you create a catalog and a desktop group containing the host computer to assign the desktop or VM hosted app to a user. 1. If necessary, install and configure your XenDesktop infrastructure and create a site. For more information about installing and configuring XenDesktop, see Installing and Upgrading to XenDesktop Technology Preview. 2. Prepare the VM or physical machine that will host the graphical application. If the host computer is equipped with a CUDA-enabled NVIDIA GPU with 96 or more CUDA cores, ensure that NVIDIA CUDA 2.1 or later display drivers are installed. Install and set up the graphics application, plus any other applications that are required. 3. Join the host computer to the Active Directory domain containing your XenDesktop controller. Make a note of the Active Directory computer account name for the host computer as you will need to know this when you create a catalog. 4. Visit the Citrix Downloads Web site and download an HDX 3D Pro key file. Save the key file on the host computer. 5. Insert the XenDesktop installation media into the optical drive or mount the ISO on the host computer. If autorun is not enabled, navigate to and run AutoSelect.exe on the installation media. 6. In the XenDesktop installation wizard, click Install Virtual Desktop Agent and then click Advanced Install. 7. Read and accept the license agreement, and click Next. 8. Select Virtual Desktop Agent for HDX 3D Pro and navigate to the location of the HDX 3D Pro key file you downloaded. Click Next. 9. On the Select Components to Install page, specify whether or not you want to install Citrix Receiver on the host computer in addition to the Virtual Desktop Agent for HDX 3D Pro. If you decide to install Citrix Receiver, you can enter the URL of your XenApp server farm to preconfigure Citrix Receiver for your users. If you plan to deliver the entire desktop of the host computer to your users, install Citrix Receiver on the host computer so that users can access XenApp applications from within the virtual desktop. You do not need to install Citrix Receiver if you plan to deliver the graphical application as a VM hosted app. 10. On the Controller Location page, specify the controllers in the XenDesktop site to which the Virtual Desktop Agent for HDX 3D Pro will connect, either by manually entering the locations or by selecting controllers from Active Directory. Alternatively, select Configure at a later time if you plan to specify controller locations later using Group Policy or by running the installer again. Important: Ensure that you specify the locations of all the controllers in the site, otherwise some user connections may be refused. For load balancing, the Virtual Desktop Agent for HDX 3D Pro automatically distributes connections evenly across the controllers. 11. On the Virtual Desktop Configuration page, specify whether or not you want to enable user desktop shadowing and real time monitoring. If the host computer is a VM, ensure that the Optimize XenDesktop Performance check box is selected. Optimizing the VM improves the performance of users' desktops by reconfiguring various Windows features that are incompatible with or unnecessary for virtual desktops, such as disabling background defragmentation and reducing the event log size. For more information about the optimizations performed by the installer, see http: //support.citrix.com/article/ctx125874/. 12. If you are using a firewall other than Windows Firewall on the host computer, manually enable ports 80, 1494, 2598, and 3389 to allow XenDesktop to function correctly and open ports 1650016509 to enable Real-time Transport for Audio. If Windows Firewall is running on the host computer, the

12.

installer gives you the option to open the ports automatically. Click Next. 13. On the Summary page, click Install. Before the Virtual Desktop Agent for HDX 3D Pro is installed, the following prerequisites are installed if they are not already present on the host computer. Microsoft .NET Framework 3.5 with Service Pack 1 Microsoft Visual C++ 2008 with Service Pack 1 Redistributable Package Microsoft Visual C++ 2005 with Service Pack 1 Redistributable Package 14. When the installation is complete, ensure that the Restart machine (required to complete install) check box is selected and click Close. 15. After completing the installation of the Virtual Desktop Agent for HDX 3D Pro, log on to the computer running Desktop Studio. Create an existing (if the host computer is a VM) or physical machine catalog, as appropriate, and add the computer hosting the graphical application. For more information about creating catalogs, see To create a new machine catalog. 16. Finally, to make the virtual desktop or VM hosted app available to users, create a desktop group or an application desktop group using the catalog containing the host computer. For more information about creating desktop groups and application desktop groups, see To create a desktop group and To create an application desktop group, respectively. You can also install the Virtual Desktop Agent for HDX 3D Pro from a command prompt. To install HDX 3D Pro, run XenDesktopVdaSetup.exe and include the arguments /ENABLE_HDX_3D_PRO and /KEY_FILE <path >, where <path> specifies the location of the HDX 3D Pro key file. For more information about installing the Virtual Desktop Agent from a command prompt, see XenDesktopVdaSetup.exe. If you want to deploy the Virtual Desktop Agent for HDX 3D Pro through Active Directory Group Policy, ensure that the transform file specifies appropriate values for the ENABLE_HDX_3D_PRO and KEY_FILE properties. For more information about deploying the Virtual Desktop Agent through group policy, see http://support.citrix.com/article/ctx127301/. Upgrading HDX 3D Pro To upgrade from an earlier version of HDX 3D Pro, uninstall both the separate HDX 3D for Professional Graphics component and the Virtual Desktop Agent before installing the latest Virtual Desktop Agent for HDX 3D Pro. Similarly, to switch from the standard Virtual Desktop Agent to the Virtual Desktop Agent for HDX 3D Pro, uninstall the standard Virtual Desktop Agent before installing the Virtual Desktop Agent for HDX 3D Pro. 1.5.4. Managing and Administering HDX 3D Pro Updated: 2011-04-14 Once you have installed the Virtual Desktop Agent for HDX 3D Pro, you can configure the image quality configuration tool for your users. If necessary, you can make changes to the configuration of the Virtual Desktop Agent for HDX 3D Pro using a command-line tool. Should users experience issues, you can enable logging in HDX 3D Pro to help with troubleshooting. Configuring the HDX 3D Pro Image Quality Configuration Tool HDX 3D Pro includes an image quality configuration tool that enables users to optimize their use of the available bandwidth by adjusting in real time the balance between image quality and responsiveness. You control the range of adjustment and options available to users in the image quality configuration tool through the following HDX 3D Pro policies in XenDesktop. For more information about configuring policies in XenDesktop, see Working with XenDesktop Policies. EnableLossless This setting specifies whether or not lossless compression can be used. By default, this setting is enabled. When this setting is enabled, lossless compression is used by default and the image quality is set to the maximum value. However, users can disable lossless compression and reduce the image quality using the image quality configuration tool. When this setting is disabled, either GPU or CPU-based compression is used

by default, according to the capabilities of the user device and the server, and the available bandwidth. Users are not given the option to enable lossless compression in the image quality configuration tool. HDX3DPro Quality Settings This setting specifies the minimum and maximum values that define the range of image quality adjustment available to users in the image quality configuration tool. Specify image quality values of between 0 and 100, inclusive. The maximum value must be greater than or equal to the minimum value. Using the HDX 3D Pro Command-Line Tool The Virtual Desktop Agent for HDX 3D Pro includes a command-line tool that enables you to make changes to the configuration. To use the tool, open a Command Prompt window and navigate to the folder containing the command-line tool, typically c:\Program Files (x86)\Citrix\ICAService. Run the tool using the following syntax, as appropriate for the operating system.

HDX3DConfigCmdLineX[86 | 64].exe <command> <value>

Valid commands and values are listed in the table below. Default values are shown in bold text. Command DEBUG_LOGGING Values 0|1 Description Specifies whether or not advanced logging is enabled for the Virtual Desktop Agent for HDX 3D Pro. Entering a value of 1 for this command enables advanced logging, which is disabled by default. Displays the current configuration of the Virtual Desktop Agent for HDX 3D Pro. Specifies whether or not HDX 3D Pro automatically adjusts the balance between image quality and responsiveness according to the available bandwidth. Entering a value of 1 for this command disables automatic adjustment of image quality and delivers all images at the specified quality, regardless of the available bandwidth.

DISPLAY CURRENT_OPTIONS DEBUG_LOGGING ENABLE_FIXEDQUALITY

None

[0 | 1]

GPUCODEC_MINCUDACORES

96 | 64 | 32

Specifies the minimum number of CUDA cores required on an NVIDIA GPU in order for it to be used by HDX 3D Pro Important: Ensure that users have logged off from the desktop or VM hosted app before you change the minimum number of CUDA cores. Citrix does not recommend using GPUs with less than 96 cores for GPU-based compression.

SET_FRAMECAPTURERATE

Integer between 10 and 50, the desired frame capture rate that HDX Specifies inclusive 3D Pro uses when automatically balancing image quality against responsiveness. CPU | GPU Specifies the type of image compression that HDX 3D Pro uses on platforms where both GPU and CPU-based encoding is available.

SWITCH_CODEC

To enable advanced logging for HDX 3D Pro HDX 3D Pro supports Windows event logging. Any events that are generated are written to the Virtual Desktop Agent for HDX 3D Pro application log, which can be viewed using Event Viewer. HDX 3D Pro also provides advanced logging, which is disabled by default. To ensure maximum performance for users, Citrix recommends that you only enable advanced logging when you are troubleshooting an issue. 1. Using an account with local administrator permissions, log on to the computer hosting the graphical application. 2. From a command prompt, navigate to the folder containing the command-line tool, typically c: \Program Files (x86)\Citrix\ICA Service, and type the following command as appropriate for the operating system.

HDX3DConfigCmdLineX[86 | 64].exe DEBUG_LOGGING 1

You can view HDX 3D Pro advanced debugging output using a tool such as Windows Sysinternals DebugView. 1.5.5. HDX 3D Pro User Experience Updated: 2011-04-01 To access the desktop or VM hosted app providing the graphical application, the appropriate Citrix client for the operating system must be installed on the user device. Once the client is installed, users access the desktop or VM hosted app in the same way as they access their other XenDesktop and XenApp resources. Image Quality Configuration Tool HDX 3D Pro includes an image quality configuration tool that enables users to adjust in real time the balance between image quality and responsiveness to optimize their use of the available bandwidth. The image quality configuration tool provides the following controls for users.

When viewing the graphical application, users can adjust the image quality with the slider or by using keyboard shortcuts. Users can change these keyboard shortcuts and alter the increment by which the shortcuts change the image quality. When users change the setting, the image quality value is displayed numerically in the bottom right-hand corner of the screen. Moving the slider to the right increases the quality of images from the application, but this can degrade the response to user input if bandwidth is limited. Decreasing the image quality reduces bandwidth usage and so improves responsiveness. By adjusting the image quality according to the task being performed, users can optimize their use of the available bandwidth. For example, users can temporarily increase the image quality to focus on the fine detail of an object and then reduce the quality when interacting with the object.

By default, users can enable and disable lossless compression by selecting and clearing the Lossless check box. To ensure that all frames are lossless when interacting with an image, users must also select the Fixed Quality check box. When the Fixed Quality check box is cleared and bandwidth is limited, lossy compression is used for intermediate frames to improve responsiveness, but the final frame is delivered using lossless compression when the image becomes stationary. Lossless compression is required to deliver pixel-perfect images for applications such as medical imaging. However, for cases where pixel-perfect images are not essential, users can make more efficient use of the available bandwidth, while still obtaining images that are visually lossless, by increasing the image quality and then selecting the Fixed Quality check box. Users with low bandwidth WAN connections can improve responsiveness when interacting with two-dimensional or wireframe images by selecting the 2D Drawing check box. This option is only enabled when GPU-based compression is available and is not suitable for use with other types of images. Users can ensure that all images are delivered at the specified quality level, regardless of the available bandwidth, by selecting the Fixed Quality check box. However, on low bandwidth

connections users may find that fixing the image quality to a high value has a negative impact on responsiveness.

Optimizing the User Experience Implement the following recommendations to provide the optimum experience for your users. To enable users to display the desktops or VM hosted apps providing their graphical applications over multiple monitors, ensure that the host computer is configured with at least as many monitors as are attached to users' devices. The monitors attached to the host computer can be either physical or virtual. Do not attach a monitor (either physical or virtual) to a host computer while a user is connected to the desktop or VM hosted app providing the graphical application as this can cause instability for the duration of the user's session. Instruct your users not to change the resolution of the desktops providing their graphical applications. To change the resolution of their desktops, users must either change the resolution of the Citrix client window or resize the client window. When multiple users are sharing a connection with limited bandwidth, such as at a branch office, Citrix recommends that you set a limit on the bandwidth available to each user to ensure that the available bandwidth does not fluctuate widely as users log on and off. Because HDX 3D Pro automatically adjusts to make use of all the available bandwidth, large variations in the available bandwidth over the course of users' sessions can negatively impact performance. For example, if 20 users share a 60 Mbps connection then the bandwidth available to each user can vary between 3 Mbps and 60 Mbps depending on the number of concurrent users. To optimize the user experience in this scenario, determine the bandwidth required per user at peak periods and limit users to this amount at all times. For more information about optimizing the HDX 3D Pro user experience, see the Troubleshooting Guide. 1.6. New and Updated Policy Settings Updated: 2011-05-12 XenDesktop Technology Preview includes a number of new and updated policy settings. You can use these policy settings in conjunction with those available in XenDesktop 5. For more information, see Working with XenDesktop Policies and XenDesktop Policy Settings Reference. New Policy Settings XenDesktop includes the following new policy settings: Location Setting

ICA > Adobe Flash Delivery > Flash Redirection Flash background color list Flash backwards compatibility Flash default behavior Flash intelligent fallback Flash URL compatibility list ICA > Audio Audio over UDP Real-time Transport

ICA > Bandwidth

TWAIN device redirection bandwidth limit TWAIN device redirection bandwidth limit percent

ICA > Desktop UI

Aero Redirection Aero Redirection Graphics Quality

ICA > Graphics > Caching ICA > Multimedia ICA > Multi-Stream Connections

Persistent Cache Threshold Multimedia conferencing Multi-Port Policy Multi-Stream (Computer Configuration) Multi-Stream (User Configuration)

ICA > TWAIN Devices

Client TWAIN device redirection TWAIN compression level

ICA > Visual Display

Max frames per second

New Names for Existing Policy Settings Citrix has changed the name of the following existing XenDesktop policy settings: This name Windows Media Redirection Windows Media Redirection Buffer Size Windows Media Redirection Buffer Size Use Is the new name for HDX MediaStream Multimedia Acceleration HDX MediaStream Multimedia Acceleration default buffer size HDX MediaStream Multimedia Acceleration default buffer size use HDX MediaStream for Flash (client side) Policy Settings HDX Multimedia for Flash (server side) Policy Settings

Flash Redirection Policy Settings Legacy Server Side Optimizations Policy Settings Port Redirection Policy Settings Universal driver preference Universal print driver usage

Ports Policy Settings Universal driver priority Universal printing

New Locations for Existing Policy Settings Citrix has changed the location of the following existing XenDesktop policy settings: Policy Setting Extra Color Compression Extra Color Compression Threshold Heavyweight compression Lossy compression level Lossy compression threshold value Progressive compression level Progressive compression level threshold value Universal driver preference Universal print driver usage Printing Policy Settings > Driver Policy Settings Printing Policy Settings > Universal Printing Policy Settings Visual Display Policy Settings > Moving Images Policy Settings Graphics Policy Settings > Image Compression Policy Settings New location Visual Display Policy Settings > Still Images Policy Settings Previous location Graphics Policy Settings > Image Compression Policy Settings

1.6.1. Flash Redirection Policy Settings Updated: 2011-03-29 The Flash Redirection section contains policy settings for handling Flash content in user sessions. These policy settings are applicable to the following Citrix products: XenApp XenDesktop

Flash background color list This setting enables you to set key colors for given URLs. By default, no key colors are specified. Key colors appear behind client-rendered Flash and help provide visible region detection. The key color specified should be rare; otherwise, visible region detection might not work properly. Valid entries consist of a URL (with optional wildcards at the beginning or end) followed by a 24-bit RGB color hexadecimal code. For example: http://citrix.com 000003 Flash backwards compatibility This setting determines if Flash acceleration is enabled for V1 connections. If disabled, V1 clients will not be able to use client-side rendering of Flash content. By default, this setting is disabled. Flash default behavior

This setting sets the default behavior for Flash acceleration. By default, Flash acceleration is enabled. This setting is affected by other multimedia settings, such as Flash URL compatibility list. Flash intelligent fallback This setting enables or disables server-side rendering for Flash Player instances in cases where clientside rendering is either unnecessary or provides a poor user experience. By default, this setting is enabled. Flash URL compatibility list This setting specifies the rules which determine whether Flash content on certain Web sites are rendered on the user device or the server. By default, no rules are specified. XenApp evaluates the rules in the sequence in which they were entered. XenApp applies each matching rule as it is evaluated. When adding this setting to a policy, make sure the Flash acceleration setting is present and set to Enabled. Otherwise, Web sites listed in the compatibility list are ignored. Valid rules follow the format <command> <URL> object id. For example:

CLIENT citrix.com myflashmovie obj1 movie12

Valid commands are as follows: CLIENT renders Flash content from the matching URL on the user device SERVER renders Flash content from the matching URL on the server BLOCK prevents rendering of Flash content from the matching URL The object id value represents an optional space-separated list of unique identifiers used in the <object> tags on the specified Web site. Listed URL strings do not need the https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid at the beginning and end of a URL. The URL can represent either the top-level Web site address or the Flash content file address. 1.6.2. Audio Policy Settings Updated: 2011-05-11 The Audio section contains policy settings you can configure to permit user devices to send and receive audio in sessions without reducing performance. Audio over UDP Real-time Transport This setting enables or disables the transmission and receipt of audio between the host and user device over RTP using the User Datagram Protocol (UDP). By default, audio is sent and received over TCP. 1.6.3. Bandwidth Policy Settings Updated: 2011-05-11 The Bandwidth section contains policy settings you can configure to avoid performance problems related to client session bandwidth use. TWAIN device redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for controlling TWAIN imaging devices from published applications. By default, no maximum (zero) is specified. If you enter a value for this setting and a value for the TWAIN device redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied. TWAIN device redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth for controlling TWAIN imaging devices from published applications as a percent of the total session bandwidth. By default, no maximum percentage (zero) is specified.

If you enter a value for this setting and a value for the TWAIN device redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions. 1.6.4. Desktop UI Policy Settings Updated: 2011-05-10 The Desktop UI section contains policy settings that control visual effects, such as desktop wallpaper, menu animations, and drag-and-drop images, to manage the bandwidth used in client connections. You can improve application performance on a WAN by limiting bandwidth usage. Aero Redirection This setting enables or disables the redirection of Aero commands from the Virtual Desktop Agent to the user device, to enhance the user experience. By default, Aero Redirection is allowed. To turn off Aero Redirection and reduce the bandwidth required in user sessions, select Disabled when adding this setting to a policy. Aero Redirection Graphics Quality This setting specifies the quality of graphics used for Aero Redirection as High, Medium, Low, or Lossless. By default, high quality graphics are redirected. Desktop wallpaper This setting allows or prevents wallpaper showing in user sessions. By default, user sessions can show wallpaper. To turn off desktop wallpaper and reduce the bandwidth required in user sessions, select Prohibited when adding this setting to a policy. Menu animation This setting allows or prevents menu animation in user sessions. By default, menu animation is allowed. Menu animation is a Microsoft personal preference setting that causes a menu to appear after a short delay, either by scrolling or fading in. When this policy setting is set to Allowed, an arrow icon appears at the bottom of the menu. The menu appears when you mouse over that arrow. View window contents while dragging This setting allows or prevents the display of window contents when dragging a window across the screen. By default, viewing window contents is allowed. When set to Allowed, the entire window appears to move when you drag it. When set to Prohibited, only the window outline appears to move until you drop it. 1.6.5. Caching Policy Settings Updated: 2011-02-28 The Caching section contains settings that enable you to cache image data on user devices when client connections are limited in bandwidth. These policy settings are applicable to the following Citrix products: XenApp XenDesktop

Persistent Cache Threshold This setting caches bitmaps on the hard drive of the user device. This enables re-use of large, frequently-

used images from previous sessions. By default, the threshold is 3000000 kilobits per second. The threshold value represents the point below which you want the Persistent Cache feature to take effect. For example, with regard to the default value, bitmaps are cached on the hard drive of the user device when bandwidth is below 3000000 kbps. 1.6.6. Multimedia Policy Settings Updated: 2011-03-29 The Multimedia section contains policy settings for managing streaming audio and video in user sessions. These policy settings are applicable to the following Citrix products, unless otherwise specified: XenApp XenDesktop

Multimedia conferencing This setting allows or prevents support for video conferencing applications. By default, video conferencing support is enabled. When adding this setting to a policy, make sure the Windows Media Redirection setting is present and set to Allowed. When using multimedia conferencing, make sure the following conditions are met: Manufacturer-supplied drivers for the web cam used for multimedia conferencing must be installed. The web cam must be connected to the client device before initiating a video conferencing session. XenApp uses only one installed web cam at any given time. If multiple web cams are installed on the client device, XenApp attempts to use each web cam in succession until a video conferencing session is created successfully. An Office Communicator server must be present in your farm environment. The Office Communicator client software must be published on the server.

1.6.7. Multi-Stream Connections Policy Settings Updated: 2011-02-28 The Multi-Stream Connections section contains policy settings for managing Quality of Service (QoS) prioritization for multiple ICA connections in a session. These policy settings are applicable to the following Citrix products: XenApp XenDesktop

Multi-Port Policy This setting specifies the TCP ports to be used for ICA traffic and establishes the network priority for each port. By default, the primary port (2598) has a High priority. When you configure additional ports, you can assign the following priorities: Very High High Medium Low You might assign a Very High priority when real-time responsiveness is required, such as for audio and video conferencing. As well, you might assign a Low priority to background processes such as printing. Each port must have a unique priority. For example, you cannot assign a Very High priority to both CGP port 1 and CGP port 3.

To remove a port from prioritization, set the port number to 0. You cannot remove the primary port and you cannot modify its priority level. When configuring this setting, reboot the server. This setting takes effect only when the Multi-Stream Computer policy setting is enabled. Multi-Stream (Computer Configuration) This setting enables or disables multi-stream on the XenApp server. By default, Multi-Stream is disabled. If you use Citrix Branch Repeater with Multi-Stream support in your environment, you do not need to configure this setting. Configure this policy setting when using third-party routers or legacy Branch Repeaters to achieve the desired Quality of Service. When configuring this setting, reboot the server to ensure changes take effect. Multi-Stream (User Configuration) This setting enables or disables multi-stream on the user device. By default, this setting is disabled for all users. This setting takes effect only on hosts where the Multi-Stream Computer policy setting is enabled. 1.6.8. TWAIN Devices Policy Settings Updated: 2011-05-12 The TWAIN devices section contains policy settings related to mapping client TWAIN devices, such as digital cameras or scanners, and optimizing image transfers from server to client. These policy settings are applicable to XenApp and XenDesktop. Client TWAIN device redirection This setting allows or prevents users from accessing TWAIN devices on the user device from published image processing applications. By default, TWAIN device redirection is allowed. TWAIN compression level This setting specifies the level of compression of image transfers from client to server. Use Low for best image quality, Medium for good image quality, or High for low image quality. By default, no compression applied. 1.6.9. Visual Display Policy Settings Updated: 2011-03-29 The Visual Display section contains policy settings for controlling the quality of images sent from virtual desktops. Max frames per second Applicable products: XenApp; XenDesktop This setting specifies the maximum number of frames per second sent to the user device from the virtual desktop. By default, the maximum is 24 frames per second. Setting a high number of frames per second (for example, 30) improves the user experience, but requires more bandwidth. Decreasing the number of frames per second (for example, 10) maximizes server scalability at the expense of user experience. 2. XenDesktop 5 Service Pack 1 Updated: 2011-05-10 This service pack provides the following server-side quality improvements to XenDesktop 5: Licensing enhancements. Version 11.9 of the License Server supports user/device licensing, manages license checkout information, and provides information that enables you to check out the least number of licenses. For further details, including any changes to system requirements, see

Licensing Your Product. You can use Desktop Studio to track and manage license usage and license models, and also to access the License Administration Console; for further details see Managing Licensing. Support for XenServer 5.6 Service Pack 2. This includes support for IntelliCache. For further details see Using IntelliCache with XenDesktop. Blade power management. Support is provided for third party plug-ins for blade servers. You can add machines to an Existing catalog by using the Import List option to specify a .csv file in which machines are specified by unique ID instead of by name. The set of power management options available in Desktop Studio is based on the capabilities reported by the plug-in. Support for Microsoft SCVMM R2 Service Pack 1 and Hyper-V 2008 R2 Service Pack 1. Support for VMware VSphere 4.1 Update 1. Fixes for the XenDesktop 5 issues listed at http://support.citrix.com/article/CTX124164. For details of how to install this service pack, see Installing and Upgrading to XenDesktop 5 Service Pack 1. Known issues specific to this service pack are listed below. For details of known issues with XenDesktop 5, see Known Issues in XenDesktop 5. Known Issues When you install the license server using the XenDesktop installation wizard, it is installed silently. If the license server install is unsuccessful, there is no indication of this in the XenDesktop user interface. If, after installing XenDesktop, you find that the license server has not been installed, check the event log for relevant error messages. [BUG0032837] XenDesktop silently installs Citrix Licensing using hardcoded port values of 27000, 7279, and 8082. If any of these ports is already in use, license server configuration fails and Desktop Studio will be unable to contact the license server. To resolve this issue, uninstall Citrix Licensing then reinstall using ctx_licensing.msi and changing the port numbers as necessary. For details of how to use ctx_licensing.msi, see Licensing Your Product. [BUG0032837] 2.1. Installing and Upgrading to XenDesktop 5 Service Pack 1 Updated: 2011-04-28 If you have already installed XenDesktop 5, you can install Service Pack 1 as an upgrade. If you have not previously installed XenDesktop 5, you can perform a single installation that incorporates both XenDesktop 5 and Service Pack 1. Both options are available as ISO images from the Citrix download page. To upgrade to Service Pack 1 Citrix recommends that you upgrade your site in two stages, as described below. The new features provided by the service pack will not be available until both the controller and the database schema have been upgraded, even though the controller will continue to function. The upgrade is not complete until all controllers in the site have been upgraded; until this happens some features may give inconsistent results. Important: As soon as you have upgraded one controller in the site, Citrix recommends that you use the upgraded version of Desktop Studio to manage any controller in the site, including those that have not yet been upgraded. Using an earlier version of Desktop Studio may result in errors. Before you upgrade Desktop Studio or the Controller services, close Desktop Studio on the machine you are upgrading, otherwise Desktop Studio may stop responding. 1. Upgrade the license server. This is mandatory; you may encounter issues during the subsequent steps of the upgrade process if you have not updated the license server. If the license server is on a XenDesktop controller, ensure that this is the first controller you upgrade; the license server is automatically upgraded as part of the upgrade to Service Pack 1. If the license server is on a different machine, upgrade it before you upgrade any of the XenDesktop controllers. To upgrade the license server, run the Service Pack 1 installation wizard as described in steps 4 to 6 below: Citrix Licensing is automatically upgraded. If you are upgrading the license server from a version earlier than 11.6.1, the License

Administration Console is not enabled by default. You can enable the console through Desktop Studio, as described in Managing Licensing, provided the license server is in the same domain as Desktop Studio, or in a trusted domain. If the necessary trusts are not possible, you must install the license server using ctx_licensing.msi, which enables the console by default. 2. 3. 4. 5. 6. 7. 8. Make sure your SQL database has a recent successful backup. Log on to the controller you want to upgrade as a local administrator. Mount the ISO. Select Upgrade XenDesktop. Follow the steps in the wizard. When the installation is complete, ensure that the Configure XenDesktop after closing check box is cleared, then click Close. Restart the controller. Repeat steps 3 through 7 on half of your controllers. The upgraded controllers are now incompatible with the database. The site can, however, continue to function using the non-upgraded controllers until the database is upgraded. 9. Validate the health of your site by: Checking that users are able to connect to desktops by logging on to Web Interface and starting a sample desktop. Using the Desktop Director dashboard to verify that the site is operating normally. In particular, check for desktops in the Unregistered or Last connection failed states and check the Infrastructure health panel for any alerts. Checking that there is no increase in the number of unregistered desktops in the Desktop Studio dashboard. When you do this, ensure that you are using Desktop Studio on a machine that has been upgraded to Service Pack 1. 10. Apply the database schema upgrade as follows: 1. Start Desktop Studio on a machine that has been upgraded to Service Pack 1 and view the dashboard for your site. You must either log on as a user with the db_owner role on the database, or you must know the credentials of an account that does have the necessary permissions. 2. 3. Click Upgrade. You can choose to either upgrade the database automatically, or use scripts to upgrade it manually later. If you choose to upgrade it automatically, the upgrade takes place immediately. If you choose to upgrade it manually, each script then appears in a Microsoft Notepad window that includes a header with instructions describing how to use the script. Remember that you should not upgrade the other controllers on your site until you have upgraded the database schema. The database is now incompatible with the non-upgraded controllers. The database is, however, compatible with the upgraded controllers, which should allow the site to continue to function while you upgrade the remaining controllers. 11. 12. 13. 14. Validate the health of your site again as described in step 9. Repeat steps 3 through 7 on your remaining controllers. Upgrade any machines that are running Desktop Studio remotely. To do this, run the Service Pack 1 installation wizard as described in steps 4 to 6: Desktop Studio is automatically upgraded. Validate the health of your site again as described in step 9.

When you upgrade XenDesktop, the default licensing model changes to user/device. If you have only concurrent licenses installed you must reconfigure the licensing model appropriately, as described in Managing Licensing. Note: If you have a proof-of-concept site with only one controller, upgrade the license server and the controller by following steps 1 through 7. Then upgrade the database as described in step 10. Finally, validate the health of your site as described in step 9.

To install XenDesktop 5 With Service Pack 1 For a fresh installation of XenDesktop 5 with Service Pack 1 on a machine that does not already have

XenDesktop 5 installed, follow the same steps as for installing XenDesktop 5 server components. For details, see Installing and Removing XenDesktop Server Components. 2.2. Managing Licensing Updated: 2011-04-15 You can use Desktop Studio to manage and track licensing as described in this topic, provided the license server is in the same domain as Desktop Studio, or in a trusted domain. For information about other licensing tasks, see Licensing Your Product. You must be a full XenDesktop administrator to carry out the tasks described below, except for viewing license information, which any type of XenDesktop administrator can do. To access the License Administration Console Note: By default, the License Administration Console is configured for access only from the machine on which it is installed. To enable remote access, disable the inbound Citrix Licensing Web Port rule. 1. 2. 3. 4. Select the Configuration node in the left pane of Desktop Studio. Select Licensing. From the Actions list in the right pane select License Administration Console. If you are the first user to access the License Administration Console after it was installed, you are prompted to set the password for the default console administrator account, which is automatically created when the console is installed (the user name for this account is 'admin'). The console then appears. If other XenDesktop users will need to access the console, you must create License Administration Console user accounts for them as described in the topic about configuring console users in Licensing Your Product. Note: After you have enabled the console by creating the admin password, you cannot disable it. If the default administrator account and password have already been created when you select to access the License Administration Console, either the console appears immediately, or, if the dashboard has been configured to be password-protected, you are prompted for your License Administration Console credentials. For details of how to use the console, see Licensing Your Product. Note: If you upgraded the license server from version 11.6.1, or if you installed it using ctx_licensing.msi, you do not need to enable the License Administration Console.

To select the type of license to use When configuring the site, after you specify the license server you are prompted to select the type of license to use. If there are no licenses on the server, the option to use the product for a 30-day trial period without a license is automatically selected. If there are licenses on the server, their details are displayed and you can select one of them. Both concurrent licenses and user/device licenses are displayed. Alternatively, you can add a license file to the server and then select that one. To change the product edition and licensing model 1. 2. 3. 4. Select the Configuration node in the left pane of Desktop Studio. Select Licensing. Select Edit licensing model. All product editions and licensing models available for XenDesktop are displayed, with the current configuration selected. Update the appropriate options, then click OK.

To change the license server

1. 2. 3. 4.

Select the Configuration node in the left pane of Desktop Studio. Select Licensing. Select Change license server. Type the address of the license server to use, then click OK. You must specify the address as name:port , where name can be a DNS, NetBIOS, or IP address. If you do not specify a port number, the default port (27000) is assumed.

To view license information 1. 2. Select the Configuration node in the left pane of Desktop Studio. Select Licensing. A summary of XenDesktop license usage and settings for the site is displayed together with a list of all the XenDesktop licenses currently installed on the specified license server.

To add a license 1. 2. 3. 4. Select the Configuration node in the left pane of Desktop Studio. Select Licensing. Select Add license. Browse to a license file and add it to the license server.

2.3. Using IntelliCache with XenDesktop Updated: 2011-05-11 IntelliCache makes hosted VDI deployments more cost-effective by enabling you to use a combination of shared storage and local storage. Performance is enhanced, and network traffic is reduced. The local storage caches the master image from the shared storage; this reduces the amount of reads on the shared storage. For shared desktops, writes to the differencing disks are written to local storage on the host and not to shared storage. Citrix recommends that you use a high performance local storage device to ensure the fastest possible data transfer. To use IntelliCache you must enable it in both XenServer and XenDesktop. To enable IntelliCache in XenServer Select Enable thin provisioning (Optimized storage for XenDesktop) when installing XenServer. Citrix does not support mixed pools of servers that have Intellicache enabled and servers that do not. For further information on using IntelliCache, refer to the chapter called XenServer and IntelliCache in the Citrix XenServer 5.6 Service Pack 2 Installation Guide, available from http://support.citrix.com/article/CTX129387. To enable IntelliCache in XenDesktop IntelliCache is disabled by default in XenDesktop. You can enable it when you are adding a host, provided the XenServer pool is XenServer 5.6 Service Pack 2 or later. You can update the setting only when the host is created; you cannot disable IntelliCache at a later date. The option to enable IntelliCache is not available if you are configuring a site using Quick Deploy. 1. 2. When you are adding a XenServer host and you are prompted for the type of storage to use, select Shared . Select Use IntelliCache to reduce load on the shared storage.

3. About XenDesktop 5 Updated: 2011-03-11 Citrix XenDesktop offers a powerful and flexible desktop virtualization solution, allowing you to deliver virtual desktops to users anywhere, no matter what device they are using. So, regardless of whether your users are task workers, power users, contractors, or mobile workers, you can use XenDesktop to provide

them with desktops tailored to their individual performance and personalization needs. Virtual desktops are assembled dynamically on demand, providing pristine yet personalized desktops, each time users log on. Powered by Citrix HDX technologies, XenDesktop provides a superior user experience with Flash multimedia and applications, 3D graphics, webcams, audio, and branch office delivery, while using less bandwidth than alternative solutions. Performance never degrades, and the high speed delivery protocol provides unparalleled responsiveness over any network. Although the desktops are virtual, running on remote servers, the user experience is equivalent to that of a local Windows desktop. From the user's perspective, logging on to a virtual desktop is the same as logging on to a local desktop. Users enter their credentials once and are connected to their desktops. With XenDesktop's FlexCast delivery technology, you can deliver every type of virtual desktop: hosted or local, physical or virtual. XenDesktop supports the full range of desktop virtualization technologies, such as server-based models in which up to 500 shared virtual desktops can be hosted on a single physical server, and VDI (virtual desktop infrastructure) where the desktop runs inside a virtual machine on a server in the data center. XenDesktop simplifies the task of creating, managing, and delivering virtual desktops to users. You build a master desktop image and then use XenDesktop to create user desktops from this image. Groups of virtual desktops are created and managed as a single entity, which enables you to assign, update, and extend thousands of user desktops quickly and easily. And, with the full integration of Citrix XenApp, you can deliver on-demand applications as a seamless part of your overall desktop management strategy, extending the benefits of virtualization throughout the enterprise. 3.1. Key Features Updated: 2010-11-12 Citrix XenDesktop provides the following key features: Superior user experience. Users are instantly provisioned with a pristine desktop that incorporates their personal settings and applications, regardless of the user device. Users get the business and productivity applications they need delivered to their virtual desktops. Profile management ensures that personal settings are applied to their virtual desktop and applications, regardless of user device or location. Users can easily request support and the help desk can view their screen and take control of the desktop, using Microsoft Remote Assistance, to resolve issues quickly. High definition performance and multimedia support. With Citrix HDX, network and display optimizations and performance boosting technologies deliver the best performance over any network, including low-bandwidth and high-latency WAN connections. HDX in the datacenter leverages the processing power and scalability of servers to deliver advanced graphical and multimedia performance, regardless of the capabilities of the user device. HDX on the network incorporates advanced optimization and acceleration capabilities to deliver a great user experience over any network, including remote desktop access over high-latency, low-bandwidth environments. HDX at the device leverages the computing capacity of user devices to enhance and optimize the user experience. HDX MediaStream technology ensures users receive a smooth, seamless experience with multimedia content as part of their virtual desktop. HDX MediaStream Flash Redirection enables Adobe Flash content to play locally on user devices, providing users with high definition playback. And with SmoothRoaming, users can pause desktop sessions and resume working from different locations at exactly the point where they left off. Single image desktop management. Maintaining a single master desktop image in the data center provides users with an up-to-date, pristine desktop at each logon, drastically reduces patch and upgrade maintenance efforts, and cuts storage costs by up to 90 percent. Built-in virtual applications. Using XenApp with XenDesktop allows you to separate applications from the desktop, resulting in fewer, simpler desktop images. 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. This reduces system conflicts, application regression testing, and increases virtual desktop density. Delivering streamed and hosted applications provides greater flexibility and simpler management. Control over data. Centralized control policies ensure that authorized users connect to their desktops and that only screen updates, mouse clicks, and keystrokes (not data) transit the network. High performance, standards-based encrypted transmissions are used to deliver desktops using SSL technology to both internal and remote users. Multifactor authentication enables and enforces secure tokens and smart card authentication to virtual desktops.

Desktop optimization and support. XenDesktop proactively ensures that users always benefit from optimized performance when using their virtual desktops. This provides a LAN-like experience, even for branch office workers. Using Desktop Director, IT Support staff can monitor a XenDesktop deployment and identify performance issues. This helps organizations maintain a healthy XenDesktop deployment and end-user experience, and enables IT departments to meet service level targets. XenDesktop also provides fast, easy, and secure remote support services for an enhanced user support experience. Open architecture. XenDesktop integrates with Citrix XenServer, Windows Server 2008 Hyper-V, and VMware vSphere, and works out-of-the-box with thin clients. This means that there is no vendor lock-in for virtualization or user devices. For additional, dedicated computing resources for power users, you can host desktops on blade PCs or on standard PCs relocated to the data center. Users can access their virtual desktops from most common client devices, including Windows, Mac OS, and Linux. Best desktop total cost of ownership. XenDesktop centralizes and simplifies desktop lifecycle management, dramatically reducing storage and user device costs. The entire desktop lifecycle is managed in one location, simplifying desktop provisioning, patching, security, and updates. Appliance costs are reduced through minimal user device maintenance, lower power consumption, longer hardware lifecycles, and the ability to repurpose aging devices. Storing one desktop image for thousands of users reduces storage requirements, and using low power thin clients and consolidating virtual desktops on servers reduces overall energy consumption and cooling requirements. XenDesktop can automatically power down or suspend desktops that are not in active use (at the administrator's discretion), further reducing power consumption and increasing resource utilization. Smart card support. Smart card support provides user authentication to XenDesktop sessions and locally installed or virtualized applications, and allows users to digitally sign or encrypt documents. Common Access Card (CAC) and USB smart card tokens are supported. Authentication using smart cards is available for virtual desktops running Windows XP, Vista and 7. Profile management. Profile management provides an easy, reliable, and high performance method to manage user personalization settings in virtualized or physical Windows environments. It requires minimal infrastructure and administration but provides users with fast logons and logoffs. Profile management can be downloaded from the MyCitrix Web site. Local peripheral support. XenDesktop users can insert a USB device locally and use it with their virtual desktops and applications as they would on a local machine. Supported USB devices include: flash drives, smartphones, PDAs, printers, scanners, MP3 players, and tablets. With HDX Plug-n-Play USB Support, isochronous devices, such as Webcams, microphones, speakers and headsets, are also supported. Devices are supported in typical low latency/high speed LAN environments. Support for Bloomberg keyboard devices is also included. Multi-monitor support. Users' particular multiple monitor configurations are reflected in their virtual desktop. For example, users can configure their XenDesktop environment with L-shaped, T-shaped and Ushaped monitor configurations or with monitors of different sizes and resolutions. HDX Plug-n-Play MultiMonitor Support ensures application compatibility with multi-monitor configurations. Users have greater control using the Desktop Viewer toolbar. For more information on multi-monitor support, see the administrator documentation for the Citrix online plug-in. User-driven desktop restart. You can provide users with the ability to shut down and restart their desktops, thus reducing calls to the help desk. Active Directory multi-forest support. XenDesktop supports deployment across a range of Active Directory topologies, including multiple domains and multiple forests. This enables virtual desktops to be delivered to users in different Active Directory forests from those in which the XenDesktop infrastructure servers are registered. 3.2. XenDesktop Components Updated: 2010-11-12 Citrix XenDesktop provides a complete virtual desktop delivery system by integrating several distributed components with advanced configuration tools that simplify the creation and real-time management of the virtual desktop infrastructure. This figure shows the key components in a typical XenDesktop deployment.

The core components of XenDesktop are: Controller. Installed on servers in the data center, the controller consists of services that authenticate users, manage the assembly of users' virtual desktop environments, and broker connections between users and their virtual desktops. It controls the state of the desktops, starting and stopping them based on demand and administrative configuration. In some editions, the controller allows you to install Profile management to manage user personalization settings in virtualized or physical Windows environments. Virtual Desktop Agent. Installed on virtual desktops, the agent enables direct ICA (Independent Computing Architecture) connections between the virtual desktop and user devices. Citrix online plug-in. Installed on user devices, the Citrix online plug-in enables direct ICA connections from user devices to virtual desktops. Machine Creation Services. A collection of services that work together to create virtual desktops from a master desktop image on demand, optimizing storage utilization and providing a pristine virtual desktop to each user every time they log on. Desktop Studio. Enables you to configure and manage your XenDesktop deployment. Desktop Studio provides various wizards to guide you through the process of setting up your environment, creating your desktops, and assigning desktops to users. Desktop Director. Enables level-1 and level-2 IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. You can also view and interact with a user's session, using Microsoft Remote Assistance, to troubleshoot problems. Citrix XenApp. You can use XenApp in a XenDesktop deployment to benefit from the efficiencies associated with application streaming and virtualization. XenApp provides a better-than-installed application experience for both users and administrators. Applications start up faster, the user experience is dramatically improved, and application management costs are significantly lowered. Citrix XenServer. XenServer is an enterprise-class virtual machine infrastructure solution that creates

the foundation for delivering virtual desktops and offers advanced management features. Multiple VMs can run on XenServer, which takes advantage of the advanced virtualization features of the latest virtualizationenabled processors from Intel and AMD. For more information about XenServer, see the Citrix XenServer Administrator's Guide. Additional XenDesktop components provide the following features: Secure delivery. When users connect from outside the corporate firewall, XenDesktop can use Citrix Access Gateway technology to secure these connections with SSL. Access Gateway is a SSL VPN appliance that is deployed in the demilitarized zone (DMZ) to provide a single secure point of access through the corporate firewall. WAN optimization. In XenDesktop deployments where virtual desktops are delivered to users at remote locations such as branch offices, Citrix Branch Repeater (formerly WANScaler) technology can be employed to optimize performance. Repeaters accelerate performance across wide area networks, so with Repeaters in the network, users in the branch office will experience LAN-like performance over the WAN. Branch Repeater can prioritize different parts of the user experience so that, for example, the user experience does not degrade in the branch location when a large file or print job is sent over the network. HDX WAN Optimization with Branch Repeater provides tokenized compression and data deduplication, dramatically reducing bandwidth requirements and improving performance. For more information, see your Citrix Branch Repeater documentation. Monitoring. Citrix EdgeSight for Virtual Desktops allows you to monitor individual virtual desktops. EdgeSight can be used not only to analyze and troubleshoot issues, but also to warn administrators in advance of problems that may arise in the future. Single Sign-on. Citrix Single sign-on provides single sign-on access regardless of how or where users connect, and it enables users to reset their own Windows password or unlock their account. 3.3. What's New in XenDesktop 5 Updated: 2010-09-01 Simplified desktop deployment and machine creation. XenDesktop simplifies the task of creating, managing, and delivering virtual desktops to users. XenDesktop's wizards guide you through the process of setting up your deployment, provisioning desktops by building a master image and creating user desktops, and then assigning desktops to users. Groups of user desktops are created and managed as a single entity, which enables you to assign, update and extend thousands of user desktops quickly and easily. XenDesktop supports desktops hosted on both VMs and on physical computers. Simplified install. New installation wizards simplify the process of installing and setting up a XenDesktop deployment. A wizard guides you through the installation of server-side XenDesktop components, including the controller, the Desktop Studio management console, licensing, and the Web Interface. The wizard also guides you through individual component installations, and pre-configures these for you (for example, it will build all the Web Interface sites). A separate wizard guides you through the installation of the Virtual Desktop Agent on virtual desktops or on a base image. Desktop Studio. This tool snaps into the Microsoft Management Console (MMC) and enables you to configure and manage your XenDesktop deployment. Desktop Studio provides various wizards to guide you through the process of setting up your environment, creating your desktops, and assigning desktops to users. Desktop Director. This Web-based tool enables level-1 and level-2 IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. You can use the Desktop Director to monitor status, such as the health of the hypervisors and controllers in a site. You can manipulate sessions and desktops, such as restarting a desktop or logging off a session. You can also view and interact with a user's session, using Microsoft Remote Assistance, to troubleshoot problems. Active Directory-based policies. XenDesktop 5 uses the Windows Active Directory-based policy mechanism for Citrix policies. Citrix policies allow you to control user access or session environments, and are the most efficient method of controlling connection, security, and bandwidth settings. You can specify policies that are shared between XenDesktop and XenApp; for example, you can turn Client Drive Mapping off using one policy. Printing optimizations. XenDesktop 5 provides administrators and users with the ability to optimize printing in their virtual desktop environment. Using printing preferences and policies to configure resolution, color depth and compression, administrators can optimize for better print quality or faster printing. Users can also modify print quality by adjusting dpi settings.

Evaluation tool. A new Proof of Concept wizard simplifies the process of setting up a XenDesktop deployment for evaluation purposes. The wizard guides you through the stages of creating and provisioning desktops, making it quick and easy to configure and evaluate XenDesktop. Improved smart card single sign-on from non domain-joined user devices. Improvements to smart card authentication mean that users only need to enter their smart card PIN once to log onto their virtual desktops from non domain-joined Windows thin clients. Removing repetitive prompts for the smart card PIN is particularly beneficial to users roaming between different thin clients who quickly need to reconnect to their virtual desktops. For more information about configuring smart card authentication for non domainjoined desktop appliances, see your Web Interface documentation. Video Conferencing. HDX RealTime provides users with a complete desktop video conferencing feature. Dynamic color compression. This improves the overall user experience by dynamically adjusting color compression based on network conditions. 32-bit color support. 32-bit color session support improves XenDesktop's application compatibility. 3.4. XenDesktop Features and Editions Updated: 2011-02-18 XenDesktop is offered in four editions: Platinum. A comprehensive enterprise-class desktop virtualization solution with advanced management and security, in addition to the features of Enterprise edition. Enterprise. An enterprise-class desktop virtualization solution with on-demand applications and FlexCast delivery technology, in addition to the features of VDI edition. VDI. For scalable Virtual Desktop Infrastructure (VDI) implementations with Citrix HDX technology. Express. A free download to help IT professionals get started with VDI, which supports up to 10 users. The components in each edition are listed below. Note: Key components are listed only; this list is not comprehensive. Licensing Named User Licensing 10 users Device based licensing Concurrent User Licensing Component Controller Limited 1 XenServer 2 XenServer XenServer, 3 Enterprise Edition 4 Receiver Desktop Studio Machine Creation Services Desktop Director XenServer, Enterprise Edition 4 XenServer, Enterprise Edition 4 Express VDI Enterprise Platinum

Workflow Studio Profile management StorageLink Access Gateway 5 XenApp XenVault Provisioning services for desktops6 Provisioning services for servers XenClient and Synchronizer EdgeSight for Virtual Desktops Branch Repeater 7 Single Sign-on 1. 2. 3. 4. Supports up to 10 users. Included free in all editions of XenDesktop. XenDesktop VDI, Enterprise and Platinum also include XenServer, Enterprise Edition. The new, free version of XenServer may be used for any server or desktop workload. XenServer, when acquired as part of XenDesktop, can only be used to manage hosted desktops and Citrix-provided components included with your XenDesktop license, such as the Controller, license and Web servers, and XenApp servers. You cannot use the XenServer included with XenDesktop to host other server workloads, or servers used for XenApp purchased separately from XenDesktop. These restrictions also apply to the provisioning services included with XenServer: you may use provisioning services for desktops and for server workloads that are part of Citrix-provided XenDesktop infrastructure, including XenApp, but no other server workloads. Access Gateway appliances or Access Gateway VPX must be purchased separately. All editions of Access Gateway are compatible with the XenDesktop editions that include Access Gateway; for example, you can use Access Gateway Enterprise Edition to provide ICA-only remote access to XenDesktop VDI or Enterprise editions. Streaming to VMs for VDI purposes is available in VDI, Enterprise, and Platinum; streaming to endpoints ("Streamed VHD") is available in Enterprise and Platinum only. Branch Repeater VPX included (throughput up to 45 Mbps per instance) for all branch offices and data centers; Branch Repeater appliances must be purchased separately. Branch Repeater VPX, when acquired as part of XenDesktop Platinum Edition, may be used only to support office locations to which XenDesktop virtual desktops and applications are being delivered. Platform License Platform License Enterprise Universal License Platinum

5.

6. 7.

3.4.1. Features in XenDesktop VDI Edition Updated: 2010-11-12 The VDI Edition provides the following features: Desktop Director. This Web-based tool enables level-1 and level-2 IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. You can use the Desktop Director to monitor status, such as the health of the hypervisors and controllers in a site. You can manipulate sessions and desktops, such as restarting a desktop or logging off a session. You can also view and interact with a user's session, using Microsoft Remote Assistance, to troubleshoot problems. Smart card support. Smart card support provides user authentication to XenDesktop sessions and locally installed or virtualized applications, and allows users to digitally sign or encrypt documents. Local peripheral support. Users can insert a USB device locally and use it with their virtual desktops and applications as they would on a local machine.

User-driven desktop restart. If the desktop fails to start or is taking a long time to connect, users can use the desktop restart option to shut down and restart the desktop. SmoothRoaming. With SmoothRoaming, users can pause desktop sessions and resume working from different locations at exactly the point where they left off. Multimedia support. Citrix HDX includes a broad set of technologies designed to provide users of virtual desktops with a high definition audio-visual experience, comparable to a local PC. For example, HDX MediaStream ensures a smooth, seamless experience with multimedia content, and provides support for Media Foundation used by Windows Media Player. HDX MediaStream Flash Redirection enables Adobe Flash content to play locally on user devices, providing users with a high definition playback. HDX Plug-n-Play enables simple connectivity for USB, multi-monitor, printers and other peripheral devices, as well as local machine resources. Other HDX technologies ensure that the delivery of virtual desktops is optimized for any network, whether local or remote. Instant on. XenDesktop virtual machines are kept running in idle pools so that new virtual desktops are ready for users when they log on, eliminating the lengthy startup times of physical computers and increasing productivity. Universal printer driver. XenDesktop delivers a consistent and fast printing experience for users without requiring specific local printer drivers. Users can simply plug in USB-compatible printers to their user devices. Virtual machine infrastructure. XenDesktop uses XenServer, an integrated 64-bit paravirtualization-based hypervisor, for scalable, cost-effective hosting of virtual desktops. XenServer delivers live migration and centralized multi-server management, radically reducing datacenter costs by transforming static and complex datacenter environments into dynamic, easy to manage IT service delivery centers. In addition, XenDesktop also supports Microsoft Windows Server 2008 Hyper-V and VMware vSphere, plus a wide range of hardware, applications, and user devices. Desktop assignment. XenDesktop allows administrators to assign different types of virtual desktops to different users, including blade PC-based desktops, dedicated virtual machine-based desktops, and pooled desktops for groups of users. Session management. XenDesktop allows administrators to manage active and inactive virtual desktop connections. Administrators can view the servers to which users are connected and log them off if necessary. Session reliability. This feature maintains users' virtual desktops during network outages. When the network connection is re-established, users can resume their work without any interruption. High availability/failover. XenDesktop eliminates single points of failure by providing failover capability. Users can continue to access and use their virtual desktops even when individual servers fail. On-demand desktops. XenDesktop allows administrators to configure resources into pools so that common configuration settings can be applied on a pool-wide basis, greatly simplifying reconfiguration tasks. Desktop image management. XenDesktop allows administrators to manage multiple virtual desktops from a single desktop image. Administrators can easily create a new virtual desktop image, update an existing image, or roll back changes without any downtime. Workflow Studio. This provides an easy-to-use, graphical interface for workflow composition that virtually eliminates scripting. Workflow Studio acts as the glue across the IT infrastructure allowing administrators to easily tie technology components together via workflows. Profile management. XenDesktop provides an easy, reliable, and high performance method to manage user personalization settings in virtualized or physical Windows environments. StorageLink. This technology lets your virtual server infrastructures fully utilize all the resources and functionality of existing storage systems. Receiver. Citrix Receiver is a new, lightweight software client that makes it easy to access virtual applications and desktops on any device. Receiver allows IT organizations to deliver desktops and Windows, Web or SaaS applications as an on-demand service to any device in any location with a rich "high definition" experience. For users, Citrix Receiver makes it easy to work anywhere with the same, simple experience in the office, travelling, or at home; users simply connect and work. For IT administration, Receiver makes it quick and easy to deliver new client software or updates without the complexity of packaging and distribution generally associated with other solutions, while reducing the cost of desktop management.

3.4.2. Features in XenDesktop Enterprise Edition

Updated: 2010-11-05 The Enterprise Edition includes all the features in the VDI Edition, plus the following: XenServer. XenServer adds valuable management features, including high availability, provisioning services, and alerting. XenApp. Citrix XenApp is an application delivery system that offers client-side and server-side application virtualization for optimal application performance and flexible delivery options. This allows the delivery of secure applications as a service, while providing the flexibility to use future application architectures. XenClient and Synchronizer. XenClient allows you to extend the benefits of desktop virtualization to laptop users. XenClient is a client-side hypervisor that enables virtual desktops to run directly on client devices. By separating the operating system from the underlying hardware, desktop images can now be created, secured, deployed and moved across any supported hardware, greatly reducing the maintenance burden on IT and simplifying disaster recovery for laptop users. Synchronizer adds centralized management, secure backup and self-service restore of virtual machines running on XenClient laptops. XenVault. Citrix XenVault extends the built-in security protection provided with delivering applications in a hosted virtual environment to include XenApp data encryption on the local device. IT can centrally manage encryption with granular application and data access policies, and can easily lock and delete data in the event of loss, theft or termination. Administrators can establish time-based lockout periods and implement self-service password resets-unlocks enhancing user experience while maintaining security and control of the local device.

3.4.3. Features in XenDesktop Platinum Edition Updated: 2011-02-09 The Platinum Edition includes all the features in the Enterprise Edition, plus the following: Citrix Access Gateway Enterprise Edition. Access Gateway provides secure remote access to XenDesktop. Desktop performance monitoring. This feature monitors and tracks the performance of virtual desktops, allowing administrators to proactively manage the virtual desktop experience by measuring key performance elements. This data can then be used to enhance the infrastructure before users are adversely affected. HDX WAN optimization. XenDesktop maximizes the quality of the branch and mobile user experience by using Citrix Branch Repeater to accelerate virtual desktop and application performance across wide area networks. Citrix Single Sign-on. Single Sign-on (formerly known as "Password Manager") provides single signon access regardless of how or where users connect, and it enables users to reset their own Windows password or unlock their account.

3.5. Information for Customers of Previous Versions Updated: 2011-03-14 Read this section only if you have used previous versions of XenDesktop. It tells you about important conceptual and architectural changes in XenDesktop 5, and changes in the terminology used throughout the documentation. Changes to key tools, which you may have used in earlier XenDesktop versions, are also discussed. There are key differences between XenDesktop 5 and previous releases that you need to be aware of, particularly if you have an existing deployment and intend transitioning this to XenDesktop 5 to take advantage of the new features and functionality. Terminology and conceptual changes Terminology in XenDesktop 5 has changed in line with industry standards. Key conceptual and terminology changes include: Farms are now referred to as sites. Think of a site as a deployment of XenDesktop in a single geographical location.

A catalog is a collection of user desktops managed as a single entity. Catalogs specify virtual machines (VMs) or physical computers that host user desktops, the Active Directory computer accounts assigned to those VMs or computers, and, in some cases, the master VM that is copied to create the user desktops. Desktop groups and the virtual desktops they contain can be configured more flexibly. A single desktop group can contain desktops from a number of catalogs rather than being limited, as in earlier versions, to a single hypervisor pool. Also, a single desktop group can be published to users so that a single user may access multiple desktops in the group, and a single desktop may be assigned for use by multiple users. Desktops can also be assigned to client machines, rather than users, if required. A host is the infrastructure on which desktops are hosted, which comprises of hypervisors (resource pools or clusters), storage etc. Key architectural differences In addition to the new features, note the following differences in XenDesktop 5's design and the consequences of these: No IMA data store. XenDesktop 5 no longer uses the IMA data store as the central database in which to store configuration information. Instead, a Microsoft SQL Server database is used as the data store for both configuration and session information. This means: Database requirements are different: Microsoft Access and Oracle are no longer supported databases. Terminal Services is no longer required on servers running the controller. There is no longer a dedicated zone master. In previous XenDesktop versions, there was a zone master/data collector responsible for user connection requests and communication with hypervisors. In XenDesktop 5, this function is distributed evenly across all controllers in the site. Due to reliance on Microsoft SQL Server, to ensure failover should the database become unavailable, you must use either SQL clustering or mirroring, or deploy the database as a virtual machine and use your hypervisor's high availability features instead. For more information about planning for high availability, see High Availability Planning. Registry-based discovery. The default mechanism for desktops to find controllers is now registrybased. An Active Directory Organizational Unit is no longer required, although you can still use Active Directory-based registration. Active Directory is still needed in a XenDesktop deployment for authentication and authorization, therefore machines need to be domain-joined regardless of whether you use registry-based discovery or not. SDKs. XenDesktop 5 provides a new PowerShell SDK which allows you to perform the same tasks as you would with the Desktop Studio console. You can also perform tasks with the SDK that you cannot do with the console, such as assigning an IP address to a desktop, rather than a user name. Desktop Studio is built upon the PowerShell SDK; you can display the PowerShell in use in the console. For more information about using the SDK, see Using the XenDesktop SDK and the PowerShell cmdlets. Note that the new PowerShell SDK is not compatible with the SDK associated with previous XenDesktop releases. Changes to Key Tools This topic lists changes to key tools you may have used in earlier versions of XenDesktop, and explains where you can find equivalent functionality in XenDesktop 5. As a result of architectural changes, particularly use of an SQL database rather than an IMA data store, some tools are no longer applicable or available in XenDesktop 5. These tools include: DS maint. Tool used to perform data store maintenance tasks, such as backing up the data store or migrating the data store to a new server. There is no equivalent supplied for XenDesktop 5; use standard database tools instead. Active Directory Configuration wizard. Tool for configuring Active Directory. In XenDesktop 5, use the new PowerShell script Set-ADControllerDiscovery.ps1, available from the \Broker\SetupScripts directory. AutoFarmTuner. Tool to optimize IMA data collectors in large deployments. There is no equivalent supplied for XenDesktop 5; use standard database optimization tools to optimize database access.

DdcSdk. The XenDesktop Delivery Controller PowerShell SDK available in earlier releases. In XenDesktop 5, use the new PowerShell SDK for the controller and the other components and services. DsView and QueryDC. Tools to examine the contents of the IMA data store. XenDesktop 5 equivalent data can be seen using the SDK or by examining database tables directly using standard SQL server tools such as SQL Server Management Studio. QueryDS and QueryHR. Tools to examine the contents of the IMA dynamic store. XenDesktop 5 equivalent data can be seen using the SDK or by examining database tables directly using standard SQL server tools such as SQL Server Management Studio. Ftacln. Tool to tidy up file type associations on client machines using PNAgent. Do not use PNAgent with XenDesktop 5 except in the 'repurposed PC as dedicated thin client' case. Sslautoconfig. Tool for setting up certificates used for secure sockets, particularly the SSL relay tool for handling XML traffic in XenDesktop 4. This tool is no longer relevant in XenDesktop 5. XenDesktop Setup Wizard. Tool to automate the creation of machines with Provisioning Services. In XenDesktop 5, this functionality is available in the Provisioning Services Console. Install the latest hotfixes for Citrix Provisioning Services 5.6 Service Pack 1 to add this capability to your XenDesktop 5 deployment. For more information, see http://support.citrix.com/article/CTX128726 . Alternatively, use the provisioning capabilities of Desktop Studio and Machine Creation Services. DSCheck, DSMaint, sqlfix. Tools to fix issues in IMA stores and check the consistency/validity of the IMA data store. This is not relevant to XenDesktop 5; use constraints checks in the database instead. ChFarm. Tool to move a Controller into or out of a farm. In XenDesktop 5, you can script this process using the new PowerShell SDK and SQL scripts. IMAPort. Tool to query or change the IMA port. This is no longer relevant in XenDesktop 5. AIEADF, AIEUN, AIECom, AIESetup, qaie. Tools relating to application isolation. Not relevant in XenDesktop 5. Acrcfg, altaddr, chgcdm, cltprint, cshadow, twconfig, ss3admin, softkey. Tools for XenAppspecific functions such as automatic client reconnect, IMA address settings, client-drive mapping, printer pipe handling, and session shadowing. Not relevant in XenDesktop 5. Auditlog. Tool for extracting IMA audit logging. Not relevant in XenDesktop 5. DriveRemap. Tool to remap Windows drives. Not relevant in XenDesktop 5. EnableLB. Tool for handling XenApp load balancing. Not relevant in XenDesktop 5. Mfcom, mfreg. Tools for dealing with SDK-level access to XenDesktop/XenApp. Not relevant in XenDesktop 5; use the new XenDesktop PowerShell SDK instead. Qserver, qfarm. Tools for examining the contents of the IMA dynamic/persistent store. XenDesktop 5 equivalent data can be seen using the SDK or by examining database tables directly using standard SQL server tools such as SQL Server Management Studio. ProductEdition.exe. Tool for changing to a different edition of XenDesktop. In XenDesktop 5, use the new PowerShell SDK.

3.6. Known Issues in XenDesktop 5 Updated: 2011-04-20 Version 1.0 This topic describes known issues in this release of XenDesktop. Read it carefully before installing the product. The number at the end of each item is a Citrix Code Problem Report (CPR) number. Notes: For a list of issues resolved in this release, see http://support.citrix.com/article/CTX124164. To access complete and up-to-date product documentation, go to Citrix eDocs located at http://support. citrix.com/proddocs/index.jsp and expand the topics for XenDesktop 5. To access licensing documentation, go to http://support.citrix.com/proddocs/topic/technologies/lic-librarynode-wrapper.html. Installation Issues If you are installing XenDesktop on Windows Server 2008 R2 or Windows 7, and the installation of .

NET Framework requires a restart, an error message appears telling you that the installation has failed because of a problem with .NET Framework. If you then restart the machine and restart the installation, it will continue as expected. To avoid this issue, install .NET Framework before installing XenDesktop. [250439] If Desktop Studio is installed on the same machine as a hotfixed version of the XenApp 6 Delivery Services Console, any additions to the policy set provided by the XenApp hotfix will no longer be available to the Delivery Services Console. To avoid this issue, run Desktop Studio and the Delivery Services Console on separate machines. [251132] If Wyse Xenith Manager fails to install, ensure that you are logged on using either a User Account Control elevated account or the Administrator account. [250339] If you run Quick Deploy then remove XenDesktop and Microsoft SQL Server Express, ensure that you remove the CitrixXenDesktopDB database before reinstalling and running Quick Deploy again: If you have removed XenDesktop, but not Microsoft SQL Server Express, you can use SQL Server to drop the database, which removes it entirely If you have already removed Microsoft SQL Server Express, you must manually delete the files it leaves behind. These are CitrixXenDesktopDB.mdf and CitrixXenDesktopDB_log.LDF in C: \Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQLDATA If you do not remove the database, Quick Deploy cannot recreate it and fails with the message "Exception has been thrown by the target of the invocation". [252423] Japanese only: the XdsAgent_(x86|x64)_ja-JP.msi files needed for remote Group Policy Object installation are not signed. If you have set the Active Directory Group Policy Object setting that prevents unsigned software from being installed, these files do not install. To avoid this issue, do either of the following: Use the signed standard version of the files, but this results in some internal strings (for example service names) being in English in the Virtual Desktop Agent. Manually install the signed standard version on the Virtual Desktop Agent. This then selects the right Japanese transform. [251727]

HDX HDX RealTime Video Conferencing does not automatically reconnect if the session connection is interrupted mid-conference. The user should restart the video conference. [233296] HDX RealTime webcam video compression currently supports Microsoft Office Communicator 2007 only. Other third-party conferencing applications may work with HDX RealTime webcam video conferencing, but Citrix has not tested and therefore does not support these applications. [241847] HDX 3D for Professional Graphics 1.1 is not supported and does not work with XenDesktop 5. To use HDX 3D for Professional Graphics 1.1, users must have access to a XenDesktop 4.x controller that works with the XenDesktop 4.x Virtual Desktop Agent. HDX MediaStream is not supported for Media Foundation-based media types on virtual desktops running on Windows Vista x64. The media will be rendered on the server side on Windows Vista x64 virtual desktops. [218535] User devices running the Citrix online plug-in must have direct network access to Adobe Flash content to support HDX MediaStream for Flash. If you have managed, locked-down devices that cannot directly access required Flash content, contact Citrix Technical Support for the latest alternatives available. [252495]

Smart Cards Smart card authentication from Linux endpoint devices to Windows 7 or Windows Vista virtual desktops may not work with most smart cards because of incompatibilities between the Linux PC/SC implementation (PCSC-Lite) and the Windows 7 and Windows Vista PC/SC implementation. A future updated version of PCSC-Lite (that is, later than 1.6.4) may resolve this issue. [239718, 217188] Smart card authentication from Linux endpoint devices to Windows XP virtual desktops may not work with some smart cards because of the limitations of the Linux PC/SC implementation (PCSC-Lite). A

future updated version of PCSC-Lite (that is, later than 1.6.4) may resolve this issue. Citrix is actively working to resolve the issue on the client side: check the Citrix Web site for the latest updates. [243362] When smart card authentication is used with certain smart cards with the Citrix Receiver for Linux 11.x on Redhat Enterprise (Desktop) 5.x user devices, attempting to launch a desktop results in the error message: "Client Error: Cannot load PCSC library libpcsclite.so" appearing. The user can select OK or Quit. If OK is selected, the desktop is launched but with no smart card logon option. This occurs because the Citrix Receiver for Linux attempts to load libpcsclite.so but Redhat only installs libpcsclite.so. 1 or libpcsclite.so.1.0.0. To address this error, create a symbolic link to 1.0.0. You can do this from a terminal as root by typing: ln -s /usr/lib/libpcsclite.so.1.0.0 /usr/lib/libpcsclite.so [218198] Logoff from domain-joined user devices running in full-screen-only mode may occur unexpectedly, depending on how smart card removal behavior is configured. This occurs if Microsoft Active Directory Group Policy is used to define smart card removal behavior, and the smart card removal behavior policy defined is different for the user device and the virtual desktop appliance. User devices running in window view mode are unaffected. [218532] Printing If Microsoft KB927489 (JIS2004 fonts) is installed in a Japanese Windows XP virtual desktop, but not installed in a user device or printer server, print corruption may occur with the Universal Print Driver of an autocreated printer. To avoid this issue, install KB927489 in the user device and printer server. [218285] Other Known Issues If there are errors or delays in starting virtual desktops or problems in managing them, this may be because the list of controllers on the virtual desktop system is invalid or incomplete. The ListOfDDCs registry key on the virtual desktop system should contain an up-to-date list of XenDesktop controller systems. Invalid entries in the list can delay the startup of the virtual desktop system software. An incomplete list can prevent the XenDesktop controllers not in the list from being able to manage the virtual desktop. To avoid these issues, ensure that the ListOfDDCs registry key is correct and complete. [248036] If you use Desktop Studio to import computer accounts that are disabled, the accounts are incorrectly marked as available. These accounts can be used to create desktops, but the desktops will not be usable because they will not join the domain and allow logon. The same issue exists with the repair operation that provides the ability to reset the computer account passwords. To avoid this issue, ensure that you import only enabled computer accounts. [250003] If you have installed the default Microsoft SQL Server Express database, you can only use Desktop Studio by default on the controller on which the database server is installed. If you want to use Desktop Studio on another machine (for example joining a second controller to an existing site by running Desktop Studio on that second controller), start the SQL Browser Service on the default controller and change the relevant firewall settings. [240888] If you log on to a controller that has not been added to a site, you must log on as the user who installed XenDesktop on that machine, otherwise when you try to open Desktop Studio the following message appears: "Value cannot be null. Parameter name: address. Reload the snap-in to retry". [250735] If you create a storage unit in XenCenter that has [square brackets] in the name, you cannot use it through Desktop Studio. [243458] XenDesktop supports only ASCII characters in site names when you are using Quick Deploy with VMware ESX, and in naming schemes when you are creating pooled catalogs on VMware ESX. If you use non-ASCII characters, the operation fails. [251999] XenDesktop supports only ASCII characters in ESX data store names when you are creating pooled or dedicated catalogs on VMware ESX. If you use non-ASCII characters, the operation fails. [BUG0033499] On virtual desktops running on 32-bit operating systems, if command-line programs that include cmd. exe are switched to full-screen mode, the session may hang. To recover the session, if you pressed Alt + ENTER to switch mode, press this key combination again. Alternatively, close the session window and restart the session. To prevent this issue occurring, avoid pressing Alt + ENTER in console applications and adjusting the window properties of full-screen applications. You should configure shortcuts to these applications to ensure that they do not automatically start in full-screen mode. You can also use Windows group policy to prevent cmd.exe from starting. [218531]

By default, audio quality is set to High in XenDesktop 5. With version 9.7 of the Client for Java or versions of the Client for Linux earlier than 11.1, an error may occur resulting in audio being disabled in the session. To avoid this issue, configure a policy to set the audio quality to Medium. [218947, 219216]

4. XenDesktop 5 System Requirements Updated: 2010-11-25 These topics describe the requirements for installing XenDesktop components, including the Controller, database, Desktop Studio, Desktop Director, Citrix Licensing, and the Virtual Desktop Agent. Active Directory and host requirements are also described. For the requirements for installing other XenDesktop components, see the product-specific documentation for each component. Important: Some requirements are third-party components supplied on the XenDesktop installation media. Before using XenDesktop, check whether there are any security updates available from the third party, and install any such updates immediately. For the Java Runtime Environment, Citrix strongly recommends that you install an update immediately before using XenDesktop. 4.1. Requirements for Controllers Updated: 2011-03-01 If you intend installing all XenDesktop server-side components on a single server, then this server must meet all the requirements detailed in this topic. Servers must meet the following requirements: One of the following operating systems: Microsoft Windows Server 2008, Standard or Enterprise Edition, with Service Pack 2 installed (32- and 64-bit) Microsoft Windows Server 2008 R2, Standard or Enterprise Edition (64-bit only) Note that you can mix operating systems within a site. Microsoft .NET Framework, Version 3.5, with Service Pack 1. If you do not have this on your server, it is installed automatically for you. The XenDesktop installation media also contain this installer in the Support\DotNet35 folder. Microsoft Internet Information Services (IIS) and ASP.NET 2.0. IIS is required only if you are installing the Web Interface, the License Server, or Desktop Director: For Windows Server 2008, Microsoft IIS Version 7.0. For Windows Server 2008 R2, Microsoft IIS Version 7.5. If you do not have these on your server, you may be prompted for the Windows Server installation media, and they are installed for you. Microsoft Visual J# 2.0 Redistributable Package, Second Edition. This is required only if Web Interface is installed on the server. If you do not have this on your server, it is installed automatically for you. The XenDesktop installation media also contain this installer in the Support\JSharp20SE folder. Microsoft Visual C++ 2008 with Service Pack 1 Redistributable Package. If you do not have this on your server, it is installed automatically for you. The XenDesktop installation media also contain this installer in the Support\vcredist folder. Microsoft Windows PowerShell version 2.0. If you are using Windows Server 2008 (not Windows Server 2008 R2), Microsoft Windows Management Framework is installed automatically if not already present on the computer, and

this download includes Microsoft Powershell 2.0. However, the installation needs to download Microsoft Windows Management Framework, so ensure an internet connection is available or preinstall Microsoft Windows Management Framework. Internet Explorer 7.0 or later if you are running the license server on the controller. Disk space requirements: 100 MB for the Controller and SDKs 50 MB for Desktop Studio 50 MB for Desktop Director 40 MB for the licensing components 100 MB for Web Interface (and clients included in the installation)

4.2. Database Requirements Updated: 2010-12-13 The Controller supports the following versions of the Microsoft SQL Server database: Microsoft SQL Server 2008 R2 Microsoft SQL Server 2008 R2 Express Edition (this is installed automatically) Microsoft SQL Server 2008, with Service Pack 1 or later, installed Both 32- and 64-bit versions are supported in stand-alone, clustered and mirrored mode (except for SQL Server 2008 R2 Express, which is supported in stand-alone mode only). 4.3. Separate Component Requirements Updated: 2011-03-11 These topics describe requirements for components that can be installed either on the same server as the controller or individually, such as Citrix Licensing and Desktop Studio. Web Interface can also be installed separately; for information about Web Interface requirements, see the Web Interface documentation. Clients are required only as part of Web Interface installation, to enable Web Interface to deliver these to user devices. Licensing Requirements You must use version 11.6.1 of the license server and console supplied with XenDesktop 5; XenDesktop 5 will not work with older license servers. Before installing Citrix Licensing, see http://support.citrix.com/proddocs/topic/technologies/lic-librarynode-wrapper.html for further details and possible updates to licensing requirements. Desktop Studio Requirements Computers running Desktop Studio must meet the following criteria: One of the following operating systems: Windows XP Professional with Service Pack 3 (32- and 64-bit versions). Windows Vista (32- and 64-bit versions). Windows 7 (32- and 64-bit versions), all editions. Microsoft Windows Server 2008 (32- and 64-bit versions). Microsoft Windows Server 2008 R2. Microsoft .NET Framework, Version 3.5, with Service Pack 1. If you do not have this on your computer, it is installed automatically for you. The XenDesktop installation media also contain this installer in the Support\DotNet35 folder. Microsoft Management Console 3.0 (MMC 3.0) must be installed.

Disk space requirements: 75 MB. Microsoft Windows PowerShell version 2.0. If you do not have this on your computer, it is installed automatically for you.

Desktop Director Requirements You can install Desktop Director on the same server as the XenDesktop Controller or standalone. In either case the system requirements are the same. To install Desktop Director, computers must meet the following criteria: One of the following operating systems: Microsoft Windows Server 2008, Standard or Enterprise Edition, with Service Pack 2 installed (32- and 64-bit) Microsoft Windows Server 2008 R2, Standard or Enterprise Edition (64-bit only) Microsoft .NET Framework, Version 3.5, with Service Pack 1. If you do not have this on your server, it is installed automatically for you. The XenDesktop installation media also contain this installer in the Support\DotNet35 folder. Microsoft Internet Information Services (IIS) and ASP.NET 2.0: For Windows Server 2008, Microsoft IIS Version 7.0. For Windows Server 2008 R2, Microsoft IIS Version 7.5. If you do not have these on your server, you are prompted for the Windows Server installation media, and they are installed for you. Microsoft WinRM 1.1 or above. WinRM 2.0 is installed automatically by the installer as part of Microsoft Windows PowerShell version 2.0 / Windows Management Framework (WinRM 1.1 for Windows 2008 Service Pack 2; WinRM 2.0 for Windows 2008 R2). To view the Web-based Desktop Director, you must use one of the following browsers: On Windows, Microsoft Internet Explorer 7.0 and 8.0, and Mozilla Firefox 3.5. On Macintosh, Apple Safari 4 and Mozilla Firefox 3.5. Adobe Flash Player 9 must be installed to view the graphs.

Microsoft Group Policy Management Console Requirements Microsoft Group Policy Management Console (GPMC) is required only if Citrix policy information is to be stored in Active Directory, and not in the database. For information on the Windows platforms that GPMC is supported on, see your Microsoft documentation. Client Requirements The following clients are supplied with XenDesktop 5: Citrix online plug-in 12.1 Citrix Receiver for Linux 11.100 Citrix online plug-in for Macintosh 11.2 For full XenDesktop 5 functionality, use the Desktop Viewer in the Citrix online plug-in 12.1. Other clients provide differing levels of functionality: see the specific client documentation for details. Note: .NET Framework Requirements. To use the Desktop Viewer, .NET 2.0 Service Pack 1 or later is required. This version is required because, if Internet access is not available, certificate revocation checks slow down connection startup times. The checks can be turned off and startup times improved with this version of the Framework but not with .NET 2.0. The Desktop Viewer Embedded Edition does not require the .NET Framework to be installed.

4.4. Active Directory Requirements Updated: 2010-07-14 Active Directory is required for XenDesktop. For more information about how Active Directory and XenDesktop interact, and about the different Active Directory topologies supported, see Active Directory Considerations. If Citrix policy information is to be stored in Active Directory, and not in the database, the domain controller can be at "Windows 2000 native" functional level or higher. However, to use Policy Modeling, the domain controller must be running on a server whose operating system is W2003 or higher; this does not affect the domain functional level, which can still be "Windows 2000 native" or higher 4.5. Virtual Desktop Agent Requirements Updated: 2010-11-15 Virtual machines must run one of the following: Windows XP 32-bit with Service Pack 3 or later. Windows XP 64-bit with Service Pack 2 or later. If virtual machines are to run Windows XP and you intend using Desktop Director in your deployment, you must install Microsoft WinRM (version 1.1 or above) on the virtual machine before installing the Virtual Desktop Agent. Windows Vista (non-Aero) 32-bit or 64-bit with Service Pack 2 or later. Windows 7 (non-Aero) 32-bit or 64-bit. Support components, such as .NET Framework 3.5 and the Visual C++ 2005 Runtime Library, are installed automatically if they are not already on the desktop. 4.6. Host Requirements Updated: 2011-05-17 XenDesktop enables you to manage virtual desktops supported on the following hosts: Note: If you plan to use Machine Creation Services, see the Requirements for Machine Creation Services for specific requirements for host and storage technologies. Citrix XenServer 5.6 Standard and Enterprise editions. For information on system requirements, see the XenServer Administrator's Guide and the XenServer Installation Guide. Note: You must use Citrix XenServer 5.6 if you intend using Machine Creation Services. Citrix XenServer 5.5 Update 2 Standard and Enterprise editions. Note: Machine Creation Services will not work with this version of XenServer. For information on system requirements, see the XenServer Administrator's Guide and the XenServer Installation Guide. VMware vSphere 4.1 (ESX 4.1 and vCenter 4.1, and ESXi 4.1 and vCenter 4.1). For information on system requirements, see the VMware documentation at http://www.vmware. com/support/pubs/vs_pubs.html/ VMware vSphere 4 Update 1 (ESX 4.0 and vCenter 4.0). For information on system requirements, see the VMware documentation at http://www.vmware.com/support/pubs/vs_pubs.html/ Note: No support is provided for vSphere vCenter 'Linked Mode' operation (see http://www. vmware.com/products/vcenter-server/features.html). Microsoft System Center Virtual Machine Manager 2008 R2; Hyper-V (Windows Server 2008 R2 Enterprise and Standard Edition; Hyper-V Server 2008 R2 Enterprise Edition). For information on

system requirements, see the Microsoft documentation at http://www. microsoft.com/systemcenter/virtualmachinemanager/en/us/default.aspx/

4.7. Requirements for Machine Creation Services Updated: 2011-05-17 Machine Creation Services and run-time Active Directory account injection into VMs is supported on: Citrix XenServer 5.6 Standard and Enterprise editions. Note: Machine Creation Services will not work with earlier versions of XenServer. For information on system requirements, see the XenServer Administrator's Guide and the XenServer Installation Guide. VMware vSphere 4.1 (ESX 4.1 and vCenter 4.1, and ESXi 4.1 and vCenter 4.1) VMware vSphere 4 (with ESX 4.x). Note: No support is provided for vSphere vCenter 'Linked Mode' operation (see http://www. vmware.com/products/vcenter-server/features.html). For information on system requirements, see the VMware documentation at: http://www.vmware.com/support/pubs/vs_pubs.html/

Microsoft System Center Virtual Machine Manager 2008 R2 (with Windows Server 2008 R2 Hyper-V). Host and Storage Technologies The following combinations of host and storage technology are supported: Local Disks NFS XenServer Yes1 ESX Hyper-V Yes4 Yes2 Block Storage Storage Link No No No

Yes (R) Yes Yes (R) Yes No Yes3 (R)

(R) = Recommended protocol. Notes: 1. Virtual Hard Disk (VHD) on Logical Volume Manager (LVM) only; this is the default for XenServer 5.5 and 5.6. VMs created in this deployment will not support XenMotion or dynamic placement. If you have multiple XenServers in a pool just using local disks, Machine Creation Services will fail. Available if there is only a single Hyper-V server in the hosting unit. Microsoft Cluster Shared Volumes are required. No support for vMotion or Dynamic placement.

2. 3. 4.

5. Planning a XenDesktop Deployment Updated: 2011-03-11 XenDesktop allows you to grow your deployment at a 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 site as necessary. The essential elements you need to have in place for a working XenDesktop site are: A server to host: The Controller The License Server. By default, this is installed when you install XenDesktop, but you can choose to use a separate server for licensing. For further information on licensing, see: Licensing.

The database. By default, a database is created locally when you install XenDesktop, but you can choose to use a database on a separate server. Important: If you intend using an external database created manually, not created using Desktop Studio, ensure your database administrator uses the following collation setting when creating the database: Latin1_General_CI_AS_KS (where Latin1_General varies depending on the country; for example Japanese_CI_AS_KS). If this collation setting is not specified during database creation, subsequent creation of the XenDesktop service schemas within the database will fail, and an error similar to "<service>: schema requires a case-insensitive database" appears (where <service> is the name of the service whose schema is being created). For further information on setting up the site database, see To configure a XenDesktop site. Desktop Studio. The console used to configure and manage your XenDesktop deployment. By default, this is installed on servers on which you install the Controller, but you can install it on a separate computer if you want to manage your deployment remotely. Desktop Director. The console for level-1 and level-2 IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. By default, this is installed on servers on which you install the Controller, but you can choose to install it on a separate computer. A domain controller running Active Directory. Active Directory is required for XenDesktop. Do not install either XenDesktop or the SQL Server database on a domain controller. For more information on Active Directory, see Active Directory Considerations. VMs or physical computers hosting the desktops you want to deliver to your users. You install the Virtual Desktop Agent on these machines to manage communications and broker connections. User devices running the appropriate client to enable your users to access desktops. Example Deployments This topic shows examples of typical XenDesktop deployments, from a simple default configuration to a complex one involving multiple sites. Simple Default Configuration Figure 1. A single controller configuration of XenDesktop, typical of an initial deployment

Note that this configuration forms a single point of failure for administration and session brokering. Distributed Components Configuration You can distribute the components of your deployment among a greater number of servers, or provide greater scalability and failover by increasing the number of controllers in your site. You can install the management consoles on separate computers to enable you to manage your deployment remotely. A distributed deployment is also necessary for an infrastructure based on remote access through Access Gateway. Figure 2. A distributed components configuration of XenDesktop

Further components available with XenDesktop to enhance your deployment include: XenServer, which is a host used for scalable and cost-effective hosting of desktops. XenApp to deliver applications to your users either by streaming them to virtual desktops or hosting them on a XenApp server. For information on using XenApp with XenDesktop, see Using XenApp with XenDesktop. Profile management to ensure that your users get a consistent experience every time they log on by managing user personalization settings. For more information, see the Profile management documentation. For more information about Citrix Access Gateway for secure remote access, Edgesight performance monitoring, Branch Repeater for WAN optimization, Workflow Studio and StorageLink, see XenDesktop Features and Editions and the product-specific documentation. Multiple Site Configuration If you have multiple regional sites, for example one in Europe and one in the US, you can use Citrix NetScaler to direct user connections to the most appropriate site and the Web Interface to deliver desktops and applications to users. In the following example, each site is split into two data centers, with the database mirrored or clustered between the data centers to provide a high availability configuration. Having two sites globally, rather than just one, minimizes the amount of unnecessary WAN traffic. A separate Desktop Studio console is required to manage each site; sites cannot be managed as a single entity. Desktop Director can be used to support users across sites. Citrix NetScaler accelerates application performance, load balances servers, increases security, and optimizes the user experience. In the example below, two NetScalers are used to provide a high availability configuration. The NetScalers are configured for Global Server Load Balancing and positioned in the DMZ to provide a multi-site, fault-tolerant solution. Figure 3. A configuration consisting of multiple regional sites and data centers

5.1. High Availability Planning Updated: 2011-01-18 This topic outlines ways in which you can increase the level of fault tolerance in a XenDesktop deployment to ensure that business-critical applications and desktops are always available. It also provides pointers to further information and products. Note: For information about configuring the Virtual Desktop Agent to operate in high availability mode, see High Availability of the Virtual Desktop Agent. Configuring Database Fault Tolerance In XenDesktop, all information is stored on the database; controllers communicate only with the database and not with each other. A controller may be unplugged or turned off without this affecting other controllers in the site. This means, however, that the database forms a single point of failure. If the database server fails, existing connections to virtual desktops will continue to function until the user either logs off or disconnects from their virtual desktop; new connections cannot be established if the database server is unavailable. Citrix recommends that you backup the database regularly so that you can restore from the backup if the database server fails. In addition to this good practice, there are three other high availability solutions to consider for ensuring automatic failover. The benefits and disadvantages of each of these solutions are outlined below: 1. SQL Mirroring. This is the recommended solution. Mirroring the database ensures that, should you lose the active database server, the automatic failover process happens quickly in a matter of seconds, so users are generally unaffected. This method, however, is more expensive than alternative solutions because full SQL server licenses are required on each database server; you cannot use SQL Express. Using the hypervisor's high availability features. With this method, you deploy the database as a virtual machine and use your hypervisor's high availability features. This solution is less expensive

2.

2. than mirroring as it uses your existing host software and you can also use SQL Express. However, the automatic failover process is slower as it can take time for a new machine to start for the database, which may interrupt the service to users. 3. SQL Clustering. Microsoft's SQL clustering technology can be used to automatically allow one server to take over the tasks and responsibilities of another server that has failed. However, setting up this solution is more complicated, and the automatic failover process typically slower than with alternatives such as SQL Mirroring.

Note: If you want to mirror the XenDesktop database, ensure that the database uses the full recovery model and not the simple model. When Desktop Studio is used to create a database on an external SQL server, the database is configured to use the simple model by default; this means the transaction log cannot be backed up and the database cannot be mirrored. To ensure the database is configured to use the full recovery model, create the database manually and then use Desktop Studio to generate the necessary setup scripts to be run on the database. For more information about configuring XenDesktop for use with a mirrored database, see http://support.citrix.com/article/ctx127359. For more information about reconfiguring an existing XenDesktop site to use a mirrored database, see http://support. citrix.com/article/ctx127538. Configuring Site Failover You can specify XenDesktop sites for emergency use when users cannot access their production sites; for example, due to a power failure or network outage. This allows you to make provisions to deal with loss of access to production servers, and to ensure critical applications and desktops are always available. To specify alternate XenDesktop sites, you use the Web Interface to direct users to a list of recovery sites when none of their normal sites can be reached. To do this, configure the Web Interface RecoveryFarm setting with a list of alternate sites. Should no primary sites be available, the sites in the RecoveryFarm list are tried one after another until a working site is found. For more information about configuring the RecoveryFarm setting, see the Web Interface documentation. To further increase the level of fault tolerance, Citrix recommends you use the intelligent load balancing features of NetScaler. In addition to providing users with a single access point, NetScaler can validate that Web Interface and XML services are functioning properly before directing user requests to Web Interface servers. This prevents users from being directed to servers with inactive services and ensures failover occurs promptly when there is a disruption. Fault tolerance can be increased yet further by using the Global Server Load Balancing (GSLB) features of NetScaler. With GSLB in front of Web Interface, you can route users to an alternative site that is still running and reachable. For more information, see the NetScaler Administration Guide and the NetScaler High Availability and GSLB knowledge base articles available on the Citrix Web site. To ensure users always access their own virtual desktops and data, regardless of where they connect from, you can use the site roaming feature of Web Interface. For example, if you have users who travel between Europe and the US, or connect from home using laptops, you can ensure that they always connect to their own virtual desktops and user data from different sites. To enable site roaming support, you configure the Web Interface, using the Farm<n>Groups parameter, to direct users to the appropriate data center for their virtual desktops. For more information, see the topic about configuring XenDesktop user roaming in your Web Interface documentation. Example The following example shows a high availability configuration consisting of a primary site and a disasterrecovery site. Each site is split into two data centers, with the database mirrored to provide a faulttolerant configuration. In the event of an outage in the primary site, NetScalers configured for Global Server Load Balancing, positioned in the DMZ in front of the Web Interface, load balance and route user connections to the disaster-recovery site. NetScalers are also positioned between the Web Interface and the XenDesktop sites to determine if a site is working properly. Figure 1. High Availability Configuration

5.2. Active Directory Considerations Updated: 2010-09-08 Active Directory is required in a XenDesktop deployment for authentication and authorization. Active Directory can also be used for controller discovery, if you decide not to use the default registry-based discovery mechanism. This topic explains how XenDesktop uses Active Directory, how to employ Active Directory-based discovery, and it outlines the Active Directory environments that are supported. XenDesktop uses the services provided by Active Directory for two main purposes: Security. Active Directory's inbuilt security infrastructure is used by desktops to verify that communications from controllers come from authorized controllers in the appropriate site. Active Directory's security infrastructure also ensures that the data exchanged by desktops and controllers is confidential. XenDesktop uses Active Directory's inbuilt Kerberos infrastructure to guarantee the authenticity and confidentiality of communication. For more information about Kerberos, refer to Microsoft's product documentation. Discovery. Active Directory is optionally used by desktops to discover the controllers that constitute a site. This means you can add a new controller to a site without having to reconfigure all desktops in the site. Instead, desktops determine which controllers are available by referring to information that controllers publish in Active Directory. This feature is available only if the desktops are in the same Active Directory forest as the controllers.

Note: By default, controller discovery is registry-based, and XenDesktop requires no objects to be created in Active Directory. For more information about the registry entries used by registry-based discovery, see: http://support.citrix.com/article/ctx118976. Active Directory-based Controller Discovery During installation of the Virtual Desktop Agent, you can choose to use Active Directory-based discovery rather than the default registry-based discovery. Active Directory-based discovery requires that all computers in a site are members of a domain, with mutual trusting relationships between the domain used by controller

and the domain(s) used by desktops. Note: If your organizational structure means that you need a deployment where the controllers are in a separate Active Directory forest from the desktops for your users, see http://support. citrix.com/article/ctx122417 for details of how to configure a supported solution. When you create a site, a corresponding Organizational Unit (OU) must be created in Active Directory if you want desktops to discover the controllers in the site through 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 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. The domain administrator can then delegate administrative authority over the OU to a XenDesktop administrator. If the XenDesktop administrator has CreateChild permissions on a parent OU, this administrator can create and populate the site OU by running a PowerShell script, called 'Set-ADControllerDiscovery.ps1'. You can use the standard Active Directory Users and Computers MMC snap-in to configure these permissions. Also, to run Set-ADControllerDiscovery.ps1, the administrator must have full administration rights on XenDesktop. A small number of objects that are essential for the operation of the farm are created in the OU. Note: Only standard Active Directory objects are created and used by XenDesktop. It is not necessary to extend the schema. The set of objects created includes: A Controllers security group. The computer account of all controllers in the site must be a member of this security group. Desktops in a site accept data from controllers only if they are members of this security group. Ensure that all controllers have the 'Access this computer from the network' privilege on all virtual desktops running the Virtual Desktop Agent. You can do this by giving the Controllers security group this privilege. If controllers do not have this privilege, virtual desktops will fail to register. A Service Connection Point (SCP) object that contains information about the site, such as the site's name. Note: If you use the Active Directory Users and Computers administrative tool to inspect a site OU, you may have to enable Advanced Features in the View menu to see SCP objects. A container called RegistrationServices, which is created within the site's OU. This contains one SCP object for each controller in the site. The SCP is created when the Set-ADControllerDiscovery. ps1 script is run. Each time the controller starts, it validates the contents of its SCP and updates them if necessary. If multiple administrators are likely to add and remove controllers after the initial installation is complete, they need permissions to create and delete children on the RegistrationServices container and Write properties on the Controllers security group (these permissions are granted automatically to the administrator who creates or populates the OU by running the Set-ADControllerDiscovery.ps1 script). Either the domain administrator or the original installing administrator can grant these permissions, and Citrix recommends setting up a security group to do this. The following points are important to bear in mind when you are using a site OU with XenDesktop: Information is written to Active Directory only when installing or uninstalling XenDesktop, or when a controller starts and needs to update the information in its SCP (for example, because the controller was renamed or because the communication port was changed). By default, the SetADControllerDiscovery.ps1 script sets up permissions on the objects in the site's OU appropriately, giving controllers Write access to their SCP. The contents of the objects in the site OU are used to establish trust between desktops and controllers. You should ensure that: Only authorized administrators can add or remove computers from the Controllers security group, using the security group's access control list (ACL) Only authorized administrators and the respective controller can change the information in the controller's SCP Depending on your Active Directory infrastructure, you should be aware of replication and its impact on

a XenDesktop implementation. Refer to Microsoft's documentation to understand the concepts of replication and associated delays. This is particularly important if you create the site's OU in a domain that has domain controllers located in multiple Active Directory sites. Depending on the location of desktops, controllers, and domain controllers, changes that are made to Active Directory when you are initially creating the OU for the site, installing or uninstalling controllers, or changing controller names or communication ports may not be visible to desktops until that information is replicated to the appropriate domain controller. The symptoms of such replication delay include desktops that cannot establish contact with controllers and are, therefore, not available for user connections. XenDesktop uses some of the standard computer object attributes in Active Directory to manage desktops. Depending on your setup, the machine object's fully qualified domain name, as stored in the desktop's Active Directory record, can be included as part of the connection settings that are returned to the user to make a connection. It is, therefore, important to ensure that this information is consistent with information held in your DNS environment. Supported Active Directory Environments XenDesktop supports deployments in which the user accounts and computer accounts exist in domains in a single Active Directory forest. User and computer accounts can exist in arbitrary domains within a single forest. All domain functional levels and forest functional levels are supported in this type of deployment. XenDesktop also supports deployments in which user accounts exist in an Active Directory forest that is different from the Active Directory forest containing the computer accounts of the controllers and virtual desktops. In this type of deployment, the domain(s) containing the controller and virtual desktop computer accounts must trust the domain(s) containing user accounts. Forest trusts or external trusts can be used. All domain functional levels and forest functional levels are supported in this type of deployment. Additionally, XenDesktop supports deployments in which the computer accounts for controllers exist in an Active Directory forest that is different from one or more additional Active Directory forests that contain the computer accounts of the virtual desktops. In this type of deployment a bi-directional trust must exist between the domain(s) containing the controller computer accounts and all domain(s) containing the virtual desktop computer accounts. In this type of deployment, all domains containing controller or virtual desktop computer accounts must be at "Windows 2000 native" functional level or higher. All forest functional levels are supported. For more information about enabling this type of deployment, see http://support.citrix.com/article/ctx122417. 5.3. Web Interface Considerations Updated: 2010-10-15 Citrix Web Interface is installed by default on all servers on which you install the controller, together with three Web sites. This topic provides details about the additional options you have in relation to the Web Interface and the default Web sites. The default sites are typically created in the following locations when the Web Interface is installed: The desktop appliance site, for XenDesktop-ready thin clients, is: \Inetpub\wwwroot\Citrix\DesktopAppliance The XenDesktop Services site, for full-screen-only use with domain-joined Windows XP and XPe appliances, is: \Inetpub\wwwroot\Citrix\PNAgent The XenDesktop Web site, for window view mode users who need to be able to access multiple desktops or to access desktops from a browser, is: \Inetpub\wwwroot\Citrix\DesktopWeb This is the default site that users are presented with if they browse just to the controller address. To modify the desktop appliance site, you must edit the configuration files as described in the Web Interface documentation. The other default sites are standard Web Interface sites and you can modify them through the Web Interface Management Console. For remote access through Access Gateway, you need to create a new Web Interface site. For information about creating sites, and details of how to modify the site's user interface to refer to desktops rather than applications, see the Web Interface documentation.

5.4. Delegated Administration Updated: 2010-11-04 This topic describes the different XenDesktop administration roles and responsibilities. Citrix administrators are not set up automatically during XenDesktop installation. After installation, only local administrators on the server running the Controller have full administrative privileges, with authority to manage and administer all areas of the XenDesktop site. Only an administrator with full rights can create additional full or delegated administrators. Note: Local administrators on the Controller always have full administrative privileges; these privileges always take precedence, regardless of delegated privileges that may later be explicitly assigned by Citrix administrators. However, Citrix recommends that for normal operation, you create Citrix administrators with the appropriate rights, rather than use the Local administrators account. Granting local administrators on the Controller full rights allows these administrators to configure the XenDesktop deployment and prevents a deployment from unintentionally being rendered unmanageable should all explicit administrators be removed. XenDesktop Administration Roles There are five types of XenDesktop administrator: Full administrator. This administrator has full administration rights with authority to manage and administer the entire XenDesktop site. Full administrators can perform any of the roles listed below, such as that of the machine or assignment administrator. Following XenDesktop installation, only local administrators on the server running the Controller have this role and can create further full or delegated administrators. Note that, to configure hosts, you must be a full administrator. Read-only administrator. This administrator can see all aspects of the XenDesktop site but has no authority to change any settings; any attempted edits will not be saved. Machine administrator. This administrator owns the catalogs and is responsible for building the virtual desktops. The machine administrator can specify which assignment administrators can consume the images created. This administrator can also see other aspects of the XenDesktop site. Assignment administrator. This administrator takes the virtual desktops created by the machine administrator, wraps these in one or more desktop groups and assigns them to users. The assignment administrator can specify which help desk administrators are permitted to support these users; for example, based on geographical roles. This administrator can also see other aspects of the XenDesktop site. Help desk administrator. This administrator performs day-to-day monitoring and maintenance tasks, such as restarting a desktop or logging off a session.

Note: For more information about displaying administration rights and creating additional administrators, see Delegating Administration Tasks. 5.5. Security Planning for XenDesktop Updated: 2010-09-08 This 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-todate information on security standards and Citrix products, consult http://www.citrix.com/security/, or contact your Citrix representative. Security Best Practices

Keep all computers in your environment up to date with security patches. One advantage of XenDesktop is that you can use thin clients as terminals, which simplifies this task. Protect all computers in your environment with antivirus software. Protect all computers in your environment with perimeter firewalls, including at 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 virtual desktop and user device are on one side of it, and the database servers and 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. You should also consider having protection between the user device and the virtual desktop. 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. 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 user devices and desktops is secured through Citrix SecureICA, which is configured by default to 128bit encryption. You can configure SecureICA when you are creating or updating an assignment; see To secure desktop groups. Managing User Privileges You should grant users only the capabilities they require. Microsoft Windows privileges continue to be applied to desktops in the usual way: configure privileges through User Rights Assignment and group memberships through Group Policy. One advantage of XenDesktop is that it is possible to grant a user administrative rights to a desktop without also granting physical control over the computer on which the desktop is stored. When planning for desktop privileges, note: By default, when non-privileged users connect to a desktop, they see the time zone of the system running the desktop instead of the time zone of their own user device. For information on how to allow users to see their local time when using desktops, see Configuring Time Zone Settings A user who is an administrator on a desktop has full control over that desktop. If a desktop is a pooled desktop rather than a dedicated desktop, the user must be trusted in respect of all other users of that desktop, including future users. All users of the desktop need to be aware of the potential permanent risk to their data security posed by this situation. This consideration does not apply to dedicated desktops, which have only a single user; that user should not be an administrator on any other desktop. Note: For information about how to use standard Windows procedures to grant users administrative privileges only over the desktop to which they are connected, see http://support. citrix.com/article/ctx116942/. A user who is an administrator on a desktop can generally install software on that desktop, including potentially malicious software. The user can also potentially monitor or control traffic on any network connected to the desktop.

Deployment Scenario Security Implications Your user environment can consist either of user devices that are unmanaged by your organization and completely under the control of the user, or of user devices that are managed and administered by your organization. The security considerations for these two environments are generally different. Managed User Devices Managed user 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 user devices directly to users; alternatively, you may provide terminals on which a single desktop runs in full-screen-only mode (XenDesktop-ready thin clients). You should follow the general security best practices described above for all managed user devices. XenDesktop has the advantage that minimal software is required on a user device. A managed user device can be set up to be used in full-screen-only mode or in window mode: If a user device is configured to be used in full-screen-only mode, users log on to it with the usual Log On To Windows screen. The same user credentials are then used to log on automatically to XenDesktop. If a user device is configured so that users see their desktop in a window, users first log on to the user device, then log on to XenDesktop through the XenDesktop Web site supplied with XenDesktop. Unmanaged User Devices User devices that are not managed and administered by a trusted organization cannot be assumed to be under administrative control. For example, you might permit users to obtain and configure their own devices, but users might not follow the general security best practices described above. XenDesktop has the advantage that it is possible to deliver desktops securely to unmanaged user devices. These devices should still have basic antivirus protection that will defeat keylogger and similar input attacks. Data Storage Considerations When using XenDesktop, you can prevent users from storing data on user devices that are under their physical control. However, you must still consider the implications of users storing data on desktops. It is not good practice for users to store data on desktops; data should be held on file servers, database servers, or other repositories where it can be appropriately protected. Your desktop environment may consist of various types of desktops, such as pooled and dedicated desktops: Users should never store data on desktops that are shared amongst users, such as pooled desktops. If users store data on dedicated desktops, that data should be removed if the desktop is later made available to other users.

5.6. User Access and Experience Updated: 2010-10-15 This topic outlines the user experience, depending on how users access their virtual desktops, such as the logon page displayed, whether sessions appear in full screen or window mode, and whether a toolbar is available or not. Understanding the implications of user access helps you determine how accessible the local operating system is to users. For example, you may wish to restrict some users to virtual desktops only, while allowing others access to their local operating system as well as their virtual desktops. The main user access scenarios supported for XenDesktop are: Using a non-domain-joined thin client to access a single virtual desktop (Scenario A in the tables below) Using a domain-joined thin client or repurposed computer to access a single virtual desktop (Scenario B in the tables below) Using a client computer to access multiple virtual desktops (Scenario C in the tables below) The following table shows the requirements for each scenario: Scenario A User device OS Windows Browser required Web Interface site Yes Desktop Appliance Client Desktop Client install Preinstalled

XP, Windows XP Embedded Linux B Windows XP, Windows XP Embedded Windows 7, Windows Vista, Windows XP Windows CE Macintosh OS X No

Appliance Lock in Citrix online plug-in 12.1 Citrix Receiver for Linux 11.100

by administrator

XenDesktop Services See manufacturer's documentation for the relevant t Preinstalled by administrator XenDesktop Web Desktop Viewer in Citrix online plug-in 12.1 Client for Windows CE 10.x Citrix online plug-in for Macintosh 11.2 Preinstalled by administrator or through auto client detection or user prompt

Yes

The table below summarizes the user experience for each scenario: Scenario A Logon XenDesktop logon page followed by automatic launch of virtual desktop 2 Windows OS logon page followed by automatic launch of virtual desktop 2 After users click on the URL that provides access to XenDesktop: On first use: If the Citrix online plug-in is installed, the XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available; If the Citrix online plug-in is not installed, the user is prompted to download and install the plug-in. The XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available. On subsequent use: The XenDesktop logon page appears followed either by a list of available virtual desktops or automatic launch if only one is available. Virtual desktop display Full screen virtual desktop. No user device OS access. Toolbar[1] No

Full screen virtual desktop. No user device OS access.

No

On first use: the virtual desktop appears in window mode. On subsequent use: the virtual desktop appears in either window or full-screen mode, depending on the display mode of the user's last virtual desktop session. User device OS access available.

Yes3

[1]

A toolbar is available that allows users to switch between different virtual desktops and to customize desktops.

[2] [3]

The first time users connect, a Welcome screen appears followed by the XenDesktop logon page.

You can disable the toolbar using the Web Interface.conf parameter "ShowDesktop Viewer"; for more information, see the Web Interface documentation. If window size must be constrained to a fixed size, disabling the toolbar allows Web Interface settings to take effect. For a list of the clients supplied on the XenDesktop 5 installation media, see Client Requirements. For full XenDesktop 5 functionality, use the Desktop Viewer in the Citrix online plug-in 12.1. Other clients provide differing levels of functionality: see the specific client documentation for details. Citrix also recommends that you regularly check http://www.citrix.com/English/ss/downloads/for new versions of the clients, which may offer further enhancements. 5.7. High Availability of the Virtual Desktop Agent Updated: 2010-11-30 If all controllers in a XenDesktop site fail, you can configure the Virtual Desktop Agent to operate in high availability mode so that users can continue to access and use their desktops. In high availability mode, the Virtual Desktop Agent will accept direct ICA connections from users, rather than connections brokered by the controller. Note: This feature is for use only on the rare occasion that communication with all controllers fails; it is not an alternative to other high availability solutions, such as configuring database fault tolerance and site failover. Before using this feature, refer to the list of limitations below as these have security implications. If communication with the controller fails, high availability mode is initiated only after a set period of time has elapsed. By default, this is 300 seconds (5 minutes) but you can configure the time period. Once in high availability mode, the Virtual Desktop Agent will attempt to register with a controller for up to 30 days, while the user continues to use the desktop in this mode. When the controller later becomes available, the desktop registers and the user's session continues uninterrupted, but any subsequent connection will be brokered by the controller as normal. If after 30 days the desktop is unable to register with the controller, the desktop will stop listening for connections and shutdown. This means the administrator has 30 days in which to repair the controller infrastructure and should not become reliant upon high availability mode. High availability mode is suitable only for use with dedicated desktops, where the mapping between the user and the Virtual Desktop Agent is known. You cannot configure high availability mode for use with pooled desktops. To enable high availability mode, you: 1. 2. Set theHighAvailability and HaRegistrarTimeout registry keys Provide users with an ICA launch file that will enable them to make direct ICA connections. You have to create an ICA file for each user who requires this feature; Citrix do not create or distribute ICA files for this purpose.

Setting the Registry Keys To configure the Virtual Desktop Agent so that it will operate in high availability mode when necessary, add the following registry key(s). You must do this after the Virtual Desktop Agent has been installed. Caution: 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. 1. In HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ VirtualDesktopAgent, add the following registry entry (of type REG_DWORD): HighAvailability. Set this to 1 to enable high availability mode; 0 (zero) disables high availability mode. 2. To change the time period that the Virtual Desktop Agent will try registering with the controller before initiating high availability mode, also add the following registry entry (of type REG_DWORD): HaRegistrarTimeout. Specify the number of seconds. The default is 300 seconds. 3. Restart the virtual desktop.

Preparing an ICA Launch File To establish a direct ICA connection to desktops, you provide users with an ICA launch file that they can use should communication with the controller fail. You must create an ICA launch file for each user who requires this feature; Citrix do not create or distribute ICA files for this purpose. For information on how to create ICA files, see http://support.citrix.com/article/CTX127392. You will need to tell users when it is appropriate to use this ICA launch file and where they can access it from. High Availability Mode Limitations High availability mode is suitable only for use with dedicated desktops; you cannot configure this for use with pooled desktops. In high availability mode, some features are unavailable. These include: User roaming. If a client device is already connected to the desktop, users will be unable to connect from a different client device. Power management. When the desktop powers up, it attempts to register, fails and, after the timeout, enters high availability mode. Controller-originated policies. Policies originating on the controller, such as those governing client drive mapping and access to the clipboard, will not function as there is no connection to the controller. Policies originating from the Domain Controller and Local Group Policy are unaffected. Access Gateway and Remote Access High availability mode persists for up to 30 days only, after which the desktop is no longer available. 6. Quick Deploy Updated: 2010-12-07 XenDesktop 5 Quick Deploy is the fastest way to deploy a fully functional XenDesktop installation. You specify a master VM and select some users, then Quick Deploy creates virtual desktops, makes them available for the users, and shows you how to access your desktops. To achieve this in the minimum number of steps, Quick Deploy has some prerequisites and makes a number of assumptions. This topic describes what Quick Deploy does, the prerequisites for running Quick Deploy, and the assumptions that Quick Deploy makes. Prerequisites To run Quick Deploy you need: A host with sufficient processors, memory, and storage to accommodate the number of machines for the desktops you plan to create. Access to an administrator account with permissions to create new machines on the host. A master VM running the Virtual Desktop Agent from which to create the desktops. The master VM must be available on the host where the machines will be created. Access to an Active Directory domain containing accounts for the desktop users. Access to a domain administrator account with permissions to create new Active Directory computer accounts for the machines. If you intend to create computer accounts in a different domain to that containing the user accounts, a trust relationship must be established between the two domains. A single-server installation of all the XenDesktop server-side components, including the controller, Desktop Studio, the Web Interface, the Citrix License Server, and Microsoft SQL Server 2008 R2.

Running Quick Deploy Quick Deploy is only available when the XenDesktop components have been installed, but not yet configured. After installing the XenDesktop components, ensure that you are logged on using an account with permissions to create machine accounts in Active Directory. If Desktop Studio is not already open following the installation, start Desktop Studio and run Quick Deploy, which includes the following steps. 1. Site. Specify a name for your XenDesktop deployment. Consider naming your site according to

1. the geographic location of the data center. 2. 3. 4. 5. 6. Host. Establish a connection to the hypervisor cluster or resource pool that will host the machines created by Quick Deploy. Resources. Specify the hypervisor storage and virtual network to be used for the machines. Master Image. Specify the virtual machine or snapshot from which you want Quick Deploy to create the desktops. Number of VMs. Specify the number of desktops that you want to create and a location for the Active Directory computer accounts. Users. Select the Active Directory users or user groups to whom you want to assign the desktops.

For more information about using Quick Deploy to set up a XenDesktop environment for evaluation purposes, see Installing and Configuring the Evaluation Deployment. Assumptions To streamline the deployment process, Quick Deploy automatically configures:

Licensing. In the absence of a valid XenDesktop license, Quick Deploy desktops are available for 30 days and usage is limited to a maximum of 10 desktops at any one time. To continue using Quick Deploy desktops after the 30 day grace period has expired or to use more that 10 desktops simultaneously, install a valid XenDesktop license on the Citrix License Server running on the server hosting the XenDesktop components. By default, Quick Deploy sets the product edition in Desktop Studio to Platinum Edition. If you install a license for a different edition, reset the product edition in Desktop Studio by selecting the Configuration node in the left pane and, in the Actions pane, clicking Edit licensing.

Virtual machines. Although XenDesktop 5 supports a number of different machine types, Quick Deploy creates pooled-random machines only. Quick Deploy machines are automatically named according to the scheme sitename**#. Here, sitename is the name you specified for your deployment on the Site page, ** is two random letters, and # is a number that increases incrementally from 1 to n, where n is the number of desktops to be created. Leading zeros are added where necessary to ensure that all machine names contain the same number of digits. Active Directory computer accounts. Quick Deploy automatically creates Active Directory computer accounts in the organizational unit you specified on the Number of VMs page. The account names are the same as the names of the machines to which they relate. Machine catalog. In XenDesktop, collections of machines are managed as a single entity called a catalog . Quick Deploy automatically creates a catalog named QD Catalog. User assignment. In XenDesktop, user assignment to machines is managed using desktop groups. Quick Deploy automatically creates a desktop group named QD Desktop Group. By default, Quick Deploy limits user access to one desktop at a time.

7. Evaluating XenDesktop 5 Updated: 2011-05-17 These topics help you quickly to set up a basic XenDesktop deployment for evaluation purposes. With the experience gained in this deployment, you can extend your installation over multiple domains and add the additional components not included in the evaluation environment. Experience of basic Windows Server administration, familiarity with one or more of the supported hypervisors, and knowledge of Active Directory is assumed. For simplicity, all the hardware is installed in a single domain and all the server-side components of XenDesktop are installed on a single virtual machine (VM). Citrix strongly recommends that you isolate the evaluation deployment from your production environment. The figure shows the XenDesktop evaluation environment. Physical computers are denoted by the prefix 'p' and VMs by the prefix 'v'.

To simplify the evaluation deployment, this scenario specifies an isolated LAN environment with an IP addressing scheme based on the following assumptions. A simple Ethernet switch is used to connect the hardware The physical machines and the VMs hosting the infrastructure components have manually assigned IP addresses The VMs providing the user desktops have IP addresses assigned by DHCP The XenDesktop evaluation environment includes the following components. Controller. Installed on servers in the data center, the controller consists of services that authenticate users, manage the assembly of users' virtual desktop environments, and broker connections between users and their desktops. It controls the state of the desktops, starting and stopping them based on demand and administrative configuration. For the evaluation environment, the following tools and components are installed locally with the controller. Desktop Studio. Management tool that snaps into the Microsoft Management Console (MMC) and enables you to configure and manage your XenDesktop deployment. Desktop Director. Web-based tool designed to enable IT Support staff to monitor a XenDesktop deployment and perform day-to-day maintenance tasks. XenDesktop database. Microsoft SQL Server database used to store both configuration and session information. Web Access. Provides users with access to their desktops. Citrix License Server. Validates XenDesktop licenses for the controller.

For production deployments, you can install these components on separate computers and deploy multiple instances of the components to support large numbers of desktops. Virtual Desktop Agent. Installed on virtual desktops, the Virtual Desktop Agent enables direct ICA (Independent Computing Architecture) connections between the virtual desktop and user devices. Citrix client. Installed on user devices, Citrix clients enable users to access virtual desktops and applications. Citrix HDX technologies. A broad set of technologies designed to enable a high definition user experience for virtual desktops and applications over any network, regardless of the capabilities of the user device. The evaluation environment requires the following infrastructure. Physical computers are denoted by the prefix 'p' and VMs by the prefix 'v'. pHost. A physical server virtualized with one of the following supported hypervisors. Citrix XenServer 5.6 Standard and Enterprise editions Windows Server 2008 R2 Hyper-V VMware vSphere 4.1 (ESX 4.1/ESXi 4.1 and vCenter 4.1) VMware vSphere 4 Update 1 (ESX 4.0 and vCenter 4.0) For a XenDesktop evaluation deployment, Citrix recommends the following server specification. CPUs Intel VT or AMD-V processors with hardware virtualization enabled in the BIOS. 1.5 GHz minimum clock speed; 2.0 GHz or faster multicore processors recommended. Memory Storage Minimum 3 GB RAM; 12 GB recommended. Minimum 150 GB locally attached storage; 1 TB recommended. Note: The above values are based on Logical Volume Manager (LVM) storage. For the most efficient use of local storage, Citrix recommends using a file-based repository with VHD format support.

Network interface card 100 Mbps (megabits per second) or faster.

The VMs hosted on pHost provide the infrastructure components, the master VM, and the user desktops. For Hyper-V environments only, this server also functions as the domain controller (Native or Mixed mode with Active Directory, DNS, and DHCP.) vSCVMM. For Hyper-V environments only, VM hosting System Center Virtual Machine Manager 2008 R2. vDmC. For XenServer and VMware environments only, VM hosting the domain controller in Native or Mixed mode with Active Directory, DNS, and DHCP. vController. VM hosting the controller, Desktop Studio, Desktop Director, the XenDesktop database, Web Access, and the Citrix License Management Console. vMaster. VM to be used as the template for the user desktops. vDesktopX. VMs providing user desktops. pCenter. For XenServer and VMware environments only, physical computer running the appropriate hypervisor management tools to enable you to manage the VMs on pHost. pUser. A Windows, Mac OS X, or Linux computer running the appropriate Citrix client for the operating system.

7.1. Installing and Configuring the Evaluation Deployment

Updated: 2011-05-17 The following tasks guide you through the process of setting up a XenDesktop evaluation environment and using it to deliver virtual desktops. Citrix strongly recommends that you isolate the evaluation deployment from your production environment. To configure the virtual machine infrastructure Set up an isolated LAN environment for the physical server pHost and use a simple Ethernet switch to connect the hardware. 1. Install one of the following supported hypervisors on pHost. Citrix XenServer 5.6 Standard and Enterprise editions Windows Server 2008 R2 Hyper-V VMware vSphere 4.1 (ESX 4.1/ESXi 4.1) VMware vSphere 4 Update 1 (ESX 4.0) 2. For XenServer environments, install XenCenter on the physical machine pCenter. In VMware environments, install vCenter Server and the appropriate management tools on pCenter. Note: XenDesktop does not support VMware vCenter Linked Mode. For Hyper-V environments, create a VM on pHost named vSCVMM, install Windows Server 2008 R2 on vSCVMM, and then install System Center Virtual Machine Manager 2008 R2. 3. For Hyper-V environments only, create on pHost a Windows network share that is writeable by the System Center Virtual Machine Manager administrator account. This share is required to allow XenDesktop remote access to the storage on pHost. 4. In the evaluation environment, Citrix recommends configuring static IP addresses for pHost and pCenter/vSCVMM.

To configure Active Directory for the evaluation environment Active Directory is required in XenDesktop deployments to verify the identities of components and to allow them to communicate securely. Optionally, Active Directory can also be used by virtual desktops for controller discovery, but the desktops in the evaluation environment use registry-based discovery, which is enabled by default. 1. For XenServer and VMware environments only, use the management tool for your hypervisor to create on pHost a VM named vDmC running a Windows Server operating system. You configure vDmC as the domain controller for the evaluation environment. Citrix recommends configuring a static IP address for vDmC in the evaluation environment. For Hyper-V environments, configure pHost as the domain controller. 2. Configure Active Directory on the domain controller using the following guidelines. 1. Create an Active Directory domain for the evaluation environment with a single domain controller. XenDesktop supports both Native mode and Mixed mode. 2. 3. Configure Active Directory to include a DNS server, which must be configured to have both forward and reverse look-up zones. Specify a DHCP scope with an address range that excludes the static IP addresses used for the infrastructure components. This enables DHCP to dynamically assign IP addresses to the virtual desktops while protecting the static IP addresses of the infrastructure components.

3.

For Hyper-V environments, add vSCVMM to the domain. For XenServer and VMware environments, optionally add pCenter to the domain.

To create the master VM The master VM is used to create virtual desktops and contains those elements that are common to all

your desktops, such as antivirus software and other default programs. 1. Using the management tool for your hypervisor, create a VM on pHost named vMaster. Provided they are sufficient to allow the VM to run, the number of vCPUs and the amount of memory you assign to vMaster are not critical at this stage because you can change these settings when you provision the desktops. However, you should ensure that you set up vMaster with the same amount of hard disk space that is required for users' desktops because this value cannot be changed subsequently. For Windows 7 and Windows Vista desktops, Citrix recommends a hard disk size of at least 16 GB. For Windows XP, at least 8 GB is recommended. Ensure that the hard disk for vMaster is attached at device location 0. Most standard VM templates configure this location by default, but some custom templates may not do so. For Hyper-V environments, do not start the VM after it is created. Instead, use Hyper-V Manager to remove the current network adapter and add a suitable network interface card as a legacy network adapter before starting the VM. 2. Install on vMaster one of the following supported operating systems (including all service packs and updates). Windows 7 64-bit Editions (non-Aero) Windows 7 32-bit Editions (non-Aero) Windows Vista 64-bit Editions with Service Pack 2 (non-Aero) Windows Vista 32-bit Editions with Service Pack 2 (non-Aero) Windows XP Professional x64 Edition with Service Pack 2 Windows XP Professional with Service Pack 3 3. Install on vMaster the appropriate integration tools for your hypervisor (XenServer Tools, HyperV Integration Services, or VMware Tools). Note: If you do not install hypervisor integration tools on the master VM, your desktops may not function correctly. On Windows XP VMs, install the Microsoft Windows Management Core, which is available from http://support.microsoft.com/?kbid=968930. This package includes Windows Remote Management 2.0, which is required to support Desktop Director. Windows Remote Management 2.0 is included by default with Windows 7 and Windows Vista. 4. Join vMaster to the evaluation environment domain that you set up in the previous task and configure a dynamic IP address so that the master VM (and therefore the desktops you will provision) receives its IP address from the DHCP server on the domain controller. Insert the XenDesktop installation media into the optical drive on pHost or mount the ISO on vMaster. If autorun is not enabled, navigate to and run AutoSelect.exe on the installation media. Before starting the installer, XenDesktop installs Microsoft .NET Framework 3.5 with Service Pack 1 if it is not already present on vMaster. 6. 7. In the XenDesktop installation wizard, click Install Virtual Desktop Agent and then click Quick Deploy. On the Summary page, click Install. Before the Virtual Desktop Agent is installed, the following prerequisites are installed if they are not already present on vMaster. Microsoft Visual C++ 2008 with Service Pack 1 Redistributable Package Microsoft Visual C++ 2005 with Service Pack 1 Redistributable Package Additionally, Citrix plug-ins are automatically installed on vMaster so that users can access XenApp virtualized applications from their desktops. 8. If you are using a firewall other than Windows Firewall on vController, manually enable ports 80, 1494, 2598, and 3389 to allow XenDesktop to function correctly. If Windows Firewall is running on vMaster, XenDesktop opens the ports automatically. When the installation is complete, ensure that the Restart machine (required to complete install)

5.

check box is selected and click Close. 9. 10. After restarting vMaster, install any third-party applications that you want to run on users' desktops, such as antivirus software. Shut down vMaster. Citrix recommends that you create a snapshot of vMaster and name the snapshot in a way that allows you to identify vMaster in the future. If you specify the VM rather than a snapshot when creating your desktops, Desktop Studio will create a snapshot for you but you will not be able to name it. The XenDesktop database retains a historical record of the master VMs used with each catalog. Provided you do not delete, move, or rename the old master VMs, this enables you quickly to revert a catalog to use a previous version of the master VM.

To install the XenDesktop infrastructure components In the evaluation environment, Citrix recommends installing all the server-side components of XenDesktop on a single VM. For production deployments, you can install these components on separate computers and deploy multiple instances of the components to support large numbers of virtual desktops. 1. Using the management tool for your hypervisor, create a VM on pHost named vController. Citrix recommends that you set up vController with at least 1 GB of memory and a hard disk size of at least 16 GB. 2. Install on vController one of the following supported operating systems (including all service packs and updates). Windows Server 2008 R2 Windows Server 2008 x64 Editions with Service Pack 2 Windows Server 2008 with Service Pack 2 3. Join vController to the evaluation environment domain. In the evaluation environment, Citrix recommends configuring a static IP address for vController. 4. On vController, install Adobe Flash Player, which is available from http://get.adobe.com/flashplayer/. Additionally, for Hyper-V environments only, install the Virtual Machine Manager Administrator Console on vController. Verify that the console can connect to System Center Virtual Machine Manager on vSCVMM. 5. Ensure that you are logged on to vController using an account with local administrator permissions or have the credentials for such an account available. Insert the XenDesktop installation media into the optical drive on pHost or mount the ISO on vMaster. If autorun is not enabled, navigate to and run AutoSelect.exe on the installation media. In the XenDesktop installation wizard, click Install XenDesktop. Read and accept the license agreement, and click Next. On the Select Components to Install page, ensure that all the components are selected for installation, including SQL Server Express, and click Next. If Windows Firewall is running on vController, ensure that the Enable these ports check box is selected. If you are using a firewall other than Windows Firewall on vController, manually enable ports 7279, 8082, and 27000 to allow XenDesktop to function correctly. Click Next. On the Summary page, check that all five XenDesktop components are listed for installation and click Install. Before the components are installed, the following prerequisites are installed if they are not already present on vController.

6. 7. 8. 9.

10.

Microsoft Windows Management Framework Core (for Windows Server 2008 with Service Pack 2 only; included by default with Windows Server 2008 R2) Note: vController must be connected to the Internet to install the Windows Management Framework.

Microsoft .NET Framework 3.5 with Service Pack 1 Microsoft SQL Server 2008 R2 Express Edition Microsoft Visual C++ 2008 with Service Pack 1 Redistributable Package Microsoft Internet Information Services Microsoft Visual J#.NET 2.0 Second Edition Java Runtime Environment 5.0 Update 15 11. When the installation is complete, click Close. If you are ready to start provisioning desktops, ensure that the Configure XenDesktop after closing check box is selected.

To create machines and provision virtual desktops In the preceding tasks, you set up the infrastructure for your evaluation environment and installed XenDesktop. You can now start provisioning virtual desktops. 1. Ensure that you are logged on to vController as a domain administrator for the evaluation environment domain. If Desktop Studio is not already open from the previous procedure, click Start > All Programs > Citrix > Desktop Studio. In the results pane of Desktop Studio, click Quick deploy. On the Site page, specify a name for your XenDesktop evaluation deployment and click Next. On the Host page, select the virtualization infrastructure that you installed on pHost. Specify the address of the hypervisor service that XenDesktop can use to create new VMs on pHost. For XenServer environments, this is the URL of pHost. In Hyper-V environments, the service address is the fully qualified domain name of vSCVMM. For VMware environments, the address specifies the access point for the vCenter SDK, which is typically the URL of pCenter appended with /sdk. 5. 6. Supply credentials for an administrator account with permissions to create new VMs on pHost and click Next. On the Resources page, specify the type of storage to use for the VMs. Select one or more check boxes next to the storage instances you want to use. If you select multiple storage locations, machines are distributed equally rather than filling up the storage instances sequentially. The evaluation environment described here assumes that you are using local storage on pHost. However, if shared storage is also available in your deployment, you can use only local or shared storage; you cannot use a mixture of both. 7. 8. Select the network containing the DHCP server you set up on the domain controller and click Next. On the Master Image page, navigate to and select a snapshot of vMaster. Click Next. Citrix recommends that you use an appropriately named snapshot of vMaster to provision your desktops. If you specify the VM rather than a snapshot, Desktop Studio will create a snapshot for you but you will not be able to name it. 9. On the Number of VMs page, specify the number of machines you want to create and allocate virtual processors and memory to the VMs. You cannot change the size of the hard disk for the machinesthis setting is determined by the hard disk size you specified when you created vMaster. 10. 11. 12. Specify the organizational unit within the evaluation environment domain to which you want new Active Directory computer accounts for the machines to be added and click Next. On the Users page, click Add and select the Active Directory users or user groups to whom you want to assign the desktops. Click Next. On the Summary page, check that the details are correct and click Finish to start creating the machines and provisioning desktops. When the process is complete, click Close.

2. 3. 4.

XenDesktop creates the required number of machines on pHost, along with the corresponding Active Directory computer accounts in the evaluation environment domain. Then, XenDesktop makes a temporary copy of vMaster and, from this copy, creates desktops on the machines.

The Quick deploy task creates pooled-random machines, which are kept in a pool and are temporarily and randomly assigned to users as they log on. When users log off, pooled-random machines are returned to the pool and become available for other users. For more information about the other machine types available in XenDesktop, see Choosing the Machine Type. In the absence of a valid XenDesktop license, your desktops are available for 30 days and usage is limited to a maximum of 10 desktops at any one time. To continue using your desktops after the 30 day grace period has expired or to use more that 10 desktops simultaneously, install a valid XenDesktop license on the Citrix License Server running on vController. For more information about Citrix Licensing, see Licensing Your Product. By default, Quick Deploy sets the product edition in Desktop Studio to Platinum Edition. If you install a license for a different edition, reset the product edition in Desktop Studio by selecting the Configuration node in the left pane and, in the Actions pane, clicking Edit licensing. The topic XenDesktop User Experience guides you through the process of accessing your new desktops and testing the HDX high definition user experience. 7.2. XenDesktop User Experience Updated: 2010-10-21 To access your virtual desktops, you install the appropriate Citrix client for the operating system on the user device pUser. After installing the client, you can log on to your desktops and evaluate the HDX high definition user experience. In the evaluation environment, pUser is a physical Windows, Mac OS X, or Linux computer on which you install the Citrix Online Plug-in 12.1 for Windows, the Citrix Online Plug-in 11.2 for Macintosh, or Citrix Receiver for Linux 11.1, respectively. You can download and install these clients from the Web site automatically installed on vController when you installed XenDesktop. The clients are also available on the XenDesktop installation media and on the Citrix Downloads Web site. The following operating systems are supported for pUser. Windows 7 64-bit Editions Windows 7 32-bit Editions Windows Embedded Standard 7 Windows Vista 64-bit Editions with Service Pack 2 Windows Vista 32-bit Editions with Service Pack 2 Windows XP Professional x64 Edition with Service Pack 2 Windows XP Professional with Service Pack 3 Windows XP Embedded with Service Pack 3 Mac OS X Snow Leopard Mac OS X Leopard Mac OS X Tiger Linux with kernel version 2.6.18 or above running on a WYSE, HP, or IGEL thin client

To access your virtual desktops 1. Log on to pUser using an account with local administrator permissions and ensure that pUser is connected to the isolated network you set up for the evaluation environment. For Windows devices only, join pUser to the evaluation environment domain. 2. Using Internet Explorer, Firefox, or Safari, navigate to http://vControllerIP, where vControllerIP is the IP address of vController in the evaluation environment. The Web site attempts to detect whether a Citrix client is installed on the user device. If the appropriate client cannot be detected, you are prompted to download and install the software. 3. 4. Read and accept the license agreement, and click Install. Download and install the appropriate client for your operating system.

4. For more information about installing Citrix clients, see the documentation for your client. 5. After installing the client, return to the Web site and, when prompted, log on as one of the evaluation environment domain users to which you assigned the desktops that you created in Installing and Configuring the Evaluation Deployment. In a production environment, Citrix recommends delivering plug-ins to Windows and Macintosh users through Citrix Receiver and Merchandising Server. In this scenario, users do not have to install a plug-in, they simply access their desktops from Citrix Receiver or from the Web site. 6. Click the desktop icon in the center of the screen. The virtual desktop appears in the Desktop Viewer with a toolbar that provides controls for the desktop window.

To experience HDX MediaStream on XenDesktop 1. 2. Log on to your desktop as described above in To access your virtual desktops. To experience how HDX MediaStream delivers rich video content to virtual desktops, visit a Web site containing high definition videos, such as http://www.microsoft.com/silverlight/iissmooth-streaming/demo/, and view a video. To enable you to experience HDX MediaStream for Flash, browse to http://get.adobe.com/flashplayer/ and download and install Adobe Flash Player on both the virtual desktop and pUser. On the Desktop Viewer toolbar, click Preferences. In the Desktop Viewer Preferences dialog box, click the HDX tab and, under Flash Acceleration, select Enabled. To experience how HDX MediaStream for Flash accelerates the delivery of Flash multimedia content to virtual desktops, visit a Web site containing Flash videos, such as http://www.youtube.com/, and view a video on your desktop. HDX MediaStream for Flash is designed to be seamless so that users will not know when it is running. However, you can check to see whether HDX MediaStream for Flash is being used by looking for a block of color that appears momentarily before the Flash player starts. 6. On Windows and Linux user devices, configure your Citrix client for maximum audio quality. For more information about configuring audio quality for the Citrix Online Plug-in for Windows, see To customize user preferences for the online plug-in. For more information about configuring audio quality for Citrix Receiver for Linux, see Configuring Session Options. To experience how HDX MediaStream delivers high definition audio to virtual desktops, install a digital audio player, such as iTunes (available from http://www.apple.com/itunes/download/), on your desktop and play some music files.

3. 4. 5.

7.

To experience HDX Plug-n-Play on XenDesktop To experience how HDX Plug-n-Play enables simple connectivity to virtual desktops for USB devices, enable the Client USB device redirection policy rule in Desktop Studio. The policy rule enables you to control whether or not USB devices that users connect to their local devices are redirected to their virtual desktops. 1. 2. 3. 4. 5. 6. 7. 8. 9. Log on to vController and click Start > All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, select HDX Policy > Users and, in the results pane, click New. On the Identify your policy page, enter a policy name and, optionally, a description. Click Next. In the Categories list, select USB devices and, in the Settings pane, select Client USB device redirection and click Add. In the Add Setting dialog box, select Allowed and click OK. Click Next. On the Choose when to apply the settings using filters page, click Next. Ensure that the Enable this policy check box is selected and click Create. Log on to your desktop as described above in To access your virtual desktops. To experience HDX Plug-n-Play, connect a USB device, such as a flash memory drive, a webcam, or an iPod, to pUser. On the Desktop Viewer toolbar, click USB and select the USB device. The USB device is seamlessly redirected to the virtual desktop. For more information about supported USB devices, see the XenDesktop USB Citrix Tested Device List.

8. Installing and Setting up XenDesktop 5 Updated: 2010-10-15 For a new installation of XenDesktop, Citrix recommends that you carry out the following tasks in this order: 1. Install the server-side components of XenDesktop. 2. Start Desktop Studio and configure a site. Site configuration includes: Licensing the site and specifying which edition of XenDesktop to use Setting up the site database Providing information about your virtual infrastructure After you have configured a site you can add more controllers to it if necessary; see To add a controller for information on how to do this. 3. To manage your deployment remotely, install Desktop Studio on appropriate computers.

4. Install the Virtual Desktop Agent on your virtual desktops or base image. When you are installing the Virtual Desktop Agent you can also install plug-ins to enable you to deliver XenApp applications to your users. Important: Citrix supports installation of XenDesktop components only through the procedures described in Citrix documentation. Command-line tools (XenDesktopServerSetup.exe and XenDesktopVdaSetup.exe) are also available for installation tasks. 8.1. XenDesktop Installation Media and Downloads Updated: 2010-11-29 The following components are provided on disc and as web downloads: Disc name XenDesktop Contents XenDesktop core components: Controller, Web Interface, Desktop Studio, Desktop Director, License Server, SDKs, Virtual Desktop Agent, Wyse Xenith management plug-ins. XenServer Workload Balancing XenServer StorageLink Service Monitoring Single Sign-on Merchandising Server Workflow Studio XenApp for UNIX XenServer Virtual Infrastructure Provisioning services XenServer Provisioning services for desktops. An SQL database is a prerequisite for installing Provisioning Services, so Microsoft SQL Server 2008 Express Edition is also provided on this disc. XenClient, Receiver for XenClient, Synchronizer for XenClient 32-bit and 64-bit versions of: XenApp for Microsoft Windows Server 2008 R2 Multilanguage XenApp for Microsoft Windows Server 2008 English

XenClient Citrix XenApp for Microsoft Windows Server 2008

XenApp for Microsoft Windows Server 2008 Japanese Citrix XenApp for Microsoft Windows Server 2003 32-bit and 64-bit versions of: XenApp for Microsoft Windows Server 2003 English XenApp for Microsoft Windows Server 2003 Japanese

The following components are available only as web downloads: Profile management XenApp 5 Feature Pack 3 Access Gateway Linux Guest Support for XenServer For information on the components that are available in each XenDesktop edition, see XenDesktop Features and Editions. 8.2. Installing and Removing XenDesktop Server Components Updated: 2010-11-22 The server-side components of XenDesktop are: Controller. The SDKs are also automatically installed when you install the Controller. Web Interface. The License Server. Desktop Studio. The SDKs are also automatically installed when you install Desktop Studio. Desktop Director. The XenDesktop installation wizard guides you through making the right deployment choices from a simple proof of concept to an enterprise-ready installation. For a first installation, Citrix recommends that you install every component onto a single server. For large scale installations, you can install each component onto a separate server, allowing your deployment to grow to match the needs of your organization. Note that the XenDesktop installation wizard does not include setting up your virtual infrastructure; you must do this before configuring your XenDesktop site, using the relevant product documentation. By default, all the components are installed, but you can choose to omit any component that you do not want or that you plan to install on a different computer. If you install Web Interface or Desktop Director on a different computer from the controllers you want these components to connect to, ensure you know the relevant controllers' details because you have to provide them during installation. For Web Interface, the controllers you specify here are the only ones Web Interface will connect to, so if you specify only one controller there will be no failover or load balancing. For Desktop Director you need to specify only one controller: any of the other controllers on the site will then be used automatically for failover. Before you install the server components, read Planning a XenDesktop Deployment, and ensure you have the prerequisites installed. Depending on which components you are installing, the following prerequisites are installed automatically if they are not already present on the computer: Microsoft Windows Management Framework, if you are using Windows Server 2008 (but not Windows Server 2008 R2). This component is downloaded so if it is missing then an internet connection is required. This download includes Microsoft Powershell 2.0, which is a prerequisite for XenDesktop. Microsoft .NET Framework 3.5 Service Pack 1. Microsoft Internet Information Services (IIS). When IIS is installed, port 80 is automatically opened. Microsoft SQL Express 2008. Java Runtime Environment 1.5 update 15. Microsoft Visual J# Redistributable Package version 2.0. Microsoft Visual C ++ 2008 Service Pack 1 runtime redistributables.

To install the server components, log on using an account that has local administrator permissions (or ensure you know the administrator password), then insert the XenDesktop installation media in the appropriate drive or mount the ISO in the appropriate virtual machine. The following is a summary of the steps you are prompted to complete: 1. On the Installation page, select Install XenDesktop. The wizard starts. 2. Select the components you want to install (all are selected by default) and where you want to install them. 3. Manage firewall configuration. If the Windows firewall is detected, the necessary ports can be opened automatically for you. If another firewall is detected, you are told which ports you need to open manually for XenDesktop to operate successfully. 4. A summary of what is going to be installed appears. 5. When installation begins, progress is displayed on the screen. During the Initializing install stage, some preconfiguration is carried out automatically: if you have enabled Web Interface, the default Web sites are set up, and if you have installed Desktop Studio and Desktop Director, these are set up for you. 6. Provided you have installed Desktop Studio, when installation is complete the default is to start Desktop Studio so that you can configure your XenDesktop site. Note: If you are installing XenDesktop on a non-domain-joined machine you cannot configure a site, so the Configure XenDesktop check box does not appear. To install Desktop Studio separately, on the Installation page select Extras, then select Install Desktop Studio . To add or remove components, select the Windows option for adding or removing programs, then select Citrix XenDesktop. You can then select to add or remove components, or to remove XenDesktop completely. Note: Before removing the Controller component from a server, you must first ensure that the controller is removed from the site using Desktop Studio. 8.3. Installing and Removing the Virtual Desktop Agent Updated: 2011-02-08 The Virtual Desktop Agent has to be present on the virtual machines (VMs) to which your users will be connecting. It enables the machines to register with controllers and manages the HDX connection between the machines and the user devices. If you are using XenDesktop or Provisioning services to provision VMs, you need to install and configure the Virtual Desktop Agent only once, but if you are using separate stand-alone virtual or physical machines you must install it on each of the machines so they can register with the controller to allow user connections. You can install the Virtual Desktop Agent from a console session or from an RDP session, but installing from an ICA session is not supported. To install the Virtual Desktop Agent, insert the XenDesktop installation media in the appropriate drive or mount the ISO in the appropriate virtual machine (VM). The following is a summary of the steps you are prompted to complete: 1. On the Installation page, select Install Virtual Desktop Agent. 2. On the next page, select Advanced Install unless you are setting up a proof of concept evaluation deployment, in which case you should select Quick Deploy; setting up an evaluation deployment is described in Evaluating XenDesktop 5. The rest of this procedure describes only the steps to follow when you are carrying out an advanced installation. 3. Select the components you want to install and where you want to install them. If you plan to deliver XenApp applications to your users, select Support for XenApp Application Delivery. 4. Specify the controllers in the XenDesktop site to which the Virtual Desktop Agent will connect, either by manually entering the locations or by selecting controllers from Active Directory. Alternatively, select Configure at a later time if you plan to specify controller locations later using Group Policy or by rerunning the Virtual Desktop Agent installer.

Important: Ensure that you specify the locations of all the controllers in the site, otherwise some user connections may be refused. For load balancing, the Virtual Desktop Agent automatically distributes connections evenly across the controllers. 5. Configure the agent as follows: Reconfigure the firewall. If the Windows firewall is detected, the necessary ports can be opened automatically for you. If another firewall is detected, you are told which ports you need to open manually for XenDesktop to operate successfully. You can also request to have the necessary ports opened for Windows Remote Assistance and Windows Remote Management. If this installation is running in a VM on a hypervisor, you can select to have the VM automatically optimized for use with XenDesktop. Optimization involves actions such as disabling offline files, disabling background defragmentation, and reducing the event log size. For full information on the optimization tool, see http://support.citrix.com/article/ctx125874/ . 6. A summary of what is going to be installed appears. 7. When installation begins, progress is displayed on the screen. 8. When installation is complete the default is to restart the machine; you must do this for the changes to take effect. You can also install the Virtual Desktop Agent through a command-line utility: XenDesktopVdaSetup.exe. To deploy the Virtual Desktop Agent through Active Directory Group Policy, see http://support. citrix.com/article/ctx127301/. Note: When you install the Virtual Desktop Agent, a new local user group for authorized RDP users is automatically created. The group is called Direct RDP Access Administrators. For further information on using protocols other than ICA, see http://support.citrix.com/article/ctx121657/. XenDesktop requires desktops and controllers to have synchronized system clocks. This is required by the underlying Kerberos infrastructure that secures the communication between the machines. You can use normal Windows domain infrastructure to ensure that the system time on all machines is correctly synchronized. To add or remove components, select the Windows option for adding or removing progams, then select Citrix Virtual Desktop Agent. You can then select to add, remove, or reconfigure components, or to remove the Virtual Desktop Agent completely. You cannot remove support for XenApp application delivery through the XenDesktop installation wizard; you must remove the plug-ins directly through the Windows removal option. The Reconfigure Components option enables you to update the site and port numbers. 8.3.1. To configure firewalls manually Updated: 2010-11-15 To enable users to connect to virtual desktops, you must configure your virtual desktop firewall as follows: For communication between user devices and virtual 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.sys) on the TCP/IP port you configured at installation time. The default port is 80. 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.

Windows Remote Assistance requires ports TCP/135, TCP/3389, and DCOM. On Windows Vista and Windows 7 desktops you can configure these exceptions by enabling the built-in Remote Assistance exception. On Windows XP you must set additional exceptions: 1. 2. 3. 4. Enable the Remote Assistance exception. Add and enable the TCP 135 exception. Add and enable the "%systemroot%\PCHEALTH\HELPCTR\Binaries\helpsvc.exe" exception. See http://support.microsoft.com/kb/555179.

Windows Remote Management requires the following ports: TCP/80 for Windows Remote Management 1.1 TCP/5985 for Windows Remote Management 2.0

8.4. To use Windows XP virtual desktops with Single Sign-on Updated: 2010-08-11 If you use Single Sign-on (formerly Password Manager) with Windows XP virtual desktops, you must carry out the following procedure to chain the GINA (Graphical Identification and Authentication) dynamic link libraries, otherwise users cannot log on successfully through XenDesktop. You must do this after both Single Sign-on and the Virtual Desktop Agent have been installed. Caution: 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.

1. Inspect the following Windows XP registry entries and make a note of their current values: HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GinaDLL HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\CtxGinaDLL HKLM\Software\Citrix\Metaframe Password Manager\Shell\OrigGinaDLL 2. Modify the registry entries so that the GINAs are called in the correct order: HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GinaDLL This should point to the XenDesktop GINA; for example, C:\Program Files\Citrix\ICAService\picaGina.dll HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\CtxGinaDLL This should point to the Password Manager GINA; for example, C:\Program Files\Citrix\MetaFrame Password Manager\SSOGina\SSOGina.dll HKLM\Software\Citrix\Metaframe Password Manager\Shell\OrigGinaDLL This should point to MSGINA.dll, or NOGINAPREVIOUSLYINSTALLED 3. Restart the virtual desktop. 8.5. Installing and Removing Wyse Xenith Updated: 2011-03-01 If you are planning to use the Wyse Xenith zero client, you can install the relevant management plug-ins through the XenDesktop installation wizard. To install the plug-ins, run the XenDesktop installer using an account that has local administrator permissions. On the Installation page, select Extras, then select Install Wyse Xenith Manager. For further information on the installation process, and for details of how to remove the plug-ins, see your Wyse documentation. Desktop Studio will include the Wyse Xenith management snap-in if the Wyse product has been detected on

the computer. 8.6. To configure a XenDesktop site Updated: 2010-11-30 After you have installed XenDesktop for the first time, you must configure a site. You cannot add more controllers to the site until you have done this. Site configuration involves: Licensing the site and specifying which edition of XenDesktop to use. Setting up the site database. Ensure that you have read the database-related information in Planning a XenDesktop Deployment before you start configuring your site. Providing information about your virtual infrastructure, in terms of the host and connection to use. A host is a representation of a XenServer pool (or ESX or SCVMM cluster), with storage and a virtual network, where you create and store virtual machines (VMs) for your user desktops. This infrastructure allows you to efficiently manage the distribution of VMs in your hypervisor infrastructure. A host connection represents the credentials and address needed to access the host; these can be used by more than one host. You can choose between two wizards when configuring sites: the Quick Deploy wizard or the Desktop Deployment wizard. The Quick Deploy wizard is intended for setting up small production sites and proofof-concept sites; it is described in Evaluating XenDesktop 5 and Quick Deploy. This topic describes the Initial Configuration steps in the Desktop Deployment wizard, which is intended for more typical production deployments. To start the wizard for configuring the site, start Desktop Studio, then select Desktop Deployment. The rest of this topic summarizes the steps the wizard takes you through and provides additional information where necessary. 1. Specify a site name. 2. Specify the license server to use. You must specify the address as name:[port], where name can be a DNS, NetBIOS, or IP address. If you do not specify a port number, the default port is assumed. If there is already a license server on the controller, you are not prompted to specify its name; instead you are prompted for a license file location and the edition is detected from the license file. If you need to point to a different license server after initially configuring the site, select Configuration in the left pane of Desktop Studio, then Edit Licensing from the list of actions. Specify the database to use: By default XenDesktop uses the locally installed copy of SQL Express, if it is available, to create the site database on the controller on which you are working. To use an alternative database, select Use existing database. The server location must be a DNS, NetBIOS, or IP address, without a port number. If you are using an existing database and you need to set up XenDesktop manually, for example if your database is locked down, click Generate. This generates two scripts for use by your database administrator: one that generates the entire database setup for XenDesktop, and one optional script for use if you are using database mirroring. These scripts must be run before you can complete XenDesktop initial configuration. Click Next. 4. Specify a connection name, the type of host you are using, and the credentials to use when accessing it. Ensure that the credentials enable you to carry out all the necessary XenDesktop tasks. If you use XenServer, note that: Citrix recommends using HTTPS to secure communication between XenDesktop and XenServer. To use HTTPS you must replace the default SSL certificate installed with XenServer with one from a trusted certificate authority. For details of how to do this see To replace the default XenServer SSL certificate You can configure high availability if it is enabled on XenServer. Citrix recommends that you select all servers in the pool to allow communication between XenDesktop and XenServer if the pool master fails.

3.

Note: If you are using XenDesktop to manage user desktops hosted on dedicated blade PCs in the

data center, select None for host type. You do not need to provide any further configuration information and the configuration summary appears. 5. Select whether to use XenDesktop to create virtual machines, or whether to create them manually. Select the XenDesktop option to use Machine Creation Services to create catalogs of pooled or dedicated VMs. The manual creation option allows you to use XenDesktop to manage and deliver user desktops that you have already migrated to VMs in the data center.

6. If you select to use XenDesktop to create desktops, you are prompted to specify the details of the host on which they will be stored: a name for the host, and the virtual network and storage to use. If both local and shared storage are available on the host you must select a single type; you cannot mix them. Note: If you intend to use SmartAccess endpoint analysis, pass-through authentication, or smart card authentication with XenDesktop, you must configure XenDesktop to trust XML services. To do this, run the following Powershell SDK command:

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

After configuring your site, you can add more controllers to it or create a catalog. 8.6.1. To replace the default XenServer SSL certificate Updated: 2010-11-22 Citrix recommends using HTTPS to secure communication between XenDesktop and XenServer. To use HTTPS you must replace the default SSL certificate installed with XenServer with one from a trusted certificate authority: 1. Modify /etc/pki/tls/openssl.cnf as follows: 1. Request extensions by uncommenting the following line:

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

[v3_req] basicConstraints = CA:FALSE keyUsage = keyEncipherment extendedKeyUsage = serverAuth

2. Generate a certificate request: openssl genrsa -out [servername].private 2048 openssl req -new -outform PEM -out [servername].request -keyform PEM -key [servername].private -days 365 where [servername] is the name of the XenServer host. This generates a request for a 1 year (365 day) certificate in the file called [servername].request. 3. Have the certificate request contained in [server name].request signed by a certificate authority. This can be either a commercial certificate authority or an internal corporate certificate authority such as Microsoft Certificate Services. 4. After the new certificate has been signed, move the existing certificate: mv/etc/xensource/xapi ssl.pem/etc/xensource/xapi -ssl.pem_orig 5. Add the new signed certificate to the XenServer host and tighten the access rights: cat [servername ].public [servername].private > [servername].pem install -m 0400 [servername ].pem/etc/xensource/xapi-ssl.pem 6. Edit the file /etc/init.d/xapissl, using the line: PEMFILE=/etc/ssl/certs/[servername].pem 7. Restart the XenServer communications service by entering the following command: /etc/init. d/xapissl restart If you are using a private certificate authority you may need to install your root certificate on the controller. To install a certificate on the controller 1. Locate the root certificate file in Windows Explorer. 2.

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. 9. Migrating to XenDesktop 5 Updated: 2011-03-14 A migration tool is available to enable you to easily transfer data and settings from your XenDesktop 4 farm to a XenDesktop 5 site. This topic provides the information you need to take into account when planning how best to migrate your deployment. The other topics in this section describe: Upgrading XenDesktop Components Data Import and Export Details Exporting Data from a XenDesktop 4 Farm Editing the Migration Tool XML File Importing Data into a XenDesktop 5 Site Post-Migration Tasks Migrating from XenDesktop 4 to XenDesktop 5: an Example To use the migration tool successfully, both deployments must use the same hypervisor environment. The recommended steps to migrate your deployment are as follows: 1. 2. 3. 4. 5. Set up a XenDesktop 5 site and upgrade Web Interface and XenServer to the latest versions. Update user devices with the latest version of Citrix Receiver. Upgrade virtual desktops to the XenDesktop 5 Virtual Desktop Agent. In XenDesktop 4, put the virtual desktops into maintenance mode. Ensure you understand which data can be exported and imported, and how this applies to your own deployment. Information on which types of data are exported and imported is available at Data Import and Export Details. Export data and settings from your XenDesktop 4 farm to an XML file. For details of using the migration tool to do this, see Exporting Data from a XenDesktop 4 Farm. Edit the XML file so that it contains only the data and settings you want to import into your XenDesktop 5 site. For further details of how to edit the XML file, see Editing the Migration Tool XML File. Import data and settings from the XML file to your XenDesktop 5 site. For details of using the migration tool to do this, see Importing Data into a XenDesktop 5 Site. Repeat steps 6 to 8 as many times as necessary. Alternatively, if the XenDesktop 4 farm is not changing very much during this time, you can keep the original exported XML file and just repeat steps 7 and 8 rather than repeating the export step. Complete the post-migration tasks described in Post-Migration Tasks.

6. 7. 8. 9.

10.

For a worked example of migrating a deployment based on the steps listed above, see Migrating from XenDesktop 4 to XenDesktop 5: an Example. 9.1. Upgrading XenDesktop Components Updated: 2011-03-14 The figure shows the main XenDesktop components and the relationships between them that are most significant in the upgrade and migration process.

To use XenDesktop 5 you must set up a new XenDesktop 5 site with its own database; XenDesktop 5 only supports Microsoft SQL Server 2008. For full details of database requirements, see Database Requirements. You cannot upgrade a XenDesktop 4 delivery controller to XenDesktop 5. XenDesktop 5 controllers cannot join a XenDesktop 4 farm, and XenDesktop 4 delivery controllers cannot join a XenDesktop 5 site. This is because XenDesktop 4 requires Microsoft Windows Server 2003, whereas XenDesktop 5 requires Microsoft Windows Server 2008. Virtual Desktop Agent You must upgrade all existing virtual desktops to the XenDesktop 5 Virtual Desktop Agent before they can be managed by a XenDesktop 5 controller. XenDesktop 5 virtual desktops can, however, be managed by XenDesktop 4 delivery controllers. Web Interface Web Interface provides the user interface that lets the user authenticate and select which desktop they want to connect to. Web Interface can aggregate XenApp and XenDesktop, and it can also aggregate multiple farms or sites for each product. Web Interface is backwards- and forwards-compatible. Specifically for XenDesktop 5, Web Interface 5.4 has been enhanced to optimize the user experience when launching desktop connections. In particular, Web Interface 5.4 provides a better way of displaying access to multiple desktops and optimizes performance when a large number of assigned desktops are available. There is one XenDesktop 5 feature that is not available through earlier versions of Web Interface: assignment of virtual desktops to user devices where users can reset these desktops. If you need to use this feature, you must upgrade to Web Interface 5.4. In all other cases, you can continue to use an existing Web Interface deployment, although Citrix recommends upgrading to the latest version to benefit from the performance and usability enhancements. The upgrade process for Web Interface has not changed from earlier versions. For further details, see Web Interface 5.4. User Device Citrix recommends that you update user devices with the latest version of Citrix Receiver to benefit from hotfixes and to receive support for the latest features. For further details, see Receiver and Plug-ins.

Provisioning Services Provisioning services continues as a supported mechanism for streaming the operating system to a virtual or physical desktop. There is support for administering Provisioning services through Desktop Studio, but this is limited to importing machines from Provisioning Services into catalogs. Citrix recommends that you use the latest version of Provisioning services. 9.2. Data Import and Export Details Updated: 2011-03-14 This topic provides two tables: one that summarizes how the various types of data are exported from XenDesktop 4 and imported into XenDesktop 5, and one that provides details of how user policy settings are exported and imported. The following table lists types of data that: Are both exported and imported. Are exported but not imported. You can extract this data from the XML file produced by the export tool and use it for other purposes. May be present in the XenDesktop 4 farm but are not exported. This list is not exhaustive: it includes the most significant relevant types of data.

Data type Desktop groups

Exported? Imported? Notes Y Y Desktop group icons are not exported. SecureIcaRequired is set to 'true' if the DefaultEncryptionLevel in XenDesktop 4 is not 'basic'.

Desktops

If a desktop group in the XenDesktop 4 farm has the same name as a desktop group in the XenDesktop 5 site, desktops belonging to it can be added to the group of the same name in the target site. To do this, you must specify the MergeDesktops parameter when you run the import tool. Note that the settings of the XenDesktop 5 group are not overwritten with the settings of the XenDesktop 4 group. If this parameter is not specified, and there is a group with the same name as one defined in the XML file, the tool displays an error and halts before any data is imported. Note that assigned desktops cannot be added to a shared desktop group, and pooled desktops cannot be added to a private desktop group.

Machines

Machines are imported into four catalogs. These catalogs are automatically created in the XenDesktop 5 site by the import tool and are called Imported Existing Random (for pooled VMs), Imported Existing Static (for assigned VMs), Imported Physical Random (for pooled PCs or blades), and Imported Physical Static (for assigned PCs or blades). Any subsequent import of machines uses the same four catalogs. Includes multi-pool pools, and idle pool settings including schedule. PeakBuffersizePercent is set to 10% by default. OffPeakBufferSizePercent is set to 10% by default. Any unselected days in the Business days setting

Pool management pools

on XenDesktop 4 are imported as part of the Weekend power time scheme in XenDesktop 5. HostingXD4 Action times are rounded up to the nearest minute. Start times are rounded down to the nearest hour. End times are rounded up to the nearest hour. Farm settings Y Y The following farm settings are imported as a machine policy: IcaKeepAlive, AutoClientReconnect, and SessionReliability. Note that the setting to enable the Flash player is not imported. Some policy data is imported. Filters, settings, and printers are imported as user policies. For further details of user policy export and import, see the other table in this topic. New access policy rules are created from XenDesktop 4 group settings. When policies are imported their relative priority order is preserved. However they are always added with a higher priority than any existing policies on the XenDesktop 5 site. Policy merging is not supported. There is no option to import policies into Active Directory. They are always stored in the site. User assignments Hypervisor settings Y Y Y Y Hypervisor addresses are exported, but not the credentials required to access those hypervisors. To create hypervisor connections in the XenDesktop 5 site you must extract the addresses from the XML file and create a Powershell hash table that maps them to the relevant credential instances. You then specify this table in the import tool HypervisorConnectionCredentials parameter. For further details on how to create the table, see Importing Data into a XenDesktop 5 Site. No merging or updating of hypervisor settings for existing desktop groups and hypervisor connections is supported. Administrators Y N No administrator data is imported, including data about delegated administrators. You must create new administrators for your XenDesktop 5 site. For example, license server name and desktop edition. Note that license files are not exported. Desktop group folders Y N XenDesktop 5 does not support desktop group folders. If you have duplicate desktop group names because different folders in the XenDesktop 4 farm contained

Policies

Licensing configuration Y

groups with the same names, edit them in the XML file. If you do not this, the import tool will halt. Registry keys Y N For information on implementing registry keys, see Post-Migration Tasks.

Provisioning services-related data Applications List of desktop delivery controllers

N N

Web N Interface configuration Active N Directory Organizational Unit (OU) configuration

Any Web Interface migration is handled by the Web Interface install and upgrade mechanisms. If you plan to configure the new site to use Active Directory-based controller discovery rather than the default registry-based controller discovery, Citrix recommends that you create a new Organizational Unit to support it.

NetScaler and Access Gateway Event log throttling settings

PortICAConfig XML file N

If you have changed the default settings for this file you may need to configure these settings for the new site through Group Policy Objects.

Configuration logging settings provided through XenDesktop 4 Service Pack 1

The following table shows how user policy data is exported and imported. XenDesktop 4 category and setting Bandwidth\Visual Effects\Session Limits OEM Virtual Channels Client Devices\Resources\Other Turn off OEM virtual channels DisableOEMVirtualChannels Not imported XML file XenDesktop 5 category and setting Not imported

ClientOEMVCBandwidth

User Workspace\Time Zones Do not use Client's local time Security\Encryption SecureICA encryption

DoNotUseClientLocalTime

Not imported

ClientSecurityRequirement

Not imported

Bandwidth\Visual Effects\SpeedScreen LossyCompression settings Image acceleration using lossy compression Bandwidth\Visual Effects Turn off desktop wallpaper Bandwidth\Visual Effects Turn off window contents while dragging Bandwidth\Visual Effects Turn off window contents while dragging Bandwidth\Visual Effects\Session Limits Printer Bandwidth\Visual Effects\Session Limits Drives Bandwidth\Visual Effects\Session Limits LPT Ports Bandwidth\Visual Effects\Session Limits COM Ports Bandwidth\Visual Effects\Session Limits Clipboard Bandwidth\Visual Effects\Session Limits Audio Bandwidth\Visual OverallBandwidth__AllowedBandWidth ClientAudioBandwidth__AllowedBandWidth ClientClipboardBandwidth__AllowedBandWidth ClientComBandwidth__AllowedBandWidth ClientLptBandwidth__AllowedBandWidth ClientDriveBandwidth__AllowedBandWidth LimitPrinterBandWidth__AllowedBandWidth DoNotShowWindowContentsWhileDragging TurnOffMenuWindowAnimation TurnOffWallpaper

Bandwidth ICA\Graphics\Image compression

DesktopWallpaper ICA\DesktopUI MenuAnimation ICA\DesktopUI

WindowContentsVisibleWhileDragging ICA\DesktopUI

PrinterBandwidthLimit ICA\Bandwidth

FileRedirectionBandwidthLimit ICA\Bandwidth

LptBandwidthLimit ICA\Bandwidth

ComPortBandwidthLimit ICA\Bandwidth

ClipboardBandwidthLimit ICA\Bandwidth

AudioBandwidthLimit ICA\Bandwidth

OverallBandwidthLimit

Effects\Session Limits Overall Session Client Devices\Resources\Audio Microphones Client Devices\Resources\Audio Sound Quality Client Devices\Resources\Audio Turn off speakers Client Devices\Resources\Drives Connection Client Devices\Resources\Drives Turn off Floppy disk drives Client Devices\Resources\Drives Turn off Hard drives Client Devices\Resources\Drives Turn off CD-ROM drives Client Devices\Resources\Drives Turn off Remote drives Client Devices\Resources\Drives Turn off USB disk drives Client Devices\Resources\Drives\Optimize CDMAsyncWrites Asynchronous writes Client Devices\Resources\Other Turn off clipboard mapping Client Devices\Resources\Ports Turn off COM ports Client Devices\Resources\Ports Turn off LPT ports Client Devices\Resources\USB USB DisableClientLPTPortMapping DisableClientCOMPortMapping DisableClientClipboardMapping DisableClientDriveMapping__DisableUSB DisableClientDriveMapping__DisableRemote DisableClientDriveMapping__DisableCdrom DisableClientDriveMapping__DisableHardDrive DisableClientDriveMapping__DisableFloppyDrive ConnectClientDriveAtLogon__TurnOn DisableClientAudioMapping ClientAudioQuality__Quality ClientAudioMicrophone__TurnOn

ICA\Bandwidth

MicrophoneRedirection ICA\Audio AudioQuality ICA\Audio ClientAudioRedirection ICA\Audio AutoConnectDrives ICA\FileRedirection ClientFloppyDrives ICA\FileRedirection ClientFixedDrives ICA\FileRedirection ClientOpticalDrives ICA\FileRedirection ClientNetworkDrives ICA\FileRedirection ClientRemoveableDrives ICA\FileRedirection AsynchronousWrites ICA\FileRedirection ClipboardRedirection ICA ClientComPortRedirection ICA\Ports ClientLptPortRedirection ICA\Ports

RemoteUSBDevices__DisableRemoteUSBDevices UsbDeviceRedirection ICA\USBDevices

Printing\Client Printers Auto-creation Printing\Client Printers Legacy client printers Printing\Client Printers Printer properties retention Printing\Client Printers Print job routing Printing\Client Printers Turn off client printer mapping Printing\Drivers Native printer driver auto-install Printing\Drivers Universal driver Printing\ Session printers Session printers Printing\ Session printers Choose client's default printer

ConnectClientPrinterAtLogon__Flag

ClientPrinterAutoCreation ICA\Printing\ClientPrinters

LegacyClientPrinters__TurnOn

ClientPrinterNames ICA\Printing\ClientPrinters

ModifiedPrinterProperties__WriteMethod

PrinterPropertiesRetention ICA\Printing\ClientPrinters

ClientPrintingForNetworkPrinter__TurnOn

DirectConnectionsToPrintServers ICA\Printing\ClientPrinters

DisableClientPrinterMapping

ClientPrinterRedirection ICA\Printing

PrintDriverAutoInstall__TurnOn

InboxDriverAutoInstallation ICA\Printing\Drivers

ClientPrintDriverToUse

UniversalPrinting ICA\Printing\UniversalPrinting

NetworkPrinters

SessionPrinters ICA\Printing

DefaultToMainClientPrinter__NetworkDefault DefaultToMainClientPrinter__TurnOn

DefaultClientPrinter ICA\Printing

9.3. Exporting Data from a XenDesktop 4 Farm Updated: 2011-04-11 The export tool extracts data from a single XenDesktop 4 farm and produces an XML file from representations of the data values. The data types exported are described in Data Import and Export Details. The schema of the XML file is provided in a file called XdFarm.xsd, which is included in the migration tool download: XdExport.zip and XdImport.zip. You must run the tool on a machine that is a desktop delivery controller in the farm from which you want to export data. This machine must have the XenDesktop 4 PowerShell SDK installed. The user identity running the tool must be configured to be at least a read-only Citrix administrator of the farm, and must have permission to read the registry. Citrix recommends that the controller on which you run the tool be up-todate with public hotfixes. You can run the tool while the controller is in active use, but Citrix does not recommend this. To run the export tool 1. 2. Download XdExport.zip and extract the files to the XenDesktop 4 desktop delivery controller. At a command-line prompt, run XdExport.exe. You can specify the following parameters:

2. Parameter -Verbose Description If you supply this parameter, messages providing detailed progress information are generated. The location of the XML file to which the farm data is exported. Default = .\XDSettings.xml If you supply this parameter, any file existing in the location specified in -Filepath is overwritten. If you do not supply this parameter and an output file already exists, the tool fails with the following error message: 'Error: File already exists. Specify /OVERWRITE to allow the file to be overwritten.' -? or -help If you supply this parameter, the tool outputs text describing the parameters and exits without exporting any data.

FilePath <path>

-Overwrite

3.

If the tool runs successfully, the message 'Done' appears. The XML file (XDSettings.xml) is stored in the location specified in the FilePath parameter. If the tool fails, an error message appears.

When you have successfully run the export tool, review and edit the XML file as described in Editing the Migration Tool XML File. 9.4. Editing the Migration Tool XML File Updated: 2011-03-10 Before importing data to your XenDesktop 5 site you will probably need to edit the contents of the XML file generated by the export tool, particularly if you choose to migrate in multiple stages and import some users, desktop groups, and policies before importing others. This topic describes three typical situations in which you may need to edit the file. You can use any text editor to view or change the file contents, or you can use a specialised XML editor such as Microsoft XML Notepad. Some elements within the XML content must be present for the XML file to be accepted by the import tool. The required XML schema is defined in the XdFarm.xsd file, which is supplied as part of the migration tool download. This file indicates in many places that particular elements must be present if the parent element is present, by specifying the minOccurs attribute with a value of 1 or more. If the XML file supplied to the import tool is not valid, the tool halts and an error message appears that should enable you to locate where the problem lies in the XML file. Importing a subset of desktops or desktop groups To import only a subset of desktop groups and desktops, you must edit the contents of the DesktopGroups element. The DesktopGroups element can hold many DesktopGroup elements, and within each DesktopGroup element there is a Desktops element that can contain many Desktop elements. You must not delete the DesktopGroups element, although you can delete all the DesktopGroup elements and leave it empty. Similarly, within each DesktopGroup element the Desktops element must be present but can be empty of Desktop elements. Delete Desktop or DesktopGroup elements to avoid importing particular single desktops or entire desktop groups. For example, the XML file might contain:

<DesktopGroups> <DesktopGroup name="Group1"> . . .

. <Desktops> <Desktop samName="DOMAIN\MACHINE1$"> . . . </Desktop> </Desktops> . . . </DesktopGroup> <DesktopGroup name="Group2"> . . . <Desktops> <Desktop samName="DOMAIN\MACHINE2$"> . . . </Desktop> <Desktop samName="DOMAIN\MACHINE3$"> . . . </Desktop> </Desktops> . . . </DesktopGroup> </DesktopGroups>
You could edit this so that the Group1 group would not be imported at all, and only the Machine3 desktop from the Group2 group would be imported:

<DesktopGroups> <DesktopGroup name="Group2"> . . . <Desktops> <Desktop samName="DOMAIN\MACHINE3$"> . . . </Desktop> </Desktops> . . . </DesktopGroup> </DesktopGroups>
Managing desktop groups with duplicate names XenDesktop 5 does not support desktop group folders, and desktop groups in a site must have unique internal names; you can specify the names that appear to users separately. In XenDesktop 4, however, a desktop group in one folder can have the same name as a group in another folder, and the name that appears to users is the desktop group name. For example, in your XenDesktop 4 farm you have two different

desktop groups that appear with the name My Desktop to two different users, and you have used desktop group folders to achieve this. If these desktop groups are to remain separate in the XenDesktop 5 site, you must edit the group names in the XML file to make them unique. If a desktop group in the XenDesktop 5 site has the same name as a group to be imported, and the groups are to remain separate in the XenDesktop 5 site, you must edit the XenDesktop 4 group name in the XML file to keep the name unique in the site. If the group being imported is really the same as the XenDesktop 5 group, and the machines in the XML file are to be merged into the existing group, you do not need to rename the group; instead, you specify the -MergeDesktops parameter to the import tool. For example, the XML file might contain:

<DesktopGroups> <DesktopGroup name="My Desktop"> . . . <Folder>\Sales</Folder> </DesktopGroup> <DesktopGroup name="My Desktop"> . . . <Folder>\Finance</Folder> </DesktopGroup> </DesktopGroups>
You could edit this to remove the duplicate names as follows:

<DesktopGroups> <DesktopGroup name="Sales Desktops"> . . . <Folder>\Sales</Folder> </DesktopGroup> <DesktopGroup name="Finance Desktops"> . . . <Folder>\Finance</Folder> </DesktopGroup> </DesktopGroups>
Managing the import of policies You can delete entire individual policies from the XML file, and you can specify unique names to avoid policy name duplication. There is no support for merging policies in the migration tool. Note that: When you import policy data, either all polices are imported successfully or, if there is a failure at any point, no policy data is imported. Importing large numbers of policies with many settings can take several hours. If you decide to import policies in batches, bear in mind that their original prioritization may be affected. When you import policies, the relative priorities of the imported polices are maintained, but they are given higher priority than policies already in the site. For example, if you have four polices to import with priority numbers 1 to 4, and you decide to import them in two batches, you should import policies with priorities 3 and 4 first, because the second batch of policies will automatically be given higher priority. To import only a subset of policies into the XenDesktop 5 site, edit the contents of the Policies element. The Policies element can hold many Policy elements. You must not delete the Policies element, although you can delete all the Policy elements and leave it empty. Delete entire Policy elements to avoid importing particular XenDesktop 4 farm policies. For example, the export tool might contain:

<Policies> <Policy name="Sales Policy"> . . . </Policy> . . . </Policies>

To avoid importing any XenDesktop 4 policies, perhaps because you want to avoid clashes with policies already configured in the XenDesktop 5 site, edit the file to remove the individual Policy elements as follows:

<Policies> </Policies>
Alternatively, you could edit the file so that the policy is imported with a different name as follows:

<Policies> <Policy name="XD4 Sales Policy"> . . . </Policy> . . . </Policies>

9.5. Importing Data into a XenDesktop 5 Site Updated: 2011-04-11 The import tool reads settings from the XML file produced by the export tool and applies those settings to an existing XenDesktop 5 site. The import tool consists of a Powershell script called Import-XdSettings.ps1. Not all the data is imported from the XML file; for details of which types of data are imported, see Data Import and Export Details. If you want to apply only a subset of the exported data, edit the XML file appropriately before running the import tool. It is likely that you will need to do considerable amounts of editing: for example, you may want to remove desktop groups and policies that are not needed in your XenDesktop 5 deployment. The import tool will still run successfully if you leave entire elements empty: for example, you could delete all the desktop groups without causing any issues. The tool always validates the XML file before attempting to import any data. For further details of how to edit the XML file, see Editing the Migration Tool XML File. The data in the XML file is applied to the XenDesktop 5 site as described in Data Import and Export Details. You can run the tool on any machine that has all the XenDesktop 5 SDKs installed. The user identity running the tool must be configured to be a full XenDesktop administrator. Citrix recommends that you complete the import to XenDesktop 5 before any user testing or general site configuration occurs. If you are merging configurations, do this while the site is not in use. To run the import tool 1. 2. Download XdImport.zip and extract the files to the machine on which you plan to run the tool. Run Import-XdSettings.ps1. You can specify the following parameters: Parameter -FilePath <path> Description The location of the XML file from which the farm data is to be imported.

By default the file is assumed to be in the folder in which the import tool is run. -AdminAddress The name of a controller in the XenDesktop 5 site. Default = localhost -HypervisorConnectionCredentials A PowerShell hash table that maps hypervisor addresses to PSCredential instances as required for the creation of hypervisor connections. Default = @{} For a single hypervisor, you could create the argument as follows:

$credential = Get-Credential $mappings = @{"http://<HypervisorIP>" =$credential} .\Import-XdSettings.ps1 -FilePath. \XdSettings.xml -HypervisorConnectionCredentials $mappings
Note that the address specified in the hash table must exactly match the address in the XML file. If you had, for example, both a XenServer and a VmWare hypervisor, you could create the argument like this:

$Xencredential = Get-Credential $VMWcredential = Get-Credential $mappings = @{"http://<XenHypervisorIP>" = $Xencredential;"http://<VmWHypervisorIP>/SDK" = $VMWcredential} .\Import-XdSettings.ps1 -FilePath. \XdSettings.xml -HypervisorConnectionCredentials $mappings

-MergeDesktops

If you supply this parameter, desktops defined in the XML file are added to desktop groups in the XenDesktop 5 site that have the same name as the groups described in the XML file. The associated machines and users are also added. If this parameter is not supplied, no content is added to existing desktop groups in the XenDesktop 5 site.

-SkipMachinePolicy

If you supply this parameter, the script does not create a machine policy to hold site level settings. If you do not supply this parameter and the machine policy already exists, the script fails. If you supply this parameter, a trial run is carried out to find what would be changed in or added to the XenDesktop 5 site. Information about this is output to the log file, but no changes are made to the site. The full path of the log file. The log file contains text describing all writes performed against the XenDesktop 5 site. Default = .\Import-XdSettings.log

-WhatIf

-LogFilePath <path>

-?

If you supply this parameter, the tool outputs text describing

the parameters and exits without importing any data.

Note that if the XML file contains policy data, either all polices are imported successfully or, if there is a failure at any point, no policy data is imported. Importing large numbers of policies with many settings can take several hours. 3. When the script completes, the message 'Done' appears.

When you have successfully imported the data from the XML file you can either run further export and import iterations, or, if you have imported all the relevant data, you can carry out the post-migration tasks described in Post-Migration Tasks. 9.6. Post-Migration Tasks Updated: 2011-03-14 After you have imported all the data you need from your XenDesktop 4 farm to your XenDesktop 5 site, there are certain tasks you need to carry out before using the new site for production work: Create any administrators you need for the XenDesktop 5 site. Modify the imported desktops to use registry-based controller discovery and point them to the XenDesktop 5 controllers. You can do this in any of the three following ways: Manually edit the registry as described in http://support.citrix.com/article/CTX118976 Set up a machine policy to distribute the list of controllers to the desktops, using the Virtual Desktop Agent settings Use the Virtual Desktop Agent installer to reconfigure the desktops Registry-based controller discovery is the default for XenDesktop 5, but Active Directory-based discovery is still available; for further details, see Active Directory Considerations. Optionally, implement the following registry key settings as described in http://support. citrix.com/article/CTX126704: HeartbeatPeriodMS, PrepareSessionConnectionTimeoutSec, MaxWorkers, DisableActiveSessionReconnect, ControllersGroupGuid. If you do not do this, the default XenDesktop 5 settings for these keys are used. Take the imported desktops out of maintenance mode if they were in maintenance mode in XenDesktop 4 before the XML file was generated. Check the XenDesktop 5 settings to make sure that they are correct, particularly if you had changed the PortICAConfig XML file on XenDesktop 4.

9.7. Migrating from XenDesktop 4 to XenDesktop 5: an Example Updated: 2011-03-14 This topic provides an example of upgrading an existing XenDesktop 4 deployment to XenDesktop 5. This deployment has the following characteristics: User devices are a mix of company-owned and user-owned devices. A number of thin clients have been set up with the full-screen user experience. Three desktop groups are available: Engineering: a set of preassigned desktops. Sales: a set of pooled desktops, using a shared disk image provided by Provisioning services. Finance: a set of pooled desktops, not using Provisioning services. Note that the names used for types of desktop group change at XenDesktop 5: assigned and preassigned desktop groups become private desktop groups, and pooled desktop groups become shared desktop groups. For details of other differences between XenDesktop 5 and previous versions of the product, see Key Differences in XenDesktop 5. A single Web Interface server has been set up. This diagram shows the existing XenDesktop 4 deployment:

Summary Rather than upgrading the entire deployment to XenDesktop 5 in one step, the example illustrates a staged approach as follows: 1. Set up a XenDesktop 5 deployment in a test lab, and provide selected users with additional desktops. These users can continue to use their existing XenDesktop 4 desktops, but are encouraged to test the new XenDesktop 5 desktops. Use the new XenDesktop 5 single image functionality to provide a mix of private desktops and shared desktops. After the first stage is successful, migrate a subset of the Engineering and Sales users to a new XenDesktop 5 deployment. It must be possible to revert these users to the XenDesktop 4 deployment in case problems occur with XenDesktop 5. After an extended test period, migrate all remaining users to the new XenDesktop 5 deployment and retire the existing XenDesktop 4 deployment.

2.

3.

In all cases, these changes are transparent to users, who do not have to reconfigure their user devices. Citrix recommends that import operations are performed during a scheduled maintenance period to minimize any impact to users and administrators using the XenDesktop 5 site. Import operations involving a large number of policies can take several hours to complete. Stage 1: Test Lab To implement this staged approach: 1. Identify the set of users that should receive the new trial desktops. Users using full-screen-only thin clients are not suitable for this, because users need to be able to choose the desktop, and fullscreen-only thin clients do not offer the user a choice. Optionally, upgrade Web Interface to the latest release. This is recommended, but not mandatory. Upgrade XenServer to the latest release or deploy a new XenServer pool using the latest release. Create a new golden virtual machine (VM) and install the XenDesktop 5 Virtual Desktop Agent on it. Create a new XenDesktop 5 site. The XenDesktop 5 site must use the same Active Directory domain as the XenDesktop 4 farm, because the imported machines' SIDs must match existing ones.

2. 3. 4. 5.

6. 7.

Create the necessary catalogs and desktop groups using the golden VM(s) created earlier, and publish them to the trial users identified in the first step.

Configure Web Interface to aggregate resources from the existing XenDesktop 4 farm and the new XenDesktop 5 site. The user roaming feature can be used to mitigate the performance impact of farm aggregation for non-trial users: 1. Ensure that all trial users (and only trial users) are members of a particular Active Directory user group. 2. 3. Configure Web Interface to make the existing XenDesktop 4 farm a home site for all users. Configure Web Interface to make the new trial site a home site for trial users.

With this setup in place, the user experience is as follows: Non-trial users experience no change from before. Trial users see one or more new desktop groups in Web Interface. They can launch connections to both the old and the new desktops and report feedback on the new desktops. This diagram illustrates the resulting deployment:

Stage 2: Part Migration

After a successful test lab deployment, the next stage is to migrate a subset of users to XenDesktop 5 virtual desktops in the production environment, as follows: 1. 2. 3. Identify the set of users that should be migrated. Ideally this should be an existing user group. For assigned desktops (Engineering users), upgrade the desktops to the XenDesktop 5 version of the Virtual Desktop Agent. For pooled desktops (Sales users), there are three options: All Sales users continue to share a single golden disk image, provided by Provisioning services: 1. Upgrade this disk image to the XenDesktop 5 version of the Virtual Desktop Agent. 2. Identify how many pooled desktops should be available to trial users, and migrate that number of computer accounts for that pool into a separate Organizational Unit (OU).

The trial Sales users use a different disk image, provided by Provisioning services: 1. Create a new golden disk image using Provisioning services and deploy the XenDesktop 5 version of the Virtual Desktop Agent. 2. Create the desired number of VMs and configure them to use Provisioning services. The trial Sales users use a different disk image, managed by Machine Creation Services: 1. Upgrade XenServer to the version shipping with XenDesktop 5. 2. 4. 5. 6. Create a new golden VM and deploy the XenDesktop 5 version of the Virtual Desktop Agent.

In XenDesktop 4, put the desktops that you are going to migrate into maintenance mode. Install XenDesktop 5 on one or more controllers and create a site. Use the migration tool to export data and settings from the XenDesktop 4 farm, then edit the XML file and import the relevant subset of policies, desktop group definitions, and user-to-desktop mappings for the trial users into the XenDesktop 5 site. Important: Citrix recommends that any import operations are performed during a scheduled maintenance period to minimize any impact to users and administrators using the XenDesktop 5 site. Import operations involving a large number of policies can take several hours to complete.

7.

Modify the trial virtual desktops to register with the XenDesktop 5 controller instead of with the XenDesktop 4 desktop delivery controller: For private desktops, modify their registry to use registry-based controller discovery and point them to the new XenDesktop 5 controllers. You can use farm OU-based discovery, but registry-based controller discovery is the default method in XenDesktop 5. For shared desktops using the first option in step 3, configure them through group policy (using the new OU) to use registry-based controller discovery and point them to the new XenDesktop 5 controllers. Any failure in rollout of group policy to individual machines and therefore registration can be seen in Desktop Studio or in the SDK.

8.

Configure Web Interface to aggregate the XenDesktop 4 farm and the XenDesktop 5 site: If partitioned user groups, as suggested in step 1, are available, then configure Web Interface to use the XenDesktop 4 farm for non-trial users, and the XenDesktop 5 site for trial users, using the Web Interface user roaming feature. If partitioned user groups are not available, remove the trial users from the desktop groups in the XenDesktop 4 desktop delivery controller to prevent multiple resources being shown to the users.

This diagram shows the resulting deployment:

If problems arise, you can rollback as follows: 1. 2. 3. In XenDesktop 5, put the desktops into maintenance mode. For private desktops, configure them to register with the XenDesktop 4 desktop delivery controllers. For shared desktops using the same golden disk image from Provisioning services, configure the GPO for the separate OU containing the computer accounts for the migrated desktops to register with the XenDesktop 4 desktop delivery controllers. In XenDesktop 4, take the desktops out of maintenance mode. In all cases, re-enable publishing for these users in the XenDesktop 4 desktop delivery controllers. Remove the XenDesktop 5 site from the Web Interface configuration.

4. 5. 6.

Stage 3: Final Migration Once users and administrators are satisfied with the XenDesktop 5 deployment, migrate more users as shown in Stage 2. When all users have been migrated, remove the XenDesktop 4 farm from Web Interface, and decommission the servers. 10. Managing XenDesktop 5 Updated: 2010-11-30

The topics in this section support the following tasks: Provisioning virtual desktops through the use of catalogs Allocating desktops to users through the use of desktop groups Maintaining catalogs, desktop groups, and individual desktops Managing your controller environment Configuring hosts Using smart cards Working with policies

10.1. Creating and Provisioning Desktops Updated: 2010-10-16 These topics explain how to prepare and manage the machines to which users connect. In XenDesktop, collections of virtual machines (VMs) or physical computers are managed as a single entity called a catalog. To deliver desktops to users, the machine administrator creates a catalog of machines and the assignment administrator allocates machines from the catalog to users by creating desktop groups. For more information about desktop groups, see Allocating and Managing Desktops. A catalog is a collection of machines of the same type. The machine type specifies the hosting infrastructure used for desktops, that is, VMs or physical computers plus associated storage. The choice of machine type affects the level of control that users have over their desktop environment and the usage scenarios for which the desktops are best suited. The type and amount of infrastructure available to host each desktop is also an important consideration. 10.1.1. Creating Machine Catalogs Updated: 2010-11-09 To create a catalog, complete the following steps:

Choose the machine type. The type of hosting infrastructure used for user desktops (VMs and physical computers) and the level of control that users have over their desktop environment are determined by the machine type. Users often want to personalize VM-hosted desktops according to their needs, for example by setting preferences or installing particular applications, so XenDesktop provides two different approaches to managing user customizations. You can choose to keep users' customizations temporarily on a per-session basis so that when users log off, their changes are discarded and they start with a fresh desktop when they next log on. This offers the advantage that you only need to work with a single VM to apply system-wide changes to thousands of users' desktops, such as applying Windows updates or adding a new application. Alternatively, you can allow users to take ownership of their desktops and make permanent changes to them. In this scenario, you manage VM-hosted desktops individually, in the same way that you currently manage physical computers.

Prepare the infrastructure. After identifying the machine type that best suits your users' needs, ensure that you have the appropriate hardware in place. Depending on the machine type you select, this could be VM hosts and storage, preprepared VMs, physical computers, or device collections (groups of Provisioning services target devices).

Prepare a master VM. Some machine types require a master VM that can be used to create user desktops. The master VM should contain those elements that will be common to all users, such as antivirus software, Citrix plug-ins, and other default programs. When a master VM is employed, all users start with desktops that are created from the master VM. Depending on the machine type you select, any user customizations and system updates made to the desktops can either be persisted or discarded when users log off. If you are using Provisioning services, you install the default programs on a master target device (either

a VM or a physical computer) and image the vDisk from this target device.

Provide Active Directory accounts. As with physical computers, each machine you create needs a corresponding computer account in Active Directory. For some machine types, you can allow XenDesktop to create new accounts as required if you have access to an Active Directory domain administrator account. Otherwise, ensure that there are sufficient unused computer accounts available in Active Directory for the number of machines you require before you create the catalog. If you are using Provisioning services, you manage Active Directory computer accounts for target devices using Provisioning services and existing Active Directory tools. Create the catalog. Once the necessary prerequisites are in place, use the Create Catalog task to combine all the elements into a catalog.

10.1.1.1. Choosing the Machine Type Updated: 2010-11-09 The machine type defines the type of hosting infrastructure used for desktops and the level of control that users have over their desktop environment. This determines the usage scenarios for which the desktops are best suited. When deciding which machine type to use, consider the tasks that users will perform with their desktops and the devices to which the desktops will be delivered. The type and amount of infrastructure available to host each desktop is also an important consideration. XenDesktop offers the following machine types: Pooled Pooled machines provide desktops that are allocated to users on a per-session, first-come first-served basis. Pooled-random machines are arbitrarily assigned to users at each logon and returned to the pool when they log off. Machines returned to the pool are available for other users to connect to. Alternatively, with pooled-static machines, users are assigned a specific machine from the pool when they first log on to XenDesktop. Users are connected to the same machines for all subsequent sessions. This allows users of pooled-static machines to be associated with specific VMs, which is a licensing requirement for some applications. Pooled desktops are freshly created from the master VM when users log on, although profile management can be used to apply users' personal settings to their desktops and applications. Any changes that users make to their desktops are stored for the duration of the session, but are discarded when users log off. Maintaining a single master VM in the data center dramatically reduces the time and effort required to update and upgrade users' desktops. Your users: Are task workers who require standardized desktops, such as call center operators and retail workers Use shared workstations, for example students and faculty in educational institutions Do not need to or are not permitted to install applications on their desktops You want to: Optimize hardware usage by providing only the number of desktops that are required at any one time rather than assigning each user a specific desktop Maintain control over desktops and increase security by preventing users from making permanent changes Minimize desktop management costs by providing a locked-down standardized environment for your users Dedicated Dedicated machines provide desktops that are assigned to individual users. Machines can be assigned manually or automatically assigned to the first user to connect to them. Whenever users request a desktop, they are always connected to the same machine, so you can allow users to personalize their desktops to suit their needs. Dedicated desktops are created from the master VM the first time that users log on, but all subsequent changes made to the desktops are persisted. As with traditional local desktops, changes and updates are permanent and must be managed on an individual basis or collectively using third-

party electronic software distribution (ESD) tools. Changes made to desktops are stored in difference disks that expand as required, so storage space is used only as it is needed. Your users: Are task or knowledge workers who require personalized desktops of which they can take ownership Are mobile workers who want to access the same desktop from a variety of devices over different networks Need to install their own applications on their desktops You want to: Standardize certain aspects of users' desktops through the use of a common template Deliver users' desktops to any device regardless of hardware capability Reduce desktop management costs while still providing your users with a personalized desktop experience Existing The existing machine type enables you to use XenDesktop to manage and deliver user desktops that you have already migrated to VMs in the data center. As with traditional local desktops, changes and updates are permanent and must be managed on an individual basis or collectively using third-party electronic software distribution (ESD) tools. Managing your existing VM-based desktops through XenDesktop affords you greater control over their power states; for example, you can configure XenDesktop to shut down VMs when users log off to minimize unnecessary power consumption in the data center. Your users: Already have VM-hosted desktops Have a large number of different and conflicting requirements for their desktops such that it is more efficient for you to prepare a bespoke desktop for each user than to create a common template that meets the needs of all users Need to install their own applications on their desktops You want to: Use XenDesktop to manage and deliver existing desktops hosted on VMs in the data center Deliver individually tailored desktops to a small but heterogenous group of users Reduce support costs by centralizing user desktops in the data center without moving to a virtual desktop solution Physical The physical machine type enables you to use XenDesktop to manage user desktops hosted on dedicated blade PCs in the data center. As with traditional local desktops, changes and updates are permanent and must be managed on an individual basis or collectively using third-party ESD tools. Using blade PCs enables you to support small numbers of users who have particularly demanding performance requirements. This approach offers all the benefits of centralization, but ensures dedicated processing power for each user by hosting only one desktop per server. Your users: Are technical workers or power users Use processor-intensive applications, such as financial modeling software Have high performance level expectations for line of business applications You want to: Use XenDesktop to manage and deliver user environments that require dedicated specialist hardware Deploy dedicated hardware for power users so that they do not have to share server resources with other users Reduce support costs by centralizing complicated specialist systems in the data center

Streamed The streamed machine type enables you to deliver desktops to VMs and blade PCs that have been configured to load the operating system over the network from Provisioning services. Target devices are managed in Provisioning services as a device collection and the desktops are delivered from a Provisioning services vDisk imaged from a master target device. Using Provisioning services to deliver desktops enables you to leverage the processing power of existing hardware, while realizing all the benefits of centralized desktop management. This approach offers an entry point to desktop virtualization using existing resources and reducing the need for additional storage capacity in the data center. Your users: Are task or knowledge workers who require either standardized desktops or individual desktops of which they can take ownership Use shared workstations, for example students and faculty in educational institutions Use locked-down workstations to access secure data, for example government employees You want to: Deliver desktops to device collections containing mixtures of different types of PC hardware Maximize data security by delivering desktops to diskless target devices Virtualize desktops using existing hardware and without adding more storage in the data center

10.1.1.2. Preparing a Master VM Updated: 2011-05-06 To deliver desktops from pooled or dedicated machines, you must prepare the master VM that is used to create user desktops. In the case of streamed machines, you prepare a master target device from which to image the vDisk in Provisioning services. 1. If you plan to create pooled or dedicated machines, use the management tool for your hypervisor to create a new VM and install the operating system (including all service packs and updates). Provided they are sufficient to allow the VM to run, the number of vCPUs and the amount of memory you assign to the master VM are not critical at this stage because you can change these settings when you create the catalog. However, you should ensure that you set up the master VM with the same amount of hard disk space that is required for users' desktops because this value cannot be changed subsequently. Ensure that the hard disk for the master VM is attached at device location 0. Most standard VM templates configure this location by default, but some custom templates may not do so. In the case of streamed machines, you can use either a VM or a physical computer as your master target device. For more information about preparing a master target device, see the Provisioning Services Installation and Configuration Guide. 2. Install on the VM the appropriate integration tools for your hypervisor (XenServer Tools, HyperV Integration Services, or VMware Tools). Note: If you do not install hypervisor integration tools on the master VM, your desktops may not function correctly. On Windows XP VMs, install the Microsoft Windows Management Core. This package includes Windows Remote Management 2.0, which is required to support Desktop Director. Windows Remote Management 2.0 is included by default with Windows 7 and Windows Vista. 3. Install the Virtual Desktop Agent from the XenDesktop installation media. When installing the Virtual Desktop Agent, select the option to optimize the desktop. This improves the performance of

users' desktops by reconfiguring various Windows features that are incompatible with or unnecessary for virtual desktops. Optionally, select the option to install Citrix plug-ins so that users can access XenApp virtualized applications from their desktops. 4. Install any third-party tools that you want to run on users' desktops, such as antivirus software or electronic software distribution agents, and configure services such as Windows Update, as required for your deployment. Ensure that you use settings appropriate for your users and the machine type you intend to use, as these configurations will be propagated to users' desktops from the master VM. 5. Install and configure any third-party applications that you do not want to virtualize. Citrix recommends virtualizing applications and delivering them to users' desktops with XenApp. This approach significantly reduces desktop management costs by removing the need to update the master VM whenever you want to add or reconfigure an application on users' desktops. In addition, with less applications installed on each desktop, you can reduce the size of the VM hard disks to save on storage costs. 6. If you plan to deliver desktops from pooled and dedicated machines, join the VM to the domain of which you want users' desktops to be members and ensure that the master VM is available on the host where you want to create the machines. In the case of streamed machines, image a vDisk from your master target device before you join the master target device to a domain. For more information about imaging a vDisk, see the Provisioning Services Installation and Configuration Guide. If you plan to deliver desktops from pooled and dedicated machines, Citrix recommends that you create a snapshot of your master VM and name the snapshot in a way that allows you to identify the master VM in the future. If you specify a VM rather than a snapshot when creating a pooled or dedicated machine catalog, Desktop Studio will create a snapshot for you but you will not be able to name it. 10.1.1.3. Providing Active Directory Computer Accounts Updated: 2010-10-26 Each machine you create needs a corresponding Active Directory computer account. If you plan to create pooled or dedicated machines and you have access to an Active Directory domain administrator account, you can allow XenDesktop to create new accounts when you create the catalog. If you do not have the necessary permissions, ensure that you have a sufficient number of unused Active Directory computer accounts available for the machines you plan to create before you start the Create Catalog task. You can select the existing computer accounts to use by browsing Active Directory when you create the catalog or, alternatively, you can import a .csv file containing a list of account names. XenDesktop requires the following format for computer accounts imported from .csv files.

[ADComputerAccount] ADcomputeraccountname.domain ...

For existing and physical machine types, you select or import existing accounts and assign each VM or physical machine to both an Active Directory computer account and a user account. In the case of streamed machines, Active Directory computer accounts for target devices are managed using Provisioning services and existing Active Directory tools. For more information about Active Directory integration with Provisioning services, see the Provisioning Services Administrator's Guide. 10.1.1.4. To create a new machine catalog Updated: 2011-05-06

Before you start the Create Catalog task, ensure that you have all the necessary prerequisites in place for the particular machine type you intend to use. To create a pooled or dedicated machine catalog To create pooled or dedicated machines, you need: A host with sufficient processors, memory, and storage to accommodate the number of machines you plan to create. A master VM from which to create the desktops. The master VM must be available on the host where the machines will be created. Either a sufficient number of unused Active Directory computer accounts for the machines you plan to create or access to an Active Directory domain administrator account for the domain of which you want the desktops to be members. 1. Log on to the computer running Desktop Studio. If you plan to use XenDesktop to create new Active Directory computer accounts for the machines, log on using a domain administrator account for the domain to which you plan to add the desktops. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. Select the Machines node in the left pane of Desktop Studio and click Create Catalog. If this is the first catalog you have created, note that the Machines node is not visible until you have completed one of the initial configuration tasks presented when you first start Desktop Studio. 4. 5. On the Machine Type page, select Pooled or Dedicated, as required. For the pooled machine type only, select Random - users are randomly assigned a machine at logon if you want to maintain a pool of machines that are arbitrarily allocated to users when they log on and returned to the pool when they log off. Alternatively, if you want machines to be assigned to individual users, select Static - users are assigned the same machine at logon. Click Next. Pooled-random machines are kept in a pool and are temporarily and randomly assigned to users as they log on. When users log off, pooled-random machines are returned to the pool and become available for other users. Pooled-static machines are assigned to the first user to connect to them. Users are then connected to the same machine for all subsequent sessions. In the case of the dedicated machine type, all machines are individually assigned to users. 6. On the Master Image page, select the host and master VM that you want to use to provision your desktops and click Next. Citrix recommends that you create an appropriately named snapshot of your master VM and use this to provision your desktops. If you specify a VM rather than a snapshot, Desktop Studio will create a snapshot for you but you will not be able to name it. The machines are created on the virtualization infrastructure hosting the master VM, so ensure that this host has sufficient processors, memory, and storage to accommodate the number of machines you plan to create. 7. On the Number of VMs page, specify the number of machines you want to create and allocate virtual processors and memory to the VMs. By default, machines are created with the same number of virtual processors and amount of memory as specified for the master VM. However, you cannot change the size of the hard diskthis setting is determined by the hard disk size of the master VM. Ensure that the host has sufficient processors and memory for the specifications of your machines. For more information about the efficient use of hosts with XenDesktop, see the XenDesktop Scalability Guidelines. 8. If you want XenDesktop to create new Active Directory computer accounts for the machines, select Create new accounts. If the Active Directory administrator has already created some computer accounts for you to use, select Use existing accounts. Click Next. To create new computer accounts, you must be logged on using an Active Directory domain administrator account. If you are using existing computer accounts, note that the number of machines you can create is limited by the number of accounts that are available. 9. On the Create accounts or Import accounts page, provide the required information and click Next.

2. 3.

9. To create new computer accounts, specify the Active Directory domain and organizational unit to which the accounts will be added. In addition, specify a naming scheme to be used to name the new accounts. To use existing accounts, click Browse and select computer accounts in Active Directory or click Import and specify a .csv file containing a list of account names. As XenDesktop will manage these accounts, either allow XenDesktop to reset the passwords for all the accounts or supply the account password (which must be the same for all accounts). Ensure that you import enough accounts for the number of machines you want to create. 10. On the Administrators page, select the assignment administrators who have permissions to use the catalog when allocating desktops to users and, optionally, include a description of the catalog. Click Next. The catalog description is seen only by the administrators that you assign to the catalog and not by users of desktops allocated from the catalog. 11. On the Summary page, check that the details are correct and specify a name for the new catalog. The catalog name is seen by users of desktops allocated from the catalog. Click Finish to start creating the machines. To enable you to continue working with Desktop Studio, machine creation is carried out as a background process. This is because XenDesktop creates VMs sequentially, which can be a lengthy process for catalogs containing a large number of machines. Machine creation will continue to completion even if you close Desktop Studio. You have now created a catalog of machines. To deliver desktops from the machines in your catalog to users, the assignment administrator must allocate the machines to users by creating desktop groups. For more information, see To create a desktop group. To create an existing or physical machine catalog To use existing or physical machines, you need: VMs or dedicated blade PCs hosting user desktops that you have already migrated to the data center. Active Directory user and computer accounts to assign to the VMs or blade PCs. 1. 2. Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. Select the Machines node in the left pane of Desktop Studio and click Create Catalog. If this is the first catalog you have created, note that the Machines node is not visible until you have completed one of the initial configuration tasks presented when you first start Desktop Studio. 3. 4. On the Machine Type page, select Existing or Physical, as required, and click Next. On the VMs & users or Machines & users page, assign Active Directory computer and user accounts to VMs or assign users to computer accounts that you have already paired with blade PCs, respectively. Click Next. For the existing machine type, click Add VMs and select VMs from one of the configured hosts. Alternatively, click Import list and specify a .csv file containing a list of VM names and host locations plus, optionally, the computer and user accounts assigned to the VMs. For each VM that you add or import, select in Active Directory a computer account and one or more user accounts. For the physical machine type, click Add Computers and select in Active Directory existing computer accounts that you have already assigned to a blade PC. Alternatively, click Import list and specify a .csv file containing a list of computer accounts and, optionally, the user accounts assigned to those computer accounts. For each computer account that you add or import, select in Active Directory one or more user accounts. 5. On the Administrators page, select the assignment administrators who have permissions to use the catalog when allocating desktops to users and, optionally, include a description of the catalog. Click Next. The catalog description is seen only by the administrators that you assign to the catalog and not by users of desktops allocated from the catalog. 6.

6.

On the Summary page, check that the details are correct and specify a name for the new catalog. The catalog name is seen by users of desktops allocated from the catalog. Click Finish.

You have now created a catalog of machines. To deliver desktops from the machines in your catalog to users, the assignment administrator must allocate the machines to users by creating desktop groups. For more information, see To create a desktop group. To create a streamed machine catalog To use streamed machines, you need: A Provisioning services deployment with a vDisk that you have imaged from the master target device. Device collections configured to load the vDisk over the network. Active Directory computer accounts managed by Provisioning services for each target device in the device collections.

Note: In XenDesktop 4, the separate XenDesktop Setup Wizard automated the creation of streamed machines. For XenDesktop 5, this functionality is available in the Provisioning Services Console. Install the latest hotfixes for Citrix Provisioning Services 5.6 Service Pack 1 to add this capability to your XenDesktop 5 deployment. For more information, see http://support.citrix.com/article/CTX128726. 1. 2. Log on to the computer running Desktop Studio using a Provisioning services administrator account. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. Select the Machines node in the left pane of Desktop Studio and click Create Catalog. If this is the first catalog you have created, note that the Machines node is not visible until you have completed one of the initial configuration tasks presented when you first start Desktop Studio. 3. On the Machine Type page, select Streamed, specify the IP address of the Provisioning services server providing the vDisk, the Active Directory domain containing the device collections, and indicate whether the target devices are VMs or physical computers. Click Next. Note: To use the fully qualified domain name of the Provisioning services server, run the Stream Service under a domain administrator account for the domain of which the Provisioning services server is a member. 4. 5. On the Device collection page, specify the device collections to include in the catalog and click Next. On the Administrators page, select the assignment administrators who have permissions to use the catalog when allocating desktops to users and, optionally, include a description of the catalog. Click Next. The catalog description is seen only by the administrators that you assign to the catalog and not by users of desktops allocated from the catalog. 6. On the Summary page, check that the details are correct and specify a name for the new catalog. The catalog name is seen by users of desktops allocated from the catalog. Click Finish.

You have now created a catalog of machines. To deliver desktops from the machines in your catalog to users, the assignment administrator must allocate the machines to users by creating desktop groups. For more information, see To create a desktop group. 10.1.2. Managing Machine Catalogs Updated: 2010-11-30 Once you have created a catalog, you may need to:

Update user desktops. For pooled machine catalogs, you maintain users' desktops by applying global updates, such as Windows updates, antivirus software updates, or configuration changes, to the master VM. Then, you modify the catalog to use the updated master VM so that users receive

the updated desktop the next time they log on. This approach enables you to make significant changes to users' desktops, including upgrading to a new operating system, for large numbers of users in a matter of minutes. Citrix recommends that you save copies or snapshots of master VMs before you make any updates. The XenDesktop database retains a historical record of the master VMs used with each catalog. Provided you do not delete, move, or rename the old master VMs, you can quickly revert a catalog to use the previous version of the master VM should users encounter problems with updates that you have deployed to their desktops, thereby minimizing user downtime. For dedicated, existing, and physical machine catalogs, updates to users' desktops must be managed outside of XenDesktop, either on an individual basis or collectively using third-party electronic software distribution tools. In the case of streamed machine catalogs, updates to users' desktops are propagated through the vDisk, which is managed in Provisioning services. Add more machines. You can deploy additional machines for new users from an existing catalog. For pooled and dedicated machine catalogs, this involves creating more machines and, if required, more Active Directory computer accounts using XenDesktop. In the case of existing and physical machine catalogs, you must set up additional VMs or blade PCs, respectively, plus any computer accounts that are required, outside of XenDesktop. You can then add these machines and/or accounts to the catalog. For streamed machine catalogs, you can add more machines by joining more target devices to an existing device collection using Provisioning services. Alternatively, create additional device collections in Provisioning services and then add the new collections to the existing catalog. Modify the catalog. You can rename existing catalogs, add or remove administrators from the list of assignment administrators permitted to use the catalog, edit the catalog description, and quickly view the details and status of all the machines included in the catalog. In addition, for pooled and dedicated machine catalogs, you can add or remove Active Directory computer accounts from the catalog. This allows you to free up unused accounts for use in other catalogs or to attach additional accounts to a catalog for use when more machines are added. Delete the catalog. When you delete a catalog, the machines and the associated Active Directory computer accounts are removed from management by XenDesktop. For pooled and dedicated machine catalogs, you can optionally delete the machines and computer accounts from the host and from Active Directory, respectively.

10.1.2.1. Updating User Desktops Updated: 2011-05-06 To apply changes to all the desktops allocated from a pooled machine catalog, you update the master VM. Managing the common aspects of users' desktops through a single master VM enables you to deploy system-wide changes, such as applying Windows updates or making configuration changes, to a large number of desktops very quickly. Major infrastructure upgrades, such as migrating users to a new operating system, are reduced from projects lasting weeks or months to simple tasks that take a few minutes. Should any issues arise with updated desktops that you have deployed, reverting to the previous master VM is just as straightforward. This enables you to provide users with continuous access to their desktops so that they can continue working while the problems with the update are addressed. To update the master VM Once you have prepared and tested a new or updated master VM, modify the pooled machine catalog to use the new master VM. Desktops are updated with the new master VM the next time users log off. Citrix recommends that you create an appropriately named snapshot before you modify an existing master VM that is being used to provide desktops to users. The XenDesktop database retains a historical record of the master VMs used with each catalog. Provided you do not delete, move, or rename the old master VMs (including any snapshots in the chains leading to the master VMs), you can quickly revert a catalog to use the previous version of the master VM should users encounter problems with updates that you have made. 1. 2. Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Update machine.

3.

3. 4.

On the Overview page, click Next. On the Master Image page, select the host and the new or updated master VM that you want to use. Click Next. Citrix recommends that you create an appropriately named snapshot of your new or updated master VM and use this to update your desktops. If you specify a VM rather than a snapshot, Desktop Studio will create a snapshot for you but you will not be able to name it.

5.

On the Strategy page, specify how the new or updated master VM will be applied to users' desktops and click Next. If you are deploying a non-urgent update and you want to minimize disruption to users, select None . The update is applied only when users next log off. If you are deploying a non-urgent update and you want to inform users, select Send message and enter a message. Users see the specified message and the update is applied only when they next log off. If you are deploying a critical update and you want to apply it to all users' desktops urgently, select Restart immediately. All users are automatically logged off and their desktops restarted. If you are deploying an urgent update and you want to allow users some time to save their work before upgrading their desktops, select Send message then restart after delay. Enter a message and specify the time delay before applying the update. The timer starts only when Desktop Studio finishes making a temporary copy of the new or updated master VM in the appropriate location. Users see the specified message and the update is applied when they next log off or, if the specified time limit is reached, users are automatically logged off and their desktops restarted.

6.

On the Summary page, check that the details are correct and click Finish.

To revert to the previous version of the master VM A historical record of the master VMs used with each pooled machine catalog is stored in the XenDesktop database. This enables you quickly to revert a catalog to use the previous version of the master VM should users encounter problems with updates that you have made. Desktops revert to the previous master VM the next time users log off. If you delete, move, or rename any old master VMs, including any snapshots in the chains leading to the master VMs, you will not be able to revert the catalog to use them. When XenDesktop is unable to locate the previous master VM, you are given the option to browse for an alternative master VM from which to update the desktops. 1. 2. 3. 4. Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Rollback machine update. On the Overview page, click Next. On the Strategy page, specify how the reverted master VM will be applied to users' desktops and click Next. If reverting users' desktops is not urgent and you want to minimize disruption to users, select None . Users' desktops are reverted only when they next log off. If reverting users' desktops is not urgent and you want to inform users, select Send message and enter a message. Users see the specified message and their desktops are reverted only when they next log off. If reverting users' desktops is critical and you want to revert all users' desktops urgently, select Restart immediately. All users are automatically logged off and their desktops restarted. If reverting users' desktops is urgent and you want to allow users some time to save their work before reverting their desktops, select Send message then restart after delay. Enter a message and specify the time delay before reverting the desktops. The timer starts only when Desktop Studio finishes making a temporary copy of the reverted master VM in the appropriate location. Users see the specified message and their desktops are reverted when they next log off or, if the specified time limit is reached, users are automatically logged off and their desktops restarted.

The rollback strategy is only applied to desktops that need to be reverted. Users of desktops that have not been updated with the problematic master VM that prompted the rollback, for example because the user has not logged off, do not receive any messages and are not forced to log off. 5. On the Summary page, check that the details are correct and click Finish.

10.1.2.2. Adding More Machines to a Catalog Updated: 2011-03-14 Once you have created a catalog, you can deploy additional desktops for new users from that catalog. To add more machines to a pooled or dedicated machine catalog To add more machines to a pooled or dedicated machine catalog, you need: To ensure that the virtualization infrastructure hosting the master VM specified for the catalog has sufficient processors, memory, and storage to accommodate the additional machines you plan to create Either a sufficient number of unused Active Directory computer accounts for the additional machines you plan to create or access to an Active Directory domain administrator account for the domain of which the desktops will be members 1. Log on to the computer running Desktop Studio. If you plan to use XenDesktop to create Active Directory computer accounts for the additional machines, log on using a domain administrator account for the domain of which the desktops will be members. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Add machines. On the Add VMs page, specify the number of additional machines you want to create. If more Active Directory computer accounts are required and you want XenDesktop to create new accounts for the machines, select Create new accounts. If the Active Directory administrator has already created some computer accounts for you to use, select Import accounts. Click Next. To create new computer accounts, you must be logged on using an Active Directory domain administrator account. If you are using existing computer accounts, note that the number of machines you can create is limited by the number of accounts that are available. 5. On the Create accounts or Import accounts page, provide the required information and click Next. To create new computer accounts, specify the Active Directory domain and organizational unit to which the accounts will be added. In addition, specify a naming scheme to be used to name the new accounts. To use existing accounts, click Browse and select computer accounts in Active Directory or click Import and specify a .csv file containing a list of account names. As XenDesktop will manage these accounts, either allow XenDesktop to reset the passwords for all the accounts or supply the account password (which must be the same for all accounts). Ensure that you import enough accounts for the additional machines you want to create. 6. On the Summary page, check that the details are correct and click Finish to start creating the additional machines. To enable you to continue working with Desktop Studio, machine creation is carried out as a background process. This is because XenDesktop creates VMs sequentially, which can be a lengthy process when you add a large number of machines to a catalog. Machine creation will continue to completion even if you close Desktop Studio.

2. 3. 4.

To add more machines to an existing or physical machine catalog To add more VMs or blade PCs to an existing or physical machine catalog, you need: Additional VMs or dedicated blade PCs hosting user desktops Active Directory user and computer accounts to assign to the additional VMs or blade PCs

1. 2. 3.

Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Add machines. On the VMs & users or Machines & users page, assign Active Directory computer and user accounts to VMs or assign users to computer accounts that you have already paired with VMs or blade PCs, respectively. Click Next. For the existing machine type, click Add VMs and select VMs from the host associated with the catalog. Alternatively, click Import list and specify a .csv file containing a list of VM names and host locations plus, optionally, the computer and user accounts assigned to the VMs. For each VM that you add or import, select in Active Directory a computer account and one or more user accounts. For the physical machine type, click Add Computers and select in Active Directory existing computer accounts that you have already assigned to a blade PC. Alternatively, click Import list and specify a .csv file containing a list of computer accounts and, optionally, the user accounts assigned to those computer accounts. For each computer account that you add or import, select in Active Directory one or more user accounts.

4.

On the Summary page, check that the details are correct and click Finish.

To add more machines to a streamed machine catalog To add device collections to a streamed machine catalog, you need: Additional device collections configured to use the same vDisk as the existing device collections in the catalog Active Directory computer accounts managed by Provisioning services for each target device in the additional device collections

Note: In XenDesktop 4, the separate XenDesktop Setup Wizard automated the creation of streamed machines. For XenDesktop 5, this functionality is available in the Provisioning Services Console. Install the latest hotfixes for Citrix Provisioning Services 5.6 Service Pack 1 to add this capability to your XenDesktop 5 deployment. For more information, see http://support.citrix.com/article/CTX128726. 1. 2. 3. 4. Log on to the computer running Desktop Studio using a Provisioning services administrator account. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Add machines. On the Device collection page, specify the additional device collections to add to the catalog and click Next. On the Summary page, check that the details are correct and click Finish.

10.1.2.3. To manage Active Directory computer accounts Updated: 2010-10-16 You can remove Active Directory computer accounts from pooled and dedicated machine catalogs to free up unused accounts for use in other catalogs. Similarly, you can attach additional accounts to a catalog so that when more machines are added to this catalog, the computer accounts are already in place. 1. 2. Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Manage AD accounts. A list of Active Directory computer accounts associated with the catalog is displayed. To make the list easier to manage, you can filter the accounts according to their current states. To use computer accounts with passwords that are shown as unknown to XenDesktop, either allow XenDesktop to reset the passwords or supply the password (which must be the same for all accounts if more than one account is selected). To do this, select accounts from the list and click Reset.

To remove accounts from the catalog and from management by XenDesktop, select accounts from the list and click Remove. Optionally, you can choose to disable or delete these accounts in Active Directory. To add more accounts to the catalog, click Add and select computer accounts in Active Directory. As XenDesktop will manage these accounts, either allow XenDesktop to reset the passwords for all the accounts or supply the account password (which must be the same for all accounts). 10.1.2.4. To delete a machine catalog Updated: 2010-10-16 Any assignment administrator who has permissions to use a catalog when allocating desktops to users can delete that catalog. Before deleting a catalog, ensure that: All users have logged off from the machines in the catalog No disconnected user sessions are still running For pooled and dedicated machine catalogs, all machines are in maintenance mode For existing machine catalogs, all machines are powered off 1. 2. 3. Log on to the computer running Desktop Studio. On the Windows Start menu, click All Programs > Citrix > Desktop Studio. In the left pane of Desktop Studio, click Machines, select your catalog in the results pane, and click Delete Catalog. For pooled and dedicated machine catalogs only, specify whether or not the machines hosting users' desktops should be deleted. If you decide to delete the machines, the associated Active Directory computer accounts are removed from management by XenDesktop. Optionally, you can the choose to disable or delete these accounts in Active Directory. Click Next. On the Summary page, check that the details are correct and click Finish.

4.

10.2. Allocating and Managing Desktops Updated: 2010-10-04 These topics explain how to create and use desktop groups to allocate desktops to users quickly and easily. How to create desktop groups from catalogs and how to manage desktop group properties are explained. Examples of typical desktop groups are also provided. Once the desktops are in use, Desktop Studio allows you to perform management tasks such as disconnecting sessions and logging off users, as well as modifying desktop and desktop group properties. 10.2.1. About Desktop Groups Updated: 2010-11-18 Important: Before you allocate and manage virtual desktops, read this topic, which contains important background information. In addition, because all desktop groups are based on catalogs, understand the characteristics of the different machine types in the catalogs you will be using. Desktop groups are sets of virtual machines allocated to users and user groups. Full and assignment administrators can create desktop groups from the catalogs previously generated using the Create Catalog wizard. Desktop groups are listed in Desktop Studio under the Assignments node. In addition to the total number of machines in each group, the number of available and in-use machines is shown; the number of unavailable and offline machines is not shown. Creating a desktop group is a flexible way of allocating machines to users. In a desktop group: You can use multiple catalogs You can allocate a user to multiple machines You can allocate multiple users to one machine You can, using the XenDesktop SDK, allocate a machine to a device instead of a user or group

You create desktop groups from catalogs. As part of the creation process, you specify the following desktop group properties: Users and groups allocated to desktop groups Desktop settings to match users' needs Desktop power management options For a set of typical business scenarios in which desktop groups are created, see Examples of Desktop Groups. You can power manage the machines in a desktop group so they suspend, disconnect, or shutdown automatically when they are not in use. Depending on the machine type in the catalog, you create the following desktop group types: Shared groups are created from pooled-random and streamed machines. Private groups are created from other machines.

Note: Using the XenDesktop Software Development Kit (SDK), you can create shared groups from other machine types. For example, existing and physical machines can be used for this purpose. In addition, application desktop groups, which can be shared or private, allow you to publish applications on machines using Citrix XenApp. For information on this, see VM Hosted Apps. The desktop group type is a summary of the underlying machine type used by the catalog or catalogs in the group. It describes the most important characteristic of the catalog; whether the machines in it are available to multiple users or devices (shared desktop groups) or whether they are tied to one user or device (private desktop groups). When creating desktop groups, you can nominate specific help desk administrators to support the users of the desktops you create. For example, you might delegate support to different help desk staff based on geographical location. When planning your desktop groups, you must identify the correct catalog to use. This may be created specifically for you by a machine administrator or you may choose an appropriate catalog from those available to you. In either case, confirm that the catalog contains enough machines for the number of desktops you want to create. 10.2.1.1. Examples of Desktop Groups Updated: 2010-10-04 Single Catalog, Single Desktop Group Your organization includes a sales team of 10 staff who require access to their own, customizable desktops. Your IT department is small so you are responsible both for creating virtual machine images, and distributing and maintaining the desktops created from them. A suitable catalog containing 50 dedicated machines exists, so you create a desktop group based on that catalog and consume 10 machines from it, allocating each member of the sales team their own machine while creating the desktop group. This leaves 40 machines in the catalog available for use in future desktop groups. Single Catalog, Multiple Desktop Groups You work in a large organization where, as one of several assignment administrators, you are responsible for distributing and maintaining desktops. A colleague, the machine administrator, is responsible for creating virtual machine images. Your company acquires another, and 200 new desktops need commissioning for the acquisition. You request these from the machine administrator, who uses one of their standard images to create the machines and then packages these into a suitable catalog, granting you (but not other assignment administrators) access to it as part of this process. You create three desktop groups, which grant access to one desktop each for:

20 executives 80 marketing staff 100 sales staff Alternatively, instead of these three role-based desktop groups, you might want to base the groups on how desktops are used and supported; sales and marketing staff need the same standard desktop and are supported by a large IT support team. However, executives need desktops they can each customize individually and they have their own, small set of IT support personnel. So you create two desktop groups: One based on a catalog of 180 pooled machines for sales and marketing staff. In this desktop group, you specify the large IT team to act as help desk administrators. One based on a catalog of 20 dedicated machines for executives. In this desktop group, you specify the small set of IT personnel to act as help desk administrators.

10.2.2. To create a desktop group Updated: 2010-11-30 This topic explains how to make sets of machines in catalogs available to users as virtual desktops. For information about publishing applications on machines using Citrix XenApp, see VM Hosted Apps. Before creating a desktop group, understand the different machine types available to you, and note the following: You can only create a desktop group if at least one machine remains unused in the catalog you select You cannot use a machine in more than one desktop group You can create desktop groups from multiple catalogs with the same machine type You cannot create mixed desktop groups from catalogs with multiple machine types 1. 2. In Desktop Studio, select the Assignments node in the left pane and click Create desktop group. On the Catalog page, select a catalog for this desktop group, and enter the number of machines the group will consume from the catalog. Tip: If machine administrators include the total number of machines in a catalog's description, this appears on the Catalog page. Assignment administrators can use the number in conjunction with their selections in the wizard to ensure sufficient machines are available for the desktop group. 3. On the Users page, add the users or user groups that can access the desktops, and enter the number of desktops available to each user. You can select user groups by browsing or entering a list of Active Directory users and groups each separated by a semicolon. For private desktop groups, you can import user data from a file after you create the group. This page is displayed only if the group is based on pooled - static, existing, or physical machines and they have not already been allocated accounts. 4. 5. 6. On the Machine allocation page, confirm the mapping of machines to users for any machines that were allocated when the catalog was created. On the Delegation page, select the XenDesktop administrators who will manage this desktop group. All XenDesktop administrators, including help desk administrators, are displayed. On the Summary page, check all details, and enter a name that users see and a name that administrators see.

10.2.3. To find desktops, sessions, and desktop groups Updated: 2010-10-20 1. 2. 3. In Desktop Studio, click the Search node. Enter the name or part of the name of the desktop you want to find. Optionally, save your search for later use.

Alternatively, use the unfold button to perform an advanced search by building an expression from the available desktop, session, desktop group, or catalog properties. Use the following tips to speed up your search: To locate a user device connected to a virtual desktop, use Endpoint and Is, and enter the device's name, or use Endpoint (IP) and Is, and enter the device's IP address. To locate active sessions, use Session State, Is, and Connected To list all of the machines in a desktop group, select the group (from the Search or Assignments node) and click View machines To display other details in search results, right-click a column heading and select Select columns

10.2.4. To import and export user data Updated: 2010-11-30 For desktop groups based on existing or physical machines, you can, with the correct permission, allocate desktops to users by importing data from a file. This file can contain data from any previous version of XenDesktop or from Desktop Server 1.0. Desktop Server 1.0 data can be used only to update desktop groups based on physical machines. You can also export user data to a file. Import and export 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 for all desktop groups except those based on physical machines. You can find sample files on the XenDesktop installation media in \support\ImportExport. To import data from or export data to a file 1. 2. 3. In Desktop Studio, under Assignments, select the desktop group whose data you want to import or export. Click Edit desktop group.

3.

On the Machine allocation page, click Import list or Export list.

10.2.5. To secure desktop groups Updated: 2010-11-30 You can obfuscate all communications to and from machines in a desktop group using the SecureICA feature, which encrypts the ICA protocol. When traversing public networks, Citrix does not recommend SecureICA as your only method of encryption. Citrix recommends using SSL/TLS encryption for traversing public networks. Unlike SSL/TLS encryption, SecureICA, used on its own, does not provide authentication of the server. Therefore information could be intercepted as it crosses a public network and then be rerouted to a counterfeit server. Also, SecureICA does not check data integrity. By default, XenDesktop disables SecureICA. If you enable it, the default encryption level is 128-bit. You can configure the level using the XenDesktop SDK. 1. 2. 3. In Desktop Studio, select the Assignments node in the left pane, and select the desktop group whose communications you want to secure. Click Edit desktop group. On the End user settings page, select Enable Secure ICA.

10.2.6. To change the display properties of desktops Updated: 2011-01-27 You can change the display properties of all the machines in a desktop group. Depending on the machine type in the catalog used for the group, you can change the desktop name that is displayed in Web Interface and the XenDesktop Viewer, and the color depth of the desktop. 1. 2. 3. In Desktop Studio, select the Assignments node in the left pane and select the desktop group whose properties you want to change. Click Edit desktop group. On the End user settings page, change the desktops' properties as required. If you modify the color depth, note that the graphics driver on the Virtual Desktop Agent handles Alpha (transparency) data in addition to red, green, and blue data. Assuming a suitable Citrix plug-in or client is used that has enough graphics memory to display 32-bit color, sessions are displayed at that color depth even if you select True Color (24 bit) here.

10.2.7. To power manage machines Updated: 2011-04-01 XenDesktop provides full and partial power management of machines in desktop groups. You can power manage virtual machines not physical ones. The ability to fully or partially control power management depends on how virtual machines in the desktop group are allocated to users or user devices. Permanently allocated machines can only be partially power managed. In addition, note that desktops can be in one of these states: In private or shared desktop groups: unallocated (and therefore unconnected) In private desktop groups: Permanently allocated and unconnected (but ready to be connected) Permanently allocated and in use In shared desktop groups: randomly allocated and in use At any given time, private desktop groups typically contain both permanently allocated and unallocated machines. Initially, all the machines are unallocated (apart from any manually allocated to individuals when the desktop group was created). As users connect, some get permanently allocated. So, when you fully

power manage groups of this type, you are in fact only fully managing the unallocated machines in it. The permanently allocated machines are partially managed. Pools and Buffers For shared desktop groups and unallocated machines in private desktop groups , a pool is a set of unallocated (or temporarily allocated) machines in the desktop group that are kept in a powered-on state, ready for users to connect. When a user logs on, they are immediately presented with a desktop. The pool size (the number of machines kept powered on ) is configurable; you'll probably want a bigger pool during office hours. For private desktop groups, there is no pool in Desktop Studio but you can use the XenDesktop SDK to configure one. A buffer is an extra, standby set of unallocated machines that are turned on, ready for users to connect. For shared desktop groups and unallocated machines in private desktop groups , desktops in the buffer are turned on when the number of machines in the pool drops below the threshold set by the buffer size. This is a percentage of the desktop group size (default 10%). For large desktop groups, a significant number of machines may therefore be turned on when the threshold is exceeded, so plan your desktop group sizes accordingly or adjust the default buffer size using the SDK. Power State Timers You can suspend desktops after users have disconnected for a defined time using power state timers. For example, desktops can be made to suspend automatically outside office hours if users have been disconnected for at least 10 minutes. Unless you have configured the ShutdownDesktopsAfterUse property of a desktop group using the SDK, pooled or streamed machines are always automatically shut down when users log off. You can configure the timers separately for weekdays (by default, Monday to Friday) and weekends, and for peak and off-peak periods. The peak period covers the time at which most users log on to their desktops, and starts at the beginning of your business day. Use the SDK if you want to shut down, rather than suspend, desktops in response to power state timers, or if you want the timers to be based on logoffs, rather than disconnections. Also, note that the Weekdays and Weekend selections in this procedure are defaults that can be configured using the SDK. Partial Power Management of Permanently Allocated Machines With machines permanently allocated to individuals or user devices, you can set power state timers but not pools or buffers. XenDesktop turns on the machines at the start of each peak period, and turns them off at the start of each off-peak period, so you have no fine control (as you do with unallocated machines) over the number of machines that become available to compensate for desktops that are consumed. 1. 2. 3. 4. 5. 6. In Desktop Studio , select the Assignments node in the left pane, and select the desktop group whose power management settings you want to control. Click Edit desktop group. On the Power management page, select Weekdays. For shared desktop groups, click Edit and specify the pool size during weekdays. In Peak hours, set your organization's peak and off-peak hours during weekdays. Set power state timers for peak and non-peak hours during weekdays: In When disconnected, specify the delay (in minutes) before suspending any disconnected machine in the desktop group, and select Suspend. In When logged off, specify the delay before turning off any logged-off machine in the desktop group, and select Shutdown. This timer is not available for groups based on pooled machines. 7. 8. Select Weekend. Configure, as above, the pool size, peak hours, and power state timers for weekends.

10.2.8. To restrict access to machines Updated: 2010-11-30 This topic describes how to restrict access to machines in a desktop group. You can restrict access in two ways: Use SmartAccess strings to filter connections made through Citrix Access Gateway. Your XenDesktop policy administrator can also perform this task in the HDX Policies node in Desktop Studio.

For more information about this, see Working with XenDesktop Policies. Use exclusion filters on access policies that you set with the XenDesktop Software Development Kit (SDK). Access policies achieve similar results to, but are are different from, XenDesktop policies. Access policies are applied to desktop groups to refine certain aspects of virtual desktop connections. For example, you can restrict desktop access to a subset of the users listed on the desktop group's Users page, and you can specify the allowed user devices that can form desktop connections. Further refinement is possible using exclusion filters that you apply to access policies. For example, for business or security reasons you can deny access to a subset of users or devices. Exclusion filters are set in the SDK and are disabled by default. For more information about access policies and exclusion filters, see the SDK help. To restrict access through the Access Gateway 1. 2. 3. 4. In Desktop Studio under Assignments, select the desktop group you want to restrict. Click Edit desktop group. On the Access policy page, select Connections through Access Gateway. Only connections through Access Gateway are allowed. To choose a subset of those connections, select Connections meeting any of the following filters and: 1. Define the Access Gateway farm. 2. Add, edit, or remove the SmartAccess strings that define the allowed user access scenarios for the desktop group. SmartAccess is a feature of Access Gateway. For more information, see the Access Gateway documentation.

To restrict access using exclusion filters This example demonstrates the use of exclusion filters. It employs Desktop Studio and the SDK to prevent any sales team member accessing two virtual machines in a desktop group you created for that team. You use the machines for testing so you want to prevent other users from accessing them. You have already applied an access policy called sales-department to the desktop group. 1. 2. 3. 4. In Desktop Studio, use Search to locate the machines you want to exclude, or select a desktop group and click View machines. Select the machines and click Add tag. Enter test-machine-sales. Run this SDK command to apply the filter:

Set-BrokerAccessPolicy -name sales-department -ExcludedTagFilterEnabled $True -ExcludedT

About Tags Tags are strings that identify desktops. You can use them to search for and limit access to desktops. You can add any number of tags of any length separated by semicolons. In this example, one tag (test-machine-sales) is used. Tip: Use the asterisk as a wildcard to match all tags that start with the same string. For example, if you add the tag test-machine-sales to one machine and test-machine-accounts to another, setting the tag in the Set-BrokerAccessPolicy script to test-machine* applies the filter to both machines. 10.2.9. To reallocate desktops Updated: 2010-11-30 This topic explains how you change the users or devices allocated to the machines in a desktop group or to individual virtual desktops. Important: Desktops may contain personal data, which you need to manage appropriately. For example, you may need to reimage the virtual machine.

To reallocate machines in a desktop group You can reallocate machines in desktop groups based on pooled, existing, and physical machines but not other machine types. 1. 2. 3. 4. In Desktop Studio, select the Assignments node. Select the desktop group containing the machines you want to reallocate and click Edit desktop group. On the Users page, add or remove the users and groups who can access any pooled machines in the group. On the Machine allocation page, use an import list to specify the users and groups who can access any existing or physical machines in the group.

To reallocate individual desktops 1. 2. 3. In Desktop Studio, use Search to locate the desktop that you want to reallocate, or select a desktop group and click View machines. Select the desktop and click Change user. Add and remove users as required.

To change the number of desktops allocated to users You can allocate more or fewer desktops to the users of a desktop group. 1. 2. 3. In Desktop Studio, select the Assignments node. Select the desktop group whose users you want to provide with more or fewer desktops and click Edit desktop group. On the End user settings page, set the number of desktops per user.

10.2.10. To shut down and restart desktops Updated: 2010-11-30 1. In Desktop Studio, use Search to locate the desktops you want to shut down or restart, or select a desktop group and click View machines. 2. Select the desktops and take one of the following actions. Depending on the state of the desktops, some of these options are not available: Shut down. Requests the desktops operating system to shut down. Note: If the desktop 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 desktop will be powered off before the updates are complete. Force shut down. Forcibly powers off the desktop and refreshes the list of desktops. Restart. Requests the desktop's operating system to shut down and then start the desktop again. If the operating system is unable to do this, the desktop remains in its current state. Suspend. Pauses the desktop without shutting it down and refreshes the list of desktops.

10.2.11. To remove desktops from desktop groups Updated: 2010-11-30 Removing a desktop deletes it from a desktop group but does not delete the associated virtual machine from the catalog that the group is based on. You can remove desktops only while they are idle or shut down, and if no user is logged on. To temporarily stop users from connecting to a desktop while you are removing it, put the desktop into maintenance mode. Important: Desktops may contain personal data. You need to manage this appropriately especially if

the desktop will be allocated to another user. For example, you may need to reimage the virtual machine. 1. 2. 3. In Desktop Studio, use Search to locate the desktop you want to remove or select a desktop group and click View machines. Select the desktop, and put it in maintenance mode. Click Remove from desktop group.

10.2.12. To delete desktops from catalogs Updated: 2010-11-30 When you delete a virtual desktop, users no longer have access to it and the machine is deleted from the catalog. Before deleting a desktop, ensure all user data is backed up or no longer required. You can delete a desktop only when it is idle or shut down, and if no user is logged on. To temporarily stop users from connecting to a desktop while you are deleting it, put the desktop into maintenance mode. Important: If you want to delete a desktop but retain the virtual machine it was created from and its associated Active Directory computer accounts, remove the desktop from the desktop group. Do not delete the desktop. 1. 2. 3. In Desktop Studio, use Search to locate the desktop you want to delete, or select a desktop group and click View machines. Select the desktop, and put it in maintenance mode. Click Delete and follow the prompts.

10.2.13. To enable or disable maintenance mode Updated: 2010-11-30 If you want to temporarily stop connections to a desktop so that maintenance tasks can be carried out, put the desktop into maintenance mode. You can perform this task on desktop groups as well as individual desktops. Putting a desktop into maintenance mode lets you perform administrative tasks on the associated image, such as applying patches and upgrades using your image management tools. XenDesktop has no control over desktops in maintenance mode. No user can log on to a desktop in this state. If a user is already logged on, maintenance mode takes effect as soon as they log off. If a user tries to connect to a desktop in a private desktop group while the desktop is in maintenance mode, a message appears telling them that it is currently unavailable and to try reconnecting. XenDesktop regains control over the desktops when you take them out of maintenance mode. 1. In Desktop Studio, do one of the following: To locate individual desktops, use Search, or select a desktop group and click View machines To locate a desktop group, select the Assignments node 2. Select the desktop or desktop group and click Enable maintenance mode or Disable maintenance mode. 10.2.14. To manage desktop sessions Updated: 2010-10-04 When a user logs on to a virtual desktop, the user device links to the Virtual Desktop Agent on the desktop and establishes a session. When carrying out maintenance or to assist users, you can control sessions in a number of ways. You can: Log users off sessions Disconnect sessions Send messages to users

You can use Search to locate sessions (as well as users and desktops). For information on this, see To find desktops, sessions, and desktop groups. To log off or disconnect sessions Depending on the machine type, you can log off and disconnect sessions. If you log off a session, it closes and the desktop becomes available to other users unless it is allocated to a specific user. If you disconnect a session, the user's applications continue to run and the desktop remains allocated to that user. If the user reconnects, the same desktop is allocated. Note: Depending on the machine type that the session connects to, you can configure power state timers to ensure that unused sessions are automatically processed. This frees up desktops and saves power. For example, XenDesktop can automatically log off any disconnected session after 10 minutes. 1. 2. In Desktop Studio, use Search to locate the session or select a desktop group and click View machines. Select the session or machine and click Log off or Disconnect.

To send messages to users You can send messages to users to inform them about desktop maintenance. For example, you may want to tell users to log off before critical maintenance is about to take place. 1. 2. 3. In Desktop Studio, use Search to locate the session, desktop, or user. Alternatively, select a desktop group and click View machines. Select the session, desktop, or user and click Send message. Compose your message and click OK.

10.3. Managing Your Controller Environment Updated: 2010-09-24 A controller is the server-side architectural component of XenDesktop that is responsible for distributing desktops, managing user access, and optimizing connections. You can manage the controller environment in several ways including: Adding controllers to sites Removing controllers from sites Moving controllers between sites Configuring Secure Sockets Layer (SSL) on controllers Permissions To add, move, or remove controllers, you need the following roles or permissions: The sysadmin or dbcreator database server role. If you don't have either of these roles, you need CreateAnyDatabase and AlterAnyDatabase server permissions. The db_owner or db_datawriter database user role. If you don't have either of these roles, you need Insert, Delete, and Update user permissions. Other Components XenDesktop administrators may use components other than the controller to administer virtual desktops. Those components include: Web Interface to configure Remote Desktop Protocol (RDP) connections and workspace control. Access Gateway to secure connections. The XenDesktop SDK to perform certain advanced desktop configuration tasks (for example, using the RDP, rather than the ICA, protocol for connections in a desktop group). In addition, you can use the SDK to disable parts of Desktop Studio. Although that use is not one you need to employ widely, it can be valuable in restricting administrator access to some Desktop Studio tasks and options, particularly brokering ones. For example, you can prevent assignment

administrators from editing access policies when they create desktop groups.

10.3.1. About Controller Discovery Updated: 2011-02-08 This topic contains important information about how XenDesktop controllers find and manage virtual desktops. For desktops to be usable, they must register (that is, establish communication) with the correct controller or with any one of the controllers, if there are more than one. The default operation, whose configuration is briefly described in this topic, uses information in the desktops' registries to establish communication. This is referred to as registry-based controller discovery. You can also use an Organizational Unit (OU) in Active Directory (AD). This is referred to as AD-based controller discovery. If you use that discovery method, you must configure the GUID of the OU in the desktops' registries. Important: If you change from one discovery method to the other or if you add or move controllers, you must update the registry values of all desktops (or the image on which the desktops are based). Otherwise, discovery will fail and users will not be able to connect. Ensure that you list all the controllers in the site in the desktops' registries or in Active Directory, otherwise some user connections may be refused. For load balancing, the Virtual Desktop Agent automatically distributes connections evenly across all the specified controllers. Active Directory-Based Controller Discovery To perform AD-based controller discovery, run the PowerShell script Set-ADControllerDiscovery.ps1 that is installed on each controller in the folder $Env:ProgramFiles\Citrix\Broker\Service\Setup Scripts. The script must be run on a controller in the site by a user who is a full administrator of the controller and who has the appropriate permissions to make changes in the relevant OU in AD. For more information about the script, see Active Directory Considerations. Registry-Based Controller Discovery Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. If you change discovery methods, or add or move controllers, you must update the ListOfDDCs registry key on each virtual desktop. Alternatively, use a Group Policy Object to do this. The ListOfDDCs registry key is:

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
This key lists all of the controllers in the site (and is the equivalent of Active Directory's XenDesktop site OU). For multiple controllers, the key's value is a space-delimited list of FQDNs. If both ListOfDDCs and FarmGUID (HKEY_LOCAL_MACHINE\Citrix\VirtualDesktopAgent\FarmGUID) are present in the registry, the ListOfDDCs value is used for controller discovery. (FarmGUID will be present if a site OU was specified when the Virtual Desktop Agent was installed.) Additionally, be aware of the ListOfSIDs registry key. Use this to avoid possible security threats from a compromised Domain Name System (DNS) server. The ListOfSIDs registry key is:

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
For more information, see http://support.citrix.com/article/ctx118976/. 10.3.2. To add a controller Updated: 2010-11-30 As a prerequisite, familiarize yourself with how registry keys on virtual desktops affect controller discovery. To use the Join existing site task, you must have the correct database roles and permissions. You cannot add servers installed with earlier versions of XenDesktop, Desktop Delivery Controller, or

Desktop Server to a site that uses this version of XenDesktop. If your deployment uses database mirroring, before carrying out this procedure ensure that the principal and mirrored databases are both running. In addition, if you are executing the scripts using SQL Server Management Studio, enable SQLCMD mode. For more information on mirroring XenDesktop sites, see http://support.citrix.com/article/CTX127359/. Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 1. On the server you want to add, run the XenDesktop installer to install the controller and any other desired components. Desktop Studio is installed by default with the controller. For more information about this, see Installing and Removing XenDesktop Server Components. In Desktop Studio, click the Join existing deployment task and enter the address of the site. If you are using registry-based discovery, register all brokered virtual desktops in the site (or images on which the desktops are based) with the new controller by setting the value of the ListOfDDCs registry key on each desktop or image to the FQDN of the controller.

2. 3.

10.3.3. To remove a controller Updated: 2011-01-05 Removing a controller does not uninstall XenDesktop or any other component. Instead, it removes the controller from the site's database so that it can no longer be used to broker connections and perform other tasks. If you remove a controller, you can later add it back into the same site or another one. A site requires at least one controller, so you cannot remove the last one listed in Desktop Studio. If your deployment uses database mirroring, before carrying out this procedure ensure that the principal and mirrored databases are both running. In addition, if you are executing the scripts using SQL Server Management Studio, enable SQLCMD mode. For more information on mirroring XenDesktop sites, see http://support.citrix.com/article/CTX127359/. 1. 2. 3. In Desktop Studio > Configuration > Controllers, select the controller you want to remove. You may need to remove the controller's machine account from the database server. Before doing so, check that the account is not used by another service.

Click Remove Controller. If you dont have the correct database roles and permissions, you are given the option of g

10.3.4. To move a controller to another site Updated: 2010-12-01 How you move a controller depends on the method of controller discovery that your deployment uses. You cannot move controllers to a site created using an earlier version of XenDesktop, Desktop Delivery Controller or Desktop Server. If you do, your site may become unusable. If your deployment uses database mirroring, before carrying out this procedure ensure that the principal and mirrored databases are both running. In addition, if you are executing the scripts using SQL Server Management Studio, enable SQLCMD mode. For more information on mirroring XenDesktop sites, see http://support.citrix.com/article/CTX127359/. Registry-Based Discovery As a prerequisite, familiarize yourself with how registry keys on virtual desktops affect controller discovery. To use the Join existing site task, you must have the correct database roles and permissions. Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 1. On the old site, in Desktop Studio > Configuration > Controllers select the controller you want

1. to move and click Remove Controller. If you dont have the correct database roles and permissions, you are given the option of generating a script that allows your database administrator to remove the controller for you. A site requires at least one controller, so you cannot remove the last one listed in Desktop Studio. 2. 3. 4. On each virtual desktop or image no longer managed by the controller in the old site, remove the controller from the values in the ListOfDDCs registry key. On the controller you are moving, open Desktop Studio, reset the XenDesktop services when prompted, click Join existing site, and enter the address of the new site. On each virtual desktop or image that will be managed by the controller in the new site, add the FQDN of the controller to the values in the ListOfDDCs registry key.

Active Directory-Based Discovery To use the Join existing site task, you must have the correct database roles and permissions. 1. On the old site, in Desktop Studio > Configuration > Controllers select the controller you want to move and click Remove Controller. If you dont have the correct database roles and permissions, you are given the option of generating a script that allows your database administrator to remove the controller for you. A site requires at least one controller, so you cannot remove the last one listed in Desktop Studio. On a controller in the old site, run the following script:

2.

Set-ADControllerDiscovery -sync
You must be a full administrator of the controller and have the appropriate permissions to make changes in the relevant OU in AD. The script synchronizes the OU with the current set of controllers. For information about this script, see Active Directory Considerations. 3. 4. On the controller you are moving, open Desktop Studio, reset the XenDesktop services when prompted, click Join existing site, and enter the address of the new site. On any controller in the new site, run the Set-ADControllerDiscovery -sync script.

10.3.5. To configure SSL on XenDesktop controllers Updated: 2010-11-23 Only follow this procedure if you want to use non-default ports on a controller for HTTP or HTTPS traffic. When doing so, be aware of the security risks of exposing a controller to untrusted networks. Instead of deviating from the defaults, it is preferable to deploy a stand-alone Web Interface server in your deployment. The XML Service runs on the controllers in your deployment and supports both HTTP and HTTPS protocols. By default, the service listens on ports 80 for HTTP traffic and port 443 for HTTPS traffic. Secure Sockets Layer (SSL) configuration includes installation of the appropriate server certificates on every controller. The XML Service supports SSL features through the use of server certificates but not client certificates. Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 1. Run the following command on the appropriate controller:

BrokerService.exe -WIPORT <http port> -WISSLPORT <https port>

<http port> is the port number for HTTP traffic and <https port> is the port number for HTTPS traffic. 2. If you want the XML Service to ignore HTTP or HTTPS traffic on the default ports, set the following Registry values on To ignore HTTP traffic, set XmlServicesEnableNonSsl to 0. To ignore HTTPS traffic, set XmlServicesEnableSsl to 0. 3. Ensure a server certificate is properly configured on the controller. You must obtain and install

3. a certificate, and register it for HTTPS. If the controller has IIS installed, use the steps described in http://support.microsoft.com/kb/299875. If the controller does not have IIS installed, one method of achieving this is as follows: 1. Obtain an SSL server certificate and install it on the controller as described in http://blogs. technet.com/b/pki/archive/2009/08/05/how-to-create-a-web-server-ssl-certificate-manually.aspx . For more information on the certreq tool, see http://technet.microsoft.com/enus/library/cc736326(WS.10).aspx. 2. Register the certificate for HTTPS following the Registering SSL Certificates section of http: //msdn.microsoft.com/en-us/library/ms186362.aspx.

10.4. Configuring Hosts Updated: 2010-11-22 These topics tell you how to: Create a host Add storage to a host Rename a host Update connection details Configure high availability on XenServer Configure hypervisor throttling Rename a connection Enable and disable maintenance mode for a connection View the details of VMs accessed through a connection Manage the VMs accessed through a connection Delete a host Delete a connection You need to be a full administrator to carry out the tasks described in these topics. Read-only administrators, however, can view host, connection, and machine details. 10.4.1. To create a host Updated: 2010-11-30 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Click Add Host. Select Connect to a new Host.

4. Specify the type of host, and the address and credentials to use when connecting. Ensure that the credentials enable you to carry out all the necessary XenDesktop tasks. If you use XenServer, note that: Citrix recommends using HTTPS to secure communication between XenDesktop and XenServer. To use HTTPS you must replace the default SSL certificate installed with XenServer with one from a trusted certificate authority. For details of how to do this see To replace the default XenServer SSL certificate You can configure high availability if it is enabled on XenServer. Citrix recommends that you select all servers in the pool to allow communication between XenDesktop and XenServer if the pool master fails.

Note: If you are using XenDesktop to manage user desktops hosted on dedicated blade PCs in the data center, select None for host type. 5. Type a name for the connection.

6. Select whether to use XenDesktop to create virtual machines or whether to create them manually. Select the XenDesktop option to use Machine Creation Services to create catalogs of pooled or dedicated VMs. The manual creation option allows you to use XenDesktop to manage and deliver user desktops that you have already migrated to VMs in the data center.

7. 8.

Click Next. If you selected to use XenDesktop to create desktops, you are prompted to enter details of the storage and virtual network to use. The wizard then finishes. If you selected manual desktop creation, no further details are needed and the wizard finishes.

To create a host using existing connection details 1. 2. 3. 4. 5. In Desktop Studio, select Configuration > Hosts. Click Add Host. Select Use an existing Host Connection, select the relevant connection from the list, then click Next. Select the storage and network for the new virtual machines, then click Next. Type a name for the new host, then click Finish.

10.4.2. Editing a Host Updated: 2010-11-08 You can add storage to an existing host, and you can also rename it. To add storage to a host 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Select the host to which you want to add storage, then click Add storage. Select the storage to add, then click OK.

To rename a host 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Select the host you want to rename, then click Rename Host. Type the new name for the host, then click OK.

10.4.3. To edit a connection Updated: 2010-11-12 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Select the connection you want to edit, then click Change details. You can edit the connection as follows: To update the connection's address and credentials, type the new details in the relevant fields, then click OK. Do not use this as a way of entering the details of a new connection; to add a new connection, see To create a host. Note: To rename the connection, select the connection then click Rename. To configure high availability, if it has been enabled on XenServer, click Edit. Citrix recommends that you select all servers in the pool to allow communication between XenDesktop and XenServer if the pool master fails. Select the servers to be used, then click OK. To configure hypervisor throttling, click Advanced. If your power management settings allow too many or too few machines to start at the same time, you can adjust the throttling limit as follows: To prevent more than a certain number of operations or actions running at any one time, enter a number in Max active actions. To limit the number of concurrent actions to a percentage of the total number of VMs configured for this connection, enter a number in Max power actions as a percentage of desktops. The actual limit applied is the lower number of the above two possibilities. For example, if the maximum active number of actions is 10, the maximum number of actions as a percentage

of desktops is 10, and the number of machines is 34, the limit is 3 (that is, 10% of 34 rounded to the nearest whole number). You can also limit the number of new actions that can be started per minute by entering a number in Max actions per minute. Note: Use Connection options only under the guidance of a Citrix Support representative.

10.4.4. To put a connection into maintenance mode Updated: 2010-11-08 Putting a connection into maintenance mode prevents any new power action affecting any machine stored on hosts accessed through this connection. No user can connect to a machine in this state. If a user is already connected, maintenance mode takes effect as soon as they log off. You can then perform administrative tasks on the associated image, such as applying patches and upgrades using your image management tools. 1. 2. In Desktop Studio, select Configuration > Hosts. Select the connection to put into maintenance mode, then click Enable maintenance mode.

To take a connection out of maintenance mode, click Disable Maintenance Mode. 10.4.5. Managing Machines Updated: 2010-11-22 You can view the details of all machines accessed through a particular connection, and you can also manage these machines. To view machine details 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Select the relevant connection. Select View machines. The machines accessed through this connection are listed in the upper panel of the screen. To display the details of a machine, select it, and the details appear in the lower panel. Session details are also provided if there is a session open. You can also use XenDesktop search facilities to find machines quickly. Either select a saved search from the list at the top of the screen, or create a new search. You can either search using the machine name, by typing in the name or part of it, or you can build an expression to use for an advanced search. To build an expression, click the unfold button then select from the lists of properties and operators. To manage machines 1. 2. 3. Display the machines as described above. Select the relevant machines. Select one of the following actions: Start. Starts the machine if it is powered-off or suspended. If the host type does not support the power-on function, the Start action is not available. Suspend. Pauses the desktop without shutting it down and refreshes the list of desktops. Shut down. Requests the desktops operating system to shut down. Note: If the desktop 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 desktop will be powered off before the updates are complete. Force shut down. Forcibly powers off the desktop and refreshes the list of desktops. Restart. Requests the desktop's operating system to shut down and then start the desktop

again. If the operating system is unable to do this, the desktop remains in its current state. Enable maintenance mode. To temporarily stop connections to a machine so that maintenance tasks can be carried out, put it into maintenance mode. No user can connect to a machine in this state. If a user is already connected, maintenance mode takes effect as soon as they log off. Note: To put all the machines accessed through a connection into maintenance mode, select the connection and click Enable Maintenance Mode, as described in To put a connection into maintenance mode. Remove from Desktop Group. Removing a machine deletes it from a desktop group, which prevents users from connecting to it, but does not delete it from the catalog that the group is based on. You can remove a machine only while no user is connected to it. To temporarily stop users from connecting to a machine while you are removing it, put the machine into maintenance mode first. Delete. When you delete a machine, users no longer have access to it and the machine is deleted from the catalog. Before deleting a machine, ensure all user data is backed up or no longer required. You can delete a machine only while no user is connected to it. To temporarily stop users from connecting to a machine while you are deleting it, put the machine into maintenance mode first.

10.4.6. To delete a host Updated: 2010-11-22 Before you delete a host, ensure that: All users have logged off from the machines stored on the host No disconnected user sessions are still running For pooled and dedicated machines, all machines are in maintenance mode For existing machine catalogs, all machines are powered off

Caution: Deleting a host can result in the deletion of large numbers of machines and in loss of data. Ensure you read this topic carefully and that any user data on affected machines is backed up or no longer required. 1. 2. 3. In Desktop Studio, select Configuration > Hosts. Select the host you want to delete, then click Delete Host. If this host still has machines stored on it, you are prompted to specify whether or not the machines should be deleted and, if they are to be deleted, what should be done with the AD computer accounts associated with them. A catalog becomes unusable when you delete a host that is referenced by that catalog. If this host is referenced by a catalog you are therefore given the opportunity to delete the catalog at this point. Before you delete a catalog, ensure that it is not supported by other hosts.

10.4.7. To delete a connection Updated: 2010-11-22 Before you delete a connection, ensure that: All users have logged off from the machines stored on the hosts accessed through this connection No disconnected user sessions are still running For pooled and dedicated machines, all machines are in maintenance mode For existing machine catalogs, all machines are powered off

Caution: Deleting a connection can result in the deletion of large numbers of machines and in loss of data. Ensure you read this topic carefully and that any user data on affected machines is backed up or no longer required. 1.

1. 2. 3.

In Desktop Studio, select Configuration > Hosts. Select the connection you want to delete, then click Delete Connection. If any host using this connection still has machines stored on it, you are prompted to specify whether the machines should be deleted and, if they are to be deleted, what should be done with the AD computer accounts associated with them. A catalog becomes unusable when you delete a connection associated with a host that is referenced by that catalog. If any host using this connection is referenced by a catalog you are therefore given the opportunity to delete the catalog at this point. Before you delete a catalog, ensure that it is not supported by other hosts.

10.5. Using Smart Cards with XenDesktop Updated: 2010-08-12 XenDesktop users can use smart cards for: Authenticating to XenDesktop sessions Digitally signing or encrypting documents Authenticating to locally installed or virtualized applications

10.5.1. Smart Card Types and Readers Supported Updated: 2010-08-12 The following are supported: Smart cards, including Common Access Card (CAC) USB smart card tokens All the above must be Microsoft-compatible. Multiple smart cards and multiple readers can be used on the same user device. Users can move between user devices with different smart card readers by reconnecting to the session after authentication to XenDesktop. You must obtain a device driver for the smart card reader and install it on the user 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 user 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

Note: Smart card drivers should automatically be downloaded on detection for virtual desktops running Windows 7. If you need to install drivers, you can obtain them from http://catalog.update. microsoft.com or from the smart card vendor. Smart card support also involves components available from Citrix partners. These will be updated independently by the partners, and are not described in these topics. Refer to the Citrix Ready program at http://www.citrix.com/ready/ for more information. 10.5.2. User Device Requirements for Smart Cards Updated: 2010-08-12 The following types of user device support smart card authentication: Domain-joined and non-domain joined thin clients. Thin clients 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 computers. These computers can connect directly to virtual desktops, applications, and other services. They can run local applications and support simultaneous connections.

User devices must have the following installed: One of the following operating systems: Microsoft Windows XP or XP Embedded (depending on device type) with Service Pack 3 or later Microsoft Vista with Service Pack 1 or later Microsoft Windows 7 (non-Aero) Linux, for non-domain-joined thin clients The Citrix online plug-in 12.0 or later or, for Linux appliances, the Citrix Receiver for Linux 11.1 or later Microsoft Internet Explorer 7 or later, 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. 10.5.3. Secure Use of Smart Cards Updated: 2010-08-12 Your organization may have specific security policies concerning the use of smart cards. These policies may, for example, state how smart cards are issued and how users should safeguard them. Some aspects of these policies may need to be reassessed in a XenDesktop environment: 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, 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 user device 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. You can reset PINs from the desktop using Microsoft Identity Lifecycle Manager (ILM) and Certificate Lifecycle Manager (CLM) smart card management systems, or using any smart card vendor's reset utilities that use the Windows smart card PC/SC (WinSCard) API. 10.5.4. Configuring Smart Card Authentication Updated: 2010-08-12 To allow users to authenticate with smart cards, you must use Web Interface to reconfigure the relevant default Web site provided with XenDesktop, or create new Web sites, as described in 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 with smart cards to virtual desktops from Windows XP and XP Embedded user devices is supported, but not from user devices running any other operating system. Pass-through with smart cards to applications hosted on XenApp servers running on Windows Server 2003 or Windows Server 2008 from Windows XP or XP Embedded user devices is supported. Pass-through from user devices running any other operating system is not supported. To use pass-through authentication with smart cards for XenApp-hosted applications, ensure you select Use Kerberos to authenticate to XenApp Services site when you configure Pass-through with smartcard as the authentication method for the site.

10.5.5. Managing Smart Card Use Updated: 2010-10-21 Keep the following points in mind when managing the use of smart cards in your organization: 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. Multiple smart cards and multiple readers can be used on the same user device, but if passthrough authentication is in use only one smart card must be inserted when the user starts a virtual desktop. When a smart card is used within an application (for example, for digital signing or encryption functions), there may be additional prompts to insert a smart card or enter a PIN. This can occur if more than one smart card has been inserted at the same time. If users are prompted to insert a smart card when the smart card is already in the reader, they should select Cancel. If they are prompted for the PIN, they should enter the PIN again. If you are using XenDesktop with XenApp-hosted applications running on Windows Server 2008 or 2008 R2 and with smart cards requiring the Microsoft Base Smart Card Cryptographic Service Provider, you may find that if a user runs a smart card transaction, all other users who use a smart card in the logon process are blocked. For further details and a hotfix for this issue, see http://support. microsoft.com/kb/949538.

10.5.6. Removing Smart Cards Updated: 2010-08-12 When the user removes their smart card, the XenDesktop behavior depends on the smart card removal policy setting on the virtual desktop: Windows Server 2003 and 2008 policy setting No action Lock workstation Force logoff Disconnect if a remote Terminal Services session XenDesktop behavior

No action. The XenDesktop session is disconnected and the virtual desktop is locked. 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. The XenDesktop session is disconnected and the virtual desktop is locked.

There may also be a user device smart card removal behavior policy if the user device is domain-joined. In this case the user device has the default Windows behavior. If a user device is installed for full-screen-only use, XenDesktop enforces consistent smart card removal policy. For example, if the Windows smart card removal policy is set to Force logoff for the desktop, XenDesktop also forces logoff on the user device, regardless of the Windows smart card removal policy set at the device. This ensures that the user device is not left in an inconsistent state. This behavior applies only to full-screen-only user devices. 10.6. Working with XenDesktop Policies Updated: 2010-10-15 To control user access or session environments, configure a Citrix policy. Citrix policies are the most efficient method of controlling connection, security, and bandwidth settings. You can create policies for specific groups of users, devices, or connection types. Each policy can contain multiple settings. For example, you can configure settings to: Control sound quality for user devices Allow users to access the Documents folder on their local user device

Allow or prevent remote users from being able to save to their hard drives from a session Allow or prevent users from accessing the Windows clipboard Monitor CPU usage, ICA Latency, and Profile Load Time You can work with policies through Desktop Studio in XenDesktop or the Group Policy Editor in Windows. The console or tool you use to do this depends on whether or not your network environment includes Microsoft Active Directory and whether or not you have the appropriate permissions to manage Group Policy Objects (GPOs). Using Desktop Studio If you are a Citrix administrator without permission to manage Group Policy, use Desktop Studio to create policies for your site. Policies created using Desktop Studio are stored in the XenDesktop database and updates are pushed to the virtual desktop either when that virtual desktop registers with the broker or when a user connects to that virtual desktop. Using the Group Policy Editor If your network environment includes Active Directory and you have the appropriate permissions to manage Group Policy, you may want to use the Group Policy Editor to create policies for your site. The settings you configure affect the GPOs you specify through the Group Policy Management console. Policies created using the Group Policy Editor are stored on the domain controller and updates are pushed to the virtual desktop at regular intervals as part of the Group Policy Object (GPO) refresh policy. In Active Directory environments, Active Directory GPOs take precedence over site policy settings. Policy updates do not affect users who are already connected to virtual desktops. Policy changes are applied either when a user logs on or when a user reconnects. Administrative Roles There are two types of XenDesktop policy administrator: Full Admin. This administrator has full administrative rights with authority to manage all aspects of policy administration, including policy creation, management, editing, and policy modelling. Read-only. This administrator can see all aspects of policy administration, but has no authority to change any policy settings. A read-only administrator can, however, run the Policy Modeling wizard to check which policy settings are being applied to a user's sessions.

Note: These roles also apply to administrators using Powershell to configure XenDesktop policies. For more information, see Delegated Administration. Tips for Working with Policies If you create more than one policy in your environment, make sure that you prioritize the policies so that it is clear, if there is conflict, which policy should take precedence. The process for configuring policies is: 1. 2. 3. 4. Note: Unfiltered policies take priority over filtered policies. To ensure policies are applied correctly, prioritize filtered policies above unfiltered policies. In general, Citrix policies override similar settings configured for an entire site, for specific controllers, or on the client. Create and name the policy. Configure policy settings. Apply the policy to connections by adding filters. Prioritize the policy.

10.6.1. Navigating Citrix Policies and Settings Updated: 2010-10-15 In Desktop Studio, policy settings are collected into two main categories: Machine and User. Machine policy settings define the behavior of virtual desktops and are applied when a virtual desktop starts. Note that these settings apply even when there are no active user sessions on the virtual desktop. User policy settings define the user experience when connecting to virtual desktops using ICA. User policies are applied whenever a user connects or reconnects to a virtual desktop using ICA. If a user connects to a virtual desktop using RDP or logs on directly at the console, user policies are not applied. Active Directory policies and settings are collected into similar categories: Computer Configuration and User Configuration. Important: Although the top-level node names for policies differ in Desktop Studio (Machine and User) and the Group Policy Editor (Computer and User), the names of individual policy settings are identical in both consoles. Accessing Policies and Settings In Desktop Studio you access policies and settings by clicking the HDX Policy node from the console tree and selecting either Machines or Users. In the Group Policy Editor, you access policies and settings by clicking the Citrix Policies node under Computer Configuration or User Configuration in the tree pane. The Machine and User tabs each display a list of the policies that have been created. Beneath this list, the following tabs are displayed: Summary displays the settings currently configured for the selected policy Settings displays by category the available and configured settings for the selected policy Filters displays the available and configured filters for the selected policy

Searching Policies and Settings From these consoles, you can search the policies you create and their settings and filters. All searches find items by name as you type. You can perform searches from the following places: For searching policies, use the search tool near the list of Citrix policies For searching settings, use the search tool on the Settings tab For searching filters, use the search tool on the Filters tab You can refine your search by: On the Settings or Filters tabs, selecting Active Settings or Active Filters, respectively, to search only the settings or filters that have been added to the selected policy. On the Settings tab, selecting a category such as Auto Client Reconnect or Bandwidth to search only the settings in that category. To search the entire catalog of settings or filters, select All Settings or All Filters. 10.6.2. Creating Policies Updated: 2010-10-15 Before you create a policy, decide which group of users or devices you want it to affect. You may want to create a policy based on user job function, connection type, user device, or geographic location. Alternatively, you can use the same criteria that you use for Windows Active Directory group policies. If you already created a policy that applies to a group, consider editing the policy and configuring the appropriate settings instead of creating another policy. Avoid creating a new policy solely to enable a specific setting or to exclude the policy from applying to certain users.

To create a policy 1. Depending on the console you use to manage Citrix policies: From Desktop Studio, select the HDX Policy node in the left pane and then select the Machines or Users tab. From the Group Policy Editor, select the Citrix Policies node in the left pane. 2. Click New. The New Policy wizard appears. 3. Enter the policy name and, optionally, a description. Consider naming the policy according to who or what it affects; for example, Accounting Department or Remote Users. 4. Choose the policy settings you want to configure. 5. Choose the filters you want to apply to the policy. 6. Elect to leave the policy enabled or clear the Enable this policy checkbox to disable the policy. Enabling the policy allows it to be applied immediately to users logging on to virtual desktops in a site. Disabling the policy prevents it from being applied. If you need to prioritize the policy or add settings at a later time, consider disabling the policy until you are ready to apply it to users. 10.6.3. Configuring Policy Settings Updated: 2010-08-02 Policies contain settings that are applied to connections when the policy is applied. Policy settings can be enabled, disabled, or not configured. By default, policy settings are not configured, meaning they are not added to a policy. Settings can be applied only when they are added to a policy. Some policy settings can be in one of the following states: Allowed or Prohibited allows or prevents the action controlled by the setting. Enabled or Disabled turns the setting on or off. If you disable a setting, it is not enabled in lowerranked policies. For settings that are Allowed or Prohibited, the action controlled by the setting is either allowed or prevented. In some cases, users are allowed or prevented from managing the setting's action in the session. For example, if the Menu animation setting is set to Allowed, users can control menu animations in their client environment. In addition, some settings control the effectiveness of dependent settings. For example, the Client drive redirection setting controls whether or not users are allowed to access the drives on their devices. To allow users to access their network drives, both this setting and the Client network drives setting must be added to the policy. If the Client drive redirection setting is disabled, users cannot access their network drives even if the Client network drives setting is enabled. In general, Machine policy setting changes go into effect either when the virtual desktop restarts or when a user logs on. User policy setting changes go into effect the next time the relevant users log on. If you are using Active Directory, policy settings are updated when Active Directory re-evaluates policies at regular 90 minute intervals and applied either when the virtual desktop restarts or when a user logs on. Default Values of Settings For some policy settings, you can enter a value or you can choose a value from a list when you add the setting to a policy. You can limit configuration of the setting by selecting Use default value. Selecting this option disables configuration of the setting and allows only the setting's default value to be used when the policy is applied. This occurs regardless of the value that was entered before selecting Use default value. Default values for all Citrix policy settings are located in the Policy Settings Reference. Best Practices for Policy Settings Citrix recommends the following when configuring policy settings: Assign policies to groups rather than individual users. If you assign policies to groups, assignments are updated automatically when you add or remove users from the group.

Do not enable conflicting or overlapping settings in Remote Desktop Session Host Configuration. In some cases, Remote Desktop Session Host Configuration provides similar functionality to Citrix policy settings. When possible, keep all settings consistent (enabled or disabled) for ease of troubleshooting. Disable unused policies. Policies with no settings added create unnecessary processing.

10.6.4. Applying XenDesktop Policies Updated: 2010-11-30 When you add a filter to a policy, the policy's settings are applied to connections according to specific criteria or rules. If no filter is added, the policy is applied to all connections. You can add as many filters as you want to a policy, based on a combination of criteria. The availability of certain filters depends on whether you are applying a Machine policy or a User policy. The following table lists the available filters: Filter Name Filter Description Policy Scope User policies only

Access Control Applies a policy based on the access control conditions through which a client is connecting. Assignment Applies a policy based on the Assignment of the desktop running the session.

Machine policies User policies

Client IP Address Client Name

Applies a policy based on the IP address (IPv4 or IPv6) of the user device used to connect to the session. Applies a policy based on the name of the user device from which the session is connected. Applies a policy based on the type of machine running the session.

User policies only User policies only

Machine Type

Machine policies User policies

Organizational Unit Applies a policy based on the organizational unit (OU) of the desktop running the session.

Machine policies User policies

Tag

Applies a policy based on any tags applying to the desktop running the session.

Machine policies User policies

User

Applies a policy based on the user or group membership of the user connecting to the session.

User policies only

When a user logs on, XenDesktop identifies the policies that match the filters for the connection. XenDesktop sorts the identified policies into priority order, compares multiple instances of any policy setting, and applies the policy setting according to the priority ranking of the policy. If you are using Active Directory, policy settings are updated when Active Directory re-evaluates policies at regular 90 minute intervals and applied when a user logs on. Any policy setting that is disabled takes precedence over a lower-ranked setting that is enabled. Policy settings that are not configured are ignored.

Important: When configuring both Active Directory and Citrix policies using the Group Policy Management Console, filters and settings may not be applied as expected. For more information, see http://support.citrix.com/article/CTX127461 Unfiltered Policies By default, XenDesktop provides an "Unfiltered" policy for both Machine and User policy settings. The settings added to this policy apply to all connections. If you use Desktop Studio to manage Citrix policies, settings you add to the Unfiltered policy are applied to all virtual desktops and connections in a site. If you have Active Directory in your environment and use the Group Policy Editor to manage Citrix policies, settings you add to the Unfiltered policy are applied to all sites and connections that are within the scope of the Group Policy Objects (GPOs) that contain the policy. For example, the Sales OU contains a GPO called Sales-US that includes all members of the US sales team. The Sales-US GPO is configured with an Unfiltered policy that includes several user policy settings. When the US Sales manager logs on to the site, the settings in the Unfiltered policy are automatically applied to the session because the user is a member of the Sales-US GPO. Filter Modes A filter's mode determines whether or not the policy is applied only to connections that match all the filter criteria. If the mode is set to Allow (the default), the policy is applied only to connections that match the filter criteria. If the mode is set to Deny, the policy is applied if the connection does not match the filter criteria. The following examples illustrate how filter modes affect Citrix policies when multiple filters are present. Example: Filters of Like Type with Differing Modes In policies with two filters of the same type, one set to Allow and one set to Deny, the filter set to Deny takes precedence, provided the connection satisfies both filters. For example: Policy 1 includes the following filters: Filter A is a User filter that specifies the Sales group and the mode is set to Allow Filter B is a User filter that specifies the Sales manager's account and the mode is set to Deny Because the mode for Filter B is set to Deny, the policy is not applied when the Sales manager logs on to the site, even though the user is a member of the Sales group. Example: Filters of Differing Type with Like Modes In policies with two or more filters of differing types, set to Allow, the connection must satisfy at least one filter of each type in order for the policy to be applied. For example: Policy 2 includes the following filters: Filter C is a User filter that specifies the Sales group and the mode is set to Allow Filter D is a Client IP Address filter that specifies 10.8.169.* (the corporate network) and the mode is set to Allow When the Sales manager logs on to the site from the office, the policy is applied because the connection satisfies both filters. Policy 3 includes the following filters: Filter E is a User filter that specifies the Sales group and the mode is set to Allow Filter F is an Access Control filter that specifies Access Gateway connection conditions and the mode is set to Allow When the Sales manager logs on to the site from the office, the policy is not applied because the connection does not satisfy Filter F.

10.6.4.1. To apply a policy Updated: 2010-07-23 You must add at least one filter to a policy for that policy to be applied correctly. If you do not add any filters, policy settings are applied to all user sessions, unless those policy settings are overidden by settings in a policy with a higher priority. 1. From the policy wizard, select the filter you want to apply and click Add. 2. From the New Filter dialog box, click Add to configure filter elements. 3. Select the mode for the filter. The policy is applied the next time the relevant users establish a connection. 10.6.5. Using Multiple Policies Updated: 2010-11-24 You can use multiple policies to customize XenDesktop to meet users needs based on their job functions, geographic locations, or connection types. For example, for security reasons you may need to place restrictions on user groups who regularly work with highly sensitive data. You can create a policy that prevents users from saving sensitive files on their local client drives. However, if some people in the user group do need access to their local drives, you can create another policy for only those users. You then rank or prioritize the two policies to control which one takes precedence. When using multiple policies, you need to determine how to prioritize them, how to create exceptions, and how to view the effective policy when policies conflict. In general, Citrix policies override similar settings configured for the entire site, for specific controllers, or on the client. Citrix policies do, however, interact with policies you set in your operating system and some Windows policies take precedence over Citrix policies; for example, security policies. Active Directory settings always take precedence over Citrix policy settings. 10.6.5.1. Prioritizing Policies and Creating Exceptions Updated: 2010-07-13 Prioritizing policies allows you to define the precedence of policies when they contain conflicting settings. The process XenDesktop uses to evaluate policies is as follows: 1. When a user logs on, all policies that match the filters for the connection are identified. 2. XenDesktop sorts the identified policies into priority order and compares multiple instances of any setting, applying the setting according to the priority ranking of the policy. You prioritize policies by giving them different priority numbers. By default, new policies are given the lowest priority. If policy settings conflict, a policy with a higher priority (a priority number of 1 is the highest) overrides a policy with a lower priority. Settings are merged according to priority and the setting's condition; for example, whether the setting is disabled or enabled. Any disabled setting overrides a lower-ranked setting that is enabled. Policy settings that are not configured are ignored and do not override the settings of lower-ranked settings. When you create policies for groups of users, user devices, or servers, you may find that some members of the group require exceptions to some policy settings. You can create exceptions by: Creating a policy only for those group members who need the exceptions and then ranking the policy higher than the policy for the entire group Using the Deny mode of a filter added to the policy A filter with the mode set to Deny tells XenDesktop to apply the policy to connections that do not match the filter criteria. For example, a policy contains the following filters: Filter A is a Client IP address filter that specifies the range 208.77.88.* and the mode is set to Allow Filter B is a User filter that specifies a particular user account and the mode is set to Deny

The policy is applied to all users who log on to the farm with IP addresses in the range specified in Filter A. However, the policy is not applied to the user logging on to the farm with the user account specified in Filter B, even though the user's computer is assigned an IP address in the range specified in Filter A. 10.6.6. Determining Which Policies Apply to a Connection Updated: 2010-10-26 Sometimes a connection does not respond as expected because multiple policies apply. If a higher priority policy also applies to a connection, it can override the settings you configure in the original policy. You can determine how final policy settings are merged for a connection by calculating the Resultant Set of Policy. You can calculate the Resultant Set of Policy in the following ways: Use the Citrix Group Policy Modeling Wizard to simulate a connection scenario and discern how Citrix policies might be applied Use Group Policy Results to produce a report describing the Citrix policies in effect for a given user and controller You can launch the Citrix Group Policy Modeling Wizard from the Action pane in Desktop Studio. If your XenDesktop environment includes Active Directory, you can launch both tools from the Group Policy Management console in Windows. Using the Citrix Group Policy Modeling Wizard With the Citrix Group Policy Modeling Wizard, you can specify conditions for a connection scenario such as domain controller, users, Citrix policy filter evidence values, and simulated environment settings such as slow network connection. The report that the wizard produces lists the Citrix policies that would likely take effect in the scenario. If you are logged on to the controller as a domain user and your environment includes Active Directory, the wizard calculates the Resultant Set of Policy using both site policy settings and Active Directory Group Policy Objects (GPOs). If you are logged on to the controller as a local user and run the wizard from Desktop Studio, the wizard calculates the Resultant Set of Policy using only site policy settings. Using Group Policy Results The Group Policy Results tool helps you evaluate the current state of GPOs in your environment and generates a report that describes how these objects, including Citrix policies, are currently being applied to a particular user and controller. Deciding Which Policy Modeling Tool to Use If you run the Citrix Group Policy Modeling Wizard or Group Policy Results tool from the Group Policy Management Console, site policy settings created using Desktop Studio are not included in the Resultant Set of Policy. To ensure you obtain the most comprehensive Resultant Set of Policy, Citrix recommends launching the Citrix Group Policy Modeling wizard from Desktop Studio, unless you create policies using only the Group Policy Management Console. 10.6.6.1. To simulate connection scenarios with Citrix policies Updated: 2010-07-02 1. Depending on your XenDesktop environment, open the Citrix Group Policy Modeling Wizard: From Desktop Studio, click the HDX Policy node in the console tree and then click the Modeling node. From the Actions pane, select Launch Modeling Wizard. From the Group Policy Management console, right-click the Citrix Group Policy Modeling node in the console tree and then select Citrix Group Policy Modeling Wizard. 2. Follow the wizard to select the domain controller, users, computers, environment settings, and Citrix

2. filter criteria you want to use in the simulation. When you click Finish, the wizard produces a report of the modeling results. In Desktop Studio, the report appears as a node in the console tree, underneath the Policies node. The Modeling Results tab in the middle pane displays the report, grouping effective Citrix policy settings under User Configuration and Computer Configuration headings. 10.6.6.2. Troubleshooting Policies With No Configured Settings Updated: 2010-07-13 Because settings configured in some policies can conflict with settings configured in others and policies can have multiple filters, a policy may not behave as expected or it may not run at all. Users, IP addresses, and other filtered objects can have more than one policy that applies to them simultaneously. In this case, XenDesktop merges these policies settings to effectively form a new policy resulting from the existing ones. This combination of settings is known as the resultant policy. When there are multiple policies that can apply to a session, it is the resultant policy that XenDesktop enforces. When you run the Citrix Group Policy Modeling Wizard or the Group Policy Results tool, you might create a resultant policy that has no configured settings. When this happens, users connecting to their virtual desktops under conditions that match the policy evaluation criteria are not affected by any policy rules. This occurs when: No policies have filters that match the policy evaluation criteria Policies that match the filter do not have any settings configured Policies that match the filter are disabled If you want to apply policy settings to the connections that meet the specified criteria: Make sure the policies that you want to apply to those connections are enabled Make sure the policies that you want to apply have the appropriate settings configured

10.6.7. Applying Policies to Access Gateway Connections Updated: 2010-08-02 You can create a policy that is applied to Access Gateway connections or to Access Gateway connections with certain properties. You can create Citrix policies to accommodate different access scenarios based on factors such as authentication strength, logon point, and user device information such as endpoint analysis. You can selectively enable client-side drive mapping, cut and paste functionality, and local printing based on the logon point used to access the published application. Prerequisites for Filtering on Access Gateway Connections For Citrix XenDesktop to filter on Access Gateway connections, you must complete all of the following: For Access Gateway: Create one or more Connection policy filters to define specified requirements for user logon. Note: You must be using Access Gateway Advanced Edition (Version 4.0 or later) or Access Gateway Enterprise Edition (Version 9.1 or later) to create filters that work with XenDesktop.

For Web Interface: Specify At Access Gateway as the point of authentication for your XenApp Web site. Ensure that controllers for a site are configured to trust requests sent to the Citrix XML service. For XenDesktop: Ensure that any access policy configured on controllers for a site allows connections to virtual desktops through Access Gateway. Create a User policy that includes a filter referencing Access Gateway filters.

To apply a policy filter based on Access Gateway connections 1. Depending on the console you use to manage Citrix policies: From Desktop Studio, select the HDX Policy node in the left pane and then select the User tab in the middle pane.

From the Group Policy Editor, under User Configuration in the left pane, select the Citrix Policies node. 2. Select an existing User policy or create a new User policy. 3. Follow the policy wizard to the filters page or click the Filters tab in the middle pane of the console. 4. Select Access Control and then click Add. 5. Click Add to configure the filter. 6. Select With Access Gateway. 7. To apply the policy to connections made through Citrix Access Gateway without considering Access Gateway policies, accept the default entries in the AG farm name and Access condition fields. 8. To apply the policy to connections made through Citrix Access Gateway based on existing Access Gateway policies, perform the following actions: 1. In AG farm name, enter one of the following items: If using Access Gateway Advanced Edition, enter the name of the Access Gateway farm. If using Access Gateway Enterprise Edition, enter the virtual server name of the Access Gateway appliance. 2. In Access condition, enter one of the following items: If using Access Gateway Advanced Edition, enter the name of the Access Gateway filter for XenDesktop to use. If using Access Gateway Enterprise Edition, enter the name of the endpoint session policy for XenDesktop to use.

Important: XenDesktop does not validate Access Gateway farm, server, and filter names, so always verify this information with the Access Gateway administrator. 9. To apply the policy to every connection except those made through Access Gateway, in the Mode list box, select Deny. The filter's mode tells XenDesktop whether or not to apply the policy to connections that match the filter criteria. Selecting Deny tells XenDesktop to apply the policy to connections that do not match the filter criteria. 11. Monitoring XenDesktop 5 Updated: 2010-11-10 Use the Desktop Studio dashboard to monitor your deployment. To display the dashboard, select Desktop Studio at the top of the tree in the left-hand pane of the console then, if necessary, select the Dashboard tab . Machines This panel displays a high level view of all the machines in your deployment, categorized as follows: All: All machines that are members of desktop groups. Unregistered: Machines that are running but are not registered with a controller. High CPU: Machines with a high CPU usage metric, as measured against the policy rule CPU Usage Monitoring Threshold. High Latency: Machines with a high ICA latency metric, as measured against the policy rule ICA Latency Monitoring Threshold. High Profile Load Time: Machines with a high Profile Management logon time metric, as measured

against the policy rule Profile Management Logon Time Monitoring Threshold. This information appears only if you have Citrix Profile management installed. Failed Connection : Machines to which a user was brokered but did not successfully connect or log on. Pending Update: Machines provisioned by Machine Creation Services that are not using the latest disk version. To display on the bar charts how the number of machines in a category are distributed across servers, catalogs, and desktop groups, select the relevant category row. Usage This panel provides information about machine states for each desktop group and for all the machines in the site: Total: The total number of machines. % Usage: The percentage of machines on which user sessions (both connected and disconnected) are running. The number of machines that are in each of the following states: In Use. Machines to which users are connected. Disconnected. Machines that have sessions running but are disconnected. Ready. Machines that are ready for brokering. Unregistered. Machines that are running but not registered with a controller. Off. Machines that are not running. The graph shows the percentage of machines that are in use for each desktop group, based on snapshots taken once an hour on the hour. The local time zone of the machine running Desktop Studio is used. To highlight the graph line for a desktop group, select the row for that group in the table. Infrastructure This panel displays health status icons for a site's hosts and controllers. For hosts, the connection status and the health of the CPU, memory, bandwidth (network usage), and storage (disk usage) are monitored using information from XenServer or VMware. To see alert details provided by the host system, mouse over the icon. If no icon appears for a particular metric, this indicates that this metric is not supported by the type of host you are using. No health information is available for SCVMM hosts. For controllers, the icons indicate whether or not servers are online, all services are running, and all services are connected to a database. 12. Customizing Your XenDesktop Environment Updated: 2010-08-11 After completing the initial setup tasks, you can customize and optimize your XenDesktop deployment: Create additional administrators for the site, if necessary. Set up any general Citrix policies that you require, including policies for printing. See Working with XenDesktop Policies for details of configuring policies. Configure USB support. Optimize the user experience by ensuring that settings for desktops and users are appropriate.

12.1. Delegating Administration Tasks Updated: 2010-10-20 This topic explains how to display information about administrative rights and how to create additional XenDesktop administrators. Displaying Administration Rights You can display the administrative rights associated with a particular administrator using Desktop Studio.

To display administration rights 1. 2. 3. Launch Desktop Studio. Choose Configuration > Administrators. A list of administrators appears together with their roles. Select an administrator to display information about their role and permissions.

Delegating Administration Tasks To manage your XenDesktop environment efficiently, you may need to create additional administrators. Only an administrator with full administration rights can create further full or delegated administrators. For more information about the different XenDesktop administrator roles, see Delegated Administration. To create a XenDesktop administrator: 1. 2. 3. Launch Desktop Studio. Choose Configuration > Administrators. Choose Action > Add Administrator. The Add Administrator dialog box appears. Follow the instructions on-screen.

To edit a XenDesktop administrator: 1. 2. 3. Launch Desktop Studio. Choose Configuration > Administrators. Select the administrator you want to edit and choose Action > Edit. The Edit Administrator dialog box appears. Follow the instructions on-screen.

To delete a XenDesktop administrator: 1. 2. 3. 4. Launch Desktop Studio. Choose Configuration > Administrators. Select the administrator you want to delete and choose Action > Delete Administrator. Click Yes to confirm deletion.

12.2. Printing with XenDesktop Updated: 2010-08-27 XenDesktop provides the same printing features as XenApp. For details of how to configure and manage printing, see the relevant topics in XenApp 6 for Windows Server 2008 R2. Citrix printing policies are described in Policy Settings Reference. XenDesktop 5 incorporates the features available in the XenApp Printing Optimization Pack. 12.3. Configuring USB Support Updated: 2010-12-10 You can enable users to interact with a wide range of USB devices during a XenDesktop session. The level of support provided depends on the client installed on the user device; see the relevant client documentation for further details. Isochronous features in USB devices such as webcams, microphones, speakers, and headsets are supported in typical low latency/high speed LAN environments. This allows these devices to interact with packages such as Microsoft Office Communicator and Skype. The following types of device are supported directly in a XenDesktop session, and so do not use USB support: Keyboards Mice Smart cards

Note: Specialist keyboards and mice (for example, Bloomberg keyboards, and 3D mice) can be configured

to use USB support. For more information about configuring Bloomberg keyboards, see http://support. citrix.com/article/ctx122615. 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: Bluetooth dongles Integrated network interface cards USB hubs USB graphics adaptors USB devices connected to a hub can be remoted, however the hub itself cannot be remoted. USB support allows virtual desktops access to USB devices that are connected to the user device. In environments where security separation between client and server is needed, users should connect only appropriate USB devices. You can also set policies at the virtual desktop and user device that restrict the types of USB devices that will be made available to the virtual desktop. For information on all USB devices tested with XenDesktop, see http://support.citrix.com/article/ctx123569. For further general information on setting up Citrix policies, see Working with XenDesktop Policies. If you are using XenApp, see USB Drive Mapping Limitations. If you are using thin clients, please consult the manufacturer for details of USB support and any configuration you may need to carry out. To Enable USB Support Enable the USB policy rule, which is in the USB Devices Policy Settings section of the ICA Policy Settings. Enable USB support when you install the client on user devices.

To Update the Range of USB Devices Supported To change the default range of USB devices, you must update the device rules on both the client and the Virtual Desktop Agent: Edit the client registry (or the .ini files in the case of the Receiver for Linux). For information about how to do this, see the relevant client documentation. An ADM file is included on the installation media to allow you to make changes to the client through Active Directory Group Policy: dvd root \os\lang\Support\Configuration\icaclient_usb.adm. Edit the administrator override rules in the Virtual Desktop Agent registry on the computer(s) hosting the desktops. Information about how to do this is included in the rest of this section.

Caution: 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. Device rules are enforced on both the client and the Virtual Desktop Agent, so you must make changes on both sides otherwise devices may not be allowed through. An ADM file is included on the installation media to allow you to make changes to the Virtual Desktop Agent through Active Directory Group Policy: dvd root \os\lang\Support\Configuration\vda_usb.adm. The product default rules are stored in HKLM\SOFTWARE\Citrix\PortICA\GenericUSB Type=String Name="DeviceRules" The default policy configuration is as follows:

DENY: class=02 # Communications and CDC-Control DENY: class=09 # Hub devices

DENY: class=09 # Hub devices DENY: class=0a # CDC-Data DENY: class=0b # Smartcard DENY: class=e0 # Wireless controller ALLOW: # Otherwise allow everything else
Do not edit the product default rules. The recommended way to change them is to use the GPO overrides described below, because these are evaluated before the default rules. The administrator override rules are stored in: HKLM\SOFTWARE\Policies\Citrix\PortICA\GenericUSB Type=String Name="DeviceRules" When you are creating new policy rules, refer to the USB Class Codes, available from the USB Web site at http://www.usb.org/. Policy rules take the format {Allow:|Deny:} followed by a set of tag=value expressions separated by white space. The following tags are supported: Tag VID PID REL Class Description Vendor ID from the device descriptor Product ID from the device descriptor Release ID from the device descriptor Class from either the device descriptor or an interface descriptor

SubClass Subclass from either the device descriptor or an interface descriptor Prot Protocol from either the device descriptor or an interface descriptor

When creating new policy rules, be aware of the following: Rules are case-insensitive. Rules may have an optional comment at the end, introduced by #. A delimiter is not required and the comment is ignored for matching purposes. Blank and pure comment lines are ignored. White space is used as a separator, but cannot appear in the middle of a number or identifier. For example, Deny: Class = 08 SubClass=05 is a valid rule; Deny: Class=0 Sub Class=05 is not. Tags must use the matching operator =. For example, VID=1230. Each rule must start on a new line or form part of a semicolon-separated list. Important: If you are using the Administrative (ADM) template, you must create rules on a single line, as a semicolon-separated list.

This example shows a set of administrator-defined USB policy rules:

Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive Deny: Class=08 SubClass=05 # Mass Storage
12.4. Support for USB Mass Storage Devices Updated: 2010-08-11 For mass storage devices only, remote access is also available through client drive mapping, where the drives on the user 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. To configure client drive mapping, use the Client removable drives setting in the File Redirection Policy Settings section of the ICA Policy Settings. The main differences between the two types of remoting policy are: Feature Client drive mapping USB rule

Enabled by default Read-only access configurable Safe to remove device during a session

Yes Yes No

No No Yes, provided users follow operating system recommendations for safe removal

If both client drive mapping and the USB rule 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 client being used and the individual user preferences; for further information, see the relevant client documentation. 12.5. Optimizing the User Experience Updated: 2010-10-07 This section describes how to configure: HDX technologies to optimize users' audio and multimedia experience. Time zone settings to allow users to see their local time when using desktops. Connection timers to provide appropriate durations for uninterrupted connections, idle sessions, and disconnected sessions. Workspace control to enable users to roam between different user devices. Removing 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 fontsmoothing technologies by default in users' profiles. 12.5.1. Enhancing the User Experience With HDX Updated: 2011-02-28 Citrix HDX includes a broad set of technologies designed to provide a high-definition user experience. HDX builds on existing technologies in Citrix products, extending them with new innovations for todays mediarich user environments. Quick Links Configuring HDX MediaStream Flash Redirection Configuring Audio HDX RealTime Webcam Video Compression for Video Conferencing Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors

12.5.1.1. Configuring HDX MediaStream Flash Redirection Updated: 2010-08-13 HDX MediaStream Flash Redirection allows you to move the processing of most Adobe Flash content to LAN-connected user's Windows devices rather than using server resources. This includes animations, videos, and applications. By moving the processing to the user device, Flash Redirection reduces server and network load, resulting in greater scalability while ensuring a high definition user experience. System Requirements for HDX MediaStream Flash Redirection Any operating system supported by Citrix XenApp 6 for Windows Server 2008 R2 and Citrix XenDesktop 5. Citrix online plug-in 12.1, 12.0.3, or 11.2 is installed on the user device. Low latency LAN-type network connection between the user's Windows device and the XenDesktop

Virtual Desktop Agent platform Adobe Flash Player 10 or 10.1 is installed on the user device and on the servers running XenApp. Note: If an earlier version of the Flash Player is installed on the user device, or the Flash Player is not installed on the user device, Flash content is rendered on the server. Windows Internet Explorer 7 or 8 with Active X capabilities. The browser must be available to the user device from the server.

Caution: Flash Redirection requires significant interaction between the user device and server components. Therefore, this feature should be used only in environments where security separation between the user device and server is not needed. User devices should be configured to use the Flash Redirection feature only with trusted servers. Flash Redirection requires the Flash Player to be installed on the user device. Therefore, Flash Redirection should be enabled only if the Flash Player itself is secured.

12.5.1.1.1. Configuring HDX MediaStream Flash Redirection on the Server Updated: 2010-09-15 You can configure HDX MediaStream Flash Redirection settings on the server through the Policies node of the Citrix Desktop Studio. You control the settings for the Flash Redirection features through the following Citrix User Policy settings: Flash acceleration Flash event logging Flash latency threshold Flash server-side content fetching whitelist Flash URL blacklist To enable and disable HDX MediaStream Flash Redirection from the server Flash Redirection is enabled on the server for client-side rendering by default. You can enable and disable Flash Redirection from the server through the Citrix User Policy setting Flash acceleration, in the HDX MediaStream for Flash (client side) category. Configure the Flash acceleration setting by selecting Enabled, which is the default, or Disabled. When Enabled is selected, all Flash content from sites not blocked by the Flash URL blacklist is rendered on the user device. If Disabled is selected, all Flash content is rendered on the server. To enable server-side event logging Flash Redirection uses Windows event logging on the server to log Flash events. You can review the event log to determine whether Flash Redirection is being used and gather details about any issues. The following are common to all events logged by Flash Redirection: Flash Redirection reports events to the Application log The Source value is Flash The Category value is None In addition to the Windows event log, on computers with Windows 7 or Windows Vista, a Flash Redirection-specific log appears in the Applications and Services Logs node. If Windows XP is used, Flash Redirection log information is found only in the Windows event log. Configure the Flash event logging setting by selecting Enabled, which is the default, or Disabled. To set the Flash latency threshold Flash Redirection measures the round trip latency between the server and user device the first time an individual browser or browser tab accesses an embedded Flash Player. This measurement includes both the latency of the network connection and any other latency in the data path. If the latency is determined to

be within an acceptable threshold, Flash Redirection is used to render Flash content on the user device. If the latency is above this threshold, the Flash content is rendered on the network server if a Flash player is available there and delivered over the virtual channels. The default threshold setting is 30 milliseconds. Increasing the value over 30 milliseconds may result in a degraded user experience. For typical use, it is best practice not to increase the latency threshold setting. Configure the Flash latency threshold setting by typing a value between 0 and 30 in the Value field. To identify Web sites for server-side content fetching Flash Redirection downloads Flash content to the user device where it is played. The Flash server-side content fetching whitelist setting allows you to specify Web sites whose Flash content can be downloaded to the server then sent to the user device. This setting works in conjunction with the Enable serverside content fetching setting on the user device. This setting is frequently used when the user device does not have direct access to the Internet. The XenApp or XenDesktop server provides that connection. Consider the following when configuring the Flash server-side content fetching whitelist setting: Add the URL of the Flash application; not the top-level .html page that instantiates the Flash Player to the whitelist. Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list. Use a trailing wildcard to allow all child URLs, for example http:// or https:// are used when present, but they are not required. Configure the Flash server-side content fetching whitelist setting by clicking New to add new URLs to the whitelist. Important: The Enable server-side content fetching setting on the user device must also be enabled for the Flash server-side content fetching whitelist on the server to work. To block Web sites from working with HDX MediaStream Flash Redirection Block specified Web sites from playing on user devices with Flash Redirection by adding the sites' URLs to a blacklist. Instead, the blocked Flash content plays on the server. Consider the following when configuring the Flash URL blacklist setting: Add the top-level .html page that instantiates the Flash Player to the blacklist; not the URL of the Flash application. Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list. Use a trailing wildcard to block all child URLs, for example http:// or https:// are used when present, but they are not required. Add sites containing Flash content that does not render correctly on the user device to the blacklist. Configure the Flash URL blacklist setting by clicking New to add new URLs to the blacklist. 12.5.1.1.2. Configuring HDX MediaStream Flash Redirection on the User Device Updated: 2010-08-16 After installation on user devices and in the absence of any overriding policy settings on the client, HDX MediaStream Flash Redirection is ready for use by your users. No further configuration is needed. If you want to change the default settings on the user device, you can do so with the Group Policy Object Editor. To configure HDX MediaStream Flash Redirection on the User Device with Group Policy Objects 1. Create or select an existing Group Policy Object. 2. Import and add the HDX MediaStream for Flash - Client administrative template (HdxFlash-Client. adm), available in: For 32-bit computers: %Program Files%\Citrix\ICA Client\Configuration\language. For 64-bit computers: %Program Files (x86)%\Citrix\ICA Client\Configuration\language.

Note: For details on creating Group Policy Objects and importing and adding templates, see the Microsoft Active Directory documentation at http://www.microsoft.com.

To enable HDX MediaStream Flash Redirection on the user device Configure Enable HDX MediaStream for Flash on the user device to determine whether Flash Redirection is enabled on your users' Windows devices. If no configuration is set, one of the following will occur, based on your users' environment: XenDesktop Viewer is used: Flash Redirection is disabled by default. XenDesktop Viewer is not used: The user receives a dialog box the first time they access Flash content in each session in which the user can enable HDX MediaStream Flash Redirection. Locked Desktop Appliance is used: Flash Redirection is enabled by default. 1. 2. 3. 4. 5. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream for Flash - Client. From the Setting list, select Enable HDX MediaStream for Flash on the user device and click policy setting. Select Not Configured, Enabled, or Disabled. If you selected Enabled, from the Use HDX MediaStream for Flash list, select Always, Ask, or Never. Note: Selecting Ask results in users receiving a dialog box the first time they access Flash content in each session in which the user can enable HDX MediaStream Flash Redirection. If the user does not enable HDX MediaStream Flash Redirection, the Flash content is played on the server. Selecting Always and Never do not result in this dialog box. Select Always to always use HDX MediaStream Flash Redirection to play Flash content on the user device. Select Never to never use HDX MediaStream Flash Redirection and have Flash content play on the server. 6. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

To enable synchronization of the client-side HTTP cookies with the server-side Enable synchronization of the client-side HTTP cookies with the server-side in order to download HTTP cookies from the server. These HTTP cookies are then used for client-side content fetching and available to be read, as needed, by sites containing Flash content. Client-side cookies are not replaced during the synchronization; they remain available if the synchronization policy is later disabled. 1. 2. 3. 4. 5. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream for Flash - Client. From the Setting list, select Enable synchronization of the client-side HTTP cookies with the server-side and click policy setting. Select Not Configured, Enabled, or Disabled. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

To enable server-side content fetching By default, HDX MediaStream Flash Redirection downloads Adobe Flash content to and plays the content on the user device. Enabling server-side content fetching causes the Flash content to download to the server

and then send it to the user device. Unless there is an overriding policy, such as a blacklist, the content will play on the user device. This setting is frequently used when the user device does not have direct access to the Internet. The XenApp or XenDesktop server provides that connection. Important: The Flash server-side content fetching whitelist setting on the server must be enabled and populated with target URLs for server-side content fetching to work. 1. 2. 3. 4. 5. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream for Flash - Client. From the Setting list, select Enable server-side content fetching and click policy setting. Select Not Configured, Enabled, or Disabled. For the policy to take effect: Computer Configuration: Changes take effect as computers in the organizational unit restart. User Configuration: Users in the organizational unit must log off and then log on to the network.

12.5.1.2. Configuring Audio Updated: 2010-08-05 You can configure audio through the Policies node of the Citrix Desktop Studio. You control the settings for the audio features through the following Citrix User Policy settings: Audio quality Client audio redirection Client microphone redirection Audio redirection bandwidth limit Audio redirection bandwidth limit percent

To set audio quality Generally, higher sound quality requires more bandwidth and greater server CPU utilization. You can use sound compression to balance sound quality and overall session performance. Use policy settings to configure the compression levels you want to apply to sound files.

Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. Over dial-up connection Configure the Audio quality setting by choosing from these audio quality levels: Low - for low speed connections. Audio playback consumes a maximum of 11 kbps of bandwidth. With both audio playback and recording total bandwidth consumption is 22 kbps at maximum. Ideal for multimedia conferences when using low speed connections. Medium - optimized for speech. Audio playback consumes a maximum of 16.8 kbps of bandwidth. With both audio playback and recording total bandwidth consumption is 33.6 kbps at maximum. Ideal for multimedia conferences. High - high definition audio. Audio playback consumes a maximum of 96 kbps of bandwidth. With both audio playback and recording total bandwidth consumption is 166 kbps at maximum. Ideal for music and video playback. Note: High definition increases bandwidth requirements by sending more audio data to user devices and increases server CPU utilization.

To disable speakers You can allow users to receive audio from an application on a server through speakers or other sound devices, such as headphones, on their client devices. Client audio mapping can cause excessive load on

the servers and the network. Configure the Client audio redirection setting by choosing Allowed, the default, or Prohibited. Important: When Client audio redirection is disabled, all audio functionality is disabled. To activate user device microphones You can allow users to record audio using input devices such as microphones on the user device. To record audio, the user device needs either a built-in microphone or a device that can be plugged into the microphone jack. If audio is disabled on the client software, this setting has no effect. The Client audio redirection setting must be enabled for an enabled Client microphone redirection to work. For security, users are alerted when servers that are not trusted by their user devices try to access microphones. Users can choose to accept or not accept access. Users can disable the alert on the Citrix online plug-in. Configure the Client microphone redirection setting by choosing Allowed, the default, or Prohibited. To set audio redirection bandwidth limits You can set limits on the allowed bandwidth in kilobits for playing and recording audio. Use the Audio redirection bandwidth limit setting to identify a specific maximum kilobit per second bandwidth for a session. Use the Audio redirection bandwidth limit percent to identify the maximum percentage of the total available bandwidth to be used. If both settings are configured, the one with the lowest bandwidth limit is used. Configure the Audio redirection bandwidth limit and Audio redirection bandwidth limit percent by typing a number in the Value field. 12.5.1.2.1. Avoiding Echo During Multimedia Conferences With HDX RealTime Updated: 2010-08-09 When users take part in audio or video conferences, they may hear an echo in their audio. Echoes usually occur when speakers and microphones are too close to each other. For that reason, Citrix recommends the use of headsets for audio and video conferences. HDX RealTime provides an echo cancellation option, enabled by default, which minimizes echo during a conference. For echo cancellation to be most effective, the user should select either Medium - optimized for speech or Low - for low-speed connections audio quality. The High - high definition audio setting is intended for music playback, rather than conference speech and should be avoided for conferences. The effectiveness of echo cancellation is sensitive to the distance between the speakers and the microphone. These devices must not be too close to each other or too far from each other. Echo cancellation is available with only Citrix Online Plug-in 12.1 and 12.0.3 for Windows and Web Interface 5.3. To enable or disable echo cancellation 1.

For 32-bit computers: On the user device, open the registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancel

For 64-bit computers: On the user device, open the registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAu Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it. 2. In the Value data field, type TRUE or FALSE to enable or disable echo cancellation.

12.5.1.3. HDX RealTime Webcam Video Compression for Video Conferencing Updated: 2011-02-02 HDX RealTime provides a webcam video compression option to improve bandwidth efficiency during video conferencing System Requirements for HDX RealTime Webcam Video Compression To use the HDX RealTime webcam video compression feature: Install Citrix online plug-in 12.1 or 12.0.3 for Windows on the user device. Install Microsoft Office Communications Server 2007 on the XenDesktop site. Install Microsoft Office Communicator 2007 on the Virtual Desktop Agent. Ensure the user device has the appropriate hardware to produce sound. Use the web camera default settings. Install drivers for web cameras on the user device. Where possible, use drivers obtained from the camera manufacturer, rather than from a third party. Note: Only one web camera is supported at a time. If a device has multiple web cameras attached, the cameras are tried in succession until a connection is made. Enable the following Citrix Policy settings in the Citrix Desktop Studio: Client audio redirection HDX MediaStream Multimedia Acceleration Configuring Client Audio redirection Client audio redirection is a Citrix User Policy setting. It allows or prevents the redirection of sound from a hosted application to a sound device on the user device. When enabled, users can also record sound from their devices. Client audio redirection is enabled by default. Configuring HDX MediaStream Multimedia Acceleration HDX MediaStream Multimedia Acceleration is a Citrix Machine Policy setting. Use this setting to allow or prohibit the delivery of streaming audio and video to users. HDX MediaStream Multimedia Acceleration is enabled by default. 12.5.1.4. Improving Responsiveness in Low Bandwidth Conditions by Compressing Colors Updated: 2010-08-12 By default, Citrix's HDX features provide a high quality graphics experience in Windows 7 desktops with an efficient use of bandwidth. If you experience low bandwidth, you can improve responsiveness by enabling extra color compression. This compression results in lower quality graphics, however. When you enable this compression, you also set a bandwidth threshold at which extra color compression occurs. High quality images are delivered as long as the bandwidth remains above the threshold. If the bandwidth drops below the threshold, extra color compression occurs, reducing graphic quality and improving responsiveness. The extra color compression ends and high quality graphics resume when the bandwidth rises above the threshold again. The two extra color compression settings, which you configure on the server through the HDX Policies node of the Citrix Desktop Studio, are: Extra Color Compression Extra Color Compression Threshold To improve responsiveness by compressing colors Extra color compression is disabled by default in order to provide high quality graphics to Windows 7 desktops. You can enable and disable extra color compression from the Desktop Studio through the Citrix User Policy setting Extra Color Compression, in the Image compression category.

When Enabled is selected, extra color compression begins, reducing the bandwidth needed to present graphics, while concurrently reducing the quality of those graphics. If Disabled is selected, high quality graphics are delivered and more bandwidth is consumed. After configuring Extra Color Compression set the bandwidth threshold with the Extra Color Compression Threshold setting. To set a threshold to activate extra color compression After changing the Extra Color Compression setting to Enable, specify a threshold at which the compression occurs. If the bandwidth is below the threshold, extra color compression occurs. If the bandwidth is above the threshold, extra color compression does not occur and high quality graphics are delivered to the users' Windows 7 desktops. Set the Extra Color Compression Threshold setting by typing a kbps rate in the Value field. Alternatively, click Use default value to use 2,000 kbps. 12.5.2. Configuring Time Zone Settings Updated: 2010-08-11 By default, when non-privileged users connect to Windows XP desktops, they see the time zone of the system running the desktop instead of the time zone of their own user device. This does not apply to Windows Vista or Windows 7, which have a separate time zone privilege. To allow Windows XP users to see their local time 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. You can configure time zone settings through Citrix policies. Use the Use local time of client policy setting in the Time Zone Control section of the ICA Policy Settings folder. 12.5.3. Configuring Connection Timers Updated: 2010-08-11 You can configure three connection timers: A maximum connection timer. This setting determines the maximum duration of an uninterrupted connection between a user device and a virtual desktop. Use the Session connection timer and Session connection timer interval policy settings to configure this. A connection idle timer. This setting determines how long an uninterrupted user device connection to a virtual desktop will be maintained if there is no input from the user. Use the Session idle timer and and Session idle timer interval policy settings to configure this. A disconnect timer. This setting determines how long a disconnected, locked virtual desktop can remain locked before the session is logged off. Use the Disconnected session timer and Disconnected session timer interval policy settings to configure this. If you need to update any of these settings, ensure that settings are consistent across your deployment. 12.5.4. Workspace Control in XenDesktop Updated: 2010-11-30 The workspace control feature provides users with the ability to roam. They can disconnect quickly from all running applications and desktops, reconnect to them, and log off from them. Workspace control enables users to move between user devices and gain access to all of their desktops or open applications when they

log on. In a XenDesktop environment, you can use workspace control in two ways: In XenDesktop sessions, workspace control is disabled by default. For instructions on enabling it, see the Web Interface documentation. In XenApp sessions within XenDesktop sessions, workspace control is enabled by default. For information on this scenario, see VM Hosted Apps.

12.5.5. Removing the Shut Down Command Updated: 2010-08-11 Citrix recommends that you apply this Microsoft policy to all XenDesktop users. This prevents users from selecting Shut Down within a XenDesktop session and powering off the desktop, which would require manual intervention from the system administrator. 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. 13. Integrating XenDesktop 5 with Other Products Updated: 2010-10-19 This section provides information on using XenDesktop in conjunction with other products: Microsoft System Center Virtual Machine Manager 2008 VMWare XenApp

13.1. Using Microsoft System Center Virtual Machine Manager 2008 with XenDesktop Updated: 2011-04-26 If you are planning on using Hyper-V with Microsoft System Center Virtual Machine Manager 2008 to provide virtual machines in your XenDesktop environment, you must ensure you configure your system as described in this topic. System Requirements Before you create your VMs, check your environment meets the minimum requirements listed in Requirements for Machine Creation Services. Planning Your Deployment You can deploy Hyper-V in two ways; as a single Hyper-V host deployment or a multiple Hyper-V host deployment. If you are using XenDesktop to create your VMs, rather than selecting an existing catalog, you must configure your Hyper-V deployment in a specific way. The requirements, installation, and configuration instructions for each deployment differ. Installing and Configuring Your Hypervisor Install Windows Server 2008 R2 Hyper-V and System Center Virtual Machine Manager 2008 R2 on your servers. Note that all controllers in your environment must be in the same forest as the System Center Virtual Machine Manager servers. Install the System Center Virtual Machine Manager Console on all controllers in your environment. If you are using XenDesktop to create your VMs, rather than selecting an existing catalog, configure your Hyper-V deployment as follows: For a single Hyper-V host deployment, create a Windows network share that is writeable by the System Center Virtual Machine Manager administrator account on the Hyper-V server. For a multiple Hyper-V host deployment, ensure your Hyper-V hosts are set up in a HyperV Failover Cluster with Cluster Shared Volume storage. On one of your Hyper-V servers, create a Windows network share, that is writeable by the System Center Virtual Machine

Manager administrator account for the Cluster Shared Volume mount point, typically C:\ClusterStorage. For more information about setting up a Hyper-V Failover Cluster with Cluster Shared Volume storage, see your Microsoft documentation.

Note: In both deployments, the Windows Network share is required to allow XenDesktop remote access to storage on the host server, where VMs you create are stored. The account you intend to use to create hosts in XenDesktop must be a member of the relevant Hyper V machines' local administrators group; if this account has only the delegated administrator role in SCVMM, the storage data is not listed in Desktop Studio during the host creation process.

Creating a Master VM Create a master VM to be copied to provide user desktops. Install the Virtual Desktop Agent on the master VM, ensuring you select the option to optimize the desktop. This improves the performance of users' desktops by reconfiguring various Windows features that are incompatible with or unnecessary for virtual desktops. Take a snapshot of the master VM to use as a back-up. For more information, see Preparing a Master VM. Creating Virtual Desktops If you are using XenDesktop to create your VMs, rather than selecting an existing catalog, run the Desktop Deployment wizard to create virtual desktops. Provide the following information: On the Host page, select Microsoft virtualization as the host type and enter the service address as the fully qualified domain name of the host server. Enter the credentials for the administrator account you set up earlier that has permissions to create new VMs. In the Host Details dialog box, select the cluster or standalone host to use when creating your new VMs. Note: You must browse for and select a cluster or standalone host even if you are using a single HyperV host deployment.

13.2. Using VMware with XenDesktop Updated: 2011-03-08 If you are planning on using VMware to provide virtual machines in your XenDesktop environment, you must ensure you configure your system as described in this topic. System Requirements Before you create your VMs, check your environment meets the minimum requirements listed in Requirements for Machine Creation Services. Installing and Configuring Your Hypervisor Install vCenter Server and the appropriate management tools required. Note: XenDesktop does not support VMware vCenter Linked Mode. Create a VMware user account with the following permissions, at the DataCenter level, at a minimum: Note: This account has permissions to create new VMs and is used by XenDesktop to communicate with vCenter. SDK Datastore.AllocateSpace Datastore.Browse User Interface Datastore > Allocate space Datastore > Browse datastore

Datastore.FileManagement Network.Assign Resource.AssignVMToPool System.Anonymous System.Read System.View Task.Create VirtualMachine.Config.AddExistingDisk VirtualMachine.Config.AddNewDisk VirtualMachine.Config.RemoveDisk VirtualMachine.Config.Resource VirtualMachine.Interact.PowerOff VirtualMachine.Interact.PowerOn VirtualMachine.Interact.Reset VirtualMachine.Interact.Suspend VirtualMachine.Inventory.Create VirtualMachine.Inventory.CreateFromExisting VirtualMachine.Inventory.Delete VirtualMachine.Inventory.Register VirtualMachine.Provisioning.Clone

Datastore > Low level file operations Network > Assign network Resource > Assign virtual machine to resource pool Added automatically. Added automatically. Added automatically. Tasks > Create task Virtual machine > Configuration > Add existing disk Virtual machine > Configuration > Add new disk Virtual machine > Configuration > Remove disk Virtual machine > Configuration > Change resource Virtual machine > Interaction > Power Off Virtual machine > Interaction > Power On Virtual machine > Interaction > Reset Virtual machine > Interaction > Suspend Virtual machine > Inventory > Create new Virtual machine > Inventory > Create from existing Virtual machine > Inventory > Remove Virtual machine > Inventory > Register Virtual machine > Provisioning > Clone virtual machine

VirtualMachine.Provisioning.DiskRandomAccess Virtual machine > Provisioning > Allow disk access VirtualMachine.Provisioning.GetVmFiles Virtual machine > Provisioning > Allow virtual machine download Virtual machine > Provisioning > Allow virtual machine files upload

VirtualMachine.Provisioning.PutVmFiles

VirtualMachine.State.CreateSnapshot VirtualMachine.State.RemoveSnapshot VirtualMachine.State.RevertToSnapshot

Virtual machine > State > Create snapshot Virtual machine > State > Remove snapshot Virtual machine > State > Revert to snapshot

If you want XenDesktop to tag VMs you create, the user account must also have the following permissions: SDK User Interface

Global.ManageCustomFields Global > Manage custom attributes Global.SetCustomField Global > Set custom attribute

Tagging excludes any VMs you create using Machine Creation Services from the list of VMs you can use as the base image for creating or updating a catalog, ensuring you use a clean base image for creating new VMs. To protect vSphere communications, Citrix recommends that you use HTTPS rather than HTTP. HTTPS requires digital certificates. Citrix recommends you use a digital certificate issued from a certificate authority in accordance with your organization's security policy. If you are unable to use a digital certificate issued from a certificate authority, and your organization's security policy permits it, you can use the VMware-installed self-signed certificate, with vSphere 4 or 4.1. To do this: 1. Add the fully qualified domain name (FQDN) of the computer running vCenter Server to the hosts file on that server, located at %SystemRoot%/WINDOWS/system32/Drivers/etc/. Note that this step is required only if the FQDN of the computer running vCenter Server is not already present in the domain name system. 2. 3. 4. 5. 6. 7. 8. 9. Open Internet Explorer and enter the address of the computer running vCenter Server as https:// FQDN. Accept the security warnings. Click the Certificate Error in the Security Status bar and select View certificates. Click Install certificate, and then click Next. Select Place all certificates in the following store, and then click Browse. Select the Show physical stores check box. Expand Trusted People and select Local Computer. Click OK, and then click Finish.

Creating a Master VM Create a master VM to be copied to provide user desktops. Install the Virtual Desktop Agent on the master VM, ensuring you select the option to optimize the desktop. This improves the performance of users' desktops by reconfiguring various Windows features that are incompatible with or unnecessary for virtual desktops. Take a snapshot of the master VM to use as a back-up. For more information, see Preparing a Master VM. Creating Virtual Desktops After creating your master VM, run the Desktop Deployment wizard to create virtual desktops, using the following information: On the Host page, select VMWare virtualization as the host type and enter the address of the access point for the vCenter SDK. Enter the credentials for the user account you set up earlier that has permissions to create new VMs. In the Host Details dialog box, select the cluster to use to store the virtual disks for your new VMs.

13.3. Using XenApp with XenDesktop Updated: 2010-10-15 Using XenApp with XenDesktop allows you to separate applications from the virtual desktop, thus reducing the overall number of master 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 virtual 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 virtual desktops. 13.3.1. Application Streaming Compared to Hosting Updated: 2010-08-12 Using XenApp, you can deliver an application to users either by streaming it to the users virtual desktop or by hosting it on the XenApp server. Application streaming simplifies delivery by allowing you to install and configure an application on one file server for delivery to virtual 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 virtual 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 user 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 virtual desktop, the application is installed on the master image; in the second desktop, the application is streamed from XenApp to the local hard disk; 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 XenDesktop controllers are near 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. 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 virtual 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 master 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. If users access any USB drives plugged into their user devices, see USB Drive Mapping Limitations for other considerations to be aware of. 13.3.2. Before Installing XenApp in a XenDesktop Environment Updated: 2011-02-10 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. Do not install XenApp and XenDesktop on the same server. The XenDesktop Controller cannot co-exist on the same computer as XenApp. Use separate databases. XenApp and XenDesktop cannot share the same database; however, the XenApp farm data store and the XenDesktop site database can reside on the same database server. Co-hosting the Delivery Services Console and Desktop Studio. You can install these management snapins on the same computer or on separate computers. XenApp is supplied on the XenDesktop installation media. For information about installing XenApp, see XenApp. A XenApp license is included with some editions of XenDesktop. 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 Licensing Your Product. 13.3.3. Optimizing Application Delivery Updated: 2010-08-12 This section 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 online plug-in and configure applications to appear in the Start menu Install the offline plug-in Set up pass-through authentication Configure a policy to map network drives

13.3.3.1. Installing the Online and Offline Plug-ins Updated: 2010-08-12 Install the online plug-in on the master image, so that when users connect to their virtual desktop, they automatically get the online plug-in. Set up Citrix XenApp so that applications appear in the users Start menu. To the user, these applications appear to behave as if they are installed locally, although the applications are running on the XenApp server. This avoids users having to visit a Web site to start their applications.

For optimal flexibility, also install the offline plug-in on the master image. When both the offline and online plug-ins are installed, you can stream applications from XenApp as well as host them. 13.3.3.2. Setting up Pass-through Authentication Updated: 2010-08-12 Pass-through authentication allows the online plug-in to access a users local Windows user name, password, and domain information and pass it to the XenApp server. This means that users are not prompted to log on to XenApp separately. To enable pass-through authentication, you must configure both the XenApp server and the online plug-in. To enable pass-through authentication in the online plug-in, during installation, choose Enable PassThrough Authentication. For more information, see Online-Plug-in. To enable pass-through authentication on the XenApp server, see XenApp. 13.3.3.3. Mapping Network Drives Using a Policy Updated: 2010-08-12 To ensure users can see their local drives when running applications hosted on XenApp, you must configure a policy on XenApp to map network drives. When a user connects to a virtual desktop, their local drives are mapped; for example, C:(\\Client) (U:). However, when the user then connects to an application hosted on XenApp, these local drives are not re-mapped, so the user does not see them. This is because XenApp does not map network drives by default. To ensure your users local drives are mapped, configure a policy on the XenApp server. For further details see Working With Citrix Policies. 13.3.4. USB Drive Mapping Limitations Updated: 2010-08-12 Mass storage devices can be passed through to applications hosted on XenApp in a XenDesktop session, using client drive mapping. You must also edit the registry on the virtual desktop (HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientDrive) and set the NativeDriveMapping key to True. Users may be unable to access some USB mass storage devices when they are running applications hosted on XenApp. Although users can see and access USB devices within their virtual desktop, some devices may not be mapped on the XenApp server: Some USB devices inserted before the connection to the virtual desktop is established are mapped into applications hosted on XenApp. These devices include printers, PDAs, and scanners. Devices inserted after the hosted application has been launched from within the virtual desktop are not 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 user devices. 14. XenDesktop 5 Reference Information Updated: 2010-10-26 These topics include information about the XenDesktop SDK, the XenDesktopServerSetup.exe file, the XenDesktopVdaSetup.exe file, and the XenDesktop Policy Settings Reference. 14.1. About the XenDesktop SDK Updated: 2011-04-20 This topic introduces the XenDesktop SDK and tells you how to access and use it. Key differences between

the SDK and the Desktop Studio console are also explained. XenDesktop provides an SDK, based on a number of PowerShell version 2.0 snap-ins, that allows you to perform the same tasks as you would with the Desktop Studio console, together with tasks you cannot do such as assigning an IP address to a desktop rather than a user. Note: the PowerShell SDK is not compatible with the SDK associated with previous XenDesktop releases. Terminology The terminology used throughout the XenDesktop SDK differs in places from that in the Desktop Studio and Desktop Director consoles. The following table explains some of the key terminology differences. SDK term Administrators provisioning admin achine administrator m The administrator who owns the images and catalogs and is responsible for provisioning the virtual desktops. broker admin assignment administrator The administrator who takes the virtual desktops provisioned by the machine administrator and allocates them to users, using one or more desktop groups. Console termDescription

Desktop groups permanent allocation type private desktop group A desktop group in which desktops are assigned to individual users. Users return to the same virtual machine even after a restart. random allocationshared desktop group type A desktop group in which desktops are allocated to users on a per session first-come-first-served basis. Catalogs single image pooled This catalog type uses the same disk image for all desktops and does not allow the user to maintain any customization of that image after logging off. Any customization must be maintained in the user profile. This catalog type uses Machine Creation Services. This catalog type is created with a single image but will maintain any user customization of a machine. This catalog uses Machine Creation Services as a simple way to create a large number of desktops. This catalog type enables you to use XenDesktop to manage user desktops that you may have already migrated to VMs in the data center. This catalog type enables you to use XenDesktop to manage user desktops hosted on dedicated physical machines (for example PC blades) or a mixture of physical and virtual machines in the data center. This catalog type enables you to integrate Provisioning services with XenDesktop 5 and benefit from the single image management provided by Provisioning services. This is the catalog type created by the XenDesktop 5 Setup Wizard, which is now part of the Provisioning Services Console. This is effectively a read-only catalog because all the management of the images and machines is completed in the Provisioning Services Console. The assignment/broker administrator will create desktop groups from this catalog type to provide users with desktops.

thin clone

dedicated

power-managed existing unmanaged physical

pvs (provisioning streamed server)

Differences in Policy Rules There are differences between the XenDesktop SDK and the Desktop Studio console in terms of policy rules. Entitlement and assignment policy rules are independent entities in the SDK; in the console, these entities are not visible as they are seamlessly merged with the desktop group. Also, access policy rules are less restrictive in the SDK. Using the XenDesktop SDK The XenDesktop SDK comprises of a number of PowerShell snap-ins which are installed automatically by

the XenDesktop installation wizard when you install either the controller or Desktop Studio components. To access and run the cmdlets: 1. Start a shell in PowerShell 2.0. To start a shell from the console, click Desktop Studio, select the PowerShell tab, and click on Launch PowerShell. You must run the shell or script using an identity that has Citrix administration rights. Although members of the local administrators group on the Controller automatically have full administrative privileges to allow XenDesktop to be installed, Citrix recommends that for normal operation, you create Citrix administrators with the appropriate rights, rather than use the Local administrators account. If you are running on Windows Server 2008 , you must run the shell or script as a Citrix administrator, and not as a member of the local administrators group. 2. To use XenDesktop SDK cmdlets within scripts, set the execution policy in PowerShell. For more information about PowerShell execution policy, see your Microsoft documentation. 3. Add the snap-ins you require into the PowerShell environment using the Add -PSSnapin command in the Windows PowerShell console. For example, type: Add-PSSnapin Citrix.ADIdentity.Admin.V1 To import all the XenDesktop cmdlets, type: Add-PSSnapin Citrix.*.Admin.V1 After importing, you have access to the XenDesktop cmdlets and their associated help. Note: For a complete listing of all help text for the XenDesktop cmdlets, see http://support. citrix.com/article/ctx127254/ Using the Group Policy SDK The Citrix Group Policy SDK allows you to display and configure Group Policy settings and filters. It uses a PowerShell provider to create a virtual drive that corresponds to the machine and user settings and filters. The provider appears as an extension to New-PSDrive. To use the Group Policy SDK, Desktop Studio or the XenDesktop SDK must be installed. Adding the Group Policy SDK 1. To add the Group Policy SDK, type: Add-PSSnapin citrix.common.grouppolicy 2. To access help, type: help New-PSDrive -path localgpo:/ Using the Group Policy SDK 1. To create a virtual drive and load it with settings, type: New-PSDrive <Standard Parameters> [-PSProvider] CitrixGroupPolicy -Controller <string> where -Controller is the fully qualified domain name of a controller in the XenDesktop site you want to connect to and load settings from 14.2. XenDesktopServerSetup.exe Updated: 2010-09-14 The XenDesktopServerSetup.exe file supports the following command-line options for managing the installation and removal of XenDesktop server components. Option /noreboot Description Suppresses restart after installation. The restart occurs only if it is necessary, for example for Microsoft .NET Framework.

/quiet

No user interface appears. 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 installation process can be seen running if you look in Windows Task Manager.

/configure_firewall Opens all the appropriate ports in the Windows firewall ready for use of the selected components. If the user interface is used this option is ignored, because the default action for the user interface is to open the relevant ports, which you can change later on the appropriate page. If you are using a third-party firewall, you must manually open port 80 for Controller services and Web Access, and ports 27000, 7279 and 8082 for the License Server. /remove /removeall Removes the XenDesktop components specified in /components from the computer. Removes all XenDesktop components from the computer.

/components <component_list> The components to install. If /remove is specfied, then the listed components are removed. <component_list> must be a comma-separated list of one or more of the following: CONTROLLER,DESKTOPSTUDIO,DESKTOPDIRECTOR,LICENSESERVER,WEBACCESS If you are doing a user interface installation with specified component groups, the component selection list preselects these components, but you can select other component groups manually. /installdir <location Installs the components in the specified location, which should be an existing to install> empty directory. /tempdir <location>The folder used to hold any temporary files used during installation. /nosql Prevents the installation of SQL Server Express 2008.

14.3. XenDesktopVdaSetup.exe Updated: 2011-03-15 The XenDesktopVdaSetup.exe file supports the following command-line options for managing the installation and removal of Virtual Desktop Agent components. Option /noreboot Description Suppresses restart after installation. The restart occurs only if it is necessary, for example for Microsoft .NET Framework. No user interface appears. This is intended to support unattended installations. When you are using the /quiet option, the only evidence that the product is being installed is that the installation process can be seen running if you look in Windows Task Manager. /remove Removes the Virtual Desktop Agent components specified in /components from the computer. Removes all Virtual Desktop Agent components from the computer.

/quiet

/removeall

/components <component_list> The components to install. If /remove is specfied, then the listed components are removed.

<component_list> must be a comma-separated list of one or more of the following: VDA,PLUGINS /installdir <location to install> /tempdir <location> /site_guid <guid> Installs the components in the specified location, which should be an existing empty directory. The folder used to hold any temporary files used during installation. The Globally Unique Identifier (GUID) of the site Active Directory OU. This is used to associate a virtual desktop with a site if you are using Active Directory based registration. The site GUID is one of the site properties displayed in Desktop Studio. Do not specify both /site_guid and /controllers. /controllers <controller url> A space-separated list of controller names to which the virtual desktop can connect. The list must be enclosed within quotation marks. Do not specify both /site_guid and /controllers. /xa_server_location <xa server url> /reconfigure The URL for the XenApp server from which applications are delivered.

Reconfigure the virtual desktop. If you specify this option without /quiet, the user interface for reconfiguring the virtual desktop appears. If you specify it with /quiet, you must also use /portnumber.

/portnumber <port number>

The port number to enable if you want to move applications to a different port. The previous port is disabled unless it is port 80. Use this option only in combination with /reconfigure.

/enable_remote_assistance

Enables Windows Remote Assistance for shadowing and adds Remote Assistance to the firewall exceptions if the Windows firewall is enabled. If you are using a different firewall you must use /reconfigure to update the firewall exceptions.

/enable_remote_management Enables and configures Windows Remote Management for reporting metrics to Desktop Studio. The relevant port (port 5985 for Windows Remote Management 2.0, or port 80 for Windows Remote Management 1.1) is also added to the firewall exceptions if the Windows firewall is enabled. If you are using a different firewall you must use /reconfigure to update the firewall exceptions. /forcewddmremove Downgrades the WDDM driver, if present. If you have not specified this option and the WDDM driver is detected, a warning dialog appears and prompts the user to continue or quit the installation. If this is a silent installation, the installation process stops and an error message appears. /nowinrm Prevents installation of Windows Remote Management.

If Windows Remote Management is not already installed and you have not specified this option, a warning dialog appears during installation and the user is prompted to continue or quit. If this is a silent installation, the installation process stops and an error message appears. /enable_hdx_ports Opens HDX ports in the Windows firewall. If you are using a third-party firewall, you must manually reconfigure the firewall as described in To configure firewalls manually, using /reconfigure. /optimize Turns on virtual machine optimization during installation.

14.4. Policy Settings Reference Updated: 2010-07-23 Policies contain settings that are applied when the policy is enforced. You configure these settings using Desktop Studio in XenDesktop or Group Policy Editor in Windows, depending on whether or not you use Active Directory in your XenDesktop environment. The descriptions for each policy setting include the following information: The name of the policy setting The Citrix products to which the policy setting applies The additional settings, if applicable, required to enable a particular feature Other settings that are similar to the policy setting in question, if applicable

14.4.1. Policy Settings: Quick Reference Table Updated: 2010-11-30 The following tables present settings you can configure within a policy. Find the task you want to perform in the left column, then locate its corresponding setting in the right column. Graphics & Multimedia Task: Control the amount of memory allocated for displaying graphics in a session Control how a user's display degrades in response to memory limits and whether or not to notify the user Use this policy setting: Display memory limit

Display mode degrade preference Notify user when display mode is degraded

Control compression of images for use in sessions of limited bandwidth

Lossy compression level Lossy compression level threshold value Progressive compression level Progressive compression threshold value

Control whether or not Flash content is rendered in sessions Control whether or not Web sites can display Flash content when accessed in sessions

Flash acceleration

Flash server-side content fetching whitelist Flash URL blacklist

Desktop UI Task: Control whether or not Desktop wallpaper is used in users' sessions View window contents while a window is dragged Use this policy setting: Desktop wallpaper

View window contents while dragging

User Devices To limit bandwidth used for: Client audio mapping Use this policy setting: Audio redirection bandwidth limit, or Audio redirection bandwidth limit percent

Cut-and-paste using local clipboard

Clipboard redirection bandwidth limit, or Clipboard redirection bandwidth limit percent

Devices connected to a local COM port

COM port redirection bandwidth limit, or COM port redirection bandwidth limit percent

Access in a session to local client drives

File redirection bandwidth limit, or File redirection bandwidth limit percent

Printers connected to the client LPT port

LPT port redirection bandwidth limit, or LPT port redirection bandwidth limit percent

Client session Printing

Overall session bandwidth limit

Printer redirection bandwidth limit, or Printer redirection bandwidth limit percent

Audio Task: Control whether or not to allow audio input from microphones on the user device Control audio quality on the user device Control audio mapping to speakers on the user device Use this policy setting: Client microphone redirection

Audio quality Client audio redirection

User drives and devices Task: Control whether or not drives on the user device are connected when users log on to the server Control how drives map from the user device Improve the speed of writing and copying files to a client disk over a WAN Control whether or not user devices attached to local COM ports are available in a session Control whether or not client printers attached to local LPT ports are available in a session Control whether or not users' local hard drives are available in a session Use this policy setting: Auto connect client drives

Client drive redirection Use asynchronous writes

Client COM port redirection

Client LPT port redirection

Client fixed drives, and Client drive redirection

Control whether or not users' local floppy drives are available in a session

Client floppy drives, and Client drive redirection

Control whether or not users' network drives are available in a session

Client network drives, and Client drive redirection

Control whether or not users' local CD, DVD, or Bluray drives are available in a session

Client optical drives, and Client drive redirection

Control whether or not users' local removable drives are available in a session

Client removable drives, and Client drive redirection

Control cut-and-paste data transfer between the server and the local clipboard

Client clipboard redirection

Printing Task: Control creation of client printers on the user device Use this policy setting: Auto-create client printers, and Client printer redirection

Allow use of legacy printer names and preserve backward compatibility with prior versions

Client printer names

of the server Control the location where printer properties are stored Control whether print requests are processed by the client or the server Control whether or not users can access printers connected to their user devices Control installation of native Windows drivers when automatically creating client and network printers Control when to use the Universal Printer Driver Choose a printer based on a roaming users session information Printer properties retention Direct connections to print servers

Client printer redirection

Automatic installation of in-box printer drivers

Universal printing Default printer

Single Sign-On Task: Identify which credential repository to use when using Single Sign-On Allow or prevent use of Single Sign-On Use this policy setting: Single Sign-On central store

Single Sign-On

14.4.2. ICA Policy Settings Updated: 2010-07-01 The ICA section contains policy settings related to ICA listener connections, mapping to the Clipboard and custom channels, connecting to server desktops, and controlling the launch behavior of non-published programs. ICA listener connection timeout This setting specifies the maximum wait time for a connection using the ICA protocol to be completed. By default, the maximum wait time is 120000 milliseconds, or two minutes. ICA listener port number This setting specifies the TCP/IP port number used by the ICA protocol on the server. The default port number is 1494. The port number must be in the range of 065535 and must not conflict with other well-known port numbers. If you change the port number, restart the server for the new value to take effect. If you change the port number on the server, you must also change it on every plug-in that connects to the server. Client clipboard redirection This setting allows or prevents the Clipboard on the user device to be mapped to the Clipboard on the server. By default, clipboard redirection is allowed. To prevent cut-and-paste data transfer between a session and the local Clipboard, select Prohibit. Users can still cut and paste data between applications running in sessions. After allowing this setting, configure the maximum allowed bandwidth the Clipboard can consume in a

client connection using the Clipboard redirection bandwidth limit or the Clipboard redirection bandwidth limit percent settings. Related Policy Settings Clipboard redirection bandwidth limit Clipboard redirection bandwidth limit percent

14.4.2.1. Audio Policy Settings Updated: 2010-03-10 The Audio section contains policy settings you can configure to permit user devices to send and receive audio in sessions without reducing performance. Audio Quality Use the projected figures for each level of sound quality to calculate the bandwidth potentially consumed in connections to specific servers. For example, if 25 users record at Medium on one server, the bandwidth used in the connections to that server is over 52,500 bytes per second. Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the bandwidth consumption is doubled. To control sound quality, choose one of the following options: Select Low - for low speed connections for low-bandwidth connections. Sounds sent to the client are compressed up to 16 Kbps. This compression results in a significant decrease in the quality of the sound but allows reasonable performance for a low-bandwidth connection. With both audio playback and recording total bandwidth consumption is 22 Kbps at maximum. Select Medium - optimized for speech for most LAN-based connections. Sounds sent to the client are compressed up to 64 Kbps. With both audio playback and recording total bandwidth consumption is 33.6 Kbps at maximum. Select High - high definition audio for connections where bandwidth is plentiful and sound quality is important. Clients can play sound at its native rate. Sounds can use up to 1.3 Mbps of bandwidth to play clearly. Transmitting this amount of data can result in increased CPU utilization and network congestion. Related Policy Settings Audio redirection bandwidth limit Audio redirection bandwidth limit percent

Client audio redirection This setting allows or prevents applications hosted on the server to play sounds through a sound device installed on the user device. This setting also allows or prevents users from recording audio input. After allowing this setting, you can limit the bandwidth consumed by playing or recording audio. Limiting the amount of bandwidth consumed by audio can improve application performance but may also degrade audio quality. Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the bandwidth consumption doubles. To specify the maximum amount of bandwidth, configure the Audio redirection bandwidth limit or the Audio redirection bandwidth limit percent settings. Related Policy Settings Audio redirection bandwidth limit Audio redirection bandwidth limit percent Client microphone redirection

Client microphone redirection This setting enables or disables client microphone redirection. When enabled, users can use microphones to record audio input in a session. For security, users are alerted when servers that are not trusted by their devices try to access microphones. Users can choose to accept or not accept access. Users can disable the alert on the Citrix online plug-in. If the Client audio redirection setting is disabled on the user device, this rule has no effect. Related Policy Settings Client audio redirection Audio redirection bandwidth limit Audio redirection bandwidth limit percent

14.4.2.2. Auto Client Reconnect Policy Settings Updated: 2010-03-10 The Auto Client Reconnect section contains policy settings for controlling automatic reconnection of sessions. Auto client reconnect This setting allows or prevents automatic reconnection by the same client after a connection has been interrupted. By default, automatic reconnection is allowed. Allowing automatic reconnection allows users to resume working where they were interrupted when a connection was broken. Automatic reconnection detects broken connections and then reconnects the users to their sessions. However, automatic reconnection can result in a new session being launched (instead of reconnecting to an existing session) if a plug-ins cookie, containing the key to the session ID and credentials, is not used. The cookie is not used if it has expired, for example, because of a delay in reconnection, or if credentials must be reentered. Auto client reconnect is not triggered if users intentionally disconnect. Auto client reconnect authentication This setting requires authentication for automatic client reconnections. By default, authentication is not required. When a user initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory and creates a cookie containing the encryption key which is sent to the plug-in. When this setting is added, cookies are not used. Instead, XenApp displays a dialog box to users requesting credentials when the plug-in attempts to reconnect automatically. Auto client reconnect logging This setting enables or disables recording of auto client reconnections in the event log. By default, logging is disabled. When logging is enabled, the servers System log captures information about successful and failed automatic reconnection events. The server farm does not provide a combined log of reconnection events for all servers. 14.4.2.3. Bandwidth Policy Settings Updated: 2010-07-01 The Bandwidth section contains policy settings you can configure to avoid performance problems related to client session bandwidth use. Audio redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for playing or recording audio in a user session. If you enter a value for this setting and a value for the Audio redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied. Audio redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth limit for playing or recording audio as a percent of the total session bandwidth. If you enter a value for this setting and a value for the Audio redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions. Clipboard redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for data transfer between a session and the local Clipboard. If you enter a value for this setting and a value for the Clipboard redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied. Clipboard redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth for data transfer between a session and the local Clipboard as a percent of the total session bandwidth. If you enter a value for this setting and a value for the Clipboard redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions. COM port redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a COM port in a client connection. If you enter a value for this setting and a value for the COM port redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied. COM port redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth for accessing COM ports in a client connection as a percent of the total session bandwidth. If you enter a value for this setting and a value for the COM port redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions. File redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a client drive in a user session. If you enter a value for this setting and a value for the File redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) takes effect. File redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth limit for accessing client drives as a percent of the total session bandwidth. If you enter a value for this setting and a value for the File redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions. LPT port redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for print jobs using an LPT port in a single user session. If you enter a value for this setting and a value for the LPT port redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied.

LPT port redirection bandwidth limit percent This setting specifies the bandwidth limit for print jobs using an LPT port in a single client session as a percent of the total session bandwidth. If you enter a value for this setting and a value for the LPT port redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions.

Overall session bandwidth limit This setting specifies the total amount of bandwidth available in kilobits per second for user sessions. Limiting the amount of bandwidth consumed by a client connection can improve performance when other applications outside the client connection are competing for limited bandwidth. Printer redirection bandwidth limit This setting specifies the maximum allowed bandwidth in kilobits per second for accessing client printers in a user session. If you enter a value for this setting and a value for the Printer redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied. Printer redirection bandwidth limit percent This setting specifies the maximum allowed bandwidth for accessing client printers as a percent of the total session bandwidth. If you enter a value for this setting and a value for the Printer redirection bandwidth limit setting, the most restrictive setting (with the lower value) is applied. If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total amount of bandwidth available for client sessions.

14.4.2.4. Desktop UI Policy Settings Updated: 2011-01-13 The Desktop UI section contains policy settings that control visual effects, such as desktop wallpaper, menu animations, and drag-and-drop images, to manage the bandwidth used in client connections. You can improve application performance on a WAN by limiting bandwidth usage. These policy settings are applicable to the following Citrix products: XenApp 6.0 XenDesktop 5.0

Desktop wallpaper This setting allows or prevents wallpaper showing in user sessions. By default, user sessions can show wallpaper. To turn off desktop wallpaper and reduce the bandwidth required in user sessions, select Prohibited when adding this setting to a policy. Menu animation This setting allows or prevents menu animation in user sessions. By default, menu animation is allowed. Menu animation is a Microsoft personal preference setting that causes a menu to appear after a short delay, either by scrolling or fading in. When this policy setting is set to Allowed, an arrow icon appears at the bottom of the menu. The menu appears when you mouse over that arrow. View window contents while dragging This setting allows or prevents the display of window contents when dragging a window across the screen. By default, viewing window contents is allowed.

When set to Allowed, the entire window appears to move when you drag it. When set to Prohibited, only the window outline appears to move until you drop it. 14.4.2.5. End User Monitoring Policy Settings Updated: 2010-03-11 The End User Monitoring section contains policy settings for measuring session traffic. ICA round trip calculation This setting determines whether or not ICA round trip calculations are performed for active connections. By default, calculations for active connections are enabled. By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates user interaction. This delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for ICA traffic. ICA round trip calculation interval (Seconds) This setting specifies the frequency, in seconds, at which ICA round trip calculations are performed. By default, ICA round trip is calculated every 15 seconds. ICA round trip calculations for idle connections This setting determines whether or not ICA round trip calculations are performed for idle connections. By default, calculations are not performed for idle connections. By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates user interaction. This delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for ICA traffic. 14.4.2.6. File Redirection Policy Settings Updated: 2010-07-01 The File Redirection section contains policy settings relating to client drive mapping and client drive optimization. Auto connect client drives This setting allows or prevents automatic connection of client drives when users log on. By default, automatic connection is allowed. When allowing this setting, make sure to enable the settings for the drive types you want automatically connected. For example, to allow automatic connection of users' CD-ROM drives, configure this setting and the Client optical drives setting. Related Policy Settings Client drive redirection Client floppy drives Client optical drives Client fixed drives Client network drives Client removable drives

Client drive redirection This setting enables or disables drive redirection to and from the user device. When enabled, users can save files to all their client drives. When disabled, all file redirection is prevented, regardless of the state of the individual file redirection settings such as Client floppy drives and Client network drives. By default, file redirection is enabled. Related Policy Settings

Client floppy drives Client optical drives Client fixed drives Client network drives Client removable drives

Client fixed drives This setting allows or prevents users from accessing or saving files to fixed drives on the user device. By default, accessing client fixed drives is allowed. When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are disabled, client fixed drives are not mapped and users cannot access these drives manually, regardless of the state of the Client fixed drives setting. To ensure fixed drives are automatically connected when users log on, configure the Auto connect client drives setting. Related Policy Settings Client drive redirection Auto connect client drives

Client floppy drives This setting allows or prevents users from accessing or saving files to floppy drives on the user device. By default, accessing client floppy drives is allowed. When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are disabled, client floppy drives are not mapped and users cannot access these drives manually, regardless of the state of the Client floppy drives setting. To ensure floppy drives are automatically connected when users log on, configure the Auto connect client drives setting. Related Policy Settings Client drive redirection Auto connect client drives

Client network drives This setting allows or prevents users from accessing and saving files to network (remote) drives through the user device. By default, accessing client network drives is allowed. When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are disabled, client network drives are not mapped and users cannot access these drives manually, regardless of the state of the Client network drives setting. To ensure network drives are automatically connected when users log on, configure the Auto connect client drives setting. Related Policy Settings Client drive redirection Auto connect client drives

Client optical drives This setting allows or prevents users from accessing or saving files to CD-ROM, DVD-ROM, and BD-ROM drives on the user device. By default, accessing client optical drives is allowed.

When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are disabled, client optical drives are not mapped and users cannot access these drives manually, regardless of the state of the Client optical drives setting. To ensure optical drives are automatically connected when users log on, configure the Auto connect client drives setting. Related Policy Settings Client drive redirection Auto connect client drives

Client removable drives This setting allows or prevents users from accessing or saving files to USB drives on the user device. By default, accessing client removable drives is allowed. When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are disabled, client removable drives are not mapped and users cannot access these drives manually, regardless of the state of the Client removable drives setting. To ensure removable drives are automatically connected when users log on, configure the Auto connect client drives setting. Related Policy Settings Client drive redirection Auto connect client drives

Use asynchronous writes This setting enables or disables asynchronous disk writes. By default, asynchronous writes are disabled. Asynchronous disk writes can improve the speed of file transfers and writing to client disks over WANs, which are typically characterized by relatively high bandwidth and high latency. However, if there is a connection or disk fault, the client file or files being written may end in an undefined state. If this happens, a pop-up window informs the user of the files affected. The user can then take remedial action, such as restarting an interrupted file transfer on reconnection or when the disk fault is corrected. Citrix recommends enabling asynchronous disk writes only for users who need remote connectivity with good file access speed and who can easily recover files or data lost in the event of connection or disk failure. When enabling this setting, make sure that the Client drive redirection setting is present and set to Allowed . If this setting is disabled, asynchronous writes will not occur. Related Policy Settings Client drive redirection

Preserve client drive letters This setting enables or disables mapping of client drives to the same drive letter in the session. By default, client drive letters are not preserved. When enabling this setting, make sure the Client drive redirection setting is present and set to Allowed. Related Policy Settings Client drive redirection 14.4.2.7. Graphics Policy Settings Updated: 2010-11-09 The Graphics section contains policy settings for controlling how images are handled in user sessions.

Display memory limit This setting specifies the maximum video buffer size in kilobytes for the session. By default, the display memory limit is 32768 kilobytes. Specify an amount in kilobytes from 128 to 65536. Using more color depth and higher resolution for connections requires more memory. If the memory limit is reached, the display degrades according to the Display mode degrade preference setting. Display mode degrade preference This setting specifies that color depth or resolution degrades first when the session display memory limit is reached. When the session memory limit is reached, you can reduce the quality of displayed images by choosing whether color depth or resolution is degraded first. When color depth is degraded first, displayed images use fewer colors. When resolution is degraded first, displayed images use fewer pixels per inch. By default, color depth is degraded first. To notify users when either color depth or resolution are degraded, configure the Notify user when display mode is degraded setting. Image caching This setting enables or disables caching of images in sessions. When needed, the images are retrieved in sections to make scrolling smoother. By default, image caching is enabled. Max frames per second This setting specifies the maximum number of frames per second sent to the client from the virtual desktop. By default, this is set to 24 frames per second. Setting a high number of frames per second improves the user experience, but requires more bandwidth. Maximum allowed color depth This setting specifies the maximum color depth allowed for a session. By default, the maximum allowed color depth is 32 bits per pixel. Setting a high color depth requires more memory. To degrade color depth when the memory limit is reached, configure the Display mode degrade preference setting. When color depth is degraded, displayed images use fewer colors. Notify user when display mode is degraded This setting displays a brief explanation to the user when the color depth or resolution is degraded. By default, notifying users is disabled. Queuing and tossing This setting discards queued images that are replaced by another image. This improves response when graphics are sent to the client. Configuring this setting can cause animations to become choppy due to dropped frames. By default, queuing and tossing is enabled. 14.4.2.7.1. Image Compression Policy Settings Updated: 2010-11-09 The Image compression section contains settings that enable you to remove or alter compression. When client connections are limited in bandwidth, downloading images without compression can be slow. Extra color compression This setting controls the degree of extra color compression used on images delivered over client connections

thta are limited in bandwidth, improving responsiveness by reducing the quality of displayed images. When enabled Extra Color Compression is applied only when the client connection bandwidth is below the Extra Color Compression Threshold value. When the client connection bandwidth is above the threshold value or Disabled is selected, Extra Color Compression is not applied. Related Policy Settings Extra color compression threshold Extra color compression threshold This setting represents the maximum bandwidth in kilobits per second for a connection below which extra color compression is applied. If the client connection bandwidth drops below the set value, extra color compression, if enabled, is applied. By default, the threshold value is 2000 kilobits per second. Related Policy Settings Extra color compression

Lossy compression level This setting controls the degree of lossy compression used on images delivered over client connections that are limited in bandwidth. In such cases, displaying images without compression can be slow. By default, medium compression is selected. For improved responsiveness with bandwidth-intensive images, use high compression. Where preserving image data is vital; for example, when displaying X-ray images where no loss of quality is acceptable, you may not want to use lossy compression. Related Policy Settings Lossy compression threshold value Progressive compression level Progressive heavyweight compression level

Lossy compression threshold value This setting represents the maximum bandwidth in kilobits per second for a connection to which lossy compression is applied. By default, the threshold value is 2000 kilobits per second. Adding the Lossy compression level setting to a policy and including no specified threshold can improve the display speed of high-detail bitmaps, such as photographs, over a LAN. Related Policy Settings Lossy compression level

Progressive compression level This setting provides a less detailed but faster initial display of images. The more detailed image, defined by the normal lossy compression setting, appears when it becomes available. Use very high or ultra high compression for improved viewing of bandwidth-intensive graphics such as photographs. For progressive compression to be effective, its compression level must be higher than the Lossy compression level setting; by default, progressive compression is not applied. Note: The increased level of compression associated with progressive compression also enhances the interactivity of dynamic images over client connections. The quality of a dynamic image, such as a rotating three-dimensional model, is temporarily decreased until the image stops moving, at which time the normal lossy compression setting is applied. Related Policy Settings Progressive compression threshold value Lossy compression level

Progressive heavyweight compression

Progressive compression threshold value The maximum bandwidth in kilobits per second for a connection to which progressive compression is applied. This is applied only to client connections under this bandwidth. By default, the threshold value is 1440 kilobits per second. Related Policy Settings Progressive compression level

Progressive heavyweight compression This setting enables or disables reducing bandwidth beyond progressive compression without losing image quality by using a more advanced, but more CPU-intensive, graphical algorithm. By default, progressive heavyweight compression is disabled. If enabled, heavyweight compression applies to all lossy compression settings. It is supported on the Citrix online plug-in but has no effect on other plugins. Related Policy Settings Lossy compression level Progressive compression level

14.4.2.8. Keep Alive Policy Settings Updated: 2010-06-07 The Keep Alive section contains policy settings for managing ICA keep-alive messages. ICA keep alive timeout This setting specifies the number of seconds between successive ICA keep-alive messages. By default, the interval between keep-alive messages is 60 seconds. Specify an interval between 1-3600 seconds in which to send ICA keep-alive messages. Do not configure this setting if your network monitoring software is responsible for closing inactive connections. If using Citrix Access Gateway, set keep-alive intervals on the Access Gateway to match the keep-alive intervals on XenApp. ICA keep alives This setting enables or disables sending ICA keep-alive messages periodically. By default, keep-alive messages are not sent. Enabling this setting prevents broken connections from being disconnected. If XenApp detects no activity, this setting prevents Remote Desktop Services from disconnecting the session. XenApp sends keepalive messages every few seconds to detect if the session is active. If the session is no longer active, XenApp marks the session as disconnected. ICA Keep-Alive does not work if you are using Session Reliability. Configure ICA Keep-Alive only for connections that are not using Session Reliability. Related Policy Settings Session reliability connections 14.4.2.9. Multimedia Policy Settings Updated: 2010-07-01 The Multimedia section contains policy settings for managing streaming audio and video in user sessions.

HDX MediaStream Multimedia Acceleration This setting controls and optimizes the way XenApp servers deliver streaming audio and video to users. By default, this setting is allowed. Allowing this setting increases the quality of audio and video rendered from the server to a level that compares with audio and video played locally on a client device. XenApp streams multimedia to the client in the original, compressed form and allows the client device to decompress and render the media. HDX MediaStream multimedia acceleration optimizes multimedia files that are encoded with codecs that adhere to Microsofts DirectShow, DirectX Media Objects (DMO), and Media Foundation standards. To play back a given multimedia file, a codec compatible with the encoding format of the multimedia file must be present on the client device. By default, audio is disabled on the Citrix online plug-in. To allow users to run multimedia applications in ICA sessions, turn on audio or give the users permission to turn on audio themselves in their plug-in interface. Select Prohibited only if playing media using multimedia acceleration appears worse than when rendered using basic ICA compression and regular audio. This is rare but can happen under low bandwidth conditions; for example, with media in which there is a very low frequency of key frames. HDX MediaStream Multimedia Acceleration default buffer size This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size is 5 seconds. HDX MediaStream Multimedia Acceleration default buffer size use This setting enables or disables using the buffer size specified in the HDX MediaStream Multimedia Acceleration default buffer size setting. By default, the buffer size specified is used. 14.4.2.9.1. HDX MediaStream for Flash (client side) Policy Settings Updated: 2010-09-15 The HDX MediaStream for Flash (client side) section contains policy settings for handling Flash content in user sessions. Flash acceleration This setting enables or disables Flash content rendering on user devices instead of the server. By default, client-side Flash content rendering is enabled. When enabled, this setting reduces network and server load by rendering Flash content on the user device. Additionally, the Flash URL blacklist setting forces Flash content from specific Web sites to be rendered on the server. When this setting is disabled, Flash content from all Web sites, regardless of URL, is rendered on the server. To allow only certain Web sites to render Flash content on the user device, configure the Flash serverside content fetching whitelist setting. Flash event logging This setting allows or prevents Flash events to be recorded in the Windows application event log. By default, logging is allowed. Flash latency threshold This setting specifies a threshold between 0-30 milliseconds to determine where Adobe Flash content is rendered. By default, the threshold is 30 milliseconds. During startup, HDX MediaStream for Flash measures the current latency between the server and user device. If the latency is under the threshold, HDX MediaStream for Flash is used to render Flash content on the user device. If the latency is above the threshold, the network server renders the content if an Adobe Flash

player is available there. Flash server-side content fetching whitelist This setting specifies Web sites whose Flash content is allowed to be downloaded to the server and then transferred to the user device for rendering. Flash content on unlisted Web sites is downloaded directly to the client. When adding this setting to a policy, make sure the Flash acceleration setting is present and set to Enabled . Otherwise, Web sites listed in the whitelist are ignored. Listed URL strings do not need the https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid at the beginning and end of a URL. Flash URL blacklist This setting specifies Web sites whose Flash content is rendered on the server. Flash content on unlisted Web sites is rendered on the user device. When adding this setting to a policy, make sure the Flash acceleration setting is present and set to Enabled . Otherwise, Web sites listed in the URL blacklist are ignored. Listed URL strings do not need the https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid at the beginning and end of a URL. 14.4.2.9.2. HDX Multimedia for Flash (server side) Policy Settings Updated: 2010-07-14 The HDX Multimedia for Flash (server side) section contains policy settings for handling Flash content on session hosts. Flash quality adjustment This setting adjusts the quality of Flash content rendered on session hosts to improve performance. By default, Flash content is optimized for low bandwidth connections only. 14.4.2.10. Ports Policy Settings Updated: 2010-03-10 The Ports section contains policy settings for client LPT and COM port mapping. Auto connect client COM ports This setting enables or disables automatic connection of COM ports on user devices when users log on to the farm. By default, client COM ports are not automatically connected. Related Policy Settings Client COM port redirection

Auto connect client LPT ports This setting enables or disables automatic connection of LPT ports on user devices when users log on to the farm. By default, client LPT ports are not connected automatically. Related Policy Settings Client LPT port redirection

Client COM port redirection This setting allows or prevents access to COM ports on the user device. By default, COM port redirection is allowed.

Related Policy Settings Auto connect client COM ports COM port redirection bandwidth limit COM port redirection bandwith limit percent

Client LPT port redirection This setting allows or prevents access to LPT ports on the user device. By default, LPT port redirection is allowed. LPT ports are used only by legacy applications that send print jobs to the LPT ports and not to the print objects on the client device. Most applications today can send print jobs to printer objects. This policy setting is necessary only for servers that host legacy applications that print to LPT ports. Related Policy Settings Auto connect client LPT ports LPT port redirection bandwidth limit LPT port redirection bandwith limit percent

14.4.2.11. Printing Policy Settings Updated: 2011-01-14 The Printing section contains policy settings for managing client printing. These policy settings are applicable to the following Citrix products: XenApp 6.0 XenDesktop 5.0

Client printer redirection This setting allows or prevents client printers to be mapped to a server when a user logs on to a session. By default, client printer mapping is allowed. Related Policy Settings Auto-create client printers

Default printer This setting specifies how the default printer on the user device is established in a session. By default, the user's current printer is used as the default printer for the session. To use the current Remote Desktop Services or Windows user profile setting for the default printer, select Do not adjust the users default printer. If you choose this option, the default printer is not saved in the profile and it does not change according to other session or client properties. The default printer in a session will be the first printer autocreated in the session, which is either: The first printer added locally to the Windows server in Control Panel > Printers The first autocreated printer, if there are no printers added locally to the server You can use this option to present users with the nearest printer through profile settings (known as Proximity Printing). Printer auto-creation event log preference This setting specifies the events that are logged during the printer auto-creation process. You can choose to log no errors or warnings, only errors, or errors and warnings. By default, errors and warnings are logged. An example of a warning is an event in which a printers native driver could not be installed and the

universal printer driver is installed instead. To allow universal printer drivers to be used in this scenario, configure the Universal printing setting to Use universal printing only or Use universal printing only if requested driver is unavailable. Related Policy Settings Universal printing

Session printers This setting specifies the network printers to be auto-created in a session. By default, no printers are specified. To add printers, enter the UNC path of the printer you want to auto-create. After adding the printer, you can apply customized settings for the current session at every logon. Wait for printers to be created (desktop) This setting allows or prevents a delay in connecting to a session so that desktop printers can be auto-created. By default, a connection delay does not occur. This setting does not apply to published applications or published desktops. 14.4.2.11.1. Client Printers Policy Settings Updated: 2010-06-07 The Client Printers section contains policy settings for client printers, including settings to autocreate client printers, use legacy printer names, retain printer properties, and connect to print servers. Auto create client printers This setting specifies the client printers that are auto-created. This setting overrides default client printer auto-creation settings. By default, all client printers are auto-created. This setting takes effect only if the Client printer redirection setting is present and set to Allowed. When adding this setting to a policy, select an option: Auto-create all client printers automatically creates all printers on a user device. Auto-create the clients default printer only automatically creates only the printer selected as the default printer on the user device. Auto-create local (non-network) client printers only automatically creates only printers directly connected to the user device through an LPT, COM, USB, or other local port. Do not auto-create client printers turns off autocreate for all client printers when users log on. This causes the Remote Desktop Services settings for autocreating client printers to override this setting in lower priority policies. Related Policy Settings Client printer redirection

Client printer names This setting selects the naming convention for auto-created client printers. By default, standard printer names are used. For most configurations, select Standard printer names which are similar to those created by native Remote Desktop Services, such as HPLaserJet 4 from clientname in session 3. Select Legacy printer names to use old-style client printer names and preserve backward compatibility for users or groups using MetaFrame Presentation Server 3.0 or earlier. An example of a legacy printer name is Client/clientname#/HPLaserJet 4. Because this option is less secure, use it only to provide backward compatibility for users or groups using MetaFrame Presentation Server 3.0 or earlier. Direct connections to print servers

This setting enables or disables direct connections from the host to a print server for client printers hosted on an accessible network share. By default, direct connections are enabled. Allow direct connections if the network print server is not across a WAN from the host. Direct communication results in faster printing if the network print server and host server are on the same LAN. If this setting is disabled, print jobs are routed through the user device, where it is redirected to the network print server. Use this option if the network is across a WAN or has substantial latency or limited bandwidth. Data sent to the user device is compressed, so less bandwidth is consumed as the data travels across the WAN. If two network printers have the same name, the printer on the same network as the user device is used. Printer properties retention This setting specifies whether or not to store printer properties and where to store them. By default, the system determines if printer properties are to be stored on the user device, if available, or in the user profile. When adding this setting to a policy, select an option: Held in profile only if not saved on client allows the system to determine where printer properties are stored. Printer properties are stored either on the client device, if available, or in the user profile. Although this option is the most flexible, it can also slow logon time and use extra bandwidth for system-checking. Saved on the client device only is for user devices that have a mandatory or roaming profile that is not saved. Choose this option only if all the servers in your farm are running XenApp 5 and above and your users are using Citrix XenApp online plug-in versions 9.x and above. Retained in user profile only is for user devices constrained by bandwidth (this option reduces network traffic) and logon speed or for users with legacy plug-ins. This option stores printer properties in the user profile on the server and prevents any properties exchange with the client device. Use this option with MetaFrame Presentation Server 3.0 or earlier and MetaFrame Presentation Server Client 8.x or earlier. Note that this is applicable only if a Remote Desktop Services roaming profile is used.

Retained and restored client printers This setting enables or disables the retention and re-creation of printers on the user device. By default, client printers are auto-retained and auto-restored. Retained printers are user-created printers that are created again, or remembered, at the start of the next session. When XenApp recreates a retained printer, it considers all policy settings except the Autocreate client printers setting. Restored printers are printers fully customized by an administrator, with a saved state that is permanently attached to a client port. 14.4.2.11.2. Drivers Policy Settings Updated: 2010-07-13 The Drivers section contains policy settings related to printer drivers. Automatic installation of in-box printer drivers This setting enables or disables the installation of Windows native drivers on the user device as needed. By default, native drivers are installed when users log on. Printer driver mapping and compatibility This setting specifies driver substitution rules for auto-created printers. When you define these rules, you can allow or prevent the creation of printers with the specified driver. Additionally, you can allow created printers to use only universal printer drivers. Driver substitution overrides (or maps) printer driver names the client provides, substituting an equivalent driver on the server. This gives server applications access to client printers that have the same drivers as the server but different driver names.

You can add a driver mapping, edit an existing mapping, remove a mapping, or change the order of driver entries in the list. When adding a mapping, enter the client printer driver name and then select the server driver you want to substitute. You can also change the settings for a printer driver to configure default preferences for options such as print quality, output resolution, duplex printing, color printing, and paper size. This enables you to restrict the print settings available to users when printing from a session. If these settings are configured, they override both the default driver settings and any retained printer settings. Related Policy Settings Universal printing Auto-create client printers

14.4.2.11.3. Universal Printing Policy Settings Updated: 2010-09-01 The Universal Printing section contains policy settings for managing universal printing. Auto-create generic universal printer This setting enables or disables auto-creation of the Citrix Universal Printer generic printing object. By default, generic universal printers are not auto-created. Universal driver priority This setting specifies the order in which XenDesktop attempts to use universal printer drivers, beginning with the first entry in the list. You can add, edit, or remove drivers, and change the order of drivers in the list. Universal printing This setting specifies when to use universal printing. Universal printing consists of a generic printer object (Citrix Universal Printer) and universal printer drivers that work with both Windows and non-Windows clients. By default, universal printing is used only if the requested driver is unavailable. When adding this setting to a policy, select an option: Use universal printing only if requested driver is unavailable uses native drivers for client printers if they are available. If the driver is not available on the server, the client printer is created automatically with the appropriate universal driver. Use only printer model specific drivers specifies that the client printer use only the native drivers that are auto-created at logon. If the native driver of the printer is unavailable, the client printer cannot be auto-created. Use universal printing only specifies that no native drivers are used. Use printer model specific drivers only if universal printing is unavailable uses the universal printer driver if it is available. If the driver is not available on the server, the client printer is created automatically with the appropriate native printer driver. Universal printing EMF processing mode This setting specifies whether to inject the EMF spool file into the spooler on the user device or reprocess the EMF records on the client. By default, EMF records are spooled directly to the printer. Spooling directly to the printer allows the spooler to process the EMF records without prompting the user for additional information, minimizing the occurrence of illegible output. When adding this setting to a policy, select an option: Spool directly to printer Reprocess EMFs for printer Universal printing image compression limit This setting specifies the maximum quality and the minimum compression level available for images printed

with the Universal printer driver. By default, the image compression limit is set to Best Quality (lossless compression). If No Compression is selected, compression is disabled for EMF printing only. When adding this setting to a policy, select an option: No compression Best Quality (Lossless) High Quality Standard Quality Reduced Quality Related Policy Settings Universal printing optimization defaults Universal printing optimization defaults This setting specifies the default values for print optimization. Image Compression The Desired image quality setting specifies the default image compression limit applied to universal printing. By default, Standard Quality is enabled, meaning that users can only print images using standard or reduced quality compression. Note however, that the Universal printing print quality limit policy overrides the default setting. For example, if default policy is set to Best Quality and the limit policy is set to Standard Quality, users can only print images using standard or reduced quality compression. The Enable heavyweight compression setting enables or disables reducing bandwidth beyond the compression level set by Desired image quality, without losing image quality. By default, heavyweight compression is disabled. Image and Font Caching The Image and Font Caching settings specify whether or not to cache images and fonts that appear multiple times in the print stream, ensuring each unique image or font is only sent to the printer once. Note that these settings apply only if the user device supports this behavior. Allow non-administrators to modify these settings This setting specifies whether or not users can change the default print optimization settings within a session. Related Policy Settings Universal printing image compression limit Universal printing print quality limit Universal printing print quality limit This setting specifies the maximum dots per inch (dpi) available for generating printed output in the session. If this policy is configured, it limits the maximum print quality available to users in terms of output resolution. By default, No Limit is enabled, meaning users can select the maximum print quality allowed by the printer to which they connect. When the setting is enabled both the print quality itself and the print quality capabilities of the printer to which the user connects are restricted to the configured setting. For example, if the Print Quality setting is configured to Medium Resolution (600 DPI), users are restricted to printing output with a maximum quality of 600 DPI and the Print Quality setting on the Advanced tab of the Universal Printer dialog box shows resolution settings only up to and including Medium Quality (600 DPI). When adding this setting to a policy, select an option: Draft (150 DPI) Low Resolution (300 DPI) Medium Resolution (600 DPI) High Resolution (1200 DPI) No limit Related Policy Settings

Universal printing optimization defaults

Universal printing preview preference This setting specifies whether or not to use the print preview function for auto-created or generic universal printers. By default, print preview is not used for auto-created or generic universal printers. 14.4.2.12. Session Limits Policy Settings Updated: 2010-07-14 The Session Limits section contains policy settings you can use to control how long sessions remain connected before they are forced to log off. Disconnected session timer This setting enables or disables a timer to determine how long a disconnected, locked workstation can remain locked before the session is logged off. By default, disconnected sessions are not logged off. Related Policy Settings Disconnected session timer interval

Disconnected session timer interval This setting determines how long, in minutes, a disconnected, locked workstation can remain locked before the session is logged off. By default, the time period is 1440 minutes (24 hours). Related Policy Settings Session disconnect timer

Session connection timer This setting enables or disables a timer to determine the maximum duration of an uninterrupted connection between a user device and a workstation. By default, this timer is disabled. Related Policy Settings Session connection timer interval

Session connection timer interval This setting determines, in minutes, the maximum duration of an uninterrupted connection between a user device and a workstation. By default, the maximum duration is 1440 minutes (24 hours). Related Policy Settings Session connection timer

Session idle timer This setting enables or disables a timer to determine how long an uninterrupted user device connection to a workstation will be maintained if there is no input from the user. By default, this timer is enabled. Related Policy Settings Session idle timer interval

Session idle timer interval This setting determines, in minutes, how long an uninterrupted user device connection to a workstation will be maintained if there is no input from the user. By default, idle connections are maintained for 1440 minutes (24 hours).

Related Policy Settings Session idle timer 14.4.2.13. Session Reliability Policy Settings Updated: 2011-01-14 The Session Reliability section contains policy settings for managing session reliability connections. These policy settings are applicable to the following Citrix products: XenApp 6.0 XenDesktop 5.0

Session reliability connections This setting allows or prevents sessions to remain open during a loss of network connectivity. By default, session reliability is allowed. Session Reliability keeps sessions active when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes. When connectivity is momentarily lost, the session remains active on the server. The users display freezes and the cursor changes to a spinning hourglass until connectivity resumes. The user continues to access the display during the interruption and can resume interacting with the application when the network connection is restored. Session Reliability reconnects users without reauthentication prompts. If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, configure the Auto client reconnect authentication setting to require authentication. Users are then prompted to reauthenticate when reconnecting to interrupted sessions. If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence. Session Reliability closes, or disconnects, the user session after the amount of time you specify in the Session reliability timeout setting. After that, the settings you configure for Auto Client Reconnect take effect, attempting to reconnect the user to the disconnected session. Session reliability port number This setting specifies the TCP port number for incoming session reliability connections. The default port number is 2598. Session reliability timeout This setting specifies the length of time in seconds the session reliability proxy waits for a client to reconnect before allowing the session to be disconnected. The default length of time is 180 seconds, or three minutes. Though you can extend the amount of time a session is kept open, this feature is designed to be convenient to the user and it does not prompt the user for reauthentication. If you extend the amount of time a session is kept open indiscriminately, chances increase that a user may get distracted and walk away from the client device, potentially leaving the session accessible to unauthorized users. If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, configure the Auto client reconnect authentication setting to require authentication. Users are then prompted to reauthenticate when reconnecting to interrupted sessions. If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence. Session Reliability closes, or disconnects, the user session after the amount of time you specify in the Session reliability timeout setting. After that, the settings you configure for Auto Client Reconnect take effect, attempting to reconnect the user to the disconnected session. 14.4.2.14. USB Devices Policy Settings Updated: 2010-09-24

The USB devices section contains policy settings for managing file redirection for USB devices. Client USB device redirection This setting allows or prevents redirection of USB devices to and from the client (workstation hosts only). By default, USB devices are not redirected. Client USB device redirection rules This setting specifies redirection rules for USB devices. When a user plugs in a USB device, the host device checks it against each policy rule in turn until a match is found. The first match for any device is considered definitive. If the first match is an Allow rule, the device is remoted to the virtual desktop. If the first match is a Deny rule, the device is available only to the local desktop. If no match is found, default rules are used. For more information about the default policy configuration for USB devices, refer to CTX119722, Creating USB Policy Rules, in the Citrix Knowledge Center. Policy rules take the format {Allow:|Deny:} followed by a set of tag= value expressions separated by whitespace. The following tags are supported: VID Vendor ID from the device descriptor PID Product ID from the device descriptor REL Release ID from the device descriptor Class Class from either the device descriptor or an interface descriptor SubClass Subclass from either the device descriptor or an interface descriptor Prot Protocol from either the device descriptor or an interface descriptor When creating new policy rules, be aware of the following: Rules are case-insensitive. Rules may have an optional comment at the end, introduced by #. Blank and pure comment lines are ignored. Tags must use the matching operator =. For example, VID=1230. Each rule must start on a new line or form part of a semicolon-separated list. Refer to the USB class codes available from the USB Implementers Forum, Inc. Web site. Examples of administrator-defined USB policy rules Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive Deny: Class=08 subclass=05 # Mass Storage To create a rule that denies all USB devices, use DENY: with no other tags. 14.4.3. Server Session Settings Updated: 2010-07-14 The Server Session Settings section contains policy settings for configuring Single Sign-On.

Single Sign-On This setting enables or disables the use of Single Sign-on when users connect to servers or published applications in a XenApp farm. By default, Single Sign-On is enabled. Single Sign-On central store This setting specifies the UNC path of the Single Sign-On central store to which users are allowed to connect. Policies apply only to shared folders you configure to be Single Sign-On central stores. If you want this setting to use the central store specified by the Single Sign-On plug-in, leave this field blank. Server farm zone failover preferences apply only to published objects, not to central stores. If the users preferred zone is not operating and the connection fails over to a backup zone, the user cannot access published objects using Single Sign-On if the central store is in the failed zone. 14.4.4. Virtual Desktop Agent Settings Updated: 2010-08-13 The Virtual Desktop Agent section contains policy settings you can configure to control communication between the Virtual Desktop Agent and controllers for a XenDesktop site. Important: The Virtual Desktop Agent requires the information provided by these settings to register with a controller. Because this information is required for registration, you must configure these settings using Active Directory's Group Policy Editor, unless you provide this information during the Virtual Desktop Agent install. The policy settings in this section are applicable to XenDesktop only. Site GUID This setting specifies the Globally Unique Identifier (GUID) of the XenDesktop site the Virtual Desktop Agent uses to register with a controller, when using Active Directory-based registration. By default, this setting is blank. Controllers This setting specifies a space-separated list of controller Fully Qualified Domain Names (FQDNs) the Virtual Desktop Agent uses to register with a controller, when using registry-based registration. This is an optional setting, that may be used in conjunction with the Controller SIDs setting. By default, this setting is blank. Controller SIDs This setting specifies a space-separated list of controller Security Identifiers (SIDs) the Virtual Desktop Agent uses to register with a controller, when using registry-based registration. This is an optional setting, that may be used in conjunction with the Controllers setting, to restrict the list of controllers used for registration. By default this setting is blank. Controller Registration Port This setting specifies the TCP/IP port number the Virtual Desktop Agent uses to register with a controller, when using registry-based registration. By default, the port number is set to 80. 14.4.4.1. CPU Usage Monitoring Settings Updated: 2010-09-23 The CPU Usage Monitoring section contains policy settings for monitoring the level of CPU usage for virtual desktops in your environment. Enable Monitoring

This setting enables or disables CPU usage monitoring for virtual desktops in a site. Monitoring Period This setting specifies the period of time, in seconds, during which the moving average for CPU usage is calculated. By default, this is set to 60 seconds. Threshold This setting specifies the threshold, as a percentage, that triggers a High CPU condition, displayed in Desktop Studio and Desktop Director. By default, this is set to 95%. 14.4.4.2. ICA Latency Monitoring Settings Updated: 2010-07-01 The ICA Latency Monitoring section contains policy settings for monitoring ICA latency on virtual desktops in your environment. Enable Monitoring This setting enables or disables ICA Latency monitoring for virtual desktops in a site. Monitoring Period This setting specifies the period of time, in seconds, during which the moving average for ICA Latency is calculated. By default, this is set to 30 seconds. Threshold This setting specifies the threshold, in milliseconds, that triggers a High Latency condition, displayed in Desktop Studio and Desktop Director. By default, this is set to 200 milliseconds. 14.4.4.3. Profile Load Time Monitoring Settings Updated: 2010-07-01 The Profile Load Time Monitoring section contains policy settings for monitoring profile load time on virtual desktops in your environment. Enable Monitoring This setting enables or disables profile load time monitoring for virtual desktops in a site. Threshold This setting specifies the threshold, in seconds, that triggers a High Profile Load Time condition, displayed in Desktop Studio and Desktop Director. By default, this is set to 60 seconds.