You are on page 1of 1203

XenApp 6.

5 for Windows Server 2008 R2

2011 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement

Contents

XenApp 6.5 for Windows Server 2008 R2 XenApp 6.5 for Windows Server 2008 R2 About This Release Known Issues System Requirements Plan Design and Plan Farm Terminology and Concepts Planning a Successful User Experience Farm Hardware Considerations Planning for Applications and Server Loads Assessing Applications for XenApp Compatibility Evaluating Application Delivery Methods Planning for Application Streaming Placing Applications on Servers Determining the Number of XenApp Servers to Deploy Deciding How Many Farms to Deploy Planning Server Functions Planning the XenApp Data Store Database Server Hardware Performance Considerations Replication Considerations Planning for Configuration Logging and IMA Encryption Planning for Data Collectors Designing Zones for a XenApp Deployment Planning for Application Access Planning for Accounts and Trust Relationships Recommendations for Active Directory Environments Planning for System Monitoring and Maintenance Planning for UAC

23 24 27 30 35 40 44 48 52 54 55 56 57 60 61 65 66 68 69 71 73 74 75 76 79 81 83 86 87

Planning for Shadowing Securing Delivery and Access Planning for Supported Languages and Windows MUI Support Planning for Passthrough Client Authentication Install and Configure Install and Configure Preparing to Install and Configure XenApp Before Installing XenApp Before Configuring XenApp Installing XenApp Using the Wizard-Based Server Role Manager Installing XenApp from the Command Line Configuring XenApp Server Role License Information Configuring XenApp Using the Wizard-based Server Configuration Tool Configuring XenApp from the Command Line Configuration Command Syntax Preparing for XenApp Imaging and Provisioning Removing Roles and Components Data Store Database Reference Microsoft SQL Server Database Oracle Database Migrate XenApp Migration Center Migration Center Interfaces Objects You Can Migrate Requirements and Installation Migrating XenApp Using the Graphical Interface Migrating XenApp Using the Command Line Interface Cmdlet Reference Post-migration Tasks Indirect Migrations and Advanced Cmdlets Manage XenApp 6 for Windows 2008 R2 Management Consoles and Other Tools To start the AppCenter and discover servers To view zones To refresh user data automatically Managing Citrix Administrators

88 89 90 91 92 94 95 96 98 100 102 105 107 111 113 119 124 127 128 131 134 136 138 140 142 145 147 149 155 156 159 161 163 165 166 167 168

Delegating Tasks to Custom Administrators Delivering XenApp to Software Services Subscribers To enable Windows 7 look and feel and control desktop customization Working with Citrix Policies Navigating Citrix Policies and Settings Creating Citrix Policies Working with Citrix Policy Templates Creating Policy Templates Importing and Exporting Policy Templates Comparing Policies and Templates Configuring Policy Settings To add settings to a policy Applying Citrix Policies To add filters to a policy Managing Multiple Policies Prioritizing Policies and Creating Exceptions Determining Which Policies Apply to a Connection To simulate connection scenarios with Citrix policies Applying Policies to Access Gateway Connections Enabling Scanners and Other TWAIN Devices Managing Session Environments and Connections Defining User Environments in XenApp Controlling the Appearance of User Logons Controlling Access to Devices and Ports To enable user execute permissions on mapped drives Displaying Local Special Folders in Sessions Configuring Audio for User Sessions To enable or disable audio for published applications To configure bandwidth limits for audio To configure audio compression and output quality To enable support for microphones and speakers To use and set sound quality for digital dictation devices Ensuring Session Continuity for Mobile Workers Maintaining Session Activity Configuring Session Reliability Configuring Automatic Client Reconnection Configuring ICA Keep-Alive 4

170 173 176 178 180 182 184 186 188 190 191 193 194 197 198 199 201 203 204 206 208 210 211 212 213 214 217 218 219 220 221 222 223 225 226 227 229

Session Linger Managing and Monitoring XenApp Sessions Monitoring Session Information Viewing User Sessions Viewing User Sessions with the Shadow Taskbar Enabling Logging for Shadowing Enabling User-to-User Shadowing with Policies Controlling Client Connections in XenApp Preventing Specific Client Connection Types Specifying Connection Limits Limiting Connections to a Server Farm Sharing Sessions and Connections Limiting Application Instances Logging Connection Denial Events Configuring the ICA Listener Preventing User Connections During Farm Maintenance Optimizing User Sessions for XenApp Optimizing Audio and Video Playback Configuring Windows Media Redirection Optimizing Flash Content Optimizing Throughput of Image Files Optimizing Display of Image Files Optimizing Keyboard and Mouse Responsiveness Configuring SpeedScreen Latency Reduction Adjusting SpeedScreen Latency Reduction for an Application To configure latency reduction settings for input fields in an application To create exception entries for non-standard input fields in an application Configuring HDX Broadcast Display Settings Enhancing the User Experience With HDX Configuring HDX MediaStream Flash Redirection Configuring HDX MediaStream Flash Redirection on the Server Configuring HDX MediaStream Flash Redirection on the User Device Configuring Audio Avoiding Echo During Multimedia Conferences With HDX RealTime

230 231 234 235 236 238 239 241 242 243 244 245 247 248 249 250 251 252 254 255 256 257 258 259 260 263 265 267 268 269 271 276 281 285

Video Conferencing with HDX RealTime Webcam Video Compression Increasing 2D and 3D Application Scalability and Performance Assigning Priorities to Network Traffic Adding Dynamic Windows Preview Support Configuring Read-Only Access to Mapped Client Drives Securing Server Farms Securing Access to Your Servers Securing the Data Store Securing Client-Server Communications Using SecureICA Enabling SSL/TLS Protocols To configure session data encryption To set a policy for ICA encryption Configuring SSL/TLS Between Servers and Clients Obtaining and Installing Server and Root SSL Certificates Choosing an SSL Certificate Authority Acquiring a Signed SSL Certificate and Password To enable the SSL Relay and select the relay credentials Using the SSL Relay with the Microsoft Internet Information Service (IIS) Configuring the Relay Port and Server Connection Settings To run the SSL Relay on port 443 without using HTTPS Configuring the Ciphersuites Allowed by the SSL Relay Using the Secure Gateway Using the Secure Ticket Authority Securing Network Communications Configuring TCP Ports Using Proxy Servers Configuring Authentication for Workspace Control Using Smart Cards with XenApp Configuring Kerberos Logon Logging Administrative Changes to a XenApp Farm Setting up the Configuration Logging Database Defining Database Permissions for Configuration Logging To configure the connection to the Configuration Logging database To set Configuration Logging properties Clearing Entries from the Configuration Logging Database 6

286 288 289 291 292 293 294 295 297 298 299 300 301 302 304 305 306 307 308 309 311 312 313 314 316 317 318 319 320 322 324 326 328 330 331 332

Encrypting Configuration Logging Data To generate a key and enable IMA encryption on the first server in a farm To load a key on servers that join the farm Managing IMA Encryption XenApp Service Account Privileges Maintaining Server Farms To search for objects in your farm To change a server's desktop settings To limit the number of server connections per user To enable or deny logons to servers Restarting Servers at Scheduled Times Removing and Reinstalling XenApp To rename a XenApp server To move or remove a server Monitoring Server Performance with Health Monitoring & Recovery Using Citrix Performance Monitoring Counters Using Worker Groups for Enhanced Resource Access To create a worker group Creating and Prioritizing Load Balancing Policies Enhancing the Performance of a Remote Group of Servers Using Preferential Load Balancing Resource Allotment Multiple Published Applications in the Same Session Managing CPU Usage Deploying virtual memory optimization Managing Farm Infrastructure Maintaining the Local Host Cache Tuning Local Host Cache Synchronization To configure zones and back-up data collectors Updating Citrix License Server Settings To set the product edition Configuring the Citrix XML Service Port and Trust To manually change the XML Service port to use a port different from IIS after installation To manually configure Citrix XML Service to share the TCP port with IIS Manage Server and Resource Loads

333 335 336 337 338 343 344 345 346 347 348 349 351 352 353 356 358 361 362 363 364 365 368 369 371 374 375 376 377 379 380 381 383 384 385

To create a new load evaluator List of Load Management Rules Assigning Load Evaluators to Servers and Applications Scheduling Server Availability Power and Capacity Management About Load Consolidation and Power Management Installing Power and Capacity Management System Requirements for Power and Capacity Management Interactively Installing Components Silently Installing Components Upgrading Administration Components Removing Components Configuring and Using Power and Capacity Management Configuring a Server Profile Configuring Server Properties Setting Global Configuration Values Configuring Sites Adding Virtual Machine Managers Managing the Concentrator Creating Setpoints and Schedules Enabling Load Consolidation and Power Management Understanding XenApp Printing Introduction to Windows Printing Concepts Local and Remote Print Job Spooling XenApp Printing Concepts Overview of Client and Network Printing Pathways Provisioning Printers for Sessions Auto-Creating Client Printers Auto-Creating Network Printers Letting Users Provision Their Own Printers Device or Session-Based Print Settings Device-Based Print Settings Controlling Printing Settings and User Preferences Setting Default Printers Printing and Mobile Workers Optimizing Printing Performance by Routing Managing Printer Drivers

387 388 390 392 393 395 397 398 402 404 410 411 412 416 418 420 421 422 424 426 429 430 431 433 435 436 441 443 447 448 449 450 451 454 455 457 458

Planning Your Printing Configuration Default Printing Behavior Printing Policy Configuration Printing Security Purchasing Printing Hardware Configuring and Maintaining XenApp Printing Configuring Printer Autocreation Settings Configuring Citrix Universal Printing Configuring Network Printers for Users To add a network printer while configuring the Session printers setting To specify a default printer for a session To edit the printer settings in the sessions policy To configure server local printers Configuring Printers for Mobile Workers Changing Network Print Job Routing Providing Tools for User Provisioning To store users printer properties To synchronize properties from the printer Controlling Printer Driver Automatic Installation Configuring Universal Printer Drivers on Farm Servers Mapping Client Printer Drivers Improving Session Performance by Limiting Printing Bandwidth Displaying Printers Managing Printers Using the Network Printing Pathway Displaying Printers Using the Client Printing Pathway XenApp Server Utilities Reference ALTADDR APP AUDITLOG CTXKEYTOOL CTXXMLSS DSCHECK DSMAINT ICAPORT IMAPORT QUERY FARM QUERY PROCESS 9

460 461 462 463 464 465 466 467 469 470 471 472 473 474 475 476 478 479 480 483 485 487 489 490 491 492 493 495 498 501 503 505 507 512 514 516 519

QUERY SESSION QUERY TERMSERVER QUERY USER Performance Counters Reference Citrix CPU Utilization Mgmt User Counters Citrix IMA Networking Counters Citrix Licensing Counters Citrix MetaFrame Presentation Server Counters ICA Session Counters Secure Ticket Authority Counters Policy Settings Reference Policy Settings: Quick Reference Table ICA Policy Settings Audio Policy Settings Auto Client Reconnect Policy Settings Bandwidth Policy Settings Client Sensors Policy Settings Desktop UI Policy Settings End User Monitoring Policy Settings File Redirection Policy Settings Flash Redirection Policy Settings Graphics Policy Settings Caching Policy Settings Keep Alive Policy Settings Legacy Server Side Optimizations Policy Settings Mobile Experience Policy Settings Multimedia Policy Settings Multi-Stream Connections Policy Settings Port Redirection Policy Settings Printing Policy Settings Client Printers Policy Settings Drivers Policy Settings Universal Printing Policy Settings Security Policy Settings Server Limits Policy Settings Session Limits Policy Settings Session Reliability Policy Settings

521 523 525 527 528 529 530 531 533 536 537 538 544 546 548 549 554 556 557 558 563 567 569 570 571 572 574 576 578 580 582 585 587 590 592 593 595

10

Shadowing Policy Settings Time Zone Control Policy Settings TWAIN Devices Policy Settings USB Devices Policy Settings Visual Display Policy Settings Moving Images Policy Settings Still Images Policy Settings Licensing Policy Settings Power and Capacity Management Policy Settings Server Policy Settings Connection Limits Policy Settings Database Policy Settings Health Monitoring and Recovery Policy Settings Memory Optimization Policy Settings Offline Applications Policy Settings Reboot Behavior Policy Settings Server Session Settings Virtual IP Policy Settings XML Service Policy Settings Publish Publish Publishing in XenApp Evaluating Application Delivery Methods Publishing Resources using the AppCenter To configure servers to publish for multiple users To publish a resource using the Publish Application wizard To select a resource type and delivery method To configure locations of published applications To configure locations of published content To disable command-line validation To pre-launch applications to user devices Publishing Applications for Streaming New Features in This Release System Requirements for Application Streaming Application Streaming Overview Components for Application Streaming Deciding Which Receiver or Plug-in to Use for Application Streaming 11

597 599 600 601 603 604 605 607 608 609 612 613 615 616 619 620 623 624 626 627 629 630 631 634 636 637 639 641 642 643 644 647 649 650 653 655 658

Providing Single Sign-on for Streamed Applications Creating Application Profiles Targets Overview Service Pack Level System Drive Letter Operating System Language Inter-Isolation Communication Overview Isolating Services Specifying Trusted Servers for Streamed Services and Profiles Managing Isolation Environment Rules Types of Isolation Environment Rules Restrictions and Limitations for Rules Creating Isolation Environment Rules for a Target To create an isolation environment rule To modify a rule Using Environment Variables to Construct Rules Preparing a Workstation for Profiling Applications Known Limitations for Profiling To install the profiler To disable and enable profile signing To start the profiler Creating a Profile and Its Initial Target To create a profile and target To allow users to update applications To set up inter-isolation communication To select an install option To install multiple applications through Advanced Install To choose an installation program for the application To create a virtual hard disk To support legacy plug-ins To install Internet Explorer plug-ins To include files and folders in a target To include registry settings To install an application in the profile To run an application in the profiler To select applications for listing in the profile 12

660 661 663 665 666 667 668 669 670 673 674 676 677 678 679 680 682 684 685 686 687 688 689 692 693 695 696 697 699 701 702 703 704 705 706 707

To sign a profile Editing Profiles To view profile information To edit the profile name, description, or location To view details about applications in a profile To view File Type Associations set in a profile To check for launch prerequisites To check for prerequisite registry entries To check for prerequisite applications and files To specify pre-launch and post-exit scripts To add a target to a profile To resolve target conflicts To resolve invalid shortcuts To delete a target from a profile To delete a folder from a profile To remove a profile from a linked profile Editing Targets To edit the target name and description To modify the application properties in the target To modify the operating system and language properties of a target To update a target To remove an old version of an updated target Profile Contents on the Server Manifest File Targets Digital Signature Icons Scripts Publishing Streamed Applications To select a streaming delivery method To force a delivery method for streamed applications To provide HTTP or HTTPS delivery method Configuring Offline Access Offline Plug-in 6.5 for Windows New Features in This Release System Requirements for Application Streaming Citrix Offline Plug-in Overview 13

708 709 710 711 712 713 714 715 717 718 719 720 722 723 724 725 726 727 728 730 731 732 733 734 735 736 737 738 739 740 742 744 747 750 751 752 755

Deciding Which Receiver or Plug-in to Use for Application Streaming Specifying Trusted Servers for Streamed Services and Profiles Using the Merchandising Server and Citrix Receiver Updater to Deploy the Plug-ins To install the Offline Plug-in To deliver the AppHubWhiteList to user devices To configure the cache size of the Offline Plug-in To deploy the Offline Plug-in using the command-line To configure an .MSI package for the Offline Plug-in using transforms To deploy the Offline Plug-in to user devices through Active Directory To deploy applications to user devices To clear the streamed application cache on user devices To clear merged rules for linked profiles on user devices Configuring Content Redirection To enable content redirection from server to client To configure content redirection from client to server Managing Application Properties To rename a published application To configure locations of servers for published resources To specify locations of applications for streaming To enable an application for offline access To configure user access to applications Granting Access to Explicit or Anonymous Users To configure shortcuts for user devices To configure access controlled by the Access Gateway To associate published applications with file types To update file type associations To configure alternate profiles To pass parameters to published applications To reduce user privileges for a streamed application To configure application limits and importance To configure audio and encryption options for published applications To configure application appearance To disable or enable a published application To delete a published application

756 758 761 762 764 765 766 768 769 770 772 774 775 776 778 779 780 781 782 783 784 786 787 788 789 791 793 794 795 796 797 799 800 801

14

To move a published application to another folder To duplicate published application settings To export published application settings to a file To import published application settings from a file Making Virtual IP Addresses Available to Applications How Virtual IP Addressing Works Binding Applications To determine whether an application needs to use virtual IP addresses To make virtual IP addresses available to applications running in sessions To make a virtual loopback address available to applications running in sessions To supply client IP addresses to published applications on a server VM Hosted Apps System Requirements Plan Install and Set Up Installing and Removing Server Components for VM Hosted Apps To configure a VM hosted apps site To replace the default XenServer SSL certificate Installing and Removing the Virtual Desktop Agent To configure firewalls manually To deploy the Virtual Desktop Agent using Active Directory Group Policy Objects To use Windows XP virtual desktops with Single Sign-on Manage Working With Machine Catalogs and Desktop Groups To create an application desktop group Managing Application Desktop Groups Working With Applications To create an application To modify applications To manage applications sessions Organizing Applications with Folders and Tags Customize Configuring USB Support for VM Hosted Apps Publishing App-V Sequences in XenApp

802 803 804 805 806 807 808 809 810 811 812 814 817 818 821 822 824 827 829 831 832 833 834 835 837 838 839 841 843 845 847 848 849 853

15

XenApp Connector for Configuration Manager 2007 System Requirements for XenApp Connector for Configuration Manager 2007 Install and Set Up XenApp Connector Uninstalling XenApp Connector Enabling Power and Capacity Management for XenApp Connector Deploying Applications to XenApp Servers and Publishing Applications with XenApp Connector To publish applications with XenApp Connector for Configuration Manager 2007 Deploying WSUS Updates to XenApp Servers with XenApp Connector Viewing and Maintaining Log Files Enterprise Management Enterprise Management Management Pack for System Center Operations Manager 2007 System Requirements for the Management Pack To install the Management Pack Management Pack Post-Installation Tasks Uninstalling the Management Pack Security Considerations for the Management Pack Troubleshooting Query Errors in Operations Manager Citrix Managed Objects Included in the Management Pack Citrix Views Included in the Management Pack To view state monitors and processing rules Viewing XenApp Alert and Event Information Viewing XenApp Deployment State Information Viewing Citrix Presentation Server Topology Diagrams To reconfigure security settings on zone data collectors Viewing XenApp Performance Information Viewing License Server Information Configuring and Enabling Site-specific Monitors To open the AppCenter from the Operations Manager Console Installation Manager Requirements and Installation Using the Installation Manager Console Using Installation Manager PowerShell Cmdlets Installation Manager Messages Reference Managing Providers and WMI

857 858 860 864 865 867 870 872 873 875 876 878 880 881 882 883 884 885 886 887 888 889 890 891 895 896 897 898 900 901 903 906 910 916 922

16

XenApp Provider Overview Licensing Provider Overview Installing the XenApp Provider Installing the Licensing Provider Starting the Provider Services Security Considerations Uninstalling the Providers WMI Schema XenApp Provider WMI Schema (Part 1 of 3) XenApp Provider WMI Schema (Part 2 of 3) XenApp Provider WMI Schema (Part 3 of 3) Citrix Licensing Provider WMI Schema Optimize WAN Access Provision Secure Enterprise Network Secure Gateway Citrix XenApp Components That Work with Secure Gateway Secure Gateway Features System Requirements for Secure Gateway Certificate Requirements Planning a Secure Gateway Deployment Deploying the Secure Gateway in a Single-Hop DMZ Running the Web Interface behind the Secure Gateway in the Demilitarized Zone Locking Down Internet Information Services Running the Web Interface Parallel with the Secure Gateway Setting Up the Web Interface and the Secure Gateway in a Single-Hop Demilitarized Zone Deploying the Secure Gateway in a Double-Hop DMZ Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ Publishing the Web Address for the Secure Gateway in a Double-Hop Demilitarized Zone Setting Up and Testing a Server Farm Installing the Secure Ticket Authority Testing Your Deployment Installing and Configuring the Secure Gateway and Secure Gateway Proxy Upgrading Secure Gateway or Secure Gateway Proxy

923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 944 946 948 949 951 953 954 955 956 959 960 961 962 963 964 965

17

Using Firewall Software with the Secure Gateway or Secure Gateway Proxy Installing the Secure Gateway or Secure Gateway Proxy To install the Secure Gateway or Secure Gateway Proxy Configuring the Secure Gateway or Secure Gateway Proxy To start the configuration wizard manually To select a configuration level (Secure Gateway) To select a configuration level (Secure Gateway Proxy) Task Summary for Secure Gateway, Advanced or Standard Configuration Task Summary for Secure Gateway Proxy, Advanced or Standard Configuration To select a server certificate To configure secure protocol settings To configure inbound client connections To configure outbound connections To configure an access control list for outbound connections To configure servers running the Secure Gateway Proxy To add the Secure Ticket Authority details To configure connection parameters To configure logging exclusions To add the Web Interface server details To configure the logging parameters To complete the configuration To stop the Secure Gateway/Secure Gateway Proxy service To uninstall the Secure Gateway Managing the Secure Gateway Viewing Session and Connection Information with the Secure Gateway Console Viewing Secure Gateway Performance Statistics To view the Secure Gateway performance statistics Performance Counters Available for the Secure Gateway Generating the Secure Gateway Diagnostics Report Viewing the Secure Gateway Events Viewing the Secure Gateway Access Logs Secure Gateway Configuration Wizard Secure Gateway Optimization and Security Guidelines Configuring Firewalls for the Secure Gateway

966 967 968 969 970 971 972 973 974 975 976 977 978 979 981 982 983 984 985 986 987 988 989 990 991 993 994 995 999 1000 1002 1003 1004 1005

18

Ensuring High Availability of the Secure Gateway Load Balancing Multiple Secure Gateway Servers Load Balancing an Array of the Secure Gateway Proxy

1006 1008 1009

Certificate Requirements for Load Balancing Secure Gateway 1010 Servers Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers 1011

Coordinating Keep-Alive Values Between the Secure Gateway and 1012 Citrix XenApp Setting Connection Keep-Alive Values and the Secure Gateway Improving Security (Recommendations) Preventing Indexing by Search Engines Troubleshooting the Secure Gateway To check your certificates Client Connections Launched from IP Addresses in the Logging Exclusions List Fail Load Balancers Do Not Report Active Client Sessions if Connections Are Idle Performance Issues with Transferring Files Between a User Device and a Citrix XenApp Server Gateway Client Connections Fail When Using Windows XP Service Pack 2 Failed Client Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log Placing the Secure Gateway Behind a Reverse Web Proxy Causes an SSL Error 4 Run the Secure Gateway Parallel to the Reverse Web Proxy Use a Network Address Translator Instead of a Reverse Web Proxy Digital Certificates and the Secure Gateway Understanding Cryptography Types of Cryptography Combining Public Key and Secret Key Cryptography Understanding Digital Certificates and Certificate Authorities Certificate Chains Certificate Revocation Lists Deciding Where to Obtain Certificates Obtaining and Installing Server Certificates Obtaining and Installing Root Certificates Support for Wildcard Certificates with the Secure Gateway Secure Application Access Monitor 1013 1014 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1035 1037 1038 1040 1042 1043 1044 1045

19

Record Record System Requirements for SmartAuditor Example Usage Scenarios Getting Started with SmartAuditor Planning Your Deployment Security Recommendations Installing Certificates Scalability Considerations Important Deployment Notes Pre-Installation Checklist To install SmartAuditor Automating Installations To configure SmartAuditor to play and record sessions Granting Access Rights to Users Creating and Activating Recording Policies Using System Policies Creating Custom Recording Policies To create a new policy To modify a policy To delete a policy To activate a policy Understanding Rollover Behavior To disable or enable recording To configure the connection to the SmartAuditor Server Creating Notification Messages Enabling Custom Event Recording To enable or disable live session playback To enable or disable playback protection To enable and disable digital signing To specify where recordings are stored Specifying File Size for Recordings Viewing Recordings To launch the SmartAuditor Player To open and play recordings To search for recorded sessions To play recorded sessions

1046 1047 1050 1053 1054 1056 1059 1060 1061 1064 1065 1066 1068 1069 1071 1072 1073 1074 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1090 1091 1092 1093 1095 1097

20

To use events and bookmarks To change the playback display To display or hide window elements To cache recorded session files To change SmartAuditor Servers Troubleshooting SmartAuditor Verifying Component Connections Testing IIS Connectivity Troubleshooting Certificate Issues SmartAuditor Agent Cannot Connect SmartAuditor Server Cannot Connect to the SmartAuditor Database Sessions are not Recording Searching for Recordings in the Player Fails Troubleshooting MSMQ Unable to View Live Session Playback To change your communication protocol Reference: Managing Your Database Records Single Sign-on Automate Citrix App Studio 1.0 Citrix App Studio About This Release System Requirements PowerShell Execution Policy and Remoting Requirements Install and Configure Installing and Configuring Citrix App Studio To configure App Studio global settings Creating and Modifying Farm Catalogs To add farms to a farm catalog Creating and Modifying Workload Catalogs Adding and Removing Session Hosts Adding and Removing Web Interface Servers Manage Working with the App Studio Console Understanding Workflows To adjust workload capacity To create a new version of a workload catalog 21

1100 1103 1105 1106 1108 1109 1110 1112 1114 1115 1116 1117 1118 1119 1120 1121 1123 1125 1126 1127 1128 1131 1134 1137 1140 1142 1145 1148 1151 1154 1157 1160 1163 1164 1166 1169 1170

Advertising Services to Tenants Managing Tenants Subscribing Tenant Users to Services Managing Administrators Providing Applications and Desktops to Customers with Citrix CloudPortal Services Manager XenApp 6.5 Mobility Pack 1.0 XenApp 6.5 Mobility Pack Technical Preview About This Release System Requirements Installing XenApp 6.5 Mobility Pack Configuring Policies for Mobility Pack Mobile Application SDK

1172 1179 1184 1187 1189 1191 1193 1195 1197 1198 1200 1202

22

XenApp 6.5 for Windows Server 2008 R2

About This Release Known Issues for XenApp 6.5 System Requirements for XenApp 6.5

Publishing Resources Enhancing the User Experience With HDX Delivering XenApp to Software Services Subscribers (Windows Desktop Experience Integration) Power and Capacity Management Profile Management Licensing Your Product Web Interface Receiver (Updater) for Windows Receiver (Updater) for Macintosh

Issues Fixed for XenApp 6.5 Installing and Configuring XenApp 6.5 XenApp Migration Center Designing a XenApp Deployment Receiver For Windows Self-service Plug-in

Other XenApp Features


Citrix XenApp includes additional features in each edition to help enhance the user application virtualization experience. This table includes links to the product documentation located in Citrix eDocs or in the Citrix Knowledge Center describing these features.

Desktop Director Provisioning Services Service Monitoring (EdgeSight) Single Sign-on Branch optimization powered by Citrix Branch Repeater SmartAccess powered by Citrix Access Gateway XenApp 6.5 Mobility Pack 1.0 Doc Finder

VM Hosted Apps XenApp Connector for Configuration Manager 2007 R2 Smart Auditor Load testing services Secure Gateway XenVault Workflow Studio orchestration Citrix App Studio 1.0

23

About Citrix XenApp 6.5 for Windows Server 2008 R2


This release includes several new features and enhancements to Citrix XenApp.

24

XenApp 6.5 for Windows Server 2008 R2

What's New
q

Server Platform Support The XenApp software can be installed on the following platforms. For all system requirements, see System Requirements.
q

Microsoft Windows Server 2008 R2

q Microsoft Windows Server 2008 R2 Service Pack 1 Windows Desktop Experience Integration

Installed by default when installing the XenApp server role, this feature provides a Windows 7 look and feel including desktop customization. PowerShell script options enable administrators to control desktop and environment defaults while allowing end users to customize their desktops. When installed and enabled, this feature also removes the Windows Server Manager Console from the XenApp server's toolbar and relocates the Citrix XenApp administrative tools such as the AppCenter to the Start menu's Administrative Tools\Citrix folder. See Delivering XenApp to Software Services Subscribers for more information.
q

Citrix AppCenter The AppCenter provides a streamlined interface for performing management functions. From the AppCenter, you can manage components administered through other Citrix products, such as Citrix Secure Access and Citrix Single Sign-On. For Citrix XenApp, you can configure and monitor servers, server farms, published resources, and sessions.

Session Pre-launch, Session Linger, and Fast Reconnect This collection of features improves the user experience by eliminating delays when launching and maintaining sessions. By using configurable Session Pre-launch policy settings, a session is started automatically when a user logs on to the farm. By implementing Session Linger policy settings, sessions remain alive for a configurable period before termination, rather than terminating when users close applications. Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays when users reconnect to existing sessions.

Citrix HDX Enhancements XenApp includes the latest HDX enhancements:


q

HDX MediaStream Flash Redirection Audio Settings Multimedia Conferencing with HDX RealTime Increased 2D and 3D Application Scalability and Performance Assigning Priorities to Network Traffic

25

XenApp 6.5 for Windows Server 2008 R2


q

Dynamic Windows Preview Support

Migration Center with Graphical User Interface With the choice of using a PowerShell cmdlet command line or graphical user interface, XenApp administrators can import application, folder, server configuration, and other XenApp object types from farms running previous versions of XenApp into XenApp 6.5 farms. See XenApp Migration Center for requirement and installation information.

Improved Performance for Pooled Desktops Application launch time in pooled desktop environments is improved through the use of virtual hard disks. Using the Streaming Profiler, virtual hard disks can be created when profiling an application. When the application is launched for the first time, the virtual hard disk is mounted and all the profile contents are copied to the virtual hard disk. For all subsequent launches, the application is launched from the virtual hard disk, resulting in a speedier launch.

Printing Optimization XenApp printing features include improved print session performance, lower bandwidth required for printing, and improved user experience when printing to redirected client printers. Universal Printing policy settings enable the administrator to control print quality, spooling, and optimization defaults. See the printing topics in the Manage node of this documentation for more information.

Receiver Storefront Receiver Storefront authenticates users to XenDesktop sites and XenApp farms, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or a Web page. If your XenApp installation media or download package contains the Citrix Receiver Storefront folder, you can install the Receiver Storefront through the XenApp Server Role Manager provided in that media/package. If your installation media or download package does not contain the Citrix Receiver Storefront folder, you can download an updated XenApp package from My Citrix.

26

About Citrix XenApp 6.5 for Windows Server 2008 R2


This release includes several new features and enhancements to Citrix XenApp.

27

About This Release

What's New
q

Server Platform Support The XenApp software can be installed on the following platforms. For all system requirements, see System Requirements.
q

Microsoft Windows Server 2008 R2

q Microsoft Windows Server 2008 R2 Service Pack 1 Windows Desktop Experience Integration

Installed by default when installing the XenApp server role, this feature provides a Windows 7 look and feel including desktop customization. PowerShell script options enable administrators to control desktop and environment defaults while allowing end users to customize their desktops. When installed and enabled, this feature also removes the Windows Server Manager Console from the XenApp server's toolbar and relocates the Citrix XenApp administrative tools such as the AppCenter to the Start menu's Administrative Tools\Citrix folder. See Delivering XenApp to Software Services Subscribers for more information.
q

Citrix AppCenter The AppCenter provides a streamlined interface for performing management functions. From the AppCenter, you can manage components administered through other Citrix products, such as Citrix Secure Access and Citrix Single Sign-On. For Citrix XenApp, you can configure and monitor servers, server farms, published resources, and sessions.

Session Pre-launch, Session Linger, and Fast Reconnect This collection of features improves the user experience by eliminating delays when launching and maintaining sessions. By using configurable Session Pre-launch policy settings, a session is started automatically when a user logs on to the farm. By implementing Session Linger policy settings, sessions remain alive for a configurable period before termination, rather than terminating when users close applications. Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays when users reconnect to existing sessions.

Citrix HDX Enhancements XenApp includes the latest HDX enhancements:


q

HDX MediaStream Flash Redirection Audio Settings Multimedia Conferencing with HDX RealTime Increased 2D and 3D Application Scalability and Performance Assigning Priorities to Network Traffic

28

About This Release


q

Dynamic Windows Preview Support

Migration Center with Graphical User Interface With the choice of using a PowerShell cmdlet command line or graphical user interface, XenApp administrators can import application, folder, server configuration, and other XenApp object types from farms running previous versions of XenApp into XenApp 6.5 farms. See XenApp Migration Center for requirement and installation information.

Improved Performance for Pooled Desktops Application launch time in pooled desktop environments is improved through the use of virtual hard disks. Using the Streaming Profiler, virtual hard disks can be created when profiling an application. When the application is launched for the first time, the virtual hard disk is mounted and all the profile contents are copied to the virtual hard disk. For all subsequent launches, the application is launched from the virtual hard disk, resulting in a speedier launch.

Printing Optimization XenApp printing features include improved print session performance, lower bandwidth required for printing, and improved user experience when printing to redirected client printers. Universal Printing policy settings enable the administrator to control print quality, spooling, and optimization defaults. See the printing topics in the Manage node of this documentation for more information.

Receiver Storefront Receiver Storefront authenticates users to XenDesktop sites and XenApp farms, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or a Web page. If your XenApp installation media or download package contains the Citrix Receiver Storefront folder, you can install the Receiver Storefront through the XenApp Server Role Manager provided in that media/package. If your installation media or download package does not contain the Citrix Receiver Storefront folder, you can download an updated XenApp package from My Citrix.

29

Known Issues for XenApp 6.5 for Windows Server 2008 R2


Readme Version: 2

Contents
q

Installation Issues SmartAuditor Issues Application Streaming Issues Single Sign-on Issues Other Known Issues

30

Known Issues

Installation Issues
q

The Provisioning Services Target Device software resets your network connection during install. As a result, you may see user interface crashes or other failures if you select this component to install from a network location. Citrix recommends that you install the Provisioning Services Target Device software using one of the following methods [#229881]:
q

Install from a local DVD image or ISO Copy the installation media locally before performing the installation Select Manually Install Components from the Autorun menu

q Install with a command-line installation If you are installing the Configuration Manager Console Extension component of the XenApp Connector for Configuration Manager 2007 on a computer that has a remote Configuration Manager console installed, this warning might display: Configuration Manager Console Extension is selected, but ConfigMgr 2007 R2 or higher is not installed. Install will continue, but the console extension feature will not be operable without ConfigMgr. If the installed Configuration Manager console is from Microsoft System Center Configuration Manager 2007 R2 or R3, ignore this warning and continue installing the Configuration Manager Console Extension. The Configuration Manager Console Extension operates normally after installation. [#0034277]

After installing the Windows Desktop Experience Integration role through the XenApp Server Role Manager on a computer running a non-English operating system and configuring the CtxStartMenuTaskbarUser Group Policy Object (GPO), the PowerShell and Server Manager icons are not removed from the Taskbar as expected. Additionally, the Internet Explorer and Windows Media Player icons are not added to the Taskbar. This occurs because the script Enable-CtxDesktopExperienceUser.ps1 does not run correctly on non-English operating systems. To resolve this issue, download the updated Enable-CtxDesktopExperienceUser.ps1 script from CTX130208 in the Citrix Knowledge Center and replace the script on the XenApp server. [#261892]

SmartAuditor Issues
q

The SmartAuditor Player might fail to correctly display sessions launched with Citrix Receiver for Windows 3.0, instead showing a black screen in the Player window. To prevent this, disable the gradient fill feature on the XenApp server hosting the sessions by creating this DWORD registry on the server and setting its value to 1: HKLM\SOFTWARE\Citrix\Ica\Thinwire\DisableGdiPlusSupport. 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. Sessions recorded after this change is made display correctly. [#254644]

31

Known Issues
q

The SmartAuditor Player might fail to play sessions launched with the Citrix Online Plug-in for Windows 12.1 or Citrix Receiver for Windows 3.0. To play these sessions, edit this text in the SmAudPlayer.exe.config file: <add key=Windows value=12.00.9999/>. To view sessions launched with Online Plug-in for Windows 12.1, change 12.00.9999 to 12.99.9999. To view sessions launched with Receiver for Windows 3.0, change 12.00.9999 to 13.00.9999. [#254795, #255780] If SmartAuditor Administration components are installed on a XenApp server, the Citrix AppCenter console might not be able to complete discovery on the server. To resolve this issue, run: %SystemDrive%\Program Files (x86)\Citrix\System32\mfreg.exe /regserver.[#260133]

Application Streaming Issues


Issues for streaming Microsoft Office applications:
q

Profiling Microsoft Office 2010 SP1 is not supported in this release. For best practices for streaming Office 2010 applications, see http://support.citrix.com/article/CTX124565 in the Citrix Knowledge Center.

Although the fonts for Office 2010 applications do not load during profiling, the fonts load correctly when the applications are launched on the user device. [#262124] While profiling Microsoft Office 2010 applications, the option to Enable User Updates fails if the applications are published to stream to client desktops. To prevent this issue, do not use that profiling option for Office 2010 applications. [#259362] When using the RadeCache flushall command, you might receive an Access Denied error for Microsoft Office applications that are streamed to server. If this occurs, restart the server and run the flushall command again. [#262465]

When profiling Office 2010 on Windows 7 using the streaming profiler, if the operating system fails with a blue screen, the profiling workstation is probably missing Windows updates and a Microsoft Hotfix. To fix the issue, update the profiling workstation with the latest Windows updates and install the Microsoft Hotfix located at http://support.microsoft.com/kb/2359223/en-US. [#248727] Streamed Office Project 2007 has the following known issues:
q

Creating Visual Reports in Project 2007 is not supported when users stream Project to their desktops, even when Excel 2007 is also streamed. [#223304]

Running Office Web Components in Project 2007 is not supported on Windows 7 operating systems. [#223553] There are no workarounds for these issues.
q

Third-party known issues for application streaming:


q

This release does not support streaming IBM Personal Communications 4.2 or IBM ClearQuest. [#259830]

32

Known Issues
q

This release does not support streaming to clients through Web Interface on the following browsers: [#262650, 257135]
q

Microsoft Internet Explorer 9

Mozilla Firefox 4.0 Other known issues for application streaming:


q q

Launching the streamed application SAP 7.20 or earlier versions on a non-English platform displays the user interface in English. In addition, the language drop-down located at File > Options > General > Language is blank. As a workaround, install the SAP application in the profile, and after installation, open the command prompt inside the Profiler. Navigate to the Lang folder (C:\Program Files\SAP\FrontEnd\SAPgui\Lang\) and copy all the files to location C:\Lang\. [#260029]

After creating the first target, you cannot modify the "Enable User Updates" setting for the profile. The setting that you select for the first target applies to all other targets that you add to this profile, even if you manually select a different setting for subsequent targets. [#252225] The Load Balancing policy fails to prevent a fallback option for delivery of an application published for dual-mode streaming (streamed if possible, otherwise stream accessed from a server). The Load Balancing policy is supposed to be able to override the dual mode and force one or the other delivery method, disallowing the other, for the specified groups of users. In this release, the policy fails to prevent the fallback option, and the application will be delivered as specified in the publishing process. There is no workaround for this issue. [#258537]

An application that is streamed to the server cannot support more than one extra parameter when there is a space character in one of the parameters. While profiling, if you add an extra parameter that has spaces, only one parameter is supported. If there are no spaces in the parameter, multiple parameters are supported. [#262752] The AppHubWhiteList is sometimes deleted when you update the Offline Plug-in. After updating the plug-in, verify that the AppHubWhiteList is still included with the plug-in, and if missing, add it manually. [#262709]

Single Sign-on Issues


q

Features that require the Single Sign-on Service might fail if the Single Sign-on Plug-in 5.0 is installed on user devices that do not have the Visual C++ 8.0 runtime library installed. To prevent this, ensure that the Visual C++ 8.0 runtime library is installed on the user device before installing the Single Sign-on Plug-in. [#261051] On user devices that are running double-byte character language operating systems and have the Single Sign-on Plug-in 5.0 installed, Input Method Editor (IME) might fail against the question-based authentication dialog boxes for self-service password reset and self-service account unlock. To allow users to use account self-service from these user devices, ensure that their answers to security questions are in languages that do not require IME. [#262856]

33

Known Issues

Other Known Issues


q

XenApp servers might stop responding when multiple users are making frequent connections to the servers. Installing Service Pack 1 for Windows Server 2008 R2 or Microsoft Hotfix Windows.1-KB2383928-x64 on the server prevents this from occurring. See Microsoft Knowledge Base article #2383928 for more information. [#254069] Adobe Flash content playback is poor when using server-side content fetching over a slow WAN connection. This may result in response failures for the Flash window or Web browser and extremely long buffer times and pauses. To avoid this issue, use server-rendered Flash delivery for user devices using WAN connections. [#261879] When using Secure Gateway in an environment where data is encrypted using SSL protocol, SSL-secured sessions might disconnect unexpectedly, reporting an SSL Library Error 45. [#259611] When publishing content to a XenApp server, the access control settings appear differently depending on whether you view them with the AppCenter console or with the XenApp command Get-XAApplication. For example, while the AppCenter might correctly display default settings, the XenApp command Get-XAApplication might display that no Access Gateway connections are allowed. This issue affects only the display of these settings; users can access the published content normally. To ensure a consistent display of access control settings, use the XenApp SDK to configure and publish content applications. [#261283]

Published applications might fail to launch, displaying a black window in place of the application window, if system memory is low. This condition is indicated by this system event log message, with picadd as its source: "The Citrix Thinwire driver stopped because it cannot allocate the required memory. You may need to manually disconnect and restart any existing sessions." [#261647] During session printer enumeration, Adobe Reader 10.1 may fail. As a workaround, edit your Adobe Reader preferences and uncheck the Enabled Protected Mode at startup checkbox. [#285090]

34

System Requirements for XenApp 6.5


System requirements for the XenApp server role and the Citrix AppCenter are described below. System requirements for other XenApp features, components, and related technologies are described in their respective system requirements documentation; that includes receivers, plug-ins and agents, Web Interface, Single Sign-on, Service Monitoring, EdgeSight, SmartAuditor, Application Session Recording, Provisioning Services, and Power and Capacity Management. To ensure the availability of XenApp 6.5 features and correct operation:
q

Use the Citrix License Server Version 11.9 (minimum). Install the most recent version of any receivers, plug-ins, and agents you use. At the time of its release, XenApp 6.5 was tested with Receiver for Windows 3.0 (with plug-in 13.0). The Citrix Online Plug-in (Web and Full) 12.1 was also tested and can be used, but some XenApp 6.5 features will not be available.

You must be in the Administrators group to install and configure the XenApp server role. Elevating your privilege to local administrator through User Account Control is not a substitute for Administrators group membership. Important:
q

Do not install XenApp on a domain controller. Citrix does not support installing XenApp on a domain controller. Do not join servers running this XenApp version to a deployment with servers running previous XenApp versions (including early release and Technical Preview versions). You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix does not support using a console from a previous XenApp release to manage XenApp 6.5 farms. (However, you can use the AppCenter from the XenApp 6.5 media to manage a XenApp 6.0 farm.) See Installing and Configuring XenApp for additional guidance, including tasks to complete before installing and configuring XenApp.

Deploying Prerequisites
During a wizard-based installation, the XenApp Server Role Manager (using the Server Role Installer) automatically installs XenApp prerequisites, as noted below. For command-line installations, you must install the prerequisite software and Windows roles before installing XenApp (except as noted). You can deploy prerequisites with PowerShell cmdlets, the Microsoft ServerManagerCmd.exe command, or the Microsoft Deployment Image Servicing and Management (DISM) tool.

35

System Requirements If installation of a required Windows role or other software requires a restart (reboot), restart the server before starting the XenApp server role installation.

XenApp Server Role


Supported operating systems: Windows Server 2008 R2 and Windows Server 2008 R2 SP1 (Enterprise, Standard, Datacenter, and Foundation). Most servers running the supported operating systems meet the hardware requirements for XenApp with ample processing power to host user sessions accessing the published resources. However, additional research may be needed to determine if current hardware meets the requirements.
q

CPU:
q

64-bit architecture with Intel Pentium Xeon family with Intel Extended Memory 64 Technology AMD Opteron family AMD Athlon 64 family

Compatible processor Memory: 512MB RAM (minimum)


q

Disk space: up to 3.2GB

The XenApp Server Role Manager deploys the following software (except as noted), if it is not already installed:
q

.NET Framework 3.5 SP1 (this is a prerequisite for the XenApp Server Role Manager; it is deployed automatically when you choose to add the XenApp server role from the Autorun menu) Windows Server Remote Desktop Services role (if you do not have this prerequisite installed, the Server Role Manager installs it and enables the RDP client connection option; you will be asked to restart the server and resume the installation when you log on again) Windows Application Server role Microsoft Visual C++ 2005 SP1 Redistributable (x64) Microsoft Visual C++ 2008 SP1 Redistributable (x64)

When you install the XenApp server role, XML and Internet Integration Service (IIS) integration is an optional component. When this component is installed, the Citrix XML Service and IIS share a port (default = 80). When this component is not installed, the Citrix XML Service defaults to standalone mode with its own port settings. You can change the port during or after XenApp configuration. The Server Role Installer checks for installed IIS role services and whether the component is selected or specified. For complete information, see Before Installing XenApp. The IIS role services are listed below.

36

System Requirements
q

Web Server (IIS) > Common HTTP Features > Default Document (selecting this automatically selects Web Server (IIS) > Management Tools > Management Console, which is not required or checked for XenApp installation) Web Server (IIS) > Application Development > ASP.NET (selecting this automatically selects Web Server (IIS) > Application Development > .NET Extensibility; although not checked for XenApp installation, ASP.NET requires .NET Extensibility) Web Server (IIS) > Application Development > ISAPI Extensions Web Server (IIS) > Application Development > ISAPI Filters Web Server (IIS) > Security > Windows Authentication Web Server (IIS) > Security > Request Filtering Web Server (IIS) > Management Tools > IIS 6 Management Compatibility (includes IIS 6 Metabase Compatibility, IIS 6 WMI Compatibility, IIS 6 Scripting Tools, and IIS 6 Management Console)

If you plan to use Philips SpeechMike devices with XenApp, you may need to install drivers on the servers hosting sessions that record audio before installing XenApp. For more information, see Citrix information on the Philips web site.

AppCenter
XenApp Management includes the AppCenter. By default, the AppCenter is installed on the same server where you install the XenApp server role; however, you can install and run the AppCenter on a separate computer. To install the AppCenter on a workstation, from the XenApp Autorun menu, select Manually Install Components > Common Components > Management Consoles. Supported operating systems:
q

Windows Server 2008 R2, 64-bit edition, SP1 Windows Server 2008 R2, 64-bit edition Windows Server 2008 Enterprise, 32-bit edition, SP2 Windows Server 2003 R2, 32-bit and 64-bit editions Windows Server 2003, 32-bit and 64-bit editions, SP2 Windows 7 Enterprise, 32-bit and 64-bit editions, SP1 Windows Vista Enterprise, 32-bit and 64-bit editions, SP2 Windows XP Professional, 32-bit edition, SP3 Windows XP Professional, 64-bit edition, SP2

Requirements:

37

System Requirements
q

Disk space: 25MB Microsoft Management Console (MMC):


q

For Windows Vista, Windows 7, Windows Server 2008 R2, and Windows Server 2008 R2 SP1: MMC 3.0 (installed by default)

For other supported Windows operating systems: MMC 2.0 or 3.0 The XenApp Server Role Manager deploys the following software, if it is not already installed:
q q

Microsoft .NET Framework 3.5 SP1 Microsoft Windows Installer (MSI) 3.0 Microsoft Windows Group Policy Management Console Microsoft Visual C++ 2005 SP1 Redistributable (x64) Microsoft Visual C++ 2008 SP1 Redistributable (x64) Microsoft Visual C++ 2008 SP1 Redistributable Microsoft Visual C++ 2005 SP1 Redistributable Microsoft Primary Interoperability Assemblies 2005

If you install the AppCenter on a computer that previously contained the Microsoft Group Policy Management Console (GPMC) and a Citrix Delivery Services Console earlier than the version delivered with XenApp 6.0, you may also need to uninstall and reinstall the Citrix XenApp Group Policy Management Experience (x64) program in order to use the GPMC to configure Citrix policies.

Data Store Database


The following databases are supported for the XenApp data store:
q

Microsoft SQL Server 2008 Express R2 Microsoft SQL Server 2008 Express SP3 Microsoft SQL Server 2008 R2 Microsoft SQL Server 2008 SP2 Microsoft SQL Server 2005 SP4 Oracle 11g R2 32-bit Enterprise Edition

Microsoft SQL Server 2008 Express can be deployed for you by the XenApp Server Configuration Tool when creating a XenApp farm.

38

System Requirements For information about the latest supported database versions, see CTX114501. For information about requirements, see Data Store Database Reference.

39

Design and Plan


XenApp is the central software component of the Citrix Windows Application Delivery Infrastructure. The goals of XenApp and the Citrix Windows Application Delivery Infrastructure are to deliver on-demand applications to both physical and virtual desktops, and to determine and provide the best method of delivery. XenApp offers three methods for delivering applications to user devices, servers, and virtual desktops:
q

Server-side application virtualization: applications run inside the Data Center. XenApp presents each application interface on the user device, and relays user actions from the device, such as keystrokes and mouse actions, back to the application. Client-side application virtualization: XenApp streams applications on demand to the user device from the Data Center and runs the application on the user device. VM hosted application virtualization: problematic applications or those requiring specific operating systems run inside a desktop on the Data Center. XenApp presents each application interface on the user device and relays user actions from the device, such as keystrokes and mouse actions, back to the application.

To provide these types of application delivery, you have many choices of deployment designs and XenApp features, which you can tailor for your users' needs. A typical process for planning a XenApp farm includes: 1. Becoming familiar with XenApp and XenApp Setup by creating a small, one-server or two-server test farm. 2. Deciding which applications to deliver to users. 3. Determining how you want to deliver applications - this includes testing and evaluating the applications and peripheral requirements. 4. Determining application to application communication, where to install the applications on XenApp servers, and which applications can be collocated. 5. Determining the number of servers you need for applications. 6. Determining the total number of servers you need for your farm and evaluating hardware requirements. 7. Creating the network infrastructure design. 8. Defining the installation processes. 9. Creating and testing a pre-production pilot farm based on your farm design. 10. Releasing the farm into production. To help you understand how a XenApp deployment delivers applications so you can complete planning tasks, consider the following diagram.

40

Plan

A XenApp deployment consists of three deployment groups: user device (represented in this diagram by Citrix Receiver), Access Infrastructure, and Virtualization Infrastructure.
q

On the left of this diagram is Citrix Receiver, which represents the set of devices on which you can install client software. Citrix Receiver manages the client software that enables your users to interact with virtualized applications. When designing a XenApp deployment, you consider how your users work, their devices, and their locations. Access Infrastructure represents secure entry points deployed within your DMZ and provide access to resources published on XenApp servers. When designing a XenApp deployment, you provide secure access points for the different types of users in your organization. Virtualization Infrastructure represents a series of servers that control and monitor application environments. When designing a XenApp deployment, you consider how applications are deployed based on your user types and their devices, the number of servers you need, and which features you want to enable in order to provide the support, monitoring, and management your organization requires.

The following diagram shows the access infrastructure in greater detail.

41

Plan In this access infrastructure diagram:


q

Citrix Receiver runs the applications. Onsite users within your corporate firewall interact directly with the XenApp Web and Services Site. Remote-site users access applications through sites replicated by Citrix Branch Repeater. Off-site users access applications though secure access, such as Access Gateway. The Merchandising Server makes available self-service applications to your users through Citrix Dazzle. The XML Service relays requests and information between the Access Infrastructure and the Virtualization Infrastructure.

The following diagram shows the virtualization infrastructure in greater detail.

In this virtualization infrastructure diagram:


q

The XML service relays information and requests. Based on Active Directory profiles and policies, the XenApp servers invoke the correct application delivery type for the user. The XenApp servers provide server-side application virtualization and session management. Session and deployment configuration information are stored in data collectors and a central data store represented by the deployment data store. The App Hub provides Streamed Application Profiles, which are client-side virtualization applications housed in your enterprise storage. The VM Hosted Apps server isolates problematic applications inside a seamless desktop, which, depending on the user profile, can be virtualized on the user device or on the server. The desktop images are provisioned through Provisioning Server. Session and

42

Plan server configuration information are stored in the enterprise database.


q

Provisioning Services delivers desktops to servers, which are stored as desktop images in your enterprise database. SmartAuditor provides session monitoring. Recorded sessions are stored in your enterprise storage and configuration information is stored in the deployment data store. Service Monitoring enables you to test server loads so you can estimate how many servers you need for your deployment and to monitor those servers once they are deployed. Power and Capacity Management enables you to reduce power consumption and manage server capacity by dynamically scaling the number of online servers. Single Sign-on provides password management for virtualized applications. Passwords are stored in the account authority.

43

Farm Terminology and Concepts

Terminology
The XenApp planning documentation uses the following terminology: Multi-user environment An environment where applications are published on servers for use by multiple users simultaneously. Production farm A farm that is in regular use and accessed by users. Design validation farm A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm. Pilot farm A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is based on access by select users, and then adding users until all users access the farm for their everyday needs.

About Infrastructures
XenApp farms have two types of infrastructures:
q

The virtualization infrastructure consists of the XenApp servers that deliver virtualized applications and VM hosted Applications, and XenApp servers that support sessions and administration, such as the data store, data collector, Citrix XML Broker, Citrix License Server, Configuration Logging database (optional), Load Testing Services database (optional), and Service Monitoring components. Access infrastructure consists of server roles such as the Receiver Storefront, Web Interface, Secure Gateway (optional), and Access Gateway (optional) that provide access administration.

In small deployments, you can group one or more server functions together. In large deployments, you provide services on one or more dedicated servers. Factors other than size can affect how you group server functions. Security concerns, virtualized servers, and user load play a part in determining which functions can be collocated.

44

Design and Plan Typically, in larger farms, you segregate session and administrative functions onto distinct servers. For small farms, you might have one server hosting infrastructure functions and multiple servers hosting published applications. Small farms that require redundancy might have one or two servers hosting session and administrative functions. For example, in a small farm, the data store might be configured on the same server as the data collector and the XML Broker and, perhaps also the Citrix License Server. Medium and large farms might group similar functions. For example, the XML Broker might be grouped with the data collector. In some larger deployments, each infrastructure service would likely have one or more dedicated servers.

About Virtualization Infrastructure


The virtualization infrastructure, which is the center of a XenApp deployment, concerns the following concepts: Application enumeration Application enumeration is when Citrix client software lists virtualized applications available on the XenApp servers. The client software transmits data to locate servers on the network and retrieves information about the published applications. For example, during enumeration, Citrix Receiver communicates through the Citrix XML Service with the XenApp server to determine applications available for that user. Application publishing To deliver an application to your users, whether virtualized on the desktop or the server, use the AppCenter to publish the application. Citrix Licensing A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone server, depending on your farms size. After you install the license server, download the appropriate license files and add these to the license server. Data Store The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store. Data Collector A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm.

45

Design and Plan By default, the data collector is configured on the first server when you create the farm, and all other servers configured with the controller server mode have equal rights to become the data collector if the data collector fails. When the zones data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server. Applications are typically not published on the data collector. Zones A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors. The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farms that span WANs. Streaming Profiles You can deliver applications to users by either virtualizing them on the desktop (streaming) or by virtualizing them on the server (hosting). If you are virtualizing applications on the desktop, either streaming to the client or server, create a streaming profile server in your environment. To virtualize applications on the desktop, you create profiles of the application and then store the profile on a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines the profile, as well as the target files, a hash key file, the icons repository (Icondata.bin), and a scripts folder for pre-launch and post-exit scripts. Receiver Storefront Receiver Storefront authenticates users to XenDesktop sites and XenApp farms, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or a Web page. The Receiver Storefront database records details of resource subscriptions and shortcuts to enable synchronization of users' desktops and applications across their devices. Web Interface You can use the Web Interface in any environment where users access their applications using either Receiver or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the Web Interface can be collocated with other functions. XenApp Web and XenApp Services Sites XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp Web or XenApp Services site, either directly or through Receiver or the Access Gateway, the site:
q

Forwards the users credentials to the Citrix XML Service

46

Design and Plan


q

Receives the set of applications available to that user by means of the XML Service Displays the available applications to the user either through a Web page or by placing shortcuts directly on the users computer

Citrix XML Broker and the Web Interface The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:
q

Receives the users credentials from the Web Interface and queries the server farm for a list of published applications that the user has permission to access. The XML Broker retrieves this application set from the Independent Management Architecture (IMA) system and returns it to the Web Interface.

Upon receiving the users request to launch an application, the broker locates the servers in the farm that host this application and identifies which of these is the optimal server to service this connection based on several factors. The XML Broker returns the address of this server to the Web Interface. The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on every server during XenApp installation. However, only the XML Service on the server specified in the Web Interface functions as the broker. (The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers.
q

The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service, regardless of whether it is hosted on a dedicated server or collocated with other functions.

47

Farm Terminology and Concepts

Terminology
The XenApp planning documentation uses the following terminology: Multi-user environment An environment where applications are published on servers for use by multiple users simultaneously. Production farm A farm that is in regular use and accessed by users. Design validation farm A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm. Pilot farm A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is based on access by select users, and then adding users until all users access the farm for their everyday needs.

About Infrastructures
XenApp farms have two types of infrastructures:
q

The virtualization infrastructure consists of the XenApp servers that deliver virtualized applications and VM hosted Applications, and XenApp servers that support sessions and administration, such as the data store, data collector, Citrix XML Broker, Citrix License Server, Configuration Logging database (optional), Load Testing Services database (optional), and Service Monitoring components. Access infrastructure consists of server roles such as the Receiver Storefront, Web Interface, Secure Gateway (optional), and Access Gateway (optional) that provide access administration.

In small deployments, you can group one or more server functions together. In large deployments, you provide services on one or more dedicated servers. Factors other than size can affect how you group server functions. Security concerns, virtualized servers, and user load play a part in determining which functions can be collocated.

48

Farm Terminology and Concepts Typically, in larger farms, you segregate session and administrative functions onto distinct servers. For small farms, you might have one server hosting infrastructure functions and multiple servers hosting published applications. Small farms that require redundancy might have one or two servers hosting session and administrative functions. For example, in a small farm, the data store might be configured on the same server as the data collector and the XML Broker and, perhaps also the Citrix License Server. Medium and large farms might group similar functions. For example, the XML Broker might be grouped with the data collector. In some larger deployments, each infrastructure service would likely have one or more dedicated servers.

About Virtualization Infrastructure


The virtualization infrastructure, which is the center of a XenApp deployment, concerns the following concepts: Application enumeration Application enumeration is when Citrix client software lists virtualized applications available on the XenApp servers. The client software transmits data to locate servers on the network and retrieves information about the published applications. For example, during enumeration, Citrix Receiver communicates through the Citrix XML Service with the XenApp server to determine applications available for that user. Application publishing To deliver an application to your users, whether virtualized on the desktop or the server, use the AppCenter to publish the application. Citrix Licensing A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone server, depending on your farms size. After you install the license server, download the appropriate license files and add these to the license server. Data Store The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store. Data Collector A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm.

49

Farm Terminology and Concepts By default, the data collector is configured on the first server when you create the farm, and all other servers configured with the controller server mode have equal rights to become the data collector if the data collector fails. When the zones data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server. Applications are typically not published on the data collector. Zones A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors. The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farms that span WANs. Streaming Profiles You can deliver applications to users by either virtualizing them on the desktop (streaming) or by virtualizing them on the server (hosting). If you are virtualizing applications on the desktop, either streaming to the client or server, create a streaming profile server in your environment. To virtualize applications on the desktop, you create profiles of the application and then store the profile on a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines the profile, as well as the target files, a hash key file, the icons repository (Icondata.bin), and a scripts folder for pre-launch and post-exit scripts. Receiver Storefront Receiver Storefront authenticates users to XenDesktop sites and XenApp farms, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or a Web page. The Receiver Storefront database records details of resource subscriptions and shortcuts to enable synchronization of users' desktops and applications across their devices. Web Interface You can use the Web Interface in any environment where users access their applications using either Receiver or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the Web Interface can be collocated with other functions. XenApp Web and XenApp Services Sites XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp Web or XenApp Services site, either directly or through Receiver or the Access Gateway, the site:
q

Forwards the users credentials to the Citrix XML Service

50

Farm Terminology and Concepts


q

Receives the set of applications available to that user by means of the XML Service Displays the available applications to the user either through a Web page or by placing shortcuts directly on the users computer

Citrix XML Broker and the Web Interface The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:
q

Receives the users credentials from the Web Interface and queries the server farm for a list of published applications that the user has permission to access. The XML Broker retrieves this application set from the Independent Management Architecture (IMA) system and returns it to the Web Interface.

Upon receiving the users request to launch an application, the broker locates the servers in the farm that host this application and identifies which of these is the optimal server to service this connection based on several factors. The XML Broker returns the address of this server to the Web Interface. The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on every server during XenApp installation. However, only the XML Service on the server specified in the Web Interface functions as the broker. (The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers.
q

The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service, regardless of whether it is hosted on a dedicated server or collocated with other functions.

51

Planning a Successful User Experience


Two key factors impact your users' satisfaction when working in a multi-user environment: how quickly sessions start, and how easily users can print.

Session Start-up Times


Certain factors can cause sessions to start slower than necessary.
q

Printer autocreation policy settings - Consider limiting the number of printers that are autocreated if session start time is a factor. Network activities occurring independently of sessions - Operations such as logging on to Active Directory, querying Lightweight Directory Access Protocol (LDAP) directory servers, loading user profiles, executing logon scripts, mapping network drives, and writing environment variables to the registry, can affect session start times. Also, connection speed and programs in the Startup items within the session, such as virus scanners, can affect start times. Roaming profile size and location - When a user logs onto a session where Microsoft roaming profiles and home folders are enabled, the roaming profile contents and access to that folder are mapped during logon, which uses additional resources. In some cases, this can consume significant amounts of the CPU usage. Consider using home folders with redirected personal folders to mitigate this problem. Whether the data collector has sufficient resources to make load balancing decisions efficiently - In environments with collocated infrastructure servers, Citrix suggests hosting the Citrix XML Broker on the data collector to avoid delays. License server location - For WANs with multiple zones, where the license server is in relation to the zone.

Printing Configuration
Your printing configuration directly affects how long sessions take to start and the traffic on your network. Planning your printing configuration includes determining the printing pathway to use, how to provision printers in sessions, and how to maintain printer drivers. Consider these recommendations:
q

Use Citrix Universal printer drivers and the Universal Printer whenever possible. This results in fewer drivers and less troubleshooting. Disable the automatic installation of printer drivers, which is the default setting. Adjust printer bandwidth using XenApp policy rules, if appropriate.

52

Planning a Successful User Experience


q

If printing across a WAN, use the XenApp Print job routing policy rule to route print jobs through the client device. Test new printers with the Stress Printers utility, which is described in the Citrix Knowledge Center.

Choose printers that are tested with multiuser environments. Printers must be PCL or PS compatible and not host-based. The printing manufacturer determines whether printers work in a XenApp environment, not Citrix.

53

Farm Hardware Considerations


The number of users a XenApp server can support depends on several factors, including:
q

The servers hardware specifications The applications deployed (CPU and memory requirements) The amount of user input being processed by the applications The maximum desired resource usage on the server (for example, 90% CPU usage or 80% memory usage)

General recommendations for selecting and configuring farm hardware include:


q

RAID - In multiprocessor configurations, Citrix recommends a RAID (Redundant Array of Independent Disks) setup. XenApp supports hardware and software RAID. Reducing hard disk failure - Hard disks are the most common form of hardware failure. You can reduce the likelihood of hardware failure with a RAID 1 (mirroring) and RAID 5 (striped set with distributed parity) configuration. If RAID is not an option, a fast Serial Attached SCSI (SAS) or a Small Computer System Interface (SCSI) Ultra-320 drive is recommended. Disk speed - Faster hard disks are inherently more responsive and might eliminate or curtail disk bottlenecks. Number of controllers - For quad or eight-way servers, Citrix recommends installing at least two controllers: one for the operating system and another to store applications and temporary files. Isolate the operating system as much as possible, with no applications installed on its controller. This principle also applies in small farms. If possible (assuming a multicore or multiprocessor system), install the operating system on a separate hard drive from XenApp and the applications. This prevents input/output bottlenecks when the operating system needs to access the CPU. Distribute hard drive access load as evenly as possible across the controllers. Dual-processor (dual-core) deployments combine overall efficiency and a lower total cost of ownership. However, once a system has a dual-core processor, implementing additional processors does not necessarily provide proportionate performance increases. Server scalability does not increase linearly with the number of processors: scalability gains level off between eight to sixteen CPU cores.

Hard disk partitions - Partition and hard-disk size depend on the number of users connecting to the XenApp server and the applications on the server. Because each users Remote Desktop Services profile is loaded on the server, consider that large numbers of user profiles can use gigabytes of disk space on the server. You must have enough disk space for these profiles on the server.

54

Planning for Applications and Server Loads


Before you can determine how many servers you need in your farm and on which servers to install applications, decide which applications you want to deliver and how you want to deliver them. Consider these factors when defining your farms hardware and operating system configuration:
q

Can I run the applications? Citrix recommends testing non-Vista-compliant applications before you publish them on your farm. Some non-Vista-compliant applications run using the Application Compatibility feature. How many users do I anticipate will want to connect to each application during peak and off-peak hours? Do I need to allocate servers for load balancing? Will users be accessing certain applications frequently? Do I want to publish all of these applications on the same server to facilitate session sharing and reduce the number of connections to a server? If you want to use session sharing, you might also want users to run applications in seamless windows. Will my organization need to provide proof of regulatory compliance for certain applications? Will any applications undergo a security audit? If you intend to use SmartAuditor to record sessions on these servers, install the SmartAuditor agent on these servers. In addition, make sure the servers have sufficient system resources to ensure adequate performance. Will any of my applications be graphically intensive? If so, consider using the XenApp SpeedScreen, Memory Utilization Management, or CPU Utilization Management features as well as more robust hardware for sessions hosted on these servers.

55

Assessing Applications for XenApp Compatibility


Ensure applications are compatible with the server operating system and are multiuser compatible. Application compatibility drives the application delivery method (for example, accessed from the server, streamed to server, or streamed to client desktops). Evaluate whether or not applications are compatible with multiuser environments and, if so, the application servers scalability. Before testing applications for compatibility, investigate how the application works with Remote Desktop Services or XenApp. Remote Desktop Services-compliant and Windows Logo certified applications experience few, if any, issues compared with noncompliant applications. Initial application compatibility testing typically involves publishing the application so that it is installed and hosted on a server in a test farm and having multiple test users connect to it. Applications that function correctly should be tested for conflicts with other applications you want to install on the server and, then, scalability. Applications that do not function correctly might not have been designed for multiuser, multiapplication environments. Applications not designed for these environments can conflict with other applications or have scalability or performance issues. Registry settings, attempts to share files or DLLs, requirements for the exclusive use of files or DLLs, or other functionality within an application can make it incompatible. You can resolve some application issues through streaming, using features like Virtual IP, or siloing the application. After testing, if these solutions do not work, you might need to find and fix the root cause of the problem. To identify root applications issues, consider using tools like the Microsoft Application Compatibility Toolkit (ACT) or Microsofts Windows Sysinternals. Examples of common issues include:
q

.INI files that contain hard-coded file path names, database connection settings, and read/write file locking configurations that need to be reconfigured to prevent file conflicts. Custom applications developed with hard-coded paths in the registry. Applications that use the computer name or IP address for identification purposes. Because a server can run multiple instances of the application, all instances could use the same IP address or computer name, which can cause the application to fail.

When you find any of these hard-coded settings or other conflicts, document the setting in your farm design document. After you find resolutions to these issues, design your farm and test your design by creating a pilot test farm.

56

Evaluating Application Delivery Methods


The application delivery method is a factor in determining the number of servers in a farm and their individual hardware requirements. How you choose to deliver applications depends on your organization's needs and end-users' requirements. For example, some organizations use XenApp to streamline administration. In other organizations, the existing hardware infrastructure might affect the delivery method selected, as can the types of applications to be delivered. In addition, some end-users might run all applications while connected to the company network, while others might work in remote locations and run applications while disconnected from the network.

Method/Description Installed on the server:

Advantages
q

Considerations
q

Applications are installed on the server, where the processing takes place, and accessed from the server. This is the traditional XenApp application delivery model. For many organizations, this provides the lowest cost of ownership for IT resources because it provides the greatest scalability.

This method provides a consistent user experience regardless of the user device. You manage applications centrally. User devices do not require extensive resources, such as excessive memory or hard drive space. This delivery method supports thin clients. This method is effective for applications with components that are intertwined with the operating system (such as a .NET framework).

Farm servers require sufficient resources to support the applications. Users must be connected to the server or network to run the applications (no offline access).

57

Evaluating Application Delivery Methods Streamed to server: Executables for applications are put in profiles and stored on a file server or Web server (the App Hub); however, when launched, they stream to the server, and application processing takes place on the server. Unlike installed applications, streamed applications are stored in the App Hub and provide application isolation by design.
q

This method has similar advantages as for installed applications, including a consistent user experience, central management, and use of server resources instead of those of the user device. In many cases, streaming to server lets conflicting applications, such as multiple versions of the same application, run on the same server without needing to silo them. Updating applications is simplified because you update only a single application profile. Users can have the local application experience, but you manage the applications centrally. Users might have a better experience when resource-intensive applications, such as graphics applications, are streamed to desktops. Using application properties and Citrix policies and filters for Offline Applications, you control the applications and users that have offline access, as well as the license period for offline use.

Farm servers require sufficient resources to support the applications. Users must be connected to the server or network (no offline access). Some applications are not candidates for profiling, such as those using a .NET framework.

Streamed to desktop: Executables for applications are put in profiles and stored on a file server or Web server (the App Hub). When launched, the files required to execute the application are streamed to the user device, and application processing takes place on the user device instead of the XenApp server. When applications are streamed to the user device, the user experience is similar to running applications locally. After applications are cached on the user device, users can continue running the apps after disconnecting from the network (referred to as offline access).

User devices must have sufficient resources to run the applications locally; the user devices cannot be thin clients. User devices must run Windows operating systems, including Windows 7, XP, or Vista.

58

Evaluating Application Delivery Methods Dual mode delivery:


q

When you select "streamed if possible, otherwise accessed from a server" (referred to as dual mode or fallback), XenApp tries to stream the application to the user device first, but uses the backup access method if streaming to desktop is not supported on the user device. For example, you can specify that some users, such as sales personnel, run applications streamed to desktop when they are accessing the applications from Windows devices, and run them as installed applications when they are accessing them from handheld mobile or kiosk-type devices.

This method provides the most versatility for application delivery, offering all the advantages of streaming to desktops for supported user devices, plus a backup delivery method for the rest. You control delivery options centrally using Citrix policies and filters, such as the server's Load Balancing Policies for Streamed App Delivery.

For the backup method to occur, ensure that the application is either installed on the XenApp server or the streaming profile is configured for a target operating system that matches the server.

Choosing Between Published Desktops and Published Applications


Before selecting the method for delivering applications, decide if you want to publish the desktop or publish applications.
q

Publishing the desktop - Presents users with an entire Windows Server desktop when they log onto XenApp. (For security, the desktop should be locked down .) Publishing applications - Publishes specific applications and delivers only those applications to users. This option provides greater administrative control and is used most frequently.

You can use policies to prevent users from accessing server drives and features with both methods of application delivery.

59

Planning for Application Streaming


Streaming applications requires a workstation for creating the application profiles and a streaming file share to store the profiles. For the Streaming Profiler, use a separate, clean workstation with an operating system similar to that of your end-users. For the streaming file share server, Citrix suggests the following hardware:
q

Network-attached storage (NAS) or storage area network (SAN) solution, if feasible. A RAID storage configuration, depending on the fault-tolerant solution desired. A single 1 Gbps network card or multiple 100 Mbps cards. If your network infrastructure and configuration does not support this speed, use dual network cards; this configuration doubles the connection speed of a traditional single network-card configuration.

Streaming file shares can be hosted on a file server or a Web server. There are two configurations for a streaming file share in branch office environments:
q

A streaming file share in each branch office hosted on network file servers - For performance (and in some countries, legal) reasons, branch offices cannot connect to a network file server in a main office. To store streaming profiles on a network file server, configure a streaming file share in each branch office. A streaming file share in the main office hosted on a Web Server - Using a Web server sends all the traffic between the client devices and the file share over HTTP or HTTPS, which is faster than a file transmission protocol.

Using a Web server for the file share reduces the need to have a file share in each branch office for performance reasons. Instead of putting a file share at each branch office, you can put all the profiles on the Web server file share at the main office.

60

Placing Applications on Servers


When designing your farm, consider the following:
q

The servers on which the applications are installed If load balancing or preferential load balancing changes your need to dedicate servers to mission-critical or highly used applications The geographic location of the servers delivering applications (for WANs and organizations with branch offices)

Grouping Applications on Servers


Traditionally, two strategies for grouping applications on servers are siloing applications and not siloing applications. When applications are siloed on farm servers, each server has a limited number of applications. Some servers might have only one application; others might have a set of interrelated applications. For example, you might install a medical application on Server A, and on Server B install an enterprise resource planning (ERP) application. However, if the ERP application is integrated with email, you might also have an email client on Server B. Siloing is sometimes required when applications have unique hardware requirements, for business reasons, to segregate mission-critical applications, or to separate frequently-updated applications. However, siloing applications is not as efficient as nonsiloed applications for hardware use and network traffic. With a nonsiloed approach, you install all applications on each server. Applications can be installed traditionally or in isolation (installing them in separate profiles). Citrix recommends installing applications that interact with each other on the same server, or including them in the same streaming profile. For example, if an application interacts with an email client by letting users send email notifications, install the application and the email client on the same server. Likewise, if applications share settings and preferences (such as Microsoft Office), install them on the same server.

Advantages

Disadvantages

61

Placing Applications on Servers Siloed


q

It is easy to track the applications location and usage Centralization makes it is easy to configure and maintain the application Other applications do not interfere with the installed application Can be useful for mission-critical applications Reduces the number of servers required for applications in smallto medium-sized farms Might simplify user permissions and ensure consistent settings during application installation

Additional servers are required to ensure sufficient redundancy

Nonsiloed
q q

Cannot be used when applications conflict with other applications

A single server is accessed by each user and session sharing is ensured By using features such as Load Manager and Preferential Load Balancing, you might not need to silo mission-critical applications or applications with high levels of peak usage.
q

When an application conflicts with other applications, rather than silo it on one server, consider streaming the application. Streaming the application effectively isolates it, which allows conflicting applications to run on a single server, reducing the need for silos.

Planning Server Loads


Consider how you want to balance server loads. You might want to load balance resource-intensive, mission-critical, or high-availability applications. XenApp offers two methods of load balancing:
q

Load Manager - Lets you balance new connections to the server. When a user launches the first published application, that user session is established on the least loaded server in the farm, based on criteria you configured. When the user launches a second application that is published on the same server, the existing session is shared, and no load management occurs. However, if that application is not published on the same server, Load Manager is invoked and another load-balancing decision is made. Load-balancing is enabled by default. When you publish an application on multiple servers, load balancing automatically ensures that the user is sent to the least-loaded server.

Preferential Load Balancing - Lets you allocate a specific portion of CPU resources to a specific session or application. You can use Preferential Load Balancing to assign importance levels (Low, Normal, or High) to specific users and applications. For

62

Placing Applications on Servers example, doctors in a hospital could be specified as important users and MRI scans or X-rays could be specified as important applications. These important users and applications with higher levels of service have more computing resources available to them. By default, a Normal level of service is assigned to all users and applications. Different application workloads can co-exist on a server; simply assign important applications a higher importance level. The key difference between the Load Manager and Preferential Load Balancing features is that the Preferential Load Balancing can be used to treat each session differently, whereas Load Manager treats each session the same. Although you can use applications as the basis for Load Manager decisions, Citrix does not recommend it. Citrix recommends invoking Load Manager based on the server only. Citrix does not recommend load balancing across zones on a WAN.

Centralizing or Distributing Application Servers


For organizations with geographically dispersed sites, application servers might be located centrally with the infrastructure servers (for example, in a data center) or decentrally, near the users who access the applications or in the same geographic region as the users. Citrix recommends placing application servers logically near any data sources. For example, for an enterprise resource planning application, collocate those XenApp servers within the same data center. Another example is a multinational corporation that uses Microsoft Exchange 2007 as the data source for email. Although the company could centralize all the Exchange servers at the primary data center, they would be more likely to enable the Exchange servers within each region and then locate the XenApp servers hosting Outlook there as well.

Servers centralized at one site

Advantages
q

Disadvantages
q

Centralized server administration and support. Centralized application management. Potentially better physical security than in branch offices.

Single point of failure; if the site loses connectivity, users have no alternative access.

63

Placing Applications on Servers Servers distributed across multiple sites

Enhanced business continuity and redundancy; if one site loses connection, it does not affect all application access. When data is maintained at different sites, placing servers at those sites provides users with local access to the data. Sites can administer their own servers. Zone Preference and Failover can be invoked if multiple zones.

Server-to-server communication crosses the WAN. If users need access to multiple sites, you might need to coordinate and replicate domains, trusts, user profiles, and data. Sites might need added local administration and support.

q q

Determining How to Install Applications


In large farms, installing applications on servers can be time consuming. Also, applications on load-balanced servers require identical configuration options and settings. To solve these issues, you can install these applications by using Installation Manager, installation scripts, Microsoft System Center Configuration Manager (formerly known as Systems Management Server (SMS)), or streaming the applications.

64

Determining the Number of XenApp Servers to Deploy


After you identify the applications you are delivering to your users and their methods of delivery, you can estimate the number of XenApp servers required for your deployment. For applications virtualized on the server, the number of servers required depends on the following factors:
q

The processing requirements of the applications and the processing capacity and available RAM of your servers. To determine the processing requirements for an application, see its product documentation. The native operating system of the applications. Running 32-bit applications on 64-bit operating systems requires more RAM than running a 32-bit application on a 32-bit operating system. Whether you are streaming applications to the server or installing the applications on the server. Depending on the network topography and the application being delivered, a deployment where applications are installed on the servers can service more users than a deployment with an equal number of servers where the applications are streamed to the servers. The size of the files with which your users work and how they use them.

Using this data you can roughly estimate the number of servers to deploy in your test farm. After setting up your test farm, use Load Testing Services on the XenApp servers to simulate how your users run applications on your servers. With Load Testing Services, you can track a variety of Perfmon counters, such as Total Processor Time, Thread Queue Length, Memory Consumption, and Pages Per Second, to determine the resource limits of the servers in your environment. This will help you determine the number of servers to deploy in your production environment.

65

Deciding How Many Farms to Deploy


Most organizations deploy a single farm. However, there are some circumstances in which deploying multiple farms makes sense. The decision to implement a single farm or multiple farms is influenced by:
q

Location and needs of the users or your organization - If your organization is a service provider, you might want to dedicate a farm to each organization for which you provide service. Multiple farms might make it easier to demonstrate compliance with specific service level agreements. Geographic layout of your organization - If your IT infrastructure is organized by region and managed in a decentralized manner, multiple farms could improve farm performance. Multiple farms could also save time when coordinating farm administration and simplify troubleshooting farm-wide issues. Network infrastructure limitations - In WANs with high latency or error rates, multiple farms may perform better than a single farm with multiple zones. Organizational security policies concerning server communications - Consider multiple farms if your organization needs to segregate data based on security level. Likewise, you might need multiple farms for regulatory compliance.

There is no exact formula for determining the ideal number of farms, but general guidelines can help:
q

In general, a single farm meets the needs of most deployments. A significant benefit to deploying a single farm is needing only one data store database. Consider using multiple farms when you have geographically dispersed data centers that can support their own data store database, or when you do not want communication between servers within the farm to cross a firewall or WAN. For very large deployments with thousands of servers, breaking the environment into multiple farms can increase performance.

Citrix regularly tests farm scalability based on 1000-server farms.

Farm Element or Component Data Store Data Store Replication

Single Farm The farm has one data store. Citrix recommends that you replicate the data store to remote sites when using one farm in a WAN environment.

Multiple Farms Each farm must have a data store. If each remote site is a farm with its own data store, there is no need for data store replication.

66

Deciding How Many Farms to Deploy Load Balancing You can load balance an application across the farm. If the farm spans multiple sites, firewall ports must be open for server-to-server communication. Data store information is synchronized with member servers through notifications and queries. When a farm has multiple zones, data collectors communicate dynamic information such as logons and application use across the farm. You can monitor and configure the farm from a single management console and need to log on to only one farm to do so. You cannot load balance an application across servers in different farms. Site-based farms eliminate the need to open firewall ports for server-to-server communication. Multiple farms might improve performance over a single farm when server-to-server traffic crosses a WAN link or when the farm is very large.

Firewall Traversal Server-to-server Communication

Management Tools

You can monitor and configure multiple farms from management console. Communicating with multiple farms from the console requires logging on to each farm.

Sharing Components Between Farms


Some Citrix components can be shared between multiple farms; consequently, it is not necessary to consolidate all servers in one farm to prevent deploying these components multiple times:
q

Web Interface - Sharing Web Interface between farms provides central access to applications published on different farms. SmartAuditor - With the exception of the SmartAuditor Agent, all components are independent of the server farm. For example, you can configure multiple farms to use a single SmartAuditor Server. Citrix Licensing - You can manage multiple farms using one Citrix License Server; however, performance might be affected if you use only one license server for all servers in a WAN. EdgeSight - You can use EdgeSight and Resource Manager powered by EdgeSight to monitor multiple farms. Note that servers running Presentation Servers 4.5 agents appear as endpoints.

67

Planning Server Functions


Regardless of your farm size, Citrix recommends having at least one server dedicated to functions other than those related to running published applications. Publishing applications on a server that also hosts administrative functions slows down application enumeration. If you decide to install administrative functions on a server hosting published applications, choose a server that hosts an infrequently used and not resource-intensive application (or lower the load threshold for that server so that it accepts fewer connections). While farm size (small, medium, large) as determined by the number of servers, can indicate the general category of your farm, consider the number of user connections. Because applications can scale differently from server to server (some servers might support 100 user connections, others might support only ten), looking solely at the number of servers might be misleading. Determine how you want to group functions by designing an initial configuration, then fine tune the design after testing the pilot farm. As you add user connections in your test configuration, watch the Windows Performance Monitor counters:
q

When the peak number of users is connecting simultaneously to the farm. When the peak number of users is connected to the farm.

If the counters exceed the values listed in the table, move the administrative functions on to separate servers until the counter metric no longer exceeds the value.

Performance Monitor Counter Name CPU Memory ResolutionWorkItemQueueReadyCount WorkItemQueueReadyCount LastRecordedLicenseCheck-OutResponseTime

Criteria > 85% - 90% > 80% > 0 for extended periods of time > 0 for extended periods of time > 5000 ms (typically evaluated only in large farms)

68

Planning the XenApp Data Store


When you deploy your server farm, it must have an associated data store. When servers in a farm come online, they query the data store for configuration information. The data store provides a repository of persistent information, including:
q

Farm configuration information Published application configurations Server configurations Citrix administrator accounts Printer configurations

The System Requirements lists the databases you can use for the farm data store. For information about supported database versions, see http://support.citrix.com/article/CTX114501.

Choosing a Database
Consider these factors before deciding which database product to use:
q

The number of servers you currently plan to have in the farm, and whether or not you plan to expand that number Whether or not you have a database administrator with the expertise to configure and manage a data store running on SQL Server or Oracle Whether or not you foresee the enterprise expanding, which would result in expanding the size and maintenance of the database Any database maintenance requirements, such as backup, redundancy, and replication

General recommendations are listed below, based on the following size table.

Servers Named Users Applications


q

Small 1-50 < 150 < 100

Medium 25-100 < 3000 < 100

Large 50-100 < 5000 < 500

Enterprise 100 or more > 3000 < 2000

Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all large and enterprise environments. When deploying large farms across a WAN, you can obtain a performance advantage by replicating the data store and distributing the load over multiple database servers. SQL Server and Oracle are

69

Planning the XenApp Data Store suitable for large farms and support replication. Do not install XenApp on the SQL Server or Oracle database server.
q

SQL Server Express is suitable for all small and many medium environments located in one physical location, which do not have branch offices across a WAN.

See the database product documentation for hardware requirements for the database server. Important: Ensure that the data store is backed up regularly. If the data store database is lost, you must recreate the farm. You cannot recreate the data store from an existing farm.

70

Database Server Hardware Performance Considerations


Increasing the CPU power and speed of the database server can improve the response time of queries made to the data store when:
q

Starting the Citrix IMA Service on multiple servers simultaneously Adding a server to the farm Removing a server from the farm

The response time of other events (such as starting the IMA Service on a single server, recreating the local host cache, or replicating printer drivers to all servers in the farm) is affected more by the farm size than by the data store response time. Adding processors to the server hosting the data store can improve response time when executing multiple simultaneous queries. In environments with large numbers of servers coming online simultaneously and at frequent intervals, additional processors can service requests faster. The capabilities of the processor on the database server affect management console performance, how long it takes to add (configure) and remove a server from the farm, and how long it takes to start multiple servers simultaneously. In the following chart, five sample farm configurations (A through E) are listed, with measurements of various metrics in the farm.

Configuration Number of servers in farm Number of applications published to all servers Number of user policies Printers per server Printer drivers installed per server Network print servers with printers Number of Load Manager load evaluators Number of application folders in management console Number of server folders in management console

A 50 50 25 5 25 5 10 10 8

B 100 50 25 5 25 5 10 10 16

C 250 50 25 5 25 5 10 10 25

D 500 50 25 5 25 5 10 10 50

E 1000 50 25 5 25 5 10 10 50

71

Database Server Hardware Performance Considerations Number of Application Isolation Environments Number of Citrix administrators 10 10 10 10 10 10 10 10 10 10

Size of data store database in megabytes 32 51 76 125 211 The following table lists suggested hardware for the server hosting the data store, for each configuration in the previous table.

Configuration Dual Pentium 4/1.6GHz with 2GB RAM Dual Pentium 4/3.0GHz with 4GB RAM

A X X

B X X

C X X

D X

Quad Pentium 4/3.0GHz with 4GB RAM X X X X X The actual performance of a farms data store varies depending on the database engine and the level of performance tuning achieved.

72

Replication Considerations
When you join a new server to a XenApp farm, a significant amount of time can be spent waiting for the server's Citrix Independent Management Architecture (IMA) service to start and come online. As a result, you might choose to configure SQL data store replication at each remote site, to allow member servers to point to their local SQL subscriber and avoid the slowness of traversing the WAN. However, as your farm expands geographically, the overhead of administering SQL subscribers at each of your sites becomes a burden. In XenApp 6.5, you can configure servers in session-host mode (also known as session-only mode). This server mode allows XenApp servers to join a farm in significantly less time with substantial bandwidth savings. When a XenApp server joins a farm, it performs numerous read and write operations to the IMA data store as well as a download of the farm data to its Local Host Cache (LHC). In previous releases of XenApp, all member servers of the farm were required to download all farm data to their LHC during a join, resulting in a large amount of data store transactions and bandwidth consumption. In XenApp 6.5, you can dedicate a select few servers as XenApp controllers which are responsible for farm management tasks, while the remaining member servers are session-only servers whose sole task is to host user sessions. XenApp controllers must synchronize all of the farm data, while session-only servers must synchronize only a subset of the information to their LHC. These changes result in fewer database transactions, less bandwidth consumption, and faster IMA startup performance. While session-only XenApp servers can host XenApp user sessions, they cannot perform the role of data collectors, nor can they participate in or trigger a data collector zone election. The XML service does not run on session-only XenApp servers; therefore, the Web Interface cannot use them to perform application enumerations. Additionally, management tasks such as AppCenter discovery or PowerShell tasks cannot be run directly on a session-only server. However, with proper planning and placement of XenApp controller servers, leveraging the session-only model can optimize your farm performance and reduce IMA bandwidth and server provisioning time. You specify the XenApp server mode through the Server Role Manager when you configure the XenApp role to join a farm. For more information, see the XenApp Server Mode section in Before Configuring XenApp. If you used data store replication in previous XenApp deployments, note that in XenApp 6.5:
q

Replication is no longer required because IMA architectural changes have significantly improved WAN performance. Future versions of Microsoft SQL Server may not support the replication model that XenApp supports (transactional replication with immediate updating subscribers).

Therefore, although you can replicate a XenApp 6.5 data store on SQL Server 2008 R2 and earlier versions, you do not need to, and you may not be able to with later SQL Server versions.

73

Planning for Configuration Logging and IMA Encryption


The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive data in the IMA data store. Enabling IMA encryption provides an additional layer of security for the data preserved by the Configuration Logging feature. If you do not enable IMA encryption, XenApp uses the standard encryption used in previous versions of XenApp. The Securing Server Farms documentation contains more information about IMA encryption, Configuration Logging, and when to enable these features. To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the key, use CTXKEYTOOL, which is available on the installation media. For custom installations or provisioning servers in large environments, consider:
q

Deploying XenApp by using images, and including the key file as part of the server image Generating a key, putting the key in a folder on your network, using a UNC path to specify the location, and performing an unattended installation

If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.

74

Planning for Data Collectors


When planning for data collectors, consider:
q

If you need a dedicated data collector If you do not need a dedicated data collector, which infrastructure services can share the same server If you need a zone in each geographic region, which means that you need data collectors for those regions as well

To maintain consistent information between zones, data collectors relay information to all other data collectors in a farm, creating network traffic. In general, data collector memory consumption increases as farm size increases. However, it is not significant. For example, the Independent Management Architecture service running on the data collector typically uses 300MB on a 1000 server farm. Likewise, CPU usage is not significant. A data collector hosted on a dual-processor server can support over 1000 servers in its zone. In general, CPU usage increases as the number of servers in a zone increases, the number of zones increases, and the number of users launching applications increases. On most networks, Citrix recommends reducing the number of data collectors and zones. For example, if you have a farm with 100 servers in one location, Citrix recommends having one zone with a dedicated data collector (although you can have backup data collectors). Citrix recommends installing XenApp on the server you want to host the data collector functionality and, after installing other member servers, configuring a server as the backup data collector.

75

Designing Zones for a XenApp Deployment


A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All servers must belong to a zone. Unless otherwise specified during XenApp Setup, all servers in the farm belong to the same zone, which is named Default Zone. Zones have two purposes:
q

Collect data from member servers in a hierarchical structure Efficiently distribute changes to all servers in the farm

Each zone contains a server designated as its data collector. Data collectors store information about the zones servers and published applications. In farms with more than one zone, data collectors also act as communication gateways between zones. This illustration depicts a server farm with multiple zones. Each zones data collector communicates with the other data collectors across the WAN link.

Because session and load information within a XenApp farm can become large in enterprise deploymentsup to several megabytesto ensure a scalable and resilient XenApp farm, it is imperative that you design zones based on your network topology. XenApp member servers replicate their dynamic data to the ZDC designated for their zone. XenApp uses a star topology for replication among zoneseach ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.

76

Designing Zones for a XenApp Deployment When designing zones, the most important variables to consider are latency and bandwidth. The amount of bandwidth and the impacts of latency are highly dependent on your XenApp deployment. The lower the bandwidth and the higher the latency, the longer a farm takes to resynchronize the dynamic data among zones after an election. In farms distributed across WANs, zones enhance performance by grouping geographically related servers together. Citrix does not recommend having more than one zone in a farm unless it has servers in geographically distributed sites. Zones are not necessary to divide large numbers of servers. There are 1000-server farms that have only one zone. Data collectors generate a lot of network traffic because they communicate with each other constantly:

Each zone data collector has an open connection to all data collectors in the farm. During a zone update, member servers update the data collector with any requests and changed data. Data collectors relay changes to the other data collectors. Consequently, data collectors have the session information for all zones.

In general, Citrix recommends using the fewest number of zones possible, with one being optimal. If all farm servers are in one location, configuring only one zone for the farm does not reduce performance or make the farm harder to manage. However, in large networks, such as organizations with data centers on different continents, grouping geographically-related servers in zones can improve farm performance. Keep in mind that data collectors must replicate changes to all other data collectors in the farm. Also, bandwidth consumption and network traffic increase with the number of zones. Separate zones are not required for remote sites, even ones on separate continents; latency is the biggest factor in determining if servers should be put in their own zone. For large farms with servers in different geographic regions, create zones based on the location of significant numbers of servers. Also decide if you want to configure failover zones or preferred zones. If a zone fails, you can configure for user connections to be redirected to another zone (failover) or control to which zones specific users connect (preference). Failover requirements might determine the number of zones required. For example, an organization with 20 farm servers in London, 50 servers in New York, and three servers in Sydney could create two or three zones. If the Sydney location has good connectivity to either New York or London, Citrix recommends grouping Sydney with the larger location. Conversely, if the WAN connection between Sydney and the other locations is poor or zone preference and failover is required, Citrix recommends configuring three zones. Consider these zone design guidelines:
q

Minimize the number of zones in your farm. Create zones for major datacenters in different geographic regions. If a site has a small number of servers, group that site in a larger sites zone.

77

Designing Zones for a XenApp Deployment


q

If your organization has branch offices with low bandwidth or unreliable connectivity, do not place those branch offices in their own zone. Instead, group them with other sites with which they have the best connectivity. When combined with other zones, this might form a hub-and-spoke zone configuration. If you have more than five sites, group the smaller sites with the larger zones. Citrix does not recommend exceeding five zones.

78

Planning for Application Access


Planning for Receiver Storefront
See the planning information in the Receiver Storefront documentation.

Planning for the Web Interface and XML Broker


The Web Interface and the XML Broker are complementary services. The Web Interface provides users with access to applications. The XML Broker determines which applications appear in the Web Interface, based on the users permissions. When determining whether or not to dedicate servers to the Web Interface and the XML Broker, consider scalability and security. In small to medium farms, you can:
q

Run XenApp and the Web Interface on the same server, depending on your security considerations. Group the XML Broker with other infrastructure services, such as the data collector or the data store, in very small farms (one to five servers). Citrix recommends grouping the XML Broker with the data collector.

In larger farms, Citrix recommends:


q

Configuring the XML Broker on data collectors or dedicated servers. In deployments with dedicated servers for infrastructure functions, dedicate a server to the XML Broker to accommodate authentication traffic. Running the Web Interface on dedicated Web servers.

Do not publish applications on the server functioning as the XML Broker. Important: If you change the port used by the Citrix XML Service on the XML Broker, set the correct port in the Receiver. When users access the Web Interface from the Internet, Citrix recommends locating the Web Interface server on the internal network and the Citrix XML Broker with the XenApp farm. Shielding the XML Broker from the external Internet protects the XML Broker and the farm from Internet security threats. If you must place the Web Interface in the DMZ and want to secure the connection between the XML Broker and the Web Interface, put the Web Interface server in the DMZ with Secure Gateway or Access Gateway. This configuration requires putting the Web Interface on a separate Web server. Install a certificate on the Web Interface server and configure SSL Relay on the servers hosting the Citrix XML Broker.

79

Planning for Application Access In very small farms, configuring the Web Interface and the XML Broker on the same server eliminates having to secure the link from the Web Interface to the farm. This deployment is used primarily in environments that do not have users connecting remotely. However, this might not be possible if your organization does not want Web servers such as Internet Information Services (IIS) in the farm.

80

Planning for Accounts and Trust Relationships


Consider how users will access resources. When multiple servers host the same published application, users could be connected to any of these servers when they access the resource. Therefore, if a user does not have permissions for all servers, the user might not be able to access the resource. To avoid these issues, you might need to establish domain trust relationships between users or servers. Also, in a farm with multiple, untrusted domains, when servers are load balanced, users can be routed to a server in a domain in which they do not have access permissions. To ensure your users are routed only to servers in domains in which they have access permissions:
q

Publish copies of an application in each domain, and allow users access only to the copy of the application in the domain in which they have access permissions. Create a Worker Group Preference and Failover policy that routes users to servers in domains in which the users have access permissions.

System Account Considerations


Consider the following when deciding how to configure your Citrix administrator accounts:
q

One full authority administrator account must always exist for the server farm. Citrix XenApp prevents you from deleting the last full authority administrator account. However, if no administrator accounts exist in the farm data store database, a local administrator account can log on to the AppCenter to set up Citrix administrator accounts. To create effective Citrix administrator accounts, ensure that all users you are going to add as Citrix administrators are Domain Users for the domain in which your farm resides. Users who are Citrix administrators who take server snapshots must also be authorized Windows Management Instrumentation (WMI) users on each server for which they are taking snapshots.

Including Servers from Other Domains


XenApp supports trust-based routing; servers in domains that do not trust each other can be members of the same farm. When a server needs to perform one of the following operations on an untrusted domain, the server determines from the data store which servers can perform the operation and routes the request to the most accessible server:

81

Planning for Accounts and Trust Relationships


q

Authenticating a Citrix administrator Refreshing the display or launching an application in Web Interface Enumerating users and groups Resolving users or groups when adding users to published application, printer auto-creation lists, or defining new Citrix administrators

Requests to enumerate applications are routed to a server that has the required domain trust relationship if the originating server does not.

Substituting Domain Accounts for User Accounts


By default, XenApp creates local accounts to run the following XenApp services: XenApp Service CPU Utilization Mgmt/CPU Rebalancer Default Local User Account ctx_cpuuser

Configuration Manager for the Web Interface Ctx_ConfigMgr Service Citrix strongly recommends that if you want to change local accounts to domain accounts, you do so before installing XenApp. Changing service accounts after installation is not supported. Install XenApp as a domain administrator to ensure the accounts are created correctly. If you are changing the accounts for services and your farm has servers in multiple domains, the domains must have trust relationships with each other.

82

Recommendations for Active Directory Environments


Citrix recommends the following configuration for server farms with Active Directory:
q

XenApp servers are in their own Organizational Units (OUs). Create OUs for application silos, keeping servers from different silos organized in their own OUs. (You can, however, create application silos that span multiple OUs.) All servers reside in the same domain. The server farm domain has no trust relationships with non-Active Directory domains, as this can affect operations requiring trusted domains. The server farm is in a single Active Directory forest. If your farm has servers in more than one forest, users cannot log on by entering user principal names (UPNs). UPN logons use the format username@UPN identifier. With Active Directory, UPN logons do not require a domain to be specified, because Active Directory can locate full UPN logons in the directory. However, if the server farm has multiple forests, problems occur if the same UPN identifier exists in two domains in separate forests. Important: Citrix XenApp does not support UPN logons if a server farm spans multiple Active Directory forests.

Active Directory User Permission


Active Directory security groups can affect authenticating to published applications or the management console. The tables that follow contain best practice guidance. Also, if a user is a member of a domain local group, the group is in the users security token only when the user logs onto a computer in the same domain as the domain local group. Trust-based routing does not guarantee that a users logon request is sent to a server in the same domain as the domain local group. Network configurations do not affect authentication to the management console because that console allows only pass-through authentication.

Domain Global Groups Authenticating to published applications Authenticating to management console

No adverse effects No adverse effects

83

Recommendations for Active Directory Environments Domain Local Groups Authenticating to published applications Recommendation: All servers that load balance an application must be in the same domain if a domain local group is authorized to use the application. Rationale: Domain local groups assigned to an application must be from the common primary domain of all the load balancing servers. When you publish applications, domain local groups appear in the accounts list if the condition above is met and accounts from the common primary domain are displayed. If a published application has users from any domain local groups and you add a server from a different domain, domain local groups are removed from the configured users list, because all servers must be able to validate any user with permission to run the application. Authenticating to management console Recommendation: If a user is a Citrix administrator only by membership in a domain local group, the user must connect the console to a server in the same domain as the domain local group. Rationale: If the user connects the console to a server in a different domain than the domain local group, the user is denied access to the console because the domain local group is not in the users security token. Universal Groups Authenticating to published applications Recommendation: If universal groups are assigned permission to the application, all servers that manage the application must be in an Active Directory domain. Rationale: A server in a non-Active Directory domain could authenticate the user to run the application. In this case, universal groups are not in the users security token, so the user is denied access to the application. It is possible for a server in a non-Active Directory domain to load balance an application with servers in an Active Directory domain if the domains have an explicit trust relationship. Authenticating to management console Recommendation: If a user is authenticating to the console and is a Citrix administrator only by membership in a universal group, the console must connect to a server that belongs to an Active Directory domain in the universal groups forest. Rationale: Non-Active Directory domain controllers and domains outside a universal groups forest have no information about the universal group.

84

Recommendations for Active Directory Environments

Active Directory Federated Services


XenApp supports Active Directory Federated Services (AD FS) when used with the Citrix Web Interface. If you need to provide a business partner with access to published applications, AD FS might be a better alternative than creating multiple new user accounts on the enterprise domain. If you plan to use AD FS with XenApp, Citrix recommends:
q

When installing XenApp on each server in your farm, ensure the port sharing with IIS option and ensure that IIS is configured to support HTTPS; see System Requirements for more information. Set up a trust relationship between the server running the Web Interface and any other servers in the farm communicating with the Web Interface through the Citrix XML Broker. The Web Interface must be able to access the certificate revocation list (CRL) for the Certificate Authority used by the federation servers. If you are provisioning the farm by imaging, configure trust requests on the server before you take the image. These trust requests must be enabled on each server in the farm and cannot be set at a farm level. To prevent external users from having unauthorized access to services on farm servers, configure all XenApp servers for constrained delegation. To provide users with access to resources on those servers, add the relevant services to the Services list using the MMC Active Directory Users and Computers snap-in.

For more information about configuring support for AD FS, see the Web Interface documentation.

85

Planning for System Monitoring and Maintenance


When designing your XenApp farm, include a monitoring and management strategy to ensure the sustainability of your environment. Consider incorporating one or more monitoring tools into your environment and customizing them to provide alerts based on metrics associated with hardware, software, and usage requirements. Designing for monitoring and management should include hardware, software, performance, and network areas. For hardware monitoring, Citrix recommends the hardware management tools provided by most server vendors. Citrix EdgeSight is an excellent technology for monitoring XenApp farms. Citrix suggests customizing the default Resource Manager and EdgeSight metrics to meet your specific monitoring needs.

86

Planning for UAC


Consider the following suggestions if you will be installing XenApp on a system with User Account control (UAC) enabled.
q

Instruct the Windows server to elevate the UAC level automatically, without prompting, by configuring a Local Security Policy setting. Instruct Windows to elevate the UAC level without prompting, through an Active Directory Default Domain Policy. This avoids having to enable this setting on each server before installation, provided you join the domain before installing XenApp. When a computer joins the domain, the domain policy is applied automatically. Enable the Print Services role so you can manage printer drivers and print queues on clients.

The following XenApp management features and tools require users be domain administrators, delegated administrators, or part of the Administrators group on the local computer:
q

AppCenter XenApp Commands SSL Relay tool Speedscreen Latency Reduction Manager

These permissions are in addition to any requirements for the feature, such as having a Citrix administrator account. To allow multiuser access to an application, install the application as a built-in administrator or enable the Create Users setting when prompted by UAC.

87

Planning for Shadowing


Session shadowing monitors and interacts with user sessions. When you shadow a user session, you can view everything that appears on the users session display. You can also use your keyboard and mouse to remotely interact with the user session. Shadowing can be a useful tool for user collaboration, training, troubleshooting, and monitoring by supervisors, help desk personnel, and teachers. Shadowing is protocol-specific. This means you can shadow ICA sessions over ICA and Remote Desktop Protocol (RDP) sessions over RDP only. Shadowing is a server-level setting. Important: By default, shadowing is enabled. Shadowing restrictions are permanent. If you disable shadowing, or change shadowing features when configuring XenApp, you cannot change those settings later. You must reinstall and reconfigure XenApp on the server to change shadowing restrictions. Any user policies you create to enable user-to-user shadowing are subject to the restrictions you place on shadowing during XenApp configuration. Citrix does not recommend disabling shadowing as a substitute for user and group connection policies.

88

Securing Delivery and Access


XenApp allows secure access to resources by users. It also enables administrators to control and monitor access to each resource and component. See the Securing Server Farms documentation for details. Complementary XenApp technologies help provide end-to-end security, including Citrix Single Sign-on, Citrix Access Gateway, and Secure Gateway. If you use one of these technologies to control remote access to the farm, set your firewall ports to communicate with the technology and the server farm. If users will connect to your farm over the Internet, consider:
q

Increasing security through two-factor authentication (adding a second authentication method such as RSA tokens). Limiting automatic printer driver installation on servers (enabled by default) if users are connecting from devices with locally attached printers. Employing a SmartAccess strategy (for example, using the Access Gateway and configuring policies that limit access according to conditions on the users client device or location). Determining how you will deploy Citrix Receiver to users, especially if they connect from airport kiosks or other public locations. Securing connections to published applications with SSL/TLS. If Receiver communicates with your farm across the Internet, Citrix recommends enabling SSL/TLS encryption when you publish a resource. If you want to use SSL/TLS encryption, use either the SSL Relay feature (for farms with fewer than five servers) or the Secure Gateway to relay ICA traffic to the XenApp server. You can also use SSL Relay to secure Citrix XML Broker traffic.

Important: XenApp installation and configuration opens Windows firewall ports to allow incoming connections, such as those from ICA traffic, Citrix Independent Management Architecture service, the Citrix XML Service, and SQL Server Express (if that database is specified during XenApp configuration).

89

Planning for Supported Languages and Windows MUI Support


XenApp 6 supports all languages of Windows Server (both native and Language Packs), providing six XenApp user interface languages. The XenApp user interface language is selected based on the language locale set in the Windows Server operating system when XenApp is installed. The following table indicates which XenApp user interface language is installed for each Windows System Language locale setting.

Windows Server 2008 R2 Language Locale English and languages other than those listed in this table French German Japanese Simplified Chinese

XenApp User Interface Language English French German Japanese Simplified Chinese

Spanish Spanish Before installing XenApp, install the target Windows Language Pack on the Windows Server, and change the language options (such as system locale and display language) to the target language. For information about installing the Language Pack and changing language options, see the Microsoft documentation. (Changing the Windows system locale after installing and configuring the XenApp server role may cause data store issues.)

90

Planning for Passthrough Client Authentication


Citrix recommends enabling passthrough client authentication. When the user connects to applications published on different servers, passthrough client authentication enables XenApp to automatically pass user credentials from the initial server to the server hosting the next application. This prevents the user from having to re-authenticate when opening applications on different servers. In this illustration, XenApp passes the user credentials from the server hosting Microsoft Outlook to the server hosting Microsoft Excel when the user opens the Microsoft Excel attachment from an email message hosted on a different server

(The passthrough authentication functionality described in this topic is not the same functionality provided by Citrix Single Sign-on or password management applications in general.) Enabling passthrough authentication requires configuring components on all XenApp application servers and enabling passthrough authentication in the Citrix Receiver installed on end-user client devices. If the passthrough authentication feature is not enabled before deploying the Receiver to end users, users must reinstall the Receiver with this feature enabled before passthrough authentication will work. To configure passthrough authentication functionality on the server, install a Citrix Receiver on each XenApp server. If you are deploying the Receiver as the client for users, install the Receiver on your server as the passthrough client.

91

Installing and Configuring XenApp


XenApp installation and configuration are separate tasks. This task division provides flexibility when using provisioning tools and disk imaging.
q

For a wizard-based XenApp installation or configuration, use the XenApp Server Role Manager. From the command line, use the XenAppSetupConsole.exe command to install the XenApp server role and the XenAppConfigConsole.exe command to configure the XenApp server role.

XenApp uses roles for XenApp features and related technologies. The wizard-based XenApp Server Role Manager uses the Server Role Installer to help you add certain XenApp roles. It detects the deployment phase for each role and displays the next task required to complete the installation and configuration of that role. From the XenApp Server Role Manager, you can:
q

Install role prerequisites Install fully-integrated server roles (such as XenApp, Citrix licensing, Single sign-on service, and Provisioning Server) Launch installers for partially-integrated roles (such as Power and Capacity Management Administration, SmartAuditor Server, EdgeSight Server) Launch the Citrix License Configuration Tool to configure the XenApp role license parameters (mode, server, and port) Launch the XenApp Server Configuration Tool to configure the XenApp server role Launch configuration tools for other roles Initiate a XenApp server restart (reboot) Remove a server from a farm Prepare a server for imaging and provisioning Remove fully-integrated XenApp 6.5 roles and components Upgrade roles (other than the XenApp server role) in XenApp 6 deployments

For command-line installation or configuration, enter the command with valid options and properties at a Windows Server command prompt.

92

Install and Configure

Accessing the Server Role Manager


The XenApp Server Role Manager runs initially from the XenApp installation media. After you install a role, the Server Role Manager is installed locally and runs every time you log on to the XenApp server (you can disable this feature by selecting a checkbox on the main Server Role Manager page). You can also run the Server Role Manager from Start > All Programs > Administrative Tools > Citrix > XenApp Server Role Manager, or from its Program Files location (Program Files (x86)\Citrix\XenApp\ServerRoleManager\XenAppServerRoleManager). If a Server Role Manager is installed locally and you invoke a different one from the XenApp installation media, the version on the installation media is used.

Using the XenApp Media to Install and Upgrade


Citrix recommends using the XenApp 6.5 media to perform a clean install of the XenApp server role on a Windows Server 2008 R2 or Windows Server 2008 R2 SP1 server. Clean install means that there is no previous version of the XenApp server role installed on the server. If you have an earlier XenApp version installed (including an early release or Technical Preview version), reimage the server before installing the XenApp 6.5 server role. If you cannot coordinate that recommended process, Citrix provides a XenApp 6.0 to 6.5 Upgrade Utility that you can customize for your servers; see CTX130614. After you install and configure XenApp 6.5, you can migrate settings from a server running a XenApp 5 or XenApp 6.0 to the new XenApp 6.5 farm. For details, see XenApp Migration Center. You can also remove a XenApp server role that was installed using the XenApp 6.5 media; however, you cannot use this functionality to remove an earlier version of the XenApp server role. If you run the Server Role Manager from the XenApp 6.5 media on a XenApp 6.0 server, new software may be available for installed roles and components other than the XenApp server role. In these cases, the Server Role Manager will display Upgrade next to the role or component; clicking that link starts the upgrade process. Important: Do not attempt to upgrade components and features in a XenApp 6.0 deployment using MSIs from the XenApp 6.5 media, unless explicitly instructed to do so.

93

Preparing to Install and Configure XenApp


Review Known Issues for late-breaking information. You must be in the Administrators group to install and configure the XenApp software. (Elevating your privilege to local administrator through User Account Control is not a substitute for Administrators group membership.) Important:
q

Do not install XenApp on a domain controller. Citrix does not support installing XenApp on a domain controller. Do not join servers running this version of XenApp to a deployment with servers running previous versions of XenApp. You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix does not support using a console from a previous XenApp release.

To ensure availability of the features and functionality of XenApp to your users, install the most recent version of receivers, plug-ins, and agents you use. When installing roles or role components other than XenApp server, see the role documentation for details about information you must provide during installation and configuration. For items to consider and tasks to complete before installing or configuring XenApp, see:
q

Before Installing XenApp Before Configuring XenApp

94

Preparing to Install and Configure XenApp


Review Known Issues for late-breaking information. You must be in the Administrators group to install and configure the XenApp software. (Elevating your privilege to local administrator through User Account Control is not a substitute for Administrators group membership.) Important:
q

Do not install XenApp on a domain controller. Citrix does not support installing XenApp on a domain controller. Do not join servers running this version of XenApp to a deployment with servers running previous versions of XenApp. You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix does not support using a console from a previous XenApp release.

To ensure availability of the features and functionality of XenApp to your users, install the most recent version of receivers, plug-ins, and agents you use. When installing roles or role components other than XenApp server, see the role documentation for details about information you must provide during installation and configuration. For items to consider and tasks to complete before installing or configuring XenApp, see:
q

Before Installing XenApp Before Configuring XenApp

95

Before Installing XenApp


q

Review the installation topics (wizard-based or command-line) to learn what information you must provide. Review the XenApp System Requirements and the system requirements for other roles you plan to install.
q

In most cases, wizard-based XenApp installations include automatic installation of prerequisite software and required Windows roles.

For command-line XenApp installations, you must install the prerequisite software and Windows roles before installing XenApp. You can deploy prerequisites with PowerShell cmdlets, the Microsoft ServerManagerCmd.exe command, or the Microsoft Deployment Image Servicing and Management (DISM) tool. Deploying prerequisites may require a server restart before you can install the XenApp server role.
q q

Ensure there is no other instance of the XenApp server role installed on the server. Ensure the server has the latest Microsoft hotfixes and that the operating system clock has the correct time. Prepare for Windows Multilingual User Interface (MUI) support, if needed. Before installing XenApp, install the target Windows Language Pack on the server, and change language options (such as system locale and display language) to the target language. For more information, see the Microsoft documentation. (Changing the Windows system locale after installing and configuring the XenApp server role may cause data store issues.)

Citrix XML and IIS Integration


When you install the XenApp role, XML and IIS integration is an optional component.
q

When this component is installed, the Citrix XML Service and IIS share a port (default = 80). You cannot change the Citrix XML port during XenApp configuration. When this component is not installed, the Citrix XML Service defaults to standalone mode with its own port settings, which you can change during XenApp configuration. You must configure a nondefault port only if you do not integrate with IIS and if IIS (or any other software) is using port 80.

The Server Role Installer checks if certain IIS role services are installed on the server, as well as options you specify.
q

In a wizard-based installation, installing the integration XML and IIS integration component is controlled through a checkbox.

96

Before Installing XenApp


q

In a command-line installation, installing the component is controlled through the /install:XA_IISIntegration and /exclude:XA_IISIntegration options, and their smart defaults. Citrix recommends you use these options to help prevent potential confusion in the future when the presence of IIS role services on the server or image may be unknown.

The following table describes the possible combinations, results, and defaults. For a list of IIS role services, see XenApp System Requirements. IIS role services installed? Yes Wizard-based install Command-line install

Select the XML IIS Integration component checkbox (default). The component is installed. Clear the XML IIS Integration component checkbox. The component is not installed. -

Specify the /install:XA_IISIntegration option. The component is installed. This is the recommended configuration. Do not specify the /install:XA_IISIntegration option. The component is installed (default). Specify the /exclude:XA_IISIntegration option. The component is not installed. Do not specify the /install:XA_IISIntegration option. The component is not installed.

Yes

Yes

No

Do not select the XML IIS Integration component checkbox (default). The component is not installed

Select the XML IIS Integration Specify the /install:XA_IISIntegration component checkbox. The option. The Server Role Installer Server Role Installer installs the installs the IIS role services and the IIS role services and the component. component. When the XML and IIS integration component is installed and the XML Service Policy is disabled, XenApp uses the installed integration component defaults. If the XML Service policy is enabled and contains a different port number setting, unexpected results may occur.

No

97

Before Configuring XenApp


q

Review the configuration topics (wizard-based or command-line) to learn what information you must provide. During configuration, you specify the database to be used for the XenApp farm data store: Microsoft SQL Server Express, Microsoft SQL Server, or Oracle. See CTX114501 for supported versions. Additional information is available at Data Store Database Reference.
q

If you use a Microsoft SQL Server Express database, XenApp configuration installs it automatically.

If you use a Microsoft SQL Server or Oracle database, install and configure the database before configuring XenApp. For an Oracle database, ensure that you also install an Oracle client on the XenApp server and restart the server. If you use a Microsoft SQL Server or Oracle database for the farm data store, and use command-line XenApp configuration, create a Data Source Name (DSN) file before configuring XenApp. (A wizard-based configuration creates the DSN file for you.) Each server in the farm must have the DSN file. You can create the file and copy it to other servers, or put it on a network share, provided you remove the value for any workstation-specific information (such as the Oracle WSID). Use the /DsnFile:dsn_file option to specify the file location on the XenApp configuration command line.
q

If you are using a custom DSN file, the file must have write permission for the Network Service.
q

If you plan to use the Configuration Logging feature and encrypt the data being logged, you must load the encryption key on servers that join the farm after configuring XenApp but before restarting the server.

XenApp Server Mode


All XenApp servers can host sessions. The XenApp server mode specifies whether the server can only host sessions (session-host only mode, also called session-only) or if it can also perform the controller functions of being elected a data collector and hosting the XML broker (controller and session-host mode, also called controller). While configuring servers as session-only can improve performance (particularly in large farms with multiple zones), ensure you have sufficient servers configured in controller mode that can serve as backup data collectors for your zones.
q

A XenApp server configured in controller mode monitors other controller servers in the XenApp farm and triggers data collector elections when necessary. The Citrix XML Service must run on a server configured in controller mode. Application enumeration and resolution are invoked only on servers configured in controller mode.

98

Before Configuring XenApp


q

The AppCenter can discover and connect only to servers configured in controller mode. Every zone and every farm must have at least one server configured in controller mode. If you plan to migrate an earlier XenApp version to XenApp 6.5, the migration operation must be run on a XenApp 6.5 server configured in controller mode.

When you create a XenApp farm, the XenApp Server Configuration Tool automatically configures the server in controller mode; you cannot configure session-only on the first server in a XenApp farm. This ensures that the XenApp farm has at least one data collector. When you configure another server to join that farm, you can choose the mode. By default, a server joins the farm in controller mode. (In earlier XenApp versions, server mode was not configurable; all XenApp servers operated in controller mode.) The following table shows how to specify the server mode during XenApp configuration. Server can host sessions, and be a data collector and XML broker (default) Select Enable Controller and Session-host modes Server can host sessions, but cannot be a data collector or XML broker Select Enable Session-host mode only

Wizard-based configuration

Command-line Specify Specify configuration /ImaWorkerMode:False /ImaWorkerMode:True To change the configured server mode, you must leave and then rejoin the XenApp farm, specifying the desired mode.

99

Installing XenApp Using the Wizard-Based Server Role Manager


To install XenApp using the wizard-based Server Role Manager: 1. On the installation media, double-click autorun.exe. The Autorun menu launches. 2. Select Install XenApp Server. The Server Role Manager launches and checks if any roles are already installed. 3. Select Add server roles. If you already installed roles other than XenApp, select Add or remove server roles, then select Add server roles. 4. Select your XenApp edition. 5. Accept the End User License Agreement. 6. Select the roles you want to add. (The Server Role Manager displays only the roles supported in the XenApp edition you selected. Some roles may require current Citrix Subscription Advantage membership.) 7. Select role components. Roles may have default and optional components.
q

When you select a role, its default components are selected automatically. The XenApp role has the following default components:
q

XenApp Management, which includes the Citrix AppCenter.

Windows Desktop Experience Integration, which configures a XenApp server to deliver remote desktops containing Windows 7 features and Microsoft applications. For more information, see Delivering XenApp to Software Services Subscribers. If you do not want to install a default component, clear its checkbox.
q q

For information about the XML Service IIS Integration optional component, see Citrix XML and IIS Integration. If IIS role services are installed on the server, this optional component is selected by default. If you plan to use role agents/plug-ins on this server (EdgeSight Agent, SmartAuditor Agent, Single Sign-on Plug-in, Power and Capacity Management Agent, or Provisioning Services Target Device), install them at the same time you install the XenApp server role. Otherwise, install these components from the packages on the XenApp media. The Citrix Receiver for Windows (formerly the online plug-in) and the Citrix Offline Plug-in are installed automatically when you install the XenApp role. These items do not appear in the components lists, and you cannot disable these installations.

100

Installing XenApp Using the Wizard-Based Server Role Manager 8. Review the prerequisites summary, which indicates which role or component needs the prerequisite, and whether the Server Role Installer installs it or you must install it. For software you must install, the display indicates whether the XenApp installation media contains the software or you must obtain it elsewhere. 9. Review the summary, which lists the selected roles and components to be installed or prepared. It also lists prerequisites which will be automatically deployed for all selected roles. After you click Install, a display indicates installation progress and the result. Important: When installing the XenApp role, the IMA Service is not started, nor are any configuration options set, such as creating or joining a farm and data store database information. After the installation result displays and you click Finish, the Server Role Manager task list displays. For each role you selected, the task list indicates the next task necessary for installation or configuration.
q

If you have not configured the license parameters for the XenApp role, click Specify Licensing, which launches the Licensing Configuration Tool. Run the Licensing Configuration Tool before configuring the XenApp server role. For installed fully integrated roles that require configuration, click Configure to launch the configuration tool for that role. For partially integrated roles, click Install to launch the installer for that role. See the role documentation for details.

101

Installing XenApp from the Command Line


Command Syntax
On the server where you want to install XenApp or other roles, from the "XenApp Server Setup\bin\" directory on the XenApp media, type the following at a command prompt: XenAppSetupConsole.exe options_properties The following table describes installation command options. Installation options and properties /help Displays command help. /logfile:path Path for the log file generated during the installation. Default = c:\Windows\Temp

102

Installing XenApp from the Command Line /install:items Comma-delimited list of roles, components, features, or technologies to install. Valid values are:
q

EdgeSightServer. EdgeSight Server. Licensing. Citrix Licensing Server. PCMAdmin. Power and Capacity Management administration components. Provisioning. Provisioning Services. SecureGateway. Secure Gateway. SmartAuditorServer. SmartAuditor server. SsonService. Single sign-on service. ReceiverStorefront. Receiver Storefront. WebInterface. Web Interface. XenApp. XenApp server. If you specify XenApp, the Server Role Manager automatically installs the Citrix AppCenter, Citrix Receiver for Windows (formerly online plug-in), Citrix Offline Plug-in, and Windows Desktop Experience Integration feature (for more information, see Delivering XenApp to Software Services Subscribers). You can also specify one or more of the following optional components to install, separated by commas. Except as noted, if you do not specify the following optional components, they are not installed.
q

XA_IISIntegration. IIS and XML Service integration. For more information, see Citrix XML and IIS Integration. If IIS role services are installed on the server, this component is installed regardless of whether you specify it on the command line, unless you use the /exclude option to exclude it. EdgeSightAgentFeature. EdgeSight Agent. SmartAuditorAgentFeature. SmartAuditor Agent. SSONAgentFeature. Single Sign-on Plug-in. PCMAgentFeature. Power and Capacity Management Agent. PVDeviceFeature. Provisioning Services Target Device.

103

Installing XenApp from the Command Line /exclude:items (Valid only when installing the XenApp server role) Comma-separated list of components to be omitted from the installation. Valid values are:
q

XA_Console. Excludes installation of the AppCenter. XA_IISIntegration. Excludes installation of the XML IIS Integration component. For more information, see Citrix XML and IIS Integration.

XenAppEnhancedDesktopExperience. Excludes installation of the Windows Desktop Experience Integration feature. You cannot exclude the installation of the Receiver for Windows or the Offline Plug-in.
q

/edition Specifies the XenApp edition. Valid values are:


q

Platinum (default) Enterprise Advanced

INSTALLDIR=directory Specifies where to install the items. Default: C:\Program Files\Citrix ONLINE_PLUGIN_INSTALLDIR=directory Specifies where to install the Citrix Receiver for Windows. Default: C:\Program Files\Citrix\ICA Client

Examples
The following command installs the XenApp server Platinum Edition in its default location. XenAppSetupConsole.exe /install:XenApp /Platinum The following command installs the XenApp server Platinum edition and the Receiver Storefront in C:\Program Files\Citrix (which is the default location). XenAppSetupConsole.exe /install:XenApp,ReceiverStorefront INSTALLDIR=C:\Program Files\Citrix The following command installs the XenApp server Platinum Edition and the Single Sign-on Plug-in, and excludes installation of the AppCenter. XenAppSetupConsole.exe /install:XenApp,SSONAgentFeature /exclude:XA_Console

104

Configuring XenApp Server Role License Information


XenApp server role license information must be specified before a XenApp server can accept connections.
q

From the Server Role Manager, use the wizard-based Licensing Configuration Tool after installing the XenApp server role. From the command line, include license server information in the XenApp server role configuration command (XenAppConfigConsole.exe).

See Licensing Your Product for complete Citrix licensing information.

Configuring XenApp License Information using the Wizard-based Licensing Configuration Tool
If you are using the Server Role Manager, launch the Licensing Configuration Tool before configuring the XenApp role. 1. After installing the XenApp role, access the XenApp Server Role Manager. 2. Click Specify licensing. The Licensing Configuration Tool launches. 3. On the Enter License Server Information page, select one of the following:
q

Connect to existing license server. Specify the case-sensitive license server name. If you do not change the license server port value, the default value 27000 is used. Click Test Connection to verify that the specified license server is running and using a compatible software version, and to check if the license server has any licenses.

q Configure later via a policy. 4. On the Select Licensing Model page, you can select a licensing model option or defer the selection to a later time.

If you clicked Test Connection on the previous page, recommendations are noted on the Select Licensing Model page, based on licenses found on the license server. Important: Select the licensing model best suited to your planned deployment, which may differ from the recommendation, which is based on the licenses currently on the license server.
q

XenApp. Select this model if you plan to use only XenApp licenses. This option is recommended if the Test Connection operation discovered no licenses, only XenApp licenses, or a mixture of unique XenApp and XenDesktop licenses on the license

105

Configuring XenApp Server Role License Information server.


q

XenDesktop concurrent system. Select this model if you plan to use XenDesktop concurrent user licenses. This option is recommended if the Test Connection operation discovered only XenDesktop concurrent licenses on the license server. XenDesktop user/device. Select this model if you plan to use XenDesktop user or device licenses. This option is recommended if the Test Connection operation discovered XenDesktop user/device licenses or both XenDesktop user/device and XenDesktop concurrent licenses.

To change license server and licensing model information later, click Edit Licensing in the XenApp Server Role Manager.

Configuring XenApp License Information from the Command Line


From the command line, you can configure XenApp license information when you configure the XenApp server role with the XenAppConfigConsole.exe command. Use the /LicenseServerName, /LicenseServerPort, and /LicenseModel options. For more information, see License server options.

106

Configuring XenApp Using the Wizard-based Server Configuration Tool


To configure XenApp using the wizard-based XenApp Server Configuration Tool: 1. Access the Server Role Manager. 2. Click Configure under XenApp. The Server Configuration Tool launches. 3. Select the task to perform.
q

Create. After you install XenApp on the first server, that server is where you create a new farm during configuration. Join. After you install XenApp on other servers, you add each server to (join) an existing farm. Prepare this server for imaging and provisioning. (Valid only if the XenApp server role was previously configured) Prepares the server for imaging.

Leave. (Valid only if the XenApp server role was previously configured) Removes the server from the farm. The remainder of this procedure assumes you are creating a new farm or adding a server to a farm.
q

4. When creating a farm, on the Enter basic information page:


q

Enter a farm name, up to 32 characters (can include spaces). If you are using Oracle as your Configuration Logging database, do not use hyphens in the farm name.

Specify the domain and username for a user who will be the first Citrix administrator. The administrator has full permissions to the farm and can create additional administrator accounts. 5. Select the data store database type and connection information.
q

If you choose the entry for New database

Action When creating a farm, the Server Configuration Tool installs the Microsoft SQL Server Express database automatically, with the instance name CITRIX_METAFRAME and database name MF20. The database uses Windows authentication. You are prompted for the instance name, the database name, and the authentication method. This database can be located on a remote SQL server. You are prompted for the Net Service name. (The Oracle entry appears only if the Oracle client is installed on the server where you are configuring the XenApp role.)

Existing Microsoft SQL Server database Existing Oracle database

107

Configuring XenApp Using the Wizard-based Server Configuration Tool 6. Specify the database credentials. Specify the user name in the form <DBMACHINE>\<USER> or <DOMAIN>\<USER>. SQL Server Express requires an existing Windows account, but it does not need to be a server or system administrator. The Server Configuration Tool adds two database administrators to SQL Server Express: (local)\administrators and the supplied credentials for the local or domain user. When adding a server to (joining) a farm, you can optionally test the connection to the database. The result does not affect Server Configuration Tool operations. 7. The default session shadowing settings (which allow shadowing) are recommended for most farms. Shadowing settings supplied during XenApp configuration override system or domain policy for user-to-user shadowing. Important: Shadowing features are permanent and should be changed only if you want to permanently prevent system or domain policy from affecting that setting. If you disable shadowing or change shadowing features during configuration, you cannot reconfigure them later. Option Prohibit shadowing of user session on this server Allow shadowing of user sessions on this server Description Disables user session shadowing on this server. If selected, shadowing cannot be enabled on this server through policies. Default = unselected Enables user session shadowing on this server. Default = selected When you enable shadowing, you can apply the following features (default = all unselected):
q

Prohibit remote control. If selected:


q

Authorized users can view sessions but do not have keyboard and mouse input

Remote control is permanently prohibited; this cannot be enabled on this server through policies. Force a shadow acceptance prompt. If selected:
q q

Authorized users must send an acceptance prompt when attempting to shadow a session.

A shadow acceptance prompt is shown on every shadowing attempt; this cannot be disabled on this server through policies. Force logging of all shadow connections. If selected:
q q

All shadowing attempts, successes, and failures are logged in the Windows event log.

Shadow connections are always logged; this cannot be disabled on this server through policies. 8. If you do not change the following server settings, the Server Configuration Tool uses default values.
q

108

Configuring XenApp Using the Wizard-based Server Configuration Tool Setting Data Collection Description Specify the server mode and zone name.
q

(Displayed only when joining a farm) Select a server mode:


q

Enable controller and Session-host modes (default). This server can host sessions and serve as a data collector or XML broker.

Enable Session-host mode only. This server can host sessions but cannot serve as a data collector or XML broker. For more information about server modes, see XenApp Server Mode.
q q

The default zone name is Default Zone. To create a custom zone name, select the checkbox and enter the name.

XML Service Receiver Remote Desktop Users

Citrix XML Service port. For more information, see Citrix XML and IIS Integration. Server name or URL of the Web Interface server used by the Citrix Receiver. Only members of the Remote Desktop Users group can connect to published applications. Until you add users to this group, only administrators can connect remotely to the server. Select one or more of the following.
q

Add Anonymous users. Adds anonymous users to the Remote Desktop Users group. Default = selected Add the Authenticated users. Adds current (and future) domain accounts in the Windows Users group to the Remote Desktop Users group. Default = unselected

Add the list of users from the Users group. Adds all current users from the Users group to the Remote Desktop Users group. If you add users later, you must add them manually to the Remote Desktop Users group. Default = selected 9. If you installed a plug-in or agent for the Single sign-on, SmartAuditor, EdgeSight, or Power and Capacity Management features on this server, specify the requested information to enable communications with them. (The feature roles use separate tools for their configuration.)
q

10. Review the summary page. After you click Apply, a display indicates configuration progress and the result. If the configuration fails, click View Log to display the configuration log. After configuration completes, you are returned to the XenApp Server Role Manager, which indicates if any requirements remain.

109

Configuring XenApp Using the Wizard-based Server Configuration Tool


q

If you have not yet configured XenApp license information, click Specify licensing. To initiate a server restart, click Reboot.

110

Configuring XenApp from the Command Line


Note: The Configuration Command Syntax topic lists and describes the XenApp configuration command-line options. This topic contains information about using the XenApp configuration command and its options.

Command Conventions
Several options use Boolean values (true or false).
q

If you omit an option that requires a Boolean value, the default value is used. For example, if you do not include the /AddLocalAdmin:True|False option in the command, the default value (false) is used (that is, a local administrator is not added). If you specify an option that requires a Boolean value but you omit the value, the option default value is true. For example, for the /AddLocalAdmin:True|False option, if you specify only /AddLocalAdmin (with no :True or :False value), the option is true (that is, a local administrator is added).

You can use environment variables to represent one or more command-line options. For example, you can group the standard Pause, Confirm, and NotStrict options as a single environment variable. You can also use environment variables in the command-line option values (for example, /ServerName:%currentServer%, where currentServer is defined as an environment variable).

Return Codes
The XenAppConfigConsole command supports the following return codes: Value 0 1 Meaning Success Invalid command-line options - for example, the command includes the options /ServerName:server_name and /ExecutionMode:Create (an option that is valid only when joining a farm was specified when creating a farm) Unmatched parameters - an unrecognized option was specified Invalid parameters - for example, for an option that requires a Boolean value (that is, True or False), you specified 'Bob' Commit failed - the configuration process did not complete; check the log file for details

2 3 4

111

Configuring XenApp from the Command Line

Mapping of Earlier XenApp Version Properties to Options


XenApp versions earlier than 6.0 supported installation and configuration properties. Some of those properties have equivalent options in XenApp 6. Property in Earlier XenApp Version CTX_MF_FARM_SELECTION CTX_MF_NEW_FARM_NAME CTX_MF_DOMAIN_NAME, CTX_MF_USER_NAME CTX_MF_SILENT_DSNFILE CTX_MF_ODBC_USER_NAME CTX_MF_ODBC_PASSWORD CTX_MF_LICENSE_SERVER_NAME CTX_MF_LICENSE_SERVER_PORT CTX_MF_ZONE_NAME CTX_MF_XML_PORT_NUMBER, CTX_MF_XML_CHOICE CTX_MF_SHADOWING_CHOICE:yes CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION CTX_MF_SHADOW_PROHIBIT_NO_LOGGING CTX_MF_ADD_ANON_USERS CTX_MF_CREATE_REMOTE_DESKTOP_USERS Option in XenApp 6 /ExecutionMode /FarmName /CitrixAdministratorAccount:domain\user /DsnFile /OdbcUserName /OdbcPassword /LicenseServerName /LicenseServerPort /ZoneName /CustomXmlServicePort /ProhibitShadowing:false /ProhibitRemoteControl /ForceShadowPopup /ForceShadowLogging /AddAnonymousUsersToRemoteDesktopUserGroup /AddUsersGroupToRemoteDesktopUserGroup

112

Configuration Command Syntax


On the server where the XenApp server role is installed, from C:\Program Files (x86)\Citrix\XenApp\ServerConfig, type the following at a command prompt: XenAppConfigConsole.exe [options] The following tables describe configuration command options, grouped by category. Note: You can also use this command to remove the XenApp server role; see Removing Roles and Components.

Configuration process and command-related options /help Displays command help. /NotStrict Allows the executable to continue processing even if options do not apply in the current context. /Confirm Displays a confirmation message before modifying the server. This can be useful when testing for correct use of command options. /Pause Pauses the executable after processing completes. This prevents the command prompt from closing when launching the command from a batch file. /LogFilename:file Logs the progress of the executable to a log file. In the log, the symbols >> indicate a function call; the symbols << indicate a function return. Default: C:\Windows\Temp General farm information options

113

Configuration Command Syntax /ExecutionMode:Create | Join | Leave | ImagePrep (Required) Specifies the task to perform.
q

Create. After you install XenApp on the first server, that server is where you create a new farm during configuration. Join. After you install XenApp on other servers, you add each server to (join) an existing farm. ImagePrep. (Valid only if the XenApp server role was previously configured) Prepares the server for imaging. Leave. (Valid only if the XenApp server role was previously configured) Removes the server from the farm.

/FarmName:name (Required and valid only with /ExecutionMode:Create) Specifies the farm name, up to 32 characters (can include spaces). If you are using Oracle for the Configuration Logging database, do not use hyphens in the farm name. /CitrixAdministratorAccount:domain\user (Required and valid only with /ExecutionMode:Create) Specifies the domain and username for the user who will be the first Citrix administrator. The administrator has full permissions to the farm and can create additional administrator accounts. /ZoneName:name Specifies the zone name. Default = Default Zone /AddLocalAdmin:True | False Enables or disables creation of Citrix administrator accounts for all user accounts in the local Administrators group. Default = False /ImaWorkerMode: True | False (Valid only with /ExecutionMode:Join) Enables or disables ability of the server to be a data collector or XML broker. For more information, see XenApp Server Mode. Default = False (server can be a data collector or XML broker) Database used for farm data store options If you use a Microsoft SQL Server Express database, you can simplify configuration by using the /SimpleDB option when creating the XenApp farm. When joining a farm that uses that database, use the /ServerName option to specify the name of the XenApp server on which you created the farm. /SqlExpressRootDir:ir Specifies the location of the SQL Server Express source installation directory. Default = C:\Program Files (x86)\Citrix\XenApp\ServerConfig\SqlExpress_2008. /SimpleDB Indicates the farm uses a SQL Server Express database for the data store.

114

Configuration Command Syntax /ServerName:name (Valid only with /ExecutionMode:Join and required with /SimpleDB) Specifies the name of the server where the XenApp farm was created (that is, where the SQL Server Express database was installed). /DsnFile:file Specifies the path to the DSN file used to connect to the data store. /AuthenticationType:Windows | Sql (Valid only when using a SQL Server or Oracle database for the farm data store) Specifies the authentication type. Default = Windows /OdbcUserName:name (Required when creating or joining a farm) Specifies the database user name in the form <DBMACHINE>\<USER> or <DOMAIN>\<USER>. SQL Server Express requires an existing Windows account, but it does not need to be a server or system administrator. XenApp configuration adds two database administrators to SQL Server Express: (local)\administrators and the supplied credentials for the local or domain user. Specify the database password with the /OdbcPassword option. /OdbcPassword:password (Required when creating or joining a farm) Specifies the database user password. Specify the database user name with the /OdbcUserName option. License server options For more information, see Licensing Your Product. /LicenseServerName:name Specifies the name of the existing license server. /LicenseServerPort:port Specifies the license server port. Default = 27000 /LicenseModel:model Specifies the licensing model. Valid values are:
q

XA. Specify this model if you plan to use only XenApp licenses. XDC. Specify this model if you plan to use XenDesktop concurrent user licenses.

q XDUD. Specify this model if you plan to use XenDesktop user or device licenses. Default = XA

Session shadowing options

115

Configuration Command Syntax Important: Citrix recommends using the default values (that is, do not specify them in this command). Shadowing settings specified during XenApp configuration override system or domain policy for user-to-user shadowing. Shadowing features are permanent and should be changed only if you wish to permanently prevent system or domain policy from affecting that setting. If you disable shadowing or change shadowing features during configuration, you cannot reconfigure them later. /ProhibitShadowing:True | False Disables or enables session shadowing. Default = False (shadowing is enabled) /ProhibitRemoteControl:True | False (Valid only if shadowing is enabled) Prohibits or allows remote control shadowing. When this option is true, authorized users can view sessions but do not have keyboard and mouse input. Default = False /ForceShadowPopup:True | False (Valid only if shadowing is enabled) Enables or disables sending a shadowing acceptance popup. When this option is true, authorized users must send an acceptance prompt when attempting to shadow a session. Default = False /ForceShadowLogging:True | False (Valid only if shadowing is enabled) Enables or disables logging of all shadow connections. When this option is true, all shadowing attempts, successes, and failures are logged to the Windows event log. Default = False Citrix XML service port options For information about the XML IIS Service Integration component, see Citrix XML and IIS Integration. /CustomXmlServicePort:port Specifies the port number to be used by the Citrix XML Service. Default = 80 /SkipXmlSetting:True | False When this option is true, the Citrix XML service and IIS port numbers are not configured (that is, the default port 80 is not used). Default = False Remote Desktop Users Group options Only members of the Remote Desktop Users Group can connect to published applications. Until you add users to this group, only administrators can connect remotely to the server. Specify one or more of the following options. /AddAnonymousUsersToRemoteDesktopUserGroup:True | False Enables or disables adding anonymous users to the Remote Desktop Users group. Default = True /AddAuthenticatedUsersToRemoteDesktopUserGroup:True | False Enables or disables adding current (and future) domain accounts in the Windows Users group to the Remote Desktop Users group. Default = False

116

Configuration Command Syntax /AddUsersGroupToRemoteDesktopUserGroup:True | False Enables or disables adding all current users from the Users group to the Remote Desktop Users group. If you add users later, you must add them manually to the Remote Desk-top Users group. Default = True Image preparation and provisioning options For more information, see Preparing for XenApp Imaging and Provisioning. /RemoveCurrentServer:True | False (Valid only with /ExecutionMode:ImagePrep) Enables or disables removing the current server instance from the XenApp farm. Default = True /PrepMsmq:True | False (Valid only with /ExecutionMode:ImagePrep) Enables or disables resetting the MSMQ ID during resealing. Default = True /ClearLocalDatabaseInformation:True | False (Valid only with /ExecutionMode:ImagePrep) Enables or disables removing the server, database, and failover partner entries from the DSN file and setting the equivalent LGPO settings to NotConfigured. Default = True Important: If you enable removal of the database information, XenApp assumes an Active Directory policy will provide database settings. If a policy is not applied, the server will not restart. Feature and component options /SmartAuditorServerName:name (Required if you installed the SmartAuditor agent on the XenApp server) Specifies the name of the SmartAuditor server. /SsoPluginUncPath:path UNC path to the Single sign-on central store. Default = use Active Directory /OnlinePluginServerUrl:name_url Server name or URL of the Web Interface server used by the Citrix Receiver. /PcmFarmName:farm Power and Capacity Management farm name. /PcmWorkloadName:name Power and Capacity Management workload name. /EdgeSightCompanyName:name EdgeSight company name.

117

Configuration Command Syntax /EdgeSightServerName:name EdgeSight server name. /EdgeSightServerPort:port EdgeSight server port. Default = 80 Other options /CreateAnonymousUserAccounts:True | False Creates anonymous Citrix accounts Anon000-Anon014. Default = True /RemoveAnonymousCitrixAccounts:True | False Removes anonymous Citrix accounts Anon000-Anon014. Default = False

Example
The following command, issued from the typical XenApp Server Configuration Tool location (C:\Program Files (x86)\Citrix\XenApp\ServerConfig\XenAppConfigConsole.exe), joins the server to the farm, specifying database credentials and the DSN file location, license server and model information, log file location, and Remote Desktop User Group configuration settings. C:\Program Files (x86)\Citrix\XenApp\ServerConfig\ -XenAppConfigConsole.exe" /ExecutionMode:Join /OdbcUserName:administrator /OdbcPassword:somepasswd /LicenseServerName:somelicenseserver /LicenseServerPort:27000 /LicenseModel:XA /ZoneName:some_zone_name /DsnFile:"c:\somepath\to\example.dsn" /Log:c:\SomewhereConfigLog.txt /CustomXmlServicePort:8080 /AddAnonymousUsersToRemoteDesktopUserGroup:True /AddUsersGroupToRemoteDesktopUserGroup:True /AddAuthenticatedUserstoRemoteDesktopUserGroup:True

118

Preparing for XenApp Imaging and Provisioning


Primary deployment methods for XenApp servers include server imaging, virtualization, and provisioning. Separation of the XenApp server role installation and configuration tasks offers flexibility in deciding when to capture (create) XenApp images. Provisioning a XenApp server uses one of three typical approaches; the approach you use depends on when you configure XenApp (earlier or later) in your preparation steps. The XenApp server joins its farm on the first restart (reboot) after configuration; this ensures that the XenApp server image joins or rejoins the farm after it has been cloned with its final identity. Important: Cloning is not supported for the first server in the farm (where you created the farm during configuration), and should be used only for creating new member servers for an existing farm. The following descriptions assume you already created a XenApp farm containing at least one server. You need the data store database information and credentials for the farm.

Approach 1: Capture an image after XenApp installation, but before configuration and restart
In this approach, you install the XenApp server role, but wait to configure XenApp (join a farm) until after the server is cloned and booted. XenApp server configuration is automated, using a script. This approach is not supported in Citrix Provisioning Services using Shared Image mode. 1. Install the XenApp server role, but do not configure the server. You may want to restart the server to ensure the system path is updated properly before installing other applications. 2. Install your applications and configure the settings you want in your image. Deploying prerequisites such as Remote Desktop Services roles may require a server restart before you can install XenApp. 3. Run the generalization tools you normally run. 4. Set up a script to run when each cloned server boots. This script configures the XenApp server (including farm information) using the XenAppConfigConsole.exe command. The script then restarts the server, whereupon the server joins the farm. You can set up scripts using typical methods such as Active Directory startup scripts or the RunOnce registry key.

119

Preparing for XenApp Imaging and Provisioning 5. Capture an image of the server.

Approach 2: Capture an image after XenApp installation and configuration, but before restart
In this approach, you install and configure the XenApp server role, but wait to restart the server until after it is cloned. When the server restarts as a clone of the original image, it joins the farm with its new identity. You do not need direct access to your database server or network during configuration, so this approach can be used to prepare XenApp images for remote deployments. If you do not or cannot verify your database credentials, and they are invalid, XenApp will not join the farm when the server restarts. In that case, run the XenApp Server Configuration Tool, providing correct credentials, and then recapture an image. 1. Install your applications and configure the settings you want in your image. 2. Install the XenApp server role. Deploying prerequisites such as Remote Desktop Services roles may require a server restart before you can install XenApp. 3. Configure the XenApp server to add the server to (join) a farm, but do not restart the server. 4. Run the generalization tools you normally run. 5. Capture an image of the server. Note: If you are using the SmartAuditor agent or other features that depend on Microsoft Messaging Queuing (MSMQ), use Approach 3.

Approach 3: Capture or update an image after XenApp installation, configuration, and restart
If you require XenApp to be installed and working before you create a final image, you must remove the server from the farm, then rejoin the farm before your final shutdown (for example, after sysprep), so that the server will join the farm on the next restart, with its new identity. 1. Install the XenApp server role. Optionally, install the Provisioning Services Target Device software. This software resets your network connection during installation. Failures may occur if you install this component from a network location. Although these failures are not commonly harmful, Citrix recommends installing the Provisioning Services Target Device software from a DVD, mounted ISO, or local copy of the installation media. 2. Configure XenApp to join a farm, and then restart (reboot) the server. 3. Install your applications and configure the settings you want in your image.

120

Preparing for XenApp Imaging and Provisioning 4. Edit your XenApp configuration and select the task Prepare this server for imaging and provisioning. (For a command-line configuration, specify the /ExecutionMode:ImagePrep option.)
q

If you are working with an image template that you do not want to keep in the current farm, select the Remove this current server instance from the farm checkbox. (For a command-line configuration, use the /RemoveCurrentServer:True option.) If you are provisioning the XenApp server with SmartAuditor or other features that depend on MSMQ, selecting the Prepare Microsoft Messaging Queuing provisioning checkbox ensures a new unique machine identifier when the server image boots. (For a command-line configuration, use the /PrepMsmq:True option.) If you select the Clear database location settings from this server checkbox, the default database information is removed from local settings (server, database, and failover partner entries are removed from the DSN file; LGPO is set to NotConfigured). This ensures that cloned servers can join only a XenApp farm that is specified with inherited group policy settings. (For a command-line configuration, use the /ClearLocalDatabaseInformation:True option.)

Important: If you select this checkbox, XenApp assumes an Active Directory policy will provide database settings. If a policy is not applied, the IMA Service will not start. 5. Run the generalization tools you normally run. 6. Capture an image of the server. The server joins the farm when the image boots.

Resealing an image
If a golden image requires updating (for example, with Citrix or Windows hotfixes, or third-party applications and patches), you can reseal the image. This procedure is similar to approach 3. 1. Boot into the image to make modifications. The XenApp server will try to join the farm if it can. 2. Modify the server as needed. 3. Proceed with step 4 in Approach 3. During the resealing process, the Server Configuration Tool:
q

Removes server-specific information, such as WSID in MF20.dsn, WSID in RadeOffline.dsn. Creates a unique Secure Ticket Authority (STA) ID in CtxSta.config, using the MAC address. Resets the local databases and removes the Servers setting from the Independent Management Architecture (IMA) data store by clearing the IMA local host cache and

121

Preparing for XenApp Imaging and Provisioning RadeOffLine databases.


q

Places the following configuration information into the Local Group Policy Object (LGPO) if they have nondefault values (nondefault values appear as Configured, default values appear as NotConfigured).
q

Product feature and server edition License server hostname License server port number XML Service port Database server, database, and failover partners (if that checkbox was selected)

Installation and Configuration Considerations


For provisioning purposes, you can install the XenApp server role using the wizard-based XenApp Server Role Manager or the command line. For wizard-based installations, do not proceed to configuring the XenApp server role until you are ready, based on the approach you select. Configuring the XenApp server after it is instanced (approach 1) should be automated using the command line. You can use the wizard-based XenApp Server Configuration Tool or the command line to configure the XenApp server if you choose approach 2 or 3. When preparing a XenApp server for imaging and provisioning:
q

The server should not be the only server in the XenApp farm. The server should not be the data collector. The server should not have the data store database installed on it. The server should not have the Citrix License Server installed on it.

Important: When provisioning XenApp, you must remove the server SSL certificate before running XenConvert; otherwise, the SSL certificate will be distributed to all provisioned XenApp servers. For example, the following command, issued from the root of the installation media, installs the XenApp server role and the Provisioning Services target device, and excludes installation of the AppCenter. \XenApp Server Setup\bin\XenAppSetupConsole.exe /install:XenApp,PVDeviceFeature /exclude:XA_Console The following command prepares XenApp for imaging and provisioning. The server will be removed from the current farm, and when the server image boots, it will contain a unique MSMQ machine identifier. Database identification information will be removed from the DSN file.

122

Preparing for XenApp Imaging and Provisioning C:\Program Files (x86)\Citrix\XenApp\ServerConfig\ -XenAppConfigConsole.exe" /ExecutionMode:ImagePrep /RemoveCurrentServer:True /PrepMsmq:True /ClearLocalDatabaseInformation:True

123

Removing Roles and Components


You can remove the following XenApp 6.5 roles and some components using the wizard-based Server Role Manager or the command line:
q

XenApp Receiver Storefront Web Interface Licensing Single sign-on service Provisioning server

Important: Although you can use Windows Programs & Features to remove the XenApp 6.5 roles listed above, Citrix strongly recommends using the Server Role Manager. To remove other roles (such as EdgeSight server, SmartAuditor server, Power and Capacity Management administration components, Secure Gateway), use Windows Programs & Features. You cannot use the XenApp 6.5 Server Role Manager to remove fully-integrated roles in an earlier XenApp version deployment (including early release or Technical Preview versions). In those cases, Citrix recommends reimaging the server and then installing XenApp. When you remove the XenApp server role, the process automatically removes the server from the XenApp farm.

124

Removing Roles and Components

Removing Roles and Components Using the Wizard-based Server Role Manager
1. Access the XenApp Server Role Manager. 2. Select Add or remove server roles. 3. On the Select a task page, select Remove server roles. 4. Select one or more roles to remove. If you select a role that has default components, those default components are automatically selected; you cannot change this (that is, you cannot remove the role without also removing its default components). To remove only a default component (for example, to remove the AppCenter but leave the XenApp server role installed), select only the component, not the role. You cannot remove the XenApp XML IIS Integration default component or the Windows Enhanced Desktop Experience optional component. Required role components are not listed. The Receiver for Windows and the Offline Plug-in are automatically installed with the XenApp server role; you cannot remove them using the Server Role Manager unless you also remove the XenApp server role. 5. Review the summary, which lists the roles and components to be removed. After you click Remove, a display indicates the progress and the result.

Removing XenApp Roles and Components Using the Command Line


On the server where you want to remove a role or component, from either the %PROGRAMDATA%\Citrix\XenAppUninstall\ or XenApp Server Setup\bin\ directory, type the following at a command prompt: XenAppSetupConsole.exe options Valid options are:

/help Displays command help. /logfile:path Path for the log file generated during the removal.

125

Removing Roles and Components /uninstall:items Comma-delimited list of roles and components to remove. Valid values are:
q

ReceiverStorefront. Receiver Storefront. WebInterface. Web Interface role. Licensing. License server role. SsonService. Single sign-on service role. Provisioning. Provisioning Services role. XenApp. XenApp server role. XA_Console. AppCenter. EdgeSightAgentFeature. EdgeSight agent. SmartAuditorAgentFeature. SmartAuditor agent. SSONAgentFeature. Single Sign-on Plug-in. PCMAgentFeature. Power and Capacity Management agent. PVDeviceFeature. Provisioning Services target device.

Note: You cannot remove the XenApp XML IIS Integration or Enhanced Desktop Experience components. The Receiver for Windows and the Offline Plug-in are removed when you remove the XenApp server role. Important: When using the XenAppSetupConsole.exe command to remove roles or components, do not specify options that configure the XenApp role.

Examples
The following command removes the XenApp server role and all its default components. XenAppSetupConsole.exe /uninstall:XenApp The following command removes the Receiver Storefront and the XenApp server role. XenAppSetupConsole.exe /uninstall:XenApp,ReceiverStorefront The following command removes the SmartAuditor agent component. XenAppSetupConsole.exe /uninstall:SmartAuditorAgentFeature

126

Data Store Database Reference


See the database vendor documentation before installing, configuring, and using the database software. CTX114501 contains information about supported database versions. If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp configuration automatically installs it. Important:
q

Citrix does not support case-sensitive databases. To avoid corruption, do not directly edit data in the data store database with utilities or tools other than those provided by Citrix.

Maintaining, Backing up, and Restoring a XenApp Data Store


Most database maintenance requires running the dsmaint and dscheck server utilities on XenApp farm servers. The XenApp Server Utilities Reference contains syntax and use details. Use dsmaint to:
q

Upgrade the XenApp data store Move the data in the data store to a different database server Change the name of the DSN file

If the data store fails, each farm server can run from the data in its Local Host Cache indefinitely, provided it can contact the license server. However, you cannot make any modifications to the farm or use the AppCenter. Create a backup copy of the data store (dsmaintbackup). Without a backup, you must manually recreate all of the farm policies, settings, accounts, and other persistent data in the data store. To restore a backup database or to migrate to a new server, use the dsmaint migrate utility. Without a backup, prepare a new data store the way you did before configuring XenApp and run the XenApp Server Configuration Tool from any farm server. After running the Server Configuration Tool, manually reenter the lost settings. If you use the same name as the previous data store, you do not need to reconfigure the farm servers.

127

Microsoft SQL Server Database


The server hosting the Microsoft SQL Server database should meet the following minimum requirements:
q

Approximately 100MB of disk space for every 250 servers and 50 published applications in the XenApp farm. Provide more disk space for greater numbers of published applications. Set the "temp" database to automatically grow on a partition with at least 1GB of free disk space. Citrix recommends 4GB if the farm is large and includes multiple print drivers.

The default database installation settings and database sizes usually suffice for XenApp data store needs. Microsoft SQL Server supports Windows and Microsoft SQL Server authentication. For high-security environments, Citrix recommends using Windows authentication only. The user account for installing, upgrading, or applying hotfixes to the data store must have database owner (db_owner) rights to the database. When you finish installing the database with database owner rights, set the user permissions to read/write only to increase the security of the database. Change the rights back to database owner before installing service packs or feature releases; installations can fail if the user account used to authenticate to the data store during Setup does not have database owner rights. When using Microsoft SQL Server in a replicated environment, use the same user account for the data store on each Microsoft SQL Server. Each farm requires a dedicated database. However, multiple databases can be running on a single server running Microsoft SQL Server. Do not configure the farm to use a database that is shared with any other client/server applications. Back up the database regularly and follow Microsoft recommendations for configuring database and transaction logs for recovery (for example, setting the Truncate log on Checkpoint option to control log space).

128

Microsoft SQL Server Database

Using Sockets to Connect to a Microsoft SQL Server Database


Two protocols used to connect to a database are TCP/IP sockets and named pipes. Named pipes is an authenticated communication protocol, so any time you attempt to open a connection to the SQL Server database using this protocol, the Windows authentication process occurs. TCP/IP sockets do not rely on Windows authentication to establish a connection, but do provide user/password authentication to the database after the connection is established. Windows authentication reduces the possibility of an error occurring when the server hosting SQL Server and the XenApp server do not have the correct domain or Active Directory trust relationship. Therefore, Citrix recommends using TCP/IP sockets. If you use named pipes, manually enable the named pipes option on the database server using the Surface Area Configuration tool packaged with SQL Server.

Creating a Microsoft SQL Server Data Source Connection


1. On the Create a New Data Source to SQL Server screen, enter the data source description and select the SQL Server to which to connect. 2. Select Windows NT Authentication or SQL Server Authentication. 3. Click Client Configuration. 4. Select TCP/IP from the available network libraries. 5. After installing XenApp, modify the Data Source Name (DSN) created during configuration and change its client configuration to use TCP/IP. To modify a DSN, use the Windows ODBC Data Source Administrator utility to open the File DSN, which is located by default in the %ProgramFiles(x86)%\Citrix\Independent Management Architecture folder, and select TCP/IP as the connection protocol for the client configuration.

Using Failover with Microsoft SQL Server


For fault tolerance with Microsoft SQL Server, use Microsoft clustering, which provides failover and failback for clustered systems. Failover of the SQL Server database in a clustered environment is transparent to XenApp. The database files for an instance of Microsoft SQL Server are placed in a single cluster group owned by the node on which the instance is installed. If a node running an instance of Microsoft SQL Server fails, the cluster group containing the data files for that instance is switched to another node. The new node already has the executable files and registry information for that instance of Microsoft SQL Server on its local disk drive, so it can start 129

Microsoft SQL Server Database up an instance of Microsoft SQL Server and start accepting connection requests for that instance. Microsoft Cluster Services clustering does not support load balancing among clustered servers because it functions in active/passive mode only.

Using Distributed Databases with Microsoft SQL Server


XenApp supports distributed (replicated) databases. Replicated databases are useful when too many read requests to the data store create a processing bottleneck. Microsoft SQL Server uses replication to create the distributed database environment. XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for storing data in the database. When configuring Microsoft SQL Server for a two-phase commit, use the Immediate Updating Subscriber model. When configuring Microsoft SQL Server, you may need to increase the value of the Max Text Replication Size property to improve replication performance. Caution: To avoid corruption, do not use merged replication. To set up a distributed environment for an existing XenApp farm: 1. Configure a Publisher (the Microsoft SQL Server currently hosting the data store) and Subscribers (remote sites) using Microsoft SQL Server Enterprise Manager. 2. Run the dsmaint publishsqlds command on a server in the farm. This executes the necessary SQL statements to create the published articles on the current Microsoft SQL Server (Publisher). 3. Configure the remote sites (Subscribers) to subscribe to the published articles created in the previous step.

130

Oracle Database
The server hosting the Oracle database should meet the following minimum requirements:
q

Approximately 100MB of disk space for every 250 servers and 50 published applications in the farm. Provide more disk space for greater numbers of published applications. 20 MB minimum tablespace size.

Oracle supports Windows and Oracle authentication. Oracle for Solaris supports Oracle authentication only; it does not support Windows authentication. In the Oracle sqlnet.ora file, set SQLNET.AUTHENTICATION_SERVICES= (NONE). The default setting (NTS) will cause connection failures. Do not install XenApp on a server hosting an Oracle database. Install the Oracle client on the server where you will be installing XenApp and then restart the server before you install XenApp. The Oracle user account must be the same for every server in the farm because all XenApp servers share a common schema. If you are using one database to hold information for multiple farms, each farm represented in the database must have a different user account because the data store information is stored in the Oracle user account. The account used to connect to the data store database has the following Oracle permissions:
q

Connect Resource Unlimited Tablespace (optional)

Consider the following guidelines when configuring an Oracle server.


q

Use Shared/Multi-Threaded Server mode to reduce the number of processes in farms with more than 100 servers (performance may be affected during periods of high data store load). If you are using Multi-Threaded Server mode, verify that values in the Init.ora file are greater than or equal to the following values. If you are running multiple farms on the same Oracle database, include all XenApp servers in the calculations. Round up fractional values. shared_servers = Number of servers / 10 max_shared_servers = Number of servers / 5

131

Oracle Database Where Number of servers is the total number of servers running XenApp.
q

When using an Oracle server in dedicated mode, add one additional process for each server connected directly to the Oracle database. For example, if the Oracle server uses 100 processes before installing XenApp, and the farm has 50 servers, set the processes value to at least 150 in the Init.ora file on the Oracle server. Create online backups using Archivelog mode, which reduces the recovery time of an unresponsive database. If you are using the same Oracle database for multiple server farms, create a unique tablespace with its own user name and password for added security for each farm. Do not use the default system account within Oracle. Maintain a standby database for quick disaster recovery. A standby database maintains a copy of the production database in a permanent state of recovery.

Using Distributed Databases with Oracle


Oracle uses replication to create the distributed database environment. To reduce the load on a single database server, install read/write replicas and distribute the farm servers evenly across the master and replicas. XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for writes to the database. Using Oracle as a distributed database solution has the following requirements:
q

All participating databases must be running Oracle. All participating databases must be running in Multi-Threaded Server/Shared mode (rather than Dedicated mode). All Oracle clients (XenApp servers that connect directly to the Oracle database) must be SQL*Net Version 2 or Net8. Install the farm data store database first on the master site, then configure replication at the sites used for database replication snapshots. Replicate all objects contained in the data store user schema (tables, indexes, and stored procedures).

If the performance at the replicated database site is significantly slower, verify that all the indexes for the users schema are successfully replicated. When configuring Oracle for a two-phase commit:
q

Use synchronous snapshots that can be updated with a single master site. XenApp requires write access to snapshot. Use the Oracle Fast Refresh feature where possible (this requires snapshot logs). When setting up the replication environment, do not configure conflict resolution.

132

Oracle Database
q

Set the replication link interval to be as frequent as the network environment allows. With Oracle replication, if no changes are made, data is not sent over the link. When Oracle is configured in Multi-Threaded Server mode and remote data transfers are initiated from the remote site, they can block local data transfers (because all connections share a set of worker threads). To remedy this, increase the value of the Max_Mts_Servers parameter in the Init.ora file.

133

XenApp Migration Center


The XenApp Migration Center pulls data from a server in a source XenApp server farm and imports (adds) it to a new XenApp server farm. The data is grouped as object types. The following table lists the supported XenApp versions for the source farm and the new farm. Source farm XenApp 5 for Windows Server 2003 (with minimum HRP5) or XenApp 5 for Windows Server 2008 XenApp 6.0 New Farm XenApp 6.5

XenApp 6.5

XenApp 6.5 deployed in a test/pilot farm XenApp 6.5 deployed in a production farm In all migrations, Citrix recommends you first use the XenApp 6.5 media to perform a clean install of the XenApp server role on one or more Microsoft Windows Server 2008 R2 or Microsoft Windows Server 2008 R2 SP1 servers. Then, use the XenApp Server Configuration Tool to create a new farm or join servers to that new farm. (Clean install means that there is no previous version of the XenApp server role installed on the server.) If you cannot coordinate that recommended process, Citrix provides a XenApp 6.0 to 6.5 Upgrade Utility that you can customize for your servers; see CTX130614. After you configure and restart the new XenApp server, use the Migration Center installed on that server to import objects from the source farm.
q

If you are migrating a XenApp 5 source farm, servers in that source farm are migrated to worker groups in the new farm according to server-to-worker-group mappings you specify before starting the migration. Servers in the mapping are representative servers chosen from each server silo in the XenApp 5 farm. If you are migrating a XenApp 6.0 source farm or a XenApp 6.5 test/pilot source farm, worker groups already exist, so you do not need to set up server mappings before the migration.

You can preview (analyze) a migration; that is, the Migration Center indicates which objects will be imported during a migration, without actually performing the migration. You can repeat the migration as additional servers in the source farm become ready for reimaging in the new farm. During subsequent migration previews, the Migration Center compares source farm objects with objects in the new farm, and lists differences. If you then migrate those objects, the current value in the new farm is overwritten with the current value in the source farm. As the migration of more source farm servers continues, use the Web Interface user roaming feature to help ensure that users can access applications and resources. Citrix recommends performing the entire migration from a server in the new XenApp farm; this is a direct migration. However, if your deployment does not allow this, you can

134

Migrate perform an indirect migration. In this case, you split the migration process by installing and using the Migration Center on a server in the source farm to export settings. Then, using the Migration Center installed on a server in the new XenApp farm, you import the settings into the new farm.

135

Migration Center Interfaces


The Migration Center comprises a PowerShell module. You can use the Migration Center through a graphical interface or a command-line interface. The interfaces use different terminology:
q

The graphical interface refers to the server in the source farm; error messages and the command-line interface refer to the remote server in the legacy farm. The graphical interface refers to the XenApp 6.5 farm as the target farm; the command-line interface uses new farm.

The following table summarizes the differences between the interfaces. Graphical interface Application that guides you through a series of set up, display, preview, and other action screens. Imports all objects from the source farm into the new farm. * Command-line interface A collection of PowerShell cmdlets that you issue in a recommended sequence to set up, display, preview, and other actions. You can specify object types and named objects to include and exclude from the migration. You can also explicitly specify 32-bit applications to be migrated; their paths will be converted to \Program Files (x86)\ so they will launch properly in the 64-bit farm environment. You can override an object property value (setting). For example, you can specify a CPU priority level for applications imported to the new farm, regardless of the CPU priority level in the source farm. Supports direct and indirect migrations, and can specify a different location where the data exported from the source farm is placed before importing it into the new farm.

Imports all property values (settings) for all objects. *

Supports direct migrations.

* Although you cannot specify setting overrides, objects to include or exclude, or other customizations in the graphical interface, you can configure them through the command-line interface, and then use the graphical interface to preview and run the migration. (Both interfaces honor Migration Center settings configured from either interface. For example, if you specify a source server in the graphical interface, the command-line interface uses that value for subsequent actions, if not explicitly overridden with a different server name in the command line.) The following table summarizes how to perform migration tasks in each interface. Action Command-line interface Graphical interface

136

XenApp Migration Center Add, display, or remove a server mapping (valid only when migrating a XenApp 5 farm) Specify a source farm server name Add-XAServerMapping, Get-XAServerMapping, Remove-XAServerMapping Set-XAMigrationOption RemoteServerName or Start-XAMigration -RemoteServerName Set-XAMigrationOption -DataFolderPath Set-XAMigrationOption ObjectType Include Exclude Get-XAMigrationOption Add-XASettingOverride, Get-XASettingOverride, Remove-XASettingOverride Start-XAMigration PendingReportOnly Start-XAMigration Start-XAMigration {-ExportOnly | -ImportOnly} Worker group mappings

Choose a source farm

Specify a nondefault data folder location Specify objects to include or exclude Display migration options Specify, display, or remove a value for an individual object property Preview a migration Migrate Import only or export only

(configure in command-line interface) (configure in command-line interface) (display in command-line interface) (configure in command-line interface)

Analyze Farms Migrate to Target Farm (use command-line interface)

137

Migration Center Interfaces


The Migration Center comprises a PowerShell module. You can use the Migration Center through a graphical interface or a command-line interface. The interfaces use different terminology:
q

The graphical interface refers to the server in the source farm; error messages and the command-line interface refer to the remote server in the legacy farm. The graphical interface refers to the XenApp 6.5 farm as the target farm; the command-line interface uses new farm.

The following table summarizes the differences between the interfaces. Graphical interface Application that guides you through a series of set up, display, preview, and other action screens. Imports all objects from the source farm into the new farm. * Command-line interface A collection of PowerShell cmdlets that you issue in a recommended sequence to set up, display, preview, and other actions. You can specify object types and named objects to include and exclude from the migration. You can also explicitly specify 32-bit applications to be migrated; their paths will be converted to \Program Files (x86)\ so they will launch properly in the 64-bit farm environment. You can override an object property value (setting). For example, you can specify a CPU priority level for applications imported to the new farm, regardless of the CPU priority level in the source farm. Supports direct and indirect migrations, and can specify a different location where the data exported from the source farm is placed before importing it into the new farm.

Imports all property values (settings) for all objects. *

Supports direct migrations.

* Although you cannot specify setting overrides, objects to include or exclude, or other customizations in the graphical interface, you can configure them through the command-line interface, and then use the graphical interface to preview and run the migration. (Both interfaces honor Migration Center settings configured from either interface. For example, if you specify a source server in the graphical interface, the command-line interface uses that value for subsequent actions, if not explicitly overridden with a different server name in the command line.) The following table summarizes how to perform migration tasks in each interface. Action Command-line interface Graphical interface

138

Migration Center Interfaces Add, display, or remove a server mapping (valid only when migrating a XenApp 5 farm) Specify a source farm server name Add-XAServerMapping, Get-XAServerMapping, Remove-XAServerMapping Set-XAMigrationOption RemoteServerName or Start-XAMigration -RemoteServerName Set-XAMigrationOption -DataFolderPath Set-XAMigrationOption ObjectType Include Exclude Get-XAMigrationOption Add-XASettingOverride, Get-XASettingOverride, Remove-XASettingOverride Start-XAMigration PendingReportOnly Start-XAMigration Start-XAMigration {-ExportOnly | -ImportOnly} Worker group mappings

Choose a source farm

Specify a nondefault data folder location Specify objects to include or exclude Display migration options Specify, display, or remove a value for an individual object property Preview a migration Migrate Import only or export only

(configure in command-line interface) (configure in command-line interface) (display in command-line interface) (configure in command-line interface)

Analyze Farms Migrate to Target Farm (use command-line interface)

139

Objects You Can Migrate


You can migrate the following XenApp object types. Object Type Application Description All applications are enumerated; however, for the corresponding worker group to be associated with the application, the application must be published to one of the servers specified in the server mapping file. Only users that can be resolved on the server in the new farm (account authorities that are trusted in the new farm) are migrated. When migrating from a XenApp 6.5 test/pilot farm, this includes pre-launched applications. When migrating from a 32-bit XenApp 5 platform, the application path is not translated. Folder Includes application folders and server folders. Server folders are migrated so that server permissions can be copied; however, the server objects are not migrated. Load evaluators and their rules are migrated. Migrated load evaluators are attached to applications (where applicable), but they are not attached to servers. Policies are migrated by creating an IMA (Independent Management Architecture) User GPO (Group Policy Object) with the same name as the policy. Server filters are migrated by using the Server Group (worker group) filter for the servers in the mapping file. For user filters, only the accounts that can be resolved on the target server in the new farm (account authorities that are trusted in the new farm) are migrated. When migrating from a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm, this includes load balancing policies. Citrix policies in the source farm that are configured in XenApp Management (Delivery Services Console or AppCenter) can be migrated. Citrix policies that are configured in Active Directory using the Group Policy Management Console are not migrated. Server configuration When migrating from XenApp 5, configuration settings for servers specified in the server mapping file are migrated by creating an IMA Machine GPO named "WorkerGroupname" where name is the name of the worker group specified in the server mapping file. This policy is filtered by worker group. Worker groups are created as necessary, but they are not associated with servers or OUs (Organizational Units). When migrating from a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm, this includes worker groups.

Load evaluator

Policy

140

Objects You Can Migrate Farm configuration Administrator Farm configuration settings are migrated by creating an IMA Machine GPO named "Farm." This policy is unfiltered.

Only Citrix administrators whose accounts can be resolved on the server in the new farm are migrated (the corresponding account authorities are trusted in the new farm or they represent Citrix built-in accounts). Farm and server settings from the source farm are compared against the default values used when the new farm was created. The corresponding setting in the policy in the new farm is set to "Not Configured" if it matches the default value for the same setting in the new farm. Health Monitoring and Recovery (HMR) test executables are not copied; however, HMR test configurations are migrated into policies in the new farm. Session printers are migrated, but the printer path is not validated on the new farm. For zones and load evaluators:
q

When migrating from a XenApp 5 farm, zones and load evaluator attachments to servers are not migrated; however, the Zone Preference and Failover policy is converted to a load balancing policy that is filtered by worker groups. The conversion uses the server mappings specified for the migration. When migrating worker groups from a XenApp 6.0 farm, if all servers in a worker group are in the same zone, a group policy is created for the initial zone, and a filter by worker group is applied. If all servers are not in the same zone, an initial zone policy is not created, and a warning appears. Similarly, if all servers in a worker group have the same load evaluator, a policy is created. When migrating from a XenApp 6.5 test/pilot farm, it is assumed that the source farm has zone and load evaluator policies, so they are copied.

The following settings are not migrated:


q

Printer management Configuration Logging settings

Only settings that reside in the IMA data store are migrated; settings that reside only in the server registry are not migrated. The migration process ignores the following settings:
q

Deprecated settings, such as AIE (Application Isolation Environment). Permissions that do not exist in the XenApp 6.5 release, whether they correspond to a deprecated feature or a configuration setting that is now supported as a policy.

141

Requirements and Installation


You can migrate a single XenApp farm.

Requirements for a XenApp 5 Source Farm


q

The servers in the XenApp 5 farm must be running XenApp 5 for Windows Server 2003 with at least Hotfix Rollup Pack 5 (HRP5), or XenApp 5 for Windows Server 2008. The source server must have network COM+ access enabled, and the MFCOM service must be available. To access the source server using a remote connection, you must be a member of the DCOM users group, and a Citrix administrator with at least view-only privileges. When migrating from a 32-bit XenApp 5 farm, network printers used by policies (session printers) must have a 64-bit driver installed in the print server; otherwise, those printers will not be migrated.

Requirements for a XenApp 6.0 Source Farm or a XenApp 6.5 Test/Pilot Source Farm
q

The servers in the farm must be running XenApp 6.0 (in the XenApp 6.0 farm) or XenApp 6.5 (in the XenApp 6.5 test/pilot farm). You must be a Citrix administrator with at least view-only privileges. The XACOM service must be available.

142

Requirements and Installation

Requirements for the New XenApp 6.5 Farm


q

The XenApp 6.5 server role must be installed and configured on the Microsoft Windows Server 2008 R2 or Microsoft Windows Server 2008 R2 SP1 server where you will use the Migration Center. The XenApp server must be configured with the XenApp controller server mode. (You cannot use the Migration Center on a XenApp 6.5 server configured with the XenApp session-only server mode.) Restart the server after configuration. The IMA and XACOM services must be running. You must be a Citrix administrator with full privileges. You must have write access to the folder where the exported data from the source farm is placed before being imported into the new farm. This folder also contains the migrationoptions.xml file containing any migration options and property overrides you set through the Migration Center command-line interface, plus server mappings (when migrating a XenApp 5 farm). By default, this is a folder named Data, located under the XenApp Migration Center installation files in C:\Users\user\appdata\local\citrix\citrix.xenapp.migration). You can specify a different folder in the command-line interface with the Set-XAMigrationOption cmdlet. By default, execution of PowerShell scripts is disabled. Set the PowerShell execution policy to AllSigned (Set-ExecutionPolicy AllSigned) or above. The following software is required to run the Migration Center. This software is required for XenApp server installation and configuration, so it is likely to already be installed.
q

.NET Framework 3.5 SP1 MSI 3.0

q PowerShell 2.0 If the source farm uses file type association for published applications, update the new farm with file type associations (using the Update file types from registry task in the Citrix AppCenter) before you migrate applications. This allows the migration process to create the associations in the new farm.

If you are migrating from a XenApp 5 farm, create worker groups in the new farm for server and application silos. (However, if a worker group you specify in a server mapping does not exist, the Migration Center creates it.)

Installing the Migration Center


The XenApp Migration Center is installed automatically when you install and configure the XenApp 6.5 server role. If you need to re-install the Migration Center at a later date, use the installation file on the XenApp 6.5 media. In the Administration\Delivery Services Console\setup folder, double-click Citrix.XenApp.Migration.Install_x64.msi. Note: Citrix recommends performing direct migrations, entirely from a server in the new farm. If your deployment does not allow this, see Indirect Migrations and Advanced

143

Requirements and Installation Cmdlets for additional installation information about indirect migrations.

144

Migrating XenApp Using the Graphical Interface


1. From the Start menu, select All Programs > Citrix > XenApp Migration > Citrix XenApp Migration Center. The application launches and the environment initializes. 2. If you have not specified a server in the source farm (for a previous migration or preview), the Choose a source farm dialog box appears. a. Enter the name or IP address of the server in the XenApp source farm. b. Click Check. If the specified server is found, the display indicates the XenApp farm name to which the server belongs, and the XenApp version (the display for servers in a XenApp 5 farm may indicate XenApp 4.5). 3. After you specify a server in the source farm, the welcome page appears. From the welcome page, you can change the source server, manage server-to-worker-group mappings (if you are migrating a XenApp 5 farm), or preview a migration. Important: If you previously used the command-line interface to configure a migration with setting overrides, object inclusions or exclusions, and other customizations, those customizations are applied when you use the graphical interface to preview or migrate. In this case, the welcome page indicates that customizations were previously configured. 4. To change the source server, click Change source farm, enter the name or IP address of the server in the source farm, and click Check. If the specified server is found, the display indicates the XenApp farm name to which the server belongs, and the XenApp version (the display for servers in a XenApp 5 farm may indicate XenApp 4.5). If you change the source server, be sure to update any previously-configured custom migration options and worker group mappings that refer to objects or locations in the source farm, if needed. 5. To manage server mappings (if you are migrating a XenApp 5 farm), click Worker group mappings. The Configure worker group mappings dialog box appears, listing all previously-configured mappings. Each mapping specifies a representative server chosen from a server silo in the source farm. Important: Before migrating a XenApp 5 farm for the first time, you must configure mappings. Although mappings are not required, a XenApp 5 farm migration is not complete without them, because no data about the servers will be migrated (for example, server settings, application servers, or the Zone Preference and Failover policy).
q

To add a mapping, click Add. Enter the name or IP address of a server in the source farm and the name of a worker group in the new (target) farm, or browse for the server and worker group. To edit a mapping, select the entry and click Edit and then change values.

145

Migrating XenApp Using the Graphical Interface


q

To delete a mapping, select the entry and click Remove.

6. To preview a migration (that is, see what will happen during a migration, without taking any action), click Analyze Farms. During the analysis, if you select the Automatically perform migration if analysis is successful checkbox, the actual migration will start automatically if the analysis completes successfully and identifies differences between the farms. Remember: Any customizations you configured previously using the command-line interface are used when you preview or migrate in the graphical interface. If the analysis completes successfully, the display identifies new and changed objects (that is, different objects and objects with different setting values in the source farm and the target farm). 7. After the analysis completes, you can:
q

Click Migrate to Target Farm to start the migration. For changed objects, the current value of each setting in the new farm is overwritten with the current value from the source farm. New objects are added to the new farm. Click Analyze Farms Again to start another preview. Click Change analysis settings to return to the welcome page, leaving the differences unchanged. Click View log to display the PowerShell log containing details of the analysis.

Exit the application, and use the command-line interface to customize the migration to accommodate any differences you want to retain, or objects you want to expressly include or exclude during subsequent migrations. Then, when you launch another preview or a migration from either interface, those customizations will be applied. After a migration, continue with Post-migration Tasks.
q

146

Migrating XenApp Using the Command Line Interface


Note: See Cmdlet Reference for information about cmdlet options and properties. 1. From the Start menu, select All Programs > Citrix > XenApp Migration > Windows PowerShell with Citrix XenApp Migration Module. The PowerShell console launches. 2. Before starting a migration, use the following cmdlets to build a file containing server-to-worker-group mappings (if migrating from XenApp 5) and optionally, migration options and property value overrides.
q

Use the Add-XAServerMapping cmdlet to map servers in the XenApp 5 farm to worker groups in the new farm. The servers in the mapping are representative servers chosen from each server silo in the legacy farm. Important: Before migrating a XenApp 5 farm for the first time, you must configure server mappings. Although mappings are not required, a XenApp 5 farm migration is not complete without them, because no data about the servers will be migrated (for example, server settings, application servers, or the Zone Preference and Failover policy).
q

To display the server mappings you specified, use the Get-XAServerMapping cmdlet.

To remove a server mapping, use the Remove-XAServerMapping cmdlet. Use the Set-XAMigrationOption cmdlet to customize the migration. Setting migration options is optional.
q

You can specify:


q

A remote server name; this is the name of the server in the source farm from which objects will be migrated. Specifying the remote server name as a migration option eliminates having to specify it each time you start a migration. If you change the source server, be sure to update any previously-configured custom migration options and worker group mappings that refer to objects or locations in the source farm, if needed.

A nondefault folder location where the exported data from the legacy farm is stored. Object types and named objects to include or exclude from the migration.

32-bit applications to be migrated to the 64-bit farm; their paths will be converted from \Program Files\ to \Program Files (x86)\. To display the migration options you specified, use the Get-XAMigrationOption cmdlet.
q

147

Migrating XenApp Using the Command Line Interface


q

Use the Add-XASettingOverride cmdlet to specify values for individual object properties, if you do not want to migrate specific values from the source farm to the new farm. Specifying setting overrides is optional.
q

To display the names of object properties you can specify with the Add-XASettingOverride cmdlet, use the Get-XALegacySettingName cmdlet. To display the property override values you specified, use the Get-XASettingOverride cmdlet.

To remove a property override value you specified, use the Remove-XASettingOverride cmdlet. Remember: Previews and migrations launched from either interface will use the customizations (and mappings, if migrating from XenApp 5) specified in the command-line interface, unless expressly overridden.
q

3. To preview the migration (that is, see what will happen during a migration, without taking any action), enter Start-XAMigration -PendingReportOnly. 4. Launch the migration with the Start-XAMigration cmdlet. 5. After running a migration, use the Get-XAMigrationObjectCount cmdlet to display a count of the objects in the legacy and new farms. This helps monitor equivalency between the new farm and the legacy farm. You can tailor the display to report differences from an existing snapshot. After a migration, continue with Post-migration Tasks. Note: Subsequent migrations (launched from either interface) will use the current migration options, and property value overrides file.

148

Cmdlet Reference

Cmdlet Summary
For PowerShell help, type Get-Help cmdlet-name.
q

To see examples, use the -examples option. For detailed information, use the -detailed option. For technical information, use the -full option.

The Migration Center cmdlets support the PowerShell common parameters. In particular, -Confirm and -Verbose can be helpful in the migration process. Although the -WhatIf common parameter is supported, using the -PendingReportOnly option with the Start-XAMigration cmdlet provides more detailed information when previewing a migration.

Add-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Adds a mapping between a server in the source farm and a worker group in the new farm. You must specify the following options:

Option -ServerName server-name -WorkerGroupName name

Description MFCOM name of the server in the source farm.

Name of the worker group in the new farm. If the worker group does not exist, it is created. For example, the following cmdlet maps the server named OfficeApps5 to the worker group named DenverAcctg. Add-XAServerMapping -ServerName OfficeApps5 -WorkerGroupName DenverAcctg

Add-XASettingOverride
Specifies a value for an object property (setting). This value is used for the object property in the new farm, regardless of the value of the property in the source farm (it overrides the setting in the source farm). To display the names of object properties you can specify with the Add-XASettingOverride cmdlet, use the Get-XALegacySettingName cmdlet.

149

Cmdlet Reference You can specify the following options:

Option -PropertyName property-name -ObjectType object-type

Description Property name. You can use wildcards. Object type. Valid values are: Administrator, Application, FarmConfiguration, Folder, LoadEvaluator, Policy, and ServerConfiguration. You can use wildcards.

-Value -MatchValue

New property value. Original property value to match before overriding the setting with the new value. If the value does not match, the override is skipped. If this option is omitted, the override always occurs.

-ObjectName object-name Object name. For example, the following cmdlet specifies a CPU priority level of "high" for migrated applications in the new farm. AddXASettingOverride CpuPriorityLevel High The following cmdlet changes the CommandLineExecutable property value to C:\Program Files\Test\Test.exe when its current value is C:\ProgramFiles (x86)\Test\Test.exe. Add-XASettingOverride -PropertyName CommandLineExecutable -ObjectType Application -Value "C:\Program Files\Test\Test.exe" -MatchValue "C:\Program Files (x86)\Test\Test.exe"

Get-XALegacySettingName
Lists the settings you can use with the Add-XASettingOverride cmdlet. You can specify the following options:

Option -PropertyName property-name -ObjectType object-type

Description Property name. You can use wildcards. Object type. Valid values are: Administrator, Application, FarmConfiguration, Folder, LoadEvaluator, Policy, and ServerConfiguration. You can use wildcards.

150

Cmdlet Reference For example, the following cmdlet gets a list of valid settings that contain "LicenseServer" in the property name. Get-XALegacySettingName *LicenseServer* The following cmdlet gets a list of valid settings for object types that start with "Server" and that contain "LicenseServer" in the property name. Get-XALegacySettingName *LicenseServer* -ObjectType Server*

Get-XAMigrationObjectCount
Displays counts of objects in the source and new farms. Use the -ImportOnly option to generate the differences from an existing snapshot.

Get-XAMigrationOption
Lists migration options (that is, migration options previously specified with Set-XAMigrationOption cmdlets).

Get-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Lists server-to-worker-group mappings (that is, mappings previously specified with Add-XAServerMapping cmdlets).

Get-XASettingOverride
Lists setting overrides (that is, object property values previously specified with AddXASettingOverride cmdlets).

Remove-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Removes a server-to-worker-group mapping (that is, a mapping previously specified with an Add-XAServerMapping cmdlet).

Remove-XASettingOverride
Removes a setting override (that is, an object property value previously specified with an Add-XASettingOverride cmdlet). 151

Cmdlet Reference

Set-XAMigrationOption
Sets migration options. Option -RemoteServerName name Description Name of the server in the source farm from which objects will be exported. This value is used if you do not specify the -RemoteServerName option in the Start-XAMigration cmdlet, or a server in the source farm when using the graphical interface. If you do not specify the -RemoteServerName option in the Start-XAMigration or Set-XAMigrationOption cmdlet, or if you did not specify a server name in the source farm using the graphical interface, the migration ends. If you change the source server, be sure to update any previously-configured custom migration options and worker group mappings that refer to objects or locations in the source farm, if needed. -DataFolderPath path Path to the folder where exported data from the source farm is placed. If the folder does not exist, the Migration Center will attempt to create it. If you do not specify this option, exported data is moved to the Data folder located under the Migration Center installation files. -ObjectType object-type Object type. This option is used with the Include and Exclude options, which specify object names. Valid values are: Administrator, Application, FarmConfiguration, Folder, LoadEvaluator, Policy, and ServerConfiguration. If you exclude folder objects from the migration, application folders that contain applications will be migrated, in order to preserve the structure and prevent duplication. However, server folders and application folders that do not contain applications will not be migrated. -Include object-name Object names to include in the migration. This option is used with the ObjectType option. Separate multiple object names with commas. You can use wildcards. Object names to exclude from the migration. This option is used with the ObjectType option. Separate multiple object names with commas. You can use wildcards. Provides an alternative to using the -Exclude * option to exclude all objects specified with the -ObjectType option from the migration.

-Exclude object-name

-Enabled $false | $true

152

Cmdlet Reference 32-bit application to be migrated. The path for this application will be converted from \Program Files\ to \Program Files (x86)\. Separate multiple application names with commas. You can use wildcards. For example, the following cmdlet uses the -ObjectType and -Exclude options to exclude applications named "A1" and "A2" from the migration. Set-XAMigrationOption ObjectType Application Exclude A1, A2 The following cmdlet uses the -ObjectType, -Include, and -Exclude options to include all applications with a name containing "Microsoft" except "Office." Set-XAMigrationOption ObjectType Application Include *Microsoft* Exclude *Office* The following cmdlet uses the -ObjectType and -Enabled options to disable migration of all applications. Set-XAMigrationOption ObjectType Application Enabled $false The following cmdlet uses the -X86ApplicationList option to migrate the 32-bit applications app1 and app2, plus all 32-bit applications with names containing "office;" the paths for these applications will be converted to \Program Files (x86)\. Set-XAMigrationOption -X86ApplicationList app1, app2, *office* -X86ApplicationList application

Start-XAMigration
Starts a migration or migration preview. You can specify the following options: Option -RemoteServerName name Description Name of the server in the source farm from which objects will be exported. If you do not specify this option, but you specified a -RemoteServerName option in the Set-XAMigrationOption cmdlet, or a server in the source farm when using the graphical interface, that name is used. If you do not specify the -RemoteServerName option in the Start-XAMigration or Set-XAMigrationOption cmdlet, or if you did not specify a server name in the source farm using the graphical interface, the migration ends. If you change the source server, be sure to update any previously-configured custom migration options and worker group mappings that refer to objects or locations in the source farm, if needed. 153

Cmdlet Reference -PendingReportOnly Generates records that indicate which objects will be migrated and which values will be changed, but does not actually perform the migration. Use this option to preview a migration. This option provides more detail than the standard PowerShell -WhatIf option. -ExportOnly Exports objects from the source farm to a file, but does not import them to the new farm. This option is generally used only during an indirect migration; see Indirect Migrations and Advanced Cmdlets. -ImportOnly Imports objects to the new farm. This option is generally used only during an indirect migration; see Indirect Migrations and Advanced Cmdlets.

154

Post-migration Tasks
After a migration completes, check the log to confirm success. Items that do not migrate successfully generate descriptive log entries, such as Skipped invalid File type <file-type>. To view the log:
q

From the graphical interface, select View Log. From the command-line interface, look in the Data folder under c:\Users\user\AppData\Local\Citrix\Citrix.XenApp.Migration (or an alternate location you specified before the migration with the -SetXAMigrationOption cmdlet)

Note: In command-line displays and the log, the Policy object refers to IMA policies configured in a XenApp 5 source farm. The Group Policy object refers to policies configured using XenApp Management (AppCenter or Delivery Services Console) in a XenApp 6.x farm. After you confirm that the migration completed successfully:
q

Associate servers or OUs with worker groups. Create load evaluator policies. Create zone policies. Configure printer settings. Initiate Configuration Logging in the new farm. Copy Health Monitoring test executables to the new farm and configure Health Monitoring settings. Optionally, add new servers in the old server folder hierarchy to preserve delegated permissions. After migrating a 32-bit XenApp 5 farm, rebuild profiled applications, to enable streamed-to-server applications to launch.

155

Indirect Migrations and Advanced Cmdlets


Indirect Migrations
Important: Indirect migrations to XenApp 6.5 from previous XenApp versions are not supported. Citrix recommends performing the migration entirely from a server in the new XenApp farm (a direct migration). However, if the source farm and new farm cannot communicate, perhaps because they are in different domains that do not have a trust relationship, you can perform an indirect migration. In an indirect migration, you run the Migration Center from a server in the source farm to export settings, then import the settings using the Migration Center on a server in the new farm. In this case, you must install the Migration Center on a server in the source farm. You must use the command-line interface for an indirect migration. 1. On a server in the source farm: a. Complete the requirements for the source farm, as described in Requirements and Installation. Additionally:
q

Ensure the IMA service is running (for XenApp 6.0 source farms, the XACOM service must also be running). You must have write access to the folder where the exported data from the source farm is placed. Set the PowerShell execution policy to AllSigned (Set-ExecutionPolicy AllSigned) or above.

Install the required software (.NET Framework 3.5 SP1, MSI 3.0, and PowerShell 2.0). b. Install the Migration Center from the XenApp 6.5 media. From the Administration\Delivery Services Console\setup folder:
q q

Double-click Citrix.XenApp.Migration.Install_x64.msi to install the Migration Center on a 64-bit computer.

Double-click Citrix.XenApp.Migration.Install_x86.msi to install the Migration Center on a 32-bit computer. c. From the Start menu, select All Programs > Citrix > XenApp Migration > Windows PowerShell with Citrix XenApp Migration Module. (Select Citrix XenApp Migration Module x86 on a 32-bit server.)
q

d. Build a file containing server mappings (if you are migrating a XenApp 5 farm), migration options, and property value overrides, as described in Migrating XenApp Using the Command Line Interface.

156

Indirect Migrations and Advanced Cmdlets e. Export settings with a Start-XAMigration -ExportOnly cmdlet. The output is a series of XML files. 2. Copy the XML files to the server in the new farm, replacing the files on that server. This includes the file containing server mappings, migration options, and property value overrides. 3. From a server in the new farm, launch the Migration Center, and import the settings with a Start-XAMigration -ImportOnly cmdlet or one of the advanced import cmdlets.

Advanced Import Cmdlets


The Start-XAMigration cmdlet is intended for scripted, unattended migrations. For interactive testing, the Migration Center includes additional object-specific import cmdlets. These cmdlets offer alternatives to using the ImportOnly option with the Start-XAMigration cmdlet and the -ObjectType and -Include options with the Set-XAMigrationOption cmdlet. You can also use these cmdlets during indirect migrations. These cmdlets use the configured server mappings (when migrating a XenApp 5 farm), migration options, and object property value overrides. For complete PowerShell syntax, type Get-Help cmdlet.
q

Import-XAAdministrator Import-XAApplication Import-XAFarmConfiguration Import-XAFolder Import-XALoadBalancingPolicy * Import-XALoadEvaluator Import-XAPolicy Import-XAServerConfiguration Import-XAWorkerGroup *

* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm.

Advanced XALegacy Cmdlets


Using the advanced XALegacy cmdlets can be helpful if an object did not migrate as expected. The Get-XALegacy* cmdlets connect to the legacy farm and read the settings for an object in the legacy farm. You can use the Convert-XALegacyObject, New-XALegacyConnection, and Remove-XALegacyConnection cmdlets when creating a custom migration script that does not use the Import-XA* or Start-XAMigration cmdlets.

157

Indirect Migrations and Advanced Cmdlets For complete PowerShell syntax, type Get-Help cmdlet.
q

Get-XALegacyAdministrator Get-XALegacyApplication Get-XALegacyFarmConfiguration Get-XALegacyFolder Get-XALegacyHmrTest Get-XALegacyLoadBalancingPolicy * Get-XALegacyLoadEvaluator Get-XALegacyPolicy Get-XALegacyPolicyConfiguration Get-XALegacyPolicyFilter Get-XALegacyServer Get-XALegacyServerConfiguration Get-XALegacySessionPrinter Get-XALegacyWorkerGroup * Convert-XALegacyObject New-XALegacyConnection Remove-XALegacyConnection

* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm. These advanced cmdlets include objects that cannot be migrated alone (for example, session printers that are inside a user policy, and HMR tests that are inside farm or server settings). This greater granularity may be helpful when troubleshooting migration, because these objects are more complex, with multiple sets of properties.

158

Managing and Administering Your XenApp Environment


The management and administration of your Citrix XenApp environment consists of performing tasks in the console to administer servers, manage administrators, and publish resources. You can also administer and modify your environment through policy-based settings. Management Console and Other Tools Describes the Citrix tool set for managing servers, farms, published resources, and connections. You can launch all tools by accessing the Citrix program group on the Start menu. How to create, modify, and delete farm administrators. How to implement the Windows Desktop Experience, includng a Windows 7 look and feel to desktops. How to control the XenApp experience through specific policies and policy settings. Manage, define, monitor, and optimize the XenApp end user sessions. Maintain a secure XenApp environment. Describes XenApp farm maintenance tasks, such as monitoring CPU usage, updating the License Server settings, using Worker Groups, and so on. Provides XenApp printing concepts and how to implement printing in your XenApp environment.

Managing Citrix Administrators Delivering XenApp to Software Service Subscribers Working with Citrix Policies Citrix Policies Reference Managing Session Environments and Connections Securing Server Farms Maintaining Server Farms

Understanding XenApp Printing Configuring and Maintaining XenApp Printing Manage Power and Capacity

Describes XenApp Power and Capacity Management to help reduce power consumption and manage XenApp server capacity by dynamically scaling up or scaling down the number of online XenApp servers. How to set up, manage, and monitor server and published application loads in a server farm so that users can run the published applications they need quickly and efficiently. Describes a broad set of technologies designed to provide a high-definition user experience Describes the XenApp server utilities, which provide an alternative method to using the console for maintaining and configuring servers and farms.

Manage Loads

Configure HDX XenApp Server Utilities Reference

159

Manage Performance Counters Reference Describes how to use the Window Performance Monitor to observe performance counters associated with sessions, networking, and security.

160

Management Consoles and Other Tools


Citrix provides a comprehensive set of tools for managing servers, farms, published resources, and connections. You can launch all tools by accessing the Citrix program group on the Start menu.

Citrix AppCenter
The AppCenter (formerly Delivery Services Console) is a tool that snaps into the Microsoft Management Console (MMC) and enables you to perform a number of management functions. For XenApp, you can set up and monitor servers, server farms, published resources, and sessions. Configure application access (both through the Web Interface and the Citrix Online Plug-in) and set up policies and printers. In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your farms, view hotfix information for your Citrix products, and track administrative changes. My Views are configurable displays that give you quick access to items you must examine regularly or items in different parts of the AppCenter tree that you want to group together. For example, create a My View display to monitor your preferred performance data for two sets of servers in different server farms. The performance-related information in a My View display is refreshed at regular intervals. With Hotfix Management, check which hotfixes are applicable to your Citrix products, search for particular updates on your system, and identify servers where up-to-date hotfixes must be applied. In the left pane of the AppCenter, select Citrix Resources > Configuration Tools > Hotfix Management. If your deployment includes multiple XenApp farms (such as one farm comprising servers running the latest version of XenApp, and another farm comprising servers running a legacy version of XenApp), you can use one MMC console that has separate AppCenter snap-ins to manage each farm.

License Administration Console


Use this console to manage and track Citrix software licenses. For more information about licensing, see the License Administration console Help and Getting Started with Citrix Licensing in Licensing Your Product.

Citrix SSL Relay Configuration Tool


Use this tool to secure communication between a server running the Web Interface and your farm.

161

XenApp 6 for Windows 2008 R2

Shadow Taskbar
Shadowing allows users to view and control other users sessions remotely. Use the Shadow Taskbar to shadow sessions and to switch among multiple shadowed sessions. You can also shadow ICA sessions with the AppCenter.

SpeedScreen Latency Reduction Manager


Use this tool to configure local text echo and other features that improve the user experience on slow networks.

162

Management Consoles and Other Tools


Citrix provides a comprehensive set of tools for managing servers, farms, published resources, and connections. You can launch all tools by accessing the Citrix program group on the Start menu.

Citrix AppCenter
The AppCenter (formerly Delivery Services Console) is a tool that snaps into the Microsoft Management Console (MMC) and enables you to perform a number of management functions. For XenApp, you can set up and monitor servers, server farms, published resources, and sessions. Configure application access (both through the Web Interface and the Citrix Online Plug-in) and set up policies and printers. In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your farms, view hotfix information for your Citrix products, and track administrative changes. My Views are configurable displays that give you quick access to items you must examine regularly or items in different parts of the AppCenter tree that you want to group together. For example, create a My View display to monitor your preferred performance data for two sets of servers in different server farms. The performance-related information in a My View display is refreshed at regular intervals. With Hotfix Management, check which hotfixes are applicable to your Citrix products, search for particular updates on your system, and identify servers where up-to-date hotfixes must be applied. In the left pane of the AppCenter, select Citrix Resources > Configuration Tools > Hotfix Management. If your deployment includes multiple XenApp farms (such as one farm comprising servers running the latest version of XenApp, and another farm comprising servers running a legacy version of XenApp), you can use one MMC console that has separate AppCenter snap-ins to manage each farm.

License Administration Console


Use this console to manage and track Citrix software licenses. For more information about licensing, see the License Administration console Help and Getting Started with Citrix Licensing in Licensing Your Product.

Citrix SSL Relay Configuration Tool


Use this tool to secure communication between a server running the Web Interface and your farm.

163

Management Consoles and Other Tools

Shadow Taskbar
Shadowing allows users to view and control other users sessions remotely. Use the Shadow Taskbar to shadow sessions and to switch among multiple shadowed sessions. You can also shadow ICA sessions with the AppCenter.

SpeedScreen Latency Reduction Manager


Use this tool to configure local text echo and other features that improve the user experience on slow networks.

164

To start the AppCenter and discover servers


When you install the first server in a new server farm, you provide credentials for a full authority Citrix administrator. This account has the authority to manage and administer all areas of farm management. If you are logging on to the AppCenter for the first time, use this account to log on and to add other individuals to the Citrix administrators group. Important: Citrix recommends that you use a domain account to run the AppCenter. You can use your local administrator account, but the user name and password should be the same for all local administrator accounts for all servers in your farms. Citrix supports using the AppCenter only with this version of Citrix XenApp. Using the AppCenter with servers running a previous version of XenApp is not supported. Likewise, using a previous version of the console with this version of XenApp is not supported. Click Start > All Programs > Administrative Tools > Citrix > Management Consoles > Citrix AppCenter. The first time you open the AppCenter you are automatically prompted to start the discovery process: you select the components you want, configure the discovery process, and find the items to manage. Discovery is an important operation that checks for items (such as devices or applications) that were added to or removed from your XenApp environment. Appropriate changes then appear in the AppCenter tree. After this, run the discovery process only if you want to refresh the view of your deployment. The AppCenter tree refreshes automatically each time you add, remove, or modify items in your deployment. When using discovery to connect to your XenApp deployment, you must specify the name or IP address of at least one server in each farm that you want to manage. When discovery is complete, the AppCenter tree displays the items that you specified. You can configure discovery only for some components. The configuration process can vary among components. The Configure and run discovery task appears in the Actions pane only for configurable components; otherwise, only the Run discovery task is available. 1. In the AppCenter tree, select Citrix Resources or the product or component whose objects you want to discover. 2. Click Configure and run discovery, or to run discovery without any configuration, click Run discovery. 3. When discovering XenApp deployments, specify the name or IP address of at least one server running XenApp in each farm that you want to manage.

165

To view zones
Zones can be viewed and configured in the console. For information on configuring zones, see To configure zones and back-up data collectors. 1. From the AppCenter, in the left pane, expand the Zones node. 2. Under Zones, select a zone. The results pane displays the servers in the chosen zone.

166

To refresh user data automatically


Refreshing user data automatically is disabled by default. You can control the frequency of automatic updates to server, server folder, and published application information on the Citrix AppCenter. The auto-refresh settings apply only to the AppCenter you are running and not other instances of the AppCenter on your network. Note: Do not enable this feature if you have many sessions, because it can affect performance. 1. In the left pane, select one of these nodes (depending on what type of user data you want to refresh automatically):
q

The farm for which you want to refresh the user data automatically The server for which you want to refresh the user data automatically

q The application for which you want to refresh the user data automatically 2. In the Actions pane or from the Other Tasks section (depending on the node that you selected), click Refresh user data and choose one of these options:

Automatically refresh user data for servers. Selecting this option enables automatic refreshing of each servers configuration and connection information. After selection, the associated Refresh rate field becomes available. Automatically refresh user data for farms and server folders. Selecting this option enables automatic refreshing of the folder organization for farm and server. After selection, the associated Refresh rate field becomes available.

Automatically refresh user data for applications. Selecting this option enables automatic refreshing of each published applications configuration and connection information. After selection, the associated Refresh rate field becomes available. 3. In the Refresh rate (seconds) box, select the number of seconds between each update (10, 30, 60, or 90).
q

167

Managing Citrix Administrators


Citrix administrators are individuals tasked with managing server farms.

To create a Citrix administrator


You can make any member of a Windows or Novell Domain Services for Windows account authority a Citrix administrator. 1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix AppCenter. 2. In the left pane, expand Citrix Resources > XenApp and select a farm. 3. From the Actions pane on the right, click Add administrator. 4. Click Add and select the configured user or user group account to designate as a Citrix administrator. 5. On the Privileges page, select the authority level you want to grant the administrator account. 6. If you are creating a custom administrator account, in the Tasks pane, select the tasks you want to delegate to the custom administrator.

To modify a Citrix administrator


1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix AppCenter. 2. From the left pane, , expand Citrix Resources > XenApp and the farm, then choose the Administrators node. 3. On the Administrators tab, select the administrator whose properties you want to change. 4. On the Actions pane, click Administrator properties. 5. Choose from the following options:
q

To change an administrator's privilege level, open the Privileges page To assign or update custom permissions, open the Permissions page

168

Managing Citrix Administrators

To disable a Citrix administrator


Disable a Citrix administrator if you want to temporarily remove access for an administrator but retain the account and settings. 1. Select the administrator whose privileges you want to disable. 2. On the Actions pane, click Disable. When an administrator is disabled, the administrator icon appears in grey and an Enable task becomes available.

To re-enable a Citrix administrator


1. Select the administrator whose privileges you want to enable and then, on the Actions pane, click Enable.

To remove a Citrix administrator


Remove a Citrix administrator if you want to delete the account and settings. Only administrators with full access can disable or remove other Citrix administrator accounts. Important: If only one Citrix administrator account with full access remains on the list, you cannot remove it. 1. Select the administrator or administrators whose account you want to remove. 2. On the Actions pane, click Delete administrator.

169

Delegating Tasks to Custom Administrators


You can delegate tasks through the Citrix AppCenter by associating custom Citrix administrator accounts with permissions to perform select tasks. Citrix recommends you create Windows, Active Directory, or NDS groups to assign these permissions. When you create custom Citrix administrators, simply select the group instead of individual users. This allows you to add and remove users to these groups without reconfiguring all of the permissions. Permissions you set on nodes apply farm wide. Permissions you set on folders (applications, servers, and any folders within) apply only to the applications and servers contained within the selected folder. You cannot grant permissions to applications and servers directly. To grant permissions to applications and servers, you must first place the applications or servers in folders and then grant permissions at the folder level. Therefore, before you delegate tasks for applications and servers, make sure you group the applications and servers in folders that allow you to delegate the tasks in a meaningful way. Note: To apply the same permissions to a new folder as to its parent folder, select the Copy permissions from the parent folder option when you create the new folder.

170

Delegating Tasks to Custom Administrators

To delegate tasks to existing custom administrators


1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix AppCenter. 2. From the left pane, expand Citrix Resources > XenApp and the farm, then choose the Administrators node. 3. On the Administrators tab, select the administrator to whom you want to delegate tasks. 4. From the right pane, under Actions, click Administrator properties. 5. In the Citrix Administrator Properties dialog box, on the Privileges pane, if Custom is not selected, select it. 6. Click Permissions to view the task permissions assigned to the administrator. 7. Click on a folder in the Folders list to view additional tasks. 8. To select the tasks to which the administrator has access, select or clear the check boxes, as appropriate. 9. If you set permissions on a node or a folder that contains a subfolder, the Copy to Subfolders button becomes active. Click this button if you want to copy the permissions from the parent node or folder to the constituent folder.

Note: If you change an administrators OBDA permissions, he or she must manually rerun discovery.

To assign folder permissions


To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the farm level. To view and change permission on objects, such as printers, you must be a Citrix administrator with full access to view and change object permissions. 1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix AppCenter. 2. From the left pane, select the folder under the farm to which you want to grant access. 3. From the Actions pane, select Other Tasks, then Permissions. The resulting dialog box lists the administrators who currently have access to the selected folder. 4. To give access to an administrator that is not on the Administrators list, click Add and then click the check box to allow access to the folder. If the administrator to whom you want to give access does not appear in the Add Access to folder dialog box, click Add to create the administrator.

171

Delegating Tasks to Custom Administrators

To assign or change object permissions


To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the farm level. To view and change permission on objects, such as printers, you must be a Citrix administrator with full access to view and change object permissions. 1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix AppCenter. 2. From the left pane, select the farm to whose objects you want to grant access. 3. From the right pane, under Actions, choose Other Tasks, then Set permission on objects. 4. Select the object whose permissions you want to change and click Permissions. Under Administrators, you can see the administrators who have access to tasks related to the object. 5. From the Administrators list select the administrator to whom you want to assign additional or change existing folder permissions. If the administrator you want is not on the list, click Add and select the administrator. If the administrator you want is not a custom administrator, click Edit and change the administrator's privilege level to Custom. This allows you to change the administrator's permissions. 6. With the administrator selected, use the check boxes to change specific permissions in the Tasks pane.

If the folder contains subfolders, the following options become available:


q

Choose Copy the permissions of this administrator for this folder to its subfolders to copy newly configured permissions to all folders nested in the selected folder for the custom administrator. Choose Copy the permissions of all administrators for this folder to its subfolders to copy the newly configured permissions of each custom administrator who has access to the selected folder to the folders nested within it. Note: If you change the permissions later in the top level folder, the changes are not automatically copied to the nested folders. When you make changes to top level folders, use either the Copy the permissions of this administrator for this folder to its subfolders or the Copy the permissions of all administrators for this folder to its subfolders function to copy the permissions again.

172

Delivering XenApp to Software Services Subscribers


XenApp enables service providers to deliver hosted desktops and applications through the Infrastructure Setup and Enhanced Desktop Experience features. Additionally, images displayed through hosted desktops and applications are optimized for low-bandwidth connections. The PowerShell scripts used to install and configure these features are located at %Program Files (x86)%\Citrix\App Delivery Setup Tools.

Infrastructure Setup
The Infrastructure Setup feature enables service providers to deploy XenApp farms quickly, add tenants, and add servers as needed to manage farm capacity. To do this, the server administrator or user with an administrator account on the primary server can execute PowerShell scripts to install and configure a XenApp farm consisting of the following components:
q

Data collector and backup data collector Web Interface configured to use Access Gateway

The following components must be present in your environment and configured prior to executing the scripts:
q

Active Directory Database server running Microsoft SQL Server 2008 or later, or Microsoft SQL Server Express 2008 or later Citrix Licensing server Access Gateway Servers running Windows Server 2008 R2, joined to the domain Windows PowerShell Remoting enabled on the servers, to facilitate remote configuration Firewall

173

Delivering XenApp to Software Services Subscribers

Enhanced Desktop Experience


The Enhanced Desktop Experience feature enables service providers to deploy hosted desktops with the Windows 7 look and feel and to control desktop customization by users through Group Policy. Installed as the Windows Desktop Experience Integration component, this feature is selected by default when you choose to install the XenApp server role. The installation sequence performs the following tasks:
q

Adds the Desktop Experience and XPS Viewer features to the Windows server configuration Moves the Citrix folder items in the Start menu to the Administrative Tools folder (including the Citrix AppCenter) Creates a new Windows Theme file and sets the default wallpaper Starts the Windows Themes service and configures it to start automatically

Usage Reporting
Premium Edition service providers have the option to use Citrix EdgeSight to monitor XenApp user sessions and application usage, and generate reports. More information on using EdgeSight for tenant usage reporting is included in the Citrix Service Provider Toolkit, available from the Citrix Web site.

Optimized Image Display


Extra color compression improves the display of images based on a bandwidth threshold being reached. This feature provides a flexible means for Citrix Service Providers to optimize image display according to users' connections. If the client connection bandwidth falls below the specified threshold, such as with low-bandwidth WAN connections, extra color compression is applied. When this occurs, images appear clearer and session bandwidth is minimized, compared to turning off compression entirely. For high-bandwidth connections, such as in a LAN environment, this compression is not applied as such connections exceed the bandwidth threshold. To configure extra color compression, create or edit a User policy and enable the Extra Color Compression setting. Add the Extra Color Compression Threshold setting and enter the value, in kilobits per second, below which compression is applied.

Additional Information for Service Providers


For more information about delivering hosted desktops, refer to the following resources: 174

Delivering XenApp to Software Services Subscribers


q

Citrix Cloud App Delivery Setup Tools Administration Guide provides information about the Infrastructure Setup and Enhanced Desktop Experience features, including requirements and script usage. This PDF document is available for download through the Citrix Service Provider CDN Web site. Script help provides detailed information about each script and its parameters within the PowerShell command window. Help is available by typing Get-Help .\scriptname.ps1 at the PowerShell command line. The Citrix Service Provider CDN Web site (http://community.citrix.com/p/csp) provides information about the Citrix Service Provider program, access to technical resources, and access to the Citrix Service Provider community.

175

To enable Windows 7 look and feel and control desktop customization


After the Windows Desktop Experience Integration role is installed through the Server Role Manager, you can deploy hosted desktops with the Windows 7 look and feel and control desktop customization through Group Policy. To perform this task, you need to run the New-CtxManagedDesktopGPO.ps1 script located at %Program Files (x86)%\Citrix\App Delivery Setup Tools. 1. Run the New-CtxManagedDesktopGPO.ps1 script at the PowerShell command line. This script creates the following GPOs:
q

CtxStartMenuTaskbarUser enables the Windows 7 look and feel for published desktops. It also changes the pinned shortcuts on the Taskbar and configures the user's Start menu to match the Windows 7 environment. This GPO includes a script that executes when a user logs on to the server for the first time. To ensure the script executes correctly, the PowerShell execution policy on the server must be set to AllSigned. CtxPersonalizableUser configures the user account that is accessing the XenApp server. It configures Windows policies to limit the available Control Panel applets and restricts users from installing programs, viewing properties, scheduling tasks, or shutting down the server. CtxRestrictedUser includes most of the policies from the CtxPersonalizableUser GPO. Additionally, this GPO configures the Desktop wallpaper policy to prevent users from personalizing their desktops and prevents users from modifying settings for the Start menu and Taskbar.

CtxRestrictedComputer configures certain restrictions on the XenApp servers allocated to the tenant. This GPO restricts users from accessing Windows Update or removable server drives. 2. In the Active Directory Users and Computers console, link the User GPOs to the OU containing the tenant's user accounts.
q

3. Link the CtxRestrictedComputer GPO to the OU containing the XenApp servers allocated to the tenant. 4. In the Group Policy Management Editor, for each User GPO, add the user accounts to the GPO's scope. 5. Add the XenApp servers to the scope of the CtxRestrictedComputer GPO.

When configuring user sessions, apply either the CtxPersonalizableUser or the CtxRestrictedUser GPO to the user account. Some Microsoft hotfixes may be required for all policies to function appropriately. For additional information about these GPOs, see the help included with the New-CTXManagedDesktopGPO script. 176

To enable Windows 7 look and feel and control desktop customization Important: Be aware that applying these policies is only one step in the process of delivering secure, locked-down desktops. You still need to follow your organizations security best practices for ensuring the servers, and the desktops they deliver, are protected.

177

Working with Citrix Policies


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. You can work with policies through the Group Policy Management Console in Windows or the AppCenter in XenApp (formerly the Delivery Services Console). 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 the Group Policy Management Editor


If your network environment includes Active Directory and you have the appropriate permissions to manage Group Policy, use the Group Policy Management Editor to create policies for the XenApp servers in your environment. The settings you configure affect the GPOs you specify through the Group Policy Management Console.

Using the AppCenter


If your environment includes a different directory service (such as Novell Domain Services for Windows) or you are a Citrix administrator without permission to manage Group Policy, use the AppCenter to create policies for your farm. The settings you configure are stored in a farm GPO in the data store.

Policy Processing and Precedence


Group Policy settings are processed in the following order: 1. Local GPO 2. XenApp farm GPO (stored in the farm data store) 3. Site-level GPOs 4. Domain-level GPOs 5. Organizational Units

178

Working with Citrix Policies However, in the event of a conflict, policy settings that are processed last can overwrite those that are processed earlier. This means that policy settings take precedence in the following order: 1. Organizational Units 2. Domain-level GPOs 3. Site-level GPOs 4. XenApp farm GPO (stored in the farm data store) 5. Local GPO For example, a Citrix administrator creates a policy (Policy A) through the AppCenter that enables client file redirection for the company's sales employees. Meanwhile, another administrator creates a policy (Policy B) through the Group Policy Management Editor that disables client file redirection for the sales employees. When the sales employees log on to the farm, Policy B is applied and Policy A is ignored. This happens because Policy B was processed at the domain level and Policy A was processed at the XenApp farm GPO level.

Active Directory Functional Levels


Citrix policies are supported for use in Active Directory environments running at the Windows 2000 domain functional level, at a minimum. To ensure Citrix policy settings are included in reports when Resultant Set of Policy is calculated, at least one domain controller running Windows Server 2003 must be present in the forest.

Workflow for Citrix Policies


The process for configuring policies is as follows: 1. Create the policy. 2. Configure policy settings. 3. Apply the policy to connections by adding filters. 4. Prioritize the policy. 5. Verify the effective policy by running the Citrix Group Policy Modeling wizard.

179

Navigating Citrix Policies and Settings


In Active Directory, policy settings are collected into two main categories: Computer Configuration and User Configuration. Computer configuration settings pertain to servers, regardless of who logs on. User configuration settings pertain to users accessing the server, regardless of where they log on. XenApp policies and settings are collected into similar categories: Computer and User. Computer policy settings pertain to XenApp servers and are applied when the server is rebooted. User policy settings pertain to user sessions and are applied for the duration of the session.

Accessing Policies and Settings


In the AppCenter console, you can access policies and settings by clicking the Policies node from the console tree and then selecting either the Computer or User tabs in the middle pane. In the Group Policy Management Editor, you can access policies and settings by clicking the Citrix Policies node under Computer Configuration or User Configuration in the tree pane. The Computer and User tabs each display a list of the policies that have been created. Beneath this list, the following tabs are displayed:
q

Summary displays the settings and filters 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:
q

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:


q

On the Settings or Filters tabs, in the Settings to show box, selecting a product version to display only the settings or filters that are supported in the selected version.

180

Navigating Citrix Policies and Settings


q

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.

181

Creating Citrix Policies


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, client 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. You can create policies using the following methods:
q

Create a new policy using the New Policy wizard Create a new policy based on the settings included in a policy template

To create a new policy with the New Policy wizard


The New Policy wizard enables you to create a new, empty policy to which you can add the settings you need. 1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane and then select the Computer or User tab.

From the Group Policy Management Editor, select the Citrix Policies node in the left pane. 2. Click New. The New Policy wizard appears.
q

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

182

Creating Citrix Policies

To create a new policy based on a template


By default, the new policy includes all the same settings as the original template. However, you can choose to accept these settings or to customize the policy according to your needs. 1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. Click the Templates tab and select the template from which you want to create the policy.
q

3. Click New Policy. The New Policy wizard appears. 4. Enter a unique name for the new policy or accept the default name that XenApp generates automatically. Note: If you enter a name that is in use by an existing policy, no policy is created. The settings you selected are retained; however, you must re-run the policy wizard. If you use the Copy-Item PowerShell cmdlet to create a policy from a template, and you specify the same name as an existing policy, the -Force switch allows you to merge the settings you selected into the existing policy. 5. Choose whether or not to customize the policy. If you choose not to customize the policy, proceed to Step 7. 6. If you choose to customize the policy, add or remove the settings you want. 7. Select and configure a filter for the new policy. 8. 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 the farm. 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.

183

Working with Citrix Policy Templates


Policy templates allow you to configure Citrix policies quickly and deploy them to your XenApp environment. Templates consist of pre-configured settings that can apply to a server or to a user session. You can use templates in the following ways:
q

As a source for creating other policies As a tool with which to compare existing policies As a method for delivering or receiving policy configurations from Citrix Support or trusted third parties

You can perform the following tasks with policy templates:


q

Create new templates using existing templates or policies Create new policies using existing templates Import and export templates Compare settings, including default values, of selected policies and templates

Templates tab
Policy templates are displayed on the Templates tab in the AppCenter console and the Group Policy Management Editor. In the AppCenter, templates for both Computer and User settings are displayed in a single list. In the Group Policy Management Editor, Computer templates are displayed when you are working with Computer policies. Likewise, User templates are displayed when you are working with User policies.

Built-in Templates
XenApp comes with the following built-in templates:
q

Citrix High Definition User Experience templates include Computer and User settings for providing high quality audio, graphics, and video to users. Citrix High Server Scalability templates include Computer and User settings for providing an optimized user experience while hosting more users per server. Citrix Optimized Bandwidth for WAN templates include Computer and User settings for providing an optimized experience to users with low bandwidth or high latency connections.

184

Working with Citrix Policy Templates


q

Citrix Security and Control templates include User settings for disabling on user devices access to peripheral devices, drive mapping, port redirection, and Flash acceleration.

You can use these templates as a model for creating new policies or templates. Built-in templates are created and updated by Citrix. You cannot modify or delete these templates. However, you can modify or delete templates that you create or import through the AppCenter or the Group Policy Management Editor.

Template Information
When selected, each template displays the following information tabs beneath the templates list:
q

Settings displays a list of all the configured settings and their values in the selected template. You can also view the default values for each setting alongside the configured values. Properties displays information such as the template creator, description, and modification date, if applicable. Prerequisites displays information pertaining to additional requirements needed for the settings in the template to be effective when applied in a policy. This tab is displayed only when a built-in template is selected.

185

Creating Policy Templates


You create templates from an existing template or an existing policy. The new template is then populated with the same settings as the original template or policy. Filters assigned to the original policy are not included in the template. Templates can include either Computer settings or User settings. You cannot include both types of settings in a template.

To create a new template based on an existing template


1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. Click the Templates tab and then select the template from which you want to create the new template.
q

3. Click New Template. The New Template wizard appears. 4. Enter a name for the template. 5. Select and configure the policy settings you want to include in the template. Remove any existing settings that should not be included. 6. Click Create. The new template appears on the Templates tab.

186

Creating Policy Templates

To create a new template based on an existing policy


1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane and then select the Computer or User tab.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. On the Policies tab, select the policy from which you want to create the template.
q

3. Click Actions and select Save as Template. The Save as Template dialog box appears. 4. Enter a name and a description for the new template. 5. Click Save. The new template appears on the Templates tab.

187

Importing and Exporting Policy Templates


Policy templates are local to the computer on which you are running the console to manage your farm. You can transfer policy configurations between environments, including other farms that you manage on the computer running the console. You transfer templates by importing or exporting them. This allows you to perform the following tasks:
q

Implement policy configurations from XenApp servers in other farms Create backups of your template files to aid recovery of policy configurations Supply policy configurations from your farm to aid Citrix Support in troubleshooting issues Implement policy configurations created by Citrix Support to resolve issues in your farm

To import a template
1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. Click the Templates tab and then click Actions > Import . The Import Template dialog box appears.
q

3. Select the template file you want to import and click Open. The imported template appears in the templates list. Note: If you import a template with the same name as an existing template, you can choose to overwrite the existing template or save the template with a different name that is generated automatically. If you are importing a template through the Group Policy Management Editor, and the template is a different type (for example, importing a Computer template while viewing User templates), a message appears, notifying you the imported template is located in the appropriate templates list.

188

Importing and Exporting Policy Templates

To export a template
1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. Click the Templates tab and then select the template you want to export.
q

3. Click Actions > Export. The Export Template dialog box appears. 4. Select the location where you want to save the template and click Save. A .gpt file is created in the location you specified.

189

Comparing Policies and Templates


In some cases, you might need to compare the settings in a policy or template with those in other policies or templates. For example, you might need to verify setting values to ensure compliance with best practices for your environment. You can display policy templates in two views: List View and Compare View. List View displays policy templates in a list similar to that shown for Computer or User policies. Compare View displays the settings of selected policies and templates in a side-by-side view. You can access these views by clicking the List View or Compare View buttons on the right side of the console, just above the template list.

To compare policies and templates


1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane.

From the Group Policy Management Editor, expand the Computer Configuration or User Configuration nodes, expand the Policies node, and then select Citrix Policies. 2. Click the Templates tab and then click the Compare View icon. The Compare Templates and Policies dialog box appears.
q

3. Select the policies or templates you want to include. To include default values in the comparison, select the Compare to setting defaults checkbox. 4. Click Compare. The configured settings for the selected items are displayed in columns. Default values, if selected, are displayed in the second column by default. Note: To change the position of the Configured Settings and Defaults columns, drag and drop the columns to the positions you want. 5. To modify the comparison, click the Configured Settings arrow and select Add/Remove Columns. 6. To compare all available settings for the selected items, click the Configured Settings arrow and select Show All Settings.

To view additional information about policies or templates included in the comparison, select the column header of the policy or template. For templates, the properties and prerequisites appear in tabs beneath the Compare View. For policies, the properties and filters appear.

190

Configuring Policy Settings


Policies contain settings that are applied to connections when the policy is enforced. 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:
q

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 lower-ranked 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, Computer policy setting changes go into effect when the server reboots. User policy setting changes go into effect the next time the relevant users establish a connection. Policy setting changes can also take effect when XenApp re-evaluates policies at 90 minute intervals.

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 enforced. This occurs regardless of the value that was entered before selecting Use default value. For example, for the Lossy compression level setting, the default value is Medium. When you add this setting to a policy and select Use default value, medium compression is always applied to images when the policy is enforced, even if the setting was previously configured as High or None. Default values for all Citrix policy settings are located in the Policy Settings Reference.

191

Configuring Policy Settings

Best Practices for Policy Settings


Citrix recommends the following when configuring policy settings:
q

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.

192

To add settings to a policy


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. You can add settings to policies using one of the following methods:
q

Using the New Policy wizard, when creating a new policy Using the Settings tab of the Edit Policy dialog box, when modifying an existing policy Using the Settings tab of the AppCenter or Group Policy Management Editor (located beneath the policies list), when modifying an existing policy

Note: When you modify a policy using the Settings tab on the console, the changes you make are applied to the policy immediately after you configure the selected setting. However, when you modify a policy using the Edit Policy dialog box, changes you make are applied to the policy only after you click OK on the Edit Policy dialog box. 1. Select a setting you want to add to the policy and click Add. The Add Setting dialog box appears, displaying the setting's default value, if applicable. You can accept or change this value according to your policy requirements. If no default value is present, enter the appropriate value for your environment. 2. Click OK to add the setting to the policy. The configured setting appears on the Settings tab of the console in the Active Settings view.

193

Applying Citrix Policies


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 Computer policy or a User policy. The following table lists the available filters:

Name

Filter Description Applies a policy based on the access control conditions through which a client is connecting. Applies a policy based on whether or not a user session was launched through Citrix Branch Repeater. Applies a policy based on the IP address of the user device used to connect to the session. IPv4 Examples:
q

Policy Scope User policies only User policies only User policies only

s Control

h Repeater IP Address

12.0.0.0 12.0.0.* 12.0.0.1-12.0.0.70 12.0.0.1/24

IPv6 Examples:
q

2001:0db8:3c4d:0015:0:0:abcd:ef12 2001:0db8:3c4d:0015::/54 User policies only

Name

Applies a policy based on the name of the user device from which the session is connected. Applies a policy based on the organizational unit (OU) of the desktop hosting the session.

izational

Computer policies User policies

Note: The Organizational Unit filter is applicable o context of the XenApp farm and is configurable on AppCenter console. If you manage Citrix policies t Group Policy Management Editor, this filter is not Applies a policy based on the user or group membership of the user connecting to the session. User policies only

or Group

194

Applying Citrix Policies Applies a policy based on the worker group membership of the server hosting the session.

er Group

Computer policies

User policies When a user logs on, XenApp identifies the policies that match the filters for the connection. XenApp 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. XenApp recalculates the policy every 90 minutes after the user logs on to the farm.
q

Any policy setting that is disabled takes precedence over a lower-ranked setting that is enabled. Policy settings that are not configured are ignored.

Unfiltered Policies
By default, XenApp provides Unfiltered policies for Computer and User policy settings. The settings added to this policy apply to all connections. If you use Active Directory in your environment and use the Group Policy Management Editor to manage Citrix policies, settings you add to the Unfiltered policy are applied to all farm servers 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 farm, the settings in the Unfiltered policy are automatically applied to the session because the user is a member of the Sales-US GPO. If you use the AppCenter console to manage Citrix policies, settings you add to the Unfiltered policy are applied to all servers and connections in the farm.

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:
q

Filter A is a User filter that specifies the Sales group and the mode is set to Allow.

195

Applying Citrix Policies


q

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 farm, 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:
q

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 12.0.0.* (the corporate network) and the mode is set to Allow.

When the Sales manager logs on to the farm from the office, the policy is applied because the connection satisfies both filters. Policy 3 includes the following filters:
q

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 farm from the office, the policy is not applied because the connection does not satisfy Filter F.

196

To add filters to a policy


To apply a policy according to specific criteria, you must add at least one filter. If no filter is added, the policy applies to all connections. You can add filters using one of the following methods:
q

Using the New Policy wizard, when creating a new policy Using the Filters tab of the Edit Policy dialog box, when modifying an existing policy Using the Filters tab of the AppCenter or Group Policy Management Editor (located beneath the policies list), when modifying an existing policy

Note: When you modify filters using the Filters tab on the console, the changes you make are applied to the policy immediately after you configure the selected filter. However, when you modify filters using the Edit Policy dialog box, changes you make are applied to the policy only after you click OK on the Edit Policy dialog box. 1. Select the filter you want to apply and click Add. 2. From the New Filter dialog box, click Add to add the criteria you want XenApp to evaluate when determining if the policy should be applied. 3. Select the mode for the filter. 4. Leave the Enable this filter element checkbox selected. This allows the filter criteria to be considered when the policy is evaluated. 5. Click OK to save the filter criteria. 6. Click OK to add the filter to the policy.

Depending on the type of policy created, the policy is applied the next time the server is rebooted (in the case of a Computer policy) or the next time users log on to the server (in the case of a User policy). To force an immediate update, open a Command Prompt window and type gpupdate /force.

197

Managing Multiple Policies


You can use multiple policies to meet users needs based on their job functions, geographic locations, or connection types. For example, compliance with security protocols may require you to place restrictions on user groups who work regularly with highly sensitive data. You can create a policy that requires a high level of encryption for sessions and 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 in the event of a conflict. Note: When managing policies through the AppCenter, be aware that making frequent changes can adversely impact server performance. When you modify a policy, the XenApp server synchronizes its copy of the farm Group Policy Object (GPO) with the data store, propagating the change to other servers in the farm. For example, if you make changes to five policies, the server synchronizes the farm GPO five times. In a large farm with multiple policies, this frequent synchronization can result in delayed server responses to user requests. To ensure server performance is not impacted by needed policy changes, arrange to make these changes during off-peak usage periods. In general, policies override similar settings configured for the entire server farm, for specific servers, or on the client. The exception to this principle is security. The highest encryption setting in your environment, including the operating system and the most restrictive shadowing setting, always overrides other settings and policies. Citrix policies interact with policies you set in your operating system. In a XenApp environment, Citrix settings override the same settings configured in an Active Directory policy or using Remote Desktop Session Host Configuration. This includes settings that are related to typical Remote Desktop Protocol (RDP) client connection settings such as Desktop wallpaper, Menu animation, and View window contents while dragging. For some policy settings, such as Secure ICA, the settings in policies must match the settings in the operating system. If a higher priority encryption level is set elsewhere, the Secure ICA policy settings that you specify in the policy or when you are publishing an application can be overridden. For example, the encryption settings that you specify when you are publishing an application should be at the same level as the encryption settings you specified throughout your environment.

198

Prioritizing Policies and Creating Exceptions


Prioritizing policies allows you to define the precedence of policies when they contain conflicting settings. The process XenApp 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. XenApp 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 whether the setting is disabled or enabled. Any disabled setting overrides a lower-ranked setting that is enabled. When you create policies for groups of users, client devices, or servers, you may find that some members of the group require exceptions to some policy settings. You can create exceptions by:
q

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 XenApp to apply the policy to connections that do not match the filter criteria. For example, a policy contains the following filters:
q

Filter A is a Client IP address filter that specifies the range 12.0.0.* 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.

199

Prioritizing Policies and Creating Exceptions

To change the priority of a policy


1. From the console tree, choose to view Citrix Computer Policies or Citrix User Policies. 2. From the middle pane, select the policy you want to prioritize. 3. Click Increase Priority or Decrease Priority as appropriate until the policy has the preferred rank.

200

Determining Which Policies Apply to a Connection


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:
q

Use the Citrix 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 server.

You can launch both tools from the Group Policy Management console in Windows. If your XenApp environment does not include Active Directory, you can launch the Citrix Group Policy Modeling Wizard from the Actions pane of the AppCenter.

Using the Citrix 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 server as a domain user and your environment includes Active Directory, the wizard calculates the resultant set of policy by including settings from Active Directory Group Policy Objects (GPOs). If you run the wizard from the AppCenter, the farm GPO residing on the server is included in this calculation as well. However, if you are logged on to the server as a local user and run the wizard from the AppCenter, the wizard calculates the Resultant Set of Policy using only the farm GPO.

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

201

Determining Which Policies Apply to a Connection

Troubleshooting Policies
Users, IP addresses, and other filtered objects can have multiple policies that apply simultaneously. This can result in conflicts where a policy may not behave as expected. When you run the Citrix Group Policy Modeling Wizard or the Group Policy Results tool, you might discover that no policies are applied to user connections. When this happens, users connecting to their applications under conditions that match the policy evaluation criteria are not affected by any policy settings. This occurs when:
q

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:
q

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

202

To simulate connection scenarios with Citrix policies


1. Depending on your XenApp environment, open the Citrix Group Policy Modeling Wizard:
q

From the AppCenter, click the Policies node, and then click Run the modeling wizard from the Actions pane.

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 filter criteria you want to use in the simulation.
q

When you click Finish, the wizard produces a report of the modeling results. In the AppCenter, the report appears as a node in the AppCenter 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.

203

Applying Policies to Access Gateway Connections


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 client 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 XenApp to filter on Access Gateway connections, you must complete all of the following:
q

Create one or more filters within Access Gateway. See the Access Gateway section of Citrix eDocs for more information about creating filters. 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 XenApp.

For published applications, select Allow connections made through Access Gateway Advanced Edition in the application properties. Ensure that your farm is configured to allow Access Gateway connections, which it is by default. Create a Computer policy within XenApp that has the Trust XML requests policy setting enabled. Create a User policy within XenApp that includes a filter referencing Access Gateway filters.

204

Applying Policies to Access Gateway Connections

To apply a policy filter based on Access Gateway connections


1. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node in the left pane and then select the User tab in the middle pane.

From the Group Policy Management 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.
q

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: a. In AG farm name, enter one of the following items:
q

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. b. In Access condition, enter one of the following items:
q q

If using Access Gateway Advanced Edition, enter the name of the Access Gateway filter for XenApp to use. If using Access Gateway Enterprise Edition, enter the name of the endpoint session policy for XenApp to use.

Important: XenApp 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 XenApp whether or not to apply the policy to connections that match the filter criteria. Selecting Deny tells XenApp to apply the policy to connections that do not match the filter criteria.

205

Enabling Scanners and Other TWAIN Devices


XenApp lets users control client-attached TWAIN imaging devices, such as scanners and cameras, from published applications. This feature is known as TWAIN redirection because XenApp provides TWAIN support by redirecting commands sent from a published application on the server to the client device. Users can connect regardless of connection type. However, XenApp requires the following for TWAIN support:
q

The imaging device must be connected locally to the user device and have the associated vendor-supplied TWAIN driver installed locally. Citrix Receiver 3.0, Citrix Online Plug-in 11.x or later, or the Citrix Offline Plug-in. XenApp 32-bit and 64-bit servers support TWAIN redirection for 32-bit TWAIN applications only. XenApp does not support 16-bit TWAIN drivers. The Client TWAIN device redirection policy setting must be added to the appropriate policy. To configure image compression, add the TWAIN compression level setting and select the appropriate compression level.

The following table lists the TWAIN hardware and software tested with XenApp. While other TWAIN devices may work, only those listed are supported.

Scanners and Scanning Devices

Canon CanoScan 3200F Canon CanoScan 8000F Canon CanoScan LiDE600F Fujitsu fi-6140 Fujitsu ScanSnap 9510 HP ScanJet 8250 IRIScan Express 2

Software

Microsoft Office Publisher 2007 Microsoft Office Word 2007 Clip Organizer

OmniPage SE Consider the following after enabling TWAIN redirection:


q

Configure bandwidth limits for image transfers. You can add the TWAIN device redirection bandwidth limit or the TWAIN device redirection bandwidth limit percent settings to the policy and enter the appropriate values denoting the maximum bandwidth allowed for image transfers.

206

Enabling Scanners and Other TWAIN Devices


q

Some applications are not Remote Desktop Session Host aware and look for Twain32.dll in the \Windows directory of the user profile (by default, C:\Documents and Settings\UserName\Windows). Copying Twain32.dll into the \Windows directory of each user profile resolves this issue. You can also correct this by adding the application to the Remote Desktop Session Host application compatibility list with the following two flags specified:
q

Windows-based 32-bit application: 0x00000008

Return system \Windows directory instead of user \Windows directory for GetWindowsDir: 0x00000400 For more information about using compatibility flags, see the article "Program compatibility flags" on the Microsoft TechNet Web site at http://technet.microsoft.com.
q q

This feature supports the following modes of TWAIN information transfer:


q

Native Buffered Memory (most scanning software works by default in Buffered Memory mode)

Note: The disk file transfer mode is not supported.

207

Managing Session Environments and Connections


Provide user access to your farms resources by:
q

Customizing user environments Controlling connections Monitoring, managing, and optimizing sessions

When a user initially connects to your farm and opens a published application, the server opens the application in a session. In XenApp, the term session refers to a particular instance of a users activity on the server; sessions are the virtualization of the users environment. Users access published applications in sessions after the client device establishes a connection with the server.

When a user logs on to the farm, the client device links to the server through a connection and establishes a session. This connection is known as the client connection. Users access published resources through client connections, inside of sessions. As an administrator, you can customize users environments, including whether or not users can access mapped drives, such as the local client devices hard disk; if they can access local special folders, the printers that are available, and the amount of bandwidth used for audio support. You can change these settings based on the location from where the users are connecting.

208

Managing Session Environments and Connections XenApp provides settings to ensure sessions remain reliable. You can also monitor users sessions, and their sessions status, by shadowing.

209

Defining User Environments in XenApp


XenApp provides different ways to control what users experience in their session environments. You can customize user environments in the following ways:
q

By suppressing the number of progress bars users see when they first open an application, so that XenApp appears to be an integrated part of their everyday environment. By either allowing or preventing users from accessing their local devices or ports during a session. You can also prevent users from accessing devices and ports during remote sessions. By defining whether or not users can hear audio or use microphones during sessions. If you enable audio support, you can specify the level of audio compression and limit bandwidth, if necessary. You can control audio either at the group level through policies or at the published application level. By ensuring that mobile workers, such as travelling salespeople or workers inside a hospital, always have the most appropriate printers and devices available to them inside of a session.

For the Citrix Receiver, you can also customize the users experience by choosing whether you want published applications and desktops to appear in a window within a Remote Desktop window or seamlessly. In seamless window mode, published applications and desktops appear in separate resizable windows, which make the application appear to be installed locally. Certain features are available only in seamless mode. Some features that relate to session environments or connections, such as dual-monitor mode support and information about logons, are plug-in specific. Details about these features are located in the Citrix Receiver and the Web Interface documentation.

210

Controlling the Appearance of User Logons


When users connect to a server, they see all connection and logon status information in a sequence of screens, from the time they double-click a published application icon on the client device, through the authentication process, to the moment the published application launches in the session. XenApp achieves this logon look and feel by suppressing the status screens generated by a servers Windows operating system when a user connects. To do this, XenApp Setup enables the following Windows local group policies on the server on which you install the product:
q

Administrative Templates > System > Remove Boot / Shutdown / Logon / Logoff status messages Administrative Templates > System > Verbose versus normal status messages

However, Active Directory group policies take precedence over equivalent local group policies on servers. Therefore, when you install XenApp on servers that belong to an Active Directory domain, those Active Directory policies may prevent XenApp from suppressing the status screens generated by the Windows operating systems of the individual servers. In that case, users see the status screens generated by the Windows operating system when connecting to that server. For optimal performance, do not configure these group policies in Active Directory.

211

Controlling Access to Devices and Ports


Citrix Receiver supports mapping devices on client computers so users can access the devices within sessions. Client device mapping provides:
q

Access to local drives and ports Cut-and-paste data transfer between a session and the local clipboard Audio (system sounds and .wav files) playback from the session

During logon, Receiver reports the available client drives and COM ports to the server. By default, client drives appear as network resources so the drives appear to be directly connected to the server. The client drives are displayed with descriptive names so they are easy to locate among other network resources. These drives are used by Windows Explorer and other applications like any other network drive. In Citrix policies, redirection settings are used for mapping.

Redirecting Client COM Ports and Audio


Client COM port redirection allows a remote application running on the server to access devices attached to COM ports on the user device. COM port and audio redirection are configured with the Client COM port redirection and Client audio redirection User policy settings. For more information, see the Receiver documentation.

212

To enable user execute permissions on mapped drives


In general, XenApp displays client drive letters as they appear on the user device; for example, the user device's hard disk drive appears as "C: on ClientName," where ClientName is the name of the user device. This allows the user to access client drive letters in the same way locally and within sessions. You can turn off client drive redirection through XenApp policies. In doing so, you also turn off mapping to client floppy disk drives, hard drive, CD-ROM drives, or remote drives regardless of the policy settings for those individual devices. As a security precaution, when a user logs on to XenApp, by default, the server maps client drives without user execute permission. To enable users to execute files residing on mapped client drives, override this default by editing the registry on a XenApp server. 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. After installing XenApp, open the Registry Editor.

2. Find the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\picadm\Parameters\ExecuteFromMappedDrive 3. To grant users execute permission on mapped drives, set ExecuteFromMappedDrive to 1. 4. To deny users execute permission on mapped drives, set ExecuteFromMappedDrive to 0. 5. Restart the server.

213

Displaying Local Special Folders in Sessions


To make it easier for your users to save files to their special folders locally, you can enable Special Folder Redirection. Special folders is a Microsoft term that refers to Windows folders such as Documents, Computer, and the Desktop. Without Special Folder Redirection enabled, the Documents and Desktop icons that appear in a session point to the users Documents and Desktop folders on the server. Special Folder Redirection redirects actions, such as opening or saving a file, so that when users save or open files from special folders, they are accessing the special folder on their local computers. In addition, for the Citrix Receiver, the Documents folder in the Start menu maps to the Documents folder on the client device. To use Special Folder Redirection, users must access the farm with the Citrix online plug-in 11.x or later or the Web Interface.

Restrictions
Do not enable Special Folders Redirection in situations when a user connects to the same session from multiple client devices simultaneously. For Special Folder Redirection to work, the user must log off from the session on the first client device and start a new session on the second client device. If users must run multiple sessions simultaneously, use roaming profiles or set a home folder for that user in the User Properties in Active Directory. Because Special Folder Redirection must interact with the client device, some settings prevent Special Folder Redirection from working. You cannot have policy settings that prevent users from accessing or saving to their local hard drives. Currently, for seamless and published desktops, Special Folder Redirection works only for the Documents folder. For seamless applications, Special Folder Redirection only works for the Desktop and Documents folders. Citrix does not recommend using Special Folder Redirection with published Windows Explorer. Special Folder Redirection requires access to the Documents and Desktop folders on the users local computer. When a user launches an application through the Web Interface and uses File Security to select No Access in the File Security dialog box in Connection Center, access is denied to the users local workstation drives, including the users local Documents and Desktop folders. As a result, some applications might be unstable when trying to perform read/write operations to the denied folders. To avoid this, always grant full local access when Special Folder Redirection is enabled. Caution: Special Folder Redirection does not redirect public folders on Windows Vista and Windows Server 2008. If users are connecting to servers that are not in their domain, instruct users not to save to public folders. If users save documents to public folders, they are saving them to a local folder on the server hosting the published application. In large environments where many servers host the same application, it could be difficult to

214

Displaying Local Special Folders in Sessions determine which server contains the public folder where the user saved the document.

To enable Special Folder Redirection


Special Folder Redirection support is enabled by default, but you must provide this feature to users through the Citrix Receiver and Web Interface. You can either enable Special Folder Redirection for all users or configure that users must enable the feature themselves in their client settings. You can allow or prevent specific users from having redirected special folders with the Special folders redirection policy setting. 1. Enable the Special Folder Redirection policy setting and apply filters to ensure the setting is applied to the users you want accessing local special folders. To prevent local special folders from being redirected, ensure a filter is configured that targets the users you do not want accessing local special folders. 2. Decide if you want to let users turn this feature on and off in their sessions. Instructions for users are provided in their plug-in help. 3. Ensure you do not have any policy settings enabled that are not supported with Special Folder Redirection (such as preventing accessing or writing to local hard drives). If you enable Special Folder Redirection without success, use Search to determine if any settings conflict with this feature. Tip: Let your users know that other Special Folders, such as Music or Recent Documents, still point to the server. If users save documents to these folders, they are saved to the server.

To enable Special Folder Redirection for Web Interface


This procedure requires that you already created a XenApp Web site. 1. From the AppCenter, select Citrix Resources > Configuration Tools > Web Interface > XenApp Web Site Name. 2. From the Action menu, choose Manage session preferences. 3. In the Managing Session Preferences page, select Remote Connection > Local Resources. 4. Select the correct options. To Select the options

215

Displaying Local Special Folders in Sessions Enable Special Folder Redirection by default and let users turn it off in their session options. Provide Special Folder Redirection to all users Allow users to customize Special Folder Redirection Disable Special Folder Redirection by default, but let users turn it on in their session options Enable Special Folder Redirection by default and prevent users from turning it on or off Allow users to customize Special Folder Redirection Provide Special Folder Redirection to all users

To enable Special Folder Redirection for Citrix Receiver


This procedure requires that you already created a XenApp Services site. 1. From the AppCenter, select Citrix Resources > Configuration Tools > Web Interface > XenApp Services Site Name > config.xml. 2. From the Action menu, choose Change session options. 3. In the Change Session Options page, select Remote Connection > Local Resources. 4. Select the correct options. To Enable Special Folder Redirection by default and let users turn it off in their session options. Select the options Provide Special Folder Redirection to all users Allow users to customize Special Folder Redirection Disable Special Folder Redirection by default, but let users turn it on in their session options Enable Special Folder Redirection by default and prevent users from turning it on or off Allow users to customize Special Folder Redirection Provide Special Folder Redirection to all users

216

Configuring Audio for User Sessions


XenApp provides tools to manage and control the availability of sound in sessions, both in terms of quality and cost in resources, including:
q

Audio properties you configure for individual published applications Audio related policy settings you configure for specific connection types Audio settings the user configures on the user device

For example, you can use audio-related connection policy settings to control bandwidth usage and server CPU utilization. You can configure a policy setting to enable audio for connections where audio is essential, and configure another setting to disable audio for connections where it is not essential. Use policy settings to control the availability of speakers and microphones in sessions. Important: To use audio in sessions, users must also enable audio on the user device. When audio is enabled, you can also use policy settings to set compression levels and bandwidth allocation.

217

To enable or disable audio for published applications


If you disable audio for a published application, audio is not available within the application under any condition. If you enable audio for an application, you can use policy settings and filters to further define under what conditions audio is available within the application. 1. In the AppCenter, select the published application for which you want to enable or disable audio, and select Action > Application properties. 2. In the Application Properties dialog box, click Advanced > Client options. Select or clear the Enable legacy audio check box.

218

To configure bandwidth limits for audio


Use policy settings to configure the amount of bandwidth you want to allocate to audio transfers between servers and client devices. For example, you might want to create separate policy settings for groups of dial-up users and for those who connect over a LAN, accommodating the different amounts of bandwidth each group will have available. In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such as servers or users. 1. Configure the following Citrix User policy settings:
q

Audio redirection bandwidth limit. Specify the bandwidth available for audio in kilobits per second. Audio redirection bandwidth limit percent. Limit the bandwidth available for audio to a percentage of the overall bandwidth available. If you configure this setting, you must enable the Overall session bandwidth limit setting.

219

To configure audio compression and output quality


Use Citrix policy settings to configure the compression levels to apply to sound files. Generally, higher sound quality requires more bandwidth and higher server CPU utilization. You can use sound compression to balance sound quality and overall session performance. Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. 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 connections that applies lower compression levels. In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such as servers or users. 1. Configure the Audio quality Citrix User policy setting with one of the following options:
q

Low - for low-speed connections. This causes any sounds sent to the client device to be compressed to a maximum of 16Kbps. This compression results in a significant decrease in the quality of the sound. The CPU requirements and benefits of this setting are similar to those of the Medium setting; however, the lower data rate allows reasonable performance for a low-bandwidth connection. Medium - optimized for speech. This is recommended for most LAN-based connections. This setting causes any sounds sent to the client device to be compressed to a maximum of 64Kbps. This compression results in a moderate decrease in the quality of the sound played on the client device. High - high definition audio. This is recommended for connections where bandwidth is plentiful and sound quality is important. This setting allows client devices to play a sound file at its native data rate. Sounds at the highest quality level require about 1.3Mbps of bandwidth to play clearly. Transmitting this amount of data can increase bandwidth requirements, and result in increased CPU utilization and network congestion.

220

To enable support for microphones and speakers


For users to use speaker and microphones in sessions, both audio input (for microphones) and output (for speakers) must be enabled. Audio input and output are controlled by two policy settings; you must configure both to ensure that audio input and output are enabled. Note: Microphone input is supported on the Citrix Receiver for Windows, and the Windows CE and Linux plug-ins. This allows you to implement separate connection policies; for example, for users of mobile devices and for users who connect over a LAN. For the mobile user group, you may want to enable audio input but disable audio output. This lets mobile users record notes from the field, but prevents the server from sending audio to the mobile devices, ensuring better session performance. Enabling audio input and output also enables support for digital dictation. On the client device, users control audio input and output in a single stepby selecting an audio quality level from the Options > Session Options dialog box. By default, when you configure these settings, audio input is enabled on client devices. Web Interface users can override the policy and disable their microphones by selecting No in the Audio Security dialog box, which they access from the Citrix Connection Center. In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such as servers or users. 1. To enable audio input for sessions, configure the Client microphone redirection Citrix User policy setting. 2. To enable audio output for sessions, configure the Client audio redirection Citrix User policy setting.

221

To use and set sound quality for digital dictation devices


If you have enabled microphone and speaker support, XenApp requires no additional configuration to allow users to record audio using a standard microphone. However, to allow users to use digital dictation devices such as Philips SpeechMike devices and dictation software such as WinScribe Internet Author and Internet Typist, you must install and configure the associated software and set session sound quality to accommodate them. To enable Phillips SpeechMike devices, go to the Philips web site for information and software downloads. Note: The Citrix plug-ins for Linux and Windows CE do not support Philips SpeechMike products. To make Philips SpeechMike devices or similar products available in user sessions, install the device drivers associated with the products on the XenApp server and on client devices. To make dictation software such as WinScribe Internet Author and Internet Typist available, install this software on the XenApp server. After installation, you might be required to enable the controls for the dictation device within the dictation software. Refer to the product documentation for instructions. Set sound quality to at least medium quality. To enable the use of Philips SpeechMagic Speech Recognition server with WinScribe software, set sound quality to high to enable accurate speech-to-text translation. 1. From Citrix Web Interface Management, select the XenApp Services site you want to configure. 2. In the Action pane, select Session Options. 3. Select Color and Sound. 4. In the Sound area, select one of:
q

Medium - optimized for speech High - high definition audio

222

Ensuring Session Continuity for Mobile Workers


The Workspace Control feature provides users with the ability to disconnect quickly from all running applications, to reconnect to applications, or to log off from all running applications. Workspace Control enables users to move among client devices and gain access to all of their open applications when they log on. For example, you can use Workspace Control to assist health-care workers in a hospital who need to move quickly between workstations and access the same set of applications each time they log on to XenApp. If you configure Workspace Control options to allow it, these workers can disconnect from multiple applications at one client device and then reconnect to open the same applications at a different client device. For users accessing applications through the Web Interface or Citrix Receiver, you can configureand allow users to configurethese activities:
q

Logging on. By default, Workspace Control enables users to reconnect automatically to all running applications when logging on, bypassing the need to reopen individual applications. Through Workspace Control, users can open disconnected applications plus applications active on another client device. Disconnecting from an application leaves the application running on the server. If you have roaming users who need to keep some applications running on one client device while they reconnect to a subset of their applications on another client device, you can configure the logon reconnection behavior to open only the applications that the user disconnected from previously. Reconnecting. After logging on to the server farm, users can reconnect to all their applications at any time by clicking Reconnect. By default, Reconnect opens applications that are disconnected plus any applications currently running on another client device. You can configure Reconnect to open only those applications that the user disconnected from previously. Logging off. For users opening applications through the Web Interface, you can configure the Log Off command to log the user off from the Web Interface and all active sessions together, or log off from the Web Interface only. Disconnecting. Users can disconnect from all running applications at once without needing to disconnect from each application individually.

Workspace Control is enabled in the server farm by default and is available only for users accessing applications through the Web Interface or Citrix Receiver. User policies, client drive mappings, and printer configurations change appropriately when a user moves to a new client device. Policies and mappings are applied according to the client device where the user is currently logged on to the session. For example, if a health care worker logs off from a client device in the emergency room of a hospital and then logs on to a workstation in the hospitals X-ray laboratory, the policies, printer mappings, and client drive mappings appropriate for the session in the X-ray laboratory go into effect at the session startup.

223

Ensuring Session Continuity for Mobile Workers You can customize what printers appear to users when they change locations as well as control whether they can print to local printers, how much bandwidth is consumed when users connect remotely, and other aspects of their printing experiences. For more information about enabling and configuring Workspace Control for users, see the Web Interface documentation.

224

Maintaining Session Activity


Users can lose network connectivity for various reasons, including unreliable networks, highly variable network latency, and range limitations of wireless devices. Losing connectivity often leads to user frustration and a loss of productivity. You can leverage these three features of XenApp to optimize the reliability of sessions and to reduce the amount of inconvenience, downtime, and loss of productivity users incur due to lost network connectivity.
q

Session Reliability Auto Client Reconnect ICA Keep-Alive

225

Configuring Session Reliability


Session Reliability keeps sessions active and on the users screen when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes. This feature is especially useful for mobile users with wireless connections. Take, for example, a user with a wireless connection who enters a railroad tunnel and momentarily loses connectivity. Ordinarily, the session is disconnected and disappears from the users screen, and the user has to reconnect to the disconnected session. With Session Reliability, the session remains active on the server. To indicate that connectivity is lost, the users display freezes and the cursor changes to a spinning hourglass until connectivity resumes on the other side of the tunnel. 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. Citrix Receiver users cannot override the server setting. Note: You can use Session Reliability with Secure Sockets Layer (SSL). By default, Session Reliability is enabled through policy settings. You can customize the policy settings for this feature as appropriate. You can edit the port on which XenApp listens for session reliability traffic and edit the amount of time Session Reliability keeps an interrupted session connected. The Citrix Computer policy Session reliability connections setting allows or prevents session reliability. The Session reliability timeout setting has a default of 180 seconds, or three minutes. Though you can extend the amount of time Session Reliability keeps a session open, this feature is designed to be convenient to the user and it does not, therefore, 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. Incoming session reliability connections use port 2598, unless you change the port number with the Citrix Computer policy Session reliability port number setting. If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, use the Auto Client Reconnect feature. You can configure the Citrix Computer policy Auto client reconnect authentication setting to prompt users 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 Citrix Computer policySession reliability timeout setting. After that, the Auto Client Reconnect policy settings take effect, attempting to reconnect the user to the disconnected session.

226

Configuring Automatic Client Reconnection


The Auto Client Reconnect feature allows Citrix Receiver for Windows and plug-ins for Java and Windows CE to detect broken connections and automatically reconnect users to disconnected sessions. When Receiver or a plug-in detects an involuntary disconnection of a session, it attempts to reconnect the user to the session until there is a successful reconnection or the user cancels the reconnection attempts. When a connection breaks, it may leave the server session in an active state. Users can reconnect only to sessions that are in a disconnected, or inactive, state. Cookies containing keys to user credentials and session IDs are created on the client device when sessions are started. Because users can be reconnected only to disconnected sessions, Auto Client Reconnect uses the cookie on the client device to disconnect an active session before attempting to reconnect. Configure Auto Client Reconnect with the following Citrix Computer policy settings:
q

Auto client reconnect. Enables or disables automatic reconnection by the same client after a connection has been interrupted. Auto client reconnect authentication. Enables or disables the requirement for user authentication upon automatic reconnection Auto client reconnect logging. Enables or disables logging of reconnection events in the event log. Logging is disabled by default. When enabled, the server's System log captures information about successful and failed automatic reconnection events. Each server stores information about reconnection events in its own System log; the server farm does not provide a combined log of reconnection events for all servers.

Auto Client Reconnect incorporates an authentication mechanism based on encrypted user credentials. When a user initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory, and creates and sends a cookie containing the encryption key to Receiver or the plug-in. Receiver or the plug-in submits the key to the server for reconnection. The server decrypts the credentials and submits them to Windows logon for authentication. When cookies expire, users must reauthenticate to reconnect to sessions. Cookies are not used if you enable the Auto client reconnection authentication setting. Instead, XenApp displays a dialog box to users requesting credentials when Receiver or the plug-in attempts to reconnect automatically. Note: For maximum protection of users credentials and sessions, use SSL encryption for all communication between clients and the server farm. Disable Auto Client Reconnect on Citrix Receiver for Windows by using the icaclient.adm file. For more information, see the Citrix Receiver or plug-in documentation. Settings for connections also affect Auto Client Reconnect.

227

Configuring Automatic Client Reconnection

Configuring Connections for Automatic Client Reconnection


By default, Auto Client Reconnect is enabled through policy settings on the farm level. User reauthentication is not required. However, if a servers ICA TCP connection is configured to reset sessions with a broken communication link, automatic reconnection does not occur. Auto Client Reconnect works only if the server disconnects sessions when there is a broken or timed out connection. In this context, the ICA TCP connection refers to a XenApps virtual port (rather than an actual network connection) that is used for sessions on TCP/IP networks. By default, the ICA TCP connection on a XenApp server is set to disconnect sessions with broken or timed out connections. Disconnected sessions remain intact in system memory and are available for reconnection by Receiver. The connection can be configured to reset, or log off, sessions with broken or timed out connections. When a session is reset, attempting to reconnect initiates a new session; rather than restoring a user to the same place in the application in use, the application is restarted. If XenApp is configured to reset sessions, Auto Client Reconnect creates a new session. This process requires users to enter their credentials to log on to the server. Automatic reconnection can fail if Receiver or the plug-in submits incorrect authentication information, which might occur during an attack or the server determines that too much time has elapsed since it detected the broken connection.

228

Configuring ICA Keep-Alive


Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled, if XenApp detects no activity (for example, no clock change, no mouse movement, no screen updates), this feature prevents Remote Desktop Services from disconnecting that session. XenApp sends keep-alive packets every few seconds to detect if the session is active. If the session is no longer active, XenApp marks the session as disconnected. However, the ICA Keep-Alive feature does not work if you are using Session Reliability. Session Reliability has its own mechanisms to handle this issue. Only configure ICA Keep-Alive for connections that do not use Session Reliability. ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy. 1. Configure the following Citrix Computer policy settings:
q

ICA keep alive timeout. Specifies the interval (1-3600 seconds) used to send ICA keep-alive messages. Do not configure this option if you want your network monitoring software to close inactive connections in environments where broken connections are so infrequent that allowing users to reconnect to sessions is not a concern. The 60 second default interval causes ICA Keep-Alive packets to be sent to client devices every 60 seconds. If a client device does not respond in 60 seconds, the status of the ICA sessions changes to disconnected.

ICA keep alives. Sends or prevents sending ICA keep-alive messages periodically.

229

Session Linger
A user session ends after user processes and visible windows end (for example, when a user exits from an application, the session ends). You can use session linger to provide a better user experience by eliminating the launch delay between applications. To use session linger for named user sessions, configure the following Citrix User policy settings:
q

Linger Terminate Timer Interval specifies the number of minutes a session remains active after the last application terminates. If a new application starts during this interval, the user session returns to the active monitoring state. If no application starts during this interval, the session ends. If this policy setting is not used, session linger is disabled.

Linger Disconnect Timer Interval specifies the number of minutes to wait after lingering begins before disconnecting the session. If a new application starts during this interval, the user session returns to the active monitoring state. It is possible that other factors may cause a session to be disconnected before the Linger Disconnect Timer Interval expires. If this policy setting is not used, a lingering session will not disconnect.

Anonymous user sessions do not have a disconnected state; they are either active or terminated. Therefore, if the Linger Terminate Timer Interval and Linger Disconnect Timer Interval policy settings are used, the effective Linger Terminate Timer Interval setting is the same as the Linger Disconnect Timer Interval setting. For a non-seamless named user session, the disconnected session remains in the disconnected state until the Linger Terminate Timer Interval expires.

230

Managing and Monitoring XenApp Sessions


You can interact directly with sessions by resetting, disconnecting or logging off sessions, or sending messages to users. You can monitor sessions through AppCenter displays or directly through shadowing.

Disconnecting and Resetting Sessions


A disconnected session is still active and its applications continue to run, but the client device is no longer communicating with the server. A user can reconnect to a disconnected session from a different client device without loss of data. For example, you might disconnect users sessions if they experience problems on their client device and do not want to lose data from their applications. When you disconnect a session, you close the connection between the client device and the server. However, this does not log off the user, and programs that were running in the session are still running on the server. (Some applications that rely on virtual channels, such as media players, may behave differently. For example, if you disconnect from a session running Media Player while playing audio, the audio stops playing because the audio virtual channel is no longer available.) When a session is disconnected, session state displays indicate Disconnected. If the client user then connects to the server (by selecting a published application or custom connection to the server), the disconnected session is reconnected. You can log off users from their sessions. You can also reset a users client session or a disconnected session. You can also connect to a users disconnected session when you are using the AppCenter from within a client session on a XenApp server. To connect, you must know the password of the user who started the session. Your session must support the same video resolution as the disconnected session. Resetting a session terminates all processes that are running in that session. You can reset a session to remove remaining processes in the case of a session error; however, resetting a session can cause applications to close without saving data. When you reset a disconnected session, session state displays indicate Down. When you refresh the AppCenter display or when the next automatic refresh occurs, the session no longer appears in the list of sessions. Special sessions that listen for requests to connect to the server indicate Listening in session state displays. If you reset a listener session, the server resets all sessions that use the protocol associated with the listener. For example, if you reset the ICA listener session, you reset the ICA sessions of all users connected to the server.

231

Managing and Monitoring XenApp Sessions

To use session controls


From the AppCenter:
q

To reset a session: Caution: Resetting effectively deletes the session and results in loss of data for the user. Only reset a session when it malfunctions or is not responding. 1. Select the server to which the user is connected. 2. In the results pane, click the Sessions tab. 3. Select the session you want to reset. (You can select one or more sessions.) 4. In the Actions pane, select Reset. To disconnect a session: 1. Select the server to which the user is connected. 2. In the results pane, click the Sessions tab. 3. Select the session you want to reset. (You can select one or more sessions.) 4. In the Actions pane, select Disconnect. To logoff from a session: Caution: Ending user sessions using Logoff can result in loss of data if users do not close their applications first. Before initiating the logoff, send a message to warn users to exit all applications. 1. Select the server to which the user is connected. 2. In the results pane, click the Sessions tab. 3. Select the session you want to log off. (You can select one or more sessions.) 4. In the Actions pane, select Log off. Confirm the logoff when prompted. To terminate processes in a user session: Caution: Terminating a process may abruptly end a critical process and leave the server in an unusable state. 1. Select the server to which the user is connected. 2. In the results pane, click the Users tab and select the session for which you want to terminate a process. 3. In the lower portion of the results pane, click the Processes tab and select the process you want to terminate. 4. In the Actions pane, select Terminate.

232

Managing and Monitoring XenApp Sessions

To send a message to one or more users from the AppCenter


Sending a message that appears in user sessions can be helpful in situations such as broadcasting information about new applications and upgrades, requesting a shadowing session, or warning of a logoff or system shutdown. 1. From the AppCenter, select the server to which the users are connected. To send a message to all user sessions in the farm, select a farm node instead of a server. 2. In the results pane, click the Users tab and select one or more sessions. 3. In the Actions pane, select Send Message. The Send Message dialog box appears. 4. Edit the title of the message, if required, and enter the message text.

233

Monitoring Session Information


1. From the AppCenter, select the server on which you want to monitor sessions. 2. In the results pane, click the Sessions tab. The display lists all sessions running on the server. By default, the upper portion of the results pane includes the following information for all sessions (click Choose columns to specify which columns to display and the display order): Field User Description Name of the user account that initiated the session. For anonymous connections, the user name is a string beginning with "Anon" followed by a session number. Unique number that begins with 0 for the first connection to the console. Listener sessions are numbered from 65,537 and numbered backward sequentially. Name of the published application running in the session. Session type: ICA or RDP Active, Listen, Idle, Disconnected, or Down. Name of the client device that is running the session. When the user logged on. How long the session has been idle.

Session ID

Application Type State Client Name Logon Time Idle Time

Server Server on which the application is running. 3. Select a session. Depending on the session you select:
q

Tasks become available in the Actions pane; these can include Reset, Log off, Disconnect, and Send Message. The lower portion of the results pane displays tabs containing additional information: Information, Client Cache, Session Information, Client Modules, and Processes.

234

Viewing User Sessions


You can view another users session on another device by using shadowing. When shadowing, you can monitor the session activity as if you are watching the screen of the client device that initiated the session. If configured, you can also use your keyboard and mouse to control the users keyboard and mouse remotely in the shadowed session. Shadowing a session provides a powerful tool for you to assist and monitor users. Shadowing is a useful option for your Help desk staff who can use it to aid users. Help desk personnel can view a users screen or actions to troubleshoot problems and can demonstrate correct procedures. You can also use shadowing for remote diagnosis and as a teaching tool. You can shadow using either the AppCenter or the Shadow Taskbar. You enable shadowing on a server when you configure XenApp and select the default option, which allows shadowing on all connections on the server. If you do not leave the shadowing option enabled during configuration, you must reinstall XenApp to get shadowing functionality. By default, the user is notified of the pending shadowing and asked to allow or deny shadowing. Important: Your client device and shadowing ICA session must support the video resolution of the users ICA session (the shadowed session). If not, the operation fails. You cannot shadow a system console from another session. For shadowing options by connection type, such as keyboard, mouse, and user notification options, use the Remote Desktop Session Host Configuration tool.

235

Viewing User Sessions with the Shadow Taskbar


Use the Shadow Taskbar to shadow multiple ICA sessions from a single location, including the server console. Use the Shadow button to start shadowing one or more users. The Shadow Taskbar uses the client to launch an ICA session to monitor a user. A separate ICA session is started for each shadowed user. You must enter your user name and password to start an ICA session on the server running the Shadow Taskbar. Note the following:
q

The client uses a license to log on to the server and start shadowing a user. The Shadow Taskbar shows sessions on the server or domain you logged on to. You can view servers in a different domain by logging on to an account in that domain and restarting the Shadow Taskbar. Each shadow session consumes memory on the server, so limit the number of simultaneous shadow sessions.

Each shadowed session is represented by a task button on the Shadow Taskbar. Use this button to switch quickly between the shadowing sessions you have open.

To start the Shadow Taskbar


1. From the Start menu, choose All Programs > Citrix > Administration Tools > Shadow Taskbar. 2. To configure shadowing options, right-click an empty area of the Shadow Taskbar or press SHIFT + F10. To switch to a shadow session, click its button in the Shadow Taskbar. To close the Shadow Taskbar, right-click an empty area of the Shadow Taskbar and select Exit.

236

Viewing User Sessions with the Shadow Taskbar

To select users and initiate shadowing


1. On the Shadow Taskbar, click the Shadow button. The Shadow Session dialog box appears.
q

The Available Users list shows user sessions that can be selected for shadowing in the current domain. User sessions are organized by servers, published applications, and users. You can shadow only client user sessions.

The Shadowed Users list shows user sessions selected for shadowing and existing shadow sessions; it also displays the user name of currently shadowed users next to the shadow icon. 2. In the Available Users list, select one or more users to shadow and click Add. The selected users move to the Shadowed Users list. Shadowing is initiated for all users in the Shadowed Users list when you click OK.
q

To end a shadowing session


1. On the Shadow Taskbar, click the Shadow button. The Shadow Session dialog box appears. 2. In the Shadowed Users list, select the users to stop shadowing and click Remove. Tip: You can end a shadow session by right-clicking the sessions task button on the Shadow Taskbar and clicking Stop Shadow. You can end all shadow sessions by right-clicking the Shadow Taskbar and clicking Stop All Shadowed Sessions.

237

Enabling Logging for Shadowing


After configuring XenApp, you can enable shadow logging and configure shadow logging output to one of two locations on the server:

In a central file. Configuring this option records a limited number of logging events, such as when and who started a shadowing session and who is being shadowed. When you configure shadow logging through the Shadow Taskbar, the logged events are not recorded in the Windows Event log. Instead, they go to a file that you specify. In the Windows Event log. Configuring this option logs several different event types in the Application log of the Windows Event log. These include user shadowing requests, such as when users stop shadowing, failure to launch shadowing, and access to shadowing denied. However, these events are logged as they occur and it can be cumbersome to see a shadowing history because the events are strewn throughout the Event log.

For ease of management, consider logging events in a central file. Only shadowing events go in to this file, so they are more centralized and easier to review.

To configure shadow logging to log in a central file


1. Click on an empty area of the Shadow Taskbar and press SHIFT + F10. 2. Click Logging Options. 3. Select the Enable Logging check box and specify a log file path. Click Clear Log to empty the current log file.

To enable shadow logging in the Windows Event log


Configure the Citrix User policy Log shadow attempts setting.

238

Enabling User-to-User Shadowing with Policies


You can create a user policy to enable user-to-user shadowing, which allows users to shadow other users without requiring them to be members of the Citrix administrator group. With user-to-user shadowing, multiple users from different locations can view presentations and training sessions, allowing one-to-many, many-to-one, and many-to-many online collaboration. Also, you can enable Help Desk personnel to shadow users sessions or allow your Sales Department to hold an online meeting to review sales leads. Important: You configure shadowing settings during XenApp configuration. If you choose to prohibit shadowing during configuration, you cannot enable shadowing with user policies. You enable user-to-user shadowing by creating policies that define users who can and cannot shadow. You then assign the policies to the users to be shadowed. The list of users permitted to shadow is exclusive for each user for whom a policy is assigned. For example, if you create a policy that permits User A to shadow User B, this policy allows only User A to shadow User B, unless you add more users to the list of users who can shadow in the same policys Property sheet.

To create a policy to define users who can shadow


1. Create a user policy that identifies the users who can shadow other users sessions. 2. Assign the policy to the users to be shadowed. 3. Publish the Citrix Shadow Taskbar and assign it to the users who will shadow. Be sure to instruct these users how to initiate shadowing from their client devices.

Note: Instruct users not to launch the Shadow taskbar in seamless mode. The Shadow taskbar cannot function in seamless mode.

Example: To create a user policy for user-to-user shadowing and assign it to users
This example demonstrates how to enable user-to-user shadowing by creating a policy for your Sales user group that allows them to shadow the department manager for online collaboration on sales leads. This procedure shows the creation of a shadowing policy. 1. Create a new policy named Sales Group Shadowing. 2. Add the Shadowing Citrix Computer policy setting and set it to Allowed.

239

Enabling User-to-User Shadowing with Policies 3. Because the Sales Manager may work with sensitive data, add the Notify user of pending shadow connections Citrix User policy setting and set it to Enabled. If the Sales Manager does not want other users to be able to take control of his mouse and keyboard, add the Input from shadow connections Citrix User policy setting and set it to Prohibited. 4. Add the Users who can shadow other users Citrix User policy setting, and select the users who can shadow the Sales Manager. 5. To specify users who cannot shadow the Sales Manager, add the Users who cannot shadow other users Citrix User policy setting, and select users. 6. Add the User filter and select the users who can receive shadowing requests.

240

Controlling Client Connections in XenApp


You can control XenApp client connections in different places:
q

XenApp policies Application Publishing Active Directory

XenApp policies
Policies let you define how you want clients to connect, including SSL or encryption requirements, and the properties for the users environments after the connection is established. Citrix recommends using XenApp policies whenever possible to control connections. Connection settings defined through XenApp policies also supersede all other connection settings in your environment, including those specified at the operating system level and when you publish an application

Application Publishing
You can define connection settings on a per-application basis when you are publishing a resource. Settings you can define include the maximum number of connections to an application, importance level of the application, maximum number of instances an application can run in the farm, types of connections that can access an application, audio properties, and encryption requirements.

Active Directory
Citrix provides a Group Policy Object (GPO) template, icaclient.adm, that contains Citrix-specific rules for securing client connections. This GPO template lets you configure rules for network routing, proxy servers, trusted server configuration, user routing, remote client devices, and the user experience. For more information, see the Citrix Receiver for Windows documentation.

241

Preventing Specific Client Connection Types


You can specify the types of client connections from which users can start sessions. For example, to increase security, you can specify that users must connect through Access Gateway Advanced Edition (Version 4.0 or later). This allows you to benefit from filters created in Access Gateway.

To configure connection access control


1. Configure the Connection access control Computer policy setting with one of the following options:
q

Any connections allows access to published applications through any connection. Citrix Access Gateway, Citrix Receiver, and Web Interface connections only allows access to published applications through the listed connections, including any version of Access Gateway. Denies access through any other connection. Citrix Access Gateway connections only allows access to published applications only through Access Gateway Advanced Edition servers (Version 4.0 or later).

242

Specifying Connection Limits


To help maintain the availability of resources in a server farm, you can limit the number of connections to servers and published applications. Setting connection limits helps prevent:
q

Performance degradation and errors resulting from individual users who run more than one instance of a published application at the same time Denial-of-service attacks by malicious users who run multiple application instances that consume server resources and connection license counts Over-consumption of resources by non-critical activities such as Web browsing

Connection limits, including the option to log denials resulting from connection limits, are configured in Computer policy settings. (You cannot configure connection limits in the plug-ins.) There are two types of connection limits:
q

Concurrent connections to the server farm - Restricts the number of simultaneous connections that each user in the server farm can establish. See Limiting Connections to a Server Farm. Published application instances - Restricts the total number of instances of a published application that can run in the server farm at one time, and prevents users from launching more than one instance of a published application. See Limiting Application Instances. .

By default, XenApp does not limit connections in any way.

243

Limiting Connections to a Server Farm


To conserve resources, you can limit the number of concurrent connections that users are permitted to establish. Limiting connections can help prevent over-consumption of server resources by a few users. Active sessions and disconnected sessions are counted for the total number of concurrent connections. For example, you can set a limit of three concurrent connections for users. If a user has three concurrent connections and tries to establish a fourth, the limit you set prevents the additional connection. A message tells the user that a new connection is not allowed. Connection control affects users only if a connection attempt is prevented. If a users number of connections exceeds a connection limit, the plug-in displays a message that describes why the connection is not available. You can also limit the number of connections on a farm by ensuring that session sharing is enabled.

To specify the total number of sessions that can logon to a server


When this setting is used, users can still launch additional sessions, as long as the limit has not been reached. 1. Configure the following Citrix Computer policy settings:
q

Limit user sessions. The maximum number of concurrent connections a user can establish, in the range 0-8192. A value of 0 indicates no connections.

Limits on administrator sessions. Enables or disables connection limit enforcement for Citrix administrators. Limiting connections for Citrix administrators can adversely affect their ability to shadow other users. Local administrators are exempt from the limit so they can establish as many connections as necessary.
q

To specify the maximum number of connections a user can make to the server farm at a given time
When this setting is used and the specified number is reached, the user cannot launch additional sessions, even if the server has availability. 1. Configure the Citrix User Policy Concurrent logon limit setting.

244

Sharing Sessions and Connections


Depending on the Receiver or plug-in, when a user opens an application, it can either appear in a seamless or non-seamless window. These window modes are available for Citrix Receiver for Windows, Web Interface, and other plug-ins.
q

In seamless window mode, published applications and desktops are not contained within an ICA session window. Each published application and desktop appears in its own resizable window, as if it is physically installed on the client device. Users can switch between published applications and the local desktop. In non-seamless window mode, published applications and desktops are contained within an ICA session window. This creates the effect of the application appearing in two windows.

The mode that you choose typically depends on the type of client device that your users will be using and whether you are publishing a desktop or individual applications. Desktops are typically published in non-seamless window mode. This table provides examples of when you might want to publish desktops and applications.

If your users will be using... Local computers Local computers with locally installed applications Thin clients Kiosks

then you... Might want to publish desktops or individual applications. Might want to publish individual applications. Must publish desktops.

Might want to publish desktops, which allows the user to have a more holistic experience and provide more control from a security perspective. When a user launches a published application, Receiver or the plug-in establishes a connection to a XenApp server and initiates a session. If session sharing is not configured, a new session is opened on the server each time a user opens an application. Likewise, every time a user opens a new application, a new client connection is created between the client device and the server. Session sharing is a mode in which more than one published application runs on a single connection. Session sharing occurs when a user has an open session and launches another application that is published on the same server; the result is that the two applications run in the same session. For session sharing to occur, both applications must be hosted on the same server. Session sharing is configured by default when you specify that applications appear in seamless window mode. If a user runs multiple applications with session sharing, the session counts as one connection. If you want to share sessions, ensure all applications are published with the same settings. Inconsistent results may occur when applications are configured for different requirements, such as encryption. Note: Session sharing is not supported on PocketPC clients. 245

Sharing Sessions and Connections Session sharing takes precedence over load balancing, except when a server is fully loaded.

246

Limiting Application Instances


By default, XenApp does not limit the number of instances of a published application that can run at one time in a farm. By default, a user can launch more than one instance of a published application at the same time. You can specify the maximum number of instances that a published application can run at one time or concurrently in the server farm. For example, you can publish an application and set a limit of 30 concurrent instances in the farm. Once 30 users are running the application at the same time, no more users can launch the application because the limit of 30 concurrent instances was reached. Another connection control option lets you prevent any user from running multiple instances of a particular published application. With some applications, running more than one instance in a single user context can cause errors. You can apply application limits independently to each published application. For example, you can apply the limitations on total concurrent instances and multiple instances by a single user to one published application. You can limit only the total concurrent instances of another application. You can configure a third application to limit launching of multiple instances by individual users. Note: Connection control options apply to published applications and published desktops only and do not affect published content such as documents and media files that execute on the client device.

To specify a limit for a published application or desktop


1. From the AppCenter, select the farm, then select Applications. 2. Select the application or desktop you want to modify. In the Action menu, select Application properties. 3. In the Properties tree, select Limits. Select one or both of the following options:
q

Limit instances allowed to run in server farm. Enter the maximum number of instances that can run at one time in the server farm without regard to who launches the application. For example, if you enter 10 and a user tries to launch the application when 10 instances are running, the server denies the connection request and records the time and the name of the published application in the System log.

Allow only one instance of application for each user. Prevents any user from running more than one instance of this application at the same time.

247

Logging Connection Denial Events


Event logging records an entry in the System log each time a server denies a user connection because of a connection control limit. Each server records the data in its own System log. By default, this type of event logging is disabled. You can configure XenApp to log when limits are reached (and connections denied) for the following:
q

Maximum connections per user Application instance limits Application instances per user

To enable or disable logging of connection denial events, configure the Logging of logon limit events Citrix Computer policy setting.

248

Configuring the ICA Listener


To configure the ICA listener, use the Citrix ICA Client Configuration Tool (CtxICACfg.exe). For more information, see CTX125139. Important: Do not use Microsoft Remote Desktop Services tools to configure the ICA listener.

249

Preventing User Connections During Farm Maintenance


You might want to prevent logons to a server when you install software or perform other maintenance or configuration tasks. This is helpful when you are installing applications that require there be no active sessions on the server. It also lets you restart the server without having to wait for users to disconnect. By default, logons are enabled when you install XenApp and users can launch an unlimited number of sessions and instances of published applications. You can prevent users from connecting to a server in the farm by disabling logons.

To disable logons on a server


1. From the AppCenter, select the server. 2. In the Actions pane, select Other Tasks > Logon Control > Prohibit logons only.

Note: To reenable disabled logons, select Other Tasks > Logon Control > Allow logons and reconnections.

250

Optimizing User Sessions for XenApp


XenApp includes various HDX features that allow you to enhance user experience by maintaining session activity and improving session responsiveness. Network latency and bandwidth availability can impact the performance of connections to published applications and content. These HDX technologies allow you to improve connection speed and responsiveness during user sessions. Instructions for configuring these features are provided in the corresponding topics:
q

MDX MediaStream Multimedia Acceleration. Allows you to control and optimize the way XenApp servers deliver streaming audio and video to users. HDX MediaStream Flash. Allows you to control and optimize how XenApp servers deliver Adobe Flash animations to users. HDX 3D Image Acceleration. Enables you to adjust the quality of photographic image files as they appear on client devices and the amount of bandwidth the files consume on their way from the server to the client. HDX 3D Progressive Display. Allows you to improve interactivity when displaying high-detail images by temporarily increasing the level of compression (decreasing the quality) of the image when it is first transmitted over a limited bandwidth connection, providing a fast (but low quality) initial display. If the image is not immediately changed or overwritten by the application, it is then improved in the background to produce the normal quality image, as defined by the normal lossy compression level. SpeedScreen Latency Reduction. Helps reduce a users perception of latency when typing and clicking. It provides visual feedback for mouse clicks and Local Text Echo; a feature that accelerates the display of input text, effectively shielding the user from experiencing latency on the network. HDX Broadcast Display. HDX Broadcast Display provides control over settings that let you reserve bandwidth by limiting session-memory usage and discarding obsolete queued images on the client. HDX Broadcast Browser. HDX Broadcast Browser provides control over whether or not the servers in your network will respond to broadcast messages sent from Citrix Receiver. You may reduce bandwidth consumption if you disable these options.

251

Optimizing Audio and Video Playback


HDX MediaStream Multimedia Acceleration improves the users experience of accessing published audio-visual applications and content. Enabling this feature 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. In addition, it reduces use of network bandwidth and server processing and memory because compressed multimedia files are intercepted and forwarded to the client to be uncompressed. This feature optimizes multimedia playback through published instances of Internet Explorer, Windows Media Player, and RealOne Player. It offers significant performance gains in these areas:
q

User Experience. Multimedia playback in sessions is much smoother. Server CPU Utilization. The client device decompresses and renders multimedia content, freeing server CPU utilization. Network Bandwidth. Multimedia content is passed over the network in compressed form, reducing bandwidth consumption.

Note: With HDX MediaStream Multimedia Acceleration enabled, RealOne Players built-in volume and balance controls do not work within client sessions. Instead, users can adjust volume and balance from the volume controls available from the device notification area. Without HDX MediaStream Multimedia Acceleration, the cumulative cost of several users playing multimedia content in sessions simultaneously is high, both in terms of server CPU utilization and network bandwidth consumption. When you play multimedia content in a session, the server decompresses and renders the multimedia file, which increases the servers CPU utilization. The server sends the file over the network in uncompressed form, which consumes more bandwidth than the same file requires in compressed form. With HDX MediaStream Multimedia Acceleration, the server streams multimedia to the client in the original, compressed form. This reduces bandwidth consumption and leaves the media for the client device to decompress and render, thereby reducing server CPU utilization. HDX MediaStream Multimedia Acceleration optimizes multimedia files that are encoded with codecs (compression algorithms) that adhere to Microsofts DirectShow, DirectX Media Objects (DMO), and Media Foundation standards. DirectShow and Media Foundation are application programming interfaces (APIs) that allow, among other things, multimedia playback. 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. Generally, if you can play back a given multimedia file locally on a given client device, you can play back the same file on the same client device within a session. Users can download a wide range of codecs, such as those supported by Windows Media Player or RealOne Player, from vendor Web sites. Users accessing audio-visual applications on servers on which HDX MediaStream Multimedia Acceleration is enabled use a little more memory but far less bandwidth than when this feature is disabled. Users use only a little more memory or bandwidth when accessing audio-visual applications compared to regular enterprise applications.

252

Optimizing Audio and Video Playback To allow users to run multimedia applications in ICA sessions, turn on audio or give the users permission to turn on audio themselves in Citrix Receiver. By default, all other plug-ins and methods are configured with audio enabled and optimized for speech sound quality. Other requirements for using HDX MediaStream Multimedia Acceleration are:
q

Users must be running Citrix Receiver. The user device must have the same memory and processing speed as is needed for playing multimedia locally. The correct codec to decompress the media file type used (MPEG for example) must reside on the user device. Windows devices have the most common codecs already installed. If you need additional codecs, you can download them from the Web sites of the manufacturers of media players.

Note: To make Windows Media Player 11 and Media Foundation components available on your XenApp server, install and configure the Microsoft Windows Server 2008 Desktop Experience in the Server Manager. Applications and media formats supported by HDX MediaStream Multimedia Acceleration are:
q

Applications based on Microsofts DirectShow, DirectX Media Objects (DMO), and Media Foundation filter technologies such as Windows Media Player, RealPlayer. Applications like Internet Explorer and Microsoft Encarta are also supported, as they leverage Windows Media Player. Both file-based and streaming (URL-based) media formats: WAV, all variations of MPEG, unprotected Windows Media Video (WMV), and Windows Media Audio (WMA).

Note: HDX MediaStream Multimedia Acceleration does not support media files protected with Digital Rights Management (DRM). When the quality of media playing on a user device deteriorates, possible solutions are:
q

If video appears in slowly changing slides while audio is intact or audio becomes choppy, this is caused by low bandwidth. Arrange for users to play media on the network where more bandwidth is available. If audio and video are not synchronized, generally only the video or audio is played using HDX MediaStream Multimedia Acceleration. This can happen if a client device lacks a codec for either video or audio. Install the needed codec on the client or use media content on the server for which clients have both codecs.

By default, HDX MediaStream Multimedia Acceleration is enabled at the server farm level.

253

Configuring Windows Media Redirection


Configure Windows Media Redirection in a Citrix policy. Note: By default, audio is disabled on the client. To allow users to run multimedia applications in sessions, turn on audio or give the users permission to turn on audio themselves on their user devices. 1. Configure the following Citrix Computer policy setting:
q

Windows Media Redirection. Enables or disables the feature. Windows Media Redirection buffer size. Specifies the buffer size in seconds, in the range 1-10; requires enabling the Windows Media Redirection default buffer size use option. You can see how much server memory the selected buffer can use by changing the buffer time. Windows Media Redirection buffer size use. Enables or disables use of a buffer. When this option is enabled, specify the buffer size with the Windows Media Redirection default buffer size option

254

Optimizing Flash Content


HDX MediaStream server-side Flash functionality allows you to optimize the way XenApp renders and delivers Adobe Flash content to users. To display Flash content in sessions, you must have the Flash plug-in and the corresponding ActiveX control installed in the Web browser before you publish it. Users playing Flash content in published applications might observe poor rendering quality of the animation, slow session responsiveness, or a combination of both. This occurs when Adobe Flash Player, which renders the content on the server, starts in high-quality mode by default. While this guarantees the highest possible rendering mode for each frame, it also means that each frame consumes considerable bandwidth on its way to the user. HDX MediaStream server-side Flash functionality improves the users session responsiveness by forcing the Flash Player to use simpler graphics (for example, no smoothing or anti-aliasing). This feature also reduces the amount of processing power that is required to render Flash content. By default, HDX MediaStream server-side Flash functionality is enabled at the server farm level. However, if HDX MediaStream client-side Flash functionality is enabled, server-side rendering is overridden. 1. Configure the Flash quality adjustment Citrix User policy setting with one of the following options:
q

Optimize Adobe Flash animation options for all connections. Select this option to always reduce the amount of Flash data sent to users. The result is minimized CPU usage on the servers on which users are using Flash within Internet Explorer. Optimize Adobe Flash animation options for low bandwidth connections only. Select this option to improve responsiveness when Flash content is sent to users on restricted bandwidth connections (under 150Kbps). On restricted bandwidth connections, such as over a WAN, less data is downloaded and the quality of Flash content is lower. When bandwidth is not limited, for example on a LAN, users get higher quality Flash animation.

Do not optimize Adobe Flash animation options. Select this option if bandwidth is not limited. 2. To reduce bandwidth consumption and improve video playback and server scalability, configure the Citrix Computer policy setting for Queueing and tossing. Configuring this setting can cause animations to become choppy due to dropped frames.
q

255

Optimizing Throughput of Image Files


The size of image files affects the amount of time the files take to travel from server to client. Often, image files contain redundant or extraneous data that is of little benefit to the user and slows down the users session while downloading and rendering. Using lossy image compression, SpeedScreen Image Acceleration lets you find a balance between the quality of photographic image files as they appear on client devices and the amount of bandwidth the files consume on their way from server to client. SpeedScreen Image Acceleration applies a lossy compression scheme to reduce the size of image files that the server sends to the client for faster throughput. The compression scheme removes redundant or extraneous data from the files while attempting to minimize the loss of information. Under most circumstances, the data loss is minimal and its effect nominal. However, Citrix recommends that you use discretion in applying this feature where preservation of image data may be vital, as in the case, for example, of X-ray images. This feature is enabled by default. Use policy settings to override the default settings and accommodate different user needs by applying different levels of image compression to different connections. 1. Configure the Lossy compression level Citrix User policy setting with one of the following options: Level High Medium (default) Low Image quality Low Good High Bandwidth requirements Lowest Lower Higher

None Same as original Highest Choose none or low compression for users who need to view images at original or near original quality levels. If this policy setting is not configured, medium compression is used for all connections, which amounts to slightly better performance due to slightly lower image quality. To configure Image Acceleration without enabling Progressive Display, after configuring the policy setting for the lossy compression level, configure the Progressive compression level Citrix User policy setting with the None option.

256

Optimizing Display of Image Files


You can enable Progressive Display to increase the performance of displaying images or parts of images that are changing. Progressive Display speeds the initial display of an image file by choosing an increased compression level while an image is dynamic. This initial display is then sharpened up to normal quality in the background if the image is not immediately changed or overwritten in the application. The quality of the final image is controlled by Image Acceleration. Progressive Display can improve the performance not only of applications that render and display images, but also those parts of an image that are dynamic, such as when scrolling through a PDF or similar document. Configure the Progressive compression level Citrix User policy setting with the desired level (Low, Medium, High, Very high, or Ultra high), and configure the Lossy compression level Citrix User policy setting to None.

257

Optimizing Keyboard and Mouse Responsiveness


SpeedScreen Latency Reduction is a collective term used to describe features such as Local Text Echo and Mouse Click Feedback that help enhance user experience on a slow network.

Mouse Click Feedback


On high latency connections, users often click the mouse multiple times because there is no visual feedback that a mouse click resulted in an action. Mouse Click Feedback, which is enabled by default, changes the appearance of the pointer from idle to busy after the user clicks a link, indicating that the system is processing the users request. When the user clicks the mouse, the ICA software immediately changes the mouse pointer to an hourglass to show that the users input is being processed. You can enable and disable Mouse Click Feedback at the server level.

Local Text Echo


On high latency connections, users often experience significant delays between when they enter text at the keyboard and when it is echoed or displayed on the screen. When a user types text, the keystrokes are sent to the server, which renders the fonts and returns the updated screen to the client. You can bridge the delay between keystroke and screen redraw by enabling Local Text Echo. Local Text Echo temporarily uses client fonts to immediately display text a user types while the screen redraw from the server is in transit. By default, Local Text Echo is disabled. You can enable and disable this feature both at the server and application level. You can also configure Local Text Echo settings for individual input fields within an application. Note: Applications that use non-standard Windows APIs for displaying text may not support Local Text Echo.

258

Configuring SpeedScreen Latency Reduction


SpeedScreen Latency Reduction Manager, a tool provided with XenApp, allows you to configure SpeedScreen Latency Reduction settings for a XenApp server, for single or multiple instances of an application, as well as for individual input fields within an application. You can also use it as a troubleshooting tool to fine-tune SpeedScreen Latency Reduction behavior for applications, or input fields within an application, that exhibit incompatibility with this SpeedScreen feature. SpeedScreen Latency Reduction Manager must be installed on a XenApp server, and can be used to customize SpeedScreen Latency Reduction settings only on that server. To launch SpeedScreen Latency Reduction Manager, select SpeedScreen Latency Reduction Manager from the Citrix > Administration Tools program group in the Start menu. Note: To run the Speedscreen Latency Reduction Manager with the User Account Control (UAC) enabled, you must be a domain administrator, delegated administrator, or part of the Administrators group on the local computer, or you will be prompted for administrator credentials. Through SpeedScreen Latency Reduction Manager, you can configure common SpeedScreen Latency Reduction settings for all applications on a server or select custom settings for individual applications. Before you can configure any settings, you must add the application.

259

Adjusting SpeedScreen Latency Reduction for an Application


If a published application exhibits abnormal behavior after it is configured to use SpeedScreen Latency Reduction, you can use the Add New Application wizard included with SpeedScreen Latency Reduction Manager to adjust latency reduction functionality for the selected application, or all instances of the selected application on the server. To optimize usability of the application, use this wizard to adjust, turn on, or turn off SpeedScreen Latency Reduction for the application. Note: The application must be running before you can use this wizard to modify existing settings.

To adjust SpeedScreen Latency Reduction for an application


If a published application exhibits abnormal behavior after it is configured to use SpeedScreen Latency Reduction, you can use the Add New Application wizard included with SpeedScreen Latency Reduction Manager to adjust latency reduction functionality for the selected application, or all instances of the selected application on the server. To optimize usability of the application, use this wizard to adjust, turn on, or turn off SpeedScreen Latency Reduction for the application. Note: The application must be running before you can use this wizard to modify existing settings. Before you can adjust Speedscreen Latency Reduction for an application, you must add the application to the Speedscreen Latency Reduction Manager. 1. From the Start menu, select All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager. 2. From the Applications menu of SpeedScreen Latency Reduction Manager, select New to start the wizard and follow the prompts. 3. Use the Define the Application screen to select an application instance on the server. To specify the application, use one of these methods:
q

Click the icon at the bottom of the page and drag the pointer onto the window of an application. The application must be running when you select it.

Click the Browse button and navigate to the application. 4. Specify whether Local Text Echo is enabled or disabled on the application by selecting or clearing the Enable local text echo for this application check box. For a definition of Local Text Echo, see Optimizing Keyboard and Mouse Responsiveness
q

260

Adjusting SpeedScreen Latency Reduction for an Application 5. Specify whether the setting you selected in the previous step should be applied to all instances of the application on the server or just the instance selected.

Test all aspects of an application with Local Text Echo in a non-production environment before enabling it to ensure that the display is acceptable to users. When you configure SpeedScreen Latency Reduction Manager on a particular server, the settings are saved in the ss3config folder in the Citrix installation directory of that server. You can propagate the settings to other servers by copying this folder and its contents to the same location on the other servers. Note: If you plan to propagate SpeedScreen Latency Reduction Manager settings to other servers, select Apply settings to all installations of the selected application when configuring Local Text Echo through the wizard. Paths to published applications might differ from one server to another; therefore, applying the settings to all instances of the selected application ensures that the settings apply regardless of where the application is located on the destination server.

To configure latency reduction settings for all applications on a server


1. From the Start menu, select All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager. 2. From the Application menu, select Server Properties. The Server Properties dialog box containing existing settings for the selected server appears. 3. Configure the SpeedScreen Latency Reduction settings that you want to be applied to all of the applications on the server. All users connecting to the server benefit from the SpeedScreen options you set here. Changes made to SpeedScreen Latency Reduction settings at an application level override any server-wide settings.
q

Enable local text echo as default for all applications on this server. Select this check box to enable Local Text Echo for all applications on the server. Enable mouse click feedback as default for all applications on this server. Select this check box to enable Mouse Click Feedback for all applications on the server. Latency threshold times for SpeedScreen (in milliseconds). Latency threshold times are used when the client device setting for SpeedScreen is set to Auto.
q

High latency threshold. Specify a threshold value above which SpeedScreen options should be enabled.

Low latency threshold. Specify a threshold value below which SpeedScreen options should be disabled. For a definition of Local Text Echo and Mouse Click Feedback, see Optimizing Keyboard and Mouse Responsiveness.
q

261

Adjusting SpeedScreen Latency Reduction for an Application

To configure custom latency reduction settings for an individual application


1. From the Start menu, select All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager. 2. In the SpeedScreen Latency Reduction Manager, select the application. 3. From the Application menu, select Properties. The Application Properties tab containing existing SpeedScreen Latency Reduction settings for the selected application appears. It contains this information:
q

Application Name. The application executable name appears here; for example, Excel.exe.

Path to Application. The path to the application executable appears here; for example, C:\Microsoft Office\Excel.exe. 4. If desired, configure application settings:
q q

Disable local text echo for this application. The current setting for Local Text Echo is displayed. Select the check box to disable Local Text Echo for this application. Clear the check box to enable it. Limit local text echo for this application. The current Local Text Echo setting for the application appears. Select the check box to limit Local Text Echo functionality for this application, and select the type of text display you need from the drop-down list. Forces Speedscreen to treat all input fields in the selected application in native mode. Select the check box if you configure a setting that forces SpeedScreen to treat all input fields in the selected application in native mode.

262

To configure latency reduction settings for input fields in an application


Input fields in an application are fields where text can be added. You can use SpeedScreen Latency Reduction Manager to set latency reduction behavior for selected input fields in a configured application to reduce delays between when users enter text at the keyboard and when it is echoed or displayed on the screen. 1. From the Start menu, select All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager. 2. Select an application. 3. From the Applications menu, select Properties. The Application Settings window appears. 4. Select the Input Field Configuration tab, then configure these settings as needed.
q

The Configured Input Field List displays the list of configured input fields. SpeedScreen Latency Reduction uses a window hierarchy to identify the input fields that need special settings. The entries shown in the tree view are the window class names of the configured fields. For example, _WwG is the window class name of the main document window in Microsoft Word.
q

Click New to run the Advanced Input Field Compatibility wizard to add a new input field. This wizard guides you through the process of configuring SpeedScreen Latency Reduction settings for an input field.

Click Delete to delete the selected input field from the Configured Input Field List. Enable local text echo for this input field enables Local Text Echo. If this check box is selected, you can apply more Local Text Echo settings to the selected field.
q

Limit local text echo forces behavior in input fields in nonstandard applications that may not behave correctly. Select one of the two available settings:
q

Display text in place ensures text is echoed in place.

Display text in a floating bubble ensures text is echoed within a floating bubble. Reduce font size forces input fields in non-standard applications to display text at a reduced font size. Use this setting when input fields in non-standard applications display misaligned text, oversized fonts, or other undesirable font behavior. Choose the percentage by which to reduce the font size. Percentage values available are 10%, 20%, and 30%.
q

Use system default colors forces non-standard input fields to use system default colors. SpeedScreen Latency Reduction tries to auto-detect the text and background colors used in input fields; however, non-standard input fields

263

To configure latency reduction settings for input fields in an application sometimes report incorrect or inadequate information. As a result, text echo in input fields on nonstandard applications can appear corrupted. This setting turns off auto-detection and controls how system default colors are applied to input fields.
q

Choose Both the text and background to apply system default colors to both text and background.

Choose The background only to apply system default colors only to the background. Input field is a password controls how hidden characters are displayed in non-standard input fields. Typically, hidden characters are located in password entry fields. Text echo in non-standard input fields might make these hidden characters appear as normal text, compromising security. This setting forces hidden characters to display as asterisks or spaces.
q q

Choose Hidden characters denoted by * if you want Local Text Echo for such input fields to be replaced by asterisks. Choose Hidden characters denoted by spaces if you want Local Text Echo for password input fields to be replaced by spaces.

264

To create exception entries for non-standard input fields in an application


Some input fields do not conform to standard Windows behavior and thus do not work correctly with SpeedScreen Latency Reduction. You can create exception entries for such fields, while still providing minimal latency reduction functionality for the rest of the application. The Input Field Compatibility wizard included with SpeedScreen Latency Reduction Manager guides you through the process of selecting non-standard input fields and creating exception entries for them. Note: The application must be running before you can configure an input field within it. 1. Start the application. 2. Select Start > All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager. 3. From the Applications menu in SpeedScreen Latency Reduction Manager, select Properties. The Application Settings window appears. 4. Select the Input Field Configuration tab. Click New to start the wizard and follow the prompts. 5. With the application running, select the input field you want to configure and complete these steps: a. Drag the pointer onto the input field window for which SpeedScreen behavior needs to be customized. b. If the SpeedScreen Latency Reduction Manager window is obscuring the target input field, check the Hide SpeedScreen Latency Reduction Manager check box. This causes the SpeedScreen Latency Reduction Manager window to be hidden from view. 6. To define the level of compatibility for the input field, select the level of SpeedScreen Latency Reduction compatibility to apply to the selected input field. Use the slider bar to select the desired compatibility level. The default compatibility level is Auto, which provides full SpeedScreen Latency Reduction functionality. However, because the field being configured is not displaying the desired behavior, downgrade the latency reduction functionality level to Medium, Low, or Off.
q

Medium Compatibility. Use this level of compatibility for input fields that are incompatible with the default Auto setting. Text echo appears in place with limited acceleration. Low Compatibility. If an input field is incompatible with both the Auto and Medium compatibility settings, select Low. Text echo appears in a floating text bubble rather than within the input field.

265

To create exception entries for non-standard input fields in an application


q

Off, or Zero Compatibility. If an input field is incompatible with Auto, Medium, and Low compatibility settings, disable Local Text Echo for that field by selecting Off.

266

Configuring HDX Broadcast Display Settings


To configure HDX Broadcast display settings
1. To improve the response when graphics are sent to the client, configure the Citrix Computer policy Queueing and tossing setting. Queued images that are replaced by another image are discarded. This is useful when bandwidth is limited. A drawback to selecting this option is that it can cause animations to become choppy because intermediate frames get dropped. 2. To make scrolling smoother because sections of an image can be retrieved from the cache, configure the Citrix Computer policy Image caching setting. 3. Enter the maximum memory to be used on the server for each client connection with the Citrix Computer policy Display memory limit setting. You can specify an amount in kilobytes from 128 to 131072. Using more color depth and higher resolution for connections requires more memory. You can calculate the maximum memory required by using this equation: (color depth in bits per pixel / 8) * vertical resolution in pixels * horizontal resolution in pixels = memory required in bytes For example, if the color depth is 24, the vertical resolution is 600, and the horizontal resolution is 800, the maximum memory required is: (24bpp / 8) * 600 pixels * 800 pixels = 1440000 bytes of memory required You can specify 1440KB in maximum memory to handle connections with these settings. 4. For the Citrix Computer policy Display mode degrade preference setting, configure one of the following options:
q

Degrade color depth first. Select this option if you want color depth to be reduced before resolution is lowered when the session memory limit is reached.

Degrade resolution first. Select this option if you want resolution to be lowered before color depth when the session memory limit is reached. 5. To display a brief explanation to the user when a session is degraded, configure the Citrix Computer policy Notify user when display mode is degraded setting. Possible reasons for degradation include exceeding the memory limit and connecting with a client that cannot support the requested parameters.
q

267

Enhancing the User Experience With HDX


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 media-rich user environments.

Quick Links
q

Configuring HDX MediaStream Flash Redirection Configuring Audio Multimedia Conferencing with HDX RealTime Increasing 2D and 3D Application Scalability and Performance Assigning Priorities to Network Traffic Adding Dynamic Windows Preview Support

268

Configuring HDX MediaStream Flash Redirection


HDX MediaStream Flash Redirection allows you to move the processing of most Adobe Flash content to LAN- and 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.

Second Generation Flash Redirection


Flash Redirection has been revised for use with:
q

Citrix XenApp 6.5 Citrix XenDesktop 5.5 Citrix Receiver 3.0

New second generation Flash Redirection features include:


q

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.

System Requirements for Flash Redirection


The following is accurate at the time this content was published. See https://www.citrix.com/support/product-lifecycle/product-matrix for more information about supported versions of Citrix products.

269

Configuring HDX MediaStream Flash Redirection For user devices:


q

Citrix Receiver 3.0 (formerly called the online plug-in) 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 for Windows - Other Browsers is installed on the user device. The version of the Flash Player on the user device must be equal to or higher than the Flash Player for Windows Internet Explorer installed on the server running Citrix XenApp 6.5 or Citrix XenDesktop 5.5. 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 Citrix XenApp 6.5 or Citrix XenDesktop 5.5:


q

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 9, Internet Explorer 8, or Internet Explorer 7. Second generation Flash Redirection on XenDesktop 5.5 supports Internet Explorer 9.

In order to enable support for Internet Explorer 9 on the XenApp 6.5 server, an edit to the registry of the XenApp server is required. 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.
q

For a 32-bit operating system: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HdxMediaStreamForFlash\Server\PseudoServer Add the entry named IEBrowserMaximumMajorVersion with a DWORD value = 00000009.

For a 64-bit operating system

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\HdxMediaStreamForFlash\Server\PseudoServ Add the entry named IEBrowserMaximumMajorVersion with a DWORD value = 00000009.

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.

270

Configuring HDX MediaStream Flash Redirection on the Server


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:
q

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

Result Second generation Legacy mode

Second generation on a user device Legacy mode and Legacy mode on a server The Enable HDX MediaStream Flash Redirection on the user device setting on the user device must also be enabled.

271

Configuring HDX MediaStream Flash Redirection on the Server To use the backward compatibility feature:
q

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

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.

Enable Flash acceleration

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.

272

Configuring HDX MediaStream Flash Redirection on the Server

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. While server-side content fetching works with most Internet sites, it is intended for use with Intranet sites and internal Flash applications. Note: Server-side content fetching does not support Flash applications using Real Time Messaging Protocols (RTMP). Instead, server-side rendering for such sites is used. 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:
q

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 http:// or 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.

273

Configuring HDX MediaStream Flash Redirection on the Server 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:
q

Rendered on the user device. Rendered on the server. Blocked from rendering.

Consider the following when configuring the Flash URL compatibility list setting:
q

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

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: 274

Configuring HDX MediaStream Flash Redirection on the Server


q

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. For best results, consider using a color not typically used on the Web page, such as black. Use a trailing wildcard to enable matching in all child URLs, for example, http://www.sitetomatch.com/* FF0000.

275

Configuring HDX MediaStream Flash Redirection on the User Device


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 (HdxFlash-Client.adm), available in:
q

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:
q

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.

276

Configuring HDX MediaStream Flash Redirection on the User Device 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:
q

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:
q

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

277

Configuring HDX MediaStream Flash Redirection on the User Device 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:
q

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:
q

The user device does not have direct access to the Internet. The user device connects to internal sites through Citrix Access Gateway.

Note: Server-side content fetching does not support Flash applications using Real Time Messaging Protocols (RTMP). Instead, server-side rendering for such sites is used. 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 278

Configuring HDX MediaStream Flash Redirection on the User Device 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. 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 deleted at the end of the session.

Enabled

Enabled (persistent caching)

Enabled (temporary caching)

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:
q

Disabled Enabled Enabled (persistent caching)

Enabled (temporary caching) 6. For the policy to take effect:


q

279

Configuring HDX MediaStream Flash Redirection on the User Device


q

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:
q

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.

280

Configuring Audio
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:
q

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:
q

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.

281

Configuring Audio 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.
q

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.

282

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

283

Configuring Audio

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.

284

Avoiding Echo During Multimedia Conferences With HDX RealTime


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 Citrix Receiver 3.0 for Windows 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\EchoCancellation. 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\ClientAudio\EchoCancellation. 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.

285

Video Conferencing with HDX RealTime Webcam Video Compression


HDX RealTime provides your users with a complete desktop multimedia conferencing feature.

System Requirements for HDX RealTime Webcam Video Compression


The following is accurate at the time this content was published. See https://www.citrix.com/support/product-lifecycle/product-matrix for more information about supported versions of Citrix products. The following conditions are required to use the HDX RealTime Webcam Video Compression:

Install Citrix Receiver 3.0 for Windows, formerly Citrix online plug-in, or Citrix Online Plug-in 12.1 for Windows on the user device. Install Microsoft Office Communications Server 2007 in the same environment as the computer running XenApp. This is not a published application. Note: Best practice indicates installing Microsoft Office Communications Server 2007 on a different computer than XenApp.

Publish Microsoft Office Communicator 2007 on your XenApp server. Ensure the user device has the appropriate hardware to produce sound. Assign one processor per user per session, whether physical or virtual devices are used for video conferencing. Use the web camera default settings. Enable the following policies settings:
q

Client audio redirection Client microphone redirection Multimedia conferencing

Windows Media Redirection Install Drivers for web cameras on the user device. Where possible, use drivers obtained from the camera manufacturer, rather than from a third party.
q

286

Video Conferencing with HDX RealTime Webcam Video Compression Note: Only one web camera is supported at a time. If a device has multiple web cameras attached, HDX RealTime tries the first camera found, continuing in succession until a connection is made.

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. Client audio redirection is enabled by default.

Configuring Client Microphone Redirection


Client microphone redirection is a Citrix User Policy setting. It allows or prevents the redirection of microphones. Client microphone redirection is enabled by default.

Configuring Multimedia Conferencing


Multimedia conferencing is a Citrix Computer Policy setting. This policy allows or prevents support for multimedia conferencing applications. By default, Multimedia conferencing is enabled.

Configuring Windows Media Redirection


Windows Media Redirection is a Citrix Computer 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.

287

Increasing 2D and 3D Application Scalability and Performance


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.

288

Assigning Priorities to Network Traffic


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:
q

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. The Secure Sockets Layer (SSL) connections are only supported when the connections are traversing an Access Gateway that supports multi-stream. When running on an internal corporate network, multi-stream connections with SSL are not supported (this includes SSL Relay, on the XenApp server). 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) or Secure Sockets Layer ( SSL).

To assign priorities to network traffic


To set quality of service for multiple streaming connections, you must configure:
q

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, a Citrix Users Policy setting in XenDesktop and a Citrix User Policy setting in XenApp.

289

Assigning Priorities to Network Traffic 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. Important: Firewalls on Virtual Desktop Agents or XenApp Server must be explicitly configured to allow the additional TCP traffic as part of the Multi-Port Policy setting. For the policies to take effect, users must log off and then log on to the network.

290

Adding Dynamic Windows Preview Support


With the Dynamic Windows Preview feature enabled, the following Windows Aero preview options are available to XenApp users with published applications:
q

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.

Dynamic Windows Preview is available for user devices running:


q

Citrix Receiver 3.0 for Windows Windows 7 configured for Aero

To configure Dynamic Windows Preview


Dynamic Windows Preview is enabled by default. You can disable and then enable the feature with the Dynamic Windows Preview computer policy setting on the XenApp server.

291

Configuring Read-Only Access to Mapped Client Drives


With the Citrix User Policy setting Read-only client drive access, you can control whether users can copy files from their virtual environments to their user devices. This policy setting is only applicable for XenDesktop 5.5 Virtual Desktop Agent and XenApp 6.5 VM Hosted Apps sessions. When enabled, files and folders on mapped client-drives cannot be added or modified from within the session. Files and folders on mapped client-drives are available in read-only mode only. When disabled, files and folders on mapped client-drives are available in read/write mode from within the session. By default, the setting is disabled. Important: When using this setting, be sure to include Client drive redirection in the policy and that it is set to Allowed.

292

Securing Server Farms


Consult with your organizations security experts for a comprehensive security strategy that best fits your needs. The Citrix Receiver is compatible with and functions in environments where the Microsoft Specialized Security - Limited Functionality (SSLF) desktop security template is used. These templates are supported in the Microsoft Windows XP and Vista platforms. Refer to the Windows XP and Windows Vista security guides available at http://technet.microsoft.com for more information about the template and related settings. In deployments where the XenApp server is part of an organization unit (OU) to which a Microsoft Specialized Security Limited Functionality Member Server (WS08R2-SSLF-Member-Server 1.0) or Enterprise Configuration Member Server (WS08R2-EC-Member-Server 1.0) security template is applied, applications might fail to launch for anonymous users or domain users. To avoid this, add the following groups to the Allow Logon through Remote Desktop Services setting for servers in the OU.
q

For anonymous users: server-name\Anonymous for each XenApp server in the farm, where server-name is the name of the XenApp server For domain users: domain-name\Domain Users for each XenApp server in the farm, where domain-name is the name of the domain

293

Securing Access to Your Servers


An important first step in securing your server farm is securing access to the servers.

Securing the AppCenter


You can use the AppCenter to connect to any server in your farm. Use it only in environments where packet sniffing cannot occur. Also, ensure that only administrators can access it. You can set NTFS permissions so that non-administrators do not have Execute permission for the AppCenter executable.

Using NTFS partitions


To ensure that appropriate access control can be enforced on all files installed by XenApp, install XenApp only on NTFS-formatted disk partitions.

Trusted Server Configuration


This feature identifies and enforces trust relations involved in client connections. This can be used to increase the confidence of client administrators and users in the integrity of data on client devices and to prevent the malicious use of client connections. When this feature is enabled, clients can specify the requirements for trust and determine whether or not they trust a connection to the server.

294

Securing the Data Store


Protecting the data store involves not only protecting the data in the data store database but also restricting who can access it. In general:
q

Users who access your farms servers do not require and should not be granted any access to the data store. All farm servers share a single user account and password for accessing the data store. Select a password that is not easy to deduce. Keep the user name and password secure and give it to administrators only to install XenApp.

Caution: If the user account for accessing the database is changed at a later time, the Citrix IMA Service fails to start on all servers configured with that account. To reconfigure the Citrix IMA Service password, use the dsmaint config command on each affected server. Be sure to create a backup of your data store before changing the password on your data store. Consult the database vendor documentation for more information.

Microsoft SQL Server


The user account that is used to access the data store on Microsoft SQL Server has public and db_owner roles on the server and database. System administrator account credentials are not needed for data store access; do not use a system administrator account because this poses an additional security risk. If the Microsoft SQL Server is configured for mixed mode security, meaning that you can use either Microsoft SQL Server authentication or Windows authentication, you may want to create a Microsoft SQL Server user account for the sole purpose of accessing the data store. Because this Microsoft SQL Server user account would access only the data store, there is no risk of compromising a Windows domain if the users password is compromised. For high-security environments, Citrix recommends using only Windows authentication. Important: For improved security, you can change the user accounts permission to db_reader and db_writer after the initial installation of the database with db_owner permission. Changing the user accounts permission from db_owner may cause problems installing future service packs or feature releases for XenApp. Be sure to change the account permission back to db_owner before installing a XenApp service pack or feature release.

295

Securing the Data Store

Microsoft SQL Server Express


Windows authentication is supported for the Microsoft SQL Server Express database. For security reasons, Microsoft SQL Server authentication is not supported. The user name and password typically are those for the local system administrator account. If users have access to the data store server, change the password with the dsmaint config command and keep the information in a safe place.

Oracle
Give the Oracle user account employed for the server farm "connect" and "resource" permissions only. System administrator (system or sys) account permissions are not needed for data store access.

296

Securing Client-Server Communications


There are two methods for encrypting the session data transmitted between clients and servers: SecureICA and SSL/TLS encryption. By default, all ICA communications are set to Basic ICA protocol encryption. The Basic setting obfuscates data but does not provide industry standard encryption. You can increase the level of SecureICA encryption up to 128-bit and/or add SSL/TLS encryption. The difference between the two types of client-server encryption is as follows:
q

SecureICA. The SecureICA feature encrypts the session data sent between a server running XenApp and a client. In general, increase the level of ICA protocol encryption when you want to encrypt internal communication within a LAN or a WAN, or you want to encrypt internal access to an intranet. Increasing the level of ICA protocol encryption prevents session data from being sent in clear text, but it does not perform any authentication. SSL/TLS protocols. SSL/TLS protocols can protect you from internal and external threats, depending on your network configuration. Citrix recommends that you enable SSL/TLS protocols. Enabling SSL/TLS ensures the confidentiality, authentication, and integrity of session data.

If you enable protection against both internal and external threats, you must enable SSL encryption. Using SecureICA with SSL or TLS provides end-to-end encryption. Both protocols are enabled on the server side, when you publish an application or resource. The Web Interface and Citrix Receiver automatically detect and use the settings specified on the server (that is, when you publish a resource). The settings you specify for client-server encryption can interact with any other encryption settings in XenApp and your Windows operating system. If a higher priority encryption level is set on either a server or client device, settings you specify for published resources can be overridden. The most secure setting out of any of the settings below is used:
q

The setting in Remote Desktop Session Host Configuration The XenApp policy setting that applies to the connection The client-server setting (that is, the level you set when you publish a resource) The Microsoft Group Policy

When you set an encryption level, make sure that it is consistent with the encryption settings you specified elsewhere. For example, any encryption setting you specify in the TSCC or connection policies cannot be higher than the application publishing setting. If the encryption level for an application is lower than what you specified through the TSCC and connection policies, the TSCC settings and the policies override the application settings.

297

Using SecureICA
By default, client-server communications are obfuscated at a basic level through the SecureICA feature, which can be used to encrypt the ICA protocol. Citrix Receiver uses the ICA protocol to encode user input (keystrokes and mouse clicks) and address it to a server farm for processing. Server farms use the ICA protocol to format application output (display and audio) and return it to the client device. You can increase the level of encryption for the ICA protocol when you publish a resource or after you publish a resource. In addition to situations when you want to protect against internal security threats, such as eavesdropping, you may want to use ICA encryption in the following situations:
q

You need to secure communications from devices that use Microsoft DOS or run on Win16 systems You have older devices running software that cannot be upgraded to use SSL As an alternative to SSL/TLS encryption, when there is no risk of a man-in-the-middle attack

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.

298

Enabling SSL/TLS Protocols


If client devices in your environment communicate with your farm across the Internet, Citrix recommends enabling SSL/TLS encryption when you publish a resource. If you want to use SSL/TLS encryption, you must use either the SSL Relay feature or the Secure Gateway to relay ICA traffic to the computer running XenApp. The nature of your environment may determine the way in which you enable SSL:
q

For client devices communicating with your farm remotely, Citrix recommends that you use the Secure Gateway to pass client communications to the computer running XenApp. The Secure Gateway can be used with SSL Relay on the computer running XenApp to secure the Secure Gateway to XenApp traffic, depending on your requirements. For client devices communicating with your farm internally, you can do one of the following to pass client communications to the computer running XenApp:
q

Use the Secure Gateway with an internal firewall and place your farm behind the firewall

Use the SSL Relay feature to secure the traffic between servers in your farm In larger environments, it may not be convenient to use SSL Relay because doing so requires storing certificates on every server in your farm. In large environments, you may want to use the Secure Gateway with an internal firewall if you are concerned with internal threats.
q

Regardless of whether you use the Secure Gateway or SSL Relay, if you want to use SSL, you must select the Enable SSL and TLS protocols setting when you publish an application. If you are using Web Interface with the Secure Gateway, see the information about SSL in the Secure Gateway and Web Interface administrator documentation.

299

To configure session data encryption


The following procedure explains how to increase the level of encryption by enabling SecureICA (ICA protocol encryption) or SSL/TLS (Secure Sockets Layer and Transport Layer Security) encryption after you publish an application. 1. From the AppCenter, select a published application in the left pane. 2. From the Action menu, select Application properties. 3. In the Application Properties dialog box, select Advanced > Client options. 4. In the Connection encryption section, select one or more of the following:
q

Select the Enable SSL and TLS protocols check box. This option requests the use of the SSL and TLS protocols for clients connecting to the published application. In the Encryption section, select a higher level of encryption from the drop-down list box.

If you are using SecureICA and you want to ensure that ICA traffic is always encrypted at a certain level, you can set a policy for encryption. Creating a SecureICA policy prevents you from accidentally publishing a resource at a lower level of encryption. If this policy is enabled and you publish a resource at a lower level of encryption than the policy requires, the server rejects client connections. For software that takes its encryption settings from the server, such as the Web Interface and Citrix Receiver, this can be problematic. Therefore, Citrix recommends as a best practice, that if you enable an encryption policy, you publish applications (or resources) by replicating an existing published application and editing it so as to replace the application with the new application you want to publish.

300

To set a policy for ICA encryption


The settings you specify for client-server encryption can interact with any other encryption settings in XenApp and your Windows operating system. If a higher priority encryption level is set on either a server or client device, settings you specify for published resources can be overridden. SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for your server farm, use SecureICA with SSL/TLS encryption. SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server and Citrix Receiver to avoid using SecureICA. 1. Configure the Citrix User policy SecureICA minimum encryption level setting with one of the following options:
q

Basic. Encrypts the client connection using a non-RC5 algorithm. It protects the data stream from being read directly, but it can be decrypted. RC5 (128 bit) logon only. Encrypts the logon data with RC5 128-bit encryption and the client connection using Basic encryption. RC5 (40 bit). Encrypts the client connection with RC5 40-bit encryption. RC5 (56 bit). Encrypts the client connection with RC5 56-bit encryption. RC5 (128 bit). Encrypts the client connection with RC5 128-bit encryption.

301

Configuring SSL/TLS Between Servers and Clients


For XenApp to accept connections encrypted with SSL or TLS, you must use SSL Relay to configure support on each XenApp server. Citrix SSL Relay can secure communications between clients, servers running the Web Interface, and XenApp servers that are using SSL or TLS. Data sent between the two computers is decrypted by the SSL Relay and then redirected using SOCKSv5 to the Citrix XML Service. SSL Relay operates as an intermediary in the communications between Citrix Receiver and the Citrix XML Service running on each server. Each Receiver authenticates the SSL Relay by checking the relays server certificate against a list of trusted certificate authorities. After this authentication, Receiver and SSL Relay negotiate requests in encrypted form. SSL Relay decrypts the requests and passes them to the server. When returning the information to Receiver, the server sends all information through SSL Relay, which encrypts the data and forwards it to the client to be decrypted. Message integrity checks verify that each communication is not tampered with. In general, use SSL Relay for SSL/TLS support when you:
q

Want to secure communications with servers that host the Citrix XML Service. Have a small number of servers to support (five or fewer). To use SSL/TLS to protect against internal threats in larger farms, consider configuring SSL/TLS support with Secure Gateway. Do not need to secure access at a DMZ. Do not need to hide server IP addresses or you are using Network Address Translation (NAT). Need end-to-end encryption of data between clients and servers.

Configure SSL Relay and the appropriate server certificate on each XenApp server in the server farm. By default, SSL Relay is installed with XenApp in C:\Program Files (x86)\Citrix\SSLRelay, where C is the drive where you installed XenApp. The Citrix XML Service provides an HTTP interface for enumerating applications available on the server. It uses TCP packets instead of UDP, which allows connections to work across most firewalls. The Citrix XML Service is included in the server. The default port for the Citrix XML Service is 80.

302

Configuring SSL/TLS Between Servers and Clients

Installing and Configuring the SSL Relay Tool


If you configure the SSL Relay tool with the User Account Control (UAC) feature of Microsoft Windows enabled, you might be prompted for administrator credentials. To run the SSL Relay tool, you must have the following privileges and associated permissions:
q

Domain administrator Delegated administrator Administrator group of the local computer where you are installing the tool

303

Obtaining and Installing Server and Root SSL Certificates


A separate server certificate is required for each XenApp server on which you want to configure SSL or TLS. The server certificate identifies a specific computer, so you must know the fully qualified domain name (FQDN) of each server. Certificates must be signed by a trusted entity called a Certificate Authority (CA). In addition to installing a server certificate on each server, you must install the root certificate from the same CA on each client device that will communicate with SSL Relay. Root certificates are available from the same CAs that issue the server certificates. You can install server and client certificates from a CA that is bundled with your operating system, an enterprise CA (a CA that your organization makes accessible to you), or a CA not bundled with your operating system. Consult your organizations security team to find out which of the following methods they require for obtaining certificates. Install the server certificate on each server. SSL Relay uses the same registry-based certificate store as IIS, so you can install certificates using IIS or the Microsoft Management Console (MMC) Certificate Snap-in. When you receive a certificate from the CA, you can restart the Web Server Certificate wizard in IIS and the wizard will install the certificate. Alternatively, you can view and import certificates on the computer using the MMC and adding the certificate as a stand-alone snap-in.

304

Choosing an SSL Certificate Authority


You can obtain and install certificates for your servers and client devices in the following ways:
q

Certificates from a CA bundled with the operating system. Some of the newer Windows operating systems include native support for many CAs. If you choose to install the certificate from a bundled CA, double-click the certificate file and the Windows Certificate Store wizard installs the server certificate on your server. For information about which operating systems include native support, see your Microsoft documentation. Certificates from an enterprise CA. If your organization makes a CA accessible to you for use, that CA appears in your list of CAs. Double-click the certificate file and the Windows Certificate Store wizard installs the server certificate on your server. For more information about whether or not your company uses an enterprise CA, consult your security team. Certificates from a CA not bundled with the operating system. Certificates from CAs that are not bundled with your operating system or made accessible to you by your organization must be installed manually on both the server running Citrix SSL Relay and on each client device. For instructions about installing certificates from an external CA, see the documentation for the servers and clients in your configuration. Alternatively, you can install certificates using Active Directory or the IIS snap-in:
q

If your computers belong to an Active Directory server, you can install the certificates using Active Directory. For instructions about how to use Active Directory to install your certificates, see your Microsoft documentation. You can use the Microsoft Web Server Certificate wizard in the IIS snap-in to request and import a certificate. For more information about using this wizard, see your Microsoft documentation.

305

Acquiring a Signed SSL Certificate and Password


After you choose a Certificate Authority (CA), generate a certificate signing request (CSR) and send it to the CA using the Web server software that is compatible with the CA. For example, if you are using the IIS snap-in to obtain your certificates, you can use Microsoft Enterprise Certificate Services to generate the CSR. The CA processes the request and returns the signed SSL certificate and password to you. For information about what software you can use to generate the CSR, consult the documentation for your chosen CA. Important: The common name for the certificate must be the exact fully qualified domain name of the server. After acquiring the signed certificate and password from your CA, install the certificates on each server and client in your configuration using the appropriate method.

306

To enable the SSL Relay and select the relay credentials


1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration Tools > Citrix SSL Relay Configuration Tool. 2. Click the Relay Credentials tab. 3. Select the Enable SSL relay check box to enable the relay features. 4. Select the Display Friendly Name check box to display the certificates friendly name, if available. This check box determines which information from the certificate appears in the Server Certificate list. Some certificates contain an additional friendly name field. If you check this box and no friendly name exists, the certificates subject common name is used (which is typically the server name). If Display Friendly Name is not checked, the entire subject name is used. 5. Select the server certificate from the Server Certificate drop-down box (used to identify the SSL Relay identity).

307

Using the SSL Relay with the Microsoft Internet Information Service (IIS)
To use the SSL Relay and Microsoft Internet Information Services (IIS) on the same server, for example, if you install the Web Interface and XenApp on the same server, you must change the port number that IIS or the SSL Relay use. SSL Relay uses TCP port 443, the standard port for SSL connections. Most firewalls open this port by default. Optionally, you can configure the SSL Relay to use another port. Be sure that the port you choose is open on any firewalls between the client devices and the server running the SSL Relay. Microsoft IIS is installed by default on Windows Server 2003 and allocates port 443 for SSL connections. It is not installed by default on Windows Server 2008. To run SSL Relay on a server running Windows Server 2003 or 2008 (with Web Server IIS installed and enabled), you must:
q

Install a server certificate on IIS before you change the port number. You can use the same server certificate with IIS and the SSL Relay. Configure IIS to use a different port or configure the SSL Relay to use a different port.

To change the SSL port for Internet Information Services, see the relevant Microsoft documentation.

308

Configuring the Relay Port and Server Connection Settings


The SSL Relay relays packets only to the target computers listed on the Connection tab of the Citrix SSL Relay Configuration Tool. By default, the SSL Relay is configured to relay packets only to the target computer on which the SSL Relay is installed. You can add other computers in the same server farm for redundancy. Use the Connection tab to configure the listener port and allowed destinations for the SSL Relay. The SSL Relay relays packets only to the target computers listed on the Connection tab. The target server and port specified on your server running the Web Interface or Citrix Receiver must be listed on this tab. By default, no servers are listed. See Configuring TCP ports for a list of ports used in a server farm. Once a certificate is added, the default ICA and Citrix XML Service ports are added for the local computer.
q

Relay Listening Port. The TCP port where SSL clients connect to the SSL Relay. The default port number is 443. If your server has multiple IP addresses, this port is used on all of them. If you change this value, you must make the same change on the client device. You may also need to open the port on any firewalls between the client device and the SSL Relay. Encryption Standard. SSL Relay can be configured to use either SSL or TLS. The protocol that is required is configured using the SSL Relay configuration tool. Server Name. The fully qualified domain name (FQDN) of the server to which to relay the decrypted packets. If certificates are not configured, no servers are listed. If certificates are configured, the FQDN of the server on which the SSL Relay is running appears here. Ports. The TCP ports where ICA and the Citrix XML Service are listening.

Important: If you change the default Citrix SSL Relay port, you must set SSLProxyHost to the new port number in the Citrix Receiver icaclient.adm file. For more information, see the Receiver administrator documentation.

309

Configuring the Relay Port and Server Connection Settings

To modify the destination server list


1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration Tools > Citrix SSL Relay Configuration Tool. 2. Click the Connection tab.
q

To add a server to the destination server list: a. Click New. b. Type the FQDN of the computer in the Server Name box. (This additional server must also be specified in the configuration of servers running the Web Interface.) c. Type the port number of the Citrix XML Service in the Destination ports box and click Add. To change the port for a server listed in the destination server list: a. Select the server entry and click Edit. b. In the Target Server Properties dialog box, select a destination port to remove and click Delete. c. In the field below Destination ports, type the number of the new destination port and click Add.

310

To run the SSL Relay on port 443 without using HTTPS


1. Stop the Microsoft Internet Information Service. 2. Configure and start the SSL Relay service. 3. Restart the Microsoft Internet Information Service. The SSL Relay uses port 443 before IIS, including when the server is restarted. Note: When you configure XenApp, members of the User group are allowed to edit registry entries in the registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Secure\Citrix\Citrix SSL Relay, or HKEY_LOCAL_MACHINE\SOFTWARE\Secure\Citrix\Citrix SSL Relay on XenApp, 32-bit Edition. You can use the Microsoft Security Configuration and Analysis tool to prevent members of the User group from editing these registry entries.

311

Configuring the Ciphersuites Allowed by the SSL Relay


Use the Citrix SSL Relay Configuration Tool to configure which combinations of ciphersuites the SSL Relay will accept from the client (a server running the Web Interface or Citrix Receiver). The Ciphersuites dialog box lists the available and allowed ciphersuites. The SSL Relay accepts connections only from clients that support at least one of the allowed ciphersuites. Installing additional ciphersuites is not supported. Available ciphersuites are grouped into GOV (Government) or COM (Commercial). Note that GOV ciphersuites are normally used when TLS is specified. However, any combination of ciphersuite and security protocol can be used. Contact your organizations security expert for guidance about which ciphersuites to use. Descriptions of ciphersuites are found in Appendix C of the Internet Society RFC 2246, available online at http://www.rfc-editor.org. By default, connections using any of the supported ciphersuites are allowed.

To add or remove ciphersuites


1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration Tools > Citrix SSL Relay Configuration Tool. Click the Ciphersuites tab. 2. Select a ciphersuite from the left column. To allow it, click Add. To disallow it, from the right column, click Remove.

312

Using the Secure Gateway


Use the Secure Gateway to provide SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled client, combined with encryption of the HTTP communication between the Web browser and the Web server. Using the Secure Gateway makes firewall traversal easier and improves security by providing a single point of entry and secure access to your server farms. In general, use the Secure Gateway when:
q

You want to hide internal IP addresses You want to secure public access to your farms servers You need two-factor authentication (in conjunction with the Web Interface)

Using the Secure Gateway provides the following benefits:


q

Secure Internet access Removes the need to publish the addresses of every server running XenApp Simplifies server certificate management Allows a single point of encryption and access to the servers

Use the Secure Gateway to create a gateway that is separate from the computers running XenApp. Establishing the gateway simplifies firewall traversal because ICA traffic is routed through a widely accepted port for passage in and out of firewalls. The Secure Gateway provides increased scalability. However, because ICA communication is encrypted only between the client and the gateway, you may want to use SSL Relay to secure the traffic between the gateway and the servers running XenApp, including the servers hosting the Citrix XML Service. For more information, see the Secure Gateway for Windows administrator documentation.

313

Using the Secure Ticket Authority


The Secure Ticket Authority (STA) is responsible for issuing session tickets in response to connection requests for published resources on XenApp. These session tickets form the basis of authentication and authorization for access to published resources. When you install XenApp, you also install the STA. The STA is embedded within the Citrix XML Service. Important: If you are securing communications between the Secure Gateway and the STA, ensure that you install a server certificate on the server running the STA and implement SSL Relay. In most cases, internally generated certificates are used for this purpose.

To display STA performance statistics


In addition to monitoring the performance of the server running the Secure Gateway, Citrix recommends monitoring the performance of the server running the Secure Ticket Authority (STA) as part of your administrative routine. 1. Access the Performance Monitor. 2. Right-click in the right pane and click Add Counters. 3. For the location of the performance counters, select Use local computer counters. 4. From the Performance Object drop-down list, select Secure Ticket Authority. 5. Select the performance counters you want to monitor and click Add. 6. Click Close. 7. Use the Windows Performance Console controls that appear at the top of the right pane to switch views and add counters.

Identifying Entries in the STA Log


The STA logs fatal errors to its application log, which is located in the \inetpub\scripts directory. When creating a log, the STA uses the following format for naming log files:

stayyyymmdd-xxx.log

314

Using the Secure Ticket Authority where yyyy is the year, mm is the month, and dd is the day of the log file creation. The first time the STA is loaded, it creates a log file. To view entries in the STA log, use a plain-text editor to open the log file. If the STA does not create a log file, it may be due to lack of write privileges to the \inetpub\scripts directory.

315

Securing Network Communications


Network communication between servers and client devices can be a security risk in any enterprise environment. In addition to physically securing servers, most organizations install network security measures including firewalls to isolate servers running XenApp and Web browsers from the Internet and publicly accessible networks. To deploy XenApp on internal networks, secure communications between the client and server by means of SSL/TLS or other security measures. Depending on your security needs, you can incorporate the following network communication security components when designing XenApp deployments:
q

At the client-server level inside your network:


q

By encrypting the Independent Computing Architecture (ICA) protocol using SecureICA

Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption At the network level, when clients are communicating with your farm remotely across the Internet:
q q

Secure Gateway Secure Ticket Authority Network firewalls

Proxy servers Part of securing your server farm is making sure that only properly authenticated users can access your servers and resources, which can include smart cards.
q

316

Configuring TCP Ports


This table lists the TCP/IP ports that the servers, Citrix Receiver, IMA Service, and other Citrix services use in a server farm. This information can help you configure firewalls and troubleshoot port conflicts with other software.

Communication Citrix AppCenter Citrix SSL Relay Citrix XML Service Client-to-server (directed UDP) ICA sessions (clients to servers) License Management Console Server to license server Server to Microsoft SQL Server or Oracle server Server to server Remote AppCenter to server Session reliability

Default port 135 443 80 1604 1494 8082 27000 139, 1433, or 443 for MS-SQL 2512 2513 2598

Configuration Not configurable See Using the SSL Relay with the Microsoft Internet Information Service (IIS) See Install and Configure Not configurable See ICAPORT See the licensing documentation In the console, open the farm or server properties page, and select License Server See the documentation for the database software

See IMAPORT See IMAPORT See Configuring Session Reliability

317

Using Proxy Servers


A proxy server accepts connection requests from client devices and redirects those requests to the appropriate XenApp servers. Using a proxy server, much like using a firewall, gives you more control over access to the XenApp servers and provides a heightened level of security for your network. A proxy server, as opposed to a firewall, uses a different port from that used by the XenApp servers. For information about using proxy servers with the Citrix Receiver, see the Citrix Receiver documentation. Supported proxy servers are:
q

Microsoft Internet Security and Acceleration (ISA) Server 2004 and 2006 iPlanet Web Proxy Server 3.6 Squid 2.6 STABLE 4 Microsoft Proxy Server 2.0

318

Configuring Authentication for Workspace Control


If users log on using smart cards or pass-through authentication, you must set up a trust relationship between the server running the Web Interface and any server in the farm that the Web Interface accesses for published applications. Without the trust relationship, the Disconnect, Reconnect, and Log Off (Workspace Control) commands fail for those users logging on with smart card or pass-through authentication. For more information about Workspace Control, see Ensuring Session Continuity for Mobile Workers. You do not need to set up a trust relationship if your users authenticate to the Web Interface or Citrix Receiver by typing in their credentials. To set up the trust relationship, configure the Citrix Computer policy Trust XML requests setting. The Citrix XML Service communicates information about published applications among servers running the Web Interface and servers running XenApp. If you configure a server to trust requests sent to the Citrix XML Service, consider these factors:
q

The trust relationship is not necessary unless you want to implement Workspace Control and your users log on using smart cards or pass-through authentication. Enable the trust relationship only on servers directly contacted by the Web Interface. These servers are listed in the Web Interface Console. When you set up the trust relationship, you depend on the Web Interface server to authenticate the user. To avoid security risks, use SSL Relay, IPSec, firewalls, or any technology that ensures that only trusted services communicate with the Citrix XML Service. If you set up the trust relationship without using IPSec, firewalls, or other security technology, it is possible for any network device to disconnect or terminate client sessions. Configure SSL Relay, IPSec, firewalls, or other technology that you use to secure the environment so that they restrict access to the Citrix XML Service to only the Web Interface servers. For example, if the Citrix XML Service is sharing a port with IIS, you can use the IP address restriction capability in IIS to restrict access to the Citrix XML Service.

319

Using Smart Cards with XenApp


You can use smart cards in your XenApp environment. Smart cards are small plastic cards with embedded computer chips. In a XenApp environment, smart cards can be used to:
q

Authenticate users to networks and computers Secure channel communications over a network Use digital signatures for signing content

If you are using smart cards for secure network authentication, your users can authenticate to applications and content published on servers. In addition, smart card functionality within these published applications is also supported. For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a smart card reader attached to the client device to log on to the server. After users are authenticated to the application, they can digitally sign email using certificates stored on their smart cards. Citrix has tested smart cards that meet Standard 7816 of the International Organization for Standardization (ISO) for cards with electrical contacts (known as a contact card) that interface with a computer system through a smart card reader device. The reader can be connected to the host computer by the serial, USB, or PCMCIA port. Citrix supports the use of PC/SC-based cryptographic smart cards. These cards include support for cryptographic operations such as digital signatures and encryption. Cryptographic cards are designed to allow secure storage of private keys such as those used in Public Key Infrastructure (PKI) security systems. These cards perform the actual cryptographic functions on the smart card itself, meaning the private key and digital certificates never leave the card. In addition, Citrix supports two-factor authentication for increased security. Instead of merely presenting the smart card (one factor) to conduct a transaction, a user-defined PIN (a second factor), known only to the user, is employed to prove that the cardholder is the rightful owner of the smart card. Note: XenApp does not support the RSA Security Inc. PKCS (Public-Key Cryptography Standard) #11 functional specification for personal cryptographic tokens. You can also use smart cards with the Web Interface for XenApp. For details, see the Web Interface administrator documentation.

Smart Card Requirements


Before using smart cards with XenApp, consult your smart card vendor or integrator to determine detailed configuration requirements for your specific implementation.

320

Using Smart Cards with XenApp The following components are required on the server:
q

PC/SC software Cryptographic Service Provider (CSP) software

These components are required on the device running the supported Citrix Receiver or client:
q

PC/SC software Smart card reader software drivers Smart card reader

Your Windows server and client operating systems may come with PC/SC, CSP, or smart card reader drivers already present. See your smart card vendor for information about whether these software components are supported or must be replaced with vendor-specific software. You do not need to attach the smart card reader to your server during CSP software installation if you can install the smart card reader driver portion separately from the CSP portion. If you are using pass-through authentication to pass credentials from your client device to the smart card server session, CSP software must be present on the client device.

Configuring XenApp for Smart Cards


A complete and secure smart card solution can be complex and Citrix recommends that you consult your smart card vendor or integrator for details. Configuration of smart card implementations and configuration of third-party security systems, such as certificate authorities, are beyond the scope of this documentation. Smart cards are supported for authenticating users to published applications or for use within published applications that offer smart card functionality. Only the former is enabled by default upon installation of XenApp. The following Citrix Receivers and clients support smart cards:
q

Receiver for Windows Receiver for Linux Receiver for MacIntosh Client for Windows-based terminals

To configure smart card support for Receiver or client users, see the Receiver or client documentation.

321

Configuring Kerberos Logon


Citrix Receiver features enhanced security for pass-through authentication. Rather than sending user passwords over the network, pass-through authentication leverages Kerberos authentication. Kerberos is an industry-standard network authentication protocol built into the Windows operating systems. Kerberos logon offers security-minded users the convenience of pass-through authentication combined with secret-key cryptography and data integrity provided by industry-standard network security solutions.

System requirements
Kerberos logon works only between clients and servers that belong to the same or to trusted Windows domains. Servers must also be trusted for delegation, an option you configure through the Active Directory Users and Computers management tool. Kerberos logon is not available:
q

If you use the following Remote Desktop Services options:


q

Use standard Windows authentication

Always use the following logon information or Always prompt for password If you route connections through Secure Gateway
q

If the server running XenApp requires smart card logon

Kerberos requires Citrix XML Service DNS address resolution to be enabled for the server farm or reverse DNS resolution to be enabled for the Active Directory domain.

User Access Control and Administrator Sessions


The User Access Control feature prompts users to enter credentials when all of the following requirements are met:
q

Kerberos logon is enabled on the server running XenApp Users logging on to the computer running XenApp are members of the Administrator group on that computer After logon, Administrator group users attempt to access network resources such as shared folders and printers

322

Configuring Kerberos Logon

Limitations of Kerberos Pass-through Authentication to XenApp


Windows supports two authentication protocols, Kerberos and NTLM, so applications such as Windows Explorer, Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, Microsoft Office, and others, can use Windows pass-through authentication to access network resources without explicit user authentication prompts. When Kerberos pass-through authentication is used to start a XenApp session, there are technical limitations that may affect application behavior.
q

Applications running on XenApp that depend on the NTLM protocol for authentication generate explicit user authentication prompts or fail. Most applications and network services that support Windows pass-through authentication accept both Kerberos and NTLM protocols, but some do not. In addition, Kerberos does not operate across certain types of domain trust links in which case applications automatically use the NTLM protocol. However the NTLM protocol does not operate in a XenApp session that is started using the Kerberos pass-through authentication, preventing applications that cannot use Kerberos from authenticating silently.

Kerberos pass-through authentication for applications expires if the XenApp session is left running for a very long time (typically one week) without being disconnected and reconnected. Kerberos is based on security tickets issued by domain controllers, which impose a maximum refresh period (typically one week). When the maximum refresh period has ended, Windows obtains a new Kerberos ticket automatically by using the cached network credentials that are required for the NTLM protocol. However, these network credentials are not available when the XenApp session was started using Kerberos pass-through authentication.

To enable Citrix XML Service DNS address resolution


Configure the Citrix Computer policy DNS address resolution setting.

To disable Kerberos logon to a server


Caution: Using Registry Editor 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. To prevent Kerberos authentication for users on a specific server, create the following registry key as a DWORD Value on the server: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon\ DisableSSPI = 1 You can configure Citrix Receiver to use Kerberos with or without pass-through authentication.

323

Logging Administrative Changes to a XenApp Farm


The Configuration Logging feature allows you to keep track of administrative changes made to your server farm environment. By generating the reports that this feature makes available, you can determine what changes were made to your server farm, when they were made, and which administrators made them. This is especially useful when multiple administrators are modifying the configuration of your server farm. It also facilitates the identification and, if necessary, reversion of administrative changes that may be causing problems for the server farm. When this feature is enabled for a licensed server farm, administrative changes initiated from the following components lead to the creation of log entries in a central Configuration Logging database:
q

Citrix AppCenter some command-line utilities tools custom built with SDKs

Before you enable the Configuration Logging feature:


q

Determine the level of security and control you need over the configuration logs. This determines if you need to set up additional database user accounts and if you want to make XenApp administrators enter credentials before clearing logs. Determine how strictly you want to log tasks; for example, if you want to log administrative tasks and if you want to allow administrators to make changes to a farm if the task cannot be logged (for example, if the database is disconnected). Determine if you want to allow administrators to be able to clear configuration logs and if you want them to have to supply credentials for this purpose. This requires the permission to Edit Configuration Logging settings.

Important: To securely store the credentials used for accessing the Configuration Logging database, you can enable the IMA encryption feature when you deploy your server farm. After this is enabled, however, you cannot disable it without losing the data it encrypted. Citrix recommends that you configure IMA encryption before the Configuration Logging feature is configured and used. To enable the Configuration Logging feature:
q

Set up the Configuration Logging database Define the Configuration Logging database access permissions Configure the Configuration Logging database connection Set the Configuration Logging properties

324

Logging Administrative Changes to a XenApp Farm


q

Delegate administrative permissions, as needed

The Configuration Logging feature, after it is properly enabled, runs in the background as administrative changes trigger entries in the Configuration Logging database. The only activities that are initiated by the user are generating reports, clearing the Configuration Logging database, and displaying the Configuration Logging properties. To generate a configuration logging report, use the PowerShell command Get-CtxConfigurationLogReport. For more information, see help for Get-CtxConfigurationLogReport or Windows PowerShell with Common Commands.

325

Setting up the Configuration Logging Database


The Configuration Logging feature supports Microsoft SQL Server and Oracle databases; for information about supported versions, see CTX114501. The Configuration Logging database must be set up before Configuration Logging can be enabled. Only one Configuration Logging database is supported per server farm, regardless of how many domains are in the farm. When the Configuration Logging database is set up, you also must ensure that the appropriate database permissions are provided for XenApp so that it can create the database tables and stored procedures (preceded by CtxLog_AdminTask_) needed for Configuration Logging. Do this by creating a database user who has ddl_admin or db_owner permissions for SQL Server, or a user who has the "connect" and "resource" roles and "unlimited tablespace" system privilege for Oracle. This is used to provide XenApp full access to the Configuration Logging data. The Configuration Logging feature does not allow you to use a blank password to connect to the Configuration Logging database. Each server in the server farm must have access to the Configuration Logging database.

Considerations for SQL Server


Only one server farm is supported per Configuration Logging database. To store Configuration Logging information for a second farm, create a second Configuration Logging database. When using Windows Integrated Authentication, only fully qualified domain logons are valid. Local user account credentials will fail to authenticate on the database server that hosts the Configuration Logging database. Ensure that all Citrix administrators accessing the same farm are configured to use the same default schema. The database user who will create the Configuration Logging tables and stored procedures must be the owner of the default schema. If you are using dbo as the default schema, the database user must have db_owner permissions. If you are using ddl_admin as the default schema, the database user must have ddl_admin permissions. See the SQL Server documentation for information about managing and using schemas.

Considerations for Oracle


Only one farm is supported per schema. To store Configuration Logging information for a second farm in the same database instance, use a different schema. Tables and stored procedures are created in the schema associated with the user who initially configured the Configuration Logging feature. For information about managing and using a different schema, see the Oracle documentation.

326

Setting up the Configuration Logging Database The user name connecting to the Oracle database should not begin with a number; otherwise, you cannot display the log from the AppCenter. Important: To use an Oracle database for configuration logging, the 32-bit Oracle client must be installed on the AppCenter. Before running the AppCenter, update the Oracle tnsnames.ora client file to include the connectivity information needed to access the available databases.

327

Defining Database Permissions for Configuration Logging


The first time the Configuration Logging feature is enabled, it connects to the Configuration Logging database and discovers that the database schema does not exist. XenApp then creates the database schema, tables, and stored procedures. To create a database schema, XenApp needs full access to the database. After the database schema is created, full access is no longer necessary and you have the option of creating additional users with fewer permissions. The following table lists the minimum permissions required to perform the Configuration Logging tasks.

Configuration Logging task To create log entries in the database tables

Database permissions needed


q

INSERT for the database tables EXECUTE for the stored procedures SELECT
q

SQL Server: for sysobjects and sysusers Oracle: for sys.all_objects, and for sequence objects and the "create session" system privilege

To clear the log

DELETE/INSERT for the database tables EXECUTE for the GetFarmData stored procedure SELECT
q

SQL Server: for sysobjects and sysusers Oracle: for sys.all_objects, and for sequence objects and the "create session" system privilege

To create a report

EXECUTE for the Configuration Logging stored procedures SELECT


q

SQL Sever: for sysobjects and sysusers

Oracle: for sys.all_objects, and for sequence objects and the "create session" system privilege The Configuration Logging components must have access to the GetFarmData stored procedure to find out if a Configuration Logging database is associated with a farm. If you do not have permission to execute an existing GetFarmData stored procedure, this farm is invisible to the Configuration Logging components.
q

328

Defining Database Permissions for Configuration Logging

Considerations for SQL Server


Before you configure the Configuration Logging database connection, grant EXECUTE permission to the sp_databases system stored procedure to list the databases on the database server. The authentication mode must be the same for the database user who creates log entries in the database tables and the database user who clears the log.

329

To configure the connection to the Configuration Logging database


After the Configuration Logging database is set up by your database administrator and the appropriate database credentials are provided to XenApp, use the Configuration Logging Database wizard to configure the connection to the database. 1. From the AppCenter, select a farm. 2. From the Action menu, select Farm properties. 3. Click Configuration Logging. 4. Click Configure Database. The wizard opens. 5. Select the connection type (SQL Server or Oracle). For SQL Server, use the drop-down list to select a SQL Server; for Oracle, select a net service name (from the Oracle tnsnames.ora client file). You can also type the entry. 6. (SQL Server only). Select an authentication mode: Windows integrated security (recommended) or SQL Server authentication. 7. Enter a valid user name and password for the database. Credentials are always required (even if you are using Windows Integrated Authentication with SQL Server). The credentials are stored using the IMA encryption feature. Each server that creates log entries uses the credentials to connect to the Configuration Logging database. 8. (SQL Server only). Select or type the name of the database. 9. Configure connection options and connection pooling options. You can use the default values for these settings. (For SQL Server, the possible exception is Use encryption. For security reasons, the default value is Yes; however, if the database server to which you are connecting does not support encryption, the connection will fail. Click Test Database Connection on the summary page to check for encryption support.) 10. Click Test Database Connection. A display indicates whether or not the connection established successfully.

After you configure the connection to the Configuration Logging database, you cannot set the database back to None. To stop logging, clear the Log administrative tasks to Configuration Logging database check box in the Configuration Logging dialog box.

330

To set Configuration Logging properties


Before you set Configuration Logging properties, configure the database and the connection to the database. Otherwise, the Configuration Logging property fields are not active. Full Citrix administrators can edit the Configuration Logging settings and clear the log, or they can authorize other administrators to perform these tasks by assigning them the delegated administration Edit Configuration Logging Settings permission. Without this permission, ordinary administrators cannot perform these functions. 1. From the AppCenter, select a farm. 2. From the Action menu, select Farm properties. 3. Click Configuration Logging. 4. To enable Configuration Logging, select the Log administrative tasks to Configuration Logging database check box. If you want administrators to be able to make changes to the server farm when log entries cannot be saved to the Configuration Logging database, select the Allow changes to the farm when logging database is disconnected check box. 5. To prompt administrators to enter their credentials before clearing the log, select the Require administrators to enter database credentials before clearing the log check box.

331

Clearing Entries from the Configuration Logging Database


It may become necessary to clear the entries in the Configuration Logging database if the population of the tables becomes too large. To manage which database users can clear the configuration log, Citrix recommends that you enable the Require administrators to enter database credentials before clearing the log check box in the Configuration Logging properties. Anyone attempting to clear the log is prompted for database credentials. The credentials must correspond to the authentication mode you selected when you connected to the database initially. Specifically:
q

For SQL authentication, credentials with permissions for the Configuration Logging database on the SQL server are required For Windows Integrated authentication, XenApp impersonates the database user when it connects to the SQL database, so credentials for the Windows user account are required

Use one of the following methods to clear log entries from the Configuration Logging database:
q

From the AppCenter, expand the farm node and select History. Select Clear history in the Actions pane or the Action menu. Use the PowerShell command Clear-XAConfigurationLog. For more information, see help for Clear-XAConfigurationLog or Windows PowerShell with Common Commands.

332

Encrypting Configuration Logging Data


Independent Management Architecture (IMA) is the underlying architecture used in XenApp for configuring, monitoring, and operating all XenApp functions. The IMA data store stores all XenApp configurations. IMA encryption protects administrative data used by Configuration Logging. This information is stored in the IMA data store. For IT environments with heightened security requirements, using IMA encryption provides a higher degree of security for Configuration Logging. One example would include environments that require strict separation of duties or where the Citrix Administrator should not have direct access to the Configuration Logging database. IMA encryption is a farm-wide setting that applies to all servers in the farm after encryption is enabled. Consequently, to use IMA encryption, you must enable it on all servers in the farm. IMA encryption has the following components: Component CTXKEYTOOL Description Also known as the IMA encryption utility, CTXKEYTOOL is a command-line utility you use to manage IMA encryption and generate key files. CTXKEYTOOL is in the Support folder of the XenApp media. The key file contains the encryption key used to encrypt sensitive IMA data. You create the key file using CTXKEYTOOL. To preserve the integrity of the encryption, Citrix recommends that you keep the key file in a secure location and that you do not freely distribute it.

Key file

The same valid IMA encryption key must be loaded on all servers in the farm if IMA encryption is enabled. After copying the key file to a server, you load the key by using CTXKEYTOOL. Configuring IMA encryption includes the following tasks:
q

Key

On the first server in a farm (that is, the server on which you create the farm during XenApp configuration), generate a key file, load the key, and enable it Make the key file accessible to other servers in the farm or put it on a shared network location Load the key onto other servers in the farm (that is, the servers that join the farm during configuration)

Citrix recommends that if you are enabling IMA encryption in environments that have multiple farms, you give the key for each farm a different name.

333

Encrypting Configuration Logging Data

Storing CTXKEYTOOL Locally


1. Copy the CTXKEYTOOL.exe file from the Support folder of XenApp media to your local computer. 2. Create a folder named Resource at the same level in your directory structure as the CTXKEYTOOL file. 3. Copy the entire Support\Resource\en folder to the new Resource folder. You can store the CTXKEYTOOL.exe file and the Resource\en folder anywhere on your computer, provided you maintain the same relative directory structure used on the media.

334

To generate a key and enable IMA encryption on the first server in a farm
Before enabling IMA encryption on the first server in the XenApp farm (that is, the server on which you created the farm), install and configure XenApp, and restart the server. 1. On the server where you created the XenApp farm, run CTXKEYTOOL with the generate option, specifying the full UNC or absolute path (including the file name of the key you want to generate) to the location where you want to store the file key. Citrix suggests naming the key after the farm on which it will be used; for example, farmakey.ctx. Citrix also suggests saving the key to a folder that uses the name of your farm; for example, Farm A Key. If the key file generates successfully, the message Key successfully generated" appears. 2. To obtain the key from the file and put it in the correct location on the server, run CTXKEYTOOL with the load option on the server on which you want to add the key, specifying the full UNC or absolute path (including the key file name) to the location where you stored the key file. If the key loaded successfully, the message Key successfully loaded appears. 3. Run CTXKEYTOOL with the newkey option to use the currently loaded key and enable the key. If IMA encryption is enabled successfully, the message The key for this farm has been replaced. IMA Encryption is enabled for this farm appears.

Storing the Key File on a Shared Network Location


If you choose to store the key on a shared network location, Citrix recommends the following:
q

Give the folder a meaningful name that specifies the name of the farm for which the key was created. This is important in situations when you follow the Citrix best practice recommendation of creating a unique key for the farm. Ensure that the account you use to generate the key is the same as the account that will be used to configure all the servers in the farm. You must use the same account for both tasks.

1. When you generate the key file, save it to a local directory (as you normally would). 2. After enabling IMA encryption on the server where you generated the key, copy the key file to the shared network location. 3. Grant Read/Execute access to the key file for each server that will be joining the farm, and to the administrator performing the installation.

335

To load a key on servers that join the farm


Before enabling IMA encryption on servers you are joining to a XenApp farm, install and configure XenApp, but do not restart the server. 1. If you do not have the key file on a shared network location, load the key file to the server. 2. To obtain the key from the file and put it in the correct location on the server, run CTXKEYTOOL with the load option, specifying the full UNC or absolute path (including the key file name) to the location where you stored the key file. If the key loaded successfully, the message Key successfully loaded appears. You do not need to enable IMA encryption on this server, because you already enabled it on the first server in the farm 3. Restart the server. Repeat this procedure on all servers you configure to join the farm.

Changing Farms
If you move a server that has IMA encryption to a farm that has IMA encryption enabled, run CTXKEYTOOL with the load option (specifying the key that was generated for the new farm) on that server is configured but before it is restarted. If you move a server that has IMA encryption enabled to a farm that does not have IMA encryption enabled, IMA encryption is disabled automatically on the server being moved.

336

Managing IMA Encryption


IMA encryption includes other features that you can use as needed:
q

Citrix strongly recommends backing up the farm key to a safe, secondary location, such as a CD, immediately after you generate a key. You can create a copy of the key file when you create it, or you can back up the farm key by running CTXKEYTOOL with the backup option. You can recreate a key file that you accidentally deleted, lost, or overwrote. All servers in the same farm use the same key, so you can obtain a key from another server on the farm; however, XenApp does not allow you to access keys. You must recreate the entire key file by running CTXKEYTOOL with the backup option on any server in the farm that has the key and is functioning properly. You can disable IMA encryption by running CTXKEYTOOL with the disable option. Because IMA encryption is a farm-wide feature, disabling it on one server disables the feature on all servers. If you disable IMA encryption, to access the Configuration Logging database, you must reenter the password for the Configuration Logging database. In addition, no configuration information is logged until you reenter your database credentials. To reenable IMA encryption after you disabled it, run CTXKEYTOOL with the enable option. After enabling IMA encryption, Citrix recommends that you run CTXKEYTOOL with the query option to verify that IMA encryption is enabled.

For more information about CTXKEYTOOL, see the XenApp Command Reference documentation.

337

XenApp Service Account Privileges


These tables provide information about the services installed by default with XenApp, their accounts, associated permissions, and privileges.

XenApp Services Overview


This table lists the display name for the service, which is the name that appears in the Services panel. When the display name and the service name differ, the table provides service name in (parentheses). The Dependencies column lists the system components, such as Windows services, Citrix services, or drivers, on which the service depends. The Dependencies column also includes subdependencies that might not appear on the Dependencies tab for the service. Licensing services, which are not listed here, might also appear if the license server is installed on the same server as XenApp.

Display Name (Service Name) Citrix 64-bit Virtual Memory Optimization

Executable ctxsfosvc64.exe

Logon Account / Startup Type Local System/ Manual

Description Dynamically optimizes 64-bit applications running on a XenApp server. Maps client drives and peripherals for access in sessions.

Dependencies None

Citrix Client Network (CdmService)

cdmsvc.exe

Local System/ Automatic

Client Drive Mapping (CDM), Windows Management Instrumentation Driver Extensions, Workstation None

Citrix CPU Utilization Mgmt/CPU Rebalancer (CTXCPUBal)

ctxcpubal.exe

.\ctx_cpuuser/Manual Enhances resource management across multiple CPUs. Installed only on servers that have multiple CPUs.

338

XenApp Service Account Privileges Citrix CPU Utilization Mgmt/Resource Mgmt (ctxcpuSched) Citrix Diagnostic Facility COM Server (CdfSvc) ctxcpusched.exe Local System/ Manual Manages resource consumption to enforce entitlement policies. Manages and controls diagnostic trace sessions, which diagnose problems on a XenApp server. Enables secure communication with RC5 128-bit encryption between Citrix Receiver and XenApp. Collects and collates end-user experience measurements. Provides health monitoring and recovery services in the event problems occur. Provides management services in the XenApp farm. Remote Procedure Call (RPC)

CdfSvc.exe

NT AUTHORITY\ Network Service/Automatic

Remote Procedure Call (RPC)

Citrix Encryption Service

encsvc.exe

NT AUTHORITY\ Local Service/ Automatic

Windows Management Instrumentation Driver Extensions

Citrix End User Experience Monitoring (Citrix EUEM)

SemsService.exe

Local Service/ Manual

Citrix SMC Support Driver

Citrix Health HCAService.exe Monitoring and Recovery (CitrixHealthMon)

NT AUTHORITY\ Local Service/ Automatic

Citrix Independent Management Architecture service Citrix Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC), TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation

Citrix Independent Management Architecture (IMAService)

ImaSrv.exe

NT AUTHORITY\ NetworkService/ Automatic

339

XenApp Service Account Privileges Citrix MFCOM Service (MFCom) mfcom.exe NT AUTHORITY\ NetworkService/ Automatic Provides COM services that allow remote connections from the management tools. Remote Procedure Call (RPC), Citrix Independent Management Architecture service, Citrix Services Manager service Print Spooler, Remote Procedure Call (RPC)

Citrix Print Manager Service (cpsvc)

CpSvc.exe

Local Service/Automatic

Manages the creation of printers and driver usage within XenApp sessions. Supports the Citrix Universal Printing features. Proxy to the Citrix Secure Gateway server. Provides XenApp with an interface to the operating system. Other services use this services for elevated operations.

Citrix Secure Gateway Proxy (CtxSecGwy)

CtxSGSvc.exe

NT AUTHORITY\ Network Service/ Automatic

None

Citrix Services IMAAdvanceSrv.exeLocal System Manager /Automatic (IMAAdvanceSrv)

None

Citrix Streaming Service (RadeSvc) Citrix Virtual Memory Optimization

RadeSvc.exe

.\Ctx_StreamingSvc Manages the /Automatic Citrix Offline Plug-in when streaming applications. Local System /Manual Dynamically optimizes applications running on a XenApp server to free up server memory.

Remote Procedure Call (RPC)

CTXSFOSvc.exe

None

340

XenApp Service Account Privileges Citrix WMI ctxwmisvc.exe Service (CitrixWMIservice) NT AUTHORITY\ Local Service/Manual Provides the Citrix WMI classes for information and management purposes. Citrix Independent Management Architecture service , Citrix Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC), TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation None

Citrix XML Service (CtxHttp)

ctxxmlss.exe

Network Service /Automatic

Services XML data requests sent by XenApp components Services network requests for session reliability and SSL from XenApp components.

Citrix XTE XTE.exe Server (CitrixXTEServer)

NT AUTHORITY\ NetworkService /Manual

None

Caution: Citrix does not recommend altering account permissions and privileges. If you delete the accounts or alter their permissions incorrectly, XenApp might not function correctly.

Permissions for Service User Accounts


This table lists the permissions associated with accounts XenApp services use. Account Name Local Service Network Service Local System Permissions Limited Limited, network resources Administrator Notes NT AUTHORITY\LocalService NT AUTHORITY\NetworkService NT AUTHORITY\System

341

XenApp Service Account Privileges Ctx_StreamingSvc Ctx_ConfigMgr Ctx_CpuUser Domain or local user Domain or local user Domain or local user Acts as a User Acts as a Power User Acts as a User

Privileges for Service User Accounts


If your organization requires that service accounts run as domain accounts and not as local accounts, you can create domain accounts to replace the Ctx_ConfigMgr and Ctx_CpuUser accounts before installing XenApp. Ensure the new account has the same privileges as the default account.

Privileges Change the system time Generate security audits Increase quotas Log on as a batch job Log on as a service Replace a process level token Debug programs

Local Service x x x x x x

Network Service x x x x x x

Ctx_ConfigMgr x x

Ctx_CpuUser x x

Increase x scheduling priority Citrix does not support changing the account for the Citrix Streaming Service (Ctx_StreamingSvc), which has the privileges: log on as a batch job, log on as a service, backup files and directories, restore files and directories, deny log on locally, deny remote log on, and take ownership of files or other objects.

342

Maintaining Server Farms


A server farm is a group of servers running Citrix XenApp and managed as a single entity. The servers in the server farm share a single IMA-based data store. Citrix recommends performing farm maintenance tasks from the data collector, assuming no applications are published on the data collector, because this updates farm data faster. Performing farm maintenance tasks from a server hosting published applications can slow down users trying to connect to published applications and take longer to update in the data store. The Citrix AppCenter provides a wide variety of summary information about the farm and each server in the farm. You can customize your view and group applications or servers in folders to make navigating through their AppCenter listings easier. Folders are also useful for Object Based Delegated Administration. Grouping servers into folders can facilitate the process of delegating administrative tasks to Citrix administrators. From the Start menu, select All Programs > Citrix > Management Consoles and choose Citrix AppCenter. When you select an item in the navigation pane, the Actions pane provides quick access to related options for the selected item. In addition, configure Citrix policy settings in the AppCenter or the Local Group Policy Editor, depending on whether or not you use Active Directory in your XenApp environment. Use these settings to maintain the farm, including scheduling restarts, optimizing and monitoring server performance, and setting the port for the Citrix XML Service and License Server. For more information, see the Policy Settings Reference.

343

To search for objects in your farm


XenApp provides an advanced search feature so that you can search for the objects in your farm such as discovered items, sessions or applications by user, and servers that do not have a specific hotfix applied to them. 1. From the Citrix AppCenter, in the navigation pane, select Search, and in the Actions pane, select Search for items. 2. In the Advanced Search dialog box, in the Find box, select one of the following:
q

Discovered items. Searches discovered items. Sessions By User. Lists the sessions to which a specific user is connected. Type a user name in the Name box. Applications By User. Lists the applications that the specified user is using. Type a user name in the Name box.

Servers without hotfix. Lets you search for all of the servers missing a specific hotfix. This feature is useful if you want to check that you applied a hotfix to all servers in your farm. Type a hotfix number in the Name box. 3. Use the Browse button to select one of the Citrix Resources locations to search in.
q

344

To change a server's desktop settings


To perform administrator tasks on a server's desktop, you can access a servers desktop only if the desktop of the selected server is published. Configure connection settings to your servers through the Microsoft Management Console (MMC) using Remote Desktop Session Host Configuration. 1. Configure the Citrix policies setting for Desktop launches to Allowed. If it is set to Prohibited, this feature fails. 2. From the Citrix AppCenter, select a server. 3. In the Actions pane, select Other Tasks > Connect to server, and choose one of the following settings:
q

Connect to servers published desktop

Connect directly to server's desktop 4. In the Launch ICA Desktop Session dialog box, choose from the following selections. The selections you make here become the new default settings.
q q

Accept the Width and Height values (800 x 600 by default) or specify a different resolution. Colors (Better Speed by default). Select the color depth for the application. The available options are 256 colors (8-bit), Better Speed (16-bit), or Better Appearance (32-bit). Encryption. Select one of the following options from the list.
q

Basic encrypts the connection using a non-RC5 algorithm (default setting). Basic encryption protects the data stream from being read directly but can be decrypted. 128-Bit Login Only (RC5) encrypts the logon data with RC5 128-bit encryption and the ICA connection with basic encryption. 40-Bit (RC5) encrypts the connection with RC5 40-bit encryption. 56-Bit (RC5) encrypts the connection with RC5 56-bit encryption. 128-Bit (RC5) encrypts the connection with RC5 128-bit encryption.

345

To limit the number of server connections per user


When a user starts a published application, the client establishes a connection to a server in the farm and initiates a client session. If the user then starts another published application without logging off from the first application, the user has two concurrent connections to the server farm. To conserve resources, you can limit the number of concurrent connections that users can make. Configure the Citrix Computer policy for Server Settings > Connection Limits by setting the following options:
q

Limit user sessions. Specify the maximum number of concurrent connections a user can make to any single server at the same time (value range 0 - 8192). Limits on administrator sessions. Enable or disable connection limit enforcement for Citrix administrators. Important: Limiting connections for Citrix administrators can adversely affect their ability to shadow other users.

Logging of logon limit events. Enable or disable the logging of events (to the server log) about connection attempts that are denied because they exceed logon limits.

346

To enable or deny logons to servers


By default, logons are enabled for each server in a farm, allowing connections, reconnections, and session sharing. Before taking a server offline, such as for maintenance, use these options to reroute logons to other servers. Citrix recommends that you drain the server slowly by denying new logons (rerouting them to other servers), but allowing users to reconnect to disconnected sessions and close applications cleanly, thus preventing loss of user data. Important: Citrix strongly recommends that you use these Logon control options (instead of the Windows Remote Desktop Services options) to control logons to XenApp servers. 1. From the Citrix AppCenter, select the server. 2. From the Actions menu, select Other Tasks > Logon control and one of the following:
q

Allow logons and reconnections. Enable all logons, reconnections, and session sharing (default setting). Prohibit logons and reconnections. Reroute all logons, reconnections, and session sharing to other servers. Prohibit logons only. Reroute new connections and session sharing, but allowing users to reconnect to disconnected sessions. This state persists until you change it manually.

Prohibit logons until server restart. Reroute new connections and session sharing, as above, but after restarting the server, the setting automatically changes back to Allow logons and reconnections. After resetting logon control, the selected option does not appear in the list.
q

347

Restarting Servers at Scheduled Times


To optimize performance, you can restart servers automatically at specified intervals by creating a restart schedule. Restart schedules are based on the local time for each server to which they apply. This means that if you apply a schedule to servers that are located in more than one time zone, the restarts do not happen simultaneously; each server is restarted at the selected time in its own time zone. When the Citrix Independent Management Architecture (IMA) service starts after a restart, it establishes a connection to the data store and updates the local host cache. This update can vary from a few hundred kilobytes of data to several megabytes of data, depending on the size and configuration of the server farm. To reduce the load on the data store and to reduce the IMA service start time, Citrix recommends maintaining restart groups of no more than 100 servers. In large server farms with hundreds of servers, or when the database hardware is not sufficient, restart servers in groups of approximately 50, with at least 10 minute intervals between groups. To create a server restart schedule, enable the Scheduled reboots setting and configure related policy settings for frequency, start date and time, and warnings to users. Additionally, configure the Reboot schedule randomization interval setting which prevents servers in the same local time zone from restarting at the same time. The interval value represents the number of minutes before or after the scheduled restart time at which the servers can be restarted. When added to a policy, this setting distributes server restarts in a uniform manner within the interval specified. For example, if the reboot schedule time is 11:00 PM and the randomization interval is 15 minutes, the servers can be restarted between 10:45 PM and 11:15 PM.

348

Removing and Reinstalling XenApp


Tasks you might need to perform to remove servers from your farm or remove XenApp software from a server include:
q

Moving a server to another farm Renaming a server Removing a server from your farm Removing XenApp from a computer in your farm or forcing its removal Removing a server from your farm if the hardware hosting XenApp fails

To accomplish these tasks, you might need to remove XenApp from its host computer, remove it from the farm or from the list of farm servers in the Citrix AppCenter, or repair the installation. In addition, see the procedures in this section for related tasks, including moving or removing a server from the farm and renaming a XenApp server.

Removing XenApp
Citrix recommends that you remove XenApp by using Control Panel > Programs and Features while the server is still connected to the farm and the network. Select Citrix XenApp <version>, click Uninstall. After the program is finished, restart the server. This method removes the host information from the farm data store and removes the server from the farm properties displayed in the management tools. To remove XenApp remotely, you can do so from within a Remote Desktop Connection (RDC) session or using tools such as Microsoft Configuration Manager 2007 (formerly Systems Management Server (SMS)). If you want to remove only specific components of XenApp, do so in the following order:
q

Citrix Management (such as Citrix AppCenter) XenApp Advanced Configuration utility or Presentation Server Console, if installed Citrix XenApp Citrix Web Interface Citrix Licensing

349

Removing and Reinstalling XenApp

Forcing the Removal of XenApp


To force the removal of XenApp from a computer, you can use msiexec on a command line to add the property: CTX_MF_FORCE_SUBSYSTEM_UNINSTALL. Set its value to Yes. The following sample command line enables logging of the uninstallation operation and forces the removal of XenApp: msiexec /x mps.msi /L*v c:\output.log CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=Yes where mps.msi is the name and location of the msi package.

Repairing a XenApp Installation


Before you start, log off from all sessions and exit any applications running on the server. After you finish, restart the server when prompted. When you run the repair utility from Control Panel > Programs and Features, XenApp overwrites all files and settings with those from the original installation. If you customized any of the files or features in your XenApp installation, running the repair utility replaces your customizations with the original files and settings.

Reinstalling XenApp Due to Hardware Failure


If the hardware for a server fails and needs to be replaced, change its name to the same name as the failed server before you connect its replacement server to your network. Assigning the replacement server the failed servers name lets the replacement have the same properties and functionality as the failed XenApp server. The records in the data store for the old server apply to its replacement of the same name. Ensure that the replacement server settings are identical to the failed server, including:
q

Server name Operating system Settings for applications made during installation or when the application was published User accounts

Backing Up and Restoring the XenApp Data Store


Many data store maintenance tasks are performed using the DSMAINT and DSCHECK commands. For more information, see the Command Reference and Data Store Database Reference documentation.

350

To rename a XenApp server


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. Create a Citrix local administrator account on the server you want to rename. 2. On the server you want to rename, run chglogon /disable to prevent users from logging on to the server. 3. Open Citrix AppCenter on a different server, and remove the server to be renamed from published applications assigned to that server. 4. On the server you want to rename, stop the Citrix Independent Management Architecture (IMA) service. 5. In the Registry, set the HKEY_LOCAL_MACHINE\SOFTWARE\ Wow6432Node\Citrix\IMA\RUNTIME\PSRequired registry value to 1. Caution: Not changing the PSRequired registry value to 1 can result in incomplete records in the data store. Changing this value to 1 forces the Citrix Independent Management Architecture service to communicate with the data store and create a record for the newly named server. The value for PSRequired reverts to 0 the next time the Citrix Independent Management Architecture service restarts. 6. Change the name of the server in the server operating system and restart the server. 7. Log on to the console using the local administrator account you created. 8. Update all references to the old server to the new server name. For versions prior to 6.0, this might require logging on to the XenApp Advanced Configuration tool or Presentation Server Console as well. Important: Before removing the old server name, change all objects that reference the old name to the new server name, including data collector ranking, published application references, load evaluators, and zone settings. 9. Expand the Servers folder and remove the old server name from the list of servers. 10. Add the new server name to the list of configured servers for published applications.

351

To move or remove a server


To move a XenApp server from the farm or join the server to another farm, use XenApp Server Configuration Tool accessed through the Server Role Manager. Alternatively, use the command-line through XenAppConfig.exe. Both methods remove the server from the farm data store and from the lists of servers displayed in the AppCenter. If the hardware for a server fails or it cannot be started to run the uninstall program, remove the server. Citrix recommends that you use the Citrix AppCenter to remove a server from the farm only in cases where the server cannot be started to run the Windows uninstall program. Caution: If you remove all servers belonging to a single domain and have Citrix administrators in the domain, their user accounts cannot be enumerated by the AppCenter and appear as a question mark (?) in the list of Citrix administrators. To remove a server from a farm 1. With the server connected to the network and online in the farm, remove XenApp from the server from Control Panel > Programs and Features by selecting Citrix XenApp <version> and selecting Uninstall. 2. On a different server in the farm, open the AppCenter, run or rerun Discovery, and check that the server was removed from the farm successfully. If the server from which you removed XenApp still appears in the AppCenter: a. In the left pane, select the server. b. From the Action menu, select Other Tasks > Remove from farm. 3. After you ensure the server no longer appears in the farm, disconnect the server from the network. Caution: Do not reconnect the server to the network until you re-image it or remove its XenApp software. If it reconnects to the network, it can corrupt your farm. 4. Run the dscheck command on the data store to repair any consistency errors. 5. Perform a new installation of operating system (that is, a clean installation and not an upgrade) and XenApp (if you want to reuse the hardware for that server).

352

Monitoring Server Performance with Health Monitoring & Recovery


You can use Health Monitoring and Recovery to run tests on the servers in a server farm to monitor their state and discover any health risks. Citrix provides a standard set of tests; you have the option of importing additional tests, including custom tests that you develop. The Citrix tests included with XenApp allow you to monitor several services and activities including Remote Desktop Services, XML Service, Citrix IMA Service, and logon/logoff cycles. By default, Health Monitoring and Recovery is enabled on all of the servers in your farm, and the tests that are included run on all servers, including the data collector. Typically, you do not need to run these tests on the data collector because, particularly in a large farm, the data collector is not used for serving applications. If you do not want Health Monitoring & Recovery to run on the data collector, you must disable it manually. Store all custom tests in the following location: %Program Files%\Citrix\HealthMon\Tests\Custom\ where %Program Files% is the location in which you installed XenApp. When saving custom tests, do not include spaces in the file names. Configure the Citrix Computer policy for Server Settings > Health Monitoring and Recovery by setting the following options:
q

Health monitoring (enabled by default). Use this setting to allow or prevent the Health Monitoring and Recovery feature. Health monitoring tests. Use this setting to specify which tests to run. Select from a standard set of Citrix tests (described below) or add your own customized tests. For descriptions of recovery actions, see Modifying Health Monitoring and Recovery Actions. Maximum percent of servers with logon control (10 percent by default). Use this setting to specify the percentage of servers that can be offline and excluded from load balancing.

For information about draining a server before taking it offline, see To enable or deny logons to servers. Use the load balancing feature of XenApp with Health Monitoring and Recovery to ensure that if a server in the farm experiences a problem (for example the Citrix IMA Service is down), the state of that server does not interfere with the users ability to access the application because the users connection to that application is redirected through another server. For more information about load balancing and using Load Manager, see the Load Management section in eDocs.

353

Monitoring Server Performance with Health Monitoring &amp; Recovery

Citrix Tests
Citrix IMA Service test This test queries the service to ensure that it is running by enumerating the applications available on the server. Logon monitor test This test monitors session logon/logoff cycles to determine whether or not there is a problem with session initialization or possibly an application failure. If there are numerous logon/logoff cycles within a short time period, the threshold for the session is exceeded and a failure occurs. The session time, interval, and threshold can be configured by modifying the parameters in the Test file field. These parameters are listed and described in the following table.

Logon monitor test parameter SessionTime SessionInterval SessionThreshold

Description Defines the maximum session time for a short logon/logoff cycle. Default is five seconds. The time period designated to monitor logon/logoff cycles. Default is 600 seconds. The number of logon/logoff cycles that must occur within the session interval for the test to fail. Default is 50 cycles.

Remote Desktop Services test This test enumerates the list of sessions running on the server and the session user information, such as user name. XML Service test This test requests a ticket from the XML service running on the server and prints the ticket. Check DNS test This test performs a forward DNS lookup using the local host name to query the local DNS server in the computers environment for the computers IP address. A failure occurs if the returned IP address does not match the IP address that is registered locally. To perform reverse DNS lookups in addition to forward DNS lookups, use the flag /rl when running this test. Check Local Host Cache test Citrix does not recommend running this test unless you have problems with corrupted local host caches. This test ensures the data stored in the XenApp servers local host cache is not corrupted and that there are no duplicate entries. Because this test can be CPU-intensive, use a 24-hour test interval (86,400 seconds) and keep the default test threshold and time-out values.

354

Monitoring Server Performance with Health Monitoring &amp; Recovery Before running this test, ensure the permissions of the files and registry keys that the test accesses are set properly. To do this, run the LHCTestACLsUtil.exe file located in C:\Program Files (x86)\Citrix\System32 of the XenApp server. To run this utility, you must have local administrator privileges. Check XML Threads test This test inspects the threshold of the current number of worker threads running in the Citrix XML Service. When running this test, use a single integer parameter to set the maximum allowable threshold value. The test compares the current value on the XenApp server with the input value. A failure occurs if the current value is greater than the input value. Citrix Print Manager Service test This test enumerates session printers to determine the health of the Citrix Print Manager service. A failure occurs if the test cannot enumerate session printers. Microsoft Print Spooler Service test This test enumerates printer drivers, printer processors, and printers to determine whether or not the Print Spooler Service in Windows Server 2008 is healthy and ready for use ICA Listener test This test determines whether or not the XenApp server is able to accept ICA connections. The test detects the default ICA port of the server, connects to the port, and sends test data in anticipation of a response. The test is successful when the server responds to the test with the correct data.

355

Using Citrix Performance Monitoring Counters


Performance monitoring counters for ICA data are installed with XenApp and can be accessed from Performance Monitor, which is part of the Windows operating system. Performance monitoring provides valuable information about utilization of network bandwidth and helps determine if a bottleneck exists. By using Performance Monitor, you can monitor the following counters:
q

Bandwidth and compression counters for ICA sessions and computers running XenApp Bandwidth counters for individual virtual channels within an ICA session Latency counters for ICA sessions

1. On the server where XenApp is installed, open the Server Manager console. 2. In the Tree view, select Diagnostics > Performance > Monitoring Tools > Performance Monitor. 3. From the menu bar, selection Action > Properties. 4. In the Performance Monitors dialog box, select the Data tab. 5. Click Add. 6. In the Add Counters dialog box, from the Select counters from computer drop-down list, ensure Local computer is selected. 7. In the Available counters list, select ICA Session. 8. To add all ICA counters, in the Available counters list, select ICA Session. To add one or more ICA counters, click the plus sign next to ICA Session and select the individual counters to be added. 9. Select All instances to enable all instances of the selected ICA counters, No instance, or Select instances from list and highlight only the instances you need. In Performance Monitor, the instance list contains all active ICA sessions, which includes any session (shadower) that is shadowing an active ICA session (shadowee). An active session is one that is logged on to successfully and is in use; a shadowing session is one that initiated shadowing of another ICA session. Note: In a shadowing session, although you can select ICA counters to monitor, you see no performance data for that session until shadowing is terminated. 10. Click Add and then click Close.

356

Using Citrix Performance Monitoring Counters You can now use Performance Monitor to view and analyze performance data for the ICA counters you added. For more information about using Performance Monitor, see your Windows documentation.

357

Using Worker Groups for Enhanced Resource Access


Worker groups are collections of XenApp servers, residing in the same farm, that are managed as a single unit. Using worker groups, you can:
q

Streamline application publishing to multiple farm servers Load balance access to published resources Filter policies so that settings are applied only to sessions hosted on a specific set of farm servers Assign load evaluators to multiple farm servers

When using worker groups, consider the following:


q

A farm server can belong to multiple worker groups A worker group can include any number of XenApp servers or none at all Only servers that belong to the same XenApp farm are included in a worker group

Publishing Applications
When publishing an application, you can use worker groups to specify the servers hosting the application. To increase capacity for the application, you can add more servers to the worker group rather than modify the application properties. If your environment includes Active Directory, you can create the worker group based on the Organizational Unit (OU) that includes the servers hosting the application. To increase capacity for the application, you add servers to the OU. New servers that you add to the OU are automatically included in the worker group. When adding servers to worker groups for application publishing, all XenApp servers in the worker group must have the application installed. When a user attempts to launch an application, XenApp checks to ensure the application is installed on the farm servers in the worker group. If the application is not installed, the application does not launch and an error is logged to the Application event log on the data collector.

Load Balancing Access to Published Resources


To ensure an optimal experience for users accessing published resources, XenApp provides load balancing policies to direct users to the least-loaded XenApp server hosting the resource. You can use load balancing policies to:

358

Using Worker Groups for Enhanced Resource Access


q

Reduce WAN traffic by directing users to the closest regional server Direct users to a backup server in the event of an outage Direct a specific group of users to a group of dedicated servers

Load balancing policies consist of the following elements:


q

A filter to determine when the policy is applied A worker group preference list to determine the servers to which users are directed when logging on

When you create a load balancing policy, configure a filter so that the load balancing policy can be applied to users when they access published resources. If you do not configure a filter, the load balancing policy will have no effect when users log on. As with other Citrix policies, you can filter based on access control, client IP address, client name, and users. Important: Load balancing policies that are filtered based on client name have no effect on sessions created through Web Interface. This is because Web Interface does not provide the actual client name during load balancing. Instead, Web Interface overrides the client name when load balancing policies are evaluated, prior to session launch. When the session launches, Web Interface provides the correct client name. Additionally, to ensure users are directed to the appropriate servers, create a worker group preference list to prioritize the servers that users can access. A priority of 1 is considered the highest priority. When a user launches a published application, the load balancing policy directs the user to servers in the highest priority worker groups first. Users are directed to servers in lower priority worker groups if servers in the higher priority worker groups are offline or have reached maximum capacity. Users are not directed to servers in worker groups that are not included in the worker group preference list. If a user attempts to launch an application that is not installed on any servers in any of the listed worker groups, regardless of priority, the launch attempt fails and an error is logged to the Application event log on the data collector. After you create load balancing policies, you prioritize them just as you would any other Citrix policy. If multiple load balancing policies apply to a single user, XenApp uses the worker group preference list from the highest priority policy to direct the user. Preference lists from lower priority load balancing policies are not considered.

Using Worker Groups to Filter Policies


You can use the Worker Group filter in Citrix policies to apply policy settings to connections. When adding the filter, you can specify worker groups by entering the name or by selecting worker groups from a list. When entering worker groups by name, be aware that the policy engine does not check to ensure the accuracy of the entry. If the worker group name is entered incorrectly, or if the worker group is renamed or deleted, the policy engine does not recognize the filter and the policy filter is not applied. To ensure the worker groups specified are correctly entered, click the Browse button on the Add Filter Element dialog box. This enables XenApp to assemble a current list of

359

Using Worker Groups for Enhanced Resource Access worker groups in the farm. Although you can add multiple worker groups to the filter, you can select only one worker group from the list at a time. Note: When adding worker groups to the filter for the first time, the list of available worker groups appears after a delay of several seconds. However, this delay is reduced when adding subsequent worker groups to the filter.

Using Worker Groups to Assign Load Evaluators


To participate in load management, each XenApp server must have a load evaluator assigned to it. When assigning a load evaluator to farm servers, you add the Load Evaluator Name policy setting to a new or existing Citrix policy and select the load evaluator you want to assign. To specify the XenApp servers to be managed, you add the Worker Group filter to the policy and specify the worker group by name.

360

To create a worker group


1. From the Citrix AppCenter, select the Worker Groups node in the left pane. 2. From the Actions pane, click Create Worker Group. 3. In the Create Worker Group dialog box, type a name for the worker group. 4. In Select source, select one of the following options:
q

Select Active Directory Containers to add servers based on organizational unit membership. Select Active Directory Server Groups to add servers based on membership in a specific group.

Select Farm Servers to add individual XenApp servers to the worker group. Use this option if you do not use Active Directory in your environment. 5. Click Add.
q

6. Select the groups of servers you want to add to the worker group. For example, if you selected Active Directory Containers in the previous step, select the organizational units that contain the servers you want to add to the worker group. Note: Only XenApp servers that reside in the same farm are included in the worker group. If an organizational unit contains XenApp servers that reside in other farms, those servers are not considered part of the worker group.

361

Creating and Prioritizing Load Balancing Policies


1. From the Citrix AppCenter, select the Load Balancing Policies node in the left pane. 2. From the Actions pane, click Create load balancing policy. 3. Under Filters, select the filter to use to determine when the load balancing policy is applied. 4. Under Load Balancing Policies, select Worker Group Preference and then select Configure application connection preference based on worker group. 5. Click Add and select the worker group you want to include. 6. Click Add to add the worker group to the list. Each worker group you add is automatically assigned a priority, from highest (1) to lowest. 7. To adjust the priority of the worker groups in the list, select a worker group and then perform one of the following actions:
q

Click Set priority and enter the priority level you want for the worker group. Entering a priority for a worker group does not affect the priority of any other worker group in the list. Multiple worker groups can share the same priority. Click Increase Priority or Decrease Priority to adjust incrementally the priority of the worker group.

To adjust the priority of a load balancing policy


1. From the AppCenter, select the Load Balancing Policies node in the left pane. 2. From the middle pane, select a load balancing policy. 3. From the Actions pane, perform one of the following actions:
q

Click Set priority and enter the priority level you want for the policy. Click Increase priority or Decrease priority as appropriate to adjust incrementally the priority of the policy.

362

Enhancing the Performance of a Remote Group of Servers


For business continuity, you can specify that if all servers in a worker group go offline, XenApp redirects user connections to a backup worker group. This feature is known as Worker Group Preference and Failover; you configure it in the Citrix AppCenter through the Load Balancing Policies. As a best practice, to keep ICA traffic from going over the WAN, you should:
q

Direct requests for applications by specifying a Worker Group connection order in the Load Balancing Policies. Create a policy that applies to connections from a worker group. Then, specify that worker group as the Primary Group in the policy. This makes XenApp route incoming connection requests from users to that worker group first.

For more information about worker groups, see Creating Worker Groups.

363

Using Preferential Load Balancing


Preferential Load Balancing assigns importance levels (Low, Normal, or High) to specific users and applications. For example, doctors and nurses in a hospital are specified as important users and MRI scans and X-rays are specified as important applications. These important users and applications with higher levels of service connect to their sessions more quickly and have more computing resources available to them. By default, a Normal level of service is assigned to all users and applications. Preferential Load Balancing calculates importance levels based on the Resource Allotment for each session. The Resource Allotment is determined by the importance levels of both the session and the published application that the session is running. To enable Preferential Load Balancing, configure the Citrix Computer policy setting for Server Settings > Memory/CPU > CPU management server level and select Preferential Load Balancing. Continue by configuring the Citrix User policy setting for Server Session Settings > Session importance by setting the Value (High, Normal, Low). Sessions with higher importance levels are directed to servers with lower resource allotments. Finally, set the application importance level when publishing the application. You can modify an application's importance level in the Limits section of the application properties.

364

Resource Allotment
Resource Allotment is calculated based on the published application importance level and the result of the XenApp policy engine for that session. The policy engine bases the session result on the session importance policy setting. A sessions Resource Allotment determines the level of service it experiences in comparison with other sessions on the same XenApp server, as well as sessions on other XenApp servers. The higher a sessions Resource Allotment, the higher service it receives compared with those other sessions. The figure illustrates a XenApp farm running sessions with different Resource Allotments. It illustrates how a sessions Resource Allotment affects its competition with other sessions on the same server and on different servers. Session 1 on Server 2 has a relatively high Resource Allotment compared with all other sessions in the farm. As a result Session 1 gets the highest percentage of CPU cycles (90%) of any session running in the farm, and at the same time has to compete with fewer sessions on that server (there are only two sessions on Server 2, as opposed to three). Any new session would be assigned to Server 1 because it has the lowest Resource Allotment of the three servers. The session with the highest Resource Allotment gets the highest percentage of CPU cycles of any sessions running in the farm.

365

Resource Allotment

The three application importance settings have Resource Allotment values associated with them, as do the three session importance policy settings. To determine the effective Resource Allotment associated with a session running the published application, multiply the application importance value by the session importance policy value. The most powerful session is one with a high importance policy setting (3) running a high importance application (3), with a total Resource Allotment of 9 (3x3). Conversely, the least powerful session is one with a low importance policy setting (1) running a low importance application (1), with a total Resource Allotment of 1 (1x1). Use this table to help determine how to set your importance levels for applications and sessions.

Resource Allotments based on importance levels Application Importance Low (1) Low (1) Low (1) Normal (2) Session Importance (from policy) Low (1) Normal (2) High (3) Low (1) Session Resource Allotment 1 2 3 2

366

Resource Allotment Normal (2) Normal (2) High (3) High (3) High (3) Normal (2) High (3) Low (1) Normal (2) High (3) 4 6 3 6 9

367

Multiple Published Applications in the Same Session


Session sharing allows multiple published applications to run in the same session. During session sharing, the Resource Allotment is calculated based on the maximum application importance level setting of all the published applications running in the session multiplied by the session importance policy setting. When an application is launched in an existing session, the importance level of the new application is compared with the maximum of all current application importance levels. If the importance level of the new application is greater, the sessions Resource Allotment is recalculated and the sessions CPU entitlement adjusted upwards. Similarly, when an application is closed, if the maximum importance level of the remaining applications is lower, the sessions Resource Allotment is recalculated and the sessions CPU entitlement adjusted downward.

368

Managing CPU Usage


The CPU utilization management feature can be used to improve the ability of a farm to manage resources and normalize CPU peaks when the farms performance becomes limited by CPU-intensive operations. When you enable CPU utilization management, the server manages the share of the CPU allocated to each user. By default, this is an equal share. This prevents one user from impacting the productivity of other users and allows more users to connect to a server. This feature allows you to control the share. The CPU utilization management feature ensures that CPU resources are equitably shared among users by having the server allocate an equal share of the CPU to each user. This is accomplished by providing CPU reservation and CPU shares.
q

CPU reservation is a percentage of your servers CPU resource that is available to a user. If all of a reserved allocation is not being used, other users or processes can use the available resource, as needed. Up to 20% of the work capability of a single CPU on a server is always set aside for the local system account and is not available to users. CPU shares are percentages of the CPU time. By default, CPU utilization management allocates four shares for each user. If two users are logged on to a server and the local system account does not need any of the resources on the system, each user receives 50% of the CPU time. If there are four users, each user receives 25% of the CPU time.

Important: The range for CPU share is 1 through 64 percent. For CPU reservation, the total cannot be more than 99%, which represents the entire CPU resource on the computer. If you enable CPU utilization management, you must disable the Microsoft Dynamic Fair Share Scheduling (DFSS). Do not enable CPU utilization management on farms or servers that host:
q

CPU-intensive applications that may require a user to have a share of the CPU greater than that allocated to fellow users. Special users who require higher priority access to servers. You can exclude specified users from CPU restrictions.

To enable CPU utilization management


You can enable CPU utilization management using Citrix policy settings. This feature is not enabled by default. Important: The Dynamic Fair Share Scheduling (DFSS) aspect of the Windows Remote Desktop Services role is incompatible with CPU utilization management. Ensure that DFSS is disabled on each server where CPU Utilization Management is enabled.

369

Managing CPU Usage 1. Configure the Citrix Computer policy settings for Memory/CPU > CPU management server level. Choose one of the following settings:
q

Select Fair sharing of CPU between sessions to allocate an equal share of the CPU to each user.

Select Preferential Load Balancing to allocate shares based on importance levels. 2. Continue by applying one or more filters to the policy based on worker groups or organizational units.
q

370

Deploying virtual memory optimization


You can enhance system speed, performance, and scalability by improving virtual memory utilization for a server using the Citrix memory optimization service. The service improves how DLLs are shared among applications running on the server, saving virtual and real memory. The service changes the location that individual DLLs are loaded in memory to increase the amount of possible sharing. The process is called rebasing. Memory optimization is especially useful when user demand exceeds available RAM and causes farm performance to degrade. Performance degradation can occur during peak times when users run memory-intensive applications in multiple sessions. For a variety of reasons, not all applications can be successfully optimized. You can add those applications that cannot be optimized to an exclusion list to bypass optimization. You do not want to enable memory utilization management on farms or servers that exclusively host signed or certified applications because these cannot be optimized. XenApp can detect only some published applications that are signed or certified. The memory optimization feature includes the ability to set the schedule for DLL rebasing and to exclude specific applications from DLL rebasing. Rebasing is composed of two parts: A scanning component that locates modules that are candidates to be rebased, and a rewriting component that performs the optimization. If you enable memory optimization, the scanning component runs regularly on the server. However, the rewriting component runs only when scheduled.

To enable memory optimization


Configure the Citrix Computer policy setting for Memory/CPU > Memory optimization to enable the feature. Continue by creating a memory optimization schedule for when a server rebases DLLs and, if needed, an exclusion list of applications that cannot be optimized. To create the list, test the feature on a test server.

To test memory optimization before deployment


1. Using a test server hosting your published applications, enable memory optimization. 2. Schedule memory optimization. 3. After memory optimization completes, run all published applications. 4. Add to the exclusion list those applications that fail.

371

Deploying virtual memory optimization

To create an exclusion list of applications


Not all applications can be optimized successfully. The process automatically excludes some applications. However, if published applications fail after enabling and running memory optimization, exclude those applications from memory optimization by adding them to the exclusion list. Some types of application that cannot be optimized include:
q

Applications that reside on network shares (automatically excluded). Applications that have digitally signed components. Applications whose DLLs are protected by Windows Rights Management. For example, applications such as Office 2003 do not benefit from this feature. Applications whose executable programmatically checks the DLL after it is loaded. Applications that require a fixed DLL address.

In general, if an application was working, but it stops working after you enable this feature, add the application to the exclusion list and see if the problem is resolved. With memory optimization enabled, to exclude additional applications, configure the Citrix policy settings for Memory/CPU > Memory optimization application exclusion list by adding the full path and executable name for the application, for example: C:\\%Program Files%\ProgramName.exe where %Program Files% is the full path to the application.

To create a memory optimization schedule


After you enable virtual memory optimization, the server rebases DLLs automatically at server start-up. When the service rebases, it changes the location that individual DLLs are loaded in memory to increase the amount of possible sharing. You can create an additional virtual memory optimization schedule that identifies other times when a server rebases DLLs for greater operating efficiency. As a best practice, schedule virtual memory optimization at a time when your servers have their lightest loads. With memory optimization enabled, configure these Citrix Computer policy settings for Memory/CPU:
q

Memory optimization interval. Set the frequency internal to daily (default), weekly, monthly, or only when you restart your server. If you choose to run the program weekly or monthly, specify the day of the week or month. Memory optimization schedule: day of month (1 by default). Enter the day of the month using values 1-31. Note that if the specified day does not occur in a given month, such as day "31" in June, memory optimization does not run in that month. This setting is used only if you set the interval to Monthly.

372

Deploying virtual memory optimization


q

Memory optimization schedule: day of week (Sunday by default). Select the day of the week that memory optimization runs. This setting is used only if you set the interval to Weekly. Memory optimization schedule: time (3:00 AM by default). This setting is used only if you set the interval to Daily, Weekly, or Monthly.

373

Managing Farm Infrastructure


All farms include infrastructure functions to support the servers hosting published applications. Whether you configure these functions on shared or stand-alone servers depends on your farms size and requirements. Farms comprise at least one zone or grouping of servers. Multiple zones are sometimes used to improve the performance on geographically segmented farms. Within the zone, there is a data collector, which contains information about other servers in the farm, and servers designated as backup data collectors. If the data store fails, each server on the farm also contains a backup of all data store information, known as the local host cache.

374

Maintaining the Local Host Cache


A subset of data store information, the local host cache, exists on each server in the farm, providing each member server with quick access to data store information. The local host cache also provides redundancy of the data store information, if for example, a server in the farm loses connectivity to the data store. When a change is made to the farms data store, a notification to update the local host cache is sent to all the servers in the farm. However, it is possible that some servers will miss an update because of network problems. Member servers periodically query the data store to determine if changes were made since the servers local host cache was last updated. If changes were made, the server requests the changed information.

Refreshing the Local Host Cache


You can force a manual refresh of a servers local host cache by executing dsmaint refreshlhc from a command prompt. This action forces the local host cache to read all changes immediately from the farms data store. Refreshing the local host cache is useful, for example, if the Citrix Independent Management Architecture (IMA) Service is running, but published applications do not appear correctly when users browse for application sets. A discrepancy in the local host cache occurs only if the IMA Service on a server misses a change event and is not synchronized correctly with the data store.

Recreating the Local Host Cache


You can manually create the local host cache from the farms data store. If the IMA Service fails to start or you have a corrupt local host cache, you may need to recreate it. To recreate the local host cache, stop the IMA Service and then run the command dsmaint recreatelhc. Running this command performs three actions:
q

Sets the value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ RUNTIME\PSRequired to 1. Deletes the existing local host cache (Imalhc.mdb) Creates an empty local host cache (Imalhc.mdb)

You must restart the IMA Service after running dsmaint recreatelhc. When the IMA Service starts, the local host cache is populated with fresh data from the data store. The data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA Service fails to start.

375

Tuning Local Host Cache Synchronization


You can adjust the interval by which member servers query the farm's data store for missed changes. The default interval is 30 minutes. In most cases, this default setting is sufficient. 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. You can configure the interval by creating the following registry key on each server you want to adjust, with the value expressed in hexadecimal notation: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ DCNChangePollingInterval (DWORD) Value: 0x1B7740 (default 1,800,000 milliseconds) You must restart the IMA Service for this setting to take effect. Most changes made through the Citrix AppCenter are written to the data store. When you open one of these tools, it connects to a specified server. The Citrix Independent Management Architecture (IMA) Service running on this server performs all reads and write operations to the data store for the AppCenter. If the data store is experiencing high CPU usage when few read or write operations to the data store are occurring, it is possible that the data store is not powerful enough to manage a query interval of 30 minutes. To determine whether or not the data store query interval is causing the high CPU usage on the data store, you can set the query interval to a very large number and test CPU usage. If the CPU usage returns to normal after you set a large query interval, the data store query interval is probably the cause of the high CPU usage. You can adjust the query interval based on performance testing. To test the query interval, set the interval to 60 minutes and then restart all the servers in the farm. If the data store is still experiencing constant high CPU usage, increase the query interval further. If the CPU usage returns to normal, you can try a smaller value. Continue these adjustments until data store CPU usage is normal. Important: Do not set the data store query interval higher than necessary. This interval serves as an important safeguard against lost updates. Setting the interval higher than necessary can cause delays in updating the local host cache of the farms member servers.

376

To configure zones and back-up data collectors


A zone is a configurable grouping of XenApp servers. You can create zones during XenApp installation or after installation. For design considerations concerning zones and data collectors, see the topics Designing a XenApp Deployment. By default, all servers in the farm belong to the same zone, named Default Zone. Each zone in a server farm contains one server that is designated as the data collector for the zone. Data collectors store information about the servers and published applications in the zone. They act as communication gateways between zones in server farms that have more than one zone. Zones are view-only in the AppCenter, where, if needed, you can create new zones. Each zone must have at least one server; empty zones are automatically removed. When you create a server farm and whenever a new server joins a zone, a server is elected as the data collector for that zone. If the data collector for the zone becomes unavailable, a new data collector is elected for the zone based on a simple ranking of servers in the zone. Important: A primary domain controller or backup domain controller must not become the data collector for a zone. This situation may arise if XenApp is installed on Windows domain controllers. Citrix does not support installing XenApp on a domain controller. 1. From the AppCenter, select the farm. 2. Expand the server node and select Zones to view the existing zones for the farm. 3. To create or modify zones, on the Actions menu, under Zones, click New > Create a new zone to open the wizard (this option appears only if two or more servers exist in the farm). Follow the instructions to name the zone and add or remove servers. 4. On the Set server's election preferences page, select a server and click Edit to select the ranking for the server by choosing from the following election options:
q

Most Preferred. The server is always the first choice to become the data collector. It is recommended that only one server per zone be given this setting. Preferred. When electing a new data collector, XenApp elects the next collector from the Preferred servers if the Most Preferred server is not available. Default Preference. The default setting for all servers. The next collector is selected from the Default servers if neither a Most Preferred server nor a Preferred server is available.

Not Preferred. Apply this setting to servers that you do not want to become the data collector for the zone. This setting means that this server becomes the data collector only when no servers are available with any of the other three settings (Most Preferred, Preferred, Default Preference). 5. Restart the affected servers to apply the changes. This is required to update the data collector information for each zone.
q

377

To configure zones and back-up data collectors Zones are listed in the middle pane according to their election preference. To modify an existing zone
q

To rename a zone, from the Zones node, right-click the zone name and select Rename. To reset the ranking, right-click a server in the zone and select Change display > Election Preference. To move the selected server to another zone, right-click a server in the zone and select Change server's zone membership.

378

Updating Citrix License Server Settings


XenApp servers must point to the license server where license files are stored. The license server settings include the name of the license server that your farm accesses to check out licenses and the port number the license server uses to communicate. For details about setting the license server, see the installation topic Configuring XenApp Server Role License Information. You can change the settings through a Citrix Computer policy by specifying the name of the license server or port number that the license server uses to communicate in the Licensing section of the policy and apply the policy through filters. You may want to change these settings in the following instances:
q

You rename your license server. You want to point to a second license server to relieve some of the traffic to the first license server. For example, you have many connections and you find that it is slowing down the network, or you would like to add a second license server to the farm and point half of the connections to it. You want to specify another license server to point to individual servers to segregate licenses. For example, you want to host the accounting departments licenses on a server other than the human resources department. The default port number (27000) is already in use. You have a firewall between the license server and the computers running your Citrix products, and you must specify a static Citrix vendor daemon port number.

To change the name of the license server or port number that it uses to communicate, configure the Citrix Computer policy for Licensing by setting the following options:
q

Enter the License server host name of the server hosting XenApp licenses. Enter the License server port number (default 27000).

Changing the settings on this page is only one part of the procedure, however. If you decide to change the license server name, ensure that a license server with the new name already exists on your network. Because license files are tied to the license servers host name, if you change the license server name, you must download a license file that is generated for the new license server. This may involve returning and reallocating the licenses. To return and reallocate your licenses, go to www.mycitrix.com. If you change the port number, specify the new number in all license files on the server. For additional information, see Technologies > Licensing Your Product.

379

To set the product edition


The product editions of XenApp support different features. To activate the features available with a particular edition installed on each server, set the product edition on each server through Citrix policies. The product edition also determines which type of license a server requests from the license server. Make sure the edition you set match the licenses you installed. 1. Locate the Citrix Computer policies for Server Settings, and configure the XenApp product edition setting. 2. Create a filter to apply the policy to specific worker groups. 3. To apply the change, you must restart each server affected by the policy.

380

Configuring the Citrix XML Service Port and Trust


The Citrix XML Service is used by user devices connecting over the TCP/IP+HTTP protocol and the Web Interface. By default, XenApp server role installation configures the Citrix XML Service and Internet Information Service (IIS) to share the same TCP/IPport (80) for communications. In this case, you cannot change the XML Service setting. During the installation of Citrix XenApp on your server, you configured the XML Service to either share the port with your Microsoft Internet Information Server or to use a particular port. For details about the XenApp and Web Server (IIS) server roles, refer to the System Requirements topic for your version of XenApp. If you specified a custom XML Service port during installation, you can change the XML port number if necessary. Note: The port option appears only if you entered a different port number than the default Share with IIS during the Web Interface installation. Use the XML Service policy setting to change the port number.

To change the XML service port


1. Locate Citrix Computer policy setting for XML Service. 2. Configure the XML service port setting. Citrix recommends using port 8080.

To enable XenApp to trust requests sent to the XML Service


The trust setting is needed only for Smooth Roaming when users authenticate using pass-through or smart-card authentication with Web Interface, or for smart-card authentication with the Citrix Receiver (formerly called the Online Plug-in). Trust is not required for explicit authentication. 1. Locate Citrix Computer policy setting for XML Service. 2. Configure the Trust XML requests setting (disabled by default). If you do not trust XML requests, certain features of XenApp are not available. Trusting requests sent to the XML Service means:

381

Configuring the Citrix XML Service Port and Trust


q

Smooth Roaming works when connecting with the Web Interface using pass-through or smart card authentication, and when connecting with the Receiver using smart card authentication or the Kerberos pass-through option. For example, you can use workspace control to assist health-care workers in a hospital using smart cards, who need to move quickly among workstations and be able to pick up where they left off in published applications.

XenApp can use the information passed on from Access Gateway (Version 4.0 or later) to control application access and session policies. This information includes Access Gateway filters that can be used to control access to published applications and to set XenApp session policies. If you do not trust requests sent to the XML Service, this additional information is ignored.

Before enabling the Citrix XML Service to trust requests it receives, use IPSec, firewalls, or another technology to ensure that only trusted services communicate with the Citrix XML Service. To avoid security risks, enable the setting only under the following conditions:

Some users connecting to their sessions using the Web Interface are also using pass-through authentication or smart cards. The same users need to move from one client device to another and still be able to pick up where they left off in published applications. You implemented IPSec, firewalls, or any technology that ensures that only trusted services communicate with the XML Service. You are selecting this setting only on servers that are contacted by the Web Interface. You are restricting access to the XML Service to the servers running the Web Interface. When Internet Information Services (IIS) and the XML Service share a port, you can use IIS to restrict port access to include the IP addresses of servers running the Web Interface only.

382

To manually change the XML Service port to use a port different from IIS after installation
Note: This setting takes effect only after the XML Service restarts. The XML Service port set using a Group Policy Object takes precedence over the port you set using the command-line in this method. 1. At a command prompt, stop IIS by typing: net stop w3svc 2. Delete the following files from the IIS scripts directory on your Web server:
q

ctxadmin.dll CtxConfProxy.dll ctxsta.dll radexml.dll

q wpnbr.dll 3. At a command prompt, restart IIS by typing: net start w3svc The XML Service no longer shares a port with IIS.

4. To ensure the XML Service is stopped, at a command prompt, type: net stop ctxhttp 5. At a command prompt, to unload the XML Service from memory, type: ctxxmlss /u 6. To install the XML service, type: ctxxmlss /rnn where nn is the number of the port you want to use; for example, ctxxmlss /r88 forces the Citrix XML Service to use TCP/IP port 88. 7. At a command prompt, start the XML Service by typing: net start ctxhttp

383

To manually configure Citrix XML Service to share the TCP port with IIS
You must have Administrator privileges to configure the Citrix XML Service. 1. At a command prompt, stop the XML Service by typing: net stop ctxhttp 2. At a command prompt, to unregister the Citrix XML Service, type: ctxxmlss /u 3. Copy the following files to the IIS scripts directory on your Web server:
q

ctxconfproxy.dll ctxsta.config ctxsta.dll ctxxmlss.exe ctxxmlss.txt radexml.dll

wpnbr.dll These files are installed in \Program Files (x86)\Citrix\System32 during XenApp installation. The default scripts directory is \Inetpub\AdminScripts.
q

4. In the IIS scripts directory, create a folder called ctxadmin and copy the file ctxadmin.dll from \Program Files (x86)\Citrix\System32 to \Inetpub\AdminScripts\ctxadmin. 5. Ensure that you have read and write permission to the files in the IIS scripts directory; for example, use Windows Explorer to view and change the permissions. 6. At a command prompt, stop and restart the Web server by typing: iisreset This setting takes effect after the Web server restarts.

384

Manage Server and Resource Loads


You can set up, manage, and monitor server and published application loads in a server farm so that users can run the published applications they need quickly and efficiently. XenApp calculates the load on a server using load evaluators and rules. Each load evaluator contains one or more rules. Each rule defines an operational range for the server or published application to which its evaluator is assigned. For detailed descriptions of these rules, see List of Load Management Rules. The following load evaluators are included in XenApp:
q

Default. XenApp assigns the Default load evaluator to each server after you add your license to the server farm. It contains two rules: Server User, which reports a full load when 100 users log on to the attached server; and Load Throttling, which specifies the impact that logging on has on load and limits the number of concurrent connection attempts the server is expected to handle. Advanced. This load evaluator contains the CPU Utilization Load, Memory Usage, Page Swaps, and Load Throttling rules.

When a user selects a published application to run, the client on the user device contacts the server farm to locate the address of a server that hosts the published application. XenApp maintains a list of available host servers within the server farm. Upon receiving the clients request, XenApp selects the server with the lowest load and returns its address to the client. The client starts a session on that server and launches the published application. XenApp calculates a server load using the load evaluators attached to a server or published application. When any rule for any relevant load evaluator reports full load or exceeds its threshold, XenApp removes the load-managed server from the internal list of available servers. The next request for an ICA connection to a published application is routed to the next available load-managed server in the list.

Working with Load Evaluators


To access the load evaluators in XenApp, you select the Load Evaluators node in the left pane of the AppCenter. The following tabs are displayed:
q

Load Evaluators displays all the load evaluators created for the farm in a list. Beneath this list, the Current Settings tab displays at-a-glance the state of all the available load evaluator rules. Usage by Application displays the load evaluators that are attached to the farm's published applications. Usage by Server displays the load evaluators that are attached to each server in the farm.

385

Manage Server and Resource Loads

Considerations
When using load evaluators, consider the following:
q

You cannot modify or delete the Default or Advanced load evaluators. You cannot modify or delete existing rules. Additionally, you cannot create custom rules. Each server or application participating in load management can have only one load evaluator assigned. To assign load evaluators to servers, use Group Policy. You can assign load evaluators to individual applications on the server. Every XenApp server in the farm is included in the load calculation regardless of the network protocol unless the server reports full load. If a server reports full load, it is no longer available for load management until its load is reduced (for example, users log off from the server or server processes consume less CPU time). After the load is reduced, the server is added automatically to the list. Servers are continuously added to and removed from the list as server load and user activity fluctuate.

386

To create a new load evaluator


1. From the AppCenter, select Load Evaluators in the left pane. 2. From the Actions pane, select New > Add load evaluator. 3. On the Add Load Evaluator dialog box, type a name and description for the new load evaluator. 4. Select one or more rules from the Rules list and configure it as required.

To change the load evaluator's rules at any time, select the load evaluator you want to modify and then, from the Actions pane, click Modify load evaluator properties.

387

List of Load Management Rules


These load management rules are included in XenApp: Application User Load Limits the number of users allowed to connect to a selected published application. This rule monitors the number of active ICA sessions using the published application. The default value to report full load is 100. Context Switches Defines a range of context switches per second for a selected server. A context switch occurs when the operating system switches from one process to another. The default value to report full load is 16000. The default value to report no load is 900at that value this rule is ignored. This rule uses the System: Context Switches/sec performance counter to determine load. CPU Utilization Defines a range of processor utilization, as a percentage, for a selected server. The default value to report full load is 90 percent. The default value to report no load is 10 percentat that value this rule is ignored. This rule uses the Processor: % Processor Time performance counter to determine load. Disk Data I/O Defines a range of data throughput, in kilobytes per second, for a selected server. The default full load value is 32767 kilobytes per second. The default no load value is 0 kilobytes per secondat that value this rule is ignored. This rule uses the PhysicalDisk: Disk Bytes/sec performance counter to determine load. Disk Operations Defines a range of disk operation, in read/write cycles per second, for a selected server. The default full load value is 100 operations per second. The default no load value is 0at that value this rule is ignored. This rule uses the PhysicalDisk: Disk Writes/sec and Disk Reads/sec performance counters to determine load. IP Range Defines a range of allowed or denied client IP addresses for a published application. It controls access to a published application based on the IP addresses of the clients. You can define ranges of IP addresses, then select to allow or deny access if the client IP addresses are within the defined ranges. This rule must be used in conjunction with another. Load Throttling

388

List of Load Management Rules Limits the number of concurrent connection attempts that a server handles. This prevents the server from failing when many users try to connect to it simultaneously. The default setting (High impact) assumes that logons affect server load significantly. This rule affects only the initial logon period, not the main part of a session. The Load Throttling rule can be applied only to a server, not to an individual application. Memory Usage Defines a range of memory usage by a server. The default full load value is 90. The default no load value is 10at that value this rule is ignored. This rule uses the Memory: % Committed Bytes in Use performance counter to determine load. Page Fault Defines a range of page faults per second for a selected server. A page fault occurs when the operating system tries to access data that was moved from physical memory to disk. The default full load value is 2000. The default no load value is 0at that value this rule is ignored. This rule uses the Memory: Page Faults/sec performance counter to determine load. Page Swaps Defines a range of page swaps per second for a selected server. A page swap occurs when the operating system moves data between physical memory and the swap file. The default full load value is 100. The default no load value is 0at that value this rule is ignored. This rule uses the Memory: Pages/sec performance counter to determine load. Scheduling Schedules the availability of selected servers or published applications. This rule sets the weekly days and hours during which the server or published application is available to users and can be load managed. Server User Load Limits the number of users allowed to connect to a selected server. The default full load value is 100 and represents the maximum number of users the system can support on a server. Load Manager user loads are calculated using active ICA sessions only.

389

Assigning Load Evaluators to Servers and Applications


To participate in load management, each server or published application must have a load evaluator assigned to it. Each server or published application can have only one load evaluator attached. To assign a load evaluator to a XenApp server, configure the Load Evaluator Name policy setting and filter the policy by worker group. You can assign load evaluators that are available in any XenApp farm. The rules and their settings determine how the load of a particular server or published application is managed. For example, if you have a published application that uses a significant percentage of a servers memory and processing capabilities, you can add the Load Evaluator Name setting to a policy, specify the Advanced load evaluator, and filter the policy by the worker group that contains all the XenApp servers hosting the application. XenApp then distributes the available memory and processor demand across the load-managed servers. When you assign a load evaluator through Citrix policies, XenApp does not validate the load evaluator name when the policy is applied to user sessions. Therefore, if the load evaluator is later renamed or deleted, the load cannot be calculated. Instead, XenApp logs an error to the Event Log and the affected servers report a load index of 10,000 (full load). Additionally, the Usage by Server tab in the middle pane of the AppCenter does not indicate the load evaluator is assigned. To ensure the policy references the correct load evaluator name, modify the Load Evaluator Name policy setting and select the correct load evaluator name from the list of available load evaluators. If the policy containing the Load Evaluator Name setting is deleted, and no other policy applied to the server specifies an alternate load evaluator, XenApp uses the Default load evaluator instead.

To assign a load evaluator to a server


1. Create a new Computer policy or select an existing Computer policy you want to modify. Depending on the console you use to manage Citrix policies:
q

From the AppCenter, select the Policies node and then select the Computer tab.

From the Group Policy Management Editor, select Computer Configuration > Policies > Citrix Policies. 2. From the settings list, locate the Load evaluator name policy setting and click Add.
q

3. Select a load evaluator from the drop-down list and then click OK. 4. Add the Worker Group filter to the policy and specify the worker group containing the servers to which you want to assign the load evaluator.

390

Assigning Load Evaluators to Servers and Applications

To assign a load evaluator to a published application


1. From the AppCenter, select the Applications node in the left pane. 2. Select the published application to which you want to attach a load evaluator. 3. From the Actions pane, select Other Tasks > Attach application to load evaluator. 4. On the Assign Load Evaluator dialog box, select the load evaluator to attach.

391

Scheduling Server Availability


Use the Scheduling rule to determine when a server or published application is available to users and can be load managed. If this rule is included in a load evaluator and attached to a server or published application, the server or published application is available only during the days and times set in this rule. The Scheduling rule must be used with at least one other rule. It cannot be the only rule in a load evaluator. You cannot apply the Scheduling rule to any custom ICA connections that connect to specific servers. Custom ICA connections cannot be controlled using the Scheduling rule.

To configure the Scheduling rule


1. In the AppCenter, select Load Evaluators in the left pane. 2. In the middle pane, select the load evaluator you want to change. 3. From the Actions pane, select Modify load evaluator properties. 4. From the Rules list, select the Scheduling rule. 5. In the Scheduling Settings panel, use the Add and Remove buttons to select the days and times that you want the server or published application to be available (Monday through Friday, 8:00 AM to 6:00 PM, by default).

392

Power and Capacity Management


Citrix XenApp Power and Capacity Management can help reduce power consumption and manage XenApp server capacity by dynamically scaling up or scaling down the number of online XenApp servers. Consolidating sessions onto fewer online servers improves server utilization, helps minimize power consumption, and helps provide sufficient capacity to handle server loads. As users log on to the system and reduce the idle capacity (the amount of capacity available for additional sessions), other servers in the workload are powered up. As users log off and idle capacity increases, idle servers are powered down. This helps optimize capacity for XenApp workloads. Scheduling provides an automated approach. An administrator defines specific times for powering on and powering off workloads. For example, a schedule powers on servers at 8 in the morning and powers them down at 7 in the evening, from Monday through Friday. The administrator can manually override capacity and schedule settings to accommodate unexpected demand. Load consolidation and power management operate in unison; load consolidation ensures sessions are not spread across online servers, which provides a better opportunity to power off excess servers later, using power management. Use Power and Capacity Management to observe and record utilization and capacity levels. Console monitoring and report generation provide valuable information, even if you do not enable power management and load consolidation. Power and Capacity Management respects all configured XenApp server settings, farm settings, and policies.

System Components
The Power and Capacity Management system comprises the following components. (From a Windows installer viewpoint, these are features; this documentation uses the term components.) Component Concentrator Description A Windows service and the central component of the Power and Capacity Management system. It coordinates system states and operations for the managed XenApp servers. You can have one or more concentrators; if you have more than one, and one fails, another assumes control. An instance of a Microsoft SQL Server database. It provides the common store for information such as managed server inventory, workload assignments, schedules, metric data, and configuration settings.

Database

393

Power and Capacity Management Reporting Subfeature of the database component. Reports are hosted on Microsoft SQL Server Reporting Services. The administrator generates reports for historical system loads, capacities, and utilization summaries. A Microsoft Managed Console (MMC) snap-in to manage, monitor, and configure the Power and Capacity Management system.

Management console

A Windows service installed on each XenApp server. The agent reports capacity and system states, and acts on operations and commands issued by the concentrator. The concentrator, database, reporting, and management console components are the administration components.

Agent

394

About Load Consolidation and Power Management


Concepts and Terminology
For XenApp Power and Capacity Management, capacity is expressed as a number of sessions (or session count). The XenApp servers being managed by Power and Capacity Management are called a farm. This farm may include some or all of the servers in a XenApp farm, or it may contain XenApp servers from different XenApp farms (for example, in a XenApp farm that covers multiple sites, you might have a Power and Capacity Management farm for the XenApp servers in each site). The Power and Capacity Management farm name is distinct from the XenApp farm name. A workload is a logical grouping of servers that all host the same application or set of applications. (In XenApp terms, this is referred to as an application silo.) The workload is named when the Power and Capacity Management agent is configured. You use setpoints in the schedule to control how servers are power managed and how load is consolidated within the workload. A setpoint represents a target number of sessions or the number of online servers. In a Power and Capacity Management farm, a XenApp server's control mode (configured in server properties) affects whether the server is eligible for power management or participating in load consolidation. (You also enable power management and load consolidation for the workload.)

What Happens during Load Consolidation


Load consolidation has the opposite effect to traditional XenApp load balancing. Its goal is to consolidate sessions onto fewer servers instead of spreading load evenly across many servers. By consolidating sessions, there is greater opportunity to power down excess servers, saving power and reducing operating costs. Greater consolidation of sessions equates to higher levels of utilization per server while online. Load consolidation works by continually monitoring the number of active sessions and remaining capacity for each server. The goal is to load new sessions onto small groups of servers to a level that the servers can handle well; this level is the optimal load (set in global configuration). Once a server reaches its optimal load, an additional server in the workload is enabled to accept new session load. When power management is used, this additional server will be powered on automatically if it is currently powered off. For load consolidation to work effectively, the capacity level of each server must be measured. Because the remaining capacity can change as load on the server fluctuates, capacity levels are continually re-evaluated. This is known as dynamic capacity estimation.

395

About Load Consolidation and Power Management Dynamic capacity estimation calculates individual server capacities based on the load on each server. The capacity of each server more accurately reflects the actual number of sessions it can handle. The load on each server is determined by its assigned XenApp load evaluator; therefore, consider the desired load criteria when configuring the assigned evaluators. The Power and Capacity Management agent regularly monitors the load and updates the estimated capacity on its server. Depending on the load, the estimation may determine that a server is capable of holding more sessions than the configured typical capacity. To allow the dynamic capacity estimation to set capacities higher than the typical value, you can set the estimated capacity limit to any value higher than the typical capacity. The typical session capacity and estimate session capacity limit are configured in the server profile.

What Happens during Power Management


When Power and Capacity Management determines that a power on or power off operation is required, it considers a server's power controller preference (configured in server properties). XenApp servers installed on virtual machines can also have a site-specific power controller preference (configured for the site); sites are specified when configuring virtual machine managers. For a power on operation, the selection algorithm chooses a server with a higher power controller preference before a server with a lower preference. For a power off operation, the algorithm chooses a server with a lower power controller preference before a server with a higher preference. For best practice, configure the preference of more power-efficient servers higher than older, less power-efficient servers. When Power and Capacity Management selects a XenApp server for power off and that server is currently hosting sessions, the server is placed into PCM drain mode (which is separate from XenApp drain mode). When a server is in PCM drain mode, load balancing attempts to avoid starting new sessions on that server. All valid servers in a worker group (online, hosting the desired application, and with available load) that are not in PCM drain mode are used before any servers at that worker group priority level that are in PCM drain mode. However, if no servers meet that criteria, the session is started on the server in PCM drain mode. Sessions hosted on a server in PCM drain mode can use session sharing. A server in PCM drain mode allows reconnection of disconnected sessions. If you disable power management for a workload, any servers currently in drain mode revert out of drain mode. In meeting capacity setpoints, Power and Capacity Management ignores the load from servers that are currently draining or powering off, as well as servers currently being evaluated for draining/power off. A server in drain mode powers off only when no sessions remain. If the agent loses connection to the concentrator, the agent reverts drain mode on draining servers. When Power and Capacity Management issues a power off or power on control, a timer starts (with a value configured in the server profile). If the operation does not complete successfully before the timer expires, the management console displays the failure. When a power control operation completes successfully, all control errors associated with that server are cleared.

396

Installing Power and Capacity Management


To install Power and Capacity Management components, you can:
q

Use the XenApp media to launch an interactive installation. Point to the XenApp media and issue commands for a silent installation. Use the XenApp Server Role Manager. Important: When using the wizard-based Server Role Manager, install the Power and Capacity Management agent when you install the XenApp server role. If you do not install them at the same time, install the agent using another method.

The following MSI packages contain the Power and Capacity Management components. Installation Package XenAppPCMAgent64.msi XenAppPCMAdmin.msi Description Installer for the agent. Combined installer for the administration components; use this MSI to install the database, reports, and management console on a supported 32-bit computer.

Combined installer for the administration components; use this MSI to instal the database, reports, concentrator, and management console on a supported 64-bit computer. Install the agent on each XenApp server. You can install all the administration components on a single computer, or you can install one or more administration components on separate computers. If you are not installing all the administration components at the same time on the same computer, install them in the following order: 1. Database 2. Reports (Reports is a subfeature of the database feature; therefore, you can install reports only if you are also installing the database component, or if you previously installed the database component) 3. Concentrator 4. Management console

XenAppPCMAdmin64.msi

397

System Requirements for Power and Capacity Management

Supported Platforms
A Power and Capacity Management farm can comprise physical and virtual XenApp servers:
q

Wake-on-LAN (WoL) power control is supported for physical XenApp servers on the same subnet. Power-on commands to virtual computers hosting XenApp servers (in one or more clusters) are supported for the following platforms, or subsequent compatible versions:
q

Citrix XenServer 4.0 Microsoft Hyper-V 1.0 Microsoft SCVMM 2008 VMware ESX and vCenter 4.0

Component Requirements
Unless otherwise noted, 32-bit and 64-bit operating system editions are supported. Component Database Support and Requirements Requirements:
q

Microsoft .NET Framework 3.5 SP1 Microsoft SQL Server 2005 SP3 and SP4 or Microsoft SQL Server 2008 R2; see CTX114501 for the latest supported versions Microsoft SQL Server Reporting Services Internet Information Services (IIS) 6.0 and ASP.NET (required only if using Reporting Services on Microsoft SQL Server 2005)

Use Microsoft Internet Explorer to view reports.

398

System Requirements for Power and Capacity Management Concentrator Supported operating systems:
q

Windows Server 2008 R2 (64-bit) Windows Server 2008 R2 SP1 (64-bit)

Requirement: Microsoft .NET Framework 3.5 SP1 For XenApp servers on the Microsoft SCVMM 2008 platform, the Microsoft SCVMM 2008 console must be installed on each server hosting a concentrator (master and slaves). Agent Supported operating systems:
q

Windows Server 2008 R2 (64-bit) Windows Server 2008 R2 SP1 (64-bit)

Requirements:
q

Microsoft .NET Framework 3.5 SP1 XenApp 6.5

Management console

Supported operating systems:


q

Windows Server 2008 R2 (64-bit) Windows Server 2008 R2 SP1 (64-bit) Windows Server 2003 R2 Windows Server 2003 (32-bit) Windows 7 Enterprise SP1 Windows Vista SP2 Windows XP SP3 (32-bit), SP2 (64-bit)

Requirements:
q

Microsoft .NET Framework 3.5 SP1

MMC 3.0 Update: http://support.microsoft.com/kb/907265 (pre-installed on Windows Vista, Windows 7, and Windows Server 2008 R2 systems) Identify the XenApp servers you want in the Power and Capacity Management farm. For optimal operation, Power and Capacity Management should register (discover) all servers in the XenApp farm. You can then change the control mode (in server properties) for servers that are not power controlled. This practice prevents the possibility of session load being sent to XenApp farm servers that Power and Capacity Management is not managing or has not discovered.
q

The XenApp servers on which you install the Power and Capacity agent, and the computers on which you install the concentrator and management console must all belong to the same

399

System Requirements for Power and Capacity Management Active Directory domain. Install the database component either in the same Active Directory domain as the other components or in a trusted domain. You do not have to run the installation of the Power and Capacity Management database component on the server where Microsoft SQL Server is installed. You can either run the installation process physically on the SQL Server or from any domain member machine. If you run the installation of the database component from a different server than SQL Server, the server on which you install the database component does not need to stay powered on.

Using Policies
You can use Citrix group computer policy settings to specify the Power and Capacity Management farm name and workload name, which apply to agent configuration. For information about specifying setting values, see Policy Settings Reference. Note the warning not to enable the Use default value checkbox for the farm name setting. When using the XenApp Server Role Manager, the Power and Capacity Management farm name and workload name are not written to local policy, and the Agent service is not started, until after the XenApp Server Configuration Tool successfully configures the XenApp server role and the server restarts.

Installing the Concentrator


When installing the concentrator, you specify the database (and the database instance, if you are not using the default instance). By default, the installer updates the database to give the concentrator necessary permissions. This action assumes that the user installing the concentrator has administrator privileges on the SQL Server instance to modify the permissions of the Power and Capacity Management database. If the user installing the concentrator does not have administrator privileges on the SQL Server to modify the permissions of the Power and Capacity Management database:
q

In a wizard-based installation, select the Do not grant DB access to concentrator check box. (This check box appears only when you are not installing the concentrator and the database at the same time.) In a silent installation, include the CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes property.

Then use SQL Server Management Studio to add the necessary permissions to the database: 1. Using SQL Server Management Studio, navigate to the main Security - Logins node. 2. Add a new login for the concentrator identity. If you are running the concentrator as the default network service, this is domain-name\computer-name$. (If you are entering a machine account, type the machine account name; do not use the Search button.) 3. Navigate to XenAppPCM database > Security > Users.

400

System Requirements for Power and Capacity Management 4. Add a new user. Citrix recommends the User Name be the same as the Login Name you specified in step 2. In the role membership list, select ConcentratorRole. If you plan to use more than one concentrator, after installing the first concentrator on a machine, install another on a different computer, and repeat as needed. Ensure that you install only the concentrator. In the wizard based installation, deselect all other components. In a silent installation, include the ADDLOCAL=Concentrator property. See Managing the Concentrator for information about manually publishing the concentrator in Active Directory.

401

Interactively Installing Components


Before interactively installing the Power and Capacity Management components, review the silent installation properties to learn about information you specify during the interactive installation.

To interactively install the agent from the XenApp media


Choose one of the following:
q

On the XenApp media, launch autorun.exe. From the Autorun menu, select Manually install components > Server Components > Power and Capacity Management > Power and Capacity Management Agent. On the XenApp media, go to the Power and Capacity Management folder and double-click XenAppPCMAgent64.msi. Follow the wizard prompts.

To interactively install the administration components from the XenApp media


Choose one of the following:
q

On the XenApp media, launch autorun.exe. From the Autorun menu, select Manually install components > Server Components > Power and Capacity Management > Power and Capacity Management Administration. If you are installing the components on a 32-bit operating system, go to the Power and Capacity Management folder on the XenApp media and double-click XenAppPCMAdmin.msi. Follow the wizard prompts. If you are installing the components on a 64-bit operating system, go to the Power and Capacity Management folder on the XenApp media and double-click XenAppPCMAdmin64.msi. Follow the wizard prompts.

By default, all administration components are selected in an interactive installation, except reports.

To interactively install components from the XenApp Server Role Manager


To use the XenApp Server Role Manager, follow the guidance in Install and Configure.

402

Interactively Installing Components


q

To install the agent, select the Power and Capacity Management Agent check box in Optional Components. When you configure the XenApp role with the XenApp Server Configuration Tool, specify the PCM farm and workload names when prompted. Important: Install the Power and Capacity Management agent at the same time you install the XenApp server role; otherwise, use another method to install the agent.

To install administration components, select the Power and Capacity Management Administration role. After the Server Role Manager installs other selected roles, components, and prerequisites, click the Install link next to Power and Capacity Management. Follow the wizard prompts. By default, all administration components are selected in an interactive installation, except reports.

403

Silently Installing Components

To silently install the agent from the XenApp media


Point to the XenApp media and enter the following command: msiexec /i XenAppPCMAgent.msi /qn CTX_XAPCM_ACCEPT_EULA=yes CTX_XAPCM_FARM_NAME=farm-name [CTX_XAPCM_WORKLOAD_NAME=workload-name] [CTX_XAPCM_AGENT_NOSTART=yes] [CTX_XAPCM_AGENT_NOPOLICY=yes] [CTX_XAPCM_AGENT_ACCOUNT=domain-account] [CTX_XAPCM_AGENT_PASSWORD=domain-account-password Agent Installation Properties CTX_XAPCM_ACCEPT_EULA=yes Accepts the license agreement. To read the EULA (End User License Agreement), launch the installation interactively and navigate to the license dialog. If you omit this property, or if the specified value is not "yes," the installation fails. CTX_XAPCM_FARM_NAME=farm-name Farm name, up to 80 characters, and cannot contain: backslash (\), single quote ('), forward slash (/), double-quote ("), less-than (<), greater than (>), pipe (|), or equal (=). The collection of XenApp servers being managed by Power and Capacity Management is known as a farm. This farm may include some or all of the servers in a XenApp farm or may contain XenApp servers from different XenApp farms. The name must be unique. If you omit this property, the installation fails. CTX_XAPCM_WORKLOAD_NAME=workload-name Workload name, up to 256 characters. A workload is a logical grouping of servers that all host the same application or set of applications. In XenApp terms, this is referred to as an application silo. If you omit this property, "Unassigned" is used. (You cannot enable power management or load consolation for an unassigned workload.) CTX_XAPCM_AGENT_NOSTART=yes Prohibits the Agent service from starting during installation. If you omit this property, or if the specified value is not "yes," the Agent service starts during installation.

404

Silently Installing Components CTX_XAPCM_AGENT_NOPOLICY=yes Prohibits the agent installer from writing the farm and workload names to local policy. If you omit this property, or if the specified value is not "yes," the farm and workload names are written to local policy. CTX_XAPCM_AGENT_ACCOUNT=domain-account Domain account with the following rights:
q

Citrix administrator for the XenApp instance Log on as service Shut down the system

Query rights for Active Directory (to locate the "Citrix XenAppPCM" SCP for the farm assigned to this agent) If you specify this property, you must specify a domain account password with the CTX_XAPCM_AGENT_PASSWORD property. You must also supply a domain account with the CTX_XAPCM_CONCENTRATOR_ACCOUNT property when installing the concentrator. (The Concentrator service cannot use a built-in account if the Agent service uses a domain account; similarly, the Concentrator service cannot use a domain account if the Agent service uses a built-in account.)
q

If you omit this property, the built-in "Local System" account is used. In this case, do not specify the CTX_XAPCM_AGENT_PASSWORD property. CTX_XAPCM_AGENT_PASSWORD=domain-account-password Password for the domain account. This property is valid only if you specified a domain account with the CTX_XAPCM_AGENT_ACCOUNT property. For example, the following command silently installs the agent with:
q

A farm name of "my_farm" A workload name of "my_workload" The agent service running under the domain account "my_domain\my_user" with the password "my_password"

msiexec /i XenAppPCMAgent.msi /qn CTX_XAPCM_ACCEPT_EULA=yes CTX_XAPCM_FARM_NAME=my_farm CTX_XAPCM_WORKLOAD_NAME=my_workload CTX_XAPCM_AGENT_ACCOUNT=my_domain\my_user CTX_XAPCM_AGENT_PASSWORD=my_password

To silently install the administration components from the XenApp media


Point to the XenApp media and enter the following command: 405

Silently Installing Components msiexec /i XenAppPCMAdmin.msi /qn CTX_XAPCM_ACCEPT_EULA=yes [ADDLOCAL=components] [CTX_XAPCM_FARM_NAME=farm-name] [CTX_XAPCM_DB_INSTANCE=db-instance] [CTX_XAPCM_DB_NAME=db-name] [CTX_XAPCM_REPORT_URL=report-url] [CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes] [CTX_XAPCM_CONCENTRATOR_ACCOUNT=domain-account] [CTX_XAPCM_CONCENTRATOR_PASSWORD=domain-account-password Administration Component Installation Properties CTX_XAPCM_ACCEPT_EULA=yes Accepts the license agreement. To read the EULA, launch the installation interactively and navigate to the license dialog. If you omit this property, or if the specified value is not "yes," the installation fails. ADDLOCAL=components Comma-separated list of components to be installed. Valid values are:
q

DatabaseInstaller Reports Concentrator

Console Reports is a subfeature of the database component; therefore, you can install reports only if you are also installing the database component, or if you previously installed the database component.
q

If you omit this property, the database, concentrator, and management console components are installed; reports is not installed. CTX_XAPCM_FARM_NAME=farm-name Use this property when installing the database component. Farm name, up to 80 characters, and cannot contain: backslash (\), single quote ('), forward slash (/), double-quote ("), less-than (<), greater than (>), pipe (|), or equal (=) . The collection of XenApp servers being managed by Power and Capacity Management is known as a farm. This farm may include some or all of the servers in a XenApp farm, or it may contain XenApp servers from different XenApp farms. The name must be unique. If you are installing the database component and omit this parameter, the installation fails.

406

Silently Installing Components CTX_XAPCM_DB_INSTANCE=db-instance Use this property when installing the database, reports, and concentrator components. Database instance name.
q

If you are installing the database component, this property specifies the instance name of the SQL Server instance in which the Power and Capacity Management database schema is to be installed. If you are using the default SQL instance on this computer, specify "." (dot); otherwise, specify the computer and instance name (for example, SQLServer\instance1).

If you already installed the database component and are installing the concentrator, this property specifies the instance name of the SQL Server instance in which the schema is installed. If the default SQL instance on this computer was used, specify "." (dot); otherwise, specify the computer and instance name (for example, SQLServer\instance1"). If you omit this property, "." is used.
q

CTX_XAPCM_DB_NAME=db-name Use this property when installing the database, reports, and concentrator components. Database name, up to 123 characters. and cannot contain: semicolon (;), question mark (?), colon (:), at (@), ampersand (&), equal (=), plus (+), dollar ($), backslash (\), asterisk (*), less-than (<), greater-than (>), pipe (|), double-quote ("), forward-slash (/), single-quote ('), back-tick (`), left square bracket ([), right square bracket (]). If you omit this property, "XenAppPCM" is used. CTX_XAPCM_REPORT_URL=report-url Use this property when installing the reports component. Report service URL, up to 512 characters.
q

If you are using the default SQL Server instance, specify the server URL http[s]://server_name/ReportServer. If you are using a named SQL Server 2005 instance, specify the server URL qualified with the instance name (http[s]://server_name/ReportServer$instance_name.

If you are using a named SQL Server 2008 instance, specify the server URL qualified with the instance name (http[s]://server_name/ReportServer_instance_name. If you omit this property, "http://local_machine_name/ReportServer" is used.
q

407

Silently Installing Components CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes Use this property when the person installing the concentrator does not have administrator rights to the database. In this case, the database administrator must manually add the correct account to the database. If you omit this property, or if the specified value is not "yes," the database is configured to accept connections from the concentrator. CTX_XAPCM_CONCENTRATOR_ACCOUNT=domain-account Use this property when installing the concentrator. Domain account with a userPrincipleName attribute within Active Directory with the following rights:
q

Log on as service

Read/write rights for Active Directory (to create the "Citrix XenAppPCM" SCP for the farm this concentrator manages); for example, read/write access to the Active Directory concentrator computer container (CN) If you specify this property, you must specify a password with the CTX_XAPCM_CONCENTRATOR_PASSWORD property. You must also supply a domain account for the CTX_XAPCM_AGENT_ACCOUNT property when installing the agent. (The Concentrator service cannot use a built-in account if the Agent service uses a domain account; similarly, the Concentrator service cannot use a domain account if the Agent service uses a built-in account.)
q

If you omit this property, the built-in "Network Service" account is used. In this case, do not specify the CTX_XPCM_CONCENTRATOR _PASSWORD property. CTX_XAPCM_CONCENTRATOR_PASSWORD=domain-account-password Use this property when installing the concentrator and only if you specified a domain account with the CTX_XAPCM_CONCENTRATOR_ACCOUNT property. Password for the domain account. For example, the following command silently installs all the administration components with:
q

A farm name of "my_farm" The default SQL Server instance on a server named "my_db" with a database name of "my_dbname" Reporting services on "http://my_report_server/reportserver" The concentrator running under the domain account "my_domain\my_user" with the password "my_password"

msiexec /i XenAppPCMAdmin.msi /qn CTX_XAPCM_ACCEPT_EULA=yes ADDLOCAL=Concentrator,Console,DatabaseInstaller,Reports CTX_XAPCM_FARM_NAME=my_farm CTX_XAPCM_DB_INSTANCE=my_db CTX_XAPCM_DB_NAME=my_dbname

408

Silently Installing Components CTX_XAPCM_REPORT_URL=http://my_report_server/reportserver CTX_XAPCM_CONCENTRATOR_ACCOUNT=my_domain\my_user CTX_XAPCM_CONCENTRATOR_PASSWORD=my_password

To silently install components using the XenAppSetupConsole.exe command


To use the XenAppSetupConsole.exe command, follow the guidance in Install and Configure. To install the agent, include the PCMAgentFeature property (for example, /install:XenApp,PCMAgentFeature). When you configure the XenApp role, specify the Power and Capacity Management farm name and workload name (using the /PcmFarmName and /PcmWorkloadName options). To install the administration components, include the PCMAdmin property (for example, /install:PCMAdmin).

409

Upgrading Administration Components


The Power and Capacity Management component packages on the XenApp 6.5 media are supported on XenApp 6.5 deployments. You can also use the administration component packages on that media (XenAppPCMAdmin.msi and XenAppPCMAdmin64.msi) to upgrade all the administration components previously installed in a XenApp 6.0 deployment. Important: You must upgrade all of the administration components (concentrator, database, reports, and management console); upgrading fewer is not supported. To upgrade the administration components in a XenApp 6.0 deployment, load the XenApp 6.5 media and use one of the following methods:
q

From the XenApp Server Role Manager, click the Upgrade link next to Power and Capacity Management. Follow the wizard prompts. From the media, follow the same procedure you used to install the Power and Capacity Management administration components in the XenApp 6.0 deployment.

During the upgrade, the installed components are uninstalled, and the newer version installed. Repeat as needed on all the computers hosting Power and Capacity Management administration components in the XenApp 6.0 deployment. You cannot (and do not need to) upgrade the Power and Capacity Management agents in a XenApp 6.0 deployment. Continue using the agents you originally installed on the XenApp 6.0 servers.

410

Removing Components
To remove Power and Capacity Management components, use Windows Programs & Features or Add/Remove Programs.

Removing a Concentrator
Removing an inactive non-master (slave) concentrator through Windows Programs & Features may not remove the database entry. If this occurs, the concentrator continues to appear in the Cluster Management window. To remove the database entry: 1. From the management console, click Cluster Management in the Actions pane. 2. In the Cluster Management dialog box, ensure that the Concentrator service for the concentrator you want to remove is stopped (State = Service stopped). 3. Select the concentrator and then click Remove Slave. 4. Confirm the removal. Note: You may still need to manually delete the concentrator's SCP entry from Active Directory.

411

Configuring and Using Power and Capacity Management


After installing the components, first-time use of the Power and Capacity Management system includes specifying configuration values. With a basic setup (using default setpoint values and without enabling load consolidation or power management), you can monitor the system and create reports. 1. (Required only if you have more than one Power and Capacity Management farm.) Connect to the Power and Capacity Management farm. In the Actions pane, click Connect to XenApp PCM Service, then select the Power and Capacity management farm you want to manage. 2. Complete the following initial configuration tasks:
q

Configuring a Server Profile Configuring Server Properties Setting Global Configuration Values Configuring Sites Adding Virtual Machine Managers

Managing the Concentrator 3. After the initial setup, observe management console displays and generate reports. Using the collected information, you can then:
q q

Creating Setpoints and Schedules Enabling Load Consolidation and Power Management

Understanding Management Console Displays


The management console connects to the master concentrator to obtain data. The menu, toolbars, and Actions pane are standard MMC 3.0 panes, some of which can be hidden if required. The workloads and tabs panes comprise the Power and Capacity Management snap-in. The workloads pane contains the following information: Workloads pane columns Workload All Workloads, plus names of individual workloads

412

Configuring and Using Power and Capacity Management Power Managed Indicates power management status for the system (All Workloads) and for each workload.
q

Checkmark = enabled ("override" indicates a manual override is in effect) x = disabled (with a notation if a workload does not have a schedule)

Load Consolidated Indicates load consolidation status for the system (All Workloads) and for each workload.
q

Checkmark = enabled x = disabled

Utilization Current utilization shown in meter form and percent text (utilization is the ratio of: total active sessions/total session capacity available from all online servers) Sessions Current number of load, unused, and offline sessions, shown graphically and in absolute counts. Servers Current number of online and offline servers in the workload, shown graphically and in absolute counts. The tabs pane contains the following information: Tabs Status Utilization, sessions, and servers information is equivalent to the information for the selected workload in the workloads pane above it. With power management enabled, the display includes current setpoint values.
q

For workloads with an empty schedule and no override, the display shows the default setpoint values. When the power controller is following the schedule for a workload, the display shows the scheduled setpoint values. When the power controller is following override setpoints for a workload, the display shows those values.

Performance Displays metric graphs collected for a specific interval. After you select an interval, the display shows values collected throughout the interval for utilization, sessions, and servers, starting with the beginning of the selected interval, and ending with the current ("Now") value. 413

Configuring and Using Power and Capacity Management Servers Lists servers in the workload selected in the workloads pane. Information for each server includes:
q

Server: DNS name and server profile information. Control mode: Power control mode, site (if there is more than one defined), and power controller preference. State: Online, Offline, Disconnected, Draining, Stopping, or Starting. In some cases, state displays vary for XenApp installations on virtual machines, depending on whether or not a Power and Capacity Management machine manager is configured and enabled. Using a machine manager results in more detailed state reporting and displays. For example, on a server without an enabled machine manager, a state display of 'Starting' indicates that Power and Capacity Management has instructed the server to power on. On a machine manager-enabled server, that state display appears as 'Starting: Powering on' or 'Starting: Waiting for connection.'

Utilization: Current percentage in graphic and text forms. Sessions. Current counts in graphic and text forms. Hovering over an entry displays the current session count for that server and the current load consolidation activity, if any. An icon to the left of the graph represents the current load consolidation activity (when load consolidation is enabled for the server's workload):
q

Green triangle = server is accepting new connections and is below optimal load Yellow triangle = server is accepting new connections but is above optimal load

Grey circle = server has been set as an undesirable target for new sessions The Sessions graphic fades for servers in PCM drain mode.
q q

Session Capacity. Hovering over an entry displays how the dynamic capacity estimate differs from the typical session capacity value configured in the server profile (the session capacity value indicates 'calculated').

Capacities Displays server profile information and the typical session capacity for each server profile (or Unset if the typical session capacity is not configured). To display the DNS names of servers that use a profile, select the profile and then click the entry in the Servers column. Schedule Displays the current Monday through Sunday schedule for a workload. (This tab is not displayed when All Workloads is selected in the workloads pane.) The entry for each day indicates time and setpoint values.

414

Configuring and Using Power and Capacity Management

To generate a workload or server report


Metrics collection is enabled and disabled in Setting Global Configuration Values. 1. From the management console, select the reporting object:
q

To generate a workload report, select a workload or All Workloads.

q To generate a server report, click the Servers tab and select a server. 2. In the Actions pane, click Generate Workload Report.

3. Select the report type, period of time the report covers, and the interval. 4. Click Generate Report. Important: The management console uses Microsoft Internet Explorer to display reports, overriding the user default browser setting. For optimal display, always use Microsoft Internet Explorer to view reports.

415

Configuring a Server Profile


Within a workload, servers are grouped by profiles, which contain information the agent discovers and information you configure. The agent discovers hardware information such as the CPU type and the amount of memory, and sends it to the concentrator. The concentrator creates a profile entry in the database for a new profile (or, if the profile values are the same as those in an existing profile, the existing profile is reused). If the hardware configuration changes (for example, more RAM is added to a server), Power and Capacity Management creates a new profile. The original profile is not altered, because other servers may still be using it. Also, when a hardware change occurs, server capacity can change. Information you configure includes capacity values and the power action timeout.

To configure a server profile


1. From the management console, click the Capacities tab. Select one or more profiles. 2. In the Actions pane, click Server Profile Properties. 3. In the Server Profile Properties dialog box:
q

Enter the typical session capacity value, which specifies the number of XenApp sessions (on average) that the server can host. A zero value is equivalent to not set. As new servers connect and report their profiles, they inherit any existing configured capacity value if they have the same profile as an existing configured server. Enter the power action timeout (seconds) value, which is used when a power off or power on control is issued. If the operation does not complete successfully before the timer expires, Power and Capacity Management assumes the operation failed. Enter the estimated session capacity limit in the range 0-10,000 (0 = not set). This allows the dynamic session capacity feature to estimate capacity higher than the typical session capacity value when it detects spare computing resources. This value must be greater than or equal to the typical session capacity value.

To delete a server profile, server, or workload


You can delete a server profile only if it has no associated servers. You can delete a server only if it (or the server it represents) is not online with the Power and Capacity Management agent running. You can delete a workload only if it has no servers associated with it. Deleting a workload also deletes all associated profiles and schedules.

416

Configuring a Server Profile Select the server profile (from the Capacities tab), server (from the Servers tab), or workload. In the Actions pane, click one of the following:
q

Delete server profile Delete server Delete workload

After you delete a server profile, server, or workload that is offline, if Power and Capacity Management discovers those objects, they will be re-created.

417

Configuring Server Properties


Server properties include the control mode and power controller preference.

Control Modes
The control mode affects whether the server is eligible for power management or participating in load consolidation. Control Mode Unmanaged Description The server is not controlled by the Power and Capacity Management system, and is ignored by the workload to which it belongs. It does not contribute to the capacity of the workload. Setting this mode is the easiest way to quickly remove a server from the scope of system control without affecting the rest of the workload The server contributes to the capacity of the workload and meeting its current setpoints; however, it is not controlled. The power management controller does not power this server off or on, and the load consolidation controller does not disable this server to force load onto other servers. Designate XenApp servers that provide essential services as managed (base load), as essential services such as the data collector or the data store should not be taken offline. If power management has a target of keeping a certain number of servers online, these servers contribute to meeting that target. Similarly, if load consolidation keeps two servers available, and there are two available base load servers, they can be used to meet the load consolidation need. Managed When planning:
q

Managed (base load)

The server is fully controlled by the Power and Capacity Management system.

Identify which XenApp servers host essential services and do not host XenApp sessions. Set the server control mode for these servers to unmanaged (or do not install a Power and Capacity Management agent on them). Identify which XenApp servers host essential services and host XenApp sessions. Set the server control mode for these servers to managed (base load).

Configure the server control mode for existing servers in server properties (see below), and for new servers in global configuration.

418

Configuring Server Properties

Power Controller Preference


When Power and Capacity Management determines a power on or power off operation is required, it considers a server's power controller preference (and site preference, for XenApp servers installed on virtual machines). For a power on operation, the selection algorithm chooses a server with a higher power controller preference before a server with a lower preference. For a power off operation, the algorithm chooses a server with a lower power controller preference before a server with a higher preference. For best practice, specify the preference of more power-efficient servers higher than older, less power-efficient servers. A typical strategy is to specify the most power-efficient servers as 1st choice. The power controller preference of a server in a Power and Capacity Management farm can also be managed by XenApp Connector for Configuration Manager. Changing the preference for those servers from the Power and Capacity Management console can have undesirable effects.

To configure server properties


1. From the management console, select a workload or All Workloads. 2. Click the Servers tab, then select one or more servers. 3. In the Actions pane, click Server Properties.
q

If you selected one server, set the desired control mode and power controller preference in the Server Properties dialog box.

If you selected more than one server, set the desired power controller preference in the Server Properties dialog box. Select the control mode from the Actions pane: Set "Managed," Set "Unmanaged," or Set "Managed (base load)." If the power controller preference of one or more selected servers is currently managed by XenApp Connector for Configuration Manager, the Server Properties dialog box indicates the names of the affected servers.
q

419

Setting Global Configuration Values


1. From the management console, click Configuration in the Actions pane. 2. In the XenApp PCM Configuration dialog box:
q

Select the control mode for new servers added to the Power and Capacity Management farm. This setting differs from the control mode for existing servers, which is set in server properties. For information about that setting and a description of all control modes, see Configuring Server Properties.

Select the optimal load, which specifies how close to capacity a server can get before additional load should be directed to other servers. The load consolidator uses this value. The optimal load is expressed as a percentage, with a default value of 70% (load consolidation will add sessions to a server until it reaches or exceeds 70% of full server capacity). The remaining 30% of capacity acts as a buffer to ensure existing sessions on the server have spare computing resources to work with. Tune the optimal load threshold to find the right balance between performance and utilization.

Enable or disable metrics data collection. Select the number of days to retain the collected metrics data. The default is 365 days (1 year).

420

Configuring Sites
When Power and Capacity Management determines a power on or power off operation is required, it considers a server's power controller preference, which is configured in server properties. If the XenApp server is installed on a virtual machine, the power controller preference for the site is also considered. To add a site, from the management console: 1. In the Actions pane, click Sites. 2. In the Server Sites dialog box, click Add. 3. Specify a site name and a power controller preference for servers that belong to this site. You can also modify or delete a site from the Server Sites dialog box.

421

Adding Virtual Machine Managers


Power and Capacity Management uses virtual machine management to automatically locate virtual machines it manages; therefore, you do not need to manually configure associations between the virtual machines and their managing hosts. Virtual machine management supports multiple concurrent resource pools. The concentrator automatically connects to the resource pool, and periodically queries the inventory of virtual machines. The management console displays the inventory poll results as a count of the number of virtual machines. The concentrator continually updates the results. If you move a virtual machine image from one resource pool to another, Power and Capacity Management discovers this during its inventory polling. Note: The list of discovered virtual machines does not necessarily match the servers being managed by Power and Capacity Management; each machine manager maintains a list of all virtual machines discovered. When the concentrator selects a server to power on, it queries all virtual machine managers for a virtual machine with that server's MAC address.
q

If a match is found, the machine manager issues the appropriate commands to the resource pool to start a virtual machine. If no virtual machine is found (because its machine manager has not been configured or connected, or because the server image is hosted on a physical machine), Power and Capacity Management broadcasts the Wake-on-LAN packet on the network. Then, the concentrator waits a prescribed interval (power control timeout) for the Power and Capacity Management agent on the appropriate XenApp server to establish connection to the concentrator.

Important: Assign unique MAC addresses to virtual machines, even across resource pools. This is typically done using the auto-generate MAC option when creating the virtual machine.

To add a virtual machine manager


From the management console: 1. In the Actions pane, click Machine Managers. 2. In the Machine Managers dialog box, click Add. 3. Specify the string or URL to the host, cluster, or resource pool master. 4. Select the virtual machine type (see Supported Platforms for version information).
q

Citrix XenServer.

422

Adding Virtual Machine Managers


q

Microsoft Hyper-V. Microsoft SCVMM 2008. The Microsoft SCVMM 2008 console must be installed on each server hosting a Power and Capacity Management concentrator (master and slaves); otherwise, you cannot add a virtual machine manager. VMware ESX & vCenter.

5. Specify the site where the resource pool is located. 6. If you select the Authenticate with user name and password checkbox, specify the credentials. Do not select this checkbox if you want to use the domain credentials of the Concentrator service to authenticate. 7. Leave the Enable this machine manager checkbox enabled. You can also modify or delete a virtual machine manager from the Machine Managers dialog box.

423

Managing the Concentrator


You can install a Power and Capacity Management concentrator on one or more servers. One concentrator is the master. All connections from agents on the XenApp servers go to the current master concentrator; there is no load balancing among multiple concentrators. Important: Multiple concentrators share a common database. Concentrators negotiate for mastership and monitor the health of the current master through the database. If the current master stops updating the database, another concentrator becomes the master. Failover usually occurs within 60 seconds. Each concentrator registers an Active Directory Service Connection Point (SCP) as part of the machine account where the concentrator is installed and records an entry in the database. When the agent on the XenApp server starts, it queries the SCP to discover all known concentrators. Each agent then tries to connect to each concentrator, looking for the master. The management console also performs the same discovery process and connection attempts. You can explicitly force a running concentrator to become the master concentrator. This may be necessary when a master concentrator has planned maintenance.

To explicitly designate a master concentrator


1. From the management console, click Cluster Management in the Actions pane. 2. In the Cluster Management dialog box, select a concentrator and click Set Master.

To change the port the agent uses to communicate with the concentrator
Edit the PCMConcentrator.exe.config file in the Install directory, then restart the PCM Concentrator service. (The default port is 11168.)

To manually publish the concentrator


If the account running the Concentrator service does not have sufficient access in Active Directory (AD) to automatically publish its service information, other Power and Capacity Management components will not be able locate Power and Capacity Management and the system will not operate correctly. In this case, the concentrator writes errors to the application log, and the console will not display the XenApp servers on which the agent has been installed. To avoid this issue, manually publish the concentrator within AD.

424

Managing the Concentrator 1. Log onto the computer hosting the concentrator, using an account with sufficient access in AD to publish the service information. 2. Ensure that the Concentrator service is running. 3. From a command prompt, navigate to the directory where the PCMConcentrator.exe file is located; by default this is %SystemDrive%\Program Files\Citrix\ XenApp Power and Capacity Management\Concentrator\ 4. Run the following command: PCMConcentrator /publish. 5. Restart the Concentrator service. This creates an AD object only; no AD schema changes are required. This object is created as a child object of the computer container hosting the concentrator, called CN=Citrix XenAppPCM SCP. Conversely, you can manually revoke the publishing information by running PCMConcentrator /revoke. This command deletes the aforementioned object in AD.

425

Creating Setpoints and Schedules

Setpoints
A setpoint defines a target capacity level (number of sessions) or a target number of online servers. You specify setpoints for each workload in a schedule. The power controller uses four setpoints. The load consolidator uses only the minimum available servers setpoint. A new workload has default setpoint values that place the workload in the most available configuration all managed servers are online. Thus, a newly discovered workload cannot be power controlled until you define appropriate setpoints for it (and enable power management). The setpoints are:
q

Online session reserve. Specifies the amount of online but unused capacity that must be maintained above the current load. As the load fluctuates throughout the day, the system maintains this buffer; this is known as a load following model. In practice, the Power and Capacity Management system powers on the smallest number of servers that can hold the target online capacity. Default: Infinite; all servers are kept online. The management console displays this value as an infinity symbol.

Minimum session capacity and maximum session capacity. These setpoints work as guards for the online session reserve. The online session reserve setpoint can raise and lower the online capacity, as long as it remains between the two guards.
q

The minimum session capacity setpoint causes servers to be powered up until the system has at least the amount of online capacity to meet or exceed the setpoint. After this setpoint is met or exceeded, the minimum session capacity has no effect; if the online session reserve setpoint drives online capacity above the minimum session capacity setpoint value, Power and Capacity Management ignores the minimum session capacity setpoint. Default: Zero, which is equivalent to not set.

The maximum session capacity setpoint functions similarly to minimum session capacity; however, it causes servers to be powered off until the online capacity is at or below the setpoint. Although the maximum session capacity setpoint is used less frequently, it can be helpful when preparing for system maintenance. After online capacity is below the setpoint value, this setpoint has no effect.

Default: Infinite, which is equivalent to not set; the management console displays this value as an infinity symbol. Minimum available servers. Works on a per-server basis (the other three setpoints are capacity based) to ensure a minimum level of service availability, in terms of servers. This can be helpful in handling redundancy; multiple servers ensure acceptance of new sessions if a server crashes. It can also help logon rates. Logging on new sessions can

426

Creating Setpoints and Schedules quickly increase server load to the point where existing sessions are degraded or new logons take significantly longer to complete. In such cases, using this setpoint can ensure you have a sufficient number of servers online to load balance the logon load. The power controller attempts to keep this many servers online, while the load consolidator attempts to keep this number of servers available to accept new sessions. You usually increase this setpoint just before and throughout the times of heaviest usage to ensure sufficient available servers for the high rate of incoming sessions. If you do not increase this setpoint for the heaviest usage, the capacity setpoints may ensure there are enough servers online to host the expected load, but the load consolidator may keep too many servers disabled. Therefore, the servers that are enabled may become overloaded while new sessions are logging on. Default: Zero, which is equivalent to not set. The system tries to meet the online session reserve setpoint first. It then bounds the output using the minimum and maximum session capacity setpoints. Finally, the system checks and ensures that the resulting number of online servers meets the minimum available servers setpoint. Therefore, setpoints have the following order of importance, from highest to lowest:
q

Minimum available servers Maximum session capacity Minimum session capacity Online session reserve

Schedules
A schedule usually specifies the online session reserve and the minimum available servers setpoints. For example, you have a deployment of 10 servers. Each server has a configured session capacity of 100, and peak session use occurs at 9:30 a.m.
q

To effectively handle demand, schedule the system to ramp up at 9:00 a.m. by setting the minimum available servers to 5, and the online session reserve to 300. After peak use (9:30 a.m.), schedule the setpoints to lower values at 10:30 a.m., with minimum available servers set to 2 and the online session reserve set to 100. After normal working hours, reduce these setpoint values further at 7:00 p.m., with minimum available servers set to 1 and the online session reserve set to 50.

After you initially set the online session reserve and minimum available servers setpoint values with scheduled changes throughout the day, observe server and session activity, and then fine-tune the schedule and setpoint values to optimize server capacity and use.

427

Creating Setpoints and Schedules

To create a schedule
From the management console, select a workload and click the Schedule tab.
q

To create a schedule, select the Allow Edit checkbox. Edit the schedule for one or more days of the week. To copy the schedule from the previous day, click Copy day's schedule in the day of the week area. To copy the entire workload schedule to another workload, ensure the workload being copied has focus, then click Copy Schedule To in the Actions pane. To delete a schedule, click Delete Schedule in the Actions pane. To delete an individual schedule item, select the leftmost cell in the item, then press the Delete key.

Manual Overrides
After you enable a workload for power management, you can manually override the schedule with different setpoint values. For example, a manual override can be useful when there is an unexpected surge in demand on the XenApp workload that is likely to continue for a few hours. Instead of changing the schedule, you can initiate an override. When the surge has subsided and the normal conditions have returned, you can cancel the override, and the scheduled setpoint values are reapplied. Using a manual override can also be helpful when the schedule requires attention or maintenance. Manual override differs from disabling power management. During a manual override, power management is still active, but the setpoints are controlled by the administrator instead of the schedule. Disabling power management for a workload is equivalent to turning off the Power and Capacity Management feature for that workload.

To start or stop a manual override


1. From the management console, select the workload. 2. In the Actions pane, click Power Controller Manual Override.
q

To start a manual override, click Start Override. To stop (cancel) a manual override, click Stop Override.

428

Enabling Load Consolidation and Power Management


You can enable or disable load consolidation and power management on a global and per-workload basis. When you enable power management and load consolidation globally (by selecting All Workloads), you can also enable or disable power management and load consolidation on a per-workload basis. To enable power management or load consolidation for one workload, power management or load consolidation must be enabled for All Workloads. 1. From the management console, select a workload or All Workloads. 2. In the Actions pane, the Action menu, or the right-click menu:
q

To enable power management, click Enable power management.

To enable load consolidation, click Enable load consolidation. To disable power management or load consolidation, click Disable power management or Disable load consolidation.
q

429

Understanding XenApp Printing


Managing printers in a XenApp environment is a multistage process. The cycle for managing printers on a farm requires that you: 1. Design your printing configuration. This includes analyzing your business needs, your existing printing infrastructure, how your users and applications interact with printing today, and what a realistic printing management model would look like for your organization (that is, assessing that the administrative overhead of printing pathway you choose is realistic in your environment). 2. Configure your printing environment, including creating the policies necessary to deploy your printing design. 3. Test a pilot printing deployment before rolling it out to users. 4. Maintain your Citrix printing environment, including updating policies when new employees or servers are added and maintaining drivers on your farm servers. 5. Troubleshoot issues that may arise in your printing environment. Before you begin planning your deployment, make sure that you understand these major concepts for printing in XenApp:
q

The concept of printer provisioning in a session and the two major types of provisioning (auto-created and self-provisioned). To understand these concepts, you need to understand, among other things, the difference between a printer, a printing device, and a printer driver. How print jobs can be routed in XenApp. The policies that you can create to manage drivers.

XenApp printing concepts build on Windows printing concepts. To configure and successfully manage printing in a Citrix environment, you must understand how Windows network and client printing works and how this translates into printing behavior in a Citrix environment.

430

Introduction to Windows Printing Concepts


This section provides a limited overview of basic printing concepts in a standard (non-Remote Desktop Services) Windows environment. However, Citrix recommends reviewing the Windows documentation about network printing, print servers, and Remote Desktop Services printing before learning about Citrix printing concepts. In a Windows environment, you can either print from your computer to a locally attached desktop printer (for example, a printer on LPT1 or COM1) or you can print to a network printer that is managed by a print server. This diagram shows how print jobs are spooled from the client device to a print server and then sent to the printing device in a Windows network.

Here are a few basic definitions: Printing Device In the context of this topic, the term printing device refers to the physical printer (that is, the hardware device to which you send print jobs). Printers The term printer refers to the software representation of a printing device. Computers must store information about printers so they can find and interact with printing devices. 431

Introduction to Windows Printing Concepts When you see printer icons in the Printers panel in the Control Panel, you are seeing the software representation of the printers. (You are not seeing the printer drivers.) For clarity, the term printer object is sometimes used to denote the software representation of a printing device. Printer driver The printer driver is the software program that lets the computer communicate with this hardware device. This program converts the information to be printed to a language that the printing device can process. It also understands the device and job settings of the printing device and presents a user interface for users to configure these. In Windows systems, printer drivers are distinct from the software representation of printers. Print job When a user prints a document, the data sent to the printer is known as a print job. Jobs are queued to the printer in a specific sequence, which the print spooler controls. When this sequence appears, it is known as the print queue. Print spooler The spooler is the Windows service that manages printer objects, coordinates drivers, lets you create new printers, determines where print jobs are processed, and manages the scheduling of print jobs. The print spooler also determines if the printer prints each page as it receives it or if the printer waits until it receives all pages to print the job. Typically, when a print job is spooled to a printer, the spooler loads documents into a buffer. The printing device then retrieves the print jobs from the buffer when it is ready to print the job. By storing the job, the computer can perform other operations while the printing occurs in the background. Print queue A sequential, prioritized list of the print jobs waiting to be printed. The spooler maintains this list for each printer object in the computer. Print server A computer that manages the communications between client devices and printers. In this context, the term print server refers to dedicated computers that are running a Windows server operating system and hosting x number of shared printers. Print servers provide client workstations with drivers they need to print and store files, or print jobs, in a print queue until the printer can print them. A print server is a remote print spooler. Network printer A shared printer object accessed through a network print server.

432

Local and Remote Print Job Spooling


Print job spooling is important because where print jobs are spooled to is where print jobs are processed. Processing location affects network traffic, resource utilization, and has additional implications in a XenApp context. Print jobs can be spooled either locally or remotely. Typically, print jobs sent to locally attached printers are spooled locally, and jobs sent to network printers are spooled remotely.

Locally Spooled Print Jobs


When print jobs are spooled locally, the local Windows computer processes the job. The application creates a spooled print job; the local print spooler, aided by the printer driver, processes the print job, and sends the rendered output to the printing device. In a Windows environment, when you print to a printer connected to your local computer (when print jobs are spooled locally), the printer drivers and settings are stored on the computer itself. A typical printing process for locally spooled print jobs is:

1. The application tells the local spooler to create a print job and an associated spool file on the local computer. 2. On the local computer, Windows writes the applications drawing commands to the local spool file. This process of writing commands occurs repeatedly until the job is completely spooled. 3. The local spooler processes the job with the printer driver in a process known as rendering. 4. The local spooler delivers the rendered data to the printing device (for example, a locally attached printer).

Remotely Spooled Print Jobs


When print jobs are spooled remotely, the Windows print server processes the print job. A typical printing process for remotely spooled print jobs is

1. The application tells the remote spooler to create a print job on the print server and an associated spool file. 2. On the local computer, Windows writes the applications drawing commands to the remote spool file. This process of writing commands across the network occurs

433

Local and Remote Print Job Spooling repeatedly until the job is completely spooled. 3. The remote spooler processes the job with the printer driver in a process known as rendering. 4. The print server delivers the rendered data to the printing device (typically a network printer).

Key Differences Between Remote and Local Spooling


Unlike remote spooling, local spooling does not use any network resources. Remote spooling requires that the local computer and the remote printer exchange many messages across the network. Even in a non-Citrix environment, if a WAN has substantial latency, users will have a poor user experience if the print jobs are spooled remotely across the WAN. However, in some situations, for example when the resources on the local computer are needed for other tasks, remote spooling is preferable. In remote spooling, the print job is processed on the print server, which off-loads processing from the local computer.

434

XenApp Printing Concepts


In a XenApp environment, all printing is initiated (by the user) on the server. However, print jobs are not always sent directly from the server to the printing device. Instead, the print jobs can be redirected through the client device. Because there is no persistent workspace for users in XenApp (when a session ends, the users workspace is deleted), all settings need to be rebuilt at the beginning of each session. As a result, each time a user starts a new session, XenApp must reprovision (recreate or restore) the printers available in a session. When a user clicks Print, XenApp:
q

Determines what printers (that is, printer objects) to provide to the user. This is known as printer provisioning. Restores the users printing preferences. Determines which printer is the default for the session.

However, you can customize how XenApp performs these tasks by configuring options for printer provisioning, print job routing, printer property retention, and driver management. Settings for these options can affect the performance of printing in your environment and the user experience. For example, you can reduce the amount of latency when users print by choosing a method of provisioning that is appropriate for your network configuration. As a result, understanding key printing concepts is critical when planning your printing configuration:
q

The difference between the client and network printing pathway and how this is not the same as local printers and network printers The term printer provisioning, the types of printer provisioning (static and dynamic), printer autocreation, and user self-provisioning Print job routing and when changing it can improve utilization The basics of printer driver management

435

Overview of Client and Network Printing Pathways


An important concept in XenApp is the printing pathway. The term printing pathway encompasses both the path by which print jobs are routed and the location where print jobs are spooled. Both aspects of this concept are important. Routing affects network traffic. Spooling affects utilization of local resources on the device that processes the job. In XenApp, print jobs can take two different printing pathways:
q

Network printing pathway Client printing pathway

Network Printing Pathway


The term network printing pathway refers to print jobs that are routed from the farm server hosting the users session to a print server and spooled remotely.

This diagram shows a XenApp network printing example: Printing begins on the farm server hosting the users session (where the application is published and executing). XenApp routes the print job over a network connection to the network print server. The network print server then routes the print job to an associated network printing device.

When a print job is spooled remotely in a Windows environment, it uses this process:

1. The application tells the remote spooler to create a print job and an associated spool file.

436

Overview of Client and Network Printing Pathways 2. The Windows Print Provider sends the spool file to the print server. 3. The print server processes the spool file. 4. The print server then sends the print job to the appropriate network printer.

Server Local Printers


The term server local printers refers to a configuration that uses the network printing pathway where printing devices are attached locally to a XenApp farm server. Server local printers are shared printing devices that are physically attached to a farm server. Note: To use a locally attached printer as a server local printer in a XenApp farm, the printer must be shared; otherwise XenApp does not recognize it. Server local printers are often a good choice for printing in small farm environments. However, server local printers are not used widely in enterprise environments because they require installing the printer drivers on each server in the farm and require additional resources on the XenApp server. Server local printers are managed and configured in the same ways as network printers.

This diagram shows a XenApp server local printing example: Printing begins on the farm server hosting the users session and is routed to a printing device attached locally to the server.

437

Overview of Client and Network Printing Pathways

Client Printing Pathway


The term client printing pathway refers to print jobs that are routed over the ICA protocol through the client device to the printer (either a printer connected directly to the client device or connected through a print server) and spooled on the Citrix online plug-in. When using the client printing pathway, a virtual printer is constructed in the session that redirects to the printer object on the client device. The client device, in turn, sends the print job to the printing device. Importantly, because all processing occurs on the XenApp server, when users print a document from a published application, they are actually starting that print job on the XenApp server. These jobs are spooled locally on the XenApp server. There are two different configurations of the client printing pathway: one for printers attached directly to the client device and another for network printers.

Locally Attached Client Printers


The simplest configuration is the one where the printer is attached directly to the client device. In this configuration, the application server sends the print job back to the client/client device. The client device then relays it to a locally attached printer.

This diagram shows a simplified XenApp client printing example: Printing begins on the server where the application is published. XenApp sends the print job over the connection to the client device. The client device then routes the print job to the printer connected locally to the client device.

When a print job is spooled to a client along the client printing pathway, it uses this process:

1. The published application tells the local spooler on the server hosting the application (that is, the host server) to create a print job and an associated spool file on the host server.

438

Overview of Client and Network Printing Pathways 2. On the host server, Windows writes the applications drawing commands to the local spool file. (This process of writing commands occurs repeatedly until the job is completely spooled.) 3. The local spooler processes the job with the printer driver in a process known as rendering. 4. The rendered data is delivered to the client device through the ICA protocol. 5. The client device relays the print data to the client-side printing device (a locally attached printer in this example).

Client Printers on the Network


While client printers are often printers physically attached to client devices, they can also be printers on the network. In this case, print jobs are routed through the client device to the print server. The process is the same as for printing to a local printing device through the client. However, instead of sending the job to the client device, the job is sent to the network print server.

This diagram shows client printing to a network printer: Printing begins on the server where the application is published. XenApp routes the print job over the connection to the client device. The client device then routes the print job over the network to the print server, which in turn routes the print job to the network printer.

439

Overview of Client and Network Printing Pathways

When a print job is spooled to a network printer along the client printing pathway, it uses this process:

1. The application server sends the print job to the client for processing. 2. The client processes the spooled job and sends it to the Windows print server for processing. 3. The Windows print server then sends the print job to the appropriate network printer. Configuring XenApp to use the client printing pathway for network printing devices is useful when a print server is in a domain different from the farm servers (and the client devices have access to the print servers domain). Using the client printing pathway lets application servers send print jobs over the ICA connection to access the printer through the client device. Configuring the client printing pathway for network printing is useful for low bandwidth connections, such as WANs, that can benefit from the traffic compression that results from sending jobs over the ICA connection. The client printing pathway also lets you limit traffic or restrict bandwidth allocated for print jobs.

440

Provisioning Printers for Sessions


For a computer to process a print command, it needs both the required printer object and a printer driver. Because sessions are hosted in a virtual workspace instead of locally on a hard drive, printers and their drivers are not stored on the local computer. Instead, they are restored at logon or reconnect. The process by which XenApp makes printers available in a session is known as provisioning. You can control printer provisioning and the way you configure it affects what printers users see in sessions and the speed of the printers. There are two types of printer provisioning:
q

Static. Server local printers are provisioned only once, when you connect them to the farm server. After that, they are always created in sessions with the same properties and do not vary according to policies. Dynamic. The printers that are available in a session are determined as the session is built. As a result, they can change according to changes to policies, changes in user location, and changes to the network (provided they are reflected in policies). When printers are provisioned dynamically, the printers that appear in a session are not predetermined and stored. Rather, the printers are assembled, based on policies, as the session is built.

Because provisioning static printers is relatively simple, this topic focuses on provisioning printers dynamically. The two most common methods of dynamic printer provisioning are:
q

User provisioning Autocreation

To control what printers users have in their sessions and ensure printers are available when users start their sessions, provision their printers through autocreation. If you do not want to specify (and administer) user printers, you can let users self-provision their printers. If you choose, you can prevent printer autocreation and let users provision printers visible from their client device.

User Provisioning
You can allow users to add printers to their sessions on their own. Users can map client printers that are not autocreated by policy manually in a user session through the Windows Add Printer wizard on the server (in their sessions). If users have thin clients or cannot access their client devices, they can self-provision by running the ICA Client Printer Configuration tool (PrintCfg.exe). For users to self-provision with the utility, you must publish PrintCfg.exe on your farm.

441

Provisioning Printers for Sessions

Autocreation
The term autocreation refers to printers XenApp creates automatically, at the beginning of each session, based on what printers are configured on the client device and any policies that apply to the session. By default, XenApp makes printers available in sessions by creating all printers configured on the client device automatically, including locally attached and network printers. After the user ends the session, the printers for that session are deleted. The next time a session starts, XenApp evaluates any policies for printer creation and enumerates the appropriate printers from the client device. You can change the default autocreation policy settings to limit the number or type of printers that are auto-created. XenApp can auto-create:
q

Client redirected printers, including auto-created client printers and a Universal Printer Network printers

There is maintenance associated with provisioning by printers by using client and network printer autocreation. When you add new printers, you need to update the autocreation list. Also, the drivers for these printers must be added to all servers on the farm; however, you can specify for XenApp to do this automatically. This topic comprises:
q

Auto-Creating Client Printers Provisioning a Citrix Universal Printing Solution Auto-Creating Network Printers Letting Users Provision Their Own Printers

All of these provisioning methods use the client printing pathway except for Auto-Creating Network Printers, which uses the network printing pathway.

442

Auto-Creating Client Printers


The autocreation feature creates a list of printers that a user can use after logging on. When the user logs in, their print drivers will be installed and all printers returned in this list will be available for use. XenApp can auto-create redirected client printers in two different ways:
q

By creating a one-to-one match with printers on the client device By creating one generic printer, the Citrix Universal Printer, that represents all (or any) printers on the client device

In many environments, especially large ones, Citrix recommends that you auto-create only one default printer. Auto-creating a smaller number of printers creates less overhead on the server and is better for CPU utilization. However, in environments where users with limited computer skills need to print to a wide variety of local printing devices, you may want to leave the default autocreation setting so that all printers are created on logon. If you do not want large numbers of printers created at the beginning of each session, consider specifying for XenApp to use the Citrix Universal Printer.

Auto-Creating Printers from the Client Device


At the start of a session, XenApp auto-creates all printers on the client device by default. You can control what, if any, types of printers are provisioned to users and prevent autocreation entirely. The Citrix policy setting Auto-create client printers lets you control autocreation and specify that:
q

All printers visible to the client device, including network and locally attached printers, are created automatically at the start of each session All non-network printers physically attached to the client device are created automatically Only the default printer for the client device is created automatically No printers visible to the client device are created automatically

When configuring policies for printer autocreation, ensure:


q

User accounts are not shared Users are not in the local power user or administrators group on the client devices You add Microsoft native or fully tested drivers only

443

Auto-Creating Client Printers


q

Users have write access on the server to %systemroot%\system32\spool

These points help ensure that printers auto-create successfully.

Provisioning a Citrix Universal Printing Solution


Citrix Universal printers and drivers are printing solutions that let users print regardless of whether or not they have the correct printers and drivers installed. Universal printing solutions are printers and drivers not tied to any specific device. Consequently, they simplify administration by reducing the number of drivers required on farm servers or the number of printers created at the beginning of sessions. Because users need to access fewer printers and drivers, the speed of starting a session is increased and the complexity of printer administration is decreased. XenApp includes two types of universal printing solutions:
q

Citrix Universal Printer. A generic printer object, replacing the printers that appear in the users Printers control panel during their session. This printer can be used with almost any printing device. Citrix Universal Printer Drivers. Windows Native Printer drivers are generic drivers that work with almost any printer. These drivers also work with non-Windows clients. Citrix-created Universal printer drivers consist of the Citrix XPS Universal Printer driver and the EMF-based Citrix Universal Printer driver.

These printing solutions can be used in one of the following ways:


q

Auto-created device printer with Citrix Universal printer driver. A device-specific printer gets auto-created but uses a Citrix Universal printer driver. For example, configured policy rules specify that the printer LaserJet5L still gets auto-created at the beginning of each session; however, the session uses the Citrix Universal printer driver to communicate with the driver on the client device and the print job is processed on the client device. Auto-created Citrix Universal Printer with a Citrix Universal printer driver. A Citrix Universal Printer gets auto-created and it uses a Citrix Universal printer driver. That is, at the beginning of each session, the only printer that is auto-created is the Citrix Universal Printer. Like the first example, the session uses the Citrix Universal printer driver to communicate with the driver on the client device and the print job is processed on the client device. Auto-created device printers, auto-created Citrix Universal Printer with a Citrix Universal printer driver At the beginning of the session, the Citrix Universal Printer and device-specific printers are auto-created. Both printers use the Citrix Universal printer driver.

Whether you use a Citrix Universal printing solution depends on various factors:
q

The Citrix Universal Printer and printer driver might not work for all client devices or plug-ins in your environment. The Citrix Universal Printer and printer driver solution requires the Citrix Online Plug-in or the Citrix Offline Plug-in.

444

Auto-Creating Client Printers The Citrix Universal Printer does not work if plug-ins are not connecting through the ICA channel, such as when you are using the Citrix Offline Plug-in and streaming applications to the client. If you want to use a universal printing solution for non-Windows plug-ins, use one of the other universal printer drivers that are based on postscript/PCL and installed automatically with XenApp.
q

The Citrix Universal printer driver might also create smaller print jobs than older or less advanced printer drivers. However, sometimes it might be better to use a device-specific driver because the driver might be able to optimize print jobs for its associated printer.

Note: If you want the Citrix Universal Printer to appear in sessions, make sure that the Citrix policy setting Client printer names is not set to Legacy printer names in any policies affecting those sessions. Universal printer drivers are installed by default on each farm server; the printer is not enabled, however. To get the best results when configuring your farm, use both the Citrix Universal Printer and a Citrix Universal printer driver. Note: Citrix Universal Printing is available for Citrix Presentation Server Client, Version 9.x or Version 10.x, Citrix XenApp Plugin for Hosted Apps 11.0, the Citrix Online Plug-in, the Citrix XenApp Plug-in for Streamed Apps, and the Citrix Offline Plug-in. This feature is available in Presentation Server 4.0 to XenApp 6.

Citrix Universal Printer


The Citrix Universal Printer is a generic printer created at the beginning of sessions that can be used with almost any printing device. This printer can print to and communicate, through the client, with any client-side printer. You may also want to use the Citrix Universal Printer because the printer name does not change when users reconnect. Changing printer names can cause problems for some applications. The Citrix Universal Printer is created on a per-session basis. When used with a Citrix Universal Printer driver, it can greatly reduce the resource usage at the start of a session from printer autocreation. When you use the Universal Printer, you can specify that only the Universal Printer be auto-created for each printer on the client device. When the Citrix Universal Printer is enabled, an extra printer is created in the session with the name Citrix UNIVERSAL Printer in session number of session. To use only the Citrix Universal Printer in sessions and not auto-create any printers on the client device, enable the Universal Printer through the registry and configure the Citrix policy setting Auto-create client printers to Do not auto-create client printers. The user experience varies depending on the type of Citrix Universal Printer. Because the Citrix Universal Printer is not tied to a specific printing device, both the EMF-based and XPS-based Citrix Universal Printers provide ways to preview and select settings:

445

Auto-Creating Client Printers


q

EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display a print preview before printing. If the Preview on client option is selected in the printers printing preferences, the user sees a preview of the print job and has the option of choosing a target printer and controlling print device setting. If the Preview on client option is not selected, no preview is displayed and print job is routed directly to the default printer on the user device. XPS-based Citrix Universal Printer. Like Microsoft XPS Document Writer, the Citrix XPS Universal Printer sends documents to Internet Explorer if a user selects Print Preview or modifies the print settings, displaying them in Microsofts XPS electronic paper format.

Note: The Print Previewer cannot be controlled by the administrator unless users have the Citrix Presentation Server Client, Version 10.100 or later, the Citrix XenApp Plug-in for Hosted Apps, Version 11x, or the Citrix Online Plug-in.

446

Auto-Creating Network Printers


By default, any network printing devices on the client device are created automatically at the beginning of sessions. However, if possible, XenApp always tries to route jobs directly from XenApp to the print server and not through the client connection. To specify that specific printers are created in sessions rather than auto-create all the network printing devices available from the client device, configure the Citrix policy setting Session printers. Network printers created with the Session printers setting can vary according to conditions where the session was initiated, such as location (by filtering on objects such as subnets). Note: For printers in domains that do not have a trust relationship with the XenApp farm, disable the Citrix policy setting Direct connections to print servers. When this setting is disabled, print jobs are routed through the client using the client printing pathway.

447

Letting Users Provision Their Own Printers


If you do not want specific printers to be auto-created at the beginning of each session, allow users to add their own printers. By default, provided they can access the network from their client devices, all users can add printing devices to be used in a session. The only time users cannot add printers to their sessions is when they cannot access their client device because they are using a thin client and there are no applications published that let them browse and add printers. Printers that users create on their own during a session are known as retained printers because they are created again (or remembered) at the start of the next session. When XenApp recreates a retained printer at the start of a session, it considers all Citrix policy settings except Auto-create client printers. Retained printers appear in sessions on that device until the client printer within the session is deleted manually, the remembered printer connection is removed from the clients properties store, or the client-side printer is inaccessible. Users might need to use the PrintCfg.exe tool to add printers if they cannot browse to the printer from within the session or cannot access their client desktop. If they use this tool, the printers are routed along the client printing pathway.

448

Device or Session-Based Print Settings


By default, all changes users make to the printer device settings and preferences, whether in a session or working on their local computer, are saved and used locally and in a session. This means that printer settings and preferences are always the same on the client device and in a session. Citrix policy settings let you change the way XenApp software saves and applies printer device settings and preferences. You can configure sessions to obtain print settings, specifically user printing preferences, from either the printer object or the printing device. XenApp can write printer settings to the printer object at the end of a session or to a client printing device, provided the users network account has sufficient permissions. By default, XenApp plug-ins use the settings stored in the printer object in the session, before looking in other locations for settings and preferences. The main reason you want sessions to obtain their print settings from the printing device is if Windows users make changes to local printers outside of sessions (that is, on their local computer offline). Non-Windows plug-ins synchronize changes made out of sessions automatically.

449

Device-Based Print Settings


Caution: Using Registry Editor incorrectly can cause serious problems that may require you to install 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. If you have Windows users with locally attached printers who work on applications locally and on the server, you might want to retain changes to the printer settings the users make locally outside of a session. To do so, create and set the Win32FavorRetainedPrinterSettings registry key to False, as described in To synchronize properties from the printer. When the registry key is modified, the plug-in gives priority to settings from the printer, rather than retained settings. Settings in the session stay synchronized with settings on the printing device. If a change was made to the printer out of a session, the change is picked up. If a change is made to the printer inside the session, the plug-in attempts to write the change back to the printer on the client device when logging off. You must have the same driver on the client device and server. If you do not, only a subset of settings is exchanged between the real printer and the virtual printer in the session. Some device independent settings are inherited and others are not.

450

Controlling Printing Settings and User Preferences


To understand how printing preferences are retained and applied, you must understand:
q

The locations printing settings can be stored in a XenApp environment The priority XenApp software uses to apply printing preferences from previous sessions to the printers in a newly created session Where XenApp software stores printing preferences by default and if there are factors in your environment that will prevent the software from successfully storing them in this location (that is, when you need to change this setting)

General Locations of Printing Preferences


In Windows printing environments, changes made to printing preferences can be stored on the local computer or in a document. In a XenApp environment, when users modify printing settings, the settings are stored in these locations:

On the client device itself. The settings are set on the client device by right-clicking the printer in the Control Panel and selecting Printing Preferences. For example, if Landscape is selected as page orientation, landscape is saved as the default page orientation preference for that printer. This type of preference is known as Device Settings. Inside of a document. In word-processing and desktop-publishing programs, settings, such as page orientation, are often stored inside documents. These settings are often referred to as Document Settings. For example, when you queue a document to print, Microsoft Word typically stores the printing preferences you specified, such as page orientation and the printer name, inside the document. These settings appear by default the next time you print that document. From changes a user made during a session. XenApp keeps only changes to the printing settings of an auto-created printer if the change was made in the the Control Panel in the session; that is, on the server. On the server. These are the default settings associated with a particular printer driver on the server.

If you want to control user printing preferences, it is important to understand that the settings preserved in any Windows-based environment vary according to where the user made the changes. This also means that the printing settings that appear in one place, such as in a spreadsheet program, can be different than those in others, such as documents. As result, printing settings applied to a specific printer can change throughout a session.

451

Controlling Printing Settings and User Preferences

Hierarchy of Users Printing Preferences


Because printing preferences can be stored in multiple places, XenApp processes them according to a specific priority. Also, it is important to note that Device Settings are treated distinctly from, and usually take precedence over, Document Settings. XenApp searches for settings in this order:

1. XenApp checks for retained printer settings. If XenApp finds retained settings, it applies these settings when the user prints. 2. If there are no retained printer settings, XenApp searches for any changes to the printer settings for the default printer for the client device. If XenApp finds any changes to printing preferences on the client device, it applies these settings when the user prints. 3. If there are no retained or client printer settings, XenApp applies the default printer settings stored on the server when the user prints. At this point, the printer settings are merged. Generally, XenApp merges any retained settings and the settings inherited from the client device with the settings for the default printer driver on the server. By default, XenApp always applies any printing settings a user modified during a session; that is, the retained settings, before considering any other settings.

Saving Users Printing Preferences


By default, XenApp attempts to store printing properties, a combination of the users printing preferences and printing device-specific settings, on the client device. If the client does not support this operation, XenApp stores printing properties in its user profile for that user. Sessions from non-Windows XenApp plug-ins or even older Windows XenApp plug-ins use the user profiles on the server for properties retention. You can use the Printer Properties Retention policy rule to force properties to be saved on either the client or on the server. If one of the following apply, you might need to reconfigure how XenApp stores user printing preferences:

Client version. Not all XenApp plug-ins allow users to store printer properties on a client device. Users must be running Citrix Presentation Server Client 9.x and higher to store user-modified printer properties on the client device. Type of Windows user profile. That is, if you are using local, roaming, or mandatory profiles on your Windows network. If you are using a mandatory profile and you want to retain the users printer properties, you must store the properties on the client device.

452

Controlling Printing Settings and User Preferences


q

Farm Size. If you have a large farm and you are load balancing applications, users will experience inconsistent printing behavior and properties if you use local profiles. The only way you can get consistent printing behavior is to save the printer properties on the client device. Type of workers. If you have mobile or remote workers and you are using roaming profiles, you must save the printer properties to the users profile and not the client device.

If none of these factors apply to you, Citrix recommends you not change where the printer properties are stored. Leaving the default setting, which saves the printer properties on the client device, is the easiest way to ensure consistent printing properties. You can specify whether you want these settings stored on the client device or with the users profile. You can also change this default behavior so settings are not stored. However, before you make these decisions, you must understand how XenApp determines what print settings it applies and also what the difference is between storing print settings on the client device or with a profile.

453

Setting Default Printers


The printer that XenApp selects for a sessions default printer can be based on:
q

A network printer you specify as the default The default printer on the client device

If you want to base the default session printer on either of these, use the Citrix policy setting Default printer. See To specify a default printer for a session for details. However, if you specified that XenApp auto-create the default client printer, then, if no other printers are provisioned in sessions, you might not need to specify a default session printer.

454

Printing and Mobile Workers


In situations where users move among different workstations or sites, you can make sure that the closest printers are presented to them wherever they try to print. Examples of such users include hospital workers who move among workstations in different wings of a hospital, reconnecting to the same session using a smart card, or employees who travel to remote business units. If you have mobile workers and need this type of printing functionality, use one of these features:
q

SmoothRoaming Proximity Printing

SmoothRoaming
Also known as Workspace control, this feature lets a user disconnect from one session, move to another device, and reconnect to continue that same session. The printers assigned on the first client device are replaced on reconnection with the printers designated on the second client device. As a result, users are always presented with applicable printer options from wherever they connect.

Proximity Printing
This feature lets you control the assignment of network printers so that the most appropriate printer is presented, based on the location of the client device. The Proximity Printing solution is enabled through the Citrix policy setting Default printer. Proximity Printing can make administration easier even if you do not have mobile workers. For example, if a user moves from one department or floor to another, you do not need to assign additional printers to that user if Proximity Printing is implemented. When the workstation is recognized within the new locations IP address range, it has access to all network printers within that range. However, if you configure Proximity Printing, you must maintain the Session printer policy. For example, as network printers are added or removed, you must update this policy to reflect the current set of network printers. Likewise, if you modify the DHCP IP address ranges for floors or departments, you must update this policy. Proximity Printing requires that you can filter the policy on some type of geographic indicator, such as:
q

The name of the workstation, if the name relates to the workstations location

455

Printing and Mobile Workers


q

Your networks IP addresses, if they correlate with user locations

456

Optimizing Printing Performance by Routing


In a XenApp environment, you can control how print jobs destined for network printers are routed. Jobs can take two paths to a network printing device: along the client or network printing pathway. By default, XenApp routes print jobs along the client printing pathway as follows:

Auto-created client printers. XenApp routes jobs to locally attached printers from the server, through the client, and then to the print device. The ICA protocol compresses the print job traffic. When a printing device is attached locally to the client device, the jobs must be routed through the plug-in. Auto-created network printers. By default, all print jobs destined for network printers route from the server, across the network, and directly to the print server. However, if the application server and the print server are on different domains, XenApp automatically routes the print job through the plug-in.

When network printers are visible from the server, you can use policies to control how print jobs are routed to network printers. You can configure that jobs be routed to network printers:
q

Through the plug-in. This is accomplished by auto-creating the network printer but specifying its jobs to route through the plug-in. Over the network. This is accomplished either by leaving the default settings so that the network printer is auto-created (or configuring a policy to do this) or by provisioning the network printer through the Session printers policy rule.

Routing jobs along the network printing pathway is ideal for fast local networks and when you want users to have the same user experience that they have on their local client device (that is, when you want the printer names to appear the same in every session). However, print jobs relayed using the network printing pathway are not suited to WANs. The spooling of print jobs using the network printing pathway method uses more bandwidth than using the client pathway; many packets are exchanged between the host server and the print server. Consequently, users might experience latency while the print jobs are spooling over the WAN. Also, the print job traffic from the server to the print server is not compressed and is treated as regular network traffic. When printing jobs across a network with limited bandwidth, Citrix recommends routing jobs through the client device so that the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting Direct connections to print servers.

457

Managing Printer Drivers


During printer auto-creation, if XenApp detects a new local printer connected to a client device, it checks the server hosting the published application (from which the user is trying to print) for the required printer driver. By default, XenApp automatically installs a native driver if one is not found on the server hosting the published application. Because users in a XenApp environment do not have a persistent workspace, drivers cannot be stored on the client. To print to a local device, XenApp must find the correct driver on: (a) its server or in the servers Windows operating system, and (b) the client device. The diagram that follows shows how the printer driver is used in two places for client printing. This diagram shows client printing to a local printer: The printer driver on the server routes the job over the ICA channel to the client device. The client device then routes the print job through the same printer driver, which is accessible on the client device. The printer driver on the client device relays the print job to the print spooler on the client device, which in turn routes the print job to the local printer.

The printer driver on the server and the driver used by the client device must match exactly. If not, printing fails. As a result, XenApp provides features to manage drivers, install them automatically, and replicate them across your farm. The following problems can arise from not managing client printer drivers correctly:
q

Any missing drivers can prevent users from printing successfully. If a third-party printer driver has multiple or inconsistent names across your farm, a session might not be able

458

Managing Printer Drivers to find it and a users job may fail to print.
q

Printing to a client printer with a defective driver can cause a fatal system error on a server. XenApp does not download drivers, including printer drivers, from the print server. For XenApp servers to print across the network printing pathway, the correct device-specific printer driver for the XenApp server's operating system (version and bit depth) must be installed on the XenApp server. Two print servers are not required. If a defective driver is replicated throughout a server farm, it is difficult and time consuming to remove it from every server to prevent its use with client printers.

When planning your driver management strategy, determine if you will support device-specific or the Universal Printing driver, or both. If you support standard drivers, you also need to determine:
q

What types of drivers you want to support If you want printer drivers automatically installed when they are missing on farm servers If you want to create driver compatibility lists If you want to replicate drivers across your farm servers automatically

459

Planning Your Printing Configuration


Choosing the most appropriate printing configuration options for your needs and environment can simplify administration. Without performing any printing configurations, users can print in most environments. However, users might not get the printing experience they expect and default printing configurations might not be appropriate for your environment. Your printing configuration depends upon:
q

Your business needs and your existing printing infrastructure. Design your printing configuration around the needs of your organization. Your existing printing implementation (users ability to add printers, which users have access to what printers, and so on) might be a useful guide when defining your XenApp printing configuration. If your organization has security policies that reserve printers for certain users (for example, printers for Human Resources or payroll). If users need to print while away from their primary work location; for example, workers who move between workstations or travel on business.

When designing your printing configuration, try to give users the same experience in a session as they have when they print when working on their local client devices.

460

Default Printing Behavior


By default, if you do not configure any policy rules, XenApp printing behavior is as follows:
q

All printers configured on the client device are created automatically at the beginning of each session. This behavior is equivalent to configuring the Citrix policy setting Auto-create client printers with the Auto-create all client printers option. XenApp routes all print jobs queued to printers locally attached to client devices as client print jobs (that is, over the ICA channel and through the client device). XenApp routes all print jobs queued to network printers directly from the server hosting the published application. If XenApp cannot route the jobs over the network, it will route them through the client device as a redirected client print job. This behavior is equivalent to disabling the Citrix policy setting Direct connection to print servers. XenApp retains all properties and settings users configure for printers they provision themselves in sessions. XenApp stores printing properties on the client device. If the client device does not support this operation, XenApp stores printing properties in the user profile for that user. This behavior is equivalent to configuring the Citrix policy setting Printer properties retention with the Held in profile only if not saved on client option. XenApp uses the Windows version of the printer driver if it is available on the server hosting the application. If the printer driver is not available, the XenApp server attempts to install the driver from the Windows operating system. If the driver is not available in Windows, it uses one of the Citrix Universal printer drivers. This behavior is equivalent to enabling the Citrix policy setting Automatic installation of in-box printer drivers and configuring the Universal printing setting with the Use universal printing only if requested driver is unavailable.

Note: If you are unsure about what the shipping defaults are for printing, display them by creating a new policy and setting all printing policy rules to Enabled. The option that appears is the default.

461

Printing Policy Configuration


When users access printers from published applications, you can configure XenApp policies to specify:
q

How printers are provisioned (or added to sessions) How print jobs are routed How printer drivers are managed

You can have different printing configurations for different client devices or users or any other objects on which policies are filtered. You must understand the ramifications of setting the options in printing policies, so review the information in the printing topics carefully before configuring them. See Configuring and Maintaining XenApp Printing for configuration details.

462

Printing Security
Client printing can, potentially, let a user from one session use another users printer in a different session. Unlike network printer connections, client printers auto-created in a XenApp session are local printers managed by the local print provider and Citrix spooler extensions. The local print provider maintains a single shared namespace for all local printers on a server. This means that a users client printers may be visible and potentially accessible to users from other sessions on the server. By default, the XenApp printer naming convention helps combat this problem by avoiding the potential for printers and ports to be shared between sessions. Printers connected through a pass-through server use the session ID to identify the printer uniquely, keeping the remainder of the name the same. This allows the user to identify both the printer and client it is connected to, without identifying which pass-through server through which it might have connected. In addition, to increase client printing security, access to the client printers is restricted to:
q

The account that the print manager service runs in Processes running in the SYSTEM account such as the spooler Processes running in the users session

Windows security blocks access to the printer from all other processes on the system. Furthermore, requests for services directed to the print manager must originate from a process in the correct session. This prevents bypassing the spooler and communicating directly with CpSvc.exe. As an administrator, you cannot access client printers from another session; this prevents you from inadvertently printing to printers in another session. If you need to adjust security settings of a printer in another session, you can do so through Windows Explorer. Note: If administrators require frequent access to printers in other sessions, add the Admins Can Manage bit flag to default print flags in the system registry of your server. See the Citrix Knowledge Center for more information.

463

Purchasing Printing Hardware


Before purchasing printers for your organization, Citrix recommends finding out if the printer models that you are considering were tested for multiuser environments, such as Windows Remote Desktop Services environments and Citrix XenApp. When purchasing a printer, make sure that it is PCL or PS compatible. Also, make sure the printer is not a host-based printer. Host-based printers use the processor on the host computer to generate print jobs; they are often labeled as GDI, HOST only, or LIDL. Because these printers require software on the client device to generate the print job, they are difficult to run in a XenApp environment. Whether printers work in a XenApp environment is determined by the printer manufacturer, not by Citrix. To determine if a printer model supports XenApp, contact the manufacturer or see the Citrix Ready product guide at www.citrix.com/ready.

464

Configuring and Maintaining XenApp Printing


Most XenApp printing functions are configured through the following Citrix policy categories and settings:
q

Client printers. The settings in this category affect the client redirected printers and printing using the client printing pathway. Drivers. The settings in this category control driver management. Printer redirection bandwidth limit. This setting restricts the bandwidth allocated to printers. Session printers. This setting configures how network printers are provisioned.

If you do not enable any settings that affect printing, XenApp uses the default printing behavior that is described in Planning Your Printing Configuration. Printing settings follow standard Citrix policy behavior:
q

Printing settings are evaluated during initial logon and remain in force throughout the session. Any new printers added to a policy or a user device during a session do not appear in the session until the user logs off and logs on, creating a new session. The policies are filtered on standard objects that apply to all Citrix policy settings. Therefore, when configuring printing settings, determine which filter objects best achieve your goals. Filtering on Client Device Name is useful if you are trying to configure proximity printing. Filtering on Client IP address is useful when associating network printers with specific workstations.

Policy prioritization
All printing policy settings follow standard XenApp prioritization. Citrix policies always take precedence over Windows policies in a XenApp environment.

Policy maintenance
Changes in your network often result in the need to update printing policy configurations. For example, users changing departments or workstation locations require that you update the printing policies associated with that user. Adding or removing printers from your network require that you update any configured Session printers policy settings.

465

Configuring Printer Autocreation Settings


Configure the Citrix policy setting Auto-create client printers to control how or if printers are created automatically at the start of sessions. By default, this setting is not enabled, so XenApp creates all printers on the user device.

To modify printer auto-creation behavior


Configure one of the following in the Auto-create client printers setting:
q

Do not auto-create client printers. Client printers are not auto-created. Auto-create the clients default printer only. Only the clients default printer attached to or mapped from the client preconfigured in the Control Panel is auto-created in the session. Auto-create local (non-network) client printers only. Any non-network printers attached to the client device preconfigured in the Control Panel are auto-created in the session. Auto-create all client printers. All network printers and any printers attached to or mapped from the user device preconfigured in the Control Panel are auto-created in the session.

To configure legacy client printer support


To auto-create client printers with legacy printer names and preserve backward compatibility for users or groups using MetaFrame 3.0 or earlier, choose the Legacy printer names option from the Citrix policy Client printer names setting.

466

Configuring Citrix Universal Printing


There are several different Universal Printing solutions. You can configure:

Citrix XPS Universal Printer driver Citrix Universal Printer driver, which is EMF-based Auto-created Citrix Universal Printer with a Citrix Universal printer driver

Configuring only a Universal printer driver will not improve session start time (printers on the client device are still enumerated and auto-created at the beginning of sessions). However, configuring a Universal printer driver does improve printer driver performance.

To configure universal printing


To configure universal printing, use the following settings:
q

Universal print driver usage. Specifies when to use universal printing. Auto-create generic universal printer. Enables or disables auto-creation of the generic Citrix UNIVERSAL Printer object for sessions when a user device compatible with Universal Printing is in use. By default, the generic Universal Printer object is not auto-created. Universal driver preference. Specifies the order in which XenApp 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 the drivers in the list. Universal printing preview preference. Specifies whether to use the print preview function for auto-created or generic universal printers. Universal printing EMF processing mode. Controls the method of processing the EMF spool file on the Windows user device. 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. Universal printing print quality limits. Specifies the maximum dots per inch (dpi) available for generating printed output in the session. By default, no limit is specified. Universal printing image compression limit. Defines 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. Compression is not disabled for XPS printing.

467

Configuring Citrix Universal Printing


q

Universal printing optimization defaults. Specifies default settings for the Universal Printer when it is created for a session:
q

Desired image quality. Controls the level of image compression. By default, Standard quality is selected. Enable heavyweight compression. Enables or disables reducing bandwidth beyond the compression level set by Desired image quality, without losing image quality. By default, heavyweight compression is disabled. Allow caching of embedded images. Allows or prevents embedded images to be cached. By default, image caching is allowed. Allow caching of embedded fonts. Allows or prevents embedded fonts to be cached. By default, font caching is allowed.

Allow non-administrators to modify these settings. Allows or prevents non-administrative users from modifying any of these options through the printer driver's printing preferences. By default, users cannot modify these options. These options are supported for EMF printing. For XPS printing, only the Desired image quality option is supported.
q

When Universal printing image compression limit and Universal printing optimization defaults are both used:
q

If the compression level in the Universal printing compression limit setting is lower than the level defined in Universal printing optimization defaults setting, images are compressed at the level defined in the Universal printing compression limits setting. If the Universal printing compression limit setting is set to No Compression, the Universal printing optimization defaults setting's Desired image quality and Enable heavyweight compression options have no effect in the policy.

For more information, see Configuring Universal Printer Drivers on Farm Servers.

To change default settings on the Universal Printer


You can change default settings for the Citrix Universal Printer, including settings for paper size, paper width, print quality, color, duplex, and the number of copies. You override the default settings of the Citrix Universal Printer and modify these settings by manually setting registry keys. For a list of the specific registry values, see the Citrix Knowledge Center.

468

Configuring Network Printers for Users


If automatic printer creation fails for network printers on a client device or for session printers because the corresponding drivers are not installed automatically by Windows (because you configured a policy setting preventing auto-installation or they are third-party drivers), you must add the corresponding drivers to your farm servers manually. 1. Add printers to the XenApp server by manually installing the printers. You can use the Add Printer wizard in Windows or browse to the server on which the printer is installed and double click the printer, which forces Windows to place the drivers in its local driver store. 2. Delete the printers. Deleting the printers ensures that they are created only when intended; that is, only if the client has that network printer installed or the GPO with Session printers configured uses filtering and applies to only a subset of all users of the XenApp server.

469

To add a network printer while configuring the Session printers setting


In the Citrix policy setting for Session printers, add a network printer using one of the following methods:
q

Printer UNC path. Enter the path using the format \\servername\printername. Browse. Locate a printer on the network. Browse for printers on a specific server. Enter the server name using the format \\servername and click Browse.

Important: The server merges all enabled session printer settings for all applied policies, starting from the highest to lowest priorities. When a printer is configured in multiple policy objects, custom default settings are taken from only the highest priority policy object in which that printer is configured.

470

To specify a default printer for a session


To specify a network printer, it must already be added to the policy in which you are enabling the Citrix policy setting Default printer. 1. Complete the procedure, To add a network printer while configuring the Session printers setting. 2. On the Default printer settings page, from the Choose clients default printer drop-down list, choose one of the following:
q

Name of the network printer you want to be default for this policy. Printers that were added with the Session printers policy setting are displayed in this drop-down menu and can be specified as the default printer. Set default printer to the clients main printer. Sets the default printer for the session to the clients current default printer. If the client's main printer is not mapped, this option has no effect. Important: Mapping for the clients main printer can also be disabled through other policies, group policies, or Remote Desktop Services settings.

Do not adjust the users default printer. Uses the current Remote Desktop Services or Windows user profile setting for the 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. You can use this option to present users with the nearest printer through profile settings (functionality known as Proximity Printing). When Do not adjust the users default printer is selected, the default printer in a session will be the first printer auto-created in the session, which is either:
q

The first printer added locally to the Windows server in the Control Panel

The first auto-created printer, if there are no printers added locally to the server 3. Apply the policy to the group of users (or other filtered objects) you want to affect.
q

471

To edit the printer settings in the sessions policy


Use the Citrix policy setting Session printers to override printer's default settings at the beginning of each session. This setting overrides retained printer settings the user set during a previous session. You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If you specify a printing option that the printer does not support, that option has no effect. 1. On the Session printers settings page, select the name of the printer for which you want to modify the settings. 2. Click Settings. 3. Specify the printer settings.

472

To configure server local printers


To let users connecting to the farm print to a printer that is local to a farm server, physically connect the printer to a farm server and share it as follows: 1. On the server where the printer is physically connected, in Control Panel > Hardware > Devices and Printers, right-click the printer you want to share. 2. Choose Printer Properties. 3. In the Sharing tab, select these check boxes:
q

Share this printer

Render print jobs on client computers Sharing the printer allows creation of the printer when a session on that server is launched.
q

473

Configuring Printers for Mobile Workers


When you want to make sure that users always see the closest printer to their client device in a session, configure the Proximity printing solution. Proximity printing enables users within a specified IP address range to automatically access the network printing devices that exist within that same range. The ability to configure proximity printing assumes that your network is designed as follows:
q

It uses a DHCP server to assign your users IP addresses by their location (for example, floor of a building) All departments/floors within the company have unique designated IP address ranges Network printers are assigned IP addresses within the range of IP addresses for the department/floor in which they are located

To configure Proximity Printing using IP addresses


1. Create a separate policy for each subnet (or to correspond with printer location). 2. In each policy, add the printers in that subnets geographic location to the Session printers setting. 3. Set the Default printer setting to Do not adjust the user's default printer. 4. Filter the policies by Client IP address.

474

Changing Network Print Job Routing


By default, XenApp routes jobs to network printers from the application server directly to the print server (along the network printing pathway). Note: Print jobs sent over the network printing pathway are not compressed. When routing printing jobs across a network with limited bandwidth, Citrix recommends routing jobs through the client device so that the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting Direct connection to print servers.

475

Providing Tools for User Provisioning


The following groups of users cannot add printers to sessions unless you publish printer provisioning tools for them:

Windows users who do not have access to the Add Printer wizard on the local client device or any applications that let them browse to printers Non-Windows plug-in users

If you want these users to add printers on their own, publish either:

The ICA Client Printer Configuration Tool (PrintCfg.exe). This tool lets Windows CE and DOS users add printers. The Add Printer wizard. Publishing this Windows wizard lets users with Windows plug-ins add printers that are on the local client device or network. Publishing this wizard is also referred to sometimes as publishing the Print Manager.

After a user adds printers using either of these methods, XenApp retains the printer information for the next time a user logs on from that client device. Client printers created using this process are considered retained printers.

To publish the Windows Add Printer wizard


This procedure assumes that you already published Windows Explorer on the server on which you want to publish the Add Printer wizard. 1. Create the following folder at the root level of one of the XenApp servers drives: C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D} where C represents a drive on the XenApp server. When you press Enter, the folder icon changes to a printer icon. 2. Create a published application with the following properties: Command line. Path of explorer.exe C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D} Working directory. The path where explorer.exe is located. If you get a path error and cannot access the published printers folder, modify the command line to include %*. For example, Command line. Path of explorer.exe %*C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}

476

Providing Tools for User Provisioning

To publish the ICA Client Printer Configuration Tool


1. Follow the instructions for publishing an application in To publish a resource using the Publish Application wizard. 2. On the Location page, enter the path for the ICA Client Printer Configuration tool (printcfg.exe) on your server. On a 64-bit system, the default location for the tool is C:\Program Files (x86)\Citrix\system32\printcfg.exe. On a 32-bit system, the default location for the tool is C:\Program Files\Citrix\system32\printcfg.exe.

477

To store users printer properties


To store user printer properties, configure the Citrix policy setting Printer properties retention by choosing from the following settings:
q

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 online plug-in versions 9.x, 10.x, 11.x, and 12.x, or Citrix Receiver 13.x. 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 user 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.

478

To synchronize properties from the printer


To obtain printer properties directly from the printer itself, rather than from the properties store, use the following procedure. This procedure ensures that changes made offline to printers on the local computer are used next time a user starts a session. 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. Open the Registry Editor and navigate to one of the following registry locations:
q

For 64-bit, HKLM\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences

For 32-bit, HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences 2. Create the following registry key: Name:Win32FavorRetainedPrinterSettings Data Type: REG_SZ Value Data: false
q

3. Restart the Citrix Print Manager Service.

479

Controlling Printer Driver Automatic Installation


Managing printer drivers is important for a successful printing experience. When XenApp autocreates printers, it determines if their corresponding drivers are missing. By default, XenApp installs any missing printer drivers from the Windows native printer driver set. If a problematic printer driver is installed automatically, it can cause issues. You can either prevent printer drivers from being installed automatically, or, if you want to have them installed automatically, you can control what drivers are installed on farm servers by specifying the drivers on a compatibility list:

If you know what printer drivers cause problems, you can specify banned printer drivers in the compatibility list If you do not know what drivers cause problems or you want tighter control over the drivers on the farm, specify to install only drivers on the compatibility list

When users log on:


q

XenApp checks the client printer driver compatibility list before it sets up the client printers If a printer driver is on the list of drivers that are not allowed, XenApp does not set up the printer unless the Universal Printing feature is enabled When the compatibility list prevents setup of a client printer, XenApp writes a message in the servers Event log

To prevent drivers from being installed automatically, configure the Printing > Drivers > Native printer driver auto-install policy rule. See the section "To add or remove drivers or edit driver names in the compatibility list" in this topic to ban specific printer drivers.

480

Controlling Printer Driver Automatic Installation

To specify how client printer drivers are installed on farm servers


1. Depending on the version of XenApp you have installed:
q

From the Start menu, open All Programs > Citrix > Administration Tools and choose XenApp Advanced Configuration.

From the ICA toolbar, open the Presentation Server Console. 2. Select the Policies node.
q

3. On the Contents tab, choose the policy for which you want to configure printing rules. 4. From the Actions menu, choose Properties. 5. In the policys Properties dialog box, expand Printing, then Drivers. 6. Under Drivers, you can configure the following rules:
q

Use the Native printer driver auto-install rule to control whether Windows native drivers are automatically installed when auto-creating either a client or network printer. Enabling this rule lets you prevent the automatic installation of printer drivers. See To control the automatic installation of printer drivers. Use the Universal driver rule to specify whether auto-created client printers use universal printer drivers, model-specific printer drivers, or both. The universal drivers can enable printing even when model-specific drivers are not available. See To specify the Universal Printer driver for sessions.

To add or remove drivers or edit driver names in the compatibility list


1. Depending on the version of XenApp you have installed:
q

From the Start menu, open All Programs > Citrix > Administration Tools and choose XenApp Advanced Configuration.

q From the ICA toolbar, open the Presentation Server Console. 2. Select Printer Management > Drivers.

3. On the Actions menu, select Printer Management > Compatibility. 4. Choose the required platform from the drop-down list. 5. Select one of the following Compatibility list options:
q

Allow only drivers in the list. Keeps a list of incompatible drivers that are not allowed to be used by client printers and allow all others.

Allow all drivers except those in the list. Keeps a list of compatible drivers that client printers are allowed to use and bans all others. 6. Update the list.
q

481

Controlling Printer Driver Automatic Installation

To control the automatic installation of printer drivers


1. Choose the Native printer driver auto-install policy rule. 2. On the Native printer driver auto-install properties page, select Enabled. 3. Select one of the following:
q

Install Windows native drivers as needed (selected by default). Allows XenApp to install Windows native printer drivers (those present in driver.cab) automatically when auto-creating either a client or network printer. Caution: Enabling this option may result in the installation of a large number of native drivers.

Do not automatically install drivers. Requires administrators to install individual native printer drivers manually.

To specify the Universal Printer driver for sessions


1. Choose the Printing > Drivers> Universal driver policy rule. 2. On the Universal driver properties page, select Enabled. 3. Select one of the following:
q

Use universal driver only. Specifies that the client printer uses the Universal printer driver only. Select this option if you do not want to use native drivers. Use universal driver 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 uses only the native drivers that are autocreated at logon. If the native driver of the printer is unavailable, the client printer cannot be autocreated.

482

Configuring Universal Printer Drivers on Farm Servers


If you configure a Universal printer driver for sessions, by default, XenApp always uses the Citrix Universal (EMF) Printer driver, when it is available. If it is not available, XenApp uses the XPS Universal Printer driver. The XPS Universal printer driver can be configured as the default by configuring the Citrix policy setting Universal driver preference. The Citrix Universal printer drivers are listed in the Print Management MMC snap-in. Provided all prerequisites for the driver were installed when you ran XenApp Setup, the following drivers appear:
q

Citrix Universal Printer, which is the .EMF driver Citrix XPS Universal Printer HP Color LaserJet 2800 PS (Citrix PS Universal Printer Driver)

If you need a Universal driver that does not appear in this list, you must install it.

To specify the Universal Printer driver for sessions


Configure the Citrix policy setting Universal print driver usage by choosing one of the following:
q

Use universal printing only if requested driver is unavailable uses standard model-specific drivers for printer creation 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 standard model-specific drivers that are auto-created at logon. If the requested driver is unavailable, the client printer cannot be auto-created. Use universal printing only specifies that no standard model-specific drivers are used. Only universal print drivers are used to create printers. 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 model-specific printer driver.
q

To change the default Citrix Universal Printer driver

483

Configuring Universal Printer Drivers on Farm Servers To force XenApp to use the Citrix XPS Universal Printer driver before the EMF-based Citrix Universal Printer driver, configure the Citrix policy setting Universal driver preference and move XPS to the top of the list.

484

Mapping Client Printer Drivers


If the servers in your farm have the same drivers as the client printers but the drivers themselves are named differently (for example, HP LaserJet 4L versus HP LaserJet 4), XenApp may not recognize the drivers are the same and users will have difficulty printing or printer autocreation may fail. You can resolve this issue by overriding, or mapping, the printer driver name the client provides and substituting an equivalent driver on the server. Mapping client printer drivers gives server applications access to client printers that have the same drivers as the server but different driver names. You can use the printer driver remapping feature to substitute:
q

Good printer drivers for outdated or corrupted drivers Specific Windows printer drivers for manufacturers client printer drivers A driver that is available on Windows server for a client driver name

Each client provides information about client-side printers during logon, including the printer model name. During client printer autocreation, Windows server printer driver names are selected that correspond to the printer model names provided by the client. The autocreation process then employs the identified, available printer drivers to construct redirected client print queues.

To map client printer drivers to server printer drivers


Configure the Citrix policy setting Printer driver mapping and compatibility by adding the client printer driver name and selecting the server driver that you want to substitute for the client printer driver from the Find printer driver menu. You can use wildcards in this setting. For example, to force all HP printers to use a specific driver, specify HP* in the policy setting.

To edit printing settings for mapped client printer drivers


After you have added a client printer driver to the list of mapped drivers, you can modify the printing settings for the driver. This setting overrides retained printer settings the user set during a previous session. You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If you specify a printing option that the printer driver does not support, that option has no effect.

485

Mapping Client Printer Drivers 1. On the Printer driver mapping and compatibility settings page, select the printer driver for which you want to modify the settings. 2. Click Settings. 3. Specify the printer settings.

486

Improving Session Performance by Limiting Printing Bandwidth


While printing files from published applications to client printers, other virtual channels (such as video) may experience decreased performance due to competition for bandwidth especially if users are accessing servers through slower networks or dial-up connections. To prevent such degradation, you can limit the bandwidth used by client printing. Important: The printer bandwidth limit is always enforced, even when no other channels are in use. By limiting the data transmission rate for printing, you make more bandwidth available in the ICA data stream for transmission of video, keystrokes, and mouse data. More available bandwidth can help prevent degradation of the user experience during printing. There are two ways you can limit printing bandwidth in client sessions using printer settings in the Bandwidth category:

Use the Citrix policy Bandwidth printer settings in the Delivery Services Console to enable and disable the printing bandwidth session limit for the farm. Use individual server settings to limit printing bandwidth in the server farm. You can perform this task using gpedit.msc locally on each server to configure the Citrix policy Bandwidth printer settings.

You can use the Citrix Session Monitoring and Control Console (included in the WFAPI SDK) to obtain real-time information about printing bandwidth. The print spooling virtual channel control (that is, the CTXCPM Client printer mapping virtual channel control) lets you set a priority and bandwidth limit for bandwidth control of this virtual channel.

To configure a printing bandwidth setting in an existing policy


Configure one of the options in the Citrix policy Bandwidth setting. If you enter values for both settings, the most restrictive setting (with the lower value) is applied.

Printer redirection bandwidth limit to specify the bandwidth available for printing in kilobits per second (kbps). Printer redirection bandwidth limit percent to limit the bandwidth available for printing to a percentage of the overall bandwidth available.

487

Improving Session Performance by Limiting Printing Bandwidth Note: If you want to specify bandwidth as a percentage using the Printer redirection bandwidth limit percent setting, you must enable the Overall session bandwidth limit as well.

To limit printer bandwidth for a server


Using the Window Group Policy Editor locally on a server, configure one of the options in the Citrix policy Bandwidth setting. If you enter values for both settings, the most restrictive setting (with the lower value) is applied.

Printer redirection bandwidth limit to specify the bandwidth available for printing in kilobits per second (kbps). Printer redirection bandwidth limit percent to limit the bandwidth available for printing to a percentage of the overall bandwidth available. Note: If you want to specify bandwidth as a percentage using the Printer redirection bandwidth limit percent setting, you must enable the Overall session bandwidth limit as well.

488

Displaying Printers
The following table summarizes where you can manage and modify print queues and display printers in a XenApp environment. For definitions of the terms client printing pathway and network printing pathway, see Overview of Client and Network Printing Pathways. Client printing pathway is not synonymous with printers attached to client devices.

Client printers (Printers attached to the client device)

Printing Pathway Client printing pathway

UAC Enabled? On

Location Print Management snap-in in the Microsoft Management Console Control Panel Print Management snap-in in the Microsoft Management Console Control Panel Print Server > Print Management snap-in in the Microsoft Management Console Print Server > Control Panel Control Panel Control Panel Control Panel Control Panel

Off Network printers (Printers on a network print server) Client printing pathway On

Off Network printers (Printers on a network print server) Network printing pathway On

Off Server local printers (Shared printers locally attached to a XenApp server) Local network server printers (Printers from a network print server that are added to server running XenApp) N/A On Off Network printing pathway On Off

489

Managing Printers Using the Network Printing Pathway


If you want to modify or manage a users network print queue that a user printed to across the network printing pathway, you must manage it through Control Panel on the print server with the correct level of Windows administrator privileges. Print queues for network printers that use the network printing pathway are private and cannot be managed through XenApp. Whenever you configure a network printing pathway and the server hosting the application does not have or cannot install the driver, by default, XenApp sends the print job along the client printing pathway. You can tell a job sent to the network printer is redirected along the client printing pathway when you see printers appearing in the Windows Server Manager Snap-in > Print and Document Services role that has the following syntax: PrinterName on PrintServer (from clientname) in session n where: PrinterName is the name of the printer being redirected PrintServer is the name of the print server with which the printer is associated clientname is the name of the client through which the print job is being rerouted n is the session ID for that ICA connection For example, Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2.

490

Displaying Printers Using the Client Printing Pathway


If UAC is not enabled, you can, however, display and manage redirected client print queues and server local printers through Control Panel > Printers of individual servers. The client printers displayed on a server fluctuate based on what sessions are active on a server because XenApp creates these printers based on the printers on the connecting client devices. You can display client printers in Control Panel > Printers.

To display printers that use the client printing pathway when UAC is enabled
1. On the XenApp server that is hosting the session for which you want to display the printers, install the Print Services server role. 2. In Administrative Tools, open the Print Management stand-alone snap-in. 3. To display client redirected printers, in the Print Management tree, select Print Management > Custom Filters > All Printers. The Print Management snap-in displays the client printers redirected from all clients connected to that server. You can display and manage the print queues for these printers and select Printers With Jobs in the Print Management Tree to display active jobs on redirected printers.

To display printers that use the client printing pathway without UAC enabled
1. On the XenApp server, open Control Panel > Printers. The Printers screen displays the local printers mapped to the ICA session. By default, the name of the printer takes the form printername (from clientname) in session x; for example, printer01 (from machine01) in session 7. Printername is the name of the printer on the client device, clientname is the unique name given to the client device or the Web Interface, and x is the SessionID of the users session on the server.

491

XenApp Server Utilities Reference


Citrix XenApp server utilities provide an alternative method to using the console for maintaining and configuring servers and farms. Citrix XenApp server utilities must be run from a command prompt on a server running Citrix XenApp.

Command altaddr app auditlog ctxkeytool ctxxmlss dscheck dsmaint icaport imaport query

Description Specify server alternate IP address. Run application execution shell. Generate server logon/logoff reports. Generate farm key for IMA encryption. Change the Citrix XML Service port number. Validate the integrity of the server farm data store. Maintain the server farms data store. Configure TCP/IP port number used by the ICA protocol on the server. Change IMA ports. View information about server farms, processes, ICA sessions, and users.

492

ALTADDR
Use altaddr to query and set the alternate (external) IP address for a server running Citrix XenApp. The alternate address is returned to clients that request it and is used to access a server that is behind a firewall.

Syntax
altaddr [/server:servername] [/set alternateaddress] [/v] altaddr [/server:servername] [/set adapteraddress alternateaddress] [/v] altaddr [/server:servername] [/delete] [/v] altaddr [/server:servername] [/delete adapteraddress] [/v] altaddr [/?]

Parameters
servername The name of a server. alternateaddress The alternate IP address for a server. adapteraddress The local IP address to which an alternate address is assigned.

Options
/server:servername Specifies the server on which to set an alternate address. Defaults to the current server. /set Sets alternate TCP/IP addresses. If an adapteraddress is specified, alternateaddress is assigned only to the network adapter with that IP address.

493

ALTADDR /delete Deletes the default alternate address on the specified server. If an adapter address is specified, the alternate address for that adapter is deleted. /v (verbose) Displays information about the actions being performed. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
The server subsystem reads the altaddr settings for server external IP addresses at startup only. If you use altaddr to change the IP address setting, you must restart the Citrix Independent Management Architecture service for the new setting to take effect. If altaddr is run without any parameters, it displays the information for alternate addresses configured on the current server.

Examples
Set the servers alternate address to 1.1.1.1: altaddr /set 1.1.1.1 Set the servers alternate address to 2.2.2.2 on the network interface card whose adapter address is 1.1.1.1:

altaddr /set 2.2.2.2 1.1.1.1

Security Restrictions
None.

494

APP
App is a script interpreter for secure application execution. Use App to read execution scripts that copy standardized .ini type files to user directories before starting an application, or to perform application-related cleanup after an application terminates. The script commands are described below.

Syntax
app scriptfilename

Parameters
scriptfilename The name of a script file containing app commands (see script commands below).

Script Commands
copy sourcedirectory\filespec targetdirectory Copies files from sourcedirectory to targetdirectory. Filespec specifies the files to copy and can include wild cards (*,?). deletedirectory\filespec Deletes files owned by a user in the directory specified. Filespec specifies the files to delete and can include wild cards (*,?). See the Examples section for more information. deleteall directory\filespec Deletes all files in the directory specified. execute Executes the program specified by the path command using the working directory specified by the workdir command. path executablepath Executablepath is the full path of the executable to be run.

495

APP workdir directory Sets the default working directory to the path specified by directory

Script Parameters
directory A directory or directory path. executablepath The full path of the executable to be run. filespec Specifies the files to copy and can include wildcards (*,?). sourcedirectory The directory and path from which files are to be copied. targetdirectory The directory and path to which files are to be copied.

Remarks
If no scriptfilename is specified, app displays an error message. The Application Execution Shell reads commands from the script file and processes them in sequential order. The script file must reside in the %SystemRoot%\Scripts directory.

Examples
The following script runs the program Notepad.exe. When the program terminates, the script deletes files in the Myapps\Data directory created for the user who launched the application:

PATH C:\Myapps\notepad.exeWORKDIR C:\Myapps\DataEXECUTEDELETE C:\Myapps\Data\*.* The following script copies all the .wri files from the directory C:\Write\Files, executes Write.exe in directory C:\Temp.wri, and then removes all files from that directory when the program terminates:

496

APP PATH C:\Wtsrv\System32\Write.exeWORKDIR C:\Temp.wriCOPY C:\Write\Files\*.wri C:\Temp.wriEXECUTEDELETEALL C:\Temp.wri\*.* The following example demonstrates using the script file to implement a front-end registration utility before executing the application Coolapp.exe. You can use this method to run several applications in succession:

PATH C:\Regutil\Reg.exeWORKDIR C:\RegutilEXECUTEPATH C:\Coolstuff\Coolapp.exeWORKDIR C:\TempEXECUTEDELETEALL C:\Temp

Security Restrictions
None.

497

AUDITLOG
Auditlog generates reports of logon/logoff activity for a server based on the Windows Server security event log. To use auditlog, you must first enable logon/logoff accounting. You can direct the auditlog output to a file.

Syntax
auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy] [[/write:filename] | [/detail | /time] [/all]] auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy] [[/write:filename] | [/detail] | [/fail ] | [ /all]] auditlog [/clear:filename] auditlog [/?]

Parameters
filename The name of the eventlog output file. session Specifies the session ID for which to produce a logon/logoff report. Use this parameter to examine the logon/logoff record for a particular session. mm/dd/yy The month, day, and year (in two-digit format) to limit logging. username Specifies a user name for which to produce a logon/logoff report. Use this parameter to examine the logon/logoff record for a particular user.

Options
/eventlog:filename

498

AUDITLOG Specifies the name of a backup event log to use as input to auditlog. You can back up the current log from the Event Log Viewer by using auditlog /clear: filename. /before:mm/dd/yy Reports on logon/logoff activity only before mm/dd/yy. /after:mm/dd/yy Reports on logon/logoff activity only after mm/dd/yy. /write:filename Specifies the name of an output file. Creates a comma-delimited file that can be imported into an application, such as a spreadsheet, to produce custom reports or statistics. It generates a report of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. If filename exists, the data is appended to the file. /time Generates a report of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. Useful for gathering usage statistics by user. /fail Generates a report of all failed logon attempts. /all Generates a report of all logon/logoff activity. /detail Generates a detailed report of logon/logoff activity. /clear:filename Saves the current event log in filename and clears the Event log. This command does not work if filename already exists. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
Auditlog provides logs you can use to verify system security and correct usage. The information can be extracted as reports or as comma-delimited files that can be used as input to other programs. You must enable logon/logoff accounting on the local server to collect the information used by auditlog. To enable logon/logoff accounting, log on as a local administrator and enable

499

AUDITLOG logon/logoff accounting with the Audit Policy in Microsoft Windows.

Security Restrictions
To run auditlog, you must have Windows administrator privileges.

500

CTXKEYTOOL
Use ctxkeytool to enable and disable the IMA encryption feature and generate, load, replace, enable, disable, or back up farm key files.

Syntax
ctxkeytool [generate | load | newkey | backup] filepath ctxkeytool [enable | disable | query]

Options
generate Generates a new key and saves it to the filepath. This command alone is not sufficient to enable IMA encryption. load Can be used to load:
q

A new key onto a server with no preexisting key The correct key onto a server that has an existing key

A new key onto a computer and the farm newkey


q

Creates a new encryption key in the data store using the local farm key. backup Backs up the existing farm key to a file. enable Enables the IMA encryption feature for the farm. disable Disables the IMA encryption feature for the farm. query

501

CTXKEYTOOL Can be used to check:


q

For a key on the local computer To see if IMA encryption is enabled for the farm If your key matches the farm key

Remarks
The first time you generate a key for the first server on the farm on which you are enabling IMA encryption, use the following sequence of options: generate, load, and newkey. On each subsequent server in the farm, you just need to load the key. After you activate the IMA encryption feature on one server, the feature is enabled for the entire farm. If you lose the key file for a server, you can get a duplicate key file by running the backup option on another server in the same farm that still has its key. This command recreates the key file. After recreating the key file, use load to load it to the server on which it was lost. After using the disable option to disable the IMA encryption feature, you must reenter the configuration logging database password. If you want to activate the IMA encryption feature again, run enable on any server in the farm.

Security Restrictions
You must be a Citrix administrator with local administrator privileges to run ctxkeytool.

502

CTXXMLSS
Use ctxxmlss to change the Citrix XML Service port number.

Syntax
ctxxmlss [/rnnn] [/u] [/knnn] [/b:a] [/b:l] [/?]

Options
/rnnn Changes the port number for the Citrix XML Service to nnn. /u Unloads Citrix XML Service from memory. /knnn Keeps the connection alive for nnn seconds. The default is nine seconds. /b:a Binds the service to all network interfaces. This is the default setting. /b:l Binds the service to localhost only. /? Displays the syntax for the utility and information about the utilitys options.

Security Restrictions
None.

503

CTXXMLSS

Remarks
For more information, see System Requirements.

504

DSCHECK
Use dscheck to validate the consistency of the database used to host the server farms data store. You can then repair any inconsistencies found. dscheck is often used after running dsmaint.

Syntax
dscheck [/clean] [/?]

Options
/clean Attempts to fix any consistency error that is found. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
Dscheck performs a variety of tests to validate the integrity of a server farms data store. When run without parameters, only these tests are run. Run dscheck on a server in the farm that has a direct connection to the data store. When you run dscheck with the /clean option, the utility runs tests and removes inconsistent data (typically servers and applications) from the data store. Because removing this data can affect the farms operation, be sure to back up the data store before using the /clean option. When you run the utility with the /clean option, you may need to run the dsmaint command with the recreatelhc parameter on each server in the farm to update the local host caches. Running this command sets the PSRequired registry value to 1 in HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\RUNTIME, or HKLM\SOFTWARE\Citrix\IMA\RUNTIME on XenApp, 32-bit Edition. Dscheck reports the results of the tests in several ways. First, it sends any errors found as well as a summary to the Event log and to the command window. You can also write the output produced by dscheck to a file.

505

DSCHECK Second, several performance monitor values are updated under the performance object for Citrix XenApp. These values include a count of server errors, a count of application errors, a count of group errors, and an overall flag indicating that errors were detected. Third, dscheck returns an error code of zero for a successful scan (no errors are found) and an error code of one if any problems are encountered. Dscheck looks primarily at three data store objects: servers, applications, and groups. For each of these object types, dscheck performs a series of tests on each object instance. For example, for each server object in the data store, dscheck verifies that there is a corresponding common server object and then further verifies that both objects have matching host IDs and host names.

Examples
To run consistency checks only: dscheck To check consistency and fix errors:

dscheck /clean

506

DSMAINT
Run dsmaint on farm servers to perform XenApp data store maintenance tasks, including backing up the data store, migrating the data store to a new server, and compacting the XenApp data store or the Streaming Offline database. Not all dsmaint commands apply to all database types.

When using this command, user names and passwords may be case-sensitive, depending on the database and the operating system you are using.

Syntax
dsmaint config [/rade] [/user:username] [/pwd:password] [/dsn:filename] dsmaint backup destination_path dsmaint compactdb [/lhc] dsmaint migrate [{/srcdsn:dsn1 /srcuser:user1 /srcpwd:pwd1}] [{/dstdsn:dsn2 /dstuser:user2 /dstpwd:pwd2}] dsmaint publishsqlds {/user:username /pwd:password} dsmaint recover dsmaint recreatelhc dsmaint recreaterade dsmaint verifylhc [/autorepair] dsmaint [/?]

Parameters
destination_path Path for the backup data store. Do not use the same path as the original database. dsn1 The name of the DSN file for the source data store. dsn2

507

DSMAINT The name of the DSN file for the destination data store. filename The name of the data store. password The password to connect to the data store. pwd1 The source data store password. pwd2 The destination data store password. user1 The source data store user logon. user2 The destination data store user logon. username The name of the user to use when connecting to the data store.

Options
config Changes configuration parameters used to connect to the data store. Enter the full path to the DSN file in quotation marks. For example, dsmaint config /user:ABCnetwork\administrator /pwd:Passw0rd101 /dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn" Stop the Citrix Independent Management Architecture service before using config with the /pwd option. Caution: Specify a /dsn for dsmaint config or you will change the security context for access to the SQL Server or Oracle database. /rade Compacts the offline data store. /user:username The user name to connect to a data store.

508

DSMAINT /pwd:password The password to connect to a data store. /dsn:filename The filename of an IMA data store. backup Creates a backup copy of the SQL Server Express database that is the farms data store. Run this command on the server that hosts the data store. Requires a path or share point to which the backup database file will be copied. Do not use this parameter to back up SQL Server or Oracle data stores. Caution: When running dsmaint backup, specifying the same path as the existing data store can damage it irreparably. compactdb Compacts the local database file. During database compaction, the database is temporarily unavailable for both reading and writing. The compacting time can vary from a few seconds to a few minutes, depending on the size of the database and the usage. /lhc Compacts the local host cache on the server where this parameter is run. Run dsmaint /lhc after your farm has been running for a long period of time as a maintenance task. migrate Migrates data from one data store database to another. Run this command on any XenApp server that has a connection to the data store. Use this command to move a data store to another server, rename a data store in the event of a server name change, or migrate the data store to a different type of database (for example, migrate from SQL Server Express to SQL Server). To migrate the data store to a new server: 1. Prepare the new database server using the steps you did before running XenApp Setup for the first time. 2. Create a DSN file for this new database server on the server where you will be running dsmaint migrate. 3. Run dsmaint migrate on any server with a connection to the data store. 4. Run dsmaint config on each server in the farm to point it to the new database. /srcdsn:dsn1 The name of the data store from which to migrate data. /srcuser:user1 The user name to use to connect to the data store from which the data is migrating.

509

DSMAINT /srcpwd:pwd1 The password to use to connect to the data store from which the data is migrating. /dstdsn:dsn2 The name of the data store to which to migrate the data. /dstuser:user2 The user name that allows you to connect to the data store to which you are migrating the source data store. /dstpwd:pwd2 The password that allows you to connect to the data store to which you are migrating the source data store. publishsqlds Publishes a SQL Server data store for replication. Run publishsqlds only from the server that created the farm. The publication is named MFXPDS. recover Restores a SQL Server Express data store to its last known good state. Run this directly on the server while the Citrix Independent Management Architecture service is not running. recreatelhc Recreates the local host cache database. Run if prompted after running dsmaint verifylhc. After running dsmaint recreatelhc, restart the IMA Service. When the IMA Service starts, the local host cache is populated with fresh data from the data store. recreaterade Recreates the application streaming offline database. Run as a troubleshooting step if the Citrix Independent Management Architecture service stops running and the local host cache is not corrupted. verifylhc Verifies the integrity of the local host cache. If the local host cache is corrupt, you are prompted with the option to recreate it. With the verifylhc /autorepair option, the local host cache is automatically recreated if it is found to be corrupted. Alternatively, you can use dsmaint recreatelhc to recreate the local host cache. /? Displays the syntax and options for the utility.

510

DSMAINT

Remarks
After using dsmaint, Citrix recommends running dscheck to check the integrity of the data on the XenApp data store.

Security Restrictions
The dsmaint config and dsmaint migrate commands can be run only by a user with the correct user name and password for the database.

511

ICAPORT
Use icaport to query or change the TCP/IP port number used by the ICA protocol on the server.

Syntax
icaport {/query | /port:nnn | /reset} [/?]

Options
/query Queries the current setting. /port:nnn Changes the TCP/IP port number to nnn. /reset Resets the TCP/IP port number to 1494, which is the default. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
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 Receiver or plug-in that will connect to that server. For instructions for changing the port number on receivers or plug-ins, see the Receiver or plug-in documentation.

Examples
To set the TCP/IP port number to 5000 512

ICAPORT

icaport /port:5000 To reset the port number to 1494

icaport /reset

Security Restrictions
Only Citrix administrators with Windows administrator privileges can run icaport.

513

IMAPORT
Use imaport to query or change the IMA port.

Syntax
imaport {/query | /set {IMA:nnn | ds:nnn}* | /reset {IMA | DS | ALL} } [/?]

Options
/query Queries the current setting. /set Sets the designated TCP/IP port to a specified port number. ima:nnn Sets the IMA communication port to a specified port number. ds:nnn Sets the data store server port to a specified port number. /reset Resets the specified TCP/IP port to the default. ima Resets the IMA communication port to 2512. ds Resets the data store server port to 2512. all Resets all of the applicable ports to the defaults. /? Displays the syntax for the utility and information about the utilitys options.

514

IMAPORT

515

QUERY FARM
Use query to display information about server farms within the network.

Syntax
query farm [server [/addr | /app | /app appname | /load | /ltload]] query farm [ /tcp ] [ /continue ] query farm [ /app | /app appname | /disc | /load | /ltload | /lboff | /process] query farm [/online | /online zonename] query farm [/offline | /offline zonename] query farm [/zone | /zone zonename] query farm [/?]

Parameters
appname The name of a published application. server The name of a server within the farm. zonename The name of a zone within the farm.

Options
farm Displays information about servers within an IMA-based server farm. You can use qfarm as a shortened form of query farm. server /addr

516

QUERY FARM Displays address data for the specified server. /app Displays application names and server load information for all servers within the farm or for a specific server. /app appname Displays information for the specified application and server load information for all servers within the farm or for a specific server. /continue Do not pause after each page of output. /disc Displays disconnected session data for the farm. /load Displays server load information for all servers within the farm or for a specific server. /ltload Displays server load throttling information for all servers within the farm or for a specific server. /lboff Displays the names of the servers removed from load balancing by Health Monitoring & Recovery. /process Displays active processes for the farm. /tcp Displays TCP/IP data for the farm. /online Displays servers online within the farm and all zones. The data collectors are represented by the notation D. /online zonename Displays servers online within a specified zone. The data collectors are represented by the notation D. /offline Displays servers offline within the farm and all zones. The data collectors are represented by the notation D. 517

QUERY FARM /offline zonename Displays servers offline within a specified zone. The data collectors are represented by the notation D. /zone Displays all data collectors in all zones. /zone zonename Displays the data collector within a specified zone. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
Query farm returns information for IMA-based servers within a server farm.

Security Restrictions
You must be a Citrix administrator to run query farm .

518

QUERY PROCESS
Use query to display information about processes within the network.

Syntax
query process [ * | processid | username | sessionname | /id:nn | programname ] [ /server:servername ] [ /system ] query process [/?]

Parameters
* Displays all visible processes. processid The three- or four-digit ID number of a process running within the farm. programname The name of a program within a farm. servername The name of a server within the farm. sessionname The name of a session, such as ica-tcp#7. username The name of a user connected to the farm.

Options
process Displays information about processes running on the current server.

519

QUERY PROCESS process * Displays all visible processes on the current server. process processid Displays processes for the specified processid. process username Displays processes belonging to the specified user. process sessionname Displays processes running under the specified session name. process /id:nn Displays information about processes running on the current server by the specified ID number. process programname Displays process information associated with the specified program name. process /server:servername Displays information about processes running on the specified server. If no server is specified, the information returned is for the current server. process /system Displays information about system processes running on the current server. /? Displays the syntax for the utility and information about the utilitys options.

Security Restrictions
None.

520

QUERY SESSION
Use query to display information about sessions within the network.

Syntax
query session [sessionname | username | sessionid] query session [/server:servername] [/mode] [/flow] [/connect] [/counter] query session [/?]

Parameters
servername The name of a server within the farm. sessionname The name of a session, such as ica-tcp#7. sessionid The two-digit ID number of a session. username The name of a user connected to the farm.

Options
session sessionname Identifies the specified session. session username Identifies the session associated with the user name. session sessionid

521

QUERY SESSION Identifies the session associated with the session ID number. session /server: servername Identifies the sessions on the specified server. session /mode Displays the current line settings. session /flow Displays the current flow control settings. session /connect Displays the current connection settings. session /counter Displays the current Remote Desktop Services counter information. /? Displays the syntax for the utility and information about the utilitys options.

Security Restrictions
None.

522

QUERY TERMSERVER
Use query to display information about terminal servers within the network.

Syntax
query termserver [servername] [/domain:domain] [/address] [/continue] query termserver [/?]

Parameters
servername The name of a server within the farm. domain The name of a domain to query.

Options
termserver servername Identifies a Terminal Server. /address Displays network and node addresses. /continue Do not pause after each page of output. /domain: domain Displays information for the specified domain. Defaults to the current domain if no domain is specified. /? Displays the syntax for the utility and information about the utilitys options.

523

QUERY TERMSERVER

Remarks
If no parameters are specified, query termserver lists all Terminal Servers within the current domain.

Security Restrictions
None.

524

QUERY USER
Use query to display information about users within the network.

Syntax
query user [ username | sessionname | sessionid ] [ /server:servername ] query user [/?]

Parameters
servername The name of a server within the farm. sessionname The name of a session, such as ica-tcp#7. sessionid The ID number of a session. username The name of a user connected to the farm.

Options
user username Displays connection information for the specified user name. user sessionname Displays connection information for the specified session name. user sessionid Displays connection information for the specified session ID.

525

QUERY USER user /server: servername Defines the server to be queried. The current server is queried by default. /? Displays the syntax for the utility and information about the utilitys options.

Remarks
If no parameters are specified, query user displays all user sessions on the current server. You can use quser as a shortened form of the query user command.

Security Restrictions
None.

526

Performance Counters Reference


Performance monitoring counters that directly relate to the performance of sessions, networking, and security are installed with XenApp. You can access these counters from the Performance Monitor, which is part of Windows operating systems. Use performance monitoring to obtain system performance data and the effects of configuration changes on system throughput. Using the standard Windows procedure, you can add and then view the following categories of XenApp-related counters, called performance objects in Performance Monitor:

Citrix CPU Utilization Mgmt User Citrix IMA Networking Citrix Licensing Citrix MetaFrame Presentation Server ICA Session Secure Ticket Authority

527

Citrix CPU Utilization Mgmt User Counters


The following counters are available through the Citrix CPU Utilization Mgmt User performance object in Performance Monitor. Counter CPU Entitlement CPU Reservation CPU Shares CPU Usage Long-term CPU Usage Description The percentage of CPU resource that Citrix CPU Utilization Management makes available to a user at a given time. The percentage of total computer CPU resource reserved for a user, should that user require it. The proportion of CPU resource assigned to a user. The percentage of CPU resource consumed by a user at a given time, averaged over a few seconds. The percentage of CPU resource consumed by a user, averaged over a longer period than the CPU Usage counter.

528

Citrix IMA Networking Counters


The following counters are available through the Citrix IMA Networking performance object in Performance Monitor.

Counter Bytes Received/sec Bytes Sent/sec Network Connections

Description The inbound bytes per second. The outbound bytes per second. The number of active IMA network connections to other IMA servers.

529

Citrix Licensing Counters


The following counters are available through the Citrix Licensing performance object in Performance Monitor.

Counter Average License Check-In Response Time (ms) Average License Check-Out Response Time (ms) Last Recorded License Check-In Response Time (ms) Last Recorded License Check-Out Response Time (ms) License Server Connection Failure Maximum License Check-In Response Time Maximum License Check-Out Response Time

Description The average license check-in response time in milliseconds. The average license check-out response time in milliseconds. The last recorded license check-in response time in milliseconds. The last recorded license check-out response time in milliseconds. The number of minutes that the XenApp server has been disconnected from the License Server. The maximum license check-in response time in milliseconds. The maximum license check-out response time in milliseconds.

530

Citrix MetaFrame Presentation Server Counters


The following counters are available through the Citrix MetaFrame Presentation Server performance object in Performance Monitor. Counter Application Enumeration/sec Application Resolution Time (ms) Application Resolutions Failed/sec Application Resolutions/sec DataStore Connection Failure DataStore bytes read DataStore bytes read/sec DataStore bytes written/sec DataStore reads DataStore reads/sec DataStore writes/sec DynamicStore bytes read/sec DynamicStore bytes written/sec DynamicStore Gateway Update Count DynamicStore Gateway Update, Bytes Sent DynamicStore Query Count DynamicStore Query Request, Bytes Received DynamicStore Query Response, Bytes Sent DynamicStore reads/sec Description The number of application enumerations per second. The time in milliseconds that a resolution took to complete. The number of application resolutions failed per second. The number of resolutions completed per second. The number of minutes that the XenApp server has been disconnected from the data store. The number of bytes read from the data store. The number of bytes of data store data read per second. The number of bytes of data store data written per second. The number of times data was read from the data store. The number of times data was read from the data store per second. The number of times data was written to the data store per second. The number of bytes of dynamic store data read per second. The number of bytes of dynamic store data written per second. The number of dynamic store update packets sent to remote data collectors. The number of bytes of data sent across gateways to remote data collectors. The number of dynamic store queries that were performed. The number of bytes of data received in dynamic store query request packets. The number of bytes of data sent in response to dynamic store queries. The number of times data was read from the dynamic store per second.

531

Citrix MetaFrame Presentation Server Counters DynamicStore Update Bytes Received DynamicStore Update Packets Received DynamicStore Update Response Bytes Sent DynamicStore writes/sec Filtered Application Enumerations/sec LocalHostCache bytes read/sec LocalHostCache bytes written/sec LocalHostCache reads/sec LocalHostCache writes/sec Maximum number of XML threads Number of busy XML threads Number of XML threads Resolution WorkItem Queue Executing Count Resolution WorkItem Queue Ready Count WorkItem Queue Executing Count WorkItem Queue Pending Count WorkItem Queue Ready Count Zone Elections The number of bytes of data received in dynamic store update packets. The number of update packets received by the dynamic store. The number of bytes of data sent in response to dynamic store update packets. The number of times data was written to the dynamic store per second. The number of filtered application enumerations per second. The number of bytes of IMA local host cache data read per second. The number of bytes of IMA local host cache data written per second. The number of times data was read from the IMA local host cache per second. The number of times data was written to the IMA local host cache per second. The maximum number of threads allocated to service Web-based sessions since the server restarted. The number of busy threads. The number of threads allocated to service Web-based sessions. The number of resolution work items that are currently being executed. The number of resolution work items that are ready to be executed. The number of work items that are currently being executed. The number of work items that are not yet ready to be executed. The number of work items that are ready to be executed. The number of zone elections that occurred. This value starts at zero each time the IMA Service starts and is incremented each time a zone election takes place. The number of times the server won a zone election.

Zone Elections Won

532

ICA Session Counters


The following counters are available through the ICA Session performance object in Performance Monitor.

Counter Input Audio Bandwidth Input Clipboard Bandwidth

Description The bandwidth, measured in bps, used when playing sound in an ICA session. The bandwidth, measured in bps, used when performing clipboard operations such as cut-and-paste between the ICA session and the local window. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client COM 1 port. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client COM 2 port. The bandwidth, measured in bps, used when sending data to the client COM port. The bandwidth, measured in bps, used when executing LongCommandLine parameters of a published application. The bandwidth, measured in bps, used when performing file operations between the client and server drives during an ICA session. The bandwidth, measured in bps, used when initiating font changes within a SpeedScreen-enabled ICA session. The bandwidth, measured in bps, used when streaming Flash data in an HDX-enabled session. The bandwidth, measured in bps, used to negotiate licensing during the session establishment phase. Often, no data for this counter is available, as this negotiation takes place before logon. The bandwidth on the virtual channel that prints to a client printer attached to the client LPT 1 port through an ICA session that does not support a spooler. This is measured in bps. The bandwidth on the virtual channel that prints to a client printer attached to the client LPT 2 port through an ICA session that does not support a spooler. This is measured in bps.

Input COM 1 Bandwidth

Input COM 2 Bandwidth

Input COM Bandwidth Input Control Channel Bandwidth Input Drive Bandwidth

Input Font Data Bandwidth Input HDX Mediastream for Flash Data Bandwidth Input Licensing Bandwidth

Input LPT 1 Bandwidth

Input LPT 2 Bandwidth

533

ICA Session Counters Input Printer Bandwidth The bandwidth, measured in bps, used when printing to a client printer through a client that has print spooler support enabled. The bandwidth, measured in bps, used for published applications that are not embedded in a session window. The bandwidth, measured in bps, used from client to server for a session. The compression ratio used from client to server for a session. The line speed, measured in bps, used from client to server for a session. The bandwidth, measured in bps, used from client to server for data channel traffic. The bandwidth, measured in bps, used for text echoing. The bandwidth, measured in bps, used from client to server for ThinWire traffic. The last recorded latency measurement for the session. The average client latency over the lifetime of a session. The difference between the minimum and maximum measured latency values for a session. The bandwidth, measured in bps, used for playing sound in an ICA session. The bandwidth, measured in bps, used for clipboard operations such as cut-and-paste between the ICA session and the local window. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client COM 1 port. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client COM 2 port. The bandwidth, measured in bps, used when receiving data from the client COM port. The bandwidth, measured in bps, used when executing LongCommandLine parameters of a published application. The bandwidth, measured in bps, used when performing file operations between the client and server drives during an ICA session. The bandwidth, measured in bps, used when initiating font changes within a SpeedScreen-enabled ICA session.

Input Seamless Bandwidth

Input Session Bandwidth Input Session Compression Input Session Line Speed Input SpeedScreen Data Channel Bandwidth Input Text Echo Bandwidth Input ThinWire Bandwidth Latency - Last Recorded Latency - Session Average Latency - Session Deviation Output Audio Bandwidth Output Clipboard Bandwidth

Output COM 1 Bandwidth

Output COM 2 Bandwidth

Output COM Bandwidth Output Control Channel Bandwidth Output Drive Bandwidth

Output Font Data Bandwidth

534

ICA Session Counters Output Licensing Bandwidth The bandwidth, measured in bps, used to negotiate licensing during the session establishment phase. Often, no data for this counter is available, as this negotiation takes place before logon. The bandwidth, measured in bps, used when streaming Flash data in an HDX-enabled session. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client LPT 1 port. The bandwidth, measured in bps, used when routing a print job through an ICA session that does not support a spooler to a client printer attached to the client LPT 2 port. The bandwidth, measured in bps, used when performing management functions. The bandwidth, measured in bps, used when printing to a client printer through a client that has print spooler support enabled. The bandwidth, measured in bps, used for published applications that are not embedded in a session window. The bandwidth, measured in bps, used from server to client for a session. The compression ratio used from server to client for a session. The line speed, measured in bps, used from server to client for a session. The bandwidth, measured in bps, used from server to client for data channel traffic. The bandwidth, measured in bps, used for text echoing. The bandwidth, measured in bps, used from server to client for ThinWire traffic. The total number of shares used by the session.

Output HDX Mediastream for Flash Data Bandwidth Output LPT 1 Bandwidth

Output LPT 2 Bandwidth

Output Management Bandwidth Output Printer Bandwidth

Output Seamless Bandwidth

Output Session Bandwidth Output Session Compression Output Session Line Speed Output SpeedScreen Data Channel Bandwidth Output Text Echo Bandwidth Output ThinWire Bandwidth Resource Shares

535

Secure Ticket Authority Counters


The following performance counters are available for the Secure Ticket Authority (STA). Performance Counter STA Bad Data Request Count STA Bad Refresh Request Count STA Bad Ticket Request Count STA Count of Active Tickets STA Good Data Request Count Description The total number of unsuccessful ticket validation and data retrieval requests during the lifetime of the STA. The total number of unsuccessful ticket refresh requests received during the lifetime of the STA. The total number of unsuccessful ticket generation requests received during the lifetime of the STA. Total count of active tickets currently held in the STA. The total number of successful ticket validation and data retrieval requests received during the lifetime of the STA. The total number of successful ticket refresh requests received during the lifetime of the STA. The total number of successful ticket generation requests received during the lifetime of the STA. The maximum rate of all monitored activities per second. The maximum rate of data requests per second during the lifetime of the STA. The maximum rate of refresh requests per second during the lifetime of the STA. The maximum rate of ticket generation requests per second during the lifetime of the STA. The total number of ticket time-outs that occur during the lifetime of the STA.

STA Good Refresh Request Count STA Good Ticket Request Count STA Peak All Request Rate STA Peak Data Request Rate STA Peak Ticket Refresh Rate STA Peak Ticket Request Rate STA Ticket Timeout Count

536

Policy Settings Reference


Policies contain settings that are applied when the policy is enforced. You configure these settings using the AppCenter or the Group Policy Management Editor, depending on whether or not you use Active Directory in your XenApp environment. The descriptions for each policy setting include the following information:
q

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

Important: If you use Windows PowerShell scripts to manage Citrix policies, be aware that the names and locations of some policy settings have changed in this version of XenApp. Although you can continue to use your existing scripts, you should verify the scripts reference the correct setting names and paths for this version of XenApp and update these references as appropriate. For more information about using PowerShell scripts to manage Citrix policies, refer to the XenApp PowerShell SDK available from the Citrix Developer Network Web site (http://community.citrix.com).

537

Policy Settings: Quick Reference Table


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.

Audio
To perform this task: Control whether or not to allow the use of multiple audio devices 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: Audio Plug N Play Client microphone redirection Audio quality Client audio redirection

Bandwidth for User Devices


To limit bandwidth used for: Client audio mapping
q

Use this policy setting: Audio redirection bandwidth limit, or Audio redirection bandwidth limit percent Clipboard redirection bandwidth limit, or Clipboard redirection bandwidth limit percent COM port redirection bandwidth limit, or COM port redirection bandwidth limit percent

Cut-and-paste using local clipboard


q

Devices connected to a local COM port


q

538

Policy Settings: Quick Reference Table Access in a session to local client drives
q

File redirection bandwidth limit, or File redirection bandwidth limit percent HDX MediaStream Multimedia Acceleration bandwidth limit, or HDX MediaStream Multimedia Acceleration bandwidth limit percent LPT port redirection bandwidth limit, or LPT port redirection bandwidth limit percent

HDX MediaStream Multimedia Acceleration


q

Printers connected to the client LPT port


q

Client session Printing

Overall session bandwidth limit


q

Printer redirection bandwidth limit, or Printer redirection bandwidth limit percent TWAIN device redirection bandwidth limit, or TWAIN device redirection bandwidth limit percent Client USB device redirection bandwidth limit, or Client USB device redirection bandwidth limit percent

TWAIN devices (such as a camera or scanner)


q

USB devices
q

Redirection of Client Drives and User Devices


To perform this task: Control whether or not drives on the user device are connected when users log on to the server Control cut-and-paste data transfer between the server and the local clipboard Control how drives map from the user device Use this policy setting: Auto connect client drives

Client clipboard redirection Client drive redirection

539

Policy Settings: Quick Reference Table 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 Client COM port redirection Client LPT port redirection

Client fixed drives, and Client drive redirection Client floppy drives, and Client drive redirection Client network drives, and Client drive redirection Client optical drives, and Client drive redirection Client removable drives, and Client drive redirection Client TWAIN device redirection TWAIN compression level Client USB device redirection, and Client USB device redirection rules

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

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

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

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

Control whether or not users' TWAIN devices, such as scanners and cameras, are available in a session and control compression of image data transfers Control whether or not USB devices are available in a session

Control whether or not Plug-and-Play USB devices, such as a camera or a point-of-sale device, are available in a session Improve the speed of writing and copying files to a client disk over a WAN

Client USB Plug and Play device redirection Use asynchronous writes

Content Redirection
To perform this task: Control whether or not to use content redirection from the server to the user device Use this policy setting: Host to client redirection

540

Policy Settings: Quick Reference Table

Graphics & Multimedia


To perform this 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 Lossy compression level Lossy compression level threshold value Progressive compression level Progressive compression threshold value Extra Color Compression, and Extra Color Compression Threshold Flash acceleration (legacy features with Citrix Online plug-in 12.1) Flash default behavior (second generation features with Citrix Receiver)

Control compression of images for use in sessions of limited bandwidth

Control image display optimization based on whether or not users reach a specified bandwidth threshold Control whether or not Flash content is rendered in sessions

Control whether or not to allow the use of legacy Flash acceleration for older versions of Citrix Receiver (fomerly Citrix Online plug-in) Control whether or not Web sites can display Flash content when accessed in sessions

Flash backwards compatibility

Flash server-side content fetching URL list Flash URL compatibility list

Enable color matching of Flash instances and the Web pages on which they appear within a session Control whether some Flash content is rendered automatically on the server when client-side rendering is either unnecessary or resource-intensive

Flash background color list

Flash intelligent fallback

541

Policy Settings: Quick Reference Table

Pre-launch and Lingering Sessions


To perform this task: Control the length of time sessions remain active after exiting applications Use this policy setting:
q

Linger Disconnect Timer Interval Linger Terminate Timer Interval Pre-launch Disconnect Timer Interval Pre-launch Terminate Timer Interval

Control the length of time pre-launched sessions are inactive before disconnecting or terminating

Prioritizing Multi-Stream Network Traffic


To perform this task: Specify ports for ICA traffic across multiple connections and establish network priorities Enable support for multi-stream connections between servers and user devices Use this policy setting: Multi-Port Policy Multi-Stream (Computer and User settings)

Printing
To perform this task: Control creation of client printers on the user device Use this policy setting:
q

Auto-create client printers, and Client printer redirection

Allow use of legacy printer names and preserve backward compatibility with prior versions 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

Client printer names

Printer properties retention Direct connections to print servers Client printer redirection Automatic installation of in-box printer drivers Universal print driver usage

542

Policy Settings: Quick Reference Table Choose a printer based on a roaming users session information Default printer

Security
To perform this task: Require that connections use a specified encryption level Use this policy rule: SecureICA minimum encryption level

User Connections and Shadowing


To perform this task: Limit the number of sessions that a user can run at the same time Control whether or not shadowing is allowed Allow or deny permission for users to shadow connections Use this policy setting: Concurrent logon limit Shadowing
q

Users who can shadow other users Users who cannot shadow other users

543

ICA Policy Settings


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


Applicable products: XenApp; XenDesktop 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


Applicable products: XenApp; XenDesktop This setting specifies the TCP/IP port number used by the ICA protocol on the server. The default port number is 1494. Valid port numbers 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 Receiver or plug-in that connects to the server.

Client clipboard redirection


Applicable products: XenApp; XenDesktop 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.

544

ICA Policy Settings

Desktop launches
Applicable products: XenApp This setting allows or prevents non-administrative users to connect to a desktop session on the server. By default, non-administrative users cannot connect to these sessions.

Launching of non-published programs during client connection


Applicable products: XenApp This setting specifies whether or not to launch initial applications or published applications through ICA or RDP on the server. By default, only published applications are allowed to launch.

545

Audio Policy Settings


The Audio section contains policy settings you can configure to permit user devices to send and receive audio in sessions without reducing performance.

Audio Plug N Play


Applicable products: XenApp This setting allows or prevents the use of multiple audio devices to record and play sound. By default, this setting is allowed.

Audio Quality
Applicable products: XenApp; XenDesktop This setting specifies the quality level of sound received in user sessions. By default, the sound quality is set to High - high definition audio. To control sound quality, choose one of the following options:
q

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. Select Medium - optimized for speech for most LAN-based connections. Sounds sent to the client are compressed up to 64 Kbps. 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.

Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the bandwidth consumption is doubled. To specify the maximum amount of bandwidth, configure the Audio redirection bandwidth limit or the Audio redirection bandwidth limit percent settings.

Client audio redirection


Applicable products: XenApp; XenDesktop 546

Audio Policy Settings 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. By default, redirection is allowed. 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.

Client microphone redirection


Applicable products: XenApp; XenDesktop This setting enables or disables client microphone redirection. When enabled, users can use microphones to record audio input in a session. By default, redirection is allowed. 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 Citrix Receiver. If the Client audio redirection setting is disabled on the user device, this rule has no effect.

547

Auto Client Reconnect Policy Settings


The Auto Client Reconnect section contains policy settings for controlling automatic reconnection of sessions. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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 Receiver's 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 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.

548

Bandwidth Policy Settings


The Bandwidth section contains policy settings you can configure to avoid performance problems related to client session bandwidth use. Important: Using these policy settings in conjunction with the Multi-Stream policy settings may produce unexpected results. If you use Multi-Stream settings in a policy, ensure these bandwidth limit policy settings are not included. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

Audio redirection bandwidth limit


This setting specifies the maximum allowed bandwidth in kilobits per second for playing or recording audio in a user session. By default, no maximum (zero) is specified. 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. By default, no maximum percentage (zero) is specified. 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.

Client USB device redirection bandwidth limit


This settings specifies the maximum allowed bandwidth, in kilobits per second, for the redirection of USB devices to and from the client (workstations hosts only) If you enter a value for this setting and a value for the Client USB device redirection bandwidth limit percent setting, the most restrictive setting (with the lower value) is applied.

549

Bandwidth Policy Settings

Client USB device redirection bandwidth limit percent


This setting specifies the maximum allowed bandwidth for the redirection of USB devices to and from the client (workstations hosts only) 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 Client USB 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.

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. By default, no maximum (zero) is specified. 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. By default, no maximum percentage (zero) is specified. 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. By default, no maximum (zero) is specified. 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.

550

Bandwidth Policy Settings

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. By default, no maximum percentage (zero) is specified. 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. By default, no maximum (zero) is specified. 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. By default, no maximum percentage (zero) is specified. 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.

HDX MediaStream Multimedia Acceleration bandwidth limit


This setting specifies the maximum allowed bandwidth limit in kilobits per second for delivering streaming audio and video using HDX MediaStream Multimedia Acceleration. By default, no maximum (zero) is specified. If you enter a value for this setting and a value for the HDX MediaStream Multimedia Acceleration bandwidth limit percent setting, the most restrictive setting (with the lower value) takes effect.

551

Bandwidth Policy Settings

HDX MediaStream Multimedia Acceleration bandwidth limit percent


This setting specifies the maximum allowed bandwidth for delivering streaming audio and video using HDX MediaStream Multimedia Acceleration. By default, no maximum (zero) is specified. If you enter a value for this setting and a value for the HDX MediaStream Multimedia Acceleration bandwidth limit setting, the most restrictive setting (with the lower value) takes effect. 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. By default, no maximum (zero) is specified. 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. By default, no maximum percentage (zero) is specified. 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. By default, no limit (zero) is specified. 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.

552

Bandwidth Policy Settings

Printer redirection bandwidth limit


This setting specifies the maximum allowed bandwidth in kilobits per second for accessing client printers in a user session. By default, no maximum (zero) is specified. 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. By default, no maximum percentage (zero) is specified. 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.

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.

553

Client Sensors Policy Settings


The Client Sensors section contains policy settings for controlling how mobile device sensor information is handled in a user session. These policy settings are applicable to the following Citrix products:
q

XenApp 6.5

Allow applications to use the physical location of the client device


This setting determines whether applications running in a XenApp session on a mobile device are allowed to use the physical location of the client device. By default, the use of location information is prohibited. When this setting is prohibited, attempts by an application to retrieve location information return a "permission denied" value. When this setting is allowed, a user can prohibit use of location information by denying a Receiver request to access the location. Android and iOS devices prompt at the first request for location information in each session. When developing hosted applications that use the Allow applications to use the physical location of the client device setting, consider the following:
q

A location-enabled application should not rely on location information being available because:
q

A user might not allow access to location information. The location might not be available or might change while the application is running.

A user might connect to the application session from a different device that does not support location information. A location-enabled application must:
q q

Have the location feature off by default. Provide a user option to allow or disallow the feature while the application is running.

Provide a user option to clear location data that is cached by the application. (Receiver does not cache location data.) A location-enabled application must manage the granularity of the location information so that the data acquired is appropriate to the purpose of the application and conforms to regulations in all relevant jurisdictions.
q

554

Client Sensors Policy Settings


q

A secure connection (for example, using SSL/TLS or a VPN) should be enforced when using location services. Citrix Receiver should connect to trusted servers. Consider obtaining legal advice regarding the use of location services.

555

Desktop UI Policy Settings


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:
q

XenApp XenDesktop

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.

556

End User Monitoring Policy Settings


The End User Monitoring section contains policy settings for measuring session traffic. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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.

557

File Redirection Policy Settings


The File Redirection section contains policy settings relating to client drive mapping and client drive optimization.

Auto connect client drives


Applicable products: XenApp; XenDesktop 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


Applicable products: XenApp; XenDesktop This setting enables or disables drive redirection to and from the user device. By default, file redirection is enabled. 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. Related Policy Settings

Client floppy drives

558

File Redirection Policy Settings


q

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

Client fixed drives


Applicable products: XenApp; XenDesktop 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.

Client floppy drives


Applicable products: XenApp; XenDesktop 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.

Client network drives


Applicable products: XenApp; XenDesktop 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 559

File Redirection Policy Settings drives setting. To ensure network drives are automatically connected when users log on, configure the Auto connect client drives setting.

Client optical drives


Applicable products: XenApp; XenDesktop 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.

Client removable drives


Applicable products: XenApp; XenDesktop 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.

Host to client redirection


Applicable products: XenApp This setting enables or disables file type associations for URLs and some media content to be opened on the user device. When disabled, content opens on the server. By default, file type association is disabled. These URL types are opened locally when you enable this setting:
q

Hypertext Transfer Protocol (HTTP) Secure Hypertext Transfer Protocol (HTTPS)

560

File Redirection Policy Settings


q

Real Player and QuickTime (RTSP) Real Player and QuickTime (RTSPU) Legacy Real Player (PNM) Microsofts Media Format (MMS)

Preserve client drive letters


Applicable to: XenDesktop 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.

Read-only client drive access


Applicable products: XenApp; XenDesktop This setting allows or prevents users and applications from creating or modifying files or folders on mapped client drives. By default, files and folders on mapped client drives can be modified. If set to Enabled, files and folders are accessible with read-only permissions. When adding this setting to a policy, make sure the Client drive redirection setting is present and set to Allowed.

Special folder redirection


Applicable products: XenApp This setting allows or prevents Citrix Receiver and Web Interface users to see their local Documents and Desktop special folders from a session. By default, special folder redirection is allowed. This setting prevents any objects filtered through a policy from having special folder redirection, regardless of settings that exist elsewhere. When you allow this setting, any related settings specified for the Web Interface or Citrix Receiver are ignored. To define which users can have special folder redirection, select Allowed and include this setting in a policy filtered on the users you want to have this feature. This setting overrides all other special folder redirection settings throughout XenApp.

561

File Redirection Policy Settings Because special folder redirection must interact with the user device, policy settings that prevent users from accessing or saving files to their local hard drives also prevent special folder redirection from working. If you enable the Special folder redirection setting, make sure the Client fixed drives setting is enabled as well. For seamless applications and seamless and published desktops, special folder redirection works for Documents and Desktops folders. Citrix does not recommend using special folder redirection with published Windows Explorer.

Use asynchronous writes


Applicable products: XenApp; XenDesktop 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.

562

Flash Redirection Policy Settings


The Flash Redirection section contains policy settings for handling Flash content in user sessions. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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. Note: This setting is used for legacy Flash redirection with Citrix online plug-in 12.1. When enabled, this setting reduces network and server load by rendering Flash content on the user device. Additionally, the Flash URL compatibility list setting forces Flash content from specific Web sites to be rendered on the server. On the user device, the Enable HDX MediaStream for Flash on the user device setting must be enabled as well. 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 URL compatibility list setting.

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

563

Flash Redirection Policy Settings

Flash backwards compatibility


This setting enables or disables the use of original, legacy Flash redirection features with older versions of Citrix Receiver (formerly the Citrix online plug-in). By default, this setting is enabled. On the user device, the Enable HDX MediaStream for Flash on the user device setting must be enabled as well. Second generation Flash redirection features are enabled for use with Citrix Receiver 3.0. Legacy redirection features are supported for use with the Citrix online plug-in 12.1. To ensure second generation Flash redirection features are used, both the server and the user device must have second generation Flash redirection enabled. If legacy redirection is enabled on either the server or the user device, legacy redirection features are used.

Flash default behavior


This setting establishes the default behavior for second generation Flash acceleration. By default, Flash acceleration is enabled. To configure this setting, choose one of the following options:
q

Enable Flash acceleration enables use of second generation features when both the server and the user device have second generation Flash redirection enabled. Legacy features are available when the Flash backwards compatibility setting is enabled. Block Flash Player prevents users from viewing Flash content. Second generation and legacy Flash redirection and server-side content rendering are not used. Disable Flash acceleration enables users to view Flash content rendered on the server, provided the Flash Player for Internet Explorer is installed on the server. Second generation and legacy Flash redirection is not used.

This setting can be overridden for individual Web pages and Flash instances based on the configuration of the Flash URL compatibility list setting. Additionally, the user device must have the Enable HDX MediaStream for Flash on the user device setting enabled.

Flash event logging


This setting enables or disables Flash events to be recorded in the Windows application event log. By default, logging is enabled. On computers running Windows 7 or Windows Vista, a Flash redirection-specific log appears in the Applications and Services Log node.

564

Flash Redirection Policy Settings

Flash intelligent fallback


This setting enables or disables automatic attempts to employ server-side rendering for Flash Player instances where client-side rendering is either unnecessary or provides a poor user experience. By default, this setting is enabled.

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, legacy Flash redirection 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. This setting is used for legacy Flash redirection with Citrix online plug-in 12.1. When adding this setting to a policy, ensure the Flash backwards compatibility setting is also added to the policy and enabled.

Flash server-side content fetching URL list


This setting specifies Web sites whose Flash content can be downloaded to the server and then transferred to the user device for rendering. By default, no sites are specified. This setting is used when the user device does not have direct access to the Internet; the server provides that connection. Additionally, the user device must have the Enable server-side content fetching setting enabled. Second generation Flash redirection includes a fallback to server-side content fetching for Flash .swf files. If the user device is unable to fetch Flash content from a Web site, and the Web site is specified in the Flash server-side content fetching URL list, server-side content fetching occurs automatically. When adding URLs to the list:
q

Add the URL of the Flash application instead of the top-level HTML page that initiates the Flash Player. Use an asterisk (*) at the beginning or end of the URL as a wildcard. Use a trailing wildcard to allow all child URLs (http://www.citrix.com/*). The prefixes http:// and https:// are used when present, but are not required for valid list entries.

565

Flash Redirection Policy Settings

Flash URL compatibility list


This setting specifies the rules which determine whether Flash content on certain Web sites are rendered on the user device, rendered on the server, or blocked from rendering. By default, no rules are specified. When adding URLs to the list:
q

Prioritize the list with the most important URLs, actions, and rendering locations at the top. Use an asterisk (*) at the beginning or end of the URL as a wildcard. Use a trailing wildcard to refer to all child URLs (http://www.citrix.com/*). The prefixes http:// and https:// are used when present, but are not required for valid list entries. Add to this list Web sites whose Flash content does not render correctly on the user device and select either the Render on Server or Block options.

566

Graphics Policy Settings


The Graphics section contains policy settings for controlling how images are handled in user sessions. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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 131072. 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. By default, color depth is degraded first. 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. To notify users when either color depth or resolution are degraded, configure the Notify user when display mode is degraded setting.

Dynamic Windows Preview


This setting enables or disables the display of seamless windows in Flip, Flip 3D, Taskbar Preview, and Peek window preview modes. By default, this setting is enabled.

567

Graphics Policy Settings

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.

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. By default, queuing and tossing is enabled. This improves response when graphics are sent to the user device. Configuring this setting can cause animations to become choppy due to dropped frames.

568

Caching Policy Settings


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:
q

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.

569

Keep Alive Policy Settings


The Keep Alive section contains policy settings for managing ICA keep-alive messages. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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.

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 keep-alive 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

570

Legacy Server Side Optimizations Policy Settings


The Legacy Server side optimizations section contains policy settings for handling Flash content on session hosts. These policy settings are applicable to XenApp.

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.

571

Mobile Experience Policy Settings


The Mobile Experience section contains policy settings for controlling interface behavior during a user session on a mobile device. These policy settings are applicable to the following Citrix products:
q

XenApp 6.5

Automatic keyboard display


This setting determines whether the mobile device keyboard opens when an editable field has the focus. By default, this setting is prohibited and a Receiver user must manually open the keyboard. When this setting is allowed:
q

The device keyboard automatically opens when an editable field has the focus. The desktop session scrolls if needed to make the input area visible. Users can change a Receiver for iOS session setting to prevent the keyboard from automatically opening. If this feature is problematic for an application, put the application in an exclusion list to disable the feature for it. For information, see "To configure the CtxUiMon exclusion list" later in this topic.

This setting has been tested with Microsoft Office applications, Internet Explorer, and various native Windows applications. Before deploying this feature, be sure to verify it with the hosted applications in your environment.

Launch touch-optimized desktop


This setting determines whether Receiver uses a touch-optimized desktop for mobile devices. By default, this setting is allowed. When this setting is allowed, Receiver users can click the icon in the top right corner of the desktop to toggle between the touch-optimized and Windows desktops. When this setting is prohibited, Receiver only uses the traditional Windows interface.

572

Mobile Experience Policy Settings

Remote the combo box


This setting determines whether the device-native combo box opens when the user clicks a Windows combo box control. By default, this setting is prohibited and only the Windows combo box opens. When this setting is allowed:
q

The device-native combo box opens. The Windows combo box also opens, but is inactive. Users can change a Receiver for iOS session setting to prevent the display of the device-native combo box. If this feature is problematic for an application, put the application in an exclusion list to disable the feature for it. For information, see "To configure the CtxUiMon exclusion list" later in this topic.

This setting has been tested with Microsoft Office applications, Internet Explorer, and various native Windows applications. Before deploying this feature, be sure to verify it with the hosted applications in your environment.

To configure the CtxUiMon exclusion list


The automatic keyboard and mobile combo box features can be problematic for some applications. For example, when the automatic keyboard feature is enabled, a tap of the Windows Start menu icon places the focus in the Start menu search box, causing the keyboard to open. That behavior is prevented by including explorer.exe in the CtxUiMon exclusion list. Several applications, such as explorer.exe, are added to the exclusion list by default. A change to the exclusion list requires an edit to the registry of the XenApp server. 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.
q

For the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxUiMon Add the entry named Exclude with a string value containing a list of application file names, delimited by semi-colons. Example: explorer.exe;myapp.exe

573

Multimedia Policy Settings


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:
q

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:
q

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.

Windows Media Redirection


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. Windows Media redirection optimizes multimedia files that are encoded with codecs that adhere to Microsofts DirectShow, DirectX Media Objects (DMO), and Media Foundation

574

Multimedia Policy Settings 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 Citrix Receiver. 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 Receiver interface. Select Prohibited only if playing media using Windows Media redirection 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.

Windows Media Redirection Buffer Size


This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size is 5 seconds.

Windows Media Redirection Buffer Size Use


This setting enables or disables using the buffer size specified in the Windows Media Redirection Buffer Size setting. By default, the buffer size specified is not used. If this setting is disabled or if the Windows Media Redirection Buffer Size setting is not configured, the server uses the default buffer size value (5 seconds).

575

Multi-Stream Connections Policy Settings


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:
q

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 ports, you can assign the following priorities:
q

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.

576

Multi-Stream Connections Policy Settings When configuring this setting, reboot the server to ensure changes take effect. Important: Using this policy setting in conjunction with bandwidth limit policy settings such as Overall session bandwidth limit may produce unexpected results. When including this setting in a policy, ensure that bandwidth limit settings are not included.

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. Important: Using this policy setting in conjunction with bandwidth limit policy settings such as Overall session bandwidth limit may produce unexpected results. When including this setting in a policy, ensure that bandwidth limit settings are not included.

577

Port Redirection Policy Settings


The Port Redirection section contains policy settings for client LPT and COM port mapping. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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.

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

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

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.

578

Port Redirection Policy Settings Related Policy Settings

LPT port redirection bandwidth limit LPT port redirection bandwith limit percent

579

Printing Policy Settings


The Printing section contains policy settings for managing client printing. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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:
q

The first printer added locally to the Windows server in Control Panel > Devices and 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.

580

Printing Policy Settings 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 print driver usage setting to Use universal printing only or Use universal printing only if requested driver is unavailable.

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.

581

Client Printers Policy Settings


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. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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:
q

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

Auto-create generic universal printer


This setting enables or disables autocreation of the generic Citrix UNIVERSAL Printer object for sessions where a user device compatible with Universal Printing is in use. By default, the generic Universal Printer object is not autocreated. Related Policy Settings
q

Universal print driver usage

582

Client Printers Policy Settings


q

Universal driver preference

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. Related Policy Settings
q

Auto-create client printers

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. You can enable 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. You can disable direct connections if the network is across a WAN or has substantial latency or limited bandwidth. Print jobs are routed through the user device where they are redirected to the network print server. 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 driver mapping and compatibility


This setting specifies the driver substitution rules for autocreated client printers. By default, no rules are specified. When you define driver substitution rules, you can allow or prevent printers to be created with the specified driver. Additionally, you can allow created printers to use only universal print drivers. Driver substitution overrides or maps printer driver names the user device 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. 583

Client Printers Policy Settings You can add a driver mapping, edit an existing mapping, override custom settings for a 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.

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:
q

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 online plug-in versions 9.x, 10.x, 11.x, and 12.x, or Citrix Receiver 13.x. 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 user 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. 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. Do not retain printer properties prevents storing printer properties.

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 Auto-create client printers setting. Restored printers are printers fully customized by an administrator, with a saved state that is permanently attached to a client port.

584

Drivers Policy Settings


The Drivers section contains policy settings related to printer drivers. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

Automatic installation of in-box printer drivers


This setting enables or disables the automatic installation of printer drivers from the Windows in-box driver set or from driver packages staged on the host using pnputil.exe /a. By default, these drivers are installed as needed.

Universal driver preference


This setting specifies the order in which universal printer drivers are used, beginning with the first entry in the list. By default, the preference order is as follows:
q

EMF XPS PCL5c PCL4 PS

You can add, edit, or remove drivers, and change the order of drivers in the list.

Universal print driver usage


This setting specifies when to use universal printing. By default, universal printing is used only if the requested driver is unavailable. Universal printing employs generic printer drivers instead of standard model-specific drivers, potentially simplifying the burden of driver management on host computers. The availability of universal print drivers depends on the capabilities of the user device, host, and print server software. In certain configurations, universal printing might not be available.

585

Drivers Policy Settings When adding this setting to a policy, select an option:
q

Use only printer model specific drivers specifies that the client printer use only the standard model-specific drivers that are auto-created at logon. If the requested driver is unavailable, the client printer cannot be auto-created. Use universal printing only specifies that no standard model-specific drivers are used. Only universal print drivers are used to create printers. Use universal printing only if requested driver is unavailable uses standard model-specific drivers for printer creation 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 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 model-specific printer driver.

Related Policy Settings


q

Auto-create generic universal printer

586

Universal Printing Policy Settings


The Universal Printing section contains policy settings for managing universal printing. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

Universal printing EMF processing mode


This setting controls the method of processing the EMF spool file on the Windows user device. By default, EMF records are spooled directly to the printer. When adding this setting to a policy, select an option:
q

Reprocess EMFs for printer forces the EMF spool file to be reprocessed and sent through the GDI subsystem on the user device. You can use this setting for drivers that require EMF reprocessing but that might not be selected automatically in a session. Spool directly to printer, when used with the Citrix Universal Printer driver, ensures the EMF records are spooled and delivered to the user device for processing. Typically, these EMF spool files are injected directly to the client's spool queue. For printers and drivers that are compatible with the EMF format, this is the fastest printing method.

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:
q

No compression Best quality (lossless compression) High quality Standard quality Reduced quality (maximum compression)

587

Universal Printing Policy Settings When adding this setting to a policy that includes the Universal printing optimization defaults setting, be aware of the following items:
q

If the compression level in the Universal printing image compression limit setting is lower than the level defined in the Universal printing optimization defaults setting, images are compressed at the level defined in the Universal printing image compression limits setting. If compression is disabled, the Desired image quality and Enable heavyweight compression options of the Universal printing optimization defaults setting have no effect in the policy.

Universal printing optimization defaults


This setting specifies the default values for printing optimization when the Universal Printer driver is created for a session.
q

Desired image quality 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. However, the Universal printing image compression limit setting overrides the default setting. For example, if the default setting is set to Best Quality and the Universal printing image compression limit setting is set to Standard Quality, users can only print images using standard or reduced quality compression. Enable heavyweight compression 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 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 sent to the printer only once. By default, embedded images and fonts are cached. Note that these settings apply only if the user device supports this behavior. Allow non-administrators to modify these settings specifies whether or not users can change the default print optimization settings within a session. By default, users are not allowed to change the default print optimization settings.

Note: These options are supported for EMF printing. For XPS printing, only the Desired image quality option is supported.

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. When adding this setting to a policy, select an option:
q

Do not use print preview for auto-created or generic universal printers

588

Universal Printing Policy Settings


q

Use print preview for auto-created printers only Use print preview for generic universal printers only Use print preview for both auto-created and generic universal printers

Related Policy Settings


q

Universal print driver usage

Universal printing print quality limit


This setting specifies the maximum dots per inch (dpi) available for generating printed output in the session. By default, No Limit is enabled, meaning users can select the maximum print quality allowed by the printer to which they connect. If this setting is configured, it limits the maximum print quality available to users in terms of output resolution. 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 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:
q

Draft (150 DPI) Low Resolution (300 DPI) Medium Resolution (600 DPI) High Resolution (1200 DPI) No limit

589

Security Policy Settings


The Security section contains policy settings for configuring session encryption and password requirements. These policy settings are applicable to XenApp only.

Prompt for password


This setting requires the user to enter a password for all server connections regardless of access scenario. By default, users are prompted for passwords only for specific types of connections.

SecureICA minimum encryption level


This setting specifies the minimum level at which to encrypt session data sent between the server and a user device. When adding this setting to a policy, select an option:
q

Basic encrypts the client connection using a non-RC5 algorithm. It protects the data stream from being read directly, but it can be decrypted. By default, the server uses Basic encryption for client-server traffic. RC5 (128 bit) logon only encrypts the logon data with RC5 128-bit encryption and the client connection using Basic encryption. RC5 (40 bit) encrypts the client connection with RC5 40-bit encryption. RC5 (56 bit) encrypts the client connection with RC5 56-bit encryption. RC5 (128 bit) encrypts the client connection with RC5 128-bit encryption.

The settings you specify for client-server encryption can interact with any other encryption settings in XenApp and your Windows operating system. If a higher priority encryption level is set on either a server or user device, settings you specify for published resources can be overridden. You can raise encryption levels to further secure communications and message integrity for certain users. If a policy requires a higher encryption level, Receivers using a lower encryption level are denied connection. SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for your server farm, use SecureICA with SSL/TLS encryption.

590

Security Policy Settings SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server and Receivers to avoid using SecureICA.

591

Server Limits Policy Settings


The Server Limits section contains policy settings for controlling idle connections. These policy settings are applicable to XenApp only.

Server idle timer interval


This setting determines, in milliseconds, how long an uninterrupted user session will be maintained if there is no input from the user. By default, idle connections are not disconnected (Server idle timer interval = 0).

592

Session Limits Policy Settings


The Session Limits section contains policy settings you can use to control the number of connections users can make and how long sessions remain connected before they are forced to log off. These settings are applicable to XenApp only.

Concurrent logon limit


This setting specifies the maximum number of connections a user can make to the server farm at any given time. The users active and disconnected sessions are counted for the users total number of concurrent connections. This setting reduces the number of client connection licenses in use and conserves resources. By default, there is no limit on concurrent connections. Related Policy Settings

Limits on administrator sessions Limit user sessions

Linger Disconnect Timer Interval


This setting specifies the number of minutes after the last application exits to disconnect an existing session. By default, no (zero) minutes are specified; therefore, the session is not disconnected until the user logs off. To configure this setting, use any positive number. Once disconnected, the XenApp license is released. If the user launches an application before the timer interval expires, the Linger Disconnect timer resets.

Linger Terminate Timer Interval


This setting specifies the number of minutes after the last application exits to terminate an existing session. By default, no (zero) minutes are specified; therefore, session lingering is disabled. To configure this setting, use any positive number. If the user launches an application before the timer interval expires, the Linger Terminate timer resets.

593

Session Limits Policy Settings

Pre-launch Disconnect Timer Interval


This setting specifies the number of minutes to disconnect an existing pre-launched session. By default, sessions are disconnected after 60 minutes. To configure this setting, use any positive number. Once disconnected, the XenApp license is released. If the user launches an application before the timer expires, the application is launched in the existing session.

Pre-launch Terminate Timer Interval


This setting specifies the number of minutes to terminate an existing pre-launched session. By default, sessions are terminated after 60 minutes. To configure this setting, use any positive number. If the user launches an application before the timer expires, the session is reconnected, if necessary. The application launches in the existing session. If the timer interval is set to zero, pre-launched sessions are terminated immediately.

594

Session Reliability Policy Settings


The Session Reliability section contains policy settings for managing session reliability connections. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

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.

595

Session Reliability Policy Settings

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.

596

Shadowing Policy Settings


The Shadowing section contains policy settings related to user-to-user shadowing. Shadowing is useful for training purposes and for viewing presentations. You can also allow help desk personnel to shadow users so they can troubleshoot user problems. These policy settings are applicable to XenApp only.

Input from shadow connections


This setting allows or prevents shadowing users to take control of the keyboard and mouse of the user being shadowed during a shadowing session. By default, the person shadowing can send input to the session being shadowed.

Log shadow attempts


This setting allows or prevents recording of attempted shadowing sessions in the Windows event log. By default, shadowing attempts are logged. Several different event types are recorded in the Windows Event log. These include user shadowing requests, such as when users stop shadowing, failure to launch shadowing, and access to shadowing denials.

Notify user of pending shadow connections


This setting allows or prevents shadowed users from receiving notification of shadowing requests from other users. When a user receives a shadowing request, the user can accept or deny the request. By default, users are notified of shadowing requests.

Shadowing
This setting allows or prevents users from shadowing other users sessions. By default, administrators can shadow users sessions. When you add this setting to a policy, specify the users allowed to shadow by configuring the Users who can shadow other users and Users who cannot shadow other users policy settings. Session shadowing monitors and interacts with user sessions. When you shadow a user session, you can view everything that appears on the users session display. You can also use your keyboard and mouse to remotely interact with the user session.

597

Shadowing Policy Settings Shadowing is protocol-specific. This means you can shadow ICA sessions over ICA and Remote Desktop Protocol (RDP) sessions over RDP only. Shadowing restrictions are set at install time and are permanent. If you enable or disable shadowing, or certain shadowing features during Setup, you cannot change these restrictions later. You must reinstall XenApp on the server to change shadowing restrictions. Any user policies you create to enable user-to-user shadowing are subject to the restrictions you place on shadowing during Setup.

Users who can shadow other users


This setting specifies the users who are allowed to shadow other users. By default, no users are specified. When added to an unfiltered policy, this setting enables the specified users to shadow all other users. When a filter is applied, the specified users can initiate shadowing sessions under the conditions specified by the filter. For example, the Sales Manager is allowed to shadow users from the office, but not when working from home. The Sales Manager is added to the Users who can shadow other users setting and a Client IP Address filter is applied that allows connections from 10.8.169.* (the corporate network). When the Sales Manager logs on to the XenApp farm from home, the ability to initiate shadowing sessions is not available.

Users who cannot shadow other users


This setting specifies the users who are not allowed to shadow other users. By default, no users are specified. This setting overrides the Users who can shadow other users setting under the following conditions:
q

Both this setting and the Users who can shadow other users setting are added to the same policy and enabled. The same user is specified in both settings.

When added to an unfiltered policy, this setting prevents the specified users from initiating shadowing sessions with all other users. However, when a filter is applied, the specified users can initiate shadowing sessions only under the conditions specified by the filter. For example, the Sales Manager is allowed to shadow only the users in the US Sales department. The Sales Manager is added to the Users who cannot shadow other users setting and a User filter is applied that specifies the users in the Sales-US group. When the Sales Manager logs on to the XenApp farm and initiates a shadowing session, the Sales Manager can select only US Sales employees. The Sales Manager cannot initiate shadowing sessions with anyone else in the company.

598

Time Zone Control Policy Settings


The Time Zone Control section contains policy settings related to using local time in sessions.

Estimate local time for legacy clients


Applicable to: XenApp This setting enables or disables estimating the local time zone of user devices that send inaccurate time zone information to the server. By default, the server estimates the local time zone when necessary.

Use local time of client


Applicable to: XenApp; XenDesktop This setting determines the time zone setting of the user session. When this setting is used with XenApp, the servers time zone is used for the session by default. When used with XenDesktop, the time zone of the user's session is used by default. For this setting to take effect, enable the Allow time zone redirection setting in the Remote Desktop Session Host node of the Group Policy Management Editor (Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection). For more information about time zone redirection, refer to the Citrix Knowledge Center.

599

TWAIN Devices Policy Settings


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. Related Policy Settings

TWAIN compression level TWAIN device redirection bandwidth limit TWAIN device redirection bandwidth limit percent

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, medium compression is applied.

600

USB Devices Policy Settings


The USB devices section contains policy settings for managing file redirection for USB devices.

Client USB device redirection


Applies to: XenApp; XenDesktop 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


Applies to: XenApp; XenDesktop This setting specifies redirection rules for USB devices. By default, no rules are specified. 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:

Tag Name VID PID REL Class SubClass Prot

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 from either the device descriptor or an interface descriptor

Protocol from either the device descriptor or an interface descriptor When creating new policy rules, be aware of the following:
q

Rules are case-insensitive.

601

USB Devices Policy Settings


q

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.

Client USB Plug and Play device redirection


Applies to: XenApp This setting allows or prevents plug-and-play devices such as cameras or point-of-sale (POS) devices to be used in a client session. By default, plug-and-play device redirection is allowed. When set to Allowed, all plug-and-play devices for a specific user or group are redirected. When set to Prohibited, no devices are redirected.

602

Visual Display Policy Settings


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.

603

Moving Images Policy Settings


The Moving Images section contains settings that enable you to remove or alter compression for dynamic images. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

Progressive compression level


This setting provides a less detailed but faster initial display of images. By default, no progressive compression is applied. 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. 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:
q

Progressive compression threshold value Lossy compression level Progressive heavyweight compression

Progressive compression threshold value


This setting represents 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 2147483647 kilobits per second.

604

Still Images Policy Settings


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. These policy settings are applicable to the following Citrix products:
q

XenApp XenDesktop

Extra Color Compression


This setting enables or disables the use of extra color compression on images delivered over client connections that are limited in bandwidth, improving responsiveness by reducing the quality of displayed images. By default, this setting is disabled. 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.

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 8192 kilobits per second.

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, heavyweight compression is disabled. If enabled, heavyweight compression applies to all lossy compression settings. It is supported on Citrix Receiver but has no effect on other plug-ins. Related Policy Settings

Progressive compression level

605

Still Images Policy Settings

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

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

606

Licensing Policy Settings


The Licensing section contains policy settings for configuring Citrix Licensing. These policy settings are applicable to XenApp.

License server host name


This setting specifies the name of the server hosting XenApp licenses. By default, no host name is specified. If you decide to change the license server name, ensure that a license server with the new name already exists on your network. Because license files are tied to the license servers host name, you must download a license file that is generated for the new license server if you decide to change the servers name. This may involve returning and reallocating the licenses.

License server port


This setting specifies the port number of the server hosting XenApp licenses. By default, port 27000 is specified. If you change the port number of the license server, specify a new number in all the license files on the server.

607

Power and Capacity Management Policy Settings


The Power and Capacity Management section contains policy settings for managing Power and Capacity Management agents. These policy settings are applicable to XenApp.

Farm name
This setting specifies the name of the collection of XenApp servers managed by Power and Capacity Management. By default, no farm name is specified. Valid farm names are unique and may contain up to 80 characters. They do not contain backslashes (\), single quotes ('), forward slashes (/), double-quotes ("), less-than (<), greater than (>), backticks (`), pipes (|), or equal signs (=). Additionally, the Value box cannot be null and a valid entry cannot consist of spaces. If Use default value is selected when configuring this setting, the XenApp Power and Capacity Management Agent service does not start.

Workload name
This setting specifies the name of the logical grouping of XenApp servers that host the same application or set of applications. By default, the workload name is Unassigned. If this setting is added to a policy with either the Unassigned value or an invalid value, neither power management nor load consolidation can be enabled. Valid workload names can be up to 80 characters. Additionally, the Value box cannot be null and a valid entry cannot consist of spaces.

608

Server Policy Settings


The Server Settings section contains policy settings for configuring access control, DNS address resolution, icon handling, and XenApp product information for licensing. These policy settings are applicable to XenApp.

Connection access control


This setting specifies the types of client connections from which users can start sessions. When adding this setting to a policy, select an option:
q

Any connections (selected by default) allows access to published applications through any connection. Citrix Access Gateway, Citrix Receiver, and Web Interface connections only allows access to published applications through the listed connections, including any version of Access Gateway. This option denies access through any other connection. Citrix Access Gateway connections only allows access to published applications only through Access Gateway Advanced Edition servers (Version 4.0 or later).

DNS address resolution


This setting enables or disables the server to return fully qualified domain names (FQDN) to clients using the Citrix XML Service. By default, the server does not use the XML Service to return FQDNs. DNS address resolution works only in server farms that contain servers running MetaFrame XP Feature Release 1 or later, and clients must be using Presentation Server Client Version 6.20.985 or later or Citrix XenApp Plugin for Hosted Apps version 11.x.

Full icon caching


This setting enables or disables the caching of larger, high resolution published application icons on farm servers. By default, icons are cached. To ensure only specific farm servers are affected by this setting, configure a worker group that includes only the servers you specify. Then, include the worker group in the filter you add to the policy. If no filter is specified, this setting affects all farm servers.

609

Server Policy Settings Consider disabling this setting if caching icons impacts performance of the server. However, do not disable this setting on servers acting as XML brokers for the farm.

Initial Zone Name


This setting specifies the name of the zone assigned to the XenApp server when joining a farm. By default, the Default zone is specified. If the setting is read by a server in controller mode and the specified zone name does not exist in the farm, the server creates the zone. If the setting is read by a server in session-only mode, the specified zone must exist in the farm before the server attempts to join. If the XenApp server is already joined to a farm, the setting has no effect.

Load Evaluator Name


This setting specifies the name of the load evaluator to be assigned to servers in a XenApp farm. By default, no load evaluator names are specified. You can specify load evaluators stored on the local XenApp server or on a XenApp server in another farm. To retrieve a list of the load evaluators available, click Retrieve List and enter the computer name of the farm server you want to use. When a load evaluator name is specified, XenApp does not validate the name at the time the policy setting is added. XenApp, however, does attempt to locate the name in the farm data store when attempting to calculate load. If XenApp cannot locate the load evaluator name specified in the policy, XenApp registers an error in the Windows Event Log and the affected servers register full loads. Additionally, the affected servers stop accepting new connection requests until a valid load evaluator name is specified. If this setting is added to a policy and the policy is later renamed or deleted, XenApp uses the Default load evaluator to calculate load.

XenApp product edition


This setting specifies the XenApp product edition. By default, the Platinum edition is specified. Setting the product edition activates the features available with a particular edition. The product edition also determines which type of license a server requests from the license server. Make sure the edition you set matches the licenses that are installed.

610

Server Policy Settings

XenApp product model


This setting specifies the product model to be activated based on the license stored on the Citrix Licensing Server. By default, the XenApp product model is specified. The product model determines the type of license the XenApp server requests from the Licensing Server. When you configure this setting, ensure the product model you select matches the licenses that are installed. After you configure this setting, restart the server so that the appropriate license is applied to the installation.

611

Connection Limits Policy Settings


The Connection Limits section contains policy settings for controlling user and administrator sessions and logon event logging. These policy settings are applicable to XenApp.

Limit user sessions


This setting specifies the maximum number of connections that users can establish, in the range 0-8192. A value of 0 indicates no connections. By default, the limit is 2147483647. When a user tries to establish a connection in excess of this limit, a message tells the user the connection is not allowed. When a connection request is denied, the server records the users name and time in the System log. Related Policy Settings: Concurrent logon limit

Limits on administrator sessions


This setting enables or disables connection limit enforcement for Citrix administrators. Limiting connections for Citrix administrators can adversely affect their ability to shadow other users. By default, administrators are exempt from connection limits.

Logging of logon limit events


This setting enables or disables the logging of events (to the server event log) about connection attempts that were denied because they exceeded logon limits. By default, these events are not logged.

612

Database Policy Settings


The Database Settings section contains policy settings for specifying the database connections used when servers join a farm. These policy settings are applicable to XenApp.

Initial Database Name


This setting specifies the name of the database used when a XenApp server is joined to a farm. By default, the database name is not specified. When you specify an initial database name, the value is placed in the ODBC DSN file on the XenApp server. If you use the Server Configuration tool to define the database name, this setting has no effect. Note: If you are using an Oracle database for the farm data store, this setting is not used; only the Initial Database Server Name setting value is used.

Initial Database Server Name


This setting specifies the name of the server hosting the farm database. By default, no database server is specified. When you specify an initial database server name, the value is placed in the ODBC DSN file on the XenApp server. If you use the XenApp Server Configuration tool to define the database server name, this setting has no effect. If you are using an Oracle database for the farm data store, and you want to use this policy setting, follow the procedure described in Approach 3 of the topic "Preparing for XenApp 6 Imaging and Provisioning" to capture an image after XenApp installation, configuration, and restart. Select the Clear database location settings from this server checkbox. After you capture an image of the server, edit the Citrix Initial Database Server name Computer policy setting with the Oracle database server name, and then apply the policy. When the image reboots, it will look in that policy for the initial database server name.

Initial Failover Partner


This setting specifies the name of the database server to be used in the event the primary database server is unavailable. By default, no value is specified. When you specify a failover database server, the value is placed in the ODBC DSN file on the XenApp server. This setting is applicable only to farms that use Microsoft SQL Server for the data store. 613

Database Policy Settings

614

Health Monitoring and Recovery Policy Settings


The Health Monitoring and Recovery section contains policy settings for configuring Health Monitoring and Recovery tests and server load balancing exclusions. These policy settings are applicable to XenApp.

Health monitoring
This setting allows or prevents running Health Monitoring and Recovery tests on the farm servers. By default, Health Monitoring and Recovery tests are allowed to run.

Health monitoring tests


This setting specifies which Health Monitoring tests to run. You can add or remove tests. You can also edit the configuration of a test (name, location, description, interval, threshold, time-out and recovery action). By default, the following Citrix tests are run:

Test Name Citrix IMA Service Test Logon Monitor Test Ticketing Test

Default Interval (seconds) 60 1 60

Default Threshold 5 5 5

Default Recovery Action Alert Only Alert Only Prohibit logons and connections to the server Alert Only

Terminal Services Test

60

Maximum percent of servers with logon control


This setting specifies the maximum percent of servers on which Health Monitoring and Recovery can prohibit logons. By default, logons are prohibited on ten percent of servers. When the specified percentage of servers are either offline or are configured to prohibit logons, the Prohibit logons and connections to the server recovery action has no effect. To ensure prompt recovery, apply the same limit to all servers in the farm.

615

Memory Optimization Policy Settings


The Memory/CPU section contains policy settings for managing CPU utilization and memory optimization. These policy settings are applicable to XenApp.

CPU management server level


This setting specifies the level of CPU utilization management on the server. Managing CPU resources can normalize CPU peaks and reduce the resources required to handle CPU spikes. By default, CPU utilization is not managed. When adding this setting to a policy, select an option:
q

No CPU utilization management disables CPU utilization management on the server. Fair sharing of CPU between sessions ensures that CPU resources are equitably shared among users by having the server allocate an equal share of CPU to each user. Preferential Load Balancing allocates more CPU resources to one user over another based on the resource allotment for each session. The resource allotment is determined by the importance levels of both the published application running in the session and the session itself.

Note: To use CPU Utilization Management, ensure the Fair Share CPU Scheduling (DFSS) feature of Remote Desktop Services is disabled on the server. Related Policy Settings: Session importance

Memory optimization
This setting enables or disables memory optimization. Enabling memory optimization improves the ability to manage DLL allocation in both real and overall virtual memory by creating shared DLLs for applications that are open in multiple sessions. By default, this setting is disabled.

Memory optimization application exclusion list


This setting specifies the applications that memory optimization should ignore. By default, no applications are specified.

616

Memory Optimization Policy Settings

Memory optimization interval


This setting specifies the interval for running memory optimization. By default, memory optimization runs daily. When adding this setting to a policy, make sure the Memory optimization setting is present and set to Enabled.

Memory optimization schedule: day of month


This setting specifies the day of the month that memory optimization runs, in the range 1-31. By default, memory optimization is scheduled for the first day of each month. When adding this setting to a policy, make sure the following policy settings are present:
q

Memory optimization, set to Enabled Memory optimization interval, set to Monthly

If the specified day does not occur in a given month (for example, the 30th day in February, or the 31st day in April or June), memory optimization does not run in that month.

Memory optimization schedule: day of week


This setting specifies the day of the week that memory optimization runs. By default, memory optimization runs on Sundays. When adding this setting to a policy, make sure the following policy settings are present:
q

Memory optimization, set to Enabled Memory optimization interval, set to Weekly

Memory optimization schedule: time


This setting specifies the time at which memory optimization runs. The time format is H:MM TT, where H is the hour, MM is the minute, and TT is the time of day (AM or PM). By default, memory optimization runs at 3:00 AM. When adding this setting to a policy, make sure the following policy settings are present:
q

Memory optimization, set to Enabled Memory optimization interval, set to Daily, Weekly,or Monthly

Memory optimization times are scheduled in the local time zone of the server and use a 12-hour clock. If you enter a time according to a 24-hour clock, the time is converted 617

Memory Optimization Policy Settings automatically to a 12-hour clock. If you enter a time without a TT value, the time defaults to AM.

618

Offline Applications Policy Settings


The Offline Applications section contains policy settings for controlling offline application access, licensing, and logging. These policy settings are applicable to XenApp.

Offline app client trust


This setting enables or disables the ability of offline application clients to recreate sessions when reconnecting, without authenticating again. By default, users must authenticate when reconnecting to offline applications.

Offline app event logging


This setting enables or disables logging of offline application events to the event log on the server. By default, offline application events are not logged.

Offline app license period


This setting specifies the number of days applications can work offline before users have to renew the license. The license period, 21 days by default, can range from 2 to 365 days. Licenses automatically renew at login and every day while logged in. Changes to the license period occur when the license is renewed. To configure licenses, administrators can use the License Administration Console or command-line tools. They must also ensure they have a sufficient number of licenses to support the total number of users with offline access permission.

Offline app users


This setting specifies the users who have permission to access offline applications. You can add or delete users from this list. By default, no users are specified. Users in this group can continue using configured applications after disconnecting from the network for the number of days specified in the Offline app license period setting. You must configure the applications for offline access in the application properties. The total number of users with offline access permission should not exceed the total number of licenses available for offline access.

619

Reboot Behavior Policy Settings


The Reboot Behavior section contains policy settings for scheduling server restarts, disabling logons, and configuring warning messages. These policy settings are applicable to XenApp, Enterprise and Platinum editions only.

Reboot custom warning


This setting enables or disables sending a custom warning message (in addition to the standard restart message) to users before a scheduled server restart. To specify the text for this warning, configure the Reboot custom warning text setting. By default, only the standard warning message is sent.

Reboot custom warning text


This setting specifies the text in the custom warning message sent to users before a scheduled server restart. By default, no message text is specified. To send a custom message, the Reboot custom warning setting must be enabled.

Reboot logon disable time


This setting specifies the number of minutes before a scheduled server restart that logons to the server are disabled. By default, logons are disabled 60 minutes prior to server restart.

Reboot schedule frequency


This setting specifies the frequency, in days, that scheduled server restarts occur. By default, scheduled restarts occur every 7 days (once each week).

Reboot schedule randomization interval


This setting specifies the interval, in minutes, in which servers are restarted before or after the scheduled restart time. This interval prevents all servers in the farm from restarting simultaneously. By default, the setting is 0.

620

Reboot Behavior Policy Settings For example, if the Reboot schedule time setting is set to 11:00 PM and the randomization interval is 15 minutes, the restart can occur at any time between 10:45 PM and 11:15 PM.

Reboot schedule start date


This setting specifies the date on which scheduled server restarts begin, in the form MM/DD/YYYY. By default, no start date is specified.

Reboot schedule time


This setting specifies the time at which scheduled server restarts occur in the form H:MM TT, where H is the hour, MM is the minute, and TT is the time of day (AM or PM). Restart times are scheduled in the local time zone of the server and use a 12-hour clock. By default, scheduled server restarts occur at 12:00 AM (midnight). If you enter a time according to a 24-hour clock, the time is converted automatically to a 12-hour clock. If you enter a time without a TT value, the time of day defaults to AM.

Reboot warning interval


This setting specifies how often standard and custom warning messages are sent to users before a scheduled restart. By default, messages are sent every 15 minutes. Configure the Reboot warning start time setting to specify when to start sending the warning messages.

Reboot warning start time


This setting specifies the number of minutes before a scheduled server restart to send standard or custom warnings to users. By default, messages are sent 60 minutes prior to server restart. Configure the Reboot warning interval setting to specify how often the warning is sent.

Reboot warning to users


This setting enables or disables sending a standard warning message to users before a scheduled server restart. By default, messages are not sent to users prior to server restarts. To send a custom warning message (in addition to the standard message), enable the Reboot custom warning setting and specify the text in the Reboot custom warning text setting.

621

Reboot Behavior Policy Settings

Scheduled reboots
This setting enables or disables scheduled server restarts. By default, server reboots are not scheduled. You can configure automatic restarts at specific times and frequencies, as well as the starting date of the schedule. When this setting is enabled, the values configured for the following settings take effect when added to a policy:
q

Reboot schedule frequency Reboot logon disable time Reboot schedule randomization interval Reboot schedule start date Reboot schedule time

622

Server Session Settings


The Server Session Settings section contains policy settings for configuring Single Sign-On and session importance. These policy settings are applicable to XenApp.

Session importance
This setting specifies the importance level at which a session is run. By default, sessions are run at the Normal level. If the CPU management server level setting is configured for No CPU utilization management, sessions with higher importance levels are allowed to use more CPU cycles than sessions with lower importance levels. If the CPU management server level setting is configured for Preferential Load Balancing, sessions with higher importance levels are directed to servers with lower resource allotments.

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. By default, no path is specified. 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.

623

Virtual IP Policy Settings


The Virtual IP section contains policy settings for configuring Virtual IP support for applications. These policy settings are applicable to XenApp.

Virtual IP adapter address filtering


This setting enables or disables filtering of the list of addresses returned by the GetAdaptersAddresses() function to only include the session virtual IP address and the loopback address. By default, the list of adapter addresses is not filtered. Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop Session Host Configuration. Additionally, enable the Virtual IP enhanced compatibility policy setting. If these settings are not configured, filtering does not occur. After enabling this setting, configure the Virtual IP filter adapter addresses programs list to add the applications whose overhead can be reduced through adapter address filtering.

Virtual IP compatibility programs list


This setting specifies the application processes that can use virtual IP addresses. By default, no processes are specified. When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.

Virtual IP enhanced compatibility


This setting enables or disables additional support of Windows Remote Desktop IP virtualization. This allows calls to the gethostbyname() function within sessions to return the assigned virtual IP address for the session. By default, this setting is disabled. Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop Session Host Configuration. If this setting is not configured, additional support does not occur. After enabling this setting, configure the Virtual IP enhanced compatibility programs list setting to add the applications that can use virtual IP addresses.

624

Virtual IP Policy Settings

Virtual IP filter adapter addresses programs list


This setting specifies the application executables that can use filter adapter addresses. By default, the executable "outlook.exe" is specified. When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.

Virtual IP loopback support


This setting enables or disables the use of virtual loopback addresses in sessions. By default, sessions do not have virtual loopback addresses. After enabling this setting, configure the Virtual IP virtual loopback programs list to add the applications that can use virtual loopback addresses.

Virtual IP virtual loopback programs list


This setting specifies the application executables that can use virtual loopback addresses. By default, no executables are specified. When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.

625

XML Service Policy Settings


The XML Service section contains policy settings for configuring the Citrix XML Service. These policy settings are applicable to XenApp.

Trust XML requests


This setting specifies whether the Citrix XML Service should trust requests it receives. By default, the XML Service does not automatically trust requests. Before enabling this rule, avoid security risks by using IPSec, firewalls, or another technology that ensures only trusted services communicate with the Citrix XML Service.

XML Service port


This setting specifies the port number to use for the Citrix XML Service. To disable the port, enter 0 as the port number. By default, the port is disabled. When specifying the XML Service port number, the range of values you can enter is 1024-65535. Citrix recommends using port 8080.

626

Publish Resources
When you publish an application, configuration information for the application is stored in the data store for the server farm. The configuration information includes which types of files are associated with the application; users who can connect to the application; importance level for Preferential Load Balancing; and client-side session properties that include window size, number of colors, level of encryption, and audio settings. When delivered to users, published applications appear very similar to applications running locally on the user device. Users start applications depending on the delivery options you select while publishing and the plug-in they are running on their devices. Consult the appropriate sections in eDocs or other documentation about the Receiver and Plug-ins for more information about the Plug-in with which your users start published applications.

In This Section
Choose from the following methods to publish your applications: Publishing Resources using the AppCenter The most commonly used method for publishing resources to users for access on any Citrix-enabled user device. This approach uses the publishing wizard in the AppCenter to make available hosted and streamed applications, content, and desktops across the XenApp environment. Publish applications hosted on virtual or physical systems (servers or desktops) through the AppCenter. This approach uses XenDesktop technology and is ideal for applications that do not support multi-user environments or have other specific requirements that make them unsuitable to install on or stream to a XenApp server. Deploy and publish physical applications and App-V sequences to XenApp directly through the System Center Console. By using Power and Capacity Management to directing incoming user connections away from servers set to receive application, deploy applications to XenApp servers with minimal to no service interruptions. Deploy Microsoft Windows Server Update Services (WSUS) updates to XenApp server the same way.

Publishing VM Hosted Apps

Deploying and Publishing Applications with Microsoft System Center Configuration Manager 2007

627

Publish Publish App-V virtual application sequences in the AppCenter for delivery to XenApp servers or Citrix-enabled user devices. Similar to Citrix Application Streaming technology, this approach allows administrators to prepare the application environment once and deliver it on-demand to various devices. In addition, the XenApp 6 Powershell SDK offers Citrix customers, distributors, and partners a programmatic interface for publishing applications using the New-XAApplication command. For information, download the Readme and SDK from the Citrix Developer Network Web site at http://community.citrix.com/display/xa/XenApp+6+PowerShell+SDK. Publishing App-V Sequences

628

Publishing Resources
With XenApp, you provide users with access to information by publishing the following types of resources that can be virtualized on servers or desktops:
q

Applications installed on servers running XenApp. When users access them, the published applications appear to be running locally on client devices. Streamed applications installed in application profiles and stored on a file server in your App Hub. Users access the profile and virtualize the applications on their client desktops. For information about preparing and publishing applications for streaming, see the topics for Application Streaming. Data files such as Web pages, documents, media files, spreadsheets, and URLs. In XenApp, the combined total of data types you publish is referred to as content. The server desktops, so users can access all of the resources available on the server. Note: Citrix recommends that server desktops be locked down to prevent user access to sensitive areas of the operating system.

Publish all of these resource types using the Publish Application wizard in the Citrix AppCenter. To further refine how your users launch and access published resources, refer to information about configuring content redirection and XenApp policies. Citrix recommends installing applications that interact with each other on the same group of servers (called a silo). If you have multiple applications silos, Citrix recommends using separate organizational units, so they can be convenient targets for policies and worker groups. For more guidance about planning for applications and server loads, see the eDocs section about designing a XenApp deployment. Important: Before you begin, refer to the system requirements for supported platforms and system prerequisites.

629

Publishing Resources
With XenApp, you provide users with access to information by publishing the following types of resources that can be virtualized on servers or desktops:
q

Applications installed on servers running XenApp. When users access them, the published applications appear to be running locally on client devices. Streamed applications installed in application profiles and stored on a file server in your App Hub. Users access the profile and virtualize the applications on their client desktops. For information about preparing and publishing applications for streaming, see the topics for Application Streaming. Data files such as Web pages, documents, media files, spreadsheets, and URLs. In XenApp, the combined total of data types you publish is referred to as content. The server desktops, so users can access all of the resources available on the server. Note: Citrix recommends that server desktops be locked down to prevent user access to sensitive areas of the operating system.

Publish all of these resource types using the Publish Application wizard in the Citrix AppCenter. To further refine how your users launch and access published resources, refer to information about configuring content redirection and XenApp policies. Citrix recommends installing applications that interact with each other on the same group of servers (called a silo). If you have multiple applications silos, Citrix recommends using separate organizational units, so they can be convenient targets for policies and worker groups. For more guidance about planning for applications and server loads, see the eDocs section about designing a XenApp deployment. Important: Before you begin, refer to the system requirements for supported platforms and system prerequisites.

630

Evaluating Application Delivery Methods


The application delivery method is a factor in determining the number of servers in a farm and their individual hardware requirements. How you choose to deliver applications depends on your organization's needs and end-users' requirements. For example, some organizations use XenApp to streamline administration. In other organizations, the existing hardware infrastructure might affect the delivery method selected, as can the types of applications to be delivered. In addition, some end-users might run all applications while connected to the company network, while others might work in remote locations and run applications while disconnected from the network.

Method/Description Installed on the server:

Advantages
q

Considerations
q

Applications are installed on the server, where the processing takes place, and accessed from the server. This is the traditional XenApp application delivery model. For many organizations, this provides the lowest cost of ownership for IT resources because it provides the greatest scalability.

This method provides a consistent user experience regardless of the user device. You manage applications centrally. User devices do not require extensive resources, such as excessive memory or hard drive space. This delivery method supports thin clients. This method is effective for applications with components that are intertwined with the operating system (such as a .NET framework).

Farm servers require sufficient resources to support the applications. Users must be connected to the server or network to run the applications (no offline access).

631

Evaluating Application Delivery Methods Streamed to server: Executables for applications are put in profiles and stored on a file server or Web server (the App Hub); however, when launched, they stream to the server, and application processing takes place on the server. Unlike installed applications, streamed applications are stored in the App Hub and provide application isolation by design.
q

This method has similar advantages as for installed applications, including a consistent user experience, central management, and use of server resources instead of those of the user device. In many cases, streaming to server lets conflicting applications, such as multiple versions of the same application, run on the same server without needing to silo them. Updating applications is simplified because you update only a single application profile. Users can have the local application experience, but you manage the applications centrally. Users might have a better experience when resource-intensive applications, such as graphics applications, are streamed to desktops. Using application properties and Citrix policies and filters for Offline Applications, you control the applications and users that have offline access, as well as the license period for offline use.

Farm servers require sufficient resources to support the applications. Users must be connected to the server or network (no offline access). Some applications are not candidates for profiling, such as those using a .NET framework.

Streamed to desktop: Executables for applications are put in profiles and stored on a file server or Web server (the App Hub). When launched, the files required to execute the application are streamed to the user device, and application processing takes place on the user device instead of the XenApp server. When applications are streamed to the user device, the user experience is similar to running applications locally. After applications are cached on the user device, users can continue running the apps after disconnecting from the network (referred to as offline access).

User devices must have sufficient resources to run the applications locally; the user devices cannot be thin clients. User devices must run Windows operating systems, including Windows 7, XP, or Vista.

632

Evaluating Application Delivery Methods Dual mode delivery:


q

When you select "streamed if possible, otherwise accessed from a server" (referred to as dual mode or fallback), XenApp tries to stream the application to the user device first, but uses the backup access method if streaming to desktop is not supported on the user device. For example, you can specify that some users, such as sales personnel, run applications streamed to desktop when they are accessing the applications from Windows devices, and run them as installed applications when they are accessing them from handheld mobile or kiosk-type devices.

This method provides the most versatility for application delivery, offering all the advantages of streaming to desktops for supported user devices, plus a backup delivery method for the rest. You control delivery options centrally using Citrix policies and filters, such as the server's Load Balancing Policies for Streamed App Delivery.

For the backup method to occur, ensure that the application is either installed on the XenApp server or the streaming profile is configured for a target operating system that matches the server.

Choosing Between Published Desktops and Published Applications


Before selecting the method for delivering applications, decide if you want to publish the desktop or publish applications.
q

Publishing the desktop - Presents users with an entire Windows Server desktop when they log onto XenApp. (For security, the desktop should be locked down .) Publishing applications - Publishes specific applications and delivers only those applications to users. This option provides greater administrative control and is used most frequently.

You can use policies to prevent users from accessing server drives and features with both methods of application delivery.

633

Publishing Resources using the AppCenter


With the AppCenter, you provide users with access to information by publishing the following types of resources that can be virtualized on servers or desktops:
q

Applications installed on servers running XenApp. When users access them, the published applications appear to be running locally on user devices. Streamed applications installed in application profiles and stored on a file server in your App Hub. Users access the profile and virtualize the applications on their user devices. Data files such as Web pages, documents, media files, spreadsheets, and URLs. In XenApp, the combined total of data types you publish is referred to as content. Server desktops so users can access all of the resources available on the server. Note: Citrix recommends that server desktops be locked down to prevent user access to sensitive areas of the operating system.

Publish all of these resource types using the Publish Application wizard. To further refine how your users launch and access published resources, refer to information about configuring content redirection and XenApp policies. Citrix recommends installing applications that interact with each other on the same group of servers (called a silo). If you have multiple applications silos, Citrix recommends using separate organizational units, so they can be convenient targets for policies and worker groups. For more guidance about planning for applications and server loads, see the eDocs section about designing a XenApp deployment. Important: Before you begin, refer to the system requirements for supported platforms and system prerequisites.

634

Publishing Resources using the AppCenter

In This Section
Publishing Hosted Resources Provide access to users for applications, content, or desktops that can be virtualized on servers or desktops. Profile and publish applications for streaming to desktops or servers, and configure those applications for offline access. Manage properties to rename, move, disable, and delete published applications and change, duplicate, import, and export published application settings. Control whether users access information with applications published on servers or with applications running locally on client devices. Allow a dynamically-assigned IP address to each session so that configured applications running within that session appear to have a unique address. Publishing Applications for Streaming

Managing Application Properties

Configuring Content Redirection

Making Virtual IP Addresses Available

Publishing in Domains with Thousands of Objects


For directory services or domain environments, such as Novell Domain Services for Windows or Microsoft Active Directory Service, containing over 10,000 objects, Citrix recommends the following:
q

Use groups to categorize and assign permissions to large numbers of users. An application published to one group of 1,000 users requires XenApp to validate only one object for all 1,000 users. The same application published to 1,000 individual user accounts requires IMA to validate 1,000 objects. When adding users through the Citrix User Selector, if the Users container holds thousands of objects, add a list of names.

635

To configure servers to publish for multiple users


To ensure applications are enabled for multiple users, install the applications using one of the following methods:
q

Install applications as the Built-in Administrator Select an install for multiple users option in the installation wizard for the application, if the Setup for the application provides this option Install the application for all users from a command line

To install an application for all users, after enabling Remote Desktop Services, use these steps before installing the application: 1. Open a command prompt so that you are running it with Administrator privileges; for example, right-click the command prompt and select Run as Administrator. 2. Run the following command at a command prompt: change user /install 3. From the command prompt, run the Setup executable for the application.

636

To publish a resource using the Publish Application wizard


Open the Citrix AppCenter from any computer that can connect to the farm. Steps and options in the wizard vary depending on the application type you select. This procedure describes the basic options. 1. From the AppCenter, under the XenApp node, expand the farm or server to which you want to publish an application. Tip: To add a server to the list of servers for a published desktop or application (after publishing the application), drag and drop the server onto the published desktop or application in the left pane of the AppCenter. You can also drag and drop the published desktop or application onto the server. 2. Select the Applications node and from the Actions pane choose Create folder. Name the folder for the application you are publishing. 3. Select the folder you created and from the Actions pane choose Publish application. 4. In the Publish Application wizard, on the Name page, provide a display name (maximum 256 characters) and application description. The name appears on user devices when users access the application and on the AppCenter for the farm applications. XenApp supports application names that use Latin-1 and Unicode character sets, including characters used in Japanese, Chinese, and Korean. 5. On the Type page, specify the type of resource you want to publish and the delivery method. Three types of resources can be published (server desktop, content, and application). The next few steps in the wizard differ based on which type you select. For more details, see To select a resource type and delivery method and To select a streaming delivery method. 6. On the Location page, add the command-line and working directory (optional) to locate the application. 7. On the Servers page, add the individual servers or worker groups on which the published application runs when accessed by an ICA connection. Note: If you add a worker group, make sure that all the servers in the worker group are running the application you are publishing. 8. On the Users page, create the Configured users list for users or groups who have access to the application. Use the options to allow access to configured user accounts only or to anonymous users. 9. On the Shortcut presentation page, select the icon for the application and choose how the application is enumerated on the user device. The AppCenter has a limit of 1,000 unique application icons. When that limit is exceeded, the AppCenter displays a generic

637

To publish a resource using the Publish Application wizard icon for all new applications. 10. On the Publish immediately page, choose whether or not to make the published application immediately available to users.
q

By default, the published application is available when you click Finish.

To prevent users from accessing the application until you manually enable it through application properties, select Disable application initially. 11. To view and select advanced options, check Configure advanced application settings now. Alternatively, modify the advanced settings using the application properties.
q

When you finish, published resources (unless disabled) are available for users.

638

To select a resource type and delivery method


In the Publish Application wizard, select the resource type that you want to deliver and the delivery method. To view the setting, from the Action menu, select Application properties and then select Type. To change the resource type, from the Action menu, select Other Tasks > Change application type and follow the instructions in the wizard. 1. Select one of the following resource types:
q

Server desktop. Publishes the entire Windows desktop of a server in the farm. When the plug-in connects to the server, the user sees a desktop interface from which any application installed on that server can be started. After selecting this application type, you must specify the server that you want to publish. To publish a desktop, you must be running XenApp. If you are running the Citrix AppCenter on a computer that is not running XenApp, you cannot publish the local desktop.

Content. Publishes nonexecutable information, such as media, Web pages, or documents. After selecting this application type, you must specify the URL (Uniform Resource Locator) or UNC (Uniform Naming Convention) path to the file you want to publish. Click Browse to view available content resources on your network. Application (selected by default). Publishes an application installed on one or more servers in the farm. Note that if you are running the AppCenter on a computer that is not a member of the farm, you cannot publish local applications. You need to indicate one of the following application types:

Accessed from a server. Grants users access to applications that run on a XenApp server and use shared server resources. If you choose this option, you must then enter the location of the executable file for the application and the XenApp server on which it will run. Choose this option as the application type unless you intend to stream your applications. Streamed if possible, otherwise accessed from a server (also called dual mode streaming). Grants users access to a profiled application that streams from the file share to their user devices and launches locally from within an isolation environment. Alternatively, for user devices that do not support streamed applications (for example, if the Offline Plug-in is not installed), this setting allows the use of an ICA connection to access the application installed on or streamed from a XenApp server. Streamed to client. Grants users access to a profiled application that streams from the file share to their user devices and launches locally from within an isolation environment. With this option, the application uses client resources

639

To select a resource type and delivery method instead of server resources. Users must have the Offline Plug-in installed and access the application using Online Plug-in or a Web Interface site. If selected, user devices that do not support client-side application virtualization (such as, they use a non-Windows client) or do not have the Offline Plug-in installed locally cannot launch the application. 2. If you selected Accessed from a server or Streamed if possible, otherwise accessed from a server, you also need to select the Server application type. These are:
q

Installed application. Enables users to launch an application installed on a XenApp server. Streamed to server. Grants users access to stream a profiled application from the file share to a XenApp server and launch it from XenApp through an ICA connection. Note: For more information about client-side application virtualization through streaming, see the information for application streaming.

640

To configure locations of published applications


To access this option in the Citrix AppCenter, from the Publish Application wizard, continue to the Location page. Alternatively, to modify a location, select a published application and under Common Tasks, select Modify application properties > Modify all properties > Basic > Location. When you publish an application, specify the command-line and working directory (optional) for the application:
q

Command-line. The full path of the application's executable file. Append the symbols "%*" (percent and star symbols enclosed in double quotation marks) to the end of the command-line to act as a placeholder for client-supplied application parameters. When a Plug-in makes a connection request, the server replaces the symbol "%*" in the command-line with application parameters provided by the Plug-in. If the path to the application's executable includes directory names with spaces, enclose the command line for the application in double quotation marks. Include a space between the closing quotation mark and the double quotation marks around the percent and star symbols. An example of the format to use with a path with spaces and a placeholder is:

"C:\Program Files\Windows Media Player\mplayer1.exe" "%*" Important: Changing the command-line text removes all file type associations from the application. If you change the command-line text, modify the Content Redirection application property page to select the file types you want to associate with the application for client to server content redirection.
q

Working directory. By default, this path is the same as the path in the Command line field. To run the application from a different directory, add an absolute path to this field.

641

To configure locations of published content


When you publish content, specify the location using address formats such as the following types (examples shown in parentheses):
q

HTML Web site address (http://www.citrix.com) Document file on a Web server (https://www.citrix.com/press/pressrelease.doc) Directory on an FTP server (ftp://ftp.citrix.com/code) Document file on an FTP server (ftp://ftp.citrix.com/code/Readme.txt) UNC file path (file://myServer/myShare/myFile.asf) or (\\myServer\myShare\myFile.asf) UNC directory path (file://myServer/myShare) or (\\myServer\myShare)

642

To disable command-line validation


XenApp provides command-line validation for content that is redirected from the client to the server only. By default, XenApp validates published application command-line parameters passed from the client to the server. When you use the symbols "%*", XenApp ensures the parameters are valid before the application launches. If the parameters are invalid, the application launches without passing the parameters. XenApp records all failed validation attempts in the server's system log and in the security event log. If your environment includes published applications that use customized client-supplied parameters for purposes other than content redirection from client to server, these applications might not function correctly when command-line validation is enabled. To ensure client-supplied parameters are passed from client to server, disable command-line validation for these published applications. When using command-line validation, add all servers that store content, such as Word documents or PDF files, to the Trusted Sites list on the XenApp server. When adding servers to the Trusted Sites list, ensure you are logged on to the XenApp server as Administrator. If the content servers reside in separate domains, ensure trust relationships are established between these servers and the XenApp server. You can disable command-line validation for selected published applications or all published applications on a server.
q

If your environment includes published applications that use customized client-supplied parameters for purposes other than content redirection from client to server, these applications might not function correctly when command-line validation is enabled. To ensure client-supplied parameters are passed from client to server, disable command-line validation for these published applications. To disable command-line validation for selected published applications, from the Location page of the application properties, append the symbols %** (percent and two star symbols enclosed in double quotation marks) to the command-line parameter.

643

To pre-launch applications to user devices


Use the pre-launch feature to reduce application launch time at high-traffic periods. For example, if your environment includes a large number of users who launch the same application within a ten-minute time-frame, the rapid succession of logon requests can overwhelm servers and slow down application launch for all users. The pre-launch feature allows a pre-launch session to be created when a user logs on, or at a scheduled time if the user is already logged on. This pre-launch session reduces the launch time of the first application. The default application ctxprelaunch.exe runs in the session, but is not visible to the user. Considerations:
q

When a pre-launch session is created, it takes up a license immediately, even if the user does not launch an application. When you enable this feature for an application, the setting applies to all users and servers configured for the application; in addition, the pre-launch session created for the application is also available for all other published applications on the listed servers.

To customize the inactivity behavior for the pre-launch application, configure the Citrix User policy for Session Limits:
q

Pre-launch Terminate Timer Interval Maximum amount of time before the pre-launch application exits (60 minutes by default). Starting a user application in the session also terminates the pre-launch application. Once the pre-launch application exits, the session remains alive if the user's applications are running or if you configured session lingering.

Pre-launch Disconnect Timer Interval Amount of time before the pre-launch application disconnects the session (60 minutes by default). Once disconnected, the session gives up the XenApp license. When a user launches an application, the session is reconnected. This timer does not disconnect a session if a user launches an application. If the interval is not configured, the pre-launch session is not ever disconnected.

Note: Customizing the pre-launch feature using Administrative Templates is not supported. However, you can change the pre-launch configuration by modifying the registry values, located at:
q

For 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Prelaunch and HKEY_CURRENT_USER\Software\Citrix\ICA Client\Prelaunch

644

To pre-launch applications to user devices


q

For 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Prelaunch

To enable the pre-launch session: 1. In the AppCenter, from the navigation pane, select the server. 2. From the Applications list, select an application. Note: Select an application that is published for the groups of users and servers that are eligible for the pre-launch session. 3. From the Actions pane, select Other Tasks > Create pre-launch application. 4. This task creates a copy of the application with all its properties, users, and servers, and PreLaunch precedes the application name. This "application" is not enumerated to users. Refer to the table below for the application properties that you can modify. Properties and tasks for pre-launch applications The following table lists the properties and tasks that are inherited or configured for pre-launch applications. The application name, display name, description, and icon are visible only in the AppCenter and do not apply to the pre-launch application. Inherited from the original application. Modifications are applicable for a pre-launch application.

Not applicable for a pre-launch application. Modifications are used.

645

To pre-launch applications to user devices Properties:


q

Properties:
q

Enable/disable application Servers Users Location Access conditions Access gateway filters

Hide disabled application: The application is always hidde

Application type: The type is always an installed applicat

Working directory: The directory is always set to Systems folder in XenApp installation location. You can change th editing the pre-launch application properties.

Client application folder: The pre-launch application is no listed on the user device. Add to client's start menu: The pre-launch application is visible on the user device.

q q

Client audio requirement Connection encryption requirement Encryption level


q q

Add shortcut to client's desktop: The pre-launch applicati not visible on the user device. File types: The pre-launch application does not have any associated file types. Maximum instances: Always one instance per user.

Session window color depth


q

Allow only one instance of application for each user: Alw only one instance of the pre-launch application. If you co more than one pre-launch application of the server and u combination, additional instances are not launched.

Application importance: The pre-launch application is alw the first application launched.

Session window size: The pre-launch application is not vis the user device.

Hide application title bar: The pre-launch application is n visible on the user device.

Maximize application at startup: The pre-launch applicati not visible on the user device.

Tasks:
q

Disable/enable application Duplication application Move to folder Delete application Refresh user data Attach application to a load evaluator

646

Publishing Applications for Streaming


After you create profiles for applications using the Streaming Profiler, you make them available for streaming to users by publishing the applications. The Publish Application wizard in the Citrix AppCenter guides you through the process of selecting the streaming options. Configure the application streaming delivery method as you publish the application. Choose delivery options based on the users who will access the applications and their environments. The profiled applications must be stored on a file share or Web server that is accessible from your XenApp server so you can publish the application, and it must be accessible by your users so they can launch the application.

Streaming Applications to User Devices


If you deliver streamed applications directly to user desktops, users can launch the streamed applications, which run in an isolation environment on their desktops and use local resources to run the applications. This delivery method offers the full set of application streaming options including desktop integration and offline access. Before publishing an application to be streamed to client desktops, complete the following tasks:
q

Install the Offline Plug-in locally, where it runs in the background to enable application streaming. Install the latest version of online plug-in locally. To stream to client devices across a network protected by a firewall, configure firewall policies to allow those applications access.

After all of these tasks are complete, publish the application as Streamed to client.

Streaming Applications to a XenApp Server


To simplify application delivery to servers in a server farm, stream applications to a XenApp server and virtualize the applications through an ICA connection to user devices. For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site to the Trusted sites list in Internet Explorer on the user devices. Before publishing an application that is streamed to server, ensure your Web Interface sites and Citrix XenApp sites are configured to run one of the following application types:
q

Remote applications only, or Dual mode streaming (streamed if possible, otherwise accessed from a server)

647

Publishing Applications for Streaming For information about managing application types on Web Interface sites, see Technologies > Web Interface. After you ensure all of these tasks are complete, publish the application as Streamed to a server.

648

New Features in This Release


In addition to improved application compatibility on Microsoft Windows Server 2008 R2 SP1 and Windows 7 SP1, the 6.5 release provides the following enhancements for application streaming:
q

Increased support for streamed apps in pooled XenDesktop environments. For faster application launch time on user devices, select the option to "Create a virtual hard disk" (VHD) while profiling. This feature copies the profile contents into the VHD and mounts it in the RadeCache location at application launch. Compliance with new FIPS guidelines. The Streaming Profiler in this release uses SHA-256 to create file hashes. To include SHA-1 hashes required by Offline Plug-ins 6.0, select the option for "Legacy Offline Plug-in support" while profiling. Enhancements for creating AppHubWhiteList. The registry key for creating the AppHubWhiteList is now consistent with other Citrix registry keys on 32-bit and 64-bit operating systems. Ability to deliver AppHubWhiteList using Citrix Receiver Updater. Ensure that unsigned profiles and services stream only from approved locations AppCenter session reports include the names of streamed applications. The reports of user sessions now include application names instead of just profile names. Launch time improvements. General performance improvements reduce launch time for streamed applications, including Microsoft Outlook.

649

System Requirements for Application Streaming


Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the following Microsoft operating systems:
q

Windows XP Home and Professional editions, 32-bit edition, with Service Pack 3 Windows XP Home and Professional editions, 64-bit edition, with Service Pack 2 Windows Server 2008, 32- and 64-bit editions Windows Server 2003 R2 Windows Server 2008 R2 Windows Server 2008 R2, with Service Pack 1 Windows Vista (Home, Business, Enterprise, and Ultimate editions), 32- and 64-bit editions, with Service Pack 1 or Service Pack 2 Windows 7, 32-bit and 64-bit (Enterprise, Professional, Ultimate)

Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the following Citrix products: Note: The list is accurate at the time of this release. For more information about supported versions, see: http://www.citrix.com/support/product-lifecycle/product-matrix.
q

Citrix XenApp 5, 6, and 6.5. Citrix XenDesktop 4, 5, and 5.5. Citrix XenServer: all supported versions. Citrix Receiver (Updater) for Windows 1.x, 2.x, and 3.0. Citrix Online Plug-in: Citrix recommends 13.0, which is installed with Citrix Receiver 3.0, but past versions 11.2 and 12.x are also supported.

The profiler workstation and user devices must meet the following requirements:
q

Microsoft XML 2.0 installed (use Windows Update to ensure you installed all recent Internet Explorer updates). Standard PC architecture, 80386 processor or greater as required for the operating system. Administrator rights for the person installing.

650

System Requirements for Application Streaming


q

To profile and stream Microsoft Office applications to Windows Server 2003 operating systems, install the Windows Data Execution Prevention (DEP) hotfix on the server and profiling workstation. For information, see http://support.microsoft.com/kb/931534.

The profiler workstation must provide a run-time environment that is as close to your users' environment as possible. To stream applications to user devices, use the following guidelines for the profiling workstation:
q

Choose a workstation that is a similar platform to your users' devices. Use a computer that is freshly reimaged so that there are no hidden files or registry settings for applications that you intend to profile. Install only the standard programs that are part of the company image, such as an antivirus program. Disable the User Account Control (UAC). To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 optional). Do not install the Offline Plug-in on the profiler workstation. You can install Citrix Receiver.

Install the profiler in a path with single-byte characters only. Double-byte characters in the installation path are not supported. The user devices must meet the following requirements:
q

A network connection to the server farm, such as a network interface card (NIC). A supported browser: Microsoft Internet Explorer 6.0, 7.0, 8.0, or 9.0. To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 is optional). Manually uninstall any previous version of the Streaming Client and Program Neighborhood Agent on user devices. To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your users, install the Offline Plug-in and the most recent version of Citrix Receiver (Enterprise), which includes the Online Plug-in. In addition:
q

Citrix recommends using Citrix Receiver Updater on user devices to install (and uninstall) Citrix plug-ins. To stream applications to user desktops, install both the Offline Plug-in and Citrix Receiver (Enterprise) on user devices.

To stream applications to a server, install Citrix Receiver (Enterprise) on user devices. The Offline Plug-in is not required. If users launch applications from a Web Interface site, install Citrix Receiver (the Enterprise version is not needed) and add the site to the list of trusted sites. Microsoft redistributable packages
q

651

System Requirements for Application Streaming The CitrixOfflinePlugin.exe and CitrixStreamingProfiler.exe installers include the following redistributables:
q

Microsoft Visual C++ 2005 Redistributable Package 8.0.56336 Microsoft Visual C++ 2005 Redistributable Package 8.0.50727.42 Microsoft Visual C++ 2008 Redistributable Package 9.0.21022 Microsoft Visual C++ 2008 Redistributable Package 9.0.30729 Microsoft Visual C++ 2008 Redistributable Package 9.0.30729.4148

Backward compatibility. To take advantage of the latest updates in application streaming, Citrix recommends installing the most current versions of the Streaming Profiler, Citrix Plug-ins, and Citrix Receiver.
q

Profiles created in the Streaming Profiler 6.5 are supported with:


q

Offline Plug-in 6.5 Offline Plug-in 6.0 (you must select the profiling option to support legacy Offline Plug-ins) Note: The Virtual Hard Disk feature is not supported for version 6.0.

Online Plug-in, which is included in Citrix Receiver 3.0 (with this release) or past versions 11.2 through 12.x. To continue using existing profiles with the plug-ins in this release, also install the latest profiler and update them (simply open them in the new profiler and re-save them).
q

If upgrading is not possible, this release provides backward compatibility for streaming profiles created with profiler 5.2 through 6.0.

Streaming Microsoft Office 2007. For best practices for streaming Office 2007 applications, see http://support.citrix.com/article/CTX118396 in the Citrix Knowledge Center. Streaming Microsoft Office 2010. For best practices for streaming Office 2010 applications, see http://support.citrix.com/article/CTX124565 in the Citrix Knowledge Center. Update the profiler workstation and user devices with the latest Microsoft hotfixes, including:
q

On Streaming Profiler workstations with Windows 7 (32-bit and 64-bit) only, download the hotfix from http://support.microsoft.com/kb/2359223/en-US (requires a computer restart). On Windows XP 32-bit platforms, install hotfix KB978835. On all Windows XP or Windows 2003 platforms, install hotfix KB973573. For more information, see http://support.citrix.com/article/CTX124563 in the Citrix Knowledge Center.

652

Application Streaming Overview


Application streaming simplifies application delivery to users by virtualizing applications on client devices. Administrators can install and configure an application centrally and deliver it to any desktop on demand. Use the application streaming feature to install and configure an application on one file server in your App Hub, publish the application using the XenApp publishing wizard, and deliver it to any desktop or server on demand. To upgrade or patch an application, you make the updates only in the location where you stored the application. Application streaming augments application delivery not only to user desktops, but also to servers in your server farms. Application streaming offers the following features: Install once, deliver anywhere Provides the ability to install an application once on a profiler workstation and have it replicated to file servers within the existing enterprise infrastructure. Once there, the applications are delivered to client devices that request access to the application, on-demand, as a result of end-user activity. Seamless updates No need to profile applications again. Updates are as simple as updating an application on a desktop using the update program supplied by the manufacturer. The update is performed once on the profiler workstation and delivered to client devices in a manner similar to that used in the initial delivery. Application isolation All streamed applications run within isolation environments that keep the applications from interfering with others running on the same client device. The isolation environment is specific for the application and user session, regardless of whether the user streams to the local client or virtualizes the streamed application from a server. The specific data files of the application, such as INI files and registry keys, are all isolated and maintained centrally for the streamed application. Application caching Application files can be cached on the client device to allow faster access the next time the application is launched. Before an application runs, cached files are updated automatically if there is a newer version on the file server. Note that application caching is strictly for performance reasons; there is no requirement to have the application cached for the application to run. Wide range of target environments Nearly any modern Windows platform can host a streamed application. Specifically, supported operating systems include Windows XP Professional, Windows Server 2003 and 2008, Windows Vista, and Windows 7. With dual mode streaming, target environments are

653

Application Streaming Overview increased to include all supported XenApp client desktops. Dual mode streaming Configure XenApp to stream software to client devices; otherwise, virtualize from a XenApp server. If launching a streamed application fails on the client device, XenApp seamlessly streams the application to the server and virtualizes the application on the client device from XenApp. Easy delivery of applications to farm servers When publishing applications in a server farm, choose to virtualize applications from XenApp, which can simplify application delivery. Instead of installing applications on your farm servers, you stream them to XenApp from a central file share in your App Hub. Update the application in the central location, and you update the application on all the farm servers. Consistent end-user experience Applications that can be accessed through the server appear next to other applications that the user is accustomed to either within the Web Interface, Citrix plug-ins, or on the desktop. The user does not have to know where and how the application is executing. Offline access Once configured and delivered, applications are available to the user while disconnected from the network. Easy disaster recovery On-demand application delivery is a powerful concept for disaster recovery situations because the application and data are not lost if the profiles can be easily backed up, and servers and desktops can be replaced easily.

654

Components for Application Streaming


The components related to a server farm that make applications available for streaming can be separated into four categories. Each of these functional areas consists of software running on one or more workstations or servers. Before you install the components for application streaming, refer to the system requirements for application streaming. The components that support virtualization on the user device, as shown in the diagram, include the XenApp server, Citrix Licensing, Streaming Profiler workstation, file servers, Web Interface, Citrix Receiver, and Offline Plug-in.

655

Components for Application Streaming

1. Licensing. Consists of the license server and License Management Console. Use the License Management Console to manage licensing. To install Citrix Licensing, see the licensing section in the Technologies node of Citrix eDocs. For more information about licensing application streaming and offline access, see Application Streaming Licensing Explained (CTX112636). 2. Administration (server farm). Consists of the following components:
q

Farm servers. IMA database.

656

Components for Application Streaming


q

The Web Interface. The AppCenter, to configure and manage the server delivery and publish applications for streaming.

3. Citrix Streaming Profiler. Creates and maintains streaming application profiles. The Streaming Profiler is an independent application that enables you to profile Windows applications, Web applications, browser plug-ins, files, folders, and registry settings that can be streamed to user devices and servers. Use the profiler to create one or more targets within an application profile that can match all the platforms of your users. This strategy creates a single profile that can accommodate a variety of user platforms. The profiler can also update applications in the profile and provide other resources that your users need. 4. Citrix Plug-ins. The Offline Plug-in support streaming applications to the user's desktop. To provide offline access to applications and dual-mode streaming, install both the Offline Plug-in and Citrix Receiver (Enterprise), which includes the Online Plug-in, on user devices. When a user runs a published application enumerated by Citrix Receiver or through a Web Interface site, the Offline Plug-in finds the correct target in the profile in the App Hub, sets up the isolation environment on the user device, and then streams the application from the profile location to the safety of the isolation environment set up on the user device. To support streaming applications to the server, install the Citrix Receiver on user devices. These applications must be published as "stream to server." When users run an application, it streams to the server and launches using an ICA connection on the user device. To stream to a Web Interface site, you must the site to the list of trusted sites.

657

Deciding Which Receiver or Plug-in to Use for Application Streaming


The delivery method for streaming that you select for published applications determines the Receiver and plug-ins to must install on servers and user devices. Citrix recommends using the Citrix Receiver Updater to deliver the packages that you want to install on user devices: Streamed to client desktops. With this method, you make available the full set of application streaming features. You can publish applications as "streamed to client" or any other method for streaming. When you stream applications directly to client desktops, some of the application files are cached locally and the application runs using the resources of the user device. Install both the CitrixReceiverEnterprise.exe and CitrixOfflinePlugin.exe on user devices. This combination enables you to:
q

Enumerate published applications in the desktop Start menu and create shortcuts on the desktop. Provide dual-mode streaming. When you select "Streamed if possible, otherwise accessed from a server" and "Streamed to server," if streaming to the client desktop fails, applications automatically stream to a XenApp server and launch using the Citrix Receiver (Enterprise). Configure the application and users for offline access. When this configuration is completed, the entire application is fully cached on the user device. Users can disconnect from the network and continue using the application for the time specified in the offline license.

Accessed from a server. The profile is streamed from the App Hub to the XenApp server, where the Offline Plug-in is installed by default. The application displays on the user devices using the Receiver; the Offline Plug-in is not required on the user device. When you publish applications as "Accessed from a server" and "Streamed to server," users access the applications using the Receiver. This method does not support offline access to applications. Select the package that fits your corporate needs:
q

Install CitrixReceiverEnterprise.exe to stream applications to XenApp servers and launch them with the Receiver if you require native Program Neighborhood Agent (Applications in folders) or Smart Card authentication. Install CitrixReceiver.exe to stream applications to XenApp servers and launch them using Citrix Receiver self-service or a Web browser using a Receiver for Web or Web Interface site you create.

658

Deciding Which Receiver or Plug-in to Use for Application Streaming Important: For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site to the trusted sites list in Internet Explorer on the user devices. Streaming to a virtual desktop. To deliver applications to pooled XenDesktop environments, install both Receiver and the Offline Plug-in on the virtual desktop image. You must profile the applications with the option to create a virtual hard disk. When users launch the application, the profile contents are mounted in the RadeCache location from the AppHub.
q

When profiling the application in the streaming profiler, select the option to Create virtual hard disk. When publishing the application in XenApp, select the delivery option to stream to client desktop. Note: Do not configure HTTP delivery for applications that stream to virtual desktops. Also, offline access is not supported on virtual desktops; if you enable offline access, the settings are ignored for this deployment.

When creating the virtual desktop image, install both the CitrixReceiverEnterprise.exe and CitrixOfflinePlugin.exe.

659

Providing Single Sign-on for Streamed Applications


Citrix extends the Single Sign-on feature for streamed applications. When Single Sign-on is installed locally, it recognizes streamed applications, even when launched in isolation environments, and manages logons as expected. For Microsoft Internet Explorer, however, the Single Sign-on feature must install a file called BHO.dll. To allow this, when creating your application profile for Internet Explorer plug-ins, select the option to Enable User Updates (formerly called Relaxed security), which is deselected by default. By enabling user updates for Internet Explorer, the application can download vendor-supplied updates over the Internet. These updates are stored within the user profile and are unique to that user. The next time the user device connects to the profiled Internet Explorer on a server or file share, the streamed application does not overwrite the updates, and Internet Explorer runs using the updates. Also with this setting, installers can run inside isolation, where they are able to install new add-ons or software updates to Internet Explorer. Local add-ons are compatible with Internet Explorer if you profile it with the default isolation rule of Isolate. Local add-ons might not install correctly if you change the isolation rule for the Internet Explorer profile to Strictly Isolate.

660

Creating Application Profiles


A profile is an application packaged for streaming using the Citrix Streaming Profiler. A profile can contain a single application or suite of applications. For example, you can profile Microsoft Word by itself or profile the entire Microsoft Office suite in a single profile, or you can profile applications separately and link them with inter-isolation communication. To create profiles, you must install the Streaming Profiler on a clean, independent computer, called the profiler workstation. The profiling wizard records the installation of applications and the metadata needed to stream the profiled applications. The profiler bundles files and configuration settings in what becomes the application profile. Individual targets within a profile represent one or more defined user environments. The initial target matches the environment of the profiling workstation; however, you can create multiple targets to match specific user environments. For example, some commercial applications are capable of running on multiple operating systems and languages, while others, such as custom applications, might be capable of running only on a particular target operating system and language. Important: Applications compiled as 64-bit applications are not supported for streaming. However, 32-bit applications can be profiled on 64-bit systems and configured to be streamed to 64-bit systems. Depending on the environment of your users, you have the option to profile prerequisites, such as Java Runtime Environment, with the profiled application. In some cases, you might find it necessary to profile certain applications together to ensure functionality among applications or to apply a range of compatibility settings to ensure profiled applications launch and run successfully. In addition, you can use the profiler to link existing profiles using inter-isolation communication so that applications interact as needed, even though they are running in isolation environments. After you create a profile and save it to a file share in your App Hub, configure users and publish the application in the profile for streaming using the publishing wizard in the Citrix AppCenter. When a user launches an application published to stream to the user device, the Citrix Plug-in running on the user device automatically chooses the correct target that matches the configuration of the user device. For information on specific topics, refer to these documents on the Citrix Knowledge Center:
q

Application Streaming FAQs for Administrators at http://support.citrix.com/article/CTX118181 Enhancing Security in Application Streaming for Desktops at http://support.citrix.com/article/CTX110304 Application Streaming Delivery and Profiling Best Practices for XenApp at http://support.citrix.com/article/CTX118623 Additionally, select your product version of XenApp on the support Web site, click the Technotes tab, and then click Application Streaming.

661

Creating Application Profiles Note: The Streaming Profiler SDK offers a set of COM objects and .NET interfaces that give Citrix customers, distributors, and partners a programmatic interface into the profiler. For information, download the SDK and Readme from the Citrix Developer Network Web site at http://community.citrix.com/.

662

Targets Overview
A target is a collection of disk files, registry data, and other information used to represent an application isolation environment. In addition, each target denotes a combination of operating system, service pack level, system drive letter, and language. Applications can be profiled for each combination of these values to support separate targets; for example: Microsoft Vista for all service packs, drive letter C, and English. There can be multiple executables inside a target including multiple applications that normally receive an entry on the Start menu. As an example, Microsoft Office is a profile and Microsoft Word is an application inside that profile. A profile can support multiple targets where the target is a separate installation of the profile-level software targeted for execution on a specific version of the operating system or language. For example, create one target for Windows Vista and another target for Windows Server 2008. User devices select targets for execution based on the computer configuration you specify while creating the target. By default, a target matches the operating system and configuration of the profiling workstation, but you can select different operating systems as well. In addition, refer to information about the following selection criteria for creating targets:
q

Service Pack Level System Drive Letter Operating System Language Inter-Isolation Communication Overview

You use the profiler to set criteria for each target in a profile. One or more administrators can run the profiler multiple times and from different packaging environments to achieve a complete set of differentiating targets. For many common scenarios, a single installation image supports a variety of computer configurations, which simplifies profile creation. The criteria associated with each target is stored in a profile manifest, a .profile file, stored with the profile files. Overlapping definitions are not permitted: only one target in a profile can be a correct match for any computer configuration at application launch. An administrator can update a profile and target at any time without affecting already active executions on user devices. The cost for this support is that file-server disk space is consumed to maintain old versions. The profiler provides no facility to delete old versions of targets. Instead, manually delete old versions of targets to reclaim server-side disk space. When deleting targets, it is the responsibility of the administrator to ensure that the deleted versions are sufficiently old that no users are employing the target. For the list of supported operating systems for application streaming, see the system requirements. By design, future operating systems are not supported, and the execution environment refuses to execute an application if the user device has an unsupported

663

Targets Overview operating system.

664

Service Pack Level


The service pack field is an optional component that augments the operating system version. Because service pack level augments the operating system version, the profiler stores service pack selection criteria on a per-operating system basis. For each operating system, set the following rules for service pack selections:
q

Not required (any service pack is acceptable) Minimum Service Pack Level Maximum Service Pack Level Range of Service Pack Levels A single, specified service pack level No service packs installed

When choosing supported service packs, ensure that you do not choose service packs that are not supported by the Offline Plug-in. Refer to the system requirements for supported platforms.

665

System Drive Letter


For best practices, Citrix recommends that you install all applications on the primary system drive. By packaging and executing using the primary system drive, you define a set of criteria that best associates a given target with a given user device. The system drive letter must be a match between the target and the user device drive for a target to be the correct match for executing an application. There is no provision for the system drive to be variable. The system drive used on the profiler workstation must match the system drive on the user device. To support user devices with different system drive letters, create a target for each drive letter.

666

Operating System Language


The following languages are supported by the profiler:
q

English French German Japanese Spanish Simplified Chinese

Using the English version of the profiler, create targets for the following operating system languages:
q

Korean Traditional Chinese

The profiler can create targets for all languages, including languages other than those listed here, but doing so is not fully supported. To create targets for other languages, Citrix recommends that you use the English language version of the profiler.

667

Inter-Isolation Communication Overview


Inter-isolation communication is a feature that links individual profiles so that applications in separate profiles can communicate with each other when launched on the user device. You can also use this feature if a streamed application fails because it needs data from another streamed application, but cannot detect it because both are running in isolation environments. You can create two types of profiles that provide inter-isolation communication:
q

An associated profile does not include any additional installation. You link existing profiles and set their hierarchy so that they can communicate when launched on the user device. For example, if you profile Microsoft Outlook and Adobe Reader in individual, simple profiles, the applications operate independently, but Outlook is not aware of the streamed Adobe Reader and therefore cannot call the application in the simple profile to open the .PDF attachment. By associating these two profiles, Outlook and the Reader can interact as users expect, even though the individual applications are profiled separately. This happens because they are now aware of each other and can interact as though they are profiled together. A dependent profile includes the installation of an application that depends on the presence of one or more other applications before its installation is complete. While you create the profile, to simulate this dependency, the existing profiles that you select are temporarily downloaded from the file server during the profiling process to establish the hierarchy and isolation rules that are used at runtime. You then install the application that is dependent on them. For example, you might include simple profiles with Office 2007 and Microsoft Dynamics in this profile before you install a .NET application that depends on them. That way, when users launch the .NET application, Office and Dynamics are also launched on the user device.

When you create a profile enabled for inter-isolation communication, applications launch on the user device and remain isolated from the system and from other isolated applications, but they can interact with each other. The advantage of inter-isolation communication is that applications can be maintained separately and updates are included automatically in all the linked profiles in which the profile is included. This feature saves time for the administration of the profile set. When you create a dependent profile, the additional properties added to any of the individual profiles in the linked profile are enabled for all the individual profiles. These properties include custom rules, pre-launch or post-exit scripts, and pre-launch analysis. When users stream applications from the inter-isolation communication profile, the combined properties of all the linked profiles execute in hierarchical order, from the lowest profile to the highest profile as listed in the profiling wizard and Linked Profiles property page. However, if you create an associated profile, without installing a new application, additional properties are not available. You can add properties only to profiles that have installed applications.

668

Isolating Services
Certain applications, such as Microsoft Office 2010, require related services to run on the user device. Beginning with version 6.0 of the profiler, services that are required by applications are automatically installed with the application as you create application profiles. Important: This feature requires that you create a whitelist of approved locations of profiles in the registry of user devices. After you create the whitelist and edit the registry for the user devices, only services from the approved locations can be loaded and run on the user device. For these steps, see Specifying Trusted Servers for Profiles and Services. Based on its startup type, a service runs in an isolation environment on the user device with the application that requires it and continues until the session ends:
q

Automatic start: These services start automatically at logon and continue running until the user shuts down or restarts the device. Manual start: These services start when called by an application in the profile and continue running until the application ends the service or the user shuts down or restarts the device.

To view or modify the services available for a target, from the profiler, from the Edit menu, select Target Properties. The Services tab lists the services, their paths, logon names, and start type.

Considerations
q

Isolated services might extend launch time for the first launch of the application each time the device is restarted. When a service runs in isolation, it might not communicate all the needed information with services running outside isolation, such as locally installed services. If communication is required, consider removing the service from isolation and installing it locally on the user device. If the profile uses inter-isolation communication to link one or more subprofiles, all services within the linked profile are started. To update a service, open the existing profile in the Update Profile wizard. Citrix recommends updating services during off-peak hours because the procedure stops the service and closes that application for end users. After completing the update, the service restarts and users can relaunch the application. In any environment, only a single instance of the service launches in isolation. For example, in a multiuser environment, the service starts when the first user launches the application and then is shared by all subsequent users running the application.

669

Specifying Trusted Servers for Streamed Services and Profiles


To ensure that unsigned profiles and services stream only from approved locations, edit the registry on user devices to enable a whitelist of trusted servers:
q

For unsigned profiles that include services, you must create a whitelist of approved server locations on the user device. If profiles attempt to stream a service from a location that is not on the whitelist, the service launch is denied and an event is sent to the event log. Optionally, to extend the whitelist requirement to unsigned profiles without services, create an additional registry setting.

Alternatively, signed profiles are always trusted, whether or not they include services, and a whitelist is not required for them. 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.

Creating a Whitelist of Locations for Unsigned Profiles with Services


To ensure that user devices run only approved services, edit the registry on user devices to enable a whitelist of approved server locations. 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade Value: AppHubWhiteList Type: REG_SZ 2. Add the server names (or local file system folder) plus the App Hub location in the registry value in a semicolon (;) or comma (,) delimited format, with or without spaces before or after the semicolon or comma. For example:
q

\\server\sharename \\server.example.net\sharename\directory

670

Specifying Trusted Servers for Streamed Services and Profiles


q

\\server.example.net\profiles

If the application has been streamed from a web location (also called http streaming), the server name must be prefixed with http (or https) in the AppHubWhiteList registry entry. Also there is clear distinction between http and https servers. That is, if a profile location is https://12.0.0.1/profiles/office/office.profile, then the AppHubWhiteList must contain https://12.0.0.1 or https://12.0.0.1/profiles. The following examples are valid entries:
q

http://streamauto;https://12.0.0.1 http://webshare.example.com/sharename 12.0.0.1;streamauto;webshare.example.com 12.0.0.1;c:\profiles;c:\folder with spaces;webshare.example.com

12.0.0.1; c:\profiles; webshare.example.com After you create the registry entry and whitelist on user devices, unsigned profiles with services can load only from the locations on the whitelist. Signed profiles are always allowed.
q

Extending the Whitelist to Unsigned Profiles without Services


Optionally, to require all profiles, even those without services, to stream only from locations on the whitelist, after creating the registry entry and whitelist in the previous steps, create an additional registry entry: 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade Value: AppHubWhiteListRequired Type: REG_DWORD 2. Set the value:
q

1 - Enables the whitelist requirement to profiles without services

q 0 - Disables the whitelist requirement to profiles without services After you create the registry entry and whitelist in the previous steps and then create and enable this registry entry on the user device, all unsigned profiles, with or without services, can load only from the locations on the whitelist. Signed profiles are always allowed.

671

Specifying Trusted Servers for Streamed Services and Profiles

Disabling Backward Compatibility


When you create a white list, by default, you can add both server names (as allowed by the 6.0 release) and the better protected share names (added in 6.5) to the AppHubWhiteList path. No registry change is needed for the default behavior. To disable backward compatibility with the 6.0 release and allow only share names, create the following registry setting: 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade\ 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade\ Value: AppHubBackWardCompatible Type: REG_DWORD 2. Set the value:
q

0 - Disables backward compatibility 1 - Enables backward compatibility

Note: To re-enable backward compatibility, either change the registry value or delete the registry entry.

672

Managing Isolation Environment Rules


The Offline Plug-in uses isolation environments to control application compatibility and accessibility. The Plug-in creates isolation environments by defining a set of rules that specify how an application functions within its confines. The default rules for isolation environments are adequate for most environments. However, alter the default set of rules, as needed, to exert control over application interactions with operating system resources on the user device. A rule for an isolation environment is based on a specific location: either a file path or a registry key path. Rules are matched by the most specific path to the resource being accessed. A rule applies to the object (file, registry, or named object) specified and all the children of the specified object, unless a more specific rule exists.

673

Types of Isolation Environment Rules


Use isolation environment rules to improve application compatibility when users stream applications to their user devices. Rules can reduce conflicts between the streamed application and other locally installed, hosted, or streamed applications. Choose from isolate, strictly isolate, ignore, and redirect rules, as needed.

Isolate Rules
This is the default behavior while profiling applications in the Streaming Profiler. The Isolate rule assures that a streamed application cannot affect locally installed components of the operating system or other applications. When user devices create a new isolation environment, its default behavior is to isolate everything with a few exceptions. When an application requests access to a system resource (such as a file, registry, or named object), a per-user version of the file or key is created as required. This behavior relieves most application conflicts and allows applications to run correctly. Isolation rules ensure that per-user level versions of files and keys are created. This creates an individual copy of each resource that a particular user accesses. Add this rule to ensure that there is one copy of a resource per isolation environment. For example, create a rule that isolates the registry hive, HKEY_LOCAL_MACHINE\SOFTWARE\classes, when you install Microsoft Office. Because each user does not require a separate version of this hive, create a rule that isolates this particular registry hive for the isolation environment.

Strictly Isolate Rules


This rule prevents the application from accessing the objects in the physical layer. The application never sees an object that is defined to be covered by this rule unless it was created within the isolation environment. This rule is commonly used to support multiple versions of an application running on the user device. The existing Isolate rule prevents an application from making changes in the global system, which might affect other applications running in the system. However, system changes made by other applications running on the system cannot be hidden from view of the isolated application. Sometimes, such changes may need to be hidden from the application view for its proper functioning or for installation of an application in the sandbox. The Strictly Isolate rule allows the sandbox to hide selective changes made in the system from the view of virtualized application.

674

Types of Isolation Environment Rules

Ignore Rules
The Ignore rule allows the rules engine to define holes in the isolation environment so that an application can write to the underlying system. Note that the Isolate rule is still the default behavior while profiling applications in the Streaming Profiler. This rule allows a streamed application running inside an isolation environment to share data with an application outside the isolation environment. For example, if you try to open a file from streamed application A to use in locally installed application B, the applications can communicate normally, as though they are both locally installed. Also, in a scenario where users can print to network printers available within a streamed-to-client session, these printers are created automatically when the user connects to a published application.

Redirect Rules
A Redirect rule redirects an application request for a file or registry key to a specified location. For example, if an application creates the file, c:\temp\data.txt, this rule can redirect those files to c:\guidtemp\%USERNAME%, regardless of the user. For example, if UserA runs the application in an isolation environment, c:\temp\data.txt is created in c:\guidtemp\UserA\data.txt. In this example, the administrator might choose to clean up the \temp directory each time the system starts up. By redirecting all access of c:\temp directory to c:\guidtemp on a per-user basis, the administrator can clean up the temporary data easily at startup.

Examples
Consider the effects of the following rules:
q

An Ignore rule for the file path: C:\Documents and Settings\%USERNAME% Every file and directory created under C:\Documents and Settings\%USERNAME% is created in the system location because you specified, through the Ignore rule, that this directory location is not isolated. If an application opens the file C:\Documents and Settings\%USERNAME%\ ApplicationData\CompanyA\foo.txt, the Ignore rule for C:\Documents and Settings\%USERNAME% applies.

A per-user Isolate rule for: C:\Documents and Settings\%USERNAME%\Windows This rule isolates the per-user Windows directory, C:\Documents and Settings\%USERNAME%\Windows. If an application opens C:\Documents and Settings\%USERNAME%\Windows\Win.ini, the isolate per-user rule for C:\Documents and Settings\Windows applies.

675

Restrictions and Limitations for Rules


Consider the following restrictions and limitations when constructing or altering the rules for your isolation environment:
q

Do not modify or delete the default rules available for an isolation environment. If you modify these rules, the isolation environment might be unable to run applications correctly. Use an asterisk (*) as a wildcard character only at the end of an ignore named object rule. For example, the rule ignore object* ignores all named objects with a name starting with object. Use of an asterisk is not allowed in isolate or redirect object rules. Important: Do not use the wildcard in a rule that applies to a file system or registry key. By definition, the rule applies to all the children of a path name.

File system rules can apply to either files or directories. Create a rule to alter the behavior of individual files or of directories and all of the files within them. For example, you might have a Redirect rule for C:\temp\fileA.txt, as well as one for C:\temp\subdir1. Rules that specify a registry object apply only to registry keys. They do not apply to registry values. Rules for an isolation environment are interpreted at run time. Any modifications to existing rules are interpreted the next time you launch an application associated with, or installed in, an isolation environment. If you are executing an isolated application and modify the rule definitions, these changes do not affect running applications. The modified rules are interpreted and take effect the next time the application is executed. A rule must be specified in terms of a full directory or key level. Matches are performed on the full name of a given hierarchy level. For example, if you create a Redirect rule for C:\temp\file, the rule applies only to a file or directory called c:\temp\file. The rule does not apply to any files or directories that have c:\temp\file as part of their name. For example, this rule does not apply to the file C:\temp\fileA.txt, the directory c:\temp\filledWithFiles\, or any files under that directory. The same principle applies for the file system, registry, and named objects (with the exception of wildcards and named object rules).

676

Creating Isolation Environment Rules for a Target


Use the Rules page of Target Properties to modify the isolation environment rules. The list of rules on the Rules page displays for each rule its name, the action to perform, and the object on which to perform the action. To display more detailed information about a rule, select it in the list and Rule Description identifies the named object on which the rule operates. After testing a profile, if you determine that your users might experience conflicts when running applications in their isolation environments, modify the isolation environment rules for the target. Some of the indications that you may want to modify the isolation rules are:
q

If an application creates a directory for per-user data that is stored in a nonstandard location (Ignore rule) If the profiler workstation has extra drive volumes and an installer writes to those drives while installing in a target (Ignore rule) If your file share volume is on your profiler workstation (Ignore rule) If you must isolate a subdirectory of an ignored directory on the user device (Ignore and Isolate rules) If you must support multiple versions of an application running on the user device (Strictly Isolate rule)

The Rules list shows the existing rules for the target and for each rule identifies:
q

Arbitrary name for the rule Action, which is the isolation environment rule that is being called Object on which the action performs

The Rule Description box at the bottom shows the command represented by the currently selected rule. To edit the set of rules, use the Add, Copy, Modify, and Delete buttons.

677

To create an isolation environment rule


To add a rule to the currently defined set of rules, from the Profiler, select the target, and from the Edit menu, select Target Properties. From the Rules tab, click Add. Use the New Rule wizard to define the new rule. 1. Select an action and the type of object on which you want the action to operate. 2. On the Select Objects page, click Add. If for the action, you choose Ignore, Isolate, or Strictly Isolate:
q

If you selected Files and Folders as the object type, use the file browser to select the files and folders on which you want the rule to operate If you selected Registry Entries as the object type, use the Choose Registry Entry dialog box to select a hive and type a key on which you want the rule to operate

If you selected Named Objects as the object type, use the Choose Named Object dialog box to type the name of the object on which you want the rule to operate If for the action, you choose Redirect, specify the source path, registry entry, or named object and its destination.
q

3. If necessary, modify the default name of the rule. By default, the New Rule wizard creates a rule name consisting of the name of the action and the name of the object.

To copy a rule in the currently defined set of rules, from the Rules tab of Target Properties , select the rule and then click Copy. The copy operation adds the copied rule to the top of the list of rule set members. Use the property also to modify the name, action, or object of the rule. To delete a rule from the currently defined set of rules, from the Rules page of theTarget Properties, select the rule and click Delete.

678

To modify a rule
To modify a rule in the currently defined set of rules, from the Rules tab of Target Properties, select the rule and click Modify. Use the New Rule wizard to define the new rule. Modifying a rule lets you modify the action and objects, but not the object type. 1. Select the action. 2. On the Select Objects page, add or modify objects. If the selected action is Ignore, Isolate, or Strictly Isolate:
q

If Files and Folders is the object type, use the file browser to select the files and folders on which you want the rule to operate If Registry Entries is the object type, use the Choose Registry Entry dialog box to select a hive and type a key on which you want the rule to operate

If Named Objects is the object type, use the Choose Named Object dialog box to type the name of the object on which you want the rule to operate If the selected action is Redirect, specify the source path, registry entry, or named object and its destination.
q

3. If necessary, modify the name of the rule.

679

Using Environment Variables to Construct Rules


Use environment variables to construct rules that contain references to path locations that can change at run time. For example, an application data path can change depending on the language selected. This can lead to errors if you use the default rules for an isolation environment. Using an environment variable to construct path-specific segments (such as a language-specific application data location, AIE_COMMONAPPLICATIONDATA) ensures that an explicit rule is created for the selected language. At run time, AIE_COMMONAPPLICATIONDATA is substituted with the language-specific application data location such as C:\Documents and Settings\All Users\Application Data. Citrix recommends that you use an environment variable to ensure universality of a rule when any of the following conditions are true:
q

Path location contains a user name Translation issues can occur with standard application locations Relative locations can change; for example, the location where you install XenApp

Environment variables can also quickly check where certain paths are within a script. For example, to find out what the file system installation root for an isolation environment is, use AIE_FSINSTALLROOT. All environment variables for isolation environments are prefixed with AIE_. When you create a new isolation environment, a number of default rules apply. These default rules use the environment variables listed in the following table to make the rules universally applicable. To view the default rules for application isolation environments, refer to the list in the Rules wizard. Note: Exercise caution when using backslash characters (\) with these environment variables. Ensure that you insert a backslash (\) after an environment variable before adding additional path information; for example, AIE_USERAPPLICATIONDATA\MyData\Mine. This table shows environment variables available for isolation environments: Environment Variable Description Example C:\Documents and Settings\All Users\Application Data C:\Documents and Settings\All Users\Desktop C:\Documents and Settings\All Users\Start Menu

AIE_COMMONAPPLICATIONDATA Common application data location AIE_COMMONDESKTOP AIE_COMMONSTARTMENU Common desktop location Common Start menu location

680

Using Environment Variables to Construct Rules AIE_FSINSTALLROOT AIE_FSUSERROOT File system install root File system user root C:\Program Files\Citrix\RadeCache\MyAIE C:\Documents and Settings\Administrator\ Application Data\Citrix\RadeCache\MyAIE C:\Program Files MyAIE HKEY_LOCAL_MACHINE \SOFTWARE\CitrixRade Cache\MyAIE HKEY_CURRENT_USER \SOFTWARE\CitrixRade Cache\MyAIE C:\Documents and Settings\Administrator\ Application Data C:\Documents and Settings\Administrator\Local Settings\Application Data C:\Documents and Settings\Administrator \Desktop S-1-5-2001-

AIE_METAFRAME AIE_NAME AIE_REGINSTALLROOT

Installation location Isolation environment name Registry install root

AIE_REGUSERROOT

Registry user root

AIE_USERAPPLICATIONDATA

User global application data location User local application data location (including temporary files) User desktop location

AIE_USERLOCALDATA

AIE_USERDESKTOP

AIE_USERSID

Unique security identifier for the current user; it is used extensively internally for security checking. User Start menu location

AIE_USERSTARTMENU

C:\Documents and Settings\Administrator\Start Menu

681

Preparing a Workstation for Profiling Applications


Configure the profiler workstation to provide a run-time environment that is as close to your user device environment as possible. For example:
q

If applications are streamed to user devices, the profiler workstation should be a similar platform The profiler workstation should also include standard programs that are part of the company image, such as an antivirus program

For the full list of supported operating systems for targets, see the System Requirements for Application Streaming. In addition, profiles created on one operating system automatically run on compatible operating systems. For example, targets created on Windows XP 32-bit platforms automatically run on Windows 2003 32-bit platforms (and vice versa). Compatible operating systems include:
q

Windows XP 32-bit and Windows 2003 32-bit Windows XP 64-bit and Windows 2003 64-bit Windows Vista 32-bit, Windows 2008 32-bit, and Windows 7 32-bit Windows Vista 64-bit and Windows 2008 64-bit

Important:
q

Other than standard operating system software and utilities, ensure the workstation is clean of other software applications. Make sure that none of the applications or files you intend to add to the profile is installed on the profiling workstation. The profiler does not install files that already reside on the computer. Do not use the profiling workstation to store or stream applications. Do not install the Plug-in used for streaming, such as the Citrix Offline Plug-in or XenApp Streaming Plug-in, on this workstation.

Install the Citrix Streaming Profiler on a clean, nonproduction server or workstation. To achieve the ideal goal of a single target executing on multiple operating system versions, Citrix recommends in general to use the oldest candidate operating system for profiling, Windows XP Professional. If the created target works on all candidate execution operating systems, you are finished. If, however, a specific operating system level has issues with the multiple-operating-system target, rerun the profiler and create a new target specific to the failing operating system version. In this later case, for this target, run the profiler on the same level operating system that is intended for execution. 682

Preparing a Workstation for Profiling Applications After installing the profiler, simplify the creation or modification of profiles by setting profiling preferences.

683

Known Limitations for Profiling


Certain applications cannot be profiled, including:
q

Applications that include device drivers Applications that install COM+ 64-bit applications Applications that install DCOM (limited support) Other applications such as Microsoft Internet Explorer, Microsoft Data Access Components (MDAC), and the .NET framework

Important: If you profile an application that requires User Access Control (UAC) rights elevation or administrator rights, make sure that you configure access to the published application only for users and groups that have the required rights on the user device. If an application you are installing in a profile must interact with an application that cannot be profiled, Citrix suggests the following procedures: 1. Install the application that cannot be profiled, such as .NET framework, on the profiling workstation before you create a profile for the applications that interact with it. 2. While profiling the new application, enable pre-launch analysis to confirm that the non-profiled application is installed before the new application can launch. 3. Install the non-profiled application on user devices to run outside isolation so that the new application can interact with it as needed. Refer also to the known issues and workarounds in this release of the Streaming Profiler and Offline Plug-in.

684

To install the profiler


For best results, use the Windows uninstall program to remove any previous version of the Citrix Streaming Profiler. Important: Before you install the profiler, refer to the system requirements for application streaming for the supported platforms, system prerequisites, and Microsoft redistributable packages included with the installation. 1. On the workstation you want to use to profile applications:
q

Insert the installation media, and in the autorun window, choose Browse Media to locate the Application Streaming Profiler folder and run CitrixStreamingProfiler.exe.

Navigate to the Citrix Support Web site for downloads and locate the most current version of the profiler for application streaming. 2. Choose a language for the installer interface and complete the installation wizard.
q

3. After installation, restart the workstation.

685

To disable and enable profile signing


If you are not signing profiles, use the profiler preferences to prevent the digital signature pages from appearing in the New Profile and Target wizards. To set this default preference for all new profiles, from the Edit menu of the profiler window, choose Preferences and then select the Digital Signature tab. If you later decide to sign profiles, use the Digital Signature tab to restore the digital signature pages to the wizards.

686

To start the profiler


1. From the Start menu, choose Programs > Citrix > Streaming Profiler. 2. Select the Streaming Profiler.

When the profiler starts, the Welcome page appears. Use the Welcome page as an easy starting point for creating and modifying profiles. To see the profiler interface, on the Welcome page, click Close. The profiler interface includes four main components:

Menu and toolbar. Located at the top. The toolbar contains buttons that initiate the following actions:
q

Starting the New Profile wizard to create a profile Opening an existing profile Saving the current profiler to a file share Updating a target or application in the open profile

Adding a new target to the profile Navigation pane. Located on the left. When populated, lists a profile and its targets.
q

Profile and target information. Located on the right. Status bar. Located across the bottom.

After starting the profiler for the first time, set profiler preferences that optimize how you create profiles and targets. To set these default preferences for all new profiles, from the Edit menu of the profiler window, choose Preferences.

Save the default User Profile Security settings for all profiles you create. This relieves you of specifying enhanced or relaxed security as you create profiles. If you are not signing profiles, use the Digital Signature setting to hide the Sign Profile page in the wizards.

Preferences save time and improve usability by enabling you to store relevant settings for use in future packaging tasks.

687

Creating a Profile and Its Initial Target


After installing the Streaming Profiler on a workstation to create profiles, prepare for the decisions needed to create profiles. When you create a new profile, your first steps are to set the following profile properties:
q

Profile name Ability for users to update applications Optionally, inter-isolation communication with existing profiles

As you continue, choose the following configuration-matching criteria for the target:
q

Operating system Service pack level Language

Then you install applications in the target (although not on the workstation itself) through either advanced or quick installation procedures. Profiling a single, standard application in a target is called a quick install. If the target needs multiple applications or other resources, use an advanced install. You must complete a full installation and can then perform any initializations or customizations needed before users access the application. A target can offer any of the following resources:
q

Applications Internet Explorer plug-ins Folders and files Registry settings

Finally you can opt to digitally sign the profile. After you build the profile, manually save it to a file share in your App Hub where you can publish the profiled application for streaming to your users. Note that you can modify the profile at any time, including updating the application, add pre-launch or post-exit scripts, add pre-launch scripts, and modify the file type association. The changes are immediately available the next time users access the published application.

688

To create a profile and target


Ensure that a file share exists with the everyone group assigned READ access and the administrators group assigned WRITE access at both the share level and NTFS level.

From the profiler workstation, make sure that you have access to the executable for the application, but that the application is not installed on the workstation. Open the profiler from the Start menu. 1. To start the New Profile wizard, either select New Profile from the first screen, or if it is already open, from the File menu, choose New. Use the New Profile wizard to complete the remaining steps. 2. Name the profile. When naming a profile, choose a simple name. Do not include any criteria that will be used to identify targets. For example, do not include a version number in the profile name. 3. Use the Enable User Updates page to enable users to update applications on their user devices (disabled by default). When the feature is enabled, executable files that are accessed through the application (such as product-update executables) run from the user profile root and launch on the user device. When disabled, the executable files launch from the install root location, which prevents most product-update executables from updating applications automatically and lets you maintain and deliver updates centrally. 4. Use the Set up Inter-Isolation Communication page to link existing profiles that need to communicate with each other on the user device (optional). If you are not setting up inter-isolation communication, do not make any entries on this page. 5. Set at least one target operating system and language. By default, the wizard selects all operating systems compatible with the profiling workstation. To link existing profiles for inter-isolation communication only but not create any new targets, click the top check box (not selected by default). To create a new target or profile, ensure the check box is not selected. Setting the target operating system and language criteria are the first steps in creating the initial target for a profile. The default operating system and language are those of the operating system installed on your profiler workstation.

a. If you selected profiles for inter-isolation communication, to associate those existing profiles without creating a new target (and skipping the installation pages of the wizard), check Minimal Target. When selected, the remaining target creation options are disabled and the wizard skips the installation pages. It goes directly to Step 12, signing the profile with a digital signature. To create a new target within the linked profile, make sure the option is not checked.

689

To create a profile and target b. To support other operating systems and languages, select the check boxes associated with those you want to support. When selecting target operating systems and languages, do not select those languages for which you are going to create separate targets. c. To consider the service pack level, click Set Service Pack. By default a target matches all service packs of the operating systems it supports. d. When selecting the service pack supported by the target, use the Supported Service Pack Levels pull-down menu to choose a rule for considering the service pack level. e. Type the number representing the service pack level in the applicable field for Minimum Level, Maximum Level, Exact Level, or, if for a range, Minimum Level and Maximum Level. Note: For subsequent targets, to ensure the current target you are adding does not conflict with other targets in the profile, click Check for Target Conflicts. 6. Choose an installation option according to the type of application or number of applications you want to install in a target:
q

Quick Install. Select this option if you are installing only one application and it has an installation program, such as setup.msi or .exe (selected by default and recommended for normal installations).

Advanced Install. Select this option only if you are installing Internet Explorer plug-ins, editing registry settings, installing an application manually, or installing from multiple installers. 7. On the Choose Installer page, click Browse to choose an executable file or a script you run to install the application in the current target. In this step you are just choosing the installer, not running it. If needed, enter required command-line arguments.
q

8. On the Run Installer page, ensure the installation program and command-line parameters are correct. Use advanced installations to select resources, including files, folders, registry settings, and Internet Explorer and plug-ins to add to the profile. 9. Click Launch Installer. Wait until the installer program launches on the workstation. For large applications, this can take several minutes. Then complete a full installation for the application. The destination path shown in the installer does not matter because the application is installed in the profile, so accept the default location. 10. When the application is fully launched and configured on the workstation, close the application and click Next in the profiling wizard. If a restart is required to complete the installation, the profiler automatically performs a virtual restart. After the virtual restart completes, the application is ready to run. 11. On the Run Application page, select and run the application. Close the application before clicking Next in the profiling wizard. Tip: After completing a full installation, which installs the application for all your users, run the application once to ensure that you complete all needed initializations before delivering the application to users. For example, you might have to enter a product serial number or license key. In addition, take some time to configure 690

To create a profile and target preferences or options and to enable or disable features before you publish the application. For example, you might have to disable auto-updates to prevent users from receiving unwanted messages or files on their computers. 12. On the Select Application page, view the list of applications discovered in the current target. Use the buttons to modify the list of applications that you want to publish later using the AppCenter. 13. On the Sign Profile page, sign the profile with a digital signature, if needed. 14. Click Finish to build the profile. Before clicking Finish, you have the opportunity to review profile information and edit profile and target settings. 15. When the wizard closes, save the profile by typing the UNC path to the file share in your App Hub. Note that a subfolder is created with a name that matches the profile name. For example, if you enter the following path:

\\citrixserver\profiles The following Save To storage location appears, based on the values of UNC Path and Profile Name:

\\citrixserver\profiles\<Profile Name>\<Profile Name>.profile If needed, change the name of the profile at this point. Important: Windows File Explorer cannot handle file paths that exceed 256 characters, However, when profiling some applications, such as Microsoft Office 2010, the file paths might exceed that limit due to the high level of folder nesting. To prevent issues due to long file names, Citrix recommends using a utility such as Robocopy to replicate profile data without errors. This utility is available with Windows Resource Kit and is a feature in Windows Vista, Windows 7, and Windows 2008. After you save your profile, use other workstations to add unique targets to the profile, if needed.

691

To allow users to update applications


Use the Enable User Updates setting in the profiling wizard to determine whether or not files for streamed applications are executed from the profile directory of the user. You can set this option only when you create a profile for the first time. Important: After creating the first target, you cannot modify the setting for the profile. The setting that you select for the first target applies to all other targets that you add to this profile, even if you manually select a different setting for subsequent targets. Additionally, to set a default for all profiles, from the Edit menu, select Preferences. Use the Enable User Updates tab to prevent the User Updates page from appearing in the profiling wizards. Set the option for the profile:
q

Select the check box to permit executable files that are accessed through the profiled application to run from the user profile root. If you profile the application with this setting selected, the application can download vendor-supplied updates over the Internet. Any updates are stored as part of the user root, so they are unique to that user. The next time the user device connects to the profiled application on a server or file share, the streamed application will not overwrite the updates, and the application runs using the updates. Selecting this setting is recommended for streamed macromedia plug-ins, which download extensions (DLLs) based on the content that is being processed. Also, some applications decompress DLLs during runtime that need to run from the user root.

Clear the check box to ensure that all executables from the profile launch from the install root location and not from the user profile root location. Clearing this setting prevents most product-update executables from installing updates automatically on user devices and lets you manage the updates centrally through the wizards in the profiler. When cleared, the system specifically inhibits the ability to run code that is not streamed from the server. Administrators can enforce a cleanup policy to delete all session artifacts when the user closes the application or logs off. Note: If your testing finds that this setting does not prevent automatic updates for an application, look for a preference in the application installer to disable automatic updates when you run the application during profiling. Alternatively, disable or uninstall the update programs manually on user devices.

692

To set up inter-isolation communication


During the profiling process, set up inter-isolation communication for applications profiled independently that should interact as though they are integrated with other profiled applications. The order in which profiles are listed determines the precedence of isolation rules and operations for the applications in the inter-isolation communication profile. The rules that exist for each profile are merged into a single list of rules, with the rules of highest priority taking precedence. Important: Refer to the system requirements for user devices if you plan to deliver profiles with inter-isolation communication. 1. On the Set up Inter-Isolation Communication page of the profiling wizard, click Browse to locate the directory (not the files themselves) where your existing profiles are stored. To be linked, the profiles must all be located in the same directory. Make sure that each of the profiles you link has a target for the operating system of the profiling workstation. 2. In the Browse for Profiles box, click Browse to locate the directory where your existing profile directories are saved. For example, if you saved Adobe.profile in the following location:

\\hostname\fileshare\Profiles\Adobe\Adobe.profile navigate to the Profiles directory (the grandparent of the profile file). To be added, all the profile directories must be located in a single directory, such as Profiles in the example. 3. Click the check box of the individual profiles to link in this profile. 4. When you highlight a profile, use the Move Up and Move Down buttons to set the order of priority. For example, if you create a linked profile for Microsoft Office 2007 and Adobe Reader (any version), make sure that Office 2007 is the top-level application in the profile, which ensures that the Office isolation rules take priority over those of Adobe Reader. This priority is required for Office applications to launch correctly. 5. For new profiles, continue in the wizard to the Set Operating System and Language page:
q

To link existing profiles only (the profiles you selected on the previous page) but not create any new applications or targets, called an associated profile, check the top check box (not selected by default). When you click Next, the wizard skips the installation pages and goes directly to the final step, signing the profile with a digital signature.

693

To set up inter-isolation communication


q

To create an additional target or application in this profile, called a dependent profile, make sure the top check box is not selected and continue using the wizard to create the new target or install the application in the profile. Use this option if the new target or application is to be dependent on the profiles you selected on the previous page.

6. On the lower part of the page, carefully review the lists of operating systems and languages. Important: Each profile must contain a similar set of targets as all the other profiles in the linked profile, including a target that matches the profiling workstation. Note the superset of operating systems, service packs, and languages contained in all the linked profiles, and then check to make sure that each linked profile contains a target for all the operating systems, service packs, and languages in the superset. User devices must have a target in each of the linked profiles or they cannot launch any applications in any of the linked profiles. Available. This profile property is available in the common range of target configurations. Not Available. This profile property is missing in one or more target configurations.

Continue the installation using the profiling wizard, as normal. After you save the profile enabled with inter-isolation communication, publish the applications using the Citrix AppCenter in XenApp. To view or modify the contents of the inter-isolation communication profile, from the navigation panel, select the profile; from the Edit menu, select Profile Properties; and from the navigation pane, select Linked Profiles. Linked profiles are stored within the .profile file by name rather than by the path. At application launch, the profiler service searches the INSTALLROOT locations of the linked profiles. When the user device runs a profile enabled for inter-isolation communication, the user-level settings that are stored on that user device by an application in one of the individual profiles are ignored, and the user-level settings of the application start fresh as if the application is being launched for the first time. To change this behavior, write a pre-launch script to migrate settings from specific applications whenever the linked profile is executed on the user device.

694

To select an install option


In the profiling wizard, choose an installation option according to the type of application or number of applications you want to install in a target:
q

Quick Install. Select this option if you are installing only one application and it has an installation program, such as setup.msi or .exe (recommended for normal installations). Advanced Install. Select this option if you are installing Internet Explorer plug-ins, editing registry settings, installing an application manually, or installing from multiple installers. Also, use this option to update profiles built using a previous version of the profiler. Enhancements from the new version of the profiler are applied to the profile. You can perform more installations or finish the profile.

695

To install multiple applications through Advanced Install


The Advanced Install option of the profiling wizard provides the opportunity to repeat the installation procedure as many times as you need to add multiple applications to a target. 1. Choose the type of resource you want to install:
q

To install an application in the target, choose Run install program or command line script. This option runs a wizard similar to the quick install. To install Internet Explorer and plug-ins so they run in isolation, choose Install IE plug-ins. To add files and folders that might be needed on the user device or to remove unneeded files and folders, choose Select files and folders. For example, use this option to include required files that are on the profiler workstation, but might not be on the user device.

To customize the registry as viewed by the user device, choose Edit registry. Each of these options provides you with the opportunity to return to this screen and install additional applications.
q

2. After you complete an installation, you have the option to install additional resources in the target. If needed, check the option to Run an application before the next installation. 3. After installing all the applications you want to include, choose Finish or Continue with none of the above, which enables you to finish creating the target.

696

To choose an installation program for the application


Select the initial executable for the application in the profiling wizard. To update an application in an existing profile, open the profile, select the target, and from the Edit menu, select Update/Install Application. On the Choose Installer page:
q

Click Browse to choose an executable file or a script you run to install the application in the current target. In this step you are just choosing the installer, not running it. Note: Make sure that the application is not currently installed on the profiling workstation. Files that exist on the profiling workstation are not added to the profile, causing the application to fail when launched from the profile.

Optionally, add a command-line script. Command-line arguments run a streamed application by modifying its properties in the target. If you add placeholders in the profile, they are replaced by command-line arguments specified when you publish the application. Command-line parameters can modify application properties after you install the application during the target creation process (in the New Profile or Add New Target wizards) or by editing application properties after you create the target. If you do not use a placeholder in the profile, the extra parameters specified when publishing an application are added at the end of the command-line.

Example of Placeholders and Command-Line Parameters


Use profile arguments to specify command-line arguments that you always want to apply during application launch, such as arguments necessary for the application to function. Use the published applications command-line arguments to fine-tune the application. If you add the ** placeholder to the Command line parameters (optional) text box in the profiler, the placeholder is replaced with the command-line arguments for the published application. To do this:

1. Specify the following arguments and placeholder in the profiled application: app.exe /a ** /b where <app.exe> is the application executable that you are profiling.

697

To choose an installation program for the application 2. Publish the application with the following arguments. (%* specifies the content redirection arguments.) /x %* /y Launch the application with content redirection. For example, on a file named my.doc, the steps are: 1. The profiled application command-line is used. app.exe /a ** /b 2. The ** placeholder is replaced with the published application arguments. app.exe /a /x %* /y /b 3. The file for content redirection replaces the %*, producing the final command-line. app.exe /a /x my.doc /y /b

698

To create a virtual hard disk


For pooled XenDesktop environments, in the profiling wizard, Citrix recommends using the option to Create virtual hard disk (VHD) for this target to improve application launch time. This option is not needed in other deployments, but if enabled, it does not interfere with normal behavior. Tip: If selected, the profiling workstation and the App Hub need up to twice the amount of disk space available as is normally used for the profile. In addition to creating the normal directory files, this option creates a virtual hard disk (VHD) while profiling. If selected, the first time users launch the application:
q

In pooled XenDesktop environments, the Offline Plug-in checks the UseVHD registry setting, and if it is set to mount the VHD, the launch copies all profile contents to the VHD in the RadeCache location in the App Hub. Subsequent launches access the files stored on the VHD, which speeds up launch time. Note: If you provisioned the pooled XenDesktop through Citrix Provisioning Server or XenDesktop Controller, the Offline Plug-in automatically detects the need to mount the VHD, regardless of this setting.

In other environments, the application launches from the directory files in the App Hub, as usual.

This option does not support:


q

Applications streamed using HTTP protocol Offline access to streamed applications

For linked profiles (those enabled for inter-isolation communication), an application launches from a VHD only if the option is enabled for its individual profile. For example, if you profile the first application and select the VHD option, and then link the profile to a second profile without the VHD option, only the first application launches from the VHD; the second application launches from the directory files in the App Hub, as usual. To unmount the VHD With administrator privileges, from the command-line, use either of the following commands:
q

radecache /flush:GUID radecache /flushall

To mount the VHD on non-pooled XenDesktop devices In addition to pooled XenDesktop environments, this option is also beneficial in environments that operate without a physical hard disk, such as XenApp running on virtual servers. If the RadeCache location for the "local" hard disk is across the network to a virtual 699

To create a virtual hard disk infrastructure, you can manually set the UseVHD registry to mount the VHD (recommended by Citrix). On the user device, create the registry key:
q

For 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade\UseVHD For 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade\UseVHD

Set a DWORD value:


q

0: Do not mount (default on non-pooled XenDesktop devices). 1: Mount occurs. The VHD attempts to be mounted in the RadeCache folder at the time of sandbox creation.

To configure a fallback method manually For situations where the VHD fails to mount, you can create a registry key with a fall-back option:
q

For 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade\ VHDErrorFallback For 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade\VHDErrorFallback

Set a DWORD value:


q

0: Deny application launch if there is no VHD or mounting the VHD failed because of any other reason. 1: If the VHD is not present, launch the application, but if the VHD cannot be mounted, deny application launch (default behavior, even if registry entry is not created). 2: Launch the application.

700

To support legacy plug-ins


By default, the Streaming Profiler 6.5 creates SHA-256 hashes, and the Offline Plug-in 6.5 uses SHA-256 to verify the contents of the profile and verify the integrity of strings and buffers. The Offline Plug-in 6.0.x, however, launches applications only from profiles with SHA-1 hashes, such as from version 6.0 of the profiler. To enable 6.0.x plug-ins to launch profiles created with Streaming Profiler 6.5, select this option to provide the additional hashes. Use this option during a transition period where both hashes are needed until all Offline Plug-ins have been updated to 6.5. SHA-2 is fully supported on Windows Server 2008 R2. For earlier Windows platforms, see the Microsoft documentation. If selected, the time required to generate both hashes increases the profiling time. To add the SHA-1 hashes in profiles created or updated with version 6.5 of the profiler:
q

In the profiling wizard, on the Legacy Offline Plug-in Support page, select the option to Enable support for 6.0 offline plug-ins. To set the preference for all profiles, from the Edit menu, select Preferences > Legacy Offline Plug-in Support, and select the check box. The setting becomes the default in the profiling wizard for all profiles created or updated after setting this option.

For more information about security standards that apply to Citrix products, see XenApp 6 Security Standards and Deployment Scenarios in Citrix eDocs.

701

To install Internet Explorer plug-ins


Use this Advanced Install option while running the profiling wizard to make Microsoft Internet Explorer available as a streamed application so that it runs inside isolation on the end-user device. 1. If you have Internet Explorer running, close it. 2. While running the New Profile or New Target wizard, complete the initial options and choose the Advanced Install option. 3. From the Select Install Method window of the wizard, choose Install IE plug-ins. 4. Click Launch Microsoft Internet Explorer. This command runs Internet Explorer in an isolation environment. 5. Using Internet Explorer, install all the plug-ins to be made available to your users.

702

To include files and folders in a target


Use this option to include specific files and folders that are not installed by an application installer but are required for the application to run. This method can also profile applications that do not need to be installed to run. 1. While running the New Profile or New Target wizard, complete the initial options and choose the Advanced Install option. 2. From the Select Install Method window of the wizard, choose Select files and folders. 3. Select the files and folders you want to include. a. Use the Look in pull-down menu to select files and folders to include in the target. b. In the Select files list, select the files you want to include in the target and click the arrow to add them to the Current files lists. c. Use the buttons at the bottom of the Current files list to create new folders, rename files and folders, or delete files and folders in the Current files list. 4. The profiler automatically performs a virtual restart if a restart is required to complete the installation. 5. Click Finish Installations and click Next. 6. On the Run Application page, click Add (do not select the Run option). 7. In the Open dialog box, enter a shortcut name and browse to the executable name that you want to run, but make sure to stay within the Device\C folder. Do not browse to the source location; the path is connected automatically. 8. Finish the profile, save it to the App Hub, and publish the application in the Citrix AppCenter.

703

To include registry settings


Use this option to provide customized registry settings in a target. 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. If you have Windows Registry Editor open, close it. 2. While running the New Profile or New Target wizard, complete the initial options and choose the Advanced Install option. 3. From the Select Install Method page of the wizard, choose Edit registry. 4. Click Launch Windows Registry Editor. 5. Use Registry Editor to make the registry changes you want to include in the target. The registry changes you make are included in the isolation environment of the target, not the registry on your profiler workstation. 6. The profiler automatically performs a virtual restart if a restart is required to complete the installation.

704

To install an application in the profile


In the profiling wizard, on the Run Installer page, ensure that the installation program and command-line parameters that you selected on the previous page are correct. This step performs a virtual installation of the application in the profile, but not on the profiling workstation. 1. Click Launch Installer. Wait until the installer program launches on the workstation. For large applications, this can take several minutes. 2. Complete a full installation for the application, including running the installation wizard. The destination path shown in the installer does not matter because the application is installed in the profile, so accept the default location. 3. When the application is fully launched on the workstation, close the application and click Next in the profiling wizard for the profiler to discover the newly installed application. If a restart is required to complete the installation, the profiler automatically performs a virtual restart. After the virtual restart completes, the application is ready to run on the next page of the wizard.

705

To run an application in the profiler


Many applications require initialization on the first launch of the program, such as accepting the license or supplying a license key. As a best practice, use the Run Applications page to perform these tasks for your users. On the Run Application page:

If the application is not already in the list, click Add and browse to and select the application executable file Select the application in the list and click Run

After the application is fully initialized, close it and continue in the profiling wizard by selecting the applications that you want to make available for publishing.

706

To select applications for listing in the profile


Use the Select Applications pane of the New Profile, New Target, and Update Application wizards to list applications in the target and make them available for publishing later in the Citrix AppCenter. In the Select Applications pane, all previously listed applications from other targets in the profile are listed as well as applications discovered in the current target you are adding.
q

Application Name gives you an indication as to whether or not you must modify the application name. If the names of applications in multiple targets match, those applications are considered available in those targets. To add other, undiscovered applications you installed in the target, click Add and browse to and select the applications you want to add to the Applications list. To remove applications from the list, select the unwanted applications and click Delete. This removes the applications only from the list. It does not delete the application from the target. If you want to change properties of the application before completing target creation, select the application whose properties you want to change and click Modify. Change properties including the name, version number, location of the executable, current working directory, application icon, and command-line parameters. An example of when you might want to change an application property is when the name of the application contains a version number or is different from the same or similar applications in other targets. In such a case, remove the version number or change the name so the application is recognized as existing in other targets.

If the Applications list is not populated, click Recover to find newly installed applications and populate the Applications list.

707

To sign a profile
Application streaming to desktops can use digital signatures to authenticate the origin and integrity of profiles signed by a trusted publisher. The signed profile applies to all applications and files contained in the profile. Applications from signed profiles are checked by user devices that have a trust list installed and can authenticate the code-signed certificate against the trust list. When signing is enabled, the user device checks the integrity of each file as it is cached. After you install and configure your code-signing certificates, sign profiles through the New Profile, New Target, and Update Target wizards. To view or modify the signature settings for the profile, from the Tools menu, select Sign Profile. To sign a profile, you need a code-signing certificate on the profiler workstation and a Certificate Trust List certificate for certificate verification on the user device. Also, you must know the password for the certificate you are using to sign.
q

To sign the profile using a certificate residing on the drive, choose Sign using key from selectable file and browse and select your certificate file To sign the profile using the code-signing certificate installed on your profiler workstation, choose Sign using locally installed certificate

Signing a linked profile created for inter-isolation communication does not sign the individual profiles automatically. Instead, each linked profile must be signed separately. Remove a signature from a signed profile at any time by opening the profile, and from the Tools menu, select Unsign Profile. Additionally, to set a default signature setting for profiles and skip this page in future profiling, you can set a preference to disable or enable profile signing.

708

Editing Profiles
After you create an initial profile and target, use the profiler to modify and maintain the profile. For example, to make applications available to more user devices, add targets to a profile that match additional and unique combinations of target criteria. For example, you can add separate targets for English, French, German, and Japanese language-based operating systems. Use the profiler to add new targets, delete targets or folders from a profile, delete old profiles, and resolve invalid shortcuts or target conflicts. Note: For steps to revert back to an older version of a profile, see http://support.citrix.com/article/CTX120436. To modify the profile properties, with the profile open in the profiler, select the profile name, and from the Edit menu, select Profile Properties. Profiles have the following properties:
q

Information. Contains general properties, which are the name, description, location, size, and creation and modification dates of a profile. Applications. Lists the settings of all applications from all targets and their availability. File Types. Lists the file types registered for the applications in the profile. Linked Profiles (visible for profiles set up for inter-isolation communication only). Lists the individual profiles included in the linked profile. User Profile Security. Specifies type of security enabled for the profile. Pre-launch Analysis. Enables the profile to examine the user device for the existence of required applications, files, or registry entries before streaming the application. Pre-launch and Post-exit Scripts. Adds scripts to run prior to and following the execution of applications in the target.

709

To view profile information


1. Start the profiler by opening the Start menu and choosing Programs > Citrix > Streaming Profiler > Streaming Profiler. 2. To open the profile, from the File menu of the profiler, choose Open. 3. Select the manifest (.profile) file of the profile stored on the file share. (Alternatively, click Open Profile on the Welcome screen.) For example: \\hostname\fileshare\Profile Name\Profile Name.profile When you open a profile, the profiler displays tabs for the following profile information:
q

Information Targets Applications File Types

Digital Signatures From the Edit menu, choose Profile Properties to view the profile properties.
q

4. Select the target in the left pane of the profiler to view information about a target. The right pane displays the following tabs for information about the target:
q

Information Applications

File Types Select the target, and from the Edit menu, choose Target Properties to view the target properties.
q

710

To edit the profile name, description, or location


You set the name, description, and location of the profile while using the profiling wizard. To view or modify the setting later, from the navigation panel, select the profile; from the Edit menu, select Profile Properties; and from the navigation pane, select General. This page displays the following information about a profile:
q

Profile name. Manifest name of the profile. To modify the name or folder location on the file share, select File > Save as, and enter the new Profile name or path; for example, a UNC might be: \\hostname\FileShare\Profile Name\Profile Name.profile. Description. Add or modify a description of the profile. Location. The storage location of the profile. Size. The size of the profile. Created. The date set by the profiler. Last updated. The date set by the profiler.

711

To view details about applications in a profile


Use the application properties to view the settings for all the applications from all targets and their availability. When an application is available, you can publish it using the Citrix AppCenter included with XenApp. To view the settings for the applications in the profile, from the navigation panel, select the profile; from the Edit menu, select Profile Properties; and in the navigation pane, select Applications. The page lists the applications in the profile and whether or not the application is available in all targets in the profile. To view more information about an application included in the target, select the application and click View Details. The details displayed about the listed application are:
q

Name of the targets in which the application is installed Whether or not the application is available in all targets Version number of the application Path to the application within the isolation environment Working directory the application uses within the isolation environment

Note that the version number displayed here is not the same as the target version number. The version number displayed here is set by the application installer. Alternatively, click Find Application if the application is missing from the target. To modify the remainder of the properties, update the target in which the application is installed.

712

To view File Type Associations set in a profile


Specify the File Type Associations (FTAs) initially in the profiling wizard. FTAs are used during application publishing so that opening a file of a certain type on the user device invokes this streamed application. The profiler detects FTAs automatically for the application (adding custom FTAs is not supported in the profiler). To view or modify the setting later, from the navigation panel, select the profile; from the Edit menu, select Profile Properties; and from the navigation pane, select File Types. The File Types page displays the following information:
q

File type extension. Description of the file type. Application invoked by the file. Whether or not the application is currently available to users. Use the options on the page to view the details about file types for each target in the profile.

To modify these properties, update the target in which the application is installed.

713

To check for launch prerequisites


After testing a profile, if you determine that user devices must have certain applications installed locally to run the application, such as a version of Microsoft Internet Explorer, you can enable a pre-launch analysis of the user device. When enabled, if a user device does not have the prerequisites for the profiled application to run correctly, profile execution stops and alerts the user of the problem. To specify these requirements, from the Edit menu, select Profile Properties and use the Pre-launch Analysis page and check Enable pre-launch analysis to inspect the user device for prerequisites before streaming the profiled application. By default, you define analysis for a profile and all its targets. If you determine that a target requires an analysis that is different from the default for the profile, select Edit > Target Properties, clear the Use profile settings check box, and specify the analysis for the target. On the Pre-launch Analysis page, click Add Item under the section appropriate to what you want to add: Applications and files or Registry entries. The prerequisites that pre-launch analysis can look at are:

Applications and versions (specific or a range) Binary files and versions (specific or a range) Registry entries

714

To check for prerequisite registry entries


After clicking Add Item from the Registry entries section of the Pre-launch Analysis tab, use the Add Registry Entry dialog box to specify the registry entry you want to identify as a prerequisite. To identify a registry entry, provide the required hive, key, value name, and type information: 1. From the Registry type drop-down list, choose a selection:
q

Key exists. The key must exist, whether or not it has subkeys or values. Key and value exist. The key must have a value of the specified type, but the data is not checked. Key and value exist, and data matches. The key must have a value of the specified type, and the data for the value must exactly match the specified data.

Key exists, and data for default value matches. The key must exist, and the data for its default value must match the specified data. 2. From the Hive drop-down list, choose the registry hive in which the registry entry resides:
q q

HKEY_LOCAL_MACHINE HKEY_CURRENT_USER HKEY_CURRENT_CONFIG HKEY_CLASSES_ROOT

HKEY_USERS 3. Type the name of the key. The following is an example: Environment
q

4. Type the value name. The following is an example: TEMP 5. To select the matching registry type for the prerequisite you are choosing, use the Type pull-down menu:
q

String value (REG_SZ) Binary value (REG_BINARY) DWORD value (REG_DWORD) Multi-string value (REG_MULTI_SZ) Expandable string value (REG_EXPAND_SZ)

715

To check for prerequisite registry entries


q

QWORD value

6. When you select a type, the list updates to reflect the registry entries.

716

To check for prerequisite applications and files


After clicking Add Item from the Applications and files section of the Pre-launch Analysis tab, use the Add dialog box to add an application or binary file: 1. Choose the application you want to identify as a prerequisite. (Note that the list of applications is static.) 2. Browse to and choose the binary file you want to identify as a prerequisite. 3. Select whether or not you want to check for a specific version or range. You must supply Version, Minimum Version, or Maximum Version. Version must be exact. Minimum Version and Maximum Version are inclusive and must be numeric.

717

To specify pre-launch and post-exit scripts


After testing a profile, if you determine that certain operations are required before or after running the application, you can write scripts and add them to the profile. To specify these operations, from the Edit menu, select Profile Properties and use the Pre-launch & Post-exit Scripts page to select scripts. By default, you define scripts for a profile and all its targets. If you determine that a target requires scripts that are different from the default for the profile, select Edit > Target Properties, and on the Pre-launch & Post-exit Scripts page, clear the Use profile scripts check box, and specify the scripts for the target. On the Pre-launch and Post-exit Scripts page: 1. Click Add Item next to Pre-launch scripts or Post-exit scripts. 2. Choose whether or not to run the script within the isolation environment by clicking one of the option buttons Isolate script or Do not isolate script. 3. Select the script you want to use. 4. Specify any command-line parameters required by the script. 5. Specify the order in which they run. The Offline Plug-in runs scripts in the order they are listed.

Pre-launch and post-exit scripts are commonly CMD files, but can be any file executable by Windows. You create pre-launch and post-exit scripts independent of the profiler. Valid file extensions are included in the PATHEXT environment variable, which shows a list of file extensions that are considered to be executable. In addition to the default file extensions, add new file extensions, if needed, by adding them on the profiling workstation in the system variable PATHEXT. Complete these changes before you launch the profiler, or re-launch it to capture the updates. After you add them, they are read from the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment in the PATHEXT element. For example, to copy dynamic files each time a user launches a certain application, create a VB Script or batch file that copies those files or runs a utility each time the application starts and exits.

718

To add a target to a profile


When adding a target to a profile, ensure the target is unique from other targets in the profile. The profiler does not permit saving a target that overlaps with any other target in the profile. 1. In the navigation pane of the profiler, select the profile. 2. From the profiler Edit menu, choose Add New Target. 3. Set target operating system and language. If the new target overlaps with other targets in the profile, a message box appears showing the target conflict. For more information, see To resolve target conflicts. 4. Choose an installation option according to the type of application or number of applications you want to install in a target, and finish the wizard.

719

To resolve target conflicts


After creating an initial target, additional targets cannot have overlapping operating systems, service pack levels, or languages. To resolve target conflicts in the profiling wizard, you must either change the supported languages to remove the language overlap, or change the operating systems and service packs to remove the operating system overlap. Conflicts occur when your new target overlaps or duplicates the configuration of an existing target. Target conflicts include all of the following situations:

Operating system overlap. Both targets support an operating system and service pack level. For example, if both targets support Windows Vista with no service packs, there is an operating system overlap. Language overlap. Both targets have at least one language in common. System drive overlap. Both targets have the same boot drive. However, the boot drive of a target cannot be changed after the target is created.

More simply, two targets overlap if:

There is an operating system overlap and There is a language overlap and The boot drive letters are the same

For example, the following targets overlap because they share an operating system, language, and boot drive, and they cannot coexist in the same profile:

Target A: Windows XP Professional [SP 2 and above] and Windows Server 2003 with CPS [all service packs] English and French languages Boot drive C

Target B: Windows XP Professional [all Service Packs] English language

720

To resolve target conflicts Boot drive C

721

To resolve invalid shortcuts


If a message appears referring to invalid shortcuts, the profiler did not install the applications referred to by the shortcuts in the list. Whether or not this is an error depends on which programs you intend to publish. Important: Files that exist on the profiler workstation's hard drive are not installed in targets. Even if the profiler workstation appears clean and has no installed applications other than the profiler, sometimes essential programs like antivirus software include other program installations. In addition, some uninstallers do not remove all program files from the hard drive. What should you do?
q

If the missing application is not needed for your publishing, do nothing. Click OK and proceed. If the missing application is one that you intend to publish, cancel the wizard, exit the profiler, and remove the existing files from the profiler workstation. Then repeat the profiling operation.

722

To delete a target from a profile


1. Start the profiler by opening the Start menu and choosing Programs > Citrix > Streaming Profiler > Streaming Profiler. 2. To open the profile, from the File menu of the profiler, choose Open. 3. Open the manifest (.profile) file of the profile stored on the file share, such as: \\hostname\fileshare\Profile Name\Profile Name.profile 4. In the left pane of the profiler, select the target you want to delete. 5. In the right pane, click the Information tab and note the location. 6. From the Edit menu, choose Delete Target. When you save the profile, the profiler deletes the associated target directory from the profile on the file share and removes associated entries from the profile manifest.

723

To delete a folder from a profile


1. With the profiler open, select the target and click Update/Install Application. 2. When the updating wizard opens, select the Advanced Install option. 3. Click Select files and folders. 4. In the Current files pane, select the target files or folders and click the icon to delete them. Finish the profiling wizard.

724

To remove a profile from a linked profile


If a profile is linked to a profile that is enabled for inter-isolation communication, you can remove the link by editing the properties of the inter-isolation profile. 1. Open the profile enabled for inter-isolation communication. 2. From the Edit menu, open the Profile properties. 3. Click the Linked Profiles tab. 4. Clear the check box for the profiles that you want to remove from the inter-isolation communication profile. When you save the linked profile, the profiler deletes the target directory from the profile on the file share and removes linked entries from the profile manifest.

725

Editing Targets
If users experience problems running applications in a profile, edit the target properties to resolve some of those problems. To view the targets, with the profile open in the Profiler, select the target and from the Edit menu, select Target Properties. Targets have the following properties:
q

General. Contains name and description, as well as the operating systems, languages, boot drive, version, location, and creation and modification dates of the current target. Applications. Contains names and version numbers of applications installed in the target, as well as the paths to the application executables, and whether or not the applications are available in all the other targets in the profile. Target Operating System and Language. Specifies the user devices that can run applications installed in the target. Rules. Governs how the isolation environment functions when running an application on the user device. Pre-launch Analysis. Ensures the existence of required applications on the user device and required registry entries in the isolation environment before streaming the applications in the target. If the check box to Use Profile settings is selected, the settings are identical to those in Profile Properties. Pre-launch and Post-exit Scripts. Specifies the scripts to run prior to and following the execution of applications in the target. If the check box to Use Profile settings is selected, the settings are identical to those in Profile Properties. Services. Lists the services installed in the profile that are available for the target, including the logon name, path, and start type (manual or automatic). When started, these services run in isolation on the user device.

726

To edit the target name and description


Modify the description of a target on the General tab of Target Properties. The target name that you select when you create the target cannot be changed except by the user. Use the properties to modify or add a description and view the creation and modification time stamps of a target. These are set by the profiler at the time you save a target.

727

To modify the application properties in the target


Use the Applications page of Target Properties to view information about or manage the applications installed in the current target. The Application page displays the following information about listed applications:
q

Application name. Manually set from the profiler by the administrator when the application is installed in the target. Availability. Specifies whether or not the application is available, not in this target, or not in other targets. Version. Set by the administrator who installed the application into the profile. Path and Working Directory. Set by the application installer. The path is not the true path to the application executable, but it is the path simulated by the isolation environment. Command line parameters. Manually set from the profiler by the administrator when the application was installed.

To modify the list of applications, use the following methods:


q

To recover or add applications to the list: If you suspect the list of applications is not complete, click Recover to force the profiler to discover all applications installed in the target. If the operating system of the workstation on which you are currently running the profiler does not match the operating system of the current target, the recover function is not available. If you want to browse to an application and add it manually, click Add. When you add or recover an application, data about the application is added to the profile manifest file.

To delete files from the list: You might want to delete an application from the list if it is auxiliary, as with an uninstall or update application. When you delete an application from the list, the profiler removes only application data from the profile manifest file. The profiler does not delete the application files. Add a deleted application back to the list by clicking Recover or Add.

To modify an entry in the list: You might want to modify an application in the list if the application name or icon is different from other similar applications in other targets or contains a version number.

728

To modify the application properties in the target

729

To modify the operating system and language properties of a target


To expand or restrict the different user devices that can run applications in a target, use the Target Operating System and Language tab of Target Properties to modify these properties. 1. Under target operating systems, check the operating systems you want user devices to match to access the current target. 2. To modify the service packs required for a match, click Set Service Pack and then specify the service pack criteria. 3. Under target language, check the languages you want user devices to match to access the current target.

The updated settings apply to targets when you save the changes.

730

To update a target
To upgrade an application within a target or add applications to a target, use the profiler to update a target. When you update a target, the profiler increments the version number and saves the target as a new file in the profile. To provide uninterrupted service to your users, the profiler maintains multiple versions of each target. After you save the profile, user devices use the most recent version of the target for new application executions. Application executions that are in progress continue to use the version of the target that was current when the applications were invoked. This enables you to update targets without forcing your users to exit the applications and restart. The next time the users run the application, they run the newest version in the target. After saving an updated profile, do not use the profiler to delete or modify previous versions of an updated target. 1. In the left pane of the profiler, with the profile open, select the target whose application you want to update. 2. From the Edit menu, choose Update/Install Application. 3. Choose an installation option according to the type of application or number of applications you want to install in a target.
q

If you want to update a single application in a target or add a single application to a target without adding any additional files, folders, or registry entries, choose Quick Install. If you want to add multiple applications in a target or add Internet Explorer plug-ins, files and folders, or registry settings to the target, choose Advanced Install.

After you update the target, save the updated profile in the original location. The next time user devices connect, they stream the updated profile. If user devices have a previous version of the cabinet file stored in the cache (such as applications enabled for offline access), the streaming service uses a technique called differential synchronization to open the cached cabinet file on the user device and compare it with the updated cabinet file in the profile. The service updates only the changed files and removes outdated files from the cabinet file in the cache. This feature reduces the time and bandwidth needed to update applications on the user device.

731

To remove an old version of an updated target


To recover disk space on the file share that hosts your streaming application profile, delete prior versions of a target that has been updated. The prior versions of an updated target are no longer available through the profiler. Do not manually remove the most recent version of a target. 1. In the left pane of the profiler, with the profile open, select the target whose application you updated. 2. In the right pane, on the Information tab, note the path to your updated target directory folder. The trailing integers of the folder name represent the target version number. For example, the version of the following folder is 2:

\\hostname\fileshare\Profile Name\720edd68-0972-49e6-aa00-80974eb81d5b_2 To choose directory folders that are obsolete, identify the folders that have trailing integers of the least value. 3. Use Windows Explorer to delete the obsolete folders from the profile on your file share.

732

Profile Contents on the Server


After you create and store an application profile on a file server, the profile consists of directories and subdirectories of files. For your reference, this topic describes the structure of profile directories and the files in them. Citrix recommends that you do not modify these files directly. Use the profiler to modify the contents of the profile folder:
q

Profile manifest file (.profile), an XML file that defines the profile Target directory providing isolation environment contents for applications in the targets Hash key file (Hashes.txt) for digital signatures and signing profiles Icons repository (Icondata.bin) Scripts folder for pre-launch and post-exit scripts

For example, if you create a profile called PDF Viewer with a single target, the profile, a folder called PDF Viewer, has contents similar to the following on the file share:
q

PDF Viewer.profile (the manifest file) 720edd68-0972-49e6-aa00-80974eb81d5b_1 (the target directory folder, first version) Hashes.txt Icondata.bin Scripts folder

733

Manifest File
The manifest (.profile) is the top file in the data structure that defines a profile. The manifest file is an XML-formatted text file that describes a profile. Manifest files have the file extension .profile. The information in a manifest file includes:
q

Description Create date Modify date User profile security (Boolean) Scripts File type association Internet Explorer application (Boolean) Applications Targets

The manifest file of a profile created for inter-isolation communication includes references to the subprofiles and may or may not have targets listed in the manifest file.

734

Targets
Each target consists of a set of files representing a compressed subdirectory structure within the profile structure. Target file names are based on the target GUID and version. The association to a user level concept, such as MS Office, comes from the profile manifest. Each time a target is created, it is assigned a GUID so it can be uniquely identified and independently cached on the user device. The GUID is used to set the name of the isolation environment so that no two different installations of the same named target occupy the same location in the execution system cache. The directory used to store the isolation environment on the user device also includes the version number of the target. In this way, when you update a target, user devices are assured that the execution InstallRoot accurately reflects the install root of the target you defined. For speed, the user device locally updates the internal file cache when a target version is updated rather than reloading from the server. If a profile is copied (including its targets), the GUID is unchanged. If a profile is new (when you use save as), the new profile has new targets, and new GUIDs are assigned for the targets in that profile. Use them to maintain each profile separately without conflicts if you update either one.

735

Digital Signature
You have the option of digitally signing the contents of a profile. The manifest file indicates if the profile is signed, and when signed, the manifest file is digitally signed to sign the entire profile. The hashes for all files in a target are stored in a single file, Hashes.txt. The SHA-256 of the Hashes.txt file in the profile is stored in the manifest, and the SHA-256 hash of each target in the profile is stored in the manifest. Because the manifest file is digitally signed, the SHA 256 of each file listed in each Hashes.txt file can be authenticated.

736

Icons
To keep the manifest file size small, the binary data that represents the application icons is stored in a separate file called icondata.bin. The profiler stores all icons for the installed application. When you publish the streamed application, you have the option to change the icon by choosing among the set of icons that the application installed or other icons that you prefer.

737

Scripts
Specify when the Citrix Offline Plug-in should execute scripts associated with a profile or target:
q

Before the Plug-in executes the first application from a profile After the Plug-in terminates the last application from a profile

Intermediate applications executed from a profile do not invoke pre-launch or post-exit scripts. Scripts are commonly .CMD files, but can be any file that Windows can execute. Create pre-launch and post-exit scripts independent of the profiler, and after creating a script, use the profiler to add the script to a target, including these settings:
q

A disk file that is executed Arguments for the executable A Boolean value indicating whether or not the script is enabled

When you add a script to a target, the profiler copies the script file to the profile. The profiler also retains the original file name of the script. If an .EXE script requires a .DLL file, add a script for the .DLL file and disable it. The .DLL file is available for the script to load, but the user device does not run the disabled .DLL. For example, use this technique to add a signed .DLL to the profile even though it is not executed.

738

Publishing Streamed Applications


To stream applications to user devices, start by reviewing the System Requirements for Application Streaming. Before publishing an application for streaming, you must use the Citrix Streaming Profiler, a stand-alone utility, to create a streaming application profile and save the profile on a network file share or Web server (your App Hub). For instructions, search for Creating Application Profiles. In particular, see To create a profile and target, as well as other topics in that section. After creating the application profile, continue by publishing the application to make it available to users. When you publish an application, you make choices about how to deliver the application and its properties. Use the Publish Application wizard in the Citrix AppCenter, the same wizard you use to publish installed applications. To review the general steps in the wizard, see To publish a resource using the Publish Application wizard. In the wizard, select the delivery options to publish the application for streaming. For guidance, see To select a streaming delivery method. Continue by locating the application profile stored in your App Hub and finish the wizard. In addition, refer to other topics about application properties and preferences and how to configure offline access (optional). Finally, to prepare user devices for streaming, see Deciding Which Plug-ins to Use for Application Streaming, as well as other topics about the Citrix Plug-ins. Important: To launch streamed applications, user devices must have sufficient RAM locally.

739

To select a streaming delivery method


You select the resource type in the Citrix AppCenter while running the Publish Application wizard. Important: For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site to the Trusted sites list in Internet Explorer on the user devices. 1. To open the Publish Application wizard, from the AppCenter, under the XenApp node, expand the farm or server to which you want to publish an application. Select the Applications node, and from the Actions pane, choose Publish application and follow the instructions in the wizard. Optionally, to change the delivery method after publishing an application, from the Action menu, select Other Tasks > Change application type and follow the instructions in the wizard. 2. In the Publish Application wizard, on the Type page, select Application. 3. Select a delivery method from the Application type list:
q

Accessed from a server. Users launch the application that runs on a XenApp server and uses shared server resources, or launch it from a Web browser using a Web Interface site you create. If you choose this option, you must then enter the location of the executable file for the application and the XenApp server on which it will run. This is the typical application type unless you intend to stream your applications to the client desktop. With this method, users access the applications using the Citrix Receiver. This method does not support desktop integration or offline access to applications. From the Server application type list, select the delivery method:

Installed application. Users launch the application installed on a XenApp server.

Streamed to server. The application in the profile is streamed from the App Hub to the XenApp server, where the Offline Plug-in is installed by default. The application displays on the user devices using the Citrix Receiver; the Offline Plug-in is not required on the user device. With this method, users access the applications using the Citrix Receiver. This method does not support desktop integration or offline access to applications. Streamed if possible, otherwise accessed from a server (called dual mode streaming). Grants users access to a profiled application that streams from the file share to their user devices and launches locally from within an isolation environment. Alternatively, user devices that do not support streamed applications (such as when they do not have the Offline Plug-in installed) instead use an ICA connection to access the application installed on or streamed from a XenApp server.
q

740

To select a streaming delivery method From the Server application type list, select the alternative delivery method for user devices that do not support streaming to user device:

Installed application. Users launch the application installed on a XenApp server.

Streamed to server. The application in the profile is streamed from the App Hub to the XenApp server, where the Offline Plug-in is installed by default. The application displays on the user devices using the Citrix Receiver; the Offline Plug-in is not required on the user device. With this method, users access the applications using the Citrix Receiver. This method does not support desktop integration or offline access to applications. Streamed to client. With this method, you make available the full set of application streaming features. When you stream applications directly to client desktops, some of the application files are cached locally and the application runs locally from within an isolation environment using the resources of the user device.
q q

Users must have both the Offline Plug-in and Citrix Receiver installed locally. With this delivery method, you can configure the application and users for offline access. When this configuration is completed, the entire application is fully cached on the user device. Users can disconnect from the network and continue using the application for the time specified in the offline license. User devices that do not support client-side application virtualization (such as, they use a non-Windows client) or do not have the Offline Plug-in installed locally cannot launch the application.

Note: You can also force a delivery method for applications published as "Streamed to client" based on filters. To do this, configure the Load Balancing policy setting (located in the AppCenter) for Streamed App Delivery. The policy setting overrides the selection in the publishing wizard.

741

To force a delivery method for streamed applications


Use the Load Balancing Policies to apply settings to sessions that are filtered for Web access, specific users, client devices, IP addresses, or server. Use the delivery method policy to override the delivery method of applications published as stream to client. If you disable the policy setting or do not configure it, the delivery method specified in the Publish Application wizard is used 1. From the Citrix AppCenter, select the farm. 2. Under the server, select Load Balancing Policies. 3. From the Actions pane, configure the policy settings for Streamed App Delivery. 4. Select one of the following options:
q

Allow applications to stream to the client or run on a Terminal Server (default setting). Force applications to stream to the client. User devices always stream the application from the App Hub to the user devices. Users must have the Offline Plug-in installed and access the application using the Citrix Receiver or a Web Interface site. For example, you might use this setting to prevent the use of server resources. User devices without the Offline Plug-in and Citrix Receiver cannot launch the application. Do not allow applications to stream to the client. Users always launch streamed applications from the server. For example, you might use this option to prevent applications from streaming to specific clients. In addition:
q

If you publish a streaming application with Streamed if possible, otherwise accessed from a server (dual mode streaming), users always launch the application from the server using the alternative method you selected. If you publish an application as Streamed to client (without dual mode), the connection fails.

This table describes the default delivery of each application type and the results of setting the policy. The policy setting overrides the delivery protocol for applications that are published as streamed to client.

Application type

No policy (default delivery)

With policy: Do not allow stream to client

With policy: Force stream to client

742

To force a delivery method for streamed applications Streamed to client Accessed from a server: Installed application Streamed to server Offline Plug-in streams application from file share to XenApp and Citrix Receiver delivers the application from XenApp. Dual mode: Offline Plug-in streams application to desktop. Otherwise, Citrix Receiver connects to the application installed on server (not streamed). Dual mode: Offline Plug-in streams application to desktop. Otherwise, Offline Plug-in streams application to the server. Policy does not apply. Policy does not apply. Offline Plug-in streams application to desktop. Citrix Receiver delivers the application installed on XenApp (not streamed). Connection fails. Policy does not apply. Connection works. Policy does not apply.

Streamed if possible; otherwise accessed from a server (dual mode): Installed application Streamed to server

Citrix Receiver always connects to application installed on server.

Offline Plug-in always streams application to desktop.

Offline Plug-in always streams application to the server.

Offline Plug-in always streams application to desktop.

743

To provide HTTP or HTTPS delivery method


To stream a profile using the HTTP or HTTPS protocol delivery method, use the following example to configure a virtual directory on the Web server. These steps assume that you already profiled the application and saved it to a file share using a UNC path. To stream from an HTTPS address, see the additional steps at the end of this procedure. Note that HTTPS requires additional certificate setup. For assistance, contact your network administrator. The Basic authentication scheme for HTTP is not allowed by default. To allow Basic authentication, create the following registry key:
q

For 32-bit systems: HKEY_LOCAL_MACHINE\Software\Citrix\Rade\AllowUnsecuredHttpAuth For 64-bit systems: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\Rade\AllowUnsecuredHttpAuth Type: REG_DWORD Value: 1

In the following example, the XenApp server, Web server, and file server are located on the same physical server. This is not a requirement. To configure the Web server: 1. Create a file share, if one does not already exist. For example: Web server name: WebServer Physical location on Web server: c:\webProfiles The share name: webProfiles An administrator must share this folder with the everyone group assigned READ access and the administrators group assigned WRITE access at both the share level and NTFS level. UNC path: \\WebServer\webProfiles 2. On the Web site hosting the profile, add the following MIME type information:
q

Extension:* MIME type: application/octet-stream

Set "Execute Permissions" to NONE You can set this information for the Web site hosting the profiles or for a specific folder in the virtual directory that holds the profiles.
q

3. In addition, if the profile includes pre-launch or post-exit scripts, also add the following MIME type information for the file extension of each script, such as .bat or .com. 744

To provide HTTP or HTTPS delivery method Extension: <file extension>, and MIME type: application/octet-stream 4. In the directory hosting the profiles: a. Open Properties and select the Directory tab. b. In the Configuration area, keep one application file extension (it doesn't matter which one you keep) and remove all the rest of the file extensions. c. Create a placeholder extension for application mapping; for example, ".testcitrix," which should not occur in the profile. d. Copy the settings from the file extension that remains (Step 4b) to the placeholder extension. e. Delete the file extension that remained in Step 4b, leaving only the placeholder extension from Step 4c. 5. Create a virtual Web site that points to the file share using the UNC path. For best results, do not use spaces in the URL. For example: HTTP (or HTTPS) path of virtual directory: http://WebServer.domain.com/webProfiles 6. Turn on Directory Browsing on the virtual Web site. Now you can test the configuration; continuing the example, browse to http://WebServer.domain.com/webProfiles/myApplication/myApplication.profile. If the Web server is configured correctly, the .profile file opens looking like an xml file (not an error message). For HTTP, you have now completed the configuration of the Web server. 7. For HTTPS, additional binding configuration of the Web server is required. See the additional steps following this procedure, based on your operating system. 8. In the Citrix AppCenter, publish the application as Streamed to client, Streamed to server, or Streamed if possible, otherwise accessed from a server and continue in the wizard. 9. On the Location page, enter the full URL path (starting with HTTP or HTTPS) to the profile (browsing to an HTTP location is not supported at this time). Use a fully qualified domain name, not a relative domain name. 10. Click in the field titled Application to launch from the Citrix streaming application profile to select the application. 11. Finish the remaining pages of the wizard. The application is ready to stream to the client device using the HTTP delivery method.

To stream from an HTTPS address from Windows Server 2008 additional configuration is required on the Web server. An appropriate Web Server Certificate must be already installed:

1. From IIS, edit the Bindings for the Web Site. 2. In the Site Bindings dialog, click Add. 3. Under Type, choose https. 745

To provide HTTP or HTTPS delivery method 4. For SSL certificate, choose the installed Web Server Certificate. 5. Using the previous example, browse to https://WebServer/webProfiles on the Web server, which must be a member of the domain and have the root certificate installed. To stream from an HTTPS address from Windows Server 2003, install a Web Server Certificate from a domain certificate authority:

1. From IIS, open Properties for the virtual Web site. 2. Click the Directory Security tab. 3. Under Server Communications, click Server Certificate. 4. Complete the Web Server Certificate wizard, and using the previous example, browse to https://WebServer/webProfiles on the Web server, which must be a member of the domain and have the root certificate installed.

746

Configuring Offline Access


Administrators can configure applications that are published to stream to desktops for offline access. This feature allows users to disconnect from the company network and continue to run their applications in offline mode for a specified length of time. No additional configuration is needed while profiling the application to create application profiles or targets that can be accessed offline. After you configure the offline application policy settings and configure a streamed application for offline access, the next time the user device connects to XenApp, the Offline Plug-in downloads the application and caches it on the user device. Important: Before you configure offline access, refer to System Requirements for Application Streaming for the supported platforms and system prerequisites for user devices.
q

Step 1: Configure policy settings for offline access Step 2: Install the Citrix Receiver and Offline Plug-in on user devices Step 3: Publish the application for offline access

You can complete these steps in any order, but users cannot run applications in offline mode until all steps are completed.

Step 1: Configure Policy Settings for Offline Applications


Configure these Citrix policy settings for Offline Applications:
q

Offline app users (required). Create a list of users or groups who have offline access permission and add that list both when creating the policy for Offline app users and when publishing the application. Users or groups listed in the offline app users policy setting and who are also configured for the application have permission to run offline-enabled applications in online and offline mode. Users who are configured for the application, but who are not added to the policy list can access the application online, but not offline. Users or groups on this list use an offline license to launch applications regardless of whether they are connected to the network or disconnected.

Offline app license period (required). Specify the number of days applications can work offline before users have to renew the license (21 days by default, but can range from 2 to 365 days). For versions 1.0 through 5.1 of the plug-in, the license for each application in the profile is activated when the user launches the application the first time, for online or offline use. Beginning with version 5.2 of the plug-in, when the user launches an

747

Configuring Offline Access application in the profile for the first time, for online or offline use, the offline license is activated for all other applications in the profile, as well. This occurs at the farm level. Thus, the offline license for all applications in the profile expires based on the date of the first application launched the first time, regardless of when the other applications are launched. To configure licenses, administrators can use the License Management Console or command-line tools. They must also ensure they have a sufficient number of licenses to support the total number of users with offline access permission. Users who run XenApp hosted applications can also stream applications to user devices without requiring a separate license. For general information, in the topics for Licensing Your Product, see Getting Started with Citrix Licensing. When users with offline access log on using the Receiver, they automatically either check out an offline license or renew a license already checked out. If users stay logged on, licenses are renewed automatically each day. If the license is near its expiration date while a user is running the application in offline mode, a notice appears reminding the user to log on (that is, change to online mode). When the user logs on, the offline license is renewed automatically if a license is available. If the license expires and no license is available, the user cannot launch the application offline.
q

Offline app client trust (optional). Use this setting to enable offline application user devices that have disconnected to recreate sessions when reconnecting, without authenticating again. Offline app event logging (optional). Use this setting to enable logging of offline application events to the event log on the server.

Step 2: Install the Receiver and Offline Plug-in on User Devices


To use the offline access feature, install both the Offline and the Receiver on the user device. The Offline Plug-in caches each streamed application on the hard drive of the user device. After the application is cached, the user can disconnect from the network or server and continue to run the application in offline mode for the period of time specified in the license.

Step 3: Publish the Application for Offline Access


The offline access feature is available only for applications that you publish as Streamed to client or Streamed if possible, otherwise accessed from a server. In addition, when publishing an application for offline access, check the application's documentation and Web site to determine whether any special configuration is required on the user device to enable offline access of that application. For example, to stream Microsoft Outlook to the user device for offline access, users must enable the Microsoft Exchange Setting to "Use Cached Exchange Mode." Configure the application for offline access while publishing the application or later using the application properties: 748

Configuring Offline Access


q

Enable the application for offline access and select the caching preference. Create a list of users or groups who have offline access permission and add that list both when creating the policy for Offline app users and when publishing the application.

749

Offline Plug-in 6.5 for Windows


Known Issues in XenApp 6.5 System Requirements for Application Streaming To configure the cache size of the Offline Plug-in Deciding Which Plug-in to Use for Application Streaming To install the Offline Plug-in To deploy the Offline Plug-in using the command-line

To deliver the AppHubWhiteList to user To deploy applications to user devices devices For information about profiling applications for streaming and then publishing them in XenApp, see the publishing section for your version of XenApp.

750

New Features in This Release


In addition to improved application compatibility on Microsoft Windows Server 2008 R2 SP1 and Windows 7 SP1, the 6.5 release provides the following enhancements for application streaming:
q

Increased support for streamed apps in pooled XenDesktop environments. For faster application launch time on user devices, select the option to "Create a virtual hard disk" (VHD) while profiling. This feature copies the profile contents into the VHD and mounts it in the RadeCache location at application launch. Compliance with new FIPS guidelines. The Streaming Profiler in this release uses SHA-256 to create file hashes. To include SHA-1 hashes required by Offline Plug-ins 6.0, select the option for "Legacy Offline Plug-in support" while profiling. Enhancements for creating AppHubWhiteList. The registry key for creating the AppHubWhiteList is now consistent with other Citrix registry keys on 32-bit and 64-bit operating systems. Ability to deliver AppHubWhiteList using Citrix Receiver Updater. Ensure that unsigned profiles and services stream only from approved locations AppCenter session reports include the names of streamed applications. The reports of user sessions now include application names instead of just profile names. Launch time improvements. General performance improvements reduce launch time for streamed applications, including Microsoft Outlook.

751

System Requirements for Application Streaming


Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the following Microsoft operating systems:
q

Windows XP Home and Professional editions, 32-bit edition, with Service Pack 3 Windows XP Home and Professional editions, 64-bit edition, with Service Pack 2 Windows Server 2008, 32- and 64-bit editions Windows Server 2003 R2 Windows Server 2008 R2 Windows Server 2008 R2, with Service Pack 1 Windows Vista (Home, Business, Enterprise, and Ultimate editions), 32- and 64-bit editions, with Service Pack 1 or Service Pack 2 Windows 7, 32-bit and 64-bit (Enterprise, Professional, Ultimate)

Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the following Citrix products: Note: The list is accurate at the time of this release. For more information about supported versions, see: http://www.citrix.com/support/product-lifecycle/product-matrix.
q

Citrix XenApp 5, 6, and 6.5. Citrix XenDesktop 4, 5, and 5.5. Citrix XenServer: all supported versions. Citrix Receiver (Updater) for Windows 1.x, 2.x, and 3.0. Citrix Online Plug-in: Citrix recommends 13.0, which is installed with Citrix Receiver 3.0, but past versions 11.2 and 12.x are also supported.

The profiler workstation and user devices must meet the following requirements:
q

Microsoft XML 2.0 installed (use Windows Update to ensure you installed all recent Internet Explorer updates). Standard PC architecture, 80386 processor or greater as required for the operating system. Administrator rights for the person installing.

752

System Requirements for Application Streaming


q

To profile and stream Microsoft Office applications to Windows Server 2003 operating systems, install the Windows Data Execution Prevention (DEP) hotfix on the server and profiling workstation. For information, see http://support.microsoft.com/kb/931534.

The profiler workstation must provide a run-time environment that is as close to your users' environment as possible. To stream applications to user devices, use the following guidelines for the profiling workstation:
q

Choose a workstation that is a similar platform to your users' devices. Use a computer that is freshly reimaged so that there are no hidden files or registry settings for applications that you intend to profile. Install only the standard programs that are part of the company image, such as an antivirus program. Disable the User Account Control (UAC). To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 optional). Do not install the Offline Plug-in on the profiler workstation. You can install Citrix Receiver.

Install the profiler in a path with single-byte characters only. Double-byte characters in the installation path are not supported. The user devices must meet the following requirements:
q

A network connection to the server farm, such as a network interface card (NIC). A supported browser: Microsoft Internet Explorer 6.0, 7.0, 8.0, or 9.0. To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 is optional). Manually uninstall any previous version of the Streaming Client and Program Neighborhood Agent on user devices. To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your users, install the Offline Plug-in and the most recent version of Citrix Receiver (Enterprise), which includes the Online Plug-in. In addition:
q

Citrix recommends using Citrix Receiver Updater on user devices to install (and uninstall) Citrix plug-ins. To stream applications to user desktops, install both the Offline Plug-in and Citrix Receiver (Enterprise) on user devices.

To stream applications to a server, install Citrix Receiver (Enterprise) on user devices. The Offline Plug-in is not required. If users launch applications from a Web Interface site, install Citrix Receiver (the Enterprise version is not needed) and add the site to the list of trusted sites. Microsoft redistributable packages
q

753

System Requirements for Application Streaming The CitrixOfflinePlugin.exe and CitrixStreamingProfiler.exe installers include the following redistributables:
q

Microsoft Visual C++ 2005 Redistributable Package 8.0.56336 Microsoft Visual C++ 2005 Redistributable Package 8.0.50727.42 Microsoft Visual C++ 2008 Redistributable Package 9.0.21022 Microsoft Visual C++ 2008 Redistributable Package 9.0.30729 Microsoft Visual C++ 2008 Redistributable Package 9.0.30729.4148

Backward compatibility. To take advantage of the latest updates in application streaming, Citrix recommends installing the most current versions of the Streaming Profiler, Citrix Plug-ins, and Citrix Receiver.
q

Profiles created in the Streaming Profiler 6.5 are supported with:


q

Offline Plug-in 6.5 Offline Plug-in 6.0 (you must select the profiling option to support legacy Offline Plug-ins) Note: The Virtual Hard Disk feature is not supported for version 6.0.

Online Plug-in, which is included in Citrix Receiver 3.0 (with this release) or past versions 11.2 through 12.x. To continue using existing profiles with the plug-ins in this release, also install the latest profiler and update them (simply open them in the new profiler and re-save them).
q

If upgrading is not possible, this release provides backward compatibility for streaming profiles created with profiler 5.2 through 6.0.

Streaming Microsoft Office 2007. For best practices for streaming Office 2007 applications, see http://support.citrix.com/article/CTX118396 in the Citrix Knowledge Center. Streaming Microsoft Office 2010. For best practices for streaming Office 2010 applications, see http://support.citrix.com/article/CTX124565 in the Citrix Knowledge Center. Update the profiler workstation and user devices with the latest Microsoft hotfixes, including:
q

On Streaming Profiler workstations with Windows 7 (32-bit and 64-bit) only, download the hotfix from http://support.microsoft.com/kb/2359223/en-US (requires a computer restart). On Windows XP 32-bit platforms, install hotfix KB978835. On all Windows XP or Windows 2003 platforms, install hotfix KB973573. For more information, see http://support.citrix.com/article/CTX124563 in the Citrix Knowledge Center.

754

Citrix Offline Plug-in Overview


The Offline Plug-in is the new name for the Streaming Client. The Offline Plug-in runs as a service on the user device to invoke applications the user selects and applications enumerated by Citrix Receiver or the Web Interface site. The Offline Plug-in finds the correct target in the profile in the App Hub, sets up the isolation environment on the user device, and then streams the application from the profile location to the safety of the isolation environment set up on the user device. The Offline Plug-in installer does not require any configuration during installation, so those users who have administrator privileges on their computers can install it themselves. The Offline Plug-in is installed by default on a server when you install XenApp. This enables the server for further configuration of streaming to server and dual-mode streaming. To authenticate profiles accessed by the user devices, install the Offline Plug-in with a digital certificate. The Offline Plug-in then streams applications only from profiles that match the digital certificate. See also Specifying Trusted Servers for Streamed Services and Profiles. The Offline Plug-in also checks the cache size of the user device. If the cache size exceeds a maximum limit, the Plug-in removes streamed application files from the cache until its size is smaller than the limit. The default cache size limit is 1000MB (1GB) or 5% of total disk space, whichever is larger. The Offline Plug-in removes streamed application files starting with the one that was not used for the longest time.

Finding the Version of the Offline Plug-in


To identify the version of your installed Plug-in, open the Windows program to add and remove programs and continue with the method for your operating system:

For Windows Vista and Windows 2008, right-click a column heading and select More. In the Choose Details page, check to option to display the version. For earlier Windows operating systems, select Plug-in name, and click the link for support information.

To take advantage of the latest updates in application streaming, Citrix recommends installing the most current versions of the Offline and Citrix Receiver.

755

Deciding Which Receiver or Plug-in to Use for Application Streaming


The delivery method for streaming that you select for published applications determines the Receiver and plug-ins to must install on servers and user devices. Citrix recommends using the Citrix Receiver Updater to deliver the packages that you want to install on user devices: Streamed to client desktops. With this method, you make available the full set of application streaming features. You can publish applications as "streamed to client" or any other method for streaming. When you stream applications directly to client desktops, some of the application files are cached locally and the application runs using the resources of the user device. Install both the CitrixReceiverEnterprise.exe and CitrixOfflinePlugin.exe on user devices. This combination enables you to:
q

Enumerate published applications in the desktop Start menu and create shortcuts on the desktop. Provide dual-mode streaming. When you select "Streamed if possible, otherwise accessed from a server" and "Streamed to server," if streaming to the client desktop fails, applications automatically stream to a XenApp server and launch using the Citrix Receiver (Enterprise). Configure the application and users for offline access. When this configuration is completed, the entire application is fully cached on the user device. Users can disconnect from the network and continue using the application for the time specified in the offline license.

Accessed from a server. The profile is streamed from the App Hub to the XenApp server, where the Offline Plug-in is installed by default. The application displays on the user devices using the Receiver; the Offline Plug-in is not required on the user device. When you publish applications as "Accessed from a server" and "Streamed to server," users access the applications using the Receiver. This method does not support offline access to applications. Select the package that fits your corporate needs:
q

Install CitrixReceiverEnterprise.exe to stream applications to XenApp servers and launch them with the Receiver if you require native Program Neighborhood Agent (Applications in folders) or Smart Card authentication. Install CitrixReceiver.exe to stream applications to XenApp servers and launch them using Citrix Receiver self-service or a Web browser using a Receiver for Web or Web Interface site you create.

756

Deciding Which Receiver or Plug-in to Use for Application Streaming Important: For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site to the trusted sites list in Internet Explorer on the user devices. Streaming to a virtual desktop. To deliver applications to pooled XenDesktop environments, install both Receiver and the Offline Plug-in on the virtual desktop image. You must profile the applications with the option to create a virtual hard disk. When users launch the application, the profile contents are mounted in the RadeCache location from the AppHub.
q

When profiling the application in the streaming profiler, select the option to Create virtual hard disk. When publishing the application in XenApp, select the delivery option to stream to client desktop. Note: Do not configure HTTP delivery for applications that stream to virtual desktops. Also, offline access is not supported on virtual desktops; if you enable offline access, the settings are ignored for this deployment.

When creating the virtual desktop image, install both the CitrixReceiverEnterprise.exe and CitrixOfflinePlugin.exe.

757

Specifying Trusted Servers for Streamed Services and Profiles


To ensure that unsigned profiles and services stream only from approved locations, edit the registry on user devices to enable a whitelist of trusted servers:
q

For unsigned profiles that include services, you must create a whitelist of approved server locations on the user device. If profiles attempt to stream a service from a location that is not on the whitelist, the service launch is denied and an event is sent to the event log. Optionally, to extend the whitelist requirement to unsigned profiles without services, create an additional registry setting.

Alternatively, signed profiles are always trusted, whether or not they include services, and a whitelist is not required for them. 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.

Creating a Whitelist of Locations for Unsigned Profiles with Services


To ensure that user devices run only approved services, edit the registry on user devices to enable a whitelist of approved server locations. 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade Value: AppHubWhiteList Type: REG_SZ 2. Add the server names (or local file system folder) plus the App Hub location in the registry value in a semicolon (;) or comma (,) delimited format, with or without spaces before or after the semicolon or comma. For example:
q

\\server\sharename \\server.example.net\sharename\directory

758

Specifying Trusted Servers for Streamed Services and Profiles


q

\\server.example.net\profiles

If the application has been streamed from a web location (also called http streaming), the server name must be prefixed with http (or https) in the AppHubWhiteList registry entry. Also there is clear distinction between http and https servers. That is, if a profile location is https://12.0.0.1/profiles/office/office.profile, then the AppHubWhiteList must contain https://12.0.0.1 or https://12.0.0.1/profiles. The following examples are valid entries:
q

http://streamauto;https://12.0.0.1 http://webshare.example.com/sharename 12.0.0.1;streamauto;webshare.example.com 12.0.0.1;c:\profiles;c:\folder with spaces;webshare.example.com

12.0.0.1; c:\profiles; webshare.example.com After you create the registry entry and whitelist on user devices, unsigned profiles with services can load only from the locations on the whitelist. Signed profiles are always allowed.
q

Extending the Whitelist to Unsigned Profiles without Services


Optionally, to require all profiles, even those without services, to stream only from locations on the whitelist, after creating the registry entry and whitelist in the previous steps, create an additional registry entry: 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade Value: AppHubWhiteListRequired Type: REG_DWORD 2. Set the value:
q

1 - Enables the whitelist requirement to profiles without services

q 0 - Disables the whitelist requirement to profiles without services After you create the registry entry and whitelist in the previous steps and then create and enable this registry entry on the user device, all unsigned profiles, with or without services, can load only from the locations on the whitelist. Signed profiles are always allowed.

759

Specifying Trusted Servers for Streamed Services and Profiles

Disabling Backward Compatibility


When you create a white list, by default, you can add both server names (as allowed by the 6.0 release) and the better protected share names (added in 6.5) to the AppHubWhiteList path. No registry change is needed for the default behavior. To disable backward compatibility with the 6.0 release and allow only share names, create the following registry setting: 1. On the user device, create the following registry location: 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Rade\ 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Rade\ Value: AppHubBackWardCompatible Type: REG_DWORD 2. Set the value:
q

0 - Disables backward compatibility 1 - Enables backward compatibility

Note: To re-enable backward compatibility, either change the registry value or delete the registry entry.

760

Using the Merchandising Server and Citrix Receiver Updater to Deploy the Plug-ins
Citrix recommends using the Merchandising Server and Receiver Updater to deploy and update Receiver to a user device. Citrix Merchandising Server administrator console. With the administrator console, you can upload the Receiver installation and metadata files, create reuseable rules to define the delivery recipients, and create deliveries. Citrix Receiver Updater client (Receiver Updater for Windows). After users install Receiver Updater on their user devices, Receiver Updater installs, updates, and starts Receiver without user interaction. Users having the correct permissions to manage their Receiver can change the Citrix XenApp server that hosts their published resources. Right-click the Receiver icon in the Windows notification area and choose Preferences, then right-click the Citrix Receiver entry in the Plug-in Status, and choose Change Server. Important: For Firefox to work correctly with Receiver for Windows, ensure that you or the user install Firefox before installing Receiver. If Receiver is already installed, uninstall it, install Firefox, and reinstall Receiver. Also ensure that the whitelists of trusted and untrusted servers contain the XenApp and Web Interface server names.

Upgrading Receiver with Receiver Updater


Updates are, by default, automatically installed on the user device. When an update is available, the Receiver Updater downloads and installs the updated Receiver.

Uninstalling Receiver with Receiver Updater


Receiver Updater upgrades Receiver when a newer Receiver is available. When users remove the Receiver Updater manually from the Add/Remove Programs utility (or Programs and Features for Windows Vista or Windows 7), Receiver is also removed. Additionally, the administrator can remove the Receiver Updater and all of its managed plug-ins through the Administrator Console. For more information, see the Receiver Updater for Windows documentation.

761

To install the Offline Plug-in


Citrix recommends delivering the Offline Plug-in to user devices through the Receiver Updater. If users install the Receiver Updater, they should also update or remove plug-ins using only the Receiver Updater (instead of the Windows uninstall program). However, you can install the plug-in manually. The CitrixOfflinePlugin.exe installer (formerly an .msi file) includes improvements for Microsoft Office applications and Microsoft Redistributable Packages. Important: Before you install the Offline Plug-in, refer to the system requirements for application streaming for the supported platforms, system prerequisites, and the Microsoft redistributable packages included with the installation. The Citrix installation media contains installation files for Citrix plug-ins in the Citrix Receiver and Plug-ins directory. The latest plug-ins are also available from the Citrix Support Web site. To take advantage of continuing improvements in the profiler, when you upgrade to the latest Offline Plug-in, also upgrade to the latest Streaming Profiler and either update your existing applications or re-profile the applications in the new profiler. In addition, Citrix provides command-line utilities and transforms with the Offline Plug-in to perform actions on user devices. Use one of the following methods:
q

Installing using the Receiver Updater. Citrix recommends using the Receiver Updater to install plug-ins, which lets you deliver and update plug-ins automatically with the Merchandising Server. The Receiver Updater upgrades plug-ins when a newer version is available. For more information, see the section for Merchandising Server. Installing manually. The Offline Plug-in installer deploys drivers and requires administrator privileges on the user devices. For users who have administrator privileges, you can make the plug-in installer available, and they can install it themselves. The plug-in installer does not require any configuration during installation.

To install the Offline Plug-in manually 1. From the installation media or Citrix download site, navigate to Citrix Receiver and Plug-ins > Windows > Offline Plug-in and run CitrixOfflinePlugin.exe. Note: On Microsoft Windows Server 2003 or 2008, Active Directory manages resources across the domain. These computers can handle only .msi files, not .exe files. For these platforms, select the .msi installer. 2. If the installer detects an installed version, the installer can upgrade or repair the installation. 3. Choose the language in which you want the plug-in installer to run. In this step, you are choosing the language for the installer, not the language of the plug-in. 762

To install the Offline Plug-in 4. After the Welcome screen, accept the license agreement and continue with the installation wizard. 5. After you finish the installation, restart the user device.

When you restart the user device, the Citrix Streaming Service (Ctx_StreamingSvc) starts automatically and runs in the background. Restarting the user device also ensures that other applications and plug-ins detect the Offline Plug-in. To remove the Offline Plug-in
q

If you used the Receiver Updater to install the plug-in, use only the Receiver Updater to remove it. If you installed the plug-in manually, you can uninstall it using the Windows uninstall program.

When users uninstall the Receiver Updater manually from their devices, all plug-ins are also removed. Additionally, the administrator can remove the Receiver Updater and all of its managed plug-ins through the Administrator Console.

763

To deliver the AppHubWhiteList to user devices


If you create an AppHubWhiteList to specify trusted servers for streamed services and profiles, beginning with the Offline Plug-in 6.0.2, use these methods to deliver the AppHubWhiteList along with the Offline Plug-in to user devices:
q

If you manually install the Offline Plug-in 6.5 using command line parameters, during the installation, ad CTX_APPHUB_WHITELIST and the IP address, FQDN, shared folders, folder on drive, and Web server add For example:

"[path]/CitrixOfflinePlugin.exe" /C:"setup /qr CTX_APPHUB_WHITELIST="" "" \\10.105.68.11\AppHub;C:\profiles;C:\folder with spaces;http://www.webshare.org


q

If you manually install the Offline Plug-in 6.0.2 using command line parameters, during the installation, a CTX_APPHUB_WHITELIST and the IP address or FQDN of the share drive, and HTTP/HTTPS server path. For example:

"[path]/CitrixOfflinePlugin.exe" /C:"setup /qr CTX_APPHUB_WHITELIST=""10.105.68 webshare.organization.com;http://www.webshare.organization.com;https://www.webs


q

To deploy the AppHubWhiteList when users install the Offline Plug-in using Receiver, configure the AppH parameter) in Citrix Merchandising Server. For more information, locate the Receivers and Plug-ins > Mer review Configuring Plug-in Parameters.

For more information about creating the AppHubWhiteList, seeSpecifying Trusted Servers for Streamed Services and Profiles.

764

To configure the cache size of the Offline Plug-in


When you run a streamed application either through Citrix Offline Plug-in or from a Web page created through the Web Interface, by default, the Plug-in caches application files on the primary, local drive of the user device at the following location: %PROGRAMFILES%\Citrix\RadeCache Before caching files, the Plug-in checks the size of this cache. If the cache size exceeds a maximum limit, the Plug-in removes streamed application files from the cache until its size is smaller than the limit. The Plug-in removes streamed application files starting with the one that was least recently used. The default cache size limit is 1000MB (1GB) or 5% of total disk space, whichever is larger. To change the default cache location or the default maximum cache size, use the ClientCache tool that you run on the user device where the Plug-in is installed. To start the tool, run the following program: %PROGRAMFILES%\Citrix\Streaming Client\ClientCache.exe Running ClientCache.exe on the computer on which the Offline Plug-in is installed enables you to change the location of the cache and the maximum cache size. Entries you make using ClientCache.exe are stored in the registry and become the new defaults. The following are some guidelines for changing these defaults: Client cache directory. The cache location you specify must be on a local drive and can be on a volume other than the main volume. Maximum client cache size. When specifying a cache size, use an integer representing the cache size in megabytes. For example, the following represents two gigabytes: 2000. The maximum size of the cache is restricted to the size of the local drive. Changes you make using this tool take effect the next time you start the Plug-in or restart the Citrix Streaming Service.

765

To deploy the Offline Plug-in using the command-line


To deploy the Offline Plug-in to user devices, use Microsoft System Management Server (SMS) or Microsoft Active Directory Services. See http://www.microsoft.com for instructions about how to use these products to deploy applications. To deploy the plug-in using command-line parameters, use the following steps: 1. On the computer where you want to install the Plug-in package, type the following at a command prompt to open the Offline Plug-in file and extract the CitrixOfflinePlugin.msi file: [path]/CitrixOfflinePlugin.exe /C:setup [Options] where path is the location of the .exe file. 2. Set the options. [Options] can be any of the traditional MSI command-line parameters. Set your extraction options as needed. Examples of parameters that are supported:
q

/Q suppresses the extraction dialog box. /T: full path specifies the temporary working folder in which to extract the files. /C extracts files only to the folder when used also with /T. Use this only if you are not including a command-line. /C:[Cmd ] overrides the install command, where Cmd is the command-line that runs after extracting the files to the temporary folder. For Cmd, set command-line properties as needed. The following properties are supported to set the user interface level and other options:

/qn executes a completely silent installation; no user interface. /qb shows simple progress and error handling; a basic user interface. /qf shows a full user interface (default). /qr shows a reduced user interface. /l [logfile] creates a verbose install log where logfile is the path and filename for where to save the log. Use double double-quotes for a path with spaces. /norestart prevents restarting of the user device following the installation.

766

To deploy the Offline Plug-in using the command-line


q

/restart initiates a restart automatically (without prompting) upon successful completion of the installation.

Locations with spaces must be enclosed with quotes; however, only single sets of double quotes are allowed, and nested double quotes causes the command to fail. In cases where a nested quote is required inside the double quotes, use double double-quotes on each end of the expression. Type the following at a command prompt, where package is the name of the Windows Installer installation package and TransformList is the list of the transforms that you want to apply: CitrixOfflinePlugin /I package TRANSFORMS=[TransformList].mst If you are applying multiple transforms, separate each transform with a semicolon. The following examples demonstrate valid command-lines:

To simply extract files: path\ CitrixOfflinePlugin.exe /C /T:c:\Documents and Settings\Administrator\Desktop\Streaming Client To run a silent install with no options: path\ CitrixOfflinePlugin.exe /C:setup /qr To add some options: path\X CitrixOfflinePlugin.exe /C:setup /qr INSTALLDIR=C:\Program Files\Citrix\Streaming Client /norestart /l c:\Log Files\streaming.log With some options and a transform: path\ CitrixOfflinePlugin.exe /C:setup /qr INSTALLDIR=C:\Program Files\Citrix\Streaming Client /norestart /l c:\Log Files\streaming.log TRANSFORMS=C:\some_transform.mst

767

To configure an .MSI package for the Offline Plug-in using transforms


Transforms manipulate the installation process by making changes to the installation database contained within a Windows Installer package. The following procedure should be attempted only by those familiar with transforms and their impact upon these settings. 1. After extracting the CitrixOfflinePlugin.msi file in a temporary folder, use Orca or your preferred tool for editing Windows Installer packages to open the .msi package. 2. Enter new values for the properties you want to change in the Property table. 3. Generate the transform file and save it with an .mst file extension. 4. To install the MSI package and use the transform you just created, follow the same steps as outlined above in the procedure dealing with command-line installations; that is, add the properties to the command-line. Additionally, however, you must add the following PROPERTY=value Here is an example: TRANSFORMS=path\my.mst where path is the location of the transform and my.mst is its file name. The following example demonstrates a valid command-line: PROPERTY=Value | ANOTHER_PROPERTY=a value with spaces

768

To deploy the Offline Plug-in to user devices through Active Directory


On Microsoft Windows Server 2003 or 2008, Active Directory manages resources across the domain. These computers can handle only .msi files, not .exe files. To install the Citrix Offline Plug-in on these user devices with an equivalent installation as with the .exe installation, use the following steps to apply a transform contained in the self-extracting package. You must be a domain administrator.

1. To extract the installation files to a file share, run: CitrixOfflinePlugin.exe /C /T:[fileshareDirectory] where the fileshareDirectory is the UNC path to a shared folder that is accessible to all the domain user devices on which you will install the Offline Plug-in. 2. From a computer in the domain:
q

On Windows Server 2003, from Administrative Tools, open Active Directory Users and Computers, right-click the organizational unit, and select Properties. From the Group Policy tab, click New.

On Windows Server 2008, open Group Policy Management, right-click Group Policy Objects, and select New. 3. Name the policy and click Edit.
q

4. In the Group Policy Object (or Management) Editor, under Computer Configuration > Software Settings, right-click Software installation. Note: Assigning the package to a User Configuration is not supported. 5. Select New and then select Package. 6. In the Open dialog box, browse to the file share location and select XenAppStreaming.msi. 7. After selecting Open, select the Advanced deployment method. 8. After the properties dialog box opens, from the Modifications tab, click Add and then double-click streaming_client_ad.mst to open the transform. This installation performs the equivalent installation of CitrixOfflinePlugin.exe, including installing the Offline Plug-in, starting the Citrix Streaming Service, and adding the Microsoft Visual C++ 2005 Redistributable Package on all user devices in the domain.

769

To deploy applications to user devices


Citrix recommends that administrators deploy the applications used most frequently by end users. Deployment pushes new or updated application files to user devices and helps avoid overloading the file servers or network. The utility enables administrators to schedule deployment overnight or during off hours. The Offline Plug-in located on the installation media includes the deployment utility called RadeDeploy.exe. After you install the plug-in, locate the utility in \Program Files\Citrix\ directory. 1. On the user device that has the Offline Plug-in installed, open a command prompt. Enter the path to locate the manifest file (.profile) on the network file share or Web server, using the following examples: radedeploy /deploy:\\2003Server\packages\adobe\adobe.profile radedeploy /deploy:https://2003server/webpackages/office/office.profile The utility automatically selects the correct target for the user device and deploys the necessary files. 2. Set any additional commands. The following additional commands are available: radedeploy /enum radedeploy [-m] /deploy:profilename radedeploy [-p] /delete:appname or profilename where appname is the name of the application and profilename is the name of the profile as listed using the radedeploy /enum command, either a .profile or .rad file. Profile names with embedded spaces should be quoted, such as deploy:my profile. Note: The /delete command does not delete subprofiles that are linked to inter-isolation communication profiles running on the user device. Instead, you must delete the inter-isolation communication profile that includes the linked profile. 3. Set your options as needed, including the following parameters:
q

/enum enumerates the applications currently deployed on the user device. /deploy adds the profiled application on the user device. /delete removes the profiled application from the user device. -m monitors the deployment until complete.

-p deletes the application profile from the user device. Note that this command also removes any other applications deployed on the user device from this application profile. 4. Repeat for other applications, as needed.
q

770

To deploy applications to user devices

Alternatively, run the command-line in third-party software, such as Microsoft System Management Server (SMS) or Microsoft Active Directory Services (ADS) to deploy applications.

771

To clear the streamed application cache on user devices


Use the RadeCache command-line utility to clear the streamed application cache on user devices. For example, free space in the application cache or start with an empty cache while troubleshooting streaming issues. The RadeCache utility is included in the CitrixStreamingProfiler.exe and is installed automatically on the user device in Program Files > Citrix. Note: Before using the RadeCache command, make sure that the application programs and processes are terminated on the user device. For large applications such as Microsoft Office, this can take up to 10 minutes. 1. On the computer where you want to clear the cache, type the following at a command prompt: radecache [-i] [-if] [-ir] [-u] [-uf] [ur] [/flush:GUID] radecache [/flushall] radecache radecache [/?] where GUID is the unique GUID for the application streamed to user devices. GUIDs must not include spaces. 2. Set your options as needed, including the following parameters:
q

/? displays the syntax for the utility and information about the options of the utility -i clears the registry and files in the install root -if clears only files in the install root -ir clears only the registry in the install root -u clears the registry and files in the user root -uf clears only the files in the user root -ur clears only the registry in the user root /flush:GUID clears the registry and files in both the install root and user root for the streamed application, and, for an application for pooled XenDesktop environments, unmounts the VHD

772

To clear the streamed application cache on user devices


q

/flushall clears the registry and files in both the install root and user root for all streamed applications, and, for applications for pooled XenDesktop environments, unmounts the VHD

3. Repeat for other applications, as needed. This method affects only the local user device.

773

To clear merged rules for linked profiles on user devices


The RadeStore folder contains the repository of registry hives, registry tab files, fonts, scripts, and merged rules of inter-isolation communication (IIC) profiles. If any of the execution targets of the IIC profile is updated, the merged rules are invalidated and then rebuilt automatically. Fonts are registered for each session from the RadeStore location. The RadeStore location is created when you install the CitrixOfflinePlugin.exe on user devices. Clear the RadeStore location manually, as needed, such as when troubleshooting application issues for users. To clear the RadeStore location: 1. On the computer where you want to clear the storage location, type the following at a command prompt: radecache /flushstore:{all|rules|hives|tabs|fonts|scripts} 2. Set your options as needed, including the following parameters:
q

rules clears the merged rules in the RadeStore location hives clears the registry hives in the RadeStore location tabs clears the registry tab files in the RadeStore location fonts clears fonts in the RadeStore location scripts clears scripts in the RadeStore location

/all clears the merged rules, registry hives, registry tab files, fonts, and scripts in the RadeStore location 3. Repeat for other RadeStore locations, as needed.
q

This method affects only the local user device.

774

Configuring Content Redirection


The capability to redirect application and content launching from server to client or client to server is referred to as content redirection. Content redirection allows you to control whether users access information with applications published on servers or with applications running locally on client devices. Note: For your users to access content published with a specified universal naming convention (UNC) path and through the Web Interface, you must publish and configure an application for content redirection so it is associated with the file type of the published content.

775

To enable content redirection from server to client


When you enable server to client content redirection, embedded URLs are intercepted on the XenApp server and sent to the client device and the Web browser or multimedia players on the client device open these URLs. This feature frees servers from processing these types of requests by redirecting application launching for supported URLs from the server to the local client device. The browser locally installed on the client device is used to navigate to the URL. Users cannot disable this feature. Accessing published content with local client desktops does not use XenApp resources or licenses because local viewer applications do not use XenApp sessions to display the published content. For example, users may frequently access Web and multimedia URLs they encounter when running an email program published on a server. If you do not enable content redirection from server to client, users open these URLs with Web browsers or multimedia players present on servers running XenApp. Note: If the client device fails to connect to a URL, the URL is redirected back to the server. Complete the following configurations: 1. From the Microsoft Management Console (MMC), locate the Citrix policy setting for Category_ICA > File Redirection. Set Host to client redirection to enable file type associations for URLs and some media content to be opened on the user device (disabled by default). When disabled, content opens on the server. 2. From the Citrix AppCenter, publish the content file and select the users or groups that can access it. The following URL types are opened locally through user devices for Windows and Linux when this type of content redirection is enabled:
q

HTTP (Hypertext Transfer Protocol) HTTPS (Secure Hypertext Transfer Protocol) RTSP (Real Player and QuickTime) RTSPU (Real Player and QuickTime) PNM (Legacy Real Player) MMS (Microsoft Media Format)

If content redirection from server to client is not working for some of the HTTPS links, verify that the user device has an appropriate certificate installed. If the appropriate certificate is not installed, the HTTP ping from the client device to the URL fails and the URL is redirected back to the server. For legacy plug-ins, content redirection from server to 776

To enable content redirection from server to client client requires Internet Explorer Version 5.5 with Service Pack 2 on systems running Windows 98 or higher.

777

To configure content redirection from client to server


Configure content redirection from client to server by associating published applications with file types and then assigning them to the users you want to be affected. When you configure client to server content redirection, devices running the Citrix Receiver open all files of the associated type with applications published on the server. Content redirection from client to server is available only for users connecting with the Receiver. For example, if you have users who run applications such as email programs locally, use the content redirection capability with XenApp to redirect application launching from the user device to the server. When users double-click attachments encountered in an email application running locally, the attachment opens in an application that is published on the server, associated with the corresponding file type, and assigned to the user. Complete the following configurations: 1. On the Web Interface server, configure Web Interface to allow content redirection for the farm. 2. In the Citrix AppCenter, as you publish the application, associate it with file types and select the users or groups that can connect to it. When users launch the application, the file type association is changed to reference the published application in the Windows registry on the user device. For example, if you publish a Microsoft Word document, make sure to also publish Microsoft Word on a XenApp server so that the .doc file can open in Word. Note: When you associate a file type with a published application, several file extensions can be affected. For example, when you associate the Word document file type, file extensions in addition to the .doc extension are associated with the published application. 3. Verify that the Client drive redirection User policy setting is enabled, either for the entire farm, for specific servers, or for specific users or groups.

When you configure content redirection from client to server, context menu commands available from within Windows Explorer function differently than on user devices that do not use this feature. For example, if you right-click a file in Windows Explorer on a user device with content redirection from client to server enabled for the file type, the Open command opens the file with the remote application on XenApp. For a streamed application, the file could be opened either on the user device or on the XenApp server, depending on the delivery configuration. Most commands on the Windows Explorer context menu are unaffected because they are not configured under keys modified by XenApp. Context menu items are generally defined by each application when installed.

778

Managing Application Properties


After publishing applications through the Publish Application wizard, manage the published applications and their properties:
q

Rename, move, disable, and delete published applications Change, duplicate, import, and export published application settings

Only a Citrix administrator with full access to the Published Applications task can change published applications. Use the application properties to change settings for a published application, including the location of the published application, the servers on which the published application is available, and the user accounts allowed to access the published application. From the Action menu, select Application properties. Important: The resource type you publish (application, content, or server desktop) determines your path through the Publish Application wizard; consequently, the properties associated with the resource may vary.

779

To rename a published application


Use the Name property to change the application name and description that you selected in the Publish Application wizard. Changes take effect after the user reconnects or refreshes the user device. This feature can distinguish among multiple versions of the same application. 1. In the left pane of the Citrix AppCenter, select the published application. 2. From the Action menu, select Application properties and then select Name. 3. The Display name is the name users see on their user device, and it must be unique within the folder. XenApp supports application names that use Latin-1 and Unicode character sets, including characters used in Japanese, Chinese, and Korean. 4. The Application name appears on the Current Settings tab in the AppCenter and should be unique within a farm (maximum 38 characters). When the application is published, this name is the same as the display name by default. 5. The Application description appears in Web Interface.

Important: If a duplicate application name is found in the farm, a four-digit hexadecimal number is appended to the original string. If the character limit is reached and duplicated, the AppCenter replaces the end characters with four-digit hexadecimal numbers, starting from the right.

780

To configure locations of servers for published resources


Choose the server on which the published application or desktop is available through the Servers page of the Publish Application wizard. To modify the setting, from the Action menu, select Application properties and then select Servers. Important: For installed applications, select the server where the published application is installed. For streamed-to-server applications, select the server to which the profiled application will stream and execute.
q

The Servers list displays the servers that belong to the farm. Initially, all servers in the farm appear. Use a filter to display only servers running a particular operating system or Citrix version. Note: If you apply a filter (in the Select Servers dialog box), the filter settings remain in effect each time the Publish Application wizard is run until the filter is removed or changed.

Use the Import from file option to import an application server list file (*.asl). You export the server list of a previously published application and then import this settings file when creating a new published application.

If you modify your servers for a published application, some users may not be in a trusted domain for that server. If you receive an error message when trying to modify configured servers for a published application, duplicate the application and then modify the servers and users lists of the new application.

781

To specify locations of applications for streaming


Before you publish applications for streaming, you must create an application profile using the Citrix Streaming Profiler, a stand-alone utility, and save the profile to a network file share in your App Hub that is accessible to the Publish Application wizard. As you publish the application in the Publish Applications wizard, specify the location of the profile: 1. Citrix streaming application profile address. Provide the location of the manifest file (.profile). For example, enter the Full Universal Naming Convention (UNC) path (such as \\citrixserver\profiles\Adobe Reader\Adobe Reader.profile). 2. Application to launch from the Citrix streaming application profile. After this field populates with files, choose the application from the drop-down menu. 3. Extra command-line parameters. (Optional) These parameters are used when the profiled application includes asterisks (**) as a placeholder for additional parameters. If no asterisks are in the command-line string, the extra parameters are added at the end of the command-line.

782

To enable an application for offline access


Before you publish applications for streaming, you must create an application profile using the Citrix Streaming Profiler, a stand-alone utility, and save the profile to a network file share in your App Hub that is accessible to the Publish Application wizard.

Configure streamed applications for offline access as you publish them or later in the Application Properties:

As you publish applications in the Publish Applications wizard, click the Enable offline access check box on the Offline Access page. In Application Properties, select Basic > Streaming settings > Offline Access. Click the Enable offline access check box to enable the feature.

Tip: If, later, some operation in the application fails offline due to a missing component, it will fail while connected as well. The solution is to ensure that you package all the necessary components by thoroughly testing the profile. The server fully caches applications enabled for offline access on user devices; the entire application is sent to user devices while the user is online so that the user can launch the application offline and have full functionality of the application. By default, applications are cached when a user logs on. Select when to cache the streamed application:

Pre-cache application at login. Caches the application when the user logs on (selected by default). However, concurrent logons may slow network traffic. Cache application at launch time. Caches the application when users launch it. Use this option if the number of users logging on at the same time (and pre-caching their applications) could overload the network.

Pre-caching is also possible using third-party tools, such as Microsoft System Management Server (SMS) or Altiris. If you use a third-party caching method, ignore this setting because it is not used; that is, applications are not cached twice.

783

To configure user access to applications


Choose the user accounts that can access applications through the Users page of the Publish Application wizard. To modify user accounts, from the Action menu, select Application properties and then select Users. Before you publish resources, consider how the configuration of user accounts can affect their access, including anonymous access and explicit (configured) user account access. Note: As a best practice, use groups for unique roles to categorize and assign permissions to large numbers of users. An application published to one group of 1,000 users requires the validation of only one object for all 1,000 users. That same application published to 1,000 individual user accounts requires the validation of 1,000 objects. 1. Select how to configure user accounts:
q

Select Allow anonymous users to let all users log on anonymously and start the streamed application without specifying a user name, domain name, and password (selected by default). This selection disables the remaining options on the page. Select Allow only configured users to allow only configured users to start the application. For example, select this option for all streamed applications. Selecting this option enables the Select directory type drop-down list, which allows you to configure the users for this application. You can configure the list later in the application properties.

Note: Streamed applications do not support anonymous users. Additionally, if you enable the streamed application for offline access, these options are not shown. 2. Use the Select directory type drop-down box to select either Citrix User Selector or Operating System User Selector. 3. Click Add. If you selected Citrix User Selector, complete the following tasks in the Select Users or Groups dialog box:

Select your account authority from the Look in drop-down list. The drop-down list contains all trusted account authorities configured on the servers in the farm. These include Novell Domain Services for Windows (NDSfW) domains, Windows NT domains, Active Directory domains, and local servers. (NDSfW domains appear only if previously configured.) When you select an account authority, the user accounts that are part of the selected authority appear in the window below the drop-down list. By default, only user groups appear. Select Show users to display all user names in the selected domain. This option displays every user in the selected domain. For NDS, alias objects also appear. The user accounts you select are listed in Configured users.

784

To configure user access to applications Tip: Instead of selecting names from the list, type them in a text box. To do this, click Add List of Names and use semicolons (;) to separate names. If you selected Operating System User Selector, use the standard Windows dialog box to select your user or group. Note: This option has several limitations. You can browse only account authorities and select users and groups that are accessible from the computer running the AppCenter. In addition, you might initially select users and groups outside the trust intersection of the farm, which causes errors later. Other limitations include the inability to add NDS users and groups. The list of user accounts is added to the Configured Accounts list. Changes take effect the next time the user launches the application.

785

Granting Access to Explicit or Anonymous Users


Before you publish resources, decide how to configure user accounts so that as you publish applications in the wizard, you can select appropriate user access.

Granting Access to Explicit Users


An explicit user is any user who is not a member of the Anonymous group. Explicit users have user accounts that you create, configure, and maintain with standard user account management tools. There are limitations on explicit users who log on to a server farm to run applications: administrators can specify the type of profile, settings, and other configurations for these users. Important: Do not assign any explicit users to the Anonymous group.

Granting Access to Anonymous Users


During XenApp installation, Setup creates a special user group named Anonymous. By default, anonymous users have guest permissions. Publishing applications for this special Anonymous user group lets you completely eliminate the need for user authentication for those applications. When a user starts an application that is configured for anonymous users, the server does not require an explicit user name and password to log the user on to the server and run the application. Anonymous users are granted minimal session permissions that include the following restrictions:

Ten-minute idle (no user activity) time-out Logoff from broken or timed out connections The user cannot change the password (none is required)

When an anonymous user session ends, no user information is retained. The server does not maintain desktop settings, user-specific files, or other resources created or configured for the user device. Note: The anonymous user accounts that XenApp creates during installation do not require additional configuration. If you want to modify their properties, do so with the standard Windows user account management tools.

786

To configure shortcuts for user devices


Configure or modify the application shortcut presented to user devices on the Shortcut presentation page of the Application Publishing wizard. To modify the setting, from the Action menu, select Application properties and then select Shortcut presentation. 1. To select a new icon for the application, click Change icon and use the options on the window. 2. To organize applications within folders on the user device, under Client application folder, enter a folder name for this application. When users view their applications, this application is listed in the folder you entered. 3. To specify the placement of the application shortcut, in the Application shortcut placement section, select one or more of these options:
q

Add to the clients Start menu. Creates a shortcut to this application in the users local Start menu. A folder appears in the first pane of the Start menu in the location you select:
q

Place under Programs folder. This option creates a shortcut under the Programs folder of the local Start menu. If a folder structure is specified in the Start Menu Folder text box, the folder structure is created within the local Programs folder.

Start menu folder. The location of the shortcut within the Start menu (or Programs folder, if selected). For example, to have the application appear under a folder called Reports, enter Reports. For more than one level of folders, separate each folder name with a backslash; for example, Reports\HR\survey. If no folder structure is specified, the application is available from the top level of the Start menu. q Add shortcut to the clients desktop. Creates a shortcut to this application on the users local desktop. Changes take effect after the user reconnects or refreshes the user device.
q

787

To configure access controlled by the Access Gateway


If Access Gateway (Version 4.0 or later) is installed, use the Access Control page of the Publish Application wizard specify the type of connections that allow the application to appear in the list of published applications on the user device. To modify the setting, from the Action menu, select Application properties and then select Access control. For example, if Access Gateway is installed and the application has software requirements, define a filter in Access Gateway and apply the filter to the published application using XenApp. Important: To use this feature, set your servers that receive XML requests to trust those requests. Use this page to view or modify connection types:
q

Allow connections made through Access Gateway Advanced Edition (Version 4.0 or later). This is the default. Select the type of connections that allow the application to appear in the list of applications:
q

Any connection. Allows connections made through Access Gateway (Version 4.0 or later), regardless of filters. This is the default. Any connection that meets any of the following filters. Allows connections made through Access Gateway (Version 4.0 or later) that meet one or more of the connection filters specified in the list.

To Add or Edit a filter, click the respective button and enter the predefined Access Gateway farm name and filter. Allow all other connections. Allows all connections except those made through Access Gateway (Version 4.0 or later). This is the default.

Users who do not have the required software running on the user device cannot access the published application.

788

To associate published applications with file types


As you publish applications, you associate the published item with certain file types present in the Windows registry on the server. Associate published applications with file types initially from the Publish Application wizard. To modify the file types, from the Action menu, select Application properties and then select Content redirection. By associating published applications with file types and then assigning the applications to users, you implement the following automatically:
q

Content redirection from user device to server. Devices running the Citrix Receiver (or other Citrix Plug-in) open all files of an associated type with a specific published application and delivery method. For example, when users double-click an email attachment, the attachment opens in an application based on the file type and delivery method set for those users. Note: If you do not want specific users to launch published applications automatically when opening published content, do not assign published applications associated with file types to those users.

Content publishing. Users connecting through the Web Interface or using the Citrix Receiver open content published on servers with applications published on servers. For example, you publish a Microsoft Word document. When you also publish the Microsoft Word application, associate it with a list of file types (files with the .doc extension, for example), and assign it to a group of users, the published content is opened in the Microsoft Word application published on the server.

File type association is a two-step process. For example, if you want to associate Microsoft Word with the .doc file extension:
q

Publish a document of the Microsoft Word for Windows file type. Publish the Microsoft Word application and associate it with the Microsoft Word for Windows file type. When users double-click the document from the user device, it opens in the Microsoft Word application published on the server. Users connecting through the Receiver or Web Interface can open published content with published applications.

1. Select one or more of the buttons to select the file types that you want the application to open when a user opens a file. Published applications can be associated with one or more file types. 2. To list all file types associated with the application, click Show all available file types for this application. Clear the check box to display only the selected file types. When changing the available file types for an application, select this check box to display the superset of file types available, not just those selected when initially publishing the application. 789

To associate published applications with file types Note: When you associate a file type with a published application, several file extensions can be affected. For example, when you associate the Word document file type, file extensions in addition to the .doc extension are associated with the published application.

790

To update file type associations


File types are associated with applications in a servers Windows registry. If you install and then publish applications after installing XenApp, you must update the file type associations in the Windows registry on the server. Choose which file types are opened with a published application. When you publish an application, a list of available file types appears on the Content redirection page. This list is current only if the data store was updated with the file type associations for the application. Update the data store from the registries of several servers containing an application to associate a complete set of file types with the application. Update the file type associations in the data store if:
q

You installed an application but have not yet published it. You plan to enable content redirection from user device to server or have users open published content using the application. The data store does not already contain the file type associations. If you updated the file types from the registries of other servers hosting the application, the data store already contains the associations. In your environment, certain file types are not supported and must be disabled.

If you publish applications to be hosted on more than one server, be sure to update the file types on each server. To view or modify the file types associated with a published application: 1. In the Citrix AppCenter, select the farm and then select the application. 2. From the Action menu, select Application properties and then select Content redirection. 3. To view and associate file types with the application in the server farms data store, select Show all file types for this application. 4. Optionally, to enable or disable file specific types for the application, select or clear the check boxes. 5. If modified, update file types for the farm or for an individual server:
q

In the AppCenter, select a farm in the left pane and from the Action menu, select Other Tasks > Update file types. Select a server in the left pane and from the Action menu, select Other Tasks > Update file types from registry.

Important: Updating the file type association data for a farm can take a long time. It depends on the number and availability of servers, the number of streamed applications, and the availability of the streamed application file shares. If you do not have permission 791

To update file type associations to access these file shares, an alert appears.

792

To configure alternate profiles


For streamed applications only, use this feature to add an alternate profile for connections that come from specific IP addresses. For example, use an alternate profile to allow one published application for users on either side of a WAN with file servers on their side. When you create an alternate profile, you create a duplicate of the primary profile that is located on a different file share, which is more accessible to the user device. Note that if the alternate profile is different from the primary package, the user device may exhibit strange behavior. To access this dialog box, from the Publish Application wizard, continue to the Alternate profiles page. Alternatively, select a published application in the left pane and from the Action menu, select Modify application properties > Modify all properties > Advanced > Alternate profiles. When you click Add, enter the starting and ending IP range for which the alternate profile applies. Specify the full path of the alternate profile or browse to locate the profile, such as a UNC: \\citrixserver\profiles\Adobe Reader\Adobe reader.profile. After you configure the range, user devices from IP addresses within the specified range access the applications from the alternate profile instead of from the default profile.

793

To pass parameters to published applications


Use the Location page of the Publish Application wizard to enter the command line and pass parameters to published applications. To modify the setting, from the Action menu, select Application properties and then select Location. When you associate a published application with file types, the symbols %* (percent and star symbols enclosed in double quotation marks) are appended to the end of the command line for the application. These symbols act as a placeholder for parameters passed to user devices. If a published application does not launch when expected, verify that its command line contains the correct symbols. By default, XenApp validates parameters supplied by user devices when the symbols %* are appended. For published applications that use customized parameters supplied by the user device, the symbols %** are appended to the command line to bypass command-line validation. If you do not see these symbols in a command line for the application, add them manually. If the path to the executable file includes directory names with spaces (such as C:\Program Files), you must enclose the command line for the application in double quotation marks to indicate that the space belongs in the command line. To do this, follow the instructions below for adding quotation marks around the %* symbols and then add a double quotation mark at the beginning and the end of the command line. Be sure to include a space between the closing quotation mark for the command line and the opening quotation mark for the %* symbols. For example, change the command line for the published application Windows Media Player to the following: C:\Program Files\Windows Media Player\mplayer1.exe %*

794

To reduce user privileges for a streamed application


For applications configured to stream to client devices, only, use this setting to reduce the user privileges for the application, thus reducing security risks. From the User privileges page of the Publish Application wizard or from the Action menu, select Modify application properties > Modify all properties > User privileges. Important: Before you select this option, test the application with a limited access configuration. Some applications expect users to have elevated privileges and might fail to operate correctly when launched by users with a least-privileged user account. Select Run application as a least-privileged user account (not selected by default). This setting configures all users, even those with an administrator account, to run the application with normal user privileges. For more information about least-privileged user accounts, search the Microsoft Technet Web site.

795

To configure application limits and importance


When a user starts a published application, the plug-in establishes a connection to a server in the farm and initiates a session. If the user then starts another published application without logging off from the first application, the user has two concurrent connections to the server farm. Use this page to limit the number of concurrent connections that users can make. You can configure application limits and importance from the Publish Application wizard Limits page, or from the Action menu > Modify application properties > Modify all properties > Advanced > Limits. Under Concurrent instances, select from the following options:
q

Limit instances allowed to run in server farm and then enter the numerical limit in Maximum instances Allow only one instance of application for each user

If Preferential Load Balancing is available in your XenApp edition, this setting (along with the session importance policy setting) determines the Resource Allotment associated with the session. The higher the Resource Allotment of the session, the higher the percentage of CPU cycles allotted to it. In the Application Importance list box, set the priority that is used with the Session Importance setting to determine the level of service for the session in the XenApp farm: High, Normal, and Low.

796

To configure audio and encryption options for published applications


For applications published for a hosted (not streamed to desktop) connection, use the Client options page of the Publish Application wizard to configure the Citrix plug-in audio and encryption options for when users connect to a published application. To modify the setting, from the Action menu, select Application properties and then select Client options. The settings that Citrix plug-ins use to communicate with a published application vary according to the type of plug-in. Citrix Receiver (which includes the Online Plug-in) automatically uses the settings you specify here to communicate with this published application. You can set the encryption level for communications in multiple places in XenApp and your Windows operating system. If a higher priority encryption level is set elsewhere, the settings that you specify can be overridden. The most secure setting out of the following settings is used:

The Citrix User policy settings that apply to the user. The application setting (that is, the level you are setting in this dialog box).

The encryption settings specified here when publishing an application should be at the same level as the encryption settings you specified elsewhere. That is, any encryption setting you specify in the Remote Desktop Session Host Configuration tool or connection policies cannot be higher than the application publishing setting. If the encryption level for an application is lower than any settings you specified for Remote Desktop Session Host Configuration and connection policies, those settings override the application settings. If the minimum requirements check box is selected and the plug-in connection does not meet the most restrictive level of encryption, the server rejects the connection when the plug-in tries to connect to the application. If the minimum requirements check box is selected, the plug-in setting is always used. However, the plug-in setting must be as secure as the server setting or the connection is denied. If you select Minimum requirement under the Encryption list box, plug-ins can connect to the published application only if they are communicating using the specified level of encryption or higher. After you set this encryption level on the server, any plug-ins connecting with that server must connect at that encryption level or higher. If a plug-in is running on a 64-bit computer, only basic encryption is supported. In this situation, setting a level of encryption higher than Basic and selecting the minimum requirements check box prevents plug-ins from connecting.
q

Select Client audio options:

797

To configure audio and encryption options for published applications


q

Enable legacy audio. Select this option to allow audio support for applications to which HDX MediaStream Multimedia Acceleration does not apply. Note: By default, audio is disabled on the user device. To allow users to listen to audio in sessions, turn on audio or give the users permission to turn on audio themselves in the plug-in interface they are using, such as Citrix XenApp.

Minimum requirement. Select this option to allow plug-ins to connect to the published application only if they have audio support. The Minimum requirement check box under the Client audio list box applies only to the legacy audio setting. It does not apply to HDX MediaStream Multimedia Acceleration.

In the Connection encryption section, select one or more of the following options:
q

Select Enable SSL and TLS protocols to request the use of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols for plug-ins connecting to the published application.

q Select Encryption to apply the RC5 encryption level for the connection. In the Printing section, select or clear Start this application without waiting for printers to be created. Selecting this option can allow the plug-in to connect faster. However, if you select this option, the printers may take a few seconds to be created; do not select this option for applications that print to the printer immediately after being launched.

798

To configure application appearance


Define how the application appears to the user through the Appearance page of the Publish Application wizard, or from the Action menu, select Application properties and then select Appearance.
q

To set the default window size, select the Session window size. Specify window size as a standard resolution, custom resolution, percentage of the screen, or full screen. To set the color depth for the application, select the Maximum color quality. The available options are Better appearance (32-bit), Better speed (16-bit), or 256-color (8-bit). To hide the application title bar and maximize the application at startup, change the setting in the Application Startup Settings.

799

To disable or enable a published application


Take published applications offline temporarily or indefinitely when you are maintaining a published application, such as applying an upgrade or a service pack to it. While an application is offline, it is not accessible to users. You can disable multiple applications simultaneously. You can initially disable an application as you publish it in the publishing wizard or enable or disable it anytime from the Citrix AppCenter.

From the Publish Application wizard, continue to the Publish immediately page and select the Disable application initially check box. When checked, the application is published, but users cannot access it until you enable it. In the AppCenter, select the application in the navigation pane, and from the Action menu, select Enable application or Disable application.

Note: If the Disable application initially option is selected and cannot be cleared, either the application requires configured users but none are specified, or the application is of a type that runs on a server (such as an installed application or streamed-to-server application) but no servers are specified.

800

To delete a published application


As you publish updated applications on your servers, delete the older or less-frequently used applications. Deleting a published application does not uninstall the application. It simply removes access to the application through plug-in connections. You can delete multiple applications simultaneously. 1. In the left pane of the Citrix AppCenter, select the application. 2. On the Action menu, select Delete application.

801

To move a published application to another folder


Use this option to move a published application to another folder in the AppCenter tree or to move servers to another server folder. Published applications can be moved only to Applications or folders under Applications. Similarly, servers can be moved only to Servers or folders under Servers. You can move multiple applications simultaneously. 1. In the left pane of the AppCenter, select the application. 2. On the Action menu, select Move to folder. 3. Use the Select destination folder dialog box to change the location of the application.

Alternatively, drag applications into a new folder.

802

To duplicate published application settings


Use the settings of a published application as a template to publish other applications. For example, if you published an application with a specified user list, you might want to apply the same user list to a new application hosted on the same set of servers. If so, copy the first published application, change the name and location to those of the second application, and thereby publish a different application with the same user and server properties. You can duplicate multiple applications simultaneously. 1. In the left pane of the Citrix AppCenter, select the application. 2. From the Action menu, select Duplicate application and a copy of the application appears under the Applications node. 3. Select the duplicated application and change the required properties.

803

To export published application settings to a file


Exporting published application settings to a file allows you to import these settings files and create new applications at a later time. First you export the desired settings to a settings file, and then you import this file to create new applications easily. In particular, import these settings files to overwrite the settings on a previously published application. This export option offers choices to export a single application, the user list only, or server list only. A Citrix administrator requires the View permission for the application folder in which the application resides to export published application settings. 1. In the left pane of the Citrix AppCenter, select the application whose settings you want to export. To export multiple published application settings to a file simultaneously, in the right pane of the AppCenter, press CTRL and select the names of the applications you want to export. 2. From the Action menu, select Other Tasks > Export application settings to a file. Select what to export:
q

Entire Application. Exports the application and all the settings associated with the published application to an .app file. If you choose this option, you can export settings from multiple applications; select them from the left pane of the AppCenter before selecting the export task. Important: If application settings are exported as a batch, they must be imported as a batch.

Server List Only. Exports only the list of configured servers for the application to an ASL file, including any per-server command-line overrides, if applicable. Then select an application and import the server list, replacing the existing server list. Alternatively, import this list of servers when publishing an application by clicking Import from file on the Servers page of the Publish Application wizard.

Note: This task is available only for applications that have servers associated with them. For this reason, this task is unavailable for published content or streamed-to-client applications. You can export the server list associated with one published application only. 3. Settings files are saved in XML format. The settings associated with your published application are saved to a settings file with one of the following extensions: APP, AUL, or ASL. The file name is the same as the application by default. For example, if you choose to export all the application settings of a published application called Notepad123, the default file name for the exported application settings file is Notepad123.app.

804

To import published application settings from a file


After you export published application settings to a file, use them to create a new application or alter the user or server settings of a previously published application. Citrix administrators require Published Application permissions for the application folder in which the application resides to import application settings. 1. In the left pane of the Citrix AppCenter, select either the folder into which you would like to place a new published application or the published application whose user or server settings you want to change. 2. From the Action menu, select Other Tasks > Import application settings from a file. 3. Use the Open dialog box to locate the settings file you want to import.
q

If you selected a folder in Step 1 of this procedure and an APP file in Step 2, the new application appears under the folder you selected. If you selected a previously published application in Step 1 and either an ASL or AUL file in Step 2, click Yes to confirm that you want to overwrite existing settings. The imported ASL or AUL file updates the server settings or user settings of the application, respectively.

Note: If any of the servers or users that were exported for a published application cannot be imported, a warning message appears identifying the list of users or servers that could not be imported. You either proceed or cancel the import at that point. Cancelling the import cancels the entire import operation. This situation might occur if a server was removed from the farm after a published application was exported, if a user was removed from the domain, or if the administrator does not have proper permissions to publish the application on one or more of the servers that were exported.

805

Making Virtual IP Addresses Available to Applications


Some applications, such as CRM and CTI, use an IP address for addressing, licensing, identification, or other purposes and thus require a unique IP address or a loopback address in sessions. Other applications may bind to a static port, which, because the port is already in use, causes the failure of multiple attempts to launch an application in a multiuser environment. For such applications to function correctly in a XenApp environment, a unique IP address is required for each device. Use the virtual IP address feature to allow a dynamically-assigned IP address to each session so that configured applications running within that session appear to have a unique address. Processes require virtual IP if either:
q

They use a hard-coded TCP port number, or They do both of the following:
q

Use Windows sockets, and

Require a unique IP address or require a specified TCP port number Also, this feature lets you configure applications that depend on communication with localhost (127.0.0.1 by default) to use a unique virtual loopback address in the localhost range (127.*).
q

Processes require virtual loopback if either:


q

They use the Windows socket loopback (localhost) address (127.0.0.1), or They use a hard-coded TCP port number

If the application requires an IP address for identification purposes only, configure your server to use the client IP address.

806

How Virtual IP Addressing Works


The Microsoft Remote Desktop (RD) IP Virtualization feature works as follows:
q

In Microsoft Server Manager, expand Remote Desktop Services > RD Session Host Connections to enable the RD IP Virtualization feature and configure the settings. For details, refer to Microsoft help and documentation, including the Microsoft TechNet Web site.
q

Once the feature is enabled, at session start-up, the server requests dynamically-assigned IP addresses from the Dynamic Host Configuration Protocol (DHCP) server. Based on your Virtual IP policy and the settings you configure, the RD IP Virtualization feature assigns IP addresses to remote desktop connections on a per session or per program basis. If you assign IP addresses for multiple programs, they share a per-session IP address. After an address is assigned to a session, it uses the virtual address rather than the primary IP address for the system whenever the following calls are made:

Bindclosesocketconnect, WSAConnect, WSAAccept, getpeername, getsockname, sendto, WSASendTo, WSASocketW, gethostbyaddr, getnameinfo, getaddrinfo XenApp extends the Windows virtual IP feature by allowing the gethostbyname API to return the virtual IP address. In addition, XenApp adds virtual loopback to all APIs. Note: All processes that require the XenApp feature must be added to the programs list for the Virtual IP policy that you enable. Child processes do not inherit this functionality automatically. Processes can be added with full paths or just the executable name. For security reasons, Citrix recommends that you use full paths.

807

Binding Applications
Using the Microsoft IP virtualization feature within the Remote Desktop session hosting configuration, applications are bound to specific IP addresses by inserting a filter component between the application and Winsock function calls. The application then sees only the IP address it is supposed to use. Any attempt by the application to listen for TCP or UDP communications is bound to its allocated virtual IP address (or loopback address) automatically, and any originating connections opened by the application are originated from the IP address bound to the application. In functions that return an address such as GetHostByName() (controlled by a XenApp policy) and GetAddrInfo() (controlled by a Windows policy), if the local host IP address is requested, virtual IP looks at the returned IP address and changes it to the virtual IP address of the session. Applications that try to get the IP address of the local server through such name functions see only the unique virtual IP address assigned to that session. This IP address is often used in subsequent socket calls (such as bind or connect). Often an application requests to bind to a port for listening on the address 0.0.0.0. When an application does this and uses a static port, you cannot launch more than one instance of the application. The virtual IP address feature also looks for 0.0.0.0 in these types of calls and changes the call to listen on the specific virtual IP address. This enables more than one application to listen on the same port on the same computer because they are all listening on different addresses. Note this is changed only if it is in an ICA session and the virtual IP address feature is turned on. For example, if two instances of an application running in different sessions both try to bind to all interfaces (0.0.0.0) and a specific port, such as 9000, they are bound to VIPAddress1:9000 and VIPAddress2:9000 and there is no conflict.

808

To determine whether an application needs to use virtual IP addresses


Some applications cannot run in multiple sessions on XenApp. For example, if the application binds to a fixed TCP port on a specific IP address such as 0.0.0.0 or 127.0.0.1, this prevents multiple instances of the application from running in multiple sessions because the port is already in use. The virtual IP feature of XenApp can help solve this problem. To determine whether or not the application needs to use virtual IP addresses: 1. Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specific IP addresses and ports. 2. Disable the Resolve IP Addresses feature so that you see the addresses instead of host names. 3. Launch the application and, using TCPView, note which IP addresses and ports are opened by the application and which process names are opening these ports.

To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1. To ensure that an application does not open the same IP address on a different port, launch an additional instance of the application.

809

To make virtual IP addresses available to applications running in sessions


Enable these Virtual IP policy settings to add additional support to the Windows IP Virtualization feature. Virtual IP addresses provide published applications with unique IP addresses for use in sessions. This is especially important for Computer Telephony Integration (CTI) applications that are widely used in call centers. Users can access these applications on a XenApp server in the same way that they access any other published application. For more information, see To determine whether an application needs to use virtual IP addresses. Before you begin, in Microsoft Server Manager console, enable the Remote Desktop IP Virtualization feature and configure it to dynamically assign IP addresses using the DHCP server on a per-session or per-program basis. To extend the IP virtualization feature, configure the following Citrix policy settings for Virtual IP:
q

Virtual IP enhanced compatibility. Use this setting if your application uses the GetHostByName API. When enabled, calls to GetHostByName within a session return the virtual IP address for the session (disabled by default). The feature applies only for the applications listed in the virtual IP compatibility programs list. Virtual IP compatibility programs list. Lists the applications that use the virtual IP enhanced compatibility policy. Virtual IP adapter address filtering. Use this setting if your application returns a large number of addresses, which slows down performance. When enabled, the list of addresses returned by GetAdaptersAddresses includes only the session virtual IP address and the loopback address, which can improve performance (disabled by default). The feature is enabled only for the applications listed in the virtual IP filter adapter addresses programs list. Virtual IP filter adapter addresses programs list. Lists the applications that use the IP adaptor address filtering policy.

810

To make a virtual loopback address available to applications running in sessions


Use the virtual loopback policy for applications that use a loopback address for interprocess communication. Enabling this virtual IP policy setting allows each session to have its own loopback address for communication. When an application uses the localhost address (127.0.0.1) in a Winsock call, the virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X, where X.X.X is a representation of the session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that the session ID exceeds the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0) to the maximum of 127.255.255.255. The virtual loopback feature does not require any additional configuration other than specifying in the programs list which processes use the feature. Virtual loopback has no dependency on Virtual IP, so no Microsoft server configuration is needed to enable virtual loopback. For more information, see To determine whether an application needs to use virtual IP addresses. Configure the following Citrix policy settings for Virtual IP:
q

Virtual IP loopback support. Use this setting to allow each session to have its own virtual loopback address for communication (disabled by default). The feature is enabled only for the applications listed in the Virtual IP virtual loopback programs list. Virtual IP virtual loopback programs list. Lists the applications that use the Virtual IP loopback support policy.

811

To supply client IP addresses to published applications on a server


Use the Client IP Address feature if an application fails because it requires a unique address strictly for identification or licensing purposes, and the application does not require a virtual address for communication. This feature hooks only calls that return a host IP address, such as gethostbyname(). Only use this feature with applications that send the value in this type of call to the server application for identification or licensing. If you deploy this feature, consider the IP addresses used by each client device. For example, if two remote users use the same IP address, a conflict will arise due to the duplicate address. When these values are configured, configure either the Virtual IP Processes or Virtual Loopback Processes with the same process names in the Virtual IP compatibility programs list setting or Virtual IP virtual loopback programs list setting for the policy. This function creates and manages the following registry entry, which is still required for the Client IP feature to work: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ CtxHook\AppInit_Dlls\VIPHook\Processname On XenApp, 32-bit Edition, this entry is: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\ AppInit_Dlls\VIPHook\Processname Note: The virtual IP address feature functions only with applications that load the user32.dll system dynamic link library. For identification purposes, some applications require the IP address be unique for a session. Such IP addresses are not needed for binding or addressing purposes. In such a case, configure the session to use the IP address of the client device. 1. On the server on which the applications reside, start regedit. 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. Using regedit, create the following two registry entries:
q

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VIP\ Name: UseClientIP Type: REG_DWORD Data: 1 (enable) or 0 (disable, which is the default)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VIP\

812

To supply client IP addresses to published applications on a server Name: HookProcessesClientIP Type: REG_MULTI_SZ Data: multiple executable names representing application processes that use client IP addresses Note: On XenApp, 32-bit Edition, these entries are found in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VIP\. 3. Close regedit and restart your server. 4. After making the prescribed registry modifications, add the application process in the programs list for the policy. Do not configure the use of client IP addresses if:
q

Plug-ins connect using network protocols other than TCP/IP Plug-ins reconnect to disconnected sessions from different client devices Sessions use a pass-through plug-in

813

VM Hosted Apps
VM hosted apps allows you to deliver applications from virtual machines or physical computers, including blade servers, running Windows single-user desktop operating systems. Users access these applications through a Web browser, the Citrix online plug-in, or Citrix Receiver, just as they would applications hosted from XenApp servers running Remote Desktop Services. VM hosted apps allows you to deliver applications that otherwise must be installed locally or require extensive compatibility testing on XenApp servers. You can publish any Windows application as a VM-hosted application, but ideal candidates include applications that:
q

Are incompatible with or not supported by Remote Desktop Services Require special hardware devices, such as USB, special keyboards, or biometric devices Consume large amounts of computing or graphics resources Require a single-user environment

To use VM hosted apps, you create a VM hosted apps site and populate it with desktop groups configured with applications you want to deliver. Users access these applications but have no direct access to the desktops. You give users access to these applications using the Web Interface. Although VM hosted apps cannot share a farm with XenApp servers, a VM hosted apps site can share a Web Interface site with XenApp server farms. Applications from VM hosted apps sites and XenApp farms appear the same to users.

VM Hosted Apps and XenDesktop


VM hosted apps is available as a feature of XenApp and as a feature of XenDesktop 5.5. VM hosted apps uses Citrix XenDesktop infrastructure to deliver applications hosted on desktops. When you install VM hosted apps as a feature of XenApp, the XenDesktop infrastructure required is installed at the same time. If you are using VM hosted apps as a feature of XenDesktop, the feature is available when you install XenDesktop 5.5; you install nothing additional. VM hosted apps does not support XenDesktop-ready thin clients.

814

VM Hosted Apps

Licensing and VM Hosted Apps


VM hosted apps uses XenApp licenses. Each user consumes one XenApp license for all application sessions, regardless of whether applications are hosted using VM hosted apps or XenApp server. If you are using VM hosted apps as a feature of XenApp, no additional Citrix licenses are required. If you are using VM hosted apps as a feature of XenDesktop 5.5:
q

The XenApp licenses required for the VM hosted apps feature are included with XenDesktop 5.5 Enterprise edition and XenDesktop 5.5 Platinum edition If you want to use VM hosted apps with a version of XenDesktop 5.5 that does not include XenApp licenses, you supply the XenApp licenses required

Key Components of a VM Hosted Apps Deployment


q

XenDesktop Controller. The XenDesktop Controller consists of services that authenticate users, manage the assembly of user 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. Desktop Studio. Provides wizards to guide you through the process of setting up your environment, creating your desktops, assigning desktops to users, and publishing applications on desktops. Virtual Desktop Agent. You install the Virtual Desktop Agent on the desktops in your VM hosted apps site. It manages communication between the desktops and the Controller and between the desktops and user devices.

Using VM Hosted Apps With Other XenApp Features


To provision desktops for VM hosted apps, use Machine Creation Services included in XenDesktop 5.5 or use Provisioning services. Use Profile manager to manage user personalization settings for VM hosted apps. Service monitoring and Edgesight resource manager are not compatible with VM hosted apps, but application performance monitoring can be used with VM hosted apps by downloading Edgesight for Desktops. SmartAuditor is not compatible with VM hosted apps.

815

VM Hosted Apps

Migrating From the Previous Version of VM Hosted Apps


Upgrading the server components of VM hosted apps from a previous version is not supported. You can upgrade the Virtual Desktop Agent. When you install the Virtual Desktop Agent, any previous version of it on the virtual desktop is automatically upgraded. For more information on migrating from this version of VM hosted apps to the previous version, see Upgrading to XenDesktop 5.

816

System Requirements for VM Hosted Apps


Because VM hosted apps uses XenDesktop 5.5 infrastructure to deliver applications, it has no separate system requirements. See XenDesktop 5 System Requirements for system requirements for XenDesktop 5.5 components used by VM hosted apps.

817

Planning Your VM Hosted Apps Deployment


Plan your VM hosted apps deployment as part of planning your overall XenApp deployment. Determine which applications to deliver using VM hosted apps and consider which types of desktops are most appropriate for the applications you want to deliver, what privileges to give desktop users, and how to secure your desktop environment. If your VM hosted apps deployment includes virtual machines, install your hosting infrastructure and Provisioning services separately from VM hosted apps site. A VM hosted apps site can use a dedicated Web Interface server or share one with other VM hosted apps sites and XenApp server farms. When VM hosted apps site shares a Web Interface site with a XenApp server farm, users can access applications from both without regard to how the application is published.

818

Plan

Elements of a VM Hosted Application Site


q

At least one XenDesktop Controller. Adding more controllers to your site increases failover and scalability. A database. By default, a database is created locally when you install the Controller, but you can choose to use a database on a separate server. All VM hosted apps site information is stored on the database; controllers communicate only with the database and not with each other. At least one Desktop Studio. 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 (optional). This Web-based tool enables level-1 and level-2 IT Support staff to monitor a VM hosted apps 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 the XenDesktop infrastructure used by VM hosted apps. Do not install either XenDesktop or the SQL Server database on a domain controller. For more information on Active Directory, see Active Directory Considerations. Virtual machines or physical computers hosting desktops. These desktops deliver applications to users. You install the Virtual Desktop Agent on these machines to manage communications and broker connections. Web Interface. VM hosted apps requires the version of Web Interface provided with it. XenApp farms and VM hosted apps sites can share the same Web Interface site. Access to a Citrix license server. A VM hosted apps site can use its own license server or share one with other VM hosted apps sites and XenApp server farms.

Security Planning for VM Hosted Apps


Secure access and delivery of applications for your VM hosted apps deployment as you would a XenApp server farm. See XenApp planning and administration topics for information on implementing secure connections to published applications. See Web Interface topics for information on securing the Web Interface. Isolate VM hosted apps farms from XenApp server farms:
q

Separate them with firewalls Use separate hosting infrastructure and hypervisor pools

Secure the desktops in your VM hosted apps deployment as described in Security Planning for XenDesktop. When securing desktops for VM hosted apps:
q

Users who are administrators can install software on the desktop even though VM hosted apps does not provide direct access to the desktop

819

Plan
q

Time zone considerations apply to applications that display the time of day Keep in mind that VM hosted apps does not support thin clients

Planning High Availability Deployments


For information on using XenDesktop infrastructure to increase the fault tolerance of your VM hosted app deploy to ensure that business-critical VM-hosted applications are always available, see the XenDesktop topic High Availability Planning.

Planning Administrator Roles


VM hosted apps allows you to create administrators in any of the five XenDesktop administration roles. For more information, see the XenDesktop topic Delegated Administration. XenDesktop full administrators and assignment administrators can create and edite VM-hosted applications. Otherwise, these XenDesktop administration roles can perform tasks on your VM hosted apps site as they would on any other XenDesktop site.

820

Installing and Setting up VM Hosted Apps as a Feature of XenApp


Note: If you are installing VM hosted apps as a feature of XenDesktop, see Installing and Setting up XenDesktop 5. Download VM hosted apps from MyCitrix.com. If you plan to use virtual infrastructure, set it up before configuring your VM hosted apps site:
q

For information on setting up and using XenServer, see the XenServer documentation For information on setting up and using Microsoft System Center Virtual Machine Manager 2008, see Using Microsoft System Center Virtual Machine Manager 2008 with XenDesktop For information on setting up and using VMWware, see Using VMWare with XenDesktop

Perform the VM hosted app installation and set-up tasks in this order: 1. Install the server-side components of XenDesktop needed for your VM hosted apps deployments. 2. Configure the VM hosted apps site. 3. After you have configured a site you can add more controllers to it, if necessary. 4. To manage your deployment remotely, install Desktop Studio on additional computers. 5. Install the Virtual Desktop Agent on any base images, virtual desktops, and physical desktops that are part of your VM hosted apps deployment.

821

Installing and Removing Server Components for VM Hosted Apps


The server components for VM hosted apps are:
q

XenDesktop Controller. The SDKs are automatically installed when you install the Controller. Desktop Studio. The SDKs are automatically installed when you install Desktop Studio. Desktop Studio configures the VM hosted apps site. Web Interface. VM hosted apps requires the version of Web Interface provided with it. Desktop Director. This Web-based tool enables level-1 and level-2 IT Support staff to monitor a VM hosted apps deployment and perform day-to-day maintenance tasks. Installation of Desktop Director is optional. License Server. A VM hosted apps site can use an existing license server.

Installing the server components requires local administration permissions. To install server components from the command line, see XenDesktopServerSetup.exe. The AutoSelect.exe file performs a wizard-based installation of some or all of these components, allowing you to select the components you want to install. By default, all components are selected. When AutoSelect.exe or XenDesktopServerSetup.exe installs the Web Interface:
q

The Web Interface's software prerequisites are install automatically Session sharing and workspace control are disabled by default

The Web Interface autorun provided with VM hosted apps does not install the software prerequisites or disable session sharing and workspace control.

822

Installing and Removing Server Components for VM Hosted Apps

To install server components using the installation wizard


1. Run AutoSelect.exe. 2. Select Install XenDesktop. 3. Accept the End User License Agreement. 4. By default, all server components are selected for installation. Clear any components you do not want to install at this time.
q

If you do not want AutoSelect.exe to install the Web Interface, clear Web Access.

If you want to use an existing license server for your VM hosted apps deployment, clear License Server. 5. Accept the default install location or choose another one.
q

6. 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. 7. Follow the prompts to complete the installations. 8. If you installed the Desktop Studio, unless you clear Configure XenDesktop after closing on the last page of the installation wizard, Desktop Studio starts so that you can configure the VM hosted apps site. If Web Interface is not yet installed, install it before or after configuring the VM hosted apps site. Repeat these steps to install server components on other servers.

To install Web Interface


1. To install the Web Interface, locate WebInterface.exe file in the files you downloaded for VM hosted apps, in the x64/Web Interface folder or the x86/Web Interface folder. 2. Run WebInterface.exe and follow the prompts to complete the installation. See the Web Interface documentation for information on installing and configuring Web Interface. You can configure Web Interface so that your VM hosted apps site shares a Web Interface site with one or more XenApp server farms.

To remove server components


To remove the XenDesktop components used by VM hosted apps, use the Windows control panel. Before removing a Controller from the server, remove it from the VM hosted apps site. For information on removing a Controller from a site, see To remove a controller.

823

To configure a VM hosted apps site


Use Desktop Studio to configure your VM hosted apps. Configuring your VM hosted apps site requires:
q

Licensing the site. Specifying the edition of XenApp or XenDesktop for which you have licenses. Note: Use the XenDesktop SDK instead of Desktop Studio to configure the license edition for your VM hosted apps site if you are using VM hosted apps as a feature of XenDesktop, you want to deliver desktops and VM-hosted applications from the site, and your XenApp edition is different from your XenDesktop edition. Using the SDK, you can specify both a XenApp edition and a XenDesktop edition.

Setting up the site database. Important: If you plan to use 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).

Providing information about your virtual infrastructure. If you are using XenServer, 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.

To perform the initial configuration of your VM hosted apps site: 1. Start Desktop Studio if it has not started automatically after installation. 2. Select Application deployment. 3. Follow the prompts to complete the configuration:

Wizard page

What to do

824

To configure a VM hosted apps site Site Enter a name for your VM hosted apps site. Specify license server information:
q

To configure a license server not installed on the XenDesktop Controller, specify the address as name:port, where name can be a DNS, NetBIOS, or IP address. To configure a license server installed on the XenDesktop Controller, specify the license file location.

If you configured a license server not installed on the XenDesktop Controller, specify the XenApp or XenDesktop edition for which you have licenses. Choose whether you want to use the default database or an existing database:
q

To use the locally installed copy of SQL Express to automatically create the site database on the controller on which you are working, select Use default database. To use an existing database, select Use specified database. The server location must be a DNS, NetBIOS, or IP address, without a port number.

Host

Specify the type of virtual infrastructure host (Citrix XenServer, Microsoft, or VMWare) your VM hosted apps site will connect to, if any. If you specified a virtual infrastructure host type, specify the address, user name, and password of the host. If you specified XenServer as your host type, and High Availability is enabled on XenServer, you can select servers for High Availability configuration. Citrix recommends that you select all servers in the pool to allow communication between XenDesktop and XenServer if the pool master fails. Specify whether you want to create virtual machines manually or use XenDesktop infrastructure to create virtual machines. Enter a name for the connection between the VM hosted apps site and the virtual infrastructure host.

825

To configure a VM hosted apps site Resource This page appears if you are configuring the site to use XenDesktop infrastructure to create virtual machines. Add storage to use when creating virtual machines. If both local and shared storage are available on the hosting unit you must select a single type; you cannot mix them. For each host :
q

Enter a name Specify shared or local Select the storage location

Specify the network the virtual machines reside on 4. To use Access Gateway, pass-through authentication, or smart card authentication with your VM hosted apps site, configure XenDesktop to trust XML services by running this Powershell SDK command:
q

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true After you configure the site, you can add more XenDesktop Controllers. See To add a controller. After the initial configuration, you can change licensing and host configuration settings by starting Desktop Studio and expanding the Desktop Studio > Configuration node.

826

To replace the default XenServer SSL certificate


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

827

To replace the default XenServer SSL certificate

To install a certificate on the controller


1. Locate the root certificate file in Windows Explorer. 2. Right-click the root certificate file and select Install Certificate. The Certificate Manager Install Wizard appears. 3. On the Welcome page, click Next. 4. On the Certificate Store page, select Place all certificates in the following store. 5. Click Browse. 6. Select Show physical stores. 7. Select Local Computer. 8. Click OK. 9. Follow the instructions in the wizard to complete the install.

828

Installing and Removing the Virtual Desktop Agent


The Virtual Desktop Agent has to be present on the virtual machines (VMs) and physical machines 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 components from the command line, see XenDesktopVdaSetup.exe. The AutoSelect.exe file performs a wizard-based installation of the Virtual Desktop Agent: 1. Run AutoSelect.exe. 2. On the Installation page, select Install Virtual Desktop Agent. 3. Associate this desktop with the VM hosted app site. 4. Configure the agent as follows:
q

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. You can also request to have the necessary ports opened for desktop shadowing and Windows Remote Management.

If this installation is running in a VM on a hypervisor, select Optimize XenDesktop Performance to have the VM automatically optimized for use with VM hosted apps. 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 the Citrix Knowledge Center. A summary of what is going to be installed appears.
q

5. When installation is complete the default is to restart the machine; you must do this for the changes to take effect. 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 the Citrix Knowledge Center. VM hosted apps requires desktops and controllers to have synchronized system clocks. This is required by the underlying Kerberos infrastructure that secures the communication 829

Installing and Removing the Virtual Desktop Agent 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, use the Windows control panel. Select Citrix Virtual Desktop Agent. You can then select to add, remove, or reconfigure components, or to remove the Virtual Desktop Agent completely. The Reconfigure Components option enables you to update the site and port numbers.

830

To configure firewalls manually


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://www.iana.org/). For communication between controllers and virtual desktops: %Program Files%\Citrix\XenDesktop\WorkstationAgent.exe requires inbound HTTP (http.sys) on the TCP/IP port you configured at installation time. The default port is 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. Enable the Remote Assistance exception. 2. Add and enable the TCP 135 exception. 3. Add and enable the "%systemroot%\PCHEALTH\HELPCTR\Binaries\helpsvc.exe" exception. 4. See http://support.microsoft.com/kb/555179. Windows Remote Management requires the following ports:
q

TCP/80 for Windows Remote Management 1.1 TCP/5985 for Windows Remote Management 2.0

831

To deploy the Virtual Desktop Agent using Active Directory Group Policy Objects
If you are using Active Directory in your environment, you can deploy the Virtual Desktop Agent to all machines in a domain or Organizational Unit (OU) using Group Policy Objects(GPO). 1. Create a network share and copy the XDSAgent.msi file from the XenDesktop installation media to that share. Note that you must set permissions on that share to allow read access to the .msi file. 2. Create a new GPO for the Organizational Unit containing the computers on which you want to deploy the Virtual Desktop Agent. 3. Edit the GPO you created in Step 2 to add the XDSAgent.msi file, using the following guidelines:
q

Enter the full Universal Naming Convention (UNC) path of the .msi file. For example, \\x-desktop-svr6\SoftwareInstall\XDSAgent.msi

Choose Assigned as the deployment method After you save the new GPO, the Virtual Desktop Agent is installed on computers within the specified OU next time they are restarted.
q

You can restart computers in the OU remotely by running the #shutdown -r -m command. For more information about using Active Directory, see the Microsoft Active Directory documentation. Note: If you deploy the Virtual Desktop Agent using GPO, you must also set the Site GUID using GPO. For more information, see http://support.citrix.com/article/CTX121493.

832

To use Windows XP virtual desktops with Single Sign-on


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:
q

HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GinaDLL HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\CtxGinaDLL

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

833

Managing VM Hosted Apps


To manage your VM hosted apps site, use XenDesktop infrastructure to:
q

Create and manage application desktop groups and the applications they host. Manage your XenDesktop Controller environment. See the XenDesktop topic Managing Your Controller Environment for information on controller discovery, adding controllers, removing controllers, moving controllers between sites, and configuring the Secure Sockets Layer. Configure hosts and connections. See the XenDesktop topic Configuring Hosts and Connections. Enable users to use smart cards. See the XenDesktop topic Using Smart Cards with XenDesktop. VM hosted apps does not support thin clients. Use Citrix policies to control users access or session environment. See the XenDesktop topics Working with XenDesktop Policies and Policy Settings Reference Monitor your VM hosted apps deployment. See the XenDesktop topic Monitoring XenDesktop 5.

Most VM hosted apps management tasks are perform using Desktop Studio or the XenDesktop SDK. To use the SDK, see the XenDesktop topic About the XenDesktop SDK.

834

Working With Machine Catalogs and Desktop Groups


In VM hosted apps, collections of virtual machines or physical computers are managed as a single entity called a catalog. After catalogs of machines are created, the machines can be allocated into desktop groups which then can be used to deliver VM-hosted applications to users. VM hosted apps supports all machine types available in XenDesktop 5.5. For information about machine types, creating catalogs, and managing catalogs, see the XenDesktop information in Creating and Provisioning Desktops. VM hosted apps supports both types of desktop groups available in XenDesktop 5.5: private and shared. For a description of desktop groups, see the XenDesktop topic About Desktop Groups. When you create a desktop group for VM hosted apps, you specify that it is an application desktop group. The characteristics of a desktop depend on its machine type and desktop group type: Machine type and desktop group type Pooled-random machines are used to create shared desktop groups These desktops...

Are virtual machines created by XenDesktop when the catalog containing them is created Discard the user's changes when the user logs off Can be shut down and started by the XenDesktop Controller Are virtual machines created by XenDesktop when the catalog containing them is created Discard the user's changes when the user logs off Can be shut down and started by the XenDesktop Controller Are virtual machines created by XenDesktop when the catalog containing them is created Retain the user's changes when the user logs off Can be shut down and started by the XenDesktop Controller

Pooled-static machines are used to create private desktop groups

Dedicated machines are used to create private desktop groups

835

Working With Machine Catalogs and Desktop Groups Existing machines are used to create private desktop groups
q

Are virtual machines that already exist when the catalog containing them is created Are not used with Provisioning services Can be configured to retain or discard the user's changes when the user logs off Can be shut down and started by the XenDesktop Controller Enable you to use the XenDesktop Controller to manage dedicated blade PCs in the data center Can be configured to retain or discard the user's changes when the user logs off Cannot be shut down or started by the XenDesktop Controller

Physical machines are used to create private desktop groups

q Streamed Are used with Provisioning services machines are used q to create shared Can be configured to retain or discard the user's changes when desktop groups the user logs off When you create application desktop groups:

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 You cannot use a machine in more than one desktop group You can only create a desktop group if at least one machine remains unused in the catalog you select

836

To create an application desktop group


VM-hosted applications are hosted by desktops in application desktop groups. 1. In Desktop Studio, select the Assignments node in the left pane and click Create Application Desktop Group. Use the Create Desktop Group wizard to create the desktop group. 2. 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. The Users page appears if the desktop group is based on pooled - static, existing, or physical machines and these machines have not already been allocated accounts. 3. If you want to give users access to applications hosted on the desktops in a private desktop group, give them access to the desktop group. 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. You can import user data from a file after you create the group. 4. On the Machine allocation page, confirm the mapping of machines to users for any machines that were allocated when the catalog was created. 5. On the Delegation page, select the XenDesktop administrators who will manage this desktop group. 6. On the Summary page, check all details, and enter a name for the desktop group.

837

Managing Application Desktop Groups


See these XenDesktop topics for desktop management tasks you can perform on application desktops:
q

To enable or disable maintenance mode. To find desktops, sessions, and desktop groups. You can find applications by selecting the Applications node in Desktop Studio and searching for the application name. To power manage machines. To shut down and restart desktops. To reallocate desktops. You can reallocate machines in a desktop group and reallocate individual desktops, but not change the number of desktops allocated to a users. To import and export user data. To remove desktops from desktop groups. To delete desktops from catalogs.

To delete an application desktop group, first remove all applications from the desktop group. See To modify applications.

838

Working With Applications


When you create an application, you assign desktop groups to deliver the application to users. All desktops in a desktop group publish the same application or set of applications.

Publishing Multiple Applications on a Desktop Group


If a user accesses one of the applications on a desktop, none of the other applications on that desktop are available to other users. Other users access applications published by the desktop group using other desktops in the desktop group, if other desktops are available. If session sharing is enabled, applications published from the same desktop group share a session when they are accessed by the same user from the same user device. If session sharing is disabled, applications published from the same desktop group are launched in separate sessions. Session sharing requires applications to have the same values for these settings:
q

Color depth Encryption Audio quality Domain name User name Farm name Special folder redirection Virtual COM port mapping Display size Client printer port mapping Client printer spooling EnableSessionSharing TWIDisableSessionSharing

Applications that require different values for these settings cannot share sessions. To help determine if applications are compatible with each other for session sharing, use the Get-BrokerSessionSharingIncompatibleApplication cmdlet in the XenDesktop SDK.

839

Working With Applications

Publishing an Application to Multiple Groups


By publishing the same applications to different types of desktop groups containing different machine types, you can provide a different user experience for the application depending on which desktop group users access the application from. For example, you might want to give one set of users access to an application on a private desktop group, allowing the users to customize the application and retain their changes after ending a session, but give another set of users access to an application on a shared desktop group, so that their changes are discarded when the session ends. If you publish an application from a private desktop group and a shared desktop group, when a user who has access to the application in both desktop groups accesses the application, VM hosted apps launches the application from a desktop in the private desktop group if a desktop is available in that group. If no desktop is available in the private desktop group, VM hosted apps launches the application from the shared desktop group.

Using Content Redirection


You can configure an application to redirect content from the user device to the desktop hosting the application by associating file types with the application. When a user opens a file on the user device of the type associated with the application, this launches the application on a desktop hosting the application. File types available for association with applications are stored in the VM hosted apps site database. The list of file types can be updated by importing file types from desktops in the desktop group assigned to an application while you are configuring content redirection for the application. A desktop must be in maintenance mode to update file types. When you create or modify an application using Desktop Studio, the list of file types you see is filtered to include only those file types likely to be used with the application. To associate other file types with the application, use the XenDesktop SDK.

840

To create an application
1. In Desktop Studio, select the Applications node in the left pane and click Create Application. 2. Use the Create Application wizard to create the application: Wizard page Desktop groups Location What to do Select existing desktop groups or create new desktop groups to host the application. Specify the application executable file. Optional: Specify the command-line and working directory to locate the application. Users Shortcut Specify users that can access the application. Specify how shortcuts to the application appears to users:
q

Select the icon displayed. Browse to the icon you want or accept the default icon. Optional: Specify a folder on the user device for the application shortcut, whether the shortcut appears on the user device Start menu and its location there, and whether it appears on the user device desktop.

841

To create an application Advanced Set advanced options or accept the defaults:


q

Advanced access control.


q

To allow connections through Citrix Access Gateway only, select Allow connections made through Access Gateway. To allow a subset of those Access Gateway connections: Select Any connection that meets any of the following filters, define the Access Gateway farm, and specify 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. Appearance. Specify the window size of the application (full screen, pixel size, or percent of display) and color depth. Content redirection. Select the file types you want to associate with the application to redirect content from the user device. Note: If the file types you want are not displayed, update the file types from an available desktop that is in maintenance mode.

Multimedia. Choose whether to enable legacy audio for the application. Resources. Set the application's CPU priority level and specify whether the application waits for printer creation on start-up. Security. Specify whether the user device is required to use a secure ICA connection. Selecting this option means the user device must connect to the application with a minimum encryption level of 128-bit RC-5 encryption. If the user device does not use this level of encryption, the application fails to launch.

Name

Specify the name displayed to users for the application. Optional: Type a description or tip displayed to users. Set the application's availability and visibility to users.

842

To modify applications
Modifications made to an application might not take effect for users connected to the application until the users have logged off their sessions.

To modify any application properties


You can modify any of an application's properties using a wizard similar to the one used to create applications. 1. In Desktop Studio, select the Applications node in the left pane. 2. Select the application you want to modify and click Application Properties. 3. Use the Application Properties wizard to modify the application. Click the name of the wizard page in the right pane of the wizard to go to that page.

To add or remove desktop groups hosting the application


1. In Desktop Studio, select the Applications node in the left pane. 2. Select the application you want to modify. 3. Add or remove desktop groups: To add or remove desktop groups, click Edit Desktop Groups. To remove desktop groups, select the desktop group you no longer want to host the application and click Remove. Clicking Remove does not delete the desktop group or alter any of its other properties.
q q

To add or remove users who can access the application


1. In Desktop Studio, select the Applications node in the left pane. 2. Select the application you want to modify. 3. Add or remove users:
q

To add users or remove, click Edit Users. To remove users, select the users you no longer want to have access to the application and click Remove.

843

To modify applications

To change the application name displayed to users


1. In Desktop Studio, select the Applications node in the left pane. 2. Select the application you want to modify. 3. From the right-click menu, choose Rename and type the name you want displayed to users for the application.

To remove applications from a desktop group


1. In Desktop Studio, select the Assignments node in the left pane. 2. Select the desktop group you want to remove applications from. 3. Select the Applications tab. 4. Select the applications you want to remove. 5. Click Remove Assignment from....

844

To manage applications sessions


When a user logs on to a VM-hosted application, 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:
q

Log users off sessions Disconnect sessions Send messages to users

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. In Desktop Studio, find the session you want to log off or disconnect:
q

Select the Applications node. Select the application for the session you want to log off ot disconnect. Select the Sessions tab.

q Use Search to locate the session. 2. 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. In Desktop Studio, find the users you want to send a message to:
q

Select the Applications node. Select the application for the session you want to log off ot disconnect. Select the Sessions tab. Select the session for the user you want to send a message to.

q Use Search to locate the session. Select a session, desktop, or user. 2. Click Send message.

3. Compose your message and click OK.

845

To manage applications sessions

846

Organizing Applications with Folders and Tags


Use folders and tags to organize applications within Desktop Studio.

To use folders
1. To create a folder: a. Select the Applications node or expand the node and select a folder within the node. b. Click Create Folder. 2. To manage the folders and the applications:
q

Select the folder or application and use the right-click menu. To copy a folder or application, drag and drop it. To move a folder or application, hold the Shift key while dragging and dropping it.

To use tags
In VM hosted apps, tags let you categorize applications in Desktop Studio. Note: Tags used with VM hosted apps cannot be used to restrict access to machines or applications. To add tags to an application or edit tags added to an application: 1. In Desktop Studio, select the Applications node in the left pane. 2. Select an application and click Edit tags.

847

Customizing Your XenDesktop Controller Environment


After completing the initial setup tasks, you can customize and optimize your VM hosted apps deployment:

Create additional administrators for the site, if necessary. See the XenDesktop topic Delegating Administration Tasks. XenDesktop full administrators and assignment administrators can create and edit VM-hosted applications. Set up any general Citrix policies that you require, including policies for printing. See the XenDesktop topic Working with XenDesktop Policies for details of configuring policies. Configure USB support. Configure HDX technologies to optimize users' audio and multimedia experience. See Enhancing the User Experience With HDX. Configure time zone settings to allow users to see their local time when using applications that display a time of day. See the XenDesktop topic Configuring Time Zone Settings. Configure connection timers to provide appropriate durations for uninterrupted connections, idle sessions, and disconnected sessions. See the XenDesktop topic Configuring Connection Timers. Configure workspace control to enable users to roam between different user devices. See the XenDesktop topic Workspace Control in XenDesktop.
q

Workspace control is enabled by default if you installed the Web Interface using the Web Interface autorun. Workspace control is disabled by default if you installed the Web Interface using AutoSelect.exe or XenDesktopServerSetup.exe. If a user accesses a VM-hosted application from a desktop hosted from the same VM hosted apps site as that application, workspace control is not supported.

848

Configuring USB Support for VM Hosted Apps


You can enable users to interact with a wide range of USB devices during a VM hosted apps 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 VM hosted apps session and do not require special configuration:

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, see http://support.citrix.com/article/ctx119722 in the Citrix Knowledge Center. By default, certain types of USB devices are not supported for remoting through VM hosted apps. 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 VM hosted apps session:
q

Bluetooth dongles USB network interface cards USB hubs USB graphics adaptors

USB support allows hosted applications access to USB devices that are connected to the user device. In environments where security separation between client and hosted application is needed, users should connect only appropriate USB devices. You can also set policies at the desktop group and user device that restrict the types of USB devices that will be made available to the hosted application. For information on all USB devices supported, see http://support.citrix.com/article/ctx119861 in the Citrix Knowledge Center. Double-hop USB is not supported. That is, if a user connects to a VM hosted apps session for a hosted desktop, the VM hosted apps session does not have USB support.

849

Configuring USB Support for VM Hosted Apps

To configure USB support for desktops


To configure USB support for the desktops you are using to deliver applications:
q

Add the Client USB device redirection policy setting to a Citrix User policy and set it to Allowed. If necessary, update the range of USB devices supported.

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:
q

Edit the plug-in 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 plug-in through Active Directory Group Policy: dvd root \os\lang\Support\Configuration\icaclient_usb.adm. Configure administrator override rules for the Virtual Desktop Agent by adding the Client USB device redirection rules setting to a Citrix User policy. The range specified in the Virtual Desktop Agent must correspond exactly to the range specified on the client; if it does not, then only the devices allowed in both ranges are allowed.

The product default rules are stored in the following locations:


q

For 32-bit computers: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\GenericUSB Type=String Name="DeviceRules" For 64-bit computers: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\PortICA\GenericUSB Type=String Name="DeviceRules"

The default configuration is as follows: DENY: class=02 # Communications and CDC-Control DENY: class=09 # Hub devices DENY: class=0a # CDC-Data DENY: class=0b # Smartcard DENY: class=e0 # Wireless controller ALLOW: # Otherwise allow everything else Note: Do not edit the product default rules. Instead, configure overrides through Citrix policies as policies are evaluated before any product default rules. To make changes to the Virtual Desktop Agent through Active Directory Group Policy, create or edit a Citrix User policy and add the Client USB device redirection rules setting. By default, no rules are specified. When you add this policy setting, you will need to create your own USB redirection rules to suit your environment.

850

Configuring USB Support for VM Hosted Apps When you are creating new USB redirection rules, refer to the USB Class Codes, available from the USB Web site at http://www.usb.org/. USB redirection 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 SubClass Prot

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 from either the device descriptor or an interface descriptor

Protocol from either the device descriptor or an interface descriptor When creating new USB redirection rules, be aware of the following:
q

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.

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

Support for USB Mass Storage Devices


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 Citrix User policy setting. The main differences between the two types of remoting policy are:

851

Configuring USB Support for VM Hosted Apps Feature Enabled by default Read-only access configurable Safe to remove device during a session Client drive mapping Yes Yes No Client USB device redirection No No

Yes, provided users follow operating system recommendations for safe removal If both client drive mapping and the Client USB device redirection policy setting are enabled, then if a mass storage device is inserted before or after the session starts, it will be redirected using 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.

852

Publishing App-V Sequences in XenApp


You can deliver the Microsoft Application Virtualization (App-V) sequences to users by publishing the sequences in XenApp and delivering the Microsoft Application Virtualization Desktop client through Citrix Merchandising Server and Citrix Receiver Updater. To deliver App-V sequences using the Citrix application streaming feature, Citrix provides a conduit utility that supports a dual mode execution. With dual-mode, users launch applications as they normally do, and the conduit checks for presence of the App-V client. If the App-V client is installed, the App-V sequence streams to the user device; if not, the application launches from a XenApp server and streams to the user device. System requirements:
q

Citrix supports App-V sequences on all operating systems supported by Microsoft App-V. Citrix Receiver Updater for Windows supports App-V clients 4.5 and 4.6. User devices must have the Citrix Offline Plug-in 6.x installed locally.

Citrix recommends the following process:


q

Deliver the App-V client to users through Citrix Merchandising Server and Citrix Receiver Updater Publish App-V sequences for virtualizing on user devices if possible, otherwise virtualizing on XenApp servers

Users can then launch the App-V sequences on their desktops by clicking on the icons delivered through XenApp. Before you start, locate the following files and have them available:
q

Microsoft Application Virtualization Desktop Client installer (setup.exe) from your Microsoft Desktop Optimization Pack (MDOP) installation media, to upload to the Merchandising Server.

App-V Integration Kit from Citrix ( http://citrix.com/English/ss/downloads/details.asp?downloadId=2310183&productId=1689163&ntref=clie ). Save the unzipped contents locally:
q

Save the App Streaming To AppV Conduit folder on your App Hub (the server where you store your profiles). The folder contains a pre-created AppStreamingToAppVConduit.profile file, as well as the required support files for the profile. This single profile can be used to publish an unlimited number of App-V sequences. Upload the App-V MetaData files and the App-V client's setup.exe file to the Merchandising Server to create an App-V client. Citrix provides these files to add

853

Publishing App-V Sequences in XenApp the functionality to the client needed for Citrix Receiver Updater. These files include:
q

AppV_MetaData.xml AppVReg.msi

AppVReg_MetaData.xml Save the Streaming Conduit - source code folder locally. These files are not needed to publish your applications, but you can use them to modify the conduit, if needed. This folder contains the source code for the conduit.
q

To deliver the App-V client with the Citrix Merchandising Server and Citrix Receiver Updater
1. In the Merchandising Server Administrator Console, navigate to the Plug-in > Upload page. 2. To upload the App-V_Reg plug-in components: a. For the Metadata File, click Browse to navigate to the unzipped location of AppVReg_MetaData.xml. b. For the Plug-in File, click Browse to navigate to the unzipped location of AppVReg.msi. c. Click Upload. 3. To upload the App-V client components: a. For the Metadata File, click Browse to where you downloaded App-V_MetaData.xml. b. For the Plug-in File, click Browse to navigate to the location of the Microsoft Application Virtualization Desktop Client installer, setup.exe. c. Click Upload. 4. Configure a delivery to communicate with your App-V server. (For additional information on creating and scheduling deliveries, see the Merchandising Server documentation.) An overview of the entire Plug-in upload and delivery process when using Merchandising Server 1.0 can be viewed at http://www.citrix.com/tv/#videos/773. If users have the Self-service Plug-in, they can add published App-V sequences as they normally add applications.

854

Publishing App-V Sequences in XenApp

To publish App-V sequences for streaming to desktops


The conduit utility AppStreamingToAppVConduit (which is the pre-created Citrix .profile) provides pre-launch and post-exit scripts that enable a dual-mode delivery method. This delivery method uses the App-V client to stream the application to the user device. If the user device does not support streaming or lacks the App-V client, the conduit triggers the secondary method and delivers the application to a XenApp server, which then delivers the application through session virtualization using a remote display protocol. The application can be locally installed on the XenApp server, or streamed through Citrix application streaming using the App-V client installed on the server. 1. In the Citrix AppCenter, open the application publishing wizard and follow the on-screen instructions. 2. Name the application with a name familiar to users, such as "Microsoft PowerPoint 2007." 3. On the Type page, configure the dual-mode delivery method:
q

Select Application. For application type, select the dual-mode option: Streamed if possible, otherwise accessed from a server.

For the server application type, select the secondary delivery method, such as Installed application. 4. On the Location page:
q q

Browse to your App-V server where both the conduit utility and App-V sequence are located. The application to launch is AppStreamingToAppVConduit. Add the command-line parameters to locate the specific App-V sequence on your App-V server. For Command Line: Enter the full path to your Microsoft Application Virtualization Client executable, followed by the location of your App-V sequence, such as:

"C:\\Program Files\Microsoft Application Virtualization Client\sfttray.exe" "\\appv\content\Off2k7\Microsoft Office PowerPoint 2007 12.0.6425.0000.osd" 5. On the Shortcut presentation page, manually select the icon from your icons directory (no icon by default), such as the icon for Microsoft PowerPoint. 6. Finish the publishing wizard as you normally do. For more information about the AppStreamingToAppVConduit utility, see http://support.citrix.com/article/CTX124860 in the Citrix Knowledge Center.

855

Publishing App-V Sequences in XenApp

To launch the App-V sequences


When users log on:
q

Citrix Receiver Updater informs them of Plug-in updates, and if they accept the App-V client, it installs silently in the background. If they use the Citrix Self-service Plug-in for the Receiver, they can subscribe to App-V sequences through that Plug-in.

Users launch applications as they normally do, and the conduit checks for presence of the App-V client:
q

If the App-V client is installed, the App-V sequence streams to the user device, where it runs in the App-V isolation environment. If the client is not installed (or the device does not support streaming for other reasons), the conduit triggers the Offline Plug-in to initiate a XenApp server session where the application executes and is presented to the user over a remote display protocol.

856

XenApp Connector for Configuration Manager 2007


XenApp Connector for System Center Configuration Manager 2007 enables you to use Microsoft System Center Configuration Manager 2007 to:
q

Deploy and publish applications to XenApp servers Manage the delivery of Microsoft Windows Server Update Services (WSUS) software updates to XenApp servers

XenApp Connector uses the Power and Capacity Management Concentrator to coordinate the power states and load consolidation of farm servers when sending Configuration Manager advertisements and installing applications and Windows updates. XenApp Connector has two components:
q

XenApp Data Connector Configuration Manager Console Extension

XenApp Data Connector


XenApp Data Connector is the bridge between the XenApp farm and Configuration Manager. It manages XenApp server collections and worker groups in Configuration Manager and gathers configuration data defined in the Configuration Manager console to configure XenApp servers. XenApp Data Connector manages XenApp servers and gathers farm data using the XenApp PowerShell SDK.

Configuration Manager Console Extension


Configuration Manager Console Extension extends the Configuration Manager console to provide a graphical user interface enabling you to deploy applications to XenApp servers and publish XenApp hosted applications. Install Configuration Manager Console Extension on the same server as the Configuration Manager console.

857

System Requirements for XenApp Connector for Configuration Manager 2007


XenApp Connector for Configuration Manager 2007 supports XenApp 6.5 for Windows Server 2008 R2. The XenApp Connector components, XenApp Data Connector and Configuration Manager Console Extension, can be installed on a single server or on different servers. The XenApp Connector requires less than 1 MB of disk space to install and creates only log files that can be automatically purged. The hardware requirement of the XenApp Connector components are identical to those of their supported operating systems.

XenApp Data Connector


Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 Microsoft Windows 7

XenApp Data Connector requires connectivity to:


q

Computer running XenApp 6.5 PowerShell SDK Power and Capacity Management Concentrator (XenApp 6.5 for Windows Server 2008 R2 version) SMS Provider for the Configuration Manager site

Configuration Manager Console Extension


Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 Microsoft Windows Server 2008 (32-bit and 64-bit)

Supported versions of Microsoft System Center Configuration Manager 2007:


q

Microsoft System Center Configuration Manager 2007 R2 Microsoft System Center Configuration Manager 2007 R3

858

System Requirements for XenApp Connector for Configuration Manager 2007

859

Install and Set Up XenApp Connector


Before you install XenApp Connector for Configuration Manager 2007:
q

Identify the computers in your XenApp Connector installation:


q

Decide where to install XenApp Data Connector. Decide where to install Configuration Manager Console Extension. Configuration Manager Console Extension is installed on the same server as Microsoft System Center Configuration Manager 2007 console. Identify the SMS Provider for the Configuration Manager site. Identify the computer you plan to use as your XenApp PowerShell host. This is the computer running the XenApp PowerShell SDK that the XenApp Data Connector uses to manage XenApp servers and gather farm data. Ensure this computer is not managed by Power and Capacity Management.

Identify a server running the Power and Capacity Management Concentrator that XenApp Data Connector will use to manage power states and load consolidation. Install PowerShell and enable PowerShell remoting on the servers you plan to use for the following:
q q

XenApp Data Connector XenApp PowerShell host Power and Capacity Management Concentrator

SMS Provider for the Configuration Manager site You can enable PowerShell remoting through the cmdlets Enable-PSRemoting and Set-ExecutionPolicy with RemoteSigned in the 32- and 64-bit PowerShell windows.
q q

To enable XenApp Data Connector to communicate with the XenApp PowerShell host, the server running the Power and Capacity Management Concentrator, and the SMS Provider for the Configuration Manager site:
q

Determine which port to use as the remote PowerShell port and decide whether to use an SSL connection.

Open the port on the firewalls or routers used by these servers. In the policies of the computer on which you install the XenApp Data Connector, ensure that the Do not allow storage of passwords and credentials for network authentication option is disabled.
q

Create or designate the account used to run the XenApp Data Connector, with these attributes:
q

Citrix full administrator

860

Install and Set Up XenApp Connector


q

Local administrator on each of the following:


q

XenApp PowerShell host Server running the Power and Capacity Management Concentrator

SMS Provider for the Configuration Manager site Rights to log on as batch job on the computer on which the XenApp Data Connector will be installed
q

Appears on the Security tab of Configuration Manager site's properties dialog box. (This dialog box is viewed and edited through the Configuration Manager console.)

After installing and configuring the Configuration Manager Console Extension, you add this account to the Security tab of Citrix XenApp Farm collection's properties dialog box. The XenApp Connector configuration wizard creates Citrix XenApp Farm collection.

861

Install and Set Up XenApp Connector

To install and configure XenApp Connector


1. On the server on which you want to install XenApp Connector, if Configuration Manager is running, close it. 2. Locate XAConfigMgr07.exe on the XenApp installation media and run it on the server on which you want to install XenApp Connector. 3. Follow the instructions in the installation wizard. 4. If Launch Configuration when Setup exits is selected on the last screen of the installation wizard, the configuration wizard starts when the installation is complete. If you choose not to run the configuration wizard now, you can do so later by running ConfigWizard.exe. 5. Follow the instructions in the configuration wizard. Depending on which components you are installing, the configuration wizard asks for the following information:
q

Credentials for the account used to run XenApp Data Connector For the XenApp PowerShell host, the server running the Power and Capacity Management Concentrator, SMS Provider for the Configuration Manager site:
q

Fully qualified domain name (FQDN) Remote PowerShell port

q Whether to configure the remote Powershell port to use an SSL connection Site code of the Configuration Manager site

Whether to enable Windows Server Update Services (WSUS) for use with the XenApp Connector

Whether to create a maintenance window for XenApp servers and maintenance window's start time, end time, and frequency 6. On the Settings Summary page, click Advanced Settings to edit the following information:
q q

Advertisement processing interval, which is how often XenApp Connector checks the Configuration Manager database for new advertisements targeted at the XenApp farm XenApp farm sync interval, which is how often XenApp Connector updates the Configuration Manager database with new, changed, or removed XenApp farm servers and worker groups XenApp publication interval, which is how often XenApp Connector checks the Configuration Manager database for new or updated publication information XenApp power-on interval, which is how long in advance off-line servers are powered on to receive software updates Advertising wait settings, such as the number of days an advertisement waits before logging off connected users and the number of minutes after a maintenance notification message is sent until users are forced to log off

862

Install and Set Up XenApp Connector 7. If you installed the Configuration Manager Console Extension, after the configuration wizard is finished running, go to the Configuration Manager console and add the account used to run XenApp Data Connector to the Security tab of Citrix XenApp Farm collection's properties dialog box.

863

Uninstalling XenApp Connector


Uninstall the components of XenApp Connector for Configuration Manager 2007 through the Control Panel. When XenApp Data Connector is uninstalled, all files and folders created when it installed on the server are removed. When the Configuration Manager Console Extension is uninstalled, these items are removed from the Configuration Manager console:
q

XenApp Publications folder in Software Distribution XenApp Publication Container in Packages All folders named Programs for XenApp in the Programs folder in each package container

Refresh the Configuration Manager console to see the results of the uninstall. When you uninstall XenApp Connector, some items are not removed:
q

Log files are not removed. Items are not removed from the Configuration Manager database. When you reinstall XenApp Connector, items that were visible in the Configuration Manager console are visible again.

864

Enabling Power and Capacity Management for XenApp Connector


XenApp Connector for Configuration Manager 2007 uses the XenApp Power and Capacity Management feature to manage the power states and load consolidation of XenApp servers when sending Configuration Manager advertisements and installing applications or Windows Server Update Service (WSUS) updates. This enables XenApp Connector to install applications and WSUS updates on servers managed by Power and Capacity Management with minimal disruption to user sessions. To allow Power and Capacity Management to manage power states and load consolidation of XenApp servers, XenApp Connector changes the servers' power controller preference and power control mode:
q

If no advertisements are pending for a XenApp server, the server's power controller preference remains at 1st choice, the default ranking for servers managed by Power and Capacity Management. When you designate an online XenApp server to receive an advertisement, XenApp Connector:
q

Takes control of the server's power controller preference and changes it to 5th choice Sets the server state to Maintenance just before the application is installed

Changes the server's power controller preference to 1st choice, relinquishes control of the server's power controller preference, and enables users to log on, after advertisement processing completes When you designate an offline XenApp server to receive an advertisement, XenApp Connector:
q q

Takes control of the server's power controller preference and changes it to 6th choice Sets the server state to Maintenance and the server control mode to Unmanaged for the duration of the maintenance window or the processing of all pending advertisements, whichever occurs first Powers on the server

Changes the server's power controller preference to 1st choice and relinquishes control of the server's power controller preference, after advertisement processing completes or the maintenance window closes The XenApp power-on interval, which is set when XenApp Connector is configured, determines how long in advance of processing advertisements offline servers are powered on.
q

Note: While a XenApp server's power controller preference is controlled by XenApp Connector, attempting to change the server's power controller preference using Power 865

Enabling Power and Capacity Management for XenApp Connector and Capacity Management console results in a warning saying that changing the servers power controller preference with the console might cause undesirable effects. XenApp Connector uses Power and Capacity Management to manage the installation of installed XenApp applications and WSUS updates; it does not affect the deployment of Microsoft Application Virtualization (App-V) sequences. Citrix recommends you document your current XenApp Power and Capacity Management server configuration before modifying it for XenApp Connector.

To enable XenApp Connector to use Power and Capacity Management


To enable XenApp Connector to use Power and Capacity Management to manage XenApp server power states and load consolidation, from the Power and Capacity Management console, configure these settings for the XenApp server:
q

Set power control mode to Managed. Set power control preference to 1st choice, 5th choice, or 6th choice.

866

Deploying Applications to XenApp Servers and Publishing Applications with XenApp Connector
XenApp Connector for Configuration Manager 2007 uses the same packages and programs to deploy applications to XenApp servers that Microsoft System Center Configuration Manager uses to distribute software to Configuration Manager client computers. You can use XenApp Connector to install applications on XenApp servers and deploy Microsoft Application Vitalization (App-V) sequences to XenApp servers. After deploying an application or App-V sequence to XenApp servers, use XenApp Connector to publish it. To deploy an App-V sequence to XenApp servers, use the Configuration Manager App-V deployment procedure for terminal servers. To deploy an installed XenApp application to XenApp servers, use Configuration Manager to create a software distribution package and program for the application. Advertise this package and program to deploy the application:
q

If the application can be installed without restarting the server For applications that require restarting the server, if you plan to place all servers in the farm into maintenance at the same time to install the application

Otherwise, after creating the software distribution package and program, create and advertise a program for XenApp for the application. This program for XenApp enables you to deploy the application in a way that manages XenApp user connections so that the application is installed without disrupting user sessions. For Configuration Manager to manage a XenApp server, send it advertisements, and include it in publications, its information must be included in the Configuration Manager database.

To create a program for XenApp


1. In the Configuration Manager console, expand the software distribution container for the application you want to deploy. 2. Within the Programs folder, right-click Programs for XenApp and select New > New program for XenApp. 3. Enter the name, installer program, and any comments for the program for XenApp, and click OK. This creates a program for XenApp for the application you want to deploy. You can automatically access the publication wizard now or configure the publication of the application later. Automatically accessing the publication wizard from the program wizard specifies the package associated with the program as the target of the application being

867

Deploying Applications to XenApp Servers and Publishing Applications with XenApp Connector published.

To publish an application
Publishing an applications from the Configuration Manager console is similar to publishing application from the Citrix AppCenter console, but instead of publishing to servers, you publish to a collection or package. The application publishing wizard that XenApp Connector provides within the Configuration Manager console enables you to specify the published application's type and how it appears to users, which users can access it, and its publication schedule. You can use the application publishing wizard to configure an application for publication before or after creating an advertisement for the program that deploys with the application. 1. If the application publishing wizard is not already running, start it from the Configuration Manager console by right-clicking the XenApp Publications folder and selecting New > XenApp application publishing. 2. To publish the application, follow the instructions in the wizard. When publishing an application you indicate the following:
q

Whether the application you are publishing is an installed XenApp application or Microsoft Application Virtualization (App-V) sequence. If you did not start the application publishing wizard from the program wizard, indicate whether your publishing target is a collection or a package.
q

If you are certain that the application you are publishing is already installed on all the servers, specify a collection as the target. When you specify a collection as the target, the Connector configures all servers in the collection to give users access to the application. Using a collection as the target is best suited to publishing applications that are always installed on servers, such as Internet Explorer.

If the application you are publishing might not already be installed on all servers, specify a package as the target. When you specify a package as the target, only after servers have processed the package advertisement and the application program do they give users access to the application. This ensures that users only access servers where the application is already installed. 3. Configure the content redirection advanced setting if the application you are publishing is:
q q

An App-V sequence

An installed XenApp application located on a computer other than the computer on which the Configuration Manager console is installed If the file type you want does not appear in the list of file types, click Add to add a custom file type.
q

To advertise the program for XenApp


868

Deploying Applications to XenApp Servers and Publishing Applications with XenApp Connector After creating a program for XenApp, advertise it to those XenApp servers on which you want to deploy it. 1. In the Configuration Manager console, expand the software distribution container for the application you want to deploy. 2. Within the Programs folder, right-click Program for XenApp for the program you want to advertise and select Advertise. 3. Select the collection of XenApp servers or worker groups on which you want to install the application. 4. To ensure users are not connected to the server during the installation schedule the advertisement. a. Specify multiple mandatory assignments, one for each installation attempt. Create at least two mandatory assignments for each maintenance window. b. Select Rerun if failed previous attempt as the program rerun behavior. Unlike other advertisements created in Configuration Manager, advertisements for XenApp have a timeout period after which the XenApp Connector notifies users and logs them off. You set the timeout period when you configure the XenApp Connector. To ensure that the last mandatory assignment logs users off and installs the application, ensure the period between the first and last mandatory assignments is longer than the timeout period. For XenApp servers that are configured to allow XenApp Connector to use Power and Capacity Management to manage their power states and load consolidation, XenApp Connector changes the servers' power controller preference to drain user connections from targeted servers that have not processed the advertisement.

869

To publish applications with XenApp Connector for Configuration Manager 2007


Publish XenApp hosted applications from the Microsoft System Center Configuration Manager 2007 console through the XenApp Connector for Configuration Manager 2007. Publishing XenApp hosted applications from the Configuration Manager console is similar to publishing XenApp hosted applications from the Citrix AppCenter console, but instead of publishing to servers, you publish to a collection or package. The publishing wizard that XenApp Connector provides within the Configuration Manager console also enables you to specify the published application's type and how it appears to users, which users can access it, and its publication schedule. For Configuration Manager to manage a XenApp server, send it advertisements, and included it in publications, its information must be included in the Configuration Manager database. Important: Do not edit the XenApp Publications folder. It is for the XenApp Connector's internal use only. 1. If the application publishing wizard is not already running, start it from the Configuration Manager console by right-clicking the XenApp Publications folder and selecting New > XenApp application publishing. 2. To publish the application, follow the instructions in the wizard. When publishing an application you indicate the following:
q

Whether the application you are publishing is an installed XenApp application or Microsoft Application Virtualization (App-V) sequence. Whether your publishing target is a collection or a package.
q

If you are certain that the application you are publishing is already installed on all the servers, specify a collection as the target. When you specify a collection as the target, the Connector configures all servers in the collection to give users access to the application. Using a collection as the target is best suited to publishing applications that are always installed on servers, such as Internet Explorer.

If the application you are publishing might not already be installed on all servers, specify a package as the target. When you specify a package as the target, only after servers have processed the package advertisement and the application program do they give users access to the application. This ensures that users only access servers where the application is already installed. If you are publishing an App-V sequence, always specify the file type or file types you want associate with the application for content redirection. The wizard cannot associate an appropriate default file type for App-V sequences.
q

870

To publish applications with XenApp Connector for Configuration Manager 2007 3. Configure the content redirection advanced setting if the application you are publishing is:
q

An App-V sequence

An installed XenApp application located on a computer other than the computer on which the Configuration Manager console is installed If the file type you want does not appear in the list of file types, click Add to add a custom file type.
q

871

Deploying WSUS Updates to XenApp Servers with XenApp Connector


XenApp Connector for Configuration Manager 2007 enables you to manage the delivery of Microsoft Windows Server Update Services (WSUS) software updates to XenApp servers. By using the Power and Capacity Management feature to coordinate the power states and load consolidation of the XenApp servers, XenApp Connector deploys WSUS updates with minimal disruption of user sessions. To use XenApp Connector to manage the delivery of WSUS updates: 1. Ensure that XenApp Connector is enabled to use Power and Capacity Management on the XenApp servers to which you want to install WSUS updates. 2. If you have not already done so, configure XenApp Connector for WSUS updates and configure a maintenance window for XenApp servers: a. On the server on which XenApp Connector is installed, run the XenApp Connector configuration wizard, ConfigWizard.exe. b. On the Configuration Manager Site page of the wizard, enable WSUS, create a maintenance window for XenApp servers, and specify maintenance window's the start time, end time, and frequency. Follow the prompts to complete the configuration wizard. The configuration wizard creates a Citrix WSUS task sequence advertisement in the Advertisements folder of the Software Distribution node of the Configuration Manager console. This advertisement has the maintenance window schedule you specified. 3. Use Configuration Manager console to deploy one or more WSUS updates to servers in the XenApp Farm collection. The deadline you set for this software update installation is used only if the Citrix WSUS task sequence fails to install the update before that time. XenApp Connector uses Power and Capacity Management to drain users from XenApp servers you targeted to receive the WSUS update. At the specified times within the maintenance window, Citrix WSUS task sequence runs on every targeted XenApp server and installs the WSUS update on XenApp servers that have no user sessions. If the WSUS update has not been installed on all targeted XenApp servers when the software update installation deadline is reached, Citrix WSUS task sequence forces installation of the update on the any server that does not yet have the update installed and reboots the server, even if it has active user sessions.

872

Viewing and Maintaining Log Files


XenApp Connector for System Center Configuration Manager 2007 creates these log files:
q

Log files created by the tasks that make up XenApp Data Connector. The log files are updated as the tasks run. The log files are retained or deleted automatically, according to settings in the XenApp Connector configuration file. Log files created when either component of the XenApp Connector is installed. Log files created when the Configuration Manager Console Extension is installed.

To view log files created by the tasks that make up XenApp Data Connector, use the SMS Trace tool provided with the Microsoft System Center Configuration Manager 2007 Toolkit V2. To view other XenApp Connector log files, use the SMS Trace tool or a text editor that maintains formatting, such as WordPad.

XenApp Data Connector Task Log Files


Log files created by the tasks that make up XenApp Data Connector are created and appended in the log folder in the install directory. Task Name XenApp Program and Package Service Log File Names Most recent output: Program and Package Service.log Archived output: Program and Package Service.date & time.log XenApp Publication Service Most recent output: Publication Service.log Archived output: Publication Service.date & time.log XenApp and ConfigMgr Synchronization Service Most recent output: Synchronization Service.log

Archived output: Synchronization Service.date & time.log By default, XenApp Connector retains and deletes files on this schedule:
q

One log file containing the most recent output and one time-stamped archive is retained for each service task When a log file containing the most recent output reaches 250 KB, the next time the task runs, the log file becomes a time-stamped archive and a new file containing the most recent output is created

To change these defaults, as well as parameters that control the types and information contained in the log files and the appearance of the log file when viewed with the SMS Trace tool, edit the XAConnector.config file.

873

Viewing and Maintaining Log Files

Install Log Files


Log files created when either component of the XenApp Connector is installed are created in the user's %temp% folder. Important: Windows Server 2008 R2 deletes a session's temporary directory when the server restarts. To preserve the install log files, either copy the logs to a safe place before the server restarts or change your local computer policy (before installation) to prevent deletion of the temporary directories.

Log File Names CitrixMsi-XAConfigMgrx64-(date & time) (64-bit) CitrixMsi-XAConfigMgrx32-(date & time) (32-bit) Citrix-XAConfigMgrSetup-(date & time) Setup (date & time)

Contents MSI information MSI information Setup user interface information Setup user interface information

Configuration Manager Console Extension Log Files


Log files created when the Configuration Manager Console Extension is installed are created and appended in the "log" folder in the install directory. Log File Name AdminUI Install Contents Errors and actions during installation of the Configuration Manager Console Extension

874

Enterprise Management
This section of Citrix eDocs contains XenApp components and features that help you manage and maintain your servers and farms.
q

Management Pack for System Center Operations Manager 2007 Installation Manager Managing Providers and WMI

875

Management Pack for System Center Operations Manager 2007


The Citrix XenApp Management Pack supports Microsoft System Center Operations Manager 2007 and Microsoft System Center Operations Manager 2007 SP 1 on servers running Citrix XenApp 5 for Windows Server 2008, Citrix XenApp 6 for Windows Server 2008 R2, and Citrix XenApp 6.5 for Windows Server 2008 R2. The Management Pack allows you to monitor the health, availability, and configuration of XenApp servers and server farms, and anticipate and react quickly to problems that might occur. Operations Manager is a management solution for Microsoft Windows server deployments that collects, filters, analyzes, responds to, and reports information about computersall from a single view on a desktop console. You can use Operations Manager for performance monitoring, event management, alerting and reporting, and trend analysis. Operations Manager also includes an extensive product support knowledge base, with links to Knowledge Base articles on the Microsoft Web site that provides you with centralized access to the information you require to manage a complex enterprise environment and troubleshoot problems occurring on servers and applications across the network. For more information about Operations Manager, see Microsofts Web site: http://www.microsoft.com/. The Management Pack interprets and reports information supplied by:
q

The XenApp Provider that runs on Citrix servers The Licensing Provider that runs on license servers System events generated on Citrix servers

Key features and benefits of using the Management Pack in your XenApp deployment are: State monitoring The Management Pack monitors the overall state of your deployment, determining its availability and performance state at any given time by comparing real-time data collected from the Provider and the Licensing Provider against thresholds defined in the Management Pack. You can view this information at different levels, from the state of the deployment as a whole, right down to the state of individual servers. Event management The Management Pack captures a variety of events from servers and server farms. These events are collated and then presented through the Operations Manager Console, allowing an overall view of server operation. Performance monitoring

876

Enterprise Management You can use the Management Pack to monitor server performance. You can customize rules and create new ones to set thresholds for key performance attributes in the server farm. Extensive knowledge base The Management Pack includes an extensive product support knowledge base, including links to relevant Citrix Knowledge Center articles. Centralized access to information about managing servers allows you to quickly interpret events and troubleshoot problems. Customizable monitors, rules, and alerts Changes in state, such as raised events or breached thresholds, trigger rules and alerts to notify you of any state changes. You can configure the Management Pack to customize how it responds to state-changing events by modifying and extending the monitors and rules to meet the needs of your environment. Important: Alerts relating to farm metric servers or summary database servers are not raised on servers running XenApp 5. Citrix views Citrix views are available in the Citrix Presentation Server folder. These views allow you to monitor events and alerts raised for servers and server farms, and to identify trends and performance issues occurring on servers and published applications. Easy installation The Management Pack consists of three files that are available on the installation media or for download from http://www.citrix.com/. To install the Management Pack, simply import these files into Operations Manager using the Operations Manager Console. Sealed Management Pack The Management Pack is packaged, versioned, and signed with a certificate. The certificate used to sign the Management Pack is provided by a publicly trusted Certificate Authority verifying that the software was developed and produced by Citrix. Sealing the Management Pack means that you can import and customize the Management Pack and all your customizations are saved separately from the original pack. When you upgrade to a new version of the Management Pack, all your customizations are retained and included in the next version of the pack. For further information about installing the XenApp Provider and the Licensing Provider, see Managing Providers and WMI.

877

Management Pack for System Center Operations Manager 2007


The Citrix XenApp Management Pack supports Microsoft System Center Operations Manager 2007 and Microsoft System Center Operations Manager 2007 SP 1 on servers running Citrix XenApp 5 for Windows Server 2008, Citrix XenApp 6 for Windows Server 2008 R2, and Citrix XenApp 6.5 for Windows Server 2008 R2. The Management Pack allows you to monitor the health, availability, and configuration of XenApp servers and server farms, and anticipate and react quickly to problems that might occur. Operations Manager is a management solution for Microsoft Windows server deployments that collects, filters, analyzes, responds to, and reports information about computersall from a single view on a desktop console. You can use Operations Manager for performance monitoring, event management, alerting and reporting, and trend analysis. Operations Manager also includes an extensive product support knowledge base, with links to Knowledge Base articles on the Microsoft Web site that provides you with centralized access to the information you require to manage a complex enterprise environment and troubleshoot problems occurring on servers and applications across the network. For more information about Operations Manager, see Microsofts Web site: http://www.microsoft.com/. The Management Pack interprets and reports information supplied by:
q

The XenApp Provider that runs on Citrix servers The Licensing Provider that runs on license servers System events generated on Citrix servers

Key features and benefits of using the Management Pack in your XenApp deployment are: State monitoring The Management Pack monitors the overall state of your deployment, determining its availability and performance state at any given time by comparing real-time data collected from the Provider and the Licensing Provider against thresholds defined in the Management Pack. You can view this information at different levels, from the state of the deployment as a whole, right down to the state of individual servers. Event management The Management Pack captures a variety of events from servers and server farms. These events are collated and then presented through the Operations Manager Console, allowing an overall view of server operation. Performance monitoring

878

Management Pack for System Center Operations Manager 2007 You can use the Management Pack to monitor server performance. You can customize rules and create new ones to set thresholds for key performance attributes in the server farm. Extensive knowledge base The Management Pack includes an extensive product support knowledge base, including links to relevant Citrix Knowledge Center articles. Centralized access to information about managing servers allows you to quickly interpret events and troubleshoot problems. Customizable monitors, rules, and alerts Changes in state, such as raised events or breached thresholds, trigger rules and alerts to notify you of any state changes. You can configure the Management Pack to customize how it responds to state-changing events by modifying and extending the monitors and rules to meet the needs of your environment. Important: Alerts relating to farm metric servers or summary database servers are not raised on servers running XenApp 5. Citrix views Citrix views are available in the Citrix Presentation Server folder. These views allow you to monitor events and alerts raised for servers and server farms, and to identify trends and performance issues occurring on servers and published applications. Easy installation The Management Pack consists of three files that are available on the installation media or for download from http://www.citrix.com/. To install the Management Pack, simply import these files into Operations Manager using the Operations Manager Console. Sealed Management Pack The Management Pack is packaged, versioned, and signed with a certificate. The certificate used to sign the Management Pack is provided by a publicly trusted Certificate Authority verifying that the software was developed and produced by Citrix. Sealing the Management Pack means that you can import and customize the Management Pack and all your customizations are saved separately from the original pack. When you upgrade to a new version of the Management Pack, all your customizations are retained and included in the next version of the pack. For further information about installing the XenApp Provider and the Licensing Provider, see Managing Providers and WMI.

879

System Requirements for the Management Pack


To use the Management Pack, you must be running Operations Manager 2007 or Operations Manager 2007 SP1. For information about Operations Manager 2007 minimum hardware and software requirements, see your Operations Manager 2007 documentation. To obtain information about servers and the server farm, the Management Pack requires the XenApp Provider to be installed on every XenApp computer that you want to monitor. The XenApp Provider is a data provider that extracts information about the server on which it is installed and presents this to the Operations Manager Agent. The Provider supplies information about the server and, where appropriate, about the farm in which this server operates. The Management Pack also requires the Licensing Provider to be installed on the license servers if you want to monitor them. The Licensing Provider is a data provider that supplies information about Citrix licenses. For example, the Management Pack displays information about the number of licenses in use for each license pool, and raises alerts if the pool is low on available licenses or if a license is about to expire. Both Providers are installed by default. For more information about the Providers, see Managing Providers and WMI. Only licensed servers running Citrix Presentation Server 4.0 or later are fully supported as managed servers. Unlicensed servers and servers running earlier versions are not monitored by the Management Pack. The Management Pack does not support agentless monitoring.

880

To install the Management Pack


1. Locate the three files, Citrix.PresentationServer.mp, Citrix.Library.mp, and Citrix.Licensing.mp. The files on the installation media are also available for download from http://www.citrix.com/. Note: If you do not want to monitor license servers, you can omit the Citrix.Licensing.mp file. 2. Log on to the Operations Manager and open the Operations Console. 3. Click Administration in the Administration pane and expand the Administration node. 4. Right-click Management Packs, then select Import Management Pack(s). 5. Select the three Management Pack files and click Open. Note: If you do not want to monitor license servers, you can omit the Citrix.Licensing.mp file. The Management Pack successfully monitors the other servers in your deployment. Important: Citrix.Library.mp provides the foundation components for all Citrix Management Packs and must be imported prior to importing any other Citrix Management Packs. In addition, Citrix.Licensing.mp requires Citrix.PresentationServer.mp. If you import these files without also importing the files they are dependent upon, the Management Pack will not function properly. However, the Management Pack functions correctly after these dependencies are resolved. 6. Click Import. Note: If you are upgrading the Management Pack, you are notified that you are replacing the existing Management Pack. Continuing with the upgrade will not affect any customized rules or company knowledge articles that you added to the Management Pack. After the Management Pack is successfully installed or upgraded, Operations Manager automatically deploys it to all the managed computers in your management group.

881

Management Pack Post-Installation Tasks


After you install the Management Pack, add the servers you want to monitor to the list of agent-managed computers if you are not already monitoring these computers using Operations Manager. Ensure that all license servers are also added to the list of managed computers in Operations Manager. To add these servers to the list of managed computers, install the Operations Manager agents on the respective servers. For more information, see your Operations Manager documentation. Some health monitors specific to XenApp are disabled by default because they require configuration to make them appropriate to your site. For information about how to configure these monitors, see Configuring and Enabling Site-specific Monitors. Important: Ensure that the XenApp Provider is installed on every server that you want to monitor, and that an appropriate license is allocated in each server farm being monitored. For more information about the XenApp Provider and the Licensing Provider, see Managing Providers and WMI.

882

Uninstalling the Management Pack


You can uninstall the Management Pack using the Operations Manager Console. Uninstalling the Management Pack removes all the references to it from the Operations Manager database, including the base monitoring objects provided by the Management Pack along with any dynamically discovered event, performance, or alert data. For information about uninstalling management packs, see your Operations Manager documentation. Important: If there are any other management packs in Operations Manager that are dependent on the Citrix XenApp Management Pack, you must uninstall them before you can successfully uninstall the Management Pack.

883

Security Considerations for the Management Pack


To display information about servers and server farms using the Management Pack, you must have the appropriate administration rights in Operations Manager. Operations Manager uses a component called the Operations Manager Agent Service to retrieve data from servers, including servers running the XenApp Provider. The Operations Manager Agent Service runs using the Operations Manager Agent Action account. Because the Provider requires Citrix administration rights, the Operations Manager Agent Action account must also have full Citrix administration rights. If this account does not have the appropriate rights, error messages appear when attempting to access WMI data specific to XenApp. You must be a member of the appropriate Operations Manager user or administrator group to view alerts and information on the Operations Manager Console. If you are not a member of the appropriate group, access to information and functions is restricted, regardless of whether you are a Citrix administrator or not. Important: Users who have the appropriate administration rights in Operations Manager can view information relating to XenApp in the Operations Manager Console. However, these users might not be Citrix administrators. Depending upon how your accounts are set up in Operations Manager, users might be able to view information about XenApp that is not normally available to them in the Access Management Console or the XenApp Advanced Configuration tool. Therefore, Citrix recommends that you take this into consideration when managing your Operations Manager user and administrator groups. By default, the WMI namespace for the Licensing Provider allows access to all authenticated users. Therefore, you might want to review access control list (ACL) settings for the Licensing Provider namespace (\root\CitrixLicensing).

884

Troubleshooting Query Errors in Operations Manager


When using Operations Manager, you might receive an error similar to: The Microsoft Operations Manager 2000 WMI provider could not register query 'select * from metaframe_server_loadlevel.' Ensure that the WMI Query is valid. This error message appears because the XenApp Provider communicates with XenApp when retrieving information, and XenApp allows only Citrix administrators to access this information. If this error message appears, configure the Operations Manager Agent Action account so that this account has full Citrix administration rights on all the server farms you are monitoring.

885

Citrix Managed Objects Included in the Management Pack


The Management Pack monitors and reports on several Citrix-specific objects. These objects are described in the following table.

Object Citrix Deployment Citrix Farm

Description Represents a discovered XenApp deployment that can consist of multiple farms and zones. Represents a XenApp farm that can consist of multiple zones. A farm is monitored by a single farm metric server. Represents a zone that can consist of multiple Citrix managed servers. A zone is managed by a single zone data collector. Represents a managed server performing the role of zone data collector. Represents a managed server performing the role of farm metric server. Represents a server monitored by Operations Manager. Represents a server not monitored by Operations Manager. An unsupported server is not running a version of XenApp supported by the Management Pack running the XenApp Provider. Represents a server not monitored by Operations Manager. An unlicensed server is running the XenApp Provider, but is unlicensed or missing a valid license. Operations Manager checks the licenses on these servers hourly. Represents a server running Citrix Licensing. Represents a server running any XenApp component.

Citrix Zone

Citrix Zone Data Collector Citrix Farm Metric Server Citrix Managed Server Citrix Unsupported Server

Citrix Unlicensed Server

Citrix License Server Citrix Server

886

Citrix Views Included in the Management Pack


The Management Pack includes a number of Citrix views that are available in the Citrix Presentation Server folder of the Operations Console. These views allow you to monitor events and alerts raised for XenApp servers and server farms, and to identify trends and performance issues occurring on servers and published applications. There are five main types of Citrix views: alert and event views, Citrix deployment state views, the Citrix Presentation Server topology diagram view, Citrix performance views, and license server views. All Citrix views can be customized to meet your organization's requirements.

887

To view state monitors and processing rules


You can see the state monitors and processing rules that define how Operations Manager collects, processes, and responds to information, and that generate the Citrix views. 1. In the Operations Console, click Authoring in the Navigation pane. 2. Select Management Pack Objects > Rules or Management Pack Objects > Monitors

The monitors and rules are grouped according to the object to which they apply. You can configure these monitors and rules and create new ones; see your Operations Manager documentation for more information. Note: After you install the Management Pack, some Citrix views might be empty for a short time until the discovery script runs. By default, this script runs hourly.

888

Viewing XenApp Alert and Event Information


Alert and event views provide you with real-time event and alert information. Alert views group alerts by severity, and event views sort events by date and time. In both alert views and event views, the Details pane shows extra information including Citrix Knowledge Center articles about each particular alert or event.

View All Citrix Events Active Alerts from Citrix Servers Active Citrix Alerts

Description Displays all the events raised by XenApp components on managed servers. Displays all unresolved alerts raised against managed servers by all management packs (not only the XenApp Management Pack). Displays all unresolved alerts raised by the Management Pack.

889

Viewing XenApp Deployment State Information


Each XenApp deployment state view summarizes the state of a component along with the state of any components directly related to it; for example, a XenApp farm view displays the state of the farm itself along with the state of the zones that are part of the farm.

View Citrix Farms Citrix Managed Servers Citrix Unlicensed Servers Citrix Unsupported Servers Citrix Zones Farm Metric Servers Zone Data Collectors

Description Displays the state of the XenApp farms in your deployment. Displays the state of the XenApp managed servers in your deployment. Displays the state of the XenApp unlicensed servers in your deployment. Displays the state of the XenApp unsupported servers in your deployment. Displays the state of the XenApp zones in your deployment. Displays the state of the farm metric servers in your deployment.

Displays the state of the zone data collectors in your deployment. State views display high-level state information about a XenApp component without detailing how and why changes of state occurred. You can investigate the reasons behind state changes by right-clicking a managed object in the Results pane of any view and selecting Show Health Explorer. The Health Explorer presents the detailed state of the selected object, displaying the state of each of its monitors on the left and a record of events that caused state changes on the right. The type of managed object you select determines which monitors appear in the Health Explorer. For example, if you select a farm or a farm metric server, the Health Explorer displays farm-wide alert monitors. Monitors are grouped by potential problem sources. For example, all printing issues are grouped together. Expanding the printing node allows you to see specific printing monitors, together with the history and causes of any state changes.

890

Viewing Citrix Presentation Server Topology Diagrams

891

Viewing Citrix Presentation Server Topology Diagrams The Citrix Presentation Server topology diagram is an Operations Manager diagram view that provides a hierarchical representation of a XenApp deployment, showing farms, zones, servers, license servers, and their relationships.

Diagram showing a Citrix Presentation Server topology diagram view The following table lists the XenApp-specific icons used in the topology view and their meanings:

892

Viewing Citrix Presentation Server Topology Diagrams Icon Meaning Deployment

Server farm

Server

License server

Farm metric server

Zone data collector

Zone

The topology view provides the following information:


q

The name of the farm, zone, or server. Zone names are prefixed by their farm names.

893

Viewing Citrix Presentation Server Topology Diagrams


q

The current alert state, propagated up the tree so that state changes are visible even when the view is collapsed. Whether a server is a zone data collector or a farm metric server and the hosting server name.

ToolTips are used to provide the following additional information:


q

XenApp version number, including hotfixes where appropriate Role (zone data collector or farm metric server) The name of the license server the computer uses Logons enabled or disabled For zones, the number of servers in the zone For zone data collectors, the name of the zone being managed For farm metric servers, the name of the farm being monitored

Note: If you make changes to your deployment and move one or more servers from one zone to another zone, the topology diagram view may still show the moved servers in their original zone. Reimporting the Management Pack forces the topology view to refresh.

894

To reconfigure security settings on zone data collectors


By default, computers running discovery scripts cannot submit data about any other computer. This means that for zone data collectors to submit data about other servers in the farm, you must change their security settings. 1. In the Operations Manager console, expand the Administration node. 2. Select Administration > Device Management > Agent Managed. 3. Then, for each zone data collector: a. Double-click the computer name. b. On the Security tab, select Allow this agent to act as a proxy and discover managed objects on other computers. Important: If you do not set this option for your zone data collectors, the topology diagram view will not display any discovered objects. This might cause an error message to appear in the Operations Manager event log.

895

Viewing XenApp Performance Information


Citrix performance views provide performance monitoring details about your deployment.

View Active Sessions Published Application Load From Load Balancing

Description Displays the number of active sessions on each managed server. Displays the published application load from the Load Manager component. Note that this information is available only if you are using Load Manager in your server farm and you configured the application load level. In addition, you must also enable the Sample published application load from load balancing rule in MOM. See Sample Published Application Load for more information. Displays the server load from the Load Manager component. Note that this information is available only if you are using Load Manager in your server farm.

Server Load From Load Balancing

896

Viewing License Server Information


License Server views provide information about the licenses and license servers in your deployment. Important: If you did not install the Citrix.Licensing.mp file, these views are not available.

View Active Citrix License Server Alerts License Servers Pooled Licenses In Use

Description Displays all unresolved alerts raised against license servers by the Management Pack. Displays the state of the license servers in your deployment. Displays the number of pooled licenses in use, as a percentage of the total number of pooled licenses.

897

Configuring and Enabling Site-specific Monitors


Most state monitors and processing rules that are specific to XenApp are enabled by default and begin functioning after you install the Management Pack. However, some of these are disabled by default because they require configuration specific to your site. Disabled monitors appear dimmed. The monitors in the following table control how Operations Manager processes and responds to information.

Disabled Monitor Too Many Disconnected Sessions

Associated Alert The number of disconnected sessions on this server is high.

Description of Monitor Defines an upper limit of disconnected XenApp sessions. The global default is 100 sessions. If this limit is exceeded, the alert warns you about possible performance problems. Note that this limit is used for all managed servers. This monitor is disabled by default because the acceptable number of disconnected sessions varies between sites. Runs a script that retrieves information from the XenApp Provider to determine if an XenApp session has been idle too long. If a session is idle too long, the script triggers an alert in response to the Operations Manager event. The alert signals problems with the session. Note that all sessions, including idle sessions, consume resources. Therefore, idle sessions might cause problems where server resources are limited. This monitor is disabled by default because the acceptable length of time for which a session should be idle varies among sites.

Citrix Session Idle Too Long

A Citrix session has been idle too long

898

Configuring and Enabling Site-specific Monitors Too Many Active Sessions The number of active sessions on this server is high. Triggers an alert to signal that there are too many active sessions running on a server. This monitor is disabled by default because the number of active sessions is dependent upon several variables including the hardware and software in your deployment. Sample Published Application Load From Load Balancing Enabling this monitor displays information in the Published Application Load From Load Balancing health monitoring view. Retrieves WMI information about the published application load from Load Manager. This monitor is disabled by default because this information is available only if you are using Load Manager in your server farm and if you configured the application load level.

899

To open the AppCenter from the Operations Manager Console


If you installed the Citrix AppCenter on the Operations Manager server, you can start the console from the Operations Manager Console. You can start the AppCenter from any non-empty Citrix view. Important: To start the AppCenter, the ASCLAUNCHPATH environment variable must be set to the path of the console; for example, C:\Program Files (x86)\Citrix\Citrix Delivery Services Console\Framework\CmiLaunch.exe. 1. Log on to the Operations Manager Console. 2. Perform one of the following:
q

In the Actions pane, select Start Access Management Console. Right-click an object in the Results pane, and select Managed Citrix Presentation Server tasks > Start Access Management Console.

900

Installation Manager
Installation Manager is a XenApp feature you can use to distribute hot fixes, patches, and file/registry updates. You can also use Installation Manager to distribute simple applications, but Citrix recommends using application streaming or App-V to manage applications. Additionally, you can use XenApp Connector for Configuration Manager 2007 R2 to install and publish applications to XenApp servers. Use Installation Manager to:
q

Schedule the installation of MSI or MSP packages on target XenApp servers. You can also specify an MST (transform) file to change parameters in the MSI package. Distribute XML files generated by Windows Task Scheduler to target XenApp servers. Automate server restarts after installing an application on a target XenApp server, making the application and the server ready for use. You can also notify users of upcoming operations such as a server restart. Associate a published application with a XenApp server. View task status to see if it ran successfully on target XenApp servers.

You can use Installation Manager through a Microsoft Management Console (MMC) snap-in, or by issuing custom Microsoft PowerShell cmdlets.

Installation Manager Components and Packages


An Installation Manager environment has the following components: Component Task management computer File share Description The computer where you manage task deployment. Transfers and stores task files, including storing cache files containing previously scheduled tasks and results. For regional deployments, you may want to use multiple file shares.

Target servers The XenApp servers on which tasks are deployed. The task management computer and the file share can be on separate computers or on one of the target servers. Installation Manager comprises two packages: Package Administration Description Contains the core Installation Manager functionality. Install this package on the task management computer.

901

Installation Manager Utilities Contains the PowerShell cmdlets required for MSI or MSP installation on target servers. Install this package on the target servers. Note: If you will not use Installation Manager to deploy MSI or MSP packages, you do not need to install the Utilities package on the target servers.

902

Requirements and Installation

Platform Requirements
The task management computer (where you install the Administration package) can be a separate computer or one of the target servers.
q

Supported platforms
q

Windows Vista (32-bit and 64-bit) Windows 7 (32-bit and 64-bit)

Windows Server 2008 R2 (64-bit) Required software


q q

.NET Framework 3.5 SP1 PowerShell 2.0 (on Vista platforms, PowerShell 1.0 is also supported)

MMC 3.0 XenApp 6 for Windows Server 2008 R2 must be installed on the Windows Server 2008 R2 platform if you want to publish applications using the management console, associate published applications with servers, or deploy existing published applications to target servers.
q

The target servers must be running Windows Server 2008 R2 and XenApp 6 for Windows Server 2008 R2. Each target server requires the following software (this software is required for XenApp installation, so it is likely to already be installed):
q

.NET Framework 3.5 SP1 PowerShell 2.0

If you will be using Installation Manager to deploy MSI or MSP packages to target servers, you must install the Utilities package on each target server. There are no additional software requirements to install or use the Utilities package on the target servers. The file share can be on any Windows Server 2003 or later platform. The file share can be on a separate computer, on the task management computer, or on a target server.

903

Requirements and Installation

Account and Permission Requirements


Installation Manager uses implicit authentication for remote access to the Windows Task Scheduler API. To create Installation Manager tasks, you must have administrative access to the Installation Manager console and the target servers, have full control of the file share, and belong to the Local Administrator group on each target server. The following example illustrates account and permission configuration: 1. Create an Active Directory group named Installation Manager Administrators. 2. Add the Installation Manager Administrators group as a member of each target servers Local Administrator, Distributed COM Users, and Event Log Readers local groups. (To simplify the permissions process by combining groups, you could create a Group Policy Preference policy in Active Directory.) 3. Assign full control rights to the Installation Manager Administrators group for the file share and folder. The group requires rights to manipulate Access Control Lists (ACLs) on the share folder. When a task is scheduled, Installation Manager automatically assigns permission from the target servers to the file share.

To install Installation Manager


1. Download the Installation Manager for Windows Server 2008 R2 software (IM_2008_R2.zip) from My Citrix to a shared folder on the network. Extract the .zip file and save the appropriate .msi files:
q

Save the Administration package (IMAdmin.msi for 32-bit systems or IMAdmin-x64.msi for 64-bit systems) to the task management computer. Save the Utilities package (IMUtilities-x64.msi) to each target server.

Note: A target server requires the Utilities package only if you plan to schedule the installation of MSI or MSP packages on the target server. 2. Be sure all users are logged off the computers where you will install the Installation Manager packages. Close all applications, including the consoles. 3. On the task management computer, double-click the Administration package (IMAdmin.msi for 32-bit systems or IMAdmin-x64.msi for 64-bit systems) and follow the wizard instructions. 4. If you will be using Installation Manager to deploy MSI or MSP packages to the target server, on each target server, double-click the Utilities package (IMUtilities-x64.msi) and follow the wizard instructions. 5. In the MMC on the task management computer, use Add/Remove Snap-in to add the Installation Manager snap-in. When prompted for the Installation Manager shared folder, either type the path or click Browse and navigate to it.

904

Requirements and Installation When you install the Utilities package on a target server, four Windows firewall rules are enabled (these rules are disabled by default). These rules allow access to the Task Scheduler and Event Log Management services using DCOM. The enabled rules are:
q

Remote Scheduled Task Management (RPC and RPC-EPMAP) Remote Event Log Management (RPC and RPC-EPMAP)

Uninstalling Installation Manager


Before uninstalling Installation Manager, be sure all users are logged off. Close all applications, including the console. Use the Remove Programs feature in the Control Panel to remove the Installation Manager package MSI. To remove the Utilities package from target servers, you can use the Remove Programs feature, or you can schedule a command-line task to uninstall the package from all target servers.

905

Using the Installation Manager Console


The Installation Manager console contains standard MMC panes and the following custom panes:
q

The Task pane lists tasks created using Installation Manager. This information is stored in the file share as IMTask.xml. The Target pane displays the results on each target server of the task selected in the Task pane. This information is stored in subdirectories of the shared folder as ImTaskResult.xml. The display refreshes automatically every ten minutes. To manually refresh the display, click Refresh in the Actions pane. The lower pane displays the PowerShell cmdlet equivalent of an action selected in the Actions pane. For example, if you select a task named InstallApp in the Task pane and a target server named srv2 in the Target pane, then click Refresh in the Actions pane, the lower pane displays: Get-IMTask Name InstallApp Targets srv2 Log \\im\InstallApp\IMTaskResult.xml

From the Installation Manager console, you can:


q

Schedule installation of an MSI or MSP package Schedule installation of a Task Scheduler file Schedule installation of a command-line task Associate published applications with servers Reschedule a task Remove a scheduled task

To schedule installation of an MSI or MSP package


To schedule installation of MSI or MSP packages using Installation Manager, the Utilities package must be installed on the target servers. From the Installation Manager console, click Schedule MSI package distribution in the Actions pane. In the Schedule MSI Package Distribution dialog box:
q

Enter the name of the task. The task name must start with an alphabetic character. The name must be unique, unless you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select this option, the task is updated with the new definition.

906

Using the Installation Manager Console


q

In the Target list, specify the target servers where you want to install this package. Click Servers to select from Active Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name. In MSI/MSP file path, enter the location of the MSI or MSP package to be scheduled for installation. To include a transform file, specify its location in MST list. To make the MSI, MSP, and MST files available from a single shared folder accessible by all target servers, click Advanced and specify a Shared folder in the Advanced Options dialog box. Any selected MSI, MSP, and MST files will be copied to this folder, if not already present. Installation Manager assigns read permission from the target servers to the file share.

Enter the date and time to start the installation in Schedule date and time, or select Now to launch the task immediately. Use Session Options to specify what happens to user sessions on the target servers during and after the installation process.

Option Disable session logon during installation process Logoff existing sessions

What happens when selected Prevents users from logging on during the installation. Forces users to log off the server before launching the installation. You can specify how long to wait before users are logged off; you can also send a message to logged-on users that instructs them to save their work and log off.

Restarts the server after installation. You can specify how long to wait after the installation completes to restart the server. If Installation Manager fails to schedule a task on a server (for example, when a server is offline), it tries to reschedule the task. To specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error occurs.)

Reboot target after successful installation

To schedule installation of MSI or MSP packages using a PowerShell cmdlet, see Create-IMMSITask.

To schedule installation of a Task Scheduler file


You should be familiar with using Task Scheduler; see the Microsoft documentation for information. Use the Task Scheduler MMC to create the Task Scheduler file. Installation Manager passes the Task Scheduler file directly to Windows Task Scheduler; it is not transferred using the file share. From the Installation Manager console, click Distribute Windows Task Scheduler file in the Actions pane. In the distribute Windows Task Scheduler File dialog box:

907

Using the Installation Manager Console


q

Enter the name of the task. The task name must start with an alphabetic character. The name must be unique, unless you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select this option, the task is updated with the new definition. Enter the location of the Task Scheduler file in Task XML file. In the Target list, specify the target servers where you want to install this task. Click Servers to select from Active Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name. If Installation Manager fails to schedule a task on a server (for example, when a server is offline), it tries to reschedule the task. To specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error occurs.)

To schedule installation of Task Scheduler Files using a PowerShell cmdlet, see Create-IMTask.

To schedule installation of a command-line task


From the Installation Manager console, click Schedule command-line task in the Actions pane. In the Schedule command-line task dialog box:
q

Enter the name of the task. The task name must start with an alphabetic character. The name must be unique, unless you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select this option, the task is updated with the new definition. In the Target list, specify the target servers where you want to install this task. Click Servers to select from Active Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name. Enter the command, or the location of the command, you want to execute on the target servers. If you enter a path, the command must be available to execute on the target servers at the specified path, or it must be available in the profile PATH. To make a command available from a single shared folder accessible by all target servers, click Advanced and specify a Shared Folder in the Advanced Options dialog box. Enter the date and time to start the installation in Schedule date and time, or select Now to launch the task immediately. If Installation Manager fails to schedule a task on a server (for example, when a server is offline), it tries to reschedule the task. To specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error occurs.)

To schedule installation of a command-line task using a PowerShell cmdlet, see Create-IMCMDTask.

908

Using the Installation Manager Console

To associate published applications with servers


After you use Installation Manager to install an application on a XenApp server, use this procedure to add the XenApp server to a preexisting published application object. This results in XenApp including that server when it load balances session requests to that application. 1. From the Installation Manager console, select a task in the Task pane and then click Publish Application in the Actions pane. 2. Click Browse and then enter the name of the XenApp server where Installation Manager will retrieve the list of published applications. 3. Click Go and select the published application from the list.

To reschedule a task
Rescheduling creates a copy of the task, so you can change its parameters. You can reschedule command-line tasks and MSI/MSP package deployments. 1. From the Installation Manager console, select a task in the Task pane and then click Reschedule in the Actions pane. 2. In the Reschedule CMD Task or Reschedule MSI Task dialog box, change field values as needed.

To remove a scheduled task


Removing a Task Scheduler entry does not remove the task from the list in the MMC. If you remove a task that has already executed, this action removes only its Task Scheduler entry; it does not undo the installation or deployment of files. From the Installation Manager console, select a task in the Task pane and then click Remove in the Actions pane. To remove scheduled tasks using a PowerShell cmdlet, see Remove-IMTask.

909

Using Installation Manager PowerShell Cmdlets

Cmdlet Summary
This reference assumes you are familiar with using PowerShell. The Installation Manager cmdlets support the standard PowerShell common parameters, such as WhatIf. To import the Installation Manager PowerShell cmdlets, either:
q

Type Add PSSnapIn IMAdmin at the PowerShell command prompt, or Import the cmdlets automatically by adding asnp IMAdmin to the PowerShell profile profile.ps1

This topic provides brief options descriptions. For complete cmdlet syntax, type Get-Help cmdlet-name at the PowerShell prompt.

Get-IMServer
Lists the servers in a specific XenApp farm. You can specify the following options:

Option -farm

Description IP address or DNS name of the MFCOM farm object. If this option is omitted, the local server is used.

-folder Path to the server folder in the farm, in the format \folder1\folder2. For example, the following cmdlet lists servers in the XenApp farm with a DNS name of XenAppFarmIN. Get-IMServer -farm XenAppFarmIN -folder Servers\TargetFolder

Create-IMMSITask
Schedules installation of an MSI or MSP package on target servers. You can specify the following options:

910

Using Installation Manager PowerShell Cmdlets Option -name -msi Description (Required) Unique task name. (Required) Path to the installation package. The file must be accessible by the task management computer. The cmdlet checks if this file exists; if it does not exist, an error is displayed. (Required) Target servers where the package will be installed. Specify one of the following:
q

-targets

A comma-delimited list of individual servers by DNS name An object containing Name attributes (as returned by the Get-IMServer cmdlet)

-mst

List of paths to MSI transform files. The files must be accessible by the task management computer. The cmdlet checks if this file exists; if it does not exist, an error is displayed. Date and time the installation task will run. Specify one of the following:
q

-schedule

A date in the format DD/MM/YYYY and the time in 24-hour format HH:MM:SS, enclosed in single or double quotes now to launch the task immediately

-logoffSessions

Forces users to log off the server before launching the installation. (You can use the -message option to prompt users to save their work and log off.) Prevents users from logging on during the installation. Restarts the server after installation. (You can use the -timeout option to specify how long to wait after installation completes to restart the server, and the -message option to specify a message to be sent to connected sessions before the restart.) Sends a message to all connected sessions before a logoff or restart. This option is valid with the -logoffSessions and -reboot options. Specifies the number of minutes that connected sessions have until a server restart. Overwrites any existing task with the same task name. If this option is omitted and another task with the same name exists, the task fails. Specifies a shared folder, in UNC format, that Installation Manager uses to transfer files to target servers. Installation Manager automatically copies the specified MSI, MSP, and transform (MST) files to this folder and assigns read permission from the target servers to the file share. You must have sufficient rights to set UNC permissions. The folder must be accessible by all specified target servers. Path to a file or XML object where the success or failure status of the installation on each target server is logged. If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager will retry the installation task. If you specify a retry time, you must also specify a retry interval.

-disablelogon -reboot

-message -timeout -update -prepareUnc

-log -retrytime

911

Using Installation Manager PowerShell Cmdlets If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager will retry the installation task. If you specify a retry interval, you must also specify a retry time. For example, the following cmdlet distributes an MSI package (located at c:localfolder\myapp.msi), using a transform (located at c:\localfolder\myapp_silent.mst), and a shared folder (\\fileserver\im), on the target servers XAWRK1, XAWRK2, and XAWRK3. The task will launch the first day of October 2010 at 11:50 p.m. Users will be alerted with a message before the installation begins. Users will not be able to log on during the installation, and the server will be restarted ten minutes after the installation completes. If a target server is busy, Installation Manager will retry every 10 seconds for a total of 60 seconds. Create-IMMSITask -name Installmyapp -targets XAWRK1,XAWRK2,XAWRK3 -msi c:\localfolder\myapp.msi -mst c:\localfolder\myapp_silent.mst -schedule '01/10/2010 23:50:00' -prepareUNC \\fileserver\im -retrytime 60 -retryinterval 10 -message "Please save your work and logoff. Server will reboot for maintenance." -timeout 10 -logoffsessions -reboot -retryinterval

Create-IMTask
Schedules installation of a Task Scheduler file. You should be familiar with using Task Scheduler. Use the Task Scheduler MMC to create the Task Scheduler file. Installation Manager passes the Task Scheduler file directly to Windows Task Scheduler; it is not transferred using the file share. You can specify the following options:

Option -name -task -targets

Description (Required) Unique task name. (Required) Path to the XML file or PowerShell XML object to install. The XML schema must follow Task Scheduler 2.0 specifications. (Required) Target servers where the file will be installed. Specify one of the following:
q

A comma-delimited list of individual servers by DNS name An object containing Name attributes (as returned by the Get-IMServer cmdlet)

-update -retrytime

Overwrites any existing task with the same task name. If this option is omitted and another task with the same name exists, the task fails. If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager will retry the installation task. If you specify a retry time, you must also specify a retry interval.

912

Using Installation Manager PowerShell Cmdlets -retryinterval If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager will retry the installation task. If you specify a retry interval, you must also specify a retry time.

Path to a file or XML object where the success or failure status of the installation on each target server is logged. For example, the following cmdlet distributes a Windows Task Scheduler file (located at C:\task.xml) that runs a backup script (named Backuptask) on the target servers (XAWRK1, XAWRK2, and XAWRK3). If a target server is busy, Installation Manager will retry every 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition will be overwritten. Success/failure status of the installations will be logged to C:\log.xml. Create-IMTask -name Backuptask -targets XAWRK1,XAWRK2,XAWRK3 -task c:\task.xml -update -retrytime 60 -retryinterval 10 -log c:\log.xml

-log

Create-IMCMDTask
Schedules installation of a command-line task. You can specify the following options: Option -name -command -targets Description (Required) Unique task name. (Required) Command-line operation to run on the target servers. (Required) Target servers where the package will be installed. Specify one of the following:
q

A comma-delimited list of individual servers by DNS name An object containing Name attributes (as returned by the Get-IMServer cmdlet)

-schedule

Date and time the installation task will run. Specify one of the following:
q

A date in the format DD/MM/YYYY and the time in 24-hour format HH:MM:SS, enclosed in single or double quotes now to launch the task immediately

-update -prepareUnc

Overwrites any existing task with the same task name. If this option is omitted and another task with the same name exists, the task fails. Specifies a shared folder, in UNC format, that Installation Manager can use to transfer files to target servers. Installation Manager automatically transfers files to this folder and updates the folders' ACL to ensure all servers have read access to it. You must have sufficient rights to set UNC permissions. If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager will retry the installation task. If you specify a retry time, you must also specify a retry interval.

-retrytime

913

Using Installation Manager PowerShell Cmdlets -retryinterval If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager will retry the installation task. If you specify a retry interval, you must also specify a retry time.

Path to a file or XML object where the success or failure status of the installation on each target server is logged. For example, the following cmdlet schedules installation of a task (named Installnotepad) using the command-line notepad.exe, on target servers XAWRK1, XAWRK2, and XAWRK3. If a target server is busy, Installation Manager will retry every 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition will be overwritten. Success/failure status of the installations will be logged to C:\log.xml. Create-IMCMDTask -name Installnotepad -command notepad.exe -targets XAWRK1,XAWRK2,XAWRK3 -update -retrytime 60 -retryinterval 10 -log C:\log.xml

-log

Get-IMTask
Obtains success or failure status about scheduled task installations. You can specify the following options.

Option -targets

Description (Required) Target servers for which you want task installation information. Specify one of the following:
q

A comma-delimited list of individual servers by DNS name An object containing Name attributes (as returned by the Get-IMServer cmdlet)

-name -fromdate -todate -log

Task name. Starting date of the interval for which you want status. End date of the interval for which you want status.

XML path of the log file. If this option is omitted, the status is displayed in the PowerShell console. For example, the following cmdlet displays status in the PowerShell console about the installation of the task named Installnotepad on target servers XAWRK1 and XAWWRK2. Get-IMTask -targets XAWRK1,XAWRK2 -name Installnotepad

Remove-IMTask
Removes a task scheduled on target servers. You can specify the following options: Option Description

914

Using Installation Manager PowerShell Cmdlets -targets (Required) Target servers on which you want to remove a scheduled task. Specify one of the following:
q

A comma-delimited list of individual servers by DNS name An object containing Name attributes (as returned by the Get-IMServer cmdlet)

-name -retrytime

(Required) Task name. If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager will retry the task removal. If you specify a retry time, you must also specify a retry interval. If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager will retry the task removal. If you specify a retry interval, you must also specify a retry time.

-retryinterval

Path to a file or XML object where the success or failure status of the task removal on each target server is logged. For example, the following cmdlet removes the task named Installnotepad from target servers XAWRK1 and XAWRK2. If a target server is busy, Installation Manager will retry every 10 seconds for a total of 60 seconds. Success/failure status of the task removal will be displayed in the PowerShell console. Remove-IMTask -targets XAWRK1,XAWRK2 -name Installnotepad -retrytime 60 -retryinterval 10

-log

915

Installation Manager Messages Reference


Installation Manager may report messages as described in the following tables. The numbers in these tables are organized by the absolute value of the initial digit, then by remaining digits. Generally, a positive value indicates a successful condition or provides general information. A negative value usually indicates an error condition.

Administration Messages
Number 0 1 -1 -100 -101 103 String SUCCESS SCHEDULED FAILURE A connection to the server could not be established. Invalid farm argument. Specify a valid server address. This Citrix XenApp PowerShell snap-in contains cmdlets used to perform remote management operations in your XenApp environments. Invalid arguments. Specify either "match" or "like" arguments, not both. XenApp SDK is not installed or Check DCOM Settings The folder specified {0} does not exist. Specify a valid folder name in the format Servers/folder1/folder2. Access denied while enumerating Servers/Folders in farm. EXECUTING Trigger or Condition The task ran successfully. The task is scheduled in the Task Scheduler. The task failed to register or execute. The server may not be physically connected. The specified farm name may either be syntactically wrong or may not exist.

-104

Specify either Match or Like for filtering servers. DCOM settings in the client computer are either missing or incorrect.

-105 -106

-107

The administrator is not a Citrix Administrator. The task is running.

916

Installation Manager Messages Reference -205 -207 Server is unreachable. Check network connections. You do not have permission to access the target server. You must be a local Administrator on that server. Invalid Task XML format. Document contains invalid tags. Unable to write Log file {0}. check that the path exists and that you have write permissions to it. Unable to read Task file {0} check that the file exists and that you have read permissions to it. Specify the interval time in seconds for the Retry parameter. This task name already exists on the target server. Enter a unique task name. Network path {0} is unreachable. Check network connections. Invalid Task XML format. Cannot find "action" tag. You do not have permission to schedule a task. You must be a local Administrator on the target server. Invalid Task XML format. The "command" tag contains invalid data. Invalid Task XML format. The "command" tag is not well-formed. The filename, directory name, or volume label syntax is incorrect for path {0} Invalid Task XML format. Task successfully registered. Invalid task name. The task cannot register itself with the Task Scheduler. The application cannot register a task because the logon credentials are not valid. The task XML document does not comply with the Task Scheduler 2.0 standard schema. The application cannot create the log file because it does not have write permission for the specified path. The task file is not at the specified location or cannot be accessed due to incorrect permissions. A negative value was specified for the retry interval time. The specified task name already exists.

-211

-212

-214

-216

-219

-220

The servers are physically disconnected.

-221 -222

The task XML file does not contain the mandatory <actions> tag. Insufficient permissions exist to access the target task scheduler.

-223

The task XML file does not contain the mandatory <command> tag. The task XML <command> tag formation is not valid. The specified task name is in an invalid format. The Task Scheduler cannot recognize the XML format. The task registered successfully in the Task Scheduler. The specified task name does not start with an alphabetical character.

-224

-226

-229 230 -233

917

Installation Manager Messages Reference -234 239 -241 Invalid target argument. Specify a valid server address. Task successfully updated. Missing retrytime argument. It is mandatory if retryinterval is provided. Missing retryinterval argument. It is mandatory if retrytime is provided. SCHEDULE_PENDING Use the following date and 24-hour time format: DD/MM/YYYY HH:MM:SS. Unable to prepare UNC path {0}. Check your credentials. Invalid command argument. Specify a valid command-line operation. Failed to assign read permissions of computer {0} to the path {1}. Ensure the path and computer name are correct, and that you have sufficient access rights to the path. CANCELLED Specify a reboot timeout period in minutes for the Reboot-Timeout parameter. Unable to read MSI file {0}. Check that the file exists and that you have read permissions to it. Unable to read MST file {0}. Check that the file exists and that you have read permissions to it. CANCEL_PENDING Task successfully removed. REMOVED The specified server IP address is not valid. The existing task in the Task Scheduler updated successfully. A retry interval value was specified without a retry time value. A retry time value was specified without a retry interval value. The task is not yet registered in the Task Scheduler. The time and date specified for the schedule option are not in the required format. Access was denied to the PrepareUNC path due to insufficient permission. A cmdlet option was incorrectly specified.

-242

3 -300

-301 -302

-303

4 -400

The running task was stopped. The timeout value specified is not an integer. Access was denied to the MSI file due to insufficient permission.

-404

-405

Access was denied to the transform (MST) file due to insufficient permission.

5 501 6

The task running is being stopped. The task was successfully removed from the Task Scheduler. The task was removed from the Task Scheduler.

918

Installation Manager Messages Reference -600 Unable to connect to Event Log of the target server. You must be a member of "Event Log Readers" group in the target server. Task not found. Task was scheduled. Task is running... Scheduling... Task was cancelled. Canceling task... Task failed. Task Failed. Verify if IM Utilities is installed at target server. COM error while scheduling task in target system : {0} Generic error while scheduling task in target system :{0} COM error while retrieving task information from target system :{0} COM error while removing task form target system :{0} Generic error while removing task from target system :{0} MFCOM is not registered on the system. Use the MFREG tool to register the server.

-601 605 606 607 608 609 -610 -611 -801

The task is not found in the target server's Task Scheduler. The task is scheduled to run on the target server. The task is running on the target server. The task is not yet registered. The running task has been stopped. The task running is being stopped. The task failed to execute. The Utilities package is not installed on the target server. A COM exception occurred while schedule a task in the Task Scheduler on the target server. An exception occurred while scheduling a task in the Task Scheduler on the target server. A COM exception occurred while retrieving task information from the Task Schedule on the target server. A COM exception occurred while removing a task form the Task Scheduler on the target server. An exception occurred while removing a task from the Task Scheduler on the target server.

-802

-803

-804

-805

-901

Utilities Messages
The following messages may be generated if you installed the Utilities package on the target servers, which is required if you are scheduling MSI or MSP packages for installation on the target servers.

Number -105

String XenApp SDK is not installed or Check DCOM Settings

Trigger or Condition DCOM settings in the client computer are either missing or incorrect.

919

Installation Manager Messages Reference -226 The filename, directory name, or volume label syntax is incorrect for path {0} Installation failed: {0} Unable to read Installation files using system credentials. Ensure "Everyone" has read permission to the share and "Advanced:Shared Folder" parameter contains the UNC path where the file is located. Unable to connect to the XenApp farm. Specify only XenApp servers when using publish-app or disable-logon parameters. Unable to add server to published application. The installation was successful, use Delivery Services Console to add the server to the published application object. Published Application name is already existed. Terminal Server role is not enabled. Reboot and logoff parameters are only available for Terminal Server targets. Unable to send message to connected sessions. Operation was canceled. Unable to reboot server. The installation was successful otherwise, reboot the server manually to complete the operation. This Citrix XenApp PowerShell snap-in contains cmdlets used to perform installations on XenApp servers. Incorrect number of parameters to MSIScriptlet.ps1 Missing MSI file path argument. Success. Missing task name argument. Success. System will reboot.

-700 -701

MSIEXEC failed to run. Unable to access MSI log file.

-702

XenApp farm initialization failed.

-703

The server may not exist.

705 -709

Target server does not have Terminal Services enabled.

-710

Error sending Terminal Services messages. Error restarting Terminal Services target.

-711

712

-715 -716 718 -720 723

Not all parameters were passed to scriplet file. The MSI file option is required. The MSI installed successfully. The task name option is required. The task ran successfully and the server will restart to complete the installation.

920

Installation Manager Messages Reference -724 Unable to write event to Windows Event Log. An error occurred when writing to Event Logger.

921

Managing Providers and WMI


Diagram showing the main components of a WMI installation

WMI Provider. Acts as an intermediary between the CIM (Common Information Model) Object Manager and the system being managed. The purpose of a WMI provider is to extract management information from the underlying system and present this to a WMI consumer. The CIM Object Manager (CIMOM). Acts as a broker between the WMI providers and consumers. When a WMI consumer requests information, CIMOM identifies the WMI provider that can supply the information, obtains the information, and passes it to the consumer. CIMOM has its own repository in which it stores the data supplied to consumers. The Managed Object Format (MOF) files are also stored in the CIMOM repository. A MOF file defines the schema, which is the data that a WMI provider can supply and the methods it can execute in response to WMI requests. WMI Consumer. A management tool such as Microsoft Operations Manager (MOM), an MMC snap-in such as the Citrix AppCenter or a third party application.

Depending on which version of XenApp you have installed, Citrix XenApp Management Pack for MOM 2005, or Citrix XenApp Management Pack for Systems Center Operations Manager 2007 and Citrix XenApp Management Pack for Systems Center Operations Manager 2007 SP1 are included with your product.

922

XenApp Provider Overview


The Citrix XenApp Provider for Microsoft Windows Management Instrumentation (also referred to as the XenApp Provider or the Provider) extracts information about the server on which it is installed and, where appropriate, about the server farm in which this server operates. It presents this information to a WMI consumer, such as MOM, for display. For example, information about sessions on the server and published applications in the server farm is provided. You can use this information to monitor the health and availability of the server and server farm. The Provider runs on the server as a Windows service.

923

Licensing Provider Overview


Citrix Licensing is handled by one or more license servers. The Licensing Provider is available on each Windows-based license server. It is installed by default with the license server. This WMI provider extracts information about licensing from the license server on which it runs and presents this data to a WMI consumer, such as MOM, for display. For example, the Licensing Provider supplies information about the number of licenses in use and licenses that are about to expire. The XenApp Provider no longer supplies licensing information for computers running MetaFrame Presentation Server 3.0 or later. However, the Lincensing Provider still supplies licensing information for servers running earlier versions of XenApp. This means that you can monitor multiple farms, running different versions of XenApp. For backwards compatibility, the licensing classes are still in the schema for the XenApp Provider. Note: For information about the data the Licensing Provider can supply, see the Citrix .mof files. The files are in the \LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).

924

Installing the XenApp Provider


Install the XenApp Provider on every XenApp computer for which you want to gather information. You install the Provider during the installation of XenApp. When you install the Provider, the files are installed in the \WMI folder in the same directory in which XenApp is installed. Typically, this is: C:\Program Files\Citrix\System32\Citrix\WMI. The following files are included in this folder:
q

The executable file for CitrixWMIService (ctxwmisvc.exe) Provider DLLs Various .fom files Managed Object Format files (.mof files)

The Provider runs as a Windows service called Citrix WMI Service.

925

Installing the Licensing Provider


The Licensing Provider is installed by default when you install the Citrix License Server for Windows. The Licensing Provider runs as a Windows service called CitrixLicensingProviderService.

926

Starting the Provider Services


After you install the XenApp Provider and if an appropriate license is present on the server, the Provider service is ready to start. There is no need to start and stop the service manually because WMI does this as required. After the Licensing Provider is installed, the Licensing Provider service is ready to start. To gather and display information, use a suitable WMI consumer, such as the Citrix XenApp Management Pack for Microsoft Operations Manager.

927

Security Considerations
To display information about XenApp computers and server farms using a WMI consumer, access to the Root\Citrix namespace in the WMI configuration is required. The appropriate Citrix administration rights to display information about servers and server farms is also required. If you delegate areas of XenApp administration and server farm management to Citrix administrators, these administrators can monitor and control only the specific administration tasks for which they have permissions. For example, if a Citrix administrator can manage only published applications, only information about published applications is available to them from the XenApp Provider.

928

Uninstalling the Providers


Uninstall the XenApp Provider using the XenApp uninstaller. The Licensing Provider is part of Citrix Licensing. To uninstall the Licensing Provider, uninstall the Citrix License Server.

929

WMI Schema
This section contains diagrams of the WMI schemas for the XenApp Provider and Licensing Provider. The schema is the data that a WMI provider can supply and the methods it can execute in response to WMI requests. The following schema are shown:
q

XenApp Provider Licensing Provider

Note: These diagrams represent typical WMI schemas, rather than providing a comprehensive list of all the data returned by the Providers. For more information about the data the XenApp Provider can supply, see the Citrix .mof files in the \WMI folder (for example: C:\Program Files\Citrix\System32\Citrix\WMI). For more information about the data the Licensing Provider can supply, see the Citrix .mof file in the \LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).

930

XenApp Provider WMI Schema (Part 1 of 3)

931

XenApp Provider WMI Schema (Part 2 of 3)

932

XenApp Provider WMI Schema (Part 3 of 3)

933

Citrix Licensing Provider WMI Schema

934

Optimize WAN Access with Branch Repeater


Branch Repeater (WANscaler) product documentation is not yet in Citrix eDocs (this site) and still resides in the Citrix Knowledge Center. We are in the process of transitioning product documentation to Citrix eDocs. For links to documentation in the Citrix Knowledge Center, go to: http://support.citrix.com/productdocs/ Important: When you click this link you leave eDocs. We recommend you bookmark eDocs so you can easily return to it.

935

Manage and Dynamically Provision Servers with Provisioning Services


The most recent Provisioning Services product documentation is located at Provisioning Services. Previous versions are located in the Citrix Knowledge Center. For links to documentation in the Citrix Knowledge Center, go to: http://support.citrix.com/productdocs/ Important: When you click this link you leave eDocs. We recommend you bookmark eDocs so you can easily return to it.

936

Secure Access to Your Enterprise Network with Secure Gateway


The Secure Gateway for Windows helps you to secure access to enterprise network computers running Citrix XenApp and provides a secure Internet gateway between Citrix XenApp and user devices. The Secure Gateway transparently encrypts and authenticates all user connections to help protect against data tampering and theft. All data traversing the Internet between a remote workstation and the Secure Gateway is encrypted using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol. The Secure Gateway is an application that runs as a service on a server that is deployed in the demilitarized zone (DMZ). The server running the Secure Gateway represents a single point of access to the secure, enterprise network. The Secure Gateway acts as an intermediary for every connection request originating from the Internet to the enterprise network. For increased security, the Secure Gateway Proxy is used with the Secure Gateway in a double-hop DMZ deployment. The Secure Gateway is installed in the first DMZ and the Secure Gateway Proxy is installed in the second DMZ. The Secure Gateway Proxy acts as a conduit for traffic originating from the Secure Gateway to servers in the secure network, and from servers in the secure network to the Secure Gateway. The following table highlights references to typical administrative tasks and conceptual information:

Task Using the Secure Gateway with computers running XenApp Installing and configuring the Secure Gateway Learning more about the Secure Gateways performance counters and error logs Getting general recommendations about using network components such as load balancers, SSL accelerator cards, and firewalls Learning more about troubleshooting a Secure Gateway deployment Learning about digital certificates and certificate installation

See This Topic Planning a Secure Gateway Deployment Installing and Configuring the Secure Gateway and Secure Gateway Proxy Managing the Secure Gateway

Secure Gateway Optimization and Security Guidelines

Troubleshooting the Secure Gateway

Digital Certificates and the Secure Gateway

937

Citrix XenApp Components That Work with Secure Gateway


Your enterprise network can contain one or more servers running Citrix XenApp. A server farm is used for hosting published resources that users can access over the network. The Secure Gateway works with the following components of Citrix XenApp for logon and authentication: Citrix Web Interface Provides user access to published resources in a server farm from a Web browser. The Web Interface works with the Secure Gateway to provide a logon interface, and facilitates authentication and authorization of connection requests to the server farm. Secure Ticket Authority (STA) The STA is responsible for issuing session tickets in response to connection requests for published resources on Citrix XenApp. These session tickets form the basis of authentication and authorization for access to published resources. During installation of Citrix XenApp, the STA is installed automatically. It is no longer necessary to reserve a separate server for the STA. Citrix XML Service When the Secure Gateway provides secure access to published resources available in a server farm, the Citrix XML Service is contacted for published resources availability and location. The Citrix XML Service is the point of contact for a server farm and provides an HTTP interface to the user device. It uses the TCP protocol instead of UDP, which allows connections to work across most firewalls. The default port for the Citrix XML Service is 80. Ensure that this port is configured, functioning correctly, and is accessible through the firewall in front of the secure network. Citrix Receiver Web You can use Citrix Receiver web to access resources available from the Web Interface and for access to resources published with traditional Application Launching and Embedding (ALE). Important: The Secure Gateway and Secure Gateway Proxy are not supported in environments using Advanced Access Control.

938

Citrix XenApp Components That Work with Secure Gateway


Your enterprise network can contain one or more servers running Citrix XenApp. A server farm is used for hosting published resources that users can access over the network. The Secure Gateway works with the following components of Citrix XenApp for logon and authentication: Citrix Web Interface Provides user access to published resources in a server farm from a Web browser. The Web Interface works with the Secure Gateway to provide a logon interface, and facilitates authentication and authorization of connection requests to the server farm. Secure Ticket Authority (STA) The STA is responsible for issuing session tickets in response to connection requests for published resources on Citrix XenApp. These session tickets form the basis of authentication and authorization for access to published resources. During installation of Citrix XenApp, the STA is installed automatically. It is no longer necessary to reserve a separate server for the STA. Citrix XML Service When the Secure Gateway provides secure access to published resources available in a server farm, the Citrix XML Service is contacted for published resources availability and location. The Citrix XML Service is the point of contact for a server farm and provides an HTTP interface to the user device. It uses the TCP protocol instead of UDP, which allows connections to work across most firewalls. The default port for the Citrix XML Service is 80. Ensure that this port is configured, functioning correctly, and is accessible through the firewall in front of the secure network. Citrix Receiver Web You can use Citrix Receiver web to access resources available from the Web Interface and for access to resources published with traditional Application Launching and Embedding (ALE). Important: The Secure Gateway and Secure Gateway Proxy are not supported in environments using Advanced Access Control.

939

Secure Gateway Features


Designed-in security The Secure Gateway provides authentication, authorization, and cryptography functionality that is consistent with Microsofts best practices for secure software. Network protocol support The Secure Gateway supports the TCP/IP protocols, such as FTP, HTTP, and Telnet. IPv4 and IPv6 protocol support The Secure Gateway can be configured to accept inbound connections from clients using IPv4 and IPv6 addresses. Secure Socket Layer support The Secure Gateway provides SSL support to secure communication between the client and the Secure Gateway components. Simple deployment Citrix XenApp includes the Secure Ticket Authority (STA) and is merged into a single Windows Installer package resulting in a more efficient deployment. The STA is deployed automatically on the same computer as Citrix XenApp, resulting in a reduction of the number of computers required for basic deployment Internet Information Server is no longer a requirement for installing the STA Internet Information Server deployment is a supported option during installation of Citrix XenApp. Certificate management The Secure Gateway Configuration wizard prevents the selection of a certificate that does not have a private key and verifies that the appropriate certificate is installed in the local computer certificate store. Wildcard certificate support. Wildcard certificates can be deployed on the Secure Gateway, the Secure Gateway Proxy, and on the computer where Citrix XenApp is hosting the STA. Load balancing The Secure Gateway provides load balancing for the Secure Gateway Proxy. IP addresses are retrieved from the DNS using a domain name or listed individually. Logging The Secure Gateway uses the Apache standard access log files and supports log rotation functionality for the access log files. The access log files provide connection information to the Secure Gateway or the Secure Gateway Proxy. Instrumentation

940

Secure Gateway Features The Secure Gateway includes a new set of performance counters to analyze the usage and load on the Secure Gateway server. Based on Apache Technology The software code based on Apache technology is used as a foundation for building the Secure Gateway. Section 508 compliance Secure Gateway is compliant with Section 508 of the United States Workforce Rehabilitation Act of 1973. Session reliability Improvements in session reliability benefit both mobile and local users by having their work items remain open when network connectivity is lost, and then seamlessly resumed when connectivity is restored. This feature is especially useful for mobile users with wireless connections that are interrupted or dropped. When a session connection is interrupted, all open windows to published resources remain visible while reconnection is attempted automatically in the background. Relay mode Secure Gateway can be installed in relay mode for internal secure communications. Relay mode can be used in secure corporate environments such as intranets, LANs, and WANs. Relay mode is not recommended for external connections from the Internet to a server farm or server access farm. Supports single-hop or double-hop DMZ deployment The Secure Gateway can be installed to span a single-hop or a double-hop DMZ. If your DMZ is divided into two stages, install the appropriate Secure Gateway component in each DMZ segment to securely transport HTTP/S and ICA traffic to and from the secure network. Supports secure communication between the Secure Gateway components The Secure Gateway components support the use of digital certificates and the task of securing links by using SSL/TLS between components. Configuration, management, and diagnostic tools The Secure Gateway Management Console is a Microsoft Management Console (MMC) snap-in you can use to manage, analyze, and troubleshoot a Secure Gateway deployment. The Secure Gateway Diagnostics tool, available from the Secure Gateway Management Console, reports configuration values, certificate details, and the state of each configured component. Minimal client configuration User devices require no preinstalled software for security. Remote, secure access is easy to support, requiring little effort from IT staff. Certificatebased security

941

Secure Gateway Features The Secure Gateway uses standard Public Key Infrastructure (PKI) technology to provide the framework and trust infrastructure for authentication and authorization. Standard encryption protocols The Secure Gateway uses industry-standard SSL or TLS encryption technology to secure Web and application traffic between the client and server. Connections between clients and the Secure Gateway are encrypted using SSL or TLS protocols. You can further enhance security by forcing the Secure Gateway to restrict its use of ciphersuites to commercial or government ciphersuites certified for Federal Information Processing Standard (FIPS) 140 requirements. Authentication and authorization The Secure Gateway works with the Web Interface to facilitate authentication of users attempting to establish connections to a server farm. Authorization occurs when the Secure Gateway confirms that the user is authenticated by the enterprise network. The authorization process is entirely transparent to the user. Single point of entry The need to publish the address of every Citrix XenApp server is eliminated and server certificate management is simplified. The Secure Gateway allows a single point of encryption and access to computers running Citrix XenApp. Firewall traversal Connections from clients are secured with standard protocols using ports typically open on corporate firewalls. This allows easy traversal of firewalls without custom configuration. Ease of installation and management Adding the Secure Gateway to an existing server farm is relatively quick and simple, and requires minimal configuration, significantly reducing time and management costs. Reliability and fault tolerance The solution allows implementation of duplicate components to enable a redundant system. Large arrays can be built using industry-standard SSL load balancing systems for scalability. Even if hardware fails, the server farm remains protected. Scalable and extensible solution A single server running the Secure Gateway can support a small corporate site consisting of hundreds of users. You can support medium to large sites catering to thousands of users connecting to an array of load balanced servers running the Secure Gateway. The Secure Gateway components do not require special hardware devices or network equipment upgrades. Event and audit logging Critical and fatal system events are logged to the Secure Gateway application log, enabling administrators to help diagnose system problems. Logging levels are configurable and can be set from the user interface. Depending on the configured logging level, you can retrieve a complete record of network connection attempts to the Secure 942

Secure Gateway Features Gateway. You can also configure the Secure Gateway to omit log entries for polls from network equipment such as load balancers.

943

System Requirements for Secure Gateway


The Secure Gateway and Secure Gateway Proxy are not supported in environments using Advanced Access Control.

Operating Systems
You can install the Secure Gateway components on computers running:
q

Windows Server 2008 R2 Service Pack 1 Windows Server 2008 R2 Windows Server 2008 Service Pack 2 (32- and 64-bit) Windows Server 2003 Service Pack 2 (32- and 64-bit)

Important: Secure Gateway runs as a 32-bit application on 64-bit Windows operating systems.

Hardware Requirements
The Secure Gateway requires the minimum hardware requirements for supported Windows operating systems, as specified by Microsoft. Important: For maximum security, Citrix recommends you reserve a standalone server for the Secure Gateway.

Citrix Products Compatibility with Secure Gateway


The Secure Gateway is compatible with the following Citrix products:
q

Citrix XenApp 6.5 for Windows Server 2008 R2 Citrix XenApp 6 for Windows Server 2008 R2 Citrix XenApp 5 for Windows Server 2008 Citrix XenApp 5 for Windows Server 2003 Web Interface

944

System Requirements for Secure Gateway You can use Secure Gateway installed on a computer running a different Windows operating system than XenApp servers in the same environment. The Secure Gateway is compatible with the following Citrix Receiver for Windows and Citrix online plug-in software:
q

Citrix Receiver for Windows 13.0, which includes Citrix Receiver Admin and Citrix Receiver Web. Citrix Receiver for Windows 13.0 is the successor to the Online Plug-in for Windows 12.1. Citrix Online Plug-in for Windows 12.1, including Citrix online plug-in web. Citrix Online Plug-in for Windows 11.2, including Citrix online plug-in web.

Important: Secure Gateway and Secure Gateway Proxy do not support the Citrix Offline Plug-in.

User Devices
The following Microsoft operating systems are supported for user devices:
q

Windows XP Home Edition Windows XP Professional Windows XP Service Pack 3 Windows Vista Windows Vista Service Pack 2 Windows 7 Windows 7 Service Pack 1 Windows Server 2003 Windows Server 2008 Windows Server 2008 R2 Windows Server 2008 R2 Service Pack 1

945

Certificate Requirements
All user devices and secure servers in a Secure Gateway deployment use digital certificates to verify each others identity and authenticity. The Secure Gateway supports the use of digital certificates. As the security administrator, you need to decide whether or not the communication links between the Secure Gateway and other servers in the DMZ or secure network need to be encrypted. See Digital Certificates and the Secure Gateway. Important: If you purchased server certificates from a commercial certificate authority (CA), support for root certificates for most commercial CAs is built into Internet Explorer and Windows server products. If you obtained server certificates from a private CA or commercial CA whose root certificates are not, by default, supported by the Windows operating system, you must install matching root certificates on all user devices and servers connecting to secure servers.

Certificate Requirements for a Single-Hop DMZ


If your secure network contains Citrix XenApp with the Secure Gateway in the DMZ, servers and clients need the following certificates:

Root certificates on all user devices that connect to the server running the Secure Gateway. Root certificates on every Secure Gateway component that connects to a secure server. For example, a root certificate must be present on the server running the Secure Gateway to verify the server certificate installed on the server running the STA. A server certificate on the server running the Secure Gateway. Optional. A server certificate on the servers running the STA. The STA is installed by default when you install Citrix XenApp.

All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Certificate Requirements for a Double-Hop DMZ


If your secure network contains Citrix XenApp with the Secure Gateway in the first DMZ, and the Secure Gateway Proxy and the Web Interface in the second DMZ, servers and clients require the following certificates:

946

Certificate Requirements
q

Root certificates on all user devices connecting to the server running the Secure Gateway. Root certificates on every Secure Gateway server that connects to a secure server or Web server. For example, an appropriate root certificate must be present on the server running the Secure Gateway to verify the server certificate installed on the Citrix XenApp server. A server certificate on the server running the Secure Gateway. Optional. A server certificate on the server(s) running the Secure Gateway Proxy. Optional. A server certificate on the server running the STA.

947

Planning a Secure Gateway Deployment


The deployment of the Secure Gateway depends on several factors, including which Citrix components you have in your enterprise network. The Secure Gateway is designed to work with Citrix XenApp. If your enterprise network contains a server farm, you can deploy the Secure Gateway to provide secure Internet access to published resources. In such deployments, the Secure Gateway works with the Web Interface to provide authentication, authorization, and redirection to published resources hosted on a Citrix XenApp server. To ensure that the security of the Secure Gateway is not compromised, Citrix recommends reserving servers for the exclusive use of the Secure Gateway. Note: Citrix recommends setting up the Secure Gateway in a test environment before implementation to your production environment to make sure all of the features work correctly. Place the Secure Gateway in the DMZ between two firewalls for maximum protection. In addition, physically secure the DMZ to prevent access to the firewalls and servers within the DMZ. A breach of your DMZ servers may, at best, create an annoyance in the form of downtime while you recover from the security breach. Important: Citrix recommends that you configure your firewalls to restrict access to specific TCP ports only. If you configure your firewalls to allow access to TCP ports other than those used for HTTP, ICA, SSL, and XML data, you may allow users to gain access to unauthorized ports on the server.

948

Deploying the Secure Gateway in a Single-Hop DMZ


In a single-hop deployment, users can connect to the enterprise network in two ways. The first is where the Secure Gateway intercepts the client connection and routes it to the Web Interface. After logging on and authenticating user credentials, the Secure Gateway handles the connection. Alternatively, users can be directed to the Web Interface first, where they log on and then the connection is handled by the Secure Gateway. The first scenario is referred to as behind the Secure Gateway. The second scenario is referred to as parallel to the Secure Gateway.

Certificate Requirements for a Single-Hop DMZ Deployment


If the Secure Gateway is in the DMZ, servers and clients need the following certificates:
q

Root certificates on all user devices that connect to the server running the Secure Gateway. Root certificates on every Secure Gateway component that connects to a secure server. For example, a root certificate must be present on the server running the Secure Gateway to verify the server certificate installed on the server running the STA. A server certificate on the server running the Secure Gateway. Optional. A server certificate on the servers running the STA. The STA is installed by default when you install Citrix XenApp.

All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Deployment Scenario A: Secure Gateway in a Single-Hop DMZ


WXYCo Inc. is an audit firm that recently purchased licenses for Citrix XenApp. The companys employees are financial auditors who visit client sites and conduct financial audits. They use a proprietary, client-server auditing software application, AuditorX. They publish AuditorX on computers running Citrix XenApp. They also deploy the Web Interface for Web access to their published resources. Employees can access AuditorX and other published resources through a Web browser on a user device connected to the LAN. 949

Deploying the Secure Gateway in a Single-Hop DMZ WXYCo realizes installing the Secure Gateway allows them to provide secure Internet access to published resources on its server farms. Because the workforce is largely mobile, use of the Internet to connect to the enterprise network is expected to reduce remote access costs dramatically.

A secure server farm using a single-hop DMZ. This figure illustrates a secure enterprise network separated from the Internet by a single-hop DMZ. The enterprise network contains a server farm including one server running Citrix XenApp with the Secure Ticket Authority (STA). The firewall separating the secure network from the DMZ has ports 80, 443, and 1494 open. If session reliability is enabled, port 2598 is open on the internal firewall. The DMZ contains a single server running the Secure Gateway, and the Web Interface. Traffic to the Web Interface is proxied through the Secure Gateway which communicates with the Web Interface using HTTP. The DMZ is separated from the Internet by a firewall that has port 443 open. The mobile workforce carries notebook PCs running a 32-bit Windows operating system, Internet Explorer 5.5, and the Citrix online plug-in for 32-bit Windows. The security analyst recommends securing the communication link between the Secure Gateway and the STA. To do this, the company purchased two server certificates from a commercial certificate authority (CA). The server running the Secure Gateway and the Web Interface have root and server certificates installed. The server running Citrix XenApp has a server certificate installed. For more information about certificates, see Digital Certificates and the Secure Gateway.

950

Running the Web Interface behind the Secure Gateway in the Demilitarized Zone
In a single-hop DMZ deployment scenario, all incoming traffic is intercepted by the Secure Gateway. The Web Interface can be installed on the same server as Secure Gateway or on a separate server. All data exchanged between user devices and the Web Interface is relayed through the Secure Gateway. The firewall facing the Internet has port 443 open. Users connect to the Secure Gateway using a URL such as https://Secure Gateway FQDN/, where Secure Gateway FQDN is the fully qualified domain name for the server running the Secure Gateway.

Advantages Disadvantages

A single server certificate is required on the server running the Secure Gateway and the Web Interface. A single port, 443, must be opened on the firewall facing the Internet. The Web Interface cannot be contacted directly from the Internet and is more secure. Deploying the Secure Gateway in this configuration affects Web Interface functionality. When you deploy the Secure Gateway in this configuration, you lose some of the features available with the Web Interface, including the following: Smart Card Authentication. The Secure Gateway negotiates the SSL handshake and terminates the SSL connection before forwarding the client connection request to the Web Interface. Smart card authentication integrated with the Web Interface is unavailable because the Secure Gateway terminates the SSL connection before it reaches the Web Interface. Firewall and Proxy Settings Requiring Knowledge of the Client IP Address Are Ineffective. All communication from the user device to the Web Interface is proxied through the Secure Gateway. As a result, all client communications to the Web Interface originate from the IP address of the server running the Secure Gateway. Though you can still configure firewall and proxy settings on the Web Interface for specific client address prefixes, these settings must allow all client communications through the Secure Gateway to have the Web Interface IP address. You will not be able to distinguish between different user devices connecting through the Secure Gateway.

Citrix recommends deploying the Secure Gateway in this configuration if your network is small to medium sized, with a usage profile of hundreds of users. This type of deployment is optimal when users are connecting over the Internet to the Secure Gateway.

951

Running the Web Interface behind the Secure Gateway in the Demilitarized Zone If any of the limitations described above are a concern and you have a sizeable user base accessing the Secure Gateway over the LAN, consider deploying the Web Interface in the configuration described in Running the Web Interface Parallel with the Secure Gateway.

952

Locking Down Internet Information Services


All traffic to the server running the Web Interface is proxied through the server running the Secure Gateway. Lockdown Internet Information Services (IIS) to allow only the Secure Gateway to communicate with the Web Interface. For instructions about configuring IIS to explicitly grant or deny access to applications or Web sites, refer to the IIS documentation that ships with your version of Microsoft Windows Server.

953

Running the Web Interface Parallel with the Secure Gateway


In this configuration, the Secure Gateway and the Web Interface are installed on separate servers. Users can connect directly to the Web Interface. Users connect directly to the Web Interface, using a URL such as https://Web Interface FQDN/citrix/AccessPlatform or https://Web Interface FQDN/citrix/XenApp, where Web Interface FQDN is the fully qualified domain name for the server running the Web Interface. Citrix recommends securing both servers by installing a server certificate on each server running the Secure Gateway and the Web Interface. Open port 443 on the firewall facing the Internet. You want to use the features available with the Web Interface, including smart card authentication and firewall and proxy settings that depend on knowing the client IP address.

954

Setting Up the Web Interface and the Secure Gateway in a Single-Hop Demilitarized Zone
In this scenario, the Web Interface and the Secure Gateway are hosted on the same server in the DMZ. Install and configure the Web Interface before you install the Secure Gateway. 1. Install the Web Interface on the server reserved for the Secure Gateway and the Web Interface. 2. Add and configure server farms for use with the Web Interface. 3. Use a Web browser on a user device to connect and log on to the Web Interface. 4. Verify that you can launch published applications. 5. Configure the Secure Gateway and include the FQDN for the STA. The Secure Gateway is installed on the same server as the Web Interface in the DMZ. To install and configure the Secure Gateway, see Installing and Configuring the Secure Gateway and Secure Gateway Proxy. Ensure the user devices connecting to the Secure Gateway meet the compatibility requirements stated in System Requirements for Secure Gateway.

955

Deploying the Secure Gateway in a Double-Hop DMZ


Deploy the Secure Gateway in a double-hop DMZ configuration if your DMZ is divided into two segments. In this configuration, the server running the Secure Gateway is in the first DMZ segment. The firewall between the first DMZ segment and the Internet has port 443 open. The Web Interface and the Secure Gateway Proxy are installed on separate servers in the second DMZ segment. The server farm is located in the secure network. The firewall between the first and second DMZ segments has ports 80 and 443 open. The Secure Gateway, deployed in the first DMZ segment, is responsible for intercepting all incoming traffic. The Web Interface is responsible for user authentication and authorization. After authentication, the Secure Gateway Proxy is responsible for relaying all data exchanged between the Secure Gateway and servers in the secure network. The firewall between the second DMZ segment and the secure network has ports 80, 443, and 1494 open. Deploy the Secure Gateway in this configuration if your network contains a double-hop DMZ. A double-hop DMZ provides additional protection because an attacker would need to penetrate multiple security zones to reach servers in the secure network. If the resources accessible through the Secure Gateway are extremely sensitive and require a high level of security, consider this configuration.

Certificate Requirements for a Double-Hop DMZ Deployment


If the Secure Gateway is in the first DMZ, the Secure Gateway Proxy is in the second DMZ, and the Web Interface is in the second DMZ, servers and clients need the following certificates:

Root certificates on all user devices connecting to the server running the Secure Gateway. Root certificates on every Secure Gateway component that connects to a secure server or Web server. For example, an appropriate root certificate must be present on the server running the Secure Gateway to verify the server certificate installed on the server running Citrix XenApp. A server certificate on the server running the Secure Gateway. Optional. A server certificate on the server(s) running the Secure Gateway Proxy.

956

Deploying the Secure Gateway in a Double-Hop DMZ


q

Optional. A server certificate on the server running the STA.

All Secure Gateway components support the use of digital certificates. Although not a requirement, Citrix recommends that the communication links between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Deployment Scenario B: Double-Hop Demilitarized Zone


WXYCo, Inc. deployed the Web Interface for access to published resources hosted on Citrix XenApp servers. The company plans to deploy the Secure Gateway to provide secure Internet access to published resources. The security analyst recommended setting up a double-hop DMZ between the Internet and the companys secure network and securing communications between the Secure Gateway, the Web Interface, and the Secure Gateway Proxy.

A Secure Gateway deployment in a double-hop DMZ environment with a server farm

This figure shows a Secure Gateway deployment used to secure a server farm in a double-hop DMZ environment. The secure enterprise network is separated from the Internet by a double-hop DMZ. The enterprise network contains a server farm including a server running Citrix XenApp with the Secure Ticket Authority (STA). The firewall separating the secure network from the second DMZ segment has port 443 open. If session reliability is enabled, port 2598 is open. The second DMZ segment contains a server running the Secure Gateway Proxy and a second server running the Web Interface. The firewall separating the first and second DMZ segments has port 443 open. The first DMZ segment contains a single server running the Secure Gateway. All traffic originating from the Secure Gateway to servers in the secure network is proxied through the Secure Gateway Proxy.

957

Deploying the Secure Gateway in a Double-Hop DMZ If the communications link between the Secure Gateway and the Secure Gateway Proxy is not secured, open port 1080 on the firewall between the first DMZ segment and the second. The Secure Gateway communicates directly with the server running the Web Interface in the second DMZ segment, which in turn communicates directly with servers in the secure network. The first DMZ segment is separated from the Internet by a firewall that has port 443 open. The mobile workforce carries notebook PCs running a 32-bit Windows operating system, Internet Explorer 5.5, and the Citrix online plug-in for 32-bit Windows.

958

Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ
The Secure Gateway is installed on a standalone server in the first DMZ. The Secure Gateway Proxy is installed on a stand-alone server in the second DMZ. See Installing and Configuring the Secure Gateway and Secure Gateway Proxy.

Setting Up and Testing the Web Interface in a Double-Hop DMZ


The Web Interface needs to be set up on a Web server in the second DMZ segment. Ensure you complete the following tasks before you install the Secure Gateway.

1. Install the Web Interface on a standalone server in the second DMZ segment. 2. To secure communications between the Secure Gateway and the Web Interface, ensure you install a server certificate on the server running the Web Interface. 3. Add and configure server farms for use with the Web Interface. 4. Configure the Secure Gateway using the FQDN of the STA. 5. Use a Web browser on a user device to connect and log on to the Web Interface. 6. Verify that you can launch published applications.

959

Publishing the Web Address for the Secure Gateway in a Double-Hop Demilitarized Zone
Because all traffic to the Web Interface is proxied through the Secure Gateway, users should type one of the following default Web address to access the logon page or XenApp Web site: https://Secure Gateway FQDN/Citrix/AccessPlatform

https://Secure Gateway FQDN/Citrix/XenApp where Secure Gateway FQDN is the fully qualified domain name for the server running the Secure Gateway. In the case of WXYCo, the default Web address for the logon page or Web site is one of the following: https://www.gateway01.wxyco.com/Citrix/AccessPlatform/ https://www.gateway01.wxyco.com/Citrix/XenApp Alternatively, consider changing the default Web root directory in IIS on the server running the Web Interface to point to the Web Interface directory. This enables you to access the logon page or Web site by connecting directly to the root Web address; that is, https://Secure Gateway FQDN/. In this case, the Web address that employees of WXYCo use to access the logon page is: https://www.gateway01.wxyco.com/

960

Setting Up and Testing a Server Farm


Complete the following tasks prior to installing and configuring the Secure Gateway.
q

Install and configure a server farm in the enterprise network. Install, configure, and publish applications on the server farm. Connect to the server farm using a user device and ensure you can access available published resources.

See the Citrix XenApp installation and administration topics for detailed instructions about performing these tasks.

961

Installing the Secure Ticket Authority


When Citrix XenApp is installed, the Secure Ticket Authority (STA) is installed and configured automatically. The STA eliminates the requirement for Microsofts Internet Information Services (IIS). The STA can be hosted by the Citrix XML Service. If the STA is hosted by the Citrix XML Service, configure the Citrix SSL Relay. During installation of the Secure Gateway, enter the FQDN of the server running Citrix XenApp. If you are using an SSL-enabled connection between the Secure Gateway and the STA, make sure the correct certificates are installed from a certificate authority.

962

Testing Your Deployment


After you complete installation and configuration of the Secure Gateway, test your deployment to make sure it works and is accessible through the Internet. If you encounter problems loading the logon page, try working your way through the deployment steps to figure out the problem. You can also run the Secure Gateway Diagnostics tool to find a solution. This utility contacts all servers running the Secure Gateway components and generates a report containing configuration and status information for each component. For more information, see Generating the Secure Gateway Diagnostics Report.

To test your deployment


1. Use a Web browser on a user device to connect to the Secure Gateway; for example, https://www.gateway01.wzyco.com/Citrix/AccessPlatform/ or https://Web Interface FQDN/Citrix/XenApp. 2. Log on using domain credentials. After a brief interval, the Applications page containing icons for published resources appears. 3. Verify that you can launch published applications from this page.

963

Installing and Configuring the Secure Gateway and Secure Gateway Proxy
In addition to describing the Secure Gateway and Secure Gateway Proxy installation and configuration processes, this section also explains how to move to the current version of Secure Gateway from an installed earlier version. It also presents how to use a firewall with Secure Gateway and Secure Gateway Proxy. When Secure Gateway or Secure Gateway Proxy is installed on a supported 64-bit Windows operating systems, it installs in the 32-bit application location by default. Important: You must have access to administrative privileges to install and configure the Secure Gateway and use the management tools. Disable User Account Control (UAC) while installing and configuring the Secure Gateway and Secure Gateway Proxy. Note: If Secure Gateway or Secure Gateway Proxy is already installed, disconnected all active sessions before reinstalling or reconfiguring it. Otherwise, the Secure Gateway service might fail to restart.

964

Upgrading Secure Gateway or Secure Gateway Proxy


You can upgrade from these versions of Secure Gateway or Secure Gateway Proxy:
q

Secure Gateway or Secure Gateway Proxy 3.2 Secure Gateway or Secure Gateway Proxy 3.1.4 Secure Gateway or Secure Gateway Proxy 3.1.3

Perform a fresh installation to migrate from these versions of Secure Gateway or Secure Gateway Proxy; upgrading is not supported:
q

Secure Gateway or Secure Gateway Proxy 3.1 Secure Gateway or Secure Gateway Proxy 3.0.x Secure Gateway or Secure Gateway Proxy 3.0

To perform a fresh installation: 1. Remove any installed Secure Gateway hotfix software packages. 2. Remove the Secure Gateway or Secure Gateway Proxy software. 3. Install Secure Gateway or Secure Gateway Proxy.

965

Using Firewall Software with the Secure Gateway or Secure Gateway Proxy
The firewall software included in your Microsoft Windows server operating system (such as Windows Firewall with Advanced Security) where the Secure Gateway or Secure Gateway Proxy is used might not automatically allow access to required ports. Non-Microsoft firewall software might also disallow port access by default. Also, the Secure Gateway or Secure Gateway Proxy does not automatically create an exception to allow access to the default SSL port 443, the default Secure Gateway Proxy port 1080, or any port number you select when configuring the software. Manually add or allow access to these ports to any firewall software you are using in your environment.

966

Installing the Secure Gateway or Secure Gateway Proxy


The Secure Gateway installer installs the Secure Gateway or the Secure Gateway Proxy. When installation is complete, the Secure Gateway Configuration wizard automatically starts so you can configure Secure Gateway. The following steps outline the installation sequence of the Secure Gateway:
q

Install Citrix XenApp. Install root and server certificates on the appropriate computers. If using a double-hop DMZ, install the Secure Gateway Proxy in the second DMZ. If you are securing communications between the Secure Gateway and the Secure Gateway Proxy, ensure you install a server certificate on the server running the Secure Gateway Proxy. Install the Secure Gateway in the first, or only, DMZ.

Important: The Secure Gateway is designed to discover and verify the existence of the other Citrix components during configuration. For example, during configuration the Secure Gateway verifies that servers running the Web Interface and the Secure Ticket Authority (STA), if used, are functional. If a required component is not found, the Secure Gateway may fail to start. Ensure that you follow the recommended installation sequence. The installation sequence must be in this order: 1. Always install components within the secure network first. 2. Optional. If your network contains a double-hop DMZ, install components in the second DMZ segment next. 3. Install components in the first DMZ segment last.

967

To install the Secure Gateway or Secure Gateway Proxy


1. On the installation media, click autorun.exe. The Autorun menu launches.. 2. Select Manually install components > Server Components > Secure Gateway. 3. On the Welcome screen, click Next. 4. Read and accept the license agreement, and then click Next. 5. In Installation Mode, select Secure Gateway or Secure Gateway Proxy. 6. To install the Secure Gateway components in the default destination path, click Next. To install these components in a different location, click Browse and then navigate to the folder you want to use. 7. In Service Account, select the user account to determine credentials and privileges. Citrix recommends that you select an account that restricts privileges. 8. Click Next and follow the instructions in the wizard to complete installation. 9. After installing the Secure Gateway, configure it as described in Configuring the Secure Gateway or Secure Gateway Proxy.

968

Configuring the Secure Gateway or Secure Gateway Proxy


The Secure Gateway Configuration or Secure Gateway Proxy Configuration wizard automatically starts when the installation is complete. The wizard guides you through configuration tasks and provides context-sensitive help describing the procedures and information you need to enter. Configuring the Secure Gateway for use with Citrix XenApp requires the following information:
q

The FQDN and path of the server running the STA The FQDN and path of the server running the Web Interface

To start the wizard manually, see To start the configuration wizard manually. See also Using Firewall Software with the Secure Gateway or Secure Gateway Proxy.

969

To start the configuration wizard manually


If you need to start the configuration wizard manually (for instance, to change the configuration at any time after initial installation and configuration), perform the following steps. 1. Log on as an administrator to the computer running the Secure Gateway. 2. Open the wizard by clicking Start and locating the Secure Gateway Management Console. 3. In the Secure Gateway Management Console menu, click Action > All Tasks and select Stop to stop the Secure Gateway Service. 4. From the Start button, locate and click Secure Gateway Configuration Wizard or Secure Gateway Proxy Configuration Wizard. 5. Click OK.

970

To select a configuration level (Secure Gateway)


Task Summary for Secure Gateway, Advanced or Standard Configuration describes the task summary depending on the configuration level you select. 1. Select one of the following to access the parameters available for modification during the configuration process:
q

Standard Includes only the minimum set of parameters required to configure the Secure Gateway. The Secure Gateway Configuration wizard sets all remaining parameters to their default values, respectively.

Advanced Includes all of the Secure Gateways configurable parameters, for example, supported secure protocols and logging exclusions.

971

To select a configuration level (Secure Gateway Proxy)


Task Summary for Secure Gateway Proxy, Advanced or Standard Configuration describes the task summary depending on the configuration level you select. 1. Select one of the following to access the parameters available for modification during the configuration process:
q

Standard Includes only the minimum set of parameters required to configure the Secure Gateway Proxy. The Secure Gateway Proxy Configuration wizard sets all remaining parameters to their default values, respectively.

Advanced

Includes all of the Secure Gateway Proxys configurable parameters, for example, supported secure protocols and logging exclusions. 2. Select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option to secure communications between the Secure Gateway and the Secure Gateway Proxy servers using SSL or TLS. When this option is not selected, the connection between the Secure Gateway and Secure Gateway Proxy is not secured. To secure traffic between the Secure Gateway and Secure Gateway Proxy you must also:
q

Install a server certificate on the server running the Secure Gateway Proxy Install a client certificate on the Secure Gateway

972

Task Summary for Secure Gateway, Advanced or Standard Configuration


The task summary when selecting the advanced or standard configuration type is as follows:

Tasks

Advanced Configuration Selected X X X X X X X X X

Standard Configuration Selected X Not available X X X Not available Not available X X

To select a server certificate To configure secure protocol settings To configure inbound client connections To configure outbound connections To add the Secure Ticket Authority details To configure connection parameters To configure logging exclusions To add the Web Interface server details To configure the logging parameters

973

Task Summary for Secure Gateway Proxy, Advanced or Standard Configuration


The task summary when selecting the advanced or standard configuration type is as follows:

Tasks

Advanced Configuration Selected X X X X Not available X X X

Standard Configuration Selected X Not available X X Not available Not available Not available X

To select a server certificate To configure secure protocol settings To configure inbound client connections To configure outbound connections To add the Secure Ticket Authority details To configure connection parameters To configure logging exclusions To configure the logging parameters

974

To select a server certificate


Server certificates enable user devices to verify the identity of the server running the Secure Gateway. Note: This option is not displayed when you are installing the Secure Gateway Proxy and you select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option as described in To select a configuration level (Secure Gateway Proxy). 1. Select a valid server certificate installed on the computer running Secure Gateway or Secure Gateway Proxy from the Certificates Found menu. 2. Click View to display the details of the selected certificate.

975

To configure secure protocol settings


This configuration dialog appears if you selected Advanced for the Secure Gateways configuration level. Select the secure protocol and cipher suite used to secure the data transmitted between the Secure Gateway and the user device or Secure Gateway Proxy. Note: When deployed in proxy mode, the Secure Gateway Proxys client is the Secure Gateway. However, when deployed in relay mode, the Secure Gateway Proxys client is Citrix Receiver for Windows or the Citrix online plug-in. 1. Select a secure protocol:
q

Transport Layer Security (TLSv1) Configure the Secure Gateway to use only TLS as its secure protocol. If you select this option, verify that all user devices support and are configured to use TLS as well.

Secure Sockets Layer (SSLv3) and TLSv1 Configure the Secure Gateway and Secure Gateway Proxy to use SSL and TLS as its secure protocols. This option is useful when deploying the Secure Gateway or Secure Gateway Proxy in an environment in which some clients support only SSL.

Note: If a user device supports both the SSL and TLS protocols, TLS is used to secure the data transmitted between the Secure Gateway/Secure Gateway Proxy and the client. 2. Select a cipher suite:
q

GOV You can configure the Secure Gateway/Secure Gateway Proxy to use the following government strength cipher suite: RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}

COM You can configure the Secure Gateway/Secure Gateway Proxy to use the following commercial strength cipher suites: RSA_WITH_RC4_128_MD5 or {0x00,0x04}, RSA_WITH_RC4_128_SHA or {0x00,0x05}

ALL You can configure the Secure Gateway/Secure Gateway Proxy to use both the commercial and government strength cipher suites. This option is useful when deploying the Secure Gateway/Secure Gateway Proxy in an environment where some user devices support only COM while others support only GOV.

Note: When the Secure Gateway and a user device support both COM and GOV cipher suites, the Secure Gateway uses the COM cipher suite. 3. Click Next to proceed.

976

To configure inbound client connections


Specify the IP addresses and TCP ports that you want the Secure Gateway/Secure Gateway Proxy to monitor for incoming connections. See also Using Firewall Software with the Secure Gateway or Secure Gateway Proxy. 1. Select each Monitor all IP addresses check box to configure the Secure Gateway to listen for connections on all available IPv4 or IPv6 addresses. This option is useful when configuring the Secure Gateway/Secure Gateway Proxy on a server using multiple network interface cards (NICs). When configured in proxy mode, the Secure Gateway Proxy listens on all available IP addresses for Secure Gateway connections. When configured for relay mode, the Secure Gateway Proxy listens on all available IP addresses for client connections. 2. Type a listener TCP port number in the TCP Port field. This option is available only when the Monitor all IP addresses option is selected. The Secure Gateway/Secure Gateway Proxy listens for Secure Gateway or client connections on all available IP addresses using the port specified on the server. The default TCP port is 443. 3. Clear the Monitor all IP addresses check boxes to configure the Secure Gateway/Secure Gateway Proxy to listen on one or more specific IP addresses. Then click Add to add one or more IP addresses and related TCP port address.

Typically, you would exclude dynamic IP addresses. When a dynamic IP address changes, new connections are not accepted on that address and the service can fail to start when the server is restarted.

977

To configure outbound connections


Select the servers to which the Secure Gateway can connect:

Options No outbound traffic restrictions Use the Secure Gateway Proxy

Description Select this option to enable the Secure Gateway/Secure Gateway Proxy to establish connections to any server within the DMZ or secure network. Click Next to continue. This option is not available when configuring the Secure Gateway Proxy. Select this option when configuring the Secure Gateway in a double-hop environment. See To configure servers running the Secure Gateway Proxy. Select the Secure traffic between the Secure Gateway and the Secure Gateway Proxy check box to use HTTPS to secure communications between them. Select this option to create an access control list for the Secure Gateway/Secure Gateway Proxy. An access control list restricts the Secure Gateway/Secure Gateway Proxy to establishing connections to servers specified in the list. Click Configure to specify the start and end IP address range for allowed connections. See To configure an access control list for outbound connections.

Use an Access Control List (ACL)

Note: In a double-hop DMZ, configure outbound access control lists on the Secure Gateway Proxy server only.

978

To configure an access control list for outbound connections


You do not need to include servers running the Secure Ticket Authority because these are configured elsewhere in the wizard. 1. Select the Use an Access Control List (ACL) button, click Configure, and then click Add. 2. If you select the IP Address Range option, type or select the following information:

Option Start address

Description Enter the IP address of a server that you want to add to the outbound access control list. When specifying an IP address range, enter the ranges start IP address. If you use an IP address range for multiple servers running XenApp, be sure that the servers you specify offer the full range of applications that you want to be available. Leave this field blank if you are creating an entry for a single server. Otherwise, enter the end address of the range. Enter the TCP port used by the server(s). To allow connections to any port on a server you can use the wild card asterisk character (*) in the TCP port field. You can use this wild card to allow one ACL entry for a range of IP addresses to permit connections using the ICA and Common Gateway Protocol (CGP) protocols. Select this option to use the default port used by the server for the protocol selected. Select this option to allow ICA/SOCKS connections to the selected servers. Typically, you would use ICA for servers running Citrix XenApp that accept ICA/SOCKS connections. This option is not available to the Secure Gateway Proxy.

End address

TCP port

Use default port ICA

Select this option to allow CGP connections to the selected servers. Typically, you would use CGP for servers running Citrix XenApp that accept CGP connections. CGP can provide session reliability if you enable session reliability on the selected servers. To allow CGP as well as ICA/SOCKS connections to the same servers, add a separate entry for each protocol. This option is not available to the Secure Gateway Proxy. 3. If you select the Server FQDN option, type or select the following information:

CGP

Options

Description

979

To configure an access control list for outbound connections FQDN TCP port Enter the fully qualified domain name of the server to which the Secure Gateway Proxy allows access. Enter the TCP port used by the server. To allow connections to any port on a server, you can use the wild card asterisk character (*) in the TCP port field.

Select this option to secure communications between the server and the Secure Gateway Proxy servers using SSL or TLS. When this option is not selected, the connection is not secured. 4. Click OK, then click Add to add another connection, or click OK to close the dialog box.

Secure traffic between the server and the Secure Gateway Proxy

980

To configure servers running the Secure Gateway Proxy


1. From the Configure outbound connections dialog window, select Use the Secure Gateway Proxy radio button and click Configure. 2. Click Add. 3. Type the fully qualified domain name (FQDN) or IP addresses and TCP port of the Secure Gateway Proxy servers to which you want the Secure Gateway server to connect. The default TCP port for unsecured communications between the Secure Gateway and the Secure Gateway Proxy is 1080. The default TCP port for secure communications between the Secure Gateway and Secure Gateway Proxy is 443. 4. Click OK. 5. Select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option to secure communications between the Secure Gateway and the Secure Gateway Proxy servers using SSL or TLS. When this option is not selected, the connection between the Secure Gateway and Secure Gateway Proxy is not secured. To secure traffic between the Secure Gateway and Secure Gateway Proxy you must also:
q

Install a server certificate on the server running the Secure Gateway Proxy

Install a client certificate on the Secure Gateway 6. Click OK.


q

981

To add the Secure Ticket Authority details


You can configure the Secure Gateway to contact multiple STAs for failover protection. If you specify multiple STAs, be sure that this list matches the list of STAs that the Web Interface is configured to contact. 1. Type or select the following information: Option FQDN Path Description Enter the fully qualified domain name of the server running the STA. This field is populated automatically with the default virtual directory path, /Scripts/CtxSTA.dll or CitrixAuthService/AuthService.asmx. If you changed the default path when you configured the Citrix XML Service to share a port with Internet Information Services on the server running Citrix XenApp, enter the correct path. This field is populated automatically by the Secure Gateway when it resolves the specified FQDN and reads the ID string from the server running the STA. If the Secure Gateway is unable to resolve the address specified you are prompted to enter the ID for the STA. The ID for the STA is a randomly generated string. You can view STA IDs by running the Secure Gateway diagnostic tool. Select this option to secure communications between the Secure Gateway and the STA by using SSL or TLS. To enable this security feature, the FQDN of the STA must match the FQDN specified by its server certificate. Enter a network port number used by the Secure Gateway to contact the STA. Select this option to use the default port assignment for the STA. The default TCP port for unsecured communications between the Secure Gateway and the STA is 80. The default TCP port for secure communications between the Secure Gateway and STA is 443.

ID

Secure traffic between the STA and the Secure Gateway TCP port Use default

982

To configure connection parameters


You can configure how connection requests time out. Preventing requests from timing out may be useful if your network has periods of high latency. However, uncompleted connection requests that do not time out, or time out slowly, can preempt additional connections through the Secure Gateway. The number of connections the Secure Gateway server can support depends on the server processor, usage, and limits set in the Concurrent Connection Limits section. Select one of the following options: Option No connection timeout Description Select this option if you do not want to limit the time in which Secure Gateway must complete a connection request. Do not select this option if typical usage behavior can result in so many uncompleted connection requests that the server stops accepting connection requests. Set the interval of time in which the Secure Gateway can complete a connection request. If the connection is not established by the time the specified value elapses, then the connection times out. By default, the connection timeout value is configured for 100 seconds. This option is not available for the Secure Gateway Proxy. Set the following values using numbers suitable to your environment. Consider processor type and processor speed as well as typical usage behavior. Failure to do so may overload the processor and result in a poor quality of service for your end users.
q

Connection timeout (seconds)

Concurrent Connection Limits

Unlimited. Select this option to configure the Secure Gateway to support up to 1,920 concurrent client connections (250 connections are allocated to HTTP/S by default, leaving 1,670 ICA/CGP connections, including MAPI over CGP connections). The Secure Gateway stops accepting new connection requests if the number of concurrent client connections reaches 1,920. This setting overrides the value entered in Maximum connections. Maximum Connections. Specify the maximum number of concurrent ICA/CGP connections supported by the Secure Gateway. The Secure Gateway stops accepting new ICA/CGP connection requests when the number of concurrent connections equals the value entered in this field.

983

To configure logging exclusions


Typically, third-party network devices such as load balancers generate extraneous Secure Gateway log information. For example, load balancers might poll the Secure Gateway repeatedly to ensure that the server is active. Each poll is recorded by the Secure Gateway as a connection, resulting in the event log containing several unnecessary entries. The Secure Gateway and the Secure Gateway Proxy generate their own log files. Therefore, if you deployed the Secure Gateway in proxy mode, you must configure each components logging exclusions separately. 1. Click Add to enter the IP address of a network device that you want the Secure Gateway to exclude from its logging operations. 2. After typing the IP address, click OK.

984

To add the Web Interface server details


The Web Interface works with the Secure Gateway to provide a logon interface, and facilitates the authentication and authorization of connection requests to server farms. Running the Secure Gateway and the Web Interface on a single server is supported only in a single-hop DMZ environment. 1. Select one of the following access options:
q

Indirect To access the Web Interface, users enter the URL of the Secure Gateway. Users connect to the Secure Gateway, which routes the request to the Web Interface. If the Web Interface is installed on the same computer as the Secure Gateway, select the Installed on this computer check box (this option is not available in a double-hop environment). If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP address, and one server.

Direct

If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP address, and one server. 2. If you do not select the Installed on this computer check box, type or select the following information in the Details area:
q

FQDN Enter the fully qualified domain name of the server running the Web Interface. If you selected Installed on this computer, this field is automatically populated with the value localhost.

TCP port

Enter the port number the Secure Gateway should use when communicating with the Web Interface. 3. Select the Secure traffic between the Web Interface check box to configure the Secure Gateway to use HTTPS when communicating with the Web Interface.

985

To configure the logging parameters


1. Specify the type of errors and events that the Secure Gateway/Secure Gateway Proxy writes to the event log and Event Viewer. The logging levels available include the following:
q

Fatal Events Only Fatal error messages are logged when an operational failure prevents the Secure Gateway Proxy from starting. Select this option to log only fatal events.

Error and Fatal Events Error messages are logged when a partial failure, such as the Secure Gateway Proxy being out of memory, occurs. Select this option to log errors and fatal events.

Warning, error, and fatal events Warning messages are logged when tickets time out, data packets are corrupted, and similar events occur. Select this option to log warnings, errors, and fatal events.

All events including informational

All events are logged, including informational messages resulting from client connections. Select this option to log all events and errors. Selecting this option will result in the Event Viewer window and event log filling up rapidly. 2. Click Next.

986

To complete the configuration


You must start or restart the Secure Gateway/Secure Gateway Proxy to use the new configuration settings. If the Secure Gateway/Secure Gateway Proxy is already running, restarting it disconnects all active sessions. To avoid disconnecting active user sessions, you can clear the Restart Secure Gateway Proxy check box. Select Start the Secure Gateway or Start the Secure Gateway Proxy and click Finish. Note: If a client is connected to the Secure Gateway and the Secure Gateway is restarted, the Secure Gateway does not generate service stop and service start event log messages. If a client is not connected and the Secure Gateway is restarted, Secure Gateway does generate these messages. See also Using Firewall Software with the Secure Gateway or Secure Gateway Proxy.

987

To stop the Secure Gateway/Secure Gateway Proxy service


1. Log on as an administrator to the Secure Gateway. 2. From the Start button, locate and click Secure Gateway Management Console. 3. In the Secure Gateway Management Console, on the Action menu, click All Tasks and click Stop.

988

To uninstall the Secure Gateway


1. Exit any applications running on the server. 2. Open the Control Panel and click Programs and Features. 3. Select Secure Gateway and click Uninstall.

989

Managing the Secure Gateway


The Secure Gateway Management Console is an MMC snap-in that provides an administrator with tools to administer, monitor, and troubleshoot the Secure Gateway. You can access the Secure Gateway Management Console from the Citrix program menu on the Start menu. You can start, stop, and restart the Secure Gateway using the icons available on the console toolbar. In addition, the Secure Gateway Management Console displays the following information:
q

Session and connection information for the Web Interface that is currently running through the Secure Gateway. The sessions for the Web Interface have one connection for one session. An instance of the Windows Performance Monitor containing performance statistics applicable to the Secure Gateway. Review this list to obtain detailed information regarding the status of client connections running through the Secure Gateway.

The Secure Gateway Management Console also provides access to the following:
q

The Secure Gateway Configuration wizard The Secure Gateway Diagnostics tool

990

Viewing Session and Connection Information with the Secure Gateway Console
The Secure Gateway provides session and connection information in the Secure Gateway Management Console.

To view session connection properties


1. From the Session Information pane, select a session. 2. Right-click and select Properties. Alternatively, double-click a session. The following statistics are available for all active sessions running through the Secure Gateway:

Statistic Client IP User Domain Time Established Time Elapsed

Description The IP address and port of the remote client. The current user associated with the session, if any. The network domain from which the current user is logged on. The time that this connection was established. The amount of time, in seconds, that elapsed since this connection was established.

To disconnect an active session


1. From the Session Information pane, right-click the active session you want to disconnect and select All Tasks > Disconnect. 2. Right-click and select All Tasks - Disconnect.

To freeze (pause) and resume the display of session information

991

Viewing Session and Connection Information with the Secure Gateway Console The information in the session information pane refreshes every five seconds. If you want to view details of a particular session, you may find it useful to turn off the automatic screen refresh feature. 1. From the Session Information pane, right-click any session entry and select All Tasks > Freeze Display. 2. From the Session Information pane, right-click any session entry and select All Tasks > Resume Display.

992

Viewing Secure Gateway Performance Statistics


The Secure Gateway includes a customized Windows System Monitor containing real-time performance statistics, or counters, for the Secure Gateway. You can use this monitor to evaluate and troubleshoot connections running through the Secure Gateway. Performance data can be used to:
q

Understand the workload on the Secure Gateway and the corresponding effect it has on system resources Observe changes and trends in workloads and resource usage so you can plan system sizing and failover Test changes in configuration or other tuning efforts by monitoring the results Diagnose problems and target components or processes for optimization

Performance statistics include the data throughput rate in bytes per second across CGP, HTTP/S, SOCKS, and total client connections through Secure Gateway. The "Successful" counters indicate the number of users connections that have successfully completed since the Secure Gateway service was last started. Users can have multiple connections within each session. The Active counters indicate the number of active connections going through the Secure Gateway. The Secure Gateway System Monitor takes advantage of several of the features included in the Windows System Monitor, including customizing the display of counter information and saving counter data. You can use the System Monitor icons at the top of the pane or shortcut keys to customize the display. For a list of the shortcut keys, see the Windows System Monitor help.You can display the Windows Performance monitor from the Secure Gateway Management Console. Citrix recommends that you monitor performance of the Secure Gateway as part of your administrative routine.

993

To view the Secure Gateway performance statistics

You can use the Secure Gateway performance statistics to troubleshoot connections to the Secure Gateway. For example:

The Secure Gateway processor load might be too high because too many users are connected to the Secure Gateway server. You can look at the total active connections to check how many users are connected. Users might not be able to launch their published applications because the Secure Gateway cannot connect to the XenApp servers. The failed Backend connections counter is high if this is the problem.

1. Open the Secure Gateway Management Console. 2. In the tree view, select Secure Gateway Performance Statistics. Performance statistics for the Secure Gateway appear in the right pane. 3. Use the Windows Performance Console controls that appear at the top of the right pane to perform tasks such as switching views or adding counters.

994

Performance Counters Available for the Secure Gateway


The following performance counters are available for the Secure Gateway: Counter name Bytes/Sec from Client Bytes/Sec to Client CGP Active Connections CGP Bytes/Sec from Client Description The data throughput rate (bytes per second) from all connected clients to the Secure Gateway. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients. The total number of CGP client connections currently active. The data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the CGP protocol. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the CGP protocol. The total number of kilobytes sent from all clients connected to the Secure Gateway using the CGP protocol. The total number of kilobytes sent from the Secure Gateway to all clients connected using the CGP protocol. The highest data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the CGP protocol. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the CGP protocol. The total number of successful CGP connections. The average amount of time (in milliseconds) for a client connection request to complete the connection process. The longest amount of time (in milliseconds) for a client connection request to complete successfully. The number of successful client connection requests per second. The highest number of successful client connection requests per second. The highest number of concurrent connections through the Secure Gateway.

CGP Bytes/Sec to Client

CGP Kilobytes from Client

CGP Kilobytes to Client

CGP Peak Bytes/Sec from Client

CGP Peak Bytes/Sec to Client

CGP Successful Connections Client Connect Time: Average (in ms) Client Connect Time: Longest (in ms) Connections/Second Connections/Second: Peak Connections: Peak Active

995

Performance Counters Available for the Secure Gateway Connections: Total Active Connections: Total Successful The total number of client connections currently active. The total number of successful client connections. It is the sum of all successful connections for all protocols: CGP, HTTP/S, and SOCKS. Total number of client connection requests accepted, but not yet completed, by the Secure Gateway. Pending connections are still active and have not timed out or failed. The total number of backend connections that failed. Clients that successfully connect to the Secure Gateway may not successfully connect to backend servers, such as a Web server. These connections are not counted as part of the failed client connection count. The total number of client connection requests that were accepted but timed out before completing the protocol handshake. The total number of client connection requests that failed to connect to the Secure Gateway for any reason other than timing out or SSL handshake error. The total number of client connection requests that were accepted but did not successfully complete the SSL handshake. The total number of failed client connection requests. It is the sum of the Failed Connections (Timed Out), Failed Connections (SSL Error), and Failed Connections (General Client Error) counters. The total number of HTTP/S connections currently active. The data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the HTTP/S protocol. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the HTTP/S protocol. The total number of kilobytes sent from all clients connected to the Secure Gateway using the HTTP/S protocol. The total number of kilobytes sent from all connected clients to the Secure Gateway using the HTTPS protocol. The highest data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the HTTP/S protocol.

Connections:Pending

Failed Backend Connections

Failed Connections: Client Timed Out Failed Connections: General Client Error

Failed Connections: SSL Client Handshake Error Failed Connections: Total Client

HTTP/S Active Connections HTTP/S Bytes/Sec from Client

HTTP/S Bytes/Sec to Client

HTTP/S Kilobytes from Client

HTTP/S Kilobytes to Client

HTTP/S Peak Bytes/Sec from Client

996

Performance Counters Available for the Secure Gateway HTTP/S Peak Bytes/Sec to Client The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the HTTP/S protocol. The total number of successful HTTP/S connections. The total number of kilobytes sent from all connected clients to the Secure Gateway. The total number of kilobytes sent from the Secure Gateway to all connected clients. The highest data throughput rate (bytes per second) from all connected clients to the Secure Gateway. The highest data throughput rate (bytes per second) from the Secure Gateway to all connected clients. The total number of SOCKS client connections currently active. The data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the SOCKS protocol. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the SOCKS protocol. The total number of kilobytes sent from all clients connected to the Secure Gateway using the SOCKS protocol. The total number of kilobytes sent from all connected clients to the Secure Gateway using the SOCKS protocol. The highest data throughput rate (bytes per second) from all clients connected to the Secure Gateway using the SOCKS protocol. The data throughput rate (bytes per second) from the Secure Gateway to all connected clients using the SOCKS protocol. The total number of successful SOCKS connections. Average length of time (in milliseconds) for an SSL handshake to complete. Length of time (in milliseconds) for the longest SSL handshake to complete. Number of successful SSL handshakes per second. Highest number of successful SSL handshakes per second. Number of SSL handshakes currently in progress between a client and the Secure Gateway.

HTTP/S Successful Connections Kilobytes from Client Kilobytes to Client Peak Bytes/Sec from Client

Peak Bytes/Sec to Client

SOCKS Active Connections SOCKS Bytes/Sec from Client

SOCKS Bytes/Sec to Client

SOCKS Kilobytes from Client

SOCKS Kilobytes to Client

SOCKS Peak Bytes/Sec from Client

SOCKS Peak Bytes/Sec to Client

SOCKS Successful Connections SSL Handshake Time: Average SSL Handshake Time: Longest SSL Handshakes/Sec SSL Handshakes/Sec: Peak SSL Handshakes: Pending

997

Performance Counters Available for the Secure Gateway SSL Handshakes: Total Total number of SSL handshakes that completed successfully between a client and the Secure Gateway.

998

Generating the Secure Gateway Diagnostics Report


The Secure Gateway Diagnostics tool presents configuration information and results of communication checks against servers hosting components such as the global settings, network protocols, and certificates. It is a quick and easy way of performing a series of checks to ascertain the health and status of the Secure Gateway components. To launch the Secure Gateway Diagnostics tools, click Secure Gateway Diagnostics from the Administration Tools found in the Citrix program group or from the Secure Gateway Management Console on the Start menu. The diagnostics tool scans the registry and reports global settings for the Secure Gateway. It uses the Secure Gateway configuration information to contact servers running the Web Interface, the Secure Gateway Proxy, and the STA, and reports whether or not the communication check passed or failed. It examines the server certificate installed on the server running the Secure Gateway and checks credentials and validity. In the Secure Gateway Diagnostics window, information icons indicate that a registry or configuration value is present:

Information icon Warning icon Passed check icon

A registry or configuration value is present. A registry or configuration value is missing. A communication check for the component passed.

Failed check icon A communication check for the component failed. For any component marked with a warning or failed check icon, verify that you properly installed the component and provided all necessary configuration information.

999

Viewing the Secure Gateway Events


Event logging allows administrators and Citrix support representatives to diagnose problems with the Secure Gateway.

To view Secure Gateway events


1. Open the Control Panel and double-click Administrative Tools. 2. Double-click Event Viewer. 3. Expand the Applications and Services Logs node and select Secure Gateway. All errors and events generated by the Secure Gateway appear in the right pane. 4. To view additional information, double-click an entry in the right pane. The General tab contains the event ID and a brief description of the Secure Gateway error.

Logging Events with the Secure Gateway Event Viewer


The Secure Gateway Event Viewer is a customized Windows Event Viewer that displays errors and events generated by the Secure Gateway. The error messages include: Status Messages of normal operational events, such as starting or stopping the Secure Gateway. Fatal Messages of operational failure events that prevent the Secure Gateway from starting. Service Messages regarding a partial failure of the Secure Gateway. Warning Messages logged as a result of events such as corrupted data requests, data packets received, or ticket time-outs. Informational Messages that are logged as a result of client connection events.

1000

Viewing the Secure Gateway Events The Secure Gateway error messages can be viewed using Windows Event Viewer. If a client is connected to the Secure Gateway and the Secure Gateway is restarted, the Secure Gateway does not generate service stop and service start event log messages. If a client is not connected and the Secure Gateway is restarted, Secure Gateway does generate these messages.

1001

Viewing the Secure Gateway Access Logs


The access logs generated by the Secure Gateway service record connection information. For the Secure Gateway, the access logs record HTTP, SOCKS, and CGP connection information. The Secure Gateway Proxy access log records SOCKS connections. Each access log provides specific information regarding connections.

To view the Secure Gateway access logs


1. Open Windows Explorer. 2. Navigate to the following path: The default path for the error logs is the installation path for the Secure Gateway or the Secure Gateway Proxy, typically %systemroot%\Program Files\Citrix\Secure Gateway\logs. 3. Open the log file with an ASCII text editor such as Notepad.

1002

Secure Gateway Configuration Wizard


The Secure Gateway Configuration wizard guides you through the process of specifying configuration parameters for the Secure Gateway. Each dialog box includes context-sensitive Help so that you can obtain additional information specific to the parameters you are configuring. Click Help within any dialog box to access the context-sensitive Help. You can access the Secure Gateway Configuration wizard from the Secure Gateway Management Console node in this console. You can also access the Secure Gateway Configuration wizard or the Secure Gateway Proxy Configuration wizard from All Programs in the Start menu of the server running the service or proxy. Running the Secure Gateway Configuration Wizard requires administrative privileges. Running the Secure Gateway Configuration Wizard requires administrative privileges.

1003

Secure Gateway Optimization and Security Guidelines


This section provides general compatibility guidelines for deploying the Secure Gateway in complex network environments containing components such as load balancers, SSL accelerator cards, and firewalls.

1004

Configuring Firewalls for the Secure Gateway


The Secure Gateway is typically deployed in the DMZ, so that traffic originating from a remote user device must traverse firewalls to get to the destination server in the secure network. It is, therefore, crucial to the Secure Gateway operation that firewalls are configured to allow network traffic traversal. Correct firewall configuration can help prevent disconnects and contribute toward better performance of the Secure Gateway. Of particular concern with regard to firewall traversal is ICA/SSL traffic, a Citrix-proprietary protocol used for communications between user devices and computers running Citrix XenApp. Firewalls are not ICA-aware and do not make any distinction between HTTPS or ICA/SSL traffic. The ICA protocol is a real-time, interactive protocol that is very sensitive to latency and other network delays. Because ICA traffic typically consists of mouse-clicks and keystrokes, delays in their transmission could result in significantly degraded performance of the connection. In contrast, HTTPS traffic is less sensitive to latency or other types of network delays. Therefore, HTTPS connections to computers running Citrix XenApp are less affected than ICA connections to computers running Citrix XenApp. To ensure that users experience usable and reliable sessions when using the Secure Gateway, Citrix recommends configuring your firewall to work in forwarding mode as opposed to proxy mode. Set the firewall to use its maximum inspection level. Configuring your firewall to use forwarding mode ensures that TCP connections are opened directly between remote user devices and the Secure Gateway. However, if you prefer to configure your firewall to use proxy mode, ensure that your firewall does not:
q

Impose any time-outs on ICA/SSL sessions, including idle, absolute, and data traffic time-outs Use the Nagle algorithm for ICA/SSL traffic Impose any other specific restrictions or filters on ICA/SSL traffic

1005

Ensuring High Availability of the Secure Gateway


You can design a Secure Gateway deployment to ensure high availability by deploying multiple servers running the Secure Gateway. This configuration does not make Secure Gateway sessions fault tolerant, but provides an alternative server if one server fails. When the number of concurrent sessions exceeds the capacity of a single server running the Secure Gateway, multiple servers running the Secure Gateway must be deployed to support the load. There is no practical limit to the number of servers running the Secure Gateway that can be deployed to service large server farms. To deploy multiple servers running the Secure Gateway, a load balancer is required. The function of the load balancer is to distribute client sessions to one of a number of servers offering a service. This is normally done by implementing a virtual address on the load balancer for a particular service and maintaining a list of servers offering the service. When a client connects to a service, the load balancer uses one of a number of algorithms to select a server from the list and directs the client to the selected server. The algorithm can be as simple as a round robin where each client connect request is assigned to the next server in a circular list of servers, or a more elaborate algorithm based on server load and response times. The client response to a server failure depends on which server fails and at what point in the session the server fails. Types of server failure include: Web Interface The server running the Web Interface is involved during user sign on, application launch, or application relaunch. Failure of the Web Interface requires you to reconnect to the logon page and sign on again when you want to launch a new application or relaunch an existing application. STA The STA is involved in the launch or relaunch of an application. Failure of the STA during application launch requires that you return to the published applications page on the Web Interface to relaunch the application. Secure Gateway The Secure Gateway is involved during application launch and the time an application remains active. If a session fails, the client connection goes to another server and the session automatically reconnects without having to log on again. Intelligent load balancers can detect the failure of a server through server polling, temporarily remove the failed server from the list of available servers, and restore them to the list when they come back online. 1006

Ensuring High Availability of the Secure Gateway

1007

Load Balancing Multiple Secure Gateway Servers


The benefits of load balancing across multiple servers running the Secure Gateway include: Scalability Optimize the Secure Gateway performance by distributing its client requests across multiple servers within the array. As traffic increases, additional servers are added to the array. The load balancing solution used imposes the only restriction to the maximum number of servers running the Secure Gateway in such an array. High availability Load balancing provides high availability by automatically detecting the failure of a server running the Secure Gateway and redistributing client traffic among the remaining servers within a matter of seconds. Load balancing an array of servers running the Secure Gateway is accomplished using a virtual IP address that is dynamically mapped to one of the real IP addresses (for example, 10.4.13.10, 10.4.13.11 and 10.4.13.12) of a server running the Secure Gateway. If you use a virtual IP address such as 10.4.13.15, all your requests are directed to the virtual IP address and then routed to one of the servers. You can set up the virtual IP address through software, such as Windows NT Load Balancing Service, or hardware solutions, such as a Cisco CSS 11000 Series Content Services switch. If you use hardware in a production environment, make sure to use two such devices to avoid a single point of failure.

1008

Load Balancing an Array of the Secure Gateway Proxy


You can load balance an array of servers running the Secure Gateway Proxy in the same way as the Secure Gateway. Instead of using an external load balancer, the Secure Gateway Proxy has built-in support for load balancing. This is useful in situations where you experience extremely high loads on the Secure Gateway array. In this case, it might help to deploy a second Secure Gateway Proxy and load balance the two servers. In addition, if the communications link between the Secure Gateway and the Secure Gateway Proxy is secured, you can use a single certificate for the Secure Gateway Proxy array.

1009

Certificate Requirements for Load Balancing Secure Gateway Servers


Load balancing relies on the use of a virtual IP address. The virtual IP address is bound to an FQDN and all clients request connections from the virtual IP address rather than the individual servers running the Secure Gateway behind it. A single IP address, the virtual IP, acts as an entry point to your servers running the Secure Gateway, simplifying the way clients access Web content, published applications, and services on computers running Citrix XenApp. If you are using a load balancing solution, all servers running the Secure Gateway can be accessed using a common FQDN; for example, csgwy.company.com. In conclusion, you need a single server certificate, issued to the FQDN (mapped to the virtual IP or DNS name) of the load balancing server. The certificate must be installed on every server running the Secure Gateway in the server array that is being load balanced.

1010

Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers
Load balancing solutions available in the market today may feature built-in SSL accelerator cards. If you are using such a solution to load balance an array of servers running the Secure Gateway, disable the SSL acceleration for traffic directed at the servers running the Secure Gateway. Consult the load balancer documentation for details about how to do this. Presence of SSL accelerator cards in the network path before the server running the Secure Gateway means the data arriving at the Secure Gateway is decrypted. This conflicts with a basic function of the Secure Gateway, which is to decrypt SSL data before sending it to a Citrix XenApp server. The Secure Gateway does not expect nonSSL traffic and drops the connection.

1011

Coordinating Keep-Alive Values Between the Secure Gateway and Citrix XenApp
If you enable TCP/IP keep-alive parameters on computers running Citrix XenApp, Citrix recommends that you modify the parameters on the server running the Secure Gateway in the same manner. In an environment containing the Secure Gateway, ICA and HTTP/S connections are routed through the Secure Gateway. TCP/IP keep-alive messages from the Citrix XenApp server to the remote client are intercepted, and responded to, by the server running the Secure Gateway. Similarly, TCP/IP keep-alive packets from the server running the Secure Gateway are sent only to the user device; the server running the Secure Gateway does not transmit keep-alives to the Citrix XenApp server. Setting the keep-alive values on the server running the Secure Gateway to match the values set on the Citrix XenApp server ensures that the server farm is aware of the client connection state and can either disconnect or log off from the connection in a timely manner.

1012

Setting Connection Keep-Alive Values and the Secure Gateway


The Secure Gateway establishes connections over the Internet between remote clients and Citrix XenApp servers. When a client connection is dropped without being properly logged off, the Secure Gateway continues to keep the connection to the server open. Accumulation of such ghost connections eventually affects Secure Gateway performance. A Secure Gateway deployment subject to a heavy load may run out of sockets because of these ghost connections remaining open. The Secure Gateway uses TCP/IP keep-alives to detect and close broken connections between the Secure Gateway and the client device. The default Windows setting for KeepAliveTime is two hours. This is the duration that TCP/IP waits before verifying whether or not an idle connection is still connected. Ghost connections may therefore remain open for up to two hours before the system detects that a connection failed. To prevent broken connections from remaining open, the Secure Gateway changes the KeepAliveTime to one minute. If a connection is dropped, the Secure Gateway knows within one minute, instead of two hours. If there is no response, TCP/IP retries the verification process after the interval specified by KeepAliveInterval and for a maximum number of times specified by TcpMaxDataRetransmissions. The default value for KeepAliveInterval is one second and the default value for TcpMaxDataRetransmissions is five seconds. If the Secure Gateway is under a heavy load and is used predominately to secure HTTP connections to internal Web servers, the Secure Gateway rapidly opens and closes connections. Closed connections stay in the TIME_WAIT state for an interval specified by TcpTimedWaitDelay. The default value of TcpTimedWaitDelay is four minutes; the Secure Gateway sets this value to 30 seconds. This change enables the Secure Gateway to recycle sockets faster resulting in improved performance. The system cannot reuse sockets in the TIME_WAIT state. MaxUserPort specifies the number of sockets available on the system. By default, the system uses ports between 1024 and 5000; the Secure Gateway modifies this setting to use ports between 1024 and 65000. The KeepAliveInterval, KeepAliveTime, MaxUserPort, TcpMaxDataRetransmissions, and TcpTimedWaitDelay parameters are stored in the Windows registry at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters\ For more information about making changes to these parameters, see the Microsoft knowledgebase articles, Q120642 - TCP/IP & NBT Configuration Parameters for Windows 2000 or Windows NT, Q314053 - TCP/IP & NBT Configuration Parameters for Windows XP, and Q196271 - Unable to Connect from TCP Ports Above 5000. Under normal circumstances, it is not necessary to change these settings.

1013

Improving Security (Recommendations)


This section suggests ways to improve security when using the Secure Gateway. Note: The Secure Gateway is an applicationspecific proxy designed to achieve a corresponding level of security. It is not a firewall and should not be used as such. Citrix recommends that you use a firewall to protect servers running the Secure Gateway, Citrix XenApp, and other corporate resources from unauthorized access from the Internet and internal users.

Changing or Restricting Ciphersuites


The process of establishing a secure connection involves negotiating the ciphersuite that is used during communications. A ciphersuite defines the type of encryption that is usedit defines the cipher algorithm and its parameters, such as the size of the keys. Negotiation of the ciphersuite involves the user device informing the Secure Gateway which ciphersuites it is capable of handling, and the Secure Gateway informing the client which ciphersuite to use for client-server communications. The Secure Gateway supports two main categories of ciphersuite: COM (commercial) and GOV (government). The ALL option includes both the commercial and government suites. The COM ciphersuites are:

SSL_RSA_WITH_RC4_128_MD5 or {0x00,0x04} SSL_RSA_WITH_RC4_128_SHA or {0x00,0x05}

The GOV ciphersuite is: SSL_RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A} Some organizations, including U.S. government organizations, require the use of government-approved cryptography to protect sensitive but unclassified data.

1014

Improving Security (Recommendations)

To change or restrict the ciphersuites


1. Log on as an administrator to the server running the Secure Gateway. 2. Launch the Secure Gateway Configuration wizard. 3. Select Advanced Configuration and click Next until you see the Configure secure protocol settings screen. The default setting for ciphersuites is ALL. 4. To restrict the ciphersuite, change the value to GOV or COM, as required. Click Next. 5. Follow prompts until configuration is complete. Click to exit the configuration wizard.

You must restart the Secure Gateway to let configuration changes take effect.

Restricting Ciphersuite Use to Secure Communication


The ciphersuites used to secure communications between the Secure Gateway and the Secure Gateway Proxy are determined by the configuration settings on the server running the Secure Gateway Proxy. The default setting on the Secure Gateway for outgoing connections to the Secure Gateway Proxy is set to use all ciphersuites. Security policies of some organizations may require tighter control of the ciphersuites offered by the Secure Gateway for outgoing connections to the Secure Gateway Proxy. This is achieved by modifying the SChannel registry settings. For instructions about modifying the SChannel registry settings to restrict ciphersuites, refer to the Microsoft Knowledge Base Article Q245030, How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll.

Modifying Protocols to Restrict Secure Gateway Connections


The Secure Gateway handles both SSL Version 3 and TLS Version 1 protocols. In this context:

The Secure Gateway uses TLS Version 1 as the default Internet Explorer uses SSL Versions 2 and 3 as the default

You can restrict the Secure Gateway to accept only SSL Version 3 or TLS Version 1 connections. If you decide to change the default protocol setting on the Secure Gateway, modify protocol settings on the client Web browser as well as the Gateway Client to match the protocol setting on the server running the Secure Gateway. Citrix recommends against changing the default setting for the secure protocol used by the Secure Gateway.

1015

Improving Security (Recommendations)

Removing Unnecessary User Accounts


Citrix recommends removing all unnecessary user accounts on servers running the Secure Gateway. Avoid creating multiple user accounts on servers running the Secure Gateway and limit the file access privileges granted to each account. Review active user accounts regularly and when personnel leave.

Removing Sample Sites Installed with IIS


An important security step is to disable or remove all sample Web applications installed by the Internet Information Services (IIS). Never install sample sites on production servers because of the many well-identified security risks they present. Some sample Web applications are installed so that you can access them only from http://localhost or the IP address 127.0.0.1. Nevertheless, you should remove the sample sites. The IISSamples, IISHelp, and Data Access virtual directories and their associated folders are good examples of sample sites that should not reside on production servers.

Securing Components that Run on IIS


To ensure that security of the Secure Gateway components is not compromised, you can do the following:

Set appropriate ACLs on IIS to prevent unauthorized access to executable and script files. For instructions about locking down IIS, refer to current Microsoft product documentation and online resources available from the Microsoft Web site. Secure all the Secure Gateway components using SSL or TLS to ensure that data communications between all the Secure Gateway components is encrypted.

To maximize the security of the servers running the Secure Gateway components hosted by IIS, follow Microsoft security guidelines for locking down Internet Information Services on Windows Servers.

Stopping and Disabling Unused Services


Windows services introduce vulnerabilities to the computer. If a Windows service is not required by your organization, Citrix recommends that the service be disabled. For a complete list of services and their functions, see the Threats and Countermeasures Guide on the Microsoft Web site. Note that disabling a Windows service could stop the computer from functioning correctly.

1016

Improving Security (Recommendations)

Installing Service Packs and Hotfixes


Ensure that you install all operating system-specific service packs and hotfixes, including those applicable to applications and services that you are running on the system. Ensure you do not install hotfixes for services that are not installed. Ensure you regularly review Security Bulletins from Microsoft.

Following Microsoft Security Guidelines


Citrix recommends that you review Microsoft guidelines for securing Windows servers. In general, refer to the Microsoft Web site for current guidance to help you understand and implement the processes and decisions that must be made to get, and stay, secure.

1017

Preventing Indexing by Search Engines


Search engines use a program that automatically retrieves Web pages and indexes the pages. This includes pages hosted on the Secure Gateway that might potentially be sensitive. Use a global file (robots.txt) to prevent indexing by most search engines. Install it at the root of the Web server, such as sg.customer.com/robots.txt. The content of robots.txt is: User-agent: * Disallow: /

1018

Troubleshooting the Secure Gateway


After you have configured NAT and packet filtering on your network, use the Secure Gateway Diagnostics tool to confirm that the Secure Gateway is configured correctly and that it is able to resolve addresses and communicate with servers located in the DMZ and the secure network. Troubleshooting information concerning firewall traversal, Domain Name Service (DNS), and Network Address Translation (NAT) are beyond the scope of this document. Run the Secure Gateway Diagnostics tool on the server running the Secure Gateway and examine the results reported. The report contains configuration values for the Secure Gateway and results of connection attempts to components and services in the DMZ and secure network that the Secure Gateway uses. For instructions about using the Secure Gateway Diagnostics tool, see Generating the Secure Gateway Diagnostics Report. Careful review of the Secure Gateway event log can help you identify the sources of system problems. For example, if log warnings show that the Secure Gateway failed because it could not locate the specified certificate, you can conclude that the certificate is missing or installed in the incorrect certificate store. In general, information in the event log helps you trace a record of activity leading up to the event of failure. If you receive an error: The Secure Gateway Fails with a CSG0188 Error, the error implies that SChannel could not validate certificate credentials of the server certificate used by the Secure Gateway. Ensure that the certificate installed was issued by a trusted source, is still valid, and is issued for the correct computer. For more troubleshooting information, see the Citrix support Web site at http://support.citrix.com/ for technical support options.

1019

To check your certificates


1. Log on as an administrator to the server running the Secure Gateway. 2. Open the Secure Gateway Configuration Wizard. 3. Select the products you want to secure and then click OK. 4. On the Secure Gateway configuration level screen, select Advanced. 5. In the Select server certificate dialog box, select the certificate the Secure Gateway is configured to use and click View. 6. Check that the value in the Issued To field matches the FQDN of this server. 7. When you view the certificate, ensure that it contains a key icon and the caption You have private key that corresponds to this certificate at the bottom of the General tab. The lack of an associated private key can result in the CSG0188 error. 8. Ensure the certificate is not expired. If it is expired, you need to apply for certificate renewal. Contact the appropriate resources in your company for assistance with certificate renewal.

1020

Client Connections Launched from IP Addresses in the Logging Exclusions List Fail
For security reasons, IP addresses configured in the logging exclusions list are not allowed to establish connections to the Secure Gateway. This measure blocks connections to the Secure Gateway that do not leave an audit trail. The logging exclusions list is designed to help keep the system log free of redundant data. Configure the IP address of load balancing devices in the Logging Exclusions list. Configuring an exclusions list enables the Secure Gateway to ignore polling activity from such devices and keeps the log free of this type of data.

1021

Load Balancers Do Not Report Active Client Sessions if Connections Are Idle
Some load balancers stop reporting active client connections flowing through them if the connections are idle for a while because of the way in which certain load balancers treat idle connections. Connections that are idle for a certain amount of time stop being represented as active connections in the load balancers reporting tools even though the connections are still valid. Resolve this issue by modifying the keepalive settings in the Windows registry on the server(s) running the Secure Gateway. If you load balance an array of servers running the Secure Gateway, decrease the keepalive values to force packets to be sent after a period of session inactivity. For more information about configuring TCP/IP keepalive settings, see Coordinating Keep-Alive Values Between the Secure Gateway and Citrix XenApp.

1022

Performance Issues with Transferring Files Between a User Device and a Citrix XenApp Server
Users may experience performance issues with data transfer using client drive mapping on high bandwidth, high latency connections. As a workaround, you can optimize throughput by increasing the value of TcpWindowSize in the Windows registry of your server running the Secure Gateway. Caution: Using the Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee resolution of problems resulting from the incorrect use of Registry Editor. Use Registry Editor at your own risk. To modify this setting, edit the following Windows Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\TcpWindowSize Citrix recommends setting the value of TCPWindowSize to 0xFFFF(64K). Be aware that this change incurs higher system memory usage. Citrix recommends increasing physical system memory on the server running the Secure Gateway to suit the typical usage profile of the network.

1023

Gateway Client Connections Fail When Using Windows XP Service Pack 2


Windows XP Service Pack 2 prevents connections to all IP addresses that are in the loopback address range except for 127.0.0.1. If the Gateway Client is using a loopback address other than 127.0.0.1, the connection to the Secure Gateway fails. Microsoft provides a patch to fix this issue. For more information, refer to the Microsoft Knowledgebase Article Programs that connect to IP addresses that in the loopback address range may not work as you expect in Windows XP Service Pack 2 (884020) available from the Microsoft Support Web site at http://support.microsoft.com/.

1024

Failed Client Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log
You may find duplicate entries for client connection attempts in the Secure Gateway application and performance logs. Duplicate entries can occur in the following situations:
q

SSL protocol mismatch between the user device and the server running the Secure Gateway Client automatically attempts to reconnect if the first connection attempts fails

The log entries are actually a record of client behavior. In these cases, the client attempts to reconnect if it fails the first time.

1025

Placing the Secure Gateway Behind a Reverse Web Proxy Causes an SSL Error 4
If the Web Interface and the Secure Gateway are on the same server, it can create confusion if a reverse Web proxy is placed between the client and the Secure Gateway. Clients can communicate with the enterprise network using HTTPS but traffic for ICA/SSL is refused. When a combination of the Web Interface and the Secure Gateway is placed behind a reverse Web proxy server, users can log on using the Web Interface and enumerate application icons, which is all HTTP communications. When users launch a published application, they receive an SSL Error 4 because the ICA/SSL session is terminated by the reverse Web proxy, not by the Secure Gateway.

This graphic shows the incorrect placement of the Secure Gateway and Web Interface behind a reverse Web proxy. The Secure Gateway views the reverse Web proxy as a man in the middle that compromises the integrity of the ICA/SSL network stream. This causes the SSL handshake between the client and the Secure Gateway to fail. There are two possible solutions to correct this problem:
q

Run the Secure Gateway parallel to the reverse Web proxy Use a network address translator (NAT) in place of the reverse Web proxy

1026

Run the Secure Gateway Parallel to the Reverse Web Proxy


The Secure Gateway and the Web Interface are installed on two separate servers. The server running the Web Interface is behind the reverse Web proxy. The Secure Gateway is parallel to the reverse Web proxy.

This graphic shows the correct placement of the Secure Gateway, which is parallel to the reverse Web proxy. Placing the Secure Gateway parallel to the reverse Web proxy provides a secure solution. Security policies that are defined on the reverse Web proxy continue to affect all Secure Gateway users. To cross the Secure Gateway, users must first satisfy the reverse Web proxy and log on to the Web Interface to get a ticket from the STA. Any access control rules that are defined on the reverse Web proxy affects users who are also trying to gain entry through the Secure Gateway.

1027

Use a Network Address Translator Instead of a Reverse Web Proxy


If the reverse Web proxy is configured to forward all network traffic (not just HTTP traffic) to the combination Secure Gateway and Web Interface, the SSL connection is not terminated at the proxy and users can connect through the Secure Gateway. The following figure is an example of how different vendors refer to this type of deployment.

This graphic shows the use of a network address translator instead of a reverse Web proxy. This approach has the disadvantage that some control must be sacrificed regarding the type of traffic that is permitted to cross the proxy. Incoming traffic must be routed directly to the Secure Gateway and the Web Interface without being decrypted, authenticated, or inspected. From a security standpoint, this is not much different from exposing the Secure Gateway server directly to the Internet. There is a logical SSL tunnel between the client and the Secure Gateway.

1028

Digital Certificates and the Secure Gateway


SSL and TLS are leading Internet protocols providing security for e-commerce, Web services, and many other network functions. The SSL/TLS protocol uses cryptography to secure communications. Cryptography provides the ability to encode messages to ensure confidentiality. To establish an SSL/TLS connection, you need a digital certificate. For more information about obtaining, exporting, and installing security certificates for your operating system, consult the Microsoft TechNet library available at http://technet.microsoft.com. The SSL protocol is todays standard for securely exchanging information on the Internet. Originally developed by Netscape, the SSL protocol became crucial to the operation of the Internet. As a result, the Internet Engineering Taskforce (IETF) took over responsibility for the development of SSL as an open standard. To clearly distinguish SSL from other ongoing work, the IETF renamed SSL as TLS. The TLS protocol is the descendant of the third version of SSL; TLS 1.0 is identical to SSL 3.1. Some organizations, including U.S. government organizations, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography. FIPS (Federal Information Processing Standard) 140 is a standard for cryptography.

Understanding SSL and TSL


The SSL/TLS protocol allows sensitive data to be transmitted over public networks such as the Internet by providing the following important security features: Authentication A client can determine a servers identity and ascertain that the server is not an impostor. Optionally, a server can also authenticate the identity of the client requesting connections. Privacy Data passed between the client and server is encrypted so that if a third party intercepts messages, it cannot unscramble the data. Data integrity The recipient of encrypted data knows if a third party corrupts or modifies that data.

1029

Understanding Cryptography
Cryptography is also used to authenticate the identity of a message source and to ensure the integrity of its contents. A message is sent using a secret code called a cipher. The cipher scrambles the message so that it cannot be understood by anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message, thus ensuring confidentiality. Cryptography allows the sender to include special information in the message that only the sender and receiver know. The receiver can authenticate the message by reviewing the special information. Cryptography also ensures that the contents of a message are not altered. To do this, the sender includes a cryptographic operation called a hash function in the message. A hash function is a mathematical representation of the information, similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates the hash function. If the receivers hash function value is the same as the senders, the integrity of the message is assured.

1030

Types of Cryptography
There are two main types of cryptography:
q

Secret key cryptography Public key cryptography

In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information. Secret key cryptography is also known as symmetric key cryptography. With this type of cryptography, both the sender and the receiver know the same secret code, called the key. Messages are encrypted by the sender using the key and decrypted by the receiver using the same key. This method works well if you are communicating with only a limited number of people, but it becomes impractical to exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the secret key securely. Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public key cryptography, keys work in pairs of matched public and private keys. The public key can be freely distributed without compromising the private key, which must be kept secret by its owner. Because these keys work only as a pair, encryption initiated with the public key can be decrypted only with the corresponding private key. The following example illustrates how public key cryptography works:
q

Ann wants to communicate secretly with Bill. Ann encrypts her message using Bills public key (which Bill made available to everyone) and Ann sends the scrambled message to Bill. When Bill receives the message, he uses his private key to unscramble the message so that he can read it. When Bill sends a reply to Ann, he scrambles the message using Anns public key. When Ann receives Bills reply, she uses her private key to unscramble his message.

The major advantage asymmetric encryption offers over symmetric key cryptography is that senders and receivers do not have to communicate keys up front. Provided the private key is kept secret, confidential communication is possible using the public keys.

1031

Combining Public Key and Secret Key Cryptography


The main disadvantage of public key cryptography is that the process of encrypting a message, using the very large keys common to PKI, can cause performance problems on all but the most powerful computer systems. For this reason, public key and secret key cryptography are often combined. The following example illustrates how this works:
q

Bill wants to communicate secretly with Ann, so he obtains Anns public key. He also generates random numbers to use just for this session, known as a session key. Bill uses Anns public key to scramble the session key. Bill sends the scrambled message and the scrambled session key to Ann. Ann uses her private key to unscramble Bills message and extract the session key.

When Bill and Ann successfully exchange the session key, they no longer need public key cryptographycommunication can take place using just the session key. For example, public key encryption is used to send the secret key; when the secret key is exchanged, communication takes place using secret key encryption. This solution offers the advantages of both methodsit provides the speed of secret key encryption and the security of public key encryption.

1032

Understanding Digital Certificates and Certificate Authorities


The ISO X.509 protocol defines a mechanism called a certificate that contains a users public key that is signed by a trusted entity called a certificate authority (CA). Certificates contain information used to establish identities over a network in a process called authentication. Like a drivers licence, a passport, or other forms of personal identification, certificates enable servers and clients to authenticate each other before establishing a secure connection. Certificates are valid only for a specified time period; when a certificate expires, a new one must be issued. The issuing authority can also revoke certificates. To establish an SSL/TLS connection, you require a server certificate at one end of the connection and a root certificate of the CA that issued the server certificate at the other end. Server certificate A server certificate certifies the identity of a server. The type of digital certificate that is required by the Secure Gateway is called a server certificate Root certificate A root certificate identifies the CA that signed the server certificate. The root certificate belongs to the CA. This type of digital certificate is required by a user device to verify the server certificate. When establishing an SSL connection with a Web browser on a user device, the server sends its certificate to the client. When receiving a server certificate, the Web browser (for example, Internet Explorer) on the user device checks to see which CA issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the Web browser prompts the user to accept or decline the certificate (effectively accepting or declining the ability to access this site). When User A receives a message from User B, the locally stored information about the CA that issued the certificate is used to verify that it did indeed issue the certificate. This information is a copy of the CAs own certificate and is referred to as a root certificate. Certificates generally have a common format, usually based on International Telecommunication Union (ITU) standards. The certificate contains information that includes the: Issuer The organization that issues the certificates. Subject 1033

Understanding Digital Certificates and Certificate Authorities The party that is identified by the certificate. Period of validity The certificates start date and expiration date Public key The subjects public key used to encrypt data. Issuers signature The CAs digital signature on the certificate used to guarantee its authenticity. A number of companies and organizations currently act as CAs, including VeriSign, Baltimore, Entrust, and their respective affiliates.

1034

Certificate Chains
Some organizations delegate the responsibility for issuing certificates to resolve the issue of geographical separation between organization units, or that of applying different issuing policies to different sections of the organization. Responsibility for issuing certificates can be delegated by setting up subordinate CAs. The X.509 standard includes a model for setting up a hierarchy of CAs. In this model, the root CA is at the top of the hierarchy and has a self-signed certificate. The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates signed by the subordinate CAs.

This illustration shows the hierarchical structure of a typical digital certificate chain. CAs can sign their own certificates (that is, they are self-signed) or they can be signed by another CA. If the certificate is self-signed, they are called root CAs. If they are not self-signed, they are called subordinate or intermediate CAs.

1035

Certificate Chains If a server certificate is signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two certificates: the end entity certificate and the root CA. If a user or server certificate is signed by an intermediate CA, the certificate chain is longer. The following figure shows the first two elements are the end entity certificate (in this case, gwy01.company.com) and the certificate of the intermediate CA, in that order. The intermediate CAs certificate is followed by the certificate of its CA. This listing continues until the last certificate in the list is for a root CA. Each certificate in the chain attests to the identity of the previous certificate.

This illustration shows a typical digital certificate chain.

1036

Certificate Revocation Lists


From time to time, CAs issue certificate revocation lists (CRLs). CRLs contain information about certificates that can no longer be trusted. For example, suppose Ann leaves XYZ Corporation. The company can place Anns certificate on a CRL to prevent her from signing messages with that key. Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use. Before you trust a public key, make sure that the certificate does not appear on a CRL.

1037

Deciding Where to Obtain Certificates


When you identify the number and type of certificates required for your Secure Gateway deployment, decide where to obtain the certificates. Where you choose to obtain certificates depends on a number of factors, including:
q

Whether or not your organization is a CA, which is likely to be the case only in very large corporations Whether or not your organization already established a business relationship with a public CA The fact that the Windows operating system includes support for many public Certificate Authorities The cost of certificates or the reputation of a particular public CA

If Your Organization Is its Own Certificate Authority


If your organization is running its own CA, you must determine whether or not it is appropriate to use your company's certificates for the purpose of securing communications in your Secure Gateway installation. Citrix recommends that you contact your corporate security department to discuss this and to get further instructions about how to obtain certificates. If you are unsure if your organization is a CA, contact your corporate security department or your organization's security expert.

If Your Organization Is Not its Own Certificate Authority


If your organization is not running its own CA, you need to obtain your certificates from a public CA such as VeriSign. Obtaining a digital certificate from a public CA involves a verification process in which: Obtaining a digital certificate from a public CA involves a verification process in which:

Your organization provides corporate information so the CA can verify that your organization is who it claims to be. The verification process may involve other departments in your organization, such as accounting, to provide letters of incorporation or similar legal documents. Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA.

1038

Deciding Where to Obtain Certificates


q

The CA verifies your organization as a purchaser; therefore your purchasing department is likely to be involved. You provide the CA with contact details of suitable individuals whom they can call if there are queries.

1039

Obtaining and Installing Server Certificates


Your organizations security expert should have a procedure for obtaining server certificates. Instructions for generating server certificates using various Web server products are available from the Web sites of popular CAs such as Verisign and others. Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test the Secure Gateway before deploying it in a production environment. If you do this, be aware that you need to download matching Test Root Certificates that must be installed on each user device that connects through the Secure Gateway. To provide secure communications (SSL/TLS), a server certificate is required on the server running the Secure Gateway. The steps required to obtain and install a server certificate on a server running the Secure Gateway are as follows: 1. Create a certificate request. 2. Apply for a server certificate from a valid CA. 3. Save the certificate response file sent by the CA as an X.509 Certificate (.cer format). 4. Import the X.509 certificate into the certificate store. 5. Export the certificate into Personal Information Exchange format (.pfx, also called PKCS #12). 6. Install the server certificate on the server running the Secure Gateway. Consider the following before obtaining and installing certificates:
q

When requesting a certificate, the greater the bit length, the higher the security. Citrix recommends that you select 1024 or higher. If you are specifying a bit length higher than 1024, ensure that the clients you deploy support it. For information about supported encryption strength on a user device, see the appropriate user devices documentation. Part of an initial request for a certificate involves generating a public/private key pair that is stored on your server. Because the public key from this key pair is encoded in your certificate, loss of the key pair on your server renders your certificate worthless. Make sure you back up your key pair data on another computer, a floppy disk, or both. Typically, the procedure for generating a key pair requires you to specify a password to encrypt the pair. The password prevents any person with access to the keypair data from extracting the private key and using it to decrypt SSL/TLS traffic to and from your server. Ensure that you store the password in a secure location. When you import a certificate, you copy the certificate from a file that uses a standard certificate storage format to a certificate store for your computer account. Use the

1040

Obtaining and Installing Server Certificates proper procedures or wizard as specified by your operating system to place certificates in the correct store on local computers. Do not attempt to import the server certificate file by double-clicking or right-clicking the certificate file within Windows Explorer. Doing so places the certificate in the certificate store for the current user.

1041

Obtaining and Installing Root Certificates


A root certificate must be present on every user device that connects to the secure network through the Secure Gateway. Support for most trusted root authorities is already built into the Windows operating system and Internet Explorer. Therefore, there is no need to obtain and install root certificates on the user device if you are using these CAs. However, if you decide to use a different CA, you need to obtain and install the root certificates yourself.

Obtaining a Root Certificate from a CA


Root certificates are available from the same CAs that issue server certificates. Well-known or trusted CAs include Verisign, Baltimore, Entrust, and their respective affiliates. Certificate authorities tend to assume that you already have the appropriate root certificates (this is because most Web browsers have root certificates built-in) so you need to specifically request the root certificate. Several types of root certificates are available. For example, VeriSign has approximately 12 root certificates that they use for different purposes, so it is important to ensure that you obtain the correct root certificate from the CA.

1042

Support for Wildcard Certificates with the Secure Gateway


The Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. The wildcard certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as http://www1.citrix.com or http://www2.citrix.com. The use of a wildcard certificate allows several Web sites to be covered by a single certificate.

1043

Provide Smart and Secure Application Access


Secure Application Access is provided by Citrix Access Gateway. For information about Access Gateway, see the Access Gateway node in eDocs.

1044

Monitor Virtual Services


Some Service Monitoring for XenApp (EdgeSight) product documentation is not yet in Citrix eDocs (this site) and still resides in the Citrix Knowledge Center. We are in the process of transitioning product documentation to Citrix eDocs. For links to documentation in the Citrix Knowledge Center, go to: http://support.citrix.com/productdocs/ Important: When you click this link you leave eDocs. We recommend you bookmark eDocs so you can easily return to it.

1045

SmartAuditor
SmartAuditor allows you to record the on-screen activity of any users session, over any type of connection, from any server running XenApp. SmartAuditor records, catalogs, and archives sessions for retrieval and playback. SmartAuditor uses flexible policies to trigger recordings of XenApp sessions automatically. This enables IT to monitor and examine user activity of applications such as financial operations and healthcare patient information systems demonstrating internal control, thus ensuring regulatory compliance and successful security audits. Similarly, SmartAuditor also aids in technical support by speeding problem identification and time-to-resolution.

Benefits
Enhanced auditing for regulatory compliance. SmartAuditor allows organizations to record on-screen user activity for applications that deal with sensitive information. This is especially critical in regulated industries such as health care and finance, where compliance with personal information security rules is paramount. Trading applications and patient information systems are two prime examples. Powerful activity monitoring. SmartAuditor captures and archives screen updates, including mouse activity and the visible output of keystrokes in secured video recordings to provide a record of activity for specific users, applications, and servers. Organizations that use SmartAuditor have a better chance of proving criminal intent, where it exists, by using video evidence combined with traditional text-based eDiscovery tools. Faster problem resolution. When users call with a problem that is hard to reproduce, help desk support staff can enable recording of user sessions. When the issue recurs, SmartAuditor provides a time-stamped visual record of the error, which can then be used for faster troubleshooting.

1046

System Requirements for SmartAuditor


SmartAuditor is available in English, French, German, Japanese, Spanish, and simplified Chinese. All SmartAuditor components that connect to each other must be the same language edition; mixed-language installations are not supported. The English-language edition of SmartAuditor is supported on English, Russian, traditional Chinese, and Korean operating systems. The French, German, Japanese, Spanish, and simplified Chinese editions of SmartAuditor are supported on operating systems in their respective languages.

SmartAuditor Administration Components


The SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, and SmartAuditor Policy Console) can be installed on a single server or on different servers.

SmartAuditor Database
Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2 Microsoft Windows Server 2003 with Service Pack 2 Microsoft Windows 2000 with Service Pack 4

Requirements:
q

Microsoft SQL Server 2008 R2 (Enterprise and Express editions), Microsoft SQL Server 2008 (Enterprise and Express editions), or Microsoft SQL Server 2005 (Enterprise and Express editions) with Service Pack 2 .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4

SmartAuditor Server
Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2

Requirements:

1047

Record
q

.NET Framework Version 3.5. If the SmartAuditor Server uses HTTPS as its communications protocol, SSL. SmartAuditor uses HTTPS by default, which Citrix recommends. Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled.

SmartAuditor Policy Console


Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2 Microsoft Windows 7 Microsoft Windows Vista

Requirements:
q

Install the Microsoft IIS Management Console manually before installing the SmartAuditor Policy Console. Microsoft IIS Management Console

SmartAuditor Agent
Install the SmartAuditor Agent on every XenApp server on which you want to record sessions. Requirements:
q

XenApp 6.5 for Windows Server 2008 R2 Platinum edition or XenApp 6 for Windows Server 2008 R2 Platinum edition server software Microsoft Windows Server 2008 R2 with Service Pack 1 or Microsoft Windows Server 2008 R2 .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4 Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled

SmartAuditor Player
Supported Windows operating systems:
q

Microsoft Windows XP

1048

Record
q

Microsoft Windows Vista Windows 7

The SmartAuditor Player requires .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4. The update contained in Microsoft Knowledge Base article 961118 is required if you are using .NET Framework Version 3.5 and installing the SmartAuditor Player on the same computer as a XenApp server. Install the update after installing .NET Framework. For optimal results, install SmartAuditor Player on a workstation with:
q

Screen resolution of 1024 x 768 Color depth of at least 32-bit Memory: 1GB RAM (minimum)additional RAM can improve performance on large files

1049

System Requirements for SmartAuditor


SmartAuditor is available in English, French, German, Japanese, Spanish, and simplified Chinese. All SmartAuditor components that connect to each other must be the same language edition; mixed-language installations are not supported. The English-language edition of SmartAuditor is supported on English, Russian, traditional Chinese, and Korean operating systems. The French, German, Japanese, Spanish, and simplified Chinese editions of SmartAuditor are supported on operating systems in their respective languages.

SmartAuditor Administration Components


The SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, and SmartAuditor Policy Console) can be installed on a single server or on different servers.

SmartAuditor Database
Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2 Microsoft Windows Server 2003 with Service Pack 2 Microsoft Windows 2000 with Service Pack 4

Requirements:
q

Microsoft SQL Server 2008 R2 (Enterprise and Express editions), Microsoft SQL Server 2008 (Enterprise and Express editions), or Microsoft SQL Server 2005 (Enterprise and Express editions) with Service Pack 2 .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4

SmartAuditor Server
Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2

Requirements:

1050

System Requirements for SmartAuditor


q

.NET Framework Version 3.5. If the SmartAuditor Server uses HTTPS as its communications protocol, SSL. SmartAuditor uses HTTPS by default, which Citrix recommends. Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled.

SmartAuditor Policy Console


Supported Windows operating systems:
q

Microsoft Windows Server 2008 R2 with Service Pack 1 Microsoft Windows Server 2008 R2 Microsoft Windows 7 Microsoft Windows Vista

Requirements:
q

Install the Microsoft IIS Management Console manually before installing the SmartAuditor Policy Console. Microsoft IIS Management Console

SmartAuditor Agent
Install the SmartAuditor Agent on every XenApp server on which you want to record sessions. Requirements:
q

XenApp 6.5 for Windows Server 2008 R2 Platinum edition or XenApp 6 for Windows Server 2008 R2 Platinum edition server software Microsoft Windows Server 2008 R2 with Service Pack 1 or Microsoft Windows Server 2008 R2 .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4 Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled

SmartAuditor Player
Supported Windows operating systems:
q

Microsoft Windows XP

1051

System Requirements for SmartAuditor


q

Microsoft Windows Vista Windows 7

The SmartAuditor Player requires .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4. The update contained in Microsoft Knowledge Base article 961118 is required if you are using .NET Framework Version 3.5 and installing the SmartAuditor Player on the same computer as a XenApp server. Install the update after installing .NET Framework. For optimal results, install SmartAuditor Player on a workstation with:
q

Screen resolution of 1024 x 768 Color depth of at least 32-bit Memory: 1GB RAM (minimum)additional RAM can improve performance on large files

1052

Example Usage Scenarios


Monitoring acceptable use of resources. Ray, the IT Manager in a local firm, needs to know whether employees are following the acceptable use policies and other business controls he instituted to regulate access to resources published using XenApp. Until now he had no way of measuring acceptable usage and had to trust that users of mission-critical applications were not misusing their privileges. He now uses SmartAuditor to record user sessions and has his surveillance officer review recorded sessions to establish cases of misuse. Monitoring specific users or groups. John, a surveillance officer at a stockbroking firm, needs to monitor a group of stockbrokers to observe particularly sensitive, high-value transactions. He uses SmartAuditor to record sessions for this group of stockbrokers. Investigating suspected violations. Lisa is Johns colleague at the stockbroking firm. She is a compliance officer who is tasked to investigate suspected compliance violations. She uses SmartAuditor to record all XenApp sessions for a particular employee. Monitoring access scenarios. Marcus, the IT Manager at an insurance company, needs to monitor access to specific applications. He uses SmartAuditor to record all sessions that involve use of a particular published application. Technical support and troubleshooting applications.Victor, a Support Engineer at a leading software vendor based in the United States, is often called on to resolve application issues at remote customer sites in Asia. He uses SmartAuditor to record user sessions and reviews recorded sessions to understand the sequence of events that led the application to fail. His colleagues in the development team are also able to deploy new versions of applications for usability testing at focus groups. User sessions are recorded and the team can understand usability issues that exist during a review of recorded sessions. Training applications. Jim is a professor in the Computer Science department of a large university. He uses SmartAuditor to record students accessing a collaborative development environment. Based on their interactions with the environment, he can identify the areas in which they need to improve and can provide appropriate feedback.

1053

Getting Started with SmartAuditor


After you perform the following steps, you can begin recording and reviewing XenApp sessions. 1. Become familiar with the SmartAuditor components. 2. Select the deployment scenario for your environment. 3. Verify the installation requirements. 4. Install SmartAuditor. 5. Configure the SmartAuditor components to permit recording and viewing of sessions. SmartAuditor consists of five components:
q

SmartAuditor Agent. A component installed on each XenApp server to enable recording. It is responsible for recording session data. SmartAuditor Server. A server that hosts:
q

The Broker. An IIS 6.0+ hosted Web application that handles the search queries and file download requests from the SmartAuditor Player, handles policy administration requests from the SmartAuditor Policy Console, and evaluates recording policies for each XenApp session.

The Storage Manager. A Windows service that manages the recorded session files received from each SmartAuditor-enabled computer running XenApp. SmartAuditor Player. A user interface that users access from a workstation to play recorded XenApp session files.
q

This illustration shows the SmartAuditor components and their relationship with each other: In the deployment example illustrated here, the SmartAuditor Agent, SmartAuditor Server, SmartAuditor Database, SmartAuditor Policy Console, and SmartAuditor Player all reside behind a security firewall. The SmartAuditor Agent is installed on a XenApp server. A second server hosts the SmartAuditor Policy Console, a third server acts as the SmartAuditor Server, and a fourth server hosts the SmartAuditor Database. The SmartAuditor Player is installed on a workstation. A client device outside the firewall communicates with the XenApp server on which the SmartAuditor Agent is installed. Inside the firewall, the SmartAuditor Agent, SmartAuditor Policy Console, SmartAuditor Player, and SmartAuditor Database all communicate with the SmartAuditor Server.

1054

Getting Started with SmartAuditor

1055

Planning Your Deployment


Depending upon your environment, you can deploy the SmartAuditor components in different scenarios. A SmartAuditor deployment does not have to be limited to a single farm. With the exception of the SmartAuditor Agent, all components are independent of the server farm. For example, you can configure multiple farms to use a single SmartAuditor Server. Alternatively, if you have a large farm with many agents and plan to record many graphically intense applications (for example, AutoCAD applications), or you have many sessions to record, a SmartAuditor Server can experience a high performance demand. To alleviate performance issues, you can install multiple SmartAuditor Servers on different computers and point the SmartAuditor Agents to the different computers. Keep in mind that an agent can point to only one server at a time.

Suggested Deployment Scenarios


These are the two suggested configurations for a SmartAuditor deployment:
q

Deploy the SmartAuditor Agent on single XenApp server. Deploy the SmartAuditor Agent on multiple XenApp servers in a server farm.

Deployment 1: Single XenApp Server


Use this type of deployment for recording sessions from one XenApp server. The SmartAuditor Agent is installed on a XenApp server. Typically, the SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, SmartAuditor Policy Console) are installed on another server, but they can be installed on the same server as the SmartAuditor Agent. These servers are in a data center behind a security firewall. The SmartAuditor Player is installed on a workstation that is behind the firewall, but not in the data center. Outside the firewall, in an unsecured network environment, are client devices, such as a workstation, a PDA, and a laptop computer.

1056

Planning Your Deployment

Note: For this deployment scenario, ensure that you install SQL Server on the same computer as the SmartAuditor Server.

Deployment 2: Server Farm Deployment


Use this type of deployment for recording sessions for one or more farms.The SmartAuditor Agent is installed on each XenApp server in a farm. The farm resides in a data center behind a security firewall. The SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, SmartAuditor Policy Console) are installed on other servers and the SmartAuditor Player is installed on a workstation, all behind the firewall but not in the data center. Outside the firewall, in an unsecured network environment, are XenApp clients, such as a workstation, a PDA, and a laptop computer.

1057

Planning Your Deployment

1058

Security Recommendations
SmartAuditor is designed to be deployed within a secure network and accessed by administrators, and as such, is secure. Out-of-the-box deployment is designed to be simple and security features such as digital signing and encryption can be configured optionally. Communication between SmartAuditor components is achieved through Internet Information Services (IIS) and Microsoft Message Queuing (MSMQ). IIS provides the web services communication link between each SmartAuditor component. MSMQ provides a reliable data transport mechanism for sending recorded session data from the SmartAuditor Agent to the SmartAuditor Server. Consider these security recommendations when planning your deployment:
q

Isolate servers running SmartAuditor components on a separate subnet or domain. Protect the recorded session data from users accessing other servers by installing a firewall between the SmartAuditor Server and other servers. Ensure servers running SmartAuditor components are physically secure. If possible, lock these computers in a secure room to which only authorized personnel can gain direct access. Strictly limit who is authorized to make recording policy changes and view recorded sessions. Install digital certificates, use the SmartAuditor file signing feature, and set up SSL communications in IIS. Use playback protection. Playback protection is a SmartAuditor feature that encrypts recorded files before they are downloaded to the SmartAuditor Player. By default, this option is enabled and is in the SmartAuditor Server Properties.

1059

Installing Certificates
On the computer on which the SmartAuditor Server is installed, the IIS Web server sends its server certificate to the client when establishing an SSL connection from the SmartAuditor Agent, SmartAuditor Player, or SmartAuditor Policy Console. When receiving a server certificate, the SmartAuditor Agent, SmartAuditor Player, or Policy Console determines which Certificate Authority (CA) issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the certificate is declined and an error is logged in the Application Event log for the SmartAuditor Agent or an error message appears to the user in the SmartAuditor Player or Policy Console. A server certificate is installed by gathering information about the server and requesting a CA to issue a certificate for that server. You must specify the correct information when requesting a server certificate and ensure the server name is specified correctly. If the fully qualified domain name (FQDN) is used for connecting clients (SmartAuditor Agent, SmartAuditor Player, and Policy Console) the certificate information specified to the CA must use the FQDN of the server rather than the NetBIOS name. If you specify NetBIOS names, do not specify the FQDN when requesting a server certificate. Install the server certificate into the local servers certificate store. Install the issuing CA certificate on each connecting client. Your organization may have a private CA that issues server certificates that you can use with SmartAuditor. If you are using a private CA, ensure each client device has the issuing CA certificate installed. Refer to Microsoft documentation about using certificates and certificate authorities. Alternatively, some companies and organizations currently act as CAs, including VeriSign, Baltimore, Entrust, and their respective affiliates. All certificates have an expiration date defined by the CA. To find the expiration date, check the properties of the certificate. Ensure certificates are renewed before the expiration date to prevent any errors occurring in SmartAuditor. The SmartAuditor installation is configured to use HTTPS by default and requires that you configure the default Web site with a server certificate issued from a CA. If you need instructions for installing server certificates in IIS, consult your IIS documentation.

1060

Scalability Considerations
Installing and running SmartAuditor requires few additional resources beyond what is necessary to run XenApp. However, if you plan to use SmartAuditor to record a large number of sessions or if the sessions you plan to record will result in large session files (for example, graphically intense applications), consider the performance of your system when planning your SmartAuditor deployment.

Hardware Recommendations
Consider how much data you will be sending to each SmartAuditor Server and how quickly the servers can process and store this data. The rate at which your system can store incoming data must be higher than the data input rate. To estimate your data input rate, multiply the number of sessions recorded by the average size of each recorded session and divide by the period of time for which you are recording sessions. For example, you might record 5,000 Microsoft Outlook sessions of 20MB each over an 8-hour work day. In this case, the data input rate is approximately 3.5MBps. (5,000 sessions times 20MB divided by 8 hours, divided by 3,600 seconds per hour.) You can improve performance by optimizing the performance of a single SmartAuditor Server or by installing multiple SmartAuditor Servers on different computers.

Disk and Storage Hardware


Disk and storage hardware are the most important factors to consider when planning a SmartAuditor deployment. The write performance of your storage solution is especially important. The faster data can be written to disk, the higher the performance of the system overall. Storage solutions suitable for use with SmartAuditor include a set of local disks controlled as RAID arrays by a local disk controller or by an attached Storage Area Network (SAN). Note: SmartAuditor should not be used with Network-Attached Storage (NAS), due to performance and security problems associated with writing recording data to a network drive. For a local drive set up, a disk controller with built-in cache memory enhances performance. A caching disk controller must have a battery backup facility to ensure data integrity in case of a power failure.

Network Capacity
A 100Mbps network link is suitable for connecting a SmartAuditor Server. A gigabit Ethernet connection may improve performance, but does not result in 10 times greater performance than a 100Mbps link.

1061

Scalability Considerations Ensure that network switches used by SmartAuditor are not shared with third-party applications that may compete for available network bandwidth. Ideally, network switches are dedicated for use with the SmartAuditor Server.

Computer Processing Capacity


Consider the following specification for the computer on which a SmartAuditor Server is installed:

A dual CPU or dual-core CPU is recommended A 64-bit processor architecture is recommended, but an x86 processor type is also suitable 2GB to 4GB of RAM is recommended

Exceeding these specifications does not significantly improve performance.

Deploying Multiple SmartAuditor Servers


If a single SmartAuditor Server does not meet your performance needs, you can install more SmartAuditor Servers on different computers. In this type of deployment, each SmartAuditor Server has its own dedicated storage, network switches, and database. To distribute the load, point the SmartAuditor Agents in your deployment to different SmartAuditor Servers.

Database Scalability
The SmartAuditor Database requires Microsoft SQL Server 2005 or Microsoft SQL Server 2008. The volume of data sent to the database is very small because the database stores only metadata about the recorded sessions. The files of the recorded sessions themselves are written to a separate disk. Typically, each recorded session requires only about 1KB of space in the database, unless the SmartAuditor Event API is used to insert searchable events into the session. The Express Editions of Microsoft SQL Server 2005 and Microsoft SQL Server 2008 imposes a database size limitation of 4GB. At 1KB per recording session, the database can catalog about four million sessions. Other editions of Microsoft SQL Server have no database size restrictions and are limited only by available disk space. As the number of sessions in the database increases, performance of the database and speed of searches diminishes only negligibly. If you are not making customizations through the SmartAuditor Event API, each recorded session generates four database transactions: two when recording starts, one when the user logs onto the session being recorded, and one when recording ends. If you used the SmartAuditor Event API to customize sessions, each searchable event recorded generates one transaction. Because even the most basic database deployment can handle hundreds of transactions per second, the processing load on the database is unlikely to be stressed. The impact is light enough that the SmartAuditor Database can run on the same SQL Server as other databases, including the XenApp data store database. 1062

Scalability Considerations If your SmartAuditor deployment requires many millions of recorded sessions to be cataloged in the database, follow Microsoft guidelines for SQL Server scalability.

1063

Important Deployment Notes


q

To enable SmartAuditor components to communicate with each other, ensure you install them in the same domain or across trusted domains that have a transitive trust relationship. The system cannot be installed into a workgroup or across domains that have an external trust relationship. SmartAuditor does not support the clustering of two or more SmartAuditor Servers in a deployment. Due to its intense graphical nature and memory usage when playing back large recordings, Citrix does not recommend installing the SmartAuditor Player as a published application. The SmartAuditor installation is configured for SSL/HTTPS communication. Ensure that you install a certificate on the SmartAuditor Server and that the root certificate authority (CA) is trusted on the SmartAuditor components. If you install the SmartAuditor Database on a stand-alone server running SQL Server 2005 Express Edition or SQL Server 2008 Express Edition, the server must have TCP/IP protocol enabled and SQL Server Browser service running. These settings are disabled by default, but they must be enabled for the SmartAuditor Server to communicate with the database. See the Microsoft documentation for information about enabling these settings. Consider the effects of session sharing when planning your SmartAuditor deployment. Session sharing for published applications can conflict with SmartAuditor recording policy rules for published applications. SmartAuditor matches the active policy with the first published application that a user opens. After the user opens the first application, any subsequent applications opened during the same session continue to follow the policy that is in force for the first application. For example, if a policy states that only Microsoft Outlook should be recorded, the recording commences when the user opens Outlook. However, if the user opens a published Microsoft Word second (while Outlook is running), Word also is recorded. Conversely, if the active policy does not specific that Word should be recorded, and the user launches Word before Outlook (which should be recorded, according to the policy), Outlook is not recorded.

1064

Pre-Installation Checklist
Before you start the installation, ensure that you completed this list:

Step

Selected the computers on which to install each SmartAuditor component and ensured that each computer meets the hardware and software requirements for the component or components to be installed on it. If you use the SSL protocol for communication between the SmartAuditor components, install the correct certificates in your environment. Install any hotfixes required for the SmartAuditor components. The hotfixes are available from the Citrix Knowledge Center.

1065

To install SmartAuditor
Use the Autorun to install SmartAuditor components.

To install SmartAuditor Administration components


The SmartAuditor Administration components are the SmartAuditor Database, SmartAuditor Server, and the SmartAuditor Policy Console. You can choose which of these components to install on a server. 1. On the installation media, click autorun.exe. The Autorun menu launches. 2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Administration. 3. Use the installation wizard to select the SmartAuditor Administration components you want to install. 4. On the Database Configuration page:
q

If you are installing all the Administration components on the same server, accept localhost in the Accessing user account for computer or localhost field.

If you are installing the SmartAuditor Server and the SmartAuditor Database on different servers, type the name of the computer hosting the SmartAuditor Server in the following format: domain\machine-name$. Ensure that the dollar symbol ($) follows the name. 5. Follow the wizards instructions to complete the installation.
q

To install the SmartAuditor Agent


The SmartAuditor Agent must be installed on a computer running XenApp. 1. On the installation media, click autorun.exe. The Autorun menu launches. 2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Agent. 3. In the SmartAuditor Agent Configuration page, enter the name of the computer where you installed the SmartAuditor Server. 4. Follow the wizards instructions to complete the installation.

To install SmartAuditor Player


1066

To install SmartAuditor The SmartAuditor Player is installed on one or more workstations for users who view session recordings. 1. On the installation media, click autorun.exe. The Autorun menu launches. 2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Player. 3. Use the installation wizard to install SmartAuditor Player. After installing SmartAuditor, configure the components for your environment so you can record and play XenApp sessions.

To uninstall SmartAuditor
To remove SmartAuditor components from a server or workstation, use the uninstall or remove programs capability available through the Windows Control Panel.

1067

Automating Installations
To install Smart Auditor Agent on multiple servers, write a script that uses silent installation. The following command line installs the SmartAuditor Agent and creates a log file to capture the install information.

msiexec /i SmartAuditorAgent.msi smartauditorservername=yourservername smartauditorbrokerprotocol=yourbrokerprotocol smartauditorbrokerport=yourbrokerport /l*v yourinstallationlog /q where: yourservername is the NetBIOS name or FQDN of the computer hosting the SmartAuditor Server. If not specified, this value defaults to localhost. yourbrokerprotocol is either HTTP or HTTPS, and represents the protocol that SmartAuditor Agent uses to communicate with SmartAuditor Broker; this value defaults to HTTPS if not specified. yourbrokerport is an integer representing the port SmartAuditor Agent uses to communicate with SmartAuditor Broker. If not specified, this value defaults to zero, which directs SmartAuditor Agent to use the default port number for the selected protocol: 80 for HTTP or 443 for HTTPS. /l*v specifies verbose mode logging yourinstallationlog is the location of the setup log file created. /q specifies quiet mode.

1068

To configure SmartAuditor to play and record sessions


After you install the SmartAuditor components, perform these steps to configure SmartAuditor to record XenApp sessions and allow users to view them:
q

Authorize users to play recordings Change the active recording policy to one that records sessions Configure SmartAuditor Player to connect to the SmartAuditor Server

To authorize users to play recorded sessions


When you install SmartAuditor, no users have permission to play recorded sessions. You must assign permission to each user, including the administrator. 1. Log on as administrator to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Authorization Console. 3. In the SmartAuditor Authorization Console, select Player. 4. Add the users and groups you want to authorize to view recorded sessions.

To set the active recording policy to record sessions


The active recording policy specifies session recording behavior on all XenApp servers that have SmartAuditor Agent installed and connected to the SmartAuditor Server. When you install SmartAuditor, the active recording policy is Do not record. Sessions cannot be recorded until you change the active recording policy. 1. Log on as administrator to the server where the SmartAuditor Policy Console is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. 3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the computer hosting the SmartAuditor Server, protocol, and port are correct.

1069

To configure SmartAuditor to play and record sessions 4. In the SmartAuditor Policy Console, expand Recording Policies. This displays the recording policies available when you install SmartAuditor, with a check mark indicating which policy is active:
q

Do not record. This is the default policy. If you do not specify another policy, no sessions are recorded. Record everyone with notification. If you choose this policy, all sessions are recorded. A pop-up window appears notifying the user that recording is occurring.

Record everyone without notification. If you choose this policy, all sessions are recorded. Users are unaware that they are being recorded. 5. Select the policy you want to make the active policy.
q

6. From the menu bar, choose Action > Activate Policy.

Note: SmartAuditor allows you to create your own recording policy. When you create recording policies, they appear in the Recording Policies folder within the SmartAuditor Policy Console.

To configure SmartAuditor Player


Before a SmartAuditor Player can play sessions, you must configure it to connect to the SmartAuditor Server that stores the recorded sessions. Each SmartAuditor Player can be configured with the ability to connect to multiple SmartAuditor Servers, but can connect to only one SmartAuditor Server at a time. If the Player is configuring with the ability to connect to multiple SmartAuditor Servers, users can change which SmartAuditor Server the Player connects to by selecting a check box. 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options. 4. In the Connections tab, click Add. 5. In the Hostname field, type the name or Internet protocol (IP) address of the computer hosting the SmartAuditor Server. 6. If you want to configure the SmartAuditor Player with the ability to connect to more than one SmartAuditor Server, repeat Steps 4 and 5 for each SmartAuditor Server. 7. Ensure that the check box for the SmartAuditor Server you want to connect to is selected.

1070

Granting Access Rights to Users


Note: For security reasons, grant users only the rights they need to perform specific functions, such as viewing recorded sessions. You grant rights to SmartAuditor users by assigning them to roles using the SmartAuditor Authorization Console on the SmartAuditor Server. SmartAuditor users have three roles:

Player. Grants the right to view recorded XenApp sessions. There is no default membership in this role. PolicyQuery. Allows the servers hosting the SmartAuditor Agent to request recording policy evaluations. By default, authenticated users are members of this role. Policy Administrator. Grants the right to view, create, edit, delete, and enable recording policies. By default, administrators of the computer hosting the SmartAuditor Server are members of this role.

SmartAuditor supports users and groups defined in Active Directory.

To assign users to roles


1. Log on to computer hosting the SmartAuditor Server, as administrator or as a member of the Policy Administrator role. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Authorization Console. 3. Select the role to which you want to assign users. 4. Choose Action > Assign Windows Users and Groups. 5. Add the users and groups. Any changes made to the console take effect during the update that occurs once every minute.

1071

Creating and Activating Recording Policies


Use the SmartAuditor Policy Console to create and activate policies that determine which sessions are recorded. You can activate system policies available when SmartAuditor is installed or create and activate your own custom policies. SmartAuditor system policies apply a single rule to all users, published applications, and servers. Custom policies specifying which users, published applications, and servers are recorded. The active policy determines which sessions are recorded. Only one policy is active at a time.

1072

Using System Policies


SmartAuditor provides these system policies:
q

Do not record. If you choose this policy, no sessions are recorded. This is the default policy; if you do not specify another policy, no sessions are recorded. Record everyone with notification. If you choose this policy, all sessions are recorded. A pop-up window appears notifying the user that recording is occurring. Record everyone without notification. If you choose this policy, all sessions are recorded. Users are unaware that they are being recorded.

System policies cannot be modified or deleted.

1073

Creating Custom Recording Policies


When you create your own policy, you make rules to specify which users and groups, published applications, and servers have their sessions recorded. A wizard within the SmartAuditor Policy Console helps you create rules. For each rule you create, you specify a recording action and a rule critera. The recording action applies to sessions that meet the rule criteria. For each rule, choose one recording action:
q

Do not record. (Choose Disable session recording within the rules wizard.) This recording action specifies that sessions that meet the rule criteria are not recorded. Record with notification. (Choose Enable session recording with notification within the rules wizard.) This recording action specifies that sessions that meet the rule criteria are recorded. A pop-up window appears notifying the user that recording is occurring. Record without notification. (Choose Enable session recording without notification within the rules wizard.) This recording action specifies that sessions that meet the rule criteria are recorded. Users are unaware that they are being recorded.

For each rule, choose at least one of the following to create the rule criteria:
q

Users or Groups. You create a list of users or groups to which the recording action of the rule applies. Published Applications. You create a list of published applications to which the recording action of the rule applies. Within the rules wizard, choose the XenApp farm or farms on which the applications are available. Applications Servers. You create a list of XenApp servers to which the recording action of the rule applies. Within the rules wizard, choose the XenApp farm or farms where the servers reside.

When you create more than one rule in a recording policy, some sessions may match the criteria for more than one rule. In these cases, the rule with the highest priority is applied to the session. The recording action of a rule determines its priority:
q

Rules with the Do not record action have the highest priority Rules with the Record with notification action have the next highest priority Rules with the Record without notification action have the lowest priority

Some sessions may not meet any rule criteria in a recording policy. For these sessions, the recording action of the policies fallback rule applies. The recording action of the fallback rule is always Do not record. The fallback rule cannot be modified or deleted.

1074

Creating Custom Recording Policies

Using Active Directory Groups


SmartAuditor allows you to use Active Directory groups when creating policies. Using Active Directory groups instead of individual users simplifies creation and management of rules and policies. For example, if users in your companys finance department are contained in an Active Directory group named Finance, you can create a rule that applies to all members of this group by selecting the Finance group within the rules wizard when creating the rule.

White Listing Users


You can create SmartAuditor policies that ensure that the sessions of some users in your organization are never recorded. This is called white listing these users. White listing is useful for users who handle privacy-related information or when your organization does not want to record the sessions of a certain class of employees. For example, if all managers in your company are members of an Active Directory group named Executive, you can ensure that these users sessions are never recorded by creating a rule that disables session recording for the Executive group. While the policy containing this rule is active, no sessions of members of the Executive group are recorded. The sessions of other members of your organization are sessions recorded based on other rules in the active policy.

1075

To create a new policy


Note: When using the rules wizard, you may be prompted to click on underlined value to edit when no underlined value appears. Underlined values appear only when applicable. If no underline values appear, ignore the step. 1. Log on to the server where SmartAuditor Policy Console is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. 3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor Server, protocol, and port are correct. Click OK. 4. In the SmartAuditor Policy Console, select Recording Policies. 5. From the menu bar, choose Action > Add New Policy. A policy called New Policy appears in the left pane. 6. Select the new policy and choose Action > Rename from the menu bar. 7. Type a name for the policy you are about to create and press Enter or click anywhere outside the new name. 8. With the policy selected, choose Action > Add New Rule from the menu bar to launch the rules wizard. 9. Follow the instructions to create the rules for this policy.

1076

To modify a policy
1. Log on to the server where the SmartAuditor Policy Console is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. 3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor Server, protocol, and port are correct. Click OK. 4. In the SmartAuditor Policy Console, expand Recording Policies. 5. Select the policy you want to modify. The rules for the policy appear in the right pane. 6. Add a new rule, modify a rule, or delete a rule:
q

From the menu bar, choose Action > Add New Rule. If the policy is active, a pop-up window appears requesting confirmation of the action. Use the rules wizard to create a new rule. Select the rule you want to modify, right-click, and choose Properties. Use the rules wizard to modify the rule. Select the rule you want to delete, right-click, and choose Delete Rule.

1077

To delete a policy
Note: You cannot delete a system policy or a policy that is active. 1. Log on to the server where the SmartAuditor Policy Console is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. 3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor Server, protocol, and port are correct. Click OK. 4. In the SmartAuditor Policy Console, expand Recording Policies. 5. In the left pane, select the policy you want to delete. If the policy is active, you must activate another policy. 6. From the menu bar, choose Action > Delete Policy. 7. Select Yes to confirm the action.

1078

To activate a policy
1. Log on to the server where the SmartAuditor Policy Console is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. 3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor Server, protocol, and port are correct. Click OK. 4. In the SmartAuditor Policy Console, expand Recording Policies. 5. Select the policy you want to make the active policy. 6. From the menu bar, choose Action > Activate Policy.

1079

Understanding Rollover Behavior


When you activate a policy, the previously active policy remains in effect until the users session ends; however, in some cases, the new policy takes effect when the file rolls over. Files roll over when they have reached the maximum size limit. For information on maximum file sizes for recordings, see Specifying File Size for Recordings. The following table details what happens when you apply a new policy while a session is being recorded and a rollover occurs:

If the previous policy was: Do not record

And the new policy is: Any other policy

After a rollover the policy will be: No change. The new policy takes effect only when the user logs on to a new session. Recording stops. Recording continues and a notification message appears. Recording stops. Recording continues. No message appears the next time a user logs on.

Record without notification

Do not record Record with notification Do not record Record without notification

Record with notification

1080

To disable or enable recording


You install the SmartAuditor Agent on each XenApp server for which you want to record sessions. Within each agent is a setting that enables recording for the server on which it is installed. After recording is enabled, SmartAuditor evaluates the active recording policies, which determines which sessions are recorded. When you install the SmartAuditor Agent, recording is enabled. Citrix recommends that you disable SmartAuditor on servers that are not recorded because they experience a small impact on performance, even if no recording takes place.

To disable or enable recording on a server


1. Log on to the server where the SmartAuditor Agent is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. 3. Under Session recording, select or clear the Enable session recording for this XenApp server check box to specify whether or not sessions can be recorded for this server. 4. When prompted, restart the SmartAuditor Agent Service to accept the change.

Note: When you install SmartAuditor, the active policy is Do not record (no sessions are recorded on any server). To begin recording, use the SmartAuditor Policy Console to activate a different policy.

1081

To configure the connection to the SmartAuditor Server


The connection between the SmartAuditor Agent and the SmartAuditor Server is typically configured when the SmartAuditor Agent is installed. To configure this connection after SmartAuditor Agent is installed, use SmartAuditor Agent Properties. 1. Log on to the server where SmartAuditor Agent is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. 3. Click the Connections tab. 4. In the SmartAuditor Server field, type the server name or its Internet protocol (IP) address. 5. In the SmartAuditor Storage Manager message queue section, select the protocol that is used by the SmartAuditor Storage Manager to communicate and modify the default port number, if necessary. 6. In the Message life field, accept the default of 7200 seconds (two hours) or type a new value for the number of seconds each message is retained in the queue if there is a communication failure. After this period of time elapses, the message is deleted and the file is playable until the point where the data is lost. 7. In the SmartAuditor Broker section, select the communication protocol the SmartAuditor Broker uses to communicate and modify the default port number, if necessary. 8. When prompted, restart the SmartAuditor Agent Service to accept the changes.

1082

Creating Notification Messages


If the active recording policy specifies that users are notified when their sessions are recorded, a pop-up window appears displaying a notification message after users type their credentials. The following message is the default notification: Your activity with one or more of the programs you recently started is being recorded. If you object to this condition, close the programs. The user clicks OK to dismiss the window and continue the session. The default notification message appears in the language of the operating system of the computers hosting the SmartAuditor Server. You can create custom notifications in languages of your choice; however, you can have only one notification message for each language. Your users see the notification message in the language corresponding to their user preferred locale settings.

To create a new notification message


1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Notifications tab. 4. Click Add. 5. Choose the language for the message and type the new message. You can create only one message for each language. After accepting and activating, the new message appears in the Language-specific notification messages box.

1083

Enabling Custom Event Recording


SmartAuditor allows you to use third-party applications to insert custom data, known as events, into recorded sessions. These events appear when the session is viewed using the SmartAuditor Player. They are part of the recorded session file and cannot be modified after the session is recorded. For example, an event might contain the following text: User opened a browser. Each time a user opens a browser during a session that is being recorded, the text is inserted into the recording at that point. When the session is played using the SmartAuditor Player, the viewer can locate and count the times that the user opened a browser by noting the number of markers that appear in the Events and Bookmarks list in the SmartAuditor Player. To insert custom events into recordings on a server:

Use SmartAuditor Agent Properties to enable a setting on each server where you want to insert custom events. You must enable each server separately; you cannot globally enable all servers in a farm. Write applications built on the Event API that runs within each users XenApp session (to inject the data into the recording).

The SmartAuditor installation includes an event recording COM application (API) that allows you to insert text from third-party applications into a recording. You can use the API from many programming languages including Visual Basic, C++, or C#. The SmartAuditor Event API .dll is installed as part of the SmartAuditor installation. You can find it at C:\Program Files\Citrix\SmartAuditor\Agent\Bin\Interop.UserApi.dll.

To enable custom event recording on a server


1. Log on to the server where the SmartAuditor Agent is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. 3. In SmartAuditor Agent Properties, click the Recording tab. 4. Under Custom event recording, select the Allow third party applications to record custom data on this XenApp server check box.

1084

To enable or disable live session playback


Using SmartAuditor Player, you can view a session after or while it is being recorded. Viewing a session that is currently recording is similar to seeing actions happening live; however, there is actually a one to two second delay as the data propagates from the XenApp server. Some functionality is not available when viewing sessions that have not completed recording:

A digital signature cannot be assigned until recording is complete. If digital signing is enabled, you can view live playback sessions, but they are not digitally signed and you cannot view certificates until the session is completed. Playback protection cannot be applied until recording is complete. If playback protection is enabled, you can view live playback sessions, but they are not encrypted until the session is completed. You cannot cache a file until recording is complete.

By default, live session playback is enabled. 1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Playback tab. 4. Select or clear the Allow live session playback check box.

1085

To enable or disable playback protection


As a security precaution, SmartAuditor automatically encrypts recorded files before they are downloaded for viewing in the SmartAuditor Player. This playback protection prevents them from being copied and viewed by anyone other than the user who downloaded the file. The files cannot be played back on another workstation or by another user. Encrypted files are identified with an .icle extension; unencrypted files are identified with an .icl extension. The files remain encrypted while they reside in the cache on the workstation where the SmartAuditor Player is installed until they are opened by an authorized user. Citrix recommends that you use HTTPS to protect the transfer of data. By default, playback protection is enabled. 1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Playback tab. 4. Select or clear the Encrypt session recording files downloaded for playback check box.

1086

To enable and disable digital signing


If you installed certificates on the computers on which the SmartAuditor components are installed, you can enhance the security of your SmartAuditor deployment by assigning digital signatures to session recording. By default, digital signing is disabled.

To enable digital signing


1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Signing tab. 4. Browse to the certificate that enables secure communication among the computers on which the SmartAuditor components are installed.

To disable digital signing


1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Signing tab. 4. Click Clear.

1087

To specify where recordings are stored


Use SmartAuditor Server Properties to specify where recordings are stored and where archived recordings are restored. Note: To archive files or restore deleted files, use the icldb command.

To specify the location for recorded files


By default, recordings are stored in the drive:\SessionRecordings directory of the computer hosting the SmartAuditor Server. You can change the directory where the recordings are stored, add additional directories to load-balance across multiple volumes, or make use of additional space. Multiple directories in the list indicates recordings are load-balanced across the directories. You can add a directory multiple times. Load balancing cycles through the directories. 1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Storage tab. 4. Use the File storage directories list to manage the directories where recordings are stored.

You can create file storage directories on the local drive, the SAN volume, or a location specified by a UNC network path. Network mapped drive letters are not supported. Do not use SmartAuditor with Network-Attached Storage (NAS), due to serious performance and security problems associated with writing recording data to a network drive.

To specify a restore directory for archived files


By default, archived recordings are restored to the drive:\SessionRecordingsRestore directory of the computer hosting the SmartAuditor Server. You can change the directory where the archived recordings are restored. 1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Storage tab.

1088

To specify where recordings are stored 4. In the Restore directory for archived files field, type the directory for the restored archive files.

1089

Specifying File Size for Recordings


As recordings grow in size, the files can take longer to download and react more slowly when you use the seek slider to navigate during playback. To control file size, specify a threshold limit for a file. When the recording reaches this limit, SmartAuditor closes the file and opens a new one to continue recording. This action is called a rollover. You can specify two thresholds for a rollover:

File size. When the file reaches the specified number of megabytes, SmartAuditor closes the file and opens a new one. By default, files roll over after reaching 50 megabytes; however, you can specify a limit from 10 megabytes to one gigabyte. Duration. After the session records for the specified number of hours, the file is closed and a new file is opened. By default, files roll over after recording for 12 hours; however, you can specify a limit from one to 24 hours.

SmartAuditor checks both fields to determine which event occurs first to determine when to rollover. For example, if you specify 17MB for the file size and six hours for the duration and the recording reaches 17MB in three hours, SmartAuditor reacts to the 17MB file size to close the file and open a new one. To prevent the creation of many small files, SmartAuditor does not rollover until at least one hour elapses (this is the minimum number that you can enter) regardless of the value specified for the file size. The exception to this rule is if the file size surpasses one gigabyte.

To specify a maximum limit for a file


1. Log on to the computer hosting the SmartAuditor Server. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties. 3. In SmartAuditor Server Properties, click the Rollover tab. 4. Enter an integer between 10 and 1024 to specify the maximum file size in megabytes. 5. Enter an integer between 1 and 24 to specify the maximum recording duration in hours.

1090

Viewing Recordings
Use SmartAuditor Player to view, search, and bookmark recorded XenApp sessions. If sessions are recorded with the live playback feature enabled, you can view sessions that are in progress, with a delay of a few seconds, as well as sessions that are completed. Sessions that have a longer duration or larger file size than the limits configured by your SmartAuditor administrator appear in more than one session file. Note: A SmartAuditor administrator must grant users the right to access to recorded XenApp sessions. If you are denied access to viewing sessions, contact your SmartAuditor administrator. When SmartAuditor Player is installed, the SmartAuditor administrator typically sets up a connection between the SmartAuditor Player and a SmartAuditor Server. If this connection is not set up, the first time you perform a search for files, you are prompted to set it up. Contact your SmartAuditor administrator for set up information.

1091

To launch the SmartAuditor Player


1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.

The SmartAuditor Player appears.

This illustration shows the SmartAuditor Player with callouts indicating its major elements. The functions of these elements are described throughout this chapter.

1092

To open and play recordings


You can open session recordings in SmartAuditor Player in two ways:

Perform a search using the Smart Auditor Player. Recorded sessions that meet the search criteria appear in the search results area. Access recorded session files directly from your local disk drive or a share drive. Access recorded session files from a Favorites folder

When you open a file that was recorded without a digital signature, a warning appears telling you that the origin and integrity of the file was not verified. If you are confident of the integrity of the file, click Yes in the warning pop-up window to open the file.

To open and play a recording in the search results area


1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Perform a search. 4. If the search results area is not visible, select Search Results in the Workspace pane. 5. In the search results area, select the session you want to play. 6. Do any of the following:
q

Double-click the session Right-click and select Play From the SmartAuditor Player menu bar, select Play > Play

To open and play a recording by accessing the file


Recorded session file names begin with an i_, followed by a unique alphanumeric file ID, followed by the .icl and .icle file extension: .icl for recordings without playback protection applied, .icle for recordings with playback protection applied. SmartAuditor saves recorded session files in a directory structure that incorporates the date the session was recorded. For example, the file for a session recorded on May 22, 2008, is saved in folder path 2008\05\22.

1093

To open and play recordings 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Do any of the following:
q

From the SmartAuditor Player menu bar, select File > Open and browse for the file Using Windows Explorer, navigate to the file and drag the file into the Player window Using Windows Explorer, navigate to and double-click the file If you created Favorites in the Workspace pane, select Favorites and open the file from the Favorites area in the same way you open files from the search results area

Using Favorites
Creating Favorites folders allows you to quickly access recordings that you view frequently. These Favorites folders reference recorded session files that are stored on your workstation or on a network drive. You can import and export these files to other workstations and share these folders with other SmartAuditor Player users. Note: Only users with access rights to SmartAuditor Player can download the recorded session files associated with Favorites folders. Contact your SmartAuditor administrator for access rights. To create a Favorites subfolder: 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. In the SmartAuditor Player, select the Favorites folder in your Workspace pane. 4. From the menu bar, choose File > Folder > New Folder. A new folder appears under the Favorites folder. 5. Type the folder name, then press Enter or click anywhere to accept the new name. Use the other options that appear in the File > Folder menu to delete, rename, move, copy, import, and export the folders.

1094

To search for recorded sessions


SmartAuditor Player allows you to perform quick searches, perform advanced searches, and specify options that apply to all searches. Results of searches appear in the search results area of the SmartAuditor Player. Note: To display all available recorded sessions, up to the maximum number of sessions that may appear in a search, perform a search without specifying any search parameters.

To perform a quick search


1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Define your search criteria:
q

Enter a search criterion in the Search field. To assist you: Move the mouse pointer over the Search label to display a list of parameters to use as a guideline Click the arrow to the right of the Search field to display the text for the last 64 searches you performed

Use the drop-down list to the right of the Search field to select a period or duration specifying when the session was recorded. 4. Click the binocular icon to the right of the drop-down list to start the search.
q

1095

To search for recorded sessions

To perform an advanced search


1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. In the SmartAuditor Player window, click Advanced Search on the tool bar or choose Tools > Advanced Search. 4. Define your search criteria in the tabs of the Advanced Search dialog box:
q

Common allows you to search by domain or account authority, server farm, group, zone, server, application, or file ID. Date/Time allows you to search date, day of week, and time of day. Events allows you to search on custom events that your SmartAuditor administrator inserted to the sessions.

Other allows you to search by session name, client name, client address, and recording duration. It also allows you to specify, for this search, the maximum number of search results displayed and whether or not archived files are included in the search. As you specify search criteria, the query you are creating appears in the pane at the bottom of the dialog box.
q

5. Click Search to start the search.

Tip: You can save and retrieve advanced search queries. Click Save within the Advanced Search dialog box to save the current query. Click Open within the Advanced Search dialog box to retrieve a saved query. Queries are saved as files with an .isq extension.

To set search options


SmartAuditor Player search options allow you to limit maximum number of session recordings that appear in search results and to specify whether or not search results include archived session files. 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options > Search. 4. In the Maximum result to display field, type the number of search results you want to display. A maximum of 500 results can be displayed. 5. To set whether or not archived files are included in searches, select or clear Include archived files.

1096

To play recorded sessions


After you open a recorded session in the SmartAuditor Player, you can navigate through the recorded sessions using these methods:

Use the player controls to play, stop, pause, and increase or decrease playback speed Use the seek slider to move forward or backward

If you have inserted markers into the recording or if the recorded session contains custom events, you can also navigate through the recorded session by going to those markers and events. Note: During playback of a recorded session, a second mouse pointer may appear. The second pointer appears at the point in the recording when the user navigated within Internet Explorer 7.0 and clicked an image that was originally larger than the screen but was scaled down automatically by Internet Explorer 7.0. While only one pointer appears during the session, two may appear during playback. Note: This version of SmartAuditor does not support SpeedScreen Multimedia Acceleration for Citrix Presentation Server. When this option is enabled, playback displays a black square.

Using Player Controls


You can click the player controls under the Player window or access them by choosing Play from the SmartAuditor Player menu bar. Use Player controls to:

Play the selected session file.

Pause playback.

Stop playback. If you click Stop, then Play, the recording restarts at the beginning of the file.

1097

To play recorded sessions Halve the current playback speed down to a minimum of one-quarter normal speed.

Double the current playback speed up to a maximum of 32 times normal speed.

Using the Seek Slider


Use the seek slider below the Player window to jump to a different position within the recorded session. You can drag the seek slider to the point in the recording you want to view or click anywhere on the slider bar to move to that location. You can also use the following keyboard keys to control the seek slider:

Key: Home End Right Arrow Left Arrow Move mouse wheel one notch down Move mouse wheel one notch up Ctrl + Right Arrow Ctrl + Left Arrow Page Down Page Up Ctrl + Move mouse wheel one notch down Ctrl + Move mouse wheel one notch up Ctrl + Page Down Ctrl + Page Up

Seek action: Seek to the beginning. Seek to the end. Seek forward five seconds. Seek backward five seconds. Seek forward 15 seconds. Seek backward 15 seconds. Seek forward 30 seconds. Seek backward 30 seconds. Seek forward one minute. Seek backward one minute. Seek forward 90 seconds. Seek backward 90 seconds. Seek forward six minutes. Seek backward six minutes.

Note: To adjust the speed of the seeks slider: From the SmartAuditor Player menu bar, choose Tools > Options > Player and drag the slider to increase or decrease the seek response time. A faster response time requires more memory.

1098

To play recorded sessions

To change the playback speed


You can set SmartAuditor Player to play recorded sessions in exponential increments from one-quarter normal playback speed to 32 times normal playback speed. 1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Play > Play Speed. 4. Choose a speed option. The speed adjusts immediately. A number indicating the increased or decreased speed appears below the Player window controls. Text indicating the exponential rate appears briefly in green in the Player window.

To skip over spaces where no action occurred


Fast review mode allows you to set SmartAuditor Player to skip the portions of recorded sessions in which no action takes place. This setting saves time for playback viewing; however, it does not skip animated sequences such as animated mouse pointers, flashing cursors, or displayed clocks with second hand movements. 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Play > Fast Review Mode. The option toggles on and off. Each time you choose it, its status appears briefly in green in the Player window.

1099

To use events and bookmarks


You can use events and bookmarks to help you navigate through recorded sessions. Events are inserted to sessions as they are recorded, using the Event API and a third-party application. Events are saved as part of the session file. You cannot delete or alter them using the SmartAuditor Player. Bookmarks are markers you insert into the recorded sessions using the SmartAuditor Player. Bookmarks are associated with the recorded session until you delete them, but they are not saved as part of the session file. By default, each bookmark is labelled with the text Bookmark, but you can change this to any text annotation up to 128 characters long. Events and bookmarks appear as dots under the Player window. Events appear as yellow dots; bookmarks appear as blue dots. Moving the mouse over these dots displays the text label associated with them. You can also display the events and bookmarks in the events and bookmarks list of the SmartAuditor Player. They appear in this list with their text labels and the times in the recorded session at which they appear, in chronological order. You can use events and bookmarks to help you navigate through recorded sessions. By going to an event or bookmark, you can skip to the point in the recorded session where the event or bookmark is inserted.

To display events and bookmarks in the list


The events and bookmarks list displays the events and bookmarks inserted in the recorded session that is currently playing. It can show events only, bookmarks only, or both. 1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Move the mouse pointer into the events and bookmarks list area and right-click to display the menu. 4. Choose Show Events Only, Show Bookmarks Only, or Show All.

1100

To use events and bookmarks

To insert a bookmark
1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Begin playing the recorded session to which you want to add a bookmark. 4. Move the seek slider to the position where you want to insert the bookmark. 5. Move the mouse pointer into the Player window area and right-click to display the menu. 6. Add a bookmark with the default label Bookmark or create an annotation:
q

To add a bookmark with the default label Bookmark, choose Add Bookmark. To add a bookmark with a descriptive text label that you create, choose Add Annotation. Type the text label you want to assign to the bookmark, up to 128 characters. Click OK.

To add or change an annotation


After a bookmark is created, you can add an annotation to it or change its annotation. 1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Begin playing the recorded session containing the bookmark. 4. Ensure that the events and bookmarks list is displaying bookmarks. 5. Select the bookmark in the events and bookmarks list and right-click to display the menu. 6. Choose Edit Annotation. 7. In the window that appears, type the new annotation and click OK.

1101

To use events and bookmarks

To delete a bookmark
1. Log on to the workstation where SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Begin playing the recorded session containing the bookmark. 4. Ensure that the events and bookmarks list is displaying bookmarks. 5. Select the bookmark in the events and bookmarks list and right-click to display the menu. 6. Choose Delete.

To go to an event or bookmark
Going to an event or bookmark causes the SmartAuditor Player to go to the point in the recorded session where the event or bookmark is inserted. 1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. Begin playing a session recording containing events or bookmarks. 4. Go to an event or bookmark:
q

In the area below the Player window, click the dot representing the event or bookmark to go to the event or bookmark. In the events and bookmarks list, double-click the event or bookmark to go to it. To go to the next event or bookmark, select any event or bookmark from the list, right-click to display the menu, and choose Seek to Bookmark.

1102

To change the playback display


Options allow you to change how recorded sessions appear in the Player window. You can pan and scale the image, show the playback in full-screen mode, display the Player window in a separate window, and display a red border around the recorded session to differentiate it from the Player window background.

To display the Player window in full-screen format


1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose View > Player Full Screen. 4. To return to the original size, press ESC or F11.

To display the Player window in a separate window


1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose View > Player in Separate Window. A new window appears containing the Player window. You can drag and resize the window. 4. To embed the Player window in the main window, choose View > Player in Separate Window, or press F10.

1103

To change the playback display

To scale the session playback to fit the Player window


1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Play > Panning and Scaling > Scale to Fit.
q

Scale to Fit (Fast Rendering) shrinks the image while providing a good quality image. Images are drawn quicker than when using the High Quality option but the images and text are not as sharp. Use this option if you are experiencing performance issues when using the High Quality mode. Scale to Fit (High Quality) shrinks the image while providing high quality images and text. Using this option may cause the images to be drawn more slowly than the Fast Rendering option.

To pan the image


1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Play > Panning and Scaling > Panning. The pointer changes to a hand and a small representation of the screen appears in the top right of the Player window. 4. Drag the image. The small representation indicates where you are in the image. 5. To stop panning, choose one of the scaling options.

To display a red border around the session recording


1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options > Player from the menu bar. 4. Select the Show border around session recording check box. Tip: If the Show border around session recording check box is not selected, you can temporarily view the red border by clicking and holding down the left mouse button while the pointer is in the Player window.

1104

To display or hide window elements


The SmartAuditor Player has window elements that toggle on and off. 1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose View. 4. Choose the elements that you want to display. Selecting an element causes it to appear immediately. A check mark indicates that the element is selected.

1105

To cache recorded session files


Each time you open a recorded session file, the SmartAuditor Player downloads the file from the location where the recordings are stored. If you download the same files frequently, you can save download time by caching the files on your workstation. Cached files are stored on your workstation in these folders:

userprofile\LocalSettings\ApplicationData\Citrix\SmartAuditor\Player\Cache on Microsoft Windows XP userprofile\AppData\Local\Citrix\SmartAuditor\Player\Cache on Microsoft Windows Vista You can specify how much disk space is used for the cache. When the recordings fill the specified disk space, SmartAuditor deletes the oldest, least used recordings to make room for new recordings. You can empty the cache at any time to free up disk space.

To enable caching
1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options > Cache. 4. Select the Cache downloaded files on local machine check box. 5. If you want to limit the amount of disk space used for caching, select the Limit amount of disk space to use check box and specify the number of megabytes to be used for cache. 6. Click OK.

1106

To cache recorded session files

To empty cache
1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options > Cache. 4. Select the Cache downloaded files on local machine check box. 5. In the SmartAuditor Player, choose Tools > Options > Cache. 6. Click Purge Cache, then OK to confirm the action.

1107

To change SmartAuditor Servers


If the SmartAuditor administrator set up your SmartAuditor Player with the ability to connect to more than one SmartAuditor Server, you can select the SmartAuditor Server that the SmartAuditor Player connects to. The SmartAuditor Player can connect to only one SmartAuditor Server at a time. 1. Log on to the workstation where the SmartAuditor Player is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. 3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections. 4. Select the SmartAuditor Server to which you want to connect.

1108

Troubleshooting SmartAuditor
This troubleshooting information contains solutions to some issues you may encounter during and after installing SmartAuditor components:
q

Components failing to connect to each other Sessions failing to record Problems with the SmartAuditor Player or SmartAuditor Policy Console Issues involving your communication protocol

1109

Verifying Component Connections


During the setup of SmartAuditor, the components may not connect to other components. All the components communicate with the SmartAuditor Server (Broker). By default, the Broker (an IIS component) is secured using the IIS default Web site certificate. If one component cannot connect to the SmartAuditor Server, the other components may also fail when attempting to connect. The SmartAuditor Agent and SmartAuditor Server (Storage Manager and Broker) log connection errors in the applications event log in the Event Viewer of the computer hosting the SmartAuditor Server, while the SmartAuditor Policy Console and SmartAuditor Player display connection error messages on screen when they fail to connect.

To verify SmartAuditor Agent is connected


1. Log on to the server where the SmartAuditor Agent is installed. 2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. 3. In SmartAuditor Server Properties, click Connection. 4. Verify that the value for SmartAuditor Server is the correct server name of the computer hosting the SmartAuditor Server. 5. Verify that the server given as the value for SmartAuditor Server can be contacted by the XenApp server.

Note: Check the application event log for errors and warnings.

To verify SmartAuditor Server is connected


Caution: Using Registry Editor 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. 1. Log on to the computer hosting the SmartAuditor Server. 2. Open the Registry Editor. 3. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Server. 4. Verify the value of SmAudDatabaseInstance correctly references the SmartAuditor Database you installed in your SQL Server instance.

1110

Verifying Component Connections

To verify SmartAuditor Database is connected


1. Using a SQL Management tool, open your SQL instance that contains the SmartAuditor Database you installed. 2. Open the Security permissions of the SmartAuditor Database. 3. Verify the SmartAuditor Computer Account has access to the database. For example, if the computer hosting the SmartAuditor Server is named SmartAudSrv in the MIS domain, the computer account in your database should be configured as MIS\SmartAudSrv$. This value is configured during the SmartAuditor Database install.

1111

Testing IIS Connectivity


Testing connections to the SmartAuditor Server IIS site by using a Web browser to access the SmartAuditor Broker Web page can help you determine whether problems with communication between SmartAuditor components stem from misconfigured protocol configuration, certification issues, or problems starting SmartAuditor Broker.

To verify IIS connectivity for the SmartAuditor Agent


1. Log on to the server where the SmartAuditor Agent is installed. 2. Launch a Web browser and type the following address:
q

For HTTPS: https://servername/SmartAuditorBroker/RecordPolicy.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server

For HTTP: http://servername/SmartAuditorBroker/RecordPolicy.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server 3. If you are prompted for NT LAN Manager (NTLM) authentication, log on with a domain administrator account.
q

If you see an XML document within your browser, this verifies that the computer running the SmartAuditor Agent is connected to the computer hosting the SmartAuditor Server using the configure protocol.

To verify IIS connectivity for the SmartAuditor Player


1. Log on to the workstation where the SmartAuditor Player is installed. 2. Launch a Web browser and type the following address:
q

For HTTPS: https://servername/SmartAuditorBroker/Player.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server

For HTTP: http://servername/SmartAuditorBroker/Player.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server 3. If you are prompted for NT LAN Manager (NTLM) authentication, log on with a domain administrator account.
q

If you see an XML document within your browser, this verifies that the computer running the SmartAuditor Player is connected to the computer hosting the SmartAuditor Server using the configure protocol.

1112

Testing IIS Connectivity

To verify IIS connectivity for the SmartAuditor Policy Console


1. Log on to the server where the SmartAuditor Policy Console is installed. 2. Launch a Web browser and type the following address:
q

For HTTPS: https://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server

For HTTP: http://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where servername is the name of the computer hosting the SmartAuditor Server 3. If you are prompted for NT LAN Manager (NTLM) authentication, log on with a domain administrator account.
q

If you see an XML document within your browser, this verifies that the computer running the SmartAuditor Policy Console is connected to the computer hosting the SmartAuditor Server using the configure protocol.

1113

Troubleshooting Certificate Issues


If you are using HTTPS as your communication protocol, the computer hosting the SmartAuditor Server must be configured with a server certificate. All component connections to the SmartAuditor Server must have root certificate authority (CA). Otherwise, attempted connections between the components fail. You can test your certificates by accessing the SmartAuditor Broker Web page as you would when testing IIS connectivity. If you are able to access the XML page for each component, the certificates are configured correctly. Here are some common ways certificate issues cause connections to fail:
q

Invalid or missing certificates. If the server running the SmartAuditor Agent does not have a root certificate to trust the server certificate, cannot trust and connect to the SmartAuditor Server over HTTPS, causing connectivity to fail. Verify that all components trust the server certificate on the SmartAuditor Server. Inconsistent naming. If the server certificate assigned to the computer hosting the SmartAuditor Server is created using a fully qualified domain name (FQDN), then all connecting components must use the FQDN when connecting to the SmartAuditor Server. If a NetBIOS name is used, configure the components with a NetBIOS name for the SmartAuditor Server. Expired certificates. If a server certificate expired, connectivity to the SmartAuditor Server through HTTPS fails. Verify the server certificate assigned to the computer hosting the SmartAuditor Server is valid and has not expired. If the same certificate is used for the digital signing of session recordings, the event log of the computer hosting the SmartAuditor Server provides error messages that the certificate expired or warning messages when it is about to expire.

1114

SmartAuditor Agent Cannot Connect


When SmartAuditor Agent cannot connect, the Exception caught while sending poll messages to SmartAuditor Broker event message is logged, followed by the exception text. The exception text provides the reason why the connection failed. These reasons include:
q

The underlying connection was closed. Could not establish a trust relationship for the SSL/TLS secure channel. This exception means that the SmartAuditor Server is using a certificate that is signed by a CA that the server on which the SmartAuditor Agent resides does not trust, or have a CA certificate for. Alternatively, the certificate may have expired or been revoked. Resolution: Verify that the correct CA certificate is installed on the server hosting the SmartAuditor Agent or use a CA that is trusted.

The remote server returned an error: (403) forbidden. This is a standard HTTPS error displayed when you attempt to connect using HTTP (nonsecure protocol). The computer hosting the SmartAuditor Server rejects the connection because it accepts only secure connections. Resolution: Use SmartAuditor Agent Properties to change the SmartAuditor Broker protocol to HTTPS.

The SmartAuditor Broker returned an unknown error while evaluating a record policy query. Error code 5 (Access Denied). See the Event log on the SmartAuditor Server for more details. This error occurs when sessions are started and a request for a record policy evaluation is made. The error is a result of the Authenticated Users group (this is the default member) being removed from the Policy Query role of the SmartAuditor Authorization Console. Resolution: Add the Authenticated Users group back into this role, or add each server hosting each SmartAuditor Agent to the PolicyQuery role. The underlying connection was closed. A connection that was expected to be kept alive was closed by the server. This error means that the SmartAuditor Server is down or unavailable to accept requests. This could be due to IIS being offline or restarted, or the entire server may be offline. Resolution: Verify that the SmartAuditor Server is started, IIS is running on the server, and the server is connected to the network.

1115

SmartAuditor Server Cannot Connect to the SmartAuditor Database


When the SmartAuditor Server cannot connect to the SmartAuditor Database, you may see a message similar to one of the following: Event Source: Citrix SmartAuditor Storage Manager Description: Exception caught while establishing database connection. This error appears in the applications event log in the Event Viewer of the computer hosting the SmartAuditor Server. Unable to connect to the SmartAuditor Server. Ensure that the SmartAuditor Server is running. This error message appears when you launch the SmartAuditor Policy Console. Resolution:
q

The Express Edition of Mircosoft SQL Server 2005 or Microsoft SQL Server 2008 is installed on a stand-alone server and does not have the correct services or settings configured for SmartAuditor. The server must have TCP/IP protocol enabled and SQL Server Browser service running. See the Microsoft documentation for information about enabling these settings. During the SmartAuditor installation (administration portion), incorrect server and database information was given. Uninstall the SmartAuditor Database and reinstall it, supplying the correct information. The SmartAuditor Database Server is down. Verify that the server has connectivity. The computer hosting the SmartAuditor Server or the computer hosting the SmartAuditor Database Server cannot resolve the FQDN or NetBIOS name of the other. Use the ping command to verify the names can be resolved.

Logon failed for user NT_AUTHORITY\ANONYMOUS LOGON. This error message means that the services are logged on incorrectly as .\administrator. Resolution: Restart the services as local system user and restart the SQL services.

1116

Sessions are not Recording


If your XenApp sessions are not recording successfully, start by checking the application event log in the Event Viewer on the XenApp server running the SmartAuditor Agent and SmartAuditor Server. This may provide valuable diagnostic information. If sessions are not recording, these issues might be the cause:
q

Component connectivity and certificates. If the SmartAuditor components cannot communicate with each other, this can cause session recordings to fail. To troubleshoot recording issues, verify that all components are configured correctly to point to the correct computers and that all certificates are valid and correctly installed. Non-Active Directory domain environments. SmartAuditor is designed to run in a Microsoft Active Directory domain environment. If you are not running in an Active Directory environment, you may experience recording issues. Ensure that all SmartAuditor components are running on computers that are members of an Active Directory domain. Session sharing conflicts with the active policy. SmartAuditor matches the active policy with the first published application that a user opens. Subsequent applications opened during the same session continue to follow the policy that is in force for the first application. To prevent session sharing from conflicting with the active policy, publish the conflicting applications on separate XenApp servers or disable session sharing. For instructions about how to disable session sharing, refer to the Citrix Knowledge Center. When disabling session sharing, consider that this can also affect the total number of sessions on a server, clipboard mapping, and session logon time. Recording is not enabled. By default, installing the SmartAuditor Agent on a XenApp server enables the server for recording. Recording will not occur until an active recording policy is configured to allow this. The active recording policy permit recording. For a session to be recorded, the active recording policy must permit the sessions for the user, server, or published application to be recorded. SmartAuditor services are not running. For sessions to be recorded, the SmartAuditor Agent service must be running on the XenApp server and the SmartAuditor Storage Manager service must be running on the computer hosting the SmartAuditor Server. MSMQ is not configured. If MSMQ is not correctly configured on the server running the SmartAuditor Agent and the computer hosting the SmartAuditor Server, recording problems may occur.

1117

Searching for Recordings in the Player Fails


If you experience difficulties when searching for recordings using the SmartAuditor Player, the following error messages may appear on the screen:
q

Search for recorded session files failed. The remote server name could not be resolved: servername. where servername is the name of the server to which the SmartAuditor Player is attempting to connect. The SmartAuditor Player cannot contact the SmartAuditor Server. Two possible reasons for this are an incorrectly typed server name or the DNS cannot resolve the server name. Resolution: From the Player menu bar, choose Tools > Options > Connections and verify that the server name in the SmartAuditor Servers list is correct. If it is correct, from a command prompt, run the ping command to see if the name can be resolved. When the SmartAuditor Server is down or offline, the search for recorded session files failed error message is Unable to contact the remote server.

Unable to contact the remote server. This error occurs when the SmartAuditor Server is down or offline. Resolution: Verify that the SmartAuditor Server is connected.

Access denied error. An access denied error can occur if the user was not given permission to search for and download recorded session files. Resolution: Assign the user to the Player role using the SmartAuditor Authorization Console.

Search for recorded session files failed. The underlying connection was closed. Could not establish a trust relationship for the SSL/TLS secure channel. This exception is caused by the SmartAuditor Server using a certificate that is signed by a CA that the client device does not trust or have a CA certificate for. Resolution: Install the correct or trusted CA certificate workstation where the SmartAuditor Player is installed.

The remote server returned an error: (403) forbidden. This error is a standard HTTPS error that occurs when you attempt to connect using HTTP (nonsecure protocol). The server rejects the connection because, by default, it is configured to accept only secure connections. Resolution: From the SmartAuditor Player menu bar, choose Tools > Options > Connections. Select the server from the SmartAuditors Servers list, then click Modify. Change the protocol from HTTP to HTTPS.

1118

Troubleshooting MSMQ
If your users see the notification message but the viewer cannot find the recordings after performing a search in the SmartAuditor Player, there could be a problem with MSMQ. Verify that the queue is connected to the SmartAuditor Server (Storage Manager) and use a Web browser to test for connection errors (if you are using HTTP or HTTPS as your MSMQ communication protocol). To verify that the queue is connected: 1. Log on to the server hosting the SmartAuditor Agent. 2. View the outgoing queues. 3. Verify that the queue to the computer hosting the SmartAuditor Server has a connected state.
q

If the state is waiting to connect, there are a number of messages in the queue, and the protocol is HTTP or HTTPS (corresponding to the protocol selected in the Connections tab in the SmartAuditor Agent Properties dialog box), perform Step 4.

If state is connected and there are no messages in the queue, there may be a problem with the server hosting the SmartAuditor Server. Skip Step 4 and perform Step 5. 4. If there are a number of messages in the queue, launch a Web browser and type the following address:
q q

For HTTPS: https://servername/msmq/private$/CitrixSmAudData, where servername is the name of the computer hosting the SmartAuditor Server

For HTTP: http://servername/msmq/private$/CitrixSmAudData, where servername is the name of the computer hosting the SmartAuditor Server If the page returns an error such as The server only accepts secure connections, change the MSMQ protocol listed in the SmartAuditor Agent Properties dialog box to HTTPS. Otherwise, if the page reports a problem with the Web sites security certificate, there may be a problem with a trust relationship for the SSL/TLS secure channel. In that case, install the correct CA certificate or use a CA that is trusted.
q

5. If there are no messages in the queue, log on to the computer hosting the SmartAuditor Server and view private queues. Select citrixsmauddata. If there are a number of messages in the queue (Number of Messages Column), verify that the SmartAuditor StorageManager service is started. If it is not, restart the service.

1119

Unable to View Live Session Playback


If you experience difficulties when viewing recordings using the SmartAuditor Player, the following error message may appear on the screen: Download of recorded session file failed. Live session playback is not permitted. The server has been configured to disallow this feature. This error indicates that the server is configured to disallow the action. Resolution: In the SmartAuditor Server Properties dialog box, choose the Playback tab and select the Allow live session playback check box.

1120

To change your communication protocol


For security reasons, Citrix does not recommend using HTTP as a communication protocol. The SmartAuditor installation is configured to use HTTPS. If you want to use HTTP instead of HTTPS, you must change several settings.

To use HTTP as the communication protocol


1. Log on to the computer hosting the SmartAuditor Server and disable secure connections for SmartAuditor Broker in IIS. 2. Change the protocol setting from HTTPS to HTTP in each SmartAuditor Agent Properties dialog box: a. Log on to each server where the SmartAuditor Agent is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. c. In SmartAuditor Agent Properties, choose the Connections tab. d. In the SmartAuditor Broker area, select HTTP from the Protocol drop-down list and choose OK to accept the change. If you are prompted to restart the service, choose Yes. 3. Change the protocol setting from HTTPS to HTTP in the SmartAuditor Player settings: a. Log on to each workstation where the SmartAuditor Player is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. c. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select the server and choose Modify. d. Select HTTP from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box. 4. Change the protocol setting from HTTPS to HTTP in the SmartAuditor Policy Console: a. Log on to the server where the SmartAuditor Policy Console is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. c. Choose HTTP from the Protocol drop-down list and choose OK to connect. If the connection is successful, this setting is remembered the next time you launch the SmartAuditor Policy Console.

1121

To change your communication protocol

To revert to HTTPS as the communication protocol


1. Log on to the computer hosting the SmartAuditor Server and enable secure connections for the SmartAuditor Broker in IIS. 2. Change the protocol setting from HTTP to HTTPS in each SmartAuditor Agent Properties dialog box: a. Log on to each server where the SmartAuditor Agent is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties. c. In SmartAuditor Agent Properties, choose the Connections tab. d. In the SmartAuditor Broker area, select HTTPS from the Protocol drop-down list and choose OK to accept the change. If you are prompted to restart the service, choose Yes. 3. Change the protocol setting from HTTP to HTTPS in the SmartAuditor Player settings: a. Log on to each workstation where the SmartAuditor Player is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player. c. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select the server and choose Modify. d. Select HTTPS from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box. 4. Change the protocol setting from HTTP to HTTPS in the SmartAuditor Policy Console: a. Log on to the server where the SmartAuditor Policy Console is installed. b. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console. c. Choose HTTPS from the Protocol drop-down list and choose OK to connect. If the connection is successful, this setting is remembered the next time you launch the SmartAuditor Policy Console.

1122

Reference: Managing Your Database Records


The ICA Log database (ICLDB) utility is a database command-line utility used to manipulate the session recording database records. This utility is installed during the SmartAuditor installation in the drive:\ProgramFiles\Citrix\SmartAuditor\Server\Bin directory at the server hosting the SmartAuditor Server software.

Quick Reference Chart


The following table lists the commands and options that are available for the ICLDB utility. Type the commands using the following format: icldb [version | locate | dormant | import | archive | remove | removeall] command-options [/l] [/f] [/s] [/?] Note: More extensive instructions are available in the help associated with the utility. To access the help, from a command prompt, type drive:\ProgramFiles\Citrix\SmartAuditor\Server\Bin directory, type icldb /?. To access help for specific commands, type icldb command /?.

Command archive

Description Archives the session recording files older than the retention period specified. Use this command to archive files.

dormant

Displays or counts the session recording files that are considered dormant. Dormant files are session recordings that were not completed due to data loss. Use this command to verify if you suspect that you are losing data. You can verify if the session recording files are becoming dormant for the entire database, or only recordings made within the specified number of days, hours, or minutes.

import

Imports session recording files into the SmartAuditor database. Use this command to rebuild the database if you lose database records. Additionally, use this command to merge databases (if you have two databases, you can import the files from one of the databases).

1123

Reference: Managing Your Database Records locate Locates and displays the full path to a session recording file using the file ID as the criteria. Use this command when you are looking for the storage location of a session recording file. It is also one way to verify if the database is up-to-date with a specific file. remove Removes the references to session recording files from the database. Use this command (with caution) to clean up the database. Specify the retention period to be used as the criteria. You can also remove the associated physical file. removeall Removes all of the references to session recording files from the SmartAuditor Database and returns the database to its original state. The actual physical files are not deleted; however you cannot search for these files in the SmartAuditor Player. Use this command (with caution) to clean up the database. Deleted references can be reversed only by restoring from your backup. version /l /f /s /? Displays the SmartAuditor Database schema version. Logs the results and errors to the Windows event log. Forces the command to run without prompts. Suppresses the copyright message. Displays help for the commands.

1124

Enable Single Sign-on Access to Windows, Web, and Apps


Citrix Single sign-on (formerly Citrix Password Manager) provides password security and single sign-on access to Windows, Web, and terminal emulator applications running in the Citrix environment as well as applications running on the desktop. For more information, see the Single sign-on node in eDocs.

1125

Automate IT Processes with Workflow Studio


Citrix Workflow Studio allows IT administrators to easily tie technology components together via workflows. For information about Workflow Studio, see Workflow Studio node in eDocs.

1126

Citrix App Studio 1.0


Citrix App Studio provides simple unified management of Citrix application and desktop delivery technologies. With App Studio, Citrix Service Providers can:
q

Manage multiple farms and provide tenants access to published resources through a single Web-based console Offer tenants options for isolating resources, enabling tenants to access shared resources or providing tenants with private access Monitor tenants and users and manage resource capacity Deploy server or application updates without interrupting service to tenants Offer App Studio as a service to customers that are already managed through Citrix CloudPortal Services Manager

1127

About Citrix App Studio 1.0


Known Issues
This section contains:
q

Installation Issues General issues

1128

Citrix App Studio

Installation Issues
q

When running the New-CamFarm, New-CamWIServer, or New-CamSessionHost scripts from the App Studio configuration server, and the configuration server is hosting the XenApp 6.5 installation media, the scripts might fail if the XenAppDVDPath parameter is defined as \\localhost. To resolve this issue, at the XenAppDVDPath prompt, specify the name of the App Studio configuration server when entering the network path. For example, \\ServerName\XenApp\dvd. [#159337] When running the New-CamFarm or New-CamSessionHost scripts, the scripts might fail, citing "error -4." This error indicates an issue has occurred when configuring XenApp 6.5 on the target servers. To troubleshoot this issue, check the Temp directory of the target server (typically, C:\Windows\Temp) and review the error logs for complete information relating to Error -4. These logs contain "XenAppConfigConsole" in the file name. In the event the error logs indicate a database connectivity issue might be present, perform the following actions to check whether or not the target servers can connect to the XenApp database: 1. On the target server, launch the XenApp Server Role Manager and click Configure. 2. Proceed through the XenApp Server Configuration Tool until you reach the Database Information page. 3. Select Existing Microsoft SQL Server Database and specify the database credentials you used when running the App Studio script. 4. Click Test connection to verify the target server can connect to the database you specified when running the App Studio script. 5. Close the XenApp Server Configuration Tool. Do not finish the configuration. [#268560]

On servers running the Japanese language version of Windows, the New-CamFarm or New-CamSessionHost scripts might fail during the following events:
q

During reboot of the primary and backup controllers or the session hosts Mapping drives

Establishing remote PowerShell connections to servers To work around this issue, wait for the affected servers to finish rebooting and then rerun the appropriate scripts with the same parameters. Alternatively, log on to each affected server and rerun the appropriate script. [#291465]
q

1129

Citrix App Studio

General Issues
q

After configuring the App Studio environment and adding servers, changing the license server through the Web console does not change the license server already configured on the servers added to the environment. To change the license server on servers already included in the App Studio environment, choose one of the following methods:
q

Change the license server manually. On each affected servers, launch the XenApp Server Role Manager and select Edit Licensing.

Change the license server via the command line. On the affected servers, use the XenAppConfigConsole.exe commandwith the /LicenseServerName, /LicenseServerPort, and /LicenseModel options. For more information about these options, refer to the "License options" section of Configuration Command Syntax in Citrix eDocs.

Change the License server host name policy setting for the farm GPO. 1. On an affected server in the farm, launch the App Center and click Policies from the tree pane. 2. Click the Computer tab and then locate the License server host name setting. 3. Click Add and then enter the new license server name. Create a new GPO and link it to the root OU. 1. On an affected server in the deployment, launch the Group Policy Management Console and create a new GPO. 2. Edit the GPO and, under Computer Configuration > Policies > Citrix Policies, locate the License server host name policy setting. 3. Click Add and then enter the new license server name.

4. Link the GPO to the root OU of the App Studio deployment. [#263406]

1130

About Citrix App Studio 1.0


Known Issues
This section contains:
q

Installation Issues General issues

1131

About This Release

Installation Issues
q

When running the New-CamFarm, New-CamWIServer, or New-CamSessionHost scripts from the App Studio configuration server, and the configuration server is hosting the XenApp 6.5 installation media, the scripts might fail if the XenAppDVDPath parameter is defined as \\localhost. To resolve this issue, at the XenAppDVDPath prompt, specify the name of the App Studio configuration server when entering the network path. For example, \\ServerName\XenApp\dvd. [#159337] When running the New-CamFarm or New-CamSessionHost scripts, the scripts might fail, citing "error -4." This error indicates an issue has occurred when configuring XenApp 6.5 on the target servers. To troubleshoot this issue, check the Temp directory of the target server (typically, C:\Windows\Temp) and review the error logs for complete information relating to Error -4. These logs contain "XenAppConfigConsole" in the file name. In the event the error logs indicate a database connectivity issue might be present, perform the following actions to check whether or not the target servers can connect to the XenApp database: 1. On the target server, launch the XenApp Server Role Manager and click Configure. 2. Proceed through the XenApp Server Configuration Tool until you reach the Database Information page. 3. Select Existing Microsoft SQL Server Database and specify the database credentials you used when running the App Studio script. 4. Click Test connection to verify the target server can connect to the database you specified when running the App Studio script. 5. Close the XenApp Server Configuration Tool. Do not finish the configuration. [#268560]

On servers running the Japanese language version of Windows, the New-CamFarm or New-CamSessionHost scripts might fail during the following events:
q

During reboot of the primary and backup controllers or the session hosts Mapping drives

Establishing remote PowerShell connections to servers To work around this issue, wait for the affected servers to finish rebooting and then rerun the appropriate scripts with the same parameters. Alternatively, log on to each affected server and rerun the appropriate script. [#291465]
q

1132

About This Release

General Issues
q

After configuring the App Studio environment and adding servers, changing the license server through the Web console does not change the license server already configured on the servers added to the environment. To change the license server on servers already included in the App Studio environment, choose one of the following methods:
q

Change the license server manually. On each affected servers, launch the XenApp Server Role Manager and select Edit Licensing.

Change the license server via the command line. On the affected servers, use the XenAppConfigConsole.exe commandwith the /LicenseServerName, /LicenseServerPort, and /LicenseModel options. For more information about these options, refer to the "License options" section of Configuration Command Syntax in Citrix eDocs.

Change the License server host name policy setting for the farm GPO. 1. On an affected server in the farm, launch the App Center and click Policies from the tree pane. 2. Click the Computer tab and then locate the License server host name setting. 3. Click Add and then enter the new license server name. Create a new GPO and link it to the root OU. 1. On an affected server in the deployment, launch the Group Policy Management Console and create a new GPO. 2. Edit the GPO and, under Computer Configuration > Policies > Citrix Policies, locate the License server host name policy setting. 3. Click Add and then enter the new license server name.

4. Link the GPO to the root OU of the App Studio deployment. [#263406]

1133

System Requirements for Citrix App Studio


For more information about XenApp and Web Interface server requirements, refer to the topics System Requirements for XenApp 6.5 and System Requirements for the Web Interface in Citrix eDocs.

General Server Requirements


All servers in your App Studio environment must meet the following requirements: Operating System Domain Functional Level Windows Server 2008 R2 SP1 Windows Server 2008 R2. All servers are joined to a single domain. Additionally, all servers, including the database server, are joined to the same domain. 4.0.30319. The .NET Framework 4 executable is located in the Support folder of the App Studio installation media. Enabled. See PowerShell Execution Policy and Remoting Requirements. Enabled. Disabled on all servers designated as XenApp session hosts. .NET Framework 3.5.1. This Windows server role is required on all XenApp and Web Interface servers in the deployment.

.NET Framework version

PowerShell remoting Windows Update Service Automatic updates Windows Server Roles

App Studio Configuration Server Requirements


The App Studio configuration server hosts the App Studio configuration service and the App Studio Web console. To install and configure the App Studio configuration server, ensure the following requirements are met, in addition to the general server requirements:

Internet Access

Enabled. App Studio Setup accesses Windows Update to verify the full version of the .NET Framework 4 is installed and to install .NET updates, if required.

1134

System Requirements Operating system updates PowerShell version Web Browser All current Windows updates and patches are installed. PowerShell 2.0 Internet Explorer 9. Required on any computer from which the App Studio Web console is accessed. SQL Server 2008 R2, configured with SQL Native authentication.

Database server

Farm Requirements
To configure the first farm and add infrastructure servers, your environment must include the following items:
q

Two servers (physical or virtual), to be prepared and used as primary and backup XenApp controllers. One or more servers, to be prepared and used as XenApp session hosts. Important: Because these servers will be added to the same workload catalog, these servers must be configured identically, including having the same updates or patches applied. When these servers are added to the App Studio deployment, App Studio registers their capabilities and uses them to evaluate subsequent servers added to the workload catalog. If subsequent servers are not identical to the initial servers' configuration, they are not accepted into the deployment.

One server, to be prepared and used as the Web Interface server. A network file share containing the installation media for XenApp 6.5. Microsoft SQL Server 2008 R2 database server, for the farm database.

As part of creating a farm in your environment, App Studio automatically creates the farm database. To ensure the database is created smoothly, the following items are required:
q

SQL Server is configured as the default instance. SQL PowerShell provider is installed on the database server. This provider is included with SQL Management Studio. Windows authentication is configured. The user account running the scripts has permission to create the database.

If you create the farm database manually, ensure that db_owner permissions for the database are assigned to the user account for IMA. Connections to the database may use either Windows authentication or SQL authentication.

1135

System Requirements

Licensing Requirements
Citrix License Server 11.9 is required for configuring the App Studio server as well as configuring the XenApp and Web Interface servers. If you use an older version of Citrix License Server, App Studio cannot validate the server during configuration of global settings.

Security Requirements
To ensure your deployment is protected from internal and external threats (depending on your network configuration), Citrix strongly recommends you use SSL certificates and enable SSL encryption when deploying App Studio in a production environment. Using SSL ensures the confidentiality, authentication, and integrity of session data. When using SSL with App Studio, the SSL certificates are used to secure connections to the App Studio configuration service and the App Studio console, which are both hosted on the same server. To use SSL with App Studio, install an SSL certificate on each server you prepare and configure as an App Studio configuration server. The certificate you install must specify the server's common name which matches the server's FQDN. You can specify that App Studio use the installed certificate during the server configuration process described in the topic Installing and Configuring Citrix App Studio.

User Account Requirements


The user account you use to configure your App Studio environment must meet the following requirements:
q

Have permission to create databases on the database server. Have permissions to connect to the database server using PowerShell remoting. This requirement is met when the database server resides in the same domain as the other servers in the App Studio environment. Have access and write permissions to the network file share where the XenApp 6.5 installation media resides.

The user account you designate as the Global Domain Administrator when configuring global settings for your environment must meet the following requirements:
q

Be a local administrator on all XenApp servers. Have permission to create Active Directory objects and to move machines between Computer folders and organizational units (OUs).

1136

PowerShell Execution Policy and Remoting Requirements


To facilitate remote administration, all servers in the App Studio environment, including the database server, must have PowerShell remoting enabled. Additionally, certain servers in the App Studio environment must have the PowerShell execution policy set to AllSigned. Note: By default, WinRM 2.0 uses the ports 5985 for HTTP traffic and 5986 for HTTPS traffic. If you are using firewalls between the App Studio configuration server and the other servers in your deployment, ensure these ports are enabled.

To set the PowerShell execution policy


Before you install App Studio, set the PowerShell execution policy on the required servers by using Group Policy. To do this, use the Group Policy Management Console to configure the Turn on Script Execution policy setting. 1. On a server joined to the domain, open the Group Policy Management Console (gpmc.msc) and create a new Group Policy Object (GPO) or edit an existing one. This GPO should be associated with the following servers in the App Studio environment:
q

App Studio configuration server XenApp controllers and session hosts Web Interface server

Database server hosting the XenApp farm databases 2. From the Group Policy Management Editor, navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell.
q

3. Right-click Turn on Script Execution and select Edit. 4. Select Enabled and then, under Options, select Allow only signed scripts.

To configure PowerShell remoting with Group Policy


You can configure PowerShell remoting on all servers in the domain by using Group Policy. To do this, use the Group Policy Management Console to enable the WinRM service, configure listeners, set the amount of session memory available, and provide a list of trusted hosts. You will also need to configure the WinRM service to start automatically and ensure Windows Firewall allows traffic through the ports assigned to WinRM.

1137

PowerShell Execution Policy and Remoting Requirements 1. On a server joined to the domain, open the Group Policy Management Console (gpmc.msc) and create a new Group Policy Object (GPO) or edit an existing one. This GPO should be associated with all servers in the App Studio environment. 2. From the Group Policy Management Editor, navigate to Computer Configuration > Policies > Administrative Templates > Windows Components. 3. Use the following table to configure the required policy settings:

Setting Location & Name Windows Remote Management (WinRM) > WinRM Service Windows Remote Management (WinRM) > WinRM Client Windows Remote Shell

Policy Setting

Setting Values

Allow automatic configuration of listeners Trusted Hosts

Enabled. To configure WinRM to listen on all addresses, type an asterisk (*) in the IPv4 Filter and IPv6 Filter fields. Enabled.

In TrustedHostsList, type an asterisk (*) to indicate all hosts ar trusted. Enabled. In MaxMemoryPerShellMB, type 1000.

Specify maximum amount of memory in MB per Shell

Specify q maximum Enabled. number of q remote shells In MaxShellsPerUser, typing 0 indicates an unlimited number per user of shells. 4. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services. 5. Double-click the Windows Remote Management service and select the following options:
q

Define this policy setting

q Automatic 6. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security > Inbound Rules.

7. Right-click Inbound Rules and select New Rule. 8. In the New Inbound Rule Wizard, on the Rule Type page, select Predefined and then select the Windows Remote Management rule. Click Next. 9. On the Predefined Rules page, accept the defaults and click Next.

1138

PowerShell Execution Policy and Remoting Requirements 10. On the Action page, ensure Allow the connection is selected and click Finish. 11. To apply the settings, on each server, open a PowerShell command window and run gpupdate.

1139

Deploying Citrix App Studio


A minimal App Studio deployment consists of the following elements:
q

At least one App Studio configuration server, where the App Studio Configuration Service and Web console reside. You use the console to manage farms, workloads, resources, and tenants. At least one XenApp farm consisting of two XenApp controllers (a primary controller and a backup controller) to provide data collection. At least one XenApp server hosting desktops and applications for tenant access. At least one Web Interface server to provide tenants access to hosted desktops and applications. At least one server running SQL Server 2008 R2, with both SQL Native authentication and Windows integrated authentication enabled. This server hosts the databases created for the App Studio deployment and for XenApp farms.

New Deployments
Creating a new App Studio deployment consists of the following tasks: 1. Install and configure the App Studio configuration server. 2. Create the deployment's initial farm and workload catalogs. 3. Create the deployment's initial farm and add XenApp controllers to the farm catalog. 4. Add XenApp session hosts to the workload catalog. 5. Add a Web Interface server to the deployment. 6. Make hosted resources available for tenant subscription. 7. Create tenants and subscribe them to services. You can then use the App Studio dashboard to manage your deployment. The App Studio dashboard displays information at-a-glance about your deployment and provides quick links for performing common administrative tasks. For more information, see the topic Working with the App Studio Console.

1140

Install and Configure

Existing Deployments
At some point in the life of your deployment, you might need to add or update services, ensure high availability of resources, or delegate administration. Expanding your deployment might consist of the following tasks:
q

Add another App Studio configuration server to increase resiliency of your deployment. Create a new version of a workload catalog to update existing session hosts or introduce new services. Create additional App Studio administrators to manage your deployment. You can also create helpdesk administrators to enable certain users to monitor assigned tenants and troubleshoot deployment issues using Desktop Director. Integrate App Studio with Citrix CloudPortal Services Manager to provision XenApp resources as services to customers and resellers.

1141

Installing and Configuring Citrix App Studio


To install and configure the App Studio configuration server, you perform the following tasks:
q

Install the App Studio software on the server designated the configuration server. Configure the App Studio configuration server for a new or existing deployment.

To ensure high availability of your deployment, you join additional App Studio configuration servers to your deployment. These servers share the same configuration database, so if any server becomes unavailable, your deployment remains online and tenants can continue accessing their subscriptions. For optimal availability and resiliency for App Studio, ensure that:
q

The App Studio database uses appropriate high availability and resiliency measures, such as regular backups and replication. There is more than one App Studio configuration server, none of which share a single point of failure. For example, if two virtual machines act as configuration servers, they should not be on the same hypervisor unless it is configured for high availability (for example, Citrix XenMotion). All XenApp farms that App Studio manages use at least two controllers. All XenApp farm databases use appropriate high availability and resiliency measures. All workloads are sized to at least two workload machines, neither of which share a single point of failure. Ideally, these workload machines are located on a hypervisor with high availability features enabled.

To install the App Studio configuration server


1. On the server designated the App Studio configuration server, double-click Setup.exe from the Citrix App Studio installation media. After a brief initialization period, the Citrix App Studio Setup wizard appears. Click Get Started. 2. Accept the end-user license agreement and click Next. 3. On the Ready to install screen, click Install. The Installing components screen displays the progress of the installation. 4. When the installation process is finished, click Close. The Citrix App Studio Server Configuration wizard appears.

1142

Installing and Configuring Citrix App Studio

To configure the App Studio configuration server for a new deployment


1. On Welcome screen of the Citrix App Studio Server Configuration wizard, click Get Started. 2. Click Create a new deployment. 3. On the Database Information screen, enter the following information and then click Next:
q

In Database name, type the name of the configuration database. In Database server name, type the name of the database server. In Database user name and Database password, type the SQL Server Authentication credentials of the database user.

Note: If you specify a database that has not yet been created, App Studio creates the database as part of the configuration process. If you do not have sufficient permissions to create databases in your organization, click Display the database initialization script. Your database administrator can use the script that appears to create a database for use with Citrix App Studio. 4. On the SSL information screen, select one of the following options and then click Next:
q

Select Use SSL if you are deploying the App Studio server in a production environment. Click Browse to select the SSL certificate you want to use. Select Don't use SSL if you are deploying the App Studio server in a test environment and do not require SSL to be enabled.

Note: Choosing this option allows App Studio to transmit sensitive information, including domain administrator credentials, in plain text across the network. Before selecting this option, ensure you are using an isolated test environment with appropriate firewalls in place for your App Studio deployment. 5. On the Update your App Delivery Tools image screen, to replace the original XenApp 6.5 App Delivery Setup Tools files with more recent files from the App Studio installation media, perform the following actions and then click Next: a. Leave the Update App Delivery Setup Tools on XenApp installation media option selected. b. In Path to XenApp installation media, type the network path to the XenApp installation directory. Note: This update is required only once for your deployment. Clear this option if this update has already occurred. 6. On the Ready to configure screen, click Configure.

After configuration finishes, click Close. Continue configuring your new deployment by launching the App Studio Web console and configuring the global settings. 1143

Installing and Configuring Citrix App Studio

To configure the App Studio configuration server for an existing deployment


Before joining additional App Studio configuration servers to a deployment, ensure you have configured the global settings using the primary configuration server with which you created the deployment. If you attempt to join additional configuration servers without first configuring the new deployment's global settings, the servers will fail to join the deployment. Additionally, ensure at least one configuration server in the deployment is online before joining additional servers. This ensures the server can acquire the information necessary to join the deployment. 1. On the server designated the App Studio configuration server, install the App Studio software as instructed in To install the App Studio configuration server. When the installation finishes, the App Studio Server Configuration wizard appears. 2. On Welcome screen of the Citrix App Studio Server Configuration wizard, click Get Started. 3. Select Join an existing deployment. 4. On the Database Information screen, enter the following information and then click Next:
q

In Database name, type the name of the configuration database for the deployment you want to join. In Database server name, type the name of the database server.

In Database user name and Database password, type the SQL Server Authentication credentials of the database user. 5. On the SSL information screen, select one of the following options and then click Next.
q

Note: You must select the same SSL option that you selected when the deployment was originally created. App Studio does not support environments in which some servers employ SSL while others do not.
q

Select Use SSL if the existing environment has been configured to use SSL. Click Browse to select the SSL certificate you want to use.

Select Don't use SSL if the existing environment has been configured for unencrypted data transmission. 6. On the Ready to configure page, click Configure.
q

After configuration finishes, click Close. When you log on to the App Studio Web console, the dashboard for the deployment appears.

1144

To configure App Studio global settings


You configure global settings after installing the initial App Studio configuration server in your deployment. These settings include the name of the Citrix License Server, the credentials for the global administrator account, and the paths to the Active Directory organizational units (OUs) where shared Web Interface servers and decommissioned server reside. During this process, you also create the initial farm and workload catalogs where App Studio places the XenApp controllers and session hosts that are added to the deployment. When creating the farm and workload catalogs, you specify the import OUs where you want App Studio to place the farm servers and session hosts that you add to your deployment. Important: When specifying these OUs, ensure they do not reside within another import OU. Otherwise, App Studio will not register the imported servers appropriately. For example, if the farm import OU resides within the workload machine import OU, and you add farm servers to your deployment, App Studio registers the servers as workload machines instead. However, if the farm import OU and workload machine import OU reside as peers within the shared allocation OU, then App Studio correctly registers any farm servers you add to the deployment. After setting up your deployment, you can access the global settings at any time from the App Studio Home page or from the Infrastructure page. From the Home page, under Actions, click Global configuration settings. From the App Studio menu bar, click System > Infrastructure > Edit Global Settings. Before configuring the global settings, ensure you have created the shared allocation OU in Active Directory. If this OU is not present when you configure the global settings, App Studio cannot validate its location and returns an error. 1. Launch the App Studio Web console by clicking Start > All Programs > Citrix > Citrix App Studio and enter the credentials of the domain administrator used to install the configuration server. 2. From the Home page, click Configure Citrix App Studio. 3. On the Global Settings page, enter the following information and then click Next:
q

License Server: The name of the Citrix License Server you want to use. Shared allocation domain: The Active Directory domain to which all servers in the deployment belong. Shared allocation OU: The Active Directory OU that acts as the root OU of your App Studio deployment. Shared infrastructure import OU: The Active Directory OU where App Studio places shared Web Interface servers that you add to the deployment. This field is populated automatically based on the shared allocation OU; however, you can modify this entry to reflect any OU in the shared allocation domain.

1145

To configure App Studio global settings


q

Decommisioned Server OU: The Active Directory OU where servers removed from App Studio allocation reside. This field is populated automatically based on the shared allocation OU; however, you can modify this entry to reflect any OU in the shared allocation domain. Global Domain Administrator: Credentials for the domain administrator account you want to use. This account must have permission to use PowerShell remoting to access all computers in the shared allocation domain you specified, add Active Directory objects, and move computers between OUs. User names are specified in "Domain\Username" format.

4. On the Create Farm Catalog page, enter the following information and then click Next:
q

In Name, enter a name for the farm catalog. In Description, enter a brief description of the farm catalog. In Tags, type labels, separated by commas, by which you can identify the purpose of the farm catalog. You can use these tags later on to allocate resources. In Maximum workload machines per farm, enter the maximum number of XenApp session hosts allowed in each farm in the catalog.

In Farm Import OU (relative to shared domain), enter the path to the Active Directory OU where you place the XenApp controllers that Citrix App Studio will add to the farm catalog. Although this field populates automatically based on the shared allocation OU and the catalog name, you can modify this field to reflect any OU in the shared allocation domain. 5. On the Farm Catalog Database Credentials page, select the authentication type for the farm database, enter the appropriate credentials and click Next.
q

Note: For this release, only Windows Authentication is supported. Citrix App Studio uses these credentials to join XenApp session hosts to a farm from this farm catalog. Therefore, all farms in the catalog must use these credentials, even if they use different database servers or instances. Additionally, ensure the credentials entered are valid as App Studio cannot validate them until farms and workload machines are imported. 6. On the Create Workload Catalog page, enter the following information and then click Next:
q

In Name, type the name of the catalog. In Description, enter a brief description of the workload catalog. In Tags, type labels, separated by commas, by which you can identify the purpose of the workload catalog. You can use these tags later on to allocate resources.

In Workload Machine Import OU (relative to shared domain), enter the path to the Active Directory OU where you place the XenApp session hosts that Citrix App Studio will add to the workload catalog. Although this field populates automatically based on the shared allocation OU and the catalog name, you can modify this field to reflect any OU in the shared allocation domain. 7. Click Finish. Citrix App Studio completes the configuration and returns you to the Welcome page.
q

1146

To configure App Studio global settings After configuring global settings, App Studio initiates workflows that create the OUs you specified. You can view these workflows by clicking Workflows from the console menu bar. After these workflows finish, continue setting up your App Studio deployment by adding farms, XenApp session hosts, and Web Interface servers.

1147

Creating and Modifying Farm Catalogs


A farm catalog consists of XenApp controllers that are configured identically, including having the same patches or updates applied. If you attempt to create a farm using controllers that are not identical to all others in the farm catalog, App Studio will not accept them into your deployment. Before you create a farm, consider whether you want to use an existing farm catalog or need to create a new farm catalog. If you need to add a farm that includes features that you want to use to differentiate services, then you must create a new farm catalog. For example, you want to add a farm that provides a high degree of availability to tenants.

To add a new farm catalog


1. From the App Studio Home page, under Actions, click Create a new farm catalog. The Farm Catalog wizard appears. 2. On the Create Farm Catalog screen, enter the following information and then click Next:
q

In Name, enter a name for the farm catalog. In Tags, type labels, separated by commas, by which you can identify the purpose of the farm catalog. In Maximum workload machines per farm, enter the maximum number of XenApp servers allowed in each farm in the catalog.

In Farm Import OU (relative to shared domain), enter the path to the Active Directory OU where you place the XenApp controllers that Citrix App Studio will add to the farm catalog. 3. On the Farm Catalog Database Credentials screen, select the authentication type for the farm database, enter the appropriate credentials and click Next.
q

4. On the Summary screen, click Finish. The new farm catalog appears on the Farm Catalogs page.

1148

Creating and Modifying Farm Catalogs

To modify farm catalog information


1. From the menu bar of the App Studio console, click Provisioning > Farm Catalogs. The Farm Catalogs page appears. 2. Click the name of the farm catalog you want to modify. The farm catalog page appears. 3. Click Edit. The Edit Farm Catalog screen appears. 4. Modify the information in each field as desired. 5. Click Save Farm Catalog to save your changes.

To remove a farm catalog from the App Studio deployment


You can remove farm catalogs in the following ways:
q

Delete: App Studio executes workflows to remove the selected farm catalog and any associated farms from the deployment. The Farm Catalogs console page continues to display the farm catalog, indicating it is being deleted. When the workflows are completed, the Farm Catalogs page displays only the remaining catalogs. Force Delete: If deletion is unsuccessful, you can forcibly delete the farm catalog. The deletion workflows that App Studio executes might be unsuccessful if, for example, any of the farms in a farm catalog is unreachable over the network. Also, deletion might be unsuccessful if any of the farms in a catalog have a corrupt IMA database that App Studio cannot remove appropriately. Forcibly deleting the farm catalog removes the catalog and all associated farms from the deployment without attempting any further cleanup of the deployed farms. Use this option only if the XenApp controllers are unresponsive or otherwise cannot complete the deletion process.

To monitor the deletion workflows, from the App Studio menu bar, click System > Workflows. 1. From the menu bar of the App Studio console, click Provisioning > Farm Catalogs. The Farm Catalogs page appears. 2. Click the name of the farm catalog you want to remove. The farm catalog page appears. 3. To delete the farm catalog, perform the following actions: a. Click Delete. The Delete Farm Catalog screen appears, confirming you want to delete the farm catalog. b. Click Delete Farm Catalog to remove the catalog from the App Studio deployment. App Studio removes the farm catalog and any farms it contains from the deployment. Afterward, the Farm Catalogs console page displays only the remaining catalogs. 4. If deleting the farm catalog results in an error, perform the following actions:

1149

Creating and Modifying Farm Catalogs a. Click Force Delete. A message appears, confirming you want to forcibly delete the farm catalog. b. Click Forcibly Delete Farm Catalog. App Studio removes the farm catalog and any farms it contains from the deployment. Afterward, the Farm Catalogs console page displays only the remaining catalogs.

1150

To add farms to a farm catalog


After completing initial setup of the Citrix App Studio configuration server, you can add farms to the farm catalog. This includes configuring XenApp controllers and setting up the farm database. To create a farm, you use the App Delivery Setup Tools to run the New-CamFarm script. After the farm is added to the farm catalog, you can create additional farms for other tenants using the App Delivery Tools or by using a XenServer snapshot of the servers in the first farm. Important: When using the App Delivery Setup Tools to deploy additional farms, you must ensure that the XenApp controllers are configured identically to the first controllers added to the farm catalog. This includes hardware, software, operating system version, and operating system updates and patches. If machine configurations differ, importing to the farm catalog might fail. When executed, the New-CamFarm script prompts you for specific information related to your deployment, such as farm catalog OU path, configuration server address, and Citrix Licensing server. As a deployment aid, App Studio can show you the actual information needed for each prompt, based on the farm catalog you select and the details you provided when you configured App Studio. To view this information, you can perform either of the following actions:
q

For a new deployment, from the App Studio Home page, in the Add farms section, click How do I do this? For an existing deployment, from the App Studio console menu bar, click Provisioning > Farm Catalogs, and then click the name of the farm catalog where you want to add the farm. From the farm catalog console page, click How do I add farms to this farm catalog?

When you click either of these links, a new browser tab (or window) opens and displays the deployment-specific information you can supply at each script prompt. 1. On the App Studio configuration server, click Start > Citrix > App Delivery Setup Tools > App Delivery Setup Tools PowerShell (x64). 2. Type the command .\New-CamFarm. 3. When prompted, provide the following information. Where applicable, default selections are highlighted in yellow. You can accept these defaults by pressing ENTER.
q

ConfigServiceAddress: Enter the name of the server hosting the App Studio configuration service. CanonicalOUPath: Enter the farm import OU that you specified when you configured the App Studio global settings and created the initial farm catalog for your deployment. Enter the network share where the XenApp DVD is located: Enter the network path where the XenApp installation media is located. Example: \\path\to\XenApp\dvd.

1151

To add farms to a farm catalog


q

XenApp Edition: Select P for XenApp Premium Edition (default) as this is the only supported edition of XenApp. Enter the name of the farm to be created: Enter the name of the XenApp farm you want to create. Enter the name of the Windows Active Directory Domain to which these servers belong: Enter domain where the farm servers are located. Enter the name of the server where the SQL DB is hosted: Enter the name of the SQL database server. Database Authentication: Select Windows (default) or SQL authentication. Database Creation: Specify whether or not you want to create the database during farm setup and the database user account you want to use. (default is Y) Enter the name of the server designated as the primary data collector for the farm: Enter the name of the server to be configured as the primary XenApp controller. Enter the name of the server designated as the backup data collector for the farm: Enter the name of the server to be configured as the backup XenApp controller. Install and Configure a Web Interface Server: Specify whether or not you want to configure a unique Web Interface server during farm setup. Select N (default) to use shared Web Interface infrastructure servers in your environment. Install and Configure a separate XML Server: Specify whether or not you want to configure a separate instance of the XML Service for the farm. Select N (default) unless you know the volume of application launch requests will require a dedicated server to handle the load. Enter the name of the Licensing Server to be used with the farm: Enter the name of the Citrix License Server. Change ACLs of XenApp Tools: Specify whether or not you want to change the access control lists (ACLs) of the XenApp command line tools to restrict tenant access. Select Y (default) if you intend to provision services to tenants using shared servers.

The script installs XenApp 6.5 with App Studio extensions on the servers you specified, and then moves the servers to the farm catalog's import OU.

After you add the farm, workflows are initiated that evaluate the XenApp controllers and add them to the appropriate farm catalog. These workflows might take several minutes to complete. You can monitor them by clicking System > Workflows. If you add the farm to a new deployment, the App Studio Home page refreshes and indicates the XenApp controllers are part of the deployment. Continue setting up your deployment by adding Web Interface servers and XenApp session hosts. When all required components have been added, click Setup complete! Go to the Dashboard to view the App Studio dashboard and manage your deployment.

1152

To add farms to a farm catalog If you add the farm to an existing deployment, the XenApp controllers appear on the Farms tab of the farm console page.

1153

Creating and Modifying Workload Catalogs


A workload catalog consists of a group of XenApp session hosts, all with the same configuration and the same installed applications. This ensures there are no variations among session hosts when provisioning services, enabling tenants' users to launch advertised applications and desktops when needed. Workload catalogs are not bound to any specific farm in the App Studio deployment. App Studio moves session hosts to any farm as needed to satisfy the allocation requirements of the workloads created.

To add a new workload catalog


After you set up the first workload catalog in your App Studio deployment, you can create additional workload catalogs. You might set up these catalogs for servers that host different applications or that have been configured differently than servers in the first workload catalog. 1. From the App Studio Home page, under Actions, click Create a new workload catalog. The Workload Catalog wizard appears. 2. On the New Workload Catalog screen, enter the following information:
q

In Name, type the name of the catalog. In Tags, type labels, separated by commas, by which you can identify the purpose of the workload catalog.

In Workload Machine Import OU (relative to shared domain), enter the path to the Active Directory OU where you place the XenApp session hosts that Citrix App Studio will add to the workload catalog. 3. Click Create Workload Catalog. The Workload Catalogs console page refreshes and displays the new catalog in the list.
q

1154

Creating and Modifying Workload Catalogs

To modify workload catalog information


1. From the menu bar of the App Studio console, click Provisioning > Workload Catalogs. The Workload Catalogs page appears. 2. Click the name of the workload catalog you want to modify. The Edit Workload Catalog screen appears. 3. Modify the information in each field as desired. 4. Click Save Workload Catalog to save your changes.

To remove a workload catalog from the App Studio deployment


You can remove workload catalogs in the following ways:
q

Delete: App Studio executes workflows to remove the selected workload catalog and all associated session hosts, including workloads and advertisements. This includes moving associated session hosts to the Decommissioned Servers OU. The Workload Catalogs console page continues to display the workload catalog, indicating it is being deleted. When the workflows are completed, the Workload Catalogs page displays only the remaining catalogs. Force Delete: If deletion is unsuccessful, you can forcibly delete the workload catalog. The deletion workflows that App Studio executes might be unsuccessful if, for example, any of the session hosts in a workload catalog are unreachable over the network. This might occur if a session host is taken offline prior to deleting the workload catalog. Forcibly deleting the workload catalog removes the catalog and all associated session hosts from the deployment without any further cleanup activity. Use this option only if the associated session hosts are unresponsive or otherwise cannot complete the deletion process.

To monitor the deletion workflows, from the App Studio menu bar, click System > Workflows. 1. From the menu bar of the App Studio console, click Provisioning > Workload Catalogs. The Workload Catalogs page appears. 2. Click the name of the workload catalog you want to remove. The workload catalog page appears. 3. To remove the workload catalog, perform the following actions: a. Click Delete. A message appears, confirming you want to remove the catalog. b. Click Delete Workload Catalog. App Studio removes the catalog from the App Studio database and the workload machine page no longer lists the catalog. 4. If deleting the workload catalog results in an error, perform the following actions: a. Click the Workflows tab and cancel any deletion workflows for the catalog that are in Pending or Ready states.

1155

Creating and Modifying Workload Catalogs b. Click Force Delete. A message appears, confirming you want to forcibly delete the workload catalog. c. Click Forcibly Delete Workload Catalog. App Studio removes the workload catalog and any session hosts it contains from the deployment. Afterward, the Workload Catalogs console page displays only the remaining workload catalogs.

1156

Adding and Removing Session Hosts


After you add farms to the farm catalog, you can add XenApp session hosts to the workload catalog using the New-CamSessionHost script included in the App Delivery Setup Tools. When you add session hosts, you specify the workload catalog to which the servers belong. All session hosts in a workload catalog must be configured identically, including having the same updates or patches applied. Important: If you attempt to add session hosts that are not identical to all others in the workload catalog, App Studio will not accept them into your environment. If you need to add session hosts that have differing capabilities or applications, you must create a separate workload catalog for them. When executed, the New-CamSessionHost script prompts you for specific information related to your deployment, such as the workload catalog OU path. As a deployment aid, App Studio can show you the actual information needed for each prompt, based on the workload catalog you select. To view this information, perform either of the following actions:
q

For a new deployment, from the App Studio Home page, in the Add machines section, click How do I do this? For an existing deployment, from the menu bar of the App Studio console, click Provisioning > Workload Catalogs and then click the name of the workload catalog where you want to add the session host. From the workload catalog console page, click How do I add machines to this workload catalog?

When you click either of these links, a new browser tab (or window) opens and displays the deployment-specific information you can supply at each script prompt.

1157

Adding and Removing Session Hosts

To add XenApp session hosts


1. Click Start > Citrix > App Delivery Setup Tools > App Delivery Setup Tools PowerShell (x64). 2. Type the command .\New-CamSessionHost. 3. When prompted, provide the following information:
q

SessionHosts[0], SessionHost[1], etc.: Enter the name of the XenApp session host. When you press ENTER after each entry, you are prompted to enter another session host. To progress to the next part of the script, leave the prompt empty and press ENTER. XenAppDVDPath: Enter the network path where the XenApp installation media is located. Example: \\path\to\XenApp\dvd

CanonicalOUPath: Enter the path in Active Directory to the workload machine import OU where you want to add the session hosts. Example: my-domain.com/CloudAppManagement/Workload Catalogs/Office Apps The script installs XenApp 6.5 with App Studio extensions on the servers you specified and then moves the servers to the workload machine import OU.
q

After you add new session hosts to your deployment, workflows are initiated that evaluate the session hosts and add them to the workload catalog. If the workload catalog is overallocated, the session hosts are moved to the appropriate workload OU. These workflows might take several minutes to complete. You can monitor them by clicking System > Workflows. If you add the session hosts to a new deployment, the App Studio home page refreshes and indicates the session hosts are part of the deployment. Continue setting up your deployment by adding Web Interface servers and XenApp farms. When all required components have been added, click Setup complete! Go to the Dashboard to view the App Studio dashboard and manage your deployment. If you add the session hosts to an existing deployment, the servers appear on the Workload Machines tab of the workload catalog's console page.

To remove XenApp session hosts from the App Studio deployment


You can remove XenApp session hosts from your App Studio deployment in the following ways:
q

Drain: Session hosts that are allocated to a workload are drained before removal. New connections are refused and users can reconnect to their existing sessions and terminate them when finished. When all user sessions have ended, App Studio moves the session host to the Decommissioned Servers OU and removed its entry from the App Studio database.

1158

Adding and Removing Session Hosts


q

Delete: Session hosts that are not allocated to any workloads are deleted. App Studio moves the session host to the Decommissioned Servers OU and removes its entry from the App Studio database. Force Delete: If deletion is unsuccessful, you can forcibly delete the session host. By doing this, you remove any associated workflows that have not yet completed. Therefore, you should use this option only if the session host is unresponsive or otherwise cannot complete the deletion process.

1. From the menu bar of the App Studio console, click Provisioning > Workload Catalogs. The Workload Catalogs page appears. 2. Click the name of the workload catalog containing the session host you want to remove. The workload catalog page displays the workload machines assigned to the selected catalog. 3. If the session host you want to remove is allocated to a workload, perform the following actions: a. Click Drain. A message appears, confirming you want to drain the selected session host. b. Click Drain Workload Machine. The workload machine page refreshes and notes the selected session host is being drained. Afterward, App Studio deletes the session host. 4. If the session host you want to remove is unallocated, perform the following actions: a. Click Delete. A message appears, confirming you want to delete the selected session host. b. Click Delete Workload Machine. The workload machine page refreshes and notes the selected session host is being deleted. 5. If the session host is unresponsive or deleting the session host results in an error, perform the following actions: a. Click the Workflows tab and cancel any deletion workflows for the session host that are in Pending or Ready states. b. Click Force Delete. A message appears, confirming you want to forcibly delete the session host. c. Click Forcibly Delete Workload Machine. The workload machine page refreshes and displays only the remaining session hosts.

1159

Adding and Removing Web Interface Servers


In your App Studio deployment, Web Interface servers are considered infrastructure resources that can be shared among several tenants or dedicated to a specific tenant. To add Web Interface servers to your deployment, you use the App Delivery Setup Tools to run the New-CamWIServer script. Important: Before adding Web Interface servers to your deployment, ensure the servers have the .NET Framework 3.5.1 Windows server role installed, as noted in System Requirements for Citrix App Studio. If this server role is not installed, the New-CamWIServer script fails. When executed, the New-CamWIServer script prompts you for specific information related to your deployment, such as infrastructure import OU path and configuration server address. As a deployment aid, App Studio can show you the actual information needed for each prompt, to add shared Web Interface servers to your deployment. To view this information, perform either of the following actions:
q

For a new deployment, from the App Studio Home page, in the Add Web Interface servers section, click How do I do this? For an existing deployment, from the menu bar of the App Studio console, click System > Infrastructure and then click How do I add shared infrastructure machines?

When you click either of these links, a new browser tab (or window) opens and displays the deployment-specific information you can supply at each script prompt.

To add Web Interface servers to the App Studio deployment


Adding shared or private Web Interface servers depends on the infrastructure import OU that you specify when you run the New-CamWIServer script included in the App Delivery Setup Tools. If you specify the shared infrastructure import OU, the Web Interface server is available to all tenants provisioned with shared or private sites. If you specify the infrastructure import OU of a specific tenant, the Web Interface server is available only to that tenant. 1. From the App Studio configuration server, click Start > Citrix > App Delivery Setup Tools > App Delivery Setup Tools PowerShell (x64). 2. Type the command .\New-CamWIServer. 3. When prompted, enter the following values:

1160

Adding and Removing Web Interface Servers


q

WIServerName: Enter the name of the server on which you want to install Web Interface. XenAppDVDPath: Enter the network path to the share containing the XenApp DVD installation media. This path must be accessible using the name you specify from a session on the target machine. Example: \\path\to\XenApp\dvd ConfigSvcAddress: Enter the name of the server hosting the App Studio configuration service. CanonicalOUPath: To add the server as a shared Web Interface server, enter the shared infrastructure import OU that you specified when you configured the App Studio global settings for your deployment. To add the server as a private Web Interface server, enter the tenant's infrastructure import OU that you specified when you created the tenant.

The script installs Web Interface with App Studio extensions and moves the machine to the appropriate infrastructure import OU. This process can take several minutes to complete. You can monitor the status by clicking System > Workflows. Shared Web Interface servers appear on the Infrastructure page of the App Studio console. Private Web Interface servers appear on the Private Infrastructure Machines tab of the tenant's console page.

To remove a Web Interface server from the App Studio deployment


When you remove a Web Interface server from your deployment, App Studio moves the server to the Decommissioned Servers OU in Active Directory and removes the server's entry from the App Studio database. If your initial attempt to remove a Web Interface server is unsuccessful, you can forcibly delete it. By doing this, you also remove any associated workflows that have not yet completed. Use this option only if the Web Interface server is unresponsive or otherwise cannot complete the deletion process. To restore a deleted server, move the server from the Decommissioned Servers OU to the Shared Infrastructure Import OU. App Studio detects the addition to the OU and adds the server to the Infrastructure page of the console. 1. From the menu bar of the App Studio console, perform one of the following actions:
q

To remove a shared Web Interface server, click System > Infrastructure.

To remove a private Web Interface server, click Tenants, select the appropriate tenant, and then click the Private Infrastructure Machines tab on the tenant's console page. The Infrastructure page appears, listing all the Web Interface servers in the deployment.
q

2. To delete a Web Interface server, perform the following actions:

1161

Adding and Removing Web Interface Servers a. For the Web Interface server you want to remove, click Delete. A message appears, confirming you want to remove the Web Interface server. b. Click Delete Infrastructure Machine. The console page refreshes and notes the selected Web Interface server is being deleted. 3. If the Web Interface server is unresponsive to the deletion workflows or if deleting the Web Interface server results in an error, perform the following actions: a. Click the Workflows tab and cancel any deletion workflows for the Web Interface server that are in Pending or Ready states. b. Click Force Delete. A message appears, confirming you want to forcibly delete the Web Interface server. c. Click Forcibly Delete Infrastructure Machine. The console page refreshes and no longer lists the selected Web Interface server. When the deletion workflow is complete, the console page no longer lists the Web Interface server.

1162

Managing Your App Studio Deployment


After your App Studio deployment is complete, you can manage tenants, services, and subscriptions. Managing your deployment includes the following tasks:
q

Get acquainted with the App Studio console for managing your deployment. Learn how to use workflows to monitor the processes in your deployment. Make hosted resources available for tenant subscription. Create tenants and subscribe them to services. Create a new version of a workload catalog to update existing session hosts or introduce new services. Create additional App Studio administrators to manage your deployment. You can also create helpdesk administrators to enable certain users to monitor assigned tenants and troubleshoot issues using Desktop Director. Add more App Studio configuration servers to increase the availability and resiliency of your deployment.

If you use Citrix CloudPortal Services Manager to provide services to customers and resellers, you can enable App Studio to provide hosted applications and desktops alongside your other managed services. For more information, see the topic Providing Applications and Desktops to Customers with Citrix CloudPortal Services Manager.

1163

Working with the App Studio Console


The App Studio console is a Web-based console that enables you to manage your App Studio deployment.

Menu Bar
The menu bar appears at the top of console and enables you to access all console pages. The menu bar is composed of the following sections:
q

Home: Displays the console dashboard. System: Provides access to the Infrastructure and Workflows pages. On the Infrastructure page, you can view Web Interface servers, manage administrators, and access App Studio global settings. On the Workflows page, you can monitor App Studio processes. Provisioning: Provides access to the Workload Catalogs and Farm Catalogs pages where you can create new catalogs and manage member servers. Services: Provides access to the Advertisements and Workloads pages. On the Advertisements page, you can make new services available to tenants and subscribe tenants to services. On the Workloads page, you can view the workloads associated with subscriptions and manage workload capacity. Tenants: Displays the list of all tenants in the deployment and enables you to add new tenants and create subscriptions.

Dashboard
The dashboard is the home page of the App Studio console and provides an at-a-glance view of your App Studio deployment. The dashboard is composed of the following sections:
q

Workflows Provisioning (farm catalogs and workload catalogs) Tenants Services (advertisements and workloads)

These sections provide overviews of the processes, components, services, and tenants in your deployment. Each section displays the following types of notifications:
q

Active, in-progress, or failed workflows

1164

Working with the App Studio Console


q

Errors or warnings associated with a tenant, service, workload, or catalog Conditions that require your attention such as overallocated workload catalogs, tenants who are not yet subscribed to services, advertisements that do not yet have subscriptions, or empty farm or workload catalogs Status of certain workflows such as transitioning to a new version of a workload catalog

The Actions list, on the right side of the dashboard, provides one-click access to common tasks for administering your deployment. Clicking these links takes you to the appropriate console area to perform the selected task and, if required, launches the appropriate wizard. For example, clicking Manage administrators takes you to the Infrastructure page of the console where the Administrators tab displays a list of administrator users. Clicking Advertise new services takes you to the Advertisements console page and launches a wizard so you can select services and make them available to tenants.

1165

Understanding Workflows
A workflow consists of a set of PowerShell scripts that are executed when App Studio detects a specific action, such as creating an advertisement, adjusting the capacity of a workload, or adding users to a subscription. Workflows often consist of multiple steps. When you complete a task, App Studio logs the workflows that are initiated and displays information on the following console pages:
q

On the App Studio Home page, the total number of active workflows are displayed. Clicking this number takes you to the Workflows page. On the Workflows page (System > Workflows), App Studio displays a list of active workflows by default. On the Workflows tab located on the console page associated with a specific workload or farm catalog, a specific advertisement or workload, or a specific tenant. This tab also appears on the Infrastructure console page. For example, when you subscribe a tenant to an advertised service, the Workflows tab on the advertisement's console page displays the active workflows as they occur.

Workflow States
The following table describes the states that workflows assume as they are completed. Name Pending Ready Description The workflow is waiting for another workflow to finish before it runs. The workflow is ready to execute and will run the next time the agent polling interval happens. The workflow is currently executing. The workflow executed successfully. Workflows that finish successfully are displayed on the Workflows console page, in the History view. The workflow is in the process of being cancelled. If you cancel a workflow that is in Ready or Started states, App Studio waits for the agent to acknowledge that the workflow has been cancelled. In the event a workflow completes cancellation before the agent can acknowledge it, the workflow appears in the History view as Succeeded or Failed, as applicable, rather than Cancelled.

Running Succeeded

Cancelling

1166

Understanding Workflows Cancelled The workflow has completed cancellation. A cancelled workflow can block other workflows from executing until it is retried or superseded. See Resolving Workflow Issues for more information. A configuration change was made after the workflow was scheduled, rendering execution unnecessary. Other workflows waiting for this workflow to execute enter Ready states. Superseded workflows appear in the History view. The workflow did not execute successfully. Failed workflows can block other workflows from executing until it is retried or superseded. See Resolving Workflow Issues for more information.

Superseded

Failed

Using the Workflows Console Page


The Workflows console pages displays workflows in the following contexts: Current view The Current workflow view displays a list of all the workflows that are active at any given moment. You can sort this list alphabetically and filter according to the workflow's current status (Errors, Warnings, or Active). As the workflow progresses, its status changes. You can view this progress by clicking Refresh. To view the tasks included in the workflow, expand the workflow entry. When the workflow finishes, App Studio records it in the workflow history. History view App Studio maintains a record of every successful and unsuccessful workflow for the life of the deployment. To view this record, click the History option on the Workflows page. You can sort and filter this record according to the following criteria:
q

Sort by age: Newest First or Oldest First

q Filter by workflow result: Succeeded, Failed, Superseded, or Cancelled For each workflow entry, App Studio displays the state of each task in the workflow and the time and date at which the workflow completed or failed. App Studio also provides information about the actions that occurred in a successful workflow or why a workflow failed. To view this information, expand the workflow entry.

Resolving Workflow Issues


Workflow issues can arise in the following ways: Workflow failure

1167

Understanding Workflows When a workflow fails, App Studio records error information on the Workflows page. To view this information, expand the workflow entry. Workflow delays Some workflows take a long time to execute, such as when draining session hosts. Other workflows, such as editing a subscription, generally execute quickly but might appear to be delayed for some reason. When executing a workflow, the agent sends progress updates to App Studio at intervals until the workflow is completed, regardless of how much time is required. As long as the agent sends updates to indicate the workflow is still active, App Studio allows the workflow to continue. However, if the agent does not send updates, App Studio considers the workflow unresponsive and marks its entry on the Workflows console page with a Warning icon. After 60 minutes, App Studio terminates the workflow. If a workflow takes longer than expected to execute, you can cancel the workflow and retry it later. This allows you to troubleshoot and correct any issues that might be causing the delay. To cancel a workflow, click the Cancel button for the selected workflow entry. When all issues have been addressed, you can restart the workflow by clicking the Retry button. Note: You can cancel and retry only the workflows that appear in the Current view. You cannot retry failed workflows in the History view. Unresponsive agents If the agent responsible for executing the workflow has stopped responding, App Studio marks the workflow entry on the Workflows console page with a Warning icon. App Studio then elects another agent to execute the workflow, typically an agent in the affected XenApp farm. This process can take up to 20 minutes. If this interval passes and the agent is still unresponsive, you can cancel the workflow and retry it later. If a workflow fails or is cancelled, App Studio might prevent other workflows from running. This occurs because the workflow failure causes the deployment to be incorrectly or incompletely configured. To rectify this, perform the following actions:
q

Troubleshoot and correct any issues outside of App Studio. Examples include network outages, offline or overloaded servers, or issues involving Active Directory permissions. Afterward, you can retry the workflows that failed or were cancelled. Workflows are designed to perform only actions that have not yet been performed, so it is safe to retry partially completed workflows or to retry workflows after performing configurations outside of App Studio. After the workflow finishes, any Pending workflows are updated to Ready. If the problem cannot be resolved outside of App Studio, determine the configuration within App Studio that triggered the workflow and alter that configuration. Afterward, App Studio marks workflows that are no longer necessary as Superseded, even if those workflows have failed or have been cancelled. For example, if a catalog import OU specifies a location that App Studio does not (and should not) have permission to access, you can correct it by changing the import OU. App Studio supersedes the existing Update-ImportOU workflow and creates a new workflow targeting the corrected OU.

1168

To adjust workload capacity


Workloads are created when you advertise shared services or create subscriptions to advertised services and specify the capacity. When creating a workload, App Studio requires that you specify a capacity of at least one session host. After you create the workload, it is reused for any service that shares the same farm catalog, workload catalog, and tenant. Capacity refers to the number of session hosts that are allocated to the services and tenants hosted by the workload. You can adjust the capacity as needed to host more or fewer users or services. Workflows are then initiated that perform the following tasks:
q

If increasing capacity: Add session hosts to the farm and move them to the appropriate workload OU for the farm. If decreasing capacity: Drain session hosts to allow users to complete any open or disconnected sessions, remove the session hosts from the farm, and move the session hosts to the Decommissioned Servers OU.

Important: Before increasing the capacity of a workload, ensure there is a sufficient number of session hosts in the workload catalog for allocation. If you increase the capacity, but there are not enough session hosts in the catalog, App Studio reports that the workload and workload catalog are overallocated. To resolve this, import additional session hosts to the workload catalog OU. After App Studio detects these machines, the workflows for increasing capacity occur. 1. From the App Studio Home page, under Actions, click Manage workloads. The Workloads page appears. 2. Click the name of the workload whose capacity you want to adjust. The workload page appears. 3. Click Edit Capacity and then, in Capacity, enter the number of session hosts you want to allocate to the workload. 4. Click Save. The workload page refreshes to display the state of the active session hosts.

1169

To create a new version of a workload catalog


During the life of your deployment, you might want to update the session hosts in a workload catalog. For example, you need to apply a hotfix, add new applications, or upgrade to more efficient hardware. To do this, you perform the following tasks: 1. Prepare new servers with the updates you want to introduce to your App Studio deployment. For example, install new applications, apply patches, etc. 2. Using the App Studio console, create a new version of the workload catalog. App Studio creates a new workload machine import OU where the new session hosts will reside. 3. Import the new servers by running the New-CamSessionHost script. For more information, see To add XenApp session hosts. The restrictions that App Studio normally enforces when adding new session hosts to a workload catalog are relaxed when you create a new version of a workload catalog. App Studio accepts differences in installed applications, applied hotfixes, and hardware configuration such as memory and CPU because the new session hosts are imported to a different workload machine import OU. Important: In addition to the updates you install, you must ensure the new session hosts have exactly the same applications installed that are already being advertised in the original workload catalog. The executable path for each installed application must match that of the advertised application. Otherwise, the workload catalog will fail to update and the App Studio console will report that certain applications are missing. For example, if you are advertising Microsoft Word 2010 to users, you can update that advertisement to Microsoft Word 2010 SP1 because the path to WINWORD.EXE is the same in both versions. However, if you are advertising Microsoft Word 2007 to users, you cannot update that advertisement to Microsoft Word 2010 because the executable path is different in each version. Instead, you might include both Word 2007 and 2010, and advertise Word 2010 as a new application. After you create the new workload catalog version and import new session hosts, App Studio drains the original session hosts, allowing users to complete existing sessions and log off. When users log back on, App Studio directs them to the session hosts in the new catalog version. App Studio directs users to machines in the newest version of a workload catalog, regardless of the number of workload catalog versions you create. For example, if you create a V2 catalog and then, soon afterward, create a V3 catalog, App Studio directs users who log off machines in the V1 and V2 catalogs to machines in the V3 catalog for new sessions. When the session hosts from the original catalog version are fully drained, they are removed from the App Studio console and moved to the Decommissioned Servers OU. 1. From the menu bar of the App Studio console, click Provisioning > Workload Catalogs. The Workload Catalogs page appears.

1170

To create a new version of a workload catalog 2. Click the name of the workload catalog you want to update. The workload catalog page appears. 3. Click Create New Version. The Create New Version screen appears. 4. In Workload Machine Import OU, verify the path to the new OU. Note: By default, App Studio creates a new OU based on the workload catalog's original OU, but you can change this to reflect any OU in the shared allocation domain. The new OU must be different from the original OU so that App Studio can recognize the new version of the catalog and assign the appropriate session hosts. 5. Click Create New Version. The App Studio console displays the new workload catalog page.

After the new catalog version is created, you can import the session hosts that will reside in the new version's Workload Machine Import OU. For more information, see To add XenApp session hosts.

1171

Advertising Services to Tenants


You can make the desktops and applications residing on XenApp session hosts available to tenants through advertising. You can then subscribe tenants to these advertised services to provision access to their users. When you create an advertisement, you choose the farm catalog from which to allocate XenApp controllers, the workload catalog from which to allocate the session hosts hosting the advertised service, and the level of isolation you want to provide to tenants accessing the service. The isolation level refers to whether the farm and session hosts used for the advertisement are shared with other tenants or allocated only to the subscribing tenant. You can choose one of the following levels:
q

Isolated farm & isolated workload machine: The advertisement uses farm servers and session hosts that are allocated only to the subscribing tenant. When a tenant subscribes to this advertisement, App Studio creates OUs in Active Directory for these machines within the tenant's OU. App Studio then moves the machines from the selected catalogs to the appropriate OU. Only the tenant's users can use these machines to access the subscribed service. Shared farm & isolated workload machine: The advertisement uses farm machines that are shared with other tenants and session hosts that are allocated only to the subscribing tenant. When a tenant subscribes to this advertisement, App Studio creates an OU in Active Directory for the session hosts within the tenant's OU. App Studio then moves the machines from the selected workload catalog to the workload machine OU. When the tenant's users access the service, they use the same farm as other tenants but no other tenants use the subscribing tenant's session hosts. Shared farm & shared workload machine: The advertisement uses farm servers and session hosts that are allocated as shared among other tenants. For advertisements with this isolation level, you must ensure the advertisement has sufficient capacity to provide access to all subscribers. When you add capacity to the advertisement, App Studio moves the allocated session host to the appropriate shared OU. Tenants can access the service in the same farm and on the same session hosts as all other tenants subscribed to the advertisement.

After creating the advertisement, you can configure the following settings: Property Group Setting Name Description

1172

Advertising Services to Tenants Basic Properties Display name Change the advertisement name displayed to tenants. By default, tenants see the display name that appears in the Start menu of the session hosts in the workload catalog. Change the tooltip text for the application shortcut displayed to users. Control user access to the subscribed application on Web Interface sites. Select Yes to allow users to see the application on their Web Interface site and launch a session. Select No, but still visible to allow users to see the application but prevent them from launching a session. Select No, and not visible to prevent users from seeing or launching the application. Require user devices to employ a secure ICA connection when accessing the application. When this option is selected, user devices must connect with a minimum encryption level of 128-bit RC-5 encryption.

Description

Enabled

Security

1173

Advertising Services to Tenants Session properties Color depth Window size Control the color depth displayed in the session. Control the default size of the session window. Select Full Screen to allow the session window to encompass the entire screen. Select Exact pixel size to specify a preferred screen resolution for the session. Select Percent to specify a percentage of the user's screen. Control whether or not audio is enabled for the session. Select Required to launch the application only if the user device supports audio. Select Enabled to allow audio on all user devices. Select Disabled to prevent audio on all user devices.

Legacy audio

1174

Advertising Services to Tenants Advanced properties Program executable The executable path of the application on the XenApp server. This setting is read-only. Pass client-supplied command-line parameters to the application. Enter the percent and asterisk symbols enclosed in double quotation marks ("%*") to act as a placeholder. When a user launches a session through Citrix Receiver, the XenApp server replaces the placeholder with the application parameters Receiver provides. Specify the directory on the user device in which the application runs. By default, applications start in the user's home directory on the XenApp session host. Specify the folder on the user device in which to place a shortcut. Control whether or not add a shortcut to the user's Start menu and specify the folder in which the shortcut appears. Control whether or not to add a shortcut to the user's Desktop. Control the resource allotment for the session. By default, Normal is selected. Select a higher priority to increase the resource allotment and devote more CPU cycles to the session.

Command-line arguments

Working directory

Client folder

Start menu

Client folder

CPU priority level

Require the application to delay startup until printers are created for the session. For more information about application properties, refer to the following topics in Citrix eDocs:
q

Startup

To configure locations of published applications To pass parameters to published applications

1175

Advertising Services to Tenants


q

To configure shortcuts for user devices

To advertise services to tenants


1. From the App Studio Home page, perform one of the following actions:
q

If you are advertising services for a new deployment, click Make desktops and apps available.

If you are advertising additional services for an existing deployment, click Create new advertisements. The Select Services screen appears, listing all the applications available for advertisement.
q

2. In Workload catalog, select the workload catalog you want to use. 3. Select the applications you want to make available to tenants and then click Next. 4. On the Select Farm Catalog screen, select the farm catalog you want to use and the isolation mode. 5. If you are advertising a service using the Shared farm & shared workload machine isolation mode, add capacity to the advertisement, if applicable: a. Under Shared workload, expand the farm catalog and click Add. b. In Capacity to add, type the number of servers hosting the selected applications that will be allocated. 6. On the Advertisement Names screen, enter the service name for each application and then click Next. These names are visible in the App Studio console and, if applicable, in the Citrix CloudPortal Services Manager control panel. 7. Click Finish to save your selections. After you finish advertising services, you can add tenants and subscribe them to the advertised services. For more information about adding tenants, see To add tenants. For more information about creating subscriptions, see Subscribing Tenant Users to Services.

1176

Advertising Services to Tenants

To modify advertisements
1. From the menu bar of the App Studio console, click Services > Advertisements. 2. Click the name of the advertised application you want to modify. The application's advertisement page appears. 3. Click Edit. The Edit Advertisement screen appears. 4. Modify the desired information on the following screens:
q

Click Basic properties to change the advertisement's display name and description, change the subscription availability, and require client encryption. Click Session properties to change the color depth and window size of accessed applications, and to enable or disable session audio.

Click Advanced properties to change where application shortcuts appear on the user's device, CPU priority, and to enable or disable printer creation on session startup. 5. Click Save Advertisement to save your selections.
q

To remove advertisements
You can remove advertisements in the following ways:
q

Delete: App Studio executes workflows to remove the selected advertisement and any associated subscriptions from the deployment. The Advertisements console page continues to display the advertisement, indicating it is being deleted. When the workflows are completed, the Advertisements page displays only the remaining advertisements. Force Delete: If deletion is unsuccessful, you can forcibly delete the advertisement. App Studio removes the advertisement and associated subscriptions from the App Studio database without attempting any further cleanup activities.

1. From the menu bar of the App Studio console, click Services > Advertisements. 2. Click the name of the advertised application you want to delete. The application's advertisement page appears. 3. To delete the advertisement, perform the following actions: a. Click Delete. A message appears, confirming you want to delete the selected advertisement. b. Click Delete Advertisement. App Studio removes the advertisement from the database and the Advertisements page displays only the remaining advertisements. 4. If deleting the advertisement is unsuccessful, perform the following actions: a. Click the Workflows tab and cancel any workflows for the advertisement that are in Pending or Ready states.

1177

Advertising Services to Tenants b. Click Force Delete. A message appears, confirming you want to forcibly delete the advertisement. c. Click Forcibly Delete Advertisement. App Studio removes the advertisement and associated subscriptions from the database and the Advertisements page displays only the remaining advertisements.

1178

Managing Tenants
App Studio manages associations between tenants' users and hosted applications and desktops. However, it does not manage tenant creation or onboarding. These functions are typically handled by other customer portal or control panel products such as Citrix CloudPortal Services Manager, or by CSP-specific onboarding scripts. Therefore, App Studio requires that, before adding a tenant through the App Studio console, you must first create the individual tenant's root OU within the shared allocation domain and ensure the tenant's users reside within this OU. During tenant import, App Studio verifies the presence of this OU and returns an error if it cannot be found. Additionally, App Studio places any privately allocated XenApp controllers, session hosts, or Web Interface servers within this OU. When you import a tenant, you can choose the isolation level of the tenant's Web Interface site. These isolation levels are:
q

Shared site: To access subscribed applications, the tenant's users log on to a shared Web Interface site on a shared Web Interface server. Other tenants use the same site URL on this server to access their own subscriptions. Private site: To access subscribed applications, the tenant's users log on to a private Web Interface site on a shared Web Interface server. Other tenants use this server to access their subscriptions, but no other tenants have access to the subscribing tenant's site. This option is useful for providing tenants a custom-branded Web Interface site without dedicating additional server resources. Private server: To access subscribed applications, the tenant's users log on to a private Web Interface site on a dedicated Web Interface server. When you import the tenant, you specify the path to the tenant's Web Interface server import OU. App Studio then creates an Infrastructure OU for the tenant which you specify when you add Web Interface servers using the New-CamWIServer script. Because the Web Interface server is allocated only to the subscribing tenant, the server does not host the sites of other tenants and no other tenant's users can access the subscribing tenant's Web Interface site.

After you import the tenant, App Studio creates the XenApp Web and XenApp Services (PNA) sites according to the isolation level you specified and displays the URLs on the tenant's console page. The tenant uses these URLs to access subscribed applications using a Web browser or Citrix Receiver, respectively. By default, the tenant's XenApp Web site URL is shown. To view the tenant's XenApp Services site URL instead, click Show PNA sites. To view the XenApp Web site URL, click Show Web Interface sites.

To isolate the Tenants root organizational unit


Before you add tenants to your deployment, ensure the Tenants root OU is sufficiently isolated. This ensures that only the App Studio configuration servers and XenApp controllers have Read access to the Tenants OU to add tenants and create tenant subscriptions. The Tenants root OU refers to the root OU where individual tenant OUs reside. For example, mydomain.com/CloudAppManagement/Tenants/ or mydomain.com/CSP_Tenants/.

1179

Managing Tenants Perform this procedure only on a deployment that is not integrated with Citrix CloudPortal Services Manager. 1. From the Active Directory Users and Computers console, click View > Advanced Features. 2. Remove the Authenticated Users group from the Tenants root OU. a. Right-click the Tenants root OU and then click Properties. b. Click the Security tab and then select the Authenticated Users group. c. Click Remove and then click Apply. 3. Create a new security group in the shared allocation domain and add the computer accounts of the App Studio configuration servers and the XenApp controllers in your deployment. a. In the tree pane, right-click the domain and select New > Group. b. In Group name, enter a name for the group. In Group Type, ensure Security is selected. Click OK. c. Right-click the new group and select Properties. d. Click the Members tab and then click Add. e. Click Object Types and select Computers. Enter the computer names of the App Studio configuration servers and XenApp controllers in your deployment. Click OK. 4. Assign the new security group Read permissions to the Tenants root OU. a. Right-click the Tenants root OU and click Properties. b. Click the Security tab and then click Add. Enter the name of the new security group and then click OK. c. In Permissions for, in the Allow column, select Read. d. Click OK. 5. Reboot the App Studio configuration servers and XenApp controllers to enable the security settings to take effect.

1180

Managing Tenants

To add tenants
1. From the App Studio Home page, perform one of the following actions:
q

If you are adding tenants to a new deployment, click Add tenants to the system.

If you are adding more tenants to an existing deployment, under Actions, click Import a tenant. 2. On the Tenant Information screen, enter the following information and then click Next:
q q

In Name, enter a name for the new tenant. In Tags, type labels, separated by commas, that identify the tenant. For example, you might enter tags that represent the tenant's billing group, license type, or service level. In Tenant root OU, enter the path to the Active Directory OU where the tenant's users and any privately allocated farms and session hosts will reside.

Note: When you enter the tenant's name, the Tenant root OU field is populated automatically. However, you can modify this entry to reflect any OU in the shared allocation domain. 3. On the Choose Web Interface Site Isolation screen, choose one of the following options:
q

Shared site: Choose this option to specify a shared Web Interface site for the tenant. Private site: Choose this option to allocate a private Web Interface site for the tenant.

Private server: Choose this option to allocate a private server to host a private Web Interface site for the tenant. In Web Interface server import OU, specify the OU where you place the tenant's private Web Interface server. 4. Click Finish to create the tenant.
q

After adding a tenant to a new deployment, the Home page refreshes, indicating all initial App Studio configuration tasks are completed. Click Setup Complete! Go to the Dashboard to view the App Studio dashboard. From the dashboard, you can advertise services and create tenant subscriptions. For more information, see Advertising Services to Tenants and Subscribing Tenant Users to Services.

1181

Managing Tenants

To modify tenant information


1. From the menu bar of the App Studio console, click Tenants. The Tenants page appears, listing all the imported tenants. 2. Click the name of the tenant you want to modify. The tenant's page appears. 3. Click Edit. The Edit Tenant screen appears. 4. Perform the following actions and modify the information in each field as desired: a. Click General to modify the tenant's basic information. b. Click Isolation to modify the tenant's Web Interface information. 5. Click Save Tenant to save your changes.

To remove a tenant
You can remove tenants in the following ways:
q

Delete: App Studio executes workflows to delete the tenant and any associated subscriptions from the deployment. Additionally, if any farm controllers, session hosts, or Web Interface servers are privately allocated to the tenant, App Studio moves these servers to the Decommissioned Servers OU. The Tenants console page continues to display the tenant, indicating that the tenant is being deleted. Force Delete: If the deletion workflows do not complete successfully, you can forcibly delete the tenant. App Studio removes the tenant and any associated subscriptions from the App Studio database without attempting any further cleanup activities.

1. From the menu bar of the App Studio console, click Tenants. The Tenants page appears, listing all the imported tenants. 2. Click the name of the tenant you want to delete. A message appears, confirming you want to delete the tenant. 3. To remove the tenant, perform the following actions: click Delete Tenant. a. Click Delete. A message appears, confirming you want to delete the tenant. b. Click Delete Tenant. App Studio deletes the tenant from the database and removes the tenant's root OU from Active Directory. The Tenants page refreshes and displays only the remaining tenants. 4. If deletion is unsuccessful, perform the following actions: a. Click the Workflows tab and cancel any deletion workflows for the tenant that are in Pending or Ready states. b. Click Force Delete. A message appears, confirming you want to forcibly delete the tenant. c. Click Forcibly Delete Tenant. App Studio removes the tenant and associated subscriptions from the App Studio database. As well, the Tenants console page

1182

Managing Tenants refreshes and displays only the remaining tenants.

1183

Subscribing Tenant Users to Services


Subscriptions enable tenants' users to access advertised resources through the Web Interface. Depending on the Web Interface isolation level you selected when you imported the tenant, users can log on to a shared or private site URL to access their subscriptions. When you create a subscription for a tenant, a workload is created to host the subscription if one does not already exist. Whether creating a workload, or using an existing one, App Studio provides an opportunity to add capacity to the workload. Adding capacity causes App Studio to allocate additional session hosts to deliver the subscribed service to the tenant's users. The workload is associated with the workload catalog, farm catalog, and tenant for whom the subscription is created. This workload is reused if another subscription is created for the same tenant using the same workload and farm catalogs.

To create subscriptions
1. From the App Studio Home page, under Actions, click Subscribe users to services. 2. On the Select Tenant screen, select the tenant for whom you want to add subscriptions and click Next. 3. On the Select Advertisements screen, select the services you want to add to the tenant's subscription and then click Next. 4. On the Add Users screen, enter the tenant's users who will use the selected services in "Domain\Username" format. You can enter individual users or Active Directory groups. 5. Click Validate Users and then click Next. 6. On the Select Capacity page, if additional capacity is required, expand the farm catalog you want to use and then click Add. Enter the number of servers that are available to serve resources to the tenant's users. 7. Click Finish to create the subscription.

1184

Subscribing Tenant Users to Services

To add or remove users from subscriptions


1. From the menu bar of the App Studio console, click Tenants. 2. From the Tenants page, click the name of the tenant whose subscriptions you want to modify. The tenant's page appears. 3. On the Subscriptions tab, click the name of the subscription you want to modify. The subscription page appears. 4. To add more users, perform the following actions: a. Click Add Users. b. Enter the tenant's users who will use the selected services in "Domain\Username" format. You can enter individual users or Active Directory groups. c. Click Validate Users and then click Next. The Select Capacity screen appears. d. If you are adding several users to the subscription, increase capacity, if necessary. Expand the workload, click Add and enter the number of session hosts to add to the workload. Click Next. e. Click Finish. 5. To remove users, perform the following actions: a. On the Users tab, for the user or group you want to remove, click Remove. A message appears, confirming you want to remove the user. b. Click Remove User. App Studio removes the selected user from the subscription.

To remove subscriptions
You can remove subscriptions in the following ways:
q

Delete: App Studio executes workflows to remove the selected subscription from the App Studio deployment. App Studio continues to display the subscription, indicating that it is being deleted. After the workflows are complete, App Studio displays only the remaining subscriptions. Force Delete: If deletion is unsuccessful, you can forcibly delete the subscription. App Studio removes the subscription from the App Studio database without attempting any further cleanup activities.

1. From the menu bar of the App Studio console, perform one of the following actions: .
q

Click Tenants, click the name of the tenant whose subscriptions you want to delete.

Click Advertisements and then click the name of the advertisement whose subscription you want to delete. 2. On the Subscriptions tab, click the name of the subscription you want to delete.
q

1185

Subscribing Tenant Users to Services 3. On the subscription console page, click Delete Subscription. A message appears, confirming you want to delete the subscription. 4. Click Delete Subscription. App Studio notes the subscription is being deleted. After the deletion is complete, App Studio displays only the remaining subscriptions. 5. If the deletion is unsuccessful, perform the following actions: a. Click the Workflows tab and cancel any workflows for the subscription that are in Pending or Ready states. b. Click Force Delete. A message appears, confirming you want to forcibly delete the subscription. c. Click Forcibly Delete Subscription. App Studio removes the subscription from the database and displays only the remaining subscriptions.

1186

Managing Administrators
In App Studio, you can create the following types of administrator users:
q

App Studio administrator: This user has access to all App Studio console functions, including changing the global domain administrator for the deployment. Helpdesk administrator: This user can view information for assigned tenants through the Desktop Director console. Assigning the helpdesk administrator role grants privileges only within Desktop Director when used in conjunction with App Studio. This role does not grant privileges to App Studio itself or to the XenApp farms that App Studio manages. For more information about Desktop Director, refer to the Desktop Director topics in Citrix eDocs.

When creating administrator users in App Studio, you can specify individual users or Active Directory groups.

To create a new App Studio administrator


1. From the App Studio Home page, under Actions, click Manage administrators. 2. On the Infrastructure page, click Add Administrators. 3. On the Add Administrators screen, enter the users to whom you want to grant administrative permissions in "Domain\Username" format. 4. Click Validate Users. App Studio validates the entries and notes they will be added as Administrators. 5. Click Add Administrators. The Infrastructure page refreshes and displays the users you added on the Administrators tab.

To create a helpdesk administrator


1. From the menu bar of the App Studio console, click Tenants. 2. Click the name of the tenant and then click Add Helpdesk Administrators. 3. On the Add Helpdesk Administrators screen, enter the users or Active Directory group to whom you want to grant administrative permissions in "Domain\Username" format. 4. Click Validate Users. App Studio validates the users you entered. 5. Click Add Helpdesk Administrators. App Studio adds the users to the Helpdesk Administrators tab on the tenant's console page.

1187

Managing Administrators

To remove an administrator
1. To remove a global administrator, perform the following actions: a. From the App Studio Home page, under Actions, click Manage administrators. b. On the Infrastructure page, on the Administrators tab, click Delete for the administrator you want to remove. c. Click Delete Administrator. App Studio removes the selected user from the database. Also, the Infrastructure page refreshes, displaying only the remaining administrators. 2. To remove a helpdesk administrator, perform the following actions: a. From the menu bar of the App Studio console, click Tenants and then click the name of the tenant whose helpdesk administrators you want to manage. b. Click the Helpdesk Administrators tab on the tenant's console page and then click Remove for the helpdesk administrator you want to remove. d. Click Remove Helpdesk Administrator. The App Studio console refreshes and the Helpdesk Administrators tab displays only the remaining helpdesk administrators.

1188

Providing Applications and Desktops to Customers with Citrix CloudPortal Services Manager
The CloudPortal Services Manager is data-center installed software that enables you to host, sell, and resell hosted applications and related infrastructure. Managed through a Web browser, the control panel is a scalable environment for service providers and resellers who provision and manage customer solutions. You can add App Studio as a service, called Hosted Apps and Desktops, to an existing Services Manager deployment. This enables you to use the Services Manager control panel to advertise XenApp and XenDesktop services and subscribe customers, including resellers, to them. Before you configure the Hosted Apps and Desktops service in Services Manager, ensure you have created in App Studio the advertisements you need for provisioning customers. When you configure the Hosted Apps and Desktops service, you add these advertisements to user plans. The user plans define the App Studio services that are available for selection when you provision Services Manager customers. When you provision a customer with the Hosted Apps and Desktops service, you are performing the following operations:
q

Set the isolation level of the Web Interface site Subscribe the customer to advertised services

The isolation levels of Web Interface sites (Shared, Private site, or Private server) available in App Studio are displayed in Services Manager as customer plans that you assign during provisioning. To set the isolation level for the customer's Web Interface site, you select the appropriate customer plan in the Service Plan Configuration. To subscribe a customer to advertisements, you select the user plans to which the customer has access. In Services Manager, subscriptions enable the customer to further provision App Studio services to users. When you provision a Services Manager customer with the Hosted Apps and Desktops service, the customer is also created as a tenant in App Studio. As well, App Studio creates a Web Interface site for the tenant at the isolation level you selected (through the customer plan) and creates subscriptions for the tenant based on the user plans you selected. After the customer is provisioned with the service, the customer logs in to the Services Manager control panel and selects the user plans with which to provision individual users. At each step in the provisioning process, App Studio executes workflows that create the tenant, subscribe to advertisements, and create the Web Interface site. You can monitor these workflows in the App Studio console by clicking System > Workflows. After these workflows finish, you can view the customer's tenant information and subscriptions in the App Studio console.

1189

Providing Applications and Desktops to Customers with Citrix CloudPortal Services Manager For more information about installing and configuring the Hosted Apps and Desktops service in a Services Manager deployment and provisioning the service to customers and users, refer to the CloudPortal Services Manager product documentation located in Citrix eDocs.

1190

XenApp 6.5 Mobility Pack 1.0


XenApp 6.5 Mobility Pack improves the experience of Citrix Receiver users working in supported Windows applications and published server desktops on mobile devices. Features include:
q

The use of mobile device controls instead of native Windows controls such as combo boxes. Automatic display of the device keyboard when an editable field has the focus. The desktop session scrolls if needed to make the input area visible. A touch-optimized desktop for mobile devices that provides:
q

Improved access to the Windows Start menu: Tap the START button and use the touch-friendly menus to navigate to applications and documents. Start an application or open a document with a single tap. Multiple pages of icons on the desktop: Swipe the desktop or tap the scroll icons to navigate. One-tap return to the touch-optimized desktop when it is hidden by a full-screen application: Tap the icon in the bottom left corner of the desktop.

One-tap return to the traditional Windows desktop: Tap the icon in the top right corner of the desktop to toggle between the touch-optimized and Windows desktops. Support for providing mobile device location (GPS) information to remote application sessions. This feature enables the remote application to obtain mobile device location information from Citrix Receiver so that the application behavior can change just as if it were running locally on the mobile device.
q

A mobile device development platform, XenApp 6.5 Mobile Application Software Development Kit (SDK), that enables Enterprise Windows developers to write applications for mobile devices using familiar programming languages. The Mobile Application SDK includes interfaces to:
q

Control how buttons are used on the mobile device Set screen orientation Activate the on-screen keyboard Use local user interface controls instead of Windows controls Access the device's telephone, SMS, and camera functions

1191

XenApp 6.5 Mobility Pack 1.0

In This Section
About This Release System Requirements Installing XenApp 6.5 Mobility Pack Configuring Policies for Mobility Pack Mobile Application SDK

1192

About XenApp 6.5 Mobility Pack 1.0


Known Issues
q

The view port may be shifted up when the automatic keyboard opens. To see the editable area, pan the [253814]

An application with a .NET 4.0 Calendar control can crash if Microsoft UI Automation monitoring is active session and the user places the focus on the Calendar control. This issue results from a missing property (ComponentResourceKey) in the DataTemplate key for the .NET 4.0 Calendar control. A resource defined level must use a ComponentResourceKey as the key. To avoid this issue with .NET 4.0, set the DataTemplate key for the Calendar control as follows:

<DataTemplate x:Key="{ComponentResourceKey TypeInTargetAssembly=CalendarItem, ResourceId=DayTi

For more information, refer to the Microsoft Support article Null reference exception when running a .ne automation. [261165]
q

The automatic keyboard feature does not scroll the display to show the input area when an iOS device re to a value other than Auto-Fit. [267307]

During some operations, applications can unexpectedly minimize to the touch-optimized desktop taskbar taskbar icon for the application to re-open it. [267606, 267609]

When a Windows notification appears, the Windows taskbar displays on top of the touch-optimized deskt redisplay the touch-optimized desktop taskbar, dismiss the notification or tap the desktop. [268911]

The touch-optimized desktop taskbar appears with the Windows desktop when the user presses Alt-Tab a the gear icon from the Windows desktop (Receiver for iOS). To correct the display, tap the icon in the lo corner. [269535]

The keyboard covers the input area when the automatic keyboard is displayed and a Receiver for iOS use device. The user can pan the display or rotate the device to the original orientation to see the input area

The touch-optimized desktop taskbar displays when an application is running in full-screen mode. [27269

The automatic keyboard or device-native combo box do not display for applications run with elevated pe (Receiver for iOS). [273016]

1193

XenApp 6.5 Mobility Pack Technical Preview

Fixed Issues
q

The automatic keyboard and mobile combo box now appear on second use. [253264] The policy help text for Automatic keyboard display and Remote the combo box is correct. [256356] The error "wfshell shell has stopped working" no longer appears when you start Microsoft Notepad after previously exiting it before the keyboard opened. [261973]

1194

About XenApp 6.5 Mobility Pack 1.0


Known Issues
q

The view port may be shifted up when the automatic keyboard opens. To see the editable area, pan the [253814]

An application with a .NET 4.0 Calendar control can crash if Microsoft UI Automation monitoring is active session and the user places the focus on the Calendar control. This issue results from a missing property (ComponentResourceKey) in the DataTemplate key for the .NET 4.0 Calendar control. A resource defined level must use a ComponentResourceKey as the key. To avoid this issue with .NET 4.0, set the DataTemplate key for the Calendar control as follows:

<DataTemplate x:Key="{ComponentResourceKey TypeInTargetAssembly=CalendarItem, ResourceId=DayTi

For more information, refer to the Microsoft Support article Null reference exception when running a .ne automation. [261165]
q

The automatic keyboard feature does not scroll the display to show the input area when an iOS device re to a value other than Auto-Fit. [267307]

During some operations, applications can unexpectedly minimize to the touch-optimized desktop taskbar taskbar icon for the application to re-open it. [267606, 267609]

When a Windows notification appears, the Windows taskbar displays on top of the touch-optimized deskt redisplay the touch-optimized desktop taskbar, dismiss the notification or tap the desktop. [268911]

The touch-optimized desktop taskbar appears with the Windows desktop when the user presses Alt-Tab a the gear icon from the Windows desktop (Receiver for iOS). To correct the display, tap the icon in the lo corner. [269535]

The keyboard covers the input area when the automatic keyboard is displayed and a Receiver for iOS use device. The user can pan the display or rotate the device to the original orientation to see the input area

The touch-optimized desktop taskbar displays when an application is running in full-screen mode. [27269

The automatic keyboard or device-native combo box do not display for applications run with elevated pe (Receiver for iOS). [273016]

1195

About This Release

Fixed Issues
q

The automatic keyboard and mobile combo box now appear on second use. [253264] The policy help text for Automatic keyboard display and Remote the combo box is correct. [256356] The error "wfshell shell has stopped working" no longer appears when you start Microsoft Notepad after previously exiting it before the keyboard opened. [261973]

1196

System Requirements for XenApp 6.5 Mobility Pack 1.0


Server
q

Windows Server 2008 R2, 64-bit edition Microsoft .NET Framework 3.5 SP1 Citrix XenApp 6.5 with all hotfixes installed

Devices
q

Citrix Receiver for Android 3.0 Citrix Receiver for iOS (current versions support touch-optimized desktop)

Application
q

Location sensing is supported for applications that use the Windows 7 Location API and can receive responses based on the client location sensor.

Mobile Application SDK


q

Development operating system: Microsoft Windows 7 (x64) Development platforms: Microsoft Visual Studio 2010 SP1 Microsoft .NET Framework 3.5 SP1 Microsoft Windows SDK 7.1 (for C++ location support)

1197

Installing XenApp 6.5 Mobility Pack


XenApp 6.5 Mobility Pack components install onto XenApp and provide the run-time environment that applications delivered to mobile devices need for mobile device user experience functionality and XenApp 6.5 Mobile Application SDK functionality. The XenApp 6.5 Mobile Application SDK provides a mobile device programming interface for Windows programs hosted on Citrix XenApp and delivered to any device with Citrix Receiver.

To install the XenApp 6.5 Mobility Pack onto a XenApp server


1. Download the XenApp 6.5 Mobility Pack 1.0 installation package. This file contains:
q

CitrixGroupPolicyManagement_x64.msi and CitrixGroupPolicyManagement_x86.msi each installs an updated version of the Citrix XenApp Group Policy Management Experience, allowing you to view and edit the policy settings added by the XenApp 6.5 Mobility Pack.

XA650W2K8R2X64011.msp the XenApp server hotfix for the service-side components of the XenApp 6.5 Mobility Pack. 2. Copy the .zip file to a shared folder on the network and extract the contents.
q

3. Save CitrixGroupPolicyManagement_xnn.msi on the XenApp server on which you want to install the XenApp 6.5 Mobility Pack. 4. Install XA650W2K8R2X64011.msp on the XenApp server. 5. To view and edit the new policies using this server, run CitrixGroupPolicyManagement_xnn.msi. To view and edit the new policies using another server, install CitrixGroupPolicyManagement_xnn.msi.

1198

Installing XenApp 6.5 Mobility Pack

To install the XenApp 6.5 Mobile Application SDK on development computers


1. Download the XenApp 6.5 Mobile Application SDK installation package. 2. Install XenApp65MobileApplicationSdk64.msi onto each development computer. The Mobile Application SDK installs into C:\Program Files (x86)\Citrix\MobilitySDK. The installed folders contain these components:
q

bin DLLs doc SDK documentation inc Include files needed to use the SDK in C/C++ code lib Static library files needed to link the SDK in C/C++ code samples Code samples using the SDK

1199

Configuring Policies for Mobility Pack


The following Citrix user configuration policy settings (all XenApp only) control Mobility Pack feature settings. Under ICA > Mobile Experience:
q

Automatic keyboard display Launch touch-optimized desktop Remote the combo box

Under ICA > Client Sensors > Location:


q

Allow applications to use the physical location of the client device

For information about setting policies, refer to Working with Citrix Policies. For more information about these policies, refer to related topics under ICA Policy Settings. Note: If you used the XenApp 6.5 Mobility Pack Technical Preview, be aware that the Automatic keyboard display and Remote the combo box policies are now prohibited by default.

To set the keyboard display behavior


The Automatic keyboard display policy setting determines the behavior of the keyboard during application sessions on mobile devices. By default, a mobile Receiver user must manually open the keyboard. To enable the keyboard to automatically open when an editable field has the focus, set this policy to Allowed. When this setting is allowed, a user can change a Receiver for iOS session setting to prevent the keyboard from automatically opening.

To provide a touch-friendly interface


The Launch touch-optimized desktop policy setting determines the overall Receiver interface behavior. By default, a touch-friendly interface that is optimized for tablet devices is used. To use only the Windows interface, set this policy to Prohibited.

To set the type of combo box displayed


The Remote the combo box policy setting determines the type of combo box displayed during application sessions on mobile devices. To display the device-native combo box control, set this policy to Allowed. When this setting is allowed, a user can change a Receiver for iOS session setting to use the Windows combo box.

1200

Configuring Policies for Mobility Pack

To allow applications to use mobile device location information


The Allow applications to use the physical location of the client device policy setting determines whether applications running in a XenApp session on a mobile device are allowed to use the physical location of the client device. Note: Obtaining location information from a mobile device raises privacy issues, as described in Client Sensors Policy Settings. By default, the use of location information is prohibited. To allow use of location information, set this policy to Allowed. When this setting is allowed, a user can prohibit use of location information by denying a Receiver request to access the location. Android and iOS devices prompt at the first request for location information in each session.

1201

Mobile Application SDK


The Mobile Application SDK provides a mobile device programming interface for Windows programs hosted on Citrix XenApp and delivered to any device with Citrix Receiver. The SDK provides Enterprise Windows developers with the means to develop Windows applications with capabilities and behaviors typical of native mobile applications. The functionality provided by the SDK significantly improves the user experience. Developers can use the SDK with the Windows application development framework that best suits their needs. The SDK is available for download from the Citrix Developer Network (CDN), where you can find an SDK reference and other resources. Typical Windows applications are based on an expansive desktop space with access to a keyboard and a mouse. Legacy Windows applications do not accommodate on-screen keyboards and other features specific to mobile devices. The Mobile Application SDK enables Windows developers to write new applications and to improve existing applications for delivery to supported mobile devices. The Mobile Application SDK enables a Windows application to control mobile device features such as:
q

Buttons Get the current button target, set the button target, and specify whether to handle a button press on the server or the mobile device. Camera Take, download, and remove pictures using the built-in camera of the mobile device. Get picture state information. Device properties Retrieve device feature support information. Display Get and set mobile device screen metrics such as orientation, scroll mode, and viewport origin to ensure that text is easy to read and controls are easy to use. Keyboard Check the keyboard state and control whether to show or hide the on-screen keyboard. The keyboard state includes the keyboard type, keyboard flags, auto-capitalization, return key type, and edit field rectangle. Notification Notify the user about special events using sound, vibration, light, and text. Phone Make phone calls based on the contacts list on a server. Picker control Select an item from a list using a control that is native to the device. SMS Send an SMS from content on a server.

For features such as phone calls, SMS, and camera functions enabled by the Mobile Application SDK, Receiver prompts the user for permission to perform the action so that the user always has the option to protect potentially sensitive information. When developing hosted applications that use the Mobile Application SDK, consider the following:

1202

Mobile Application SDK


q

A secure connection (for example, using SSL/TLS or a VPN) should be enforced for the applications. Citrix Receiver should connect to trusted servers. Consider obtaining legal advice regarding the use of mobile device features, such as the camera, which raise privacy issues.

1203

You might also like