Xenapp PDF

Citrix
eDocs product documentation library

http://edocs.citrix.com
2011, Citrix Systems, Inc. All rights reserved.
XenApp
Contents
1. XenApp 6 for Windows Server 2008 R2
2. XenApp 6 Security Standards and Deployment Scenarios
3. XenApp 5 Feature Pack 3 for Windows Server 2008
5. XenApp 5 for Windows Server 2008
8. XenApp 5 Feature Pack for Windows Server 2003
8.1. Release Notes for XenApp 5.0 Feature Pack
8.2. Readme for XenApp 5 for Windows Server 2003
8.3. Getting Started with Citrix XenApp
8.3.1. Before You Begin
8.3.1.1. New Product and Feature Names
8.3.1.2. Media Kit Contents
8.3.2. Introducing Citrix XenApp 5
8.3.2.1. XenApp Product Editions
8.3.2.2. New Features and Changes in XenApp 5
8.3.2.3. New Features, Capabilities, and Changes in the XenApp 5 Feature Pack
8.3.3. XenApp Feature Overview
8.3.3.1. Hosted Application Delivery and Features
8.3.3.2. Application Streaming
8.3.3.3. Citrix Receiver and Merchandising Server
8.3.3.4. XenServer Virtualization Platform
8.3.3.5. Load Testing Services
8.3.3.6. Provisioning Services
8.3.3.7. Profile Management
8.3.3.8. Service Monitoring
8.3.3.9. SmartAuditor
8.3.3.10. Secure Application Access
8.3.3.11. Branch Optimization
8.3.3.12. Single Sign-on
8.3.3.13. EasyCall Voice Services
8.3.3.14. Workflow Studio Orchestration
8.3.4. Getting Up and Running with XenApp 5
8.3.4.1. Using XenApp to Manage Applications
8.3.4.2. Preparing to Create the Farm
8.3.4.3. Licensing This Release
8.3.4.4. Installing XenApp 5
8.3.4.5. Installing Additional Features
8.3.4.6. Running Mixed Farms
8.4. System Requirements for XenApp 5.0 for Windows Server 2003
8.5. Planning Your XenApp Deployment
8.5.1. Farm Terminology and Concepts
8.5.2. Farm Hardware Considerations
8.5.3. Remapping Drive Letters
8.5.4. Planning for Applications and Server Loads
8.5.4.1. Assessing Applications for XenApp Compatibility
8.5.4.2. Evaluating Application Delivery Methods
8.5.4.3. Placing Applications on Servers
8.5.5. Deciding How Many Farms to Deploy
8.5.6. Planning Infrastructure Servers
8.5.6.1. Planning the XenApp Data Store
8.5.6.1.1. Connecting to the Data Store

8.5.6.1.2. Database Server Hardware Performance Considerations
8.5.6.1.3. Replication Considerations
8.5.6.1.4. Planning for Configuration Logging and IMA Encryption
8.5.6.2. Planning for Data Collectors
8.5.6.3. Planning for WANs by Using Zones
8.5.6.4. Planning for the Web Interface and XML Broker
8.5.7. Planning for Application Streaming
8.5.8. Designing Terminal Services User Profiles
8.5.9. Planning for Accounts and Trust Relationships
8.5.10. Recommendations for Active Directory Environments
8.5.11. Planning for System Monitoring and Maintenance
8.5.12. Planning for Shadowing
8.5.13. Securing Delivery and Access
8.5.14. Planning for Supported Languages and Windows MUI Support
8.5.15. Planning for Passthrough Client Authentication
8.5.16. Planning a Successful User Experience
8.5.17. Integrating Other XenApp Features and Technologies
8.5.18. Choosing an Installation Method
8.6. XenApp Installation
8.6.1. Building a XenApp Farm
8.6.1.1. Preparing Your Environment
8.6.1.2. Creating a Farm
8.6.1.2.1. Choosing the Edition
8.6.1.2.2. Choosing an Installation Category
8.6.1.2.3. Selecting Components
8.6.1.2.4. Enabling and Configuring Passthrough Client Authentication
8.6.1.2.5. Installing the License Server
8.6.1.2.6. Specifying the Farm Name, Data Store, Zone, and Credentials
8.6.1.2.7. Enabling and Configuring IMA Encryption
8.6.1.2.8. Specifying the Citrix License Server
8.6.1.2.9. Enabling and Configuring Session Shadowing
8.6.1.2.10. Configuring the Citrix XML Service Port
8.6.1.2.11. Adding Users to the Remote Desktop Users Group
8.6.1.3. Joining a Server Farm
8.6.2. Upgrading or Migrating an Existing Server Farm
8.6.3. Provisioning Servers and Configuring XenApp
8.6.3.1. Provisioning Farm Servers
8.6.3.2. Cloning XenApp Servers
8.6.3.3. To clone a server
8.6.3.4. Configuring Infrastructure Servers After Setup
8.6.3.5. Configuring XenApp after Installation
8.6.4. Custom XenApp Installation
8.6.4.1. Generating an Installation Log File
8.6.4.2. Preparing for Custom XenApp Installations
8.6.4.3. Installing XenApp by Modifying Windows Installer Packages
8.6.4.4. Applying Transforms to Setup
8.6.4.5. Performing an Unattended Installation with an Answer File
8.6.5. XenApp Windows Installer Properties Reference
8.6.5.1. XenApp Setup Properties for Create Farm and Join Farm
8.6.5.1.1. CTX_ADDLOCAL
8.6.5.1.2. CTX_CONFIGMGR_USER
8.6.5.1.3. CTX_CONFIGMGR_USER_PASSWORD
8.6.5.1.4. CTX_CPSVC_SERVICE_USER_NAME
8.6.5.1.5. CTX_CPSVC_SERVICE_USER_PASSWORD
8.6.5.1.6. CTX_IGNORE_MCM
8.6.5.1.7. CTX_IMA_PROTECTION_ENABLE
8.6.5.1.8. CTX_MALOO_SERVICE_USER
8.6.5.1.9. CTX_MALOO_SERVICE_USER_PASSWORD
8.6.5.1.10. CTX_MF_ADD_ANON_USERS
8.6.5.1.11. CTX_MF_ADD_LOCAL_ADMIN
8.6.5.1.12. CTX_MF_CREATE_FARM_DB_CHOICE
8.6.5.1.13. CTX_MF_CREATE_REMOTE_DESKTOP_USERS
8.6.5.1.14. CTX_MF_DOMAIN_NAME
8.6.5.1.15. CTX_MF_ENABLE_VIRTUAL_SCRIPTS
8.6.5.1.16. CTX_MF_FARM_SELECTION
8.6.5.1.17. CTX_MF_INDIRECT_JOIN_DOMAIN_NAME
8.6.5.1.18. CTX_MF_INDIRECT_JOIN_PASSWORD
8.6.5.1.19. CTX_MF_INDIRECT_JOIN_USER_NAME
8.6.5.1.20. CTX_MF_JOIN_FARM_DB_CHOICE
8.6.5.1.21. CTX_MF_JOIN_FARM_SERVER_NAME
8.6.5.1.22. CTX_MF_JOIN_FARM_SERVER_PORT
8.6.5.1.23. CTX_MF_LIC_CHOICE_FOR_CREATE
8.6.5.1.24. CTX_MF_LIC_CHOICE_FOR_JOIN_OR_UPGRADE
8.6.5.1.25. CTX_MF_LICENSE_SERVER_NAME
8.6.5.1.26. CTX_MF_LICENSE_SERVER_PORT
8.6.5.1.27. CTX_MF_LICENSE_SERVER_PORT_DEFAULT
8.6.5.1.28. CTX_MF_LOCAL_DATABASE
8.6.5.1.29. CTX_MF_MSDE_INSTANCE_NAME
8.6.5.1.30. CTX_MF_NEW_FARM_NAME
8.6.5.1.31. CTX_MF_ODBC_DRIVER
8.6.5.1.32. CTX_MF_ODBC_PASSWORD
8.6.5.1.33. CTX_MF_ODBC_USER_NAME
8.6.5.1.34. CTX_MF_ONLY_LAUNCH_PUBLISHED_APPS
8.6.5.1.35. CTX_MF_SERVER_TYPE
8.6.5.1.36. CTX_MF_SHADOW_PROHIBIT_NO_LOGGING
8.6.5.1.37. CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION
8.6.5.1.38. CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA
8.6.5.1.39. CTX_MF_SHADOWING_CHOICE
8.6.5.1.40. CTX_MF_SILENT_DSNFILE
8.6.5.1.41. CTX_MF_USER_NAME
8.6.5.1.42. CTX_MF_XML_CHOICE
8.6.5.1.43. CTX_MF_XML_PORT_NUMBER
8.6.5.1.44. CTX_MF_ZONE_NAME
8.6.5.1.45. CTX_PROTECT_KEY_PATH
8.6.5.1.46. CTX_PROTECT_KEY_TYPE
8.6.5.1.47. CTX_PROTECT_NEW_KEY_PATH
8.6.5.1.48. CTX_RDP_DISABLE_PROMPT_FOR_PASSWORD
8.6.5.1.49. CTX_REMOVE_WI_TURNKEY
8.6.5.1.50. CTX_SERV_MALOO_LOGON
8.6.5.1.51. CTX_SERV_PRINTER_LOGON
8.6.5.1.52. CTX_USE_EXISTING_JRE
8.6.5.1.53. INSTALLDIR
8.6.5.1.54. REBOOT
8.6.5.1.55. REINSTALLMODE
8.6.5.2. XenApp Windows Setup Properties Script Examples
8.6.6. Data Store Database Reference
8.6.6.1. Microsoft Access Database
8.6.6.2. Microsoft SQL Server Express Database
8.6.6.3. Microsoft SQL Server Database
8.6.6.4. Oracle Database
8.6.6.5. IBM DB2 Database
8.6.6.6. Creating a DSN File for XenApp Setup
8.6.6.7. Maintaining and Recovering a XenApp Data Store
8.6.6.8. Migrating a Farm Data Store
8.6.6.8.1. Migrating a Farm Data Store from MSDE to SQL Server Express
8.7. XenApp Administration
8.7.1. Management Consoles and Other Tools
8.7.1.1. Choosing the Console or Tool to Use
8.7.1.2. To start the console
8.7.1.3. Displaying Items in the Console
8.7.1.4. The Console User Interface
8.7.1.5. Performing Tasks with the Console
8.7.1.5.1. To view zones
8.7.1.6. Enabling Citrix Administrators to Manage Farms Remotely

8.7.1.7. XenApp Advanced Configuration and Presentation Server Console
8.7.2. Managing Citrix Administrators
8.7.2.1. Delegating Tasks to Custom Administrators
8.7.3. Publishing Resources
8.7.3.1. Publishing Resources for Users
8.7.3.1.1. To publish a resource using the Publish Application wizard
8.7.3.1.2. To select a resource type and delivery method
8.7.3.1.3. To configure locations of published applications
8.7.3.1.4. To configure locations of published content
8.7.3.1.5. To disable command-line validation
8.7.3.2. Configuring Content Redirection
8.7.3.2.1. To enable content redirection from server to client
8.7.3.2.2. To configure content redirection from client to server
8.7.3.3. Managing Application Properties
8.7.3.3.1. To rename a published application
8.7.3.3.2. To configure locations of servers for published resources
8.7.3.3.3. To specify locations of applications for streaming
8.7.3.3.4. To enable an application for offline access
8.7.3.3.5. To configure user access to applications
8.7.3.3.6. Granting Access to Explicit or Anonymous Users
8.7.3.3.7. To configure shortcuts for user devices
8.7.3.3.8. To configure access controlled by the Access Gateway
8.7.3.3.9. To associate published applications with file types
8.7.3.3.10. To update file type associations
8.7.3.3.11. To configure alternate profiles
8.7.3.3.12. To pass parameters to published applications
8.7.3.3.13. To reduce user privileges for a streamed application
8.7.3.3.14. To configure application limits and importance
8.7.3.3.15. To configure audio and encryption options for published applications
8.7.3.3.16. To configure application appearance
8.7.3.3.17. To disable or enable a published application
8.7.3.3.18. To delete a published application
8.7.3.3.19. To move a published application to another folder
8.7.3.3.20. To duplicate published application settings
8.7.3.3.21. To export published application settings to a file
8.7.3.3.22. To import published application settings from a file
8.7.3.4. Making Virtual IP Addresses Available to Applications
8.7.3.4.1. How Virtual IP Addressing Works
8.7.3.4.2. Configuring Virtual Loopback
8.7.3.4.3. Binding Applications
8.7.3.4.4. To determine whether an application needs to use virtual IP addresses
8.7.3.4.5. To make virtual IP addresses available to applications running in sessions
8.7.3.4.6. To assign virtual IP address ranges to servers
8.7.3.4.7. To enable application processes to use virtual IP addresses or virtual loopback
8.7.3.4.8. To supply client IP addresses to published applications on a server
8.7.3.4.9. To make a virtual loopback address available to applications running in sessions
8.7.3.4.10. To enable or disable virtual loopback for a farm
8.7.3.4.11. To configure virtual IP addresses and virtual loopback on an individual server
8.7.4. Working with XenApp Policies
8.7.4.1. Creating XenApp Policies
8.7.4.2. Applying XenApp Policies
8.7.4.3. Configuring Policy Rules
8.7.4.3.1. To configure policy rules
8.7.4.4. Using Multiple Policies
8.7.4.4.1. Using Citrix policies with Active Directory
8.7.4.4.2. Prioritizing Policies and Creating Exceptions
8.7.4.5. Determining Which Policies Apply to a Connection
8.7.4.5.1. Resolving Search Results that Partially Match Criteria
8.7.4.5.2. Troubleshooting Policies with Conflicting Rules
8.7.4.6. Disabling, Reenabling, and Deleting Policies
8.7.4.7. Changing Settings Based on User Location
8.7.4.8. Configuring Policies and Filters for Web Access

8.7.4.9. Enabling Scanners and Other TWAIN Devices
8.7.4.9.1. To enable TWAIN redirection
8.7.5. Managing Session Environments and Connections
8.7.5.1. Defining User Environments in XenApp
8.7.5.1.1. Controlling the Appearance of User Logons
8.7.5.1.2. Controlling Access to Devices and Ports
8.7.5.1.2.1. Mapping Client Drives
8.7.5.1.2.2. Mapping Client COM Ports and Audio
8.7.5.1.3. Configuring Audio for User Sessions
8.7.5.1.3.1. To enable or disable audio for published applications
8.7.5.1.3.2. Limiting Bandwidth for Audio Throughput
8.7.5.1.3.3. To configure audio compression and output quality
8.7.5.1.3.4. Enabling Support for Microphones and Speakers
8.7.5.1.3.5. Setting Up for Digital Dictation Devices
8.7.5.1.4. Ensuring Session Continuity for Mobile Workers
8.7.5.1.5. Maintaining Session Activity
8.7.5.1.5.1. Configuring Session Reliability
8.7.5.1.5.2. Configuring Automatic Client Reconnection
8.7.5.1.5.3. Configuring ICA Keep-Alive
8.7.5.2. Managing and Monitoring XenApp Sessions
8.7.5.2.1. Monitoring Session Status
8.7.5.2.2. Viewing User Sessions
8.7.5.2.2.1. Viewing User Sessions with the Shadow Taskbar
8.7.5.2.2.2. To view user sessions with the console
8.7.5.2.2.3. Enabling Logging for Shadowing
8.7.5.2.2.4. Enabling User-to-User Shadowing with Policies
8.7.5.2.3. Managing User Sessions
8.7.5.2.3.1. To terminate processes in a users session
8.7.5.2.3.2. To display session properties
8.7.5.2.3.3. To connect to a users session from Program Neighborhood
8.7.5.2.3.4. To reset a session
8.7.5.2.3.5. To log off from a session
8.7.5.2.4. To send a message to one or more users
8.7.5.3. Controlling Client Connections in XenApp
8.7.5.3.1. Preventing Specific Client Connection Types
8.7.5.3.2. Specifying Connection Limits
8.7.5.3.2.1. Limiting Connections to a Server Farm
8.7.5.3.2.2. Sharing Sessions and Connections
8.7.5.3.2.3. Limiting Application Instances
8.7.5.3.2.4. Logging Connection Denial Events
8.7.5.3.3. Controlling Connections with Terminal Services Configuration
8.7.5.3.4. Preventing User Connections during Farm Maintenance
8.7.5.4. Optimizing User Sessions for XenApp
8.7.5.4.1. Optimizing Web Page and Email Responsiveness
8.7.5.4.1.1. Effects of Restricting Animations in Internet Explorer
8.7.5.4.1.2. SpeedScreen Browser Acceleration Limitations
8.7.5.4.1.3. Configuring SpeedScreen Browser Acceleration
8.7.5.4.2. Optimizing Audio and Video Playback
8.7.5.4.2.1. Configuring SpeedScreen Multimedia Acceleration
8.7.5.4.3. Optimizing Flash Animations
8.7.5.4.4. Optimizing Throughput of Image Files
8.7.5.4.5. Optimizing Display of Image Files
8.7.5.4.6. Optimizing Keyboard and Mouse Responsiveness
8.7.5.4.6.1. Configuring SpeedScreen Latency Reduction
8.7.5.4.6.2. Adjusting SpeedScreen Latency Reduction for an Application
8.7.5.4.6.3. To configure latency reduction settings for input fields in an application
8.7.5.4.6.4. To create exception entries for non-standard input fields in an application
8.7.5.4.7. Configuring ICA Display Settings
8.7.5.4.8. To configure ICA browser settings for a server
8.7.6. Securing Server Farms
8.7.6.1. Securing Access to Your Servers
8.7.6.2. Securing the Data Store

8.7.6.3. Securing Client-Server Communications
8.7.6.3.1. Using SecureICA
8.7.6.3.2. Enabling SSL/TLS Protocols
8.7.6.3.3. To configure session data encryption
8.7.6.3.4. To set a policy for ICA encryption
8.7.6.4. Configuring SSL/TLS Between Servers and Clients
8.7.6.4.1. Task Summary for Implementing SSL Relay
8.7.6.4.2. Obtaining and Installing Server and Root SSL Certificates
8.7.6.4.3. Choosing an SSL Certificate Authority
8.7.6.4.4. Acquiring a Signed SSL Certificate and Password
8.7.6.4.5. To enable the SSL Relay and select the relay credentials
8.7.6.4.6. Using the SSL Relay with the Microsoft Internet Information Service (IIS)
8.7.6.4.7. Configuring the Relay Port and Server Connection Settings
8.7.6.4.8. To add a server to the destination server list
8.7.6.4.9. To change the port for a server listed in the destination server list
8.7.6.4.10. To run the SSL Relay on port 443 without using HTTPS
8.7.6.4.11. Configuring the Ciphersuites Allowed by the SSL Relay
8.7.6.5. Using the Secure Gateway
8.7.6.6. Using the Secure Ticket Authority
8.7.6.7. Securing Network Communications
8.7.6.7.1. Configuring TCP Ports
8.7.6.7.2. Using Proxy Servers
8.7.6.7.3. Configuring Authentication for Workspace Control
8.7.6.8. Using Smart Cards with Citrix XenApp
8.7.6.8.1. Smart Card Requirements
8.7.6.8.2. Configuring XenApp for Smart Cards
8.7.6.9. Configuring Kerberos Logon
8.7.6.10. Logging Administrative Changes to a XenApp Farm
8.7.6.10.1. Setting up the Configuration Logging Database
8.7.6.10.2. Defining Database Permissions for Configuration Logging
8.7.6.10.3. To configure the connection to the Configuration Logging database using the Configuration
Logging Database wizard
8.7.6.10.4. To configure a SQL Server database for configuration logging
8.7.6.10.5. To configure an Oracle database for configuration logging
8.7.6.10.6. To set Configuration Logging properties
8.7.6.10.7. Delegating the Administration of Configuration Logging
8.7.6.10.8. To view Configuration Logging properties
8.7.6.10.9. Clearing Entries from the Configuration Logging Database
8.7.6.10.10. Generating Configuration Logging Reports
8.7.6.11. Encrypting Sensitive Configuration Logging Data
8.7.6.11.1. Copying the key to a local computer
8.7.6.11.2. To generate a key and enable IMA encryption on the first server in a farm
8.7.6.11.3. To load a key on subsequent servers in the farm
8.7.6.11.4. To store the key on a network location
8.7.6.11.5. Changing Farms
8.7.6.11.6. Enabling IMA Encryption Features
8.7.6.12. XenApp Service Account Privileges
8.7.7. Maintaining Server Farms
8.7.7.1. Displaying and Organizing Your Farm
8.7.7.1.1. Organizing Your Farm Display in the Console
8.7.7.2. To configure general farm properties
8.7.7.3. To search for objects in your farm
8.7.7.4. Connecting to a Remote Server Console
8.7.7.5. To connect to a servers published desktop
8.7.7.6. To connect directly to a server's desktop
8.7.7.7. To limit the number of server connections per user
8.7.7.8. To disable and re-enable server logons
8.7.7.9. Enabling Local Browsers with Published Applications
8.7.7.10. Restarting Servers at Scheduled Times
8.7.7.11. To repair a XenApp installation
8.7.7.12. Changing XenApp Farm Membership
8.7.7.13. Removing and Reinstalling XenApp

8.7.7.13.1. To remove XenApp
8.7.7.13.2. To force the uninstallation of XenApp
8.7.7.13.3. To remove a server from the farm
8.7.7.13.4. To rename a XenApp server
8.7.7.14. Monitoring Server Performance with Health Monitoring & Recovery
8.7.7.14.1. Enabling and Disabling Health Monitoring & Recovery
8.7.7.14.2. Modifying Health Monitoring & Recovery Test Settings
8.7.7.14.2.1. To modify the Health Monitoring & Recovery Tests settings for farms or a server
8.7.7.14.3. Adding Health Monitoring & Recovery Tests
8.7.7.14.4. Developing Custom Health Monitoring & Recovery Tests
8.7.7.14.5. Getting Health Monitoring & Recovery Alerts
8.7.7.15. Using Citrix Performance Monitoring Counters
8.7.7.16. Optimizing Server Performance
8.7.7.16.1. Managing CPU Usage
8.7.7.16.1.1. Enabling CPU Utilization Management
8.7.7.16.2. Managing Virtual Memory Usage
8.7.7.16.2.1. Enabling Memory Utilization Management
8.7.7.16.2.2. Scheduling Virtual Memory Optimization
8.7.7.16.2.2.1. To create a memory optimization schedule
8.7.7.16.2.3. Excluding Applications from Memory Optimization
8.7.7.16.2.3.1. To exclude additional applications from memory optimization
8.7.7.16.3. Optimizing Simultaneous Logon Performance
8.7.7.17. Managing Farm Infrastructure
8.7.7.17.1. Maintaining the Local Host Cache
8.7.7.17.1.1. Tuning Local Host Cache Synchronization
8.7.7.17.1.2. Refreshing the Local Host Cache
8.7.7.17.1.3. Recreating the Local Host Cache
8.7.7.17.2. Data Collectors and Elections
8.7.7.17.2.1. Specifying Backup Data Collectors
8.7.7.17.3. Enhancing the Performance of a Remote Group of Servers
8.7.7.17.3.1. To configure zones in your farm
8.7.7.18. Updating Citrix License Server Settings
8.7.7.18.1. To specify a default license server for a farm
8.7.7.18.2. To specify a license server for individual servers
8.7.7.19. To set the product edition
8.7.7.20. Setting the Citrix XML Service Port
8.7.7.20.1. To configure the Citrix XML Service port for a server
8.7.7.20.2. To manually change the XML Service port to use a port different from IIS after installation
8.7.7.20.3. To manually configure Citrix XML Service to share the TCP port with IIS
8.7.8. Understanding XenApp Printing
8.7.8.1. Introduction to Windows Printing Concepts
8.7.8.1.1. Local and Remote Print Job Spooling
8.7.8.2. XenApp Printing Concepts
8.7.8.2.1. Overview of Client and Network Printing Pathways
8.7.8.2.2. Provisioning Printers for Sessions
8.7.8.2.2.1. Auto-Creating Client Printers
8.7.8.2.2.2. Auto-Creating Network Printers
8.7.8.2.2.3. Letting Users Provision Their Own Printers
8.7.8.2.3. Device or Session-Based Print Settings
8.7.8.2.3.1. Device-Based Print Settings
8.7.8.2.3.2. Controlling Printing Settings and User Preferences
8.7.8.2.4. Setting Default Printers
8.7.8.2.5. Printing and Mobile Workers
8.7.8.2.6. Optimizing Printing Performance by Routing
8.7.8.2.7. Managing Printer Drivers
8.7.8.3. Planning Your Printing Configuration
8.7.8.3.1. Default Printing Behavior
8.7.8.3.2. Printing Policy Configuration
8.7.8.3.3. Printing Security
8.7.8.3.4. Purchasing Printing Hardware
8.7.9. Configuring and Maintaining XenApp Printing
8.7.9.1. Configuring Printing

8.7.9.1.1. Configuring Printer Autocreation Settings
8.7.9.1.2. Configuring Citrix Universal Printing
8.7.9.1.3. Configuring Auto-Creation for DOS and Windows CE Clients
8.7.9.1.4. Configuring Network Printers for Users
8.7.9.1.4.1. To import printers from a network print server
8.7.9.1.4.2. To import printers from other domains
8.7.9.1.4.3. To assign printers using the Session printers policy rule
8.7.9.1.4.4. To add a network printer while configuring the Session printers rule
8.7.9.1.4.5. To specify a default printer for a session
8.7.9.1.4.6. To edit the printer settings in the sessions policy
8.7.9.1.4.7. To configure server local printers
8.7.9.1.5. Configuring Printers for Mobile Workers
8.7.9.1.6. Changing Network Print Job Routing
8.7.9.1.7. Providing Tools for User Provisioning
8.7.9.1.8. To store users printer properties
8.7.9.1.9. To synchronize properties from the printer
8.7.9.1.10. Controlling Printer Driver Automatic Installation
8.7.9.1.11. Configuring Universal Printer Drivers on Farm Servers
8.7.9.1.12. Mapping Client Printer Drivers
8.7.9.2. Increasing Printing Speed and Session Performance
8.7.9.3. Updating Network Print Server Information
8.7.9.4. Replicating Printer Drivers Across a Farm
8.7.9.4.1. Replicating Printer Drivers Manually
8.7.9.4.2. Replicating Printer Drivers Automatically
8.7.9.5. Displaying Printers
8.7.9.5.1. Displaying Printers Using the Network Printing Pathway
8.7.9.5.2. Displaying Printers Using the Client Printing Pathway
8.7.9.6. Displaying Drivers
8.7.10. XenApp Commands Reference
8.7.10.1. ACRCFG
8.7.10.2. ALTADDR
8.7.10.3. APP
8.7.10.4. AUDITLOG
8.7.10.5. CHANGE CLIENT
8.7.10.6. CHFARM
8.7.10.6.1. To move a server to a new server farm using SQL Server Express
8.7.10.7. CTXKEYTOOL
8.7.10.8. CTXXMLSS
8.7.10.9. DRIVEREMAP
8.7.10.10. DRIVEREMAP64
8.7.10.11. DSCHECK
8.7.10.12. DSMAINT
8.7.10.13. ENABLELB
8.7.10.14. ICAPORT
8.7.10.15. IMAPORT
8.7.10.16. MIGRATETOSQLEXPRESS
8.7.10.17. QUERY FARM
8.7.10.18. QUERY PROCESS
8.7.10.19. QUERY SESSION
8.7.10.20. QUERY TERMSERVER
8.7.10.21. QUERY USER
8.7.10.22. TWCONFIG
8.7.11. Policy Rules Reference
8.7.11.1. Policy Rules: Quick Reference Table
8.7.11.2. Bandwidth Folder
8.7.11.2.1. Visual Effects Folder
8.7.11.2.2. SpeedScreen Folder
8.7.11.2.3. Session Limits and Session Limits (%) Folder
8.7.11.3. Client Devices Folder
8.7.11.3.1. Resources Folder
8.7.11.3.1.1. Audio Folder
8.7.11.3.1.2. Drives Folder

8.7.11.3.1.2.1. Optimize Folder
8.7.11.3.1.3. Other Folder
8.7.11.3.1.4. Ports Folder
8.7.11.3.1.5. PDA Devices folder
8.7.11.3.2. Maintenance Folder
8.7.11.4. Printing Folder
8.7.11.5. User Workspace Folder
8.7.11.5.1. Connections Folder
8.7.11.5.2. Content Redirection Folder
8.7.11.5.3. Shadowing Folder
8.7.11.5.3.1. Configuring User Shadowing
8.7.11.5.3.2. Permissions to Shadow Users
8.7.11.5.4. Time Zones Folder
8.7.11.5.5. Citrix Password Manager Folder
8.7.11.5.6. Streamed Applications Folder
8.7.11.6. Security and Encryption Folders
8.7.12. Performance Counters Reference
8.7.12.1. Citrix CPU Utilization Mgmt User Counters
8.7.12.2. Citrix IMA Networking Counters
8.7.12.3. Citrix Licensing Counters
8.7.12.4. Citrix MetaFrame Presentation Server Counters
8.7.12.5. ICA Session Counters
8.7.12.6. Secure Ticket Authority Counters
8.8. Application Streaming
8.8.1. Components for Application Streaming
8.8.2. Creating Application Profiles
8.8.2.1. Targets Overview
8.8.2.1.1. Service Pack Level
8.8.2.1.2. System Drive Letter
8.8.2.1.3. Operating System Language
8.8.2.2. Managing Isolation Environment Rules
8.8.2.2.1. Types of Isolation Environment Rules
8.8.2.2.2. Restrictions and Limitations for Rules
8.8.2.2.3. Creating Isolation Environment Rules for a Target
8.8.2.2.4. To create an isolation environment rule
8.8.2.2.5. To modify a rule
8.8.2.2.6. Using Environment Variables to Construct Rules
8.8.2.3. Preparing a Workstation for Profiling Applications
8.8.2.3.1. Known Limitations for Profiling
8.8.2.3.2. To install the profiler
8.8.2.3.3. To start the profiler
8.8.2.3.4. To disable and enable profile signing
8.8.2.4. Creating a Profile and Its Initial Target
8.8.2.4.1. To create a profile and target
8.8.2.4.2. To install multiple applications through Advanced Install
8.8.2.4.3. To set user profile security
8.8.2.4.4. To install Internet Explorer plug-ins
8.8.2.4.5. To include files and folders in a target
8.8.2.4.6. To include registry settings
8.8.2.4.7. To choose an installation program for the application
8.8.2.4.8. To run an application in the profiler
8.8.2.4.9. To select applications for listing in the profile
8.8.2.4.10. To sign a profile
8.8.2.5. Editing Profiles
8.8.2.5.1. To view profile information
8.8.2.5.2. To edit the profile name, description, or location
8.8.2.5.3. To view details about applications in a profile
8.8.2.5.4. To view File Type Associations set in a profile
8.8.2.5.5. To check for launch prerequisites
8.8.2.5.6. To check for prerequisite registry entries
8.8.2.5.7. To check prerequisite applications and files
8.8.2.5.8. To specify pre-launch and post-exit scripts

8.8.2.5.9. To add a target to a profile
8.8.2.5.10. To resolve target conflicts
8.8.2.5.11. To delete a folder from a profile
8.8.2.5.12. To delete a target from a profile
8.8.2.5.13. To resolve invalid shortcuts
8.8.2.6. Editing Targets
8.8.2.6.1. To edit the target name and description
8.8.2.6.2. To modify the application properties in the target
8.8.2.6.3. To modify the operating system and language properties of a target
8.8.2.6.4. To check for launch prerequisites for a target
8.8.2.6.5. To specify pre-launch and post-exit scripts for a target
8.8.2.6.6. To update a target
8.8.2.6.7. To remove an old version of an updated target
8.8.2.7. Profile Contents on the Server
8.8.2.7.1. Manifest File
8.8.2.7.2. Targets
8.8.2.7.3. Digital Signature
8.8.2.7.4. Icons
8.8.2.7.5. Scripts
8.8.3. Managing Streamed Applications
8.8.3.1. Publishing Streamed Applications
8.8.3.1.1. Streaming Applications to Client Devices
8.8.3.1.2. Accessing Applications from a XenApp Server
8.8.3.1.3. To publish an application for streaming
8.8.3.1.4. To select a streaming delivery method
8.8.3.1.5. To specify a farm-wide policy for delivery
8.8.3.1.6. To enable event logging and a trust relationship to the client
8.8.3.2. Configuring Offline Access
8.8.3.2.1. To set the license period for offline users
8.8.3.2.2. To renew offline licenses
8.8.3.2.3. Indirect Membership to the Offline Access User List
8.8.3.2.4. Experiencing Offline Access
8.8.4. Managing the XenApp Streaming Plug-in
8.8.4.1. XenApp Streaming Plug-in Overview
8.8.4.2. Managing the XenApp Streaming Plug-in
8.8.4.2.1. To install the XenApp Streaming Plug-in
8.8.4.2.2. To configure the cache size of the streaming plug-in
8.8.4.2.3. To deploy the XenApp Streaming Plug-in
8.8.4.2.4. To configure an .MSI package using transforms

8.8.4.2.5. To deploy the XenApp Streaming Plug-in to client devices through Active Directory
8.8.4.2.6. To deploy applications to client devices
8.8.4.2.7. To clear the streamed application cache on user devices
8.9. Enterprise Management
8.9.1. Management Pack for Microsoft Operations Manager 2000
8.9.2.1. Management Pack Features
8.9.2.2. The Management Pack and the Providers
8.9.2.3. Citrix Views in the Management Pack
8.9.2.3.1. Health Monitoring Views
8.9.2.3.2. Discovery Views
8.9.2.3.3. Deployment Topology View
8.9.2.3.4. State View: the Citrix Server and Citrix Licensing Roles
8.9.2.4. XenApp Managed and Unmanaged Computers
8.9.2.5. About Citrix Computer Groups
8.9.2.6. To install or upgrade the Management Pack for MOM 2005
8.9.2.7. Management Pack Post-Installation Tasks
8.9.2.7.1. Security Considerations for the Management Pack
8.9.2.7.2. Troubleshooting Query Errors in MOM
8.9.2.8. Configuring Topology Discovery
8.9.2.9. To specify server farm and zone computer groups
8.9.2.10. To configure Citrix Administrators as MOM operators
8.9.2.11. To change the format of net send messages
8.9.2.12. Configuring and Enabling Site-specific Rules for MOM 2005
8.9.2.12.1. Too Many Disconnected Sessions
8.9.2.12.2. Idle Sessions
8.9.2.12.3. Too Many Active Sessions
8.9.2.12.4. Sample Published Application Load
8.9.2.13. To open the Access Management Console from the MOM Operator Console
8.9.2.13.1. To change the Access Management Console path with the MOM Administrator Console
8.9.3. Installation Manager
8.9.4. Network Manager for Citrix Presentation Server
8.9.5. Resource Manager
8.9.6. Managing Providers and WMI
8.9.6.1. XenApp Provider Overview
8.9.6.2. Licensing Provider Overview
8.9.6.3. Installing the XenApp Provider
8.9.6.4. Installing the Licensing Provider
8.9.6.5. Starting the Provider Services
8.9.6.6. Security Considerations
8.9.6.7. Uninstalling the Providers
8.9.6.8. WMI Schema
8.9.6.8.1. XenApp Provider WMI Schema (Part 1 of 3)
8.9.6.8.4. Citrix Licensing Provider WMI Schema
8.10. Load Manager
8.10.1. Working with Load Manager Rules
8.10.1.1. List of Load Manager Rules
8.10.2. Working with Load Evaluators
8.10.2.1. Viewing and Modifying Load Evaluator Properties
8.10.2.2. Creating Load Evaluators
8.10.2.3. Assigning Load Evaluators to Servers and Applications
8.10.2.4. Copying Load Evaluators
8.10.2.5. Deleting Load Evaluators
8.10.2.6. Scheduling Server Availability
8.10.3. Monitoring Server Loads
8.10.3.1. Logging Load Manager Activity
8.10.3.2. Setting the Frequency of Information Updates
8.10.3.3. Viewing Usage Reports
8.11. Secure Gateway
8.11.1. Citrix XenApp Components That Work with Secure Gateway

8.11.1.1. Secure Gateway Features
8.11.2. System Requirements for Secure Gateway
8.11.2.1. System Hardware Requirements
8.11.2.2. Citrix Products Compatibility with Secure Gateway
8.11.2.3. Certificate Requirements
8.11.3. Planning a Secure Gateway Deployment
8.11.3.1. Deploying the Secure Gateway in a Single-Hop DMZ
8.11.3.1.1. Running the Web Interface behind the Secure Gateway in the Demilitarized Zone
8.11.3.1.2. Locking Down Internet Information Services
8.11.3.1.3. Running the Web Interface Parallel with the Secure Gateway
8.11.3.1.4. Setting Up the Web Interface and the Secure Gateway in a Single-Hop Demilitarized Zone
8.11.3.2. Deploying the Secure Gateway in a Double-Hop DMZ
8.11.3.2.1. Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ
8.11.3.2.2. Publishing the Web Address for the Secure Gateway in a Double-Hop Demilitarized Zone
8.11.3.3. Setting Up and Testing a Server Farm
8.11.3.4. Installing the Secure Ticket Authority
8.11.3.5. Testing Your Deployment
8.11.4. Installing and Configuring the Secure Gateway and Secure Gateway Proxy
8.11.4.1. Upgrading Secure Gateway or Secure Gateway Proxy
8.11.4.2. Using Firewall Software with the Secure Gateway or Secure Gateway Proxy
8.11.4.3. Installing the Secure Gateway or Secure Gateway Proxy
8.11.4.3.1. To install the Secure Gateway or Secure Gateway Proxy
8.11.4.4. Configuring the Secure Gateway or Secure Gateway Proxy
8.11.4.4.1. To start the configuration wizard manually
8.11.4.4.2. To select a configuration level (Secure Gateway)
8.11.4.4.3. To select a configuration level (Secure Gateway Proxy)
8.11.4.4.4. Task Summary for Secure Gateway, Advanced or Standard Configuration
8.11.4.4.5. Task Summary for Secure Gateway Proxy, Advanced or Standard Configuration
8.11.4.4.6. To select a server certificate
8.11.4.4.7. To configure secure protocol settings
8.11.4.4.8. To configure inbound client connections
8.11.4.4.9. To configure outbound connections
8.11.4.4.9.1. To configure an access control list for outbound connections
8.11.4.4.9.2. To configure servers running the Secure Gateway Proxy
8.11.4.4.10. To add the Secure Ticket Authority details
8.11.4.4.11. To configure connection parameters
8.11.4.4.12. To configure logging exclusions
8.11.4.4.13. To add the Web Interface server details
8.11.4.4.14. To configure the logging parameters
8.11.4.4.15. To complete the configuration
8.11.4.4.15.1. To stop the Secure Gateway/Secure Gateway Proxy service
8.11.4.5. To uninstall the Secure Gateway
8.11.5. Managing the Secure Gateway
8.11.5.1. Viewing Session and Connection Information with the Secure Gateway Console
8.11.5.2. Viewing Secure Gateway Performance Statistics
8.11.5.2.1. To view the Secure Gateway performance statistics
8.11.5.2.2. Performance Counters Available for the Secure Gateway
8.11.5.3. Generating the Secure Gateway Diagnostics Report
8.11.5.4. Viewing the Secure Gateway Events
8.11.5.5. Viewing the Secure Gateway Access Logs
8.11.5.6. Secure Gateway Configuration Wizard
8.11.6. Secure Gateway Optimization and Security Guidelines
8.11.6.1. Configuring Firewalls for the Secure Gateway
8.11.6.2. Ensuring High Availability of the Secure Gateway
8.11.6.2.1. Load Balancing Multiple Secure Gateway Servers
8.11.6.2.2. Load Balancing an Array of the Secure Gateway Proxy
8.11.6.2.3. Certificate Requirements for Load Balancing Secure Gateway Servers
8.11.6.2.4. Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers
8.11.6.3. Coordinating Keep-Alive Values Between the Secure Gateway and Citrix XenApp
8.11.6.3.1. Setting Connection Keep-Alive Values and the Secure Gateway
8.11.6.4. Improving Security (Recommendations)
8.11.6.5. Preventing Indexing by Search Engines

8.11.7. Troubleshooting the Secure Gateway
8.11.7.1. To check your certificates
8.11.7.2. Client Connections Launched from IP Addresses in the Logging Exclusions List Fail
8.11.7.3. Load Balancers Do Not Report Active Client Sessions if Connections Are Idle
8.11.7.4. Performance Issues with Transferring Files Between a Client Device and a Citrix XenApp Server
8.11.7.5. Gateway Client Connections Fail When Using Windows XP Service Pack 2
8.11.7.6. Failed Client Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log
8.11.7.7. Placing the Secure Gateway Behind a Reverse Web Proxy Causes an SSL Error 4
8.11.7.7.1. Run the Secure Gateway Parallel to the Reverse Web Proxy
8.11.7.7.2. Use a Network Address Translator Instead of a Reverse Web Proxy
8.11.8. Digital Certificates and the Secure Gateway
8.11.8.1. Understanding Cryptography
8.11.8.1.1. Types of Cryptography
8.11.8.1.2. Combining Public Key and Secret Key Cryptography
8.11.8.2. Understanding Digital Certificates and Certificate Authorities
8.11.8.2.1. Certificate Chains
8.11.8.2.2. Certificate Revocation Lists
8.11.8.3. Deciding Where to Obtain Certificates
8.11.8.4. Obtaining and Installing Server Certificates
8.11.8.5. Obtaining and Installing Root Certificates
8.11.8.6. Support for Wildcard Certificates with the Secure Gateway
8.11.9. Using the Secure Gateway Proxy in Relay Mode
8.11.9.1. Modes of Operation for the Secure Gateway Proxy
8.11.9.2. How Relay Mode Works
8.11.9.3. Installing the Secure Gateway Proxy in Relay Mode
8.11.9.3.1. To install the Secure Gateway Proxy in relay mode
8.11.9.3.2. To configure the Secure Gateway in relay mode
8.11.9.4. Configuring Plug-ins for Secure Gateway
8.11.9.4.1. To configure plug-in connections to the Secure Gateway Proxy
8.11.9.4.2. To configure all application sets for the plug-in to connect to the Secure Gateway Proxy
8.11.9.5. To test the Secure Gateway relay mode
8.11.9.6. To start or stop the Secure Gateway Proxy Service manually
8.12. SmartAuditor
8.12.1. Example Usage Scenarios
8.12.2. Getting Started with SmartAuditor
8.12.2.1. Planning Your Deployment
8.12.2.2. Security Recommendations
8.12.2.2.1. Installing Certificates
8.12.2.3. Scalability Considerations
8.12.2.4. Important Deployment Notes
8.12.2.5. Pre-Installation Checklist
8.12.2.6. To install SmartAuditor
8.12.2.7. Automating Installations
8.12.2.8. Uninstalling SmartAuditor
8.12.2.9. To configure SmartAuditor to play and record sessions
8.12.3. Granting Access Rights to Users
8.12.4. Creating and Activating Recording Policies
8.12.4.1. Using System Policies
8.12.4.2. Creating Custom Policies
8.12.4.2.1. To create a new policy
8.12.4.2.2. To modify a policy
8.12.4.2.3. To delete a policy
8.12.4.3. To activate a policy
8.12.4.4. Understanding Rollover Behavior
8.12.5. To disable or enable recording
8.12.6. To configure the connection to the SmartAuditor Server
8.12.7. Creating Notification Messages
8.12.8. Enabling Custom Event Recording
8.12.9. To enable or disable live session playback
8.12.10. To enable or disable playback protection
8.12.11. To enable and disable digital signing
8.12.12. To specify where recordings are stored

8.12.13. Specifying File Size for Recordings
8.12.14. Viewing Recordings
8.12.14.1. To launch the SmartAuditor Player
8.12.14.2. To open and play recordings
8.12.14.3. To search for recorded sessions
8.12.14.4. To play recorded sessions
8.12.14.5. To use events and bookmarks
8.12.14.6. To change the playback display
8.12.14.7. To display or hide window elements
8.12.14.8. To cache recorded session files
8.12.14.9. To change SmartAuditor Servers
8.12.15. Troubleshooting SmartAuditor
8.12.15.1. Verifying Component Connections
8.12.15.1.1. Testing IIS Connectivity
8.12.15.1.2. Troubleshooting Certificate Issues
8.12.15.2. SmartAuditor Agent Cannot Connect
8.12.15.3. SmartAuditor Server Cannot Connect to the SmartAuditor Database
8.12.15.4. Sessions are not Recording
8.12.15.5. Searching for Recordings in the Player Fails
8.12.15.5.1. Troubleshooting MSMQ
8.12.15.6. Unable to View Live Session Playback
8.12.15.7. To change your communication protocol
8.12.16. Reference: Managing Your Database Records
8.13. Glossary
9.1. Security Considerations in a XenApp Deployment
9.1.1. Country-Specific Government Information
9.1.2. FIPS 140 and XenApp
9.1.3. TLS/SSL Protocols
9.1.3.1. Government Ciphersuites
9.1.4. IP Security
9.1.5. Citrix Password Manager
9.1.6. Smart Cards
9.1.6.1. Smart Card Support
9.1.7. Kerberos Authentication
9.1.8. Citrix XenApp Plugins
9.1.8.1. Standards Summary
9.1.9. Virtual Channels
9.1.10. Additional XenApp Security Features
9.1.10.1. ICA Encryption Using SecureICA
9.1.10.2. Authentication for the Web Interface Using RSA SecurID
9.1.10.3. Authentication for the Web Interface Using SafeWord
9.2. Deployment Samples
9.2.1. Sample A Using the SSL Relay
9.2.1.1. How the Components in Sample Deployment A Interact
9.2.1.2. FIPS 140 Validation in Sample Deployment A
9.2.1.3. TLS/SSL Support in Sample Deployment A
9.2.1.3.1. Supported Ciphersuites for Sample Deployment A
9.2.1.3.2. Certificates and Certificate Authorities in Sample Deployment A
9.2.1.4. Smart Card Support in Sample Deployment A
9.2.1.5. Plugins Used in Sample Deployment A
9.2.2. Sample B Using Secure Gateway (Single-Hop)
9.2.2.1. How the Components in Sample Deployment B Interact
9.2.2.1.1. IPSec in Sample Deployment B
9.2.2.2. FIPS 140 Validation in Sample Deployment B
9.2.2.3. TLS/SSL Support in Sample Deployment B
9.2.2.3.1. Supported Ciphersuites for Sample Deployment B
9.2.2.3.2. Certificates and Certificate Authorities in Sample Deployment B
9.2.2.4. Smart Card Support in Sample Deployment B
9.2.2.5. Plugins Used in Sample Deployment B
9.2.3. Sample C Using Secure Gateway (Double-Hop)
9.2.3.1. How the Components in Sample Deployment C Interact

9.2.3.1.1. IPSec in Sample Deployment C
9.2.3.2. FIPS 140 Validation in Sample Deployment C
9.2.3.3. TLS/SSL Support in Sample Deployment C
9.2.3.3.1. Supported Ciphersuites for Sample Deployment C
9.2.3.3.2. Certificates and Certificate Authorities in Sample Deployment C
9.2.3.4. Smart Card Support in Sample Deployment C
9.2.3.5. Plugins Used in Sample Deployment C
9.2.4. Sample D Using the SSL Relay and the Web Interface
9.2.4.1. How the Components in Sample Deployment D Interact
9.2.4.2. FIPS 140 Validation in Sample Deployment D
9.2.4.3. TLS/SSL Support in Sample Deployment D
9.2.4.3.1. Supported Ciphersuites for Sample Deployment D
9.2.4.3.2. Certificates and Certificate Authorities in Sample Deployment D
9.2.4.4. Smart Card Support in Sample Deployment D
9.2.4.5. Plugins Used in Sample Deployment D
9.2.5. Sample E Using Password Manager and Secure Gateway (Single-Hop)
9.2.5.1. How the Components in Sample Deployment E Interact
9.2.5.1.1. IPSec in Sample Deployment E
9.2.5.2. FIPS 140 Validation in Sample Deployment E
9.2.5.3. TLS/SSL Support in Sample Deployment E
9.2.5.3.1. Supported Ciphersuites for Sample Deployment E
9.2.5.3.2. Certificates and Certificate Authorities in Sample Deployment E
9.2.5.4. Smart Card Support in Sample Deployment E
9.2.5.5. Plugins Used in Sample Deployment E
10. XenApp for UNIX
10.1. Citrix XenApp 4.0, with Feature Pack 2, for UNIX
10.1.1. XenApp 4.0, with Feature Pack 2, for UNIX Release Note
10.1.2. Citrix XenApp 4.0, with Feature Pack 2, for UNIX Readme
10.1.3. Licensing XenApp for UNIX
10.2.2. XenApp for UNIX Administration
10.2.2.1. Introducing XenApp for UNIX
10.2.2.1.1. Key Features
10.2.2.1.2. Whats New in Feature Pack 1 for Version 4.0?
10.2.2.1.3. UNIX Command-Line Conventions
10.2.2.1.4. Getting Started Quickly
10.2.2.2. Deploying XenApp for UNIX
10.2.2.2.1. Before You Begin Installing
10.2.2.2.2. System Requirements
10.2.2.2.2.1. Hardware Requirements
10.2.2.2.2.2. Software Requirements
10.2.2.2.2.3. SSL Relay Requirements
10.2.2.2.2.4. Euro Currency Symbol Support
10.2.2.2.3. Installing XenApp
10.2.2.2.3.1. Creating the Administrator Users and Group
10.2.2.2.3.2. Installing XenApp Using the Installer Script
10.2.2.2.3.3. Performing an Unattended Install
10.2.2.2.3.3.1. Performing an Unattended Install on Solaris
10.2.2.2.3.3.2. Performing an Unattended Install on HP-UX
10.2.2.2.3.3.3. Performing an Unattended Install on AIX
10.2.2.2.3.3.4. After Unattended Installation
10.2.2.2.4. Setting the Paths to XenApp Commands
10.2.2.2.4.1. Configuring User Access to Commands
10.2.2.2.4.2. Configuring Administrator Access to Commands
10.2.2.2.5. Setting the Path to the man Pages
10.2.2.2.6. Starting and Stopping XenApp
10.2.2.2.7. About Client Keyboard Support
10.2.2.2.7.1. Configuring Non-English Keyboard Support
10.2.2.2.8. Configuring Event Logging
10.2.2.2.9. Removing XenApp
10.2.2.2.10. What to Do Next

10.2.2.3. Introducing Server Farms
10.2.2.3.1. Server Farm Components
10.2.2.3.2. Communication between Servers in a Farm
10.2.2.3.3. Multiple Farms and Subnet Considerations
10.2.2.3.4. Integrating with Other XenApp Servers
10.2.2.3.5. Creating a Server Farm
10.2.2.3.6. Joining a Server Farm
10.2.2.3.6.1. Moving a Server to a Different Farm
10.2.2.3.6.2. Troubleshooting Joining a Server Farm
10.2.2.3.7. Removing a Server from a Farm
10.2.2.3.8. Renaming a Server
10.2.2.3.9. Identifying Servers in a Farm
10.2.2.4. Licensing XenApp for UNIX
10.2.2.4.1. Licensing XenApp for UNIX: An Overview
10.2.2.4.2. Configuring Communication with the License Server
10.2.2.5. Publishing Applications and Desktops
10.2.2.5.1. Why Publish Applications?
10.2.2.5.2. Publishing Applications for Explicit or Anonymous Use
10.2.2.5.3. Publishing an Application, Shell Script, or Desktop
10.2.2.5.3.1. Publishing Applications
10.2.2.5.3.2. Publishing a Shell Script
10.2.2.5.3.3. Publishing a Desktop
10.2.2.5.3.4. Publishing a Java Application
10.2.2.5.3.5. Publishing a UNIX Command-Line Application
10.2.2.5.3.6. Publishing an Application on a UNIX Server of Different Architecture
10.2.2.5.3.7. Specifying a Working Directory for Published Applications
10.2.2.5.3.8. Publishing an Application to Accept Parameters from the Plugin
10.2.2.5.4. Displaying Published Application Details
10.2.2.5.5. Maintaining Published Applications
10.2.2.5.5.1. Changing the Settings of a Published Application
10.2.2.5.5.2. Displaying and Changing the Icon File
10.2.2.5.5.3. Specifying Default Settings for Published Applications
10.2.2.5.5.4. Configuring User Access to Published Applications
10.2.2.5.5.5. Managing the Servers that Publish an Application
10.2.2.5.5.6. Deleting a Published Application from All Servers
10.2.2.5.6. Enabling and Disabling Published Applications
10.2.2.5.7. Creating a New Published Application from Existing Details
10.2.2.5.8. Renaming a Published Application
10.2.2.5.9. Restricting Connections to Published Applications Only
10.2.2.5.10. Configuring an Initial Program
10.2.2.5.11. Publishing Preconfigured Applications for Anonymous Use
10.2.2.6. Managing Servers, Users, and Sessions
10.2.2.6.1. Displaying Information about Users and Sessions
10.2.2.6.1.1. Displaying More Details or Details in a Different Format
10.2.2.6.1.2. About the Display
10.2.2.6.2. Displaying Information about Servers on the Network
10.2.2.6.3. Ending a Session
10.2.2.6.3.1. Logging off from a Session
10.2.2.6.3.2. Disconnecting a Session
10.2.2.6.4. Connecting to a Disconnected Session
10.2.2.6.5. Resetting a Session
10.2.2.6.6. Reconnecting to Load Balanced Sessions
10.2.2.6.7. Shadowing a Users Session
10.2.2.6.7.1. Starting Shadowing
10.2.2.6.7.2. About Shadowing and the Clipboard
10.2.2.6.7.3. Ending Shadowing
10.2.2.6.8. Sending Messages to Users
10.2.2.6.9. Printing
10.2.2.6.9.1. Displaying Client Printers or Printer Ports
10.2.2.6.9.2. Printing from a Command Line
10.2.2.6.9.3. Printing from Applications

10.2.2.6.9.4. Troubleshooting Printing
10.2.2.6.10. Connecting to a Remote Server from an ICA Session
10.2.2.7. Configuring XenApp for UNIX
10.2.2.7.1. Configuring the Server
10.2.2.7.1.1. Controlling Logon Settings
10.2.2.7.1.2. Setting the Number of Permitted ICA Connections
10.2.2.7.1.3. Disabling New Logons
10.2.2.7.1.4. Controlling Behavior for Disconnected or Broken Connections
10.2.2.7.1.5. Enabling or Disabling Printing for Users
10.2.2.7.1.6. Enabling or Disabling Clipboard Mapping
10.2.2.7.1.7. Providing Additional Graphics Clipboard Support
10.2.2.7.1.8. Enabling or Disabling Shadowing
10.2.2.7.1.9. Controlling Time-Out Behavior
10.2.2.7.1.10. Allowing Users to Log on without a Home Directory
10.2.2.7.1.11. Configuring Mouse-Click Feedback for High Latency Connections
10.2.2.7.1.12. Generating and Using Server Configuration Details
10.2.2.7.1.13. Screensaver Setting Recommendations
10.2.2.7.2. Customizing the Appearance of XenApp
10.2.2.7.2.1. Customizing the Login Screen
10.2.2.7.2.2. Changing the Window Manager
10.2.2.7.2.2.1. Troubleshooting the ctxwm Window Manager
10.2.2.7.2.3. Changing the Font Path
10.2.2.7.3. Configuring X Server Settings
10.2.2.7.3.1. Configuring Backing Store
10.2.2.7.3.2. Interactive Performance Tuning
10.2.2.7.3.3. Configuration Required for Fixes to Take Effect
10.2.2.7.3.3.1. Fixing the Disappearing Text Cursor Problem
10.2.2.7.3.3.2. Enabling the Left-Hand Keypad of SPARC Keyboards
10.2.2.7.3.3.3. Fixing the Disappearing X Cursor Problem
10.2.2.7.3.3.4. Fixing Screen Refresh Problems
10.2.2.7.3.3.5. Fixing NUM LOCK Problems
10.2.2.7.3.3.6. Fixing Java Application Splash Screen Problems
10.2.2.7.3.3.7. Disabling Color Cursor Support
10.2.2.7.3.3.8. Disabling Scrollmouse Support
10.2.2.7.4. Color Depth Limitations
10.2.2.7.5. Multimonitor Display Limitations
10.2.2.8. Advanced Topics
10.2.2.8.1. Configuring Anonymous Users
10.2.2.8.1.1. Displaying Anonymous User Settings
10.2.2.8.1.2. Configuring Anonymous User Settings
10.2.2.8.1.2.1. Changing the Number of Anonymous Users
10.2.2.8.1.2.2. Changing the Naming of Anonymous User Accounts
10.2.2.8.1.2.3. Setting an Idle Time-Out Period
10.2.2.8.1.2.4. Specifying a Particular Shell for Anonymous Users
10.2.2.8.1.2.5. Specifying User Ids for Anonymous Users
10.2.2.8.1.3. Troubleshooting Anonymous User Accounts
10.2.2.8.2. Configuring XenApp Security
10.2.2.8.2.1. Security Overview
10.2.2.8.2.2. Default Security Settings
10.2.2.8.2.3. Displaying Security Settings for a Function
10.2.2.8.2.4. Configuring Security Settings
10.2.2.8.2.4.1. To change a global security setting
10.2.2.8.2.4.2. To configure security for a user
10.2.2.8.2.4.3. To configure security for a group of users
10.2.2.8.2.4.4. To inherit a security setting
10.2.2.8.2.5. Examples
10.2.2.8.3. XenApp for UNIX and the ICA Browser Service
10.2.2.8.3.1. Controlling the Master Browser
10.2.2.8.3.2. Manipulating Master Browser Elections
10.2.2.8.3.3. Introducing a New Server
10.2.2.8.3.3.1. Biasing the Results of Elections
10.2.2.8.3.3.2. Configuring the ICA Browser

10.2.2.8.3.3.3. Starting and Stopping the ICA Browser
10.2.2.8.3.3.4. If a Server Uses Multiple Network Interface Cards
10.2.2.8.4. Load Balancing Published Applications
10.2.2.8.4.1. Load Balancing a Group of Servers
10.2.2.8.4.2. Tuning Load Balancing
10.2.2.8.4.3. Troubleshooting Load Balancing
10.2.2.8.5. Configuring ICA Gateways
10.2.2.8.6. Using ICA with Network Firewalls
10.2.2.8.7. ICA Browsing with Network Address Translation
10.2.2.8.8. Configuring the TCP/IP Port Number
10.2.2.8.9. Configuring Session Status Logging
10.2.2.8.10. Configuring the Operating System for a Large Number of Connections
10.2.2.8.10.1. Configuring a Solaris System
10.2.2.8.10.1.1. Changing the Number of Pseudo-Terminals
10.2.2.8.10.1.2. Increasing File Limits
10.2.2.8.10.1.3. Increasing the Number of Concurrent CDE Sessions
10.2.2.8.10.1.4. If the Database Gets Corrupted
10.2.2.8.10.2. Configuring an HP-UX System
10.2.2.8.10.3. Configuring an AIX System
10.2.2.8.10.3.2. Increasing the Number of Processes Per User
10.2.2.8.11. Configuring Non-English Language Support
10.2.2.8.11.1. Which Locales Provide Non-English Language Support?
10.2.2.8.11.2. Limitations of Non-English Language Support
10.2.2.8.11.3. Changing the Locale
10.2.2.8.11.4. Troubleshooting Non-English Language Support
10.2.2.9. Using the Citrix XML Service
10.2.2.9.1. Getting Started with the Citrix XML Service
10.2.2.9.2. Starting and Stopping the Citrix XML Service
10.2.2.9.3. Configuring the Server Port
10.2.2.9.4. Configuring the XML Service for Use with SSL Relay
10.2.2.9.5. Configuring DNS Address Resolution
10.2.2.10. Using Client Drive Mapping
10.2.2.10.1. Enabling Client Drive Mapping
10.2.2.10.2. Configuring Access to Specific Drives
10.2.2.10.2.1. To configure access to specific drives for every user
10.2.2.10.2.2. To configure access to specific drives for a particular trusted user
10.2.2.10.2.3. To configure access to specific drives for a particular untrusted user
10.2.2.10.3. Disabling Client Drive Mapping
10.2.2.10.4. Features and Limitations of Client Drive Mapping
10.2.2.10.4.1. How Does Client Drive Mapping Work?
10.2.2.10.4.2. File Names
10.2.2.10.4.3. File Permissions
10.2.2.10.4.4. File Attributes
10.2.2.10.4.5. File Formats
10.2.2.10.5. Troubleshooting Client Drive Mapping
10.2.2.10.5.1. Client Drive Mapping Does not Work
10.2.2.10.5.2. Invalid Directory or Stale File Error Messages
10.2.2.10.5.3. Problems Accessing and Updating Files
10.2.2.10.5.4. A File Looks Different when Displayed in an ICA Session
10.2.2.10.5.5. NFS Error Messages
10.2.2.11. Command Reference
10.2.2.11.1. XenApp Commands
10.2.2.11.1.1. ctx3bmouse
10.2.2.11.1.2. ctxalt
10.2.2.11.1.3. ctxanoncfg
10.2.2.11.1.4. ctxappcfg
10.2.2.11.1.5. ctxbrcfg
10.2.2.11.1.6. ctxcapture
10.2.2.11.1.7. ctxcfg
10.2.2.11.1.8. ctxconnect
10.2.2.11.1.9. ctxcreatefarm
10.2.2.11.1.10. ctxdisconnect
10.2.2.11.1.11. ctxfarm
10.2.2.11.1.12. ctxgrab
10.2.2.11.1.13. ctxjoinfarm
10.2.2.11.1.14. ctxlogoff
10.2.2.11.1.15. ctxlpr
10.2.2.11.1.16. ctxlsdcfg
10.2.2.11.1.17. ctxmaster
10.2.2.11.1.18. ctxmount
10.2.2.11.1.19. ctxmsg
10.2.2.11.1.20. ctxprinters
10.2.2.11.1.21. ctxqserver
10.2.2.11.1.22. ctxqsession
10.2.2.11.1.23. ctxquery
10.2.2.11.1.24. ctxquser
10.2.2.11.1.25. ctxreset
10.2.2.11.1.26. ctxsecurity
10.2.2.11.1.27. ctxshadow
10.2.2.11.1.28. ctxshutdown
10.2.2.11.1.29. ctxsrv
10.2.2.11.2. XML Service Commands
10.2.2.11.2.1. ctxnfusesrv
10.2.3. SSL Relay for UNIX Administration
10.2.3.1. Introducing SSL Relay
10.2.3.1.1. Overview of Security, SSL, and Cryptography
10.2.3.1.1.1. Understanding the Threats to Secure Communications
10.2.3.1.1.2. Using SSL to Tackle Security Threats
10.2.3.1.1.3. Comparing SSL with Citrix SecureICA
10.2.3.1.1.4. About Cryptography
10.2.3.1.2. Getting Started - A Summary of the Steps
10.2.3.1.2.1. To get SSL Relay up and running
10.2.3.2. Planning Your SSL Relay Deployment
10.2.3.2.1. Choosing an Appropriate Security Solution
10.2.3.2.2. Obtaining a Digital Certificate
10.2.3.2.2.1. Determining the Certificates Required
10.2.3.2.2.2. Using SSL with Load Balancing
10.2.3.2.2.3. Where Do I Get Certificates From?
10.2.3.2.2.4. Configuring ctxssl Access to Commands
10.2.3.2.2.5. Generating or Renewing a Certificate
10.2.3.2.2.5.1. To generate a CSR file
10.2.3.2.2.6. Sending a Certificate Signing Request file to a CA
10.2.3.2.3. Preparing for an Attack on Your Security
10.2.3.2.4. Planning the Renewal of Expired Certificates
10.2.3.3. Installing Digital Certificates
10.2.3.3.1. Protecting the Private Key
10.2.3.3.2. Installing a Server Certificate on a Server
10.2.3.3.2.1. To install a server certificate requested using ctxcertreq
10.2.3.3.2.2. To install a server certificate not requested using ctxcertreq
10.2.3.3.2.3. Example - the CA emails the server certificate as one file
10.2.3.3.2.4. Example - the CA emails the server certificate as two files
10.2.3.3.3. Installing a Root Certificate
10.2.3.4. Configuring SSL Relay
10.2.3.4.1. To enable or disable SSL Relay
10.2.3.4.2. Configuring SSL Relay Ready for Use
10.2.3.4.2.1. To configure SSL Relay ready for use
10.2.3.4.3. To start the SSL Relay
10.2.3.4.4. To stop the SSL Relay
10.2.3.4.5. Displaying a TCP Ports Configuration
10.2.3.4.5.1. To display summary information for all the ports

10.2.3.4.5.2. To display a particular ports configuration
10.2.3.4.6. Changing the SSL Relay Configuration
10.2.3.4.6.1. To add a new TCP port
10.2.3.4.6.2. To edit a ports configuration
10.2.3.4.6.3. To move a ports configuration
10.2.3.4.6.4. To copy a ports configuration
10.2.3.4.6.5. To remove a ports configuration
10.2.3.4.7. Managing Your Server Certificates
10.2.3.4.7.1. To display server certificate information
10.2.3.4.7.2. To export a certificate to another server
10.2.3.4.7.3. To remove a stored certificate
10.2.3.5. SSL Relay Command Reference
10.2.3.5.1. ctxcertmgr
10.2.3.5.2. ctxcertreq
10.2.3.5.3. ctxsslcfg
10.2.3.6. Glossary
Citrix XenApp
Updated: 2011-02-17
Citrix XenApp is an on-demand application delivery solution that enables any Windows application to
be virtualized, centralized, and managed in the datacenter and instantly delivered as a service to users
anywhere on any device. XenApp reduces the cost of application management by up to 50 percent, increases
IT responsiveness when delivering an application to distributed users, and improves application and data security.
Product documentation is available for the following XenApp releases:
XenApp 6 for Windows Server 2008 R2
XenApp 5 Feature Pack 3 for Windows Server 2008
XenApp 5 for Windows Server 2008
XenApp 5 Feature Pack for Windows Server 2003
XenApp 4.0, with Feature Pack 2, for UNIX
Quick Links
Licensing Your Product
Readme for XenApp for Windows Server 2008 R2
About XenApp 5 Feature Pack 3 for Windows Server 2008
Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6
Readme for Citrix Online Plug-in 12.0 for Windows
Fixed Issues
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.
Branch optimization powered by Citrix
Branch Repeater
SmartAccess powered by Citrix Access Gateway
EasyCall voice services
Service Monitoring (EdgeSight)
Load testing services
Single Sign-on
Power and Capacity Management
SmartAuditor
Provisioning Services
Workflow Studio orchestration
Cant find what youre looking for? If youre looking for documentation for previously released versions of
this product, go to the Citrix Knowledge Center. For a complete list of links to all product documentation in
the Knowledge Center, go to http://support.citrix.com/productdocs/.
1. XenApp 6 for Windows Server 2008 R2
Updated: 2011-02-17
Readme for XenApp for Windows Server 2008 R2
Designing a XenApp Deployment
System Requirements for XenApp 6 for

Windows Server 2008 R2
Enhancing the User Experience With HDX
Readme for Citrix Online Plug-in 12 for Windows
Doc Finder
Readme for Citrix Offline Plug-in 6 and

Streaming Profiler 6
Profile Management
Issues Fixed in the Offline Plug-in 6 for

Windows and Online Plug-in 12 for Windows
Web Interface

Branch Repeater
SmartAuditor
VM Hosted Apps
XenApp Connector for Configuration Manager 2007 R2
XenApp Printing Optimization Pack
XenApp 6 Migration Tool
Single Sign-on
Updated: 2010-03-26
Citrix products offer the security specialist a wide range of features for securing a XenApp system according
to officially recognized standards.
Security standards as they apply to Citrix XenApp 6.0 for Microsoft Windows Server 2008 R2 are discussed
here. These topics provide an overview of the standards that apply to XenApp deployments and describe
the issues involved in securing communications across a set of sample XenApp deployments. For
more information about the details of the individual security features, refer to the relevant product or
component documentation.
When deploying XenApp within large organizations, particularly in government environments, security
standards are an important consideration. For example, many government bodies in the United States
and elsewhere specify a preference or requirement for applications to be compliant with FIPS 140. These
topics address common issues related to such environments.
These topics are designed for security specialists, systems integrators, and consultants, particularly those
working with government organizations worldwide.
Updated: 2011-02-17
XenApp 5 Feature Pack 3 for Windows Server 2008 delivers key HDX user experience enhancements to XenApp
5 on Windows 2008. It also makes available enhancements to application streaming, profile management,
and other XenApp features.
XenApp 5 Feature Pack 3 for Windows Server 2008 Overview
HDX MediaStream for Flash
Doc Finder
HDX Plug-n-Play for USB storage devices
Profile Management
HDX IntelliCache for XenApp optimization over WAN
Web Interface
Online Plug-in for Windows 12.0.x
Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6

Branch Repeater
Single Sign-on
VM Hosted Apps

Updated: 2011-02-17
You can install and use XenApp 5 Feature Pack 2 features listed on this page with XenApp 5 for Windows
Server 2008. For XenApp topics other than those listed here, see the documentation for XenApp 5 for
Windows Server 2008.
Issues Fixed in Offline Plug-in 5.2 and Online Plug-in 11.2 for Windows
Readme for Citrix Offline Plug-in 5.2 and Streaming Profiler 5.2
Doc Finder
Profile Management
Web Interface
Platinum Features
Branch Repeater
Single Sign-on
VM Hosted Apps
5. XenApp 5 for Windows Server 2008

Updated: 2011-02-17
Release Notes for XenApp 5.0 Feature Pack
New Features, Capabilities, and Changes in the XenApp

5 Feature Pack
Readme for Citrix XenApp 5.0 for Windows

Server 2008
New Features and Changes in XenApp 5
Readme for Citrix Offline Plug-in 5.2 and

Streaming Profiler 5.2
Compare Features of XenApp Product Editions
Doc Finder
Issues Fixed in Offline Plug-in 5.2 and Online

Plug-in 11.2 for Windows
Profile Management
Installation Checklist for Citrix XenApp 5.0

for Windows Server 2008
Web Interface
Security Standards and Deployment Scenarios
Platinum Features
Branch Repeater
Single Sign-on

Updated: 2011-02-17
XenApp 5 Feature Pack 3 for Windows Server 2003 uses a hotfix to deliver server-side content fetching for
HDX MediaStream for Flash to XenApp 5 Feature Pack 2 on Windows Server 2003. Server-side content
fetching allows you to specify Web sites whose Flash content can be downloaded to the XenApp server and
sent to a user device. This hotfix requires the Citrix online plug-in 12.0.
To download this hotfix and find more information:
For 32-bit editions of XenApp, see Knowledge Center article CTX124145
For 64-bit editions of XenApp, see Knowledge Center article CTX124146
XenApp 5 Feature Pack 3 for Windows Server 2003 also makes available enhancements to application
streaming, profile management, and other XenApp features. To download these features, including the
Citrix online plug-in 12.0, go to My Citrix.
XenApp 5 Feature Pack 3 for Windows Server 2003 Overview
Online Plug-in for Windows 12.0.x
Profile Management
Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6 Web Interface
Doc Finder

Branch Repeater
Single Sign-on
SmartAuditor
Note: Before installing Single Sign-on, read known issues #222720 and #230824 in the Readme for
XenApp for Windows Server 2008 R2. These issues affect Single Sign-on in XenApp 5 in Feature Pack 3
for Windows Server 2003.
Updated: 2011-02-17
Readme for XenApp 5 Feature Pack 2 for
Windows Server 2003
XenApp Feature Overview

New Features in XenApp 5 Feature Pack 2
XenApp 5 Feature Pack 2 Product Editions and Features

HDX MediaStream for Flash
Readme for VM Hosted Apps
Doc Finder
System Requirements for XenApp 5 Feature Pack

2 for Windows Server 2003
Profile Management
Web Interface
Platinum Features
Branch Repeater
Secure application access powered by Citrix

Access Gateway
Single Sign-on
SmartAuditor
VM Hosted Apps
8. XenApp 5 Feature Pack for Windows Server 2003

Updated: 2011-02-17
Release Notes for XenApp 5.0 Feature Pack
New Features, Capabilities, and Changes in the XenApp

5 Feature Pack
Readme for XenApp 5 for Windows Server 2003
New Features and Changes in XenApp 5

Compare Features of XenApp Product Editions
Doc Finder

Profile Management
System Requirements for XenApp 5 for

Windows Server 2003
Web Interface
Platinum Features
Branch Repeater
Single Sign-on
8.1. Release Notes for XenApp 5.0 Feature Pack

Version: 1.0
Contents
Introduction
Installation Procedure
Introduction
This document describes the prerequisites and installation steps for the Citrix XenApp 5.0 Feature Pack.
The feature pack comprises download links for new and enhanced features, plus links to information
about complementary additions to XenApp.
Note: To obtain the features through the XenApp 5.0 Feature Pack pages on My Citrix, you must be a
current member of Citrix Subscription Advantage as of March 9, 2009.
For information about XenApp features, see Getting Started with Citrix XenApp in Citrix eDocs or CTX116418.
The XenApp 5.0 Feature Pack download pages on My Citrix contain links to additional information.
The Application streaming feature has been added to the XenApp Advanced Edition. To use this feature,
Advanced Edition customers must follow the procedures provided in the Citrix support article CTX120305.
Installation Procedure
This procedure applies to XenApp 5.0 for Windows Server 2008, XenApp 5.0 for Windows Server
2003, Presentation Server 4.5, and Presentation Server 4.5 with Feature Pack 1.
Note: If you are running XenApp 5 for Windows Server 2003, Presentation Server 4.5, or Presentation
Server 4.5 with Feature Pack 1, you must install Hotfix Rollup Pack 3 before downloading any of the
XenApp 5.0 Feature Pack software. See CTX115626 (32-bit) or CTX115627 (64-bit) for details.
Unless otherwise noted, the following instructions assume you are at your XenApp 5.0 Feature Pack
download page.
1. Access your XenApp 5.0 Feature Pack download page.

1. Log on to My Citrix.
2. From the Support menu, select Downloads.
3. In the Search Downloads by Product box, select Citrix XenApp.
4. In the Product Software section, select XenApp 5 Feature Pack.
5. Select the link for your XenApp edition.
2. If you do not yet have XenApp installed, links are provided to images. For the latest
installation documentation, see Citrix eDocs.
3. Download XenApp and Access Management Console hotfixes, using the links provided.
At the XenApp hotfix link destination, select the hotfix for your XenApp server.
At the Access Management Console link destination, select the hotfix for your XenApp server.
For Windows Server 2008 systems, the updates are packaged in a .zip file containing an
executable file that calls .msi files for each extension. For Windows Server 2003 systems,
the updates comprise a single executable file that calls the Presentation Server extension.
4. Install the latest license server, using the link provided. Citrix recommends upgrading to the latest
license server, which may include security updates, bug fixes, and new features. For the latest
licensing documentation, see Licensing Your Product in Citrix eDocs.
5. For XenApp Enterprise and Platinum Edition customers using the Application streaming feature: To
enable the use of the Application streaming offline feature, or to use application streaming with
Citrix Receiver, download the latest versions of the application streaming plug-in and profiler, using the
link provided.
For XenApp Advanced Edition customers: The Application streaming feature has been added to the
XenApp Advanced Edition. To use this feature, Advanced Edition customers must follow the
procedures provided in the Citrix support article CTX120305.
6. For XenApp Platinum Edition customers using the Single sign-on feature: To enable use of the Single
sign-on offline feature, download the latest version of the Password Manager plug-in, using the
link provided.
7. To download the software for the following features, click the links provided, in any order. If a feature
is not supported in your XenApp edition, the link will guide you to more information.
Note: If you already have these features installed, you must download the latest version.
Profile management
Provisioning services
Branch optimization
For information about the complementary capabilities available with Citrix XenServer, click the
link provided.
http://www.citrix.com
Copyright 2009 Citrix Systems, Inc.
8.2. Readme for XenApp 5 for Windows Server 2003
Readme Version: 1.02
Notes:
For the latest critical updates for XenApp, visit the critical updates page for the 32-bit edition or for the
64-bit edition to download and apply any available critical updates.
For updates concerning the XenApp Plugins for Hosted Apps (formerly named the Presentation
Server Clients) and Streamed Apps (formerly named the Streaming Client), go to Readme for
Citrix XenApp Plugin for Hosted Apps 11.0 for Windows and Citrix XenApp Plugin for Streamed Apps 1.2
for Windows.
To access licensing documentation in Citrix eDocs, go to Licensing Your Product at http://support.
citrix.com/proddocs/topic/licensing/lic-library-node-wrapper.html.
To access the Password Manager Readme and locate product documentation in Citrix eDocs, go to
http://support.citrix.com/proddocs/topic/passwordmanager/pm-library-wrapper.html.
Getting Support
Citrix provides an online user forum for technical support. This forum can be accessed at http://support.
citrix.com/xenappforum. The Web site includes links to downloads, the Citrix Knowledge Center, Citrix
Consulting Services, and other useful support pages.
Citrix provides technical support primarily through Citrix Solutions Advisor. Contact your supplier for firstline support or use Citrix Online Technical Support to find the nearest Citrix Solutions Advisor.
Citrix offers online technical support services on the Citrix Support Web site. The Support page includes links
to downloads, the Citrix Knowledge Center, Citrix Consulting Services, and other useful support pages.
Installation Issues
Before you install this product, consult System Requirements for XenApp 5.0 for Windows Server 2003.
Secure Gateway
Citrix does not support installing Secure Gateway 3.1 on the same computer as Citrix XenApp
(Advanced, Enterprise, and Platinum Editions). Install the Secure Gateway on an independent computer in
the DMZ. If you are using Citrix Access Essentials 3.0, installing these components on the same computer
is supported. For a workaround, see "XTE service will not start after installing Secure Gateway" at http:
//support.citrix.com/article/CTX118021. [#175968]
SmartAuditor
Upgrading SmartAuditor 1.1 to version 1.2 is not supported.
To use the latest version of SmartAuditor, remove all instances of the previous installation and perform a
fresh installation of version 1.2. [#195803]
XenApp
Upgrading any XenApp 5.0 component or Citrix License Server from an early release, including the
Beta and Release Preview, is not supported. Uninstall all components from early releases before
installing XenApp 5.0. [#192993]
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, go to http://support.microsoft.com/kb/931534. [#192147]
To install XenApp components on a Windows 2000 Server, before you begin the installation, download
the gdiplus.dll file from the Microsoft Web site at http://www.microsoft.com/downloads/details.
aspx?familyid=6A63AB9C-DF12-4D41-933C-BE590FEAA05A&displaylang=en. Run gdiplus_dnld.exe on
the local server and copy gdiplus.dll in the winnt\system32 folder. Then start Autorun.[#190821, #196361]
The Suite Monitoring and Alerting (SMA) service used by the Access Management Console might not
start when the computer running XenApp 5 for Windows Server 2003 is restarted. This situation
has occurred when XenApp components, such as Citrix Password Manager and Hotfix Rollup Pack 2,
have been installed on the computer running XenApp 5 for Windows Server 2003. No fix or workaround
is available at this time. [#194890]
Other Known Issues

XenApp issues
Roaming between 32-bit and 64-bit versions of Microsoft Windows Server 2003 might cause errors
relating to tasks associated with the ICA Toolbar or icon display corruption. [#166167]
Report specifications created or updated using the Access Management Console of Citrix XenApp 5.0
cannot be used in the Access Management Console of Presentation Server 4.5. [#166167]
Secure Gateway issues
The Citrix Secure Gateway service fails to start if the installed certificate's Distinguished Name (DN) of
the server computer contains a non-English (EN) or extended character. The Windows event log
might contain a message indicating that the Common Name (CN) does not match the DN or server name
of the virtual host. Ensure that you are not using the extended character set in the server
name. [#191888, #192314]
The Advanced options of the Secure Gateway Configuration wizard enables you to exclude computers
such as load balancers from creating event log entries (known as logging exclusion). At this time, the
IP address field in the Logging Exclusions dialog box accepts IPv4 addresses only. To prevent
those computers with IPV6 addresses from creating log entries:
1. Stop the Secure Gateway service (from the Services control panel or the Secure
Gateway Management Console).
2. Open the C:\Program Files\Citrix\XTE\conf\httpd.conf file with a text editor and add the
following entry for each computer to exclude:
SetEnvIf Remote_Addr ^IPV6-address$ nolog=IPV6-address

where IPV6-address is the IPv6 address of the computer to exclude.
3. Save and exit the file.
4. Restart the Secure Gateway service (from the Services control panel or the Secure
Gateway Management Console).
[#193725]
Applications streaming issues
Profiling Microsoft Input Method Editor (IME), which is included with Microsoft Office, is not supported.
You can create a profile for Microsoft Office that includes the IME without errors, but the IME is
disabled and cannot be launched. To prevent users from attempting to launch the IME, exclude it
when profiling Microsoft Office. [#180338]
When publishing an application to be streamed to desktops and made available with offline access (that
is, published with the Streamed to client and Enable offline access options enabled), choose the
Operating System User Selector option. For this release, the Citrix User Selector option fails to add
user names correctly; users added with that option do not see the application in their offline
applications list. [#197023]
When streaming OneNote 2007, the audio recording feature fails. If started, an incorrect error
message states that the recycle bin is corrupted and the feature stops. Users can disregard this
message. The recycle bin is neither corrupted nor related to the OneNote feature. [#172666]
When streaming any Office application to a Microsoft Vista platform, users cannot delete files using
the Open File dialog box. Attempting to do causes an error message stating that the recycle bin
is corrupted. If this occurs, users can disregard this message. The recycle bin is neither corrupted
nor related to the Office application.
Third party issues
Terminal servers running Windows Server 2003 or Windows Server 2008 might stop accepting new
connections, and existing connections become unresponsive. Microsoft has released a hotfix, available at
http://support.microsoft.com/kb/956438 to address this issue. [#184398]
Citrix Systems, Inc.
851 West Cypress Creek Road
Fort Lauderdale, Florida 33309 USA
954-267-3000
http://www.citrix.com
Copyright 2009 Citrix Systems, Inc.

8.3. Getting Started with Citrix XenApp
This section describes XenApp features and product naming.
For known issues in this release, see the Readme for Citrix XenApp 5.0 for Windows Server 2008.
For information about XenApp 5.0 for Windows Server 2003, see the Citrix XenApp 5.0 for Microsoft
Windows Server 2003 Upgrade Guide.
8.3.1. Before You Begin
This documentation provides information about Citrix XenApp 5 and includes information about the XenApp
5 Feature Pack.
This documentation focuses primarily on XenApp 5 for Windows Server 2008. For more information on XenApp
5 for Windows Server 2003, see CTX113699 and CTX116622.
8.3.1.1. New Product and Feature Names
Citrix has changed the name of its product line and several features.
Note: You might see previous product and feature names in documentation, user interfaces, Web pages,
and support materials.
This name
is the new name for
Citrix XenApp
Citrix Presentation Server
XenApp Advanced Configuration
Presentation Server Console
Citrix XenApp Plug-in for Hosted Apps, which contains

the following plug-ins:
Citrix XenApp (formerly Program
Neighborhood Agent)
Citrix Presentation Server Client
Citrix XenApp Web Plug-in (formerly the Web Client)

Program Neighborhood
XenApp Plug-in for Streamed Apps
Citrix Streaming Client
Citrix XenApp Provider
WMI Provider
Citrix XenApp Management Pack
System Center Operations Manager and

MOM Management Packs
Branch optimization
WAN optimization
Secure application access
SmartAccess
EasyCall
EdgeSight for Load Testing
Provisioning Server for Datacenters
Single sign-on
Single Sign-on powered by Password Manager
Profile management
Portable Profile Manager
Workflow Studio
8.3.1.2. Media Kit Contents

The media kit for XenApp for Microsoft Windows Server 2008 contains the following items:
Tab 1: Citrix XenApp 5.0 for Microsoft Windows Server 2008. This DVD includes XenApp and all
the component technologies for Advanced, Enterprise, and Platinum Editions, 32-bit and 64-bit.
Tab 2: Citrix XenApp 5.0 for Microsoft Windows Server 2003 on six CDs:
Platinum Edition
Platinum Edition 64-bit
Advanced and Enterprise Editions
Advanced and Enterprise Editions 64-bit
Components
Citrix Password Manager 4.6 with Service Pack 1
Tab 3: Citrix XenApp for Unix 4.0 with Feature Pack 1 (CD)
Tab 4: Resources
Document describing where to find information and downloads for the XenApp 5 Feature Pack
This release of Citrix XenApp 5.0 for Microsoft Windows Server 2008 includes the following component
and feature versions:
License Server 11.5
Web Interface 5.0.1
XenApp Plugin for Hosted Apps 11.0
Streaming Profiler 1.2 and XenApp Plugin for Streamed Apps 1.2
The Secure Gateway 3.1
XenApp Provider 5.0 and XenApp Management Pack 5.0
SmartAuditor 1.2
EasyCall 1.2
EdgeSight 5.0 (English only)
Access Gateway Standard Edition 4.5.8, Advanced Edition 4.5, and Enterprise Edition 8.1
Password Manager 4.6 with Service Pack 1
WAN Optimization for WANScaler 4.3
For information about getting the XenApp 5 Feature Pack, see the Release Notes for XenApp 5.0 Feature Pack.
8.3.2. Introducing Citrix XenApp 5
Citrix XenApp is a Windows application delivery system that manages applications in the datacenter and
delivers them as an on-demand service to users anywhere using any device. XenApp reduces the cost
of application management by up to 50 percent, increases IT responsiveness when delivering an application
to distributed users and improves application and data security.
The XenApp documentation includes information about planning your deployment, including farm
concepts, configuration considerations, and access options.
8.3.2.1. XenApp Product Editions
XenApp 5 is released in three editions: Advanced, Enterprise, and Platinum. The following chart identifies
key features included, supported, or licensed in each edition. An asterisk (*) indicates that an appliance must
be purchased separately
In the edition columns, numeric notations refer to expanded functionality or support in the XenApp 5 Feature Pack.
1 - Feature is new to this edition
2 - Feature has enhanced functionality
3 - New feature or complementary capability
For more information about the XenApp 5 Feature Pack, see New Features, Capabilities, and Changes in
the XenApp 5 Feature Pack.
Feature
Advanced
Enterprise
Platinum
Hosted application delivery and
Yes
Yes
Yes
presentation virtualization
Application streaming
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
XenServer virtualization platform
Yes
Yes
Yes
Enterprise Management (Includes Resource

Manager, Installation Manager,
CPU/Memory Optimization, Health Assistant,
XenApp Provider and Management Pack)
Yes
Yes
Yes
Yes
Profile management
Yes
Yes
Yes
SmartAuditor
Yes
Branch optimization *
Yes
Application performance monitoring
Yes
Secure application access *
Yes
Single sign-on
Yes
8.3.2.2. New Features and Changes in XenApp 5

XenApp 5 is designed to bring world-class application delivery to Windows Server 2003 and Windows Server
2008 and optimize and enhance the Microsoft platform. To learn more about XenApp 5 for Windows Server
2003, see CTX113699 and CTX116622.
Below are the new features and benefits added in XenApp 5.
Performance Improvements
XenApp 5 includes these significant overall performance improvements:
Farm scalability: Reductions in Independent Management Architecture (IMA) service start time,
discovery time, application resolution and enumeration time, and server enumeration time.
Data store sizing: Reductions in installation time and XenApp Advanced Configuration start time.
Single server scalability: With over 50 users launching applications simultaneously, application launch
time decreases by over 50 percent.
Application streaming: Significant improvements in application launch time on both servers and laptops
Single sign-on: Significant reductions of plug-in logon time for Active Directory and file server
central stores and of plug-in response time for Windows, Web, and Java applications.
Enhanced Security
XenApp 5 provides the following security enhancements:
Support for Windows Server 2008 security enhancements, including Microsoft User Account Control (UAC).
Citrix XenApp Plugin for Hosted Apps now supports IPv6 via the Secure Gateway feature of XenApp.
It provides the ability to connect to published applications from a pure IPv6-only based network using
the XenApp Plugin. It also improves connectivity and mobility by supporting a higher number of
client devices and their unique static IPv6 addresses.
Enhanced security (or hardening) of XenApp services. For example, new functionality adds
extended command-line parameter validation for applications launched by file type association.
Support for Microsoft Data Execution Prevention (DEP) hardware and software technology.
User Access and Experience

XenApp 5 provides the following enhancements to improve the experience of end users.
The XenApp Plugin for Hosted Apps and the Web Interface offer new features such as Special
Folder Redirection and ClearType font smoothing.
XenApp supports the Windows Vista Security Guide, including its Enterprise Client (EC) and
Specialized Security-Limited Functionality (SSLF) templates.
The Web Interface now supports any device that authenticates using the RADIUS authentication
protocol, including RADIUS servers.
The Web Interface application presentation has been redesigned to provide more functionality and
an enhanced user experience. For details, see the Web Interface Administrator's Guide.
XPS Printing support. XenApp uses this printing specification in addition to the current Enhanced
Metafile Format (EMF) protocol.
Support for Philips SpeechMike USB devices. When setting up for digital dictation devices, you can
enable support for Philips SpeechMike USB devices.
Optimized Support for Media Software

XenApp 5 optimizes the latest releases of the following software:
SpeedScreen Flash Acceleration now supports Adobe Flash Player, Versions 8 to 10
Multimedia Acceleration now supports Windows Media Player 9, Windows Media Player 10, Real Player,
and any DirectShow Based Media Players
SpeedScreen Browser Acceleration now supports Internet Explorer 6 and 7, Outlook 2003, and
Windows Mail
Enhanced Documentation
XenApp 5 provides improved documentation:
A handy reference page, the Welcome to Citrix XenApp at CTX113391 (or Read_Me_First.html on
the installation media ), with links to PDF guides on the Web. This page is available from the Start
menu. Alternatively, go to the Quick Links for product documentation at CTX116089.
All documentation is now installed on your system by default in a searchable centralized help
system, known as the XenApp Document Library. From the Access Management Console, use the Help
menu to open the library. (Citrix eDocs may contain more current information.)
Changes to Installation
For details about changes to Setup, see the XenApp installation documentation..
The XenApp Media Kit, which contains the installation media, is now on a DVD.
The XenApp Plugin for Hosted Apps is now an explicit option in the XenApp Setup (mps.msi); it is no
longer silently installed by XenApp Setup. If you are performing installation using any method other
than Autorun, you must install the plugin before Setup; Setup fails without the plugin and you might
not get a warning prompt if you are performing a silent install.
Java Runtime Environment (JRE) is no longer installed by default or included in the Support folder of
the XenApp installation media. See the Citrix XenApp Installation Checklist for details.
For unattended installations, the sequence of installation options has changed and some Setup
programs are no longer part of mps.msi.
The Access Management Console uninstaller now lets you uninstall all Access Management
Console components in a single removal task.
Changes for Resource Publishing and Delivery

For more detailed information, refer to the XenApp administration documentation.
The Microsoft Windows 2000 operating system is no longer supported for virtualizing or
streaming applications and resources.
Isolation environments are no longer configured in the Publish Applications wizard. The
application streaming feature is the recommended solution for delivering applications that must be
isolated. In particular, applications that are not compliant with Terminal Services and applications
that cannot socialize with others should be streamed so that application isolation can be used.
The application streaming feature allows you to profile these applications individually and then
publish them so they run in isolation environments on user desktops or from a server. for more
information about application streaming enhancements, see the application streaming documentation.
Specifying CPU priorities exclusively for applications is no longer supported when publishing
applications. This option has been replaced by an application importance level setting, which is used
with the session importance policy setting to determine the Resource Allotment for Preferential
Load Balancing.
Changes to Features and General Changes

Before you install XenApp, note the following changes, which may change your farm deployment or the
operating systems of the servers on which you publish applications.
The English version of XenApp is now supported on Russian language operating systems. The
installation for the XenApp Plugin for Hosted Apps and the user interface for the plugin and Web
Interface include Russian language support.
Network Manager is no longer available to manage vendor-specific snap-ins for SNMP network
monitoring; the snap-ins for third-party products and instructions for their use are now provided by
the product vendors. You can continue to enable the SNMP agent on supported platforms and use
the Access Management Console to enable or disable traps to be reported.
Installation Manager has been rewritten based on Windows Server 2008 Task Scheduler.
Conferencing Manager is no longer included as part of Citrix XenApp. Citrix recommends using
Citrix GoToMeeting instead.
Citrix has replaced its former Resource Manager monitoring and reporting tools with Resource
Manager powered by EdgeSight (Enterprise Edition) and EdgeSight for XenApp (Platinum Edition).
If you are familiar with Presentation Server 4.5 monitoring and reporting functionality, see
Finding EdgeSight Documentation. This guide directs users to documentation for their
EdgeSight equivalent, where one exists.
For monitoring in a mixed farm environment, use Resource Manager in XenApp
Advanced Configuration as well as the Dashboard and Report Center features in the
Access Management Console to monitor computers running Presentation Server 4.5.
HP ProtectTools is not currently supported on XenApp 5 for Windows Server 2008.
Downgrading a server in your farm from XenApp 5 to Presentation Server 4.5 is not supported.
8.3.2.3. New Features, Capabilities, and Changes in the XenApp 5 Feature Pack
The Citrix XenApp 5 Feature Pack extends the value of using XenApp 5 by enhancing current features, adding
new features and capabilities, and expanding feature support to other XenApp editions.
The XenApp 5 Feature Pack is supported on the following XenApp versions:
XenApp 5 for Microsoft Windows Server 2008
XenApp 5 for Microsoft Windows Server 2003, with Hotfix Rollup Pack 3 installed
Citrix Presentation Server 4.5, with Hotfix Rollup Pack 3 installed
Citrix Presentation Server 4.5 with Feature Pack 1, with Hotfix Rollup Pack 3 installed
The following table lists the new and enhanced features and complementary capabilities in the XenApp 5
Feature Pack.
Advanced
Enterprise
Platinum
Application streaming
new to edition
offline support added

Workflow
Studio orchestration
new feature
new feature
new feature
XenServer
virtualization platform
new
complementary capability
new
new
new to edition
new to edition
(previously supported)
Profile management
new feature
new feature
new feature
new feature
new feature
Single sign-on
See XenApp Feature Overview for descriptions. For installation information, see the Release Notes for XenApp
5.0 Fature Pack.
8.3.3. XenApp Feature Overview
Citrix XenApp features enable users to access applications easily and increase productivity. This section
provides summary descriptions of several XenApp features.
Citrix has changed the names of several features. For details, see New Product and Feature Names.
Important Information About Editions and Subscription Advantage
Certain features are supported in all XenApp 5 editions; others are supported in only specific editions. See
XenApp Product Editions for edition support information.
For a more comprehensive chart of the features in all editions and how XenApp 5 compares to past editions,
see the Citrix XenApp Comparative Features Matrix at http://www.citrix.com/xenapp/comparativematrix.
Only customers with a current Citrix Subscription Advantage membership are allowed to implement
certain features. This includes many of the features in the XenApp 5 Feature Pack.
8.3.3.1. Hosted Application Delivery and Features
Hosted application delivery is the process of delivering applications to users by first hosting them on
centralized servers in the data center, and then remotely displaying or presenting them to user
devices. Presentation virtualization occurs when the user connects to the hosting server and the application
is remotely displayed on their device in a seamless fashion.
The following sections briefly describe the XenApp features that help facilitate hosted application delivery. See
the XenApp administration documentation for more information about each feature, unless otherwise noted.
Load Management
Use Load Manager to set up, monitor, and balance the server and published application loads in a server farm
so that users can run the published applications they need quickly and efficiently.
The criteria you define in Load Manager determine which servers are least busy and can best run an
application. When users launch published resources, Load Manager selects the server that runs the application
or desktop session, based on server load. Load Manager ensures that each new session request is forwarded to
a server that is not overloaded, thus improving the user experience. For more information, see the Load
Manager documentation.
Preferential Load Balancing
Preferential Load Balancing provides preferential treatment for users and applications. This feature enables you
to prioritize a user group and applications based on pre-established priorities. Use Preferential Load Balancing
to assign higher or lower levels of XenApp service to specific users, groups, and applications.
Users and applications with higher priorities and levels of service connect to their XenApp sessions more
quickly, experience more interactive ICA sessions, and have more computing resources available to them.
CPU Utilization Management
CPU utilization management improves the ability of a farm or server to manage resources and normalize
CPU peaks when performance becomes limited by CPU-intensive operations (Enterprise and Platinum
Editions only). Depending on your XenApp edition, you can enable Fair Sharing or Preferential Load Balancing.
Resource Management
For the XenApp Enterprise Edition, a new Resource Manager improves monitoring and reporting capabilities
with session-level performance counters, multivariable alert capabilities, a vast library of pre-configured
and customizable reports, and integration with Health Assistant.
To locate the EdgeSight documentation needed to transition to this release of Resource Manager, see
Finding EdgeSight Documentation.
Health Assistant
The Health Monitoring and Recovery service monitors the health of many XenApp features and reports
failures. You can configure this utility to stop accepting new connections or take the server offline if it detects
a problem, thereby optimizing the end-user experience.
SNMP Monitoring
XenApp supports Simple Network Management Protocol (SNMP) monitoring and integration with third-party
SNMP network management products. Via this support, third-party applications can monitor server
status, terminate processes on servers, disconnect, logoff, or send messages to users, and query server activity.
The XenApp administrator enables SNMP monitoring on the XenApp servers, and indicates the traps to
be monitored.
XenApp Provider and XenApp Management Pack
Working together, the XenApp Provider for Microsoft Windows Management Instrumentation (XenApp
Provider) and the XenApp Management Pack for Microsoft Operations Manager and System Center
Operations Manager (XenApp Management Pack) enable you to monitor the health and availability of farms.
This feature enables integration with Microsoft monitoring tools to anticipate and react quickly to any problems.
For more information, see the Management Pack and Managing Providers documentation..
8.3.3.2. Application Streaming
Updated: 2009-09-14
Application streaming centralizes the management of desktop applications and isolates and streams them to
users without application and system conflicts. When you publish applications for streaming to user
desktops, users access the application from the file share or Web server and stream it to their user
devices. Streamed applications are cached on the local user device and run within an isolation environment,
which prevents conflicts with locally installed applications. You must prepare applications for streaming using
the Streaming Profiler. Users install the Citrix offline plug-in locally to stream application to their user devices.
Application streaming provides the following benefits:
Applications run on the local Windows user device. Streamed applications can use system
resources on the user device, not the XenApp server.
Update applications centrally. Deliver upgrades or patches efficiently and seamlessly to user devices
the next time they access the application.
Isolation environments. Run applications within protected isolation environments on user devices,
which prevents conflicts with other applications installed locally.
Application caching. Configure the option for caching files on the user device to allow faster access
the next time the application is launched.
Dual-mode streaming. Configure a fall-back method for application delivery in case user devices do
not support streaming.
Offline access. Allow users to continue running streamed applications after disconnecting from
the network.
Inter-isolation communication. Link individual profiles so that applications in separate profiles
can communicate with each other when launched on the user device.
Support for Citrix Receiver. Deploy and update the offline plug-in using Citrix Receiver.
Sandbox reuse. Improves application launch time for applications from a single profile by launching
them in the same sandbox. Sandboxes are left alive for five minutes (configurable in the registry) after
the last application terminates.
Isolation environment variables are now visible from pre-launch/post-exit scripts run
outside of isolation. This feature enables you to purge the per-user isolation space before and
after application use without using the RadeRunSwitches command.
Software for the most recent Citrix plug-ins is always available for download at http://www.
citrix.com/xenapp/clients.
Local desktop (offline) use of the application streaming feature is available to all XenApp users who access
hosted applications. This allows XenApp users to stream applications to the desktop without requiring a
separate license.
Important: Your use of application streaming to user devices included with XenApp is limited to support
users of XenApp hosted applications, and not other users.
8.3.3.3. Citrix Receiver and Merchandising Server
Updated: 2009-09-04
Citrix Receiver for Windows (Receiver) and Citrix Merchandising Server are components of the Citrix
Delivery Center solution that together enable you to deliver plug-ins to your users. While Citrix Delivery
Center provides the application delivery infrastructure to the IT administrator, the Merchandising Server and
the Receiver work together to streamline the installation and management of plug-ins on users' desktops.
The Receiver and the Merchandising Server provide two very important features. First, the Merchandising
Server allows you to configure, deliver, and upgrade plug-ins for your users. Second, the Receiver manages
plug-in operations and configurations for your users.
The system consists of the Receiver application that is installed on your users' computers, the
Merchandising Server that is installed on a virtual machine in your data center, and the Citrix Update Service
that is hosted on Citrix.com. The Merchandising Server Administrator Console is the interface on
the Merchandising Server that you use to configure plug-ins and schedule their delivery to your users.
The Merchandising Server delivers the plug-ins and their installation instructions to your users on the
scheduled date.
Citrix Receiver simplifies application access and management for end users and administrators by providing
the following features:
Seamless installation. Your users install Receiver for Windows on their computers. If a download
is interrupted, the Receiver silently resumes the action when the connection is restored. When
installation is complete, the Receiver immediately installs the scheduled plug-ins without requiring the
user to enter any information. The Receiver can even be installed from outside of the company firewall.
The Receiver upgrades itself automatically.
Manage connections to Delivery Services. The Receiver uses Citrix secure access plug-in to
supply secure connectivity enabling users access to work applications from any where.
Simplified administration. The Merchandising Server enables you to deliver plug-ins to all your users
at once. The Merchandising Server retrieves plug-in updates from the Citrix Update Service and
presents the update list to you through the Administrator Console.
Simplified installation and upgrade. The Merchandising Server virtual appliance is delivered ready
to import through your Citrix XenServer. Upgrades to the Merchandising Server are imported
directly through the Administrator Console.
8.3.3.4. XenServer Virtualization Platform
The Citrix XenServer virtualization platform provides open, powerful server virtualization that reduces
datacenter costs by transforming static and complex datacenter environments into more dynamic, easy
to manage server workload delivery centers. Based on the open source Xen hypervisor, XenServer delivers
a secure and mature server virtualization platform with near bare-metal performance.
For more information, see the XenServer documentation.
8.3.3.5. Load Testing Services
The Load testing services feature provides an efficient and cost effective method of server sizing and
application load testing for XenApp environments. By simulating hundreds of virtual Citrix users and
monitoring the responsiveness of the system under test, it allows the administrator to determine how the
current configuration and hardware infrastructure will support anticipated demand.
This load generating software solution enables XenApp administrators to:
Predict how systems will cope with high levels of user load
Deliver tried and tested application virtualization environments by simulating thousands of users to
identify system bottlenecks or application instability before systems go live
Reduce costs associated with change management and application regression testing; reusable
scripts simplify before and after comparison following application patches or operating system updates
Assess new hardware; understand the capacity limits of different hardware types to make
informed purchasing decisions
Perform branch office application performance testing; create real traffic from remote sites,
ensuring bandwidth and server resources are available to deliver the best user experience
8.3.3.6. Provisioning Services

The Provisioning services feature reduces total cost of ownership and improves both manageability and
business agility by virtualizing the workload of a datacenter server operating system, applications,
and configuration - and streaming server workloads on demand to physical or virtual servers in the network.
By delivering server workloads on demand rather than deploying them on individual servers, the
Provisioning services feature:
Simplifies and streamlines server management, and reduces software rollout risk
Delivers the operating system, applications, and server configuration information in a real time
stream, maximizing performance and minimizing network load
Assures server consistency by provisioning servers simultaneously from a single standard image
Increases IT responsiveness and agility by enabling capacity on demand; repurpose any server to do
any job
Reduces utility costs and space needs by lowering the number of backup servers needed to
support disaster recovery and business continuity
Risk-free server workload rollout - rollback to a previous working image in the time it takes to reboot
Built-in support for redundant servers, networks, and databases
Important: Your use of the Provisioning services feature included with the Platinum Edition of XenApp
is limited to provisioning only XenApp Platinum Edition workloads.
8.3.3.7. Profile Management
Updated: 2009-09-08
The Profile management feature provides an easy, reliable way for managing user personalization settings.
Profile management saves these settings during logoff to the user store for each user. If the file already
exists (the most common case), the changes from the current session are merged with the existing settings.
At logon, if a locally cached profile exists, the two sets are synchronized.
Local desktop use of the Profile management feature is available in XenApp Enterprise and Platinum Editions
for all users who access hosted applications.
8.3.3.8. Service Monitoring
Updated: 2009-08-21
Service monitoring is an end-to-end performance and resource management solution for users and
servers running XenApp. It monitors user sessions and server performance in real time, allowing you to
analyze, resolve, and proactively prevent problems quickly.
The application performance monitoring feature includes:
Service level monitoring, with the ability to synthesize user tasks and monitor their execution
time, providing feedback on application performance and availability as experienced by end-users.
Farm-wide monitoring, including a tree view of the entire farm structure, visual detection of errors,
and visual flags for devices with alerts.
Server availability and session reliability monitoring.
Health check alert displays.
Suite Monitoring and Alerting (SMA) that provides log entries and alerts.
8.3.3.9. SmartAuditor
Updated: 2009-09-03
SmartAuditor uses flexible policies to trigger recordings of XenApp sessions automatically. This enables IT
to monitor and examine user interaction with 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.
8.3.3.10. Secure Application Access
The Secure application access feature empowers users with easy anywhere access and provides
administrators market-leading application-level control. With a single point of control and marketleading application-level control, it provides administrators with better risk, security, and
compliance management, while boosting user productivity by optimizing access for each user, network,
and device.
8.3.3.11. Branch Optimization
XenApp accelerates and optimizes application delivery to any remote or mobile user, whether the task is
receiving a streaming application, running remotely using XenApp, or doing other tasks over the network.
These advanced acceleration features give your remote users in-office performance wherever they are.
This feature requires the purchase of one or more Citrix WANScaler appliances.
8.3.3.12. Single Sign-on
The Single sign-on feature is an enterprise-class solution that provides secure and managed access to
Windows, Web, and terminal emulator applications running in the Citrix environment as well as local
applications on the desktop of XenApp Platinum Edition.
Users authenticate once and the Single sign-on feature does the rest, automatically logging on to
password-protected information systems, enforcing password policies, monitoring all password-related
events, and even automating user tasks, including password changes.
Local desktop (offline) use of the Single sign-on feature is available to all XenApp Platinum Edition users
who access hosted applications. Locally installed instances of the Password Manager plug-in in a XenApp
Platinum Edition environment do not require a separate license.
Important: Your use of the Single sign-on feature on end-user devices (or clients or machines) included
with the Platinum Edition of XenApp is limited to support users of XenApp Platinum hosted applications, and
not other users.
8.3.3.13. EasyCall Voice Services
Updated: 2009-09-02
EasyCall voice services embeds communications directly into applications that are delivered using XenApp
or deployed on the desktop. The EasyCall voice services Agent enables a computer user to hover over any
phone number in published, streamed, or installed Windows applications and have that number
automatically dialed for them. The user simply hovers the mouse over the number and clicks a button to start
the call or even initiate a conference from any telephone (desk, mobile, and home).
Important: Your use of the EasyCall voice services feature on end-user devices (or clients or
machines) included with XenApp is limited to support users of XenApp hosted applications, and not other users.
8.3.3.14. Workflow Studio Orchestration
Citrix Workflow Studio orchestration is an infrastructure process automation platform that enables you
to transform your data center into a dynamic delivery center. It natively supports Citrix products
including XenApp, XenDesktop, XenServer and NetScaler. Built on top of Windows PowerShell and
Windows Workflow Foundation, Workflow Studio orchestration provides an easy-to-use, graphical interface
for workflow composition that virtually eliminates scripting. Workflow Studio orchestration acts as the glue
across the IT infrastructure, allowing administrators to easily tie technology components together via workflows.
Customers may want to review the available activity libraries and workflows as they are released to
determine when this feature will meet their needs.
8.3.4. Getting Up and Running with XenApp 5
This section provides high-level guidance for installing XenApp 5 for Windows Server 2008. This information is
not comprehensive; for complete information, see the XenApp installation documentation.
8.3.4.1. Using XenApp to Manage Applications
Preparing and Publishing Applications
With XenApp, you can deliver:
Streamed applications installed in application profiles and stored on a file server. Users access the
profile and virtualize the applications on their user devices.
Applications installed on servers running XenApp. When users access them, the published
applications appear to be running locally on 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 that Publish the entire Windows desktop of a server in the farm.
To use the application streaming feature, you package applications into profiles. A profile contains one or
more targets (a collection of disk files, registry data, and other information that represents an
application isolation environment), plus the metadata needed to stream the profiled applications. Each
target specifies a combination of operating system, service pack level, system drive letter, and language. A
profile can contain one or more applications; for example, a single profile can contain Microsoft Word or the
entire Microsoft Office suite.
When you publish an application, configuration information for the application is stored in the data store for
the server farm. Configuration information includes the types of files associated with the application, users
who can connect to the application, and the importance level for load balancing.
See the XenApp administration section of eDocs for complete information about managing delivery options
for published resources, managing application properties, using virtual IP addresses, and using the
Publish Application wizard.
Accessing Applications
Citrix offers a variety of options for accessing applications. Additionally, you can customize the
user environments, as well as manage and optimize sessions.
Citrix Receiver for Windows. Citrix Receiver provides a simple way to download, install, and
update Citrix plug-ins.
Web Interface. The Web Interface can be used to create stand-alone Web sites for access to
published resources that you integrate into your corporate portal. The Web Interface queries the
server farms and dynamically creates an HTML page that can be viewed with a Web browser. After
logging on, users are presented with a customized Web page containing a list of the published
resources that you make available to them.
Citrix plug-ins. Citrix offers plug-ins for a wide range of user devices and platforms for access to
hosted applications. Application streaming also has its own plug-in. You can use Citrix Receiver to
manage several of these plug-ins; you can also manage plug-ins individually.
You can customize the user environment through client-side session management properties such as window
size, number of colors, encryption level, and audio setting. To further refine how users launch and
access published resources, you can use content redirection and XenApp policies.
Application Enhancements
XenApp offers a variety of features that complement and enhance application delivery. For details, see
XenApp Feature Overview.
8.3.4.2. Preparing to Create the Farm
Before you install XenApp, prepare the servers and install the preliminary components so that the
XenApp installation wizard can reference them. See the XenApp installation documentation for details.
1. Citrix recommends installing Citrix XenApp on a fresh installation of Windows Server 2008.
In particular, uninstall any XenApp components and Citrix License Server from early releases, including
the Beta and Release Preview.
2. Configure Windows Server 2008 for XenApp 5.
3. Install the system prerequisites on all XenApp servers. See the Installation Checklist for details.
4. Install Certificate Services. Obtain the necessary certificates. Certificate Services issues and
manages SSL certificates within the domain to which the servers belong. A certificate is required for
use with the XenApp Single sign-on feature. As a best practice, isolate evaluation systems from
your production network environment. For example, install an isolated Certificate Authority on the
domain controller.
5. Install Citrix Licensing.
6. Install and configure the Web Interface. Install and configure this feature on one server in the
farm. For details, see the Web Interface documentation.
7. Install and deploy the XenApp Plug-ins for Hosted Apps and Streamed Apps.Whether as part
of Setup or separately, you must install, at a minimum, the client engine, which is included in
the Clients\ica32\XenAppWeb.exe, which provides the function for pass-through client authentication.
To stream applications from any server, even if you are not streaming applications on this server, you
must install the XenApp Plug-in for Streamed Apps.
8.3.4.3. Licensing This Release
Updated: 2009-09-15
Important: The latest licensing documentation is available in the Technologies > Licensing Your Product
section of eDocs.
To run this release, update the license server to the most recent version. You can find version 11.6.1 on
the XenApp 5.0 Feature Pack 2 installation media; otherwise, you can download the most recent version from
the Citrix download site.
The most recent license server is always available for download at http://www.
citrix.com/english/ss/downloads/results.asp?productID=1679389.
8.3.4.4. Installing XenApp 5
For details about planning and installing XenApp 5, see the XenApp installation documentation.
A typical installation comprises the following tasks:
1. On the initial Autorun page, choose the XenApp Edition.
2. Choose the installation category Application Virtualization.
3. From this category, the following pages appear:

The License Agreement page.
The Prerequisites Installation page. See the Citrix XenApp Installation Checklist for details.
The Component Selection page. A sequence of separate Setup wizards guides you through
the installation of selected XenApp features. Note that Citrix Licensing is disabled by default.
Depending on the components selected, some configuration options may not be available or may appear
in different order:
Citrix Licensing (if enabled on the Component Selection page)
Pass-through authentication
Access Management Console
Web Interface (reference the preconfigured site or accept the default)
XenApp Plugins
XenApp farm
Documentation
Citrix strongly recommends that you review the Setup instructions for these components in their
respective documentation before attempting their installation.
After installing XenApp and deploying your farm, continue by installing the additional features required for
your organization.
8.3.4.5. Installing Additional Features
The XenApp editions license some or all of the following additional features. Do not install XenApp features on
a domain controller.
Note: The following list includes high-level installation information; it is not comprehensive. Use the
feature documentation for installation guidance.
Application streaming. On a separate, clean workstation with an operating system similar to that of
your end-users, install the Citrix Streaming Profiler and use this workstation to profile applications
for streaming.
Single sign-on. Before installing the Password Manager plug-in from a command prompt onto a
Windows Vista or Windows Server 2008 computer, install the Microsoft Visual C++ 2005
SP1 Redistributable Pack (x86) and Microsoft Visual C++ 2005 SP1 Redistributable Pack (x64),
available from the installation media in the Support/vcredist directory.
SmartAuditor. Install the SmartAuditor player on a Windows Vista or Windows XP device only.
The SmartAuditor Server and database cannot be installed on Windows Server 2008. As a best practice,
do not install the SmartAuditor Server and database on the same server as XenApp.
Application performance monitoring. Install this feature on a separate server. To avoid errors
in performance measurement, do not install the Application performance monitoring database on any
farm servers that will be hosting user sessions.
EasyCall voice services. Install the EasyCall plugin and configure the EasyCall appliance
using documentation provided with the appliance (purchased separately). Install the EasyCall plug-in
on every XenApp 5 server or client device as required.
Secure application access. Depending on your Access Gateway edition, you can install the plug-in
from the appliance (purchased separately).
WANScaler. Install the WANScaler plug-in provided with this release and install and configure
the WANScaler appliance using documentation provided with the appliance (purchased separately).
The Branch optimization feature does not function with Access Gateway Enterprise Edition.
Installing the XenApp 5 Feature Pack

For information about installing the XenApp 5 Feature Pack, see the Release Notes for XenApp 5.0 Feature Pack.
8.3.4.6. Running Mixed Farms

When you run multiple versions of XenApp in your farm, this is known as a mixed farm or mixed mode.
For information about mixed farms, as well as upgrading or migrating to XenApp 5, see CTX117913. The
XenApp installation documentation contains additional information.
8.4. System Requirements for XenApp 5.0 for Windows Server 2003
Updated: 2010-06-17
Note: When using the wizard-based installation method, the initial Setup page contains a link to an
Installation Checklist (CTX113962). This document contains similar information.
The following sections list the supported platforms and system requirements for XenApp 5.0 for Windows
Server 2003 and its server consoles.
System requirements for features and related technologies are described in their respective documentation.
For information about which features are supported in each XenApp edition (Platinum, Enterprise, and
Advanced), see http://www.citrix.com/xenappcomparativematrix.
For information about Citrix License Server and License Management Console requirements, see the
Citrix licensing documentation.
For information about preparation tasks you may need to complete before beginning XenApp installation, see
Preparing Your Environment. Also check the Pre-installation Update Bulletin (CTX113540).
XenApp 5.0 for Windows Server 2003 supports both 32-bit and 64-bit editions of the Windows server in the
same farm.
XenApp 5.0 for Windows Server 2003, 32-bit Edition
XenApp 5.0 for Windows Server 2003 is supported on the following operating systems:
Windows Server 2003 (Standard, Enterprise, and Datacenter editions) with Service Pack 1 or 2
Requirements:
Disk space:
400MB for XenApp 5.0 for Windows Server 2003, Enterprise Edition
50MB for the Presentation Server Console
25MB for the Access Management Console
Terminal Services, running in application mode
Autorun installs the following software, if it is not already installed (you can also install it manually from
the Support folder on the installation media):
Java Runtime Environment, Version 1.5.0_09
.NET Framework Version 2.0
Citrix does not recommend installing XenApp on a domain controller.
XenApp 5.0 for Windows Server 2003, 64-bit Edition
XenApp 5.0 for Windows Server 2003, 64 bit edition, has the same requirements as the 32-bit edition, with
the following exceptions:
Minimum CPU: 64-bit architecture-based computer with Intel Pentium or Xeon family with Intel
Extended Memory 64 Technology, or AMD Opteron family, AMD Athlon 64 family, or compatible processor
Minimum RAM: 512MB
Multiprocessor support: up to eight
Minimum disk space: 4GB

By default, the Access Management Console is installed on the same computer where you install
XenApp. However, you can install and run it on a separate computer.
The Access Management Console is supported on the following Windows operating systems:
Windows Server 2008
Windows Server 2003 (Standard, Datacenter, and Enterprise editions)
Windows Server 2003, 32-bit edition, with Service Pack 2
Windows Server 2003, 64-bit edition
Windows Server 2003 R2, 32-bit edition
Windows XP Professional
Windows XP Professional, 32-bit edition, with Service Pack 3
Windows Vista (Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions, with Service Pack 1
Requirements:
If you want to run reports from the summary database on farms using Microsoft SQL Server or Oracle
as data stores: Microsoft Data Access Component (MDAC) Version 2.6
Disk space: 25MB
Microsoft Management Console (MMC) - For Windows Vista: MMC 3.0; for all other supported
Windows operating systems: MMC 2.0 or 3.0
Autorun installs the following software, if it is not already installed (you can also install it manually from
the Support folder on the installation media):
Microsoft .NET Framework 2.0
Microsoft Windows Installer (MSI) 3.1

By default, the Presentation Server Console is installed on the same computer where you install
XenApp. However, you can install and run it on a separate computer.
The Presentation Server Console is supported on the following Windows operating systems:
Windows Server 2008
Windows Server 2003
Windows 2000 Professional with Service Pack 4
Windows 2000 Server with Service Pack 4
Windows XP Professional with Service Pack 2
Windows Vista (Business, Enterprise, and Ultimate editions) with Service Pack 1
50MB of disk space is required
Autorun installs Java Runtime Environment Version 1.5.0_09, if it is not already installed (you can also install
it manually from the Support folder on the installation media).
Data Store Databases
The following databases are supported for the XenApp 5.0 data store:
Microsoft Access
SQL Server 2005 Express Edition, Service Pack 1
Microsoft SQL Server
Oracle
IBM DB2
For information about supported versions, see CTX114501.
Citrix XenApp Plug-in for Hosted Apps for Windows
The Citrix XenApp Plug-in for Hosted Apps for Windows is supported on the following Windows operating systems:
Windows Vista (Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions
Windows XP Professional, 32-bit and 64-bit editions
Windows XP Embedded
Windows Server 2008, 32-bit and 64-bit editions
Windows 2000
The following browsers are supported (minimum versions):
Internet Explorer Version 5.0
Mozilla Firefox Version 1.0
Requirements:
VGA or SVGA video adapter with color monitor
Windows-compatible sound card for sound support (optional)
For network connections to the server farm, a network interface card (NIC) and the appropriate
network transport software
The following table lists the supported connection methods and network transports:
Protocol
Citrix XenApp Citrix XenApp Web Plug-in Program Neighborhood
TCP/IP+HTTP
SSL/TLS+HTTPS X
TCP/IP
For more information, see the XenApp Plug-in for Hosted Apps Administrators Guide.
For information about clients for other operating systems, go to http://support.citrix.com.
Application Streaming
The Citrix XenApp Plug-in for Streamed Apps and the Streaming Profiler are supported on the following
Windows operating systems:
Windows Server 2003
Windows Server 2003 (Standard, Enterprise, and Datacenter editions), 32-bit and 64-bit
editions, with Service Pack 1 or 2
Windows Server 2003 R2, 32-bit and 64-bit editions
Windows Vista (Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions, with Service Pack 1

The profiler workstation and client computers must meet the following requirements:
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.
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, go to http://support.microsoft.com/kb/931534.
The profiler workstation must provide a run-time environment that is as close to your client
computer environment as possible:
If applications are published as Streamed to Client, 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
The client computers must meet the following requirements:
A network connection to the server farm, such as a network interface card (NIC) and the
appropriate browser: Internet Explorer Version 6.0 or 7.0, Netscape Version 7.1, or Firefox Version 1.0
.NET Framework 2.0, 3.0, or 3.5 installed to stream Microsoft Office 2007 programs or to stream
profiles enabled for inter-isolation communication
Manually uninstall any previous version of the Streaming Client and Program Neighborhood Agent on
client devices, and install the version included in this release:
If applications are Streamed to Client, client computers need both the Citrix XenApp Plug-in
for Streamed Apps and XenApp Plug-in for Hosted Apps installed
If applications are Accessed from a server, client computers need the XenApp Plug-in for
Hosted Apps installed, but not the Citrix XenApp Plug-in for Streamed Apps
8.5. Planning Your XenApp Deployment

Review this planning information before installing the first XenApp server in your farm.
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 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 and defining the installation processes.
8. Creating a pre-production pilot farm based on your farm design.
9. Testing the pilot farm.
10. Releasing the farm into production.
8.5.1. Farm Terminology and Concepts
Terminology
The XenApp planning and installation documentation uses the following terminology.
Multi-user environment
An environment, including XenApp and Terminal Services, where applications are published on servers
for use by multiple users simultaneously.
Application servers
The farm servers that host published applications.
Infrastructure servers
The farm servers that host services such as the data store or the license server. Typically, they do not
host published applications.
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.
Enumeration
The process in which a client transmits data to locate servers on the network and retrieves
information about the server farms published applications. For example, during enumeration, the
XenApp Plug-in for Hosted Apps communicates with the Citrix XML Service or the ICA browser,
depending on the browsing protocol selected in the plug-in.
XenApp Setup comprises two installation wizards:
Create a New Farm. The first time you install XenApp, select Create a New Farm in the
installation wizard and Setup creates the farm with that server hosting specific roles.
The server where you installed XenApp and created the farm is the first farm server or the Create farm
server.
Join an Existing Farm. When you run Setup on servers after installing XenApp on the first farm
server, you take a different path in Setup and XenApp references the settings you specified on the
first farm server. These servers join the existing farm and communicate with the first server in the farm.
Farm Environment
You should already be familiar with client-server architecture, redirection, and application publishing.
This illustration shows a basic deployment of XenApp.
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.
By default, the first server in the farm functions as the data collector.
By default, the data collector is configured on the first farm server during the Create Farm Setup and
all other servers are configured with 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
The data collector is an infrastructure server and applications are typically not published on it.
Zone
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 File or Web Server
Applications can be delivered to users by either streaming or hosting the applications on the server. If
you are streaming applications, either to client or server, you must install a streaming file server in
your environment. When streaming applications, 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 CAB files, a hash key file, the icons repository
(Icondata.bin), and a scripts folder for pre-launch and post-exit scripts.
Web Interface
The Web Interface is a required component in any environment where users access their applications
using either the XenApp plugin or a Web browser. Install the Web Interface on a stand-alone
computer; however, where resources are limited, the Web Interface is sometimes 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 the XenApp plug-in or the Access Gateway, the site:
Forwards the users credentials to the Citrix XML Service
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 Service and the Citrix XML Broker
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:
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 Setup. 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.
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 infrastructure functions.
This illustration uses a large farm to show how the Web Interface and the XML Broker work together. (1) The
user connects to the Web Interface through the XenApp plug-in or a Web browser; (2) the Web Interface
contacts the XML Broker to determine which applications are available for this user; (3) the XML Broker
queries the IMA service for this information and returns the results to the Web Interface; (4) the Web
Interface displays the available applications to the user either through a Web page or by placing shortcuts
directly on the users computer.
Infrastructure Servers
XenApp farms have two types of servers: infrastructure servers and member servers that host
published applications. Infrastructure servers perform specific functions and do not typically host
published applications, except in small farms. The services include:
Farm infrastructure services - Data store, data collector, and the Citrix XML Broker.
Access infrastructure services - Web Interface, Secure Gateway (optional), and Access Gateway (optional).
Additional services - Citrix License Server, Streaming File or Web Server (optional), a computer for
profiling applications, Configuration Logging database (optional), EdgeSight database (optional),
and SmartAuditor player (optional).
One or more infrastructure services can be grouped together in small farms. In large deployments, each
service runs on one or more dedicated servers.
This illustration suggests which infrastructure functions can be grouped on the same server, depending on
the size of your environment.
Factors other than size can affect how infrastructure functions are grouped . Security concerns,
virtualized servers, and user load play a part in determining which functions can be collocated.
This illustration depicts infrastructure servers in a large farm. The Web Interface, XML Service, data collector,
and data store are deployed on separate servers.
One way to think of the division between infrastructure servers and published application servers is to consider
an infrastructure server as the controller server and the published application servers as the worker servers.
The controller server provides the infrastructure that manages and supports the worker servers, which host
the applications. Typically, in larger farms, you segregate the controller functions onto distinct servers. For
small farms, you might have one controller server hosting infrastructure functions and multiple worker
servers hosting published applications.
Small farms that require redundancy might have one or two infrastructure servers. For example, in a small
farm with an Access data store, 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 and the Web Interface.
Medium and large farms might group infrastructure servers and services together when they have
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. In large
farms, the Citrix License Server and the Web Interface are typically hosted on separate servers.
8.5.2. Farm Hardware Considerations
The number of users a XenApp server can support depends on several factors, including:
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:
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 Terminal 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.
Operating system - Running Windows Server 64-bit edition on 64-bit computers can optimize
processor resources. Limitations on the amount of kernel memory available in 32-bit operating systems
can reduce user scalability. You can work around 32-bit architecture limitations by using 32-bit and 64bit applications on a 64-bit operating system.
8.5.3. Remapping Drive Letters

Important: This feature is supported on XenApp for Windows Server 2003; it is not supported on XenApp 5
for Windows Server 2008.
When a user launches a session, XenApp tries to map disk drives on the server to the typical drive letters for
the client device. If the drive letters are available, the server maps the client's first floppy disk drive to A,
the second floppy drive to B, the first hard disk drive to C, and so on. However, a server cannot map client
device drives to letters that are assigned to the server's own disk drives.
Client drives that use the same letters as the server's drives are assigned different drive letters,
starting with V and going backward through the alphabet.
If client drive letters do not conflict with the server's drive letters, the original letters for the client
drives are used.
Server floppy disk drives are not available to client users, so the drive letters for floppy disk
drives specified on the client devices are used. Non-Windows clients that support floppy drive mapping
can be configured manually with specific drive letter mappings for each drive.
Default Drive Mappings

The following table lists the default drive mappings for sessions. Client drives C and D are renamed V and
U, because the server drives use the letters C and D.
Logical drive letter Drive letter in session
Client drives
A (floppy drive)
B (floppy drive)
Server drives C
Remapping Drive Letters

To make drive access more familiar for users, you can change the server drives to use letters that are not
likely to be used by client devices. This ensures that client drives retain their original drive letters. By
changing the server to use higher drive letters (such as M, N, or O), the original lower drive letters
become available for assignment to the drives on the client devices.
The following table illustrates an example of changing server drive letters.
Logical drive letter Drive letter in session
Client drives
A (floppy drive)
B (floppy drive)
Server drives C
Important: To ensure stable performance, remapping server drives should be done before installing .NET
2.0 and before installing XenApp.
To remap server drive letters, select Remap drives from the Autorun Setup menu.
(Remapping uses the driveremap or driveremap64 utility. Do not use this utility on a server with .NET
2.0 installed.)
For best practices information, see CTX457309.
8.5.4. Planning for Applications and Server Loads
Updated: 2009-09-23
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:
Can I run the applications on the Windows Server platform, Terminal Services, or on XenApp 5.0?
For XenApp 5 for Windows Server 2008, Citrix recommends testing non-Vista-compliant applications
on Windows Server 2008 before you publish them on your farm.
Some non-Vista-compliant applications run on Windows Server 2008 using its
Application Compatibility feature
Consider using XenApp 5 for Windows Server 2003 for applications that do not run under
the Windows Server 2008 Application Compatibility feature
If users require any features that are not supported on XenApp 5 for Windows Server 2008, such
as PDA Sync, you might need to deploy a farm that includes XenApp 5 for Windows Server 2003
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.
If you have applications that require XenApp for Windows Server 2003, determine how you want to manage
your mixed-farm requirements. Use one of these scenarios:
One farm that runs both XenApp 5 for Windows Server 2003 and XenApp 5.0 for Windows Server
2008. Use this as only part of a farm migration strategy and not as a permanent solution.
One farm for XenApp 5 for Windows Server 2003 and one farm for XenApp 5 for Windows Server
2008. Use the Web Interface to provide one consolidated access point for users. Citrix recommends
this strategy where a mixed farm is a permanent requirement.
8.5.4.1. 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 Terminal Services or XenApp. Terminal 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 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:
.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.
8.5.4.2. 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 organizations needs. 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.
Applications can be delivered to users as:
Hosted and Accessed from Server - Applications are installed on the server, where the processing
takes place, and accessed from the server. This is the traditional XenApp publishing model. For
many organizations, this provides the lowest cost of ownership for IT resources because it provides
the highest scalability.
Streamed to server - Executables for applications are put in profiles and stored on a file server;
however, application processing takes place on the server. One of the main differences between
streaming an application to the server and hosting the application on the server is that
streamed applications are stored on a central file server, and provide application isolation by design.
Streamed to client - Applications are stored on a file or Web server; however, application processing
takes place on the client device and not the server. When applications are streamed to the client device (
streamed to desktop), the user experience is similar to running applications locally. The executables
for applications are stored on the streaming file share.
Advantages
Disadvantages
Installed
and hosted on
the server
or streamed
to server
There is a more consistent user

experience regardless of the client device.
You can maintain and manage
applications centrally.
Farm servers
require sufficient
resources to support
the applications.
In many cases, streaming to server

lets conflicting applications run on the
same server without needing to silo them.
Client devices do not require
extensive resources, such as hard
drives. These delivery methods support
thin clients.
Streamed to client
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 or CPU-intensive applications,
are streamed to client.
Client devices must

have sufficient resources
to run the
applications locally;
the client devices cannot
be thin clients.
Client devices must
run Windows XP or
Vista operating systems.
The requirement for a central file server is not necessarily an impediment to deploying streamed applications
in organizations with branch offices because the streaming file share can be deployed on a Web Server.
Combining Application Delivery Methods
You can run applications in dual mode in which XenApp tries to stream the application to the client device first
but uses another access method if streaming to client is not supported on the client device. You can specify
that some users, such as sales personnel, run applications streamed to client when they are accessing
the applications from Windows devices and then run them as hosted applications when they are accessing
them from handheld mobile or kiosk-type devices.
If users need to access applications when they are offline (not connected to the farm), consider
streaming applications. If your users have thin clients, install and deliver applications from farm servers.
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.
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 local devices and ports with both methods of
application delivery.
8.5.4.3. Placing Applications on Servers
When designing your farm, consider the following:
The servers on which the applications are installed
If 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
Siloed
It is easy to track the application

s location and usage
Disadvantages
Additional servers are required
to ensure sufficient redundancy
Centralization makes it is easy

to configure and maintain the application
Other applications do not interfere
with the installed application
Can be useful for missioncritical applications
Nonsiloed
Reduces the number of servers

required for applications in smallto medium-sized farms
Cannot be used when

applications conflict with
other applications
Might simplify user permissions

and ensure consistent settings
during application installation
A single server is accessed by each
user and session sharing is ensured
By using features such as Load Manager, you might not need to silo mission-critical applications or
applications with high levels of peak usage.
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.
Use Load Manager to 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.
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.
Advantages
Servers centralized at
one site
Centralized server administration

and support.
Centralized application management.
Potentially better physical
security than in branch offices.
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.
Disadvantages
Single point of failure; if
the site loses
connectivity, users have
no alternative access.
Server-toserver 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.
Determining How to Install Applications

In large farms, installing applications on servers can be time consuming. Also, applications on loadbalanced 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.
8.5.5. 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:
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:
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
Single Farm
Multiple Farms
Data Store
The farm has one data store.
Each farm must have a data store.
Data
Store Replication
Citrix recommends that you replicate

the data store to remote sites when
using one farm in a WAN environment.
If each remote site is a farm with its

own data store, there is no need for
data store replication.
Load Balancing
You can load balance an application

across the farm.
You cannot load balance an

application across servers in
different farms.
Firewall Traversal
If the farm spans multiple sites,

firewall ports must be open for serverto-server communication.
Site-based farms eliminate the need

to open firewall ports for server-toserver communication.
Server-toData store information is synchronized

server Communication 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.
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.
Management Tools
You can monitor and configure

multiple farms from the
Access Management
Console. Communicating with
multiple farms from the console
requires logging on to each 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.
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:
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.
8.5.6. Planning Infrastructure Servers

Regardless of your farm size, Citrix recommends having at least one server dedicated to infrastructure
functions. Publishing applications on the infrastructure server slows down application enumeration. If you
decide to install infrastructure 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, another factors to consider is 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 infrastructure 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:
When the peak number of users is connecting simultaneously to the farm; this usually occurs in
the morning.
When the peak number of users is connected to the farm; this usually occurs during the day.
If the counters exceed the values listed in the table, move the infrastructure functions on to separate servers
until the counter metric no longer exceeds the value.
Performance Monitor Counter Name
Criteria
CPU
> 85% - 90%
Memory
> 80%
ResolutionWorkItemQueueReadyCount
> 0 for extended periods of time
WorkItemQueueReadyCount
> 0 for extended periods of time
LastRecordedLicenseCheck-OutResponseTime
> 5000 ms
Typically, you need to evaluate the LastRecordedLicenseCheck-OutResponseTime counter only in large farms.
8.5.6.1. 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:
Farm configuration information
Published application configurations
Server configurations
Citrix administrator accounts
Printer configurations
For information about supported database versions, see http://support.citrix.com/article/CTX114501.
Choosing a Database
For this XenApp version, you can use the following database software for the farm data store:
Microsoft SQL Server, Oracle, and IBM DB2 These are true client/server databases that offer robust
and scalable support for multiple-server data access.
Note: Do not install XenApp on the Microsoft SQL Server, Oracle, or IBM DB2 database server.
Microsoft SQL Server 2005 Express Edition This type of database is most appropriate for small
to medium-sized farms and can be administered using standard Microsoft SQL Server tools.
Microsoft Access Microsoft Access is the default database type. If you leave this at the default,
Setup creates the data store on the first server in the farm using Microsoft Access.
Consider these factors before deciding which database product to use:

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, Oracle, or DB2
Whether or not you foresee the enterprise expanding, which would result in expanding the size
and maintenance of the database
Whether a server has the appropriate hardware configuration to also run an Access or SQL Server
Express database or whether you require that the database be located on a server that is not also
running XenApp
Any database maintenance requirements, such as backup, redundancy, and replication
General recommendations are listed below, based on the following size table.
Small
Medium
Large
Enterprise
1-50
25-100
50-100
100 or more
Named Users < 150
< 3000
< 5000
> 3000
Applications
< 100
< 500
< 2000
Servers
< 100
Microsoft SQL, Oracle, and IBM DB2 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, Oracle, and IBM DB2 are suitable for large farms and support replication.
Microsoft Access and SQL Server Express are suitable for all small and many medium environments
located in one physical location (that is, 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.
8.5.6.1.1. Connecting to the Data Store
A factor in planning your data store is deciding how you want servers in the farm to access the server on
which the data store database is running: directly or indirectly. (You specify the access method when you
run Setup to install XenApp on servers to join an existing farm.)
Direct access - If you are in an large farm environment, have a mission-critical farm, or are using
Oracle, SQL Server, or DB2 as the database for your data store, Citrix recommends accessing the
data store directly. For direct access, a server must have appropriate ODBC drivers installed and configured.
Indirect access - With indirect access, servers in the farm connect to an intermediary server
running XenApp, which connects to the data store directly. If you are in a small to medium
environment and are using SQL Server Express or Microsoft Access for your data store, each server in
the farm (other than the Create Farm server), must access the data store indirectly.
Citrix does not recommend indirect access for mission-critical farms because the intermediary server is
a single point of failure.
By default, indirect access uses TCP port 2512 for communication between servers in the farm and
the intermediary server that connects to the data store. If the servers are in different subnets divided by
a firewall, be sure this port is open on the firewall.
Protecting the data store is part of securing your server farm; this includes protecting the data and
restricting who can access it. In a direct connection, all farm servers share a single user account and password
for accessing the data store. Keep the credentials secure and provide them to administrators only for
installing XenApp. See the XenApp security documentation for more information.
8.5.6.1.2. 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:
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 Access Management Console and
Advanced Configuration tool performance, how long it takes to add (install) 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
50
100
250
500
1000
Number of applications published to all servers
50
50
50
50
50
Number of user policies
25
25
25
25
25
Printers per server
Printer drivers installed per server
25
25
25
25
25
Network print servers with printers
Number of Load Manager load evaluators
10
10
10
10
10
Number of application folders in Access

Management Console
10
10
10
10
10
Number of server folders in Access Management Console
16
25
50
50
Number of Application Isolation Environments
10
10
10
10
10
Number of Citrix administrators
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
Quad Pentium 4/3.0GHz with 4GB RAM
The actual performance of a farms data store varies depending on the database engine and the level
of performance tuning achieved.
8.5.6.1.3. Replication Considerations
A significant amount of network traffic for XenApp farms consists of reads from the data store; writes
are infrequent. The amount of bandwidth required increases as farm size increases. Actions such as data
store reads and restarting multiple servers simultaneously use disproportionately more bandwidth on larger farms.
Citrix recommends using a single data store for most deployments, but in some situations, placing a
replicated data store at remote sites can improve farm performance. Citrix recommends replicating the data
store across all high-latency or low-bandwidth WAN links. A replicated data store ensures all data store
reads occur on the network local to the XenApp server.
In a WAN environment, place replicas of the data store at sites with a large number of servers; this
minimizes reads across the WAN link. Database replication consumes bandwidth. Limit the use of
replicated databases to configurations where the remote site has enough servers to justify the bandwidth cost
of placing a replicated copy of the database at the site. For SQL Server, you must use immediate
updating transactional replication.
Crossing high latency links without using replicated databases can create situations where the data store is
locked for extended periods of time when performing farm maintenance from remote sites. Data store reads
do not adversely affect local connections but remote sites can experience slower performance. This means
that the Citrix IMA Service may start after extended periods of time and some normal operations may fail
when initiated from the remote site.
Note: You might experience poor performance if you use a local XenApp management console to perform
farm maintenance on a remote site that has high latency. You can resolve this issue by publishing
the management consoles as applications on a server at the remote site and use a Citrix XenApp plug-in
to access the published management tools.
8.5.6.1.4. 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 XenApp administration documentation contains more information about IMA
encryption, Configuration Logging, and when to enable these features.
You can enable IMA encryption during or after XenApp Setup; however, it is easier to enable it during Setup.
To enable IMA encryption during Setup, you specify a key which is used for all the servers in your farm. You
can generate the key before or during Setup.
For custom installations or provisioning servers in large environments, consider:
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
Important: If you add a key file to a network location, ensure that you have explicit rights to the
key file so that you are not prompted for your credentials during Setup. Mapped drives are not
supported for specifying the path for the key during installation.
To generate the key before Setup, use CTXKEYTOOL, which is available on the installation media.
If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.
Enabling IMA Encryption as a Local Administrator
Citrix recommends that if you plan to enable IMA encryption during Setup and want to connect to the data
store indirectly (as is the case with Microsoft SQL Server Express and Microsoft Access databases, by
default), install XenApp using a domain account that has local administrative privileges on the server.
You cannot enable IMA encryption when you join a farm (either during Setup or when changing farms) if you
are logged in as a local administrator and you try to connect to the data store indirectly. If you use a
local administrator account that is not part of the Citrix Administrator group, configure all local administrators
as Citrix Administrators after running Setup on the first server in the farm.
1. In the Access Management Console or Delivery Services Console, expand the XenApp node.
2. In the left pane, under the Farm node, select the Administrators node and select Action > New >
Add administrator.
3.
3. On the Add Citrix Administrator page, select the Add local administrators check box. This adds
all previously created local administrators to the Citrix Administrators group and automatically adds
any local administrators created in the future to the Citrix Administrators group.
8.5.6.2. Planning for Data Collectors
When planning for data collectors, consider:
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 300 MB 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.
8.5.6.3. Planning for WANs by Using 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:
If a site has a small number of servers, group that site in a larger sites zone.
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.
8.5.6.4. Planning for the Web Interface and XML Broker
Updated: 2009-10-14
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:
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:
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 plug-in.
Security Considerations
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.
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.
8.5.7. 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:
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:
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.
8.5.8. Designing Terminal Services User Profiles
Terminal Services user profiles define the user-specific Windows Server environment and preference
settings, including desktop appearance and color options. Citrix recommends setting Terminal Services profiles
for all users to avoid inconsistencies. Terminal Services user profiles are distinct from Windows user profiles.
Effectively designing Terminal Services user profiles can improve the performance and manageability of a
XenApp environment, reducing the occurrence of slow logons, loss of user settings, profile corruption,
and excessive administration effort.
When a user logs on, the users profile is loaded onto the XenApp server. If a Terminal Services profile is
not designated, the users Windows profile is used. If there is no Windows profile, the users local profile on
the server is used or created.
In a XenApp environment, Terminal Server profiles behave as follows:
Local Profiles
Local profiles are stored on each farm server and are initially created based on
the default user profile. A user accessing applications in a load-managed
XenApp farm creates an independent profile on each server. Users can save
changes to their local profile on each individual server, but changes are only
available to future sessions on that server. Local profiles require no configuration; if
a user logging onto a XenApp server does not have a profile path specified, a
local profile is used.
Although local profiles are the default, Citrix does not recommend using
them because profiles are created for each user on every server to which they
have connected, which leads to an inconsistent user experience.
Roaming Profiles
Roaming profiles are stored in a central location for each user. The information
in roaming profiles, such as a printer or a registry setting, is available to all
XenApp servers in the environment. To configure a user for a roaming profile,
you specify the users Terminal Server Profile Path to a particular location on a
file server. The first time the user logs on to a XenApp server, the default user
profile is used to create the users roaming profile. During logoff, the profile is
copied to the specified location on a file server.
Mandatory Profiles
Mandatory profiles are stored in a central location for each user. However, the user
s changes are not retained on logoff. To configure a user for a mandatory profile,
you create a mandatory profile file (NTUSER.MAN) from an existing roaming or
local profile, and assign the users Terminal Services profile path to the
location where the file can be accessed.
Citrix recommends, where feasible, using mandatory profiles if they address
the defined requirements.
Multiple Profiles
Multiple profiles combine two or more of the profile types (local, roaming,
or mandatory) for the same user. Multiple profiles are useful in environments
with load-managed groups or application silos. For example, in a XenApp farm
with two load-managed groups serving SAP and Microsoft Office, you can
configure users with a mandatory profile for the SAP servers and a roaming profile
for the Microsoft Office servers. Multiple profiles are also useful for farms that
span WAN connections, so that profiles can be accessed from local file servers.
Multiple profiles are more complex to administer and maintain and are not
widely used.
When defining user profiles for your XenApp environment, consider:

If users run applications such as Microsoft Office where settings must be retained, consider a
roaming profile. If users do not need to save settings, using a mandatory profile solution can
ease administration.
If the application you are publishing references the HKEY_CURRENT_USER (HKCU) hive in the registry,
use a roaming or multiple profile design.
If you provision printers by auto-creating client printing devices and use client device printing settings,
you can use mandatory profiles. To save printer settings, use the XenApp printer properties retention
policy rule.
If applications are siloed in load-managed groups, roaming profile designs make profile setting loss
or corruption possible. For example, users accessing SAP and Microsoft Office at the same time
can overwrite roaming profile settings made in the Office session if the user logs off from the Office
session before the SAP session. Consider multiple profile designs for farms employing loadmanaged groups.
This table compares the profile options:
Advantages
Local Profile
Roaming Profile
Disadvantages
No requirement for file server

for profile storage
Settings are not consistent

across servers and sessions
Not susceptible to corruption
Consumes local disk space
Settings are saved across sessions
Slower logon times
Consistency
Mandatory Profile
Fast Logon
Settings are not saved across sessions
Not susceptible to corruption
Multiple Profiles
Benefits of both mandatory

and roaming profiles
Potential for additional file

server space requirements
Additional administration
and maintenance
When configuring profiles, designate profiles within Active Directory policies, if possible, not user properties.
Citrix recommends storing roaming profiles and permanent user data on a centralized file server, storage
area network (SAN), or Network Attached Storage (NAS) unit that supports the environment. Locate this
storage medium logically near XenApp to reduce the number of router hops required and optimize logon times.
In addition to profile type, folder redirection is generally recommended. This ensures that user data stored in
the designated folders does not need to be written to the profile. Folder redirection is typically useful
for mandatory and roaming profiles. Although you can configure folder redirection in Windows Server,
Citrix provides a Special Folder Redirection feature. For more information, see the Special Folder
Redirection documentation.
8.5.9. 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.
Caution: If you change the servers hosting applications and this changes the trust intersection,
applications can become unavailable to users who are not in that trust intersection.
System Account Considerations

Consider the following when deciding how to configure your Citrix administrator accounts:
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 Access
Management Console 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.
If you want to enable the Independent Management Architecture (IMA) encryption feature during
Setup, Citrix recommends that you install XenApp using the same network credentials.
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:
Authenticating a Citrix administrator
Refreshing the display or launching an application in Program Neighborhood and 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 Setup creates local accounts to run the following XenApp services:
XenApp Service
Default Local User Account
Citrix Print Manager Service
ctx_cpsvcuser
CPU Utilization Mgmt/CPU Rebalancer
ctx_cpuuser
Configuration Manager for the Web Interface Service Ctx_ConfigMgr

Citrix strongly recommends that if you want to change local accounts to domain accounts, you do so
before installing XenApp. Changing service accounts after Setup is not supported.
Run Setup 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.
To substitute your newly-created domain account for the local account during XenApp installation, use
an installation method that employs Windows Installer Commands. Specify the property for the service,
and provide the new domain account name as a parameter.
8.5.10. Recommendations for Active Directory Environments
Citrix recommends the following configuration for server farms with Active Directory:
XenApp servers are in their own Organizational Units (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, the Advanced Configuration
or Presentation Server Console, and Program Neighborhood filtering. 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 Access Management Console or Delivery
Services Console because that console allows only pass-through authentication.
Domain Global Groups
Authenticating to published applications
No adverse effects
Authenticating to Advanced Configuration

or Presentation Server Console
No adverse effects
Program Neighborhood filtering
No adverse effects
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
Advanced Configuration
or Presentation
Server 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.
Program
Neighborhood filtering
Recommendation: All servers in the farm must be in the same domain

for Program Neighborhood filtering to work properly.
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.
Rationale: If a user is a member of a domain local group, the group is present

in the users security token only when logging on to a computer in the
same domain as the domain local group. Trust-based routing does not
guarantee that a logon request is sent to a server in the same domain as
the domain local group. It guarantees only that the request is handled by
a server in a domain that trusts the users domain.
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 user
s 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
or Presentation
Server 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.
Program
Neighborhood filtering
Recommendation: No Active Directory domains in the forest to which the

servers belong have explicit trust relationships with non-Active
Directory domains.
Rationale: Non-Active Directory domains have no knowledge of universal
groups and the domain controllers exclude a universal group from a user
s security token. As a result, applications might not appear in
Program Neighborhood.
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:
During Setup for each XenApp server in your farm, select the port sharing with IIS option and ensure
that IIS is configured to support HTTPS.
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.
8.5.11. 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.
8.5.12. 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.
Important: Shadowing restrictions are permanent. If you disable shadowing, or enable shadowing but
disable certain shadowing features during Setup, you cannot change the 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.
Shadowing is a server-level setting, so you can enable shadowing on one server and disable it on another.
Citrix does not recommend disabling shadowing as a substitute for user and group connection policies.
8.5.13. 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. The XenApp administration documentation includes detailed
information about securing server farms.
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:
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 plug-ins to users, especially if they connect from airport kiosks or
other public locations.
Securing connections to published applications with SSL/TLS. If plug-ins 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, 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: On Windows Server 2008 systems, XenApp Setup reconfigures the default Windows Firewall
port settings to allow incoming connections, such as those from ICA traffic and the Citrix
Independent Management Architecture service.
8.5.14. Planning for Supported Languages and Windows MUI Support
Updated: 2010-08-20
XenApp Language Edition Operating System Language Edition
XenApp, English
Windows Server 2003, English

Windows Server 2003, Russian
Windows Server 2003, Simplified Chinese

Windows Server 2003, Traditional Chinese
Windows Server 2003, Korean
XenApp, French
Windows Server 2003, French
XenApp, German
Windows Server 2003, German
XenApp, Japanese
Windows Server 2003, Japanese
XenApp, Spanish
Windows Server 2003, Spanish
Windows Multilingual User Interface Pack (MUI) is supported only on the English edition of Windows.
XenApp supports Windows MUI for Windows Server. Users connecting from non-English language clients see
their environment and applications in the language that corresponds to their language setting, provided
the server operating system and applications support it, and the corresponding language packs are installed
on the server. While XenApp supports Windows MUI, some XenApp components and features do not display in
the non-English language.
1. Before you install XenApp, make sure the Windows Server language option is set to English. The
language setting is located in Regional and Language Options. For more information, see the
Microsoft documentation.
2. Install the English version of XenApp.
3. Install the Windows MUI language packs you want to deliver to users, and install any applications
required, MUI or native.
Caution: Changing the Windows Server language option to another language after you install XenApp
might lead to display issues.
8.5.15. 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 plug-ins installed on end-user client devices. If the
passthrough authentication feature is not enabled before deploying the plug-ins to end users, users must
reinstall the plug-ins with this feature enabled before passthrough authentication will work.
To configure passthrough authentication functionality on the server, install a XenApp hosted plug-in on
each XenApp server. If you are deploying the XenApp plug-in as the client for users, install the XenApp plug-in
on your server as the passthrough client.
8.5.16. Planning a Successful User Experience
Two key factors impact your users' satisfaction with 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.
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 Terminal Services
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 Terminal Services 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:
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.
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.
The XenApp administration documentation contains details about printing configurations.
8.5.17. Integrating Other XenApp Features and Technologies
Each XenApp edition comprises a different set of features and technologies.
Usually, you install the XenApp farm and its required features first. Then, after installing XenApp and
the supporting infrastructure servers, you can optionally install other features and technologies supported in
your XenApp edition. In some cases, this includes installing plug-ins or clients on farm servers or
user workstations.
For complete information about design considerations, installing, and using the features and technologies,
see their documentation. The following notes may also help with your XenApp farm planning.
EdgeSight or Resource Manager Powered by EdgeSight - The EdgeSight Server includes a database
server and a Web server, which can be located on the same computer or on different
computers. Alternatively, if your XenApp data store is hosted on an SQL Server, you can collocate
the EdgeSight database with the data store. However, Citrix recommends monitoring the database
server to ensure it is not overloaded. To avoid errors in performance measurement, do not install
the EdgeSight database on any farm servers hosting user sessions.
Password Manager - The Password Manager service is typically installed on its own server. The
server hosting the Password Manager Service and central store contains highly sensitive userrelated information. Citrix recommends using a dedicated server and placing that server in a
physically secure location.
SmartAuditor - The player requires a separate desktop workstation. The administration components
are typically installed on a server dedicated to administration.
Access Gateway - The Access Gateway can control access to published applications on a XenApp
server. The Access Gateway is typically installed in the DMZ. There are specific design considerations
when you are deploying the Access Gateway with the Web Interface.
Installation Sequence
You can launch the Setup programs for several XenApp features and technologies from the XenApp wizardbased installation. Some of these and other XenApp features and technologies have different
installation prerequisites and considerations than the core XenApp software. This documentation does not
provide complete Setup instructions nor does it provide prerequisites for those features and technologies.
With the exception of the XenApp management consoles, instructions for installing these features
and technologies are provided in their respective documentation.
The wizard-based method installs the features and technologies you select in the correct order. For a
custom installation, follow the order listed below. Although the sequence is not mandatory, it reduces the need
to manually configure options after Setup because information was not available, such as server or site names.
1. Citrix Licensing, including the Citrix License Server and the License Management Console.
2. Web Interface. Installing the Web Interface and creating a Web Services site before installing XenApp
lets you provide a response for the site name when prompted by XenApp Setup. If you are deploying
2.
a Citrix XenApp plug-in, install the Web Interface and create a XenApp Services site. (You can also
install the Web Interface after installing XenApp. In some situations, this might be easier and preferable.)
3. XenApp.
4. XenApp management consoles. (You can install these consoles on a remote computer as well as on
XenApp servers. However, for the Web Interface, you must install the Access Management Console
(also known as the Delivery Services Console, depending on your XenApp version) on the same server.)
To install the management consoles for XenApp, Password Manager, and the Access Gateway on the
same server, install the extensions in the following order:
1. Access Gateway
2. Password Manager
3. XenApp
5. EdgeSight or Resource Manager powered by EdgeSight.
6. Secure Gateway. (Installing the Secure Gateway after installing XenApp lets you complete the
Secure Gateway configuration wizard. If you install the Secure Gateway before you create your farm,
you must re-run the Secure Gateway configuration wizard by re-running Setup. Secure Gateway is
not typically installed on a XenApp server.)
7. Password Manager.
8. SmartAuditor.
9. Other features and technologies supported on your XenApp edition.
Installing Agents for XenApp Features and Technologies

If you plan to deploy the following features and technologies (if available in your XenApp edition), consider
these notes:
Note: You can also install some of these features during XenApp Setup.
EdgeSight - Install the EdgeSight agent on the XenApp servers and client devices you want to monitor.
Citrix Password Manager - Install and publish the Citrix Password Manager plug-in on each server
that publishes applications requiring authentication. The plug-in provides credentials for
published applications only. You can also install the Citrix Password Manager plug-in locally on
client devices.
SmartAuditor - Install the SmartAuditor agent on the servers hosting the applications you want to
monitor. Install the agent after you install the XenApp server software.
EasyCall - Install the EasyCall client on the client devices or make it available to users by publishing it
on your farm.
8.5.18. Choosing an Installation Method

Updated: 2009-08-11
There are two general XenApp installation methods: wizard-based and custom.
The installation method you choose is related to the way you want to provision the servers in your farm. Select
an installation method that lets you install servers quickly in the event of server failure or network growth.
Having a repeatable way to build XenApp servers quickly saves time and resources, and ensures
consistent configurations.
Setup is the process of installing XenApp and its components and features. You invoke or run Setup with
an installation method.
Wizard-Based XenApp Installations
Wizard-based installations are initiated from the Autorun program, autorun.exe. Use wizard-based installations
if you need to install an individual component, install XenApp on small farms, or when creating images for
server provisioning. During a wizard-based installation, Setup automatically installs many non-Windows
system requirements; custom installations might not perform those tasks automatically.
A wizard-based installation manually installs XenApp and requires selecting options for every page of the
wizard. Deploying XenApp across a farm can involve repeating the same installation on many servers.
Often, performing a wizard-based installation on each server in the farm is too time consuming to be feasible.
Custom XenApp Installations
Custom installations provide more control over installation options than wizard-based installations (for
example, the ability to change local accounts for Citrix services to domain accounts, prevent nonadministrative users from connecting to the desktop of the server, and control the reboots after Setup).
Custom installations often provide a scalable approach for server provisioning.
XenApp supports the following types of custom installations:
Transforms - In large environments, if you deploy XenApp to multiple servers simultaneously
through Active Directory or Configuration Manager, you can use transforms with XenApp Setup (mps.
msi). Use the sample transforms included with XenApp to customize the XenApp Setup properties.
To perform this type of installation, Citrix recommends that you have Windows Installer and
installation database knowledge. You also need a third-party MSI editing tool.
Windows Installer commands (msiexec) - As with transform-based installations, Windows
Installer command installations require a solid understanding of the XenApp Setup properties.
Windows Installer commands can be used separately, or you can combine them with transforms for
Active Directory deployments. You can create scripts containing Windows Installer commands that
install system prerequisites and XenApp in one action.
Unattended installation with an answer file - Using the Unattended Installation Template, you can create an
answer file that provides responses to installation options during XenApp Setup. A sample answer file
that uses XenApp Setup properties is included in the XenApp installation media. Answer files provide
an installation that is ready to use with minimal customization on your part. Consequently,
unattended installations are one of the easiest ways to perform custom installations and generate
Windows Installer command lines. Since answer files are text files with a small file size, they are easy
to store and compare to other answer files using a file comparison utility. However,
unattended installations are not as powerful as Windows Installer Commands or transforms, and
you cannot use unattended installations to provision servers using Active Directory.
When performing custom installations, consider enabling Windows Installer logging, which provides a
detailed summary of installation actions.
8.6. XenApp Installation
Use this documentation to help prepare your XenApp environment and then install the XenApp server software.
XenApp comprises many features and technologies, many of which have their own preparation, installation,
and configuration instructions. This documentation does not cover those topics; see the documentation for
the feature or technology (for example, Web Interface, Access Gateway, Secure Gateway, and Citrix plugins). Additionally, features and technologies offered in the XenApp editions (such as Single sign-on,
Provisioning services, Load testing services) have their own installation documentation.
8.6.1. Building a XenApp Farm
The first time you install XenApp, you create a farm. When you install XenApp on other computers, you join
the farm you created on the first computer.
Before you build a XenApp farm, read about XenApp deployment planning, and complete the preparation tasks.
A typical high-level installation sequence is:
1. Install Citrix Licensing. (You can do this before, during, or after Setup; see the Citrix
licensing documentation for instructions.)
Note: If you plan to install multiple components on the same 64-bit server, install the Web
Interface before the License Management Console or XenApp.
2. Install the Web Interface, if you will be using it. (See the Web Interface documentation for
installation instructions; it is not covered in this section.)
3. Install one or more Citrix plug-ins on the server on which you are creating the farm. (You can do
3.
this before or during XenApp Setup.)
4. Install the management consoles. (These tools can be installed on a XenApp server either before or
during Setup; they can also be installed on other systems.)
5. Create a farm by installing XenApp on the server you want to function as the data collector for the first
(or only) zone.
6. Install XenApp on other infrastructure servers and then on servers that will host published applications.
7. XenApp prompts you to restart at the end of installation. You must restart XenApp for it to
integrate properly with Terminal Services.
After installing XenApp, perform the required post-installation configuration tasks.
The information that follows is based on using the wizard-based installation. Generally, the sequence
and explanations also apply to custom installations.
8.6.1.1. Preparing Your Environment
Updated: 2010-03-02
Before installing XenApp, complete the following preparation tasks, in any order. Some tasks are required only
if you want to use a particular feature or technology. Most tasks apply when you are creating the XenApp
farm; for preparation tasks when joining a farm, see Joining a Server Farm.
Use the left column to mark completed tasks.
Review the System Requirements and install any prerequisites that will not be installed by Setup.
Know which XenApp edition you will be installing (Platinum, Enterprise, or Advanced).
Choose a name for your farm. Farm names can include spaces, and up to 32 characters. If you plan to
use the Configuration Logging feature with an Oracle database, do not use hyphens in the farm name.
Choose an installation method.
Obtain the domain credentials for the user who will be the first administrator on the XenApp farm.
That administrator has full permissions to the farm and can create additional administrator accounts.
For more information, see Planning for Accounts and Trust Relationships.
Ensure the operating system clock on each server has the correct time.
Install the Terminal Server component (in Application Server mode), using the Manage Your Server
wizard to add the Terminal Services role to your server. Terminal Server is not installed with Windows
by default.
Complete the requirements for the database you will be using for the XenApp data store. (This can
include installing the database software, installing the database client, and (for direct access)
installing appropriate ODBC drivers.) For database planning information, see Planning fro the XenApp
Data Store. If you plan to use the IMA encryption features, see Planning for Configuration Logging
and IMA Encryption. The topics in the Data Store database Reference section contain database
installation guidance, plus additional information that might affect installation. If you are using a
Microsoft SQL Server, Oracle, or IBM DB2 database for the data store, and are not using the wizardbased Setup, see Creating a DSN File for XenApp Setup.
Install Citrix licensing, unless you choose to install it during or after Setup (Setup prompts you
for licensing information).
Install the Web Interface (if you plan to use it), unless you choose to install it during Setup. If you
want the XML Service to share a port with IIS, you must install the Web Interface before running
Setup. Configure a XenApp Web or XenApp Services site. For more information, see Planning for the
Web Interface and XML Broker and the Web Interface documentation.
If you want to change the accounts under which certain XenApp services run, see Substituting
Domain Accounts for User Accounts.
Install XenApp plug-ins on each server in the farm, unless you want Setup to install them. Setup
requires installing at least one XenApp plug-in for functionality such as pass-through client
authentication and shadowing to work correctly. If you invoke Setup from Autorun, the XenApp
hosted plug-in and the XenApp streaming plug-in are installed automatically by default.
Optimally, graphics displays for computers running the management consoles should be set to at
least 1024 x 768 pixels.
If you plan to remap drives, see Remapping Drive Letters.
If you use HP Protect Tools, install them before installing XenApp.
If you plan to use Philips SpeechMike devices with XenApp, install the drivers on all servers
hosting sessions that record audio.
If you plan to enable Windows Multilingual User Interface (MUI) support, see Planning for
Supported Languages and Windows MUI Support.
If you plan to use session shadowing, see Planning for Shadowing.
If you plan to use passthrough client authentication, see Planning for Passthrough Client Authentication.
If you plan to use the XenApp Management Pack for Microsoft Operations Manager 2005 or
Microsoft Systems Center Operations Manager 2007 to monitor either your XenApp farm or
Citrix Licensing, install the XenApp Provider and the Licensing Provider, which are the XenApp
Windows Management Instrumentation (WMI) providers.
8.6.1.2. Creating a Farm
You must have local administrator provileges to install the XenApp software.
Start the wizard-based installation by double-clicking autorun.exe. (You cannot start Setup by doubleclicking mps.msi.)
The following list summarizes the tasks to create a XenApp farm. Links are provided to separate topics if a task
is extensive or requires further description.
On the initial page, select Product installations and updates.
On the Presentation Server 4.5 page, select Install Citrix Presentation Server 4.5 and
its components. (You can also choose to install Citrix Licensing from this page, or install only
the management consoles.)
After choosing to install the server and component software, the License Agreement page appears.
Read the License Agreement and indicate your agreement.
The Prerequisites Installation page lists the items to install before installing the server software. If
you are using the wizard-based installation, some of these prerequisites are installed automatically.
This information is also available in the Installation Checklist.
Selecting Components.
Choosing the Edition.
Enabling and Configuring Passthrough Client Authentication.
Installing the License Server.
Installing the Access Management Console
The Access Management Console is a framework into which you install snap-ins or extensions.
Each extension provides additional administrative functionality for your Citrix environment. For
example, when installing XenApp Platinum Edition, extensions for features such as Password Manager
are installed.
Important: Do not install different versions of Access Management Console on the same server.
Selecting Components of XenApp.
Specifying the Farm Name, Data Store, Zone, and Credentials.
Enabling and Configuring IMA Encryption.
Specifying the Citrix License Server.
Enabling and Configuring Session Shadowing.
Configuring the Citrix XML Service Port.
Adding Users to the Remote Desktop Users Group.
Installing the Presentation Server Console
Important: Do not install different versions of the Presentation Server Console on the same server.
Important: The documentation and help provided with the software contains information available when
this version released. The most current documentation is in Citrix eDocs.
8.6.1.2.1. Choosing the Edition
Start the installation by double-clicking autorun.exe. (You cannot start Setup by double-clicking mps.msi.)
The initial Autorun page has the following options:
Option
Description
Installation Checklist
Displays XenApp installation prerequisites and system requirements.

Reading this can help avoid delays during Setup.
Platinum Edition,
Enterprise Edition,
Advanced Edition
XenApp is available in three editions. The components and features

available for installation vary with each edition.
Citrix on the Web
Provides links to the Citrix Web site and the Citrix Support Web site.
To continue installation, select your XenApp edition.

8.6.1.2.2. Choosing an Installation Category
Select an installation category. The components and features displayed vary according to the XenApp edition
you selected previously; the following display is for the Platinum Edition.
Option
Description
Application Virtualization
Installs Citrix Licensing, XenApp, Web Interface, Access

Management Console, Advanced Configuration tool,
and documentation.
Application Session Recording
Installs SmartAuditor administration features, the

SmartAuditor Player, and the SmartAuditor Agent.
Application Performance Monitor
Installs EdgeSight Server and the EdgeSight Agent.
Single Sign On
Installs the Citrix Password Manager service, the plug-in, and

the Central Store.
Common Components
Installs components such as the Citrix XenApp plug-ins,

Streaming Profiler, Access Management Console,
XenApp Configuration tool, Web Interface, Secure Gateway,
Citrix Licensing, and documentation
To install the XenApp server, select Application Virtualization.

8.6.1.2.3. Selecting Components
On the Component Selection page, select the major components you want to install. By default, all
components except the license server and the EdgeSight agent are enabled for installation. When you click Next
, a sequence of separate wizards guides you through the installation of the selected components.
Depending on the components selected, some configuration options might not be available or might appear in
a different order.
Option
Description
Citrix Licensing (disabled by default)
Installs or upgrades the licensing components for your

Citrix product. Every server farm must have access to a
Citrix License Server. Do not install Citrix Licensing every
time you run XenApp Setup. Instead, point your XenApp
servers to a common license server.
Installs the console framework for managing Citrix

components; this console snaps in to the Microsoft
Management Console (MMC).
Web Interface
Installs the Web Interface.
Citrix XenApp
Installs XenApp and its components. There are two suboptions:

Pass-through client. Installs Program Neighborhood
and the XenApp hosted plug-in. You can select either
or both.
Citrix XenApp Plugin for Streamed Apps. Installs
the XenApp streaming plug-in. Even if you are
not streaming applications on this server, install this
client to stream applications on other servers in the farm.
XenApp Advanced Configuration or

Installs the tool that manages printing, policies, load

manager, and zones.
XenApp Document Library
Installs the XenApp Document Library, which is a help

system for all major XenApp components and plug-ins. If
you disable this component, no help will appear in any
server-side XenApp components.
Note: See Citrix eDocs for the most current documentation.
EdgeSight Presentation Server Agent

(disabled by default)
Installs the agent for Resource Manager powered by EdgeSight.
If you select Citrix Licensing, see the Citrix Licensing documentation. For Web Interface and EdgeSight
installation information, see their respective documentation.
8.6.1.2.4. Enabling and Configuring Passthrough Client Authentication
To enable passthrough client authentication, select Yes on the Passthrough Authentication for
the Passthrough Client page.
After you enable passthrough client authentication, the Server Address for the Passthrough Client
page appears.
If you installed the XenApp hosted plug-in as the passthrough client, specify the URL for your
XenApp Services site (for example, http://yourservername/Citrix/PNAgent).
If you installed the Web Interface on this server, specify either localhost or the full URL for the
XenApp Services site. If you installed the Web Interface on a different server, specify the full URL for
the XenApp Services site.
If you are provisioning your servers using a third-party cloning program or using them in a
virtual environment, specify the name of the Web Interface server, not localhost.
If you have not installed the Web Interface, click Next and enter the address after installation.
For more information, see Planning for Passthrough Client Authentication.
8.6.1.2.5. Installing the License Server
If you deselected the Citrix Licensing component in the Component Selection page, a Warning! page
appears, containing two options:
Option
Description
Install a license server now
Launches the license server Setup, which installs the Citrix

License Server and the License Management Console.
I already have a license server,

or will use the installation media
to install one later.
Defers the requirement to specify a license server name until

later in Setup. You can also defer installing the
licensing components until after Setup.
8.6.1.2.6. Specifying the Farm Name, Data Store, Zone, and Credentials
Three pages appear during the process of creating a server farm.
Create or Join a Server Farm Page
Select Create a new farm. The Create a Server Farm page appears.
Create a Server Farm Page
1. Enter a name for the new server farm. Farm names can contain up to 32 characters and include spaces.
If you will be using Oracle as your Configuration Logging database, do not use hyphens in the farm name.
2. Select the data store database.
If you are using a Microsoft SQL Server, Oracle, or IBM DB2 database for the data store, select
Use the following database on a separate database server, and select the database from
the list. If your driver does not appear on the list, cancel Setup, install the driver, and then
restart Setup. (After you complete this page, Setup creates a Data Source Name (DSN) file
and names it MF20.dsn.)
If you are using a Microsoft Access or SQL Server Express database for the data store, select Use
a local database on this server, and select the database from the list.
3. If you want to change the default server farm zone name (Default Zone), clear the Use default
zone name check box and enter the new name.
For more information about the data store, see Planning the XenApp Data Store and Data Store
Database Reference. For information about zones, see Planning for WANs by Using Zones.
Assign Farm Administrator Credentials Page
Enter the domain credentials for the user who will be the first farm administrator. This administrator has
full permissions to the farm after XenApp is installed, and can create additional administrator accounts in
the Access Management Console.
8.6.1.2.7. Enabling and Configuring IMA Encryption
If you enable IMA encryption when you create a farm, you must enable it on all servers that join that farm,
using a key specified during Create Farm Setup. After enabling IMA encryption, you cannot disable it
without reinstalling all existing farm servers.
To enable IMA encryption during Setup, keys must be specified and loaded (activated in the data
store). Specifying a key does not necessarily load it.
If you have multiple farms in your environment, Citrix recommends that you generate separate keys for
each farm.
Citrix recommends installing XenApp using network credentials when enabling IMA encryption during Setup.
1. On the Enable IMA Encryption page, select the Enable IMA Encryption check box and click Next.
2. On the IMA Encryption Key Type page, select one of the following options:
Option
Description
Install Key From File
Select this option if you already generated a key file for this farm.
This option specifies the key file and loads it. If you already
loaded the key, use the Use Previously Loaded Key option.
Generate and Install New Key
Select this option if you have not yet generated a key for this
farm. This option generates a key and installs it on the
local computer.
Use Previously Loaded Key
Select this option if you already generated a key using

the CTXKEYTOOL and loaded the file on this server before you
started Setup. (This option is not available if the key file is not on
this server.)
If you select Install Key From File, browse to the location of the key file (USB flash drive,
diskette, or other location you can access). If the key file is on a network location, use a UNC path
to specify the location.
After you select the key file, the Citrix License Settings page appears; this indicates
you successfully loaded the key.
If you select Generate and Install New Key, save the key to any folder on your local computer.
Important: Citrix recommends choosing a meaningful key name, such as one that matches
the farm (for example, C:\Alpha Farm Key\alphafarmkey.ctx). You can specify any
extension that is not in use. Citrix also recommends backing up the key file.
After you click Save, the Citrix Licensing Settings page appears. This indicates you
successfully configured and enabled IMA encryption.
If you select Use Previously Loaded Key and you loaded a valid key, the Citrix
Licensing Settings page appears. This indicates you successfully configured and enabled
IMA encryption.
For more information, see Planning for Configuration Logging and IMA Encryption.
8.6.1.2.8. Specifying the Citrix License Server
Before users can connect to XenApp, you must configure the first server in the farm to use a Citrix
License Server. Select one of the following options:
Option
Description
Enter the host name for the

machine hosting your Citrix
License Server
Type the host name. If the license server is not using

the default port number (27000), enter the port number.
By default, servers joining the farm use the information
you enter here.
You cannot leave the license server name blank.
Enter the correct host name later
If you do not know the license server name and port

number, you can enter this information later using the
Access Management Console.
8.6.1.2.9. Enabling and Configuring Session Shadowing

Session shadowing lets you monitor and interact with user sessions. When you shadow a user session, you
can remotely view the user session display and interact with the session using your own keyboard and mouse.
Caution: Shadowing restrictions are permanent. If you disable shadowing or shadowing features during
Setup, you cannot reconfigure them after Setup, and they apply to any policies for user-to-user shadowing.
Choose among the following options:
Option
Description
Prohibit shadowing of user sessions

on this server
Disables user session shadowing on this server.
Allow shadowing of user sessions on

this server
Enables user-session shadowing by the server. You can

apply the following restrictions:
Prohibit remote control. By default, authorized
users can view a session they are shadowing and
use their keyboard and mouse to interact with it.
This option lets authorized users know their session

is being shadowed.
Force a shadow acceptance popup. By default,
an acceptance prompt notifies users when an
authorized user attempts to shadow their sessions.
This option prevents authorized users from
shadowing sessions without sending an
acceptance prompt.
Log all shadow connections. Enables logging
of shadowing attempts, successes, and failures in
the Windows event log.
For more information, see Planning for Shadowing.

8.6.1.2.10. Configuring the Citrix XML Service Port
XenApp uses the Citrix XML Service to supply the Web Interface server and its connecting clients with the
names of applications available in a farm. By default, Internet Information Services (IIS) uses port 80 for
HTTP traffic and port 443 for HTTPS traffic, if configured.
Important: All servers in the farm must use the same TCP port for the Citrix XML Service.
This page has the following options:
Option
Description
Share default TCP/IP port with

Internet Information Services (default)
The XML Service and IIS use the same port

for communications. This option requires the Web
Interface be installed before running XenApp Setup.
Use a separate port
Opens a different port number on the XenApp server for

XML Service communications with the Web Interface and
the clients.
Make sure other applications do not use the port number.
For a list of ports in use, type netstat -a at a
command prompt. Configure Web Interface servers (and
any clients connecting to it) to use the new port number.
Select the port sharing option if:

You plan to send data to the Web Interface over a secure HTTP connection using SSL. You can run
the Citrix XML service over port 443 using SSL in two ways:
Configure IIS for HTTPS traffic on port 443.
Configure SSL relay on port 443. It does not matter whether you choose port sharing or not.
The Web Interface and XenApp are installed on the same server.
The Web Interface and the Citrix XML Service are installed on the same server.
Select the separate port option if:
You want to install the Citrix XML Service on a dedicated XML server
You do not want the Citrix XML Service to share the TCP port with IIS
If you want to change the Citrix XML Service port after installation, you must do it manually; there is no option
on the Server Properties > XML Service page.
For more information, see Planning for the Web Interface and XML Broker,
8.6.1.2.11. Adding Users to the Remote Desktop Users Group
Only users who are members of the Remote Desktop Users group can connect to published applications.
By default, there are no users in the Remote Desktop Users group. Until you add users to this group,
only administrators can connect remotely to the server.
This page has the following options:
Option
Description
Add the Authenticated Users now
Adds domain accounts in the Windows Users group to

the Remote Desktop Users group. Users added to the
Windows Users group in the future will also added to
the Remote Desktop Users group.
Add the list of users from the

Users group now
Copies all current users from the Users group to the

Remote Desktop Users group. After Setup, if you add
user accounts, you must add the accounts to the
Remote Desktop Users group manually.
Skip this step, and add users later
Does not add any users to the Remote Desktop Users group.
8.6.1.3. Joining a Server Farm

After installing XenApp on the first server in the farm (creating the farm), you can install XenApp on
other servers. When you install XenApp on other servers, you join the farm, and see a subset of the options in
the Create Farm Setup.
This topic provides information about the tasks in Join Farm Setup that differ from Create Farm Setup.
Preparation for Join Farm Setup
Before you join servers to an existing server farm, have the following information available:
The farm name.
If you are using a Microsoft SQL Server, Oracle, or IBM DB2 database on a dedicated server for the
data store, you need the logon credentials of a user authorized to access the database.
If you are using a Microsoft Access or SQL Server Express database on the first server in the farm for
the data store, you need the name of that server and the logon credentials of a user authorized to
access the database.
If you enabled IMA encryption when you created the farm, either:
Copy the key you used for the first server in the farm to a network share that you specify with
a UNC path, or
Access the key you generated when you created the farm from a portable storage device (such as
a USB flash drive).
You cannot generate a new key when joining a farm.
Citrix recommends that you delete the key from the server after you complete the installation of the farm.
Initial Setup When Joining a Farm

Until you reach the Create or Join a Server Farm page, Setup is identical to creating a farm. Install
the components and features you want on that server. Servers joining farms might not need as
many components as the first server in the farm.
On the Create or Join a Server Farm page, select Join an existing farm. The Join a Server Farm
page appears.
Configuring Zones and the Server Connection to the Farm
On the Join a Server Farm page:
1. If you have more than one zone in your farm, clear the Use default zone name check box, and
enter name of the zone where you want add the server. For environments with only one zone, leave the
1.
Use default zone name check box selected.

2. To connect to the data store directly (typically when using a Microsoft SQL Server, Oracle, or IBM
DB2 database on a dedicated server for the data store):
1. Select Connect directly to the database using ODBC
2. Select your database from the list and click Next.
3. Configure the ODBC driver associated with the database, using the instructions in the
database vendor documentation.
To connect to the data store indirectly (typically when using a Microsoft Access or Microsoft SQL
Server Express database):
1. Select Connect to a database on this server, specify the name of the server hosting
the database, and click Next. The default communication port is 2512.
2. On the Access the Database on a Citrix XenApp computer page, specify credentials for
the server to which you are connecting, and click Next.
After completing the Join a Server Farm page, either the Citrix Licensing Settings page or the
IMA Encryption Key Type page appears, depending on whether or not IMA encryption is enabled on the
farm you are joining.
Specifying the IMA Encryption Key File Location
Setup automatically detects if IMA encryption is enabled on the farm you are joining, and prompts you to
specify the location of the same key used on the first server in the farm.
To configure IMA encryption during Join Farm Setup, complete one of the following:
Add the key file to each computer before installation
Put the key file in a shared network location that is accessible by specifying a UNC path
Put the key file on a portable storage device, such as CD or USB drive that you use for every installation
Select one of the following methods of specifying the key file location:
Option
Description
Install Key From File
Select this option if you did not load a key file on this
server. Browse to the location of the key file. If the key file
is on a network location, use a UNC path to specify the location.
Use Previously Loaded Key
This option is available only if you already loaded the key

for this farm onto this server. If you loaded a valid key, the
Citrix Licensing Settings page appears.
To verify that IMA encryption is enabled and configured properly on the servers, use the CTXKEYTOOL
command with the query option, which is located in the Support folder on the installation media.
Using Farm Licensing Settings
When joining a farm, you can use the same settings as the farm or point to a different license server. On the
Citrix Licensing Settings page, select one of the following options:
Option
Description
Enter the host name for

the machine hosting your
Citrix License Server
Points to a different license server than the other servers in the farm.
Use the global farm settings for

the license server
Points to the same license server as the other servers in the farm.
Enter the correct host name later
If you do not know the license server name and port number, you
can enter this information later using the Access Management Console.
8.6.2. Upgrading or Migrating an Existing Server Farm

Depending on the previous versions of Presentation Server being used in your server farm, you may be able
to use the automatic upgrade process to move to XenApp 5 for Windows Server 2003 (Presentation Server
4.5 with Feature Pack 1), or you may need to migrate your farm.
Automatic upgrading uses Setup. When you run Setup on a server in your farm, it detects the presence
of a previous release of Presentation Server, and runs in upgrade mode. Upgrading
preserves customizations you made to each server and farm.
If your server farm currently uses Presentation Server 3.0 or 4.0 on Windows Server 2003, you
can upgrade.
When you migrate a farm, you perform a new installation of Citrix Presentation Server with Feature Pack
1, but you do so using a manual process that allows you to preserve your farm settings.
If your server farm currently uses Presentation Server 3.0 or 4.0 on Windows 2000 Server, or
earlier versions of MetaFrame, you must migrate.
For instructions and other considerations, see CTX117913.
For information about upgrading XenApp features in the XenApp 5 Feature Pack, see CTX120635.
8.6.3. Provisioning Servers and Configuring XenApp
Provisioning refers to the process of distributing XenApp software across a group of servers.
After XenApp Setup completes, you can refine the configuration of infrastructure servers and zones, and
configure application servers.
You can run scripts to perform configuration tasks such as publishing applications, setting data collector
election preferences, and applying load evaluators. You can make changes on a per-server basis, as needed.
For information about scripting, see the Citrix Developer Network.
8.6.3.1. Provisioning Farm Servers
After you install XenApp on the second server in your farm, you can provision other servers in the farm.
When provisioning farm servers, consider these methods:
Using Citrix Provisioning services - Certain XenApp editions support Citrix Provisioning services,
which streams operating systems and applications, including XenApp, to farm servers. The streamed
data is not persistent, so images must include everything you want to stream (that is, the
operating system, XenApp, published applications). For more information, see the Citrix Knowledge
Center; an implementation guide is available in CTX120513, and an integration utility in CTX116063.
Deploying Windows Installer Packages using Active Directory - You can use Active Directory to push
out Windows Installer packages to multiple servers and workstations simultaneously. You can use
XenApp transforms to select the installation options and enter data. Using Active Directory for imaging
can reduce the number of times you need to directly interact with a server during the imaging process.
You can install prerequisites (depending on the vendor for the prerequisite support), run
XenApp installation, and then install applications. You do not need to connect to the target server to
invoke the installation programs manually.
Cloning servers with preconfigured images - You can use third-party imaging programs, such as
Symantec Altiris, to create a copy of the installation and configuration of a server that joined the
farm. Then, use this image to create additional servers in the farm. This process is referred to as cloning
. You can also clone virtual machines with products such as XenServer.
Using the XenApp unattended installation - With unattended installations, you create an answer file
that specifies your configuration. You then run Setup on a system, using that answer file. This method
does not let you include prerequisites in the installation and requires more manual interaction; however,
a template is provided.
See the Custom XenApp Installation topics for more information about using Windows Installer packages
and unattended installations.
Simultaneous Installation Considerations
When you install multiple servers simultaneously, servers write configurations to the same data store
indexes. Consequently, the more servers you install simultaneously, the more likely you are to create
deadlocks on the database server.
During XenApp Setup, deadlocks can occur when one server times out while waiting to write to a piece of
data that is locked by another server. Deadlocks can cause installation to fail on some servers or cause them
to install much slower than necessary.
When installing servers simultaneously, Citrix recommends:
Server Hosting Data Store
Maximum Number of Servers to

Install Simultaneously
Dual processor or greater
30
Older server
10
Do not install multiple servers and create a zone at the same time. Create the zone first and then perform
the simultaneous installations. Having the zone in place before running simultaneous installations prevents
the new servers from being configured as the data collector.
8.6.3.2. Cloning XenApp Servers
Cloning a XenApp server involves the following:
1. Creating a template image from a configured farm server, which means removing the image identity
so that the image becomes a template you can reuse (servers have properties that contribute to
their unique identity, such as the server name, domain membership, and Security ID (SID)).
2. Distributing the image to the farm servers.
3. Recreating the unique identity of each of these servers.
Cloning techniques are used when creating a XenApp farm with provisioning technologies such as
Citrix Provisioning services or Symantec Altiris. These techniques are also used with virtualization
technologies that host XenApp, such as Citrix XenServer, the Windows Server 2008 Hyper-V feature, and
VMWare environments.
Typical candidates for cloning are servers you must repeatedly install. In small or medium farms, you might
only need to make cloned images of servers that will host published applications. In large farms, you might
also create cloned images for the Create Farm server and infrastructure servers.
When preparing a server for cloning with Citrix Provisioning services, you can include any applications and
other settings you want to appear in that image.
Although XenApp is compatible with server cloning, issues resulting from cloning software can cause the
operating system or its add-ons to function incorrectly. When cloning XenApp servers, clone one server and
check its operation in a test environment before deploying the image to the rest of the farm.
Preparing your Servers for Cloning
Before changing the SID on the server used to access the XenApp Advanced Configuration tool, add one of
the following as a Citrix Administrator with read-write privileges:
A domain administrator
The Local Administrators group
A local administrator from a server where the SID will remain static
Important: Do not create an image of a server with an SSL certificate installed; SSL certificates are unique
to the hardware.
Configuring Servers after Cloning
Zone settings are not retained when cloning a server. When the Citrix Independent Management
Architecture service on the cloned server starts for the first time, the cloned server joins the Setup default
zone. When deploying images to servers in multiple zones, assign zone information for each server after
the cloning process.
After imaging your servers, join these servers to your farm by using the CHFARM command.
8.6.3.3. To clone a server
This task requires a system preparation utility, such as Microsoft Sysprep, third-party imaging software, and
a text editor.
This task assumes you want to clone a server for the purpose of hosting published applications and that
a relational database (Oracle, SQL Server, or DB2) is hosting the data store. C is the drive on which XenApp
is installed.
If you are using Citrix Provisioning services, using the PVS PS Integration Utility can accelerate the
integration process by automating some steps.
Important: Citrix strongly recommends that you create initial images on a test farm, not in a
production environment. These instructions are for guidance only, and will vary depending on the
environment and imaging software.
Caution: The following procedure requires editing the registry. 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. After creating your farm, install XenApp on another server using Join Farm Setup, and join the farm
you created.
2. Configure the server with settings you want on all servers. (For example, you might want to
configure policies, set the data collector election preference to Not Preferred if this image will be used
for servers hosting published applications, or add printer drivers.)
3. Configure XenApp services.
Stop the Citrix MFCOM Service, and set its Startup type to Manual.
Stop the Citrix Independent Management Architecture, and set its Startup type to Manual.
Stop the Citrix WMI Service
4. Configure the registry.
1. In the registry on the server, set
HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\RUNTIME\PSRequired to 1. This key is
in HKLM\SOFTWARE\Citrix\IMA\Runtime\PSRequired on XenApp, 32-bit edition. This forces
the server to communicate with the data store so that the local host cache is updated with the
new information.
2. Delete the value for HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\ServerHost. This key is
in HKLM\SOFTWARE\Citrix\IMA\ServerHost on XenApp, 32-bit edition.
5. Delete the contents of database local persistent cache files.
1. Delete the contents of the Local Host Cache in C:\Program Files (x86)
\Citrix\Independent Management Architecture\imalhc.mdb by running dsmaint recreaterade.
2. Delete the contents of the Application Streaming Offline database cache in C:\Program Files
(x86)\Citrix\Independent Management Architecture\RadeOffline.mdb by running
dsmaint recreatelhc.
3. In mixed farm environments, if you are cloning a Presentation Server 4.5 with Feature Pack
1 server, delete the Resource Manager database cache in C:\Program Files (x86)
\Citrix\Citrix Resource Manager\LocalDB\RMLocalDatabase.mdb.
6. Remove the workstation Identification (WSID) from DSN files. Using a text editor, open the files MF20.
dsn and RadeOffline.dsn in C:\Program Files (x86)\Citrix\Independent Management Architecture,
and delete the line that specifies the WSID.
7. If you are cloning a system which might have had an older XenApp plug-in installed on it at one
time, delete the C:\WFCName.ini file. This file was created by previous versions of the XenApp hosted
plug-in.
8. Create an image of this installation using Citrix Provisioning services, Citrix XenServer, or thirdparty imaging software.
9. Deploy this image to other servers using the tools provided by the imaging software.
10. To begin initializing the cloned image, restart the server where the image was deployed.
11. Using a system preparation utility or the imaging software, assigned the cloned image a new
computer name.
12. Set HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\Logging\HostName to the new computer name. This
key is in HKLM\SOFTWARE\Citrix\IMA\Logging\HostName on XenApp, 32-bit edition.
13. Edit the CtxSta.config file to create a unique STA ID. (If you do not change this to a unique STA ID,
the Secure Gateway and other components cannot uniquely identify the new server.)
1. Using a text editor, open the CtxSta.config file in C:\Program Files (x86)\Citrix\System32.
2. Use the MAC address of the new server to which you applied the clone to create the STA ID.
Remove any colons or spaces from the MAC address and preface it with STA. (For example,
the MAC address 02-00-68-55-4D-01 becomes STA020068554D01.)
3. Enter the STA ID in the UID field in the CtxSta.config file. (For example, UID=STA020068554D01.)
14. In the Windows Services panel:
1. Set the Startup type for Citrix Independent Management Architecture and the Citrix MFCOM
service to Automatic.
2. Start the Citrix Independent Management Architecture service.
3. Start the Citrix MFCOM service.
4. Start the Citrix WMI service.
8.6.3.4. Configuring Infrastructure Servers After Setup
Although you can configure infrastructure servers when you install your initial farm components, you can
refine the configurations for certain infrastructure elements after XenApp Setup.
Configuring Data Collectors After Setup
By default, Setup configures the Create Farm server as the data collector by setting its server election
preference to Most Preferred. All servers that join the farm are set to Default Preference.
To dedicate a server as the data collector, use the XenApp Advanced Configuration tool to set it to
Most Preferred and do not use it for any other functions, including hosting published applications.
After configuring the data collector, set the election preferences of servers hosting published applications to
Not Preferred, the lowest election preference so that the possibility of those servers acting as a data collector
is low.
Configuring Zones After Setup
When configuring zones for a WAN, Citrix recommends the following:
Do not enable load balancing across zones. Use the Zone Management feature in the
Advanced Configuration tool to specify the Do not share load information option.
Direct users requests for applications to the nearest geographic location by setting up a preferred
zone connection order in the User Workspace > Connections > Zone preference and failover
policy rule. Routing users to connect to servers in their own zone can reduce traffic across high
latency connections. This feature only affects the XenApp plug-in and the Web Interface.
8.6.3.5. Configuring XenApp after Installation

After you install XenApp and configure infrastructure servers, complete the following tasks. For details, see
the XenApp administrator documentation.
1. Change essential settings, including the following:
To allow users to reconnect to sessions consistently, set the Restrict each user to a single session
option to No in the Terminal Services Configuration tool. (In Windows Server 2008, this setting
is enabled by default.)
Citrix recommends using the server and farm-wide settings in XenApp to control the number
of sessions users can launch.
2. After installing the Web Interface, use the Access Management Console or Delivery Services Console
2.
to create one or more sites, so that users can connect through the Web Interface or the XenApp plug-in.
3. Use the console to discover the servers in your farm.
4. Create administrative accounts.
5. Publish applications.
6. Perform other customization, such as setting policies, configuring printing, changing server
election settings, and configuring load balancing.
7. Create plug-in packages and deploy them to users. See the plug-in documentation for details.
8.6.4. Custom XenApp Installation
XenApp offers alternatives to the wizard-based installation. Custom installations are useful when
installing XenApp on large numbers of servers. See Custom XenApp Installations for custom installation
method descriptions.
See XenApp Windows Installer Properties Reference for information about the properties specified in
custom installations.
Custom Installations of the XenApp Management Consoles
The XenApp management consoles have their own .msi files. The .msi file referenced by Autorun cannot be
used for custom installations.
Delivery Services Console or Access Management Console - The .msi file is in Administration\console_name
\setup on the XenApp installation media. Citrix recommends running CtxInstall.exe, which installs all
of the extensions. If you install this console using another method, the extensions must be installed in
a specific sequence or installation fails. To install this console silently, run CtxInstall.exe /silent.
Advanced Configuration or Presentation Server Console - The .msi file is in Administration\console_name
\setup on the XenApp installation media. Citrix recommends running cmc.msi.
8.6.4.1. Generating an Installation Log File

Installation and uninstallation log files are not created automatically for Windows Installer packages. You
can create log files with the following methods:
Use the logging command to create log files for only the Windows Installer operations
Turn on automatic logging for all Windows Installer operations by creating a new registry string value.
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 making changes to it.
Key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer
Type
REG_SZ
Name
Logging
Value data
voicewarmup
A log file is created in the %Tmp% directory for each operation.

Use the Active Directory Group Policy Editor to configure logging properties for an Active Directory
group. To edit the Logging policy, open the Group Policy Editor and select Computer Configuration
> Administrative Templates > Windows Components > Windows Installer.
8.6.4.2. Preparing for Custom XenApp Installations

Updated: 2010-03-02
Generally, preparing for a custom installation is the same as preparing for a wizard-based installation; see
Preparing Your Environment. There are several exceptions and considerations.
Prerequisites that are automatically installed during a wizard-based Setup are not installed during a
custom installation. Therefore, install all prerequisites.
A wizard-based Setup includes automatic installation of a XenApp plug-in by default. For a custom
installation, install the plug-in before you install XenApp; otherwise, functionality such as passthrough authentication and shadowing might not work correctly.
The Citrix online plug-in installation packages,CitrixOnlinePluginFull.exe and CitrixOnlinePluginWeb.exe,
are in the Online Plug-in folder in the installation media. You can install the online plug-in, the online
plug-in web, or a combination. Install the online plug-in web package if you are configuring the
Web Interface on the server.
Citrix recommends also installing the Citrix offline plug-in, CitrixOfflinePlugin.exe, which is in the
Offline Plug-in folder in the installation media.
Important: If you are upgrading plug-ins/clients on the server, uninstall all previous versions, including
offline plug-ins, and then install the new plug-ins.
8.6.4.3. Installing XenApp by Modifying Windows Installer Packages
XenApp and several of its components and features are compiled into a Windows Installer package (.msi)
file. Windows Installer technology comprises the Windows Installer Service for the Windows operating
systems and the package .msi file format used to hold information about the application setup. The
XenApp Windows Installer package, mps.msi, is located in the XenApp Server folder in the XenApp
installation media.
If you encounter problems when running a Windows Installer package, check the Windows Event Viewer.
Also check the Application Log for entries in the Source column of type MSIInstaller.
Using the Windows Installer msiexec Command
Use the msiexec command to install, modify, and perform operations on Windows Installer (.msi) packages
from the command line. Set properties by adding Property=value after other switches and parameters.
The following sample command line installs the XenApp Windows Installer package and creates a log file
to capture information about this operation. This example does not include required properties.
msiexec /i mps.msi /L*v c:\output.log

The following table lists several common options for the msiexec command.
Option
Syntax
Install or configure a product
msiexec /i {package|ProductCode}
Uninstall a product
msiexec /x {package|ProductCode}
Set a logging level (use with Install

or Uninstall option)
msiexec /L [i][w][e][a][r][u][c][m][p][v][+][!] LogFile
Install a transform (use with Install

or Uninstall option)
msiexec /i package TRANSFORMS=TransformList
Set the user interface level (use

with Install or Uninstall option)
msiexec /q {n|b|r|f}
To include the v option in a log file using the wildcard flag, type /L*v.
See the Microsoft documentation for more command information. See XenApp Windows Installer
Properties Reference for property descriptions and XenApp Windows Setup Properties Script Examples for
sample scripts.
8.6.4.4. Applying Transforms to Setup
XenApp provides four sample Windows Installer transform (.mst) files in the Support\Install directory for
XenApp Create Farm, Join Farm, and Citrix Licensing installations. Applying transforms is one method of
installing XenApp through Active Directory.
Transforms you create to customize a XenApp installation package remain cached on your system. They are
re-applied to the base installation package (mps.msi) when you install hotfixes (whenever the Installer needs
to modify mps.msi). However, you can apply transforms only when you initially install XenApp; you cannot
apply transforms to XenApp after it is installed.
To set a property in the .msi file to Null, delete the property in the transform file.
Creating a Customized Transform Using the Sample Transform
You need a third-party tool to edit Windows Installer packages.
1. Using the Windows Installer package editing tool, open the XenApp installation package (mps.msi) in
the XenApp Server\w2k8x64 and the XenApp Server\w2k8 folders of the XenApp installation media.
2. Apply the transform that includes the properties and values you want to modify. At a command
prompt, type the following, where package is the name of the XenApp installation package and
TransformList is the list of the transforms you want to apply (separate multiple transforms with
a semicolon):
msiexec /i package TRANSFORMS=TransformList
3. Enter new values for the properties you want to change.
4. Generate the transform file and save it with a new name.
Sample Transforms
Sample transforms are provided in the Support\Install folder of the XenApp installation media.
thirdpartydb_create_direct.mst
Creates a new XenApp farm that uses an enterprise database

(Microsoft SQL Server, Oracle, or IBM DB2) for the data store on
a separate dedicated server. The database is configured for
direct access.
thirdpartydb_join_direct.mst
Joins an existing XenApp farm that uses an enterprise database for

the data store on a separate dedicated server. The new server
joining the farm accesses the data store directly.
Localdb_access_create.mst
Creates a new XenApp farm that uses a Microsoft Access or

Microsoft SQL Server Express database for the data store.
The database is stored locally on the first server in the farm on
which XenApp is installed.
Join_Indirect.mst
Joins an existing XenApp farm that uses Microsoft Access or

Microsoft SQL Server Express for the data store. The database is
stored on one of the XenApp servers.
This transform does not enable IMA encryption. If you want to
enable IMA encryption, enable it manually after installation using
CTXKEYTOOL.
To install the Citrix License Server through Active Directory, you can use the
transform ActiveDirectoryLicensingInstallSupport.mst, which is associated with ctx_licensing.msi. For
information, see the Citrix Licensing documentation.
The following table lists the property values in the sample transforms. The columns are:
A - thirdpartydb_create_direct.mst
B - thirdpartydb_join_direct.mst
C - Localdb_access_create.mst
D - Join_Indirect.mst
An empty cell indicates that property is not included in the sample transform.
Property
CTX_MF_CREATE_FARM_DB_CHOICE
ThirdParty
Local
CTX_MF_DOMAIN_NAME
Domain1
Domain1
CTX_MF_ENABLE_VIRTUAL_SCRIPTS
CTX_MF_FARM_SELECTION
Create
Join
Yes
Yes
Create
Join
CTX_MF_INDIRECT_JOIN_DOMAIN_NAME
Domain1
CTX_MF_INDIRECT_JOIN_PASSWORD
(see note 2)
CTX_MF_INDIRECT_JOIN_USER_NAME
Administrator
CTX_MF_JOIN_FARM_DB_CHOICE
Direct
Indirect
CTX_MF_JOIN_FARM_SERVER_NAME
Server1
CTX_MF_JOIN_FARM_SERVER_PORT
2512
CTX_MF_LICENSE_SERVER_NAME
License_Server
License_Server License_Server
CTX_MF_LOCAL_DATABASE
SQLEXPRESS
CTX_MF_MSDE_INSTANCE_NAME
CITRIX_METAFRAME
License_Server
CTX_MF_NEW_FARM_NAME
Farm-ThirdParty
FarmAccess
CTX_MF_ODBC_PASSWORD
citrix
citrix
CTX_MF_ODBC_RE_ENTERED_PASSWORD
citrix
citrix
CTX_MF_ODBC_USER_NAME
sa
sa
CTX_MF_SERVER_TYPE
CTX_MF_SHADOW_PROHIBIT_NO_LOGGING
No
No
No
Yes
CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION Yes
Yes
No
No
CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA
No
No
No
No
CTX_MF_SHADOWING_CHOICE
Yes
Yes
Yes
CTX_MF_SILENT_DSNFILE
(see note 1)
(see note 1)
CTX_MF_USER_NAME
Administrator
CTX_MF_XML_CHOICE
Separate
Separate
Share
Share
CTX_MF_XML_PORT_NUMBER
180
180
80
80
Administrator
Note 1. Add this row to the transform because it is not available in the default Windows Installer package used for
mps.msi: CTX_MF_SILENT_DSNFILE=\\fileserver\image\TestSQL.DSN
Note 2. Properties for the database password are not included. If the database has a password , add this row to
the transform (if the database has a blank password, do not add the password
property): CTX_INDIRECT_JOIN_PASSWORD=Password
8.6.4.5. Performing an Unattended Installation with an Answer File

You can perform an unattended installation of XenApp by creating an answer file to respond to XenApp
Setup prompts. A sample answer file is provided, with instructions for setup options.
You can also use the answer file to generate a Windows Installer command line with the silent option.
This command line results from running the XenApp unattended installation.
To perform an unattended installation with an answer file:
1. Copy the sample answer file (UnattendedTemplate.txt in the Support\Install directory on the
installation media) to another location.
2. The file includes definitions and possible values for each entry. Using a text editor, enter values for
entries you want to set, then save the file.
3.
3. At a command prompt, type the following, where path-to-mps.msi is the full path to your
XenApp installation, and answer_file.txt is the name of the text file you created and edited in the
previous steps.
UnattendedInstall.exe <path-to-mps.msi> <answer_file.txt> [MSIPROPERTY1=VALUE1] ... [
MSIPROPERTYN=VALUEN]
Note: Passwords are not stored in the answer file; they must be provided on the command line when
you invoke UnattendedInstall.exe. The sample file contains password command-line options.
The following example command includes the ODBC password.
c:\XenApp\UnattendedInstall.exe "c:\Setup\MPS.msi"
c:\cps\x32ORCL10-1.txt CTX_ODBC_PASSWORD="password"
CTX_MF_ADD_LOCAL_ADMIN=Yes
The following example command includes the indirect join password.
c:\XenApp\UnattendedInstall.exe "c:\Setup\MPS.msi"
c:\cps\x32Access-2All.txt
CTX_INDIRECT_JOIN_PASSWORD="password"
CTX_MF_ADD_LOCAL_ADMIN=Yes
For property descriptions, see XenApp Windows Installer Properties Reference.
8.6.5. XenApp Windows Installer Properties Reference
Updated: 2009-10-16
For custom XenApp installations, XenApp Setup properties are used with Windows Installer (msiexec)
commands and transforms.
Some values, such as passwords, may be case-sensitive.
When performing an unattended install (UnattendedInstall.exe), use Setup properties in the command
line to specify user credentials; these are not included in the XenApp answer file. You can also use
the command line to specify other Setup properties, such as installation directories.
When using Setup properties in a command line as part of an unattended installation, enclose values
that include spaces in quotation marks (""). If you use quotation marks when running Setup properties
in the command line, set them explicitly by prefacing them with the escape character (\). For example, use
INSTALLDIR=\"C:\Program Files\Citrix\" instead of INSTALLDIR="C:\Program Files\Citrix".
Setup properties for XenApp features, technologies, and plug-ins are described, when available, in
their documentation.
See the licensing documentation for Windows Installer commands for Citrix Licensing.
The management consoles have their own .msi files; they are not specified using Windows Setup
properties as part of XenApp installation. For more information, see Custom Installations of the
XenApp Management Consoles.
8.6.5.1. XenApp Setup Properties for Create Farm and Join Farm
The following table indicates the properties used for the Create Farm and Join Farm installations.
For an Unattended Installation, values are provided with a different syntax from Windows Installer
commands; equivalent parameters are provided in the table.
Unless otherwise noted, the property is supported on XenApp 5 for Windows Server 2003 and XenApp 5
for Windows Server 2008 installations. The property descriptions indicate valid and default values.
Property
Create Farm
Join Farm
Unattended
Installation Equivalent
CTX_ADDLOCAL
CTX_CONFIGMGR_USER
CTX_CONFIGMGR_USER_PASSWORD
CTX_CPSVC_SERVICE_USER_NAME
CTX_CPSVC_SERVICE_USER_PASSWORD
CTX_IGNORE_MCM *
CTX_IMA_PROTECTION_ENABLE
X **
CTX_MALOO_SERVICE_USER
CTX_MALOO_SERVICE_USER_PASSWORD
CTX_MF_ADD_ANON_USERS
CTX_MF_ADD_LOCAL_ADMIN
CTX_MF_CREATE_FARM_DB_CHOICE
CTX_MF_CREATE_REMOTE_DESKTOP_USERS
CTX_MF_DOMAIN_NAME
CTX_MF_ENABLE_VIRTUAL_SCRIPTS
EnableVirtualScripts
CTX_MF_FARM_SELECTION
CreateFarm
CTX_MF_INDIRECT_JOIN_DOMAIN_NAME
DomainName
CTX_MF_INDIRECT_JOIN_PASSWORD
CTX_MF_INDIRECT_JOIN_USER_NAME
UserName
CTX_MF_JOIN_FARM_DB_CHOICE
DirectConnect
CTX_MF_JOIN_FARM_SERVER_NAME
IndirectServerName
CTX_MF_JOIN_FARM_SERVER_PORT
IndirectServerPort
CTX_MF_LIC_CHOICE_FOR_CREATE
DirectConnect
FarmAdministratorDomain
CTX_MF_LIC_CHOICE_FOR_JOIN_OR_UPGRADE
EncryptionEnable
LicenseServerChoice
X
LicenseServerChoice
CTX_MF_LICENSE_SERVER_NAME
LicenseServerName
CTX_MF_LICENSE_SERVER_PORT
LicenseServerPort
CTX_MF_LICENSE_SERVER_PORT_DEFAULT
LicenseServerPortDefault
CTX_MF_LOCAL_DATABASE
LocalDBType
CTX_MF_MSDE_INSTANCE_NAME
InstanceName
CTX_MF_NEW_FARM_NAME
CTX_MF_ODBC_DRIVER
CTX_MF_ODBC_PASSWORD
CTX_MF_ODBC_USER_NAME
CTX_MF_ONLY_LAUNCH_PUBLISHED_APPS
CTX_MF_SERVER_TYPE
ServerType
CTX_MF_SHADOW_PROHIBIT_NO_LOGGING
ProhibitLoggingOff
CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION
ProhibitNotificationOff
CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA
ProhibitRemoteControl
CTX_MF_SHADOWING_CHOICE
AllowShadowing
CTX_MF_SILENT_DSNFILE
CTX_MF_USER_NAME
FarmName
X
X
UserName
DSNFilePath
FarmAdministratorUsername
CTX_MF_XML_CHOICE
ExtendIIS
CTX_MF_XML_PORT_NUMBER
DedicatedPortNumber
CTX_MF_ZONE_NAME
CTX_PROTECT_KEY_PATH
ZoneName
KeyPath
KeyType
CTX_PROTECT_KEY_TYPE
CTX_PROTECT_NEW_KEY_PATH
NewKeyPath
CTX_RDP_DISABLE_PROMPT_FOR_PASSWORD
DisableRDPPromptForPassword
CTX_REMOVE_WI_TURNKEY *
CTX_SERV_MALOO_LOGON *
CTX_SERV_PRINTER_LOGON *
CTX_USE_EXISTING_JRE *
INSTALLDIR
REBOOT
REINSTALLMODE
* This property is valid only on XenApp for Windows Server 2003 installations.
** This property is valid when creating a farm with a XenApp 5 for Windows Server 2003 installation. It is
valid when creating or joining a farm with a XenApp 5 for Windows Server 2008 installation.
8.6.5.1.1. CTX_ADDLOCAL
Updated: 2011-03-16
Specifies one or more XenApp features to install. The features must be installed locally. Separate multiple
values with commas. (This property is similar to the Windows Installer ADDLOCAL property.)
For XenApp 5 for Windows Server 2008 installations, this property does not provide values for installing
the Access Management Console or XenApp Advanced Configuration. For XenApp 5 for Windows Server
2003 installations, this property does not provide a value for installing XenApp Advanced Configuration.
Valid values
See tables below for valid values in XenApp 5 for Windows Server 2008 and
XenApp 5 for Windows Server 2003 installations.
Default value
Blank
Installation type
Create Farm, Join Farm
The following table lists valid values for XenApp for Windows Server 2008 installations.
Description
Blank
(default)
All
Installs all XenApp features and components
CTX_MF_MetaFrame_Core
Installs only the XenApp core server software
CTX_MF_LM
Installs the Load Manager
WMI
Installs the XenApp Provider
CTX_MF_IMA_Core
Installs the Citrix Independent Management

Architecture service
CTX_MF_CTXCPU
Installs the Citrix CPU Utilization Management feature
CTX_MF_CTXSFO
Installs the Memory Optimization Management feature
CSS_SS
Installs support for application streaming

Caution: Do not specify CSS_SS value if you have
an Advanced Edition license. Specifying this property
can cause issues after Setup when applying hotfixes.
The following table lists valid values for XenApp for Windows Server 2003 installations.
Important:
For readability, the table contains spaces between multiple values. When entering multiple values,
do not use spaces.
@Core is a placeholder and should not actually be used in the command.
Value(s)
Description
Blank
(default)
All
Installs all XenApp features and components
MetaFrame_XP,
CTX_MF_MetaFrame_Core,
CTX_MF_IMA_Core,
CTX_MF_ICA_Shell_Editor,
CTX_SMA, CTX_MF_CTXCPU, CTX_MF_CTXSFO
Installs only the core server software, required for

any configuration (referred to below as @Core)
PN, PN_ENGINE
Installs the full Program Neighborhood client as

the passthrough client (referred to below as PN)
PN_AGENT, PN_ENGINE
Installs the Program Neighborhood Agent as

the passthrough client
CTX_MF_CMC,
CTX_MF_IM_Plugin, CTX_MF_RM_Plugin
Installs the Advanced Configuration (referred to below

as @CMC)
CTX_MF_IM_Service
Installs the Installation Manager installer service
CTX_MF_IM_Packager
Installs the Installation Manager packager
CTX_MF_IM,
CTX_MF_IM_Service, CTX_MF_IM_Packager
Installs all Installation Manager components (referred

to below as @IM)
CTX_MF_RM
Installs the Resource Manager
@Core, CTX_MF_LM, WMI, @CMC, PN,

@IM, CTX_MF_RM, CTX_MF_ASCII
Installs default Enterprise or Platinum Edition components
@Core, CTX_MF_LM, @CMC, PN
Installs default Advanced Edition components
8.6.5.1.2. CTX_CONFIGMGR_USER
Defines the account for Configuration Manager for the Web Interface Service. If this property is not specified,
the service is installed with the default local user account (Ctx_ConfigMgr). You can change this to run under
a different account by using this property with CTX_CONFIGMGR_USER_PASSWORD.
To specify a domain account for a service, log on to the server on which you are running Setup as a
domain administrator of the domain on which you want to run the server.
To specify another account to use for Setup, specify the following privileges when you create the account: Log
on as a service (SeServiceLogonRight) and Log on as a batch job (LogonAsBatch). Without these
privileges, the Configuration Manager for the Web Interface Service service will not start.
Format
Domain\Username
Valid values
User defined
Default value
Ctx_ConfigMgr
Installation type Create Farm, Join Farm

8.6.5.1.3. CTX_CONFIGMGR_USER_PASSWORD
Specifies the password for the Configuration Manager for the Web Interface Service. Use
with CTX_CONFIGMGR_USER.
Valid values
User defined

8.6.5.1.4. CTX_CPSVC_SERVICE_USER_NAME
Specifies a different user account for the Citrix Print Manager Service. If this property is not specified, the
service is installed under the account ctx_cpsvcuser. To change the account, specify this property with a
value representing the account you already created, and specify the password
with CTX_CPSVC_SERVICE_USER_PASSWORD.
on as a service (SeServiceLogonRight) and Log on as a batch job (LogonAsBatch). Without these
privileges, the Citrix Print Manager Service will not start.
Note: The Citrix Print Manager Service now uses the ctx_cpsvcuser account instead of the
Ctx_SmaUser account, which the service used in Presentation Server 4.0.
Format
Domain\Username
Valid values
User defined
Default value
ctx_cpsvcuser

8.6.5.1.5. CTX_CPSVC_SERVICE_USER_PASSWORD
Specifies the password for the Citrix Print Manager Service.
Specifying this property without specifying CTX_CPSVC_SERVICE_USER_NAME installs the service
under the default account (ctx_cpsvcuser) and changes the password.
Specifying this property with CTX_CPSVC_SERVICE_USER_NAME changes the user name and password
for this account.
Valid values
User defined

8.6.5.1.6. CTX_IGNORE_MCM
Note: This property is valid only on XenApp 5 for Windows Server 2003 installations.
This XenApp release is not compatible with Conferencing Manager 2.0. If you upgrade to this XenApp
version before upgrading Conferencing Manager, Conferencing Manager fails on this server. Therefore,
upgrade Conferencing Manager before upgrading to this version of XenApp. The latest version of
Conferencing Manager is available on the installation media.
If the installer detects Conferencing Manager 2.0 on the server, an error message appears. When you set
this property value to Yes, the installer ignores the error message and continues the installation.
Valid values
Yes
No
Default value
No

8.6.5.1.7. CTX_IMA_PROTECTION_ENABLE
Enables or disables IMA encryption.
Valid values
1 - enables IMA encryption; use with CTX_PROTECT_KEY_TYPE

0 - disables IMA encryption
Default value
Installation type
0
XenApp 5 for Windows Server 2003: Create Farm
XenApp 5 for Windows Server 2003: Create Farm, Join Farm
8.6.5.1.8. CTX_MALOO_SERVICE_USER
Specifies a different user account for the CPU Utilization Mgmt/CPU Rebalancer service. If this property is
not specified, the service is installed under the ctx_cpuuser account. To change the account, specify this
property with a value representing the account you already created, and specify the password
with CTX_MALOO_SERVICE_USER_PASSWORD.
This service is only installed on servers with multiple processors.
on as a service (SeServiceLogonRight), Log on as a batch job (LogonAsBatch), Debug programs
(SeDebugPrivilege), and Increase scheduling priority (SeIncrementBasePriorityPrivilege). Without
these privileges, the CPU Utilization Mgmt/CPU Rebalancer service will not start.
Format
Domain\Username
Valid values
User defined
Default value
ctx_cpuuser

8.6.5.1.9. CTX_MALOO_SERVICE_USER_PASSWORD
Specifies the password for the Citrix CPU Utilization Mgmt/CPU Rebalancer service.
Specifying this property without specifying CTX_MALOO_SERVICE_USER installs the service using
the default value for the CTX_MALOO_SERVICE_USER property (ctx_cpuuser) as the user name,
and changes the password.
Specifying this property with CTX_MALOO_SERVICE_USER changes the user name and password for
this account.
Valid values
User defined

8.6.5.1.10. CTX_MF_ADD_ANON_USERS
Specifies whether or not anonymous users can connect remotely.

Valid values
Yes
If CTX_MF_CREATE_REMOTE_DESKTOP_USERS is set to CopyUsers
or DoNothing, anonymous users are added to the Remote
Desktop Users group in Windows Server
If CTX_MF_CREATE_REMOTE_DESKTOP_USERS is set to
AddEveryone, this property is ignored because the Remote
Desktop Users group is configured so that every user in the Users
group is also a remote desktop user
No - prohibits anonymous connections to XenApp
Default value
Yes
Installation type
8.6.5.1.11. CTX_MF_ADD_LOCAL_ADMIN
Enables or disables the creation of Citrix administrator accounts for all user accounts in the local
Administrators group.
Valid values
Yes
No
Default value
No
Installation type Create Farm

8.6.5.1.12. CTX_MF_CREATE_FARM_DB_CHOICE
Specifies whether the database is a local database stored on the first server in the farm or an enterprise
(third-party) database stored on a separate server.
Valid values
Local Microsoft Access or Microsoft SQL Server Express. (Use with

CTX_MF_LOCAL_DATABASE and, if using Microsoft SQL Server Express,
CTX_MF_MSDE_INSTANCE_NAME.)
Third Party Microsoft SQL Server, Oracle, or IBM DB2. (Use with
CTX_MF_ODBC_USER_NAME and CTX_MF_ODBC_PASSWORD.)
Default value
Local
Installation type
8.6.5.1.13. CTX_MF_CREATE_REMOTE_DESKTOP_USERS
Determines whether or not to add users to the Windows Remote Desktop Users group if the accounts are
already created on the system. Users must be members of the Remote Desktop Users group to log on remotely
to a Windows Server system.
Setting this property has no effect if the Remote Desktop Users group already has members.
Note: This property takes precedence over CTX_MF_ADD_ANON_USERS. If this property is set
to AddEveryone and CTX_MF_ADD_ANON_USERS is set to No, anonymous connections to XenApp
are enabled on this server.
Valid values
AddEveryone Adds the Authenticated Users group to the Remote
Desktop Users group. All current members of the Users group are allowed
to log on remotely to the server, and whenever you add a user to the
Users group, XenApp automatically adds the user to Remote Desktop
Users group.
CopyUsers Copies all current users from the Users group to the
Remote Desktop Users group. After Setup, any user accounts you add must
be added manually to the Remote Desktop Users group.
DoNothing Does not add any users to the Remote Desktop Users group.
No users will be allowed to log on remotely to the server until you add users
to the Remote Desktop Users group in Windows Server.
Default value
CopyUsers
Installation type
8.6.5.1.14. CTX_MF_DOMAIN_NAME
Specifies the domain name for the first Citrix administrator account you create in the farm.
Valid values
User defined
Default value
DomainName

8.6.5.1.15. CTX_MF_ENABLE_VIRTUAL_SCRIPTS
Updated: 2009-09-25
Enables or disables port sharing with IIS during Setup. This property directs XenApp Setup to create the
virtual scripts directory, which is required for IIS.
If you are running a silent installation and this property is not set to Yes or 1 and the XML port on the
server is shared with IIS (for example, if you are installing the Web Interface on the same server as
XenApp), Setup fails and the following error message is added to the installation log file:
ERROR: SetIISScriptsDir - Could not get the scripts path because the Virtual Scripts directory in not enabled
in IIS or the property CTX_MF_ENABLE_VIRTUAL_SCRIPTS is not set to Yes.
If the property is defined, the silent installation continues with no error.
Valid values
Yes or 1 Creates the virtual scripts directory if it does not already

exist. Setup does not prompt you to create the virtual scripts directory, even
if you are running Setup in wizard-based mode.
Not defined, 0, or No Does not create the virtual scripts directory if it
does not already exist. You are prompted during Setup to create the
virtual scripts directory.
Default value
Not defined
Installation type
8.6.5.1.16. CTX_MF_FARM_SELECTION
Specifies whether you are creating a new server farm or joining an existing farm. If this server is joining
an existing farm, you must also set CTX_MF_JOIN_FARM_DB_CHOICE.
Valid values
Create
Join
Default value
Create

8.6.5.1.17. CTX_MF_INDIRECT_JOIN_DOMAIN_NAME
Specifies the domain name of a user account that has full administrative rights in XenApp. Use this property
if you are joining a farm that uses a Microsoft Access or Microsoft SQL Server Express database stored locally
on the first server in the farm (indirect connection).
Valid values
Any domain in which the user account has full administrative rights on the
XenApp farm
Default value
DomainName
Installation type
Join Farm
8.6.5.1.18. CTX_MF_INDIRECT_JOIN_PASSWORD
Specifies the password for a user account that has full administrative rights in XenApp. Use this property if
you are joining a farm that uses a Microsoft Access or Microsoft SQL Server Express database stored locally
on the first server in the farm (indirect access).
Valid values
Password for the user name specified in CTX_MF_INDIRECT_JOIN_USER_NAME
Default value
(null)
Installation type
Join Farm
8.6.5.1.19. CTX_MF_INDIRECT_JOIN_USER_NAME
Specifies the user name for an account that has full administrative rights in XenApp. Use this property if you
are joining a farm that uses a Microsoft Access or Microsoft SQL Server Express database stored locally on
the first server in the farm (indirect connection).
Valid values
Any user account that has full administrative rights on the XenApp farm (ideally,
the same account used to create the farm)
Default value
Administrator
Installation type
Join Farm
8.6.5.1.20. CTX_MF_JOIN_FARM_DB_CHOICE
Specifies whether the existing farm connects directly or indirectly to the data store.
Valid values
Direct Set this value if you are using a Microsoft SQL, Oracle, or IBM
DB2 database stored on a separate, dedicated database server.
Indirect Set this value if you are using a Microsoft Access or Microsoft
SQL Server Express database stored locally on the first server in the farm
on which you installed XenApp.
Default value
Direct
Installation type
Join Farm
8.6.5.1.21. CTX_MF_JOIN_FARM_SERVER_NAME
Specifies the name of the first server in the farm that you want to join.
Valid values
The name of a server hosting the Microsoft Access or Microsoft SQL Server
Express database as the data store
Default value
ServerName
Installation type
Join Farm
8.6.5.1.22. CTX_MF_JOIN_FARM_SERVER_PORT
Specifies the IMA communication port number used to communicate with the farm data store. This
property applies if you are using a Microsoft Access or Microsoft SQL Server Express database stored locally
on the first server in the farm on which you installed XenApp.
Valid values
User defined
Default value
2512
Installation type Join Farm

8.6.5.1.23. CTX_MF_LIC_CHOICE_FOR_CREATE
Configures the server to point to an existing Citrix License Server when creating a farm. If set to Point,
ensure that CTX_MF_LICENSE_SERVER_NAME points to a valid license server. If you plan to install the
license server after installing XenApp, set CTX_MF_LIC_CHOICE_FOR_CREATE to DontKnow.
Note: You can also configure the server to point to the license server after running Setup.
Valid values
Point
DontKnow
Default value
Point

8.6.5.1.24. CTX_MF_LIC_CHOICE_FOR_JOIN_OR_UPGRADE
Configures XenApp to point to an existing Citrix License Server.
If set to Point, ensure that CTX_MF_LICENSE_SERVER_NAME points to a valid license server.
If set to UseFarmSettings, ensure that the existing server farm is configured to use a license server.
Set this property to "DontKnow" if you plan to install the license server after installing XenApp.
Note: You can also configure XenApp to point to the license server after running Setup.
Valid values
Point
UseFarmSettings
DontKnow
Default value
UseFarmSettings

8.6.5.1.25. CTX_MF_LICENSE_SERVER_NAME
Specifies the license server the XenApp server uses. This applies only:
When performing a new installation when joining an existing server farm and
CTX_MF_LIC_CHOICE_FOR_JOIN_OR_UPGRADE is set to Point
When performing a new installation while creating a new server farm and
CTX_MF_LIC_CHOICE_FOR_CREATE is set to Point
Valid values
User defined
Default value
localhost

8.6.5.1.26. CTX_MF_LICENSE_SERVER_PORT
Specifies a different port number (other than the default 27000) to use when communicating with the
Citrix License Server. The value must match the port number configured on the license server. Use with
CTX_MF_LICENSE_SEVER_PORT_DEFAULT set to (null).
Valid values
An integer representing the port number through which the license server listens
for requests
Default value
27000
Installation type
8.6.5.1.27. CTX_MF_LICENSE_SERVER_PORT_DEFAULT
Controls whether XenApp communicates with the license server through the license server default port (27000).
Valid values
1 XenApp uses the default port number, 27000

(null) XenApp uses the value of CTX_MF_LICENSE_SERVER_PORT as
the port number when communicating with the Citrix License Server
Default value
Installation type
8.6.5.1.28. CTX_MF_LOCAL_DATABASE
Specifies the type of local database for the farm data store.
Valid values
Access
SQL (for Microsoft SQL Server Express)
Default value
Access

8.6.5.1.29. CTX_MF_MSDE_INSTANCE_NAME
If you install the Microsoft SQL Server Express database using the batch file SetupSqlExpressForCPS.cmd,
the default instance name is CITRIX_METAFRAME. However, if you defined a different instance name, use
this property to specify that name. That is, use this property if you modified the instance name in the batch file
or did not install Microsoft SQL Server Express using the batch file.
Valid values
User defined
Default value
CITRIX_METAFRAME

8.6.5.1.30. CTX_MF_NEW_FARM_NAME
Specifies the name of the new farm. (If you are joining a farm, use CTX_MF_JOIN_FARM_SERVER_NAME.)
Valid values
User defined
Default value
NewFarmName

8.6.5.1.31. CTX_MF_ODBC_DRIVER
Specifies the ODBC driver name for the database hosting the farm data store. Use when joining a farm directly.
Valid values
The ODBC driver name such as SQL Server, Oracle in OraClient11g_home1,

or IBM DB2 ODBC DRIVER - DB2COPY1
Default value
(null)
Installation type
8.6.5.1.32. CTX_MF_ODBC_PASSWORD
Specifies the password for a directly connected database that stores the farm data store. Use with
MF_ODBC_USER_NAME.
Valid values
User defined
Default value
Password

8.6.5.1.33. CTX_MF_ODBC_USER_NAME
Specifies the user name for a directly connected database that stores the farm data store. Use with
CTX_MF_ODBC_PASSWORD.
Valid values
User defined
Default value
UserName

8.6.5.1.34. CTX_MF_ONLY_LAUNCH_PUBLISHED_APPS
By default, XenApp prohibits non-administrative users from connecting to the published desktops and the
desktop of the servers hosting XenApp. When this property is set to either Yes or (null), users can
only connect to published applications. This setting is a server setting and not farm wide. To allow users
to connect to some server desktops but not all, change this property value for those servers.
Valid values
Yes users cannot connect to published desktops or server desktops

with clients
No users can connect to published desktops or server desktops with clients
(null) users cannot connect to published desktops or server desktops
with clients
Note: If set to a value other than Yes or No:
For XenApp 5 for Windows Server 2008 installations, this
security enhancement is enabled
For XenApp 5 for WIndows Server 2003 installations, this
security enhancement is enabled for clean installs, but disabled for upgrades
Default value
(null)
Installation type
8.6.5.1.35. CTX_MF_SERVER_TYPE
Updated: 2009-09-22
Specifies the edition of XenApp to be installed.
Valid values
P Platinum Edition
E Enterprise Edition
A Advanced Edition
Default value
XenApp 5 Feature Pack 2 for Windows Server 2003 and XenApp 5 for
Windows Server 2008: none
Important: Because there is no edition type set as the default, Setup fails
if you do not set this property or leave it as (null)
XenApp 5 for Windows Server 2003: P
Installation type
Create Farm
8.6.5.1.36. CTX_MF_SHADOW_PROHIBIT_NO_LOGGING
Prohibits or allows shadow connections without logging.
Valid values
Yes prohibit
No allow
Default value
No

8.6.5.1.37. CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION
Prohibits or allows shadowing connections without user notification.
Valid values
Yes prohibit
No allow
Default value
No

8.6.5.1.38. CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA
Prohibits or allows remote control of mouse and keyboard in shadowed sessions.
Valid values
Yes prohibit
No allow
Default value
No

8.6.5.1.39. CTX_MF_SHADOWING_CHOICE
Enables or disables session shadowing.
Important: If you turn session shadowing off when you install XenApp, you cannot enable it later through
user policies or connection configuration.
Valid values
Yes turn it on
No turn it off
Default value
Yes

8.6.5.1.40. CTX_MF_SILENT_DSNFILE
Specifies the path to the Data Source Name (DSN) file used to connect to the data store when the database
is Oracle, SQL, or DB2. During a wizard-based installation, Setup creates the DSN file for you. For a
custom installation, you must create the DSN file and use this property to specify its location.
Valid values
Complete path to the DSN file
Default value
(null)

8.6.5.1.41. CTX_MF_USER_NAME
Specifies the user name for the first Citrix administrator account you create in the farm.
Valid values
User defined
Default value
UserName

8.6.5.1.42. CTX_MF_XML_CHOICE
Specifies whether Microsoft Internet Information Services (IIS) and the Citrix XML Service share the same port
on this server or use separate ports. If you do not want IIS and the Citrix XML Service to share the same port,
set the Citrix XML Service port number using CTX_MF_XML_PORT_NUMBER.
Valid values
Share share with IIS

Separate use separate port, set in CTX_MF_XML_PORT_NUMBER
Default value
Share
Installation type
Create Farm
8.6.5.1.43. CTX_MF_XML_PORT_NUMBER
Port number the Citrix XML Service will use (when you do not want the Citrix XML Service and IIS to share ports).
Valid values
User defined
Default value
80

8.6.5.1.44. CTX_MF_ZONE_NAME
Specifies the name of the zone to which the server belongs. For a Create Farm Setup, this property specifies
the name of the first zone in the farm. For a Join Farm Setup, this property specifies the name of the zone
where you want to add the server.
Valid values
Not applicable
Default value
XenApp 5 for Windows Server 2008: Default Zone

XenApp for Windows Server 2003: None; the default value is
generated programmatically, based on the server subnet address
Installation type
8.6.5.1.45. CTX_PROTECT_KEY_PATH
Specifies where a valid encryption key file is stored. Use this property with CTX_PROTECT_KEY_TYPE with a
value of file. Failure to set both key properties correctly causes XenApp Setup to not activate the
encryption settings for the current server.
Valid values
The full path where an encryption key file is stored
Default value
(null)

8.6.5.1.46. CTX_PROTECT_KEY_TYPE
Specifies how the IMA encryption key is provided.
Valid values
file Provides a path to the location where the key file resides. Use with
CTX_PROTECT_KEY_PATH.
generate Provides a writable location where the key file is stored after
Setup generates a new encryption key. Use with
CTX_PROTECT_NEW_KEY_PATH.
existing Indicates a key is already loaded on the computer; Setup will
not attempt to replace the existing key with a new key from the file.
Default value
file
Installation type
8.6.5.1.47. CTX_PROTECT_NEW_KEY_PATH
Specifies the location of the writable folder where you want the IMA encryption key file created. If the folder
is not writable, Setup fails. Use this property with CTX_PROTECT_KEY_TYPE containing a value of
generate. Failure to set both properties correctly causes XenApp Setup not to activate the encryption
settings for the current server.
Valid values
The full path where an encryption key file will be created
Default value
(null)

8.6.5.1.48. CTX_RDP_DISABLE_PROMPT_FOR_PASSWORD
Setting this property to Yes changes the security setting on the server so that passwords from users
of Microsoft Remote Desktop Web Connection software are not required. Users must still enter credentials
when logging on to the Web Interface, but can launch applications without further prompts for credentials by
the server.
Valid values
Yes
No
Default value
No

8.6.5.1.49. CTX_REMOVE_WI_TURNKEY
When upgrading from earlier versions of Presentation Server that include the Web Interface, you must
upgrade the Web Interface before upgrading Presentation Server; otherwise, the Web Interface may be
removed from the server. Set this property to Yes if you do not object to the removal of the Web Interface
from the server.
Valid values
Yes
No
Default value
No

8.6.5.1.50. CTX_SERV_MALOO_LOGON
Defines the Citrix CPU Utilization Mgmt/CPU Rebalancer Service as the CPU user rather than using the build
in accounts created by XenApp.
Format
USERID:PASSWORD:DOMAIN/MACHINENAME
Default value
ctx_cpuuser

8.6.5.1.51. CTX_SERV_PRINTER_LOGON
Defines the Citrix Print Manager Service as the printer user rather than the built in accounts created by XenApp.
Format
USERID:PASSWORD:DOMAIN/MACHINENAME
Default value
ctx_cpsvcuser

8.6.5.1.52. CTX_USE_EXISTING_JRE
Instructs the installer to accept the JRE version currently installed on the computer.
Valid values
Yes
No
Default value
No
8.6.5.1.53. INSTALLDIR
Target location for the installation.
Valid values
User defined
Default value
%Program Files%\Citrix

8.6.5.1.54. REBOOT
Specifies whether you restart a server manually or are prompted for the server to be restarted.
Note: XenApp requires that you reboot the server after running Setup.
Valid values
Force forces restart to occur; no further prompts are displayed

Suppress forces restart to not occur by default; a prompt appears if
action is necessary
ReallySuppress forces restart to not occur; no prompts appear
Default value
Force
Installation type
8.6.5.1.55. REINSTALLMODE
Specifies the type of reinstall to perform. Options are case-insensitive and order-independent.
Important: Citrix recommends that you do not modify this property.
Valid values
p install missing files

o replace older versioned or missing files
c replace corrupt files (checksum validation)
e replace same versioned or missing files
d replace files of differing versions
a replace all files regardless of version
u replace user registry settings
m replace registry settings on the server
s replace shortcuts
v replace the cached .msi package with the package currently being installed
Default value
oums
Installation type
In XenApp for Windows Server 2008 installations, this property performs the same function as the Repair
function in Control Panel > Programs and Features.
8.6.5.2. XenApp Windows Setup Properties Script Examples
Create Farm Sample Windows Installer Command Script
This sample script creates a farm using a local database (Microsoft Access) with port sharing, IMA encryption,
and shadowing enabled.
msiexec.exe /i MPS.msi /qb- /l*v C:\mps.log CTX_MF_SERVER_TYPE="P"

INSTALLDIR="C:\XenApp\" CTX_MF_FARM_SELECTION="Create"
INSTALLDIR="C:\XenApp\" CTX_MF_FARM_SELECTION="Create"
CTX_MF_CREATE_FARM_DB_CHOICE="Local" CTX_LOCAL_DATABASE="Access"
CTX_MF_NEW_FARM_NAME="NewFarmName" CTX_MF_XML_CHOICE="Share"
CTX_MF_USER_NAME="Administrator" CTX_MF_DOMAIN_NAME="DomainName"
CTX_MF_LIC_CHOICE_FOR_CREATE="Point"
CTX_MF_LICENSE_SERVER_NAME="LicenseServerName"
CTX_MF_LICENSE_SERVER_PORT_DEFAULT="1"
CTX_MF_LICENSE_SERVER_PORT="27000" CTX_IMA_PROTECTION_ENABLE="1"
CTX_PROTECT_KEY_TYPE="generate"
CTX_PROTECT_NEW_KEY_PATH="C:\KeyFile.key"
CTX_MF_SHADOWING_CHOICE="Yes"
CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION="No"
CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA="No"
CTX_MF_CREATE_REMOTE_DESKTOP_USERS="AddEveryone"
CTX_MF_ADD_ANON_USERS="Yes" CTX_MF_ENABLE_VIRTUAL_SCRIPTS="Yes"
CTX_MF_ADD_LOCAL_ADMIN="Yes" CTX_MF_ONLY_LAUNCH_PUBLISHED_APPS="No"
Join Farm Sample Windows Installer Command Script

This sample script joins a farm whose data store is hosted on a third-party, or enterprise, database (SQL
Server). The farm has IMA encryption and shadowing enabled.
msiexec /i MPS.msi /qb- /l*v C:\mps.log CTX_MF_SERVER_TYPE="E"

INSTALLDIR="C:\XenApp\" CTX_MF_FARM_SELECTION="Join"
CTX_MF_CREATE_FARM_DB_CHOICE="Thirdparty"
CTX_MF_JOIN_FARM_DB_CHOICE="Direct"
CTX_MF_ODBC_USER_NAME="DomainName\UserName"
CTX_ODBC_PASSWORD="****" CTX_MF_ODBC_RE_ENTERED_PASSWORD="****"
CTX_MF_SILENT_DSNFILE="C:\SQLWin.dsn"
CTX_MF_SELECTED_DRIVER_NAME="SQL Server"
CTX_MF_XML_CHOICE="Separate" CTX_MF_XML_PORT_NUMBER="8080"
CTX_MF_LIC_CHOICE_FOR_JOIN_OR_UPGRADE="UseFarmSettings"
CTX_IMA_PROTECTION_ENABLE="1" CTX_PROTECT_KEY_TYPE="file"
CTX_PROTECT_KEY_PATH="C:\KeyFile.key" CTX_MF_SHADOWING_CHOICE="Yes"
CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION="No"
CTX_MF_SHADOW_PROHIBIT_NO_LOGGING="No"
CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA="No"
CTX_MF_CREATE_REMOTE_DESKTOP_USERS="CopyUsers"
Citrix Licensing Sample Windows Installer Command Script

This sample script installs Citrix Licensing.
msiexec.exe /i ctx_licensing.msi
CTX_LICENSING_INSTALLDIR="C:\program files\citrix\"
CTX_LIC_FILE_PATH="C:\program files\citrix\licensing\my files\"
CTX_WEB_SERVER="IIS" CTX_LICENSE_SERVER_PORT="23456"
CTX_VENDOR_DAEMON_PORT="65432" /l*v "C:\Lic.log" /qb-
Web Interface Sample Windows Installer Command Script

This sample script installs the Web Interface.
WebInterface.exe -q -v %systemdrive%\WI.log
8.6.6. Data Store Database Reference
This section contains data store reference information, including installation requirements.
For data store planning considerations, see the XenApp planning documentation
Supported database versions are detailed in http://support.citrix.com/article/CTX114501
See the database vendor documentation before installing, configuring, and using the database software.
Important:
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.
8.6.6.1. Microsoft Access Database

The Microsoft Access database engine and ODBC drivers are default components of Windows servers. The
ODBC connection to Access uses the Microsoft Jet Engine. To use this database engine, you do not have to
install any drivers or perform any database configuration before installing XenApp.
The database has the following minimum requirements:
Approximately 50MB of disk space for every 100 servers. More disk space is needed for greater numbers
of published applications.
32MB of additional RAM if the server also hosts connections.
Changing the Password to a Microsoft Access Database File

When you create a local Microsoft Access database for the data store, Setup creates a database file named
Mf20.mdb. The default user name and password for this database file are both citrix.
The Mf20.mdb file and all automatic backup files are located by default in the %ProgramFiles
(x86)%\Citrix\Independent Management Architecture folder.
To change the password for the database file, use the dsmaint config /pwd:newpassword command. The
Citrix IMA Service can be running when you use the command.
Important: Back up the Access database using the dsmaint backup command before changing the
password used to access the database.
Backing Up and Restoring a Microsoft Access Database
Use the dsmaint command to back up or recover a Microsoft Access data store. Back up the data store
regularly with a batch file script and before activities such as changing the configuration.
Automatic backups occur each time the Citrix IMA Service is stopped or a server is restarted. During an
automatic backup, the existing Mf20.mdb file is backed up, compacted, and copied as Mf20.bak. Each time
the IMA Service starts, it deletes Mf20.bak if it exists and renames the Mf20.unk file to Mf20.bak. This
process ensures that the Mf20.bak file is a valid farm database.
If the server runs out of disk space on the drive where the Mf20.mdb file is stored, automatic backups
stop. Ensure that the amount of free disk space is at least three times the size of the Mf20.mdb file.
Caution: The dsmaint recover command removes the existing Mf20.mdb file from the server. Therefore,
do not try to recover the data store with this command without first verifying that the Mf20.bak file exists.
If the Mf20.bak file does not exist, run dsmaint backup prior to recovering the data store.
For more information, see Maintaining and Recovering a XenApp Data Store.
8.6.6.2. Microsoft SQL Server Express Database
Windows authentication is supported for the SQL Server Express database. For security reasons, Microsoft
SQL Server authentication is not supported.
Installing Microsoft SQL Server Express
Install SQL Server Express on the server before running XenApp Setup.
The server hosting the database should meet the following requirements:
Approximately 50MB of disk space for every 100 servers and 25 applications in the farm
32MB of additional RAM if the server also hosts connections

70MB of disk space for the database
Important: Do not use double-byte characters in the name of the server on which the database is
installed. You must reboot the system after installing the database software, before installing Citrix XenApp.
There are two methods for installing Microsoft SQL Server Express:
If you do not have an instance of SQL Server Express already installed on the database server and
you want to use the default instance name (CITRIX_METAFRAME) and system administrator
password (CITRIX):
Run the SetupSqlExpressForCPS.cmd batch file, which is on the XenApp installation media in
the \Support\SqlExpress_2005_SPx directory.
The required files and directories are created in the %ProgramFiles(x86)%\Microsoft SQL Server
directory and the named instance directory MSSQL$CITRIX_METAFRAME.
If you cannot or do not want to use the default instance name and administrator password:
1. At a command prompt, change to the \Support\SqlExpress_2005_SPx directory on the
XenApp installation media. (For example, if your media drive is E, type: E:
cd \Support\SqlExpress_2005_SPx, where x is the Service Pack number.)
2. Change to installation mode by typing change user /INSTALL.
3. Launch the SQL Server 2005 Express Edition Service Pack installer, specifying the instance
name and system administrator password: setup.exe INSTANCENAME=name SAPWD=password
Important: If you install SQL Server Express with a nondefault instance name , you must install
XenApp using a manual installation method so that you can specify the new instance name with
the XenApp Setup property CTX_MF_MSDE_INSTANCE_NAME.
Backing Up and Restoring a Microsoft SQL Server Express Database

Use dsmaint backup to back up a data store hosted on SQL Server Express. Specify a local path for the
location of the database backup files. Use dsmaint recover to restore a back up copy of a SQL Server
Express data store.
Note: If you are moving a SQL Server Express data store to a different server in the farm, perform
dsmaint failover on all indirect servers to point them to the new database server.
8.6.6.3. Microsoft SQL Server Database
The server hosting the SQL Server database should meet the following minimum requirements:
Approximately 100MB of disk space for every 250 servers and 50 published applications in the farm.
More disk space is needed 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.
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. This increases the security of the database.
If you change the rights from database owner to read/write, change the rights back to database owner
before installing service packs or feature releases. Those installations can fail if the user account you use
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.
During database installation, the default settings and database sizes usually suffice for XenApp data store needs.
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).
Using Sockets to Connect to a Microsoft SQL Server Database
Two common 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 running SQL Server and the server running XenApp do not have the
correct domain or Active Directory trust relationship. Therefore, Citrix recommends that you use TCP/IP
sockets to connect servers running XenApp to a server hosting Microsoft SQL Server.
If you are running Microsoft SQL Server and configure named pipes to establish a connection to the
database, manually enable the named pipes option on the database server. To enable named pipes, use
the Surface Area Configuration tool packaged with SQL Server. For additional information, see the SQL
Server documentation.
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) you created during installation 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.
A Microsoft Cluster Services cluster group is a collection of resources such as disk drives, that are owned by
one of the failover cluster nodes. You can transfer the ownership of the group from one node to another, but
each group can be owned by only one node at a time.
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. Because the new
node already has the executable files and registry information for that instance of Microsoft SQL Server on
its local disk drive, it can start up an instance of Microsoft SQL Server and start accepting connection requests
for that instance.
Note: 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. See the Microsoft SQL Server documentation for more information.
Caution: To avoid corruption, do not use merged replication.
To set up a distributed environment for an existing 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.
8.6.6.4. Oracle Database
The server hosting the Oracle database should meet the following minimum requirements:
Approximately 100MB of disk space for every 250 servers and 50 published applications in the farm.
More disk space is needed for greater numbers of published applications.
20 MB minimum tablespace size.
Oracle supports Windows and Oracle authentication. See the Oracle documentation for information
about configuring Windows 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.
Install the Oracle client on the server and then reboot the server before you install XenApp.
The Oracle user account must be the same for every server in the farm because all servers running XenApp
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:
Connect
Resource
Unlimited Tablespace (optional)
Important:
Do not install Citrix XenApp on the server hosting an Oracle database.
Consider the following guidelines when configuring an Oracle server to host the farm data store.
Use Shared/Multi-Threaded Server mode to reduce the number of processes in farms with more than
100 servers. However, 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 values shown here. If you are running multiple farms on the same Oracle database, include
all servers running XenApp in the calculations. Round up fractional values.
shared_servers = Number of servers / 10
max_shared_servers = Number of servers / 5
Where Number of servers is the total number of servers running XenApp.

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.
Using Failover with 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. See the Oracle documentation for setup instructions.
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:
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 (servers running XenApp 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 user
s schema are successfully replicated.
When configuring Oracle for a two-phase commit:
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.
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.
8.6.6.5. IBM DB2 Database

When you install the database, Citrix recommends the following settings:
Prefetch Size = 32
Overhead = 8.3
Transfer = 0.18
Use the 'grant all' option for the selected tablespace
User privileges should be 'grant all' to the public group
If you have multiple farms, create a separate database/tablespace for each farm data store.
Approximately 100MB of disk space is required for every 250 servers and 50 published applications in the
farm. More disk space is required for larger numbers of published applications.
Install the IBM DB2 Run-Time Client on each server accessing the database server. Restart the server after
you install the IBM DB2 Run-Time client and before you install XenApp.
If you create a data source name (DSN) for use with an unattended installation of IBM DB2, create the DSN
using the Microsoft ODBC Data Source Administration page. Doing so ensures that the DSN is populated
according to server requirements for proper connectivity to the DB2 database or tablespace.
Give the following permissions to the IBM DB2 user account for the farm:
Connect database
Create tables
Register functions to execute to database managers process
Create schemas implicitly
System administrator (DB2Admin) account permissions are not needed for data store access.
Important:
Do not install Citrix XenApp on the server hosting an IBM DB2 database.
When migrating a farm data store to an IBM DB2 database, the migration is completed as a single transaction
for roll-back purposes. Before migrating the database, verify that the target IBM DB2 server has sufficient
log space to support the migration. If the DB2 server runs out of log space, the migration fails and rolls back
Using Distributed Databases with IBM DB2
IBM DB2 uses replication to create the distributed database environment.
XenApp uses the data type of binary large object (BLOB) to store information in an IBM DB2 database. IBM
DB2 does not support the use of BLOB data types in a replication scenario that can be updated. Therefore, if
your farm requires replicas that can be updated, use Microsoft SQL Server or Oracle for the farm data
store instead of IBM DB2.
8.6.6.6. Creating a DSN File for XenApp Setup
If you do not use the wizard-based Setup to install XenApp and your data store is on an Oracle, Microsoft
SQL Server, SQL Microsoft SQL Server Express, or IBM DB2 database, create a Data Source Name (DSN)
file before running Setup to configure the XenApp connection to the data store.
The DSN file must be on each server in the farm. You can create the file once 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 CTX_MF_SILENT_DSNFILE Setup property to specify the file location during Setup.
You can use DSN files during a wizard-based Setup if you specify them when you configure the ODBC driver.
That occurs after completing the Create a Server Farm or Join a Server Farm pages in Setup.
8.6.6.7. Maintaining and Recovering a XenApp Data Store
Most database maintenance requires running the dsmaint and dscheck commands. (The XenApp
Commands Reference documentation contains syntax and use details. You can also display information from
a command prompt on a XenApp server by typing the command name and /?.)
For example, use dsmaint to:
Upgrade the XenApp data store
Move the data in the data store to a different database server

Migrate the data store from a Microsoft Access database to a Microsoft SQL Server database
Change the name of the DSN file
With the exception of Microsoft Access, dsmaint is run on XenApp farm servers and not the database
server. Many dsmaint parameters affect how XenApp connects to the data store, although some affect the
data store.
Citrix strongly recommends creating a backup copy of the data store (dsmaint backup). Without a backup,
you must manually recreate all of the farm policies, settings, accounts, and other persistent data in the data store.
If the data store fails, each farm server can run off 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
Access Management Console or the XenApp Advanced Configuration tool.
To restore a backup database or migrate to a new server, use the dsmaint migrate command. Without
a backup, prepare a new data store the way you did before running XenApp Setup and run chfarm from any
farm server. Using chfarm is equivalent to running XenApp Setup to configure the data store. After running
chfarm, 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.
8.6.6.8. Migrating a Farm Data Store
Updated: 2009-09-23
Migrating a XenApp 5 farm data store is supported for certain versions, as listed below. For
comprehensive version information, see CTX114501. Data store migration uses the DSMAINT command; see
DSMAINT.
Migrating a Farm Data Store from Microsoft Access to Microsoft SQL Server Express
Run the MigrateToSqlExpress utility, which is located in the Support\SqlExpress_2005_SPx directory of
the installation media (where x is the Service Pack number supported by the XenApp release). For
more information, see MIGRATETOSQLEXPRESS.
Migrating a Farm Data Store from MSDE to Microsoft SQL Server Express
Microsoft SQL Server Desktop Engine (MSDE) is not supported for use as a data store on XenApp 5. For
migration information, see Migrating a Farm Data Store from MSDE to SQL Server Express.
Migrating a Farm Data Store to Microsoft SQL Server
For XenApp 5 for Windows Server 2003, migrating a farm data store to a Microsoft SQL Server database
is supported for the versions listed in the following table.
Original database
Supported target database
Microsoft Access
Microsoft SQL Server 2000 SP 3a
Oracle 9.2.0.1
Oracle 10.2.0.1.0
IBM DB2 8.2
Microsoft Access
SQL Server 2005 Express Edition
Oracle 9.2.0.1
Oracle 10.2.0.1.0
IBM DB2 8.2
Microsoft SQL Server 2005
For XenApp 5 for Windows Server 2008, migrating a farm data store to a Microsoft SQL Server database
is supported for the versions listed in the following table.
Original database
Microsoft Access
Microsoft SQL Server 2005 SP2
Oracle 10.2.0.3
Oracle 11.1
IBM DB2 8.2
IBM DB2 9.5
Migrating a Farm Data Store to Oracle

For XenApp 5 for Windows Server 2003, migrating a farm data store to an Oracle database is supported for
the versions listed in the following table.
Original database
Microsoft Access *
Oracle 9.2.0.1
Microsoft SQL Server 2005 Express Edition Oracle 10.2.0.1.0

IBM DB2 8.2
For XenApp 5 for Windows Server 2008, migrating a farm data store to an Oracle database is supported for
Original database
Microsoft Access
Oracle 10.2.0.3
Microsoft SQL Server 2005 Express SP2 Oracle 11.1

IBM DB2 8.2
IBM DB2 9.5
Migrating a Farm Data Store to IBM DB2

For XenApp 5 for Windows Server 2003, migrating a farm data store to an IBM DB2 database is supported for
Original database
Target database
Microsoft Access
IBM DB2 8.2
Microsoft SQL Server 2005 Express Edition

Oracle 9.2.0.1
Oracle 10.2.0.1.0
For XenApp 5 for Windows Server 2008, migrating a farm data store to an IBM DB2 database is supported for
Original database
Target database
Microsoft Access
IBM DB2 8.2
Microsoft SQL Server 2005 Express SP2 IBM DB2 9.5

Oracle 10.2.0.3
Oracle 11.1
8.6.6.8.1. Migrating a Farm Data Store from MSDE to SQL Server Express
The Microsoft SQL Server Desktop Engine (MSDE) is no longer supported for a XenApp farm data store. If you
are migrating from a previous release of Presentation Server, you must migrate the data store from an
MSDE database to another database, such as SQL Server Express Edition.
The procedure comprises the following tasks:
1. Give the Network Service Account Access to the MSDE CITRIX_METAFRAME instance, using one of the
two following methods:
Using SQL Server Management Studio Express:
1. Download and install the following, which are available from Microsoft:
Microsoft Core XML Services (MSXML) 6.0, which includes the Microsoft XML Parser to
update your XML services.
SQL Server Management Studio Express, which provides tools not included in the
standard SQL Server Express installation. (The procedure below assumes you are using
the version for SQL Server Express 2005; the instructions may vary if you use
another version.)
2. Start SQL Server Management Studio Express and connect to the CITRIX_METAFRAME instance.
3. In SQL Server Management Studio Express, open the Security folder.
4. Right-click the Logins folder, then click New Login.
5. With the Windows authentication option selected, type:
Login name: NT AUTHORITY\NETWORK SERVICE.
6. Open the Databases folder, the MF20 folder, and then the Security folder.
7. Right-click the Users folder, then click New User.
8. With the Login name option selected, type:
User name: NETWORK SERVICE
Login name: NT AUTHORITY\NETWORK SERVICE.
9. In the Database role membership section, select the db_owner checkbox.
Using a script:
1. Set the environment variable for your system path to the bin directory for your MSDE instance.
2. Create a folder and name it Netservice.
3. In that folder, save the following script in a text file; name the file netservice_perm.txt.
USE MF20
go
sp_grantlogin 'NT AUTHORITY\NETWORK SERVICE'
sp_grantlogin 'NT AUTHORITY\NETWORK SERVICE'

go
sp_grantdbaccess 'NT AUTHORITY\NETWORK SERVICE'
go
sp_addrolemember 'db_owner','nt authority\network service'
go
4. From a command prompt within the Netservice folder, type: osql -E S localhost\CITRIX_METAFRAME -i netservice_perm.txt.
2. Migrate your Presentation Server farm to XenApp 5. After restarting the XenApp server, you may
receive event log messages because XenApp is temporarily using MSDE for the data store.
3. On the XenApp server, stop the Citrix Independent Management Architecture service, using one of
the following methods:
Stop the service in the Windows Services panel
At a command prompt, type net stop "Citrix Independent Management Architecture"
and enter y when prompted.
4. Run the MigrateToSqlExpress utility, which is located in the Support\SqlExpress_2005_SPx folder on
the installation media. See MIGRATETOSQLEXPRESS for details.
5. Restart the XenApp server on which you performed the migration.
8.7. XenApp Administration
The administration of your Citrix XenApp server farm consists of tasks in the management console to
manage administrators, publish resources, manage user sessions, secure your deployment, and maintain
your printing resources and server farms.
Before you install Citrix XenApp, review the Readme for Citrix XenApp document and the Installation Checklist.
For planning and installation information, see the XenApp Installation.
8.7.1. 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.
Access Management Console and Delivery Services Console
The Access Management Console and Delivery Services Console are two names for a tool that snaps into
the Microsoft Management Console (MMC) and enables you to perform a number of management functions.
The name of this tool depends on the version of XenApp you have installed.
You can manage items administered through other Citrix products, such as Citrix Secure Access and
Citrix Password Manager. For Citrix XenApp, you can set up and monitor servers, server farms,
published resources, and sessions. Create a variety of reports and configure application access (both through
the Web Interface and the Citrix XenApp plugin).
In addition, you can troubleshoot alerts, diagnose problems in your farms, view hotfix information for your
Citrix products, set up health checks on servers and farms, and track administrative changes.
XenApp Advanced Configuration and Presentation Server Console
XenApp Advanced Configuration and Presentation Server Console are two names for a tool that allows you to:
Connect to any server farm in your deployment
Set up policies and printers
Configure and manage your deployment with Load Manager
The name of this tool depends on the version of XenApp you have installed.
License Management Console
Use this console to manage and track Citrix software licenses. For more information about licensing, see
the License Management console Help and the Getting Started with Citrix Licensing Guide 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.
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 Access Management Console or Delivery Services Console.
SpeedScreen Latency Reduction Manager
Use this tool to configure local text echo and other features that improve the user experience on slow networks.
8.7.1.1. Choosing the Console or Tool to Use
Managing your XenApp deployment involves working with the Access Management Console or the
Delivery Services Console and the tool known as XenApp Advanced Configuration or Presentation Server
Console, depending on the version of XenApp you have installed.
To manage your deployment more flexibly, install the Access Management Console (or Delivery Services
Console) and XenApp Advanced Configuration (or Presentation Server Console) on a computer that is not
running XenApp. However, for the best console performance, Citrix recommends running the Access
Management Console or Delivery Services Console on a XenApp server.
For more information about the installation requirements of each of the management tools, see the
Installation Checklist for XenApp.
Use the Access Management Console or Delivery
Services Console to perform these tasks:
Use XenApp Advanced

Configuration or Presentation
Server Console to perform these tasks:
Assign load evaluators to applications
Create and manage zones in a farm.
Create Citrix administrators and modify their privileges.
Create policies for users connections.
Create reports with Report Center.
Configure and manage printers.
Configure access to published resources through the

Web Interface and Citrix XenApp plugin.
Configure, adjust, and monitor server

and application loads with Load Manager.
Configure and manage applications (including

Streamed Applications), servers, and farms.
Configure health tests for servers and farms using
Health Monitoring & Recovery. Create trace logs to assist
Citrix Technical Support with problem analysis.
Manage plugin sessions and server processes.
Monitor server performance and view zones in multiple farms.
Track administrative changes made through the console by
setting up Configuration Logging.
View hotfix information.
8.7.1.2. To start the console
Do not run the Access Management Console or Delivery Services Console in two sessions simultaneously on
one computer using the same account. Changes made on the console in one session can overwrite changes
made in the other.
1.
1. Click Start > All Programs > Citrix > Management Consoles > Access Management Console or
Delivery Services Console.
Important: Interoperability of XenApp 5.0 for Windows Server 2008 with versions prior to
Presentation Server 4.5 for Windows Server 2003 is not supported.
8.7.1.3. Displaying Items in the Console
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 console tree.
The first time you open the Access Management Console or Delivery Services Console 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.
After this, run the discovery process only if you want to configure discovery for a component, or if items
were added to or removed from 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 console 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 task pane only for
configurable components; otherwise, only the Run discovery task is available.
To use the discovery process to specify more than one server farm for console management
1. In the console tree, select Citrix Resources.
2. Click Configure and run discovery.
3. Specify the name or IP address of at least one server running XenApp in each farm that you want
to manage.
To run the discovery process for more than one product or component
1. In the console tree, select Citrix Resources.
2. Click Configure and run discovery.
To run the discovery process for a single product or component

1. In the console tree, select the product or component.
2. To configure discovery, click Configure and run discovery. To run discovery without any
configuration, click Run discovery.
8.7.1.4. The Console User Interface
The main user interface of the Access Management Console and Delivery Services Console consists of three panes:
The left pane contains the console tree.
The task pane in the middle displays administrative tasks and tools. This pane is typically not present
in other MMC snap-ins.
The details pane on the right displays items and information associated with the selected node in
the console tree.
Typically, you use the console as follows:
Select a node in the left pane, which updates the items and information displayed in the details pane
The Change display menu in the task pane allows you to view different items and information
associated with the node
To modify or otherwise administer an item, select it and click a task in the task pane or details pane
Be aware that there is a limit of 1000 unique application icons. When that limit is exceeded, the console
displays a generic icon for all new applications in the left pane.
Note: When you are browsing a list of objects in the console (for example, the list of administrators) and
the list table in the right pane is too small to list all the objects, a dialog box might appear stating there was
an unhandled exception. The exception might prevent the table from populating properly. To avoid this,
enlarge the table by dragging the horizontal line separating the table of items in the upper-right pane from
the list of tasks in the lower-right pane.
This screen capture shows the layout of the console after running discovery. The left pane contains the
console tree. The task pane is in the middle. The details pane is on the right.
These nodes are available under the top-level node in the console tree:
Alerts. Lists the alerts created by all the items in your deployment. Double-click an alert to drill down
to the affected item.
Search Results. Displays the results of any search that you perform. Click Search in the task pane
to perform a standard or advanced search.
My Views. Allows you to customize the information that you display in the details pane. See
Customizing Your Displays Using My Views for instructions about creating My Views.
In addition, nodes are also created by some snap-ins when they are installed. Some snap-ins are not visible
as nodes in the console tree but they add features, such as extra tasks, to other snap-ins. The
Access Management Console Framework (or Delivery Services Console Framework) is another component
that performs functions common to all snap-ins. All installed snap-ins require the Framework to be present;
the console as a whole cannot function without it.
Depending on your console installation, some or all of these snap-ins are available:
Report Center. Allows you to create and schedule reports describing many aspects of your deployment.
Licensing. Launches the License Management Console on your Citrix License Server(s), allowing you
to manage your Citrix product licenses. For information about this console, see the Getting Started
with Citrix Licensing Guide in Licensing Your Product.
Diagnostic Facility. Creates and packages trace logs and other system information to assist
Citrix Technical Support in diagnosing problems.
XenApp. Allows the console to establish contact with your deployment and lets you manage
applications and servers, and view zones in your farms. You also use this snap-in to create
Citrix administrators, audit the changes they make with the console, and configure and run health
checks on servers. XenApp is contained in the Citrix Resources node.
Web Interface. Allows you to manage how users access applications through the Web Interface and
Citrix XenApp plugin sites. Web Interface is located in the Configuration Tools node under Citrix Resources.
Hotfix Management. Manages hotfixes for your Citrix products. Hotfix Management is located in
the Configuration Tools node under Citrix Resources.
8.7.1.5. Performing Tasks with the Console

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 Access Management Console or the Delivery Services Console for the first time,
use this account to log on and to add other individuals to the Citrix administrators group.
Citrix recommends that you use a domain account to run the console. 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. This is necessary to ensure that access to every server is available
when you use Report Center.
Assigning Farm Administrator Credentials
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 Access Management Console or the Delivery Services Console for the first time,
use this account to log on and to add other individuals to the Citrix administrators group.
Customizing Your Displays Using My Views
My Views are configurable displays that give you quick access to items you must examine regularly or items
in different parts of the console 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.
Managing Applications and Servers in Multiple Farms
View and change details about any farm or its applications and servers in your enterprise. Farms and their
servers are controlled by the XenApp snap-in. For example, you can publish applications, add or remove
servers, and configure server and farm properties.
Viewing Zones
Zones enhance the performance of a server farm by grouping geographically related servers together, whether
or not they are connected to the same network subnet. By default, all servers in a farm that are on the
same network subnet belong to the same zone. Each zone in a server farm contains one server that is
designated as the data collector for the zone. Zones are view-only.
Managing User Sessions and Server Processes
Manage all user sessions in multiple farms in your enterprise. Alternatively, list sessions accessing a
specific published application, sessions connecting to a specific server, or view a specific users sessions
and applications.
View details of server processes, including the names of the executable files that generated the processes.
Creating Reports
Use Report Center to easily generate reports from a variety of real-time and historical data sources. Wizards
help you select the type of report, the data to be displayed, and the schedule for running the report. View
the status of your scheduled reports and adjust the report parameters. Report Center contains these reports:
Application
Configuration Logging
Policy
Virtual Memory Optimization
Configuring Application Access

Use the console with a Citrix Web Interface site to configure how users access published applications and
content through a standard Web browser or through the Citrix XenApp plugin.
For more information about configuring application access, see Web Interface.
Creating Trace Logs
Use the Diagnostic Facility to gather system data for servers in multiple farms to assist Citrix Technical
Support with problem analysis. In the left pane of the console, select the required servers and in the task
pane, click Diagnose problems > Start trace log and follow the on-screen instructions. At the request of
Citrix Technical Support, you then select the Diagnostic Facility node and click Set packaging details to
send the packaged trace log by File Transfer Protocol (FTP).
Viewing Citrix Hotfix Information
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 console, select Citrix Resources > Configuration Tools > Hotfix Management.
8.7.1.5.1. To view zones
Zones can be viewed but not configured in the console. For information on configuring zones, see To
configure zones in your farm.
1. Depending on the version of XenApp you have installed, from the Start menu, select All Programs
> Citrix > Management Consoles and choose Access Management Console or Delivery
Services Console.
2. In the left pane, under the Zone node, select a zone.
3. In the Details pane, choose Servers in the drop-down menu to display the servers in the chosen zone.
8.7.1.6. Enabling Citrix Administrators to Manage Farms Remotely
If you use the Access Management Console or Delivery Services Console to connect to, discover, or
manage remote servers, you may receive an error message when you attempt to discover a server in your
farm. Check the details of the discovery failure error to narrow down the potential causes of the failure.
One of the reasons this might occur is that you are using an account that does not have Distributed
Component Object Model (DCOM) Remote Launch permissions on the remote server. To prevent this error
from occurring, grant DCOM Remote Launch permissions to any Citrix administrators whom you allow to
access the farm. You can grant DCOM Remote Launch permissions to administrators on remote servers
running Windows Server 2008.
To grant DCOM Remote Launch permissions to administrators
1. On each server in the farm, install Remote COM+ support.
1.
1.
1. From the Server Manager, choose Roles, Add Roles, and then click Server Roles in the left pane.
2. Select Application Server.
3. Select COM+ Network Access, click Next, and then click Install.
2. On each server in the farm, add all users permitted to manage the farm remotely to the Distributed
COM Users group and give them farm administrator privileges. Alternatively, you can create a
domain group for this task to centralize management by following these steps:
1. Create a group named Citrix Administrators. To simplify and centralize group administration,
Citrix recommends that this be a domain group.
2. Add the Citrix Administrators group to the built-in Distributed COM Users group on the
remote server. Perform this step on all servers that are used to discover farms or that are
managed by the console remotely.
3. Add the Citrix administrator accounts to the Citrix Administrators group.
3. On the remote server, set the DCOM Default Impersonation Level to Impersonate.
1. Run the MMC and add the Component Service snap-in.
2. Select Computers, right-click My Computer, and select Properties.
3. Select the Default Properties tab.
4. From the Default Impersonation Level drop-down list, select Impersonate.
4. Depending on the version of XenApp you have installed, allow access to the Access Management Console
or Delivery Services Console and the tool known as XenApp Advanced Configuration or Presentation
Server Console through any software or hardware firewalls between the remote servers and the farm
or disable these firewalls.
8.7.1.7. XenApp Advanced Configuration and Presentation Server Console
XenApp Advanced Configuration and Presentation Server Console are two names for the same tool. The name
of of the tool depends on the version of XenApp you have installed.
To use this tool, you must be a Citrix administrator. Citrix administrators can have varying levels of access
to areas of server farm management. If you try to access an area of the tool that you are not authorized to
use, the details pane on the right does not display the associated information.
XenApp Setup installs the tool on each server in the farm by default. Use the XenApp installation media to
install the tool on other workstations you want to use to manage server farms.
Important: Earlier versions of this tool do not recognize settings you configure using your most
current version. If you run this tool from devices that do not have XenApp installed, such as workstations
or laptops, upgrade those devices to your most current version.
Conserving Bandwidth for Remote Monitoring
When using this tool to monitor a farm at a remote site, conserve bandwidth across the WAN by publishing
the Advanced Configuration tool application on a remote server and connecting to it using the Citrix
XenApp plugin locally.
To configure the tool for screen reader accessibility
Screen reader software might not readily interpret some of the text that appears in XenApp
Advanced Configuration or Presentation Server Console. By default, screen readers do not interpret static
text areas separate from input elements such as text boxes or check boxes. You can configure the tool so
that you can use the Tab key to move to static text areas you want screen readers to interpret.
1. On a computer where XenApp Advanced Configuration or Presentation Server Console is installed,
locate and open the Isctx.log file using a text editor. If you installed the tool in the default location,
Isctx.log is located in the \Program Files\Citrix\Administration folder.
2. On the second line of Isctx.log, type this text, including the hyphen: -labelsGetFocus:true
3. Save and close the file, then restart the tool.
8.7.2. 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 Directory Services account authority a Citrix administrator.
Services Console.
2. In the left pane, select a farm. Then select Action > New > Add Administrator.
3. Look up or select the name of the configured user or user group account you want to designate as a
Citrix administrator and click Add.
4. On the Privileges page, select the authority level you want to grant the administrator account.
5. 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

Services Console.
2. From the left pane, select the Administrators node.
3. In the details pane, select the administrator whose properties you want to change.
4. From the Tasks menu, click Modify administrator properties.
5. Choose from the following options:
To change an administrator's privilege level, open the Privileges page
To assign or update custom permissions, open the Permissions page
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. Under Tasks, 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, under Tasks, select 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. Under Tasks, click Delete administrator.
8.7.2.1. Delegating Tasks to Custom Administrators
Depending on the version of XenApp you have installed, you can delegate tasks through the Access
Management Console or the Delivery Services Console 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.
To delegate tasks to existing custom administrators

Services Console.
2. In the left pane, select the Administrators node and then in the detail pane, select an administrator.
3. Under Tasks, click Modify Administrator Properties.
4. Click Permissions to view the task permissions assigned to the administrator.
5. Click on a folder in the Folders list to view additional tasks.
6. To select the tasks to which the administrator has access, select or clear the check boxes, as appropriate.
7. 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 will need to 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. You can view and change permission on objects, such as printers, that are managed primarily in
the tool named XenApp Advanced Configuration or Presentation Server Console (depending on the version
of XenApp you have installed). You must be a Citrix administrator with full access to view and change
object permissions.
Services Console.
2. From the left pane, select the folder under the farm to which you want to grant access.
3. From the task pane, under Other Tasks, click 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.
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. You can view and change permission on objects, such as printers, that are managed primarily in
the tools known as XenApp Advanced Configuration or Presentation Server Console (depending on the version
of XenApp you have installed). You must be a Citrix administrator with full access to view and change
object permissions.
Services Console.
2. From the left pane, select a farm and then, in the task pane under Other Tasks, click Set permission
on objects.
3. 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.
4. 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.
5. 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:
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.
8.7.3. Publishing Resources

Updated: 2009-10-09
With XenApp, you provide users with access to information by publishing the following types of resources that
can be virtualized on servers or desktops:
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 XenApp console. To further
refine how your users launch and access published resources, refer to information about configuring
content redirection and XenApp policies.
Important: Before you begin, refer to Getting Started with Citrix XenApp to review the new and
discontinued features for publishing applications.
Additionally, refer to the System Requirements for supported platforms and system prerequisites.
8.7.3.1. Publishing Resources for Users
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; and client-side session properties that include window
size, number of colors, level of encryption, and audio setting.
When delivered to users, published applications appear very similar to applications running locally on the
client device.
Users start applications depending on the delivery options you select in the publishing wizard and the plug-in
they are running on their client devices. Consult the appropriate plug-in sections in eDocs or other
documentation for more information about the plug-in with which your users start published applications.
Publishing in Domains with Thousands of Objects
For directory services or domain environments, such as Novell Directory Service or Microsoft Active
Directory Service, containing over 10,000 objects, Citrix recommends the following:
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.
8.7.3.1.1. To publish a resource using the Publish Application wizard

Run the console included with your version of XenApp (Access Management Console or Delivery Services
Console) 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. 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 console. You can also drag and drop the published desktop or application onto the server.
2. Select the Applications node and from the Common Tasks pane choose New > Folder. Create a
folder for the application you are publishing.
3. Select the folder you created and from the Common Tasks pane choose New > 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 console 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.
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 on which the published application runs when accessed
by an ICA connection.
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 console has a limit of 1,000 unique application icons. When
9.
that limit is exceeded, the console displays a generic icon for all new applications.
10. On the Publish immediately page, choose whether or not to make the published application
immediately available to users.
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.
When you finish, published resources (unless disabled) are available for users.
8.7.3.1.2. 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 change the resource type, from the Action menu, select All Tasks > Change application type and
follow the instructions in the wizard.
1. Select one of the following resource types:
Server desktop. Publishes the entire Windows desktop of a server in the farm. When the plugin 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 console 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 console 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 client devices and launches locally from within an isolation
environment. Alternatively, for client devices that do not support streamed applications
(for example, if the XenApp Streaming Plug-in is not installed), use 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 client desktops and launches locally from within an isolation
environment. With this option, the application uses client resources instead of
server resources. Users must have the XenApp Streaming Plug-in installed and access
the application using XenApp Hosted Plug-in or a Web Interface site. If selected, client
devices that do not support client-side application virtualization (such as, they use a
non-Windows client) or do not have the XenApp Streaming 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:
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.
8.7.3.1.3. To configure locations of published applications

To access this option in the Access Management Console, 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:
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, use the Content Redirection property page to select the file
types you want to associate with the application for client to server content redirection.
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.
8.7.3.1.4. 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):
HTML Web site address (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)
8.7.3.1.5. 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.
Caution: Using Registry Editor 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.
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.
If your XenApp environment consists of a mixed farm and includes published applications that
use customized client-supplied parameters, use the following steps to disable command-line validation
for all applications:
1. On the server where the applications reside, run regedit.
2. Modify the following entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI
Name: PublishedAppCommandLineFlag
Type: DWORD
Data: 1 (enable validation, default) or 0 (disable validation)
8.7.3.2. 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 decide 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.
Redirecting Content 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
, users running the XenApp Plug-in for Hosted Apps 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 Citrix XenApp. You must
use the Web Interface server to allow users to connect to published applications. Citrix XenApp gets
updated properties for published applications from the server running the Web Interface. When you publish
an application and associate it with file types, the file type association is changed to reference the
published application in the Windows registry on the client device.
If you have users who run applications such as email programs locally, use the content redirection capability
with Citrix XenApp to redirect application launching from the client device to the server. When users doubleclick 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.
Important: You must enable client drive mapping to use this feature.
Redirecting Content 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. The browser locally installed on the client device is used to play the URL.
Users cannot disable this feature.
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. To free
servers from processing these types of requests, redirect application launching for supported URLs from
the server to the local client device.
Note: If the client device fails to connect to a URL, the URL is redirected back to the server.
The following URL types are opened locally through client devices for Windows and Linux when this type
of content redirection is enabled:
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)
Important: If content redirection from server to client is not working for some of the HTTPS links, verify
that the client 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.
Content redirection from server to client requires Internet Explorer Version 5.5 with Service Pack 2 on
systems running Windows 98 or higher.
8.7.3.2.1. To enable content redirection from server to client
Complete the following tasks in the Access Management Console to enable content redirection from server
to client and to publish content to be accessed with local applications.
When you configure XenApp to enable users to open published content with applications running locally on
client devices, the client passes the name of the published content file to the local viewer application. The
server does not download the file to the client device. Instead, the local viewer application accesses the file
the same as it would if a user double-clicked the file in Windows Explorer (and a file type association specified
the application to use).
Accessing published content with local client devices does not use XenApp resources or licenses because
local viewer applications do not use ICA sessions to display the published content.
To enable content redirection for the farm, select the farm in the left pane:
1. Select Action > Modify farm properties > Modify all properties.
2. From the Properties list, select Server default > XenApp.
3. Select Content Redirection to enable users to open URLs found in remote published applications
in a local Web browser.
4. Select Content redirection from server to client.
To enable content redirection for a specific server, select the server in the left pane:
1. Select Action > Modify server properties > Modify all properties.
2. Select Content Redirection to enable users to open URLs found in remote published applications
in a local Web browser.
3. Select Use farm settings (available on server level only) or Content redirection from server
to client.
To enable content redirection for specific connections:
1. Use XenApp Advanced Configuration or the Presentation Server Console, depending on the
version of XenApp you have installed. In a policy, enable the rule User Workspace >
Content Redirection > Server to client.
2. Assign the policy to only those connections for which you want to open supported URL file types
on client devices.
To publish content to be accessed with local applications:
1. Publish the content file you want users to access.
2. If you publish the application that corresponds to the content file type, do not associate it with
2.
any file types if you want users to open the published content with locally installed applications.
8.7.3.2.2. To configure content redirection from client to server

1. Determine which of your users or groups connect to published applications using Citrix XenApp.
2. Verify that client drive mapping is enabled, either for the entire farm, for specific servers, or for
specific users or groups with user policies.
3. Publish the application to be shared or the application that corresponds to the file type for the
published content. For example, if you publish a Microsoft Word document named Quarterly_Sales.
doc, make sure to also publish Microsoft Word on a XenApp server so that the .doc file can open in Word.
4. Associate the appropriate file type with the application.
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.
5. Assign the published application to the users you want to access it.
When you configure content redirection from client to server, context menu commands available from
within Windows Explorer function differently than on client devices that do not use this feature. For example,
if you right-click a file in Windows Explorer on a client 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 client 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.
After publishing applications through the Publish Application wizard, manage the published applications and
their properties:
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 Modify application properties > Modify all 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.
Use the Name property to change the application name and description that appears in Web Interface.
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 console, select the published application.
2. From the Action menu, select Modify application properties > Modify all properties > Name.
3. The Display name is the name users will see on their user device, and it must be unique within the folder.
4. The Application name appears in the console 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 console replaces the
end characters with four-digit hexadecimal numbers, starting from the right. The application name appears
in the left pane of the Properties dialog box for an application.
Choose the server on which the published application or desktop is available through the Servers page of
the Publish Application wizard, or from the Action menu, select Modify application properties >
Modify 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.
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.
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.
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.
Choose the user accounts that can access applications through the Users page of the Publish Application
wizard. To change the user accounts, from the Actions menu in the console, select Modify
application properties > Modify 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:

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
Directory Services (NDS) trees, Windows NT domains, Active Directory domains, and local
servers. (NDS trees 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 dropdown 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.

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 console. 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.
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.
Configure or modify the application shortcut presented to user devices on the Shortcut presentation page
of the Application Publishing wizard or by selecting Modify application properties > Modify all properties >
Basic > 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 Citrix XenApp applications, this application
2.
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:
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:
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.
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.
Use the Access control page of the Publish Application wizard or the application properties to specify the
types of connections through which users can start sessions to access published applications on the farm.
If Access Gateway (Version 4.0 or later) is installed, use the Access Control page of the Publish
Application wizard or select Access Control from the Advanced Application Properties page to specify
the type of connections that allow the application to appear in the list of published applications on the user device.
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:
Allow connections made through Citrix 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:
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.
As you publish applications, you associate the published item with certain file types present in the
Windows registry on the server. You associate published applications with file types initially in the
Publish Application wizard or later from a Properties page for the published application. By associating
published applications with file types and then assigning the applications to users, you implement the
following automatically:
Content redirection from user device to server. Users running the Citrix online or offline 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 Citrix XenApp 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:
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 Web Interface or using a Citrix plugin can open published content with published applications.
Associate published applications with file types initially from the Publish Application wizard, on the
Content redirection page, or later from the Action menu, select Modify application properties >
Modify content redirection properties
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.
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.
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. Use Update file types to associate these file types with the application in the server farms
data store. To verify which file types are associated with a published application, use the Content redirection
tab of the Properties page for the application.
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 to access these file shares, an alert appears.
Update the file type associations in the data store if:
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.
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.
If needed, update file types for the farm or for an individual server:
1. In the console, select a farm in the left pane and from the Action menu, select All Tasks > Update
file types.
2.
Select a server in the left pane and from the Action menu, select All Tasks > Update file types
from registry.
If you publish applications to be hosted on more than one server, be sure to update the file types on each server.
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.
Use the Location page of the application properties in the console to pass parameters to published
applications. 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 %*
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.
When a user starts a published application, the plugin 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:
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
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.
For applications published for an online connection, use the Client Options page of the application Properties
to configure the Citrix plug-in audio and encryption options for when users connect to a published application.
To locate the page, open the console, select the application, and from the Action menu, select
Modify application properties > Modify all properties > Advanced > Client options.
The settings that Citrix plug-ins use to communicate with a published application vary according to the type
of plug-in. The Citrix online plug-in and Web Interface automatically use 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 setting in Terminal Services Configuration (TSCC) and/or the setting in Citrix Connection
Configuration Tool (Mfcfg.exe)
The policy setting that applies to the connection
The application setting (that is, the level you are setting in this dialog box)
The Microsoft Group Policy
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 TSCC
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 TSCC 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.
Select Client audio options:
Enable legacy audio. Select this option to allow audio support for applications to
which SpeedScreen 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 plugin 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
SpeedScreen Multimedia Acceleration.
In the Connection encryption section, select one or more of the following options:
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.
Select Encryption to apply the RC5 encryption level for the connection.
In the Printing section, select or clear Start this application without waiting for client 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.

Define how the application appears to the user through the Appearance page of the Publish Application wizard,
or from the Action menu, select Modify application properties > Modify all properties > Advanced >
Appearance.
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 Colors. The available options are 16 Colors,
256 Colors, High Color (16-bit), or True Color (24-bit).
To hide the application title bar and maximize the application at startup, change the setting in the
Application Startup Settings.

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 might initially disable an application as you publish it in the publishing wizard or enable or disable it
anytime from the console.
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 console, select the application in the navigation pane, and from the Action menu, select
Enable application or Disable application.
In the console, select the application in the navigation pane, and from the Action menu, select
Modify application properties > Modify all properties. From the Name property, select
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.
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 console, select the application.
2. On the Action menu, select Delete application.
Use this option to move a published application to another folder in the console 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.
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.
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.
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.

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 console, 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 console, press CTRL
and select the names of the applications you want to export.
2. From the Action menu, select All Tasks > Export application settings to a file. Select what to export:
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 console before selecting the export task.
Important: If application settings are exported as a batch, they must be imported as a batch.
User List Only. Exports only the list of configured users for the application to an AUL file.
This option can export the user list associated with one published application only. Then select
a published application and import the user list, replacing the existing user list.
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.
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 console, 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 All Tasks > Import application settings from a file.
3. Use the Open dialog box to locate the settings file you want to import.
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.
8.7.3.4. 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 assign a static range of IP addresses to a server and have these
addresses individually allocated to each session so that configured applications running within that session
appear to have a unique address.
Processes require virtual IP if either:
They use a hard-coded TCP port number, or
They do both of the following:
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.*).
Processes require virtual loopback if either:

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.
8.7.3.4.1. How Virtual IP Addressing Works
The virtual IP Address feature works as follows:
During IMA startup, the virtual IP address assigner binds the assigned IP addresses to the NIC
that matches the same subnet as the virtual addresses.
When the virtual IP feature is enabled on a specific server, the virtual IP address allocator allocates all
new sessions connecting to the server an address from the pool of available addresses that were
assigned by the virtual IP address assigner.
Each new session is allocated an address that is removed from the pool of available addresses. When
the session logs off, the allocated address is returned to the available address pool.
After an address is allocated to a session, it uses the allocated 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, gethostbyname,
gethostbyaddr, getnameinfo, getaddrinfo
Note: All processes that require this feature must be added to the Virtual IP Process list. Child processes do
not inherit this functionality automatically. Processes can be configured with full paths or just the
executable name. For security reasons, Citrix recommends that you use full paths.
8.7.3.4.2. Configuring Virtual Loopback
When enabled, the Virtual Loopback function does not require any additional configuration other than
specifying which processes use the feature. 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.
Virtual Loopback enables multiple published applications that depend on the localhost interface for
interprocess communication to function correctly within the session.
8.7.3.4.3. Binding Applications
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() and GetAddrInfo(), 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.
8.7.3.4.4. 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 app
8.7.3.4.5. To make virtual IP addresses available to applications running in sessions
Use virtual IP addresses to 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 of these applications can access them on a XenApp server in the same fashion that they access any
other published application.
To assign virtual IP address ranges, you must have a reserved range of static IP addresses to assign to
the server. Work with your network administrator to obtain a list of free addresses that are not part of your
DHCP pool. Ensure that you do not include broadcast addresses.
Before assigning virtual IP address ranges, determine the maximum number of users you may have
connecting concurrently to the server. Because every session connecting to the server is assigned an IP
address (not just sessions launching the application that require virtual IP addresses), assign at least as
many static IP addresses to the server as the maximum number of users who may be connecting concurrently
to that server.
Note: In the event more sessions are launched on a server than IP addresses are available, the server
displays the error message: No virtual IP address is available for this session, please contact
your administrator. The inability of the server to assign a virtual IP address to a session does not prevent
the user from launching an application that requires a virtual IP address within the session; however,
the application may not function correctly.
At the farm level, configure virtual IP address ranges and assign them to servers.
Enable applications to use virtual IP addresses.
In addition to configuring virtual IP address ranges and enabling applications for use with virtual IP
addresses, this feature can control and monitor virtual IP addresses available from each server.
8.7.3.4.6. To assign virtual IP address ranges to servers
Before enabling the virtual IP address feature, configure ranges of IP addresses that are excluded from any
DHCP servers or otherwise duplicated. These ranges must share the same subnets as the assigned IP
addresses of the XenApp servers that are configured for virtual IP, because there is no routing mechanism
in place to traverse subnets.
The pool of IP addresses assigned to the server farm must be large enough to include all concurrent user
sessions on every server that is configured, not just the sessions running the applications requiring virtual
IP address functionality. Add the servers that require virtual IP address functionality that share the same
subnet as the address range to the range. The addresses in the range are distributed equally (by default)
among the selected servers and assigned. You can then change the number of addresses assigned to each
server. Citrix recommends that you configure a Load Management Server User Load rule that is equal to or
fewer than the total number of addresses assigned to the server.
Use the Access Management Console to assign a specific address range to each XenApp computer or group
of computers. This may be a viable option within environments where the servers span subnets or
where insufficient IP addresses exist within the current subnet. You can also modify existing ranges to increase
or decrease the number of addresses in the range. When programs running in multiple, concurrent user
sessions have problems with TCP port conflicts, the system uses these virtual addresses to assign each
user session a unique IP address. Servers with virtual IP disabled appear in the left pane with a red circle and
x in their icon. When virtual IP is enabled, server icons do not have the red circle or x.
1. In the left pane of the Access Management Console, select a farm. Then select Action > Modify
farm properties > Modify Virtual IP properties.
2. From the Virtual IP page, select Address Configuration.The Virtual IP address ranges list
appears. This displays the ranges defined for the farm, the servers assigned to the range, and the
number of assigned addresses for each server.
3. Use the Address Configuration dialog box to configure the virtual IP address ranges and assign them
to servers. Use the buttons provided to configure the ranges:
Add IP Range. Allows you to define a new range of IP addresses. Make sure all addresses in
the range are valid and on the same subnet as the XenApp server. Specifically, do not include:
IP addresses in use by other devices on the network
Broadcast addresses
Configure Servers. Opens a dialog box to add or remove servers in the selected range and
modify the number of addresses assigned to each server.
4. Select the Enable logging of IP address assignment and release check box to log IP
address assignments and releases in the systems application log (not selected by default).
This information includes virtual IP addresses, user names, and session IDs. Clear the check box to
remove information from the log.
Important: When you finish, restart all affected servers to apply the changes.
By default, servers use the settings selected for the farm. To customize the setting for individual servers, use the
Server Properties page to override the farm settings.
After configuring virtual IP address ranges, continue by specifying the application processes that are enabled
to use virtual IP addresses.
8.7.3.4.7. To enable application processes to use virtual IP addresses or virtual loopback
After you configure virtual IP addresses or virtual loopback for a farm, continue by specifying the
application processes (that is, the executables that run the applications) that can use the virtual IP addresses
or virtual loopback.
You configure the virtual IP feature for application processes through the Process Configuration page of
the Access Management Console. This page displays two lists of processes that are enabled for virtual IP
and virtual loopback, respectively.
1. In the left pane of the management console, select the farm.
2. Select Action > Modify farm properties > Modify Virtual IP properties.
3. From the Virtual IP page, select Process Configuration.
4. In the Processes Configuration dialog box, use the buttons to control lists of processes to which
the server provides virtual IP and loopback addresses.
The Add Process option allows you to type the executable name to add the process to the list. You
can add executables to one or both lists. (Do not specify the path; specify only the executable name.)
When adding files to the lists, select the executable files associated with the applications you want
to enable to use virtual IP and virtual loopback.
Depending on the list to which you add a process, the next time the process starts in a session, it uses a
virtual IP address or virtual loopback.
8.7.3.4.8. To supply client IP addresses to published applications on a server
Updated: 2010-03-05
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. 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: 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.
2. Using regedit, create the following two registry entries:
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\
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. For instructions, see
To enable application processes to use virtual IP addresses or virtual loopback. Do not configure the use
of client IP addresses if:
Plugins connect using network protocols other than TCP/IP

Plugins reconnect to disconnected sessions from different client devices
Sessions use a pass-through plugin
8.7.3.4.9. To make a virtual loopback address available to applications running in sessions

Use virtual loopback to provide published applications with loopback addresses to use in sessions hosted on
a server. An administrator can publish applications that require separate loopback addresses per session. Users
of these applications can access them on XenApp servers in the same way that they access any other
published application. Use virtual IP addresses or virtual loopback for applications that fail or do not
behave properly when running in multiple, concurrent user sessions. These problems occur mainly with inhouse or customized applications that have trouble running on Windows Terminal Services.
The behavior of the applications determines whether they use virtual IP or virtual loopback.
1. At the farm level, enable virtual loopback on servers.
2. Enable application processes to use virtual loopback.
After you configure virtual loopback on your servers, control and monitor this feature at the server level.
8.7.3.4.10. To enable or disable virtual loopback for a farm
You configure virtual loopback for the servers in a farm through the Loopback Configuration page of the
Access Management Console. You have the option to configure this feature for specified servers or all
servers associated with a farm.
1. In the left pane of the Access Management Console, select a farm. Then select Action > Modify
farm properties > Modify Virtual IP properties.
2. On the Virtual IP page, select Loopback Configuration.
3. Select the servers in the list for which you want to enable virtual loopback and click Add, or click Add All
to enable virtual loopback on all servers in the farm.
4. Select Include subfolders if you want to configure servers contained in subfolders.
5. To disable virtual loopback, select a server in the Selected items list and click Remove, or click
Remove All to disable virtual loopback on all the servers in the farm.
After configuring virtual IP loopback on your servers, continue by specifying the application processes on
each server for which you want virtual loopback available.
After enabling the option for the farm, continue by configuring virtual IP addresses and virtual loopback on
an individual server.
8.7.3.4.11. To configure virtual IP addresses and virtual loopback on an individual server
After you configure virtual IP address ranges or virtual loopback at the farm level, use virtual IP
configuration settings at the server level to:
Enable and disable the use of virtual IP and virtual loopback on a server
View the IP address ranges available on a server
Control logging of the assignment and release of virtual IP addresses
By default, servers in a farm use the settings defined for the farm. To override the farm setting, configure
an individual setting for a particular server. For example, use this feature to temporarily disable the use of
virtual IP addresses for a server.
Configure the options on each server:
1. In the left pane of the management console, select a server. Then select Action > Modify
server properties > Modify all properties.
2. From the Server Properties list, select Virtual IP.
3. On the Virtual IP page, if you want to enable virtual IP, select Enable virtual IP for this server.
This option allows sessions to use virtual IP addresses on the server. Virtual IP addresses are enabled
by default when you assign an address range to a server.
Note: This option is available only after you enable virtual IP on the Farm Properties page and
then add this server to one or more address ranges. The list in the dialog box shows the address
ranges already defined for the server.
Clear the check box to disable the use of virtual IP addresses for this server. Disabling a servers virtual
IP addresses does not affect the assignment of addresses to the server. The assigned addresses
remain reserved for the server.
4. If you want to enable logging, select the Use farm settings for IP address logging check box.
By default, servers use the farm setting for logging events to the systems Application log. This
option applies the farm setting to the selected server.
Clear the check box to customize the logging option for the server.
5. If desired, select the Enable logging of IP address assignment and release on this server check box.
This option logs IP address assignments and releases in the systems Application log. This
information includes virtual IP addresses, user names, and session IDs.
6. If you want to enable virtual loopback, select the Enable virtual loopback for this server check
box. This option allows sessions to use virtual loopback on the server (selected by default if you
assigned addresses for this server on the Properties page for the farm).
8.7.4. Working with XenApp Policies
To control user access or session environments, configure a XenApp policy. XenApp 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 rules. For example, you can configure rules to:
Control sound quality for client devices
Allow users to access the Documents folder on their local client device
Prevent remote users from being able to save to their hard drives from a session
Prevent users from accessing the Windows clipboard
Route print jobs from specific workstations directly from the server to the printer, rather than through
the client device
Set a required encryption level for specific Citrix XenApp Plugins
Direct users to connect to servers in a specific remote zone in the event of failure
If you create more than one policy in your environment, make sure that you prioritize the policies so that it
is clear, if there is conflict, which policy should take precedence.
In Citrix products, Citrix policies always supersede all other policies and settings in your environment,
including Active Directory policies and Windows settings.
The process for configuring policies is:
1. Create and name the policy.
2. Configure policy rules.
3. Apply the policy to connections by filtering according to access control, client IP address, client
name, servers, and users.
4. Prioritize the policy.
In general, policies override similar settings configured for the entire server farm, for specific servers, or on
the client. However, the highest encryption setting and the most restrictive shadowing setting always
override other settings.
Policies are applied when users connect to the server farm and remain in effect for the length of the
session. Changes you make to policies do not affect users who are already connected. The changes take
effect the next time the users connect.

8.7.4.1. Creating XenApp 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 rules instead of creating another policy. Avoid creating a new policy solely to enable a specific rule
or to exclude the policy from applying to certain users.
Note:
In addition to the procedures described here, you can use the XenApp Management SDK (MPSSDK) to
create and edit policies. For information about the XenApp Management SDK, see the Citrix Developer Network.
To create a policy
1. Depending on the version of XenApp you have installed:
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 Policies in the left pane and select Actions > New > Policy.
3. In the New Policy dialog box, 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. If you want to use a preconfigured set of rules for the policy, select Optimize initial policy settings for
a connection type and select the connection type from the drop-down list. The rules are optimized for:
WAN. Configures policy rules suitable for most networks.
Satellite. Configures policy rules suitable for high latency conditions.
Dial-up. Configures policy rules suitable for low-bandwidth, high latency conditions.
To edit a policy
2. Select Policies in the left pane.
3. Right-click the name of the policy you want to edit and select one of the following:
Edit Description
Rename Policy
Properties
8.7.4.2. Applying XenApp Policies

For a policy to become active, you must create a filter for it so the server can apply it to matching connections.
You can create filters based on a combination of the following criteria:
IP address of the client device used to connect to the session
Name of the client device from which the session is connected
User or group membership of the user connecting to the session
Server hosting a session
Access control through which a client is connecting to a session

You can add as many filters as you want to the policy. The policy is applied only to connections that meet
all filtering conditions.
When a user logs on, all policies that match the filters for the connection are identified. XenApp sorts
the identified policies into priority order, compares multiple instances of any rule, and applies the rule
according to the priority ranking of the policy.
Any rule that is disabled takes precedence over a lower-ranked rule that is enabled. Policy rules that are
not configured are ignored.
To apply a policy
You must add at least one filter to a policy for that policy to be applied.
2. In the left pane, select Policies.
3. From the Contents tab, select the policy you want to apply.
4. From the Actions menu, select Policy > Apply this policy to.
5. In the Policy Filters dialog box, configure filters:
1. From the policy filters list, select a filter for the policy. You can filter based on:
Access Control. See To apply a policy filter based on existing Access Gateway policies
for details.
Client IP Address. See To filter based on client IP address for details. If you are
concerned about network access and identity and want to use filters to enforce your
security goals, Citrix does not recommend filtering by client IP address, because a
malicious user can change the IP address reported by the client.
Client Name. See To filter based on client name for details. If users can change the name
of their client devices, you may not want to filter policies by client device name. If you
are concerned about network access and identity and want to use filters to enforce
your security goals, Citrix does not recommend filtering by client device name, because
a malicious user can change the IP address reported by the client.
Servers. See To filter based on servers for details.
Users. See To filter based on users for details.
2. To enable the filter for the policy, select Filter based on type of filter.
3. Repeat these steps for each filter you want to apply.
The policy is applied the next time the relevant users establish a connection.
To filter based on client IP address
5. In the Policy Filters dialog box, select Client IP Address.
6.
6. Select Filter based on client IP address.

7. Select one of the following:
Apply to all client IP addresses to apply this policy to all connections. To add most but not
all addresses, select Apply to all client IP addresses and then create exceptions. To
create exceptions, add the addresses to which you do not want the policy to apply, then select Deny
for each address.
Add to add specific client addresses. Make sure Allow is selected for each address or range chosen.
To filter based on servers

5. In the Policy Filters dialog box, select Servers.
6. Select Filter based on servers.
7. To specify servers to which you do not want to apply this policy, from the check mark drop-down list
beside the server name, select Do not apply to this server.
Important: If you filter a policy based on a server, the Configure delivery protocol policy rule, which
is used to configure the Citrix application streaming feature, does not apply. For more information
about application streaming, see Application Streaming .
To filter based on users
5. In the Policy Filters dialog box, select Users.
6. Select Filter based on users.
7. Use the controls to apply the policy to all users, all explicit users, all anonymous users, or a list of users.
Tip: You can add users or groups by clicking Add List of Names or using the Look in list box. The
Look in list box locates all trusted account authorities configured on the farm servers, including
Novell Directory Services (NDS) trees, Active Directory domains, and local servers.
To add a list of names in the Add List of Names dialog box, do one of the following:
Enter the user names you want to add. Separate user names with a semicolon.
Enter Windows NT Domain account names in the domain\account format and Active
Directory account names in the account@example.company.com format.
Important: To use Active Directory Domain Local Groups and Universal Groups, your server
farm must meet specific network configuration conditions. For more information, see the
XenApp Installation.
If NDS is enabled, enter NDS account names in the ndstree\account format, where account is
the distinguished name of the account.

Note: When adding NDS users, you must have rights to edit farm settings. Use the Look In list
to assign NDS users to objects in any area of management; for example, applications to which
you want them to have access.
To filter based on client name

5. In the Policy Filters dialog box, select Client Name.
6. Select Filter based on client name.
Apply to all client names to apply this policy to all connections. To add most but not all
client names, select Apply to all client names and then create exceptions. To create
exceptions, add the client names to which you do not want the policy to apply, then select Deny
for each name.
Add to add specific client names. Make sure Allow is selected for each name chosen.
In the Add Client Name to Policy Filter dialog box, you can include wildcard characters.
Important: Web Interface client names are assigned randomly with a prefix of WI_;
therefore, specific client names cannot be anticipated. To filter Web Interface connections by
client name, use the wildcard expression WI_*. Consider using client name filtering in
conjunction with IP address filtering for users who access XenApp servers from the Web Interface.
8.7.4.3. Configuring Policy Rules

Citrix recommends the following when configuring policy rules:
Assign user policies to groups rather than individual users. If you assign user policies to
groups, assignments are updated automatically when you add or remove users from the group.
Do not enable conflicting or overlapping settings in Terminal Services Configuration tool or in the
farm settings of the Access Management Console. In some cases, the Terminal Services Configuration
tool and the farm-wide settings in the Access Management Console provide similar functionality to
XenApp policy rules. When possible, keep all settings consistent (enabled or disabled) for ease
of troubleshooting.
Disable unused policies. Policies with all the rules set to Not Configured create unnecessary processing.
Set unused policy rules to Not Configured. Disabling unused policy rules disables the rule in all
policies lower ranked policies.
8.7.4.3.1. To configure policy rules

Policies contain rules that define and configure connection settings to be applied when the policy is
enforced. Policy rules can be enabled, disabled, or not configured. By default, most rules are not
configured. Rules are applied only when they are enabled.
1.

2. Select the policy, then select Actions > Properties.
3. Expand the folders to view the rules you can apply.
4. Decide how to use rules in the policy and change their state accordingly. Policy rules can be in one of
three states:
Not Configured. By default, most rules are not configured, meaning they are ignored when
users log on to the server. If you want to disable a rule in this policy but you want to be able
to enable this rule in a lower-ranked policy, select Not Configured.
Enabled. Adds the rule to the policy and allows you to set the rule options in the details pane.
Disabled. Explicitly disallows the rule. If you disable a rule, it is not enabled in any lowerranked policies. Disabling a features rule does not enable the inverse of the rule. That is, you
cannot turn a feature on in the product by disabling its rule.
The policy rule changes come into effect the next time the relevant users establish a connection, provided
you already applied the policy by enabling a filter.
8.7.4.4. Using Multiple Policies
You can use multiple policies to tailor XenApp to meet users needs based on their job functions,
geographic locations, or connection types. For example, for security reasons you may need to place
restrictions on user groups who regularly work with highly sensitive data. You can create a policy that requires
a high level of encryption for sessions and prevents users from saving sensitive files on their local client
drives. However, if some of the people in the user group do need access to their local drives, you can
create another policy for only those users. You then rank or prioritize the two policies to control which one
takes precedence.
When using multiple policies, you need to determine how to prioritize them, how to create exceptions, and how
to view the effective policy when policies conflict.
In general, 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.
XenApp policies interact with policies you set in your operating system. Some Windows policies take
precedence over XenApp policies. For some policy rules, 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 settings
that you specify in the Secure ICA 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.
8.7.4.4.1. Using Citrix policies with Active Directory
Active Directory and Windows policies do not take precedence over XenApp policies. In a XenApp
environment and with XenApp features, Citrix policies always take precedence over Windows policies and settings. Citrix desi
In a Citrix environment, XenApp policy rules override the same settings configured in an Active Directory policy
or using the Terminal Services Configuration tool. They also override Microsoft policies, including those that
are related to typical Remote Desktop Protocol (RDP) client connection settings such as the policies for
Desktop wallpaper, Menu animations, and Windows contents while dragging.
However, XenApp policy rules do not always override policies for encryption and shadowing. These
policies behave according to the most restrictive settings configured by the Terminal Services Configuration
tool, Active Directory group policies, application configuration, and Citrix policies.
If you are familiar with Active Directory, note these important distinctions:
For Active Directory policies, the disabled setting affects how the feature functions. That is, it disables
or enables the feature.
For XenApp policies, the disabled setting only prevents a lower-priority policy from being able to
enable the policy rule. Disabling a XenApp policy rule does not disable its corresponding feature in
the product.
8.7.4.4.2. Prioritizing Policies and Creating Exceptions
Prioritizing policies allows you to define the precedence of policies when they contain conflicting rules. The process XenApp us
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
rule, applying the rule 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. Rules are merged according to priority and the rules
condition; for example, whether the rule is disabled, enabled, or not configured. Any disabled rule overrides
a lower-ranked rule that is enabled. Policy rules that are not configured are ignored and do not override
the settings of lower-ranked rules.
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 rules. To more effectively manage exceptions, you can create
new policies for only those group members needing the exceptions, and then rank that policy higher than
the policy for the entire group.
To display the priorities of all policies
3. From the View menu, select Details.
To give a policy a higher priority

2. Select the policy.
3. From the Actions menu, select Policy > Priority.
4. Select Increase Priority until the policy has the preferred rank.
8.7.4.5. 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 rules you set in the original policy. Use the Policy
Search feature to:
Find all policies that can apply to a specific connection
Determine how final policy rules are merged for the connection (that is, determine the resultant policy)
To find out which policies apply to connections, you can search by specifying the same filters that are used
to apply policies, adding more search filters if necessary.
If the expected policies are not listed in the Search results, check the filters assigned to the policies and
your search criteria. For example, verify that you have the Allow option set for a configured account within
a user filter assigned to a policy.
To discover which policies apply to a connection

1. From the Actions menu, select Search.
2. In the Search Criteria list, select a filter name. You can narrow the selection by defining multiple
search criteria.
3. Click Edit.
4. Depending on the search criteria you selected:
Enter Access Control Search Criteria. Select an Access Control connection to find all policies
that match or partially match this connection type.
Enter Client IP Search Criteria. Select a client IP address to find all policies with filters that
match or partially match this address.
Enter Client Name Search Criteria. Select a client name to find all policies with filters that
match or partially match this name.
Enter Server Search Criteria. Select a server to find all policies with filters that match or
partially match this server.
Enter User Search Criteria. Select a user or group to find all policies with filters that match
or partially match this name.
If you search to see which policies apply to a domain user, the search results do not list any
policies that are applied to any local groups of which the user is a member.
5. Click Search. Accept any prompts that appear. The results appear in the Search Results display at
the bottom of the dialog box.
To resolve partial matches, see Resolving Search Results that Partially Match Criteria.
To display the resultant policy, see Troubleshooting Policies with Conflicting Rules
8.7.4.5.1. Resolving Search Results that Partially Match Criteria
When you use the Search feature to discover which policies apply to a connection, the results list all policies
that match or partially match the search criteria that you selected. A policy is a partial match if matches some
but not all of the search criteria.
You can eliminate partial matches when you locate all valid matches for the connection about which you
want information.
To resolve search results that partially match search criteria
This procedure assumes that you performed a search and the search results included a policy that
partially matches the search criteria.
1. Right-click the policy in the Search Results pane and select Why is this policy a partial match?
2. Return to the Search dialog box and supply any additional search criteria to the connection about
which you want information.
3. Eliminate partial matches when you locate all valid matches for the connection about which you
want information. If a message appears saying that no rules are configured for a policy, see When
No Policy Rules are Configured for further details.
Note: Partial matches might make some of the resultant policy settings appear in an indeterminate
state. However, settings that are not affected by the partially matched policies still appear normally.
8.7.4.5.2. Troubleshooting Policies with Conflicting Rules
Because rules set in some policies can conflict with rules set in others and policies can have multiple filters,
a policy may not behave in the way you expect or it may not run at all. Users, IP addresses, and other
filtered objects can have more than one policy that applies to them simultaneously. When this happens,
XenApp merges these policies rules to form, in effect, a new policy resulting from the existing ones.
This combination of rules is known as the resultant policy. When there are multiple policies that can apply to
a session, it is the resultant policy that XenApp enforces.
If you have multiple policies in your environment and you are having trouble figuring out why a policy wont
run, Citrix recommends that you determine the resultant policy.
To determine a resultant policy
1. Search to determine which policies apply to a connection. See Determining Which Policies Apply to
a Connection.
2. In the Search results dialog box, make sure partial matches are not selected in the Include column,
then select View Resultant Policy.
When No Policy Rules are Configured

When a resultant policy does not contain any configured rules, users connecting to their applications
under conditions that match the search criteria are not affected by any policy rules.
When you perform a search, you can end up with a resultant policy that has no configured rules when:
No policies have a filter set that matches the search criteria
Policies that match the filter do not have any rules configured
Policies that match the filter have their rules disabled
If you want to apply policy rules to the connections that meet the specified criteria:
Make sure the rules that you want to apply to those connections are enabled
Rank the policy that you want to apply higher than other policies
8.7.4.6. Disabling, Reenabling, and Deleting Policies

Disable unused policies to prevent unnecessary processing. Disabled policies can be reenabled.
If you delete a policy rather than disabling it, you cannot undelete the policy.
To disable a policy
3. In the Contents tab, select the policy you want to disable.
4. From the Actions menu, select Policy > Disable Policy. The policy appears in the right pane with
an orange bar through it.
To reenable a policy
3.
3. In the Contents tab, select the policy you want to reenable.

4. From the Actions menu, select Policy > Enable Policy.
To delete a policy
3. In the Contents tab, select the policy you want to delete.
4. From the Actions menu, select Policy > Delete Policy.
8.7.4.7. Changing Settings Based on User Location
You can use multiple policies to selectively apply XenApp settings to users tailored to how they connect.
For example, you may have staff members who download high resolution graphics. You can create two
policies, one that enables compression when users employ dial-up connections, and one that
disables compression when they use high-speed connections.
To create policies to customize the user experience based on how users connect
1. Determine how you want policy rules to apply to specific connections. For example, you may want
to enable compression for everyone except those connecting from a specific IP address range.
2. Create policies for the connections to which you want to apply specific rules.
3. Use filters to set conditions that a connection must meet for a policy to be applied. For example, when
you assign an IP address range filter to a policy, that policy applies only to connections in that IP
address range. A users connection must meet all filtering conditions in a policy for that policy to be
applied to the users session.
4. Prioritize policies so that rules are applied in the correct order. For example, rank a policy that
disables compression for specific IP addresses higher than the policy that enables compression
for everyone in general.
5. Use Search to confirm how final policy rules are merged for a specific connection. Search calculates
the final rule settings for any combination of a user, group, and IP address after the rules priorities
are taken into account.
8.7.4.8. Configuring Policies and Filters for Web Access
You can create a policy that is applied to Access Gateway connections or to Access Gateway connections
with certain properties.
You can create XenApp 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:
Create one or more filters within Access Gateway Advanced Edition. See the Administrator's Guide
for Access Gateway Enterprise in the Citrix Knowledge Center for more information about creating filters.
Note: You must be using Access Gateway with the Access Gateway Advanced Edition (Version 4.0
or later) to create filters that work with XenApp.
Select Allow connections made through Access Gateway Advanced Edition for
published applications.
On each server, select Trust requests sent to the XML Service.
Ensure that your farm is configured to allow Access Gateway connections, which it is by default.
Create policies within XenApp that reference Access Gateway Advanced Edition filters.
To apply a policy filter based on Access Gateway connections

3. Select an existing policy or create a new policy for the access control filter.
4. From the Actions menu, select Policies > Apply this policy to.
5. In the left pane, select Access Control.
6. Select Filter based on Access Control.
7. Select Apply to connections made through Access Gateway.
8. Select Any connection to apply this policy to connections made through Citrix Access Gateway
servers (Version 4.0 or later) without considering Access Gateway policies.
To apply a policy filter based on existing Access Gateway policies

7. Select Any connection that meets any of the following filters.
8. Click Add. The Add Access Gateway Filter dialog box appears.
9. In the Access Gateway farm list box, enter the name of the Access Gateway farm.
10. In the Access Gateway filter list box, select the Access Gateway policy for XenApp to use.
Important: XenApp does not validate Access Gateway farm and filter names, so always verify
the names with the Access Gateway administrator.
To apply a policy to every connection except those based on Access Gateway

5.

7. Select Apply to all other connections. Doing so applies this policy to all connections except those
made through Access Gateway (Version 4.0 or later).
8.7.4.9. 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:
The imaging device must be connected locally to the client and have the associated vendorsupplied TWAIN driver installed locally.
Citrix Presentation Server Client Version 9.x or later, the Citrix XenApp Plugin for Hosted Apps, or
the Citrix XenApp Plugin for Streamed Apps.
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 Configure TWAIN redirection policy rule must be enabled.
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
Epson Perfection 3170 Photo
Fujitsu fi-6140
HP Office Jet 7130 All-In-One
HP ScanJet 8250
HP ScanJet 8290
Microtek ScanMaker 5950
Visioneer OneTouch 9320
Xerox DocuMate 510
Web/Digital Cameras
D-Link VisualStream DSB-C310 PC Camera

Logitech QuickCam Messenger
Software
Adobe Acrobat Capture

Adobe Pagemaker 7.0
Corel Paint Shop Pro
Microsoft Digital Image Suite 9
Microsoft Digital Image Suite 10
Microsoft Office Document Scanning
Microsoft Office Publisher 2003
Microsoft Office Publisher 2007
Microsoft Picture It!
OmniPage SE Version 2.0
8.7.4.9.1. To enable TWAIN redirection

2. Open the Properties dialog box of the policy in which you want to control TWAIN redirection.
3. Enable the rule Client Devices > Resources > Other > Configure TWAIN redirection.
4. Use the options to allow and disallow TWAIN redirection, as well as control the level of data compression.
Consider the following after enabling TWAIN redirection:
The image acquisition software must be installed on the XenApp server.
Image acquisition software that provides the USB device drivers must be installed on the client platform.
Some applications are not Terminal Server 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 Terminal Server application compatibility list with the following two flags specified:
Windows application: 0x00000008
Do not substitute user Windows directory: 0x00000400
This feature supports the following modes of TWAIN information transfer:
Native
Buffered Memory (most scanning software works by default in Buffered Memory mode)
Note: The disk file transfer mode is not supported.
8.7.5. Managing Session Environments and Connections

Provides user access to your farms resources by:
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.
XenApp provides settings to ensure sessions remain reliable. You can also monitor users sessions, and
their sessions status, by shadowing.
8.7.5.1. Defining User Environments in XenApp
Updated: 2010-03-08
XenApp provides different ways to control what users experience in their session environments. You
can customize user environments in the following ways:
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 Citrix XenApp Plug-in for Hosted Apps, 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
XenApp Plugin for Hosted Apps and the Web Interface topics in the Citrix eDocs documentation library.
8.7.5.1.1. 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:
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.
8.7.5.1.2. Controlling Access to Devices and Ports
Citrix XenApp Plugin for Hosted Apps supports mapping devices on client computers so users can access
the devices within sessions. Client device mapping provides:
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, the plugin informs the server of the available client drives and COM ports. By default, client
drives are mapped to server drive letters so the drives appear to be directly connected to the server.
These mappings are available only for the current user during the current session. The mappings are
deleted when the user logs off and recreated the next time the user logs on.
8.7.5.1.2.1. Mapping Client Drives
By default, the drives on the client system are mapped automatically to drive letters on the server when users
log on. The clients disk drives appear as shared folders with mapped drive letters. These drives are used
by Windows Explorer and other applications like any other network drive.
In general, XenApp tries to match the client drives to the client drive letters; for example, the client devices
first floppy disk drive to A, the second floppy disk drive to B, the first hard disk partition to C, and so forth.
This allows the user to access client drive letters in the same way locally and within sessions.
However, the same drive letters are often in use by the drives on the server. In this case, client drives
are mapped to different drive letters. The server starts at V and searches in ascending order for unassigned
drive letters.
You can turn off client drive mapping through policies you configure in XenApp. Similarly, you can turn
off mapping to client floppy disk drives, hard drive, CD-ROM drives, or remote drives.
If access to the floppy disk drives is not needed, consider disabling access to speed up the logon process.
As a security precaution, when a user logs on to XenApp, by default, the server maps client drives without
user execute permission. For users to be able to execute files residing on mapped client drives, override
this default by editing the value of ExecuteFromMappedDrive in the registry on 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.
To enable users to execute files on mapped drives

1. After installing XenApp, run regedit.
2. Find the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cdm\Parameters\ExecuteFromMappedDrive
3. To grant users execute permission on mapped drives, set ExecuteFromMappedDrive to 1. This is
the default setting. To deny users execute permission on mapped drives, set ExecuteFromMappedDrive
to 0.
4. Restart the server.
8.7.5.1.2.2. Mapping Client COM Ports and Audio
Client COM port mapping allows a remote application running on the server to access devices attached to
COM ports on the client device. Client COM ports are not mapped automatically to server ports at logon, but
can be mapped manually using the net use or CHGCDM commands.
Client audio mapping allows applications running on the server to play sounds through a sound device on
the client device. The server can control the amount of bandwidth used by client audio mapping. Audio mapping
is configured with Citrix policies.
For more information about client COM port and audio mapping, see the administrators guides for the plugins
you plan to deploy.
8.7.5.1.3. 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:
Audio properties you configure for individual published applications
Audio related policies and settings you configure for specific connection types
Audio settings the user configures on the client device
For example, you can use audio-related connection policies to control bandwidth usage and server CPU
utilization. You can configure a policy rule to enable audio for connections where audio is essential, and
configure another rule to disable audio for connections where it is not essential.
You control the availability of speakers and microphones in sessions with policy rules. On the client device,
a single setting controls both. To enable audio on the client device, the user selects an audio quality level
from the Settings dialog box (for Program Neighborhood) or from the Options dialog box (for the Citrix
XenApp plugin). The connection policies you configure on the server determine what audio quality levels
are available to the user. Connection policies permitting, enabling audio on the client device turns on
speakers, microphones, or both.
Important: This topic covers aspects of enabling audio support on servers. To use audio in sessions,
users must also enable audio on the client device. For more information about enabling audio for plugins,
see the administrators guides for the specific plugins.
When audio is enabled, you can also use policy rules to fine tune compression levels and bandwidth allocation.
Note: The availability and quality of audio in sessions is determined by Terminal Services (TS Config)
settings and policies you configure. By default, Terminal Services settings are configured, whereas
XenApp policies are not. This means that Terminal Services settings apply by default, making medium
quality audio available in sessions until you configure XenApp policies that override the Terminal
Services settings. When configured, XenApp policies override Terminal Services settings.
8.7.5.1.3.1. To enable or disable audio for published applications
You can 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 rules and filters to further define under what conditions audio is available within the application.
1. In the Access Management Console, select the published application for which you want to enable
or disable audio, and select Action > Modify application properties > Modify all properties.
2. Under Advanced > Client options, select or clear the Enable legacy audio check box.
8.7.5.1.3.2. Limiting Bandwidth for Audio Throughput

Use policy rules 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 rules for groups of dialup users and for those who connect over a LAN, accommodating the different amounts of bandwidth each
group will have available.
To configure bandwidth limits for audio
In this procedure, you are editing an existing policy that applies to a specific group of filtered objects, such
as servers or users.
2. Select the policy for which you want to configure the rule.
3. From the Actions menu, select Properties.
4. Expand Bandwidth.
5. Select one of these folders:
Select Session Limits to specify the bandwidth available for audio in kilobits per second
(for example, 70Kbps).
Select Session Limits (%) to limit the bandwidth available for audio to a percentage of the
overall bandwidth available.
Note: If you want to specify bandwidth as a percentage using the Session Limits (%) rule,
you must enable the Overall Session rule in the Session Limits folder as well.
6. Select Audio to configure the rule and enter the bandwidth limit.
8.7.5.1.3.3. To configure audio compression and output quality
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. Use policy rules to configure
the compression levels you want to apply to sound files.
Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. Over dial-up connection
In this procedure, you are editing an existing policy that applies to a specific group of filtered objects (such
as, servers and users).
4. Select Client Devices > Resources > Audio > Sound quality and configure the rule.
5. Choose from these levels of sound quality:
Low sound quality; best performance. This setting is recommended for lowbandwidth connections. This setting 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 lowbandwidth connection.
Medium sound quality; good performance. (Default.) This setting 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 sound quality; lowest performance. This setting is recommended for connections
only 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.3
Mbps of bandwidth to play clearly. Transmitting this amount of data can result in increased
CPU utilization and network congestion.
Note: High sound quality increases bandwidth requirements by sending more audio data to
client devices and increases server CPU utilization.
8.7.5.1.3.4. Enabling 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 separate policy rules; you
must configure both to ensure that audio input and output are enabled.
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 dev
On the client device, users control audio input and output in a single stepby selecting an audio quality
level from the Settings dialog box (for Program Neighborhood) or from the Options > Session Options
dialog box (for the Citrix XenApp plugin).
By default, when you configure this rule, 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.
To enable audio input for sessions
In this procedure, you are editing an existing policy that applies to a specific group of filtered objects, such
as servers or users.
2. Select the policy for which you want to enable audio input.
4. Select Client Devices > Resources > Audio > Microphones.
5. Select Enabled and Use client microphones for audio input.
Note: Microphone input is supported on Citrix XenApp Plugin for Hosted Apps for Windows, Windows CE,
and Linux.
To enable audio output for sessions

2. Select the policy for which you want to enable audio output.
4.
4. Select Client Devices > Resources > Audio > Turn off speakers. By default, the client device
s speakers are turned off because this property is enabled.
5. Select Disabled.
8.7.5.1.3.5. Setting Up 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.
Note: The plugins for Linux and Windows CE do not support Philips SpeechMike products, nor does XenApp
on 64-bit operating systems.
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. Citrix recommends you
install Philips SpeechMike device drivers before installing XenApp. 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 on installation and enabling controls.
Within the Web Interface, set sound quality for the XenApp service site to at least medium quality. To enable
the use of Philips SpeechMagic Speech Recognition server in conjunction with WinScribe software, set
sound quality to high to enable accurate speech-to-text translation.
After installing XenApp, you can enable the use of Philips SpeechMike USB devices by implementing
certain changes to Microsoft Windows 2008 that include editing the Microsoft Windows registry.
Philips SpeechMike serial port devices do not require these changes.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall
Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
For information on enabling support for Philips SpeechMike USB devices, see Microsoft article http:
//support.microsoft.com/kb/961918.
To set sound quality for digital dictation devices
Services Console.
2. In the left pane, select Citrix Resource > Configuration Tools > Web Interface > XenApp
Services Site Name > config.xml.
3. From the Action menu, select Change session options.
4. In Change Session Options, select Color and Sound.
5. In the Sound area, select Medium quality or High quality.
8.7.5.1.4. 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 the Citrix XenApp plugin, you can configure
and allow users to configurethese activities:
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 the Citrix XenApp plugin.
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.
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 Web Interface topics.
8.7.5.1.5. 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.
Session Reliability
Auto Client Reconnect
ICA Keep-Alive
8.7.5.1.5.1. 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 user
s 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.
Users of Program Neighborhood can override the Session Reliability setting by selecting or clearing the
Enable session reliability option in their application or connection settings. Users of the Citrix XenApp
plugin and the Citrix XenApp Web Plugin cannot override the server setting.
By default, Session Reliability is enabled at the server farm level through the Access Management Console or
the Delivery Services Console, depending on the version of XenApp you have installed. You can customize
the settings for this feature from the server farms Properties page and modifying the Session Reliability
settings 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 Seconds to keep sessions active option 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.
Note: You can use Session Reliability in conjunction with Secure Sockets Layer (SSL).
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 Auto Client Reconnect 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 Seconds
to keep sessions active. After that, the settings you configure for Auto Client Reconnect take effect,
attempting to reconnect the user to the disconnected session.
Important: If the Session Reliability feature is enabled, the default port used for session
communication changes from 1494 to 2598.
8.7.5.1.5.2. Configuring Automatic Client Reconnection
The Auto Client Reconnect feature allows plugins for Windows, Java, and Windows CE to detect
broken connections and automatically reconnect users to disconnected sessions. When 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.
By default, Auto Client Reconnect is enabled at the server farm level through the Access Management Console
or the Delivery Services Console, depending on the version of XenApp you have installed. User reauthentication
is not required. You can customize the settings for this feature at the farm level and for individual servers. To
do this, select ICA on the corresponding farm or server Properties page and modify the Auto Client
Reconnect settings as appropriate.
Security in Auto Client Reconnect. 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 the plugin. 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 select
Require user authentication. Selecting this option displays a dialog box to users requesting credentials
when 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.
Configuring Auto Client Reconnect Settings. You can configure these Auto Client Reconnect settings:
Require user authentication upon auto reconnection. You can set this requirement at the server farm
level or for individual servers.
Enable or disable logging of reconnection events for the server farm or individual servers.
Enable or disable auto reconnect functionality on the client device using an ICA file or using Group Policy
to configure Session reliability and automatic reconnection on client devices.
To require user authentication for automatic reconnection and reconnection event logging, you can use the acrcfg
command or the Access Management Console (or Delivery Services Console, depending on the version of
XenApp you have installed). Reconnection event logging is disabled by default. For more information about the
acrcfg command, see XenApp Commands Reference.
Disable Auto Client Reconnect on the plugin for Windows by using the icaclient.adm file. For more
information about plug-in configuration, see XenApp Plug-in for Hosted Apps.
Settings for connections also affect Auto Client Reconnect.
Configuring Connections for Automatic Client Reconnection. By default, Auto Client Reconnect is enabled
at the server 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
the plugin.
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.
Logging Automatic Client Reconnection Events. To enable or disable log entries for automatic
reconnection events, open the ICA page in the Properties pages for the server farm or individual servers.
Logging is disabled by default. When logging is enabled, the servers System log captures information
about successful and failed automatic reconnection events to help with diagnosis of network problems.
Automatic reconnection can fail if the plugin 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.
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.
To configure a default Auto Client Reconnect setting for a farm
Services Console.
2. Select the farm.
3. From the Action menu, select Modify farm properties > Modify all properties.
4. From the Properties list, select Server Default > ICA > Auto Client Reconnect.
5. Choose one of these options:
Require user authentication. Select this option if you want users to be prompted for
credentials during automatic reconnection to an ICA session. Do not select this option if you
want users to be reauthenticated automatically during reconnection. Settings for automatic
client reconnection override similar settings configured in Microsoft Windows Group Policy.
Reconnect automatically (default setting). Select this option if you do not want users to
be prompted for credentials. Selecting this option also allows reconnection attempts to be logged.
6. If you selected Reconnect automatically in the previous step, you can select the Log
automatic reconnection attempts check box to record information about successful and failed
automatic reconnection events to each servers system log.
To configure an Auto Client Reconnect setting for a server

Services Console.
2. Select the server.
3. From the Action menu, select Modify server properties > Modify all properties.
4. From the Properties list, select ICA > Auto Client Reconnect.
5. If you want the server to use the default farm settings, select the Use farm settings check
box; otherwise, follow Steps 4 and 5 in the To configure an Auto Client Reconnect setting for a farm
procedure.
8.7.5.1.5.3. 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 Terminal 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 are not
using Session Reliability.
You can configure Keep-Alive as a farm-wide server default setting or as an individual setting for a
particular server.
To configure ICA Keep-Alive settings for a farm
Services Console.
2. Select the farm.
4. From the Properties list, select Server Default > ICA > Keep-Alive.
5. Select the ICA Keep-Alive time-out value (1-3600 seconds) check box to allow users to reconnect
to disconnected sessions and resume working where they were interrupted in their published applications.
Do not select 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.
ICA Keep-Alive settings override Keep-Alive settings that are configured in Microsoft Windows Group Policy.
Important: Servers running the Citrix Access Gateway intercept packets being sent from servers
to client devices. Set Keep-Alive values on the Access Gateway servers to match Keep-Alive values
on XenApp servers. Doing so allows ICA sessions to be changed from active to disconnected as intended.
6. Specify an interval between 1 and 3600 seconds.
Do not select 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.
ICA Keep-Alive settings override Keep-Alive settings that are configured in Microsoft Windows Group Policy.
Important: Servers running the Citrix Access Gateway intercept packets being sent from servers
to client devices. Set Keep-Alive values on the Access Gateway servers to match Keep-Alive values
on XenApp servers. Doing so allows ICA sessions to be changed from active to disconnected as intended.
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.
To configure ICA Keep-Alive settings for a server

Services Console.
2. Select the server.
4. From the Properties list, select ICA > Keep-Alive.
box; otherwise, follow Steps 4 and 5 in the To configure ICA Keep-Alive settings for a farm procedure.
8.7.5.2. Managing and Monitoring XenApp Sessions
XenApp lets you monitor sessions either by displaying their status or monitoring the session directly
through shadowing. You can also interact with sessions directly by saving disconnected sessions,
terminating sessions and processes, and sending messages to users.
In general, if a session disconnects in which a user is running multiple applications, the applications continue
to run on the server until the user closes the applications. However, 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.
To end the applications session, exit the application and log off from the farm. If users disconnect without
exiting the application or logging off from the farm, their session remains active. In this case, when
they reconnect from another client device, XenApp reconnects them to the same session.
8.7.5.2.1. Monitoring Session Status
You can display the incoming and outgoing traffic for a session. When you display the session status, you can
see the number of bytes, frames, bytes per frame, and frame errors; the percentage of frame errors; timeout errors; and compression ratios.
The session information that appears in the console is in table format and includes details that help you
identify the various types of sessions and the users associated with the sessions.
To display information about a session
Services Console.
2. Select the server on which you want to monitor sessions.
3. From the Action menu, select Change display > Sessions. The right pane of the console displays
all sessions running on the server.
4. Click Choose columns to specify the columns that you want to display and the order in which you want
to see them.
5. Select a session and these tasks become available: Reset, Log off, Disconnect, Send Message, and
Shadow.
6. Click Show more tasks for the selected items to obtain a list of available displays including
Client Cache, Session Information, Client Modules, and Processes.
To display information about active sessions

Services Console.
2. Select a server.
3. From the Action menu, select Change display > Sessions. Information about active sessions appears
3.
in the details pane. Each row in the table lists details for one session. The following column labels
appear on tabs that display session information.
User. The name of the user account that initiates a session. In the case of anonymous
connections, the user name is a string with the letters Anon followed by a session number.
Session ID. A unique number that begins with 0 for the first connection to the console.
Listener sessions are numbered from 65,537 and numbered backward in sequence.
Type. The type of session ICA or RDP.
Application The name of the published application running within this session.
State. A sessions state is listed as Active, Listen, Idle, Disconnected, or Down.
Client name. The name of the client device that is running the session.
Logon Time. The time at which the user logged on.
Server. The server on which the selected application is running.
To display session status

Services Console.
2. Select the server hosting the session.
3. From the Action menu, select Change display > Sessions.
4. Select the session for which you want to display the status.
5. From the Action menu, select All Tasks > Status.
A Session Status dialog box appears.
To display session properties
Services Console.
2. Select the server hosting the session.
4. Select a session, click Show more tasks for the selected items, and select one of these
menu commands:
Client Cache. Displays the session cache, including the client and bitmap caches.
Session Information. Displays the details of the session, including the client name, build
number, directory, and address.
Client Modules. Lists the client modules associated with the session.
Processes. Lists the processes associated with the session.
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 Access Management Console (or
Delivery Services Console, depending on the version of XenApp you have installed) you are running. The
auto-refresh settings apply only to the Access Management Console or Delivery Services Console you are
running and not other instances of the console on your network.
Note: Do not enable this feature if you have many sessions, because it can impact performance.
1. In the left pane, select one of these nodes (depending on what type of user data you want to
refresh automatically):
1.
The farm for which you want to refresh the user data automatically
The server for which you want to refresh the user data automatically
The application for which you want to refresh the user data automatically
2. In the center pane, from the Other Tasks section or the Common 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 server folders. Selecting this option enables
automatic refreshing of each servers folder organization. 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).
8.7.5.2.2. 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
Access Management Console (or Delivery Services Console, depending on the version of XenApp you
have installed) or the Shadow Taskbar.
You enable shadowing on a server when you install 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 Setup,
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 be capable of supporting 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 Terminal Services Configuration tool.
8.7.5.2.2.1. 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 are required to enter your user name and password to start an ICA session on the server running the
Shadow Taskbar.
Note the following:
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
To configure options, click an empty area of the Shadow Taskbar and press SHIFT + F10. To switch to a
shadow session, click its button in the Shadow Taskbar.
To close the Shadow Taskbar
1. Click an empty area of the Shadow Taskbar and press ALT + F4.
To select users for shadowing

Use the Shadow Session dialog box to select users to shadow. 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.
The Shadowed Users list also displays the user name of currently shadowed users next to the shadow icon. If
a shadowed user is removed from the Shadowed Users list, the shadow session ends when you click OK.
1. On the Shadow Taskbar, click the Shadow button.
2. In the Available Users list, select the user to shadow and click Add.
Tip: You can add multiple users to the Shadowed Users list. Shadowing is initiated for all users in
the Shadowed Users list when you click OK.
To end a shadowing session

1. On the Shadow Taskbar, click the Shadow button.
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.
8.7.5.2.2.2. To view user sessions with the console
Depending on the version of XenApp you have installed, when you use the Access Management Console
or Delivery Services Console for shadowing, you must start each shadowing session individually; if you
select multiple sessions to shadow, the Shadow command and button are not available. To start
shadowing multiple sessions at once, use the Shadow taskbar.
To use the console for shadowing, you must have Program Neighborhood installed on the computer hosting
the console.
Services Console.
2. In the left pane, select the server to which the user is connected.
4. Select the required session, and from the Action menu, select Shadow. If the users permission
is required, the session does not appear until the user grants permission.
5. On the Shadow dialog box, select the key sequence that will end shadowing.
8.7.5.2.2.3. Enabling Logging for Shadowing

After installation, you can enable shadow logging and configure it so that it outputs 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. If 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 to 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. Because only shadowing events go in to
this file, they are more centralized and easier to review.
To configure shadow logging to log in a central file
When you enable this option on a XenApp server, the shadowing events are logged in a central file on that server.
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
When you enable this option on a XenApp server, the shadowing events are logged in the Application log of
the Windows Event log.
Services Console.
2. Select the server in the left pane.
4. From the Properties list, select XenApp > Shadow Logging
5. Select the Log shadowing sessions check box if you want all shadow sessions initiated from the
server to be written to the Application log.
8.7.5.2.2.4. 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 are prompted to configure shadowing settings during XenApp Setup. If you choose to
prohibit shadowing during Setup, you cannot enable shadowing with user policies.
You enable user-to-user shadowing by creating policies that define users who can shadow. You then assign
the policies to the users to be shadowed.
To create a user policy to define users who can shadow
1. Create a user policy that identifies the users who can shadow other users sessions.
2.
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

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. Open the Sales Group Shadowing policys properties by selecting the policy and choosing Actions
> Properties.
3. Open the Shadowing folder under User Workspace in the left pane. Select the rule named
Configuration.
1. Set the rules state to enabled by selecting Enabled.
2. Select Allow shadowing to enable shadowing. Because the Sales Manager may work with
sensitive data, select the option Prohibit being shadowed without notification. If the
Sales Manager does not want other users to be able to take control of his mouse and
keyboard, select the option Prohibit remote input when being shadowed.
4. In the left pane of the property sheet, select the rule named Permissions.
5. Set the rules state to enabled by clicking Enabled.
6. Click Configure to select the users who will shadow the Sales Manager. To allow the members of the
Sales Department to shadow the Sales Manager, select the Sales user group and then click Add. The
user group is listed in the Configured Accounts list. Click OK when you are done adding users. The
users and user groups you added to the Configured Accounts list appear in the right pane of the policy
s property sheet. By default, the shadowing permission for each user or user group is set to Allow.
You can deny shadowing permissions by clicking Deny.
After you create the policy and configure the rules, you must assign the policy to the users who you want to
be shadowed.
Note: You can create and apply a policy that allows Novell Directory Services (NDS) users to be
shadowed. However, you cannot configure NDS users to have shadowing permissions.
Example: To assign the shadowing policy to users

This procedure shows the assignment to the users in the Sales group of the policy you created.
1. Select the Sales Group Shadowing policy and choose Actions > Policy > Apply this policy to.
2. Select Users in the left pane and select Filter based on users. Select the users you want to
be shadowed. To allow the Sales Manager to be shadowed, select the domain of which the manager is
a member. Click Show Users to display the individual user accounts in the selected domain.
3. Select the Sales Managers user name and then click Add to display the user account in the
Configured Accounts list.
Important: 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 publish the Shadow taskbar utility to the users you want to be able to shadow, see .
To merge shadowers in multiple policies
Use this procedure to allow merging of shadow policies. If you create multiple shadowing policies, you must
also select this option. If you do not enable this option, the resultant policy uses the shadowing policy with
the highest priority and ignores the rest of the shadowing policies, even if they do not conflict.
1. In the Access Management Console, select the farm in the left pane.
3. From the Properties list, select Farm-wide > XenApp > Shadow Policies.
4. Under Shadow policies, select the Merge shadowers in multiple policies check box.
8.7.5.2.3. Managing User Sessions
Depending on the version of XenApp you have installed, you can use the Access Management Console or
the Delivery Services Console to manage user sessions.
You can view information about active sessions and also perform session management activities, including
logging off, disconnecting, and sending messages to users. You can select client sessions and choose
commands to manage the sessions through the Action menu or the Tasks list that appears at the bottom of
the details pane.
If a connection breaks, a session using the connection can remain active until its state is changed by Auto
Client Reconnect or ICA Keep-Alive settings, or by a Citrix administrator.
You can perform these tasks to better manage your disconnected sessions:
Disconnecting sessions
Ending sessions
Disconnecting Sessions and Terminating Processes

You can use the console to disconnect a user session from a server or terminate a process in a session.
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. 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. When a session is disconnected, the word Disconnected
appears in the State column on the tabs where session information appears.
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 console 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 be capable of supporting the same video resolution as the disconnected session.
Resetting a session with the Reset command terminates all processes that are running in that session. You
can use the Reset command to remove remaining processes in the case of a session error. However, resetting
a session can cause applications to close without saving data.
If you reset a disconnected session, the word Down appears in the State column for the session. When
you refresh the console 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 are identified by the word Listen in the
State column. 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
who are connected to the server.
8.7.5.2.3.1. To terminate processes in a users session
1.
Services Console.
2. In the left pane, right click the server to which the user is connected and select Change display > Users.
The right pane of the console displays all users connected to the server.
3. Select the users session for which you want to terminate the process.
4.
In the Tasks list at the bottom of the right pane, click Show more tasks for the selected items.
5. In Available Displays, click Processes.

6. Select the process you want to terminate.
7. From the Action menu, select Terminate.
Note: Terminating a process may abruptly end a critical process and leave the server in an unusable state.
8.7.5.2.3.2. To display session properties
Services Console.
2. In the left pane, select the server hosting the session.
3. From the Action menu, select Change display > Sessions. The right pane displays all sessions
running on the server.
4.
Select a session, click Show more tasks for the selected items, and select one of these
menu commands:
Client Cache. Displays the session cache, including the client and bitmap caches.
Session Information. Displays the details of the session, including the client name, build
number, directory, and address.
Client Modules. Lists the client modules associated with the session.
Processes. Lists the processes associated with the session.
8.7.5.2.3.3. To connect to a users session from Program Neighborhood

To connect to a disconnected or live session remotely through Program Neighborhood, your session must
support the video resolution of the disconnected session. Also, you can connect only to disconnected sessions
that were disconnected from the Access Management Console (or Delivery Services Console, depending on
the version of XenApp you have installed).
1. Using Program Neighborhood, create a direct custom connection to the server hosting the session.
1. In Program Neighborhood, create a Custom ICA Connection directly to the server.
2. Use your new custom ICA connection to connect to the desktop of the server hosting the session.
2. After you authenticate to the host server, open the Access Management Console or Delivery
Services Console.
3.
In the left pane, select the server to which the user was connected (that is, the server to which you
just connected).
5. Select the session you want to log off and from the Action menu, select Connect.
8.7.5.2.3.4. 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 is not responding or malfunctions.
Services Console.
3.
From the Action menu, select Change display > Sessions. The right pane of the console displays
3.
4. Select the session you want to reset, and from the Action menu, select Reset. You can select and
reset multiple sessions at the same time.
8.7.5.2.3.5. To log off from a session
Important: Ending users sessions with the Logoff command can result in loss of data if users do not
close their applications first. Send a message to warn users to exit all applications if you need to log off
their sessions.
Services Console.
3.
From the Action menu, select Change display > Sessions. The right pane of the console displays
4. Select the session you want to log off and from the Action menu, select Log off. You can select and log
off multiple sessions at the same time.
5. Confirm the logoff when prompted.
8.7.5.2.4. To send a message to one or more users
You can send a message that appears in user sessions. For example, you can broadcast information about
new applications and upgrades, request a shadowing session, or warn of system shutdowns.
Services Console.
2. In the left pane, select the server to which the users are connected.
Tip: To send a message to all user sessions in the farm, you can select the Farm node instead of
a server.
3. From the Action menu, select Change display > Users.
4. In the right pane, select the sessions to which the user is connected.
5. Select one or more sessions and from the Action menu, select Send Message.
6. In the Send Message dialog box, edit the title of the message, if required, and enter the content of
the message in the Message text box.
The message is sent to users immediately.
8.7.5.3. Controlling Client Connections in XenApp
You can control XenApp client connections in different places:
XenApp policies
Application Publishing
Terminal Services Configuration
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 at the operating system level, in TS Config, and specified 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.
Terminal Services Configuration
Terminal Services Configuration (TS Config), which is part of Windows Server 2008, lets you define
XenApp connection settings similar to the ones found in XenApp policies. However, these TS Config settings
must be defined on a per-server basis. Because defining settings using TS Config requires setting them on
each server in your farm, Citrix recommends using TS Config to define connection settings only for test farms
or very small server farms.
Active Directory
Citrix provides a Group Policy Object (GPO) template, the icaclient.adm, that contains Citrix-specific rules
for securing client connections. This GPO lets you configure rules for network routing, proxy servers,
trusted server configuration, user routing, remote client devices, and the user experience. The icaclient.
adm template is in the XenApp installation media. For more information about the icaclient.adm template, see the
XenApp Plug-In for Hosted Apps for Windows.
8.7.5.3.1. 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 controls
This procedure specifies the types of client connections from which users can start sessions. Use this procedure
if you want to affect all servers on your farm. If you want more granular control, perform this task by
configuring a policy.
Services Console.
2. In the left pane, select the farm.
4. From the Properties list, select Farm-wide > Connection Access Controls.
5. Select one of these options:
Any connections (selected by default) allows access to published applications through
any connection.
Citrix Access Gateway, Citrix XenApp plugin, 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).
8.7.5.3.2. 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:
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 the
Access Management Console. (You cannot configure connection limits in the plugins.)
The Access Management Console provides two types of connection limits:
Limit type
Description
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. If you want to limit connections, enable these settings.
8.7.5.3.2.1. 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 you prevent over-consumption of server resources by a few users.
A limit on connections applies to each user who connects to the server farm. A users active sessions
and disconnected sessions are counted for the users 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 plugin 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 limit concurrent connections to a server farm
Services Console.
2. In the left pane, select the farm and select Action > Modify farm properties > Modify all properties.
3. From the Properties list, select Farm-wide > Connection Limits.
4. Select Maximum connections per user to limit each users concurrent connections. Enter the number
of concurrent connections to allow for each user. For example, you can limit users to a maximum of
five connections. If a user tries to launch a sixth connection, the server denies the connection request
and records the users name and the time in the System log.
5. If you want the connection limitation to apply to everyone, including local administrators, select
Enforce limit on administrators.
Important: Limiting connections for Citrix administrators can adversely affect their ability to
shadow other users. By default, local administrators are exempt from the limit so they can establish
as many connections as necessary.
8.7.5.3.2.2. Sharing Sessions and Connections
Depending on the plugin, when a user opens an application, it can either appear in a seamless or non-seamless
window. These window modes are available for most plugins, including the Web Interface, Citrix XenApp
plugin, and Program Neighborhood.
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 nonseamless window mode. This table provides examples of when you might want to publish desktops
and applications.
If your users will be using...
then you...
Local computers
Might want to publish desktops or individual applications.
Local computers with locally

installed applications
Might want to publish individual applications.
Thin clients
Must publish desktops.
Kiosks
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, the plugin 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.
Session sharing always takes precedence over load balancing. That is, if users launch an application that
is published on the same server as an application they are already using but the server is at capacity, XenApp
still opens the second application on the server. Load Manager does not transfer the users request to
another server where the second application is published.
8.7.5.3.2.3. 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

Services Console.
2. In the left pane, select Citrix Resources > XenApp > yourfarmname > Applications and select
the published application or desktop you want to modify.
3. From the Actions menu, select Modify application properties > Modify all properties.
4. In the Properties tree, select Limits.
5. On the Limits page, select one or both of these options:
Limit instances allowed to run in server farm. Select this option and 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 type 10 in Maximum instances 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. Select this option to prevent any
user from running more than one instance of this application at the same time.
8.7.5.3.2.4. 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:
Maximum connections per user, as set in the server farm properties
Application instance limits, as set for a published application
Application instances per user, as set for a published application
To enable logging of connection denial events

Services Console.
2. Select a farm and select Action > Modify farm properties > Modify all properties.
3. Open the Connection Limits page in the farms Properties list.
4. Select Log over-the-limit denials.
8.7.5.3.3. Controlling Connections with Terminal Services Configuration
Important: Citrix recommends controlling connections by using Citrix policies. While you can use the
Terminal Services Configuration (TS Config) tool, Citrix policies are better suited for farm-level changes.
Using the TS Config tool is more time-consuming and requires that you specify settings on each XenApp server.
You can control connection settings for individual servers using TS Config, which is a snap-in you can add to
the Microsoft Management Console (MMC). You can specify these settings in either TS Config or XenApp policies:
Redirection, including disabling drive mapping
Printing
Ports
The clipboard
Other settings, including color depth on plugins
You might need to use the TS Config in these situations:
If you want to configure a test farm or create a very small farm and you do not want to configure
policies, specifying settings in TS Config might be easier than configuring policies.
When you want to configure certain TS Config policies that do not have a corresponding Citrix policy,
such as policies that correspond with these tasks:
Idle Session Limit. In the ICA-tcp properties in TS Config, select the Sessions tab, enable
Override user settings and then specify the Idle Session Limit.
Restrict users to one session. This setting is in Terminal Services Configuration in the
Server Manager. Citrix strongly recommends that you turn this setting off because it might
affect your user sessions negatively.
For more information about TS Config, see your Microsoft documentation.
To control connections on a server with TS Config
To use TS Config to control connections on a remote computer that has XenApp installed, XenApp must
be installed on the local computer; otherwise, the ICA Settings tab on the properties dialog box does not appear.
This procedure assumes that you already added the TS Config tool snap-in to the MMC. If not, do so
before proceeding. See your Microsoft documentation for details as needed.
1. From the Start menu, select Administrative Tools > Terminal Services > Terminal
Services Configuration.
2. With Connections selected in the left pane of the console that opens, right-click ICA-tcp in the right
pane and select Properties.
3. Using the tabs that appear in this properties dialog box, you can select options for configuring
your connections.
Note: The Citrix Connection Configuration tool is no longer available. It has been replaced by the ICA-tcp
entry in TS Config.
8.7.5.3.4. 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
Services Console.
2. Select the server and select Action > All Tasks > Disable logon.
Note: To reenable disabled logons, use the Enable logon option.

8.7.5.4. Optimizing User Sessions for XenApp
Updated: 2010-03-09
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:
HDX 3D Browser Acceleration. Optimizes the responsiveness of graphics-rich HTML pages in
published versions of Microsoft Outlook Express, Outlook 2003, Windows Mail, and Internet Explorer.
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 online plug-in. You may
reduce bandwidth consumption if you disable these options.
8.7.5.4.1. Optimizing Web Page and Email Responsiveness

As both Web pages and HTML-based email get richer in graphics content, more bandwidth is used. You can
use SpeedScreen Browser Acceleration to optimize the responsiveness of image-rich Web pages and email
in published versions of Microsoft Internet Explorer, Outlook 2003, and Windows Mail. With SpeedScreen
Browser Acceleration, the user can scroll the pages and use the Back and Stop buttons immediately while
image files download in the background.
To further accelerate the accessibility of Web pages and email, enable JPEG compression with
SpeedScreen Browser Acceleration. JPEG compression lets you find a balance between the quality of JPEG files
as they appear on client devices and the amount of bandwidth the files consume on their way from server
to client. JPEG compression results in slightly lower image resolution and slightly higher resource consumption
on both server and client. It does not affect JPEG files rendered by applications other than those mentioned above.
Users with limited bandwidth connections benefit the most from SpeedScreen Browser Acceleration.
Users connecting on the LAN may see improvement only when networks are congested. Enabling this feature
uses more resources on both servers and clients.
Enabling SpeedScreen Browser Acceleration results in:
Background image delivery. Users can click Back and Stop while images are being downloaded in
the background.
Progressive drawing. Users can interact with elements of a page while the page continues to download.
Responsive scrolling. Scrolling speed and responsiveness is similar to scrolling in a local browser.
JPEG image recompression. You can select a compression level for JPEG images. Higher
compression results in less bandwidth used but lowers image quality.
Adaptive JPEG image recompression. The available bandwidth is used to determine how much
images are compressed. If enough bandwidth is available, images are not compressed. You can limit
the compression level.
SpeedScreen Browser Acceleration requires at least Version 7.0 or later of the Presentation Server Clients
for Windows or Citrix XenApp Plugin for Hosted Apps 11.x for Windows, Internet Explorer 5.5 through 7.0,
and High Color (16-bit) or greater connection color depth.
Speed Screen Browser Acceleration is not supported with Microsoft Outlook 2007; Citrix supports Speed
Screen Browser Acceleration for Microsoft Outlook 2003 only.
By default, SpeedScreen Browser Acceleration is enabled at the server farm level.
The SpeedScreen Browser Acceleration feature possesses the following limitations:
Supports JPEG and nontransparent GIF images.
Not compatible with Adobe Flash.
Does not support images that are resized using dimensions specified in the HTML of a Web page
which might be different than the actual width and height of the image. In this case, Internet
Explorer grows or shrinks the image as required to fit it into the size specified in the HTML. Images that
are resized in HTML are drawn in legacy mode.
Note: Image resizing in HTML described here is not the same as the Internet Explorer Automatic
Image Resizing feature.
8.7.5.4.1.1. Effects of Restricting Animations in Internet Explorer

At installation XenApp disables the Internet Explorer setting Play animations in web pages for all users on
the server. For optimal performance with SpeedScreen Browser Acceleration, Citrix recommends that you
keep this setting disabled.
When Play animations in web pages is enabled, animated GIF images are rendered as animations
and SpeedScreen Browser support for GIF images is disabled. When this feature is disabled,
SpeedScreen Browser Acceleration support for GIF images is enabled. The secondary benefit is a
bandwidth reduction due to the absence of animations that consume significant bandwidth.
If a user subsequently enables Play animations in web pages, only an administrator can modify it again
by making changes to specific values in the registry.
Users can access Play animations in web pages by opening Internet Explorer and selecting Tools >
Internet Options > Advanced or by navigating to Internet Options under Control Panel.
8.7.5.4.1.2. SpeedScreen Browser Acceleration Limitations
The SpeedScreen Browser Acceleration feature possesses the following limitations:
Supports JPEG and nontransparent GIF images.
Not compatible with Adobe Flash.
Does not support images that are resized using dimensions specified in the HTML of a Web page
which might be different than the actual width and height of the image. In this case, Internet
Explorer grows or shrinks the image as required to fit it into the size specified in the HTML. Images that
are resized in HTML are drawn in legacy mode.
Note: Image resizing in HTML described here is not the same as the Internet Explorer Automatic
Image Resizing feature.
8.7.5.4.1.3. Configuring SpeedScreen Browser Acceleration

When ICA connections have limited bandwidth, downloading images can be slow. SpeedScreen
Browser Acceleration can improve responsiveness for users when they are using Internet Explorer 5.5 or later
as published applications. Specifically, this feature helps ensure that images display cleanly and scrolling
is smooth in Web browsers.
You can configure SpeedScreen Browser Acceleration as a farm-wide server default setting or as an
individual setting for a particular server.
Do not enable Flash content in your Web browser display if you want SpeedScreen Browser Acceleration to
be used. Regardless of whether you configured the optimization settings for Speedscreen Flash
Acceleration, SpeedScreen Browser Acceleration does not work when Flash content is on a page.
SpeedScreen Browser Acceleration is disabled if Internet Explorer is running in Protected Mode. However, you
can turn on SpeedScreen Browser Acceleration even when Internet Explorer is running in Protected Mode
by adding EnableProtectedModeSpeedBrowse and setting it to 1 in
the HKEY_LOCAL_MACHINE\SOFTWARE\CITRIX\SpeedBrowse registry key.
To configure SpeedScreen Browser Acceleration for a farm
Services Console.
4. From the Properties list, select Server Default > SpeedScreen > Browser Acceleration.
5. Select the SpeedScreen Browser Acceleration check box to improve responsiveness when users
run HTML-capable published applications.
6. Select the Compress JPEG images to improve bandwidth check box to improve bandwidth.
7. Select one of these options if the ICA connections have very low bandwidth:
Image compression levels. Select High, Medium, or Low compression for JPEG images. The
higher the compression, the less bandwidth used and the lower the image quality. Select High
when bandwidth usage is most important, such as when running a published application over a
WAN connection. Select Low if image quality is more important than bandwidth usage.
Adjust compression level based on available bandwidth. Select this option if the
available bandwidth can vary for ICA connections. The available bandwidth and image size are
used to determine how much images are compressed. If enough bandwidth is available, images
are not compressed.
Note: Compressing JPEG images reduces image quality.
To configure SpeedScreen Browser Acceleration for a server

Services Console.
2. In the left pane, select the server.
4. From the Properties list, select SpeedScreen > Browser Acceleration.
5. If you want the server to use the default farm settings, select the Use farm settings (available
server level only) check box.
8.7.5.4.2. Optimizing Audio and Video Playback
SpeedScreen Multimedia Acceleration improves the users experience of accessing published audiovisual applications and content. Enabling this feature increases the quality of audio and video in ICA sessions 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:
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 SpeedScreen 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 client notification area.
Without SpeedScreen 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 SpeedScreen 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.
SpeedScreen 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 SpeedScreen 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.
By default, audio is disabled on any custom connections created with Program Neighborhood. To allow users
to run multimedia applications in ICA sessions, turn on audio or give the users permission to turn on
audio themselves in Program Neighborhood. By default, all other clients and methods are configured with
audio enabled and medium sound quality.
Other requirements for using SpeedScreen Multimedia Acceleration are:
Users must be running a XenApp Plugin.
The client device must have the same memory and processing speed as is needed for playing
multimedia locally.
The correct codec, or compression algorithm, to decompress the media file type used (MPEG for
example) must reside on the client device. Windows clients 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 SpeedScreen Multimedia Acceleration are:
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, and
unprotected Windows Media Video (WMV) and Windows Media Audio (WMA)
Note: SpeedScreen Multimedia Acceleration does not support media files protected with Digital
Rights Management (DRM).
When the quality of media playing on a client device deteriorates, possible solutions are:
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
SpeedScreen 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.
Note: Volume and balance selections do not work with RealOne in an ICA session. Users can still
control volume and balance outside the RealOne application with controls on the client.
By default, SpeedScreen Multimedia Acceleration is enabled at the server farm level.
8.7.5.4.2.1. Configuring SpeedScreen Multimedia Acceleration
You can configure SpeedScreen Multimedia Acceleration as a farm-wide server default setting or as an
individual setting for a particular server.
Note: By default, audio is disabled on the client. 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 client interface.
To configure SpeedScreen Multimedia Acceleration for a farm

Services Console.
4. From the Properties list, select Server Default > SpeedScreen > Multimedia Acceleration.
5. Select the SpeedScreen Multimedia Acceleration check box. By default, SpeedScreen
Multimedia Acceleration is enabled. Turn off this setting only if playing media using
SpeedScreen Multimedia Acceleration appears worse than when rendered using basic ICA compression
and regular audio. This is rare but can happen under low bandwidth conditions; for example, with media
in which there is a very low frequency of key frames.
6. Choose one of these options:
Accept the recommended default buffering of five seconds.
Select Custom buffer time in seconds (1-10) and enter another figure.
You can see how much server memory the selected buffer can use by changing the buffer time.
To configure SpeedScreen Multimedia Acceleration for a server

Services Console.
4. From the Properties list, select SpeedScreen > Multimedia Acceleration.
5. If you want the server to use the default farm settings, select the Use farm settings (available
server level only) check box.
8.7.5.4.3. Optimizing Flash Animations
SpeedScreen Flash Acceleration allows you to optimize the way XenApp renders and delivers Adobe
Flash animations to users. To display Flash animations 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 animations 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 animation 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.
SpeedScreen Flash Acceleration improves the users session responsiveness by forcing 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 animations.
By default, SpeedScreen Flash Acceleration is enabled at the server farm level. However, the Web browser,
and not this feature, controls whether or not Flash content appears. SpeedScreen Flash Acceleration lets
you specify the optimization settings when Flash is present on a Web page.
You can configure the optimization settings for SpeedScreen Flash Acceleration as a farm-wide server
default setting or as an individual setting for a particular server.
Note: SpeedScreen Flash Acceleration now supports Adobe Flash 9.
To configure SpeedScreen Flash Acceleration for a farm

Services Console.
4. From the Properties list, select Server Default > SpeedScreen > Flash Acceleration.
5. Select the Enable Adobe Flash Player check box to configure Flash optimization settings.
6. Under Optimize Adobe Flash animation options, you can select one of these options to reduce
the amount of Flash data sent from the server to client devices:
Do not optimize. Select this option if bandwidth is not limited.
Restricted bandwidth connections. 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.
All connections. Select this option to always reduce the amount of Flash data sent to users.
The result is that CPU usage is minimized on the servers on which users are using Flash
within Internet Explorer.
7. From the Properties list, select Server Default > ICA > Display and select the Discard queued
image that is replaced by another image check box to reduce bandwidth consumption and
improve video playback and server scalability.
To configure SpeedScreen Flash Acceleration for a server

Services Console.
4. From the Properties list, select SpeedScreen > Flash Acceleration. If you want the server to use
the farm settings, select the Use farm settings (available on server level only) check box. If not,
follow Steps 4 to 5 in To configure SpeedScreen Flash Acceleration for a farm.
5. From the Properties list, select ICA > Display. If you want the server to use the farm settings, select the
Use farm settings (available on server level only) check box.
8.7.5.4.4. Optimizing Throughput of Image Files
Updated: 2010-01-20
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.
Unlike the other SpeedScreen features, SpeedScreen Image Acceleration is not configured through the
Access Management Console or Delivery Services Console. This feature is enabled by default. You can use
policy rules to override the default settings and accommodate different user needs by applying different levels
of image compression to different connections. To do this:
4. Select HDX 3D > Progressive Display and configure the rule.
Choose no or low compression for users who need to view images at original or near original quality levels.
You can accelerate image throughput by choosing one of four compression levels per policy rule:
Lossy compression level
Image quality
Bandwidth requirements
High compression
Low
Lowest
Medium compression
Good
Lower
Low compression
High
Higher
No compression
Same as original
Highest
If no policy rule is configured, SpeedScreen Image Acceleration applies image compression as follows:
Medium compression for all connections. Medium compression amounts to slightly better performance due
to slightly lower image quality. Use policy rules to override the default behavior as appropriate.
To configure SpeedScreen Image Acceleration without enabling SpeedScreen Progressive Display, after
enabling the policy rule and choosing Compression level, for SpeedScreen Progressive Display
compression level, choose Disabled; no progressive display.
8.7.5.4.5. Optimizing Display of Image Files
As part of the HDX 3D policy rule (HDX 3D > Progressive Display), you can also 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.
To configure Progressive Display without enabling Image Acceleration, after enabling the policy rule and
choosing the HDX 3D Progressive Display compression level, for Compression level, choose Do not use
lossy compression.
8.7.5.4.6. 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.
8.7.5.4.6.1. 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 finetune 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.
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.
8.7.5.4.6.2. 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:
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
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

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.
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.
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
To configure custom latency reduction settings for an individual application

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:
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:
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.
8.7.5.4.6.3. 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.
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.
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.
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.
Limit local text echo forces behavior in input fields in nonstandard applications that may
not behave correctly. Select one of the two available settings:
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%.
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 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.
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.
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.
8.7.5.4.6.4. 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:
1. Drag the pointer onto the input field window for which SpeedScreen behavior needs to
be customized.
2. 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.
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.
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.
8.7.5.4.7. Configuring ICA Display Settings
To configure ICA display settings for a farm

Services Console.
4. From the Properties list, select Server Default > ICA > Display.
5. Select the Discard queue image that is replaced by another image check box to improve
response when graphics are sent to the client. 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.
6. Select the Cache image to make scrolling smoother check box if you want to make scrolling
smoother because sections of an image can be retrieved from the cache.
7. Enter the maximum memory to be used on the server for each client connection in the
Maximum memory to use for each sessions graphics (KB) box.
You can specify an amount in kilobytes from 300 to 65536. 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 ICA connections with these settings.
8. Under Degradation bias, select one of these options to prioritize when the session memory limit
is reached.
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.
9. Select the Notify user of session degradation check box to display a brief explanation to the user
when a session is degraded. Possible reasons for degradation include exceeding the memory limit
and connecting with a client that cannot support the requested parameters.
To configure ICA display settings for a server

Services Console.
4. From the Properties list, select ICA > Display.
box; otherwise, follow Steps 4 and 8 in To configure ICA display settings for a farm.
8.7.5.4.8. To configure ICA browser settings for a server
ICA browser settings control whether or not a server responds to client broadcast messages. If these options
are enabled, all servers in your network respond to broadcast messages. If you are running
Program Neighborhood with HTTP Browsing, do not enable these options. This procedure applies only
to environments with Program Neighborhood.
Services Console.
4. From the Properties list, select ICA > Browser.
5. Select either of these check boxes:
Select Create browser listener on UDP network to enable the ICA browser on the
selected server respond to any ICA browser network packets on UDP networks. This setting
is enabled by default. Each server that has this setting enabled has a listener on the
network. Clearing this setting disables the listener for a server. In large environments, you
may want to clear this check box on specific servers because having a listener enabled for
every server on your network consumes network resources. Clearing this check box on some
servers in large environments allows you to optimize your network.
Select Server responds to client broadcast messages to allow the server it is enabled on
to broadcast messages on the network and responds to messages clients broadcast. This setting
is disabled by default. Enabling it makes configuring Program Neighborhood easier; users do
not have to enter an address in Program Neighborhood for the server to which they want to connect.
8.7.6. Securing Server Farms

Consult with your organizations security experts for a comprehensive security strategy that best fits your needs.
The Citrix XenApp plug-ins are compatible with and function 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.
8.7.6.1. Securing Access to Your Servers
An important first step in securing your server farm is securing access to the servers.
Securing XenApp Advanced Configuration
The XenApp Advanced Configuration tool can be used to connect to any server in your farm. Run the tool only
in environments where packet sniffing cannot occur. Also, ensure that only administrators have access to the
tool. You can set NTFS permissions so that non-administrators do not have Execute permission for the
tool executable (Ctxload.exe).
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.
Installing and configuring the Simple Network Management Protocol (SNMP) service
The SNMP service is not installed by default on computers running Windows Server 2003 and 2008. If you
install this service, you must configure the SNMP community string. You may also want to create a white list
that limits the remote IP addresses that have access to the SNMP service.
The Windows SNMP service has many read/write privileges by default; however, you must give
read/create permissions to the SNMP service for administrative tasks, such as logoff and disconnect
through Network Manager. If you use Network Manager or other SNMP management software for monitoring
the server only (and not remote management), Citrix recommends that the privileges be read only. If no
SNMP consoles are used, do not install SNMP components on the server.
You can configure the SNMP community and designated management consoles to prevent unauthorized
access. Configure SNMP agents to accept traps from known SNMP consoles only.
Note: You can block incoming SNMP traffic from the Internet by using a firewall that prevents passage of
traffic on UDP ports 161 and 162.
For more information about installing the SNMP service and using it with XenApp, see the following:
For XenApp 5 for Windows Server 2003, see Network Manager Administrator's Guide and Monitoring
Server Performance with Citrix Presentation Server available from the Citrix Knowledge Center.
For XenApp 5 for Windows Server 2008, see Enabling SNMP Monitoring
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.
8.7.6.2. Securing the Data Store
One of the most important aspects of securing your server farm is protecting the data store. This involves
not only protecting the data in the data store database but also restricting who can access it. In general:
Users who access your farms servers do not require and should not be granted any access to the
data store.
When the data store connection is a direct one (that is, no intermediary server is used), 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 direct mode access to 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. For information about the
dsmaint config command, see DSMAINT.
More specific Citrix recommendations for securing the data store vary depending on the database you use for
the data store. The following topics discuss security measures to consider for each of the database
products XenApp supports.
Important: Be sure to create a backup of your data store before using dsmaint config to change
the password on your data store.
Microsoft Access
For an Access data store, the default user name is citrix and the password is citrix. If users have
network access to the data store server, change the password using dsmaint config and keep the information
in a safe place.
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 user
s password is compromised.
Note: 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 account
s 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 service pack or
feature release for XenApp.
Microsoft SQL Server 2005 Express Edition
Windows authentication is supported for the Microsoft SQL Server 2005 Express Edition database. For
security reasons, Microsoft SQL Server authentication is not supported. For further information, consult
Microsoft documentation. 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
If the data store is hosted on 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.
IBM DB2
If the data store is hosted on IBM DB2, give the DB2 user account employed for the server farm the
following permissions:
Connect database
Create tables
Register functions to execute to database managers process
Create schemas implicitly
System administrator (DB2Admin) account permissions are not needed for data store access.
8.7.6.3. 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:
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
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 in two places:
On the server side, when you publish an application or resource.
On the client side (for Program Neighborhood only). The Web Interface and XenApp plugin for Hosted
Apps 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:

The setting in Terminal Services Configuration (TSCC)
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.
8.7.6.3.1. 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.
Plugins use 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:
You need to secure communications from devices that use Microsoft DOS or run on Win16 systems
You have older devices running plugin 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.
8.7.6.3.2. 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:
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:
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.
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 at Citrix eDocs.
8.7.6.3.3. 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 encryption after you publish an application.
Services Console.
2. Select a published application in the left pane by selecting XenApp > your farm name > Applications >
application name.
3. From the Action menu, select Modify application properties > Modify all properties.
4. In the Application Properties dialog box, select Advanced > Client options.
5. In the Connection encryption section, do one or more of the following:
Select the Enable SSL and TLS protocols check box. This option requests the use of the
Secure Sockets Layer (SSL) and Transport Layer Security (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.
(For Program Neighborhood only. Optional.) Select the Minimum requirement check box, which
is available only if you increase the level of ICA protocol encryption. The Minimum requirement
check box sets a requirement that Program Neighborhood plugins connecting to a
published application use the specified level of encryption or higher. This means the following:
If you do not select the Minimum requirement check box, Program Neighborhood
s connections to the server are encrypted at the level that you set in Program
Neighborhood. If the encryption level on the server and in Program Neighborhood do
not match, you can still connect. The encryption settings you specify in
Program Neighborhood override the encryption level set for the application.
If you select the Minimum requirement check box, Program Neighborhoods connections
to the server must be encrypted at the same level that you set on the server, or the
server refuses the clients transmission and the session is dropped.
6. Click OK.
If you are using Program Neighborhood as one of the plugins in your environment, you must also
enable encryption on the client side.
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 plugins that take their
encryption settings from the server, such as the Web Interface and the Citrix XenApp plugin, 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.
8.7.6.3.4. To set a policy for ICA encryption
2. Select Policies.
3. From the Actions menu, click New > Policy.
4. Select the policy name; on the Actions menu, click Properties.
5. From the list of folders in the left pane, select Security > Encryption > SecureICA encryption.
6. Select Enabled; from the Encryption Level list box, select the encryption level you want for this policy.
7. Enable the policy by applying a filter.
For additional details about creating policies in general, see Working with XenApp Policies.
8.7.6.4. 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 the plugin and the Citrix XML
Service running on each server. Each plugin authenticates the SSL Relay by checking the relays server
certificate against a list of trusted certificate authorities. After this authentication, the plugin and SSL
Relay negotiate requests in encrypted form. SSL Relay decrypts the requests and passes them to the server.
When returning the information to the plugin, 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:
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.
8.7.6.4.1. Task Summary for Implementing SSL Relay
To implement the SSL Relay, perform the following steps:
Task
See this topic
Obtain and install server and root SSL certificates.
Obtaining and Installing Server and

Root SSL Certificates
Enable the SSL relay and select the server certificate in the
Relay Credentials tab of the SSL Relay Configuration Tool.
To enable the SSL Relay and select the

relay credentials
Use the features available from the Connection tab to

change the target server or port, or add servers for redundancy.
TCP Ports and the SSL Relay

Using the SSL Relay with
the Microsoft Internet
Information Service (IIS)
Configuring the Relay Port and
Server Connection Settings
Use the features available from the Ciphersuites tab of the

Configuring the Ciphersuites Allowed by
SSL Relay Configuration Tool to select which ciphersuites to allow. the SSL Relay
8.7.6.4.2. 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.
8.7.6.4.3. Choosing an SSL Certificate Authority
You can obtain and install certificates for your servers and client devices in the following ways:
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:
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.
8.7.6.4.4. 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.
8.7.6.4.5. 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.
4.
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).
8.7.6.4.6. 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:
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.
8.7.6.4.7. Configuring the Relay Port and Server Connection Settings
Updated: 2011-03-25
The SSL Relay relays packets only to the target computers listed on the Connection tab. 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 through the Connection tab.
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 XenApp plug-in must be listed on this tab. By
default, no servers are listed.
See the topic 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.
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 XenApp Plug-in for Hosted Apps icaclient.adm file. For more information about plugin settings, see the XenApp Plug-in for Hosted Apps administrator documentation in Citrix eDocs.
8.7.6.4.8. To add a server to the destination server list
Updated: 2011-03-25
1.
2.
On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration Tools
2.
Click the Connection tab and click New.
3.
Type the FQDN of the computer in the Server Name box.
4.
Type the port number of the Citrix XML Service in the Destination ports box and click Add. Type
the port number where ICA is listening in the Destination Ports box and click Add.
These additional servers must also be specified in the configuration of servers running the Web Interface.
8.7.6.4.9. To change the port for a server listed in the destination server list
Updated: 2011-03-25
1.
If you did not already do so, select the Connection tab.
2.
Click the entry that you want to edit to select it.
3.
Click Edit to display the Target Server Properties dialog box.
4.
Select a destination port to remove and click Delete.
5.
In the field below Destination ports, type the number of the new destination port and click Add.
8.7.6.4.10. 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 install 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.
8.7.6.4.11. Configuring the Ciphersuites Allowed by the SSL Relay
Use the Ciphersuites tab to configure which combinations of ciphersuites the SSL Relay will accept from
the client (a server running the Web Interface or XenApp plugin). 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
2. Select a ciphersuite from either the left column and click Add to allow it or from the right column and click
Remove to disallow it.
8.7.6.5. 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, you use the Secure Gateway when:
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:
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 about implementing and configuring the Secure Gateway, see the Secure Gateway
for Windows administrator documentation at Citrix eDocs.
8.7.6.6. 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
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.
8.7.6.7. 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:
At the client-server level inside your network:
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:
The 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 .
8.7.6.7.1. Configuring TCP Ports
This table lists the TCP/IP ports that the servers, XenApp Hosted Plug-in, 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
Default port
Configuration
Access
Management Console
135
Not configurable
Citrix SSL Relay
443
See Using the SSL Relay with the Microsoft

Internet Information Service (IIS) for
configuration instructions
Citrix XML Service
80
See the information about configuring the XML

Service port in the XenApp Installation documentation at
Citrix eDocs for configuration instructions
Client-to-server
(directed UDP)
1604
Not configurable
ICA sessions (clients

to servers)
1494
See the XenApp Command Reference at Citrix eDocs

for instructions about the ICAPORT command to
change the port number
License
Management Console
8082
See Getting Started with Citrix Licensing at Citrix eDocs

for more information
XenApp
or Presentation
Server Console to server
2513

for information about the IMAPORT command
Server to license server
27000
In the console, open the farm or server properties

page, and select License Server
Server to Microsoft SQL

or Oracle server
139, 1433, or 443

for MS-SQL
See the documentation for the database software
Server to server
2512

for information about the IMAPORT command
Session reliability
2598
See Configuring Session Reliability.
8.7.6.7.2. 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 XenApp plug-ins, see the information about XenApp Plug-in
for Hosted Apps .
Supported proxy servers are:
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
8.7.6.7.3. 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 XenApp Plugin
for Hosted Apps by typing in their credentials.
To set up the trust relationship, open the servers Properties page in the Access Management Console, choose
XML Service in the left pane, and select Trust requests sent to the XML Service. 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:
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.
8.7.6.8. Using Smart Cards with Citrix 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:
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 device called a smart card reader. 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 RSA Security Inc.s 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 about configuring the Web
Interface for smart card support, see the Web Interface administrator documentation at Citrix eDocs.
8.7.6.8.1. Smart Card Requirements
Before using smart cards with XenApp, consult your smart card vendor or integrator to determine
detailed configuration requirements for your specific smart card implementation.
The following components are required on the server:
PC/SC software
Cryptographic Service Provider (CSP) software
These components are required on the device running the supported XenApp plug-in:
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.
8.7.6.8.2. Configuring XenApp for Smart Cards
A complete and secure smart card solution can be relatively complicated 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 XenApp clients and plug-ins support smart cards:
XenApp Plug-in for Hosted Apps
Client for Linux
Client for Windows-based terminals
Client for MacIntosh
To configure smart card support for users of these plug-ins and clients, see the section in eDocs for the plugins and clients in your environment.
8.7.6.9. Configuring Kerberos Logon
Updated: 2010-05-25
Citrix XenApp Plug-in for Hosted Apps 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:
If you use the following options in Terminal Services Configuration:
Use standard Windows authentication
Always use the following logon information or Always prompt for password
If you route connections through Secure Gateway
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.
Windows Server 2008 User Access Control and Administrator Sessions
The User Access Control feature of the Windows Server 2008 operating system prompts users to enter
their credentials when all of the following requirements are met:
Kerberos logon is enabled on a computer hosting the Windows 2008 Server operating system and
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.
Limitations of Kerberos Pass-through Authentication to XenApp
Windows supports two authentication protocols, Kerberos and NTLM, so Windows 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.
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
1.
Depending on the version of XenApp you have installed, from the Start menu, select All Programs
Services Console.
2.
Select the Farm node and select Action > Modify farm properties > Modify all properties.
3.
From the farms Properties list, open the XenApp page and select the General option.
4.
In the details pane, select the option XML Service DNS address resolution.
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.
On XenApp, 64-bit Edition: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon\ DisableSSPI = 1
On XenApp, 32-bit Edition: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Logon\DisableSSPI = 1
You can configure the Citrix online plug-ins to use Kerberos with or without pass-through authentication.
8.7.6.10. 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:
Access Management Console or Delivery Services Console
Advanced Configuration tool or Presentation Server Console
some command-line utilities
tools custom built with the MPSSDK and CPSSDK
Before you enable the Configuration Logging feature:
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.
To enable the Configuration Logging feature:
Set up the Configuration Logging database
Define the Configuration Logging database access permissions
Configure the Configuration Logging database connection
Set the Configuration Logging properties
Delegate administrative permissions, as needed
Note: 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.
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.
8.7.6.10.1. Setting up the Configuration Logging Database
The Configuration Logging feature supports Microsoft SQL Server 2005 and 2008 and Oracle Version 10.2
and 11.1 databases.
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.
General Requirements
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
Note: For additional instructions about how to manage and use schemas in SQL Server, see your SQL
Server documentation.
Considerations for SQL Server

For SQL Server 2005, 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.
For SQL Server 2005, 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.
For SQL Server 2005, 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.
Considerations for Oracle

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 instructions about how to manage and use a different schema, see your
Oracle documentation.
Before running the Access Management Console or Delivery Services Console, you must update the
Oracle tnsnames.ora client file to include the connectivity information needed to access the
available databases.
If you are using Oracle Version 10.2, Citrix recommends that you apply the Oracle patch 10.2.0.1.4
P (patch 4; patchset 4923768) and any subsequent patches. These patches ensure that the Oracle
client software can operate correctly if installation directories contain a parenthesis character; for
example, a directory folder named Program Files/(x86).
8.7.6.10.2. 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 as described in
Setting up the Configuration Logging 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
Database permissions needed
To create log entries in the database tables
INSERT for the database tables, EXECUTE for

the stored procedures, and SELECT for sysobjects
and sysusers (SQL Server) or sys.all_objects (Oracle)
(Oracle also requires SELECT 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, and SELECT
for sysobjects and sysusers (SQL Server) or
sys.all_objects (Oracle)
(Oracle also requires SELECT for sequence
objects and the create session system privilege)
To create a report
EXECUTE for the Citrix Configuration Logging

stored procedures
SELECT for sysobjects and sysusers (SQL Server) or
sys.all_objects (Oracle)
(Oracle also requires the create session
system privilege)
Note: 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.
Considerations for SQL Server
Before you configure the Configuration Logging database connection, grant EXECUTE permission to
the system stored procedure sp_databases 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
8.7.6.10.3. To configure the connection to the Configuration Logging database using the
Configuration Logging Database wizard
After the Configuration Logging database is set up by your database administrator and the appropriate
database credentials are provided to XenApp, the connection to the Configuration Logging database must
be configured through the Configuration Logging Database wizard.
Services Console.
2. Select a farm.
3. In the task pane, under Common Tasks, click Modify farm properties > Modify configuration
log properties.
4. In the Configuration Logging dialog box, click the Configure Database button to open the wizard.
If you are using a SQL Server database, you need to provide or select:
The name of the database server
An authentication mode
The name of the database
The logon credentials for the database user that were created when you set up the Configuration
Logging database
When you use SQL Server, the Use encryption connection option in the wizard is enabled by default. If
your database does not support encryption, you must disable this option.
If you are using an Oracle database, you must provide a net services name as well as the logon credentials.
The net services names listed in the Data Source drop-down list are in the Oracle tnsnames.ora client file. You
are then asked to specify various connection and pooling options. For information about how to configure
these options, see your SQL Server or Oracle documentation.
Note: Credentials are always required for both Oracle and SQL Server, even if you are using
Windows Integrated Authentication. 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.
Note: 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.
8.7.6.10.4. To configure a SQL Server database for configuration logging
1.
2.
3.
Under Database configuration on the Configuration Logging page of your Farm Properties
dialog box, click Configure Database.
On the Select Connection Details page, select SQL Server as a connection type.
Use the drop-down list to select a SQL Server. You can also enter a server name manually if the server
is available but does not appear in the drop-down list.
4.
Select Use Windows integrated security (recommended) or Use SQL Server authentication.
5.
Enter a valid user name and password for your SQL Server database.
6.
Click Next. The Select Database page opens. Use the Specify the database drop-down list to enter
the name of your database. You can also enter a database name manually here.
7.
Click Next. The Select Advanced Options page opens. Configure the following connection
and connection pooling options:
7.
Connection options comprise Connection time-out (seconds), Packet size (bytes), and
Use encryption.
Under Connection pooling on the database server, if desired, clear Connection pooling enabled
. This disables the Connection Pooling feature.
Note: It is not necessary to modify the default values of these settings for the configuration to work.
A possible exception is the Use encryption setting. For security reasons the default value of this
setting is Yes. However if the SQL Server database server you are connecting to does not
support encryption, the connection will fail. Click the Test Database Connection button on the
Check New Connection Summary page to check whether or not the database supports encryption.
If it does not, an error message to that effect is returned.
8.
Click Next. The Check New Connection Summary page opens with a summary of the settings
you configured. Click Back to return and alter any settings if required.
9.
Click Test Database Connection. A dialog box appears telling you whether or not the connection
was successfully established.
8.7.6.10.5. To configure an Oracle database for configuration logging

1.
Under Database configuration on the Configuration Logging page of your Farm Properties
dialog box, click Configure Database.
2.
On the Select Connection Details page, select Oracle as an information type. This selection
dynamically changes some of the information for which you will be asked.
3.
Use the drop-down list to select a net service name. You can also enter a net service name manually.
4.
Enter a valid user name and password for your Oracle database.
5.
Click Next. The Select Advanced Options page opens. Configure the following connection
and connection pooling options.
Connection options comprise Connection time-out (seconds), Packet size (bytes), and
Use encryption.
Under Connection pooling on the database server, if desired, clear Connection pooling enabled
. This disables the Connection Pooling feature.
Note: It is not necessary to modify the default values of these settings for the configuration to work.
6.
Click Next. The Check New Connection Summary page opens with a summary of the settings
you configured. Click Back to return and alter any settings if required.
7.
Click Test Database Connection. A dialog box appears telling you whether or not the connection
was successfully established.
8.7.6.10.6. To set Configuration Logging properties

Before you set Configuration Logging properties, ensure a SQL Server or Oracle database is
configured. Otherwise, the Log Tasks and Clearing log areas of the Configuration Logging page are not active.
After establishing a connection to the database, you enable the Configuration Logging feature:
Services Console.
2. Select a farm.
log properties.
4. Under Log tasks, select Log administrative tasks to logging database to enable configuration logging.
If you want administrators to be able to make changes to the farm when the database is
disconnected, select Allow changes to the farm when database is disconnected, which
becomes available when configuration logging is enabled.
5. To prompt administrators to enter their credentials before clearing the log, under Clearing log, select the
5.
Require administrators to enter database credentials before clearing the log check box.
Note: A Citrix administrator requires the Edit Configuration Logging Settings permission to change
any Configuration Logging settings or clear the log.
8.7.6.10.7. Delegating the Administration of Configuration Logging
Full Citrix administrators can edit the Configuration Logging settings and select the task to clear the log in
the Access Management Console or Delivery Services Console, or they can authorize other administrators
to perform these tasks by assigning them the delegated administration permission Edit Configuration
Logging Settings. Without this permission, ordinary administrators cannot perform these functions.
8.7.6.10.8. To view Configuration Logging properties
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.
You can view Configuration Logging properties at the farm level.
Services Console.
2. In the left pane, select a farm.
log properties.
8.7.6.10.9. Clearing Entries from the Configuration Logging Database
It may become necessary to clear the entries in the Configuration Logging database occasionally if the
population of the tables becomes too large. To clear the log, you must:
Be a full or delegated Citrix administrator with the permissions to edit the Configuration Logging
settings. These permissions allow you to select the Clearing the Log task.
Have the correct database user account permissions. These permissions allow you to clear the log in
the database. By default, the database credentials defined in the database wizard are used to clear the log.
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
Configuration Logging properties. This ensures only database users with permissions to clear logs can clear
them. Therefore, anyone attempting to clear the log is prompted for database credentials.
If you configured a SQL Server database and you want to clear a log, you can only enter credentials
that correspond with the same type of authentication mode that you selected when you connected to
the database initially. Specifically:
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 you must enter the credentials for the Windows user account
To clear log entries from the Configuration Logging database

Services Console.
2. From the left pane, select a farm.
3. From the task pane, under Other Tasks, click Clear configuration log.
8.7.6.10.10. Generating Configuration Logging Reports

Reports that draw the information from the tables created in the Configuration Logging database can
be configured and generated in the Report Center.
Important: When the Configuration Logging feature is enabled, only administrative changes made to
servers running XenApp are logged and appear in the reports that are generated.
The supported versions of Microsoft SQL Server are verified for MDAC 2.8.
Reports can be generated based on the following filter criteria (wildcards are not supported):
Time period. When the actions occurred that you want to review. The actions covered in the report
appears with the local time where the report is generated.
Type of item. Select the type of object for which you want to report changes.
Name of item. After you select an item type, you can provide the name of a specific object on which
to report. The name of the item search does not support wildcards; therefore, enter the exact name of
the object to get the desired result.
User name. The Citrix administrators whose actions are covered in the report.
When no filter criteria are selected, the default, all log entries are included in the report. After you select
the filtering criteria for the report, it can be published from the Report Center.
Note: To generate a report from an Oracle logging database, you must first install the Oracle Provider for
OLE DB. This can be done by performing a custom installation of the Oracle client.
To generate a Configuration Logging report

Services Console.
2. In the left pane, select the Report Center node.
3. In the task pane under Common Tasks, click Generate report.
4. From the Report type drop-down list, select Configuration Logging Report.
5. Click Next to start the Configuration Logging Report wizard. Follow the steps in the wizard to generate
a report.
Note: If you are using SQL Server or Oracle database authentication, the Allow saving password check
box must be selected.
8.7.6.11. Encrypting Sensitive 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.
The IMA encryption feature protects administrative data used by the configuration logging feature.
This information is stored in the IMA data store. For IT environments with heightened security
requirements, enabling IMA encryption provides a higher degree of security for the configuration logging
feature. 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, if you want to enable IMA encryption, you must enable it on all servers in the farm.
IMA encryption has the following components:
CTXKEYTOOL. Also known as the IMA encryption utility, CTXKEYTOOL is a command-line utility that
you can use to manage IMA encryption and generate key files. CTXKEYTOOL is in the Support folder of
the XenApp media.
Key file. The key file contains the encryption key used to encrypt sensitive IMA data. You create the key
file by using the CTXKEYTOOL, during Setup, or while changing farms (chfarm). 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. The same valid IMA encryption key must be loaded on all servers in the farm if IMA encryption
is enabled. After copying the farms key file to a server, you load the key by using the CTXKEYTOOL,
during Setup, or using the functionality in chfarm.
It is easier to enable IMA encryption as part of the installation process than after installation. Enabling
IMA encryption after installation requires performing a manual process on each server. For information
about installation methods when you are enabling IMA encryption during Setup in large-farm environments,
see the information about planning for IMA encryption in the XenApp installation documentation at Citrix eDocs.
Regardless of when you enable IMA encryption, the process has the same basic elements. At a high level,
you perform the following tasks in the order given:
Generate a key file
Make the key file accessible to each server in the farm or put it on a shared network location
Load the key on to the server from the key file
Enable IMA encryption
These topics provide information about IMA encryption:
How to use the IMA encryption utility (CTXKEYTOOL)
How to enable IMA encryption after installation
How to change farms
How to back up farm keys
What to do if you installed XenApp as a local administrator when you enabled IMA encryption
Citrix recommends that, if you are enabling IMA encryption in environments that have multiple farms, you
give the keys for each farm a different name.
Important: Citrix strongly recommends backing up the farm key to a safe, secondary location.
For information, see Enabling IMA Encryption Features.
8.7.6.11.1. Copying the key to a local computer
Citrix provides a utility for performing various administrative functions after you install XenApp. This utility
is known as the IMA encryption utility and you run it from the CTXKEYTOOL command. You can use the
IMA encryption utility to enable and disable the IMA encryption feature and generate, load, replace,
enable, disable, and retrieve lost key files. You can also use the IMA encryption utility to check to see if a key
is loaded on the local computer, if IMA encryption is enabled for the farm, and if your key matches the farm key.
To run the utility locally
1. Copy the CTXKEYTOOL.exe file from the Support folder of the 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 its accompanying Resource\en folder anywhere on your
computer, provided you maintain the same relative directory structure in which they were stored on the media.
8.7.6.11.2. To generate a key and enable IMA encryption on the first server in a farm
You can enable IMA encryption after you install or upgrade to XenApp. Use this procedure to generate a key
and load the key to the first server to enable IMA encryption, and then continue by loading the key on
the subsequent servers in the farm.
You must have a key on every server in the farm for IMA encryption to work correctly.
1. On the server on which you want to enable IMA encryption, run the generate option of the
1.
CTXKEYTOOL command. The following is an example of the command line to use to accomplish this:
ctxkeytool generate 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 key file
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.
2. Press Enter. The following message appears indicating that you successfully generated a key file for
that server, Key successfully generated.
3.
To obtain the key from the file and put it in the correct location on the server, run the load option of
the CTXKEYTOOL command on the server on which you want to add the key. The following is an example:
ctxkeytool load full UNC or absolute path, including the key file name, to the location where you
stored the key file
4. Press Enter. The following message appears indicating that you successfully loaded the key on to
that server: Key successfully loaded. You are now ready to enable the IMA encryption feature in the
data store.
5. Run the newkey option of the CTXKEYTOOL command to use the currently loaded key and enable the key.
ctxkeytool newkey
6. Press Enter. The following message appears indicating that you successfully enabled the IMA
encryption feature in the data store: The key for this farm has been replaced. IMA Encryption is
enabled for this farm.
7.
Continue to the procedure for loading the key to other servers in the farm.
8.7.6.11.3. To load a key on subsequent servers in the farm

1. If you do not have the key file on a shared network location, on the next server on which you want
to begin enabling IMA encryption, load the key file to the server from portable storage media.
2. To obtain the key from the file and put it in the correct location on the server, run the load option of
the CTXKEYTOOL command on the server on which you want to add the key. The following is an example:
ctxkeytool load full UNC or absolute path, including the key file name, to the location where you
stored the key file
3.
Press ENTER. The following message appears indicating that you successfully loaded the key on to
that server, Key successfully loaded. You do not need to enable IMA encryption again (using the
newkey option) because you have already enabled it on one server in the farm.
4. Repeat this process on every server in the farm.

8.7.6.11.4. To store the key on a network location
If you choose to store the key on a shared network location, Citrix recommends the following:
Make sure that the folder has a meaningful name that specifies the name of the farm for which the key
was created. This is especially important in situations when you follow the Citrix best
practice recommendation of creating a unique key for the farm.
Make sure that the account you use to generate the key is the same as the account that will be used
to install all the servers in the farm. You must use the same account for both tasks.
Grant Read/Execute access to the key file to each computer that will be joining the farm and to
the administrator performing the installation.
In addition, if you want to specify this key when you are enabling IMA encryption during Setup, you must
specify it using a Universal Naming Convention (UNC) path.
The following procedure explains how to store a key on a shared network location. The procedure assumes
that you are performing an Autorun-based installation and generating a key from Setup while you are
installing the first server on the farm. The guidelines provided in these steps apply to other situations in
which you specify the key, such as chfarm and unattended installations.
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 originally generated the key, copy the key file
to the shared network location that you want to use for the subsequent server installations.
3.
3.
Grant Read/Execute access to the key file to each computer that will be joining the farm and to
the administrator performing the installation.
8.7.6.11.5. Changing Farms

If you need to move a server to a farm that has IMA encryption enabled, you must use the chfarm
command. When you run chfarm, a wizard similar to the Citrix XenApp Setup wizard launches. This Setup
wizard prompts you to specify a key the same way as product Setup does when you choose to enable
IMA encryption. If, before running chfarm, you choose to load the new farms key to the server, note that
adding a key to a server with the same name as an existing key overwrites the existing key.
You cannot enable IMA encryption when you join a farm, either during Setup or when changing farms, if you
are logged on as a local administrator and you attempt to connect to the data store indirectly. For
more information, see the XenApp installation documentation at Citrix eDocs.
If you are moving a server to a farm that does not have IMA encryption enabled, Setup does not prompt you
to provide a key file and IMA encryption is disabled automatically on the server you are moving.
8.7.6.11.6. Enabling IMA Encryption Features
IMA encryption includes other features that you can use as needed:
Backing up keys. 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 using the backup option in the CTXKEYTOOL command.
Retrieving lost, deleted, or accidentally overwritten keys. It is possible to recreate a key file that
you accidentally deleted, if, for example, you need it to join a new server to the farm. Because all
servers in the same farm use the same key, you can obtain a key from another server on the farm.
XenApp does not allow you to access keys. Consequently, to obtain the lost key, you must recreate
the entire key file by running the backup option in the CTXKEYTOOL command on any server in the
farm with IMA encryption that has the key and is functioning properly.
Disabling and reenabling IMA encryption. You can disable IMA encryption by running the
ctxkeytool disable command on any server in the farm. Because IMA encryption is a farm-wide
feature, you do not need to run this command on every server in the farm. Running it on one
server, disables the feature for 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 in the Access Management Console or Delivery
Services Console.
If you want to reenable IMA encryption after you disabled it, use the enable option of the
CTXKEYTOOL command. After running the enable option, Citrix recommends that you always run
the query option to verify that IMA encryption is enabled.
For information about the CTXKEYTOOL, see the XenApp Command Reference at Citrix eDocs.
8.7.6.12. 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 in the table 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
Executable
Logon Account
Description
Dependencies
Name
(Service Name)
/ Startup Type
Citrix 64-bit
ctxsfosvc64.exe
Virtual
Memory Optimization
Local System
Citrix Client Network
Local System
cdmsvc.exe
(CdmService)
Dynamically optimizes 64-bit

None applications running o
Manual
Automatic
Maps client
drives
and peripherals
for access
in sessions.
Client
Drive
Mapping (CDM)
Windows Management Instr

Workstation
Citrix CPU
ctxcpubal.exe
Utilization Mgmt/CPU Rebalancer
.\ctx_cpuuser
Manual
(CTXCPUBal)
None
One of the
services for the
CPU
Utilization Management feature.
This
service
enhances
resource management across multiple CPUs.
This service
is installed only
on servers that
have multiple CPUs.
Citrix CPU
ctxcpusched.exe
Utilization Mgmt/Resource Mgmt
Local System
Manual
(ctxcpuSched)
One of the
Remote Procedure Call (RPC
services for the
CPU
Utilization Management feature.
Manages
resource consumption to enforce entitlement policie
Citrix
Diagnostic
Facility COM Server
CdfSvc.exe
Automatic
(CdfSvc)
Citrix
Encryption Service
NT
AUTHORITY\
Network Service
encsvc.exe
NT AUTHORITY\
Local Service
Manages
and
controls
diagnostic
trace
sessions, which
are used
to
diagnose
problems on
a XenApp server.
Enables
secure communication with RC5 128-bit encryption
Automatic
Citrix End
SemsService.exe
User
Experience Monitoring
(Citrix EUEM)
Local Service
Manual
Collects and
Citrix
collates endSMC
user
Support Driver
experience measurements.
Citrix
Health
Monitoring
and Recovery
HCAService.exe
NT AUTHORITY\
Local Service
Automatic
(CitrixHealthMon)
Provides
health
monitoring
and
recovery services
in the
event
problems occur.
Citrix Independent Managem

Terminal Services
Citrix
ImaSrv.exe
Independent Management Architecture
NT
Provides management services
Citrix
in the XenApp farm
AUTHORITY\ NetworkService
Services Manager service
(IMAService)
Automatic
IPsec
Policy Agent

TCP/IP
Protocol Driver
Server

Workstation
Citrix MFCOM Service mfcom.exe
(MFCom)
Citrix Print
Manager Service
CpSvc.exe
Provides
NT
COM services
that allow
remote
Automatic
connections
from
the
management tools.
.\ctx_cpsvcuser
Print Spooler
Automatic
(cpsvc)
Manages
the creation
of printers
and driver
usage
within
XenApp sessions.

Citrix
This
service supports
the Citrix
Universal
Printing features.
Citrix
Secure
Gateway Proxy
CtxSGSvc.exe
(CtxSecGwy)
Citrix
Services Manager
(IMAAdvanceSrv)
NT
AUTHORITY\
Network Service
Automatic
IMAAdvanceSrv.exe
Local System
Automatic
Proxy to the
Citrix
Secure
Gateway server.
None
Provides
XenApp with
an interface to
the
operating
system.
Other services
use this services
None
to perform
elevated operations.
Citrix
Streaming Service
RadeSvc.exe
.\Ctx_StreamingSvc
Automatic
(RadeSvc)
Citrix
CTXSFOSvc.exe
Virtual
Memory Optimization
Local System
Citrix WMI Service
NT AUTHORITY\
Local Service
ctxwmisvc.exe
(CitrixWMIservice)
Manages
the XenApp Plugin for
Streamed
Apps
when
streaming applications.
Dynamically optimizes applications

None
running on a Xe
Manual
Manual
Provides the
Citrix WMI
Citrix
classes
for information
and
IPsec
management purposes.Policy Agent

TCP/IP
Protocol Driver
Server

Workstation
Citrix XML Service
ctxxmlss.exe
(CtxHttp)
Citrix XTE Server
Network Service
Automatic
XTE.exe
(CitrixXTEServer)
Services XML
data requests
sent by
XenApp components
None
NT
Services
None
network requests
for session
Manual
reliability and
SSL from
XenApp components.
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
Permissions
Notes
Local Service
Limited
NT AUTHORITY\LocalService
Network Service
Limited, network resources
NT AUTHORITY\NetworkService
Local System
Administrator
NT AUTHORITY\System
Ctx_StreamingSvc
Domain or local user
Acts as a User
ctx_cpsvcuser
Acts as a Power User
Ctx_ConfigMgr
Acts as a Power User
Ctx_CpuUser
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_cpsvcuser, Ctx_ConfigMgr, and Ctx_CpuUser accounts
before installing XenApp and specify the new accounts during Setup. Citrix does not support changing the
account for the Citrix Streaming Service (Ctx_StreamingSvc). Follow the guidelines in the XenApp
installation documentation at Citrix eDocs and ensure the new account has the same privileges as the
default account.
Privileges
Local Service
Network Service
Ctx_StreamingSvc ctx_cpsvcuser Ctx_ConfigMgr Ctx_CpuUser
Change
the
system time
Generate security
x audits
Increase quotas
x
Load
and
unload device drivers
Log on as
a batch job
Log on as
a service
Restore files and directories
Replace
x
a
process level token
Debug programs
Increase scheduling priority
8.7.7. 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.
This topic describes how to perform the following tasks:
Displaying and Organizing Your Farm
To configure general farm properties
To search for objects in your farm
Connecting to a Server
Restarting Servers at Scheduled Times
To repair a XenApp installation
Changing XenApp Farm Membership
Removing and Reinstalling XenApp
Monitoring Server Performance with Health Monitoring & Recovery
Using Citrix Performance Monitoring Counters

Optimizing Server Performance
Managing Farm Infrastructure
Updating Citrix License Server Settings
Setting the Product Edition
Setting the Citrix XML Service Port
8.7.7.1. Displaying and Organizing Your Farm

Server and farm properties are configuration settings specific to individual servers or entire farms. Using the
Farm Properties page, you can configure a number of properties at the farm level. By default, all servers
are configured to use the farm settings for a given property.
Using a Server Properties page, you can override farm settings and customize the configuration of
individual servers. For example, if you specify a license server on a Farm Properties page, all servers in
the farm, including servers you add later, point to that license server. To point particular servers to a
different license server, use those Server Properties pages to specify a different license server.
Important: Interoperability of XenApp 5.0 for Windows Server 2008 with versions prior to Presentation
Server 4.5 for Windows Server 2003 is no longer supported.
To view farm information
You can view summary information about the server farm, published resources, servers, and sessions.
Depending on the configuration of your farm, some areas may not appear.
Services Console.
3. From the Action menu, click Change display > Information. The right, or details, pane of the
console displays summary information about the farm, servers, published resources, and sessions.
4. From Available Displays, you can click Alerts, Users, Offline Sessions, Hotfixes, Configured
file types, Read-only Properties, or Offline users for more detailed information about these areas.
Note: The displays that appear depend on the features you enabled in XenApp.
To view server information

You can view a wide variety of summary information about each server in the farm. Depending on
the configuration of your server, some areas may not appear.
Services Console.
2. In the left pane, select a server.
3. From the Action menu, select Change display > Information. The details pane of the console
displays summary information about the product edition and version, installed service packs,
server operating system, and TCP address. Click Expand list to view more server summary information.
4. From Available Displays, you can select Alerts, Users, Sessions, Processes, Hotfixes,
Published applications, Read-only Properties, View server health, and Trace Sessions for
more detailed information about these areas.
Note: The displays that appear depend on the features you enabled in XenApp.
8.7.7.1.1. Organizing Your Farm Display in the Console
You can group applications or servers in folders to make navigating through their console 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.
You can move items between folders by dragging and dropping.
Important: The folder structure within Applications is not related to, or reflected in, the folder structure
for clients using Program Neighborhood.
To create a folder
Services Console.
2. In the left pane, select Applications or Servers. To create a subfolder, select the folder in which you
want the new folder created.
3. From the Action menu, select New > Create folder.
4. In the New Folder dialog box, type the name of the new folder, and select Copy permissions from
the parent folder if you want the new folder to be accessed by the same administrators who have
access to the parent folder.
Note: This is a one-time only inheritance; no updating occurs if you make permission changes to
the parent folder later. If you clear the check box to disable the option, only administrators with
view only or full administration privileges can access the folder. Administrators with Custom
privileges cannot access the folder until they are given permission.
To rename a folder
1. Select the folder in question and from the Action menu, select Rename.
2. Type the new name of the folder directly in the left pane.
To delete a folder
1. If the folder contains applications or servers, move them to other locations.
Note: You can delete empty folders only.
2. Select the empty folder you want to delete.
3. From the Action menu, select Delete folder.
To move the contents of a folder

1. Select the published application, server, or folder you want to move.
2. From the Action menu, select Move to folder.
3. Select the required destination folder and click OK.
To move servers to a folder

1. In the left pane, select the destination folder (under the Servers folder only) into which you want to move
a server.
2. From the Action menu, select All Tasks > Move servers to folder.
3. Select the required server or subfolder and click Add.
Note: Published applications can be moved only to Applications or folders under Applications.
Similarly, servers can be moved only to Servers or folders under Servers.

8.7.7.2. To configure general farm properties
General farm properties includes settings such as broadcast response, client time zones, Citrix XML Service,
and Novell Directory Services.
Services Console.
3.
From the Action menu, select Modify farm properties > Modify all properties.
4. From the Properties list, select Farm-wide > XenApp > General.
5. Under Respond to client broadcast messages, select either of the following check boxes to respond
to broadcasts from clients:
Data collectors
RAS servers
6. Under Client time zones, select Use Clients local time.
This means that all time stamps for all applications are based on the clients time instead of the server
s time.
You can then select Estimate local time for clients. This time is based on the clients time zone settings.
Note: Client time zone settings override similar settings that are configured in Microsoft Windows
Group Policy.
Important: Version 6.x of the Presentation Server Clients introduced the capability to send time
zone information to the server. For earlier versions of clients, the client sends the local time, which
could be incorrect or modified by the user, so the servers estimate of the client time zone might not
be accurate.
7. Under Citrix XML Service, select XML Service DNS address resolution to allow a server to return
the fully qualified domain name (FQDN) to clients using the Citrix XML Service.
Important: 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.
8.
Under Novell Directory Services, in the NDS preferred tree field, enter the name of the NDS tree
used to access NDS user account information and authentication.
9. Under Published application icons, select Enhanced icon support to enable additional icon
color depths (32-bit) when you publish applications. To apply this setting to previously
published applications, delete them and publish the applications again.
8.7.7.3. 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.
Services Console.
2. From the Tasks pane, select Search > Advanced search.
3.
In the Advanced Search dialog box, in the Find box, select one of the following:
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.
4. If desired, select one of the following locations to search in:
A farm. Displays all applications in that farm matching the search.
An application folder. Displays all applications in that folder matching the search.
An application. Displays only that application, if it matches the search.
A server folder. Displays all applications published to servers in the folder, that match the search.
A server. Displays all applications published to the server, that match the search.
A zone. Displays all applications published to servers in the zone, that match the search (may
be useful for zone preference and failover scenarios).
Any other node. Displays all applications in all farms, that match the search.
Note: If there are multiple farms in the search scope, the Select directory type box contains multiple
Citrix User Selector, for farm <n> entries. After you enter or select a complete user name, the user
s account authority is checked. If you enter a user name and password that is incorrect or is not recognized
by any of the farms in the search scope, the Enter Credentials dialog box reappears. If the user is an
Active Directory Service (ADS) user, you are prompted whether or not you want to do a full ADS tree search.
After resolving the credentials, a progress dialog may appear and then your search results appear.
8.7.7.4. Connecting to a Remote Server Console

Before connecting to a remote server console:
Enable connections to it. You can enable connections to a server console for all servers in a farm or
for individual servers.
Ensure you are a local administrator on each server to which you want to connect remotely.
To enable remote console connections for a farm

Services Console.
4. From the Properties list, select Server Default > XenApp.
5. Select Remote Console Connections to allow administrators to connect remotely to console sessions
on servers running Microsoft Windows 2003.
6. On the Remote Console Connections page, select Remote connections to the console.
To enable remote console connections for a server

Services Console.
2. In the left pane, select a server
4. From the Properties list, select XenApp.
5. Select Remote Console Connections.
6. Select Use farm settings (available on server level only) or Remote connections to the console.
To connect to a remote server console

Services Console.
3. From the Action menu, select All Tasks > Connect to server > Connect to server's console.
4. Click OK to accept the default values. If desired, you can specify values for the Width, Height, Colors
, and Encryption level for the remote console display. After you click OK, the connection progress
dialog box appears. You are prompted to enter your credentials and then the console appears.
8.7.7.5. To connect to a servers published desktop
You can access a servers desktop only if the desktop of the selected server is published, and the selected
server is running XenApp 5.0 or later.
Services Console.
3. From the Action menu, select All Tasks > Connect to server > Connect to servers
published 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.
Published Desktop. Select the published desktop from the list to which you want to connect.
Accept the Width and Height values or specify a different resolution.
Colors. Select the color depth for the application. The available options are 16 Colors, 256
Colors, High Color (16-bit), or True Color (24-bit).
Encryption. Select one of the following options from the list.
Basic encrypts the connection using a non-RC5 algorithm. 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.
8.7.7.6. To connect directly to a server's desktop

Configure connection settings to your server farm through the Microsoft Management Console (MMC)
using Terminal Services Configuration.
Services Console.
3. From the Action menu, select All Tasks > Connect to server > 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.
Accept the Width and Height values or specify a different resolution.
Colors. Select the color depth for the application. The available options are 16 Colors, 256
Colors, High Color (16-bit), or True Color (24-bit).
Encryption. Select one of the following options from the list.
Basic encrypts the connection using a non-RC5 algorithm. 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.

8.7.7.7. 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.
1. Select the farm in the left pane.
3. From the Properties list, select Farm-wide > Connection Limits.
4. Select Maximum connections per user and type the numerical limit.
5. Select Enforce limit on administrators to extend the connection limit to Citrix administrators.
Important: Limiting connections for Citrix administrators can adversely affect their ability to
shadow other users.
6. Select Log over-the-limit denials to record information about denied connection events in the server
s system log.
7. Click Apply to implement your changes and then OK to close the Farm Properties dialog box.
8.7.7.8. To disable and re-enable server logons
By default, logons are enabled for each server in a farm. You can disable logons on a per-server basis, such
as during maintenance, then re-enable after maintenance is complete.
Services Console.
3. From the Action menu, select one of the following:
All Tasks > Disable logon
All Tasks > Enable logon
4. Click Yes to confirm.
8.7.7.9. Enabling Local Browsers with Published Applications
To enable your users to use local browsers to open URLs found in remote published applications, enable
content redirection.
You can configure content redirection as a farm-wide server default setting or as an individual setting for
a particular server.
To enable content redirection for a farm
Services Console.
4. From the Properties list, select Server Default > XenApp.
5. Select Content Redirection to allow users to open URLs found in remote published applications in a
local Web browser.
6.
6. On the Content Redirection page, select Content redirection from server to client.
To enable content redirection on a server

Services Console.
4. From the Properties list, select XenApp.
5. Select Content Redirection to allow users to open URLs found in remote published applications in a
local Web browser.
6. On the Content Redirection page, select Use farm settings (available on server level only) or
Content redirection from server to client.
8.7.7.10. Restarting Servers at Scheduled Times
To optimize performance, you can restart a server 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 define when multiple servers restart
1. In the left pane of the Access Management Console, select the Servers folder.
2. In the Contents display in the right pane, press the SHIFT key and select the servers to restart.
3. From the Action menu, select All Tasks > Set restart options > Set restart schedule. This starts
the Set Restart Schedule wizard.
4. Use the wizard to configure your restart options.
To define when a single server restarts

1. In the left pane of the Access Management Console, select a server.
2. From the Action menu, select All Tasks > Modify server properties > Modify all properties.
3. In the Server Properties dialog box, select Restart Schedule and configure your restart options.
To stop restarts for a server

1. Select the servers you do not want to restart.
2. In the center pane of the Access Management Console, select Other Tasks > Set restart options
> Disable restarts.
8.7.7.11. To repair a XenApp installation
Updated: 2010-11-16
When you run the repair utility, if a public hotfix or hotfix rollup pack is installed, the same file versions of
the hotfix or hotfix rollup pack are reinstalled, not the original versions. Therefore, you can perform a repair on
a system without having to re-apply previously installed public hotfixes or hotfix rollup packs.
However, this excludes installed private hotfixes or other customizations; they are applied manually and
the system does not track them. In these cases, running the repair utility replaces the private hotfixes or
other customizations with the original files and settings.
1.
Log off from all sessions and exit any applications running on the server.
2.
Choose Start > Control Panel > Programs and Features.
3.
4.
Select Citrix XenApp <version>, click Change, and then select Repair when asked to select
the maintenance action you want to perform.
Restart the server when prompted.
8.7.7.12. Changing XenApp Farm Membership

To change the farm to which a XenApp server belongs, use the chfarm command utility. For more
information about chfarm including syntax, parameters, and limitations, see CHFARM.
8.7.7.13. Removing and Reinstalling XenApp
At times, you might have to remove servers from your farm or uninstall XenApp software from a server.
Some tasks you might need to perform include:
Moving a server to another farm
Renaming a server
Removing a server from your farm
Uninstalling XenApp from a computer in your farm or need to force its uninstallation
Removing a server from your farm if the hardware hosting XenApp fails
To accomplish these tasks, you might need to uninstall XenApp from its host computer, remove it from the
farm or from the list of farm servers in the Access Management Console or Delivery Services Console, or
both depending on your situation.
Moving a Server to a Different Farm
If you want to move a XenApp server to another farm, use the Change Farm (CHFARM) command. This
removes the server from the farm data store and from the lists of servers displayed in the consoles.
Renaming a Server
Follow the instructions in To rename a XenApp server to rename a server. They contain critical steps to
ensure records are not corrupted in the data store.
Uninstalling XenApp
Citrix recommends that you uninstall XenApp by using Control Panel > Programs and Features while the server
is still connected to the farm and the network. This method removes the host information from the farm
data store and removes the server from the farm properties displayed in the management tools.
When uninstalling servers that connect to the data store indirectly through another farm server, uninstall
the indirectly connected servers before uninstalling the directly connected server. Uninstalling the direct
server first prevents the other servers from being uninstalled properly from the data store.
Citrix does not recommend uninstalling XenApp from within a Remote Desktop Connection (RDC) session
because the uninstall program needs to log off all remote users as it uninstalls XenApp. If you need to
uninstall XenApp remotely, you can do so using tools such as Microsoft Configuration Manager 2007
(formerly Systems Management Server (SMS)).
Removing a Server from a Farm
If you want to remove a server from a farm, Citrix recommends that you uninstall XenApp. Then, check
the server was successfully removed from the farm and reimage it, if desired. While you can remove the
server from the farm using only the console, Citrix strongly recommends using the method explained in
To remove a server from the farm since it is safer.
Forcing the Uninstall of XenApp
If you cannot uninstall XenApp through the Control Panel, you can force the removal of the software by using
the Windows Msiexec command.
Removing a Server from a Farm Due to Hardware Failure
If the hardware for a server fails or it cannot be brought up to run the uninstall program, remove the
server. Citrix recommends that you only use the console to remove a server from the farm in cases where
the server cannot be brought up to run the 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 console and appear as a question mark (?) in the
list of Citrix administrators.
Reinstalling XenApp Due to Hardware Failure

If the hardware for a server fails, before you connect its replacement server to your network, change its name
to the same name as the failed server. 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.
When you assign a replacement server the failed servers name, make sure the settings on the
replacement server are identical to the failed server. This includes settings for the operating system, settings
for applications made during installation or when the application was published, and any user accounts on
the failed server.
Backing Up and Restoring the XenApp Data Store
Many data store maintenance tasks, such as backing up and restoring the data store, are performed using
the DSMAINT and DSCHECK commands. Some data store maintenances tasks have different
instructions according to the type of database (for example, Microsoft Access). The data store
maintenance instructions are in the Citrix XenApp Installation Guide.
Note: If the server that failed was hosting an indirect data store, create a new data store. If the new
server hosting the data store has a different name than the failed server, run the CHFARM command on
each server in the farm so they reference the new data store.
8.7.7.13.1. To remove XenApp
Updated: 2010-04-28
For illustration purposes, this procedure assumes that you installed XenApp with all options enabled.
Caution: If you are removing XenApp remotely, do not do so from within a Remote Desktop Connection
(RDC) session. Using RDC to remove XenApp remotely can result in you being unexpectedly disconnected
from the computer with no way to reconnect or complete the removal.
1. Log off from all sessions and exit any applications running on the server.
2.
If the Citrix License Server is running on the XenApp server you are uninstalling, manually stop
the License Management Console service. This action prevents Java errors during the uninstallation
that could result from other Citrix components that detect the service.
3. Choose Start > Control Panel > Programs > Programs and Features.
4. Select Citrix XenApp <version>, click Uninstall, click Yes when asked if you want to uninstall
XenApp, and follow the instructions that appear.
5. Remove XenApp. If you want to remove only specific components of XenApp, do so in the following order:
5.
Citrix Access Management Console or Delivery Services Console
XenApp Advanced Configuration or Presentation Server Console
Citrix XenApp
Citrix Web Interface
Citrix Licensing
Note: To complete the removal, you must restart the computer after you remove XenApp.
8.7.7.13.2. To force the uninstallation of XenApp
1.
If you need to force the uninstallation 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
2.
The following sample command line enables logging of the uninstallation operation and forces the
removal of XenApp: msiexec /x cps.msi /L*v c:\output.log CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=Yes
where cps.msi is the name and location of the msi package.
8.7.7.13.3. To remove a server from the farm

1. With the server still on the network and online in the farm, uninstall XenApp from the server from
Control Panel > Programs and Features by selecting Citrix XenApp 5.0 and selecting Uninstall.
2. Open the Access Management Console or Delivery Services Console on a different server, run or
rerun Discovery and check the server was removed from the farm successfully. If the server from
which you uninstalled XenApp still appears in the console:
2. From the Action menu, select All 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 reimage 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 5.0 (if you want to reuse the hardware for that server).
8.7.7.13.4. To rename a XenApp server
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 into the server.
3. Open the Access Management Console or Delivery Services Console on a different server, 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 service.
5. In the Registry, set the
HKEY_LOCAL_MACHINE\SOFTWARE\ Wow6432Node\Citrix\IMA\RUNTIME\PSRequired registry value to
1. This value is HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA \RUNTIME\PSRequired on XenApp, 32bit Edition.
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. 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.
8.7.7.14. Monitoring Server Performance with Health Monitoring & Recovery
You can use Health Monitoring & 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 10 tests; you have the option of
importing additional tests, including custom tests that you develop. The 10 tests included with XenApp allow
you to monitor several services and activities including Terminal Services, XML Service, Citrix IMA Service,
and logon/logoff cycles. These tests are:
Note: You can update the default names of these tests. Therefore, within your organization, the tests
might have different names from those specified in this topic.
Terminal 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.
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
Description
SessionTime
Defines the maximum session time for a short logon/logoff

cycle. Default is five seconds.
SessionInterval
The time period designated to monitor logon/logoff cycles. Default

is 600 seconds.
SessionThreshold
The number of logon/logoff cycles that must occur within the

session interval for the test to fail. Default is 50 cycles.
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
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.
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.
Note: Through the Health Monitoring & Recovery page of the Farm Properties and Server Properties
dialog boxes, you can configure the feature to allow additional tests to run on your servers.
Use the load balancing feature of XenApp with Health Monitoring & 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 Manager documentation at Citrix eDocs.
8.7.7.14.1. Enabling and Disabling Health Monitoring & Recovery
By default, Health Monitoring & Recovery is enabled on all of the servers in your farm, and the four 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.
To disable Health Monitoring & Recovery on all servers in a farm
1. In the left pane of the Access Management Console, select a farm.
2. From the Action menu, select Modify farm properties > Modify all properies.
3. In the Farm Properties dialog box, from the Properties list, select the Server Default >
Health Monitoring & Recovery.
4. Clear the Run health check tests on all servers in the farm check box.
To disable Health Monitoring & Recovery on a particular server

1. In the left pane of the Access Management Console, select a server.
3. In the Server Properties dialog box. from the Properties list, select Health Monitoring & Recovery.
4. Clear the Use farm settings and Run Health Monitoring tests on this Server check boxes.
8.7.7.14.2. Modifying Health Monitoring & Recovery Test Settings
The Health Monitoring & Recovery tests included with XenApp are configured with default settings. You
can modify the settings for each test by server or across all servers in a farm through the Health Monitoring
& Recovery page of the Server Properties or Farm Properties dialog box.
Selecting Recovery Actions
Alert Only
Sends an error message to the Event log but takes no other action. The test continues to run, and if
it subsequently successfully passes, an event is sent to the system log. This recovery action is the
default for all tests except the Citrix XML Service test.
Remove Server from load balancing
Excludes the server from load balancing. Clients do not attempt to make new connections to this
server through Load Manager. However, existing connections are maintained, and attempts are made
to reconnect disconnected sessions. You can make new direct connections to the server; this enables
you to try to correct any problems. To prevent possible farm-wide outages, this is the default
recovery action for the Citrix XML Service test.
Note: To restore one or more servers to load balancing, use the enablelb command-line utility.
Shut Down IMA
Shuts down the Citrix IMA Service. After this happens, tests continue to run but failures will not
trigger events to be sent to the Event log until the Citrix IMA Service is up and running again.
Restart IMA
Shuts down and then restarts the Citrix IMA Service. After this happens, tests will run but failures will
not trigger events to be sent to the Event log until the Citrix IMA Service is up and running again.
Reboot Server
Restarts the server. An alert is triggered before the server is restarted. After the system is restarted,
the tests resumes.
Note: If the Recovery Action list contains the entry Action ID followed by a number, this means that
Citrix supplied a new action through a hotfix. Although you applied the hotfix to the selected server, you did
not apply it to the computer on which the Access Management Console or Delivery Services Console is
running. When the hotfix is fully applied, a meaningful name for the new action is added to the list.
8.7.7.14.2.1. To modify the Health Monitoring & Recovery Tests settings for farms or a server
To modify the settings of Health Monitoring & Recovery tests for a farm
Services Console.
4. From the Properties list, select Server Default > Health Monitoring & Recovery.
5. Select a test and click Modify.
6. Make the necessary modifications and click OK.
To modify the settings of Health Monitoring & Recovery tests for a server
Services Console.
4.
4. From the Properties list, select Health Monitoring & Recovery.

5. Clear the Use farm settings check box and ensure Run Health Monitoring tests on this server
is selected.
6. To copy existing tests from the farm to the server, click Copy From Farm.
7. Select a test and click Modify.
8. Make the necessary modifications and click OK.
8.7.7.14.3. Adding Health Monitoring & Recovery Tests
You can add two types of Health Monitoring & Recovery tests to your servers: tests supplied by Citrix through
the Citrix Knowledge Center and custom tests developed by your organization or third parties.
Citrix recommends that you store all tests in the following location:
%Program Files%\Citrix\HealthMon\Tests\
where %Program Files% is the location in which you installed XenApp. Store Citrix-supplied tests in the
Citrix folder and custom tests in the Custom folder.
Note: For information about custom tests, see Developing Custom Health Monitoring & Recovery Tests.
To add tests to a farm

Services Console.
4. From the Properties list, select Server Default > Health Monitoring & Recovery.
5. Click New.
6. In the New Health Monitoring & Recovery Test dialog box, select the Allow running custom
Health Monitoring tests check box. This setting is disabled by default. By selecting this check box,
you can import a test by typing or navigating to the appropriate file path in the Test file field.
To add tests to a server

Services Console.
4. From the Properties list, select Health Monitoring & Recovery.
5. Clear the Use farm settings check box and ensure Run Health Monitoring tests on this server
is selected.
6. Click New.
7. In the New Health Monitoring & Recovery Test dialog box, select the Allow running custom
Health Monitoring tests check box. This setting is disabled by default. By selecting this check box,
you can import a test by typing or navigating to the appropriate file path in the Test file field.
8.7.7.14.4. Developing Custom Health Monitoring & Recovery Tests
If you want to perform particular tests that are not included in Health Monitoring & Recovery, you can
develop custom tests using the Health Monitoring & Recovery SDK. This SDK includes a Readme file and
white papers that contain information required to use the SDK, including security requirements and return
values. In addition, the SDK contains various sample test scripts that you can use as examples to develop
custom tests that can be run on a server farm or on individual servers in a farm. The Health Monitoring
& Recovery SDK is available for download from the Citrix Knowledge Center.
8.7.7.14.5. Getting Health Monitoring & Recovery Alerts

In the event of a test failure, an HCAService Test Failed alert is raised for the relevant server. This
alert, displayed in the Access Management Console or Delivery Services Console, indicates the name of the
test that failed. For information about the alert that appears, view the Citrix Knowledge Center article
associated with the alert.
The default recovery action for all tests (except the Citrix XML Service test) is that an error message is sent to
the Event log. For the Citrix XML Service test, the default action is to exclude the server from load balancing
to prevent possible farm-wide outages.
Note: In the Advanced Edition of XenApp, XML ticketing failures also result in the server being excluded
from load balancing. This action is performed by the Citrix XML Service and not by Health Monitoring
& Recovery, so no alerts are sent. For any servers excluded in this way, the IMA service needs to be
restarted for the server to rejoin the load balancing tables.
If the test is run again and it is successful, an event is sent to the Event log.
8.7.7.15. 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:
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. Select Start > Administrative Tools > Server Manager.

2. In the Tree view, Select Diagnostics > Reliability and Performance > Monitoring Tools
> Performance Monitor.
3. Click Add.
4. In the Add Counters dialog box, from the Select counters from computer drop-down list, ensure
Local computer is selected.
5. In the Available counters list, select ICA Session.
6. 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.
7. 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.
8. Click Add and then click Close.
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.
8.7.7.16. Optimizing Server Performance
XenApp provides you with a number of ways to optimize the performance of the servers in your farm:
Assigning load evaluators to servers and published applications
Managing CPU usage
Managing virtual memory usage
Enhancing the performance of remote servers
Working with the cache
Updating license server settings
8.7.7.16.1. 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 allocates an equal share of the CPU to each user.
This prevents one user from impacting the productivity of other users and allows more users to connect to
a server.
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.
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. The percentages stated here are of the available,
not the total, CPU resource.
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-64. For CPU reservation, the total cannot be more than 100%,
which represents the entire CPU resource on the computer.
Do not enable CPU optimization on farms or servers that host:
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.
8.7.7.16.1.1. Enabling CPU Utilization Management

You can enable CPU utilization at the farm level and at an individual server level. This feature is not enabled
by default.
To enable CPU utilization management for a farm
Services Console.
2. In the left pane, select the farm for which you want to enable CPU utilization management.
4. In the left pane of the Farm Properties dialog box, click Server Default > Memory/CPU >
CPU Utilization Management.
5. On the CPU Utilization Management page, select the CPU Utilization Management check box,
if desired.
To enable or disable CPU utilization management for a server

Services Console.
2. In the left pane, select the server for which you want to enable CPU utilization management.
3. Select Action > Modify server properties > Modify all properties.
4.
4. In the left pane of the Server Properties dialog box, click Memory/CPU > CPU
Utilization Management.
5. On the CPU Utilization Management page, select the CPU Utilization Management and Use
Farm Settings check boxes, as appropriate.
8.7.7.16.2. Managing Virtual Memory Usage
You can improve system speed, performance, and scalability by controlling virtual memory utilization for a
farm or individual servers. This feature 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.
To increase the number of users who can use a server and improve a farms ability to optimize the use of
DLLs stored in virtual memory, enable memory utilization management. When you enable memory
utilization management, you enable the rebasing of DLLs for virtual memory savings without actually
changing the DLL files. You can also schedule the rebasing of DLLs for off peak hours, exclude
specific applications from DLL rebasing, and rebase DLLs through a user account with permissions to
access application files stored on file servers.
You do not want to enable memory utilization management on farms or servers that exclusively host signed
or certified applications. XenApp can detect only some published applications that are signed or certified.
Caution: If, after enabling memory utilization management and running scheduled memory
optimization, published applications fail, exclude those applications from memory optimization.
Before Deploying Memory Utilization Management

1. Using a test server hosting your published applications, enable memory utilization management.
2. Schedule memory optimization.
3. After memory optimization completes, run all published applications.
4. Add to the exclusion list those applications that fail.
8.7.7.16.2.1. Enabling Memory Utilization Management
You can enable memory utilization management at the farm level and at an individual server level. This feature
is not enabled by default.
To enable memory optimization for a farm
Services Console.
2. In the left pane, select the farm for which you want to enable memory optimization.
4. In the left pane of the Farm Properties dialog box, click Server Default > Memory/CPU >
Memory Optimization.
5. On the Memory Optimization page, select the appropriate check boxes.
To enable memory optimization for a server

Services Console.
2. In the left pane, select the server for which you want to enable memory optimization and select Action
> Properties.
3. In the left pane of the Server Properties dialog box, click Memory/CPU > Memory Optimization.
4. On the Memory Optimization page, select the appropriate check boxes.
When you enable virtual memory optimization at the server level, virtual memory optimization occurs at a
time set by the farm-wide schedule. After enabling memory optimization, create a schedule for when the
servers can rebase DLLs.
8.7.7.16.2.2. Scheduling Virtual Memory Optimization
After enabling virtual memory optimization, you create a virtual memory optimization schedule that
identifies when a server rebases DLLs for greater operating efficiency.
When a server rebases a DLL:
It makes a hidden copy of the DLL
It modifies the starting address of the DLL to avoid conflicts that result in multiple copies of a single
DLL held in virtual memory
Schedule virtual memory optimization at a time when your servers have their lightest loads.
8.7.7.16.2.2.1. To create a memory optimization schedule
Services Console.
2. In the left pane, select the farm for which you want to create a virtual memory optimization schedule.
4.
In the Farm Properties dialog box, choose Farm-wide > Memory/CPU > Optimization Interval.
5. In the Optimization interval area, specify when to run the optimization program to set the frequency
at which the server rebases DLLs. You can set the frequency to be every time you restart your
server, every day, once a week, or once a month (daily is the default). If you choose to run the
program weekly or monthly, specify the day of the week or month.
Note: Citrix recommends that if you select Day of month, you do not enter a value higher than 28
in the text box. If you specify a higher value, memory optimization may not occur in some months.
6. Specify the startup time (3:00 by default) in the Optimization time box to set the time at which
the server begins rebasing DLLs. The optimization time is specified using a 24-hour clock format.
Note: If you selected to optimize at startup, this option is disabled.
7. In the Memory optimization user area, if you want the memory optimization program to
run automatically using the local system account, select the Use local system account check
box (enabled by default).If you want to run the optimization program with a local or remote user
account (for example, if you store application files on a file server or remote server that requires
special access permissions, such as a domain administrator), clear the Use local system account
check box and supply the valid user name and password of a domain or local administrator.
Note: The user must have read-write permission to all the files that you want to be optimized.
8.
Click Apply to implement your changes and then OK to close the Farm Properties dialog box.
8.7.7.16.2.3. Excluding Applications from Memory Optimization

The following applications are excluded from being rebased by virtual memory optimization:
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 fail after you enable memory optimization. Add the applications' executables to
the memory optimization exclusion list.
8.7.7.16.2.3.1. To exclude additional applications from memory optimization

1.
Services Console.
2. In the left pane, select the farm on which you want to exclude additional applications from
memory optimization.
4.
In the Farm Properties dialog box, choose Farm-wide > Memory/CPU > Exclude Applications. The
Exclude Applications page appears. This page lists the applications that memory optimization
ignores. For example, some applications require a fixed DLL address. If an application was working but
it stops working after enabling this feature, add the application to this list and see if the problem
is resolved.
5. Click Add. The Browse Files dialog box listing all servers in the farm appears.
6. Navigate to the applications from each server that you would like memory optimization to ignore, clicking
OK to add each executable to the Exclude Applications page.
7. Click Apply to implement your changes and then OK to close the Farm Properties dialog box.
8.7.7.16.3. Optimizing Simultaneous Logon Performance
You might see an improvement in simultaneous logon performance if you enable disk write caching on the
servers RAID controller. The reason is the logon process is dependent on dynamic information and is handled
by a data collector in the farm rather than being dependent on the data store.
8.7.7.17. 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.
Citrix does not recommend publishing applications on infrastructure servers.
These topics contain information about data collectors, zones, and the local host cache:
Maintaining the Local Host Cache
Data Collectors and Elections
Enhancing the Performance of a Remote Group of Servers
8.7.7.17.1. 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.
8.7.7.17.1.1. 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.
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)
Note: This registry key is HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\ DCNChangePollingInterval
(DWORD) on XenApp, 32-bit Edition.
You must restart the IMA Service for this setting to take effect.
Most changes made through the Access Management Console, Delivery Services Console, XenApp
Advanced Configuration, or Presentation Server Console are written to the data store. When you open one
of these tools, it connects to a specified server. The Citrix Independent Management Architecture service
running on this server performs all reads and writes to the data store for the console.
If the data store is experiencing high CPU usage when there should not be significant read or writes to the
data store, 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.
8.7.7.17.1.2. 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 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.
8.7.7.17.1.3. Recreating the Local Host Cache
You can manually create the local host cache from the farms data store. If the Citrix 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:
Sets the value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ RUNTIME\PSRequired to 1. This key
is HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\ RUNTIME\PSRequired to 1 on XenApp, 32-bit Edition.
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 Citrix IMA Service fails to start.
8.7.7.17.2. Data Collectors and Elections
A data collector is 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 their zone. Data collectors
relay information to all other data collectors in the farm. The data collector tracks, for example, which
applications are available and how many sessions are running on each server in the zone. The data
collector communicates this information to the data store on behalf of the other servers in the farm. By default,
in farms that communicate indirectly with the data store, the first server in the farm functions as the
data collector.
Farms determine the data collector according to what level the election preference is set for a server. By
default, all servers joining the farm are configured as backup data collectors. When the zones data collector
fails, a data collector election occurs and a backup data collector replaces the failed data collector.
If the data collector fails, existing and incoming sessions connected to other servers in the farm are not
affected. The data collector election process begins automatically and a new data collector is elected
almost instantaneously. Data collector elections are not dependent on the data store.
New Data Collector Election
When communications fail between data collectors or between a server and its data collector, the process
to choose or elect a new data collector begins. For example:
1. The data collector for Zone 1 has an unplanned failure. If the data collector shuts down correctly, it
triggers the election process as it shuts down.
2. The servers in Zone 1 detect the data collector failed and start the election process. The server set to
the next highest election preference is elected as the new data collector.
3. The member servers start sending their information to the new data collector for Zone 1.
4. The new Zone 1 data collector replicates this information to the other data collectors in the farm.
Sometimes, you might decide to have a dedicated data collector after your farm is in production. In general,
if users experience slow connection times due to high CPU utilization on the data collector, consider dedicating
a server to act solely as the zone data collector.
8.7.7.17.2.1. Specifying Backup Data Collectors
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 recommend such installations.
To set the data collector election preference of a server
2. Select the farm.
3. On the Actions menu, click Properties.
4. Select Zones.
5. In the list of zones and their servers, locate the server, select it, and click Set Election Preference.
6. Select the ranking for the server by choosing from the following election options:
Important: If you change the server name of the data collector, the new server name is added to
the list of servers in the farm. The old server name is still listed as a member of your farm and must
be removed using the Access Management Console. Before removing the old server name, you
must update the data collector ranking for the new server name.
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).
8.7.7.17.3. Enhancing the Performance of a Remote Group of Servers
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.
This illustration depicts a server farm with multiple zones. Each zones data collector communicates with the
other data collectors across the WAN link.
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.
Zones have two purposes:
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 zone
s servers and published applications. In farms with more than one zone, data collectors also act
as communication gateways between zones.
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.
You can create zones during XenApp installation or after installation. This topic provides information
about creating zones after Setup, moving servers between zones, and renaming zones. For design
considerations for zones, including whether to zones for small groups of remote servers, see the Citrix
XenApp Installation documentation at Citrix eDocs.
For business continuity, you can specify that if all zone servers go offline, XenApp redirects user connections to
a backup zone. This feature is known as Zone Preference and Failover; you configure it through the
User Workspace > Connections > Zone preference and failover policy rule.
To minimize data exchanges among zones on WANs, and the ensuing network traffic, you should:
Not configure zones to load balance across zones (share load information). By default, load
balancing between zones is disabled.
Direct requests for applications to the nearest geographic location by specifying a preferred
zone connection order in the User Workspace > Connections > Zone preference and failover
policy rule.
Create a policy that applies to connections from a zones location. Then, specify that zone as the
Primary Group zone in the Zone preference and failover rule. This makes XenApp route
incoming connection requests from users to the zone for their location first.
Zones are view-only in the Access Management Console and Delivery Services Console. Use XenApp
Advanced Configuration or Presentation Server Console to configure zones.
8.7.7.17.3.1. To configure zones in your farm
2. Select the farm.
3. On the Actions menu, click Properties.
4. Select Zones.
Change the configuration of the zones in your farm by selecting:
The buttons provided.
The Only zone data collectors enumerate Program Neighborhood check box to make your
server farm more secure. When Program Neighborhood users browse for application sets,
servers enumerate, or list, the published applications they are authorized to launch. When this option is
not selected, any server in the farm can respond to client enumeration requests. For any server in the
farm to enumerate users applications, you must allow users to retain the Windows Group Policy right
to log on locally to every server. When you select this option, a data collector is always used to
specify which applications appear for a user in Program Neighborhood. You can then confine users
access to the servers that are or may become data collectors.
Do not select this option if you want the fastest possible enumeration of applications to occur in
Program Neighborhood and security is not a concern.
Important: Servers running some earlier releases of XenApp in a mixed farm cannot access this
farm setting to direct a connection for enumeration correctly. If users are directed to a server on
which they are not permitted access, their applications cannot be enumerated and they will receive
error messages. Citrix recommends that you maintain all servers in a farm at the same release level.
The Share load information across zones check box to allow data collectors to exchange server
load information across zones and ensure users are efficiently routed to the least loaded server in
any zone. Enable this setting only if the following conditions are true:
The bandwidth capacity among zones is not limited, such as if the zones are in the same LAN
You are not implementing zone preference and failover policies
Selecting this option can result in increased network traffic because every change in server load
is communicated to all data collectors across all zones. Connection requests are routed to the least
loaded server in the server farm, even a server located across a WAN, unless a preferred order
is established using the Zone preference and failover policy rule. When you establish a
preferred connection order, the zone data collectors query the preferred zones in the order you set.
To create new zones

Use the New Zone dialog box to enter the name of the new zone.
Empty zones are not allowed. After you create a new zone, you must move one or more servers into the
new zone before you click OK in Zones or exit Zones by making another selection in the left pane of the farms
Properties page.
To rename zones
Use the Rename Zone dialog box to change the name of the zone you selected. Enter the new name of the
zone in the text box provided.
If you change the server name of the data collector, the new server name is added to the list of servers in
the farm. The old server name is still listed as a member of your farm and must be removed using the
Access Management Console or Delivery Services Console.
To move servers between zones
Use the Move Servers dialog box to move the selected server to another zone. This button is available
only when one or more servers is selected.
After you move one or more servers among zones, you must restart each server that was moved. This is
required to update the data collector information for each zone.
To remove zones
Use the Remove Zone button to delete the selected zones. A zone cannot be removed until all the servers in
the zone are moved to other zones.
8.7.7.18. Updating Citrix License Server Settings
Use the License Server page in the farms Properties dialog box to change the name of the license server
or port number that the license server uses to communicate. You can apply the changes to either an
individual server (on the License Server page of the servers Properties dialog box) or an entire farm and
you can type the license server name or its IP address in the Name field.
License files are stored on a license server. XenApp servers must point to the license server. After you
install XenApp, you can change the port number or license server name on the license server Properties
dialog box for the farm or an individual server.
The settings for your Citrix License Server are configured automatically when you install the licensing
components as part of the Setup program for your Citrix product. Two of these settings are the name of
the license server that your farm accesses to check out licenses and the port number the license server uses
to communicate. You may want to change these settings in the following instances:
You rename your license server.
You want to specify another license server to point to (either for an entire farm or for individual
servers only) to relieve some of the traffic to the 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, type the license
server name or its IP address in the Name field of the License Server page of the servers or farms Properties
dialog box (to apply the changes to either an individual server or an entire farm). 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. For additional information, see Licensing Your Product.
If you change the port number, specify the new number in all license files on the server. For
additional information, see Licensing Your Product.
8.7.7.18.1. To specify a default license server for a farm
Services Console.
3. From the Action menu, select Modify farm properties > Modify license server properties.
4. Modify one or more of the following values:
Name. You can enter either a license server name or an IP address
Port number (default 27000). Enter the license server port number
Note: If you change the port number, you must specify the new number in all license files on
the server. For additional information, see Licensing Your Product.
5. Click Apply to implement your changes.

8.7.7.18.2. To specify a license server for individual servers
Use this method to specify a license server for individual servers in your farm.
Services Console.
3. From the Action menu, select Modify server properties > Modify license server properties.
4. Clear the Use farm settings check box (selected by default).
5. Specify the following information:
Name. Because license files are tied to the license servers host name, if you change the
license server name, you must ensure that you 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. Additionally, before you change the server
name, ensure that there is a license server with that name on your network. Note that you
cannot leave the license server name blank.
Port Number. If you change the port number, you must specify the new number in all license
files on the server. For additional information, see Licensing Your Product.
8.7.7.19. 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 edition of the product for each server.
The product edition also determines which type of license a server requests from the license server. Make
sure the editions you set match the licenses you installed.
Important: To apply changes to the product edition, you must restart the servers.
Services Console.
2. In the left pane, select the required server.
3. From the Action menu, select All Tasks > Set server edition.
4. Select the required edition.
Important: Do not select Other unless you are asked to do so by Citrix Technical Support.
8.7.7.20. Setting the Citrix XML Service Port
The Citrix XML Service is used by clients connecting over the TCP/IP+HTTP protocol and the Web Interface.
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.
If you chose to have the XML Service share the port, this page displays a short message to this effect.
If you chose a particular port during installation, the TCP/IP Port field reflects your choice. Use this field
to 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 this option to change the port number.
If you do not trust XML requests, certain features of XenApp are not available. Trusting requests sent to the
XML Service means:
Users can move among client devices and reconnect to all of their applications. For example, you can
use workspace control to assist health-care workers in a hospital who need to move quickly
among workstations and be able to pick up where they left off in published applications.
Users can connect to the Web Interface using pass-through authentication or smart cards to reconnect
to ICA sessions. These credentials are not passed from the server running the Web Interface to the
servers on which the users access their applications. Users can reconnect to their ICA sessions even
though their credentials are not passed when this option is selected.
XenApp can use the information sent in those requests by Access Gateway (Version 4.0 or later).
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.
Others on the network can disconnect or terminate sessions without authentication. It can also allow
clients to make false security assertions.
To avoid security risks, select Trust requests sent to the XML Service only under the following conditions:
Some users connecting to their ICA sessions using the Web Interface are also using passthrough 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.
8.7.7.20.1. To configure the Citrix XML Service port for a server

1.
Select the server in the left pane
2.
From the Action menu, select Modify server properties > Modify all properties.
3.
From the Properties list, select XML Service.
4.
5.
Select the Trust requests sent to the XML Service check box if you ensured that only trusted
services communicate with the XML Service.
Click Apply.
8.7.7.20.2. 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.
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:
ctxadmin.dll
CtxConfProxy.dll
ctxsta.dll
radexml.dll
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.
7.
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.
At a command prompt, stop the XML Service by typing: net stop ctxhttp
8.7.7.20.3. To manually configure Citrix XML Service to share the TCP port with IIS
Updated: 2010-03-31
1.
At a command prompt, stop the XML Service by typing: net stop ctxhttp
2.
At a command prompt, to uninstall the Citrix XML Service, type: ctxxmlss /u
3.
Copy the following files to the IIS scripts directory on your Web server:
ctxconfproxy.dll
ctxsta.config
ctxsta.dll
ctxxmlss.exe
ctxxmlss.txt
radexml.dll
wpnbr.dll
These files are installed in \Program Files\Citrix\System32 during XenApp installation. The default
scripts directory is \Inetpub\AdminScripts.
4.
5.
6.
In the IIS scripts directory, create a folder called ctxadmin and copy the file ctxadmin.dll from
\Program Files\Citrix\System32 to \Inetpub\AdminScripts\ctxadmin.
Use Internet Service Manager to give the files read and write access.
6.
At a command prompt, stop and restart the Web server by typing: iisreset This setting takes effect
after the Web server restarts.
8.7.8. 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:
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.
8.7.8.1. Introduction to Windows Printing Concepts
This section provides a limited overview of basic printing concepts in a standard (non-Terminal Services)
Windows environment. However, Citrix recommends reviewing the Windows documentation about
network printing, print servers, and Terminal 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. 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.
8.7.8.1.1. 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 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 nonCitrix 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.
8.7.8.2. XenApp Printing Concepts

Updated: 2010-03-10
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:
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:
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
8.7.8.2.1. 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:
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 user
s session to a print server and spooled remotely.
This diagram shows a XenApp network printing example: Printing begins on the farm server hosting the user
s 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.
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 user
s session and is routed to a printing device attached locally to the server.
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 XenApp Plug-in for Hosted Apps.
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.
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.
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.
8.7.8.2.2. 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:
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. While there are other ways in which printers can be provisioned, such as through Active
Directory policies, this topic discusses the most common methods using XenApp.
The two most common methods of dynamic printer provisioning are:
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.
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:
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:
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.
8.7.8.2.2.1. Auto-Creating Client Printers
The main purpose of the autocreation feature is to create a list of printers that a user can use when they log
in. 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:
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 Auto-creation policy rule lets you control autocreation and specify that:
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
You can also use the Auto-creation policy rule to specify that XenApp auto-creates network printing devices
that are accessible through the client device only. An example is printing devices in a domain different from
the application server.
When configuring policies for printer autocreation, ensure:
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
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:
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:
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:
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 XenApp Plugin for Hosted Apps or the Citrix XenApp Plug-in for Streamed Apps (when streaming to the server).
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 XenApp Plug-in for Streamed Apps 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.
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 rule Printing >
Client Printers > Legacy client printers is not set to Create old-style client printers in any
policies affecting those sessions. If the Legacy client printers rule is enabled, set it to Create
dynamic session-private client printers.
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 later and
the Citrix XenApp Plug-in for Streamed Apps (streamed to server). This feature is available in
Presentation Server 4.0 to XenApp 5.0
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 clientside 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 in conjunction 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.
Unlike many printing settings, the Universal Printer does not appear in the policy rules. By default, the
Universal Printer does not appear in XenApp unless you enable it by editing the registry. When 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 set the Printing > Client Printers > Auto-creation
rule 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 XPSbased Citrix Universal Printers provide ways to preview and select settings:
EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display a Print
Previewer before printing. Clicking Local Settings in the Citrix Print Previewer is the only way users
can select a different printer, control the device settings for the printer hardware, and preview the
print job. You control whether or not the Local Settings button is available to users. If you do not
allow users to change their printer through the Local Settings button, the Citrix Universal Printer prints
to the default printer on the client 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 or the Citrix XenApp Plug-in for Hosted Apps, Version 11. x.
8.7.8.2.2.2. 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 Session Printer policy rule.
The key difference between provisioning network printers with the Printing > Client Printers > Auto-creation
rule and the Printing > Session printers rule is that the Auto-creation rule automatically creates all printers
on the client device whereas the Session printers rule lets you specify which printers are created.
Network printers created with the Session printers rule can vary according to conditions where the session
was initiated, such as location (by filtering on objects such as subnets).
Before you can configure the Session printers rule, you must import the printer objects stored on your
print server into your XenApp farm. After importing printers into XenApp, you can assign them to user
sessions through the Session Printer policy rule. See Configuring Network Printers for Users
Note: For printers in domains that do not have a trust relationship with the XenApp farm, configure them
as redirected client printers using the Auto-creation rule. When network printing devices are provisioned in
this way, the print jobs are routed through the client using the client printing pathway.
8.7.8.2.2.3. 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 policy rules except the Auto-creation rule.
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 clientside 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.
8.7.8.2.3. 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. XenApp policies 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). NonWindows plug-ins synchronize changes made out of sessions automatically.
8.7.8.2.3.1. Device-Based Print Settings
Updated: 2010-03-10
Caution: Using Registry Editor incorrectly can cause serious problems that may require you to install
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 plugin 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 plugin 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.
8.7.8.2.3.2. Controlling Printing Settings and User Preferences
To understand how printing preferences are retained and applied, you must understand:
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
Control Panel > Printers 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 Control Panel > Printers 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.
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.
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.

8.7.8.2.4. Setting Default Printers
The printer that XenApp selects for a sessions default printer can be based on:
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 Session printers policy rule. See
To assign printers using the Session printers policy rule 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.
8.7.8.2.5. 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:
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 Session printers policy rule.
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:
The name of the workstation, if the name relates to the workstations location
Your networks IP addresses, if they correlate with user locations
8.7.8.2.6. 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:
Through the plugin. 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 is chatty; 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, enable the Printing > Client Printers
> Print job routing policy rule and select the Always connect indirectly as a client printer option. See
Print Job Routing for policy details.
8.7.8.2.7. Managing Printer Drivers
Updated: 2009-10-16
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 server
s 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 accessib
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:
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 to find it and a users job
may fail to print.
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:
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
8.7.8.3. 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:
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.
8.7.8.3.1. Default Printing Behavior
Updated: 2010-03-10
By default, if you do not configure any policy rules, XenApp has this printing behavior:
All printers configured on the client device are created automatically at the beginning of each session.
This behavior is equivalent to enabling the Printing > Client Printers > Auto-creation policy rule
with the Auto-create all client printers option selected.
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 enabling the Printing
> Client Printers > Print job routing policy rule with the Connect directly to network print server
if possible option selected.
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 enabling the Printing > Client Printers > Printer properties retention policy rule
with the Held in profile only if not saved on client option selected.
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 installs the driver from the Windows operating
Printing > Drivers > Native printer driver auto-install policy rule with the Install Windows
Native drivers as needed option selected, and enabling the Printing > Drivers > Universal driver
policy rule with the Use universal driver only if requested driver is unavailable option.
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.
8.7.8.3.2. Printing Policy Configuration
When users access printers from published applications, you can configure XenApp policies to specify:
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.
8.7.8.3.3. 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:
The account that the print manager service runs in (default: Ctx_cpsvcuser)
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.
8.7.8.3.4. Purchasing Printing Hardware
Updated: 2010-09-07
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.
8.7.9. Configuring and Maintaining XenApp Printing
This topic provides procedures for configuring and maintaining printing. This topic assumes that you
understand the information provided in Understanding XenApp Printing and that you already planned
your printing deployment.
This topic complements the information about printing policies in the Policy Rules Reference.
8.7.9.1. Configuring Printing
Most XenApp printing functions are configured through XenApp policies. To find printing policy rules, select
the following in the tool known as XenApp Advanced Configuration or Presentation Server Console (depending
on the version of XenApp you have installed):
Bandwidth > Session Limits > Printer. This rule restricts the bandwidth allocated to printers.
Printing > Client Printers. These rules affect the client redirected printers and printing using the
client printing pathway.
Printing > Drivers. These rules control driver management.
Printing > Session printers. This rule configures how network printers are provisioned and specifies
a default network or client printer.
However, some printing management tasks are performed in the Printer Management node, which
controls farm connections to print servers, drivers, and printing bandwidth on a per-server basis
If you do not enable any policy rules that affect printing, XenApp uses the default printing behavior that
is described in Planning Your Printing Configuration.
Printing policy rules follow standard XenApp policy behavior:
Printing rules in policies are evaluated during initial logon and remain in force throughout the session.
Any new printers added to a policy or a client 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 XenApp policy rules. Therefore,
when configuring printing rules, you need to 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.
XenApp policy behavior

Xenapp policies do not behave like Microsoft policies. Review the distinction between Not Configured and
Disabled, best practices for creating policies, resultant policies, and other policy topics.
Policy prioritization
All printing rules follow standard XenApp prioritization. Xenapp 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 rules.
8.7.9.1.1. Configuring Printer Autocreation Settings
Enable this rule to control how or if printers are created automatically at the start of sessions. By default, this
rule is not enabled, so XenApp creates all printers on the client device.
To modify printer auto-creation behavior
2. In the left pane, select the Policies node.
3. On the Contents tab, choose the policy you want to configure for printing rules.
4. From the Actions menu, choose Properties.
5. Select Printing > Client Printers and enable the Auto-creation rule.
Auto-create all client printers. All network printers and any printers attached to or mapped
from the client device preconfigured in the Printers Control Panel are auto-created in the session.
Auto-create local (non-network) client printers only. Any non-network printers attached to
the client device preconfigured in Control Panel > Printers are auto-created in the session.
Auto-create the clients default printer only. Only the clients default printer attached to
or mapped from the client preconfigured in Control Panel > Printers is auto-created in the session.
Do not auto-create client printers. Client printers are not auto-created.
To configure legacy client printer support

Enable this rule to auto-create client printers before MetaFrame 3.0.
3. On the Contents tab, choose the policy you want to configure for printing rules.
5. Select Printing > Client Printers and enable the Legacy client printers rule.
Create dynamic session-private client printers to create printers that use default Presentation
Server 4.0 to XenApp 5.0 naming conventions
Create old-style client printers to create printers that use printer names that are compatible
with MetaFrame 3.0 or earlier
8.7.9.1.2. 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 the Citrix Universal Printer
The following procedure provides instructions about configuring the Citrix Universal Printer. If you want to use
the Universal Printer, configure it on each server hosting published applications in your farm.
1. Find the following registry key on each server: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Print

2. Modify the registry key, DefaultPrnFlags, so that it has a bit value of 0x00000020.
3. Restart the Citrix Print Manager Service.
To change the default settings on the Universal Printer

You can change the 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.
8.7.9.1.3. Configuring Auto-Creation for DOS and Windows CE Clients
If devices running the Client for Windows CE have local printers, you can auto-create these client printers
for users each time the client devices connect to the server farm using the tool known as XenApp
Advanced Configuration or the Presentation Server Console, depending on the version of XenApp you
have installed.
In this case, client printers refers to client redirected printers (printers that are physically attached to
client devices or mapped from client devices) for DOS and Windows CE Clients.
Note: Unlike devices running the Client for Windows CE with local printers, client printers available from
other clients are auto-created based on the settings configured using Printing policies.
When you configure auto-creation, XenApp downloads appropriate printer objects to the client device to make
the client printer available in client sessions.
You can view the status of printers for clients on DOS and Windows CE platforms in the Client Printers
dialog box. In the dialog box, the word <downloaded> appears in the list when information for client
printer setup is sent from the server to the client device.
To add a printer to the Windows CE and DOS auto-creation list
Use this dialog box to define the client printers that are available to named devices running the Client
for Windows CE. Each time users of those devices log on to your farm, those client printers are available to
them automatically.
After adding a new client printer at your organization for use by Windows CE and DOS users, update the
auto-creation list to ensure the definition is available when printers are auto-created at the beginning of sessions.
2. Under the Printer Management node, select Printers.
3. From the Actions menu, choose Printer Management > Client Printers. The Client Printers dialog
box appears. This dialog box lets you add, reset, edit, and delete the printers that will be auto-created
for the clients for DOS and Windows CE printers.
Note: These printers are available only on the client and appear only in server-based applications
during the users session.
4. Click Add.
5. In the Add Client Printer dialog box, type the name of the client device in the Client Name box.
6. Specify the printer driver name in one of the following ways:
In the Driver box, type the name of the driver on the client printer.
Browse for the Driver Mapping by clicking one of the following buttons:
Click Browse Mappings to open a dialog box from which you can select a driver
mapping. This dialog box displays the name of the client printer driver and the server
printer driver.
Click Browse Drivers to open a dialog box from which you can select a printer driver.
All printer drivers available in the farm are listed. The driver name that appears is the
name of the server printer driver.
7. In the Port drop-down box, select the printer port. The client printer information is downloaded the
next time the client device connects to the farm.
Tip: You can check if the client printer information was downloaded in the Status column - Pending
or Downloaded.
To display auto-created printers for Windows CE and DOS clients

1.

2. Under the Printer Management node, select Printers.
3. From the Actions menu, choose Printer Management > Client Printers.
The information about each selected client printer appears under the following columns:
Client Name. The name of the client device.
Printer Name. The name of the client printer.
Driver. The name of the driver on the client printer.
Port. The port on which the client printer is connected to the client device.
Status. Displays values of Pending, Downloaded, or Deleting.
Pending. The client has not yet connected to the farm to allow information download for the
client printer.
Downloaded. The client connected and the client printer information was downloaded.
Deleting. The auto-creation setting for the client printer is set to be deleted, but the client has
not connected to the farm. When the client connects, the client printer is removed from the
client and the client printer entry is removed from the displayed list.
Note: These printers are available only on the client device and appear only in server-based
applications during the users session.
4. To include client printers with Downloaded status in the list, click the Show downloaded printers
check box.
5. To change the status of the selected client printer, click the Reset. For printers that are currently
Deleting, the status is changed to Downloaded. For printers that are currently Downloaded, the status
is changed to Pending. When the plugin next connects, the client printer information is downloaded.
To update auto-created DOS and Windows CE client printer entries

1. Perform any of the following tasks to update your auto-created DOS and Windows CE client printer entries:
To change the driver or port assigned to a client printer, click Edit to open the Edit Client Printer
dialog box.
To delete a client printer from the list, click Delete.
To download the client printer configuration again, click Reset. The status of the client printer is
set to Pending and its information is downloaded the next time the client device connects to the farm.
8.7.9.1.4. Configuring Network Printers for Users

Before you can make network printers available to users, you must import information about these printers
into your farm. This lets farm servers establish a connection to a network printer when a user prints.
Making printers available to users requires performing two tasks, in sequence:
1. Importing the network print server information.
2. Assigning the imported network printer to users (that is, making it appear in sessions by filtering on
an object that applies to the users session).
You can import all the information either for one printer or all the printers on a print server. Before
importing, have on hand the path for the printer in the form servername\printersharename or its IP address.
XenApp also needs to know the driver to use when constructing the printer connection. This information
is collected on import and retained as a list of known print queues. However, you can also add individual
printers from within the Session printers policy rule, which is handy if you did not import all information from
a print server.
Importing printers from a print server identifies the drivers XenApp requires, but does not install these
drivers. After importing printers, if the corresponding drivers are not installed automatically by Windows
(because you configured a policy rule preventing auto-installation or they are third-party drivers), you must
add the corresponding drivers to your farm servers manually.

Import printers before using the Session Printers policy rule to assign auto-created network printers.
After importing the information from your network print servers into your farm, make these printers available
so your users can access this printer from within a session.
Note: Early versions of XenApp allowed an administrator to provision network printer connections to
their users. In Presentation Server 4.0 and higher, the Session printers policy rule provides this functionality.
You can also configure XenApp to route print jobs to network printers through the client printing pathway.
8.7.9.1.4.1. To import printers from a network print server
2. In the left pane, select the Printer Management node.
3. On the Actions menu, select Printer Management > Import Network Print Server.
4. In the Server box, type one of the following:
The name of the print server you want to add. If using the name of the server, do not include
the backslash characters; for example, type printserver1, not \\printserver1
The static IP address of the print server you want to add
5. Enter credentials to authenticate to the print server by doing one of the following:
Clear the Use your Citrix Administrator credentials check box and enter credentials for
a network user account with access to printers on the specified server.
Select the Use your Citrix administrator credentials check box if you want to use the local
user credentials that you enabled in Pass-Through Authentication.
The printers available from the server are limited to those available to the user account entered. If you
do not enter any user information, information about only those printers available to all users is
imported. When the operation finishes, the print server appears on the Network Print Servers tab in
the Advanced Configuration tool or Presentation Server Console (depending on your version).
Note: If you do not want to add all the printers on the network print server, you can add individual
printers when you configure the Session printers policy rule instead, as described in To add a network
printer while configuring the Session printers rule.
8.7.9.1.4.2. To import printers from other domains
Printers cannot be imported from a network print server when the printer resides in a different workgroup or
the printer is in a different domain from any servers in the server farm. To import printers from other
domains, there has to be a trust relationship between the domain the user is logging on to and the domain
on which the print server resides.
1.
Enable the printer to be imported by doing one of the following:

Add the network print server to the same domain as the servers in the farm
Add one of the computers running XenApp to the same domain as the network print server
2.
Assign the printers to the Everyone group, rather than specific groups or users. Authenticate
without credentials to receive the list of printers assigned to everyone.
Tip: To allow Novell users access to Microsoft print servers, you must enable the Guest account
and assign Everyone or Guest access.
If you cannot use one of these strategies to import network printers from other domains, you can still allow
users to print to network print servers that are not in the same domain as the farm servers by using
client printing.
8.7.9.1.4.3. To assign printers using the Session printers policy rule
Before assigning printers using this rule, import any printers you want to assign from your network
printer servers.
3. From the Contents tab, choose the policy for which you want to configure printing rules.
5. In the policys Properties dialog box, expand Printing, then select Session printers.
Important: The server merges all enabled session printer rules for all applied policies, starting from
the highest to lowest priorities. However, if you disable a session printer rule in a policy, the
merging stops at that policy and ignores all session printer rules in lower-priority policies, even if
the option is enabled.
8.7.9.1.4.4. To add a network printer while configuring the Session printers rule
1. On the Printing > Session printers policy rule page, click Add. If the rule is not currently enabled, click
Enabled on the Session Printers rule page to display the Add button.
2. In the Add printers dialog box, click New.
3. In the Add Network Printers to Farm dialog box, select either authentication method:
Select Console Administrator to use the current administrator credentials.
Select Other to enter different credentials for authentication. These credentials must have
Access permissions for the printer.
4. Click Next.
5. Using one of the following options, specify the Network Printer Location:
Choose Enter UNC Path to enter the path using the format servername\printername.
Choose Browse for Printer to locate a printer on the network.
8.7.9.1.4.5. To specify a default printer for a session

Updated: 2010-03-11
To specify a network printer, it must already be imported into your farm and added to the policy in which you
are enabling the Session printers policy rule.
1. Complete the procedure, To add a network printer while configuring the Session printers rule.
2. On the Session printers rule page, from the Choose clients default printer drop-down list, choose
one of the following:
Name of the network printer you want to be default for this policy. Printers do not appear
in this list unless you added them to this policy.
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 be disabled in other ways, such as
through other Advanced Configuration tool (formerly Presentation Server Console) policies,
group policies, or Terminal Services settings.
Do not adjust the users default printer. Uses the current Terminal 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 autocreated in the session, which is either:
The first printer added locally to the Windows server in Control Panel > Printers
The first autocreated printer, if there are no printers added locally to the server.
3. Apply the policy to the group of users (or other filtered objects) you want to affect.
8.7.9.1.4.6. To edit the printer settings in the sessions policy
1. On the Session printers rules page, select the name of the printer for which you want to modify
the settings.
2. Click Settings.
3. Check Apply customized settings.
4. Change the settings for Paper Size, Copy Count, Print Quality, and Orientation.
5. To ensure that the settings you specify here are restored in concurrent sessions even if users modify
them in their initial session, select the Apply customized settings at every logon check box.
This check box applies to additional sessions opened while the users first session is still active.
Important: The type of Windows profiles configured in your environment change the effect of
settings. For more information, see Controlling Printing Settings and User Preferences.
If you clear this check box and a user opens his or her initial session, changes these printer settings,
and then opens a second session (while the first session is still active), the settings you specified in
this dialog box are not carried over to the second session.
For example, if you specified Landscape as a custom Orientation setting, the check box is selected, a
user starts a session (Session1), the user changes the Orientation to Portrait, and then starts
another simultaneous session (Session2), Session2 uses your custom settings and the Orientation
is Landscape. If you clear Apply customized settings at every logon, XenApp carries the users
changes into Session2 so the Orientation is Portrait.
After clicking OK, the Settings value in the list of printers on Session printers properties page
changes to Modified.
8.7.9.1.4.7. 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 to which the printer is physically connected, in Control Panel > Printers, select the
printer you want to share.
2.
Choose File > Properties.
3. In the Sharing tab, select these check boxes:

Share this printer
Render print jobs on client computers
4. Verify the printer is shared by checking to see if the printer appears in the Printer Management
> Printers tab of the Advanced Configuration tool (formerly the Presentation Server Console). If
the printer is not shared correctly, it does not appear in the Printers tab.
8.7.9.1.5. 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, you
can 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:
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 one of these policies, enable the Session Printers policy rule and do the following:
Add the printers in that subnets geographic location
Set Choose clients default printer to Do not adjust the user's default printer
3. Filter the policies by Client IP address.
8.7.9.1.6. 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, select the Always connect indirectly as a client printer
in the Print job routing rule.
8.7.9.1.7. 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 plugin 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 plugins 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.
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}
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.
8.7.9.1.8. To store users printer properties
Updated: 2010-03-11
3. On the Contents tab, choose the policy for which you want to configure printing rules.
5. In the policys Properties dialog box, select Printing > Client Printers > Printer properties retention.
6. Select one of the following to specify where the printer properties should be stored:
Held in profile only if not saved on client. Selected by default. Allows the system to
determine the method. It stores printer properties on the client device, if available, or if not, in
the user profile. Although this option is the most flexible, it can also slow down logon time and
use extra bandwidth to perform the needed system-checking.
Choose this option if your server farm requires backward compatibility with prior versions of
XenApp and its plugins and is not constrained by bandwidth or logon performance.
Saved on the client device only. Stores printer properties only on the client device. If users
are assigned a Terminal Services mandatory profile or roaming profile, select this option.
Choose this option only if all the servers in your farm are running XenApp 5 and your users are
using Citrix XenApp Plugin versions 9.x and above.
Retained in user profile only. Stores printer properties in the user profile on the server
and prevents any properties exchange with the client device. This option is useful if your system
is constrained by bandwidth (this option reduces network traffic) and logon speed or your users
use legacy plugins. Note that this is applicable only if a Terminal Services roaming profile is used.
8.7.9.1.9. 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.
1. Open the Registry Editor and navigate to one of the following registry locations:
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
8.7.9.1.10. 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:
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 server
s Event log
To prevent drivers from being installed automatically, configure the Printing > Drivers > Native printer
driver auto-install policy rule. See To add or remove drivers or edit driver names in the compatibility list to
ban specific printer drivers.
To specify how client printer drivers are installed on farm servers
2. Select the Policies node.
5. In the policys Properties dialog box, expand Printing, then Drivers.
6. Under Drivers, you can configure the following rules:
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 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.
Install Windows native drivers as needed (selected by default). Allows XenApp to
install Windows native printer drivers (those present in driver.cab) automatically when autocreating 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 add or remove drivers or edit driver names in the compatibility list

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:
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.
8.7.9.1.11. Configuring Universal Printer Drivers on Farm Servers
If you configure a Universal printer driver for sessions, by default, XenApp always uses the XPS Universal
Printer driver, when it is available. If it is not available, XenApp uses the Citrix Universal (EMF) Printer driver.
The EMF Universal printer driver can be configured as the default by editing the registry.
The Citrix Universal printer drivers are listed in the Drivers tab of the Print Server Properties dialog box,
which appears when you click the Server Properties button in Control Panel > Printers. Provided
all prerequisites for the driver were installed when you ran XenApp Setup, the following drivers appear:
Citrix Universal Printer, which is the .EMF driver
Citrix XPS Universal Printer
HP Color LaserJet 4500 PCL 5 (Citrix PCL5c Universal Driver)
HP Color LaserJet 4500 PS (Citrix PS Universal Printer Driver)
HP LaserJet Series II (Citrix PCL4 Universal Driver)
If you need a Universal driver that does not appear in this list, you must install it.
To install a Citrix Universal Printer Driver on a farm server
1.
1. Make sure the server has .NET 3.0 with SP1 is installed. If the server did not have .NET 3.0 with
SP1 installed when you installed XenApp, install either .NET 3.0 with SP1 or .NET 3.5 from the
\Support folder on the installation media.
2. Open the Microsoft Add Printer Driver wizard by clicking Add on the Print Server properties page
and accept the initial default options.
3. Browse to the XPS Universal printer driver (CitrixUpd.inf) in one of the following folders in the
installation media:
For 32-bit systems, \XenApp Server\w2k8\Program Files\Citrix\Drivers
For 64-bit systems, \XenApp Server\w2k8x64\Program Files\Citrix\Drivers
4. On the Printer Driver Selection page of the Add Printer Driver wizard, select one of the following drivers:
Citrix Universal Printer, which installs the .EMF based Citrix Universal printer driver
Citrix XPS Universal Printer
To specify the Universal Printer driver for sessions

1. In the Advanced Configuration tool or Presentation Server Console (depending on your version), select the
Policies node.
4. Choose the Printing > Drivers> Universal driver policy rule.
5. On the Universal driver properties page, select Enabled.
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.
To change the default Citrix Universal Printer driver

To make XenApp try to use the Citrix XPS Universal Printer driver before the EMF-based Citrix Universal
Printer driver, modify the registry.
1. Open the Registry Editor and select HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\UniversalPrintDrivers.
The Driver List registry key appears in the right pane after you select UniversalPrintDrivers.
2. In the Value data in the Driver List registry key, make one of the following changes:
To specify a different default printer driver, place the abbreviation for the printer driver at
the beginning of the Value data string.
For example, to make XenApp attempt to use the Citrix XPS Universal Printer driver before the
EMF-based Citrix Universal Printer driver, specify XPS;EMF;PCL5c;PCL4;PS.
To prevent XenApp from using a specific Universal Printer driver, remove its abbreviation from
the Value data string.
8.7.9.1.12. 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
Good printer drivers for bad 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 define client printer driver mappings for all servers in the farm
2. Expand the Printer Management node and select Drivers.
3. From the Actions menu, choose Printer Management > Mapping. Use the Driver Mapping dialog
box to maintain a list of mappings between client drivers and server drivers if they are known to
have different names.
4. In the Driver Mapping dialog box, choose a server platform. The mapping you create maps all the
servers in the farm on the platform you specify here to the client driver you specify in the Add Mappings
dialog a box.
5. Click Add to add the names of client printer drivers that correspond to the drivers you installed on
servers in the farm.
To define client printer driver mappings for a specific server

1. Add mapping entries for the specific client and server driver names to the Wtsuprn.txt template file
located in the /Program Files/Citrix/System32/ directory.
2. Rename the file to Wtsuprn.inf and copy it to the same directory on all servers on which you want to
apply similar mappings.
Note: You can use wildcards to match a range of client driver names using a single mapping entry;
for example, hp laserjet* will match any client driver with an identical prefix.
To map client printer drivers to server printer drivers

2. Select Printer Management > Drivers.
3. On the Actions menu, click Printer Management > Mapping.
4. In the Driver Mapping dialog box, choose the required platform from the drop-down list and click one
of the following:
Add. Lets you associate a server printer driver with a client printer driver.
4.
Edit. Lets you edit an existing mapping. Select the driver mapping you want to modify and click Edit.
5. In the Add/Edit Mappings dialog box, enter the client printer driver name and select the server
driver from the drop-down list that you want to substitute for the client printer driver.
Tip: To display driver information for a specific server, select the server from the Servers folder in
the left pane of the Advanced Configuration tool and select the Printer Drivers tab.
8.7.9.2. Increasing Printing Speed and Session Performance
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:
Use the Printer policy rule to enable and disable the printing bandwidth session limit.
Use individual server settings to limit printing bandwidth in the server farm. You can perform this task
in the Access Management Console or the Delivery Services Console, or the tool known as
XenApp Advanced Configuration or the Presentation Server Console, depending on the version of
XenApp you have installed.
You can use the Citrix Session Monitoring and Control Console 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 rule in an existing policy
3. In the right pane of the tool, select a policy that is suitable for sessions with low connection speeds
(for example, it contains the group of users affected).
5. Expand Bandwidth.
6. Select one of the following folders:
Select Session Limits to specify the bandwidth available for printing in kilobits per second (kbps).
Select Session Limits (%) 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 Session Limits (%) rule,
you must enable the Overall Session rule in the Session Limits folder as well.
7. Select Printer to configure the rule and configure the bandwidth limit.
To limit printer bandwidth for a server using the Access Management Console
1.
Services Console.
2. In the left pane, select Citrix Resources > XenApp > farmname > Servers folder > servername.
4. In the Properties tree, select ICA > Printer Bandwidth.
5. Select one of the following options:
Select Unlimited client printer bandwidth to enable client print jobs to use as much
available bandwidth in the connection as possible.
Select Limit bandwidth to use (kbps) to set an upper limit (in kbps) for the bandwidth used
by client print jobs. Enter the maximum amount of bandwidth in kilobits per second. This is
the amount of bandwidth that a print job can consume in an ICA connection.
Tip: The same information is available from the ICA Printer Bandwidth tab when you select
the Servers folder in the Advanced Configuration tool or Presentation Server Console.
To display the client printer bandwidth for a server

2. Select the Printer Management node.
3. In the right pane, select the Bandwidth tab. The Bandwidth pane appears, displaying the
maximum bandwidth that a print job queued from a client printer can use in a single connection.
By default, the bandwidth is unlimited.
To limit printer bandwidth for a server

2. Select the Servers folder.
3. In the right pane, select the ICA Printer Bandwidth tab.
4. In the right pane, select the server name for which you want to limit the bandwidth.
5. Select the server in the right pane and, on the Actions menu, click Printer Management > Edit. The
Edit Bandwidth Limit dialog box appears. Use this dialog box to limit the bandwidth allocated to
printing for the selected server.
6. Select one of the following options:
Unlimited bandwidth. This option allows client print jobs to use as much available bandwidth
in the connection as possible.
Limit bandwidth to use (kbps). This option sets an upper limit (in kbps) for the bandwidth
used by client print jobs. Enter the maximum amount of bandwidth in kilobits per second that a
print job can consume in an ICA connection.
To copy one servers limit to one or more servers

1. Follow Steps 1 to 3 from To limit printer bandwidth for a server to select the server whose limit you
want to copy.
2. On the Actions menu, click Printer Management > Copy.
3. Select the destination servers in the Copy Bandwidth Settings dialog box. The dialog box lists all
servers in the farm except the source server.
8.7.9.3. Updating Network Print Server Information
Whenever you add or remove printers from a network print server in the farm, update the information in the
tool known as XenApp Advanced Configuration or the Presentation Server Console (depending on the version
on XenApp you have installed) to ensure it displays an accurate listing of printers. You can:
Update one individual printer that you added to your network.
Update all of the printers in a print server after you imported the initial list of printers from your
print server.
Remove outdated print server information from the server farm. Removing a print server from
your Windows network is not reflected automatically in the tool. You must discard the print
server information referenced by the tool. Discarding information for a network print server also
removes any associated autocreation settings.
To update information about a network print server

2. Select Printer Management.
3. On the Network Print Servers tab, select the print server you want to update.
4. On the Actions menu, select Printer Management > Update Network Print Server.
5. In the Update Network Print Server dialog box, enter the credentials for a user account with access
to printers on the specified print server. The printers available from the server are limited to
those available to the user account entered.
To discard information for a network print server

2. Select Printer Management and select the Network Print Servers tab.
3. Select the print server you want to remove.
4. On the Actions menu, select Printer Management > Discard Network Print Server.
8.7.9.4. Replicating Printer Drivers Across a Farm
To print from a published application accurately, the driver for the selected printer must be installed on
the applications server. To maintain consistent drivers across your farm, you can copy or replicate drivers
from one server to another. Replication copies driver files and registry settings from a source server to one
or more destination servers.
Replication may be easier than visiting all the servers and installing the driver on each machine. You can
replicate drivers for both client and network printers.
XenApp provides two driver replication features:
Use Replicate to copy a driver manually to specific existing servers. For example, to add the driver for
a plotter only to the servers hosting the relevant application.
Use Autoreplicate to push a set of drivers to all current and future servers in the farm. See
Replicating Printer Drivers Automatically.
8.7.9.4.1. Replicating Printer Drivers Manually

You can copy printer drivers to other servers on your farm by replicating them manually. You may want
to replicate drivers manually when:
You need a speciality driver on specific servers as opposed to all servers on your farm
You want to ensure that all servers in your farm that use a shared printer, which is attached locally to
a farm server, have the correct drivers for it
To replicate one or more drivers

The destination servers must be on the same platform as the selected driver. If the destination server is not
on the same platform as the driver, its name will not appear.
2. In the left pane, select Printer Management > Drivers. The Drivers tab displays a list of all
drivers available from all servers in the farm.
3. Choose a server source from the drop-down list of servers. A list of drivers on the chosen server appears
in the lower left pane. Choose Any for replication from any one of the servers on which the driver
is installed.
Citrix recommends setting the source to Any only if you are certain that all servers in your farm have
the same driver version installed. If Server A has driver version 2.0 and Server B has version 2.1,
explicitly choose a driver as the source.
4. Select one or more drivers and, on the Actions menu, select Printer Management > Replicate Drivers
. The drivers must be supported on the same platform.
5. Choose your replication option:
Replicate to all servers on the same platform and add to the Auto-replication list.
The driver information is copied to all other servers in the farm on the same platform and is
added to the autoreplication list for the farm.
Choose the servers to which you want to copy the driver information. Select the
servers from the list provided.
6. To replace old drivers, select Overwrite existing drivers. If the destination server already has a
driver installed with the same name, the selected driver overwrites the existing driver.
To check the progress of the driver replication, select each server in the left pane of the tool and select the
Printer Drivers tab. After the driver is replicated, it is listed on the Printer Drivers tab. If the replication did
not complete, an entry is written to the source servers event log.
To replicate all drivers for a shared printer
This procedure lets you replicate the drivers from a shared printer that is local to a farm server.
2. In the left pane, select Printer Management > Printers. The Printers tab displays a list of all printers
in the farm.
3. Select the shared printer from which you want to replicate the drivers. On the Actions menu, select
Printer Management > Replicate Drivers.
4. Choose your replication option:
Replicate to all servers on the same platform and add to the Auto-replication list.
The driver information is copied to all other servers in the farm on the same platform and is
added to the autoreplication list for the farm.
Choose the servers to which you want to copy the driver information. Select the
servers from the list provided.
5. To replace old drivers, select Overwrite existing drivers. If the destination server already has a
driver installed with the same name, the selected driver overwrites the existing driver.
6. To replace old drivers, select Overwrite existing drivers. By default, this option is not selected.
8.7.9.4.2. Replicating Printer Drivers Automatically
Use the tool known as XenApp Advanced Configuration or the Presentation Server Console (depending on
the version of XenApp you have installed) to instruct XenApp to replicate any new printer drivers you add to
the farm automatically by creating an autoreplication list. This lists drivers that are replicated automatically
to each server as it joins or connects to the farm.
When you edit the autoreplication list, you can use a specific server or any server as the source for a
particular printer driver. If you specify that you want to use any server, XenApp copies the driver from any
server that is available in the farm at the time of autoreplication to a new or restarted server. This setting
avoids the possibility that a specific source server for a printer driver might be unavailable when new or
restarted servers need to receive a printer driver. However, if servers are not consistent, the users might not
be able to print consistently.
XenApp cannot replicate drivers from network printers (drivers installed on network print servers) because it
does not have access to the driver files.
If driver replication fails because of communication errors, the tool displays an error message and records
the error in the server System log for each server where the operation failed.
Note: Administrators have more control over printer driver replication when manual replication is
used. Perform replication during low usage periods.
The autoreplication list is subdivided based on the server platform.
To replicate a driver automatically to each server in the farm
2. In the left pane, select Printer Management > Drivers.
3. On the Drivers tab, select the driver you want to replicate.On the Actions menu, select
Printer Management > Auto-replication.
4. In the Auto-replication dialog box, choose the required platform from the drop-down list and click Add.
5. In the the Select Drivers to Replicate dialog box, choose the printer drivers that will be copied to
all servers in the farm:
1. Choose a server source from the drop-down list of servers to display only the printer drivers
installed on the selected server. By default, Any appears in the Server list. Choose Any
for replication from any one of the servers on which the driver is installed. Citrix recommends
setting the source to Any only if you are certain that all servers in your farm have exactly the
same driver version installed.
2. If you want to prevent XenApp from creating duplicate drivers with the same name, select the
Overwrite existing drivers check box. If you select this check box and the destination
server already has a driver installed with the same name, the selected driver overwrites the
2.
existing driver.
Note: To display the servers where a driver is installed, select the driver.
6. Click Yes to the warning message, if prompted. After you add a driver, the Auto-replication dialog
box displays information about each printer driver in the list under the following columns:
Source. The name of the server from which the driver is copied. If you use Any, the driver
is replicated from any one of the servers on which the driver is installed.
Overwrite. If you selected Overwrite existing drivers when you added a driver to the list,
a checkmark appears. Otherwise, the column is blank.
To remove drivers from the autoreplication list

2. In the left pane, select Printer Management > Drivers.
3. On the Actions menu, select Printer Management > Auto-replication.
4. Choose the required platform from the drop-down list.
5. Select the driver you want to remove and click Remove.
8.7.9.5. 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
Location
Print Management snap-in in

the Microsoft Management Console
Control Panel > Printers
Network printers (Printers on a

network print server)
Print Management snap-in in

the Microsoft Management Console
Network printers (Printers on a

network print server)
Network
printing pathway
Print Server > Print Management

snap-in in the Microsoft
Management Console
Print Server > Control Panel > Printers
Server local printers (Shared

printers locally attached to a
XenApp server)
N/A
Local network server printers

(Printers from a network print server
that are added to server running XenApp)
Network
printing pathway

8.7.9.5.1. Displaying Printers Using the Network Printing Pathway

Network print server printers appear on the Network Print Servers tab when you click the Printer
Management node in the tool known as XenApp Advanced Configuration or the Presentation Server
Console, depending on the version of XenApp you have installed. However, 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 > Printers 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 for Printers that has the following syntax:
PrinterName on PrintServer (from clientname) in session n
where PrinterName is the name of the printer being redirected and PrintServer is the name of the print server it
is associated with, and clientname is the name of the client through which the print job is being rerouted.
(For example, Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2 .)
To display a list of the network and server local printers in your farm
This procedure displays a list of all the imported print server printers and server local printers in your farm.
This list does not include client printers.
2. Expand the Printer Management node and select Printers.
3. The Printers tab displays the following information about each printer:
Shared Name. The name of the printer available from the associated print server.
Server. The name of the print server.
Driver. The name of the driver in use by the printer. No information appears for network
print servers.
Platform. The operating system for the print server. No information appears for network
print servers.
To display a list of the server local printers for a server

You can display a list of the shared local printers available on a specific server.
Note: Server local printers must be shared in Windows Server 2008 or they do not appear in the tool known
as XenApp Advanced Configuration or Presentation Server Console. See To configure server local printers.

2. Select Servers > servername.
3. Click the Printers tab. The Printers tab displays the following information about each printer:
Shared Name. The name used to connect to the printer on the associated print server.
Driver. The name of the driver in use by the printer. No information appears for network
print servers
8.7.9.5.2. Displaying Printers Using the Client Printing Pathway

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
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.
8.7.9.6. Displaying Drivers
You can display drivers on a per-server or per-farm basis.
To display a list of the drivers on a server
This procedure displays a list of all the printer drivers on a specific server.
2. Select Servers > servername.
3. Click the Printer Drivers tab.
4. In the right pane of the tab, select a driver to list the servers on which it is installed.
To display a list of the printer drivers available from a server in your farm
2. In the left pane, select Drivers.
3. In the Drivers display, select a server from the Server drop-down list, which displays the servers in
the farm. The default value is Any.
4. To display only the printer drivers installed on the selected server, select a server from the drop-down
list. The selected server is used as the source for driver replication if that command is selected.
The information about each printer driver appears under the following columns:
Driver. The name of the printer driver.
Platform. The operating system for the driver. If a server is selected, it is the operating system
for the server.
In the right pane of the tab, select a driver to list the servers on which the driver is installed.
To replicate printer drivers, select one or more drivers and on the Actions menu, click
Printer Management > Replicate Drivers.
8.7.10. XenApp Commands Reference
Citrix XenApp commands provide an alternative method to using the console for maintaining and
configuring servers and farms. Citrix XenApp commands must be run from a command prompt on a
server running Citrix XenApp.
Command
Description
acrcfg
Configure auto-reconnect settings.
altaddr
Specify server alternate IP address.
app
Run application execution shell.
auditlog
Generate server logon/logoff reports.
change client
Change client device mapping.
chfarm
Change the server farm membership of the server, create an additional

farm, and configure a replacement data store.
ctxkeytool
Generate farm key for IMA encryption.
ctxxmlss
Change the Citrix XML Service port number.
driveremap
Remap the server's drive letters for 32-bit systems.
driveremap64
Remap the server's drive letters for 64-bit systems.
dscheck
Validate the integrity of the server farm data store.
dsmaint
Maintain the server farms data store.
enablelb
Enable load balancing for servers that fail health monitoring tests.
icaport
Configure TCP/IP port number used by the ICA protocol on the server.
imaport
Change IMA ports.
migratetosqlexpress
Migrate the server farms data store from a Microsoft Access database to a
SQL Server Express database.
query
View information about server farms, processes, ICA sessions, and users.
twconfig
Configure ICA display settings.
8.7.10.1. ACRCFG
Use acrcfg to configure Auto Client Reconnect settings for a server or a server farm.
Syntax
acrcfg [/server:servername | /farm]
[/query | /q]
acrcfg [/server:servername | /farm] [/require:on | off] [/logging:on | off]

acrcfg [/server:servername | /farm] [/require:on | off] [/logging:on | off]
acrcfg [/server:servername] [/inherit:on | off] [/require:on | off] [/logging:on | off]
acrcfg [/?]
Parameters
servername
The name of a server running Citrix XenApp
Options
/query
/q
Query current settings.
/server
The server to be viewed or modified by the other command-line options. The server specified by
servername must be in the same server farm as the server on which the command is run. This option
and the /farm option are mutually exclusive. The local server is the default if neither /server nor /farm
is indicated.
/farm
The options on the command-line after /farm are applied to the entire server farm.
/inherit:on | off
To use the Auto Client Reconnect settings from the server farm, set /inherit to on for a server.
To disregard the Auto Client Reconnect settings from the server farm, set /inherit to off. By default,
/inherit is set to on for a server.
/require:on | off
If you want users to be prompted for credentials during automatic reconnection, set /require to on
. Servers inherit the server farm setting unless /inherit is off. To allow users to automatically reconnect
to disconnected sessions without providing credentials, set /require to off. By default, /require is set to
off for both a server and a server farm.
/logging:on | off
You can enable logging of reconnections in the Application Event log on a server. Logging can be set
only when /required is set to off. Logging is set to off for both servers and server farms by default.
/?
Displays the syntax for the utility and information about the utilitys options.
Remarks
Enabling automatic reconnection allows users to resume working where they were interrupted when
an connection was broken. Automatic reconnection detects broken connections and then reconnects the users
to their sessions.
However, automatic reconnection can result in a new session being launched (instead of reconnecting to
an existing session) if a plugins 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 because /require is set to on. Auto Client Reconnect is not triggered if users
intentionally disconnect.
The Auto Client Reconnect feature is enabled by default and can be disabled using the icaclient.adm file or an
ICA file only on the Citrix XenApp Plugin for Hosted Apps or with the Web Interface.
The /require and /logging options are valid with either /server or /farm, but /inherit is not used with /farm
. If neither /server nor /farm is selected and the /inherit, /require, or /logging options are used, they
are applied to the local server. You can set /require only when /inherit is set to off. You can set logging
only when /require and /inherit are set to off. When logging is not valid, it disappears from later queries.
A query shows the required setting whether or not it is on.
Settings and values are not case-sensitive.
Examples
The following four commands result in the following configurations:
Require users to enter credentials when they automatically reconnect to servers configured to inherit
farm-wide settings
Show the results
Allow users to be reauthenticated automatically to the local server and set the server to log
plugin reconnections
Show the results
C:\>acrcfg /farm /require:onUpdate successfulC:\>acrcfg /farm /qAuto Client Reconnect Info for:
Security Restrictions
To make changes, you must be a Citrix administrator with Windows administrator privileges.
8.7.10.2. 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.
/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.
/?
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
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
None.
8.7.10.3. 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 applicationrelated 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.
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:
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
None.
8.7.10.4. 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
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.
/?
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 logon/logoff accounting with
the Audit Policy in Microsoft Windows.
To run auditlog, you must have Windows administrator privileges.
8.7.10.5. CHANGE CLIENT
Change client changes the current disk drive, COM port, and LPT port mapping settings for a client device.
Syntax
change client [/view | /flush | /current]
change client [{/default | [/default_drives] | [/default_printers]} [/ascending]] [/noremap]

[/persistent] [/force_prt_todef]
change client [{/default | [/default_drives] | [/default_printers]} [/ascending]] [/noremap]
[/persistent] [/force_prt_todef]
change client [/delete host_device] [host_device client_device] [/?]
Parameters
host_device
The name of a device on the host server to be mapped to a client device.
client_device
The name of a device on the client to be mapped to host_device.
Options
/view
Displays a list of all available client devices.
/flush
Flushes the client drive mapping cache. This action forces the server and the client to resynchronize all
disk data.
/current
Displays the current client device mappings.
/default
Resets host drive and printer mappings to defaults.
/default_drives
Resets host drive mappings to defaults.
/default_printers
Resets host printer mappings to defaults.
/ascending
Uses ascending, instead of descending, search order for available drives and printers to map. This
option can be used only with /default, /default_drives, or /default_printer.
/noremap
If /noremap is specified, client drives that conflict with server drives are not mapped.
/persistent
Saves the current client drive mappings in the client device users profile.
/force_prt_todef
Sets the default printer for the client session to the default printer on the clients Windows desktop.
/delete host_device
Deletes the client device mapping to host_device.
/? (help)
Remarks
Typing change client with no parameters displays the current client device mappings; it is equivalent to typing
change client /current.
Use change client host_device client_device to create a client drive mapping. This maps the client_device
drive letter to the letter specified by host_device; for example, change client v: c: maps client drive C to
drive V on the server.
The /view option displays the share name, the share type, and a comment describing the mapped
device. Sample output for change client /view follows:
C:>change client /viewAvailable Shares on client connection ICA-tcp#7

Sharename
Type
Comment
\\Client\A$
Disk
Floppy
\\Client\C$
Disk
FixedDrive
\\Client\D$
Disk
CdRom
\\Client\LPT1:
Printer
Parallel Printer
\\Client\COM1:
Printer
Serial Printer
The /flush option flushes the client drive cache. This cache is used to speed access to client disk drives
by retaining a local copy of the data on the server running Citrix XenApp. The time-out for hard drive
cache entries is 60 seconds and the time-out for diskette data is two seconds. If the client device is using
a multitasking operating system and files are created or modified, the server does not know about the changes.
Flushing the cache forces the data on the server to be synchronized with the client data. The cache time-out
for diskettes is set to five seconds because diskette data is usually more volatile; that is, the diskette can
be removed and another diskette inserted.
The /default option maps the drives and printers on the client device to mapped drives and printers on
the server running Citrix XenApp. Drives A and B are always mapped to drives A and B on the server. Hard
drives are mapped to their corresponding drive letters if those drive letters are available on the server. If
the corresponding drive letter is in use on the server, the default action is to map the drive to the highest
unused drive letter. For example, if both computers have drives C and D, the client drives C and D are mapped
to V and U respectively. These default mappings can be modified by the /ascending and /noremap options.
The /default_printers option resets printer mappings to defaults. /default_printers attempts a one-toone mapping of all client printers; for example, the clients LPT1 and LPT2 ports are mapped to the servers
LPT1 and LPT2 ports. If the /ascending option is specified, the mapping is done in ascending order.
The /default_drives option resets host drive mappings to defaults. /default_drives attempts a one-toone mapping of all client drives; for example, client drives A and B are mapped to server drives A and B.
Hard drives are mapped to their corresponding drive letters if those drive letters are available on the server.
If the corresponding drive letter is in use on the server, the default action is to map the drive to the
highest unused drive letter. For example, if both computers have drives C and D, the client drives C and D
are mapped to V and U respectively. If the /ascending option is specified, the mapping is done in
ascending order.
The /ascending option causes the mapping to occur in ascending drive letter order. For example, if the first
two available drive letters on the server are I and J, drives C and D in the preceding example are mapped to
I and J respectively.
The /noremap option causes the mapping to skip drive letters occupied on the server. For example, if the
server has a drive C but no drive D , the clients drive C is mapped to D on the server, but the clients drive D
is not mapped.
The /persistent option causes the current device mappings to be saved in the users profile. Drive conflicts
can occur if the /persistent option is in use and the user logs on from a client device that has a different disk
drive configuration, or logs on to a server that has a different disk drive configuration.
The /force_prt_todef option sets the default printer for the ICA session to the default printer on the client
s Windows desktop.
None.
8.7.10.6. CHFARM
The chfarm utility is used to change the farm membership of a server, configure replacement data stores,
and create additional farms. The utility is installed in %ProgramFiles%\citrix\system32\citrix\IMA.
To run this utility, choose Start > Run and then type chfarm.
Caution: Be sure that the Access Management Console or Delivery Services Console and the tool known
as XenApp Advanced Configuration tool or the Presentation Server Console (depending on the version
of XenApp you have installed) are closed before you run the chfarm command. Running chfarm while
these tools are open can result in loss of data and functionality.
Syntax for creating a new farm with an Access database
chfarm [/verbose] [/createfarm] [/farmname:name] [[/admin:[domain\]username [/zone:zonename]]
Syntax for creating a new farm with a SQL Server Express database
chfarm [/verbose] [/createfarm] [/farmname:name] [[/admin:[domain\]username [/zone:zonename]]

[/instancename:iname] [/database:dname]
Syntax for joining an existing farm with a direct connection to SQL, DB2, or Oracle databases
chfarm
[/verbose] [/joinfarm] [/ddsc:databasetype] [/zone:zonename] [/odbcuser:username] [/odbcpwd:pa
[/dsnfile:path_and_dsnname] [/quiet]
Syntax for joining an existing farm with an indirect connection to Access or SQL Server
Express databases
chfarm [/verbose] [/joinfarm] [/ldsc:servername] [/zone:zonename] [/user:[domain\]username]

[/pwd:password] [/quiet]
Options
/admin:[domain\]username
Specifies the initial Citrix administrator account you want to use for the farm. The domain\ parameter
is optional.
/createfarm
Initiates the farm creation process.
/database:dname
Specifies the name of the SQL Server Express database you want to use. The default value is MF20.
/ddsc:databasetype
Specifies the type of database used for the data store of the target farm. For example, SQL Server.
/dsnfile:path_and_dsnname
Specifies the complete path and filename of the databases file DSN.
/farmname:name
Specifies the name of the XenApp farm you want to create.
/instancename:iname
Specifies the name of the instance of SQL Server Express you want to use. The default value
is CITRIX_METAFRAME.
/joinfarm
Initiates the join process for the farm.
/ldsc:servername
Specifies the name of the server whose farm you want to join.
/odbcpwd:password
Specifies the password for the SQL, DB2, or Oracle database connection.
/odbcuser:username
Specifies the username for the SQL, DB2, or Oracle database connection.
/pwd:password
Specifies the password for connecting to the target server.
/quiet
Supresses display of confirmation messages.
/user:[domain\]username
Specifies the user account needed to connect to the target server. The domain\ parameter is optional.
/verbose
Displays extra debugging information about the actions being performed. You can also redirect this
output to a file.
/zone:zonename
The zone where you want to create or connect to the Access or SQL Server Express database.
Remarks
chfarm has much of the same functionality as XenApp Setup. You can use chfarm when you want to move
a server from its current server farm to an existing server farm or create a new server farm at the same time
that you move the server.
If you did not back up your farms data store and you need to recreate it (for example, in the event of
hardware failure), running chfarm performs the same data store configuration tasks as XenApp Setup. You
can also run the chfarm utility with additional command-line options to create a new farm or join an
existing farm.
Citrix recommends that you back up your data store before running chfarm. Chfarm stops the
Citrix Independent Management Architecture service on the server.
Caution: If chfarm reports any errors, continuing the process can corrupt the data store. If you cancel
the data store configuration part of the Citrix XenApp Setup wizard, the server you are switching rejoins
the original farm.
Do not remove the server hosting the data store from the farm unless all other servers are removed first.
Doing so renders the farm unstable.
After the farm membership is changed or a new farm is created, restart the server.
When you run chfarm, the batch file JOINFARM.BAT is created in the same folder from which you run the
utility. You can use this batch file to run chfarm with the same settings on other servers. Before using this
file, you need to modify information according to the file comments; for example, passwords or the DSN
file location.
Limitations of using the command line to run CHFARM
If you choose to run the CHFARM utility from the command line instead of the Citrix XenApp Setup wizard,
be aware of the following limitations:
You can create new farms using only Access and SQL Server Express databases. You cannot create
new farms using SQL Server, Oracle, or DB2 databases.
You cannot generate or load registry keys in the HKLM\SOFTWARE\Wow6432Node\Citrix\IMA folder,
or HKLM\SOFTWARE\Citrix\IMA folder on XenApp, 32-bit Edition.
You cannot specify a license server. Instead, chfarm assumes the server will connect to the license
server specified for the farm.
You cannot specify a server port for an indirect connection to the farm data store. Instead, you must
use port 2512.
Important Notes for SQL Server Express Data Stores

If you want to use SQL Server Express to host a new server farms data store, a named instance must
be installed on the server on which you run chfarm. The default named instance that chfarm uses
is CITRIX_METAFRAME.
Running chfarm does not automatically install SQL Server Express; you must install it separately. For
more information, see To move a server to a new server farm using SQL Server Express.
Note: You cannot migrate a database to the same named instance of SQL Server Express that is already
in use. If you are already using SQL Server Express and you want to migrate to a new farm using SQL
Server Express, you must either migrate to another database (Access or a third-party database) and then
back to SQL Server Express, or install another named instance of SQL Server Express and then launch chfarm
with the /instancename option.
8.7.10.6.1. To move a server to a new server farm using SQL Server Express
1. Create a named instance of SQL Server Express by installing it on the first server in the new farm. You
can do this by performing the following steps:
1. Open a text editor such as Notepad and modify the the instance_name parameter of
the SetupSQLExpressForCPS.cmd file.
2. Run SetupSQLExpressForCPS.cmd.
2. Run chfarm on the server that you want to use to create the new farm using the /instancename:iname
option, where iname is the name of the instance of SQL Server Express you created in Step 1.
Note: If you name an instance of SQL Server Express CITRIX_METAFRAME, you do not need to use the
/instancename option.
8.7.10.7. 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:
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
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
Can be used to check:
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.
You must be a Citrix administrator with local administrator privileges to run ctxkeytool.
8.7.10.8. 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.
/?
None.
Remarks
For more information, see Configuring the Citrix XML Service Port.
8.7.10.9. DRIVEREMAP
Updated: 2009-09-22
Use the driveremap utility to change the server's drive letters on a 32-bit operating system or to update the
32-bit SQL Server 2005 Express Edition SP1 or SQL Server database locations. XenApp setup installs this
utility (driveremap.exe) in the \Program Files\Citrix\System32 directory.
Important Considerations
If you are using a 64-bit operating system, run the driveremap64 command.
You must run this command from a network share or CD-ROM drive.
Do not install the driveremap utility on a server with .NET 2.0 installed. You can install .NET 2.0 after
you remap server drives.
If you are installing XenApp on a server that is not running a previous version of XenApp, run the
driveremap utility before you install XenApp. Citrix recommends that you do not change server
drive letters after you install XenApp or applications you want to publish for users to access.
Syntax
driveremap /?
driveremap /dbscript:filename
driveremap /drive:M
driveremap /u
driveremap /noreboot
driveremap /IME
Options
/?
Displays the syntax for the utility and information about the utility's options.
/dbscript:filename
Sets the path to Fixsecuritydatabase.cmd to filename. For Windows Server 2003, the
Fixsecuritydatabase utility is run to update drive information in the Windows security database after
you remap the system drive.
If you run driveremap from a location other than the XenApp installation media, use the /dbscript
switch to specify the path to Fixsecuritydatabase.cmd. If you copy Fixsecuritydatabase.cmd to
a folder with the same relative location to driveremap.exe as on the XenApp installation
media (\Support\Install\Fixsecuritydatabase.cmd), you do not need to specify a new path with the
/dbscript switch.
After remapping drives on Windows Server 2003, ensure that you restart the server and log on with
an administrator account that has read access to the Fixsecuritydatabase.cmd file specified by /dbscript.
/drive:M
Specifies the drive letter to use for the first remapped drive.
/u
Permits unattended or silent installation where no dialog boxes appear and no user input is required.
You must use this option in conjunction with the /drive: option.
/noreboot
Suppresses the Restart Computer message and does not restart the system. Citrix strongly
recommends that you restart the system after running this utility.
/ime[filename]
Changes the drive letter specified
in \Software\Microsoft\Windows\CurrentVersion\Ime\Japan\IMEJP\Dictionaries for all of the loaded
hives under HKEY_USERS.
Remarks
Caution: Do not run driveremap within an ICA or RDP session; for example, from a command prompt of
a server desktop published as an application. Running driveremap in an ICA or RDP session can cause
the server to become unstable.
Examples
The following command remaps the server's drive letters. The first available drive is changed to M. The
command uses the noreboot option.
driveremap /u /drive:M /noreboot

The following command returns the server's drive letters to the drive letters that start at C and then prompts
you to restart the server.
driveremap /u /drive:M /drive:C

Known Issues
When running driveremap, you might encounter the following issues.
When running driveremap with no parameters, the drive letter choices in the drop-down list may
be unavailable. This can occur if the server has non-contiguous drive letters; for example, C, D, X.
The mapped drive letters are spread over the interval [a..z] and no reasonable interval shifting can
be performed. Network drives are also taken into account.
To work around this issue, change the drive letters to C, D, and E and then run the driveremap utility.
At a command prompt, if you remap to a letter that is in use, nothing happens and you are returned
to the prompt. Locate the server's drive letters in Windows Explorer to verify the drive letters are changed.
Installation of the Web Interface on a XenApp server may fail if you are upgrading a server with
remapped drives. See CTX240747 in the Citrix Knowledge Center.
If you upgrade from MetaFrame 1.8 to Citrix XenApp on a server with changed server drive letters ,
the Windows Pass-through Client is not updated. To avoid this issue, be sure the server is operating
in install mode before running Setup.
Only Citrix administrators can run this command.
Additional Information
If you change the server's drive letters, XenApp searches the following registry keys and changes all
drive references to the new drive letters:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*
HKEY_LOCAL_MACHINE\SOFTWARE\Equinox\eqn\CurrentVersion\NetRules
HKEY_LOCAL_MACHINE\SYSTEM\*
HKEY_CLASSES_ROOT\*
HKEY_USERS\*
XenApp also updates the pagefile entry and the following shortcut files:
%SystemRoot%\Profiles\Default User\*.lnk
%SystemRoot%\Profiles\Administrator\*.lnk
%SystemRoot%\Profiles\All Users\*.lnk
Note: The first time a user logs on to a server after you change the drive lettes, references to the old
drive letters in the user's profile are updated.
Before installation of XenApp 5 for Windows Server 2003, you can run the Drive Remapping utility from
the autorun screens of the XenApp installation media (this is not available on XenApp 5 Feature Pack 2
for Windows Server 2003). After installing XenApp, you can open the utility by running driveremap.exe with
no parameters.
8.7.10.10. DRIVEREMAP64
Updated: 2009-09-22
Use the driveremap64 utility to change the server's drive letters on a 64-bit operating system. XenApp
setup installs this utility (driveremap64.exe) in the \Program Files (x86)\Citrix\System32 directory.
Important Considerations
If you are using a 32-bit operating system and you want to change the server's drive letters or update
the 32-bit SQL Server 2005 Express Edition SP1 or SQL Server database locations, use the driveremap
command.
You must run this command from a network share or CD-ROM drive.
Do not install the driveremap64 utility on a server with .NET 2.0 installed. You can install .NET 2.0
after you remap server drives.
If you are installing XenApp on a server that is not running a previous version of XenApp, run
the driveremap utility before you install XenApp. Citrix recommends that you do not change server
drive letters after you install XenApp or applications you want to publish for users to access.
Syntax
driveremap64 /?
driveremap64 /dbscript:filename
driveremap64 /drive:M
driveremap64 /u
driveremap64 /noreboot
driveremap64 /IME
Options
/?
Displays the syntax for the utility and information about the utility's options.
/dbscript:filename
Sets the path to Fixsecuritydatabase.cmd to filename. For Windows Server 2003, the
Fixsecuritydatabase utility is run to update drive information in the Windows security database after
you remap the system drive.
If you run driveremap64 from a location other than the XenApp installation media, use the /dbscript
switch to specify the path to Fixsecuritydatabase.cmd. If you copy Fixsecuritydatabase.cmd to
a folder with the same relative location to driveremap64.exe as on the XenApp installation
media (\Support\Install\Fixsecuritydatabase.cmd), you do not need to specify a new path with the
/dbscript switch.
After remapping drives on Windows Server 2003, ensure that you restart the server and log on with
an administrator account that has read access to the Fixsecuritydatabase.cmd file specified by /dbscript.
/drive:M
Specifies the drive letter to use for the first remapped drive.
/u
Permits unattended or silent installation where no dialog boxes appear and no user input is required.
You must use this option in conjunction with the /drive: option.
/noreboot
Suppresses the Restart Computer message and does not restart the system. Citrix strongly
recommends that you restart the system after running this utility.
/ime[filename]
Changes the drive letter specified
in \Software\Microsoft\Windows\CurrentVersion\Ime\Japan\IMEJP\Dictionaries for all of the loaded
hives under HKEY_USERS.
Remarks
Caution: Do not run driveremap64 within an ICA or RDP session; for example, from a command prompt of
a server desktop published as an application. Running driveremap64 in an ICA or RDP session can cause
the server to become unstable.
Examples
The following command remaps the server's drive letters. The first available drive is changed to M. The
command uses the noreboot option.
driveremap64 /u /drive:M /noreboot

The following command returns the server's drive letters to the drive letters that start at C and then prompts
you to restart the server.
driveremap64 /u /drive:M /drive:C

Known Issues
When running driveremap64, you might encounter the following issues.
When running driveremap64 with no parameters, the drive letter choices in the drop-down list may
be unavailable. This can occur if the server has non-contiguous drive letters; for example, C, D, X.
The mapped drive letters are spread over the interval [a..z] and no reasonable interval shifting can
be performed. Network drives are also taken into account.
To work around this issue, change the drive letters to C, D, and E and then run the driveremap64 utility.
At a command prompt, if you remap to a letter that is in use, nothing happens and you are returned
to the prompt. Locate the server's drive letters in Windows Explorer to verify the drive letters are changed.
Installation of the Web Interface on a XenApp server may fail if you are upgrading a server with
remapped drives. See article CTX240747 in the Citrix Knowledge Center.
If you upgrade from MetaFrame 1.8 to Citrix XenApp on a server with changed server drive letters ,
the Windows Pass-through Client is not updated. To avoid this issue, be sure the server is operating
in install mode before running Setup.
Only Citrix administrators can run this command.
Additional Information
If you change the server's drive letters, XenApp searches the following registry keys and changes all
drive references to the new drive letters:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*
HKEY_LOCAL_MACHINE\SOFTWARE\Equinox\eqn\CurrentVersion\NetRules
HKEY_LOCAL_MACHINE\SYSTEM\*
HKEY_CLASSES_ROOT\*
HKEY_USERS\*
XenApp also updates the pagefile entry and the following shortcut files:
%SystemRoot%\Profiles\Default User\*.lnk
%SystemRoot%\Profiles\Administrator\*.lnk
%SystemRoot%\Profiles\All Users\*.lnk
Note: The first time a user logs on to a server after you change the drive lettes, references to the old
drive letters in the user's profile are updated.
Before installation of XenApp 5 for Windows Server 2003, you can run the Drive Remapping utility from
the autorun screens of the XenApp installation media (this is not available on XenApp 5 Feature Pack 2
for Windows Server 2003). After installing XenApp, you can open the utility by running driveremap.exe with
no parameters.
8.7.10.11. 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.
/?
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 farm
s 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.
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.
For data store reference information, see the Citrix XenApp Installation Guide.
Examples
To run consistency checks only:
dscheck
To check consistency and fix errors:
dscheck /clean
To run this utility, you must have direct access to the data store.
8.7.10.12. DSMAINT
Updated: 2011-01-10
Run the 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 [/user:username] [/pwd:password] [/dsn:filename]

dsmaint backupdestination_path destination_path
dsmaint failover direct_server [psserverport=portnumber]
dsmaint compactdb [/ds] [/lhc]
dsmaint migrate [{/srcdsn:dsn1 /srcuser:user1 /srcpwd:pwd1}] [{/dstdsn:dsn2 /dstuser:user2
/dstpwd:pwd2}]
dsmaint patchindex [/user:username] [/pwd:password] [/dsn:filename]
dsmaint publishsqlds {/user:username /pwd:password}
dsmaint recover
dsmaint recreatelhc
dsmaint recreaterade
dsmaint verifylhc [/autorepair]
dsmaint [/?]
Parameters
destination_path
Path for the backup Microsoft Access 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
The name of of the DSN file for the destination data store.
filename
The name of the data store.
direct_server
The name of the new direct server for data store operations.
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"
/user:username
The user name to connect to a data store.
/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 Access 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. This parameter cannot be used to back up Oracle or SQL data stores.
Caution: When running dsmaint backup, specifying the same path as the existing data store
can damage it irreparably.
failover
Switches the server to use a new direct server for data store operations. Using psserverport, you
can specify a port number when switching servers.
compactdb
Compacts the Access database file.
/ds
Specifies the database is to be compacted immediately. If the Citrix Independent Management
Architecture service is running, this can be executed from the direct server or an indirect server. If
the Citrix Independent Management Architecture service is not running, this can be executed only on
the direct server.
/lhc
Compacts the local host cache on the server where this parameter is run. You might want to 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 direct 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 Access to Oracle).
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 direct 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.
/srcpwd:pwd1
The password to use to connect to the date 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.
recover
Restores an Access data store to its last known good state. Run this directly on server while the
Citrix Independent Management Architecture service is not running.
recreatelhc
Recreates the local host cache database. Perform 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. Perform 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.
Remarks
After using dsmaint, Citrix recommends running dscheck to check the integrity of the data on the XenApp
data store.
For data store reference information, see the Citrix XenApp Installation Guide.
compactdb
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.
config
For Access databases, this command resets the password used to protect the database, setting the
matched security context to allow IMA access to this database.
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
or Oracle database.
migrate
Existing data store databases can be migrated to different database software. For example, you can create a
farm with an Access database and later migrate the farm data store to a SQL Server database. For
more information about migrating the data store to different database software and which migrations
are supported, see Data Store Database Reference.
Important: By default, the Access database does not have a user name or password. When migrating
a database from Access, leave the /srcuser:and /srcpwd: parameters blank.
The connection to a local Access database is based on the host servers name. If the name of the server
changes, use migrate to change the name of the database.
patchindex
After running dsmaint patchindex, you must restart the Citrix Independent Management Architecture service
on all servers.
publishsqlds
Execute publishsqlds only from the server that created the farm. The publication is named MFXPDS.
The dsmaint config and dsmaint migrate commands can be executed only by a user with the correct
user name and password for the database.
8.7.10.13. ENABLELB
If one or more servers is removed from load balancing because they failed a Health Monitoring test, use enablelb
to restore them to the load balance tables.
Syntax
enablelb servername [servername servername ]
Parameters
servername
The name of the computer running Citrix XenApp.
To use this utility you must be a Citrix administrator with edit privileges for Other Farm Settings and Other
Server Settings for the server you want to restore to load balancing.
8.7.10.14. 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.
/?
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 plugin that will connect to that server. For
instructions for changing the port number on plugins, see the Administrators Guide for the plugins that you
plan to deploy.
Examples
To set the TCP/IP port number to 5000
icaport /port:5000
To reset the port number to 1494
icaport /reset
Only Citrix administrators with Windows administrator privileges can run icaport.
8.7.10.15. IMAPORT
Use imaport to query or change the IMA port.
Important: When you run Citrix XenApp Setup, Setup references port 2513 for communication with the
tool known as XenApp Advanced Configuration or the Presentation Server Console, depending on the version
of XenApp you have installed. If you change this port number on the first server in the farm on which
you install Citrix XenApp, you cannot join additional servers to the server farm.
Syntax
imaport {/query | /set {IMA:nnn | ds:nnn | cmc:nnn}* | /reset {IMA | DS | CMC | ALL} } [/?]
Options
/query
Queries the current setting.
/set
Sets the designated TCP/IP port(s) to a specified port number.
ima:nnn
Sets the IMA communication port to a specified port number.
cmc:nnn
Sets the XenApp Advanced Configuration connection port to a specified port number.
ds:nnn
Sets the data store server port to a specified port number (indirect servers only).
/reset
Resets the specified TCP/IP port to the default.
ima
Resets the IMA communication port to 2512.
cmc
Resets the XenApp Advanced Configuration connection port to 2513.
ds
Resets the data store server port to 2512 (indirect servers only).
all
Resets all of the applicable ports to the defaults.
/?
8.7.10.16. MIGRATETOSQLEXPRESS
Use migratetosqlexpress to migrate a server farms data store from Microsoft Access to Microsoft SQL
Server 2005 Express Edition.
Migratetosqlexpress offers fail-safe operation and automatically rolls back any changes that it makes to
the system in the event of any failures.
The utility is located on the Citrix XenApp installation media in the Support\SqlExpress directory.
Syntax
migratetosqlexpress [/instancename:instancename | /dbname:dbname | /accessuser:user |

/accesspwd:pwd | /revert | [/?]
Options
/instancename:instancename
Specify a named instance of SQL Server Express other than the default value of CITRIX_METAFRAME.
/dbname:dbname
Specify a database other than the default value of MF20.

/accessuser:user
/accesspwd:pwd
Specify the user and pwd values for your Access database if you changed them using the dsmaint config
utility.
/revert
Reverts to the Access database originally used as the server farms data store. Running this
command restores backups that were made when the migration was initially done. Any changes made
to the farm since the migration from Access to SQL Server Express are lost.
/?
8.7.10.17. 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
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.
/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.
/?
Remarks
Query farm returns information for IMA-based servers within a server farm.
You must be a Citrix administrator to run query farm .
8.7.10.18. 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
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.
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.
/?
None.
8.7.10.19. QUERY SESSION
Updated: 2010-06-07
Use query to display information about sessions within the network.
Syntax
query session [sessionname | username | sessionid]
query session [sessionname | username | sessionid]

query session [/server:servername] [/mode] [/flow] [/connect] [/counter]
query session [/?]
Parameters
servername
sessionname
sessionid
The two-digit ID number of a session.
username
Options
session sessionname
Identifies the specified session.
session username
Identifies the session associated with the user name.
session sessionid
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.
/?
None.
8.7.10.20. 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
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.
/?
Remarks
If no parameters are specified, query termserver lists all Terminal Servers within the current domain.
None.
8.7.10.21. QUERY USER
Use query to display information about users within the network.
Syntax
query user [ username | sessionname | sessionid ] [ /server:servername ]

query user [/?]
Parameters
servername
sessionname
sessionid
The ID number of a session.
username
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.
user /server: servername
Defines the server to be queried. The current server is queried by default.
/?
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.
None.
8.7.10.22. TWCONFIG
Use twconfig to configure ICA display settings that affect graphics performance for plugins.
Syntax
twconfig [/query | /q]

twconfig [/inherit:on | off]
twconfig [discard:on | off]
twconfig [/supercache:on | off]
twconfig [/maxmem:nnn]
twconfig [/degrade:res | color]
twconfig [/notify:on | off]
twconfig [/?]
Options
/query
/q
Query current settings.
/inherit:on | off
Set to on to use the ICA display properties defined for the farm. Set to off to use the settings specified
for this server. By default, this is set to on.
/discard:on | off
Discard redundant graphics operations.
/supercache:on | off
Use alternate bitmap caching method.
/maxmem:nnn
Maximum memory (in kilobytes) to use for each sessions graphics (150KB minimum, 8192KB maximum).
/degrade:res | color
When the maxmem limit is reached, degrade resolution first or degrade color depth first.
/notify:on | off
If on, users are alerted when the maxmem limit is reached.
/?
Remarks
A server can be set to inherit its ICA display settings from the server farm ICA display settings. Use /query
to display the current inherit settings. If /inherit is on, the settings displayed with /query are the server
farm settings. When /inherit is off, the settings shown are for the current server only.
Within the maxmem limit, various combinations of session size and color depth are available. The session
size and color depth values are determined using the following formula: height x width x depth maxmem
, where the height and width are measured in pixels and depth is the color depth in bytes according to
the following table:
Color depth
Bytes
True Color (24-bit) 3

High Color (16-bit) 2
256 Colors (8-bit)
16 Colors (4-bit)
.5
The following is a list of the maximum session sizes with a 4:3 aspect ratio for each color depth at the default
maxmem value (height by width by color depth):
1600 by 1200 by 24-bit color
1920 by 1440 by 16-bit color
2752 by 2064 by 256 colors
3904 by 2928 by 16 colors
To run twconfig you must have Windows administrator privileges.
8.7.11. Policy Rules Reference
Policies contain rules that define and configure connection settings to be applied when the policy is enforced.
You configure these rules using the tool known as XenApp Advanced Configuration or the Presentation
Server Console, depending on the version of XenApp you have installed.
The major categories of rules are:
Bandwidth
Client Devices
Printing
User Workspace
Security
Service Level
All of these categories are represented by top-level folders that contain related rules.
Note: Servers running some earlier releases of XenApp in a mixed farm cannot access all these rules.
Citrix recommends that you maintain all servers in a farm at the same release level.
8.7.11.1. Policy Rules: Quick Reference Table

Updated: 2009-08-13
The following tables present rules you can configure within a policy. Find the task you want to perform in the
left column, then locate its corresponding rule in the right column.
HDX 3D
To limit bandwidth used for:
Use this policy rule:
Compression level for image acceleration and

image acceleration for dynamic graphics
Progressive Display
HDX Broadcast
To limit bandwidth used for:
Desktop wallpaper
Visual Effects > Turn off desktop wallpaper
Window contents while a window is dragged
Visual Effects >Turn off window contents

while dragging
Client audio mapping
Session Limits > Audio
Cut-and-paste using local clipboard
Session Limits > Clipboard
Devices connected to a local COM port
Session Limits > COM ports
Access in a session to local client drives
Session Limits > Drives
Printers connected to the client LPT port
Session Limits > LPT Ports
Custom devices connected to the client through

OEM virtual channels
Session Limits > OEM Virtual Channels
Client session
Session Limits > Overall Session
Printing
Session Limits > Printer
TWAIN device (such as a camera or scanner)
Session Limits > TWAIN Redirection
HDX Plug-n-Play
Task:
Control whether or not to allow audio input from

client-device microphones
Client Resources > Audio > Microphones
Control client-device audio quality
Client Resources > Audio > Sound quality
Control audio mapping to client-device speakers
Client Resources > Audio > Turn off speakers
Control whether or not client-device drives are

connected when users log on to the server
Client Resources > Drives > Connection
Control how drives map from the client device
Client Resources > Drives > Mappings
Improve the speed of writing and copying files to a

client disk over a WAN
Client Resources > Drives > Optimize

> Asynchronous writes
Prevent client devices attached to local COM ports

from being available in a session
Client Resources > Ports > Turn off COM ports
Prevent client printers attached to local LPT ports

from being made available in a session
Client Resources > Ports > Turn off LPT ports
Enable USB-tethered Windows CE-based PDA devices

to use USB-to-virtual COM-port emulation
Client Resources > PDA Devices > Turn

on automatic virtual COM port mapping
Configure resources for the use of TWAIN devices,

such as scanners and cameras
Client Resources > Other > Configure

TWAIN redirection
Prevent cut-and-paste data transfer between the

server and the local clipboard
Client Resources > Other > Turn off

clipboard mapping
Prevent use of custom devices, such as an electronic

pen (stylus)
Client Resources > Other > Turn off OEM

virtual channels
Turn off automatic plugin updates
Client Maintenance > Turn off auto client update
Control creation of client printers on the client device
Printing > Client Printers > Auto-creation
Allow use of legacy printer names and

preserve backward compatibility with prior versions
of the server
Printing > Client Printers > Legacy client printers
Control the location where printer properties are stored
Printing > Client Printers > Printer

properties retention
Control whether print requests are processed by

the client or the server
Printing > Client Printers > Print job routing
Prevent users from using printers connected to

their client devices
Printing > Client Printers > Turn off client

printer mapping
Control installation of native Windows drivers

when automatically creating client and network printers
Printing > Drivers > Native printer driver auto-install
Control when to use the Universal Printer Driver
Printing > Drivers > Universal driver
Choose a printer based on a roaming users

session information
Printing > Session printers
Control whether or not to use content redirection

from the server to the client device
Content Redirection > Server to client
Use the servers time zone instead of the client

s estimated local time zone
Time Zones > Do not estimate local time for

legacy clients
Use the servers time zone instead of the clients

time zone
Time Zones > Do not use Clients local time
User Workspace
Task:
Limit the number of sessions that a user can run at

the same time
Connections > Limit total concurrent sessions
Direct connections to preferred zones and failover

to backup zones
Connections > Zone preference and failover
Control whether or not shadowing is allowed
Shadowing > Configuration
Allow or deny permission for users to shadow connections Shadowing > Permissions
Identify which credential repository to use when
using Citrix Password Manager
Single Sign-on > Central Credential Store
Prevent use of Citrix Password Manager
Single Sign-on > Do not use Citrix

Password Manager
Override the delivery protocol for applications

streamed to client
Streamed Applications > Configure

delivery protocol. This rule appears only in
the Enterprise Edition of XenApp.
Security
Task:
Require that connections use a specified encryption level Encryption > SecureICA encryption
8.7.11.2. Bandwidth Folder

The Bandwidth folder contains subfolders of rules you can configure to avoid performance problems related
to client session bandwidth use. These subfolders are:
Visual Effects
SpeedScreen
Session Limits and Session Limits (%)
Visual Effects Folder

This folder contains rules to turn off visual effects to lower bandwidth used in client connections.
SpeedScreen Folder
This folder contains a rule that removes or alters compression when downloading images.
Session Limits and Session Limits (%) Folders
These folders contain rules that limit bandwidth used for data transfer in client connections.
8.7.11.2.1. Visual Effects Folder
The Visual Effects folder contains rules to turn off visual effects, such as desktop wallpaper, menu
animations, and drag-and-drop images, to lower the bandwidth used in client connections. You can
improve application performance on a WAN by limiting bandwidth usage.
Turn Off Desktop Wallpaper
To turn off desktop wallpaper in user sessions, set this rule to Enabled.
Turn Off Menu Animations
Menu animations are a Microsoft personal preference setting that causes a menu to appear after a short
delay, either by scrolling or fading in. When menu animations are on, an arrow icon appears at the bottom of
the menu and the menu appears when you mouse over that arrow.
If you want to turn off menu animations in client connections, set this rule to Enabled.
Turn Off Window Contents While Dragging
When you drag a window across the screen, either the entire window appears to move when you drag it or
just an outline of the window moves until you drop the window. The latter occurs when you turn off
window contents while dragging.
If you want to turn off window contents while dragging in user sessions, set this rule to Enabled.
8.7.11.2.2. SpeedScreen Folder
The SpeedScreen folder contains a rule that enables you to remove or alter compression. When client
connections are limited in bandwidth, downloading images without compression can be slow.
Image Acceleration Using Lossy Compression
This rule defines ways in which images can be compressed to improve the responsiveness of graphicsintensive applications:
Normal lossy compression
Progressive display compression
If your server farm includes servers running different releases of XenApp, you may not be able to apply all
of these image acceleration techniques to all of the servers in the farm. Citrix recommends that you maintain
all servers in a farm at the same release level.

If this rule is not configured, SpeedScreen Image Acceleration applies image compression as follows:
Medium compression for WAN and lower bandwidth connections; no compression for LAN connections
SpeedScreen Progressive Display is disabled
Compression Level
This setting controls the normal lossy compression level used over client connections that are limited
in bandwidth. In such cases, displaying images without compression can be slow. The Compression level
setting defines the degree of lossy compression used on images. 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.
Enter the maximum bandwidth in kilobits per second in Restrict compression to connections under
this bandwidth. The Compression level setting is then applied only to client connections under this bandwidth.
SpeedScreen Progressive Display Compression Level
Slow initial download of images can be frustrating for users. The SpeedScreen Progressive
Display compression level setting provides a less detailed but faster initial display. 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.
Enter the maximum bandwidth in kilobits per second in Restrict compression to connections under
this bandwidth. The SpeedScreen Progressive Display compression level is then applied only to
client connections under this bandwidth.
For this feature to be effective, the SpeedScreen Progressive Display compression level setting must be
higher than the Compression level setting. By default, it is two settings higher. For example, if
Compression level is set to medium compression, SpeedScreen Progressive Display compression level
is set to very high compression.
Note: The increased level of compression associated with SpeedScreen Progressive Display 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.
8.7.11.2.3. Session Limits and Session Limits (%) Folder
The Session Limits and Session Limits (%) folders contain rules you can use to limit the bandwidth used for
data transfer in client connections; for example, when accessing drives or printing. You can improve
application performance on a WAN by limiting bandwidth used by competing channels for drives and printers
over the same client connection or for all client connections.
If you want to limit sessions by a specific amount of kilobits per second, use the rules in the Session Limits
folder. If you want to limit sessions to a percentage of the overall session bandwidth setting, use the rules in
the Session Limits (%) folder. This specifies a limit for the individual virtual channels. If you use Session
Limits (%) rules, you must also enable the Overall Session rule in the Session Limits folder.
If you set a fixed value and a percentage value in two parallel rules (for example, Bandwidth > Session Limits
> Audio and Bandwidth > Session Limits (%) > Audio), the most restrictive rule (that is, the lower value) is
the one that is applied.
Audio
By default, users have access to audio equipment attached to their client devices when connected to a
session. Applications running in a session can play sounds on the client. Client audio mapping can cause
excessive load on the servers and the network.
You can limit the bandwidth consumed by audio on a client in a client connection. Limiting the amount
of bandwidth consumed by audio can improve application performance. This is useful when audio and
application data compete for limited bandwidth. Limiting the bandwidth used can degrade audio quality.
After enabling the rule, enter the maximum amount of bandwidth in the Limit box. The value you enter is
either in kilobits per second or as a percentage of overall available bandwidth, depending on whether you
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that audio
can consume in a client connection.
Clipboard
You can limit the bandwidth consumed by a cut-and-paste data transfer between a session and the
local clipboard. Limiting the amount of bandwidth consumed by using the clipboard can improve
application performance. This is useful when clipboard data and application data compete for limited bandwidth.
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that using
the clipboard can consume in a client connection.
COM Ports
You can limit the bandwidth consumed when a client COM port is accessed in a client connection. Limiting
the amount of bandwidth consumed by COM port communication can improve application performance. This
is useful when the COM port virtual channel and application data compete for limited bandwidth.
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that COM
port access can consume in a client connection.
Drives
You can limit the bandwidth consumed when a client drive is accessed in a client connection. Limiting the
amount of bandwidth consumed by client drive access can improve application performance. This is useful
when mapped drive virtual channels and application data compete for limited bandwidth.
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that client
drive access can consume in a client connection.
LPT Ports
You can limit the bandwidth consumed by a print job using an LPT port in a single client connection. Limiting
the amount of bandwidth consumed by LPT port communication can improve application performance. This
is useful when the LPT port channel and application data compete for limited bandwidth.
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that LPT
port access can consume in a client connection.
OEM Virtual Channels
Custom (OEM) devices attached to ports on the client device can be mapped to ports on the server.
You can limit the bandwidth that a custom devices virtual channel can consume in a single client
connection. Limiting the amount of bandwidth consumed by these devices can improve application
performance. This is useful when custom devices and application data compete for limited bandwidth.
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that an OEM
s virtual channel can consume in a client connection.
Overall Session
You can limit the bandwidth used in a single client connection overall. 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.
in kilobits per second. This is the amount of bandwidth that a client connection can consume overall.
Printer
You can limit the bandwidth that a print job can use in a single client connection. Limiting the amount
of bandwidth consumed by print jobs can improve application performance. This is useful when printing
and application data compete for limited bandwidth.
in either kilobits per second or as a percentage of overall available bandwidth, depending on whether you
choose the Session Limits folder or the Session Limits % folder. This is the amount of bandwidth that a print
job can consume in a client connection.
TWAIN Redirection
Use this rule to set the maximum amount of bandwidth available to this feature in client sessions.
TWAIN devices are image acquisition devices, such as scanners and digital cameras, that use
manufacturer-supplied, industry standard TWAIN drivers. TWAIN redirection (enabled by default) allows users
to access client-side TWAIN devices from published image processing applications.
choose the Session Limits folder or the Session Limits % folder.
To set a compression level for image transfers or to disable TWAIN redirection, use the rule Client Devices
> Resources > Other > Configure TWAIN redirection.
8.7.11.3. Client Devices Folder
The Client Devices folder contains subfolders of rules related to mapping various functions to client devices.
These subfolders are:
Resources
Audio
Drives
Optimize
Special Folder Redirection
Ports
PDA Devices
Other
Maintenance
Note: Disabling or not configuring rules that explicitly turn off device mapping does not turn device mapping on.
8.7.11.3.1. Resources Folder
The Resources folder contains rules related to mapping various client devices to similar devices on a server.
Citrix XenApp Plugin for Hosted Apps for Windows supports mapping client devices to servers so they
are available to users running sessions. You can restrict access to client devices depending on
connection conditions.
8.7.11.3.1.1. Audio Folder
The Audio folder contains rules you can set to permit client devices to send and receive audio in sessions
without reducing performance.
Microphones
You can allow users to record audio using devices such as microphones on the client. To record audio, the
client device needs either a built-in microphone or a device that can be plugged into the microphone jack.
If audio is disabled (the default on the client), this rule has no effect.
For security, users are alerted when servers that are not trusted by their client devices try to access
microphones. Users can choose to accept or not accept access. Users can disable the alert on Citrix XenApp
Plugin for Hosted Apps for Windows.
To control whether or not users can record audio during their sessions, enable the rule and then choose one
of the following options:
To allow recording, select Use client microphones for audio input
To turn off audio recording (for example, when bandwidth is limited), select Do not use
client microphones for audio input
Sound Quality
Use the projected figures for each level of sound quality to calculate the bandwidth potentially consumed
in connections to specific servers. For example, if 25 users record at medium quality on one server,
the bandwidth used in the connections to that server is over 200,000 bytes per second.
Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the
bandwidth consumption is doubled.
To control sound quality, enable this rule and then choose one of the following options:
Select Low sound quality for low-bandwidth connections. Sounds sent to the client are compressed up
to 16Kbps. This compression results in a significant decrease in the quality of the sound but
allows reasonable performance for a low-bandwidth connection.
Select Medium sound quality for most LAN-based connections. Sounds sent to the client are
compressed up to 64Kbps. This compression results in a moderate decrease in the quality of the
sound played on the client device and allows good performance.
Select High sound quality 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.3Mbps of bandwidth to
play clearly. Transmitting this amount of data can result in increased CPU utilization and
network congestion.
Turn Off Speakers

You can allow users to receive audio from an application on a server through speakers on their client
devices. Client audio mapping can cause excessive load on the servers and the network.
To turn off audio reception in connections, enable this rule.
8.7.11.3.1.2. Drives Folder
The Drives folder contains rules relating to client drive mapping and client drive optimization.
Connection
By default, all drives are mapped when users log on. If you want to stop drives from being mapped when
users log on (for example, to prevent users from saving files to their local drive), enable this rule.
After enabling this rule, select one of the following options:
Do Not Connect Client Drives at Logon
Connect Client Drives at Logon
Mappings
By default, all client drives are mapped when a user logs on and users can save files to all their client drives.
To prevent users from saving files to one or more client drives, enable this rule and select the drives that
you want to prevent users from accessing.

Turn off Floppy disk drives
Prevents users from accessing their floppy disk drives, such as drive A.
Turn off Hard drives
Prevents users from accessing any of their hard drives, such as drive C.
Turn off CD-ROM drives
Prevents users from accessing any of their CD-ROM drives.
Turn off Remote drives
Prevents users from accessing any mapped network drives, such as remote drives located in the
Windows Server 2008 Computer panel.
Disabling this rule causes the default of access to all drives to override the same rule in lower priority policies.
This rule does not turn drive mapping on for users. Use the Connection rule to stop or start mapping
drives automatically when users log on.
8.7.11.3.1.2.1. Optimize Folder
The Optimize folder contains rules related to improving client drive performance.
Asynchronous Writes
Use this rule to specify asynchronous disk writes and change the speed at which physical files are
transferred from server to client. Asynchronous disk writes can speed up file transfers and general writing
to client disks over wide area networks (WANs), which are typically characterized by relatively high
bandwidth and high latency.
However, if there is a line 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, and the user can then take remedial
action, such as restarting an interrupted file transfer on reconnection or when the disk fault is corrected.
With the rule enabled, the check box for Turn on asynchronous disk writes to client disks is selected.
This setting enables asynchronous file transfers for a connection.
Citrix recommends that you implement 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.
8.7.11.3.1.3. Other Folder
The Other folder contains rules related to mapping to other client resources; for example, ports to which
custom devices are attached.
Configure TWAIN Redirection
Use this rule to configure a compression level for image transfers from client to server or to disable
TWAIN redirection. TWAIN redirection (enabled by default) allows users to access TWAIN devices on the
client from published image processing applications.
TWAIN devices are image acquisition devices, such as scanners and digital cameras, that use
manufacturer-supplied, industry-standard TWAIN drivers. This rule sets the compression level when users
connect to TWAIN devices on the client with published image processing applications.
After enabling the rule, select an option:
Do not allow TWAIN redirection
Prevents the use of TWAIN devices on the client from published applications.
Allow TWAIN redirection
Enables the feature and lets you configure a compression level. Selected by default.
Use lossy compression for high color images

Allows you to select the level of compression from the list (low for best image quality, medium for
good image quality, or high for lowest quality).
To limit the amount of bandwidth available to this feature in client sessions, use either the rule Bandwidth >
Session Limits > TWAIN Redirection or Bandwidth > Session Limits (%) > TWAIN Redirection.
Turn Off Clipboard Mapping
By default, clients map the client clipboard to the server clipboard.
To prevent cut-and-paste data transfer between a session and the local clipboard, set the rule to Enabled.
Users can still cut and paste data between applications running in sessions.
Turn Off OEM Virtual Channels
By default, custom devices attached to ports on the client device can be mapped to ports on the server.
To turn off OEM virtual channels in connections to which this policy is applied, set this rule to Enabled.
8.7.11.3.1.4. Ports Folder
This folder contains rules for client LPT and COM port mapping.
Turn Off COM Ports
By default, client COM ports are turned on and available for mapping to server COM ports. However, they are
not mapped automaticallyat logon; you must map them manually in the session.
To make client COM ports unavailable for mapping, set the rule to Enabled.
Note: PDA devices are not supported in XenApp 5.0. However, in a mixed-farm environment, enabling this
rule prevents PDA devices from working in client sessions initiated from pre-Windows Vista client devices.
Turn Off LPT Ports

By default, the LPT ports on the client are mapped to LPT ports on the server when a user logs on to a
session. However, 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.
When this rule is enabled, users cannot print to legacy applications that print through LPT ports. This rule
is necessary only for servers that host legacy applications that print to LPT ports.
To prevent data transmission to an LPT port, set the rule to Enabled.
8.7.11.3.1.5. PDA Devices folder
Due to limitations in Windows Server 2008, PDA support is not available in XenApp 5.0. Users can sync PDAs
only if they are running an operating system released before Windows Vista on their client device and they
are syncing to an application published on a server running Citrix Presentation Server 4.0 or 4.5. The Turn
on automatic virtual COM port mapping rule appears in XenApp 5.0 to let you manage servers from
earlier releases; it has no effect on a server running XenApp 5.0.
Turn On Automatic Virtual Com Port Mapping
Use this rule to enable users with USB-tethered, Windows CE-based PDA devices to use USB-to-virtual-COMport emulation in client sessions.
By default, client COM ports, both physical and virtual, are not mapped automatically at logon.
To map virtual COM ports automatically at logon
1.
1. On a server running Windows Server 2003 and Presentation Server 4.5, set this rule to Enabled.
2. Set the rule Client Devices > Resources > Ports > Turn off COM ports to Not Configured or Disabled.
8.7.11.3.2. Maintenance Folder
The Maintenance folder contains rules related to the maintenance of client devices.
Turn Off Auto Client Update
You can use an Auto Client Update database to distribute the latest Delivery Client (SV) software to client
devices automatically.
Note: The Auto Client Update feature is no longer supported.
If you are using Auto Client Update and want to turn it off; for example, in client connections to specific
servers, set the rules state to Enabled.
8.7.11.4. Printing Folder
Updated: 2010-04-08
The Printing folder contains the Session printer policy rule which assigns auto-created network printer. It
also contains subfolders of rules for managing client printing and printer drivers.
Client Printers Folder
This folder contains rules for client printers, including settings to autocreate client printers, use legacy
printer names, retain printer properties, route print jobs, and turn off client printer mapping.
Auto-Creation
Use this rule to override default client printer autocreation settings. By default, client printers are created at
logon based on Terminal Services settings and users can print from sessions using these printers.
Disabling this rule causes the Terminal Services settings for autocreating client printers to override this rule
in lower priority policies.
Important: This rule applies only if client printer mapping is enabled.
Auto-create all client printers
Automatically creates all printers on a client device. Selected by default.
Auto-create local (non-network) client printers only
Automatically creates only printers directly connected to the client device through an LPT, COM, USB,
or other local port.
Auto-create the clients default printer only
Automatically creates only the printer selected as the clients default printer.
Do not auto-create client printers
Turns off autocreate for all client printers when users log on.
Legacy Client Printers

Use this rule to allow old-style client printer names and preserve backward compatibility for users or groups
using MetaFrame Presentation Server 3.0 or earlier.
Create dynamic session-private client printers
Creates client printers that are private to each user session, and uses standard client printer names
similar to those created by native Terminal Services, such as HPLaserJet 4 from clientname in session
3. Selected by default.
Create old-style client printers
Creates printers that can be shared between sessions and uses printer names based on the old
naming conventions, such as 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.
Printer Properties Retention

Use this rule to choose where to store printer properties: on the client device only, in the user profile only, or
a combination based on the best option for your users. Base your choice on the installed versions of Citrix
XenApp and Citrix XenApp Plugin for Hosted Apps for Windows.
Held in profile only if not saved on client
Allows the system to determine the method. Selected by default. Printer properties are stored on the
client device if available, or, if not, in the user profile. Although this option is the most flexible, it can
also slow down logon time and use extra bandwidth to perform the needed system-checking.
Saved on the client device only
Stores printer properties only on the client device. Use this option if your system has a mandatory
or roaming profile that you do not save.
Retained in user profile only
Stores printer properties in the user profile on the server and prevents any properties exchange with
the client. Use this option with installations of MetaFrame Presentation Server 3.0 or earlier and
MetaFrame Presentation Server Client 8.x or earlier. This option is also useful if your system is
constrained by bandwidth (this option reduces network traffic) and the default combination option
slows down logon time.
Print Job Routing

Use this rule to control how to route printing requests to the network print server.
Connect directly to network print server if possible
Routes print jobs directly from the XenApp server to the network print server. Selected by default. Use
this option if the network print server is not across a WAN from the server. Direct communication results
in faster printing if the network print server and server are on the same LAN.
Always connect indirectly as a client printer
Routes print jobs through the client device, where it is redirected to the network print server. Use
this option if the network is across a WAN or has substantial latency or limited bandwidth. Data sent to
the client is compressed, so less bandwidth is consumed as the data travels across the WAN.
Additionally, if two network printers have the same name, the printer on the same network as the client
is used.
Turn Off Client Printer Mapping

Use this rule to disable all client printing by preventing mapping to client printers. By default, client printers
are mapped to a server when a user logs on to a session.
Drivers Folder
The Drivers folder contains rules relating to printer drivers.
The Native Printer Driver and Universal Driver rules control whether certain printer drivers are used when
users log on to a XenApp farm. The Session Printers rule controls the printers roaming users can access based
on their session information.
For information about configuring these rules, see Configuring Printing.
8.7.11.5. User Workspace Folder
The User Workspace folder contains subfolders of rules for maintaining a good user experience while
permitting specific capabilities and without reducing server performance.
8.7.11.5.1. Connections Folder
This folder contains rules for directing and limiting connections for each user.
Limit Total Concurrent Sessions
You can restrict the number of concurrent connections (user sessions) that users can have in the server
farm. This reduces the number of client connection licenses in use and conserves resources. The setting for
the least connections overrides any other setting.
To limit the number of concurrent connections allowed, set the rule to Enabled and then type the number
of concurrent connections you want to allow in the Limit box.
Zone Preference and Failover
You can use zone preference and failover to direct connections to the least loaded server in the same zone
or zones on the same LAN. Unless zones are arranged in a preferred connection order, users are directed to
the server with the least load even if that server is in another zone across a WAN. If a zone is unavailable,
the connection can be directed to other primary zones, backup zones, or zones with no preference, for
business continuity.
Important: Zone preferences always take precedence over session sharing when they are in conflict.
This rule can be applied to users, IP addresses, and client names, but not servers.
To set the connection order for zones, set the rule to Enabled and then select one or more zones in
Zone preference settings. For zones to which you want connections directed first, select Primary Group.
For zones to which you do not want users to connect, select Do Not Connect.
You can select additional zones as backups. You can place zones in Backup Group 1 through Backup Group 10 in
Set connection order for selected zones. Backup Group 10 is last in backup connection order. Zones with
no preference, which is the default, are chosen for connection after zones in Backup Group 10.
8.7.11.5.2. Content Redirection Folder
This folder contains rules for using content redirection from servers to plugins.
Server to Client
By default, users open URLs embedded in remote applications using Web browsers or multimedia players
running on servers. An example is a link to a multimedia URL sent in an email message. This can cause
excessive load on the servers and the network. If you want the users locally installed browser or
multimedia player to play URLs, turn on server content redirection. Server content redirection is available for
the plugins for Windows and the Client for Linux.
These URL types are opened locally when server content redirection is enabled:
Hypertext Transfer Protocol (HTTP)
Secure Hypertext Transfer Protocol (HTTPS)
Real Player and QuickTime (RTSP)
Real Player and QuickTime (RTSPU)
Legacy Real Player (PNM)
Microsofts Media Format (MMS)
To control server content redirection, set the rule to Enabled and then select one of the following options:
Use Content Redirection from server to client
Do not use Content Redirection from server to client
8.7.11.5.3. Shadowing Folder

You can allow users to shadow other users. This 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.
For user-to-user shadowing to work, configure the rules in the Shadowing folder, as follows:
Enable the Configuration rule to allow user-to-user shadowing in your environment. Then,
configure shadowing options for connections to which this policy is applied. You must specify which
users have permissions to shadow in the Permissions rule.
Use the Permissions rule to assign shadowing permissions to users who are allowed to shadow
other users.
You specify the users who can be shadowed when you apply the policy through a filter. All of the filtered
objects to which this policy is applied can be shadowed by anyone whose name is in the user list in
the Permissions rule.
If you create multiple shadowing policies and assign priorities, enable the Merge shadowers in
multiple policies setting on the farms Properties page. Without this setting enabled, lower priority
shadowing policies may be ignored.
You can configure shadowing during or after XenApp Setup by using policies or using Terminal
Services Configuration. The most restrictive shadowing settings override all other settings.
Note: Shadowing policy rules are not supported for users who authenticate through Novell Directory
Services when they log on.
8.7.11.5.3.1. Configuring User Shadowing
When you want to configure user-to-user shadowing you must enable support for it by enabling the
Configuration rule. Then select the users you want to be able to shadow other users in the Permissions rule.
To allow users to shadow the connection to which this policy is applied
1. Select this rule from the policys properties (User Workspace > Shadowing > Permissions).
2. Set the rule to Enabled.
3. Click Configure.
4. In the Assign Shadowing Permissions dialog box, specify the user or user group accounts that you
want to allow to shadow:
To add users or user groups to the Configured Accounts list, click Add List of Names to enter
user account names. Separate user names with a semicolon.
Use the Look in list to locate all trusted account authorities configured on the servers in the
farm. These can include Novell Directory Services (NDS) trees, Windows NT domains, Windows
2000 Active Directory domains, and local servers.
When you select an account authority, the user accounts that are part of the selected
authority appear in the window below the list. By default, only user groups appear.
To display every user in the selected domain, select Show Users. For NDS, alias objects also appear.
To deny shadowing permissions to any users in the Configured Accounts list, select Deny.
By default, each user or group is set to Allow.
8.7.11.5.3.2. Permissions to Shadow Users

To specify the users who can shadow other users, use the Permission rule. The users who can be shadowed
are all of the users to which this policy is applied. You must also enable the Configuration rule in the same
policy for shadowing to work.

To allow a user or user group to be shadowed
1. Select this rule from the policys properties (User Workspace > Shadowing > Configuration).
2. Set the rule to Enabled.
3. Select Allow Shadowing.
4. If you want the user being shadowed to be notified when shadowing starts, select Prohibit
Being Shadowed Without Notification.
5. If you do not want users to be able to take control of the mouse and keyboard of the user they
are shadowing, select Prohibit Remote Input When Being Shadowed.
6. In the left pane of the Property sheet, select the rule Permissions and then select which users can
shadow other users.
7. Filter the policy containing this rule based on the users you want to allow to be shadowed.
To prevent shadowing of the connections to which this policy is applied, set the rule to Enabled and select
Do Not Allow Shadowing.
To default to the settings in Terminal Services Configuration or in other policies, set the rule to Disabled.
8.7.11.5.4. Time Zones Folder
You can set the following policy rules in this folder to configure the time zone for connections to which this
policy is applied:
Enable the Do not estimate local time for legacy clients rule if you want the clients time zone to
be used when that information is available from the client device, but not estimated if the client
device cannot send that information. If you enable the rule Do not use Clients local time, this rule has
no effect.
Enable the Do not use Clients local time rule if you want the servers time zone to be used for all clients.
Do Not Estimate Local Time for Legacy Clients

By default, published applications reflect the users local time zone in sessions. Earlier plugin versions may
not send accurate time zone information to the server. In this situation, the server estimates local time zones
for client devices.
If you want the servers time zone to be used for older plugins instead of an estimated local time zone that
may not be accurate, set the rule to Enabled.
If you are using the servers time zone for all plugins because you enabled the rule Do not use Clients local
time, enabling the rule Do not estimate local time for legacy clients has no effect.
Do Not Use Clients Local Time
By default, published applications reflect the users local time zone in sessions. If you want the servers time
zone to be used, set this rule to Enabled.
8.7.11.5.5. Citrix Password Manager Folder
Some environments use Citrix Password Manager to authenticate users of published applications. This
folder contains policy rules for configuring and controlling the use of Password Manager.
Central Credential Store
Central credential stores are repositories for Password Manager data. Central credential stores can be of
several types, including file share and Active Directory. Use this rule to control which credential repository
stores information about which users or user groups. By default, the rule is Not Configured. To override
lower-priority policies, the rule must be Disabled or Enabled.
Because a single file share supports a maximum of 15,000 concurrent users, you may need multiple
credential stores if you have more than this number of users.
Controlling which credential store users connect to allows you to:

Assign users to geographically close central credential stores, thereby preventing that data from being
sent over a WAN
Define which central credential stores are used by specific user groups, clients, or servers
For more information about central credential stores, see the Password Manager documentation.
Enter the UNC path of the central credential store for use with this policy. Policies apply only to shared folders
you configure to be Password Manager central credential stores. If you want this policy to use the
central credential store specified by the Password Manager agent, leave this field blank.
Important: Server farm zone failover preferences apply only to published objects, not to central
credential 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 Password Manager if the credential store is in the
failed zone.
Do Not Use Citrix Password Manager
Use this policy rule to control which users can run Password Manager when they connect to servers or
published applications in your farm. This allows you to:
Deploy Password Manager gradually to user groups within zones or within the farm
Limit use of Password Manager to subgroups who are specifically licensed to use it within zones or
within the farm
Limit use of Password Manager to specific clients or to specific servers in the farm
By default, the rule is Not Configured. To override lower-priority policies, set the rule to Disabled or Enabled.
8.7.11.5.6. Streamed Applications Folder
This folder contains rules for configuring how streamed applications are delivered to users.
For information about the Citrix application streaming feature, see Application Streaming.
Configure Delivery Protocol
This rule enables you to override the delivery of applications published as Streamed to client. You select
the delivery method in the Publish Application wizard.
For streamed applications published as Accessed from a server, this rule does not apply.
The Force server access option, selected by default, forces users to launch streamed applications
from the server:
If you publish a streamed application as Streamed if possible, otherwise accessed from
a server (dual mode streaming), users 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.
The Force streamed delivery option forces client devices to stream the application from the file
share location to the client desktops. Users must have the XenApp Plugin for Streamed Apps installed
and they must access the application using XenApp Plugin for Hosted Apps or a Web Interface site.
For example, you might use this setting to prevent the use of server resources.
If you disable the rule or do not configure it, the delivery method selected in the Publish Application wizard
is used.
8.7.11.6. Security and Encryption Folders
Within the Security folder, the Encryption folder contains rules for raising encryption levels to further
secure communications and message integrity for certain users.
SecureICA Encryption
By default, the XenApp server uses basic encryption for client-server traffic. You can raise encryption levels
to further secure communications and message integrity for certain users. If you create a policy to require
a higher encryption level, plugins using a lower encryption level are denied a connection.
You can specify encryption levels for sessions using policies or using the Access Management Console or
Delivery Services Console. The setting configured for the highest encryption overrides all other settings.
After enabling this rule, select one of the following encryption levels:
Basic encrypts the client connection using a non-RC5 algorithm. It protects the data stream from
being read directly, but 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.
8.7.12. 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 XenApprelated 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
8.7.12.1. Citrix CPU Utilization Mgmt User Counters

The following counters are available through the Citrix CPU Utilization Mgmt User performance object
in Performance Monitor.
Counter
Description
CPU Entitlement
The percentage of CPU resource that Citrix CPU Utilization

Management makes available to a user at a given time.
CPU Reservation
The percentage of total computer CPU resource reserved for a user,

should that user require it.
CPU Shares
The proportion of CPU resource assigned to a user.
CPU Usage
The percentage of CPU resource consumed by a user at a given

time, averaged over a few seconds.
Long-term CPU Usage
The percentage of CPU resource consumed by a user, averaged over a

longer period than the CPU Usage counter.
8.7.12.2. Citrix IMA Networking Counters

The following counters are available through the Citrix IMA Networking performance object in
Performance Monitor.
Counter
Description
Bytes Received/sec
The inbound bytes per second.
Bytes Sent/sec
The outbound bytes per second.
Network Connections
The number of active IMA network connections to other IMA servers.
8.7.12.3. Citrix Licensing Counters

The following counters are available through the Citrix Licensing performance object in Performance Monitor.
Counter
Description
Average License Check-In Response Time (ms) The average license check-in response time in milliseconds.
Average License Check-Out Response
Time (ms)
The average license check-out response time in milliseconds.
Last Recorded License Check-In

Response Time (ms)
The last recorded license check-in response time in milliseconds.
Last Recorded License Check-Out

Response Time (ms)
The last recorded license check-out response time

in milliseconds.
License Server Connection Failure
The number of minutes that the XenApp server has

been disconnected from the License Server.
Maximum License Check-In Response Time
The maximum license check-in response time in milliseconds.
Maximum License Check-Out Response Time
The maximum license check-out response time in milliseconds.
8.7.12.4. Citrix MetaFrame Presentation Server Counters

The following counters are available through the Citrix MetaFrame Presentation Server performance object
in Performance Monitor.
Counter
Description
Application Enumeration/sec
The number of application enumerations per second.
Application Resolution Time (ms)
The time in milliseconds that a resolution took to complete.
Application Resolutions Failed/sec
The number of application resolutions failed per second.
Application Resolutions/sec
The number of resolutions completed per second.
DataStore Connection Failure
The number of minutes that the XenApp server has been

disconnected from the data store.
DataStore bytes read
The number of bytes read from the data store.
DataStore bytes read/sec
The number of bytes of data store data read per second.
DataStore bytes written/sec
The number of bytes of data store data written per second.
DataStore reads
The number of times data was read from the data store.
DataStore reads/sec
The number of times data was read from the data store per second.
DataStore writes/sec
The number of times data was written to the data store per second.
DynamicStore bytes read/sec
The number of bytes of dynamic store data read per second.
DynamicStore bytes written/sec
The number of bytes of dynamic store data written per second.
DynamicStore Gateway Update Count
The number of dynamic store update packets sent to remote

data collectors.
DynamicStore Gateway
Update, Bytes Sent
The number of bytes of data sent across gateways to remote

data collectors.
DynamicStore Query Count
The number of dynamic store queries performed.
DynamicStore Query Request,

Bytes Received
The number of bytes of data received in dynamic store query

request packets.
DynamicStore Query Response,

Bytes Sent
The number of bytes of data sent in response to dynamic store queries.
DynamicStore reads/sec
The number of times data was read from the dynamic store per second.
DynamicStore Update Bytes Received
The number of bytes of data received in dynamic store update packets.
DynamicStore Update
Packets Received
The number of update packets received by the dynamic store.
DynamicStore Update
Response Bytes Sent
The number of bytes of data sent in response to dynamic store

update packets.
DynamicStore writes/sec
The number of times data was written to the dynamic store per second.
Filtered Application Enumerations/sec
The number of filtered application enumerations per second.
LocalHostCache bytes read/sec
The number of bytes of IMA local host cache data read per second.
LocalHostCache bytes written/sec
The number of bytes of IMA local host cache data written per second.
LocalHostCache reads/sec
The number of times data was read from the IMA local host cache
per second.
LocalHostCache writes/sec
The number of times data was written to the IMA local host cache
per second.
Maximum number of XML threads
The maximum number of threads allocated to service Webbased sessions since the server restarted.
Number of busy XML threads
The number of busy threads.
Number of XML threads
The number of threads allocated to service Web-based sessions.
Resolution WorkItem
Queue Executing Count
The number of resolution work items currently being executed.
Resolution WorkItem Queue

Ready Count
The number of resolution work items ready to be executed.
WorkItem Queue Executing Count
The number of work items currently being executed.
WorkItem Queue Pending Count
The number of work items not yet ready to be executed.
WorkItem Queue Ready Count
The number of work items ready to be executed.
Zone Elections
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.
Zone Elections Won
The number of times the server won a zone election.
8.7.12.5. ICA Session Counters

The following counters are available through the ICA Session performance object in Performance Monitor.
Counter
Description
Input Audio Bandwidth
The bandwidth, measured in bps, used when playing sound in an

ICA session.
Input Clipboard Bandwidth
The bandwidth, measured in bps, used when performing

clipboard operations such as cut-and-paste between the ICA
session and the local window.
Input COM 1 Bandwidth
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.
Input COM 2 Bandwidth

Input COM Bandwidth
The bandwidth, measured in bps, used when sending data to the

client COM port.
Input Control Channel Bandwidth
The bandwidth, measured in bps, used when

executing LongCommandLine parameters of a published application.
Input Drive Bandwidth
The bandwidth, measured in bps, used when performing file

operations between the client and server drives during an ICA session.
Input Font Data Bandwidth
The bandwidth, measured in bps, used when initiating font

changes within a SpeedScreen-enabled ICA session.
Input 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.
Input LPT 1 Bandwidth
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.
Input LPT 2 Bandwidth
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 Management Bandwidth

management functions.
Input PN Bandwidth
The bandwidth, measured in bps, used by Program Neighborhood

to obtain application set details.
Input Printer Bandwidth
The bandwidth, measured in bps, used when printing to a client

printer through a client that has print spooler support enabled.
Input Seamless Bandwidth
The bandwidth, measured in bps, used for published applications

that are not embedded in a session window.
Input Session Bandwidth
The bandwidth, measured in bps, used from client to server for

a session.
Input Session Compression
The compression ratio used from client to server for a session.
Input Session Line Speed
The line speed, measured in bps, used from client to server for
a session.
Input SpeedScreen Data

Channel Bandwidth
The bandwidth, measured in bps, used from client to server for

data channel traffic.
Input Text Echo Bandwidth
The bandwidth, measured in bps, used for text echoing.
Input ThinWire Bandwidth
The bandwidth, measured in bps, used from client to server

for ThinWire traffic.
Input VideoFrame Bandwidth
The bandwidth, measured in bps, used from client to server traffic

on a virtual channel.
Latency - Last Recorded
The last recorded latency measurement for the session.
Latency - Session Average
The average client latency over the lifetime of a session.
Latency - Session Deviation
The difference between the minimum and maximum measured

latency values for a session.
Output Audio Bandwidth
The bandwidth, measured in bps, used for playing sound in an

ICA session.
Output Clipboard Bandwidth
The bandwidth, measured in bps, used for clipboard operations

such as cut-and-paste between the ICA session and the local window.
Output COM 1 Bandwidth

Output COM 2 Bandwidth

Output COM Bandwidth
The bandwidth, measured in bps, used when receiving data from

the client COM port.
Output Control Channel Bandwidth
The bandwidth, measured in bps, used when

executing LongCommandLine parameters of a published application.
Output Drive Bandwidth
The bandwidth, measured in bps, used when performing file

operations between the client and server drives during an ICA session.
Output Font Data Bandwidth
The bandwidth, measured in bps, used when initiating font

changes within a SpeedScreen-enabled ICA session.
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.
Output LPT 1 Bandwidth

client printer attached to the client LPT 1 port.
Output LPT 2 Bandwidth

client printer attached to the client LPT 2 port.
Output Management Bandwidth

management functions.
Output PN Bandwidth
The bandwidth, measured in bps, used by Program Neighborhood

to obtain application set details.
Output Printer Bandwidth
The bandwidth, measured in bps, used when printing to a client

printer through a client that has print spooler support enabled.
Output Seamless Bandwidth
The bandwidth, measured in bps, used for published applications

that are not embedded in a session window.
Output Session Bandwidth
The bandwidth, measured in bps, used from server to client for

a session.
Output Session Compression
The compression ratio used from server to client for a session.
Output Session Line Speed
The line speed, measured in bps, used from server to client for
a session.
Output SpeedScreen Data

Channel Bandwidth
The bandwidth, measured in bps, used from server to client for

data channel traffic.
Output Text Echo Bandwidth
The bandwidth, measured in bps, used for text echoing.
Output ThinWire Bandwidth
The bandwidth, measured in bps, used from server to client

for ThinWire traffic.
Output VideoFrame Bandwidth
The bandwidth from server to client traffic on a virtual

channel. Measured in bps.
Resource Shares
The total number of shares used by the session.
8.7.12.6. Secure Ticket Authority Counters

The following performance counters are available for the Secure Ticket Authority (STA).
Performance Counter
Description
STA Bad Data Request Count
The total number of unsuccessful ticket validation and data

retrieval requests during the lifetime of the STA.
STA Bad Refresh Request Count
The total number of unsuccessful ticket refresh requests

received during the lifetime of the STA.
STA Bad Ticket Request Count
The total number of unsuccessful ticket generation requests

STA Count of Active Tickets
Total count of active tickets currently held in the STA.
STA Good Data Request Count
The total number of successful ticket validation and data

retrieval requests received during the lifetime of the STA.
STA Good Refresh Request Count
The total number of successful ticket refresh requests

STA Good Ticket Request Count
The total number of successful ticket generation requests

STA Peak All Request Rate
The maximum rate of all monitored activities per second.
STA Peak Data Request Rate
The maximum rate of data requests per second during the

lifetime of the STA.
STA Peak Ticket Refresh Rate
The maximum rate of refresh requests per second during

the lifetime of the STA.
STA Peak Ticket Request Rate
The maximum rate of ticket generation requests per second

during the lifetime of the STA.
STA Ticket Timeout Count
The total number of ticket time-outs that occur during the lifetime
of the STA.
8.8. Application Streaming

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, and Windows Vista. With dual
mode streaming, target environments are 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.
8.8.1. Components for Application Streaming
The components related to a server farm that make streamed applications available 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 applications streaming, refer to the XenApp Installation Checklist
in Citrix eDocs for the supported platforms and system prerequisites.
Each of the followning functional areas presents a unique set of tasks for the administrator:
1. Licensing. Consists of the license server and License Management Console. Use the License
Management Console to manage licensing. To install Citrix Licensing, follow the instructions in
Getting Started with Citrix Licensing, located in Citrix eDocs in Licensing Your Product.
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:
Farm servers.
IMA database.
The Web Interface.
Access Management Console. Use the Access Management Console to configure and manage
the server delivery and to publish streamed applications.
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 desktops 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. XenApp Plug-in for Streamed Apps and optional XenApp Plug-in for Hosted Apps. The
XenApp Plug-in for Streamed Apps is the new name for the Streaming Client. You or your users must
install this plug-in on client devices to support streaming applications to the client desktop. When a
user runs a published application enumerated by XenApp Plug-in for Hosted Apps or through a
Web Interface site, the streaming plug-in finds the correct target in the profile on the file server, sets
up the isolation environment on the client device, and then streams the application from the profile
location to the safety of the isolation environment set up on the client device.
For known issues and workarounds for applications streaming in this product release, see the Readme for
Citrix XenApp in Citrix eDocs.
For known issues and workarounds in the XenApp plug-ins, see the Readme for Citrix XenApp Plug-in for
Hosted Apps and XenApp Plug-in for Streamed Apps in Citrix eDocs.
This diagram shows the components that make up each of these four functional areas and a general summary
of the types of tasks administrators must perform.
The components that support client-side virtualization include the XenApp server, Citrix Licensing,
Streaming Profiler workstation, file servers, Web Interface, and XenApp plug-ins.
8.8.2. 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. 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, 32bit applications can be profiled on 64-bit systems and configured to be streamed to 64-bit systems.
After you create a profile and save it to a file share in your App Hub, configure users and publish the
application for streaming using the Access Management Console. When a user launches an application
published to stream to the client, the 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:
Application Streaming FAQs for Administrators at http://support.citrix.com/article/CTX118181
Enhancing the Security of Application Streaming for Desktops at http://support.
citrix.com/article/CTX110304
Application Streaming Delivery and Profiling Best Practices 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.
8.8.2.1. 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 profilelevel 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.
Client 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. For guidelines about selecting operating systems, see
the topics for Preparing a Workstation for Profiling Applications.
In addition, refer to information about the following selection criteria for creating targets:
Service Pack Level
System Drive Letter
Operating System Language
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
client systems, which simplifies profile creation.
The criteria associated with each target is stored in a profile manifest, a .profile file, stored with the profile files.
The only requirement from the profiler regarding targets is that overlapping definitions are not permitted:
only one target in a profile can be a correct match for any client system at application launch.
An administrator can update a profile and target at any time without affecting already active executions on
client 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 Installation Checklist for XenApp.
By design, future operating systems are not supported, and the execution environment refuses to execute
an application if the client device has an unsupported operating system.
8.8.2.1.1. Service Pack Level

Updated: 2009-10-06
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:
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 Citrix offline plug-in. Refer to the System Requirements for supported platforms.
8.8.2.1.2. System Drive Letter
Updated: 2009-10-06
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.
8.8.2.1.3. Operating System Language
Updated: 2009-10-06
The following languages are supported by the profiler:
English
French
German
Japanese
Spanish
Using the English version of the profiler, create targets for the following operating system languages:
Korean
Simplified Chinese
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.
8.8.2.2. Managing Isolation Environment Rules
The XenApp Plug-in for Streamed Apps 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 client operating system resources.
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.
8.8.2.2.1. Types of Isolation Environment Rules
Use isolation environment rules to improve application compatibility when users stream applications to their
client 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
When clients 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 default 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 of the client device.
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 client 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.
Ignore Rules
This rule can define holes in the isolation environment so that an application can write to the underlying
system. There are instances when an application inside an isolation environment needs to share data with
an application outside the isolation environment. For example, 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:
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 peruser rule for C:\Documents and Settings\Windows applies.
8.8.2.2.2. Restrictions and Limitations for Rules

Updated: 2009-10-06
Consider the following restrictions and limitations when constructing or altering the rules for your
isolation environment:
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).
8.8.2.2.3. Creating Isolation Environment Rules for a Target

Updated: 2009-10-06
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:
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:
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.
8.8.2.2.4. To create an isolation environment rule
Updated: 2009-10-06
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:
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.
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.
8.8.2.2.5. To modify a rule
Updated: 2009-10-06
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:
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.
3. If necessary, modify the name of the rule.

8.8.2.2.6. Using Environment Variables to Construct Rules
Updated: 2009-10-06
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:
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
AIE_COMMON APPLICATION DATA
Common application data location
C:\Documents and
Settings\All Users\Application Data
AIE_COMMON DESKTOP
Common desktop location
C:\Documents and
Settings\All Users\Desktop
AIE_COMMON STARTMENU
Common Start menu location
C:\Documents and
Settings\All Users\Start Menu
AIE_FSINSTALL ROOT
File system install root
C:
\Program Files\Citrix\RadeCache\MyAIE
AIE_FSUSERROOT
File system user root
C:\Documents
and
Settings\Administrator\
Application Data\Citrix\RadeCache\MyAIE
AIE_METAFRAME
Installation location
C:\Program Files
AIE_NAME
Isolation environment name
MyAIE
AIE_REGINSTALL ROOT
Registry install root
HKEY_LOCAL_MACHINE \SOFTWARE\CitrixRade
AIE_REGUSER ROOT
Registry user root
HKEY_CURRENT_USER \SOFTWARE\CitrixRade C
AIE_USER APPLICATION DATA
User global application data location
C:\Documents
and
Settings\Administrator\
Application Data
AIE_USERLOCAL DATA
User local application data

location (including temporary files)
C:\Documents
and
Settings\Administrator\Local Settings\Applicatio
AIE_USERDESK TOP
User desktop location
C:\Documents
and Settings\Administrator \Desktop
AIE_USERSID
Unique security identifier for

the current user; it is
used extensively internally
for security checking.
S-1-5-2001-
AIE_USERSTART MENU
User Start menu location
C:\Documents
and
Settings\Administrator\Start Menu
8.8.2.3. Preparing a Workstation for Profiling Applications

Updated: 2009-10-06
Configure the profiler workstation to provide a run-time environment that is as close to your user
device environment as possible. For example:
If applications are streamed to user devices, the profiler workstation should be similar platforms
The profiler workstation should also include standard programs that are part of the company image,
such as an antivirus program
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:
Windows XP 32-bit and Windows 2003 32-bit
Windows XP 64-bit and Windows 2003 64-bit
Windows Vista 32-bit and Windows 2008 32-bit
Windows Vista 64-bit and Windows 2008 64-bit
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. Other than standard operating system software and
utilities, ensure the workstation is clean of other software applications, particularly any applications or files
that you intend to install in a profile. During profiling, application files that are installed locally on the
profiler workstation are ignored and, thus, are missing in the profile.
Important: Do not use the profiling workstation to store or stream applications. In addition, do not install
the plug-in used for streaming, such as the Citrix offline plug-in or XenApp Streaming Plug-in, on
this workstation.
After installing the profiler, simplify the creation or modification of profiles by setting profiling preferences.
8.8.2.3.1. Known Limitations for Profiling
Updated: 2009-10-06
Certain applications cannot be profiled, including:
Applications that include services or drivers, such as AutoCAD and IBM DB2
Other applications such as Microsoft Internet Explorer 7.0, 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.
For known issues and workarounds in this product release, see the Readmes in Citrix eDocs.
8.8.2.3.2. To install the profiler
Updated: 2009-10-06
For best results, use the Windows uninstall program to remove any previous version of the Citrix
Streaming Profiler.
For guidance about choosing a workstation on which to install the profiler, see Preparing a Workstation
for Profiling Applications.
Important: Before you install the profiler, refer to the Installation Checklist in Citrix eDocs for the
supported platforms and system prerequisites.
1. On the workstation you want to use to profile applications:
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 Web site for Downloads and locate the most current version of the
profiler and offline plug-in for application streaming.
2. Choose a language for the installer interface and complete the installation wizard.
3. After installation, restart the workstation.
8.8.2.3.3. To start the profiler
Updated: 2009-10-06
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:
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.
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.
8.8.2.3.4. 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.
8.8.2.4. 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:
Profile name
Ability for users to update applications
As you continue, choose the following client-matching criteria for the target:
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:
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 postexit scripts, add pre-launch scripts, and modify the file type association. The changes are immediately
available the next time users access the published application.
8.8.2.4.1. 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 the client uses to
identify targets. For example, do not include a version number in the profile name.
3. Select the level of user profile security you want for the profile.
4. Set at least one target operating system and language.
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.
1. 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.
2. 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.
3. If you want the client to consider the service pack level, click Set Service Pack. By default a
target matches all service packs of the operating systems it supports.
4. 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.
5. 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.
5. Choose an installation option according to the type of application or number of applications you want
to install in a target:
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.
6. 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.
7. On the Run Installer page, ensure the installation program and command-line parameters are correct.
Best Practice: Check Perform virtual restart so that after the application installer finishes, the
profiler simulates a restart. Some applications do not complete the installation until the computer
is restarted. When you click Next, instead of restarting your profiler workstation, the profiler simulates
a system restart.
Use advanced installations to select resources, including files, folders, registry settings, and
Internet Explorer and plug-ins to add to the profile.
8. 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.
9. When the application is fully launched and configured on the workstation, close the application and click
Next in the profiling wizard. After the virtual restart completes, the application is ready to run.
10. On the Run Application page, select and run the application. Close the application before clicking Next
in the profiling wizard. Best Practice: 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 preferences or options and to enable or
disable features before you publish the application. For example, you might have to disable autoupdates to prevent users from receiving unwanted messages or files on their computers.
11. 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 Access
Management Console.
12. On the Sign Profile page, sign the profile with a digital signature, if needed.
13. Click Finish to build the profile. Before clicking Finish, you have the opportunity to review
profile information and edit profile and target settings.
14. 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.
After you save your profile, use other workstations to add unique targets to the profile, if needed.
8.8.2.4.2. To install multiple applications through Advanced Install
Updated: 2009-10-06
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:

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.
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.
8.8.2.4.3. To set user profile security
The profile security setting determines whether or not files for streamed applications can be run from the
profile directory of the user. Set this level initially during profiling. To modify it later, from the Edit menu, select
Profile Properties, and from the navigation pane, select User Profile Security.
Additionally, to set a default for all profiles, from the Edit menu, select Preferences. Use the User
Profile Security tab to prevent the User Profile Security page from appearing in the profiling wizards.
Choose a security setting:
Enhanced security. Selected by default. Ensures that all executables from the profile launch from
the install root location and not from the user profile root location. This setting protects against
users running application DLLs, malicious code, Adware, spyware, and other undesirable elements on
the enterprise network. All content received during a user session is completely isolated in the user
profile root location. Administrators can easily enforce a cleanup policy to delete all session artifacts
when the user closes the application or logs off. Malicious executables or programs that rely on a
restart are neutralized because session files are isolated and, therefore, are not executed.
If enhanced security mode is on, the system specifically inhibits the ability to run code that is not
streamed from the server. Using enhanced security mode also helps prevent the execution of
malicious code inadvertently downloaded from the Internet.
Additionally, this setting prevents most product-update executables from installing updates
automatically on client devices and lets you manage the updates centrally through the wizards in
the profiler.
Note: if your testing finds that this setting does not prevent automatic updates for an application,
look for a preference to disable automatic updates when you run the application during
profiling. Alternatively, disable or uninstall the update programs manually on client devices.
Relaxed security. Permits executable files that are accessed through the profiled application to run
from the user profile root.
If you profile the application in relaxed security mode (not the default), 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 client 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. Generally, however, the administrator is the best person to evaluate updates
and decide when and how to apply those updates to the organization.
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.
8.8.2.4.4. To install Internet Explorer plug-ins

Updated: 2009-10-06
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.
8.8.2.4.5. 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.
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.
1. Use the Look in pull-down menu to select files and folders to include in the target.
2. 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.
3. 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. After you include all the files and folders the application requires, simulate a system restart by checking
Perform virtual restart (recommended).
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 file share, and publish the profile in the Access Management Console.
8.8.2.4.6. To include registry settings
Use this option to provide customized registry settings in a target.
Caution: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall
1. If you have Windows Registry Editor open, close it.

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. After saving the registry settings, simulate a system restart in the target by checking Perform
6.
virtual restart.
8.8.2.4.7. To choose an installation program for the application
Updated: 2009-10-06
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:
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 application
s 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
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
8.8.2.4.8. To run an application in the profiler
Updated: 2009-10-06
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.
8.8.2.4.9. To select applications for listing in the profile
Updated: 2009-10-06
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 console included with
your version of XenApp: Delivery Services Console or Access Management Console.
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.
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.
8.8.2.4.10. To sign a profile

Updated: 2009-10-06
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.
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.
8.8.2.5. 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 client 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.
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:
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.
User Profile Security. Specifies type of security enabled for the profile.
Pre-launch Analysis. Enables the profile to examine the client 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.
8.8.2.5.1. To view profile information

Updated: 2009-10-06
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:
Information
Targets
Applications
File Types
Digital Signatures
From the Edit menu, choose Profile Properties to view the profile properties.
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:
Information
Applications
File Types
Select the target, and from the Edit menu, choose Target Properties to view the target properties.
8.8.2.5.2. To edit the profile name, description, or location
Updated: 2009-10-06
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, elect General.
This page displays the following information about a profile:
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.
8.8.2.5.3. To view details about applications in a profile

Updated: 2009-10-06
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 console 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:
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.
8.8.2.5.4. To view File Type Associations set in a profile
Updated: 2009-10-06
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:

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.
8.8.2.5.5. To check for launch prerequisites
Updated: 2009-10-06
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
8.8.2.5.6. To check for prerequisite registry entries

Updated: 2009-10-06
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:
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:
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

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:
String value (REG_SZ)
Binary value (REG_BINARY)
DWORD value (REG_DWORD)
Multi-string value (REG_MULTI_SZ)
Expandable string value (REG_EXPAND_SZ)
QWORD value
6. When you select a type, the list updates to reflect the registry entries.
8.8.2.5.7. To check 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:
Choose the application you want to identify as a prerequisite. (Note that the list of applications is static.)
Browse to and choose the binary file you want to identify as a prerequisite.
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.
8.8.2.5.8. To specify pre-launch and post-exit scripts
Updated: 2009-10-06
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 & Postexit 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 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. 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.
8.8.2.5.9. To add a target to a profile

Updated: 2009-10-06
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.
to install in a target, and finish the wizard.
8.8.2.5.10. To resolve target conflicts
Updated: 2009-10-06
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
Boot drive C
8.8.2.5.11. To delete a folder from a profile
Updated: 2009-10-06
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.
8.8.2.5.12. To delete a target from a profile

Updated: 2009-10-06
1.
2.
3.
Start the profiler by opening the Start menu and choosing Programs > Citrix > Streaming Profiler >
Streaming Profiler.
To open the profile, from the File menu of the profiler, choose Open.
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 cabinet (CAB) files from the profile on the
file share and removes associated entries from the profile manifest.
8.8.2.5.13. To resolve invalid shortcuts
Updated: 2009-10-06
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?
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.
8.8.2.6. Editing Targets

Updated: 2009-10-07
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:
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.
8.8.2.6.1. To edit the target name and description

Updated: 2009-10-07
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.
8.8.2.6.2. To modify the application properties in the target
Updated: 2009-10-07
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:
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:
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.
8.8.2.6.3. To modify the operating system and language properties of a target

Updated: 2009-10-07
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.
8.8.2.6.4. To check for launch prerequisites for a target
By default, you define pre-launch analysis for a profile and all its targets. If, after testing a profile, you
determine that a target requires pre-launch analysis or analysis that is different from the default for the
profile, enable pre-launch analysis for the target.
To check for prerequisites on a user device before starting an application for the selected target, from the Edit
menu, select Target Properties and use the Pre-launch Analysis page to specify prerequisites:
1. Clear the Use profile settings check box.
2. Select the Enable pre-launch analysis check box.
3. Specify the type of prerequisites using the Add Item button.
8.8.2.6.5. To specify pre-launch and post-exit scripts for a target
By default, you define scripts for a profile and all its targets. If, after testing a profile, you determine that a
target requires scripts that are different from the default for the profile, enable scripts for the target.
To override the default profile-level scripts and use different scripts that you design specifically for a
particular target, from the Edit menu, select Target Properties and use the Pre-launch & Post-exit Scripts
page.
1. Clear the Use profile scripts check box.
2.
Click Add Item to specify the pre-launch or post-exit scripts and command-line parameters for the scripts.
8.8.2.6.6. 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, clients 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.
to install in a target.
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 client devices
connect, they stream the updated profile.
8.8.2.6.7. To remove an old version of an updated target
Updated: 2009-10-07
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 CAB file.
The trailing integers of the CAB file name represent the target version number. For example, the version
of the following file is 2:
\\hostname\fileshare\Profile Name\720edd68-0972-49e6-aa00-80974eb81d5b_2.cab
To choose CAB files that are obsolete, identify the ones that have trailing integers of the least value.
3.
Use Windows Explorer to delete the obsolete CAB file from the profile on your file share.
8.8.2.7. Profile Contents on the Server

Updated: 2009-10-07
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:
Profile manifest file (.profile), an XML file that defines the profile
Target CAB files 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:
PDF Viewer.profile (the manifest file)
720edd68-0972-49e6-aa00-80974eb81d5b_1.cab (the target CAB), first version
Hashes.txt
Icondata.bin
Scripts folder
8.8.2.7.1. Manifest File

Updated: 2009-10-07
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:
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.
8.8.2.7.2. Targets
Updated: 2009-10-07
Each target consists of a cabinet file (CAB file) representing a compressed subdirectory structure within the
profile structure.
Target CAB 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.
8.8.2.7.3. Digital Signature
Updated: 2009-10-07
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 same process is conducted for all of the profile level files. The SHA 1 of the Hashes.txt file at the profile
level is stored in the manifest, and the SHA 1 of each target in the profile is stored in the manifest. Because
the manifest file is digitally signed, the SHA 1 of each file listed in each Hashes.txt file can be authenticated.
8.8.2.7.4. Icons
Updated: 2009-10-07
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.
8.8.2.7.5. Scripts
Specify when the XenApp Streaming Plug-in should execute scripts associated with a profile or target:
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 postexit scripts independent of the profiler, and after creating a script, use the profiler to add the script to a
target, including these settings:
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 client 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.
8.8.3. Managing Streamed Applications
Updated: 2010-03-05
After you create profiles for streaming applications using the Streaming Profiler, you make them available
to users by publishing the applications.
The Publish Application wizard in the console installed with your version of XenApp (Delivery Services Console
or Access Management Console) 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.
8.8.3.1. Publishing Streamed Applications
Before publishing a streamed application, 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 in your App Hub.
An integral function of XenApp is to make profiled applications available to users. When you publish
an application, you also make choices about the application properties. Use the Publish Application wizard in
the Access Management Console to publish streamed applications in your farm.
As you publish the application, choose how to deliver streamed applications. Use the application
streaming options to stream profiled applications to the server or the client desktop.
Important: To launch streamed applications, client devices must have sufficient RAM locally.
8.8.3.1.1. Streaming Applications to Client 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.
Before publishing an application to be streamed to client desktops, complete the following tasks:
Install the XenApp Streaming Plugin locally, where it runs in the background to enable application streaming
To allow offline access, install the latest version of XenApp Hosted 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 on each server as Streamed to client.
8.8.3.1.2. Accessing Applications from 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 client desktops.
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:
Remote applications only
Dual mode streaming (streamed if possible, otherwise accessed from a server)
Important: For users to stream applications through a Web Interface site using an Internet Explorer or
Firefox browser, you must add the site to the Trusted sites list in Internet Explorer.
For information about managing application types on Web Interface sites, see the Web Interface Administrator
s Guide.
After you ensure all of these tasks are complete, publish the application on XenApp to stream to a server.
8.8.3.1.3. To publish an application for streaming
Steps and options in the wizard vary depending on the application type you select. This procedure describes
the basic options available for streamed applications.
Important: Before you begin, refer to Getting Started with Citrix XenApp to review the new and
discontinued features for publishing applications on XenApp for Windows Server 2008.
Additionally, refer to the Installation Checklist for supported platforms and system prerequisites.
1. Under the XenApp node of the Access Management Console, expand the farm to which you want
to publish an application.
2. Select the Applications node and from the Common Tasks pane, choose New > Folder. Create a
folder for the application you are publishing.
3. Select the folder you created and from the Common Tasks pane, choose New > 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 clients devices when users access
the application and on the Access Management Console for the farm applications. Note that all
applications enabled for offline access must have unique names across all farms.
5. On the Type page:
Select Application.
Select the delivery method.
6. On the Location page:
Browse to the application profile on the file share where the .profile file is stored or type the
UNC path to the .profile file; for example: \\citrixserver\profiles\Adobe Reader\Adobe Reader.profile.
After you select a profile, the application drop-down list is populated with the applications in
the profile.
From the drop-down list, select the application to publish.
Optionally, create alternate profiles for specific IP ranges.
7. On the Servers page, add the servers on which the published application runs when accessed by an
ICA connection.
8. For applications configured to stream to clients only, the wizard continues with the Offline Access page
on which you specify whether or not users can run the published application in offline mode.
If you enable the application for offline access:
Specify how you want the plugin to cache the necessary application files on the client device:
at logon or at launch.
Click Configure Offline Access Users to open the farm property for Offline Access > Users
and create the Configured users list of users and groups that have permission to run
enabled applications in offline mode. Alternatively, configure this list later in the farm properties.
9. On the Users page, create the Configured users list for users or groups who have access to
the application.
10. On the Shortcut presentation page, select the icon for the application and choose how the application
is enumerated on the client device. .
11. On the Publish immediately page, choose whether or not to make the published application
immediately available to users.
11.
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
12. To view and select advanced options, check Configure advanced application settings now. Note
that the available options depend on your delivery type. Alternatively, modify the advanced settings
later using the application properties.
When you finish, published applications (unless disabled) are available for users.
8.8.3.1.4. To select a streaming delivery method
You select the resource type initially in the Publish Application wizard. To change the resource type, from the
Action menu, select All Tasks > Change application type and follow the instructions in the wizard.
1. In the Publish Application wizard, on the Type page, select Application.
2. Select a delivery method from the Application type list:
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.
From the Server application type list, select the delivery method:
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.
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 client
devices and launches locally from within an isolation environment. Alternatively, client devices
that do not support streamed applications; for example, if the XenApp Plugin for Streamed Apps
is not installed, instead use an ICA connection to access the application installed on or
streamed from a XenApp server.
From the Server application type list, select the alternative delivery method for clients that do
not support streaming to client:
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.
Streamed to client. Grants users access to a profiled application that streams from the file share
to their client desktops and launches locally from within an isolation environment. With this
option, the application uses client resources instead of server resources. Users must have
the XenApp Plugin for Streamed Apps installed and access the application using XenApp Plugin
for Hosted Apps or a Web Interface site.
If selected, client devices that do not support client-side application virtualization (such as, they
use a non-Windows client) or do not have the XenApp Plugin for Streamed Apps installed
locally cannot launch the application.
8.8.3.1.5. To specify a farm-wide policy for delivery

Updated: 2010-03-05
Use 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.
1.
2. Under the farm name, select Policies.
3. From the Actions menu, select New > Policy, name the policy, and click OK.
4. Open the properties by selecting the policy name and from the Actions menu, select Properties.
5. In the Properties dialog box, expand User Workspace > Streamed Applications >
Configure delivery protocol.
6. Click Enabled and select an option:
Force server access (selected by default). 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:
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.
Force streamed delivery. Client devices always stream the application from the file share
location to the client desktops. Users must have the XenApp Streaming Plug-in installed and
access the application using the XenApp Hosted Plug-in or a Web Interface site. For example,
you might use this setting to prevent the use of server resources.
If you disable the rule or do not configure it, the delivery method specified in the Publish Application wizard
is used.
This table describes the default delivery of each application type and the results of setting the policy. The
policy overrides the delivery protocol for applications that are published as streamed to client.
Application type
No policy (default delivery)
With policy:
Force
server access
With policy:
Force
streamed delivery
Streamed to client
XenApp Streaming Plug-in

streams application from file share
to desktop.
Connection fails
Connection works
Accessed from a server:
XenApp Hosted Plug-in virtualizes

the application installed on
XenApp (not streamed).
Policy does
not apply
Policy does
not apply
Streamed to server
XenApp Streaming Plug-in

streams application from file share
to XenApp and any XenApp
Hosted Plug-in virtualizes
the application from XenApp.
Policy does
not apply
Policy does
not apply
Streamed if
possible;
otherwise
accessed from a
server (dual mode):
Dual mode:XenApp Streaming Plugin streams application from file

share to desktop.
XenApp
Hosted Plugin always
connects
to
application
installed on server
XenApp
Streaming Plugin always
streams
application
to desktop
XenApp
streams
application
to XenApp
XenApp
streams
application
to desktop
Installed application
Installed application
Streamed to server
Otherwise, any XenApp Hosted Plugin virtualizes the application

from XenApp.
Dual mode:XenApp Streaming Plugin streams application from file
share to desktop.
Otherwise, application streams
from file share to XenApp and
any XenApp Hosted Plug-in
the application from XenApp.
8.8.3.1.6. To enable event logging and a trust relationship to the client

Use the Access Management Console to enable logging for application streaming events and set a
trust relationship for the client. From the Action menu, select Modify farm properties > Modify all properties
. From the Properties list, select Farm-wide > Application Streaming.
Click Log application streaming events to the event log to enable streaming and client events to
be added to the Event log.
Click Trust XenApp Plugin for Streamed Apps to allow administrators to reestablish an
interrupted client session for the same application after the network connection is restored, without
asking for user credentials again. If trusted, users do not notice the network failure or disruption
while using applications.
8.8.3.2. Configuring Offline Access

Administrators can configure applications that are published to stream to desktops so that users can
disconnect from the company network and continue to run the applications in offline mode for a specified
length of time. This capability is referred to as offline access.
When you configure a streamed application for offline access, the next time the client device connects to
XenApp, the XenApp Streaming Plug-in downloads the application and caches it on the client device.
Important: Before you configure offline access, refer to the Installation Checklist for Citrix XenApp for
the supported platforms and system prerequisites for client devices.
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.
To enable the offline access feature, applications configure the following settings using the Access
Management Console:
Configure the farm-wide properties for offline access.
Configure users for offline access permission
Set the license period for offline users
Configure the application properties for offline access.
Enable the application for offline access
Configure users for access to the application
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 client desktop to enable offline access
of that application. For example, to stream Microsoft Outlook to the client desktop for offline access, users
must enable the Microsoft Exchange Setting to "Use Cached Exchange Mode."
Users who have offline access permission for the farm and permission to access the published application
must launch the application through Citrix XenApp to use the offline access feature. This means that users
must install both the XenApp Streaming Plug-in and the XenApp Hosted Plug-in on the client device.
The XenApp Streaming Plug-in caches each streamed application on the hard drive of the client workstation.
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.
You do not need to do any additional configuration in the streaming profiler to create application profiles
or targets with applications that can be accessed offline. Save the profiles to a network file share or Web
server so they are available for publishing using the Access Management Console.
Administrators must create a list of users who have offline access permission. This list can be completed
during publishing or later in the farm properties. Users or groups listed in this farm property (and who are
also configured for the application) have permission to run offline-enabled applications in offline mode.
Users or groups on this list use an offline license to launch applications regardless of whether they are online
or offline.
Note: You must add the users to the configured users list for the applications that they can access
offline. Users who are configured for the application in this wizard, but who are not added to the
configured users list for offline access in the farm, can access the application online but not offline.
8.8.3.2.1. To set the license period for offline users
The license specifies the time period that users can run streamed applications before they must renew the license.
1. From the Access Management Console, select the farm.
2. Under Common Tasks, select Modify farm properties > Modify all properties. From the
Farm Properties dialog box, select Offline Access > Offline License Settings.
3. Set the license period. The license period, 21 days by default, can range from 2 to 365 days. This
number specifies the number of days that users can run the application both online and offline before
they have to renew the license.
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. For more information, in the topics for Licensing Your Product, see Getting Started
with Citrix Licensing.
8.8.3.2.2. To renew offline licenses
When users with offline access log on to Citrix XenApp, they automatically either check out an offline license
or renew a license already checked out.
Licenses extend for the specified license period, set in the farm property for Offline License Settings.
If users stay logged on to Citrix XenApp, 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 to Citrix XenApp (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, online or offline.
8.8.3.2.3. Indirect Membership to the Offline Access User List

You might give users indirect permission for offline access by making them members of groups or subgroups
that have offline access.
For example, if you add Group A to the offline user list, and User 1 is a member of Group A and is also added
to the application user list, User 1 has offline access for the application.
A user who is in the application user list and is also a member of a group that has offline access
permission, indirectly has offline access to the application.
Specify subgroups of larger groups for indirect access. For example:
Group A contains Subgroups B and C

Users of Subgroup B have farm-wide permission for offline access
Group A has permission for access to the application
With this grouping, only members of Group B can access the application offline or online (even though Group B
is not explicitly added to the application user list), while Group C can access the application only when online.
Users in subgroups have their own access permissions as well as the indirect access permissions of any groups
or subgroups to which they belong.
8.8.3.2.4. Experiencing Offline Access
When users who are configured for a streamed application and have offline access permission run an
offline-enabled application, they automatically check out an offline license (or renew a currently held license).
In addition, applications download to users depending on the caching preference set for the farm:
If you configured pre-caching at logon (selected by default), a notification message tells the users
when the download starts and completes. After the download finishes, users can disconnect from
Citrix XenApp and run the cached applications in offline mode until the period of time elapses.
If you configured caching at launch, users must launch the application while connected to the
network (online mode). After the download finishes, users can disconnect from Citrix XenApp and run
the cached application in offline mode until the period of time elapses.
When users are offline, application shortcuts appear as available if the license is still current or unavailable if
the offline license expired (these applications cannot launch).
To review the status of their cached applications, users can right-click the Citrix XenApp icon in the
notification area and select Offline Applications. The list includes the offline applications with their
download status, total offline license period, and number of days remaining before the check-out period ends.
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 to Citrix XenApp (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, online or offline.
8.8.4. Managing the XenApp Streaming Plug-in
The XenApp Streaming Plug-in is the component of the application streaming feature that provides clientside application virtualization. After you or users install the plug-in on their client devices, it runs as a service
in the background, invisible to users, to provide the streaming functionality and access published resources.
Before installing or configuring the plug-in, administrators should know the following information:
The server farm to which client devices connect
The operating systems on the client devices
When you publish profiled applications for streaming, the method you select determines the type of
additional components your users need to access the applications.
Important: For users to stream applications through a Web site using an Internet Explorer or Firefox
browser, you must add the site to the Trusted sites list in Internet Explorer on the client devices.
Either of the following combinations is available with the application streaming feature:
XenApp Streaming Plug-in and XenApp Hosted Plug-in. Install both the client-side and server-side plugins on client devices to make available the full set of application streaming features. Installing both the
XenApp Streaming Plug-in with the XenApp Hosted Plug-in enables you to enumerate published applications
in the desktop Start menu and create shortcuts on the desktop. Use this combination to stream
applications directly to client desktops. In addition to desktop integration, XenApp Hosted Plug-in also
enables users to go offline with published applications.
The XenApp Hosted Plug-in is centrally administered and configured in the Access Management Console using
a Citrix XenApp site created in association with a site for the server running the Web Interface. For
information about installing and configuring the plug-in for hosted applications, see the topics for XenApp
Hosted Plug-in.
XenApp Streaming Plug-in with a Web browser. Install the client-side plug-in and the XenApp Web Plugin on client devices to access published applications through a Web browser using the Web Interface site
you create. For information about installing and configuring the Web plug-in, see the topics for XenApp
Hosted Plug-in.
For this access method, the XenApp Hosted Plug-in is not required on the client device. Note that offline access
to applications and desktop integration are not available when using this access method.
8.8.4.1. XenApp Streaming Plug-in Overview
The XenApp Streaming Plug-in is the new name for the Streaming Client. The plug-in runs as a service on
the client device to invoke applications the user selects and applications enumerated by XenApp Hosted Plug-in
or the Web Interface site. The streaming plug-in finds the correct target in the profile in the App Hub, sets up
the isolation environment on the client device, and then streams the application from the profile location to
the safety of the isolation environment set up on the client device.
The 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 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 client devices, install the plug-in with a digital certificate. The plugin then streams applications only from profiles that match the digital certificate.
The plug-in also checks the cache size of the client device. If the cache size exceeds a maximum limit, the plugin 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 plug-in removes
streamed application files starting with the one that was not used for the longest time.
Finding the Version of the Plug-in
To identify the version of your installed plug-in, open the Windows program to 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 Streaming Profiler and XenApp Streaming Plug-in. If upgrading is not possible, this
release provides limited backward compatibility for Streaming Clients 1.1x. The current plug-in supports
profiles created with Streaming Profiler 1.1.
8.8.4.2. Managing the XenApp Streaming Plug-in
The Citrix installation media contains installation files for all the Citrix XenDesktop Server and XenApp plug-ins
in the Clients directory. The latest plug-ins are also available from the Citrix download site.
The XenApp Streaming Plug-in installer deploys drivers and requires administrator privileges on the client
devices. For those users who have administrator privileges on their computers, make the plug-in
installer XenAppStreaming.exe available, and they can install it themselves. The plug-in installer does not
require any configuration during installation.
To take advantage of continuing improvements in the profiler, when you upgrade to the latest streaming plugin, also upgrade to the latest Citrix Streaming Profiler and either update your existing applications or reprofile the applications in the new profiler.
In addition, Citrix provides command-line utilities and transforms with the XenApp Streaming Plug-in to
perform actions on client devices.
8.8.4.2.1. To install the XenApp Streaming Plug-in
The XenAppStreaming.exe installer (formerly an .msi file) includes the Microsoft Visual C++ 2005
Redistributable Package and improvements for Microsoft Office applications.
Important: Before you install the plug-in, refer to the Installation Checklist for Citrix XenApp for the
supported platforms and system prerequisites.
After installation, restart the computer to start the streaming services and ensure that other applications and
plug-ins detect the streaming plug-in.
For best results, use the Windows uninstall program to remove any previous version of the streaming plugin. Close all running programs before starting the installer.
Note that on Microsoft Windows Server 2003 or 2008, Active Directory manages resources across the
domain. These computers can handle only .msi files, not .exe files.
1. From the installation media or Citrix download site, navigate to Clients > Streaming and run
XenAppStreaming.exe, or if needed, XenAppStreaming.msi.
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.)
4. After the Welcome screen, accept the license agreement and continue with the installation wizard.
5. After you finish the installation, restart the computer.
After installing the plug-in and restarting the client device, the Citrix Streaming Service starts automatically
and runs in the background as the user Ctx_StreamingSvc.
Restarting the client device also ensures that other applications and plug-ins detect the streaming plug-in.
8.8.4.2.2. To configure the cache size of the streaming plug-in
When you run a streamed application either through XenApp Hosted 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
client 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 plugin 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 client 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 XenApp Streaming 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 client cache take effect the next time you start the plug-in or restart the
Citrix Streaming Service.
8.8.4.2.3. To deploy the XenApp Streaming Plug-in
To deploy the XenApp Streaming Plug-in to client 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 XenAppStreaming.exe file and extract the XenAppStreaming.msi file:
[path]/XenAppStreaming.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 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 client device following the installation.

/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:
XenAppStreaming /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\XenAppStreaming.exe /C /T:c:\Documents
and Settings\Administrator\Desktop\Streaming Client
To run a silent install with no options: path\XenAppStreaming.exe /C:setup /qr
To add some options: path\XenAppStreaming.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\XenAppStreaming.exe /C:setup /qr INSTALLDIR=
C:\Program Files\Citrix\Streaming Client /norestart /l c:\Log Files\streaming.log TRANSFORMS=
C:\some_transform.mst
8.8.4.2.4. To configure an .MSI package 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 XenAppStreaming.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
8.8.4.2.5. To deploy the XenApp Streaming Plug-in to client 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 XenApp Streaming Plug-in on these client 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:
1.
XenAppStreaming.exe /C /T:[fileshareDirectory]
where the fileshareDirectory is the UNC path to a shared folder that is accessible to all the domain
client devices on which you will install the plugin.
2. From a computer in the domain:
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.
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 XenAppStreaming.exe, including installing the
XenApp Streaming Plug-in, starting the Citrix Streaming Service, and adding the Microsoft Visual C++
2005 Redistributable Package on all client devices in the domain.
8.8.4.2.6. To deploy applications to client devices
Citrix recommends that administrators deploy the applications used most frequently by end users.
Deployment pushes new or updated application files to client devices and helps avoid overloading the file
servers or network. The utility enables administrators to schedule deployment overnight or during off hours.
The XenApp Streaming 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 client device that has the XenApp Streaming 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 client 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
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.
3. Set your options as needed, including the following parameters:
/enum enumerates the applications currently deployed on the client device.
/deploy adds the profiled application on the client device.
/delete removes the profiled application from the client device.
-m monitors the deployment until complete.
-p deletes the application profile from the client device. Note that this command also removes
any other applications deployed on the client device from this application profile.
4. Repeat for other applications, as needed.
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.
8.8.4.2.7. To clear the streamed application cache on user devices
Updated: 2009-08-31
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 [/?]
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:

/? 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
/flushall clears the registry and files in both the install root and user root for all
streamed applications
3. Repeat for other applications, as needed.

This method affects only the local user device.
8.9. Enterprise Management
This section of Citrix eDocs contains references to XenApp components and features that help you manage
and maintain your servers and farms. These references are applicable to servers running Citrix
Presentation Server 4.5 or XenApp 5.0 for Microsoft Windows Server 2003.
Management Pack for Microsoft Operations Manager 2000
Management Pack for Microsoft Operations Manager 2005
XenApp Provider for Windows Management Instrumentation (WMI)
Installation Manager for Citrix Presentation Server
Network Manager for Citrix Presentation Server
Resource Manager for Citrix Presentation Server

The Management Pack for Microsoft Operations Manager 2000 helps system administrators monitor the
health and availability of their Citrix Presentation Server 4.0 and 4.5 servers and farms.
This topic references the current version of the Management Pack Administrator's Guide. To view, search,
and print the documentation, you need Adobe Reader 5.0.5 or later with Search. You can download Adobe
Reader for free from the Adobe Systems Web site at http://www.adobe.com.
Management Pack Administrator's Guide
Welcome to the Citrix XenApp Management Pack for Microsoft Operations Manager (MOM) 2005, for Citrix
XenApp 5.0.
This document uses the following abbreviated product names:
The Citrix XenApp Management Pack for Microsoft Operations Manager 2005 is referred to as the
Management Pack.
The Citrix XenApp Provider for Microsoft Windows Management Instrumentation is also referred to as the
XenApp Provider or simply the Provider .
The Citrix XenApp Licensing Provider is referred to as the Licensing Provider.
MOM is a management solution for Microsoft Windows server deployments. MOM collects, filters,
analyzes, responds to, and reports on information about computersall from a single view on a desktop
console. System administrators can use MOM for performance monitoring, event management, alerting
and reporting, and trend analysis.
MOM also includes an extensive product support knowledge base, with links to Knowledge Base articles on
the Microsoft Web site, that provides system administrators with centralized access to the information
they require to manage a complex enterprise environment.
By providing administrators with a live view of critical events, together with links to Microsoft Knowledge
Base articles and other related information, MOM helps administrators and network support specialists
identify trends and troubleshoot problems occurring on servers and applications across the network .For
more information about MOM, see Microsofts Web site: http:://www.microsoft.com.
The Management Pack is a plug-in to MOM that enables system administrators to monitor the health
and availability of servers and server farms, and anticipate and react quickly to problems that may occur.
The Management Pack interprets and reports on information supplied by:
The XenApp Provider that runs on servers
The Licensing Provider that runs on license servers
System events generated on servers
The Management Pack provides system administrators with real-time event and performance monitoring
of servers and server farms from the MOM Operator Console. The Management Pack also includes its
own extensive knowledge base, with links to Citrix Knowledge Center articles, that administrators can use
to interpret events and troubleshoot problems.
8.9.2.1. Management Pack Features
This topic describes the key features and benefits of using the Management Pack in your XenApp deployment.
Event management. The Management Pack captures a variety of events from servers and server
farms. These events are collated and then presented through the MOM Operator Console, allowing
an overall view of server operation.
Performance monitoring. 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 enables you to quickly interpret events and troubleshoot problems.
Customizable rules and alerts. You can configure the Management Pack to alter how it responds to
an event. You do this by modifying and extending the rules to best suit your environment. Citrix
Knowledge Center documentation is available to help you with this customization.
Farm-wide alerts. Farm-wide alerts are available for servers running Presentation Server 4.0
or Presentation Server 4.5. They are raised against the primary farm metric server for each farm. All
the primary farm metric servers in your deployment are included automatically in the Citrix Farm
Metric Servers computer group.
Important: Farm-wide alerts are not raised on XenApp 5.0 servers.
Citrix views. Citrix views are available in the Public Views 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.
Deployment Topology view. The Management Pack contains a MOM Diagram view that displays
a topological diagram of your Citrix deployment. This view shows a hierarchical representation of
the deployments farms, zones, and servers, and the relationship between them.
State view. The Management Pack supports the MOM State view. When you import the Management
Pack into MOM, two new roles are added to the State view: Citrix Server and Citrix Licensing. The
Citrix Server role monitors XenApp servers. The Citrix Licensing role monitors Citrix license servers.
Citrix notification group. The Management Pack includes a notification group, called the
Citrix Administrators group. You can configure this group to ensure that the appropriate people are
notified about problems with servers and server farms.
Easy Installation. The Management Pack consists of a single file that is available on the
XenApp installation media. To install the Management Pack, import this file into MOM, using the
MOM Administrator Console.
8.9.2.2. The Management Pack and the Providers

The Management Pack requires the XenApp Provider to be installed on every XenApp server about which
you want to gather information.
The XenApp Provider is a data provider that extracts information about the server on which it is installed
and presents this to the MOM 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 server(s). Ensure
that you add the license server to the list of XenApp managed computers in MOM.
The Licensing Provider is a data provider that runs on the license server and supplies information about
Citrix licenses. The Management Pack interprets and reports this information. For example, it displays
information about the number of licenses in use for each license pool, and it 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 further information about installing the XenApp Provider and
the Licensing Provider, see Managing Providers and WMI.
For more information about Windows Management Instrumentation (WMI), see Microsofts Web site http:
//msdn.microsoft.com/.
8.9.2.3. Citrix Views in the Management Pack
The Management Pack includes a number of Citrix views that are available in the Public Views folder on the
MOM Operator Console. 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.
There are four main types of Citrix views:
Health Monitoring
Discovery
Deployment Topology
State
The processing rules that define how MOM collects, processes, and responds to information, and that generate
the Citrix views, are in the Management Packs\Rule Groups\Citrix Rules folder in the MOM Administrator
Console. You can configure these rules and create new ones.
Important: After you install the Management Pack, some Citrix views may be empty until 3:55 A.M. the
next day. By default, 3:55 A.M. is the time that certain data is collected by the Management Pack. This
data includes farm and zone membership information, product version, and hotfix information. However,
you can change the time this information is gathered by modifying the appropriate rules.
8.9.2.3.1. Health Monitoring Views
Health Monitoring views provide real-time event and alert information, together with performance
monitoring details about servers and server farms.
View
Description
Events
Displays all the events raised by XenApp components

on managed servers.
Open Alerts From Citrix Servers
Displays all unresolved alerts raised against managed servers

by all management packs (not only the Citrix
XenApp Management Pack).
Open Citrix Alerts
Displays all unresolved alerts raised by the Management Pack.
Active Sessions
Displays the number of active sessions on each managed server.
Published Application Load From

Load Balancing
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. For more
information about Load Manager, see the Load
Manager documentation.You must also enable the
Sample published application load from load balancing
rule; see Sample Published Application Load for
more information.
Server Load From Load Balancing
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.
Pooled Licenses In Use
Displays the number of pooled licenses in use, as a percentage

of the total number of pooled licenses. Note that in releases
prior to MetaFrame Presentation Server 3.0, after you install
the Management Pack, this view is empty until 3:55 A.M.
the next day.
8.9.2.3.2. Discovery Views

Discovery views provide an overview of the structure of your deployment, together with information
about individual servers.
View
Description
Managed Citrix Servers
Displays all managed servers in the Citrix XenApp Managed

Computers computer group.
Unmanaged Citrix Servers
Displays all servers in the Citrix XenApp Unmanaged

Computers computer group.
Product Versions
Displays information about the XenApp software versions on

each managed server. After you install the Management Pack, this
view is empty until 3:55 A.M. the next day.
Hotfixes
Displays information about the XenApp hotfixes installed on

each managed server. After you install the Management Pack, this
view is empty until 3:55 A.M. the next day.
Computer Groups
Displays all configured farm and zone computer groups.
Farm and Zone Membership
Displays farm and zone information for each managed server. After
you install the Management Pack, this view is empty until 3:55 A.M.
the next day.
8.9.2.3.3. Deployment Topology View

The Deployment Topology view is a MOM Diagram view that provides a hierarchical representation of a
Citrix deployment, showing farms, zones, managed and unmanaged servers, and the relationships between
them. This view is available only under the MOM Administrator scope.
Diagram showing a Deployment Topology view

The following table lists the Citrix-specific icons used in the topology view and their meanings:
Icon Meaning
Server farm
Farm metric server
Zone data collector
Zone
The topology view provides the following information:

The name of the farm, zone, or server. Zone names are prefixed by their farm names.
For managed servers, the current alert state.
Whether a server is a zone data collector or a farm metric server.
Tooltips are used to provide the following additional information:
Computer domain and name
IP address
Status
XenApp version number
Role (zone data collector or farm metric server)
The name of the license server the computer uses
Logons enabled or disabled
By default, this view uses the MOM Tree layout. However, if your deployment has over 20 servers, you
might not be able to see all your servers using this layout. To change to a layout that enables you to see all
your servers but does not display them hierarchically, change the views Node Placement Style property
to Undirected.
8.9.2.3.4. State View: the Citrix Server and Citrix Licensing Roles
For each managed server, the MOM State view displays the roles the computer has and the alert status for
each role.
The Management Pack adds two roles to the State view: Citrix Server and Citrix Licensing.
Citrix Server Role
The Citrix Server role monitors every managed server. This role has five subcomponents, each monitoring
a different set of alerts:
Subcomponent
Alerts
Connections
Session and connection limit.
Client update
Client update. This alert is not raised for servers running Presentation Server
4.5 or XenApp 5.0 because auto client update is not available with these versions.
IMA
IMA, including alerts related to zone election.
Printing
Client printer.
RM
Farm-wide alerts, which are all Resource Manager alerts. Farm-wide alerts
are not raised on XenApp 5.0 servers.
Citrix Licensing Role

The Citrix Licensing role monitors every managed server that is running the Licensing Provider. This role has
just one subcomponent, State, which represents the overall state of the license server and its licenses.
Subcomponent Alerts
State
License expires soon.

Subscription Advantage expires soon.
Subscription Advantage expired.
Low on available licenses.
Out of available licenses.
8.9.2.4. XenApp Managed and Unmanaged Computers

In the Management Pack, a XenApp managed computer is a server that is running one of the following with
an appropriate license:
MetaFrame XP Enterprise Edition, Feature Release 2
MetaFrame XP Enterprise Edition, Feature Release 3
MetaFrame Presentation Server 3.0, Enterprise Edition
Citrix Presentation Server 4.0, Enterprise Edition
Citrix Presentation Server 4.5, Enterprise or Platinum Edition
Citrix XenApp 5.0, Enterprise or Platinum Edition
Servers running Presentation Server 3.0 or later are fully supported as managed servers. Servers
running MetaFrame XP Enterprise Edition, Feature Release 2 or Feature Release 3 might be present in the list
of managed servers, but you might find that not all the documented features are available or fully functioning.
Important: After licenses are allocated, XenApp computers might not be recognized as managed until the
next time Attribute Discovery runs. By default this happens every 60 minutes.
A XenApp unmanaged computer is a server running:
MetaFrame XP Advanced Edition
MetaFrame XP Standard Edition
MetaFrame XP Enterprise Edition without the XenApp Provider and an appropriate license
8.9.2.5. About Citrix Computer Groups

The Management Pack includes a number of Citrix computer groups that are available in the
Management Packs\Computer Groups folder in the MOM Administrator Console.
These groups are described in the following table.
Group
Description
Citrix All Managed Servers in All

Farms in All Zones
Allows you to configure MOM to recognize the farms and zones

in your deployment. This means you can display and monitor
servers by farm or zone.
Citrix Topology Discovery Computers
Specifies the servers on which the topology discovery script runs.

You must specify at least one server from each farm. For
more information about topology discovery, see Configuring
Topology Discovery.
Citrix Zone Data Collectors
Specifies the zone data collectors for your deployment. This group
is populated automatically.

Managed Computers
Allows you to specify which servers you want to monitor using

MOM. A managed server must be a server that is running a version
of XenApp listed in XenApp Managed and Unmanaged Computers
, with an appropriate license. The server must also be running
the XenApp Provider.

Unmanaged Computers
Specifies servers not monitored by MOM. See XenApp Managed

and Unmanaged Computers for information about
unmanaged servers.
Citrix Unlicensed Servers
Specifies servers running the XenApp Provider, but which

are unlicensed or missing a valid license. Note that MOM checks
the licenses on these servers every hour. After a server in this
group is properly licensed, the Management Pack regards it as
a managed server after the next computer scan.
Citrix License Servers
Specifies servers running Citrix Licensing.
Citrix Farm Metric Servers
Specifies the primary farm metric server for each server farm in
your deployment. This server must be running Presentation
Server 4.0 or later. Farm-wide alerts are raised against this server
in the State view. Note that farm-wide alerts are not raised
on XenApp 5.0 servers.
8.9.2.6. To install or upgrade the Management Pack for MOM 2005

The Management Pack consists of a single file called Citrixps2005.akm, which is supplied on the
installation media. To install the Management Pack, you import the Citrixps2005.akm file into MOM from the
MOM Administrator Console.
To use the Management Pack, you must be running MOM 2005. For information about MOM minimum
hardware and software requirements, see your MOM documentation.
To obtain information about servers and the server farm, the Management Pack requires the XenApp Provider
to be installed on every Enterprise or Platinum Edition computer that you want to monitor.
The Management Pack also requires the Licensing Provider to be installed on the license server(s).
Note: The Management Pack does not support agentless monitoring.
Important: Once installed, the Management Pack cannot be uninstalled. Therefore, Citrix recommends
that you back up the MOM database before installing the Management Pack.
1. Locate the file, Citrixps2005.akm. This file is in the \XenApp Management Pack folder on the
installation media.
2. Log on to the MOM Administrator Console.
3. Click Management Packs in the Navigation Pane.
4. Click Import/Export Management Packs in the Details pane.
5. Follow the instructions in the wizard to import the Citrixps2005.akm Management Pack file.
6. If you are upgrading the Management Pack rather than installing it for the first time, you are prompted
to specify whether you want to update or replace the existing Management Pack. Citrix recommends
that you choose the Update optionthis ensures that you retain any customized rules or
company knowledge articles that you may have added to the Management Pack.
8.9.2.7. Management Pack Post-Installation Tasks
After you install the Management Pack, add the servers you want to monitor to the list of managed computers
if you are not already monitoring these computers using MOM. Ensure that all license servers are also added
to the list of managed computers in MOM.
To add these servers to the list of managed computers, install the MOM agents on the respective servers.
For more information, see your MOM documentation.
To ensure that topology discovery runs efficiently in deployments that contain more than 10
computers, reconfigure the Citrix Topology Discovery Computers group. For more information, see
Configuring Topology Discovery.
If you have multiple server farms or data collector zones in your deployment, you can configure MOM to
recognize these groupings so that you can display and monitor servers by farm or zone. For more
information, see To specify server farm and zone computer groups.
The Management Pack includes a notification group called the Citrix Administrators group that you can
configure to ensure that the appropriate people are notified about problems with servers and server farms.
For more information, see To configure Citrix Administrators as MOM operators.
Some rules 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 rules, see Configuring and
Enabling Site-specific Rules for MOM 2005.
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.
8.9.2.7.1. 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 MOM.
MOM uses a component called the MOM Agent Service to retrieve data from servers, including servers running
the XenApp Provider. The MOM Agent Service runs using the MOM Agent Action account. Because the
Provider requires Citrix administration rights, the MOM 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 MOM user or administrator group to be able to view alerts
and information on the MOM Administrator Console or MOM Operator 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 MOM can view information relating
to XenApp in the MOM Administrator Console or MOM Operator Console. However, these users might not
be Citrix administrators. Depending upon how your accounts are set up in MOM, users might be able to
view information about XenApp that is not normally available to them in other XenApp management
consoles. Therefore, Citrix recommends take this into consideration when managing your MOM 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 ACL settings for the Licensing Provider namespace (\root\CitrixLicensing).
8.9.2.7.2. Troubleshooting Query Errors in MOM
When using MOM, 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 occurs because the XenApp Provider communicates with XenApp when retrieving information,
and XenApp allows only Citrix administrators to access this information.
If this error occurs, configure the MOM Agent Action account so that this account has full Citrix
administration rights on all the server farms you are monitoring.
8.9.2.8. Configuring Topology Discovery
The Deployment Topology view is populated by a discovery script that runs automatically once a day by
default. The script runs on the computers that are in the Citrix Topology Discovery Computers group. To
ensure that the topology view is populated when you initially install the Management Pack, this computer group
is populated by default with every managed server. However, if your deployment has more than 10 servers,
you reconfigure the Citrix Topology Discovery Computers group to include a maximum of two computers for
each farm; one is sufficient, but two allows redundancy.
To reconfigure the Citrix Topology Discovery Computers group
2. In Management Packs > Computer Groups, right-click the Citrix Topology Discovery Computers
group and select Properties.
3. On the Search for Computers tab, select Do not search for computers.
4. On the Included Computers tab, add a maximum of two computers for each farm.
5. To apply your changes, right-click Management Packs, then select Commit Configuration Change.
By default, computers running discovery scripts cannot submit data about any other computer. To configure
the computers in the Citrix Topology Discovery Computers group to submit data about other servers in the
farm, you must change two security settings.

To reconfigure security settings on topology discovery computers
1. In the MOM Administrator Console, expand the Administration node.
2. Select Administration > Computers > Agent-Managed Computers.
3. Then, for each computer that runs topology discovery, double-click the computer name. The computer
s properties appear.
4. On the Security tab, clear Use Global Settings and Agent Proxying.
After you reconfigure the security settings on all relevant computers, you must restart the MOM service on
those computers. You can do this by using the Stop MOM 2005 service and Start MOM 2005 service tasks
in the Operator Console. Note that, because by default topology discovery runs only once a day, it might take
up to 24 hours for any change you make to take effect.
8.9.2.9. To specify server farm and zone computer groups
After you install the Management Pack, MOM displays all XenApp computers in the network in the
Administration > Computers > All Computers area of the MOM Administrator Console. However, if you
have multiple server farms or data collector zones in your deployment, you might want to configure MOM
to recognize these groupings so that you can display and monitor servers by farm or zone.
To enable MOM to recognize server farms and zones, you must specify farm and zone computer groups in MOM.
2. Select Management Packs, then right-click Computer Groups and select Create Computer Group.
3. The Create Computer Group wizard appears. Click Next.
4. Type the name of the relevant farm or zone, then click Next until the Search for Computers
page appears.
5. Select Search for all computers using the criteria specified below, ensure that the Servers
check box is selected, and then click Next.
6. Select Specify a formula for the computer group.
7. Click Attribute.
8. If you are creating a farm computer group, select Citrix Farm Name. If you are creating a zone
computer group, select Citrix Zone Name.
9. Click OK. The attribute value you selected appears in the Formula for computer group: field.
10. After the attribute value, type ="name", where name is the name of the relevant farm or zone.
11. Click Next until you reach the end of the wizard.
12. To populate the new group, select Management Packs, then right-click Computer Groups and select
Calculate Group Membership.
8.9.2.10. To configure Citrix Administrators as MOM operators
The Management Pack includes a notification group, called the Citrix Administrators group. By default, this
group is empty. Therefore, configure the group to ensure that the appropriate people are notified about
problems with servers and server farms.
Before you configure this notification group, you must define the appropriate Citrix administrators as
operators within MOM.
Important: When you configure MOM 2005 to send Simple Mail Transfer Protocol (SMTP) email
notification responses, the email notification is not sent. For information about how to solve this issue, search
http://support.microsoft.com/ for article number 885741.
2. In Management Packs > Notification > Notification Groups, right-click Citrix Administrators
and choose Properties.
3. Select the appropriate Citrix administrators from the list of Available operators and move these into the
3.
Group operators list.
4. To apply your changes, right-click Management Packs, then select Commit Configuration Change.
8.9.2.11. To change the format of net send messages
By default, if you send alerts using net send and an alert occurs that generates a notification, no
meaningful description appears in the alert detail. You can change the format of net send messages to
include more meaningful information in notifications.
Important: These settings are applied globally, so the changes you make affect all net send
message notifications for all management packs.
2. Select Administration > Global Settings.
3. Double-click Notification Command Format.
4. On the Notification Command Format tab, change the Command Line option to use
$Alert Description$ instead of $Description$.
8.9.2.12. Configuring and Enabling Site-specific Rules for MOM 2005
Most rules that are specific to XenApp are enabled by default and begin functioning after you install
the Management Pack. However, some of these rules are disabled by default because they require
configuration specific to your site.
The rules that define how MOM collects, processes, and responds to information and that generate the
Citrix views are in the Management Packs\Rule Groups\Citrix Rules folder in the MOM Administrator
Console. Disabled rules are identified by a red cross through the rule icon.
8.9.2.12.1. Too Many Disconnected Sessions
This rule controls how MOM processes and responds to information about the number of disconnected
XenApp sessions. It is in the Management Packs\Rule Groups\Citrix Rules\Presentation Server
Rules\Performance Rules folder.
Disabled Rule
Associated Alert
Description of Rule
Too many disconnected sessions
The number of
disconnected sessions on this
server is high.
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 rule is disabled by default because the acceptable number of disconnected sessions varies between sites.
For more information about how to configure and enable this rule, see the rules Knowledge Base entry in
the MOM Administrator Console.
8.9.2.12.2. Idle Sessions
The following rules control how MOM processes and responds to information about idle XenApp sessions. They
are located in the Management Packs\Rule Groups\Citrix Rules\ Presentation Server Rules\Event Rules folder.
Disabled Rule
Associated Alert
Check for Citrix session idle too long A Citrix session has been idle
too long.
Description of Rule
Runs a script that
retrieves information from
the XenApp Provider, to determine
if an XenApp session has been
idle too long. If a session has

been idle too long, the
script generates a MOM event.
Citrix session idle too long
A Citrix session has been idle

too long.
Triggers an alert in response to

the MOM event. The alert
signals problems with the
session. Note that all
sessions, including idle
sessions, consume
resources. Therefore, idle
sessions might cause
problems when server resources
are limited.
These rules are disabled by default because the acceptable length of time for which a session can be idle
varies among sites.
For more information about how to configure and enable these rules, see the rules Knowledge Base entries in
8.9.2.12.3. Too Many Active Sessions
This rule controls how MOM processes and responds to information about the number of active XenApp
sessions. It is in the Management Packs\Rule Groups\Citrix Rules\ Presentation Server Rules\Performance
Rules folder.
Disabled Rule
View
Description of Rule
Too many active sessions
The number of active sessions

on this server is too high.
Triggers an alert to signal

that there are too many
active sessions running on a server.
This rule is disabled by default because the number of active sessions is dependent upon several
variables including the hardware and software in your deployment.
8.9.2.12.4. Sample Published Application Load
The following rule controls how MOM collects information about published application load.
This rule is in the Management Packs\Rule Groups\Citrix Rules\ Presentation Server Rules\Performance
Rules folder.
Disabled Rule
View
Description of Rule
Sample published application

load from load balancing
Enabling this rule

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 rule 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.
8.9.2.13. To open the Access Management Console from the MOM Operator Console
If the Citrix Access Management Console is installed on the MOM server, you can open it from the MOM
Operator Console.
You can open the Access Management Console from all views, except for the following:
Topology view
Computer Groups view
Performance Graph and Performance Counter Selection views
Any view that is empty (for example, the Alerts view when there are no alerts)
1. Log on to the MOM Operator Console.

2. In the Tasks pane, expand Citrix Tasks.
3. Select Launch Access Management Console.
8.9.2.13.1. To change the Access Management Console path with the MOM Administrator Console
The Access Management Console is assumed to be in the default installation directory for XenApp 5.0. If
you installed the console in a different directory, update the path for the task as follows:
2. In the Navigation pane, select Management Packs > Tasks > Citrix Tasks.
3. Double-click Launch Access Management Console.
4. Select the Details tab.
5. In the Start in: field, type the path where the console is installed.
8.9.3. Installation Manager
Installation Manager facilitates the rapid installation of applications and other software components to servers in
a XenApp farm.
This topic references the current version of the Installation Manager Administrator's Guide. To view, search,
Installation Manager Administrator's Guide
8.9.4. Network Manager for Citrix Presentation Server
Network Manager provides system management capabilities to Presentation Server farms through thirdparty SNMP management consoles. Network Manager runs on farms running Presentation Server 4.5,
Enterprise Edition.
This topic references the current version of the Network Manager Administrator's Guide. To view, search,
Network Manager Administrator's Guide
8.9.5. Resource Manager
Resource Manager helps you manage resources on a single or on multiple computers running Citrix
Presentation Server 4.0.
This topic references the current version of the Resource Manager Administrator's Guide. To view, search,
Resource Manager Administrator's Guide
8.9.6. 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 Access Management Console or Delivery Services Console, or a third party application.
The Citrix XenApp Management Pack for MOM 2005 and the Citrix XenApp Management Pack for Systems
Center Operations Manager 2007 are included with XenApp.
8.9.6.1. 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.
8.9.6.2. 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).
8.9.6.3. 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:
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.
8.9.6.4. 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.
8.9.6.5. 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.
8.9.6.6. 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.
8.9.6.7. 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.
8.9.6.8. 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:
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).
8.9.6.8.4. Citrix Licensing Provider WMI Schema
8.10. Load Manager

With Load Manager, 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.
Load Manager is a component of Citrix XenApp. It is installed by default with XenApp. To uninstall Load
Manager, you must uninstall XenApp.
Important: See the Readme document for your version of XenApp for the latest updates, known issues,
and other important information developed after this guide was completed.
Load Manager 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.
When a client user selects a published application to run, the client contacts the server farm to locate the
address of a server that hosts the published application. Load Manager maintains a list of available host
servers within the server farm. Upon receiving the clients request, Load Manager 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.
Load Manager 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, Load Manager removes t
Every server running XenApp 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.
Load Manager Monitor tool included with Load Manager allows you to view server loads graphically, log
activity, and view usage reports.
8.10.1. Working with Load Manager Rules
Load Manager Provides you with a set of rules. See List of Load Manager Rules. You cannot create your own rules.
Rules define how Load Manager manages loads on your servers and publishes applications. To include
additional factors in the management of the loads on your servers, you can find appropriate rules and add
them to an existing load evaluator.

You can remove rules from a load evaluator when you no longer want to include certain categories in the
load management of your servers and published applications. For example, you can remove the Memory
Usage rule from a load evaluator if you no longer want to manage memory usage.
Important: The Advanced or Default load evaluators cannot be altered. You can, however, create a copy
of these load evaluators and then modify the copys rules. See Copying Load Evaluators for details.
To add a rule to a load evaluator
2. Select Load Evaluators in the left pane.
3. In the Contents tab, select the load evaluator you want to change.
4. From the Actions menu, select Load Manager > Load Evaluator Properties.
5. From the Available Rules list, select the required rule and click Add.
6. Select the rule in the Assigned Rules list and edit its settings.
To remove a rule from a load evaluator

3. In the Contents tab, select the load evaluator containing the rule you want to remove.
5. Select the rule in the Assigned Rules list and click Remove. The rule is returned to the Available Rules
list for that load evaluator.
To change how a rule measures server activity

Load evaluator rules define the characteristics that are measured when calculating server or published
application loads. By adjusting how rules measure performance, you can control which servers are available
when a client user logs on to the server farm.
From the Start menu, open All Programs > Critix > Administration Tools and choose
5. Select the rule in the Assigned Rules list.
6. In the Rule Settings panel, change the values for the rule.
8.10.1.1. List of Load Manager Rules
These rules are included in Load Manager:
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. 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 Swap. 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.
8.10.2. Working with Load Evaluators

These load evaluators are included in Load Manager:
Default. Load Manager attaches the Default load evaluator to each server after you add your license to
the server farm. It contains two rules: Server User Load, 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, Memory Usage, Page Swaps, and
Load Throttling rules.
You can create new load evaluators based on the rules available in Load Manager.
Important: Each server or published application can have only one load evaluator attached to it.
You can attach one load evaluator to a server and one load evaluator to each published application on the
same server. For example, you can keep the Default load evaluator attached to your server and attach
another load evaluator to each of your published applications on that server.
Viewing Load Evaluator
Right-clicking a load evaluator allows you to copy it, delete it, view its properies, or create a new load evaluator.
Important: You cannot delete the Citrix-provided Advanced or Default load evaluators.
8.10.2.1. Viewing and Modifying Load Evaluator Properties
The properties of a load evaluator include its name, description, assigned rules, and rule settings. You can
view the properties of a load evaluator at any time from the Contents tab of the Load Evaluators node.
Important: The Default and Advanced load evaluator properties cannot be edited.
To change the properties of a load evaluator
3. Select the load evaluator that you want to edit.
5. On the Evaluator Properties dialog box, do one of the following:
View the load evaluator properties
Make your required changes to the load evaluator properties
8.10.2.2. Creating Load Evaluators

The Default and Advanced load evaluators provided with Load Manager are intended for use with
computers running XenApp. However, they may not meet all your load management needs. You can create
your own load evaluators with the rules available in Load Manager and attach them to your servers or
For example, with the Default load evaluator attached to a server, the server reports a full load when 100
users connect to it. If you find the number of user connections to the server consistently causes the server
to report full load, you can either increase the limit using a new load evaluator on each server hosting
the published application or publish the application on more load-managed servers.
Attaching the Advanced load evaluator to a server or application allows you to control the CPU utilization,
memory usage, virtual memory available, and the number of concurrent connection attempts the server
can handle.
To create a new load evaluator

2. Select Load Evaluators.
3. From the Actions menu, select Load Manager > New Load Evaluator.
4. On the New Evaluator dialog box, type a name and description for the new load evaluator.
5. Select one or more rules from the Available Rules list and add them to the Assigned Rules list.
6. Select each rule in the Assigned Rules list and configure it as required.
7. Close the New Evaluator dialog box and save your new load evaluator.
8.10.2.3. 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. 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 attach the Advanced load evaluator (included with Load Manager) to
every server hosting the application. By doing so, Load Manager distributes the available memory and
processor demand across the load-managed servers.
Each server or published application can have only one load evaluator attached to it.
To assign a load evaluator to a server
Services Console.
2. Select the server to which you want to attach a load evaluator.
3. From the Action menu, select All Tasks > Assign load evaluator.
4. On the Assign Load Evaluator dialog box, select the required load evaluator.
To assign a load evaluator to a published application

Services Console.
2. Select the published application to which you want to attach a load evaluator.
3. From the Action menu, select All Tasks > Load Manage Application.
4. On the Load Manage Application dialog box, select one or more servers from the Configured Servers
list and click Edit to change the load evaluator.
8.10.2.4. Copying Load Evaluators
As you become more familiar with the use of Load Manager, you can develop a range of rule parameters that
you may want to apply to multiple load evaluators. For example, you may have set up a load evaluator with
four rules but you want the settings for the rules to be different. Load Manager allows you to copy an
existing load evaluator rather than create a new one each time you want to change the properties of a
load evaluator or one of its rules.
To copy a load evaluator
1.

3. Select the load evaluator that you want to copy.
4. From the Actions menu, select Load Manager > Duplicate Load Evaluator. The Duplicate Evaluator
dialog box appears.
5. Edit the name, description, and rules for the new load evaluator and click OK.
8.10.2.5. Deleting Load Evaluators
You can delete load evaluators that are no longer in use. You cannot delete a load evaluator that is assigned to
a server or published application. You must assign a different evaluator to the published application or
server before you delete it. You cannot delete the Default and Advanced load evaluators from the console.
To delete a load evaluator
3. Select the load evaluator that you want to remove.
4. From the Actions menu, select Load Manager > Delete Load Evaluator(s).
5. Click Yes to delete the selected load evaluator.
8.10.2.6. 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 in conjunction with another 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
5. From the Available Rules list, select the Scheduling rule and click Add.
6. In the Rule Settings panel, use the Add Interval and Remove Interval buttons to select the days
and times that you want the server or published application to be available (Sunday through Saturday,
08:00 to 18:00, by default).
8.10.3. Monitoring Server Loads
You can monitor server loads by viewing them graphically, in real-time, using Load Manager Monitor.
The Load Manager Monitor checks recent loads for load managed servers and displays them as a graph of
load against time. The reported evaluator loads continuously change based on the rules you set in a
load evaluator and how much load activity there is.
You can view the monitor in a tab or as a separate window. Graph generation begins when you select the
Load Manager Monitor tab or open the Load Manager Monitor window. The monitor line starts on the right
side of the grid and continues to the left edge of the grid. The top of each grid represents a full load and
the bottom of each grid represents no load.
To review all ICA connection requests made to load managed servers, you can enable Load Manager logging
and save the contents of the log as separate text files.
The frequency with which Load Manager data is transmitted within the farm can also be customized to
your communication needs. For more information about relationships among your load evaluators,
published applications, and load-managed servers, you can view usage reports generated by Load Manager.
To view the Load Manager Monitor for a server
2. Select the server that you want to monitor.
3. Select the Load Manager Monitor tab.
To view the Load Manager Monitor in a separate window

2. Select the server that you want to monitor.
3. From the Actions menu, select Load Manager Monitor. The Load Manager Monitor dialog box appears.
8.10.3.1. Logging Load Manager Activity
The Load Manager log records ICA connection requests to load-managed servers in the server farm and can
store up to 16KB of text messages.
The Log tab is available when you select Load Evaluators in the Presentation Server Console or XenApp
Advanced Configuration. It displays the contents of the Load Manager log. With logging enabled, the
Load Manager log records each attempt by client users to launch a published application and the results of
that attempt.
Important: The Log tab is not populated with information until you attach a load evaluator to a server
or published application, and a client user attempts to launch a published application on that server.
The Load Manager log records information about active ICA sessions only.
To enable logging in Load Manager
Message logging for Load Manager is disabled by default.
1.
3. Select the Log tab.
4. From the Actions menu, select Log > Enable Logging.
To view the Load Manager log

3. Select the Log tab.
To save or clear the Load Manager log

3. Select from the Actions menu.
To save the contents of the Load Manager log, selectLog > Save Log.
To delete the contents of the Load Manager log, selectLog > Clear Log.
8.10.3.2. Setting the Frequency of Information Updates

The information displayed in the Load Manager Monitor and the loads reported by servers are updated at
defined intervalsevery minute for the Load Manager Monitor and every five minutes for load evaluator data.
You can change the frequency with which information is updated to meet your requirements.
3. From the Actions menu, select Load Manager > Load Manager Settings.
4. On the Load Manager Settings dialog box, set your required update frequency.
8.10.3.3. Viewing Usage Reports
With Load Manager, usage reports provide quick and easy access to the distribution of load evaluators in
use across your server farm.
The Usage Reports tab is available when you select Load Evaluators in the Presentation Server Console
or XenApp Advanced Configuration. It displays information about the load evaluators in the farm and the
servers or published applications to which they are attached.
The available report types are:
By Server (default). Lists the name of each server in the farm and the load evaluator attached to it.
By Application. Lists the published applications, including published desktops, the load
evaluators attached to them, and the servers on which they are installed.
By Evaluator. Lists each load evaluator, the published applications, including published desktops, and
the servers to which they are attached.
Tip: Double-click a load evaluator in a usage report to change its properties.

3. Click the Usage Reports tab.
4. Select the type of report you want to view.
8.11. 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 client 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
See This Topic
Using the Secure Gateway with

computers running XenApp
Planning a Secure Gateway Deployment
Installing and configuring the Secure Gateway
Installing and Configuring the Secure Gateway and

Secure Gateway Proxy
Learning more about the Secure Gateway

s performance counters and error logs
Managing the Secure Gateway
Getting general recommendations about

using network components such as
load balancers, SSL accelerator cards,
and firewalls
Secure Gateway Optimization and Security Guidelines
Learning more about troubleshooting a

Secure Gateway deployment
Troubleshooting the Secure Gateway
Learning about digital certificates

and certificate installation
Digital Certificates and the Secure Gateway
8.11.1. 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:
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 client 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 XenApp Web Plugin
You can use Citrix XenApp Web Plugin 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.
8.11.1.1. 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
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
Client devices require no preinstalled software for security. Remote, secure access is easy to
support, requiring little effort from IT staff.
Certificatebased security
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 Gateway. You can also configure the Secure Gateway to
omit log entries for polls from network equipment such as load balancers.
8.11.2. System Requirements for Secure Gateway
Upgrading from earlier versions of Secure Gateway or Secure Gateway Proxy on the Windows Server
2003 platform is supported. Upgrading on the Windows Server 2008 platform is not supported; you must
perform a fresh installation of Secure Gateway or Secure Gateway Proxy in this case. 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 the following Microsoft operating systems:
Windows Server 2008 Family, except Web Server
Windows Server 2003
Important: Secure Gateway runs as a 32-bit application on 64-bit versions of the Windows Server
2008 operating system.
Client Devices
The following Microsoft operating systems are supported for client devices:
Windows 2000 Professional
Windows XP Home Edition
Windows Vista
Windows Server 2003
Windows Server 2008
8.11.2.1. System Hardware Requirements

Important: For maximum security, Citrix recommends you reserve a standalone server for the
Secure Gateway.
The Secure Gateway requires the minimum hardware requirements for Windows Server 2003 and
Windows Server 2008, as specified by Microsoft:
Windows Server 2003

Processor
266Mhz or higher Pentium-compatible CPU
Memory
512MB RAM
Hard drive
4GB with 2GB of free space. Reserve 150MB for

Secure Gateway installation.
Networking
One network adapter
Display
VGA or higher resolution monitor
Keyboard
Required
Pointing device
Required
Windows Server 2008

Processor
1 GHz (32-bit) or higher Pentium-compatible CPU, 1.4

GHz (64-bit) or higher Itanium CPU
Memory
512MB RAM
Hard drive
10GB with 4GB of free space. Reserve 150MB for

Secure Gateway installation.
Networking
One network adapter
Display
Super VGA or higher resolution monitor
Keyboard
Required
Pointing device
Required
8.11.2.2. Citrix Products Compatibility with Secure Gateway

The Secure Gateway is compatible with the following Citrix products:
Citrix XenApp for Windows Server 2008
Citrix XenApp for Windows Server 2003
Web Interface
You can use Secure Gateway installed on a computer running Windows Server 2003 in the same environment
as a Citrix XenApp server for Windows Server 2008. You can also use Secure Gateway installed on a
computer running Windows Server 2008 in the same environment as a Citrix XenApp server for Windows
Server 2003.
The Secure Gateway is compatible with the following Citrix XenApp Plugin for Hosted Apps software:
Citrix XenApp (the new name for Program Neighborhood Agent and related clients)
Citrix XenApp Web Plugin (the new name for Web Client)
Important: Secure Gateway and Secure Gateway Proxy do not support the Citrix XenApp Plugin for
Streamed Apps, formerly known as the Citrix Streaming Client.
8.11.2.3. Certificate Requirements
All client devices and secure servers in a Secure Gateway deployment use digital certificates to verify each other
s 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
client 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 client 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:
Root certificates on all client 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.
Optional. A server certificate on the server(s) running the Secure Gateway Proxy.
Optional. A server certificate on the server running the STA.
8.11.3. 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.
Deploying the Secure Gateway in a Single-Hop DMZ
Deploying the Secure Gateway in a Double-Hop DMZ

Setting Up and Testing a Server Farm
Installing the Secure Ticket Authority
Configuring the Web Interface to Support the Secure Gateway
Testing Your Deployment
8.11.3.1. 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:
Root certificates on all client 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.
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
client device connected to the LAN.
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
XenApp plugin 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.
8.11.3.1.1. 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 client 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
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.
Disadvantages
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 client 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 client 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.
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.
8.11.3.1.2. 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.
8.11.3.1.3. 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.
8.11.3.1.4. 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 client 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 client devices connecting to the Secure Gateway meet the compatibility requirements stated in
System Requirements for Secure Gateway.

8.11.3.2. 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 client 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.
Optional. A server certificate on the server(s) running the Secure Gateway Proxy.
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.
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 XenApp plugin for 32-bit Windows.
8.11.3.2.1. 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 client device to connect and log on to the Web Interface.
6. Verify that you can launch published applications.
8.11.3.2.2. 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/
8.11.3.3. Setting Up and Testing a Server Farm
Complete the following tasks prior to installing and configuring the Secure Gateway.
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 client device and ensure you can access available published resources.
See the Citrix XenApp installation and administration topics (http://support.citrix.com/proddocs/index.jsp)
for detailed instructions about performing these tasks.
8.11.3.4. 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.
8.11.3.5. 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 client 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.
8.11.4. 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.
Important: You must have access to administrative privileges to install and configure the Secure Gateway
and use the management tools.
8.11.4.1. Upgrading Secure Gateway or Secure Gateway Proxy
Upgrading directly to Secure Gateway 3.1 or Secure Gateway Proxy 3.1. You must perform the following steps:
1. Remove any installed Secure Gateway hotfix software packages.
2. Remove the Secure Gateway or Secure Gateway Proxy software.
3.
Perform a fresh installation of Secure Gateway or Secure Gateway Proxy.
8.11.4.2. 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.
8.11.4.3. 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:
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.
8.11.4.3.1. To install the Secure Gateway or Secure Gateway Proxy
1. Insert the installation media in the media drive.
2. From the Autorun screen, click Platinum, Enterprise, or Advanced and then click
Common Components.
3. Click Secure Gateway.
4.
4. On the Welcome screen, click Next.

5. Read and accept the license agreement, and then click Next.
6. In Installation Mode, select Secure Gateway or Secure Gateway Proxy.
7. 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.
8. In Service Account, select the user account to determine credentials and privileges. Citrix
recommends that you select an account that restricts privileges.
9. Click Next and follow the instructions in the wizard to complete installation.
10. After installing the Secure Gateway, configure it as described in Configuring the Secure Gateway or
8.11.4.4. 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 contextsensitive help describing the procedures and information you need to enter.
Configuring the Secure Gateway for use with Citrix XenApp requires the following information:
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.
8.11.4.4.1. 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.
8.11.4.4.2. 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:
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.
8.11.4.4.3. 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.
1. Select one of the following to access the parameters available for modification during the
configuration process:
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:
Install a server certificate on the server running the Secure Gateway Proxy
Install a client certificate on the Secure Gateway
8.11.4.4.4. 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

Standard Configuration Select
To select a server certificate
To configure secure protocol settings
Not available
To configure inbound client connections
To configure outbound connections
To add the Secure Ticket Authority details
To configure connection parameters
Not available
To configure logging exclusions
Not available
To add the Web Interface server details
To configure the logging parameters
8.11.4.4.5. 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

Standard Configuration Select
To select a server certificate
To configure secure protocol settings
Not available
To configure inbound client connections
To configure outbound connections
To add the Secure Ticket Authority details
Not available
Not available
To configure connection parameters
Not available
To configure logging exclusions
Not available
To configure the logging parameters
8.11.4.4.6. To select a server certificate

Server certificates enable client 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.
8.11.4.4.7. 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 client 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 the Citrix XenApp plugin
(formerly known as Program Neighborhood Agent).
1. Select a secure protocol:

Transport Layer Security (TLSv1)
Configure the Secure Gateway to use only TLS as its secure protocol. If you select this option,
verify that all client 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 client 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:

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 client devices support
only COM while others support only GOV.
Note: When the Secure Gateway and a client device support both COM and GOV cipher suites,
the Secure Gateway uses the COM cipher suite.
3.
Click Next to proceed.
8.11.4.4.8. 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.
8.11.4.4.9. To configure outbound connections
Select the servers to which the Secure Gateway can connect:
Options
Description
No outbound traffic restrictions 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.
Use the Secure Gateway Proxy
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.
Use an Access Control

List (ACL)
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.
Note: In a double-hop DMZ, configure outbound access control lists on the Secure Gateway Proxy server only.
8.11.4.4.9.1. 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
Description
Start address
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.
End address
Leave this field blank if you are creating an entry for a single
server. Otherwise, enter the end address of the range.
TCP port
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.
Use default port
Select this option to use the default port used by the server for
the protocol selected.
ICA
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.
CGP
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
3. If you select the Server FQDN option, type or select the following information:
Options
Description
FQDN
Enter the fully qualified domain name of the server to which

the Secure Gateway Proxy allows access.
TCP port
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.
Secure traffic between

the server and the
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.
8.11.4.4.9.2. 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:
Install a server certificate on the server running the Secure Gateway Proxy
Install a client certificate on the Secure Gateway
6. Click OK.
8.11.4.4.10. 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
Description
FQDN
Enter the fully qualified domain name of the server running the STA.
Path
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.
ID
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.
Secure traffic
between the STA and
the Secure Gateway
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.
TCP port
Enter a network port number used by the Secure Gateway to contact

the STA.
Use default
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.
8.11.4.4.11. 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
Description
No connection timeout
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.
Connection
timeout (seconds)
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.
Concurrent Connection Limits 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.
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.
8.11.4.4.12. 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.
8.11.4.4.13. 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:
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:
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.
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.
8.11.4.4.14. 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:
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.
8.11.4.4.15. 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.
8.11.4.4.15.1. 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.
8.11.4.5. 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.
8.11.5. 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:
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:
The Secure Gateway Configuration wizard
The Secure Gateway Diagnostics tool
8.11.5.1. 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
Description
Client IP
The IP address and port of the remote client.
User
The current user associated with the session, if any.
Domain
The network domain from which the current user is logged on.
Time Established
The time that this connection was established.
Time Elapsed
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

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.
8.11.5.2. 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:
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.
8.11.5.2.1. 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.
8.11.5.2.2. Performance Counters Available for the Secure Gateway

The following performance counters are available for the Secure Gateway:
Counter name
Description
Bytes/Sec from Client
The data throughput rate (bytes per second) from all

connected clients to the Secure Gateway.
Bytes/Sec to Client
The data throughput rate (bytes per second) from the

Secure Gateway to all connected clients.
CGP Active Connections
The total number of CGP client connections currently active.
CGP Bytes/Sec from Client

clients connected to the Secure Gateway using the CGP protocol.
CGP Bytes/Sec to Client

Secure Gateway to all connected clients using the CGP protocol.
CGP Kilobytes from Client
The total number of kilobytes sent from all clients connected

to the Secure Gateway using the CGP protocol.
CGP Kilobytes to Client
The total number of kilobytes sent from the Secure Gateway

to all clients connected using the CGP protocol.
CGP Peak Bytes/Sec from Client
The highest data throughput rate (bytes per second) from

all clients connected to the Secure Gateway using the
CGP protocol.
CGP Peak Bytes/Sec to Client

Secure Gateway to all connected clients using the CGP protocol.
CGP Successful Connections
The total number of successful CGP connections.
Client Connect Time: Average (in ms)
The average amount of time (in milliseconds) for a

client connection request to complete the connection process.
Client Connect Time: Longest (in ms)
The longest amount of time (in milliseconds) for a

client connection request to complete successfully.
Connections/Second
The number of successful client connection requests per second.
Connections/Second: Peak
The highest number of successful client connection requests

per second.
Connections: Peak Active
The highest number of concurrent connections through

the Secure Gateway.
Connections: Total Active
The total number of client connections currently active.
Connections: Total Successful
The total number of successful client connections. It is the

sum of all successful connections for all protocols: CGP,
HTTP/S, and SOCKS.
Connections:Pending
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.
Failed Backend Connections
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.
Failed Connections: Client Timed Out
The total number of client connection requests that

were accepted but timed out before completing the
protocol handshake.
Failed Connections: General Client Error
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.
Failed Connections: SSL Client

Handshake Error
The total number of client connection requests that

were accepted but did not successfully complete the
SSL handshake.
Failed Connections: Total Client
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.
HTTP/S Active Connections
The total number of HTTP/S connections currently active.
HTTP/S Bytes/Sec from Client

clients connected to the Secure Gateway using the
HTTP/S protocol.
HTTP/S Bytes/Sec to Client

Secure Gateway to all connected clients using the
HTTP/S protocol.
HTTP/S Kilobytes from Client

to the Secure Gateway using the HTTP/S protocol.
HTTP/S Kilobytes to Client
The total number of kilobytes sent from all connected clients

to the Secure Gateway using the HTTPS protocol.
HTTP/S Peak Bytes/Sec from Client

HTTP/S protocol.
HTTP/S Peak Bytes/Sec to Client

HTTP/S protocol.
HTTP/S Successful Connections
The total number of successful HTTP/S connections.
Kilobytes from Client

to the Secure Gateway.
Kilobytes to Client
The total number of kilobytes sent from the Secure Gateway

to all connected clients.
Peak Bytes/Sec from Client

all connected clients to the Secure Gateway.
Peak Bytes/Sec to Client

the Secure Gateway to all connected clients.
SOCKS Active Connections
The total number of SOCKS client connections currently active.
SOCKS Bytes/Sec from Client

clients connected to the Secure Gateway using the
SOCKS protocol.
SOCKS Bytes/Sec to Client

SOCKS protocol.
SOCKS Kilobytes from Client

to the Secure Gateway using the SOCKS protocol.
SOCKS Kilobytes to Client

to the Secure Gateway using the SOCKS protocol.
SOCKS Peak Bytes/Sec from Client

SOCKS protocol.
SOCKS Peak Bytes/Sec to Client

SOCKS protocol.
SOCKS Successful Connections
The total number of successful SOCKS connections.
SSL Handshake Time: Average
Average length of time (in milliseconds) for an SSL handshake

to complete.
SSL Handshake Time: Longest
Length of time (in milliseconds) for the longest SSL handshake

to complete.
SSL Handshakes/Sec
Number of successful SSL handshakes per second.
SSL Handshakes/Sec: Peak
Highest number of successful SSL handshakes per second.
SSL Handshakes: Pending
Number of SSL handshakes currently in progress between

a client and the Secure Gateway.
SSL Handshakes: Total
Total number of SSL handshakes that completed

successfully between a client and the Secure Gateway.
8.11.5.3. 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
A registry or configuration value is present.
Warning icon
A registry or configuration value is missing.
Passed check icon 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.
8.11.5.4. 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.
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.
8.11.5.5. 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.
8.11.5.6. 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.
8.11.6. 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.
This topic contains the following:
Configuring Firewalls for the Secure Gateway
Ensuring High Availability of the Secure Gateway
Coordinating Keep-Alive Values Between the Secure Gateway and Citrix XenApp
Improving Security of the Secure Gateway
Preventing Indexing by Search Engines
8.11.6.1. Configuring Firewalls for the Secure Gateway

The Secure Gateway is typically deployed in the DMZ, so that traffic originating from a remote client 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 client devices and computers running Citrix XenApp. Firewalls are not ICA-aware and do not ma
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 client devices and the Secure Gateway.
However, if you prefer to configure your firewall to use proxy mode, ensure that your firewall does not:
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
8.11.6.2. 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.
8.11.6.2.1. 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.
8.11.6.2.2. 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.
8.11.6.2.3. 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.
8.11.6.2.4. 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.
8.11.6.3. 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 client 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.
8.11.6.3.1. 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.
8.11.6.4. 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 client device informing the Secure Gateway which ciphersuites it
is capable of handling, and the Secure Gateway informing the client which ciphersuite to use for clientserver 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 governmentapproved cryptography to protect sensitive but unclassified data.
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.
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.
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.
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.
8.11.6.5. 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: /
8.11.7. 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.
8.11.7.1. 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.
6.
In the Select server certificate dialog box, select the certificate the Secure Gateway is configured to
use and click View.
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.
8.11.7.2. 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.
8.11.7.3. 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.
8.11.7.4. Performance Issues with Transferring Files Between a Client 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.
8.11.7.5. 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/.
8.11.7.6. 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:
SSL protocol mismatch between the client 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.
8.11.7.7. 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:
Run the Secure Gateway parallel to the reverse Web proxy
Use a network address translator (NAT) in place of the reverse Web proxy
8.11.7.7.1. 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.
8.11.7.7.2. 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.
8.11.8. 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.
8.11.8.1. 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.
8.11.8.1.1. Types of Cryptography
There are two main types of cryptography:
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:
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.
8.11.8.1.2. 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:
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.
8.11.8.2. 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 client device to verify the server certificate.
When establishing an SSL connection with a Web browser on a client device, the server sends its certificate to
the client.
When receiving a server certificate, the Web browser (for example, Internet Explorer) on the client 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
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.
8.11.8.2.1. 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.
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.
8.11.8.2.2. 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 Ann
s 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.
8.11.8.3. 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:
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.
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.
8.11.8.4. 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 client
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:
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 client device,
see the appropriate clients 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 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.
8.11.8.5. Obtaining and Installing Root Certificates

A root certificate must be present on every client 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 client 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.
8.11.8.6. 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://www2.citrix.com. The use of a wildcard certificate allows several Web sites to
be covered by a single certificate.
8.11.9. Using the Secure Gateway Proxy in Relay Mode
Relay mode, a feature of Citrix XenApp, provides flexibility in the way the Secure Gateway is used. It is a
simpler solution and requires fewer hardware resources. The benefits of this mode of operation are:
Provides compatibility with client deployments that do not include the Web Interface or ticketing
support. You can use relay mode in secure corporate environments such as intranets, LANs, and WANs.
Fully secures data, but provides relatively weaker authentication.
Enables use of Program Neighborhood to browse for applications.
8.11.9.1. Modes of Operation for the Secure Gateway Proxy

You can use the Secure Gateway Proxy in either normal mode or relay mode.
Normal Mode
Citrix recommends the normal mode of operation for the Secure Gateway Proxy because it provides
strong security. In normal mode, the Secure Gateway server functions as an Internet gateway with
authentication and authorization support provided by the Web Interface and the Secure Ticket Authority that
is used with Citrix XenApp.
Relay Mode
The Secure Gateway Proxy can also be used in relay mode. Relay mode provides more flexibility in the way
the Secure Gateway is used at the expense of ticketing support. The biggest difference in this mode is
the absence of ticketing support provided by the STA. Installing the Secure Gateway Proxy in relay mode does
not provide secure connections.
Caution: Relay mode is not the recommended mode in which to use the Secure Gateway. In this mode,
the Secure Gateway is essentially an encrypted tunnel through your firewall. IP addresses of your servers
are visible from the client. Be aware that you are opening up a well-known port on your firewall and of
the associated risks in doing so.
Use the Secure Gateway in relay mode only when:
You want to use the Secure Gateway but do not want to use the ticketing support available through
the STA.
You want to use the Secure Gateway but are not using the Web Interface and do not intend to.
You want to use the Secure Gateway to secure your corporate intranet, LAN, or WAN, and users' plugins are connecting from a secure network. Do not use relay mode for plug-ins that are connecting from
an external network or the Internet.
The Secure Gateway Proxy is installed on a stand-alone server. In relay mode, a client device connects to
a server farm through the Secure Gateway Proxy server, which acts as a server-side proxy. User authentication
is performed by Citrix XenApp.
In this mode, the Secure Gateway Proxy supports plug-ins as they attempt to locate the Citrix XML
Service, browse, and connect to a server farm. When you install the Secure Gateway Proxy in relay mode,
session reliability is not supported.
8.11.9.2. How Relay Mode Works
To use the Secure Gateway Proxy in relay mode, install the Secure Gateway Proxy on a stand-alone server.
The figure illustrates the communications that take place between the client device, the Secure Gateway
Proxy, and a server farm in relay mode.
A remote user connects to the Secure Gateway Proxy server on port 443 and requests access to
a published application or a Citrix XenApp resource.
The Secure Gateway Proxy checks that the server address and port for the requested resource exists in
its Access Control List. If the server address and port are found, the connection is made.
The XenApp server prompts the user to log on using valid user credentials. When authenticated,
the connection is established and the published application or application list is made available to the user.
When the connection is established, the Secure Gateway Proxy decrypts data from the client
before sending the data to the server, and encrypts data from the server before forwarding it to the client.
The IP addresses in the access control list (ACL) should be static; if the servers get a different IP
address from the DHCP server, the ACLs have to be updated.
8.11.9.3. Installing the Secure Gateway Proxy in Relay Mode

Before installing the Secure Gateway Proxy, compile all of the required information to correctly configure
the Secure Gateway Proxy.
Item description
Example
FQDN of the server running the Citrix XML Service.
mfserver01.company.com
IP addresses, or IP address ranges, and port numbers of

the server(s) that the Secure Gateway is allowed to
access. This list should also include separate entries for
the Citrix XenApp computer running the Citrix XML Service
used for HTTP browsing. The port number used by
Citrix XenApp for ICA traffic is 1494; for the Citrix XML
Service, it is 80.
10.1.1.11 to 10.1.1.255:
149410.1.1.11:8010.1.40.11 to
10.1.40.255:1494
FQDN of the Secure Gateway server.
csgwy.company.com
IP address of the Secure Gateway server.
10.42.1.17
Listener port number for SSL/TLS connections on the

Secure Gateway server.
443
You can specify these values during installation. The values in this listing are for illustration purposes
only; replace them with specifics of your network environment.
Print and fill out the Secure Gateway Pre-Installation Checklist. Keep the completed checklist near when
you install the Secure Gateway Proxy.
A server certificate must be installed on the Secure Gateway Proxy and a root certificate on the client device.
When configuring the client device to connect to the Secure Gateway Proxy, use the FQDN of the server
certificate that is installed on the Secure Gateway Proxy.
8.11.9.3.1. To install the Secure Gateway Proxy in relay mode
1. Ensure port 443 on this server is not being used by any Windows service.
The Secure Gateway Proxy uses port 443. This is the default setting. Internet Information Services
(IIS) also uses port 443. If IIS and the Secure Gateway Proxy are installed on the same server, change
the IIS port to something different from port 443. If both IIS and the Secure Gateway Proxy use port
443, client connections fail.
2. Install the server certificate.
3. Install the Secure Gateway Proxy as described in Installing and Configuring the Secure Gateway
and Secure Gateway Proxy.
4. Follow the instructions in the configuration wizard to complete the installation.
Immediately after installation, the Secure Gateway Proxy Configuration wizard starts.
8.11.9.3.2. To configure the Secure Gateway in relay mode
For the Secure Gateway Proxy to run in relay mode, you must use a certificate; otherwise the Secure
Gateway Proxy runs in normal mode.
1. On the Secure Gateway configuration level screen, select one of the following:
Use Standard to specify the minimum set of configuration values required to run the
Secure Gateway
Use Advanced if you are an expert user and prefer to specify all the configuration values
required for Secure Gateway operation
2. Check Secure traffic between the Secure Gateway and Secure Gateway Proxy to ensures that
a certificate is used and click Next.
3. Select the server certificate that is required by the Secure Gateway. If you have more than one
certificate installed, click View to examine details of a certificate. Click Next.
4. Select the network protocols and the ciphersuites you want to use. Click Next to accept the default
to monitor all IP addresses.
The Secure Gateway listens on port 443 for inbound connections. To monitor for specific IP
addresses, clear the Monitor all IP addresses check box, click Add, and type the IP address and
TCP port of the network interface you want to monitor. Click Next.
5. In Configure outbound connections, click Use an Access Control List (ACL) to define the
IP addresses for the ACL and click Configure.
To use the Secure Gateway in relay mode, define an access control list (ACL). The ACL lists the
IP addresses and the TCP port numbers (1494) for allowed access to Citrix XenApp. The ACL also
contains IP addresses and the TCP port number (80) of servers running the Citrix XML Service. You
can enter a range of IP addresses and ports to include IP addresses of all servers in a given range.
The listener port for ICA traffic is 1494.
6. In the Configure allowed outbound connections dialog box, click Add to add an entry to this list. The
Enter IP address range dialog box appears.
7. Enter the range of IP addresses that the Secure Gateway Proxy will use.
8. To specify a single IP address, leave the End address field blank. The default TCP port is 1494.
9. After the IP addresses are configured, click OK. The IP addresses appear in the Configure
9.
allowed outbound connections dialog box.
10. Click Add and click Server FQDN. Enter the FQDN of the Citrix XenApp server. To secure the
traffic between the Secure Gateway Proxy and Citrix XenApp, click Secure traffic between the
server and the Secure Gateway Proxy. Click Next.
The port for secure traffic between the server and the Secure Gateway Proxy is 443.
11. Specify the connection time limits and click Next.
12. To specify the IP addresses to exclude from logging, click Add and type the address of the device
to exclude. Click Next.
13. Specify the error logging level you want to use. The value you enter specifies the type of events to
be logged in the Windows system event log. Click Next.
14. Click Finish to complete configuration of the Secure Gateway Proxy in relay mode. The Secure
Gateway Proxy automatically restarts when the configuration is complete.
8.11.9.4. Configuring Plug-ins for Secure Gateway
In relay mode, plug-ins installed on client devices connect directly to the Secure Gateway Proxys external
DNS name. Configure settings on the client device to enable connections to the Secure Gateway Proxy.
Configuration of Program Neighborhood is described here to illustrate client-side settings required for
connections to a Secure Gateway Proxy relay server.
For more information about configuring Program Neighborhood for Secure Gateway, locate the topics about
Configuring Program Neighborhood in Citrix eDocs.
8.11.9.4.1. To configure plug-in connections to the Secure Gateway Proxy
1. Make sure the client device meets all system requirements for Program Neighborhood.
2. Start Program Neighborhood, and make a selection:
If you are configuring an application set:
Right-click the application set you want to configure and select Application Set Settings.
A configuration dialog box for the application set appears.
If you are configuring an existing custom ICA connection:
Right-click the custom ICA connection you want to configure and select Properties. The Properties
dialog box for the custom connection appears.
If you are configuring all future custom ICA connections:
Right-click in a blank area of the Custom ICA Connections window and select Custom
Connections Settings. The Custom ICA Connections dialog box appears
3. From the Network Protocol menu, make a selection:
If you are configuring an application set or an existing custom ICA connection, select
SSL/TLS+HTTPS.
If you are configuring all future custom ICA connections, select HTTP/HTTPS.
4. On the Connection tab, click Firewalls.
5. Enter the FQDN of the Secure Gateway server in the Secure Gateway address box.
6. Enter the port number in the Port box, and click OK to close the dialog box.
8.11.9.4.2. To configure all application sets for the plug-in to connect to the Secure Gateway Proxy
1. On the Start menu, locate Program Neighborhood.
2. On the File menu, click Application Set Settings.
3.
4.
In the Network Protocol drop-down list, select SSL/TLS+HTTPS.
4. Click Add, type the name of the server and port, and then click OK.
5. Click Firewalls. In the Firewall Settings dialog box, specify the Secure Gateway address and the Port.
Important: For SSL network connections, the address specified must be the same server
certificate FQDN to which plug-ins connect from an external network. Plug-ins must be able to
resolve the DNS name to the external IP address of the Secure Gateway Proxy.
6. Click the Default Options tab. Clear the Enable session reliability check box. If session reliability
is enabled in relay mode, plug-in connections are broken.
7.
Click OK to exit the Connection Settings dialog box.
Note that all applications defined within the application set inherit these settings.
8.11.9.5. To test the Secure Gateway relay mode
1. Ensure that the plug-in is configured to connect through Secure Gateway. See Configuring Plug-ins
for Secure Gateway for instructions about configuring plug-ins.
2. In Program Neighborhood, double-click an ICA connection to launch it. If you did not enter your
user credentials for this application set or custom ICA connection, a logon dialog box appears. Enter a
valid user name, domain, and password. After a brief interval, the application window appears.
3. Open the ICA Connection Center and check the entry for the published application you have open. You
will see the string \\Remote, 128-bit SSL/TLS appended to the application name.
If you have trouble launching an ICA connection or a connection fails, see Troubleshooting the Secure Gateway
for information about known problems and typical troubleshooting procedures.
8.11.9.6. To start or stop the Secure Gateway Proxy Service manually
1. Log on as an administrator to the Secure Gateway Proxy.
2. On the desktop of the Secure Gateway Proxy, right-click My Computer and select Manage.
3.
In the Computer Management Console, double-click Services and Applications and then click Services
. A list of all services registered for this computer is shown in the right-hand pane.
4. Select Secure Gateway Proxy.

5. From the Action menu, start or stop the service.
8.12. 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.
8.12.1. 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
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.
8.12.2. 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:
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:
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.
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.
8.12.2.1. 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:
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 one XenApp server and all the SmartAuditor Administration components (SmartAuditor
Database, SmartAuditor Server, SmartAuditor Policy Console) are installed on another server. Both 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.
Note: For this deployment scenario, ensure that you install SQL Server 2005 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.
8.12.2.2. 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:
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.
8.12.2.2.1. 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 se
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.
8.12.2.3. 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.
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
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. 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.
Microsoft SQL Server 2005 Express Edition 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 2005 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.
If your SmartAuditor deployment requires many millions of recorded sessions to be cataloged in the
database, follow Microsoft guidelines for SQL Server 2005 scalability.
8.12.2.4. Important Deployment Notes
Updated: 2010-04-26
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.
If you attempt to install SmartAuditor Server on a Windows Server 2003 64-bit server on which the
Citrix Web Interface is installed, an error message appears and the installation fails. The Web
Interface uses the 32-bit IIS mode that is not compatible with SmartAuditors 64-bit mode.
SmartAuditor does not support the clustering of two or more SmartAuditor Servers in a deployment.
SmartAuditor does not support ThinWire 1.0 clients. If SmartAuditor Agent is installed on a XenApp
server and has session recording enabled, the XenApp server rejects connections from ThinWire 1.0 clients.
SmartAuditor is available in English, French, German, Japanese, and Spanish. 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, simplified
Chinese, traditional Chinese, and Korean operating systems. The French, German, Japanese, and
Spanish editions of SmartAuditor are supported on operating systems in their respective languages.
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, 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.
8.12.2.5. 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. Refer to the Citrix XenApp Installation Checklist for more information.
Ensured that the main server software of the Platinum edition of XenApp 5.0 is installed and
licensed on each server on which sessions are to be recorded. Refer to XenApp Installation for
more information. If you are setting the product edition of XenApp to Platinum after
installation, refer to XenApp Administration.
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.
8.12.2.6. To install SmartAuditor
This topic details the process of installing SmartAuditor components in the sequence provided by Autorun:
1. SmartAuditor Administration. The SmartAuditor Administration components are the

SmartAuditor Database, SmartAuditor Server, and the SmartAuditor Policy Console. Using Autorun,
you can to choose which of these components to install on a server. These components are not
supported on Microsoft Windows Server 2008.
2. SmartAuditor Agent for Citrix XenApp. The SmartAuditor Agent must be installed on a
computer running XenApp.
3. SmartAuditor Player. The SmartAuditor Player is installed on one or more workstations for users
who view session recordings.
To install SmartAuditor Administration components

1. On the server where you are installing the SmartAuditor Administration components
(SmartAuditor Database, SmartAuditor Server, SmartAuditor Policy Console), insert the installation
media. If Autorun does not launch, navigate to and double-click autorun.exe.
2. Choose Platinum Edition > Application Session Recording > SmartAuditor Administration.
3. Use the installation wizard to select the SmartAuditor Administration components you want to install on
the server.
4. On the Database Configuration page:
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.
To install SmartAuditor Agent
Note: When installing SmartAuditor Agent, do not accept the default value for the name of the
computer hosting the SmartAuditor Server. If you accept the default value, localhost, SmartAuditor
cannot record sessions until you use SmartAuditor Agent Properties to reconfigure SmartAuditor Server
to the name of the computer where you installed the SmartAuditor Server.
1. On each XenApp server from which you want to record sessions, insert the installation media. If
Autorun does not launch, navigate to and double-click autorun.exe.
2. Choose Platinum Edition > Applications Session Recording > SmartAuditor Agent.
3. At the SmartAuditor Agent Configuration window in the installation wizard, 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

1. On each workstation where session recordings will be played and reviewed, insert the installation media.
If Autorun does not launch, navigate to and double-click autorun.exe.
2. Choose Platinum Edition > Application Session Recording > 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.
8.12.2.7. 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.
8.12.2.8. Uninstalling SmartAuditor
To remove SmartAuditor from a server or workstation, use the Add/Remove Programs option accessed in
the Control Panel.
8.12.2.9. 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:
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.
4.
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:
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 popup 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.
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
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.
8.12.3. 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.
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.
8.12.4. 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.
8.12.4.1. Using System Policies
SmartAuditor provides these system policies:
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 popup 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.
8.12.4.2. Creating Custom 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:
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:
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:
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.
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 privacyrelated information or when your organization does not want to record the sessions of 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.
8.12.4.2.1. 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.
4.
5.
6.
7.
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.
In the SmartAuditor Policy Console, select Recording Policies.
From the menu bar, choose Action > Add New Policy. A policy called New Policy appears in the
left pane.
Select the new policy and choose Action > Rename from the menu bar.
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.
8.12.4.2.2. To modify a policy

1.
Log on to the server where the SmartAuditor Policy Console is installed.
2.
3.
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:

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.
8.12.4.2.3. To delete a policy

Note: You cannot delete a system policy or a policy that is active.
1.
2.
3.
4.
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.
8.12.4.3. To activate a policy

1.
2.
3.
4.
5.
Select the policy you want to make the active policy.
6.
From the menu bar, choose Action > Activate Policy.
8.12.4.4. 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:
And the new policy is:
After a rollover the policy will be:
Do not record
Any other policy
No change. The new policy takes effect

only when the user logs on to a new session.
Record without notification
Do not record
Recording stops.
Record with notification
Recording continues and a

notification message appears.
Do not record
Recording stops.
Record without notification
Recording continues. No message appears

the next time a user logs on.
Record with notification
8.12.5. 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.
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.
8.12.6. 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.
2.
Log on to the server where SmartAuditor Agent is installed.

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.
8.12.7. 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.
If you are using the English-language edition of SmartAuditor, the default notification message appears in
the same language as the operating system of the computers hosting the SmartAuditor Server: English,
Russian, simplified Chinese, traditional Chinese, or Korean. The French, German, Japanese, and Spanish
editions of SmartAuditor display the default notification message in their respective languages.
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.
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.
8.12.8. 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
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.
8.12.9. 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 are 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.
Server Properties.
3. In SmartAuditor Server Properties, click the Playback tab.
4.
4. Select or clear the Allow live session playback check box.

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

Server Properties.
3. In SmartAuditor Server Properties, click the Signing tab.
4. Click Clear.
8.12.12. 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.
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.
Server Properties.
3. In SmartAuditor Server Properties, click the Storage tab.
4. In the Restore directory for archived files field, type the directory for the restored archive files.
8.12.13. 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
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.
8.12.14. 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.
8.12.14.1. To launch the 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.
8.12.14.2. 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
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:
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.
3. Do any of the following:
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:
3.
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.
8.12.14.3. 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

3. Define your search criteria:
Enter a search criterion is 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.
To perform an advanced search

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:
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.
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.
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.
8.12.14.4. 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.
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:
Seek action:
Home
Seek to the beginning.
End
Seek to the end.
Right Arrow
Seek forward five seconds.
Left Arrow
Seek backward five seconds.
Move mouse wheel one

notch down
Seek forward 15 seconds.
Move mouse wheel one notch up
Seek backward 15 seconds.
Ctrl + Right Arrow
Ctrl + Left Arrow
Page Down
Seek forward one minute.
Page Up
Seek backward one minute.
Ctrl + Move mouse wheel

one notch down
Ctrl + Move mouse wheel

one notch up
Ctrl + Page Down
Seek forward six minutes.
Ctrl + Page Up
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.
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.
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.
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.
8.12.14.5. 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.
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.
To insert a bookmark
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:
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.
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.
To delete a bookmark
2.
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.
3. Begin playing a session recording containing events or bookmarks.
4. Go to an event or bookmark:
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.
8.12.14.6. 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
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

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.
To scale the session playback to fit the Player window

3. From the SmartAuditor Player menu bar, choose Play > Panning and Scaling > Scale to Fit.
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

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

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.
8.12.14.7. 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.
8.12.14.8. 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\Local Settings\Application Data\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
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.
6. Click OK.
To empty cache
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.
8.12.14.9. 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.
8.12.15. Troubleshooting SmartAuditor

This troubleshooting information contains solutions to some issues you may encounter during and after
installing SmartAuditor components:
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
8.12.15.1. 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
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
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.

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.
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.
8.12.15.1.1. 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
2. Launch a Web browser and type the following address:
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
3. If you are prompted for NT LAN Manager (NTLM) authentication, log on with a domain
administrator account.
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
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
Player is connected to the computer hosting the SmartAuditor Server using the configure protocol.
To verify IIS connectivity for the SmartAuditor Policy Console
1. Log on to the server where the SmartAuditor Policy Console is installed.
For HTTPS: https://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where
For HTTP: http://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where
Policy Console is connected to the computer hosting the SmartAuditor Server using the configure protocol.
8.12.15.1.2. 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:
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
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.
8.12.15.2. 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:
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.
8.12.15.3. 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:
SQL Server 2005 Express Edition 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.
8.12.15.4. Sessions are not Recording
Updated: 2010-04-26
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:
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.
8.12.15.5. 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:
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.
8.12.15.5.1. 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.
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:
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.
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.
8.12.15.6. 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.
8.12.15.7. 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:
1. Log on to each server where the SmartAuditor Agent is installed.
2.
Agent Properties.
3. In SmartAuditor Agent Properties, choose the Connections tab.
4. 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:
1. Log on to each workstation where the SmartAuditor Player is installed.
3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select
the server and choose Modify.
4. 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:
Policy Console.
3. 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.
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:
1. Log on to each server where the SmartAuditor Agent is installed.
Agent Properties.
3. In SmartAuditor Agent Properties, choose the Connections tab.
4. 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:
1. Log on to each workstation where the SmartAuditor Player is installed.
3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select
the server and choose Modify.
4. 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:
Policy Console.
3. 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.
8.12.16. 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
:\Program Files\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:\Program Files\Citrix\SmartAuditor\Server\Bin directory, type icldb /?.
To access help for specific commands, type icldb command /?.
Command
Description
archive
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).
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
Displays the SmartAuditor Database schema version.
/l
Logs the results and errors to the Windows event log.
/f
Forces the command to run without prompts.
/s
Suppresses the copyright message.
/?
Displays help for the commands.
8.13. Glossary
access server farm
A logical grouping of servers on which Advanced Access Control Services run. An access server
farm consists of one or more networked computers that run Advanced Access Control components such
as the Web server, and database server. These components work together to provide access to
corporate resources such as Web sites, file shares, and email.
access control list (ACL)
In the context of the Secure Gateway, an ACL is a mechanism that restricts access to resources. The ACL
is a data structure containing the IP addresses and ports of XenApp servers on the network to
which Secure Gateway components have access.
The Access Management Console is a stand-alone snap-in to the Microsoft Management Console
(MMC) that allows you to manage items in multiple server farms. Management functionality is
provided through a number of management tools (extension snap-ins).
account authority
The platform-specific source of information about user accounts used by a XenApp server; for example,
a Windows NT domain, Active Directory domain, or Novell eDirectory.
Advanced Access Control
A management component for Citrix Secure Access that provides additional granular control
over applications, files, Web content, and email attachments. It manages what can be accessed and
what actions are permitted, based on the users access scenario.
anonymous application
An application published exclusively for the use of anonymous users.
anonymous session
A plugin session started by an anonymous user.
anonymous user
An unidentified user granted minimal access to a server or farm and its published applications.
anonymous user account
A user account defined on a XenApp server for access by anonymous users.
application compatibility script
A file containing commands and registry settings necessary for some applications to run in
multisession environments.
application name
A text string used to uniquely identify a published application within a farm. The application name is
used by the farm and plugins to recognize individual applications that might have the same display
name. The text string is generated automatically based on the display name entered when the
application is published.
Application Publishing wizard
A tool that you use to publish applications and other items on servers.
application set
A users view of the applications published in a server farm that the user is authorized to access.
attended computer
A server with a logged on user who can respond to system prompts.
authentication
The process of identifying a user, usually based on a user name and password. In security
systems, authentication is distinct from authorization, which is the process of giving users access to
system objects based on their identity. Authentication confirms the identity of the user but does not
impact the access rights of the user.
authentication service
A service available on a server running Citrix Access Gateway Advanced or Enterprise Edition that
issues access tokens for connection requests for resources available through an access server farm.
These access tokens form the basis of authentication and authorization for users connecting
through Access Gateway.
authorization
The process of granting or denying access to a network resource. Most computer security systems
are based on a two-step process. The first stage is authentication, which confirms the identity of the
user. The second stage is authorization, which allows the user access to various resources based on
the users identity.
auto-creation
See also printer auto-creation.
automatic plugin reconnect
The feature that prompts supported Citrix XenApp Plugin for Hosted Apps to reconnect automatically to
a session when dropped connections are detected (when network issues outside of the XenApp
server occur).
autorun installation
A method for installing XenApp on a server that requires user intervention. It is accessed from the
autorun feature and uses the Citrix XenApp Setup wizard. The wizard guides you through the process
of installing XenApp and its components on the server and also allows you to select various
installation options for the components.
certificate
See also digital certificate.
certificate store
The location on the computer running the Citrix SSL Relay that contains the server certificate. Store
the certificate for the SSL Relay in Local computer/Personal so that you can manage it with the
certificate snap-in for the Microsoft Management Console (MMC).
ciphersuite
An encryption/decryption algorithm. When establishing an SSL/TLS connection, the client and
server determine a common set of supported ciphersuites and then use the most secure one to encrypt
the communications. These algorithms have differing advantages in terms of speed, encryption
strength, and exportability.
Citrix Activation System
The part of the MyCitrix.com Web site where you register for licenses, allocate them, and download
license files used by the Citrix License Server.
Citrix administrators
System administrators responsible for installing, configuring, and maintaining XenApp servers. In a
UNIX environment, it is the user group assigned to these administrators, which has the default
name ctxadm.
Citrix Access Gateway Plugin
Citrix plugin software used with Citrix Access Gateway to connect users to network resources. In
Standard Edition and Enterprise Edition, users access a secure Web address to download the software
and authenticate to the Access Gateway appliance. In Advanced Edition, administrators create a
connection policy to require use of the software when users access specific logon points through the
Access Gateway appliance. Users can download the software after they authenticate to the server
running Advanced Access Control.
Citrix SSL Relay
A Citrix service that facilitates an SSL-secured connection between a XenApp server, the Web Interface,
or a Citrix XenApp plugin.
Citrix Streaming Profiler
A stand-alone application that enables administrators to prepare applications, browser plug-ins,
files, folders, and registry settings that can stream to the clients local cache for execution.
Citrix Universal Printer
The Citrix Universal Printer is a device-independent printer object that represents all printers on the
client device. Using the Citrix Universal Printer reduces the number of printer objects created during
printer auto-creation at the beginning of sessions.
The Web Interface provides users with access to published applications through the Citrix XenApp plugin
or a standard Web browser.
Citrix XenApp (plugin)
Citrix XenApp (formerly named Program Neighborhood Agent) allows you to deliver published
applications directly to users desktops so users can access links to published applications with or without
a Web browser. With Citrix XenApp, links to published applications appear in the Start menu, on
the Windows desktop, or in the Windows notification area. Remote applications are integrated into
the desktop and appear to the user as local applications. You must use Citrix Web Interface to use
Citrix XenApp.
Citrix XenApp Plugin for Hosted Apps
Citrix software (formerly named the Presentation Server Client) that enables users to connect to
XenApp servers from a variety of client devices. The Citrix XenApp Plugin for Hosted Apps contains
Citrix XenApp, the Citrix XenApp Web Plugin, and Program Neighborhood.
Citrix XenApp Plugin for Streamed Apps
The plugin (formerly named the Streaming Client) that provides streamed applications from an
application profile on a network file server to the user desktop or XenApp server.
Citrix XML Service
A Windows service that provides an HTTP interface to the client users browser. It uses TCP packets
instead of UDP, which allows connections to work across most firewalls. The default port for the Citrix
XML Service is 80.
client COM port mapping
The feature that enables applications running on a server to access peripherals attached to COM ports
on the client device.
client device
Any hardware device capable of running the plugin software.
client device mapping
The feature that enables published applications running on the server to access storage and
peripherals attached to the local client device. Client device mapping consists of several distinct
features: client drive mapping, client printer mapping, and client COM port mapping.
client drive mapping
The feature that enables applications running on the server to access physical and logical drives
configured on the client device.
client printer mapping
The feature that enables applications running on the server to send output to printers configured on
the client device.
common gateway protocol
A general-purpose tunneling protocol that provides connection reliability by allowing broken connections
to be restored without affecting the tunneled protocols.
compatibility script
See also application compatibility script.
Configuration Logging
A feature that tracks administrative changes made to the server farm and logs them to a logging
database from which reports can be generated in the Access Management Consoles Report Center.
The Configuration Logging feature is available only with the Enterprise and Platinum editions of XenApp.
connection control
The feature that allows you to set a limit on the number of connections that each user can
have simultaneously in the farm. You can also limit the number of concurrent connections to
specified published applications, and you can prevent users from launching more than one instance of
the same published application.
console
A control unit used to communicate with a computer. See also License Management Console and
Access Management Console.
content publishing
This feature allows you to publish document files, media files, Web URLs, and any other type of file
from any network location. Icons for published content appear in Citrix XenApp plugin and
Program Neighborhood on the desktop and on the users logon page for the Web Interface. Users
can double-click published content icons to access content in the same way they access
content redirection
This feature allows you to specify whether plugins open published content, applications, browsers,
and media players locally or remotely. There are two types of content redirection: from server-toclient device and from client device-to-server.
CPU prioritization
The feature that allows you to assign each published application in the server farm a priority level for
CPU access. This feature can be used to ensure that CPU-intensive applications in the server farm do
not degrade the performance of other applications.
CSV
Comma-separated values. A file format used as a portable representation of a database. Each line is
one entry or record and the data fields in a record are separated by commas. Commas can be followed
by spaces and/or tab characters that are ignored. If a field includes a comma, the entire field must
be surrounded with double quotes.
ctxcertreq
A command-line tool for generating a certificate request file that can be sent to a Certificate Authority.
You can use ctxcertreq to create a request for a new certificate or a request to renew a certificate that
is about to expire.
ctxcertmgr
A command-line tool for managing certificates.
custom administrator
An administrator who is subordinate to a full administrator. Custom administrators cannot set up
other administrator accounts and have only a subset of the permissions that a full administrator has.
custom ICA connection
In Program Neighborhood, a user-created shortcut to a published application or XenApp server.
data source name
The system data source name (DSN) stores information about how a plugin can connect to a
database. XenApp servers use a DSN file to access the data store.
data store
An Open Database Connectivity (ODBC)-compliant database that stores persistent data for a
farm. Examples of persistent data include configuration information about published applications,
users, printers, and servers. Each server farm has a single data store.
DBMS
Database management system. A software interface between the database and the user. A DBMS
handles user requests for database actions with provision for data security and integrity requirements.
delegated administration
The feature that allows you to delegate areas of administration and farm management to your IT
staff. Administrators can assign specialized staff members to perform specific tasks such as
managing printers, published applications, or user policies. Specialized staff members can carry out
their assigned tasks without being granted full access to all areas of farm management.
demilitarized zone (DMZ)
A network isolated from the trusted or secure network by a firewall. Network administrators often
isolate public resources, such as Web or email servers in the DMZ, to prevent an intruder from
attacking the internal network.
digital certificate
A credential for a principal, such as a user or server. The certificate consists of the principals public key,
a digital signature from a certificate authority, and other information. The digital certificate is used
to perform authentication of the principal cryptographically and to secure communications between
the principal and another entity.
disconnected session
When the user does not log off from a session and the client device is no longer connected to the
server, the applications in the session continue running on the server. A user can reconnect to
a disconnected session. If the user does not do so within a specified time-out period, the
server automatically terminates the session.
display name
A name you specify when you publish an application. The display name appears in the Citrix XenApp
plugin and in application folders in the Access Management Console or Advanced Configuration tool.
You can also choose to use the display name in the Web Interface.
dynamic store
An in-memory database that contains frequently updated configuration data such as application
load information. A server farm replicates dynamic store information across multiple servers.
file type association
By associating the content with the application, you enable a client device with Citrix XenApp installed
to launch the published application when you open that file type, which is redirected to the
published instance of the application. You 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.
FQDN
Fully qualified domain name.
full administrator
An administrator who has full access to all the administrative functions and features of the server farm.
Full administrators are the only ones who are allowed to create or modify other administrator accounts.
Health Monitoring & Recovery
A feature of XenApp that allows you to run tests on servers that participate in load balancing to ensure
that if one server experiences a problem, it does not interfere with the users ability to access
published applications through another server. Citrix provides a standard set of tests; however, you
can also develop your own tests using the Health Monitoring & Recovery SDK. Health Monitoring
& Recovery is available only with the Enterprise and Platinum editions of XenApp.
ICA (Independent Computing Architecture)
The architecture that XenApp uses to separate an applications logic from its user interface. With ICA,
only the keystrokes, mouse clicks, and screen updates pass between the client device and server on
the network, while 100% of the applications logic executes on the server.
icaclient.adm
Group Policy Object template file used to configure the plugin options and settings.
ICA connection
The logical port used by a plugin to connect to, and start a session on, a XenApp server. It is the active
link established between a plugin and a XenApp server.
ICA file
A text file (with the extension .ica) containing information about any ICA connection. ICA files are
written in Windows .ini file format and organize published application information in a standard way
that plugins can interpret. When a plugin receives an ICA file, it initializes a session running the
application on the server specified in the file.
ICA Printer Configuration tool
The utility you use to create and connect to client printers for the plugins for Windows CE. You must
run this utility in an ICA session from the client device whose printer you want to configure.
ICA protocol
The protocol that plugins use to format user input (such as, keystrokes, and mouse clicks) and address
it to a server farm for processing. Server farms use it to format application output (display and audio)
and return it to the client device.
ICA session
A connection between a plugin and a XenApp server, identified by a specific user ID and ICA
connection. The session consists of the status of the connection, the server resources allocated to the
user for the duration of the session, and any applications executing during the session. An ICA
session normally terminates when the user logs off from the server.
IMA Encryption
A feature of XenApp that allows the administrator to automatically encrypt sensitive information that
is housed in the IMA data store.
Independent Management Architecture (IMA)
A server-to-server infrastructure that provides robust, secure, and scalable tools for managing any
size server farm. Among other features, IMA enables centralized platform-independent management,
an ODBC-compliant data store, and management products that plug into a management console.
inter-isolation communication
A feature provided by the Streaming Profiler that allows individually profiled applications to
communicate with each other when launched on the client device.
isolation environment
A feature provided by the application streaming feature that allows published applications to run on
the local client device without interfering with other applications running on the same device. An
isolation environment is specific for the application and user session, regardless of whether the
user streams to the local client device or virtualizes the streamed application from a server.
license allocation
The process of selecting a specific number of licenses that you want to download in a license file.
You allocate licenses from your license entitlement. See also license entitlement.
license code
A series of numbers and letters required to download license files from MyCitrix.com. It is included in
your products packaging or sent to you by email.
license count
The number of licenses available for use on a license server. In MyCitrix.com, the number of
licenses available for allocation to a license file.
license entitlement
Your license entitlement is the total number of licenses that you purchase. You can see your entitlement
on MyCitrix.com. You choose the licenses you want to allocate from your entitlement. See also
license allocation.
license file
A digitally signed text-only file downloaded from MyCitrix.com that contains product licenses
and information the license server requires to manage the licenses.
license grace period
The amount of time that Citrix products continue to work after they can no longer contact the
license server (for example, if the license server experiences a power outage). If contact is not made
with the license server by the end of the grace period, the product stops working.
license hostname
The name of the computer acting as the license server. During the license allocation process, you enter
the host name of the license server. License files are specific to license servers because, in part, of
the hostname you enter when you generate a license file. Host names are case-sensitive; you must
enter the hostname in MyCitrix.com exactly as it appears on the license server.
License Management Console
An optional Web-based tool that runs on the same computer as the license server. Some
License Management Console features help you download license files from Citrix, copy license files to
the license server, and run reports to evaluate license usage.
license server
A shared or dedicated computer installed with licensing software and, optionally, the License
Management Console. This server responds to requests for licenses for Citrix products. You can
share license servers among farms. License servers can host licenses for multiple products.
load management
A feature of XenApp that enables management of application loads. When a user launches a
published application that is configured for load management, that users session is established on
the most lightly loaded server in the farm, based on criteria you can configure.
local application
An application installed on a local client device.
local host cache
A local subset of the server farm data store information. This file is present on all XenApp servers.
local text echo
A feature that accelerates the display of text input on a client device to effectively shield users
from experiencing latency on the network.
logging database
A database that must be set up and configured to support the configuration logging feature.
Information about administrative changes is stored in this database and the Access Management Console
s Report Center is used to generate reports from this information.
metric
One of a series of measurable items for a server or application. You can select which metrics you want
to monitor for a particular server.
migrate
A process where you manually move your server farm from a legacy version of Presentation Server to
a newer version of XenApp.
monitoring
The process of automatically checking the values of metrics on servers.
mouse-click feedback
A feature that enables visual feedback for mouse clicks. When a user clicks the mouse, the plugin
software immediately changes the mouse pointer to an hourglass to show that the users input is
being processed.
MSI package
Microsoft Installer package. An installation package based on Microsofts Windows Installer Service.
XenApp is an example of a product that ships as an MSI package for installation on target servers.
MSP package
Microsoft Patch package. An installation package based on Microsofts Windows Installer Service.
MSP packages are typically used to patch or update application installations that use the Windows
Installer Service.
network printer
A shared printer object accessed through a network print server.
normal mode
A computer that is running the Secure Gateway Proxy, typically in the second segment of a doublehop demilitarized zone (DMZ). When the Secure Gateway Proxy is running in normal mode, it provides
full functionality and security for the enterprise network.
Novell Directory Services (NDS) support
Support for NDS allows users in Novell network environments to log on using their NDS credentials
to access applications and content published on XenApp servers.
offline access
The capability to configure users and streamed applications so that users can disconnect from the
company network and continue to run the applications in offline mode for a specified length of time.
panning and scaling
Features of the plugins that allow users to view a remote session that is larger than the client desktop.
For example, if the client desktop is 1024 x 768 pixels and the session is 1600 x 1200 pixels, the
session image does not fit in the session view window. Panning provides scroll bars. Scaling
provides controls in the System menu to shrink the session window.
pass-through authentication
When you enable pass-through authentication for XenApp Advanced Configuration, the tool uses your
local user credentials from the server on which the tool is running. You can log on without
reentering credentials. Users can also enable pass-through authentication in plugins that support
this feature.
pass-through plugin
A plugin (Citrix XenApp or Program Neighborhood) is installed on a XenApp server ensuring that
users, after initially connecting to an application on one server, can connect to applications published
on other servers. The pass-through plugin is used primarily for published desktops when some
applications are installed on a server different from the server hosting the desktop session. If passthrough authentication is enabled, the user is not prompted for a password when the remote
desktop connects.
policies
XenApp policies are a method of controlling connection settings for groups of users, client devices,
and servers. You can use policies to apply select settings, known as rules, to connections filtered for
access type, specific users, client devices, IP addresses, or servers. For example, you can create
policies that apply one set of rules to connections from workstations in company headquarters and
another set of rules to connections from lender laptops that you provide to a roaming sales force.
preferential load balancing
This feature assigns importance levels (Low, Normal, or High) to specific users and applications.
The important users and applications with higher levels of service connect to their sessions more
quickly and have more computing resources available to them.
printer auto-creation
The term autocreation refers to a process XenApp uses to add printers (printer objects) at the beginning
of sessions. When a user starts a session, by default, printer objects are created automatically in
the session based on the printers on the client device. When the user ends the session, these printers
are deleted. This occurs so that printer objects are not stored locally on the client device. The way in
which the printers are auto-created is based on printing policy settings.
printer driver
The software program that lets the computer communicate with the printing device. This program
converts the information to be printed to a language that the printing device can process. The
printer driver also understands the device and job settings of the printing device and presents a
user interface for users to configure the settings. In a Windows system, printer drivers are distinct from
the software representation of printers.
printers
Refers to the software representation of a printing device. Computers must store information about
printers so they can find and interact with printing devices. The printer icons in the Control Panel
> Printers panel display the software representation of the printers. (You are not seeing the
printer drivers.) Printer object is also used to refer to the software representation of a printing device.
printer driver mapping
The process of connecting inconsistently named printer drivers on the client device and server
operating systems. For example, if you have a printer driver on the client operating system named
HP LaserJet5 PostScript and the same driver on the server operating system is named HP LaserJet
5 PS, specify for XenApp to use the HP LaserJet 5 PS driver whenever it encounters HP
LaserJet5 PostScript.
printing device
In a XenApp printing context, the term printing device refers to the physical printer (that is, the
hardware device to which you send print jobs).
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 it waits until
it receives all pages to print the print 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 server that manages the communications between client devices and printers. In Citrix
documentation, 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.
process
An instance of a program that is being executed.
One of the plugins in the Citrix XenApp Plugin for Hosted Apps that enables users to view the
published resources they are authorized to use in the server farm. Program Neighborhood
contains application sets and custom ICA connections.
Program Neighborhood folder
A group of logically related applications within a users application set. You can assign an application to
a specific Program Neighborhood folder when you publish it.
published application
An application installed on computers in a XenApp server farm that is configured for multiuser access
from plugins. With Load Manager, you can manage the load for published applications among servers in
the server farm. With the plugins, you can push a published application to your users client devices.
published content
A document, media clip, graphic, or other type of file or URL that you publish for access by users.
Published content is executed by local applications on client devices.
purge
Systematically eliminates old or unneeded information.
redirection
The term redirection refers to redirecting client device resources to server sessions so that
published applications or desktops have access to them. Redirection is often used to describe the
process by which users can access local hardware devices, such as printers, hard drives, Special
Folders, COM ports, TWAIN scanners, smart cards, and digital cameras.
relay listening port
The TCP port on a XenApp server that the Citrix SSL Relay monitors for data from a Web server.
relay mode
In this mode, the Secure Gateway functions without the Web Interface and ticketing support from
the secure ticket authority (STA). It is a less secure mode in which the Secure Gateway functions as
a server-side proxy server that provides a single point of entry into a server farm.
Resource Manager
Resource Manager (powered by EdgeSight technology) is a resource management solution for
Citrix XenApp, Enterprise Edition. It monitors user sessions and server performance in real time,
allowing you to quickly analyze, resolve, and proactively prevent problems. The main components are
the agents, the server, and an administration and reporting console.
schema
A description of a database to a database management system (DBMS) in the language provided by
the DBMS. A DBMS handles requests for database actions and permits control of security and data
integrity requirements.
seamless window
One of the settings you can specify for the window size of a published application. If a published
application runs in a seamless window, the user can take advantage of all the client platforms
window management features, such as resizing and minimizing.
Secure Gateway
A component that provides a secure encrypted channel for ICA traffic over the Internet using
Secure Sockets Layer (SSL) or Transport Layer Security (TLS) between clients and the Secure
Gateway. The Secure Gateway provides a single point of encryption and access to server farms.
A component of Secure Gateway that functions as a proxy server between the Secure Gateway and
the secure network.
Secure Sockets Layer/Transport Layer Security (SSL/TLS)
A standards-based architecture for encryption, authentication, and message integrity. It is used to
secure the communications between two computers across a public network, authenticate the
two computers to each other based on a separate trusted authority, and ensure that the
communications are not tampered with. See also ciphersuites.
Secure Ticket Authority (STA)
The STA is a ticketing mechanism that issues session tickets for clients. These tickets form the basis
of authentication and authorization for connections to a server farm.
server
A server on which XenApp software is running. You can publish applications, content, and desktops
on these servers for remote access by plugins.
server farm
A group of computers running XenApp managed as a single entity with some form of physical
connection between servers and an IMA-based data store.
server group
A group of servers used for easier application deployment on target servers.
session ID
A unique identifier for a specific ICA session on a XenApp server.
session reliability
Session reliability keeps ICA sessions active and on the users screen when network connectivity
is interrupted. Users continue to see the application they are working in until network connectivity resumes.
shadow taskbar
The taskbar on a server desktop that you can use to shadow multiple users and to switch
between shadowed sessions quickly.
shadowing
A feature that enables an authorized user to remotely join or take control of another users plugin
session for diagnosis, training, or technical support. See also user-to-user shadowing.
SpeedScreen Browser Acceleration
A feature that optimizes the responsiveness of graphics-rich HTML pages in published versions of
Microsoft Outlook, Outlook Express, and Internet Explorer.
SpeedScreen Flash Acceleration
A feature that allows you to control and optimize the way XenApp passes Adobe Flash animations to users.
SpeedScreen Image Acceleration
A feature that offers you a trade-off 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 the server to the
client device.
SpeedScreen Latency Reduction
A combination of technologies implemented in ICA that decreases bandwidth consumption and
total packets transmitted, resulting in reduced latency and consistent performance regardless of
network connection.
SpeedScreen Multimedia Acceleration
A feature that allows you to control and optimize the way XenApp passes streaming audio and video
to users.
SpeedScreen Progressive Display
A feature that allows you to improve interactivity when displaying high-detail images by
temporarily increasing the level of compression (decreasing the quality) of such an image when it is
first transmitted over a limited bandwidth connection, to provide a fast (but low quality) initial display.
start-up license
A file (citrix_startup.lic) that handles the initial communication between the product and the license
server. This file does not affect your license count. Do not delete this file.
status icon
A colored signal in the status display that shows the status of each metric. When a status icon in
the display changes, an alarm condition occurs.
streaming application profile
A collection of client configurations (targets) and a list of applications that users can execute. In
addition, profiles include scripts and other settings that are used in streaming applications to
client workstations. Administrators create application profiles on a profiler workstation and make
them available for publishing by saving them to a network file share.
transform file
A database file that modifies an MSI package. The transform file modifies instructions about how
the package is installed; for example, to enable an application to run in a Terminal Services environment.
UAC
User Account Control. A security feature of Windows Vista and Windows Server 2008.
unattended install
An installation type that does not require user intervention during software installations.
unattended server
A server that does not require user intervention during application installations.
UNC
Universal Naming Convention. UNC format is \\servername\sharename\path\filename.
UTC
Coordinated Universal Time. UTC is the same as Greenwich Mean Time (GMT) and is the reference
time zone used for calculating world time zones.
universal printer
See Citrix Universal Printer.
universal printer driver
A universal printer driver can be used as the driver for any printing device. Citrix provides several
generic printer drivers that you can use as universal printer drivers, as well as an XPS-based
Citrix Universal Printer Driver and a WMF-based Citrix Universal Printer Driver. Using a universal
printer driver on farm servers can replace multiple native printer drivers and reduce driver maintenance.
universal printing
The term Citrix Universal Printing refers to the Citrix Universal Printing solution, which comprises
the universal printer drivers and the Citrix Universal Printer.
upgrade
A process where you move from one version of XenApp to another, newer version. You must be using
an earlier version of Presentation Server, or XenApp, that is compatible with the upgrade path to
the newest version; otherwise, you must migrate your server farm. Often, the term upgrade denotes
using an installation wizard to move to the newer version.
user-to-user shadowing
The feature that allows users to shadow other users without requiring administrator rights. Multiple
users from different locations can view presentations and training sessions, allowing one-to-many, manyto-one, and many-to-many online collaboration. See also shadowing.
Web-based plugin installation
A Web-based method for deploying plugin software to users. When a user visits a XenApp Web site,
the Web Interface detects the device and Web browser types and guides the user through the process
of installing an appropriate plugin.
Windows-based terminal (WBT)
A fixed-function thin-client device that can run applications only by connecting to a server. WBTs
cannot run applications locally.
The tool (formerly named Presentation Server Console) is used to configure XenApp printing,
policies, zones, and load evaluators and in mixed-farms. Administering XenApp requires both this tool
and the Access Management Console.
zone
A logical grouping of XenApp servers. All servers in a zone communicate with the server designated as
the data collector for the zone. Citrix recommends limiting the number of zones in a farm and using
them only for different geographic sites across a WAN.
zone data collector
A computer that stores dynamic data for one zone in a farm. Examples of dynamic data include
current server load, the number of current user sessions, and the applications currently running in
user sessions on a specified server.
Updated: 2010-04-13
Citrix products offer the security specialist a wide range of features for securing a XenApp system according
to officially recognized standards.
Security standards as they apply to Citrix XenApp 5.0 for Microsoft Windows Server 2003 and Citrix XenApp
5.0 for Microsoft Windows Server 2008 are discussed here. These topics provide an overview of the
standards that apply to XenApp deployments and describe the issues involved in securing communications
across a set of sample XenApp deployments. For more information about the details of the individual
security features, refer to the relevant product or component documentation.
When deploying XenApp 5.0 for Windows Server within large organizations, particularly in
government environments, security standards are an important consideration. For example, many
government bodies in the United States and elsewhere specify a preference or requirement for applications to
be compliant with FIPS 140. These topics address common issues related to such environments.
These topics are designed for security specialists, systems integrators, and consultants, particularly those
working with government organizations worldwide.
Note: Later Citrix product and feature versions may be available and may be supported on different
operating system versions; Citrix XenApp 5 security test configurations used the versions noted in these topics.
9.1. Security Considerations in a XenApp Deployment
XenApp provides server-based computing to local and remote users through the Independent
Computing Architecture (ICA) protocol developed by Citrix.
ICA is the communication protocol by which servers and client devices exchange data in a XenApp
environment. ICA is optimized to enhance the delivery and performance of this exchange, even on low
bandwidth connections.
As an application runs on the server, XenApp intercepts the applications display data and uses the ICA
protocol to send this data (on standard network protocols) to the plugin software running on the users
client device. When the user types on the keyboard or moves and clicks the mouse, the plugin software sends
the data generated for processing by the application running on the server.
ICA requires minimal client workstation capabilities and includes error detection and recovery, encryption,
and data compression.
A server farm is a collection of XenApp servers that you can manage (from the Access Management Console) as
a single entity. A server can belong to only one farm, but a farm can include servers from more than one
domain. The design of server farms has to balance the goal of providing users with the fastest possible
application access with that of achieving the required degree of centralized administration and network security.
Note that in XenApp deployments that include the Web Interface, communication between the server running
the Web Interface and client devices running Web browsers (and plugin software) takes place using HTTP.
In a XenApp deployment, administrators can configure encryption using either of the following:
SSL Relay, a component that is integrated into XenApp
Secure Gateway, a separate component provided on the XenApp installation media
9.1.1. Country-Specific Government Information

Updated: 2009-08-25
The following topics are of particular relevance to XenApp installations in Australia, the United Kingdom, and
the United States:
FIPS 140 and XenApp
TLS/SSL Protocols
Smart Cards
Smart Card Support
Kerberos Authentication
In addition, for information on Common Access Cards (of particular relevance to installations in the
United States), see Smart Card Support.
For more information about issues specific to your country, contact your local Citrix representative.
9.1.2. FIPS 140 and XenApp
Updated: 2009-09-07
Federal Information Processing Standard 140 (FIPS 140) is a U.S. Federal Government standard that specifies
a benchmark for implementing cryptographic software. It provides best practices for using
cryptographic algorithms, managing key elements and data buffers, and interacting with the operating system.
An evaluation process that is administered by the National Institute of Standards and Technology (NIST)
National Voluntary Laboratory Accreditation Program (NVLAP) allows encryption product vendors to
demonstrate the extent to which they comply with the standard and, thus, the trustworthiness of
their implementation.
FIPS 140-1, published in 1994, established requirements for cryptographic modules to provide four security
levels that allowed cost-effective solutions appropriate for different degrees of data sensitivity and
different application environments. FIPS 140-2, which superceded FIPS 140-1 in 2002, incorporated changes
in standards and technology since 1994. FIPS 140-3, which is still in draft, adds an additional security level
and incorporates new security features that reflect recent advances in technology.
Some U.S. Government organizations restrict purchases of products that contain cryptography to those that
use FIPS 140-validated modules.
In the U.K., guidance published by the Communications-Electronics Security Group (CESG) recommends the
use of FIPS 140-approved products where the required use for information is below the
RESTRICTED classification, but is still sensitive (that is, data classified PRIVATE).
The security community at large values products that follow the guidelines detailed in FIPS 140 and the use
of FIPS 140-validated cryptographic modules.
To implement secure access to application servers and to meet the FIPS 140 requirements, Citrix products
can use cryptographic modules that are FIPS 140 validated in Windows implementations of secure TLS or
SSL connections.
The following XenApp components can use cryptographic modules that are FIPS 140 validated:
XenApp
Citrix XenApp Plugin for Hosted Apps for Windows (including the Citrix XenApp plugin, the Citrix
XenApp Web Plugin, and Program Neighborhood)
Web Interface
SSL Relay
Secure Gateway for Windows
Where the client and server components (listed above) communicate with the TLS or SSL connection enabled,
the cryptographic modules that are used are provided by the Microsoft Windows operating system. These
modules use the Microsoft Cryptography Application Programming Interface (CryptoAPI) and are FIPS
140 validated.
Note: On both Windows Vista with Service Pack 1 and Windows Server 2008, you must apply Microsoft
hotfix kb954059 (http://support.microsoft.com/kb/954059) to ensure that the random number generator
used within CryptoAPI and, therefore, the underlying operating system is FIPS 140 compliant.
The ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, defined in Internet RFC 2246 (http://www.ietf.
org/rfc/rfc2246.txt), uses RSA key exchange and TripleDES encryption.
This is achieved as follows:
According to the Microsoft documentation (http://technet.microsoft.com/en-us/library/cc750357.aspx
), FIPS-compliant systems that use FIPS 140-certified cryptomodules can be deployed by following
a prescribed set of steps. These steps include setting a particular FIPS local policy flag.
As noted in the Microsoft documentation referenced above, not all Microsoft components and
products check the FIPS local policy flag. Refer to the Microsoft documentation for instructions on how
to configure these components and products to behave in a FIPS-compliant manner.
Similarly, Citrix components do not check the FIPS local policy flag. Instead, these components must
be configured to behave in a FIPS-compliant manner.
Specifically, Citrix components that use TLS must be configured to use government ciphersuites. This
will cause the component to select one of the following ciphersuites:
RSA_WITH_3DES_EDE_CBC_SHA [RFC 2246]
RSA_WITH_AES_128_CBC_SHA [FIPS 197, RFC 3268]
RSA_WITH_AES_256_CBC_SHA [FIPS 197, RFC 3268]
Given the accuracy of the above statements, and assuming that all these steps are followed, the resulting
XenApp configuration will use FIPS 140 cryptomodules in a FIPS-compliant manner.
For a list of currently validated FIPS 140 modules, see http://csrc.nist.gov/cryptval/140-1/1401val.htm.
For more information about FIPS 140 and NIST, visit the NIST Web site at http://csrc.nist.gov/cryptval/.
9.1.3. TLS/SSL Protocols
You can secure communications between client devices and servers using either the Transport Layer
Security (TLS) 1.0 or Secure Sockets Layer (SSL) 3.0 protocols. These protocols are collectively referred
to TLS/SSL.
Both TLS and SSL are open protocols that provide data encryption, server authentication, message integrity,
and optional client authentication for a TCP/IP connection. Note that both the SSL Relay and Secure
Gateway support TLS and SSL.
SSL is an open, nonproprietary security protocol for TCP/IP connections. If you want to use the SSL Relay
to secure communications between client devices and servers within the server farm, you must install the
SSL Relay on each server in the farm. Alternatively, you can use Secure Gateway. Both the SSL Relay and
Secure Gateway implementations are discussed in this documentation.
TLS, which is also an open standard, is the latest, standardized version of the SSL protocol. The SSL Relay
also supports TLS; you can configure the SSL Relay, Secure Gateway, and the Web Interface to use TLS.
Support for TLS Version 1.0 is included in XenApp 5.0 and Password Manager 4.6.
Because there are only minor differences between TLS and SSL, the server certificates in your installation can
be used for both TLS and SSL implementations.
9.1.3.1. Government Ciphersuites
You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography
to protect sensitive but unclassified data.
For RSA key exchange and TripleDES encryption, the government ciphersuite is RSA_WITH_3DES_EDE_CBC_SHA.
Alternatively, for TLS connections, you can use Advanced Encryption Standard (AES) as defined in FIPS 197.
The government ciphersuites are RSA_WITH_AES_128_CBC_SHA for 128-bit keys
and RSA_WITH_AES_256_CBC_SHA for 256-bit keys.
9.1.4. IP Security
IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that provides authenticated
and encrypted communications with data integrity and replay protection. IPSec is a network-layer protocol set,
so higher level protocols such as Citrix ICA can use it without modification.
Although such sample deployments are outside the scope of this document, you can use IPSec to secure
a XenApp deployment within a virtual private network (VPN) environment.
IPSec is described in Internet RFC 2401.
Microsoft Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003 have built-in support
for IPSec.
9.1.5. Citrix Password Manager
Citrix Password Manager increases application security for all XenApp applications, allowing organizations
to centralize password management while providing users with fast sign-on access to Web, Windows, and
host-based applications. Password Manager is available as a standalone product and is included in
XenApp Platinum Edition.
9.1.6. Smart Cards
You can use smart cards with XenApp, supported XenApp plugins, the Web Interface, and Password Manager
to provide secure access to applications and data. Using smart cards simplifies the authentication process
while enhancing logon security. XenApp supports smart card authentication to published applications,
including smart card-enabled applications such as Microsoft Outlook.
In a business network, smart cards are an effective implementation of public key technology and can be used
for the following purposes:
Authenticating users to networks and computers
Securing channel communications over a network
Securing content using digital signatures
If you are using smart cards for secure network authentication, your users can authenticate to applications
and content published on your server farms. 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 in order to log on to a XenApp server. After users
are authenticated to the application, they can digitally sign email using certificates stored on their smart cards.
Citrix supports the use of Personal Computer Smart Card (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 that the private key and digital certificates never leave the card. In addition, you can use twofactor 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 used to prove that the cardholder
is the rightful owner of the smart card.
9.1.6.1. Smart Card Support

Citrix continues testing various smart cards to address smart card usage and compatibility issues with XenApp.
XenApp supports the Common Access Card in a deployment that includes the Citrix XenApp Plugin for
Hosted Apps for Windows. Contact your Common Access Card vendor or Citrix representative for
more information about supported versions of Common Access Card hardware and software.
Citrix tests smart cards using certificates from common certificate authorities such as those supported
by Microsoft. If you have any concerns regarding your certificate authority and compatibility with XenApp,
contact your local Citrix representative.
9.1.7. Kerberos Authentication
Kerberos is an authentication protocol. Version 5 of this protocol is standardized as Internet RFC 1510.
Many operating systems, including Microsoft Windows 2000 and later, support Kerberos as a standard feature.
XenApp extends the use of Kerberos. When users log on to a client device, they can connect to XenApp
without needing to authenticate again. The users password is not transmitted to XenApp; instead,
authentication tokens are exchanged using the Generic Security Services API (GSSAPI) standardized in
Internet RFC 1509.
This authentication exchange is performed within an ICA virtual channel and does not require any
additional protocols or ports. The authentication exchange is independent of the logon method, so it can be
used with passwords, smart cards, or biometrics.
To use Kerberos authentication with XenApp, both the client and server must be appropriately configured.
You can also use Microsoft Active Directory Group Policy selectively to disable Kerberos authentication for
specific users and servers.
9.1.8. Citrix XenApp Plugins
Updated: 2009-09-07
With the Citrix XenApp Plugin for Hosted Apps installed on their client devices, users can work with
applications running on XenApp servers. Users can access these applications from virtually any type of
client device over many types of network connection, including LAN, WAN, dial-up, and direct
asynchronous connections. Because the applications are not downloaded to the client devices (as with the
more traditional network architecture), application performance is not limited by bandwidth or
device performance.
Citrix XenApp Plugins are available for Windows, Macintosh, Linux, UNIX, and Windows CE operating systems,
and the Java Runtime Environment. Additionally, you can use the Citrix XenApp Web Plugin with Web
browsers that support ActiveX controls or Netscape plug-ins.
Citrix XenApp Plugins for Windows use cryptographic modules provided by the operating system. Other
plugins, including the Client for Java, contain their own cryptographic modules. The Client for Java can,
therefore, be used on older Windows operating systems that do not support strong encryption.
The table in Standards Summary lists the latest versions of the available plugins. The table specifies whether
each plugin is FIPS 140 compliant, supports TLS, includes smart card support, uses government
ciphersuites, supports certificate revocation checking, and supports Kerberos authentication. Note that
certificate revocation checking is applicable to plugins running on Microsoft Windows 2000, Windows XP,
and Windows Vista only. Where the latest version of a plugin does not completely supersede a previous
version (for example, a particular operating system may be supported only by an earlier plugin version),
the earlier version of the plugin is also listed.
9.1.8.1. Standards Summary
Updated: 2010-04-22
The following table summarizes the standards relevant to the various XenApp plugins:
Plugin type
FIPS 140TLS
TripleDES AES
CRL checkSmart cardKerberos
Citrix XenApp plugin

(Win32) 11.x
Citrix XenApp Web

Plugin (Win32) 11.x
(Win32) 11.x
Client for Windows CE

for Windows-Based
Terminals 10.x
Client for Windows CE

for Handheld and Pocket
PCs 10.x
Client for Macintosh 10.x
Client for Linux 10.x
Client for Java 9.x
Client for Sun Solaris 8.x
*
*
*
*
Notes:
These plugins inherit FIPS 140 compliance from the base operating system, Windows.
These plugins inherit FIPS 140 compliance from the base operating system, Windows CE.
Kerberos authentication is not supported when the Client for Java is running on Mac OS X client devices.
The table below shows the certificate source for plugins that support at least one of the security features listed
in the table above. Plugins marked OS use certificates stored in the operating system certificate store,
those marked Plugin use certificates bundled with the plugin, and plugins marked JRE use certificates stored
in the Java keystore.
Plugin type
Root certificate source
Citrix XenApp plugin (Win32) 11.x
OS
Citrix XenApp Web Plugin (Win32) 11.x
OS
Program Neighborhood (Win32) 11.x
OS
Client for Windows CE for Windows-Based Terminals 10.x OS

Client for Windows CE for Handheld and Pocket PCs 10.x
OS
Client for Macintosh 10.x
OS
Client for Linux 10.x
Plugin
Client for Java 9.x
JRE (Java 1.4.x)

JRE or OS (Java 1.5.x or later)
Client for Sun Solaris 8.x
Plugin
9.1.9. Virtual Channels

The following table shows which ICA virtual channels (or combination of virtual channels) can be used
with XenApp for authentication and application signing or for encryption methods.
Note: This table applies only to XenApp, not to Password Manager.
Smart card authentication
Smart card
virtual channel
Kerberos
virtual channel
Core ICA protocol (no

virtual channel)
Biometric authentication
Password authentication
Application signing/encryption
*
Third-party equipment is required for biometric authentication.
9.1.10. Additional XenApp Security Features

The following products can be used with XenApp to provide additional security:
SecureICA
RSA SecurID
Aladdin SafeWord
The topics below provide a brief overview of how these products can be used with XenApp. However,
these additional security measures are not included in the sample deployments. For more information about
the features of these products, refer to the relevant product documentation.
9.1.10.1. ICA Encryption Using SecureICA
ICA encryption with SecureICA is integrated into XenApp. With SecureICA, you can use up to 128-bit
encryption to protect the information sent between a XenApp server and users client devices. However, it
is important to note that SecureICA does not use FIPS 140-compliant algorithms. If this is an issue, you
can configure XenApp servers and plugins to avoid using SecureICA.
9.1.10.2. Authentication for the Web Interface Using RSA SecurID
You can use the third-party product RSA SecurID as an authentication method for the Web Interface running
on Internet Information Services. If RSA SecurID is enabled, users must log on using their credentials
(user name, password, and domain) plus their SecurID PASSCODE. The PASSCODE is made up of a PIN
followed by a tokencode (the number displayed on the users RSA SecurID token).
RSA SecurID supports authentication on both XenApp and Password Manager.
9.1.10.3. Authentication for the Web Interface Using SafeWord
You can use the third-party product Aladdin SafeWord as an authentication method for the Web Interface
running on Internet Information Services. If SafeWord is enabled, users must log on using their credentials
(user name, password, and domain) plus their SafeWord passcode. The passcode is made up of the
code displayed on the users SafeWord token, optionally followed by a PIN.
SafeWord supports authentication on XenApp, but not on Password Manager.
9.2. Deployment Samples
To make a XenApp deployment FIPS 140 compliant, you need to consider each communication channel within
the installation. The following deployment samples show how users can connect to XenApp servers with
different configurations of components and firewalls. In particular, the samples provide general guidance on
how to make each communication channel secure using TLS/SSL so that the system as a whole is FIPS
140 compliant.
Note: Secure Gateway and the SSL Relay support both TLS and SSL-based encryption. Your choice of
method is largely determined by which topology best meets the needs of your organizations security policies.
The deployment samples described in this document are as follows:
Sample A Using the SSL Relay
Sample B Using Secure Gateway (Single-Hop)
Sample C Using Secure Gateway (Double-Hop)
Sample D Using the SSL Relay and the Web Interface
Sample E Using Password Manager and Secure Gateway (Single-Hop)
9.2.1. Sample A Using the SSL Relay

Updated: 2010-03-26
This deployment uses the SSL Relay to provide end-to-end TLS/SSL encryption between the XenApp server
and the plugin.
This diagram shows sample deployment A, which uses the SSL Relay.
The deployment uses XenApp 5.0 for Microsoft Windows Server 2008. Users run the Citrix XenApp plugin 11.x
(32-bit Windows) on their client devices.
9.2.1.1. How the Components in Sample Deployment A Interact
Use TLS/SSL to secure the connections between client devices and the XenApp servers. To do this,
deploy TLS/SSL-enabled plugins to users and configure the SSL Relay on the XenApp servers.
This deployment provides end-to-end encryption of the communication between the client device and the
XenApp servers. Both the SSL Relay and the appropriate server certificate must be installed and configured
on each server in the farm.
The SSL Relay operates as an intermediary in communication between client devices and the XML Service on
each server. Each client device authenticates the SSL Relay by checking the SSL Relays server certificate
against a list of trusted certificate authorities. After this authentication, the client device and the SSL
Relay negotiate requests in encrypted form. The SSL Relay decrypts the requests and passes them to the
XenApp servers. All information sent to the client device from the servers passes through the SSL Relay,
which encrypts the data and forwards it to the client device to be decrypted. Message integrity checks verify
that each communication has not been tampered with.
This diagram shows a detailed view of sample deployment A.
9.2.1.2. FIPS 140 Validation in Sample Deployment A

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and
associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and
decrypt communication between client devices and servers. For more information about the FIPS 140 validation
of the CSPs, see the Microsoft documentation.
For Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003, TLS/SSL support and
the supported ciphersuites can also be controlled using the following Microsoft security option:
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
For more information, see the documentation for your operating system.
9.2.1.3. TLS/SSL Support in Sample Deployment A
Updated: 2010-04-13
You can configure XenApp to use either the Transport Layer Security 1.0 protocol or the Secure Sockets Layer
3.0 protocol. In sample deployment A, the components are configured for TLS.
For more information about configuring TLS, see the Citrix plugin documentation and the XenApp
Administration documentation for the SSL Relay Configuration Tool. When using the SSL Relay Configuration
Tool, ensure that TLS is selected on the Connection tab.
9.2.1.3.1. Supported Ciphersuites for Sample Deployment A
Updated: 2010-04-13
In this deployment, XenApp can be configured to use government-approved cryptography, such as the
ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data. For more
information about configuring government ciphersuites, see:
The XenApp Administration documentation for the SSL Relay Configuration Tool. When using the SSL
Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab.
The Citrix plugin documentation.
Alternatively, for TLS connections, you can use AES as defined in FIPS 197. The government ciphersuites
are RSA_WITH_AES_128_CBC_SHA for 128-bit keys and RSA_WITH_AES_256_CBC_SHA for 256-bit keys.
As defined in Internet RFC 3268 http://www.ietf.org/rfc/rfc3268.txt, these ciphersuites use RSA key
exchange and AES encryption. For more information about AES, see http://csrc.nist.gov/cryptval/des.htm.
9.2.1.3.2. Certificates and Certificate Authorities in Sample Deployment A

Updated: 2010-03-05
Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In
sample deployment A, a separate server certificate is configured for each XenApp server on which the SSL
Relay is used. A root certificate is required for each client device. For more information, see the
XenApp Administration documentation.
9.2.1.4. Smart Card Support in Sample Deployment A
In this deployment, you can configure XenApp to provide smart card authentication. To do this, you
must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.
9.2.1.5. Plugins Used in Sample Deployment A
In this deployment, users access their applications using the Citrix XenApp plugin. For more information about
the security features and capabilities of Citrix XenApp Plugins, see Citrix XenApp Plugins.
9.2.2. Sample B Using Secure Gateway (Single-Hop)
This deployment uses Secure Gateway in a single-hop configuration to provide TLS/SSL encryption between
a secure Internet gateway server and an SSL-enabled plugin, combined with encryption of the
HTTP communication between the Web browser and the Web server. Additionally, you can secure ICA
traffic within the internal network using IPSec.
This diagram shows sample deployment B, which uses Secure Gateway in a single-hop configuration.
The following table lists the components of the deployment and the operating systems required for the
servers and client devices.
XenApp farm
Components
Operating systems
XenApp 5.0 for Microsoft Windows Server
Windows Server 2008
SSL Relay enabled
Windows Server 2003 with Service Pack 2
Secure Ticket Authority installed

on XenApp server
Web server
Web Interface 5.0.1 for

Internet Information Services
Windows Server 2008

.NET Framework 3.5 or 2.0 (IIS 6.0 only)
Visual J#.NET 2.0 Second Edition
Secure
Gateway server
Secure Gateway 3.1 for Windows
Windows Server 2008

Users
client devices

for Windows 11.x
Windows Vista
TLS-enabled Web browser
9.2.2.1. How the Components in Sample Deployment B Interact

Use TLS to secure the connections between client devices and Secure Gateway. To do this, deploy
TLS/SSL-enabled plugins and configure Secure Gateway at the network perimeter, typically in a
demilitarized zone (DMZ).
Secure the connections between users Web browsers and the Web Interface using HTTPS. Additionally,
secure communication between the Web Interface and the XenApp servers using TLS.
This diagram shows a detailed view of sample deployment B.1.
In this deployment, Secure Gateway removes the need to publish the address of every XenApp server in the
farm and provides a single point of encryption and access to the farm. Secure Gateway does this by providing
a gateway that is separate from the XenApp servers and reduces the issues for firewall traversal to a
widely accepted port for ICA traffic in and out of the firewalls.
Set against the increased scalability of sample deployment B is the fact that ICA communication is encrypted
only between client devices and Secure Gateway. ICA communication between Secure Gateway and the
XenApp servers is not encrypted.
Note that the SSL Relay in sample deployment B is used to encrypt communication between the Web
Interface and the XML Service running on the XenApp servers. Secure Gateway communicates with the
XenApp servers directly, so the SSL Relay is not used for communication between Secure Gateway and the
server farm.
To comply with FIPS 140, secure the communication between Secure Gateway and the server farm using
IPSec, as shown in sample deployment B.2.
This diagram shows a detailed view of sample deployment B.2, which includes IPSec.
9.2.2.1.1. IPSec in Sample Deployment B

To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you
must configure IPSec on each server, including the Secure Gateway server.
IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment
B.2, IPSec is enabled on the requisite servers and the security method is configured for 3DES encryption and
SHA-1 integrity to meet FIPS 140 requirements.
9.2.2.2. FIPS 140 Validation in Sample Deployment B
In this deployment, the SSL Relay uses the Microsoft cryptographic service providers and
9.2.2.3. TLS/SSL Support in Sample Deployment B
Updated: 2010-04-13
You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0
protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment B, the components are configured
for TLS.
For more information about configuring TLS, see the Web Interface, Secure Gateway for Windows, and
Citrix plugin documentation.
9.2.2.3.1. Supported Ciphersuites for Sample Deployment B
Updated: 2010-04-13
In this deployment, Secure Gateway and the Web Interface can be configured to use governmentapproved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive
but unclassified data. For more information about configuring government ciphersuites, see the Secure
Gateway for Windows and Citrix plugin documentation.
9.2.2.3.2. Certificates and Certificate Authorities in Sample Deployment B
sample deployment B, one server certificate is configured on Secure Gateway and one on the Web Interface.
A certificate is also configured on each XenApp server. For more information, see the relevant
product documentation.
9.2.2.4. Smart Card Support in Sample Deployment B
9.2.2.5. Plugins Used in Sample Deployment B
9.2.3. Sample C Using Secure Gateway (Double-Hop)
This deployment uses Secure Gateway in a double-hop configuration to provide TLS/SSL encryption between
a secure Internet gateway server and an SSL-enabled plugin, combined with encryption of the
HTTP communication between Secure Gateway and the Web browser, the Web Interface, and the Secure
Gateway proxy. Additionally, you can secure ICA traffic within the internal network using IPSec.
This diagram shows sample deployment C, which uses Secure Gateway in a double-hop configuration.
XenApp farm
Components
Operating systems
Windows Server 2008
SSL Relay enabled

on XenApp server
Web server

Windows Server 2008

Secure
Gateway Service
Windows Server 2008

Secure
Gateway Proxy
Users
client devices

for Windows 11.x
Windows Vista
9.2.3.1. How the Components in Sample Deployment C Interact

Here, the DMZ is divided into two sections by an additional firewall. The server running the Secure
Gateway Service is located in the first section of the DMZ. The Web Interface and the Secure Gateway Proxy
are located in the second section. Users connect to the Secure Gateway Service located in the first section of
the DMZ.
TLS/SSL-enabled plugins and configure Secure Gateway at the network perimeter, typically in a DMZ.
This diagram shows a detailed view of sample deployment C.
To comply with FIPS 140, secure the communication between the Secure Gateway Proxy and the server
farm using IPSec.
9.2.3.1.1. IPSec in Sample Deployment C
To enable IPSec to secure communication between the Secure Gateway Proxy and the XenApp server farm,
you must configure IPSec on each server, including the Secure Gateway Proxy.
IPSec is configured using the local security settings (IP security policies) for each server. In sample
deployment C, IPSec is enabled on the requisite servers and the security method is configured for
3DES encryption and SHA-1 integrity to meet FIPS 140 requirements.
9.2.3.2. FIPS 140 Validation in Sample Deployment C
9.2.3.3. TLS/SSL Support in Sample Deployment C
Updated: 2010-04-13
You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0
protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment C, the components are configured
for TLS.
For more information about configuring TLS, see the Web Interface, Secure Gateway for Windows, and
Citrix plugin documentation.
9.2.3.3.1. Supported Ciphersuites for Sample Deployment C
Updated: 2010-04-13
In this deployment, Secure Gateway, the Secure Gateway Proxy, and the Web Interface can be configured to
use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to
protect sensitive but unclassified data. For more information about configuring government ciphersuites, see
the Web Interface, Secure Gateway for Windows, and Citrix plugin documentation.
9.2.3.3.2. Certificates and Certificate Authorities in Sample Deployment C
sample deployment C, one server certificate is configured on Secure Gateway, one on the Secure Gateway
Proxy, and one on the Web Interface. A certificate is also configured on each XenApp server. For
more information, see the relevant product documentation.
9.2.3.4. Smart Card Support in Sample Deployment C
Updated: 2010-03-05
Smart card authentication is not supported in sample deployment C. You cannot configure smart card
support when Secure Gateway is positioned between the client devices and the Web Interface to provide a
single point of access to the server farm.
For more information, see the Secure Gateway for Windows documentation.
9.2.3.5. Plugins Used in Sample Deployment C
9.2.4. Sample D Using the SSL Relay and the Web Interface
This deployment uses the SSL Relay and the Web Interface to encrypt the ICA and HTTP communication
between the XenApp server and the Web server, combined with encryption of the HTTP communication
between the Web browser and the Web server.
This diagram shows sample deployment D, which uses the SSL Relay and the Web Interface.
XenApp farm
Components
Operating systems
Windows Server 2008
SSL Relay enabled

on XenApp server
Web server

Windows Server 2008

Users
client devices

for Windows 11.x
Windows Vista
9.2.4.1. How the Components in Sample Deployment D Interact

Use HTTPS to secure the connections between users Web browsers and the Web Interface. Secure the
connection between the Web Interface and the SSL Relay using TLS.
Additionally, use TLS to secure the connections between client devices and the SSL Relay.
The SSL Relay operates as an intermediary in communication between client devices, the Web Interface, and
the XML Service on each server. Each client device authenticates the SSL Relay by checking the SSL Relay
s server certificate against a list of trusted certificate authorities. After this authentication, the client device
and the SSL Relay negotiate requests in encrypted form. The SSL Relay decrypts the requests and passes them
to the XenApp servers. All information sent to the client device from the servers passes through the SSL
Relay, which encrypts the data and forwards it to the client device to be decrypted. Message integrity
checks verify that each communication has not been tampered with.
This diagram shows a detailed view of sample deployment D.
9.2.4.2. FIPS 140 Validation in Sample Deployment D

9.2.4.3. TLS/SSL Support in Sample Deployment D
Updated: 2010-04-13
You can configure the SSL Relay and the Web Interface to use either the Transport Layer Security 1.0 protocol
or the Secure Sockets Layer 3.0 protocol. In sample deployment D, the components are configured for TLS.
For more information about configuring TLS, see:
Relay Configuration Tool, ensure that TLS is selected on the Connection tab.
The Web Interface documentation.
9.2.4.3.1. Supported Ciphersuites for Sample Deployment D

Updated: 2010-04-13
In this deployment, the SSL Relay and the Web Interface can be configured to use governmentapproved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive
but unclassified data. For more information about configuring government ciphersuites, see:
Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab.
The Web Interface documentation.
9.2.4.3.2. Certificates and Certificate Authorities in Sample Deployment D
Updated: 2010-03-05
sample deployment D, a separate server certificate is configured for each XenApp server on which the SSL
Relay is used. For more information, see the XenApp Administration documentation.
9.2.4.4. Smart Card Support in Sample Deployment D
9.2.4.5. Plugins Used in Sample Deployment D
9.2.5. Sample E Using Password Manager and Secure Gateway (Single-Hop)
Updated: 2010-04-13
This deployment uses Password Manager and Secure Gateway in a single-hop configuration to enable single
sign-on and TLS/SSL encryption between a secure Internet gateway server and an SSL-enabled plugin,
combined with encryption of the HTTP communication between the Web browser and the Web
server. Additionally, you can secure ICA traffic within the internal network using IPSec.
For further information about the Password Manager components in this deployment, see the Password
Manager documentation.
This diagram shows sample deployment E, which uses Password Manager and Secure Gateway.
Note: The Password Manager central store is hosted on two servers (primary and secondary), both
running Active Directory. The secondary server is only used to provide failover for the primary server.
XenApp farm
Components
Operating systems
Windows Server 2008
SSL Relay not enabled

on XenApp server
Java 1.4.x or later
Password Manager 4.6 with Service Pack

1 agent
Password Manager Service
Password Manager 4.6 with Service Pack
1 Service
Windows Server 2008 (32-bit)

Windows Server 2003 with Service Pack
2 (32-bit)
Windows Server 2003 R2 (32-bit)
.NET Framework 2.0
Password Manager central

Password
store
Manager 4.6 with Service Pack
1 central store
Windows Server 2008

Web server

Windows Server 2008

Secure
Gateway server
Windows Server 2008

Users
client devices

for Windows 11.x
Windows Vista
9.2.5.1. How the Components in Sample Deployment E Interact

TLS/SSL-enabled plugins and configure Secure Gateway at the network perimeter, typically in a
demilitarized zone (DMZ). Secure the connections between users Web browsers and the Web Interface
using HTTPS.
Additionally, use TLS to secure communication between the Web Interface and the XenApp server farm,
and between the farm and the Password Manager central store and Password Manager service.
Set against the increased scalability of sample deployment E is the fact that ICA communication is encrypted
only between client devices and Secure Gateway. ICA communication between Secure Gateway and the
XenApp servers is not encrypted.
To comply with FIPS 140, secure the communication between Secure Gateway and the server farm using IPSec.
This diagram shows a detailed view of sample deployment E.
9.2.5.1.1. IPSec in Sample Deployment E

To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you
must configure IPSec on each server, including the Secure Gateway server.
IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment
E, IPSec is enabled on the requisite servers and the security method is configured for 3DES encryption and SHA1 integrity to meet FIPS 140 requirements.
9.2.5.2. FIPS 140 Validation in Sample Deployment E
9.2.5.3. TLS/SSL Support in Sample Deployment E
Updated: 2010-04-13
In this deployment, you can configure Secure Gateway and the Web Interface to use the Transport Layer
Security 1.0 protocol.
For more information about configuring TLS, see the Web Interface Administration, Secure Gateway for
Windows, XenApp plugin, and Password Manager Administration documentation.
9.2.5.3.1. Supported Ciphersuites for Sample Deployment E
Updated: 2010-04-13
In this deployment, Secure Gateway and the Web Interface can be configured to use governmentapproved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive
but unclassified data. For more information about configuring government ciphersuites, see the Secure
Gateway for Windows and XenApp plugin documentation.
9.2.5.3.2. Certificates and Certificate Authorities in Sample Deployment E
sample deployment E, one server certificate is configured on Secure Gateway and one on the Web Interface.
A certificate is also configured on each XenApp server and on the server running the Password Manager
service. For more information, see the relevant product documentation.
9.2.5.4. Smart Card Support in Sample Deployment E
9.2.5.5. Plugins Used in Sample Deployment E
10. XenApp for UNIX
Updated: 2010-03-11
Quick Links
XenApp 4.0, with Feature Pack 1, for UNIX Readme
XenApp 4.0, with Feature Pack 2, for UNIX Readme

Updated: 2010-03-05
This section of eDocs contains up-to-date product information about installing, configuring, and
administering XenApp 4.0, with Feature Pack 2, for UNIX.
Learn about the following important topics.
XenApp 4.0, with Feature Pack 2,
for UNIX Release Note
Summarizes the new features and enhancements and describes

how to install or upgrade to this version. Use this release note
in conjunction with your XenApp 4.0, with Feature Pack 1, for
UNIX documentation.

for UNIX Readme
Known issues with this release of Citrix XenApp for UNIX
Third Party Attributions for

for UNIX
Compilation of third party licenses for software that may be

delivered with XenApp for UNIX
Citrix License Server Readme, for

Citrix XenApp 4.0, with Feature Pack
2, for UNIX
Installing, configuring and managing the Citrix License Server for UNIX
10.1.1. XenApp 4.0, with Feature Pack 2, for UNIX Release Note
Updated: 2010-02-23
This release note summarizes the new features and enhancements in XenApp 4.0, with Feature Pack 2, for
UNIX and describes how to install or upgrade to this version.

Use this release note in conjunction with XenApp 4.0, with Feature Pack 1, for UNIX. All the information
for Feature Pack 1 is valid for Feature Pack 2.
Known issues in this version are described in Citrix XenApp 4.0, with Feature Pack 2, for UNIX Readme.
What's New?
XenApp 4.0, with Feature Pack 2, for UNIX provides the following new features and enhancements, which are
all described in more detail in subsequent sections of this release note:
HDX Image Acceleration
Pluggable/Loadable Authentication Modules (PAM/LAM) enhancements
Advanced load balancing
HP-UX 11i v3 support
AIX 6.1 support
X clients extension
Group enumeration
XenApp for UNIX is no longer supported on Sun Solaris SPARC 8, IBM AIX POWER 5.1 and 5.2, and HP HP-UX
PA-RISC 11.0. Special extended maintenance support is available for Sun Solaris SPARC 8: for further
details please contact your Citrix representative.
Installing and Upgrading
If you are installing XenApp for UNIX for the first time, follow the installation instructions for installxau in
XenApp 4.0, with Feature Pack 1, for UNIX.
Upgrading to XenApp 4.0, with Feature Pack 2, for UNIX from all previous versions is supported, and is
described in the following sections.
Citrix recommends that you install this feature pack on all servers running XenApp 4.0 for UNIX .
The feature pack requires 15 MB of free space.
Upgrading on Solaris x86/x64
1.
Download the file to a suitable directory on the server on which you want to install the feature pack.
2.
Untar and uncompress the file by typing:
compress -dc PSE400SOLX061.tar.Z | tar xvf 3.
Ensure there are no users logged on and stop the server, using the ctxshutdown command.
4.
Log on as root.
5.
In the directory containing the PSE400SOLX061 directory, install the feature pack by typing:
patchadd -M . PSE400SOLX061
Upgrading on Solaris SPARC
1.
2.
Untar and uncompress the file by typing:
compress -dc PSE400SOL061.tar.Z | tar xvf 3.
4.
Log on as root.
5.
In the directory containing the PSE400SOL061 directory, install the feature pack by typing:
patchadd -M . PSE400SOL061
Upgrading on HP-UX
1.
2.
Untar the file by typing:
tar -xvf PSE400HPUX061.tar

This creates a file called PSE400HPUX061.depot.
3.
4.
In the directory containing the file PSE400HPUX061.depot, install the hotfix by typing:
swinstall -s `pwd`/PSE400HPUX061.depot PSE400HPUX061

5.
6.
Log on as root.
Once the installation is finished, check that the hotfix is among the list of Citrix products installed
by typing:
swlist | grep Citrix
Upgrading on AIX
1.
2.
Untar the file, by typing:
tar -x -v -f PSE400AIX061.tar
This creates a file called Citrix.MetaFrame.4.0.0.61.bff.
3.
4.
Log on as root.
5.
Citrix recommends that you use SMIT to install the .bff file. If the installation fails, one reason may
be that it was unable to produce the .toc file that it needs. To work around this, run the following
command in the directory where you have placed the .bff file:
inutoc `pwd`
Run the smit command and select "Software Installation and maintenance", then "Install and
Update Software", then "Install Software".
6.
Input the path of the .bff file described in step 2. You will then be prompted by a series of flags you
must set to Yes or No.
All flags can be left at their default settings except "COMMIT software updates", which has to be set to
No to install the patch as a separate component so that it can be removed.
Making New Features Available

If you upgrade to Feature Pack 2, as opposed to running a fresh installation, then to make the new
features available you must run the following command after completing the upgrade:
ctxlsdcfg -m FeaturePack2
This makes the features available on every server in the farm on which you have installed the feature pack.
HDX Image Acceleration
HDX Image Acceleration lets you find a balance between the quality of photographic image data as it appears
on a user's device and the amount of bandwidth the images consume on their way from server to client.
Image Acceleration applies a lossy compression scheme to reduce the amount of image data that the
server sends to the client for faster screen updates. The compression scheme removes redundant or
extraneous data from the images while attempting to minimize the perceptible loss of information. Under
most circumstances, the data loss is barely visible 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.
Lossy compression is enabled only when available throughput for a connection falls below the specified number
of bytes per second. To specify the number, log on as an administrator, then at a command line type:
ctxcfg -k lossycompthreshold=n
where n = any number from 0 to 104857600 (100 MB). The default value is 0, which means the feature is off.
To specify the compression quality, log on as an administrator, then at a command line type:
ctxcfg -k lossycompquality=n
where n = any number from 20 to 95. The default value is 85. Choose high values for users who need to
view images at a level near original quality. To achieve faster updates over slow links, choose lower values.
The default value provides medium compression, giving good image quality and low bandwidth usage.
You must set the threshold and quality on each individual server in the farm.
For lossy compression to be used, this feature must also be supported and enabled on the client.
PAM/LAM Enhancements
Pluggable/Loadable Authentication Modules (PAM/LAM) allow you to select the authentication service you want
to use, and plug-in and make available new authentication service modules without having to modify
your applications. Solaris and HP-UX use PAM for user name and password validation. AIX has its
own authentication framework, which is called the LAM system and provides similar functionality.
The integration of PAM and LAM with XenApp for UNIX's authentication process has been enhanced as follows:
User-specific PAM and LAM information messages can be displayed to the user in a popup dialog
box. Examples include password expiry notices and messages informing the user that an account is
locked. These messages are specific to the PAM and LAMs in use and are separate to XenApp for
UNIX messages. By default, the messages are not displayed. To display the messages, log on to
the relevant server as an administrator, then at a command line type:
ctxcfg -k authdialogs=1
A more extensive set of system administrator PAM and LAM error messages is now automatically gathered and logged
XenApp for UNIX sessions can be authenticated through two methods: direct, using the ctxlogin process,
and indirect, using the XML service. The enhancements provided with this version are available only when you
are using direct authentication.
Advanced Load Balancing
You can build on the standard XenApp for UNIX load balancing capabilities based around the number of
sessions on each server to take into account actual system load as reported by the 1, 5 and 15 minute run
queue averages. These advanced capabilities can be used in isolation from the actual number of sessions or
in conjunction with them to build up highly tuneable load balancing criteria.
You can base the way the server load is calculated on a number of parameter settings; you can control the
effect of those settings on the server load by assigning a series of weightings to each parameter that establish
its importance compared to the other parameters.
The ctxbal utility is provided to set and adjust the load balancing parameters in the following ways:
Maximum number of user sessions allowed
The weight to be applied to user sessions, 1 minute run queue averages, 5 minute run queue
averages, and 15 run queue averages
The bias value to be applied to the load
Load factor
For more information on how to use advanced load balancing, including configuration and monitoring
examples, see http://support.citrix.com/article/CTX123584.
HP-UX 11i v3 Support
XenApp 4.0, with Feature Pack 2, for UNIX supports HP-UX 11i v3 on HP PA-RISC.
If installation of XenApp for UNIX fails because of installation dependencies, retry installing with
dependency checking suppressed. Citrix advises that you use this option only when there is no
alternative solution.
To install XenApp for UNIX with dependency checking suppressed, use installxau with the -d option. This option
is recognized only on HP-UX.
For Client Drive Mapping (CDM) to work, version 8 of Open Network Computing (ONC) must be installed. This
is available at http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ONCplus.
To verify whether your system has the correct ONC version installed, use this command:
/usr/sbin/swlist -l fileset |grep ONC

If the output looks like this:
NFS B.11.31.08 ONC/NFS; Network-File System,Information Services,Utilities

you have version 8 installed and CDM will work correctly.
AIX 6.1 Support
XenApp 4.0, with Feature Pack 2, for UNIX supports AIX 6.1 on IBM AIX POWER.
X Client Extension
You can configure the maximum number of clients an X server can accept. To specify the number of
clients allowed, for each server, add -maxclients xxx to the XTW_OPTS line in the file ctxXtw.sh, where xxx is
the maximum number of clients.
The default is 256. Any values lower than 256 are ignored. The maximum value is either 1024, or the
maximum number of file descriptors the X server is allowed to have open, whichever is the lower. On
most systems you will need to use the ulimit command to increase the soft limit for the number of open
file descriptors allowed per process, to allow maxclients values of greater than 256 to take effect.
Group Enumeration
You can configure how groups files are processed by XenApp for UNIX servers by using the ctxcfg k fullyenumerategroups=[0|1] parameter on each server.
By default, this is set to 1 and the server reads the entire groups database before processing user logons
and other actions. If you do not want the server to read the entire groups database, set the value to 0.
In some cases, group authentication mechanisms such as NIS or LDAP do not always supply accurate
information when processed by some standard OS facilities. This flag ensures accurate group processing
is performed. Note that this can result in longer authentication times.
Updated: 2010-02-23
Readme Version: 1.0
This file contains the latest information relating to Citrix XenApp 4.0, with Feature Pack 2, for UNIX. Please
read this file fully before using Citrix XenApp 4.0, with Feature Pack 2, for UNIX. It contains important
information that may be more up to date than other documentation you have available.
Contents
What's Included
Finding Documentation
Getting Support
Usage Notes, Restrictions, and Known Issues
What's Included
XenApp 4.0, with Feature Pack 2, for UNIX includes:
On the Solaris SPARC platform, a Solaris package in the solaris directory on the CD-ROM.
On the Solaris x86/x64 platform, a Solaris package in the solaris_x86 directory on the CD-ROM.
On the AIX platform, a SMIT installable package in the usr/sys/inst.images directory on the CD-ROM.
On the HP-UX platform, a HP-UX Software Distributor Depot in the hpux directory on the CD-ROM.
On all platforms, a Citrix XenApp for UNIX installation script called installxau in the top level directory
on the CD-ROM.
On all platforms, hotfix packages in the hotfixes directory on the CD-ROM.
The Citrix License Server for UNIX in the ctxls directory on the CD-ROM.
To access complete and up-to-date product information, go to Citrix eDocs located at http://support.
citrix.com/proddocs/index.jsp and expand the topics for your product.
After installing XenApp for UNIX, you can also view man pages for specific XenApp commands.
Getting Support
Citrix provides technical support primarily through Citrix Solutions Advisor. Contact your supplier for firstline support or use Citrix Online Technical Support to find the nearest Citrix Solutions Advisor.
Licensing Issues
To license Citrix XenApp 4.0, with Feature Pack 2, for UNIX, you require Enterprise or Platinum edition licenses.
If you are covered by Subscription Advantage dated 17th March 2010 or later, you can use your licenses
for XenApp 4.0, with Feature Pack 2, for UNIX on Solaris SPARC, Solaris x86/x64, AIX POWER, or HP-UX PA-RISC.
The Citrix License Server for UNIX, which runs on Solaris 9, SPARC version, and Solaris 10, x86/x64 or
SPARC versions, is available from the Citrix Web site. Choose Downloads > Citrix Licensing and select the
License Server for UNIX.
Hotfix Packages
This release installs all hotfixes up to, and including, PSE400xxx061.
The hotfix packages, included on the CD-ROM, contain functional changes for the Feature Pack 2 release and
are installed with the main product when using the installxau product installation script. Do not attempt to
install the hotfix packages separately. All features included in these hotfix packages are described in the
XenApp for UNIX documentation at http://support.citrix.com/proddocs/topic/xenapp/ps-unix-wrapper-allversions.html.
Known Issues
Restart ctxload each time you change the ctxbal parameters. The ctxload utility is a tool that tracks and
graphs the load balancing value over time. However, when ctxbal is used to change the way the load value
is calculated, this is not automatically reflected in the ctxload graphical output. To address this issue, stop
and retart ctxload. The load is then logged correctly against the new ctxbal criteria.
Installation issues on HP-UX 11i. Dependency errors may prevent the installation of XenApp for UNIX on HP-
UX 11i platforms. This problem occurs because of the way Java 1.4 and 1.5 are packaged on HP's
distribution DVDs. swinstall checks that any prerequisite or co-requisite software is complete, but on a PA
system only the PA binaries and libraries are installed for Java; thus an error is generated. To address this
issue, use the workaround involving the installxau -d option, as described in the XenApp 4.0, with Feature Pack
2, for UNIX Release Note. Alternatively, you can either install the IA versions of the binaries, which will
increase disk usage, or download PA-only versions of these binaries from http://www.hp.com/go/java.
Installation issues on AIX. There is an issue with the AIX installer where installations on systems with only Java
6 installed may fail. To address this issue, install Java 5 or Java 1.4 before installing XenApp for UNIX.
After installation of XenApp for UNIX is complete, you can remove the Java 5 or Java 1.4 distribution, leaving
the Java 6 distribution intact.
10.1.3. Licensing XenApp for UNIX
Updated: 2010-01-05
Citrix License Server for UNIX provides licenses for Citrix XenApp 4.0 for UNIX and any feature packs released
for this version.
The License Server for UNIX package includes:
An install package, CTXSls. This is available on the XenApp for UNIX installation media, or you
can download it from http://www.citrix.com/English/ss/downloads/details.
asp?downloadId=1681208&productId=186&c1=pov1680320.
Documentation: the FLEXnet License Administration Guide. The installed location for this guide
is /opt/CTXSls/docs/FNP_11.5_LicenseAdministration.pdf.
For general information on Citrix Licensing, see Licensing Your Product. In this general set of topics, one of
the main differences between the UNIX installation and the Windows installation is the file locations. The
following table compares their locations:
File
Location on Windows (32-bit)
Location on UNIX
Vendor options file
C:\Program
Files\Citrix\Licensing\MyFiles\CITRIX.opt
/etc/opt/CTXSls/CITRIX.opt
Citrix start-up license file
C:
/etc/opt/CTXSls/citrix_startup.lic
\Program Files\Citrix\Licensing\MyFiles\citrix_startup.lic
License files
C:\Program Files\Citrix\Licensing\MyFiles\*.lic
/etc/opt/CTXSls/*.lic
Citrix vendor daemon

log file
C:
\Program
Files\Citrix\Licensing\LS\lmgrd_debug.log
/var/CTXSls/lmgrd_debug.log
Hardware Requirements
Requirements vary depending on the number of XenApp for UNIX servers using this license server. Any
server capable of running XenApp for UNIX on the Solaris platform can run this license server.
For details about selecting a server, see the FLEXnet License Administration Guide.
Software System Requirements
The license server (32-bit only) is supported on:
Solaris 9, SPARC version
Solaris 10, x86/x64 or SPARC versions
Citrix recommends that you install the latest patches for the operating system that you are using. For
information and downloads, see the Sun Microsystems, Inc. Web site.
Installing the License Server
1.
Create the following groups and users. They can be either local accounts or remote accounts: for
example, NIS, NIS+, or LDAP.
1.
The lmadmin license server administrator group. Add the users that you want to
become administrators to this group. This group is required by license server commands
that demand special administration rights, but do not require root access to the UNIX system.
The users in this group log on with their normal user accounts.
A ctxlsadm user. Add the user to the lmadmin group.
Citrix recommends, for security reasons, that you disable logons for ctxlsadm user. If you do so,
install licenses as root.
2.
Log on as root on the server where you want to install the license server.
3.
Change to the directory containing the package.
4.
Run /usr/sbin/pkgadd -d CTXSls
5.
At the prompt, type all (or press Enter to accept all as the default).
6.
At the Do you want to install these as setuid/setgid files? prompt, type y to set the correct
file permissions for the files and processes. Do not type n, because this causes the license server
to operate incorrectly.
7.
At the Do you want to continue with the installation of <CTXSls> prompt, type y. Do not type n
, because this causes the license server to operate incorrectly.
The installation continues until complete and a success message appears. An error message appears if
the installation is not successful.
Do not overwrite or remove the Citrix start-up license file, /etc/opt/CTXSls/citrix_startup.lic. This file is
necessary for the license server to run correctly.
Configuring the License Server
You can configure the license server lmstart and lmstop scripts by editing the /etc/opt/CTXSls/lm.conf file,
in which you will find an explanation of the options that are available.
Uninstalling the License Server
1.
Log on as root on the server on which you installed the license server.
2.
Stop the license server by typing /opt/CTXSls/sbin/lmstop.
3.
Run /usr/sbin/pkgrm CTXSls.
4.
At the Do you want to remove this package? prompt, type y.
5.
At the Do you want to continue with the removal of this package prompt, type y. Do not type n
, because the uninstall may fail. The uninstall continues until complete and a success message appears.
An error message appears if the uninstall is not successful.
After you uninstall the license server, if you customized any configuration files and installed user licenses,
remove the files from /etc/opt/CTXSls.
Obtaining your License Files
License files are downloaded and managed through the Citrix Activation System at http://www.mycitrix.com/.
For information about obtaining your license files, see Licensing Your Product.
Installing your License Files
As either the root or the ctxlsadm user, copy the downloaded license files into the /etc/opt/CTXSls directory.
The ctxlsadm user and lmadmin group must have read access to the files. If the files were copied as root, run
the following commands to set the permissions correctly:
chown ctxlsadm:lmadmin [license files]
chmod 640 [license files]
If a license file is copied into the /etc/opt/CTXSls directory after the license server is started, the license
server needs to be stopped and restarted, or the /opt/CTXSls/sbin/lmreread -c [license file] command can
be used to reread the license files. The option argument to the -c option can either be the
/etc/opt/CTXSls directory, which will cause the rereading of all license files in that directory, or it can be
an individual license file in that directory. Multiple -c options can be specified on the command line.
Starting the License Server
Any user in the lmadmin group, or root, can start the license server by running the
/opt/CTXSls/sbin/lmstart command.
By default, a log file (/var/CTXSls/lmgrd_debug.log) is generated after the license server starts. This log
file contains basic information about licenses in use. It also logs any rejected license requests.
Stopping the License Server
Any user in the lmadmin group, or root, can stop the license server by running the
/opt/CTXSls/sbin/lmstop command.
Starting the License Server on a System Restart
The license server package automatically configures the system to restart the license server on system restart.
To disable this functionality, remove the hard-linked files:
/etc/rc2.d/K02CTXSls
/etc/rc2.d/S98CTXSls
To reenable this functionality, run the following commands:
ln /etc/init.d/CTXSls /etc/rc2.d/K02CTXSls
ln /etc/init.d/CTXSls /etc/rc2.d/S98CTXSls
Viewing License Usage
You can view license usage by running the /opt/CTXSls/bin/lmstat command. In addition, add the -a option
to display all checked out licenses.
For example:
bash-3.00$ lmstat -a
lmstat - Copyright ) 1989-2007 Macrovision Europe Ltd. and/or Macrovision Corporation. All Rig
Flexible License Manager status on Tue 3/11/2008 17:10
License server status: 27000@sporty
License file(s) on sporty:
/etc/opt/CTXSls/MPS_MCM_ALL_EDITION_PROD.lic:/etc/opt/CTXSls/citrix_startup.lic:
sporty: license server UP (MASTER) v11.5
Vendor daemon status (on sporty):
CITRIX: UP v11.5
Feature usage info:
Users of MPS_PLT_CCU: (Total of
Users of MPS_ENT_CCU: (Total of
Users of MPS_STD_CCU: (Total of
Users of MPS_ADV_CCU: (Total of
Users of MCM_STD_CCU: (Total of
Users of CITRIX: (Total of 5000
1000 licenses issued; Total

licenses issued; Total of 0
Backing Up Your Files

Back up the following files:
/etc/opt/CTXSls/CITRIX.opt
/etc/opt/CTXSls/lm.conf
Any administrator-installed license files in /etc/opt/CTXSls
of 0 licenses in
of 0 licenses in
of 0 licenses in
of 0 licenses in
of 0 licenses in
licenses in use)
use)
use)
use)
use)
use)

Updated: 2010-01-22
This section of eDocs contains up-to-date product information about installing, configuring, and
administering Citrix XenApp 4.0, with Feature Pack 1, for UNIX.
Learn about the following important topics.
1, for UNIX Readme
Known issues with this release of Citrix XenApp for UNIX
Administration
Install, configure and maintain Citrix XenApp for UNIX
SSL Relay for UNIX Administration
Plan, configure and maintain SSL Relay for XenApp for UNIX
Third Party Attributions, for

1, for UNIX
Compilation of third party licenses for software that may be

delivered with XenApp for UNIX
Citrix License Server Readme, for

1, for UNIX
Installing, configuring and managing the Citrix License Server for UNIX
Updated: 2010-01-21
Readme Version: 1.0
This file contains the latest information relating to Citrix XenApp 4.0, with Feature Pack 1, for UNIX. Please
read this file fully before using Citrix XenApp 4.0, with Feature Pack 1, for UNIX. It contains important
information that may be more up to date than other documentation you have available.
Contents
What's Included
Getting Support
Whats Included
XenApp 4.0, with Feature Pack 1, for UNIX includes:
On the Solaris SPARC platform, a Solaris package in the solaris directory on the CD-ROM.
On the Solaris x86/x64 platform, a Solaris package in the solaris_x86 directory on the CD-ROM.
On the AIX platform, a SMIT installable package in the sr/sys/inst.images directory on the CD-ROM.
On the HP-UX platform, a HP-UX Software Distributor Depot in the hpux directory on the CD-ROM.
On all platforms, a Citrix XenApp for UNIX installation script called installxau in the top level directory
on the CD-ROM.
On all platforms, hotfix packages in the hotfixes directory on the CD-ROM.
The Citrix License Server for UNIX on the CD-ROM.
To access complete and up-to-date product information, go to Citrix eDocs located at http://support.
citrix.com/proddocs/index.jsp and expand the topics for your product.
After installing XenApp for UNIX, you can also view man pages for specific XenApp commands.
Getting Support
Citrix provides technical support primarily through Citrix Solutions Advisor. Contact your supplier for first-
line support or use Citrix Online Technical Support to find the nearest Citrix Solutions Advisor.
Licensing Issues
To license Citrix XenApp 4.0, with Feature Pack 1, for UNIX, you require Enterprise or Platinum edition licenses.
If you are covered by Subscription Advantage dated 27th April 2005 or later, you can use your licenses for
Citrix Presentation Server for UNIX Version 4.0, Solaris SPARC, AIX, or HP-UX.
If you are covered by Subscription Advantage dated 22nd February 2007 or later, you can use your licenses
for Citrix Presentation Server for UNIX Version 4.0 or later on any supported platform, including Solaris x86/x64.
The Citrix License Server for UNIX, which runs on Solaris 8, SPARC version, Solaris 9, SPARC version, and
Solaris 10, x86/x64 or SPARC versions, is available from the Citrix Web site. Choose Downloads > Citrix
Licensing and select the License Server for UNIX.
Hotfix Packages
This release installs all hotfixes up to, and including, PSE400xxx054.
The hotfix packages, included on the CD-ROM, contain functional changes for the Feature Pack 1 release and
are installed with the main product when using the installxau product installation script. You should not
attempt to install the hotfix packages separately. All features included in these hotfix packages are described
in the XenApp for UNIX documentation at http://support.citrix.com/proddocs/topic/xenapp/ps-unix-wrapperall-versions.html.
Known Issues
By default, XenApp for UNIX is now compatible with other Citrix license sharing mechanisms. However,
changing the compatibility setting affects the way licenses are allocated by the license server. For this
reason, Citrix recommends that you ensure all users are logged off, before running the ctxsldcfg -c command.
For more information, see the XenApp for UNIX documentation at http://support.
citrix.com/proddocs/topic/xenapp/ps-unix-wrapper-all-versions.html. [# 195309]
10.2.2. XenApp for UNIX Administration
Updated: 2010-01-22
This section contains up-to-date product information about installing, configuring, and administering
Citrix XenApp 4.0, with Feature Pack 1, for UNIX. These topics are for system administrators responsible
for deploying and maintaining Citrix XenApp for UNIX.
Introducing XenApp for UNIX
Configuring XenApp for UNIX
Deploying XenApp for UNIX
Advanced Topics
Introducing Server Farms
Using the Citrix XML Service
Licensing XenApp for UNIX
Using Client Drive Mapping
Publishing Applications and Desktops
Command Reference
Managing Servers, Users, and Sessions

10.2.2.1. Introducing XenApp for UNIX
Updated: 2010-01-22
Citrix XenApp for UNIX is a server-based software product that you can use to provide your users
with uninterrupted, secure access to UNIX and Java applications.
You install XenApp on a UNIX computer that will be used as a server. Sun Solaris, HP-UX, and IBM AIX
platforms are supported. XenApp allows multiple users to log on and run applications in separate,
protected sessions on the same server. For example, you may want to make word processors, Web
browsers, Java applications, a particular window manager, or custom applications available to users.
You install the plugin software on the client devices, so users can connect to the server from a client device,
such as a Windows PC. The plugin software is provided free, and is available for a range of different devices.
This allows users to connect to the server from various platforms.
XenApp uses the ICA protocol to send information between the client device and the server. The ICA
protocol sends keystrokes, mouse clicks, and screen updates between the server and the client. The
application processing remains on the server, which means that processing on the client is kept to a minimum.
To the user of the client device, it appears as if the software is running locally on the client.
Because applications run on the server and not on the client device, users can connect from any client device.
A Macintosh, a Windows PC, or another UNIX computer can be used; the application looks and feels the same
on each client device.
10.2.2.1.1. Key Features
Updated: 2010-03-26
This topic describes the key features and benefits of using XenApp for UNIX.
Rapid application deployment. You can provide your users with access to UNIX and Java applications by
publishing these applications using XenApp for UNIX. A published application is a predefined application or
shell script and its associated environment. To access a published application, users connect to it using
the software on the client device. The application runs in a separate, protected session on the server. When
the user exits the application, the session closes.
User access to UNIX desktops. You can provide users with full access to the UNIX server desktop. Users
can run any application available on the desktop, in any order, or simultaneously. The server desktop appears
in a window on the client device.
Integration with UNIX security and accounts. XenApp uses the security setup on the UNIX server.
Therefore, you do not need to set up new user accounts for XenApp. Users at the client device can log on
using their existing UNIX user account and password. Solaris and HP-UX use Pluggable Authentication
Modules (PAM) for user name and password validation; AIX uses its own authentication mechanism. Note
that XenApp supplies the user name and password for authentication; if additional information is required for
the authentication process, this is not supported. For more information about configuring PAM on Solaris and
HP-UX computers, see the man page for PAM. For AIX, see the man page for authenticate.
Special group and account for Citrix administrators. XenApp requires you to create a special user group
with the authority to run administration commands and start and stop the server. This is the administrator
group, which is called ctxadm. The user ctxsrvr must be created and added to this group.
Configurable permissions for access to features. You can control which users or groups of users can
use particular XenApp features, such as logging on, disconnecting, and sending messages to other sessions,
using the XenApp security feature. See Configuring XenApp Security for further information.
Guest user access. XenApp includes special anonymous user accounts with limited permissions. You can
use these accounts to provide users with guest access to published applications and a temporary
working directory for use during the session.
Shadowing user sessions. You can display and interact (using your keyboard and mouse) with another user
s session from your own session. This feature is called shadowing. You can use shadowing to help remote
users with training or technical support issues.
Copying text and graphics between applications. Users can copy text and graphics between serverbased applications and applications running locally on the client device. The clipboard behaves as if
all applications are running on the client device itself.
Load balancing among servers. You can publish the same application on a number of servers. Users connect
to the published application and XenApp ensures that the connections are distributed among servers so that
a particular server does not become overloaded. You can also tune the distribution of connections among a
group of load balanced servers.
SSL security. XenApp for UNIX includes support for SSL Relay, which allows you to secure communications
using Version 3.0 of the Secure Sockets Layer (SSL) protocol. SSL provides server authentication, encryption
of the data stream, and message integrity checks. You can use SSL Relay to secure communications between
an SSL-enabled client device and a XenApp server, or in a Web Interface deployment, between the Web
server and a XenApp server.
Support for RSA SecurID. Support for RSA SecurID Versions 4.2 and 5.0 is included, allowing your users to
log on to XenApp computers using RSA SecurID authentication.
XML Service and Web Interface deployment. XenApp for UNIX includes support for the Citrix XML
Service. The Citrix XML Service communicates information about the UNIX applications published in a server
farm to the Web server component of the Web Interface deployment. The Citrix XML Service also provides
users with HTTP (HyperText Transport Protocol) browsing.
Support for server farms. Server farm support provides powerful, enterprise-level management
and administration capabilities by allowing you to group XenApp servers into server farms that can be
managed as a single unit. This means you can easily configure features and settings for the entire farm, from
a central location, rather than configuring each server individually. For example, you can publish the
applications or resources you want to make available to users at the farm level, establishing configuration
settings that pertain to all instances of the application running in the farm.
10.2.2.1.2. Whats New in Feature Pack 1 for Version 4.0?
Updated: 2009-11-23
Feature Pack 1 for Version 4.0 provides a number of new features and enhancements that together extend
the capabilities and flexibility of XenApp for UNIX. These include:
Message of the day facility. This feature allows you to specify a message of the day to display to users as
they log on. Text stored in /var/CTXSmf/motd appears in a message box before logon, up to a maximum size of
2 KB.
Disable new logons. This feature allows you to prevent any new logons to a particular server, though users
can still reconnect to disconnected sessions. See Disabling New Logons to a Server for more information
about configuring this feature.
ICA stack enhancements. These enhancements provide increased connection stability and greater
stack throughput on heavily loaded servers.
10.2.2.1.3. UNIX Command-Line Conventions
Citrix XenApp for UNIX has a command-line interface, which means you type the commands to control the
server at a command prompt. If you are not familiar with UNIX command lines, note that:
All UNIX commands are case sensitive
The spacing on the command line is important and must be followed exactly as described in
the instructions
Note: Run only one instance of some XenApp for UNIX commands at any one timethese are the
commands that cause configuration changes (rather than commands that just query and display
information). If more than one instance runs simultaneously, you may get unpredictable results.
10.2.2.1.4. Getting Started Quickly
Updated: 2009-11-30
This topic provides an overview of the minimum steps required to install and set up a server running XenApp
for UNIX. For full details of how to install XenApp, including step-by-step installation and
configuration instructions, see Deploying XenApp for UNIX. Citrix recommends that you read this topic
before installing XenApp for the first time.
1.
Configure a Citrix License Server. Citrix recommends that you do this before you install XenApp for
UNIX so that you can tell the installer script the details of the license server. If you set up a license
server after installing XenApp, you will need to use the ctxlsdcfg command to configure
communication with the license server manually. For more information about configuring a license
server, see Licensing XenApp for UNIX. and Getting Started with Citrix Licensing.
2.
Consider the design of the server farm. For example, because the server that you create the farm on
will become the Management Service Master (the server with authoritative control of the farm), ensure
that you create the farm on an appropriate server. For more information about server farms, see
Introducing Server Farms.
3.
Set up the accounts for the administrator. Use the standard UNIX system tools to do this. Log on as
root and create a group called ctxadm, and add the users that you want to become administrators to
this group. You must also create a ctxsrvr user and add this to the ctxadm group. If you do not set
up these accounts, the installer script can do this for you. For information about setting up the
accounts, see Creating the Administrator Users and Group.
4.
Install the XenApp software on your UNIX server. The easiest way to do this is by using the installer
script, which guides you through each step and prompts you for the information that it requires.
For information about installing XenApp, see Installing XenApp.
5.
Start XenApp on the server using the command ctxsrv start all.
6.
Install the plugin software on each client device you plan to use from the XenApp installation media,
or from the Citrix Web site. For information about installing plugins, see the installation topic in
the administrators guide for the plugin you plan to deploy.
7.
After installing the plugin software, create ICA connections to your server and test that you can
connect from each type of plugin. For information about creating a connection from a client device to
a server, see the administrators guide for the appropriate plugin.
When you can connect to your server from a client device, your server is operational.
Note: There is an administrators guide for each plugin in the documentation directory on your
XenApp installation media.
10.2.2.2. Deploying XenApp for UNIX

Updated: 2009-11-30
These topics describe how to install XenApp for UNIX and carry out initial tasks such as creating
administrative users and groups, setting the paths to XenApp commands and man pages, and configuring
event logging. They also provide details of how to remove XenApp.
10.2.2.2.1. Before You Begin Installing
Updated: 2009-11-23
Make sure that you read the following information before installing XenApp:
Licensing XenApp for UNIX. If you intend to use the installer script, Citrix recommends that you set up
the Citrix License Server before you install XenApp. If you do this before installing XenApp, the
installer script configures communication with the license server for you. If you do it after, you need to
use the ctxlsdcfg command to configure communication with the license server manually. For
more information about setting up a license server, see Getting Started with Citrix Licensing.
Introducing Server Farms. Consider the design of your server farm before installing XenApp. For
example, because the server that you create the farm on will become the Management Service Master
(the server with authoritative control of the farm), ensure that you create the farm on an
appropriate server.
UNIX Operating System Requirements. The UNIX Operating System must be installed before you
install XenApp. You must also ensure that your operating system is configured to run XenApp, and that
you install the required updates, as listed in this topic.
Creating the Administrator Users and Group. Unless you intend to use the installer script to install
XenApp, you must create the ctxadm group and the ctxsrvr and ctxssl users before you
begin installation.
Note: Make sure that all users who connect to the server have a home directory path that is valid on
the server, and that can be written to by the user.
If a user has no home directory and tries to connect, the logon fails. Note that you can configure
the server to allow users whose home directories are unavailable to log on; for more information, see
Allowing Users to Log on without a Home Directory.
10.2.2.2.2. System Requirements

Updated: 2009-10-20
These topics list the minimum hardware and software system requirements for XenApp for UNIX. They
include information about required operating system patches, Java Runtime Environment requirements,
SSL Relay requirements, and Euro-currency symbol support.
10.2.2.2.2.1. Hardware Requirements
Updated: 2009-10-05
The minimum computer specification depends upon how many connections are to be supported. As a general
rule, Citrix recommends that each server has between 16 and 24 MB of RAM per ICA connection. However,
you may need to increase this amount of RAM depending upon the type of applications your users are
running and the session properties, such as color depth and size.
Note: On the Solaris SPARC platform, XenApp for UNIX is supported only on processors based on SPARC
V8 architecture or later.
10.2.2.2.2.2. Software Requirements
Updated: 2009-11-19
Operating System Patches
Citrix recommends that you install the latest patches for the operating system you are using. For information
and downloads, see your operating system manufacturers Web site.
On Solaris 8 SPARC, to prevent sessions from freezing when running XenApp, apply patch 108993-37 (or
later). This patch is available from the Sun Microsystems Web site.
Java Runtime Environment Requirements
Citrix recommends that you install the latest patches for the Java runtime environment (JRE) you are using.
For all platforms, ensure that the JRE installed on your system is Version 1.4.2. or higher. To obtain JRE
versions, see the Web site for your operating system manufacturer.
On the Solaris platform, do not use the 64-bit Solaris JRE. XenApp for UNIX is compatible with the 32-bit
Solaris JRE only.
On the AIX platform, XenApp for UNIX runs only with JRE Version 1.4.2 (any patch level).
On the HP-UX platform, you must use a JRE of 1.4.2.08 or lower when installing XenApp for UNIX. Using a JRE
of 1.4.2.09 or later will result in a Java compatibility error when the ctxxmld daemon is started. After
installation, you can apply a later JRE version and install the latest public hotfix that addresses this issue.
The hotfix is available from the Citrix Web site: http://support.citrix.com/.
Note: Some platforms may require prerequisite patches for the JRE. See the Web site for your
operating system manufacturer or contact your hardware vendor for details about the appropriate patches.
On the Solaris Platform
The Solaris edition of XenApp for UNIX requires one of the following:
Solaris 10, x86/x64 or SPARC versions
Note: The Solaris x86/x64 edition of XenApp for UNIX is available only on Solaris 10.
The server must have an X Window system installed with the appropriate window manager for the platform;
for example, CDE.
The following operating system packages are required:
SUNWxwoftX Window System optional fonts
SUNWuiu8Iconv modules for UTF-8 locale
Verify that these packages are installed using the pkginfo command.
Note: On Solaris 8, these two packages are installed when you do an end-user install.
The Iconv libraries must be installed; they are necessary for XenApp to run. Check that the following files exist
in the /usr/lib/iconv folder:
UCS-2*.so UTF-8*.so 8859-1*.so
On the HP-UX Platform
The HP-UX edition of XenApp for UNIX requires:
HP-UX Version 11
HP-UX 11i
for example, CDE.
Note: Due to an HP-UX system limitation, you cannot specify server names of more than eight characters
when running XenApp for UNIX on the HP-UX operating system.
On the AIX Platform
The AIX edition of XenApp for UNIX requires AIX Versions 5.1, 5.2, or 5.3.
for example, CDE.
10.2.2.2.2.3. SSL Relay Requirements
SSL Relay for UNIX is included automatically when you install XenApp for UNIX. SSL Relay provides
server authentication, encryption of the data stream, and message integrity checks. The system requirements
for SSL Relay are the same as for XenApp for UNIX. For more information, see the Citrix XenApp SSL Relay
for UNIX Administrators Guide.
10.2.2.2.2.4. Euro Currency Symbol Support
XenApp supports the ISO 8859-15 Euro-currency symbol, if the underlying UNIX operating system supports it.
To ensure this support, you may need to install patches recommended by your operating system and
hardware vendor. See the Web site for your operating system manufacturer or contact your hardware vendor
for details about the appropriate patches and for instructions to ensure Euro symbol support.
10.2.2.2.3. Installing XenApp
Updated: 2009-10-20
You need to perform the following steps to install XenApp:
1.
2.
3.
4.
If you are installing XenApp for the first time, create the administrator user and group accounts.
However, if you intend to use the installer script to install XenApp, the script creates these for you.
Install XenApp from the installation media.
If you are installing XenApp for the first time, add the XenApp path(s) to your path, so that you can
run the commands.
Start the XenApp processes on the server.
10.2.2.2.3.1. Creating the Administrator Users and Group

Updated: 2009-10-06
Before you install XenApp, create the XenApp ctxadm administrator group and add the users that you want
to become administrators to this group. The ctxadm group is required by some XenApp commands that
demand special administration rights, but do not require root access to the UNIX system. The users in the ctxadm
group log on with their normal user accounts. If you create a farm containing more than one server, the ctxadm
group must be a network group visible to all servers in the farm.
You must also create a ctxsrvr user and add this to the ctxadm group. Citrix recommends that the ctxsrvr
user not be a logon user account.
You must also create a ctxssl user and add this to the ctxadm group. This account is used for SSL
Relay administration.
Important: Do not use the ctxadm group and ctxsrvr user account for any purposes other than
XenApp system administration.
Do not use the ctxssl user account for any purposes other than SSL Relay administration.
The following procedure is different from the one Citrix recommended in previous versions of XenApp for
UNIX. This new procedure is considered a security best practice because users in the ctxadm group log
on with their normal user accounts and the ctxsrvr user is no longer a logon account.
To create administrator group and user accounts

1.
Create the administrators group using the group name ctxadm.
2.
Add the users that you want to become administrators to the ctxadm group.
3.
Create a user account called ctxsrvr and add this user to the ctxadm group. Make sure the ctxsrvr
user is not a logon user account (for example, set the shell for this user to be /etc/NoShell to
prevent logons).
4.
Create an SSL Relay administrator using the user name ctxssl. Make sure that you add the ctxssl user
to the ctxadm group and that the ctxadm group is its primary group.
10.2.2.2.3.2. Installing XenApp Using the Installer Script

Updated: 2009-11-30
You can install SenApp for UNIX using the installer script provided. The installer script guides you through
each step and prompts you for the information that it requires. This procedure works on all platforms.
Note: The following instructions describe a typical installation involving the creation of a new farm. You
may see some or all of the following prompts, depending on the configuration of your system. For example,
you see different prompts if you are joining a farm rather than creating a farm.
To install XenApp
1.
Log on as root at the server on which you want to install XenApp.
2.
Mount the XenApp installation media.
3.
Change to the base directory of the XenApp installation media. For example, type: cd /cdrom The path
is usually /cdrom/... but it may change depending on how your system mounts the installation media.
4.
To start the package installer script and install XenApp, type: sh installxau [-b package_dir] [-p
patch_dir] The install script has two options, -b and -p, which you can optionally use to customize
your install process. By default, the install script looks for the install package on the installation media
as follows:
$CDROOT/solaris/CTXSmf, for Solaris SPARC
$CDROOT/solaris_x86/CTXSmf, for Solaris x86/x64
$CDROOT/usr/sys/inst.images/Citrix.MetaFrame.bff, for AIX
$CDROOT/hpux/MetaFrame.depot, for HP-UX
Using the -b option and supplying a location for package_dir, you can instruct the install script to look
in the specified directory for the install package.
Any hotfixes for the appropriate platform located on the CD-ROM in $CDROOT/hotfix will be
installed automatically as part of the install, after the base install package has been installed and
before the final configuration of the system takes place. These hotfixes are patch files that follow the
Citrix patch file naming convention for this product: PSE4.0[SOL|SOLX|AIX|HPUX][0-9][0-9][0-9].
tar[.Z]. These files do not require any uncompressing or unpacking to be used by the install script.
Using the -p option and supplying a location for patch_dir, you can instruct the install script to look in
the specified directory for hotfix patches to install. As XenApp for UNIX hotfixes contain all the
changes from previous hotfixes, only the latest hotfix needs to be applied to fully patch an installation.
5.
At the prompt for the license agreement, type y to accept the agreement and continue with installation.
If you do not accept the license agreement, installation terminates.
6.
At the prompt for server farm, type c (or create) to create a new server farm or j (or join) to join
an existing farm.
7.
If you are creating a new farm, at the prompt for the license server, type the name or network address
of the license server.
8.
If you are creating a new farm, at the prompt for the license server port number, type a port number
or press ENTER to accept the default of 27000.
9.
If you are creating a new farm, at the prompt for the product edition, type Enterprise or Platinum
depending on which XenApp edition you are licensed to use, or press ENTER to accept the default
of Enterprise.
Note: If you do not know the details of the license server, you can configure the license server
name, port, and product edition later using the ctxlsdcfg command.
10.
At the prompt for the XML Service port number, type the port number the XML Service will use
for connections to the Web Interface or press ENTER to accept the default of port 80. If port 80 is
already in use, assign the XML Service to an unused port.
11.
At the prompt for enabling SSL Relay, type y to enable SSL-secure connections to the server, or
press ENTER to accept the default of n (not enabled). For more information about using SSL Relay, see the
Citrix XenApp SSL Relay for UNIX Administrators Guide. If you are installing on an HP-UX or AIX
platform, go to step 18.
12.
At the prompt for the location of the Java Runtime Environment (JRE), type the path to the JRE;
for example: /usr/j2re1.4.2_06.
13.
At the prompt for the startup/shutdown script installation, type y if you want to start XenApp when
the server is started and stop it when the server is shut down. If you answer yes, the script S99ctxsrv
is installed in the /etc/rc2.d directory.
14.
15.
At the prompt for the man page installation, type y to install the XenApp man pages.
At the prompt for anonymous users, type y to create 15 anonymous user accounts, if you want to
enable guest access.
Note: When installing in a non-global zone on Solaris platforms, you are not given the option to
enable anonymous user accounts. This is because by default XenApp creates the home directory
for these users in the /usr filesystem, which is read-only in non-global zones. To enable
anonymous users in such installations, run the ctxanoncfg -d utility to specify an alternative
home directory after the main installation is complete. See Sun Microsystems Solaris
Zones documentation to determine which file systems are read-only in a non-global zone.
16.
At the prompt about security settings for setuid/setgid, type y to set the correct file permissions for
the files and processes.
Important: Do not type n, or XenApp will not operate correctly.
17.
18.
19.
At the next prompt, type y to continue installing XenApp. When complete, a message tells you that
the installation was successful.
At the prompt for farm name, type the name you want to give the farm.
At the prompt for farm passphrase, type a passphrase. Citrix recommends that you choose a
suitably strong passphrase, in accordance with your companys security policy.
19.
Note: You can use the ctxfarm command to change this passphrase later if necessary.
20.
Confirm the passphrase.

Installation is complete and you are now ready to start XenApp.
Note: Do not attempt to share or copy the XenApp installation files between servers. The
configuration database cannot be duplicated, and you will experience problems if you attempt to do this.
10.2.2.2.3.3. Performing an Unattended Install

Updated: 2009-10-20
These topics explain how to perform an unattended (quiet) installation on the various UNIX platforms.
Unattended installation allows you to install XenApp quickly and easily on multiple servers, without prompting.
10.2.2.2.3.3.1. Performing an Unattended Install on Solaris
Updated: 2009-11-20
This topic explains how to perform an unattended installation on the Solaris platform. To do this, you use
the administration and response files supplied on the XenApp installation media. You create a script file to run
the unattended install using these files.
About the Response File
A response file, called response, is included in the /solaris or /solaris_x86 directory (as appropriate) on
the XenApp installation media. This file is used by the -r option of the pkgadd command. This file includes
the following:
A basic XenApp for UNIX package is installed
Fifteen anonymous users are added
A startup script is installed
man pages are installed
If you want to use different settings, copy and change this file as appropriate, or run pkgask to create a file
of responses. For more information about pkgask, see its man page.
About the Administration File
An administration defaults file, called admin, is included in the /solaris or /solaris_x86 directory (as
appropriate) on the XenApp installation media. This file is used by the -a option of the pkgadd command.
Note: The admin file assumes that the Java Runtime Environment is installed in /usr/j2se. If it is
installed elsewhere, you must either edit a copy of the response file or make a symbolic link to the JRE.
The admin file permits running of install-time scripts as root, and installation of setuid/setgid binaries. It
enforces dependency checking and disk-space checking.
To perform an unattended install on Solaris
1.
2.
Mount the XenApp installation media and locate the admin and response files in the Solaris directory.
3.
Create a script file to perform the unattended install; for example:
#!/bin/sh
pkgadd -r /cdrom/solaris/response -a /cdrom/solaris/admin -d
/cdrom/solaris/CTXSmf CTXSmf
where /cdrom/solaris/admin is the administration defaults file, and /cdrom/solaris/response is the
response file. The path is usually /cdrom/solaris/... but it may change depending on how your
system mounts the installation media.
Note: If you are installing on Solaris x86/x64, replace solaris in the above paths with solaris_x86.
4.
Change permissions on the script file so that root can execute it; for example:
chmod 744 scriptfile
5.
6.
Run the script file to start the unattended install.

When the unattended installation is complete, you must configure some settings manually. For
more information, see After Unattended Installation.
10.2.2.2.3.3.2. Performing an Unattended Install on HP-UX

Updated: 2009-11-20
This topic explains how to perform an unattended install of XenApp on an HP-UX platform.
To perform an unattended install on HP-UX
1.
2.

Insert the XenApp installation media and mount it as a read-only filesystem. For example, at a
command prompt type:
mount -r /dev/dsk/c0t0d0 /mnt/cdrom
where /dev/dsk/c0t0d0 is the file that identifies the drive and /mnt/cdrom is the mount point of
the installation media.
3.
To install the entire XenApp package (including man pages, 15 anonymous user accounts, and the
startup script), at the command prompt, type:
swinstall -s /mnt/cdrom/ MetaFrame.depot MetaFrame
Alternatively, list the particular filesets you want to install. For example, to install XenApp and the
man pages, at a command prompt, type:
swinstall -s /mnt/cdrom MetaFrame.Runtime MetaFrame.Man
The following table describes the available filesets:
4.
Fileset
Description
Anon
Choose to create 15 anonymous user accounts. You cannot install this fileset on
its ownthe Runtime fileset must also be installed.
Man
Choose to install the XenApp manual pages. You cannot install this fileset on
its ownthe Runtime fileset must also be installed.
Runtime
Choose to install the runtime environment (the programs and the

configuration database).
Startup
Choose if you want to start XenApp when the computer is started and stop it
when the machine is shut down. If you choose this fileset, the script ctxsrv
is installed in the /sbin/init.d directory and two symbolic links are added:The startup link S999ctxsrv is installed in /sbin/rc3.d- The shutdown link
K001ctxsrv is installed in /sbin/rc2.dYou cannot install this fileset on its own
the Runtime fileset must also be installed.
After the unattended installation is complete, you must configure some settings manually. For
10.2.2.2.3.3.3. Performing an Unattended Install on AIX

Updated: 2009-10-09
This topic explains how to perform an unattended install of XenApp on an AIX platform.
To perform an unattended install on AIX
1. Log on as root at the server on which you want to install XenApp.
2.
Insert the XenApp installation media.
3. To install the entire XenApp package (including man pages, 15 anonymous user accounts, and the
startup script), at a command prompt, type:
installp -X -d/dev/cd0 Citrix.MetaFrame
where -d/dev/cd0 is the installation media device, and -X ensures that there is sufficient disk space
to install the package.
Alternatively, list the particular filesets you want to install. For example, to install XenApp man pages, at
a command prompt, type:
installp -X -d/dev/cd0 Citrix.MetaFrame.man
The following table describes the available filesets
Citrix.Metaframe...
Fileset description
.boot
Choose if you want to start XenApp when the computer is started and
stop it when the computer is shut down. If you choose this fileset,
the daemon ctxmfd is installed in /usr/lpp/CTXSmf/sbin and starts
up automatically.
During the installation of the .boot fileset, an entry is made in
the /etc/inittab file that starts up ctxmfd and the server, when starting.
You cannot install this fileset on its ownthe Citrix.MetaFrame.rte
fileset must also be installed.
.anon
Choose to create 15 anonymous user accounts. You cannot install

this fileset on its ownthe Citrix.MetaFrame.rte fileset must also
be installed.
.rte
Choose to install the runtime environment (the programs and

the configuration database).
.man
Choose to install the manual pages.
4. When the unattended installation is complete, you must configure some settings manually; for
10.2.2.2.3.3.4. After Unattended Installation
After performing an unattended installation, to complete the installation, you must configure the
following settings manually:
Set the XML Service port number using ctxnfusesrv -port portnumber
Start the Management Service daemon using ctxsrv start msd
Create or join a server farm using ctxcreatefarm or ctxjoinfarm
Configure communication with the license server using ctxlsdcfg
If you want to enable SSL Relay, write SSL_ENABLED=1 to /var/CTXSmf/ssl/config
10.2.2.2.4. Setting the Paths to XenApp Commands

Updated: 2009-11-19
There are two types of XenApp commands:
User commands
Any user can run these commands. They include the commands
for logging off and disconnecting from a server. User commands
are installed in the following directories:
On HP-UX and Solaris:
/opt/CTXSmf/bin
On AIX:
/usr/lpp/CTXSmf/bin
System administration commands
Only members of the ctxadm group can run these commands.

They include server, published application, and ICA
browser configuration tools. Administration commands are installed
in the following directories:
/opt/CTXSmf/sbin
On AIX:
/usr/lpp/CTXSmf/sbin
10.2.2.2.4.1. Configuring User Access to Commands

Updated: 2009-11-19
Generally, you do not have to do anything to allow users to run user commands from their sessions. The path
to these commands is added to each users path upon connection to the server, so any user can access
XenApp user commands from an ICA session.
However, you may have to configure access to XenApp commands if the users shell script startup file
(for example, .profile or .login) overrides the path. For example, on HP-UX, the default system
profile (/etc/profile) sets the PATH environment variable explicitly.
To configure user access to XenApp commands
If you are using a C shell, use a .login file for the user and add the path to the user commands.
For example:
setenv PATH ${PATH}:/opt/CTXSmf/bin

On AIX:
setenv PATH ${PATH}:/usr/lpp/CTXSmf/bin

If you are using a Bourne or similar shell, use a .profile file for the user and add the path to the
user commands. For example:
PATH=${PATH}:/opt/CTXSmf/bin
export PATH
On AIX:
PATH=${PATH}:/usr/lpp/CTXSmf/bin
export PATH
10.2.2.2.4.2. Configuring Administrator Access to Commands

Updated: 2009-11-30
An administrator needs to be able to run both user and system administration commands. If you are
installing XenApp for the first time, you need to configure your system so that administrators can run all
the commands from the server console and also from an ICA session.
To configure administrator access to commands
If you are using a C shell, use a .login file for the administrator and add the path to the user
and administrator commands. For example:
setenv PATH ${PATH}:/opt/CTXSmf/sbin:/opt/CTXSmf/bin

On AIX:
setenv PATH ${PATH}:/usr/lpp/CTXSmf/sbin:/usr/lpp/CTXSmf/bin

If you are using a Bourne or similar shell use a .profile file for the administrator and add the path to
the user and administrator commands. For example:
PATH=${PATH}:/opt/CTXSmf/sbin:/opt/CTXSmf/bin
export PATH
On AIX:
PATH=${PATH}:/usr/lpp/CTXSmf/sbin:/usr/lpp/CTXSmf/bin
export PATH
10.2.2.2.5. Setting the Path to the man Pages

Updated: 2009-11-30
Generally, you do not have to do anything to allow users to display man pages for XenApp commands from
a session. The path to these files is added to every users MANPATH environment variable upon connection to
the server.
However, you may have to configure access to the man pages if the users shell script startup file (for example,
.profile or .login) overrides the path. For example, on HP-UX, the default system profile (/etc/profile) sets
the MANPATH environment variable explicitly.
To display the man pages from the server console when you log on as an administrator, you must set up
your MANPATH environment variable to point to the location of the installed man pages. You need to do this
only if you are installing XenApp for the first time.
To set the MANPATH environment variable
If you are using a C shell:
setenv MANPATH ${MANPATH}:/opt/CTXSmf/man

On AIX:
setenv MANPATH ${MANPATH}:/usr/lpp/CTXSmf/man

If you are using a Bourne shell:
MANPATH=${MANPATH}:/opt/CTXSmf/man
export MANPATH
On AIX:
MANPATH=${MANPATH}:/usr/lpp/CTXSmf/man
export MANPATH
10.2.2.2.6. Starting and Stopping XenApp

Updated: 2009-11-30
To start XenApp
When installation is complete, start the XenApp process on each server using the ctxsrv command.
Note: If, during installation, you choose to add the startup/shutdown script, XenApp automatically starts
when the computer starts.
1.
Log on to the server as an administrator.
2.
At a command prompt, type:

ctxsrv start all
To stop XenApp
To stop the XenApp process on a server, use the ctxshutdown command. With ctxshutdown, you can
specify when the shut down process will begin, and notify users that the server is about to shut down. This
allows users to save their work and log off gracefully.
When the shut down process begins, applications will terminate, except for those that have registered
window hints. These applications will attempt to interactively log users off by displaying a series of prompts.
With ctxshutdown, you can specify the maximum duration that users have to respond to these prompts.
Any sessions that are still active when this period expires are terminated and the users are automatically
logged off.
The server prevents users from logging on during the shut down process.
1.
2.
At a command prompt:
To
Use the command
Shut down the server using the defaults. By default, the

server shutdown process begins after 60 seconds; the message
Server shutting down. Auto logoff in 60 seconds is sent to all
users logged on to the server. Applications that have registered
window hints (the WM_DELETE_WINDOW attribute) have a further
30 seconds to interactively log users off before terminating.
ctxshutdown
Operate in quiet mode. This reduces the amount of

information displayed to the administrator by the ctxshutdown
command.
ctxshutdown -q
Specify when the shut down process will begin, and how long
the message will appear, in seconds. The default is 60 seconds.
When this period expires and the shut down process
begins, applications that have registered window hints
(the WM_DELETE_WINDOW attribute) will attempt to interactively
log users off. Applications that have not registered window hints
will terminate immediately.
ctxshutdown -m seconds
Specify how long applications that have registered window hints

(the WM_DELETE_WINDOW attribute) have to interactively log
users off. The default is 30 seconds. When this period expires,
any remaining sessions are automatically terminated, users
are automatically logged off, and the process stops.
ctxshutdown -l seconds
Specify the message displayed to all users logged on to the server.

If you do not specify a message, the default message Server
shutting down. Auto logoff in x seconds appears, where x =
ctxshutdown message
the number of seconds specified in the -m option (or the default of

60 seconds if this is not specified).
Example
The following example shows how to display a message and begin the shut down process after two
minutes. Applications that have registered window hints are given a further three minutes to attempt
to interactively log users off.
ctxshutdown -m 120 -l 180 Please log off now
10.2.2.2.7. About Client Keyboard Support
Updated: 2009-11-30
XenApp supports client devices that use the following keyboards:
Language
Locale ID
US English
409
UK English
809
French
40c
German
407
Swedish
41d
Spanish
40a
Italian
410
Danish
406
Dutch
413
Finnish
40b
Norwegian
414
Polish Programmers
415
Portuguese
816
Belgian Dutch
813
Korean (see note)
e0010412
French Canadian (see note) c0c

Swiss German
807
Icelandic
40f
Japanese (see note)
e0010411
Note: The Korean and French Canadian keyboard locales are supported on the Citrix XenApp Plugin for
Hosted Apps for Windows only. Only partial support for Japanese keyboards is available, allowing typing
of English characters using a Japanese keyboard.
10.2.2.2.7.1. Configuring Non-English Keyboard Support
Updated: 2009-11-20
Your users can make connections to the server with client devices that use non-English keyboards. The
keyboards that XenApp supports are shown in the table above.
To configure non-English keyboard support
1.
Ensure you start the server in the country locale of the client keyboard that your users are employing.
For example, if your users have German keyboards, start the server in a German locale. This ensures
that the session runs in an appropriate locale where fonts containing the required keyboard symbols are
in the font path and keyboard symbols appear correctly on the screen.
2.
Make sure your users select the appropriate keyboard in the Settings dialog box on the client device.
For further information about selecting keyboards, refer to the administrators guides for the plugins
you are deploying.
Tip: You can alter the locale for an individual user by setting environment variables in the users start-up files.
Troubleshooting Non-English Keyboard Support

If users experience problems obtaining accent symbols, such as the circumflex accent (^), it may be that
the application they are using does not support dead keys. A dead key is a key that does not produce a
character when pressedinstead, it modifies the character produced by the next key press. For example, on
a generic French PC keyboard, the circumflex (^) key is a dead key. When this key is pressed, and then the
a key is pressed, is generated.
10.2.2.2.8. Configuring Event Logging
Updated: 2009-11-30
When you first install XenApp, events are not configured to be sent to the system log (syslog).
XenApp uses the following event log levels:
user.notice
user.info
user.warning
user.err
user.debug
To record XenApp events, add a line to the /etc/syslog.conf file and specify the event log levels that you want
to record. You must be root to edit syslog.conf.
Note: The event log level names that XenApp uses may also be used by other programs. You may
see messages from other software in the event log.
For example, adding the following line to the end of syslog.conf (separated with a tab, not a space) causes
all event log messages from XenApp to be put in the file /var/adm/messages:
On Solaris and AIX:
user.notice;user.info /var/adm/messages
On HP-UX:
user.notice;user.info /var/adm/syslog/syslog.log
Note: The file that you use (that is, /var/adm/messages) must exist. If it does not, you must create it.
You may also want to send certain types of XenApp event details to the console. For example, to ensure that
all error messages appear on the console, add this line to the file /etc/syslog.conf:
user.err /dev/console
Note: You can configure the logging of session logons, logoffs, disconnects, and reconnects using the ctxcfg
command with the -k option.
For information, see Configuring Session Status Logging. For further details about configuring system
event logging, see the syslog.conf man page.
10.2.2.2.9. Removing XenApp

Updated: 2009-11-30
Instructions for removing XenApp differ, depending on the operating system you are running. Procedures
for removing XenApp from all supported operating systems are provided below.
To remove XenApp on Solaris
1. Log on to the server as an administrator.
2. Ensure that there are no active sessions and stop XenApp using the ctxshutdown command.
3. Log on as root.
4. To remove XenApp, type:
pkgrm CTXSmf
To remove XenApp on HP-UX

3. Log on as root.
4. To remove XenApp, type:
swremove
5. The SD Remove dialog box appears. Choose MetaFrame.
6. From the Actions menu, choose Mark for Remove.
7. From the Actions menu, choose Remove (analysis) to display analysis information prior to
the installation. If any warnings are generated, display the Logfile for further details.
8. Choose OK to remove XenApp.
Tip: To quickly remove the entire XenApp package, at a command prompt, type:
swremove MetaFrame.
To remove XenApp on AIX

1. Log on to the server as an administrator
3. Log on as root.
4. Type smit. The System Management Interface Tool dialog box appears.
5. Choose Software Installation and Maintenance.
6. Choose Software Maintenance and Utilities.
7. Choose Remove Installed Software. The Remove Installed Software dialog box appears.
8. In SOFTWARE name, type Citrix.MetaFrame. To remove a particular fileset, type in its name;
for example Citrix.MetaFrame.man.
Note: If you want to remove the Citrix.MetaFrame.rte fileset, you must also remove the
Citrix.MetaFrame.boot and Citrix.MetaFrame.anon filesets. If you do not, a Dependency Failure
error message appears.
9. Set PREVIEW only? to no.
10. Choose OK.
11. At a prompt, choose OK to confirm you want to remove the software. When complete, check the
Installation Summary to make sure that the removal was successful.
Note: If the removal of XenAppfails, it may be because you did not stop the serversee Step 2.
12. To exit from smit, select Exit SMIT from the Exit menu.
Tip: To quickly remove the entire XenApp package, at a command prompt, type: installp -u
Citrix.MetaFrame.
Updated: 2009-11-20
If you set up the license server before installation and you used the installer script to install XenApp,
your server is licensed and operational. If you did not set up the license server before installation or
you did not configure communication with the license server during installation, set up the license
server and use the ctxlsdcfg command to configure communication with it manually.
If you did not configure the server farm during installation, you must create or join a server farm.
Install the plugin software on each client device you plan to use from the XenApp installation media,
or from the Citrix Web site. After installing the plugin software, create ICA connections to your server
and test that you can connect from each type of plugin. For information about installing plugins
and creating connections from a client device to a server, see the administrators guide for the
appropriate plugin.
When you can connect to your server from a client device, your server is operational.
To provide your users with access to applications, publish applications using the ctxappcfg command.
10.2.2.3. Introducing Server Farms

Updated: 2009-11-23
A server farm is a group of XenApp servers that is managed as a single entity. Using a server farm allows you to:
Deploy published applications and resources to all servers in the farm quickly and easily.
Manage and administer settings for the entire farm from a single location, rather than configuring
each server individually. You can administer the farm from any server in the farm; you do not need
to connect remotely to other servers in the farm.
To create a server farm, you use the ctxcreatefarm command. After you create the farm, you use the
ctxjoinfarm command to join other servers to the farm. The ctxcreatefarm and ctxjoinfarm commands
are aliases of the ctxfarm command.
Note: If you are running this version of XenApp for UNIX alongside earlier versions in a server farm,
ensure that the latest public hotfix is installed on all servers running earlier versions. You can download
the latest hotfix from the Citrix Web site, at http://www.citrix.com.
10.2.2.3.1. Server Farm Components
Updated: 2009-11-20
The following diagram illustrates the key components in a typical server farm. The diagram shows the
server where the administrator is logged on, the Management Service Master server, and other servers that
are members of the farm. Secure communication between the various Management Services running on
each server in the farm is also shown.
The Management Service Master

When you create a new server farm, the server on which you create the farm becomes the Management
Service Master. The Management Service Master is a XenApp server that has authoritative control of the farm.
The Management Service Master also holds the master copy of the farms data store.
Data Store
The data store is a human-readable text file that stores persistent data for the farm, such as
configuration information about the servers and published applications in the farm. The Management
Service Master holds the master file, while other servers in the farm each hold a copy of the data store.
When a server joins the farm, the data store is updated to reflect the addition of the new server, and the
new server is given a copy of the farms data store.
The Management Service
The Management Service is a daemon that runs on each server in the farm that communicates server
farm information, such as details about the published applications available in the farm.
When you make a configuration change to the server farm (for example, you publish a new application in
the farm), the Management Service Master communicates this change to the other servers in the farm using
the Management Service.
Communication between the various Management Services in the farm takes place over a secure
communication channel.
Secure Communication Channel
To protect sensitive information and administrator commands sent between servers, XenApp for UNIX provides
a secure, private communication channel between all servers in a farm. This secure communication
channel employs the Generic Security Service Application Program Interface (GSS-API) to provide
mutual authentication of servers, and confidentiality and integrity protection for data transmitted across
the network. GSS-API is an industry-standard security framework defined by the Internet Engineering Task
Force RFC 2743. Authentication and data protection are performed by the Kerberos 5 GSS-API
security mechanism (RFC 1964) in a way that avoids the need for an external Kerberos authentication
server. Authentication instead depends on a shared secret that is securely distributed to servers when they
join the server farm. The server farm passphrase is used for initial authentication when servers join the farm.
Note: You can use the ctxfarm command to change the farm passphrase and shared secret if necessary.
For secure communication between servers in a farm to function correctly, you must ensure that:
Clock settings on all servers in a farm are synchronized. You can set up a network time server
to ensure that clock settings on all servers in a farm are synchronized.
Name resolution between servers in a farm is consistent. You should ensure that all servers to
be placed in a farm resolve the names of other servers in the farm consistently. All servers must be able
to resolve server names to IP addresses and IP addresses to server names.
10.2.2.3.2. Communication between Servers in a Farm

Interserver communication using the Secure Communication Channel occurs over TCP/IP on port number
2897. This communication consists of administration commands and management information updates
and queries.
Interserver communication between ICA browsers occurs over UDP on port number 1604. This
communication consists of UDP broadcasts to locate or elect the master browser for the local network or
subnet, and UDP packets directed to the master browser to send server information updates and queries.
The master browser holds information about each servers address, load, available applications, and
disconnected sessions.
10.2.2.3.3. Multiple Farms and Subnet Considerations
Updated: 2009-11-20
Citrix recommends that all servers in a farm are on one subnet. If servers in a farm are on different subnets,
you must configure an ICA gateway to allow the servers to contact one another.
If you must create multiple farms on one subnet, ensure that published applications have different names in
the different farms. For example, name the Diary application DiaryA in server farm A, and DiaryB in
server farm B. This ensures that the Diary application is not load balanced over the two different farms and
that users get consistent results, regardless of how they browse for applications.
Note: For more information about configuring ICA gateways, see Configuring ICA Gateways.
10.2.2.3.4. Integrating with Other XenApp Servers
Cross-server administration between Windows and UNIX versions of XenApp is not possible. Only servers
running XenApp for UNIX can become part of a UNIX server farm. Similarly, only servers running XenApp
for Windows can become part of a Windows server farm.
XenApp for UNIX will coexist with other servers running XenApp (for example, XenApp for Windows) on a
network by sharing master browser information.
You can make applications published on XenApp for UNIX servers appear in the same location as
applications published on XenApp for Windows farms. To do this, you use the Citrix XML Service with the
multiple server farm functionality in the Web Interface. The Citrix Web Interface is an application
portal technology that lets you integrate and publish applications to a Web browser from any standard
Web server. For more information, see the Web Interface Administrators Guide. The Citrix XML Service
is included automatically when you install XenApp for UNIX.
10.2.2.3.5. Creating a Server Farm
Updated: 2009-10-19
When you install XenApp for UNIX using the installer script, you are prompted to create a server farm or join
an existing farm during the installation process. These topics describe how to create or join server farms
manually using the ctxcreatefarm and ctxjoinfarm commands.
To create a server farm, you use the ctxcreatefarm command. Because the server that you create the farm
on will become the Management Service Master, ensure that you create the farm on an appropriate computer.
When you create a farm, you are prompted for a passphrase. Citrix recommends that you choose a
suitably strong passphrase, in accordance with your companys security policy. You can use the ctxfarm
command to change the farm passphrase later if necessary.
Note: You must remember this passphrase, because the passphrase you specify when you create the farm
will be required by administrators whenever they attempt to join servers to this farm. If you lose
the passphrase, you cannot add servers to the farm.
To create a server farm

1.
Log on to the server that will become the Management Service Master as an administrator.
2.

ctxcreatefarm
3.
At the prompt for farm name, type the name you want to give the farm.
4.
At the prompt for passphrase, type a passphrase.
5.
Confirm the passphrase.
10.2.2.3.6. Joining a Server Farm

Updated: 2009-10-19
After creating a server farm, you can join other servers to the farm using the ctxjoinfarm command.
For security, before you can join a server to a farm, you need to know the passphrase specified for the
farm. When you join a server to a farm, the server is updated with a copy of the new farms configuration.
To join a server farm

1.
Log on to the server that you want to join to the farm as an administrator.
2.

ctxjoinfarm
3.
At the prompt for farm name, type the name of the farm you want the server to join.
4.
At the prompt for passphrase, type the passphrase specified for the farm.
5.
At the prompt for server name, type the name or IP address of a server already in this farm.
XenApp communicates with the server farm and automatically joins the server to the farm.
10.2.2.3.6.1. Moving a Server to a Different Farm
Updated: 2009-11-20
You can use the ctxjoinfarm command to move a server to a different farm.
When you move a server to a different farm, the data store in the old farm is updated to reflect the removal
of the server, and the server is updated with a copy of the new farms configuration. However, any
published applications that were on the server in the old farm are no longer available in the new farm. To
make these applications available in the new farm, you must publish them using ctxappcfg publish.
To move a server to a different farm
1.
Log on to the server that you want to move to a different farm as an administrator.
2.

ctxjoinfarm
3.
At the prompt for farm name, type the name of the farm you want the server to join.
4.
At the prompt for passphrase, type the passphrase specified for the farm.
5.
At the prompt for server name, type the name or IP address of a server already in this farm.
6.
At the prompt, confirm that you want to move the server to the new farm. XenApp communicates with
the server farm and automatically joins the server to the farm.
10.2.2.3.6.2. Troubleshooting Joining a Server Farm

Updated: 2009-11-19
Note: On HP-UX, due to an operating system limitation, you cannot specify server names of more than
eight characters when running XenApp for UNIX.
If you experience problems attempting to join a server to a farm, check that:
Clock settings on all servers are synchronized. You can set up a network time server to ensure
that clock settings on servers already in a farm and servers joining the farm are synchronized. New
servers cannot join the farm if clock settings are not synchronized.
Name resolution between servers is consistent. You should ensure that all servers in a farm
resolve the names of servers joining the farm consistently. If name resolution is not consistent,
new servers cannot join a farm.
All servers are running the latest public hotfix. If joining a server running this version of XenApp
for UNIX to a farm created using a previous version fails, ensure that all the servers in the farm
are running the latest public hotfix. On the Management Service Master, run the ctxfarm -k command
to change the farm passphrase, and then retry joining the server to the farm.
10.2.2.3.7. Removing a Server from a Farm

Updated: 2009-10-19
You can remove a server from a farm using the ctxfarm -r command.
Note: You cannot remove the Management Service Master from a farm. Only members of a server farm
that are not the Management Service Master can be removed from a farm.
When a server is removed from a farm, its copy of the farm data store is removed and published applications
are no longer available from this server.
A server can be removed from a farm even when this server is unavailable. To do this, you log onto
another server in the farm and remove the server. The remaining servers in the farm delete the information
they hold about the removed server. You can also remove a server from a farm even when the
Management Service Master is unavailable (for example, if the Management Service Master goes down).
To remove a server from the farm
1.
Log on to a server in the farm as an administrator.
2.

ctxfarm -r [server-name]
where server-name is the name of the server you want to remove from the farm. If you do not specify
a server name, the local server is removed from the farm.
10.2.2.3.8. Renaming a Server

Updated: 2009-11-20
You cannot rename a server using the ctxfarm command.
To rename a server you must remove the server from the farm using the ctxfarm -r command. Note that
you cannot remove the Management Service Master from a farm. Also, when you remove a server, any
published applications available on this server are deleted.
Rename the server, then add the server to the farm again using the ctxjoinfarm command.
10.2.2.3.9. Identifying Servers in a Farm
Updated: 2009-10-19
You can identify the servers in a farm using the ctxfarm -l command. The list provides details of all the
servers currently in a farm and also identifies the Management Service Master.
To identify the servers in a farm
1.
Log on to a server in the farm as an administrator.
2.

ctxfarm -l

Updated: 2009-11-20
After creating a server farm and joining servers to the farm, you can manage the farm using the various
ctx commands. For example, you can use the ctxappcfg command to publish and configure applications on
one or more servers in the farm, and ctxqsession to query servers in the farm.
Note: If you used previous versions of XenApp for UNIX, you may notice changes to some ctx
commands, particularly for server farms. For example, there is a publish parameter in the ctxappcfg
command (that replaces the add parameter) that allows you to publish and configure applications on
any server in the farm.
10.2.2.4. Licensing XenApp for UNIX
Updated: 2009-10-21
XenApp for UNIX uses the Citrix Licensing method. This means that you use a license server and, if you use
the Citrix License Server for Windows, a user interface for managing licenses, known as the License
Management Console. License files are downloaded from the Citrix Web site and stored on the license server.
Citrix Licensing offers many benefits, including the ability to centrally manage and monitor license usage,
access your licensing data remotely, and create reports for analyzing trends in license usage. Licenses can
be shared across farms, and an electronic backup of all licenses is stored on the Citrix Web site.
To license XenApp for UNIX, you require XenApp Enterprise edition or Platinum edition licenses. These
licenses enable all the features available in XenApp for UNIX, including load balancing and client drive
mapping. Other edition licenses are not applicable to XenApp for UNIX; upgrade licenses are also not applicable.
Citrix License Server for UNIX
A license server that runs on the Solaris platform, rather than on Windows, is available, called the Citrix
License Server for UNIX. This license server can be downloaded from the Citrix Web site. For more
information about installing and configuring this license server, see the documentation that accompanies
the download.
Coexisting with Earlier Citrix Licensing
The previous Citrix licensing method, in which base licenses and server extension licenses were installed on
each product server, is no longer supported in XenApp for UNIX.
Licenses cannot be shared between Version 4.0 servers and servers running earlier versions. However,
servers running Version 4.0 and earlier versions will coexist in a network.
Commands such as ctxqserver -license, that relate to the previous Citrix licensing method, will continue
to function for backwards compatibility; however, meaningful results will appear only for servers running
XenApp versions prior to Version 4.0.
10.2.2.4.1. Licensing XenApp for UNIX: An Overview
Updated: 2009-11-20
To deploy and license XenApp for UNIX, you must complete the following tasks:
1.
Install the license server and the License Management Console on a suitable computer. The
Windows licensing components and the License Management Console are available on the
XenApp installation media.
Note: To run a license server on the Solaris platform, download the Citrix License Server for UNIX
from the Citrix Web site. The download includes documentation about installing and configuring
this license server. Note that this download does not include the License Management Console.
2.
Connect to http://www.citrix.com to download your license files.
3.
Copy the license files to your license server.

Note: These tasks are described in detail in Getting Started with Citrix Licensing. Citrix recommends
that you read this guide before installing XenApp for UNIX.
4.
5.
Deploy XenApp for UNIX.

If necessary, configure communication between XenApp for UNIX servers and the license server using
ctxlsdcfg. This is described in the following topic. However, if you use the installer script to install
XenApp for UNIX, the installer script configures communication with the license server for you.
10.2.2.4.2. Configuring Communication with the License Server

Updated: 2009-10-21
This topic discusses how to configure XenApp for UNIX to use Citrix Licensing. It explains how to display
and specify the license server location and port number using ctxlsdcfg.
Typically, these communication settings are specified during XenApp for UNIX installation. Sometimes,
however, you may need to edit these settings after installation; for example:
If you decide to install the license server software after you install XenApp
If you do not use the installer script to install XenApp
If you rename your license server
If you transfer the licenses for a server farm to another license server
If you change the port your license server uses
If you change a server farm so that it points to another license server
If you want to change whether XenApp runs in feature pack or hotfix mode
If you want to change how XenApp for UNIX shares licenses with XenApp for Windows
ctxlsdcfg is a farm-wide setting, so you need to run this command on only one server in the farm. The
settings you specify are propagated automatically throughout the server farm.
To change license server settings for a farm
1.
2.
At a command prompt, type ctxlsdcfg.

The following prompt appears:
License Config>
3.
At the License Config prompt:

To specify the license server name, type server server-name where server-name is the name
of the license server.
To specify the license server port number, type port port-number where port-number is the
port number of the license server. By default the port number is 27000.
To specify the product edition, type edition product-edition where product-edition is
either Enterprise or Platinum depending on which XenApp edition you are licensed to use. By
default the product edition is Enterprise.
To specify feature pack or hotfix mode, type mode mode where mode is either
FeaturePack1or Base. By default the mode is FeaturePack1 when running XenApp 4.0, with
Feature Pack 1.
To specify whether XenApp for UNIX servers can share licenses with older or newer versions
of XenApp for Windows, type compatibility compatibility where compatibility is 4.0 to
allow license sharing with servers running Citrix Presentation Server 4.0 for Windows or earlier,
or post4.0 to allow license sharing with servers running Citrix Presentation Server 4.5 or later.
By default compatibility is set to post4.0.
Note: Settings for compatiblity and mode options are propagated to all servers in the farm
only if Citrix XenApp 4.0, with Feature Pack 1, for UNIX is installed on the Management
Service Master server.
4.
At the License Config prompt, type exit.
5.
At the prompt to save your changes, type y (or yes).
To display license server settings for a farm

1.
2.
At a command prompt, type ctxlsdcfg.

License Config>
3.
At the License Config prompt, type list. The current license server settings appear.
4.
At the License Config prompt, type exit.
10.2.2.5. Publishing Applications and Desktops

Updated: 2009-10-21
To a client user, a published application appears similar to an application running locally on the client device.
Published applications:
Give client users easy access to applications running on servers
Increase your control over application deployment
Shield users from the complexities of the UNIX environment hosting the ICA session
The ctxappcfg command is the main tool for publishing applications. You can publish any application that can
run on the UNIX workstation or server on which XenApp is installed.
10.2.2.5.1. Why Publish Applications?
Updated: 2009-10-21
The main reasons for publishing applications are the ease of user access, the degree of administrative
control, and the efficient use of resources.
Administrative Control
When you publish applications, you get greater administrative control over application deployment.
Enabling and disabling applications. You can disable published applications without having to
delete their configuration. This allows you to temporarily stop users from connecting to
published applications. A disabled application can be quickly enabled at a later stage.
Load balancing. Application publishing lets you direct connection requests to the least busy server in
a group of servers configured to run an application.
User Access
When you publish applications, user access to those applications is greatly simplified in the following areas:
Addressing. Instead of connecting to a server by its IP address or server name, client users can
connect to a specific application or desktop by whatever name you give it. Connecting to applications
by name eliminates the need for users to remember which servers contain which applications. This
also allows administrators to change the server(s) on which applications are deployed,
without reconfiguring plugins, and without users being aware of the change.
Navigation of the server desktop. Instead of requiring client users to have knowledge of the
UNIX desktop to find and start applications after connecting to servers, published applications present
the user with only the desired application in an ICA session.
Efficient Use of Resources
ICA connections to server desktops can consume considerable resources because, by default, CDE is loaded
for each connection. For more efficient use of server resources, use published applications rather than
server desktops.
10.2.2.5.2. Publishing Applications for Explicit or Anonymous Use
Updated: 2009-11-20
When you publish an application, you have to specify whether the application is for anonymous or explicit use.
Publishing Applications for Explicit Use
Explicit users have their own user accounts.
If you publish an application for use by explicit users, when the users log on, they supply their user name
and password. Explicit users have a permanent existencetheir desktop and security settings are
retained between sessions and their files persist from one session to another.
Publishing Applications for Anonymous Use

Publishing applications for anonymous use allows you to provide guest user access to an application.
When a user starts an application published for anonymous use, no logon box appears and the user does not
have to supply a user name or password. Instead, the server selects an available account from a pool
of anonymous user accounts and assigns this to the user.
A temporary home directory is also assigned to users for use during the session. Users do not have a
persistent identity, and no information in the home directory is retained when they log off. Any desktop
settings, user-specific files, or other resources created or configured by the user are discarded at the end of
the ICA session.
If the session is idle (that is, if there is no user activity for a specified time period), the session is
terminated. Users are logged off after a broken connection or time-out.
For information about how to change or maintain anonymous user accounts, see Configuring Anonymous Users.
For information about setting up configuration files for applications published for anonymous use, see
Publishing Preconfigured Applications for Anonymous Use.
Note: The total number of users, whether anonymous or explicit, who can be logged on to the server at
the same time depends upon your licensed user count. See Getting Started with Citrix Licensing for details.
Security Considerations
Take care when choosing applications to publish anonymously, because no user name or password is required
to access these applications and, therefore, little meaningful audit data can be obtained. Citrix recommends
that you do not publish applications that will provide users with a command shell, because they may be able
to access and affect the system in the same way as an explicit user.
For example, on HP-UX, users can change their shell or information from a logon shell. Such changes persist
even after the session is terminatedthat is, if a change is made to an anonymous user account, the next user
of this account will pick up these changes. To prevent users from changing their shell, restrict /etc/shells so that
it contains only the desired system shell.
If you need to publish applications for explicit use and applications for anonymous use that may present
users with a command shell, you can partition the applications onto separate servers and tune the server
security so that the server with anonymous applications is more tightly controlled than the server with
explicit applications. You may also need to change the permissions on some command-line tools (for
example, passwd and chsh) so that members of the ctxanon group cannot execute these tools.
10.2.2.5.3. Publishing an Application, Shell Script, or Desktop
Updated: 2009-10-21
These topics explains how to publish applications (including Java and legacy applications), shell scripts,
and server desktops. They also explains how to publish applications on UNIX servers of different
architecture, change the working directory, and configure the server to accept published application
parameters passed by the plugin.
10.2.2.5.3.1. Publishing Applications
Updated: 2009-11-20
Use the ctxappcfg command to publish an application. The command prompts you for the information
required to publish the application.
Application installation is not part of the application publishing process. Before an application can be
published, both XenApp and the application must be installed. The order in which you install the application
and XenApp does not matter. After an application is installed, it can be published at any time.
To publish an application
1.
2.
At a command prompt, type ctxappcfg.
2.
App Config>
3.
At the App Config prompt, type publish. You are prompted for each item of information you need
to supply:
At the prompt for
Specify
Default
Name
The name you want to use for the published

application. The user selects this name when setting
up an ICA connection to this published application.
The name does not need to be the same as the name
of the executable file for a particular program.
No default
Command-line
The command line required to run the application

or script file; for example: /usr/bin/diary.bin.
No default
Working directory
The default working directory. This directory must

exist. Leave blank to specify the users home
directory. Note that ~/sub-dir is supported; ~otheruser
is not.
Users
home directory
Anonymous [yes|no]
yes if the application is for anonymous use only, or no

if it is for use by users with explicit accounts only.
No default
Description
An optional description that appears on the users

Web page. This information is required for
applications accessed using the Web Interface.
Blank
Folder
A folder containing the application. This information

is required for applications accessed using the
Web Interface.
Blank
Icon File
The icon file displayed against a published application

in the Web Interface.
ICA icon
Window Size
The window size and type of window. This information

is required for applications accessed using the
Web Interface. Specify window size as: widthxheight
, for example, 1024x768; or % (percentage) of
a desktop, for example, 70%. Specify type of window as
seamless (the window size is controlled by the
plugin) or fullscreen (full screen display).
800 x 600 pixels
Color Depth
The number of colors used to display the

application. Choose from 16, 256, 4bit, 8bit, 16bit, and
24bit. This information is required for
applications accessed using the Web Interface.
256 colors
Enable SSL security
yes to use SSL to secure connections to this

application, or no if you do not want to use SSL.
Controlled
by default settings
User name
The user names of users permitted to access

this application. Type one user name per line. Leave
a blank line to complete the list.
No default
Group name
The names of user groups or netgroups permitted

to access this application. Type one group name per
line. Leave a blank line to complete the list. To denote
a netgroup, use an @ as the first character of the
name; for example @netgroup1.
No default
Server name
The names of servers in the farm that will publish

this application. Type one server name per line. Leave
a blank line to complete the list. To specify all
No default
current servers in the farm, type an asterisk (*).

To specify all current and future servers in the farm,
type a plus sign (+).
4.
At the App Config prompt, type exit.
Note: Increasing window size and color depth increases demand upon memory. For example, an
ICA connection configured to run at a color depth of 256 colors and window size of 4096 x 4096
uses approximately 16MB of memory just for the ICA session (additional memory is required for
the applications). An ICA connection configured to run at the same window size but at a color depth of 24bit True Color uses approximately 64MB of memory. Consequently, as memory consumption increases, it
may not be possible to run as many concurrent sessions without increasing memory.
If you specify a netgroup, only the presence of a user in a netgroup is checked; the host and domain fields
are ignored.
The published application is enabled automatically. You can now connect to the server from a client device
and set up a connection to this published application.
You can change the configuration of a published application at any time; see Changing the Settings of a
Published Application for more details.
When you first publish an application, you can specify display settings for folder, icon, window size, and
color depth. If you do not configure these display settings, default display settings are used. You can change
the default display settings for all published applications in the server farm; for more information, see
Specifying Default Settings for Published Applications.
Tip: To publish an application for both explicit and anonymous use, publish it under different namesonce
for explicit use and once for anonymous use.
10.2.2.5.3.2. Publishing a Shell Script
You can also publish an application by writing a script file that sets up the application environment and
then executes the application. You then publish the shell script file as a published application, using the ctxappcfg
command. To publish a script file, enter the path to and name of the script file at a command prompt.
Publish a shell script if you want to publish an application that requires a particularly complex environment;
for example, if you need to set particular environment variables.
To publish a shell script in a server farm, ensure the shell script is present on all the servers in the farm on
which you want to publish it.
10.2.2.5.3.3. Publishing a Desktop
You publish a server desktop in the same way you publish an application, using the ctxappcfg
command. However, to indicate you are publishing a desktop, you leave the command line blank.
Note: ICA connections to server desktops consume considerable server resources because, by default, CDE
is loaded for each connection. For more efficient use of server resources, use published applications rather
than server desktops.
10.2.2.5.3.4. Publishing a Java Application
You can publish Java applications on your server by writing a script file that you publish using the ctxappcfg
command. In the script file, include any environment variables required to set up the application environment
and the commands to start the Java application.
10.2.2.5.3.5. Publishing a UNIX Command-Line Application
You can publish applications that require use only of the command line. For example, you may have a
legacy application that you want to publish. You do this using the ctxappcfg command. At a command
prompt, type:
xterm -e <path> commands
where commands is the set of commands required to start the application. Enclose the commands within
double quotes. If the set of commands is complex, include this in a script file and run the script file:
xterm -e <path> script_file
10.2.2.5.3.6. Publishing an Application on a UNIX Server of Different Architecture
Updated: 2009-11-20
You can publish applications on UNIX servers that are of an architecture different from the XenApp server.
For example, you can publish an application on a XenApp server, although the application exists and runs on
a Linux server.
To do this, you create a script file on the XenApp server to set up the application environment and start
the application on the remote server. This script uses the ssh client command to run the script on the
remote server.
Finally, you publish the script on the XenApp server using the ctxappcfg command.
Example
The following example shows how to publish an application that runs on a Linux server. In this example,
the XenApp server is called Buffy, the Linux server is called Mandix, and the application is called Diary.
Step 1 - Create a script file for Buffy

1.
Create a script file on Buffy that will set up the application environment and start rundiary.sh on
Mandix. For example, create a script file /export/home/apps/diary.sh containing:
#!/bin/sh
# launch app on the machine "Mandix"
ssh -X Mandix "/usr/local/bin/rundiary.sh ~/group.cal"
2.
Make sure that the script file works on Buffy, by testing that it correctly launches the application
on Mandix, using a display on Buffy. ~/group.cal is the parameter passed to the Diary application
on Mandix.
Step 2 - Publish the application on Buffy

1.
Create a script file on Buffy that uses the ctxappcfg command to publish diary.sh. Make sure you
include blank lines where appropriate. For example:
ctxappcfg <<EOF
1.
ctxappcfg <<EOF
publish
MY_DIARY
/export/home/apps/diary.sh
~/data
no
My diary application
Applications
/tmp/icon1.xpm
800x600
16bit
no
user1
group1
group2
buffy
EOF
2.
Test that the script file works by making an ICA connection to MY_DIARY.
10.2.2.5.3.7. Specifying a Working Directory for Published Applications

Updated: 2009-11-20
By default, when a user connects to a published application, the application starts in the users home directory
on the XenApp server. However, you can change the directory in which the application runs by specifying
a working directory on the client device.
To do this, you publish the application on the server in the usual way, and configure the plugin to pass a
working directory parameter to the server.
Example
The following example shows how to configure the published application Editor to run in the working
directory /home/docs.
Step 1Publish Editor on the server
1.
Install Editor on the XenApp server.
2.
Publish Editor in the normal way using the ctxappcfg command.
Step 2Configure the plugin

1.
2.
Create an ICA connection to the Editor application in Program Neighborhoodfor example, create an
ICA connection and name it MyEditor.
Locate the APPSRV.ini file and open it in an editor (such as Notepad).
3.
In the APPSRV.ini file, find the name of the published application; this is the name you gave
the application in Program Neighborhood, contained within square brackets. For example, find: [MyEditor].
4.
In the lines relating to the published application, add a line for the working directory (if such a line
does not exist already). For example, for the Editor application, add the line:
WorkDirectory=/home/docs
10.2.2.5.3.8. Publishing an Application to Accept Parameters from the Plugin
Updated: 2009-10-22
You can configure the XenApp server to accept published application parameters passed by the plugin. This
allows users to connect to a published application and automatically launch a particular file. For example, if
users regularly update a particular document, you can publish the application that they use to automatically
open the document specified by the client device.
To do this, you configure the plugin to pass parameters to the server, and configure the server to accept and
use the parameters passed by the plugin.
Example
A user wants to regularly update a resume, which is stored in: /home/docs/MyCV.doc, using the
published application Word. The following shows how to configure the published application to
automatically open this file when the user connects.
Step 1Publish Word on the server
1.
2.
Install Word on the XenApp server.

Publish Word using the ctxappcfg command. At a command prompt, include %* where the
parameters from the plugin are to be included. For example:
/usr/bin/word.bin %*
Step 2Configure the plugin

1.
2.
3.
4.
Create an ICA connection to the Word application in Program Neighborhood; for example, create an
ICA connection and name it MyCV.
Locate the APPSRV.ini file and open it in an editor (such as Notepad).
In the APPSRV.ini file, find the name of the published applicationthis is the name you gave
the application in Program Neighborhood, contained within square brackets. For example, find: [MyCV].
In the lines relating to the published application, find the line for the initial program. For example:
InitialProgram=#SERVER1
5.
Edit this line with the file name to be opened. For example:
InitialProgram=#SERVER1 /home/docs/MyCV.doc
Note: If there is no %* in the command line on the server, parameters from the plugin are ignored. If
no parameters are passed by the plugin or the syntax is incorrect (for example, the quotes are missing),
the server ignores the parameters and %* has no effect.
Because plugin parameters are interpreted by the shell, you can use wildcards, environment variables, and
so on.
If you specify plugin parameters, seamless session sharing is switched off.
10.2.2.5.4. Displaying Published Application Details

Updated: 2009-11-20
You can use ctxappcfg to display all the applications published on the local server or in the server farm. You
can then use select to display details about a particular published application.
To display details about the applications published
1.
2.
At a command prompt, type ctxappcfg. This starts the program and displays the following prompt:
App Config>
3.
At a command prompt, type list. This displays the names of the applications published on the server or
in the server farm:
App Config> list

Name: Accounts
Name: Orders
Name: Diary
Applications that are disabled have (disabled) displayed next to them.

4.
To find out more details about a particular published application, use the select command with the
name, for example:
App Config> select Diary

This displays the details for the published application, for example:
Name: Diary
Command line: /usr/bin/diary.bin
Working directory: ~/tmp
Icon: Inherited from default application settings.
Anonymous: no
Enabled: yes
Description:
Folder:
Window Size: Inherited from default application settings.
Color Depth: Inherited from default application settings.
SSL security configuration: Inherited from default application settings.
5.
6.
If you want to list information for a different application, type drop to deselect the current
application. You can then use the select command again with the appropriate application name.
To exit from ctxappcfg, type exit.
Tip: You can also display information about published applications on the network using the ctxqserver
command.
10.2.2.5.5. Maintaining Published Applications
Updated: 2009-10-23
These topics explain how to change a published applications settings, configure user access to
published applications, and manage the servers that publish applications. They also describe how to
configure default settings for all published applications in the server farm.
10.2.2.5.5.1. Changing the Settings of a Published Application
Updated: 2009-11-20
After publishing an application, you can change its settings using the ctxappcfg command. You can change
the settings for published applications on the local server or in the server farm.
First, you use the select command to select the application you want to change. Then you use the set
command to configure settings, such as the working directory or the applications description. The set
command is described below.
Note: After selecting an application, you can also change the icon file displayed against a published
application, configure user access to applications, and manage the servers that publish an application.
These features are described later in this chapter.
To configure a published application

1.
2.
App Config>
3.
4.
At a command prompt, type list to check the names of the applications published on the server or in
the server farm.
Select the published application you want to change; for example:
4.

5.
This displays the details for the published application, for example:
Name: Diary
Anonymous: no
Enabled: yes
Description:
Folder:
6.
To change the configuration, use the set command. This has the following syntax:
set [cmd={cmd_line}, dir={dir_name}, anonymous={yes|no}, enabled={yes|no}, description={de

Or
set server={server_name}, [cmd={cmd_line}, dir={dir_name}]

Option
Description
cmd
The command line required to run the application or script file; for
example, /usr/bin/diary.bin.
dir
The default working directory. This directory must exist. Leave blank
to specify the users home directory. Note that ~/sub-dir is supported; ~
otheruser is not.
anonymous
Type yes if the application is for anonymous use only, or no if it is for use
by users with explicit accounts only.
enabled
Type no to disable an applicationthis stops users from connecting to

the application without you having to delete its configuration. Type yes
to enable a previously disabled application.
description
The description displayed on the users Web page. If the description

includes spaces, enclose it within quotes. This information is required
for applications accessed using the Web Interface.
folder
The name of a folder containing the program that the Web Interface displays.
window_size
The window size and type of window that the Web Interface displays.
Specify window size as: widthxheight, for example, 1024x768; or
% (percentage) of a desktop, for example, 70%. Specify type of window as
seamless (the window size is controlled by the plugin) or fullscreen
(full screen display).
color_depth
The number of colors used to display the application in the Web

Interface. Specify 16, 256, 4bit, 8bit, 16bit, or 24bit.
ssl_enabled
Specifies whether or not SSL is used to secure connections to the

application. Type yes to use SSL, or no if you do not want to use SSL.
server
To change the settings on a particular server only, specify a server name.

This option applies only to the command line and working directory.
7.
To save your changes, type save.
8.
10.2.2.5.5.2. Displaying and Changing the Icon File

Updated: 2009-10-23
Use ctxappcfg to find out which icon is currently displayed against a published application when the application
is accessed using the Web Interface.
Use the export icon command to save the icon to a file. You can later view this file using a suitable tool. Use the
import icon command to specify a new icon for the published application.
By default, the ICA icon appears. However, you can specify another icon to use for a published application.
The icon you specify must be:
A graphic in .xpm (X pixmap) format.
32 x 32 pixels. If your icon is larger than this, use an image editor to resize it to the correct size.
To display or change the icon used for a published application

1.
2.
App Config>
3.
4.
the server farm.
Select the published application you want; for example,

5.
This displays the details for the published application; for example,
Name: Diary
Anonymous: no
Enabled: yes
Description:
Folder:
To
Type
Export the current icon to a file that you can later view. You are prompted
for the file name.
export icon
Specify a different icon file for the published application. You are prompted
for the file name.
import icon
6.
7.
10.2.2.5.5.3. Specifying Default Settings for Published Applications

Updated: 2009-11-20
You can configure default settings for all published applications in the server farm using the ctxappcfg
command. You can configure:
Default display settings for applications accessed using the Web Interface. These settings include
folder name, window size, and color depth. These settings affect only applications accessed using the
Web Interface, not applications accessed using a direct client connection where display settings
are controlled by the plugin.
SSL secure connections to applications.
To change the default settings for all published applications

1.
2.
App Config>
3.
At a command prompt, type default. The default settings appear; for example,
App Config> default

Icon: Not configured.
Description:
Folder:
Window Size: 800x600
Color Depth: 256 colors
SSL security enabled: no
4.
To change the default settings, use the set command, which has the following syntax:
set [folder={folder name}, window_size={window size}, color_depth={color depth}, ssl_enabl

Option
Description
folder
The name of a folder containing the published application. This is used by

the Web Interface, which can organize applications into logical folders.
window_size
The window size and type of window that the Web Interface displays.
Specify window size as: widthxheight, for example, 1024x768; or
% (percentage) of a desktop, for example, 70%. Specify type of window as
seamless (the window size is controlled by the plugin) or fullscreen
(full screen display).
color_depth
The number of colors used to display the application. Choose from 16, 256, 4bit
, 8bit, 16bit, and 24bit.
ssl_enabled
Specifies whether or not SSL is used to secure connections to the

application. Type yes to use SSL, or no if you do not want to use SSL.
Note: You cannot display the default icon using ctxappcfg; however, you can use the export icon
command to save the icon to a file that you can later view using a suitable tool.
5.
6.
10.2.2.5.5.4. Configuring User Access to Published Applications

Updated: 2009-10-26
You can configure which users and groups of users can access a published application using the ctxappcfg
command.
For each application, the Citrix XML Service stores a list of groups and users for whom the application is
visible. The Citrix XML Service for UNIX uses the same users and groups as the XenApp server and the
underlying UNIX operating system.
You can display the users and groups allowed to access a published application using the list users and
list groups commands. You can also add users and groups who are allowed to access an application, and
prevent access to an application using the add users, add groups, remove users, and remove groups
commands.
You can add netgroups in addition to normal groups. To denote a netgroup, use an at symbol (@) as the
first character of the name; for example, @netgroup1. Note that only the presence of a user in a netgroup
is checked; the host and domain fields are ignored.
To configure access to an application

1.
2.
App Config>
3.
4.
the server farm.
Select the published application you want to display information about; for example,

This displays the details for the published application.
To
Type
Display the users who are allowed to access the published application.
list users
Display the groups of users who are allowed to access the

list groups
Add users who are allowed to access the published application. Type
one user name per line. Leave a blank line to complete the list.
add users
Add groups of users or netgroups who are allowed to access the

published application. Type one group per line. Leave a blank line
to complete the list. To denote a netgroup, use an @ as the first
character of the name; for example, @netgroup1.
add groups
Prevent particular users from accessing the published application. Type

one user name per line. Leave a blank line to complete the list.
remove users
Prevent groups of users from accessing the published application. Type

one group per line. Leave a blank line to complete the list.
remove groups
5.
6.
10.2.2.5.5.5. Managing the Servers that Publish an Application

Updated: 2009-11-20
You can display the servers in a farm that publish an application using ctxappcfg with the list servers
command. You can also publish an application on one or more servers in the farm using the add servers
command.
Note: Ensure the application is installed on a server before you attempt to publish it. After an application
is installed, it can be published at any time.
To remove a published application from particular servers in the farm, you use the remove servers
command. This removes the application only from the servers you specify; the application remains on
other servers in the farm. If you want to completely remove a published application from all servers in the
farm, use the delete command.
To manage the servers that publish an application
1.
2.
App Config>
3.
3.
the server farm.
4.
Select the published application you want to display information about; for example,

5.
To
Type
Display all servers in the farm that publish the application.
list servers
Publish the application on another server in the farm. Type one

server name per line. Leave a blank line to complete the list. To specify
all current servers in the farm, type an asterisk (*). To specify all
current and future servers in the farm, type a plus sign (+).
add servers
Remove the published application from one or more servers in the

farm. Type one server name per line. Leave a blank line to complete
the list.
remove servers
10.2.2.5.5.6. Deleting a Published Application from All Servers

Updated: 2009-11-20
Deleting a published application removes all published application configuration information from all servers in
the farm. When you delete a published application, that application is no longer available to client users under
the published application name (although it may be available as another published application or from a
server desktop session).
Tip: To temporarily stop users from connecting to a published application, disable the published
application. Disabling a published application does not delete its configuration, and it can be quickly enabled
at a later stage.
If you want to make the application available again, republish it under its old name or with a new name.
To delete a published application from the farm
1.
2.
Run ctxappcfg. At a command prompt, type list to display the names of the applications published on
the server.
Select the published application you want to delete; for example,

3.
Type delete.
4.
Confirm the deletion by typing y.
5.
Type exit.
10.2.2.5.6. Enabling and Disabling Published Applications

Updated: 2009-11-20
You can disable a published application without having to delete its configuration. This is useful when you want
to temporarily stop users from connecting to a published application; for example, to upgrade the application to
a newer version or to apply patches. A disabled application can be quickly enabled at a later stage.
When you disable a published application, users can no longer see or connect to the disabled application on any
of the servers in the farm.
Note: When you publish an application, it is enabled by default.
To enable or disable a published application

1.
2.
Use the ctxappcfg utility with the set command.

Set the enabled option to no to disable an application, or set it to yes to enable a previously
disabled application.
10.2.2.5.7. Creating a New Published Application from Existing Details

Updated: 2009-11-20
After you publish an application, you can reuse the settings by copying the details to a new name.
To copy details to create a new published application
1.
2.
App Config>
3.
At a command prompt, type list to check the names of the applications published on the server.
4.
Select the published application that has the details you want to copy; for example,

5.
Type copy and the new name for the published application at the prompt.
6.
Type drop.
7.
Change the details for the new published application using the set command.
8.
When you are finished configuring the published application, type save to save the changes.
9.
10.2.2.5.8. Renaming a Published Application

Updated: 2009-11-20
After you publish an application, you can change it's name by copying the settings to a new name and
then deleting the original.
To rename a published application
1.
2.
App Config>
3.
At a command prompt, type list to check the names of the applications published on the server.
4.
Select the published application you want to rename; for example,

This displays the details of the published application.
5.
Type copy and the new name for the published application at the prompt.
6.
Type drop.
7.
To delete the original published application settings, select the original application and use the delete
command.
10.2.2.5.9. Restricting Connections to Published Applications Only

Updated: 2009-12-04
You can restrict users so that they can connect only to published applications on a server. Doing so
prevents users from connecting to a server by name or to the server desktop.
Because connections to server desktops consume considerable server resources, restricting users to
published applications makes more efficient use of resources.
To restrict connections to published applications only
1.
2.
Use the ctxcfg command to allow users to run only published applications:
ctxcfg -i PUBONLY
Note: To restrict access on several servers, you must run ctxcfg -i PUBONLY at each server.
10.2.2.5.10. Configuring an Initial Program
Updated: 2009-10-26
An initial program is an application that XenApp starts automatically when a user logs on. Closing the
initial program does not terminate the ICA session.
Initial programs:
Can be set on the server by an administrator.
Can be set from a client device as part of the properties for a specific connection. If an initial program
is configured on the server and client device, the initial program configured on the server is started when
a user logs on.
To configure an initial program on the server

1.
2.
To
Use the command
Configure the server so that if an initial

program is set on the client device, it is used.
ctxcfg -i INHERIT
Configure the server to start the initial program

progname whenever a user connects, where wd
is the working directory.
ctxcfg -i prog=progname,wd=dir
List the current initial program details.
ctxcfg -i list
10.2.2.5.11. Publishing Preconfigured Applications for Anonymous Use

Updated: 2009-11-30
When a user logs on to use an application that you published for anonymous use, the user is assigned an
empty home directory. When the user logs off, any files that the user creates in this directory are deleted.
Some applications use configuration files that initialize settings when the application starts. For example,
an application such as a Web browser may use proxy settings, file paths, and font and display settings. In
normal use, a user configures these settings once. If the configuration files are not available, the
application starts in its default configuration.
You can set up configuration files for applications that you publish for anonymous use. You create these in
a special template directory called /usr/anon/anontmpl. When a user logs on, all files in the template directory are copied to t
To create configuration files for an application
1.
1. Create a user (for example, called anontmpl) with home directory set to /usr/anon/anontmpl. Use
this user account only to preconfigure applications for anonymous use.
2. Log on to the server as this user and run the application you want to configure.
3.
Configure the application so that it mirrors the settings you want to provide when an anonymous user
logs on. For example, for a Web browser application such as Netscape, you may want to set proxy
server settings or clear the cache.
4. Exit the application.

5. Start the application again and make sure that the application works as required. If not, adjust the
process and repeat until you are sure that the correct configuration is in use when the application starts.
6. Using grep or a text editor, search for occurrences of the user name or folder name (in this
example, anontmpl) in each of the files in /usr/anon/anontmpl.
7.
Make the template directory readable by everyone using:

chmod -R a+rX
8. Log on as an administrator.
9. Edit the script file ctxanoninit.sh. This file is installed in the following directory:
/opt/CTXSmf/lib
On AIX:
/usr/lpp/CTXSmf/lib
10.
For each file containing occurrences of anontmpl in the files in /usr/anon/anontmpl, add lines to the
end of ctxanoninit.sh that use the sed command to substitute the user name and home directory.
For example, a Netscape preferences file contains references to the home directory, so add the
following lines to the end of ctxanoninit.sh:
sed e s,anontmpl,$USER,g $ANON_TMPL_DIR/.netscape/preferences.js >

newprefs.js
rm .netscape/preferences.js
mv newprefs.js .netscape/preferences.js
# add commands here to set the correct file permissions.
Note: Use the environment variable $USER, which is set automatically by /bin/sh, to determine
the name to substitute.
11. Publish the application for anonymous use. Make sure that the application works by launching a
session from a client device, repeating the above steps as necessary.
10.2.2.6. Managing Servers, Users, and Sessions
Updated: 2009-11-30
These topics describe how to manage the users, sessions, and processes on a XenApp server. and
include information about how to:
Display information about sessions and users
Display information about the servers on the network
Log off, disconnect, and reconnect sessions
Reset sessions in case of error
Shadow ICA sessions
Send messages to users on your server
Display available client printers and print files from the command line or from applications
Connect to a remote server from within an ICA session
10.2.2.6.1. Displaying Information about Users and Sessions
Updated: 2009-11-20
You can display information about connections to one or more XenApp servers in a farm. This includes
information about the users who are connecting and session details, such as the session id and session state.
To display a default listing of session details, use the ctxqsession command. To display a similar listing,
ordered by user name, use the ctxquser command. If you require more information about sessions, such as
the X display number, or you want to display information in a format that differs from the default listing, use the
ctxquery command. You can also use ctxquery to produce machine-readable output. These commands
are described in the following topic.
To display session details
Run the ctxqsession command:
To
Type
Display sessions on the local server
ctxqsession
Display sessions on another server in the farm
ctxqsession -s servername where servername is

the name of the server you want to query
Display sessions on all the servers in the farm
ctxqsession -S
A list similar to the following appears:
To display session details, by user name

Run the ctxquser command:
To
Type
Display all user sessions on the

local server
ctxquser
Display a specific user session on

the local server
ctxquser user username where username is the name of the

user you want to query
Display all user sessions on

another server in the farm
ctxquser -s servername where servername is the name of

the server you want to query
Display a specific user session

on another server in the farm
ctxquser -s servername user username where servername is

the name of the server and username is the name of the user
you want to query
Display all user sessions on all

the servers in the farm
ctxquser -S
Display a specific user session on all

the servers in the farm
ctxquser -S user username where username is the name of

the user you want to query
A list similar to the following appears:
10.2.2.6.1.1. Displaying More Details or Details in a Different Format

Updated: 2009-11-20
You can display more information about users and sessions than ctxquser or ctxqsession can provide, using the
ctxquery command. For example, you can use ctxquery to display the X display number or the name of
a published application. You can also use ctxquery to configure the display format. This is useful if you
require information in a format other than the default provided by ctxquser or ctxqsession; for example,
to display fields in a particular order or produce machine-readable output.
ctxquery has the following syntax:
ctxquery -f short_format_options | -o long_format_options |

[-m] | [-S | -s server_name user user_name]
You can use ctxquery to display information about sessions and users using the -S | -s server_name user
user_name options, in the same way as you do using ctxqsession and ctxquser. For information about
using these options, refer to the ctxquser and ctxqsession commands.
This topic discusses how to configure the display format using the -f short_format_options and -o
long_format_options. With these options, you input either characters or keywords, respectively, to
produce your listing. The commands generate the same information so it is a matter of preference as to
which one you choose. The use of ctxquery is illustrated in the following example.
Example
To locate a user called Fred, the X display number he is using, and the published application he launched, type:
ctxquery -o user,id,state,xdpy,app user fred
Or
ctxquery -f uiSxp user fred
Tip: For additional examples of how to use ctxquery, see the ctxquery man page.
Producing Machine-Readable Output
You can use ctxquery with the -m option to produce machine-readable output. This alters the column headers
to remove spaces so that a constant number of columns appears on every line, making the output
machine-readable. For example:
ctxquery -f uiSxp user fred -m
10.2.2.6.1.2. About the Display
Updated: 2009-10-29
The following table shows the information displayed by the ctxqsession, ctxquser, and ctxquery commands.
It also shows the keywords and characters you can use to configure the display format with ctxquery.
Display
Description
ctxquery -octxquery
option -f option
SESSION
This is in the format servername:id, where servername is

the name of a server in the farm, and id is the session
identifier. For example, server1:34 means session 34 running
id
on server1.
SESSION NUMBER
The session id number only. Use this to display the

session number without the servername: prefix.
sess#
SESSION NAME
The session name; for example, tcp#41.
sess
USERNAME
The name of the user.
user
STATE
listenindicates the session that is listening for new

incoming connections.activeindicates an established,
active connection.connqindicates a brief session
initialization phase that occurs before the logon prompt
appears, and during reconnect.inita brief session
initialization phase.connindicates a session that is
being connected.discindicates a disconnected session.
downindicates a broken session. shadowindicates that
the user of this session is shadowing another.resetindicates
a session currently being reset.
state
TYPE
wdicaindicates that the ICA protocol is being used.
type
DEVICE
The name of the client device.
dev
IDLE TIME
The length of time since there was user activity in this session.
It may take some time to display this, depending on the
number of users and how they are distributed across servers.
idle
LOGON TIME
The time the user logged on to the system.
logon
CLIENT ADDRESS
The IP address of the client device.
addr
APPLICATION NAME The name of the published application.
app
SERVER NAME
The name of the server in the farm.
srvr
DISPLAY
The X display number.To display this without the : prefix using

ctxquery, use a capital X.
xdpyXdpy
xX
10.2.2.6.2. Displaying Information about Servers on the Network

Updated: 2009-11-20
Use the ctxqserver (query server) command to display information about servers on the subnet. You can
display information such as server name and network address, transport protocol, and the number of
connections available.
To display information about all servers on the subnet
ctxqserver
To display information about a specific server
At a command prompt, type ctxqserver and specify the server name:
ctxqserver server-name
About the Display

The ctxqserver command displays:
Display
Description
Server
The server name.
Transport
The transport protocol; that is TCP/IP.
Conns
The current number of ICA connections on the server.
Free
The remaining number of connections the server is capable of receiving.
Total
The current number of ICA connections plus the number of free connections.
Network Address
The IP address of the server. An M next to the IP address indicates that the server
is the master browser.
Note: You can use ctxqserver to display information specific to XenApp servers (such as ICA gateways),
or about published applications and sessions on the subnet. You can also use ctxqserver to send requests
to servers.
If the server has more than one network interface card (NIC) and you configured it so that the ICA
browser listens on only one subnet, ctxqserver displays information only about this one subnet.
10.2.2.6.3. Ending a Session

To end a session, you can use commands that either log off or disconnect the session. You can log off
or disconnect sessions on the local server or on other servers in the farm.
Disconnecting a session terminates the connection between the server and client device. However,
the user is not logged off, all running programs remain active, and the user can later reconnect to
the disconnected session.
Logging off a session terminates the connection and all running programs, and the user cannot
reconnect to the session.
10.2.2.6.3.1. Logging off from a Session

Updated: 2009-11-20
Use the ctxlogoff command to log off from a session.
To log off from your own session
1.
Type ctxlogoff.
To log off another users session

1.
1.
2.
At a command prompt, type ctxqsession to display sessions on the local server or in the farm.
3.
From the results of ctxqsession, identify the session id of the connection session you want to forcibly
log off.
Note: You must specify a session identifier. Session names are no longer supported.
4.
To
Use the command
Log off a session on the local server
ctxlogoff id
Log off a session on another server in the farm
ctxlogoff servername:id, where servername is

the name of a server in the farm, and id is the
session identifier. For example, server1:34
means session 34 running on server1.
10.2.2.6.3.2. Disconnecting a Session

Updated: 2009-11-20
Use the ctxdisconnect command to disconnect a session.
To disconnect your own session
1.
Close the plugin or type ctxdisconnect at a command prompt.
To disconnect another users session

1.
2.
3.
From the results of ctxqsession, identify the session id of the session you want to disconnect.
4.
To
Use the command
Disconnect a session on the local server
ctxdisconnect id
Disconnect a session on another server in

the farm
ctxdisconnect servername:id, where servername

is the name of a server in the farm, and id is
the session identifier. For example, server1:34
means session 34 running on server1.
If a user logs on to the server and there is a disconnected session on the server belonging to that user, the
user is given a choice of whether to connect to the disconnected session or start a new session.
Note: You cannot disconnect an anonymous user session because you cannot reconnect to the session
when the identity of the user is unknown. If an anonymous session is disconnected, the session is logged off.
10.2.2.6.4. Connecting to a Disconnected Session
Updated: 2009-10-29
Use the ctxconnect command from within an ICA session to reconnect to a disconnected session on the
local server.
A user can connect to a previously disconnected session by logging on again with the same user name.
Once logged on, if there are disconnected sessions on the server, the user can reconnect to the
disconnected session or start a new session.
An administrator can connect to any users session. Other users can connect only to their own sessions.
To connect to a disconnected session
1.
At a command prompt, type ctxqsession to display current sessions on this server. A

disconnected session shows disc in the State field.
2.
From the results of the ctxqsession command, identify the session id associated with the session
to which you want to connect.
3.
At a command prompt from within an ICA session, type:

ctxconnect id
where id is the session id of the session to which you want to connect.
The server disconnects your current session and connects you to the selected session.
Note: Your connected session must be capable of supporting the video resolution used by the
disconnected session. If the session does not support the required video resolution, the operation fails.
10.2.2.6.5. Resetting a Session
Updated: 2009-11-20
You can reset a session in the event of an error using the ctxreset command. You can reset a session on the
local server or another server in the farm. The system will attempt to terminate all processes running within
that session. Resetting a session may cause applications to close without saving data.
To reset a session
1.
2.
3.
From the results of ctxqsession, identify the session id you want to reset.
4.
To
Use the command
Reset a session on the local server
ctxreset id
Reset a session on another server in the farm
ctxreset servername:id, where servername is the

name of a server in the farm, and id is the
session identifier. For example, server1:34 means
session 34 running on server1.
10.2.2.6.6. Reconnecting to Load Balanced Sessions

Updated: 2009-11-20
Published applications allow users to run applications or access a desktop session without knowing the name
or address of a particular server. If the published application is located on a single server, users can
disconnect and reconnect to the same session.
If the published application is configured to run on multiple servers, users must be reconnected to the
same server to reconnect to their session. The ICA browser can reconnect users to their previous session on
the same server under certain conditions.
For a user to reconnect to disconnected load balanced sessions:
The user must disconnect gracefully from the server; for example, by using ctxdisconnect
The user must reconnect from the same client device (using the same client device name)
Use ctxqsession to view a list that displays disconnected sessions.
Note: If users frequently disconnect and reconnect their sessions rather than logging off, the number
of sessions on a server farm may not be evenly distributed because users are reconnected to their
previous sessions on the same servers.
10.2.2.6.7. Shadowing a Users Session
Updated: 2009-11-02
You can monitor the actions of users, and interact with their sessions, using the keyboard and mouse. This
is called shadowing. The person who issues the ctxshadow command is called the shadower, and the
session being shadowed is called the shadowed session.
10.2.2.6.7.1. Starting Shadowing
Updated: 2009-11-20
Use the ctxshadow command to shadow another users session:
ctxshadow {id | servername:id} [-v] [-h[[a][c][s]+]x]
The ctxshadow command is a user command, rather than a system administration command. Therefore,
any user can shadow any other session, provided the shadowed user approves the shadowing, and
XenApp security permits the user to shadow. Disabling shadowing notification means that a user may be
unaware that shadowing is occurring.
Note: The following procedure assumes that you will use the CTRL+* (asterisk) hotkey combination to
end shadowing. If you cannot use this hotkey combination, or you want to use an alternative combination
to end shadowing, see Ending Shadowing.
To start shadowing a session

1.
Log on to an ICA session.
2.
At a command prompt, type ctxqsession to display the current sessions on this server.
3.
From the results of the ctxqsession command, identify the session id of the users session that you
want to shadow.
Note: You must specify a session identifier. Session names are no longer supported. You cannot
shadow a session on another server.
4.
At a command prompt, type ctxshadow and specify a session id. Use the -v (verbose) argument
to display more information during the shadow session initiation; for example:
ctxshadow server1:5 -v
The user is notified of the pending shadowing, and is given the opportunity to allow or deny the
shadowing (unless notification was disabled for shadowing using ctxcfg. If the user does not respond to
the notification message, the shadow request times out and is terminated.
10.2.2.6.7.2. About Shadowing and the Clipboard
The user of the shadowed session can use the clipboard to copy and paste between the session and
applications running locally. As shadower, you cannot access the contents of the shadowed sessions
clipboardinformation in the clipboard belongs to the shadowed session. However, if you copy information to
the clipboard while shadowing, this information is available to the shadowed session for pasting.
10.2.2.6.7.3. Ending Shadowing
Updated: 2009-11-02
By default, you can end shadowing using the CTRL+* (asterisk) hotkey combination.
To end the shadowing session
1.
Press CTRL+* (asterisk) key of your keyboards numeric keypad.
To configure a different hotkey to end shadowing

If you cannot use the default hotkey combination from the client device you are using or you prefer to use
an alternative, you can configure your own combination. You do this using the ctxshadow command.
The hotkey you configure applies only to the current shadowed session and therefore needs to be set up
each time you shadow a session.
1.
Log on to an ICA session.
2.
At a command prompt, type ctxqsession to display current sessions.
3.
From the results of ctxqsession, identify the session id of the users session that you want to shadow.
4.

ctxshadow {id | servername:id} [-h [[a][c][s]+]x]
where [a][c][s] and x is the hotkey combination you want to use to end shadowingchoose
this combination from:
[a][c][s] a = ALT; c = CTRL; s = SHIFT Note: you can use any combination of a, c and s, including all
or none.
x Choose from the alphanumeric characters: a to z (or A to Z) and 0 to 9.
Example
To begin shadowing, and to specify a hotkey combination of ALT+q to stop shadowing the session, type:
ctxshadow server1:5 -h a+q
Note: The hotkey combination is not case-sensitive; therefore, in the above example, you could choose
ALT+Q or ALT+q to stop shadowing.
10.2.2.6.8. Sending Messages to Users
Updated: 2009-11-20
You can send a message to users using the ctxmsg command. A message can be sent to a particular session
or to all sessions, either on the local server or in the entire server farm.
Tip: If a message includes spaces or any other characters that have a special meaning in your UNIX
shell, enclose all the text in double quotes.
To send a message to users

1.
2.

If you want to send a message to particular sessions, use ctxquser to display the current sessions.
From the results of ctxquser, identify a session id for the users and sessions you want to send a
message to.
3.
To
Use the command
Send a message to a session on the local server.
ctxmsg id message, where id is the
session identifier.
Send a message to a session on another server
in the farm.
ctxmsg servername:id message, where

servername is the name of a server in the
farm, and id is the session identifier. For
example, server1:34 means session 34 running
on server1.
Send a message to all sessions on a

particular server.
ctxmsg -s servername message, where

servername is the name of a server in the farm.
Send a message to all sessions on the local server.
ctxmsg -a message
Send a message to all sessions on all servers in

the farm.
ctxmsg -S message
Send a message that includes a time-out period,

in seconds. The message appears on the user
s screen until it times out or the user dismisses it.
ctxmsg id message timeout
Send a message that will suspend your

terminal window until the message times out or
is dismissed by the user. Note that a
command prompt appears only when the
user responds or the message times out.
ctxmsg -w id message timeout
Examples
ctxmsg 11 Hello
ctxmsg server1:34 Happy Birthday
ctxmsg 5 Fancy lunch? 30
ctxmsg -w server1:34 Are you at your desk? 60
ctxmsg -S Get out, the building is on fire
Tip: To inform users that the server is about to shut down, use the message option with the ctxshutdown
command.
10.2.2.6.9. Printing
This topic describes the information your plugins need to know when they want to print. It explains how users
can list available client printers and print files from a command prompt or from applications.
In the UNIX environment, the application performs the print rendering. The print driver is specified inside
the application or, in the case of a desktop utility, raw unformatted text is generated.
10.2.2.6.9.1. Displaying Client Printers or Printer Ports
Updated: 2009-11-02
When a client device connects to a server, client printers are mapped and are available from the
desktop command line and from applications running in the session.
From a session, users can list the mapped client printers or available printer ports using the ctxprinters
command.
To display mapped client printers
ctxprinters
A list of printers configured on the client device and mapped for use from the ICA session appears.
(default) appears after the printer that is the default. The following information is shown for each printer:
Printer name or printer port (for example, lpt1). This can be used in the ctxlpr -P command to specify
a printer other than the default.
Printer driver name. This is for information only.
Printer connection description. This is for information only.
10.2.2.6.9.2. Printing from a Command Line

Updated: 2009-11-02
Within an ICA session, users can print a file from the command line by using ctxlpr, instead of lpr or lp. If
no files are specified, the ctxlpr command takes its input from standard input (stdin).
To print a file from an ICA session
1.
2.
3.
At a command prompt, type ctxprinters.

From the results of ctxprinters, identify the printer or printer port that you want to use. To print to
a printer other than the default, note the printer name (the printer name is the first item in the
ctxprinters listing).
To
Use the command
Print the file named filename to the default printer.
ctxlpr filename
Print a series of files to the default printer. Each file

is treated as a separate print job.
ctxlpr filename filename
Print a file to a printer (or printer port) other than

the default. This is the printer name or printer
port shown in the first column of the output
from ctxprinters.
ctxlpr -P [Printername | Printerport]

filename
Print a file in the background.
ctxlpr -b filename
Print a file only if the printer is not in use. Use

this option to stop an application waiting while
other printer jobs are handled. If the printer is in
use, an error message appears.
ctxlpr -n filename
Examples
To send the file mydoc.ps to the printer \\PRINTSRVR\Sales_HP4000, use the following command:
ctxlpr -P '\\PRINTSRVR\Sales_HP4000' mydoc.ps
Note: In some UNIX shells, a backslash (\) has a special meaning so you may need to substitute a
double backslash (\\). For example: ctxlpr -P "\\\\PRINTSRVR\\Sales_HP4000" mydoc.ps

If you are using a client device that uses direct printer port mapping:
ctxlpr -P lpt2 mydoc.ps
10.2.2.6.9.3. Printing from Applications
The exact configuration of how to set up printing from applications depends on the behavior and user interface
of the UNIX application.
If the user interface for an application allows you to specify the actual printer command to use when printing,
you can configure client printing by replacing the lpr or lp command with the ctxlpr command.
When a user connects to the server and prints from the application in a session, the server redirects the output
to the mapped client printer.
Often, in this type of application, you can also specify the command-line modifiers on a different line. You can
use the same switches for ctxlpr as when printing from the command line. For example, use -P with a
printer name (or printer port) to print to a printer other than the default; -b for background printing, and so on.
Note: If the user interface of an application does not allow you to specify the actual printer command to
use when printing, find out whether or not the application (or window manager) uses a configuration file
where you can replace the lpr command functionality with ctxlpr.
10.2.2.6.9.4. Troubleshooting Printing
Updated: 2009-11-19
Because UNIX applications generally produce only UNIX ASCII text or PostScript output, PCL (Printer
Control Language) printers are not suitable. Therefore, ensure your client printers support PostScript. If you
do not have a PostScript printer, install a utility such as Ghostscript to convert PostScript files to a
different output format, such as PCL.
If text does not print correctly, this may be due to carriage return / line feed differences between UNIX and
DOS text files. To print a UNIX text file to a Windows printer, use a utility such as unix2dos. For example,
to print a UNIX text file called printfile type:
On Solaris:
unix2dos printfile | ctxlpr
On HP-UX:
ux2dos printfile | ctxlpr
Alternatively, use Perl instead. For example, type:
perl -pe 's/\n$/\r\n/' printfile | ctxlpr
Or, create a script file called unix2dos that includes the following:
#!/bin/sh
perl -pe 's/\n$/\r\n/' "$@"
Make the script file executable using chmod a+rx unix2dos. You can now use the script file just like
the unix2dos utility.
10.2.2.6.10. Connecting to a Remote Server from an ICA Session
Updated: 2009-11-30
You can establish a connection to a remote server from within an ICA session.
When you establish a remote session, you must set the $DISPLAY environment variable in the remote session
to ensure that graphics, keystrokes, and mouse clicks are sent back to your ICA session. To simplify the setting
of $DISPLAY, use the $CITRIX_REMOTE_DISPLAY environment variable.
Example
The following example shows how to establish a connection to the remote server Emily from within an
ICA connection to the server Bagpuss and how to correctly set the value of the $DISPLAY variable
using $CITRIX_REMOTE_DISPLAY.
To connect to the remote server Emily from an ICA session
1.
2.
Establish an ICA connection to Bagpuss.

Open a terminal window and display the value of the $CITRIX_REMOTE_DISPLAY environment variable.
setenv | grep CITRIX_REMOTE
The system displays a value; for example, bagpuss:10.0.
3.
Make a note of the value of $CITRIX_REMOTE_DISPLAY.
4.
Establish a remote logon session to Emily using the rlogin command:

rlogin emily
5.
6.
Enter your logon password.

Open a terminal window and set the value of the $DISPLAY environment variable to the value
of $CITRIX_REMOTE_DISPLAY. For example, if you are using a C shell, type:
setenv DISPLAY bagpuss:10.0
10.2.2.7. Configuring XenApp for UNIX

Updated: 2009-11-30
These topics describe how to configure a XenApp for UNIX server to provide the required resource access
and session behavior for the client users of your network and include information about:
Configuring the server
Screensaver recommendations
Customizing the appearance of a server
Configuring X server settings
10.2.2.7.1. Configuring the Server

Updated: 2009-11-20
You can configure your server in different ways to control access to services for users connecting to the
server. The combination of settings you use depends on how you intend to use your servers. From the server, you can config
The number of ICA sessions you want to allow at this server.
What happens to a session if the connection is broken or times out.
Whether or not to allow local printer mapping. If you enable printer mapping from the server, client
users can configure and use their local printer to print from applications that are actually running on
the server.
Whether or not to allow local clipboard mapping. If you enable clipboard mapping from the server,
client users can copy and paste text between applications running on the client device and the
remote applications running on the server.
Whether or not to allow shadowing.
The maximum permitted session duration, and how long to leave idle or disconnected sessions
before timing out.

Whether or not to allow users to log on without a home directory.Mouse-click feedback.
Note: User access to commands and sessions is controlled by the ctxsecurity function.
10.2.2.7.1.1. Controlling Logon Settings
Updated: 2009-11-30
When client users connect to a server, the users need to supply a user name and password (unless they
are accessing an application published for anonymous use). Users can either type this information in the
dialog box that appears when they connect to the server or published application, or configure the plugin so
that their user name and password are saved as part of the properties for a particular connection.
You can also use the ctxcfg tool on the server to configure settings that give you and client users flexibility
and security when logging on.
To display the current logon settings
1.
2.

ctxcfg -a list
This displays the current logon settings.
Note: The list argument never displays passwords.
To change the logon settings

1.
2.
To
Use the command
Configure the server so that if logon details are set

on the client device, they are used.
ctxcfg -a INHERIT
Configure the server so that a user logging on

is always prompted for a password, regardless of
any password set on the server or the client device.
ctxcfg -a prompt=TRUE
Configure the server so that a user logging on is

not prompted for a password.
ctxcfg -a prompt=FALSE
Set a default user name for all users who log on to

the server. For example, you can use this to set up
a guest user account.
ctxcfg -a user=name
Set a password for all users who log on to the

server. Type pass as a keyword; ctxcfg then
displays a prompt where you can type the
password. Note that if you did not set up a user
name, this setting is ignored.
ctxcfg -a pass
Erase any user name and password details that

were set (using the user and pass options)
and configure the server to use logon details set
on the client device.
ctxcfg -a ERASE
Displaying a Message of the Day

You can specify a message of the day to display to users as they log on. Text stored in
/var/CTXSmf/motd appears in a message box before logon, up to a maximum size of 2 KB.
Configuring RSA SecurID Support
XenApp supports RSA SecurID Versions 4.2 and 5.0, allowing your users to log on to XenApp servers using
RSA SecurID authentication.
Before you configure your servers for RSA SecurID support, ensure that you installed SecurID correctly.
Citrix recommends that you test whether or not you can log on to your system using RSA SecurID before
you attempt to use SecurID with XenApp.
To configure RSA SecurID Support on XenApp
1.
Log on as root to the server.
2.
Go to the directory where RSA SecurID is installed, and change to the prog directory below it.
3.
Find the program files Xprompt (this file is called XPrompt in Version 4.2) and sdfindshell.
4.
5.
Copy the files into the /usr/sbin directory. Note that the copy of XPrompt must use this
spelling, regardless of whether the original is spelled Xprompt or not.
Make the copy of XPrompt executable by using chmod +x.
10.2.2.7.1.2. Setting the Number of Permitted ICA Connections

Updated: 2009-11-05
You can specify a maximum number of concurrent ICA connections that a particular server will support.
To check the current number of permitted connections
1.
2.

ctxcfg -l list
This command displays the number of logons permitted or displays UNLIMITED if no limit is set.
To change the number of permitted connections
1.
2.

To set
Use the command
A maximum, where num is the number

of concurrent connections you want to allow.
ctxcfg -l max=num
No limit to the number of concurrent sessions

you want to allow.
ctxcfg -l max=UNLIMITED
Note: The number of ICA connections that a server can support is also affected by Citrix Licensingsee
Getting Started with Citrix Licensing for more information.
10.2.2.7.1.3. Disabling New Logons

Updated: 2009-11-03
You can prevent any new logons to a particular server, although users can still reconnect to disconnected sessions.
To disable new logons
1.
2.

ctxcfg -k nomorelogons=1
Note that this setting is reset each time XenApp restarts.

10.2.2.7.1.4. Controlling Behavior for Disconnected or Broken Connections
Updated: 2009-11-20
To display the current configuration for broken and timed-out connections
1.
2.

ctxcfg -c list
To configure the settings for disconnected and broken connections

1.
2.

To configure the server so that
Use the command
Broken connections are immediately reset.
ctxcfg -c broken=reset
Broken connections are disconnected.
ctxcfg -c broken=disconnect
A user is automatically logged off from a

broken connection.
ctxcfg -c broken=logoff
A user can connect to a disconnected session from

any client device.
ctxcfg -c reconnect=any
A user can connect to a disconnected session only

from the original terminal.
ctxcfg -c reconnect=original
You can configure the system so that disconnected sessions are reset or logged off automatically after a timeout interval, or continue until a user (or an administrator) resets the session. See Controlling Time-Out Behavior
for details about how to set a time-out interval for disconnected sessions.
10.2.2.7.1.5. Enabling or Disabling Printing for Users
Updated: 2009-11-03
Client printer mapping allows client users to use printers that are available on the client device from
applications running on a server.
Use the ctxcfg tool with the -p switch to enable or disable client printer mapping.
To check if client printing is currently enabled or disabled
1.
2.

ctxcfg -p list
To enable or disable client printing

1.
2.
To
Use the command
Enable client printing.
ctxcfg -p enable
Disable client printing. ctxcfg -p disable

10.2.2.7.1.6. Enabling or Disabling Clipboard Mapping
Updated: 2009-11-03
Users can copy text and graphics between server-based applications and applications running locally on the
client device. Even if an application is running on the server, the clipboard behaves as if it is on the client device.
Use the ctxcfg tool with the -C switch to enable or disable client clipboard mapping.
To check if the client clipboard is currently enabled or disabled
1.
2.

ctxcfg -C list
To enable or disable the client clipboard

1.
2.
To
Use the command
Enable client clipboard mapping.
ctxcfg -C enable
Disable client clipboard mapping. ctxcfg -C disable

10.2.2.7.1.7. Providing Additional Graphics Clipboard Support
Updated: 2009-11-30
XenApp for UNIX provides users with the ctxgrab tool that lets them grab windows or screen areas and
copy them from an application in an ICA session window to an application running on the local client device.
By default, ctxgrab is available to users connecting to published applications through the ctxwm
window manager as follows:
In a seamless window, right click the
button in the top, left hand corner of the screen to display
a menu and choose the Screen Grab option.
In a full screen window, right click to display the ctxwm menu and choose the Screen Grab option.
Users connecting to a server desktop can run the tool by typing ctxgrab at a command prompt.
If you have users who require more extensive graphics clipboard support, you can deploy the ctxcapture
tool. With ctxcapture users can:
Grab dialog boxes or screen areas and copy them between an application in an ICA session window and
an application running on the local client device, including non-ICCCM-compliant applications.
Copy graphics between the client device and the X graphics manipulation utility XV. XV is a
shareware utility that is available for download from the Internet.
Providing Users with xcapture

You do not have to do anything to make ctxcapture available to users connecting to a server desktop; it
is available from a command prompt by typing ctxcapture.
To make ctxcapture available to users who are connecting to published applications, you make it available
from the ctxwm window manager. To do this, you edit the ctxwmgrab.sh script to make ctxcapture, rather than
ctxgrab, available.
To make ctxcapture available to users of published applications
2. Open the ctxwmgrab.sh script.
On HP-UX and Solaris, this is located in the:
/opt/CTXSmf/lib directory
On AIX, this is located in the:
/usr/lpp/CTXSmf/lib directory
3. Find the following line:
exec /opt/CTXSmf/bin/ctxgrab
On AIX:
exec /usr/lpp/CTXSmf/bin/ctxgrab
4. Substitute ctxgrab with ctxcapture.
10.2.2.7.1.8. Enabling or Disabling Shadowing
Updated: 2009-11-20
Session shadowing allows you to monitor the display of another active session. Shadowing lets you see
what users are doing and interact with their sessions, using the keyboard and mouse. You can shadow
active sessions on the same server.
Use the ctxcfg tool with the -s switch to configure shadowing.
Note: By default, any user can shadow any other session. To change this, amend your XenApp
security settings.
To display the current shadowing settings for the server

1.
2.

ctxcfg -s list
The shadowing configuration for the current server appears, for example:
To change the shadowing settings for the server

1.
2.
To enable shadowing
Use the command
So that sessions on the server can be shadowed. By default,

input is set to on and notify to on.
ctxcfg -s enable
To change the input and notify options
Use the command
So that the shadower can input keyboard and mouse actions

to the shadowed session.
ctxcfg -s input=on
So that the shadower cannot input keyboard and mouse

actions to the shadowed session.
ctxcfg -s input=off
So that the shadowed user gets a notification

message requesting confirmation that the shadowing can occur.
ctxcfg -s notify=on
So that the shadowed user does not get a notification message.
ctxcfg -s notify=off
To disable shadowing
Use the command
So that sessions on the server cannot be shadowed.
ctxcfg -s disable
Important: Disabling shadowing notification means that users might be shadowed by another user, but
be unaware that they are being shadowed. Some countries require by law that users be notified
before shadowing occurs.
Example
You may want to set up shadowing to help you solve technical support issues. The system administrator can
show the user how to complete a task by shadowing the users session. To allow shadowing with notification
and to allow the shadower to control the mouse and keyboard, use the command:
ctxcfg -s enable,input=on,notify=on
10.2.2.7.1.9. Controlling Time-Out Behavior
Updated: 2009-11-20
These settings specify time-out intervals in minutes or seconds. The time-outs are:
Connection
The maximum connection duration (in minutes). If a connection duration is

specified, the session is disconnected or terminated when the specified
duration elapses. If NONE is specified, the connection timer is disabled.
Disconnection
The maximum duration that a disconnected session is retained (in minutes). If

a disconnection duration is specified, sessions in the disconnected state are
either terminated or logged off when the specified duration elapses. If NONE
is specified, the disconnection timer is disabled.
Log off
Disconnected sessions can be logged off when the specified duration elapses. You
must also set the disconnection time-out for this to take effect. If NONE is specified,
the disconnected session is reset unless the disconnection time-out is also set to
NONE.If log off fails, the session is reset.
Idle
The maximum idle time (time without user activity) allowed before the session
is disconnected or reset (in minutes). If an idle duration is specified, the session
is disconnected or reset when the specified interval elapses without any activity on
the connection. If NONE is specified, the idle timer is disabled. To specify
whether sessions are disconnected or reset, see To configure the settings
for disconnected and broken connections. To specify an idle time-out period
for anonymous users, see Configuring Anonymous Users.
Authentication
The maximum duration that a session in the connected state exists on the server,
prior to the user logging on or reconnecting (in minutes). When the specified
duration elapses, the session is reset. This is useful, for example, if network
problems result in sessions becoming stuck in the conn state; using this
setting means you do not have to reset these sessions manually.
Client check
The maximum period of time before the server checks that a client device is
still connected and responsive (in seconds). If a client check time-out is set, the
server sends a ping to unresponsive client devices when the specified interval
elapses. If NONE is specified, the client check timer is disabled.
Note: You must configure both client check and client response options if you
want sessions to be disconnected automatically.
Client response
The maximum period of time before the server disconnects sessions associated
with unresponsive client devices (in seconds). If a client response time-out is set,
the server disconnects all sessions associated with unresponsive client devices when
the specified interval elapses. Client devices must respond to the servers ping
during the specified time period to prevent sessions from being
disconnected automatically. If NONE is specified, the client response timer is disabled.
Note: You must configure both client check and client response options if you
want sessions to be disconnected automatically.
To display the current time-out intervals

1.
2.

ctxcfg -t list
The current time-out value for each setting appears. If a time-out interval is configured, the value is shown
in minutes. If no time-out interval is configured, the keyword NONE shows that sessions will not be timed out.
To change the time-out intervals

1.
2.
To set
Use the command
A connection time-out (in minutes). All

connections are terminated after this period.
ctxcfg -t connect=num
No connection time-out. All sessions continue

until the user disconnects or logs off.
ctxcfg -t connect=NONE
A disconnection time-out (in minutes).

Disconnected sessions are reset after this
period unless you specified that they be logged
off (see below).
ctxcfg -t disconnect=num
No disconnection time-out. Disconnected

sessions remain until reset by a user or
an administrator.
ctxcfg -t disconnect=NONE
A disconnection time-out (in minutes).

Disconnected sessions are logged off after this period.
ctxcfg -t disclogoff=num
No logoff time-out. Disconnected sessions are

reset unless the disconnect time-out was also set
to None.
ctxcfg -t disclogoff=NONE
An idle time-out (in minutes). If no user activity

is detected during this time, the connection
is terminated.
ctxcfg -t idle=num
No idle time-out. All sessions continue until the

user disconnects or logs off.
ctxcfg -t idle=NONE
An authentication time-out (in minutes). If a

session remains in the connected state after
this period, the session is reset.
ctxcfg -t authentication=num
No authentication time-out.
ctxcfg -t authentication=NONE
A client check time-out (in seconds). If the

server receives no traffic from the client
device during this period, it sends a ping to the
client device to check if the plugin is still responding.
ctxcfg -t clientcheck=num
No client check time-out.
ctxcfg -t clientcheck=NONE
A client response time-out (in seconds). If the

server does not receive a response to the ping sent
to the client device during this period, the session
ctxcfg -t clientresponse=num
is disconnected.
No client response time-out.
ctxcfg -t clientresponse=NONE
Note: Only new sessions are affected by changes to the time-out intervals. ctxcfg -t has no effect
on anonymous usersto specify an idle time-out period for anonymous users, see Configuring
Anonymous Users.
Example
If you expect users to dial in to the server, you may want to set the disconnect time-out to a suitable setting
in case of a broken connection. Users can reconnect to their sessions during the time-out interval. To set
the disconnection time-out to 15 minutes, type:
ctxcfg -t disconnect=15
10.2.2.7.1.10. Allowing Users to Log on without a Home Directory
Updated: 2009-11-03
By default, users whose home directories are unavailable cannot log on to the server. However, you can
configure the server to allow users whose home directories are unavailable to log on. For example, you might
do this if your users home directories are mounted on a network that is occasionally unreliable.
If you allow users whose home directories are unavailable to log on, all explicit users (that is, users who
have their own user accounts) can log on, regardless of whether their home directories are available or
not. Anonymous user accounts are not affected by these changes, because anonymous users are never allowed
to log on without a home directory.
A temporary home directory is allocated to users in: /tmp/CTXSmf_uid where uid is a decimal number;
for example, /tmp/CTXSmf_12345.
If users log on and their home directory is unavailable, the following message appears: Your home directory
is unavailable. Logging you in with temporary home directory: /tmp/CTXSmf_uid.
Important: You must make your users aware that /tmp/CTXSmf_uid is temporary and may be deleted at
a later stage. Any changes and additions that users make in this directory must be applied to their
normal home directory when this becomes available.
In the unlikely event that there is a problem with the /tmp/CTXSmf_uid directory, the temporary home
directory defaults to: / (the root directory). Note that some applications may not operate correctly when
the home directory is / because users do not have write permissions.
To allow users whose home directories are unavailable to log on
1.
2.

ctxcfg -k lognohome=1
To prevent users from logging on without a home directory

1.
2.

ctxcfg -k lognohome=0
10.2.2.7.1.11. Configuring Mouse-Click Feedback for High Latency Connections

Updated: 2009-11-19
With mouse-click feedback, when a user clicks the mouse, the plugin software changes the mouse pointer to
an hourglass to show that the users input is being processed. Mouse-click feedback is enabled by default.
Typically, you do not need to configure mouse-click feedback; however, for high latency connections, you
may want to adjust this to improve your users interaction with the system.
You can configure the thresholds in which mouse-click feedback operates, or you can disable mouseclick feedback. To do this, you use the ctxcfg command with the -m option:
ctxcfg -m [enable|disable] [lowerthreshold=num] [upperthreshold=num] [list]
About the Thresholds
Mouse-click feedback is controlled by upper and lower threshold values, which are like switches that
determine when mouse-click feedback is on or off. The thresholds are the network delay between client
device and server (that is, the latency) that triggers the display of the hourglass symbol.
Upper threshold. If the latency exceeds the upper threshold, the hourglass symbol appears.
Lower threshold. If the latency falls below the lower threshold, the hourglass symbol does not appear.
Between the two thresholds. What happens between the upper and lower thresholds depends
upon whether the latency is increasing or decreasing. If the latency was previously above the
upper threshold but falls to between the two thresholds, the hourglass symbol appears until the
latency drops below the lower threshold. If the latency was previously below the lower threshold
but increases to between the two thresholds, the hourglass symbol does not appear until the
latency increases above the upper threshold. This controls the sensitivity of mouse-click feedback,
and prevents the hourglass from flickering on and off as the latency fluctuates.
By default, the upper threshold is 500 milliseconds and the lower threshold is 150 milliseconds. The
following diagram illustrates what happens between the default threshold values.
To change the mouse-click feedback thresholds

1.
2.

ctxcfg -m lowerthreshold=num,upperthreshold=num
where num is the threshold value in milliseconds.
To disable mouse-click feedback

1.
2.

ctxcfg -m disable
To display current mouse-click feedback settings

1.
2.

ctxcfg -m list
Information similar to the following appears:
Mouse click feedback: enabled

Lower threshold for mouse click feedback: 150
Upper threshold for mouse click feedback: 500
10.2.2.7.1.12. Generating and Using Server Configuration Details
Updated: 2009-11-03
You can generate a list of the current ctxcfg settings for a particular server. If you send the output to a file,
you can use the file in a shell script to replicate identical configuration settings on other servers. You can also
use a file as a temporary backup of the current configuration, allowing you to experiment with other settings,
but easily restore your original settings, if desired.
To display a list of the current ctxcfg settings
1.
2.

ctxcfg -g
This generates a list of the current settings.
Creating a Shell Script of the Current Configuration

When you use the -g option with the ctxcfg command, the generated list contains the commands and
settings for the current configuration using the ctxcfg command-line syntax. You can redirect the output of
this command to a file and use the file as a shell script to restore (or set) this configuration.
To propagate the same configuration from one server to another
You can use the output from ctxcfg -g if you want to configure a number of servers in the same way.
1.
2.
Complete the configuration of the first server. Generate a list of the server configuration using the ctxcfg
command and the -g option, piping the output of the command to a file. Note that ctxcfg -g does
not generate the logon password, so you need to enter this manually.
Log on to the next server as an administrator and run the file as a shell script.
Tip: You can use the scp (secure copy) command to propagate the shell script on a remote server.
10.2.2.7.1.13. Screensaver Setting Recommendations
Updated: 2009-11-03
ICA connections running graphical screensavers can consume considerable server resources. Therefore,
Citrix recommends that you switch screensavers off. In XenApp for UNIX, screensavers are switched off by default.
To switch screensavers off
Run the xset command with the s option and off parameter:
xset s off
To ensure published applications are run in sessions with the appropriate screensaver settings, Citrix
recommends you publish a script file that runs the xset s off command and then the application.
Note: Although you can switch screensavers off by default, CDE may override this setting. To switch
the screensaver off in CDE, choose the Screen option in the Style Manager and set Screen Blanker to off.
To switch screensavers on
Although it is best to switch screensavers off, if you prefer not to (for example, for security reasons), you can
use the X server prefer blanking screensaver option. This causes the screen to go blank, rather than display
a pattern, when the screensaver is activated.
To switch screensavers on, run the xset command with the s option and blank parameter:
xset s blank
For example, to make the screen go blank after one minute, use the commands:
xset s 60
xset s blank
To display the current screensaver setting
To display the current settings, run the xset command with the q option.
xset q
10.2.2.7.2. Customizing the Appearance of XenApp
Updated: 2009-11-30
You can customize XenApp to change the appearance of the XenApp Login screen and the window manager,
and remove the X font server from the font path.
Your XenApp installation includes script files that you can customize. These scripts are located in the
following directories:
/opt/CTXSmf/lib and /opt/CTXSmf/slib
On AIX:
/usr/lpp/CTXSmf/lib and /usr/lpp/CTXSmf/slib
The script ctxXtw.sh runs when the X server starts, and includes X server configuration settings such as the
font path and the X security policy. By default, the XenApp X server does not use a security policy (for the
X security extension). It is disabled by the option -sp /dev/null in ctxXtw.sh. If you want to use a security
policy, write the security policy (see the Xserver man page for details about how to do this) and then change
this option in ctxXtw.sh to point to the policy file.
Note: Information about the switches in ctxXtw.sh is contained in a file called ctxXtw.sh.readme.
The script ctxsession.sh runs after a user logs on. You can use this script file to customize the local
environment for user sessions, such as defining the default window manager, configuring scripts, or
setting environment variables for users.
10.2.2.7.2.1. Customizing the Login Screen
Updated: 2009-11-30
You can change the appearance of the Login screen by substituting the Citrix logo frame for a graphic of
your choice. The graphic you choose must be in .xpm (X pixmap) format.
The graphic used in the Login screen is located in:
/opt/CTXSmf/data/C/LOGO.xpm
On AIX:
/usr/lpp/CTXmf/data/C/LOGO.xpm
The image that appears is limited to 120 x 200 pixels and 256 colors. If you use a larger graphic, only the 120
x 200 pixels in the center of the graphic appear. If you use a smaller graphic, the image displayed is centered
in the frame.
To display a different logo on the Login screen
1.
2.
Rename the current Citrix LOGO.xpm file; for example: old_LOGO.xpm
3.
Rename your new graphic to LOGO.xpm and move this to the appropriate .../CTXSmf/data/C/
directory (see previous).
The new graphic appears on the Login screen

10.2.2.7.2.2. Changing the Window Manager
Updated: 2009-11-20
Using ctxsession.sh you can configure the system to load a window manager other than CDE. You can do this
for every user who logs on to the server, or for a particular user.
You can change the window manager that XenApp loads for connections to server desktops and
published applications running in full screen windows. By default, the ctxwm window manager is loaded for
all connections to published applications.
To use a different window manager for every user
Use the following procedure to load a new window manager for every user who logs on to the server.
Note: The window manager is not loaded for any initial programs that a user set on the client device. To
do this, use the To use a different window manager for a particular user procedure.
1.
2.
Install the new window manager.
3.
Open the ctxsession.sh script and locate the following line:
: ${CDE_WM:="/usr/dt/bin/dtsession"}
4.
Change this line to:
: ${CDE_WM="/path/window_manager"}
where path is the location of the new window manager and window_manager is the name of the
new window manager.
To use a different window manager for a particular user

Use the following procedure to load a new window manager for a particular user each time the user logs on.
The new window manager is also loaded for any initial programs that the user set on the client device.
1.
2.
Install the new window manager.
3.
Open the ctxsession.sh script and locate the following lines:
#if [ -f $HOME/.ctx.session.sh ] ; then

# . $HOME/.ctx.session.sh
#fi
4.
Remove the # character from the start of each line, so that these lines are no longer commented out.
5.
In the users home directory, create a file called .ctx.session.sh.
6.
In the .ctx.session.sh file, add the new window managers bin directory to the path:
PATH=${PATH}:/path
where path is the location of the new window managers bin directory.
7.
Add lines to load the new window manager and suppress the message that tells the user that the
window manager is being loaded:
DESKTOP_WM=/path
DESKTOP_MESSAGE=
where path is the location of the new window managers start file.
8.
Add lines to load the new window manager when an initial program is launched, and suppress
8.
the message that tells the user that the window manager is being loaded:
INITIAL_APPS_WM=/path
INITIAL_APPS_MESSAGE=
where path is the location of the new window managers start file.
Example
The following example shows the lines required in the users .ctx.session.sh file to start the kde window manager:
PATH=${PATH}:/usr/local/kde/bin
DESKTOP_WM=/usr/local/kde/bin/startkde
DESKTOP_MESSAGE=
INITIAL_APPS_WM=/usr/local/kde/bin/startkde
INITIAL_APPS_MESSAGE=
The result is that every time a user logs on, the system checks for the .ctx.session.sh file in the users
home directory. If it finds this file, the system runs it and the new window manager is loaded. If the file is
not found, or the user connects to a published application, CDE is loaded.
10.2.2.7.2.2.1. Troubleshooting the ctxwm Window Manager
Updated: 2009-11-30
This topic describes problems that you or your users may experience when using the ctxwm window
manager, and provides possible solutions for them.
Preventing Published Application Windows being Placed Off-Screen
To prevent windows for published applications being positioned off-screen, use the DontPlaceOff option in
the system.ctxwmrc file.
In /opt/CTXSmf/data/C/system.ctxwmrc, uncomment the following line:
#DontPlaceOff # do not allow windows to be placed off screen, even
Ignoring Modifier Map Entries

The modifier map entries set for the ctxwm window manager may cause some applications to
behave unexpectedly. For example, the behavior of lock keys such as CAPS LOCK may be unpredictable. To
make ctxwm ignore some modifier map entries, use the IgnoreModifier option in the system.ctxwmrc file.
The IgnoreModifier option takes the form: IgnoreModifier { keyword }, where keyword can be one or more
of the following, separated by spaces:
Keyword
Modifier Affected
shift
shift modifier
lock
lock modifier
control
control modifier
mod1 modifier
m1
mod1 modifier
m2
mod2 modifier
m3
mod3 modifier
m4
mod4 modifier
m5
mod5 modifier
a1
mod1 modifier
a2
mod2 modifier
a3
mod3 modifier
a4
mod4 modifier
a5
mod5 modifier
For example, in /opt/CTXSmf/data/C/system.ctxwmrc, add lines such as the following:
IgnoreModifier { m3 m5 lock } # Ignore lock key modifiers (Num/Scroll/Caps)

Note: Different systems can have different modifiers mapped to different keys.
Fixing Input Focus Problems
Applications that do not follow one of the ICCCM input focus models may behave unexpectedly on XenApp
for UNIX because ctxwm adheres strictly to ICCCM. These applications may not set the appropriate X
properties to allow the window manager to determine how to handle focus. To address this issue, use
the ForceFocus option in the system.ctxwmrc file. This option permits more flexibility for non-ICCCM
compliant applications.
Use the ForceFocus option to list either the WM_NAME or WM_CLASS (instance or class) to identify
windows where the focus should be set. Use the xprop utility to determine these values for windows with
focus issues. The best value to use depends on whether you are configuring an isolated window or a set
of application windows. To fix the focus issue for a single window, use the WM_NAME property. To fix the
focus issue for a set of windows, use the WM_CLASS property. For example, the third party party
application Slickedit does not follow ICCCM. Adding the Slickedit WM_CLASS value
to /opt/CTXSmf/data/C/system.ctxwmrc as follows fixes the focus issue for all the Slickedit application windows:
ForceFocus {
Slickedit
}
10.2.2.7.2.3. Changing the Font Path
Updated: 2009-11-05
By default, the font path contains the X font server. However, you can remove the X font server from the
font path by editing the ctxsession.sh script.
For information about the X font server, and how to set it up, refer to the documentation provided with the X
font server.
About Font Servers and Font Paths
An X Windows session can obtain the fonts that it requires locally or from a font server. A font server
provides sessions with fonts and performs font conversion. Typically, a font server is used to deploy a set of
fonts across a network; it is also useful for applications that have particular font requirements, such as
TrueType fonts.
The path that a session takes to search for fonts is determined by the font path. The ctxXtw.sh script on
the server, that runs when the X server starts, sets the default font path. The ctxsession.sh script, that runs
after a user logs on, checks whether or not the font path contains the X font server. If the font path does
not contain the X font server, ctxsession.sh adds it (provided the X font server is running).
Important: XenApp does not start the font server. Therefore, Citrix recommends that you enable the
font server to start automatically.
Removing the Font Server from the Font Path
You can remove the font server from the font path by editing the ctxsession.sh script.
For example, you may want to remove the font server from the font path if the font server causes
performance problems on the XenApp server. Note, however, that performance problems are unlikely to
occur unless many short-term applications run on the server and make demands on the font server.
To remove the font server from the font path
1.
2.
USE_FONT_SERVER=1
3.
Set the USE_FONT_SERVER flag to zero:
USE_FONT_SERVER=0
10.2.2.7.3. Configuring X Server Settings
Updated: 2009-11-30
To configure X server settings, such as switching on the backing store feature, you edit ctxXtw.sh which is a
script file that runs when the X server starts. You can also edit ctxXtw.sh to configure settings for particular
fixes to take effect. For more information, see the ctxXtw.sh.readme file.
10.2.2.7.3.1. Configuring Backing Store
Updated: 2009-11-03
You can switch on the backing store feature in the X server for applications that rely on this functionality.
Backing store caches the contents of the window displayed by an application and, where necessary,
automatically repaints the window from the cache.
By default, backing store is switched off.
When Should Backing Store be Switched On?
Only some applications require backing store to be switched on. An application may require backing store if
the application appears to be running very slowly or users experience screen corruption problems.
Because the use of backing store can increase the bandwidth between the server and the client device,
Citrix recommends that you do not switch backing store on unless you are deploying applications that require it.
To switch backing store on
1.
2.
Open the ctxXtw.sh script and locate the following line:
XTW_OPTS=-session $CITRIX_SESSION_ID -terminate -bs

3.
Delete the -bs parameter from this line to turn backing store on.
To switch backing store off

1.
To switch backing store off, reinstate the -bs parameter in the ctxXtw.sh script.
10.2.2.7.3.2. Interactive Performance Tuning

Updated: 2009-11-03
XenApp lets you control the display of graphics in ICA sessions by allowing you to specify the length of delay
for the buffering of graphics. You can do this by setting two parameters. Both set a delay time in
milliseconds. Recommended settings are between 5ms and 100ms. Setting the delay time to a lower value
makes the session more responsive to graphics updates, but may increase the bandwidth requirements for
the connection.
To control the outbuffer delay time

1.
2.
To
Use the command
Set the delay time, where num is the time

in milliseconds
ctxcfg -o set=num
List the current setting
ctxcfg -o list
To reset the current setting to 100ms
ctxcfg -o reset
To control the buffer delay for Thinwire 2 graphics operations

1.
2.
Open the ctxXtw.sh script and find the line that begins with
XTW_OPTS
3.
Add the command-line option -qandtdelay n; for example,
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -qandtdelay 10 -bs"

10.2.2.7.3.3. Configuration Required for Fixes to Take Effect
This topic explains how to configure your server for particular fixes to take effect. If you do not require
these fixes, you can disregard this topic.
10.2.2.7.3.3.1. Fixing the Disappearing Text Cursor Problem
To fix the disappearing text cursor problem, include the -notransfills switch in ctxXtw.sh. This switch turns off
the transparent fills optimization setting that can cause this problem with some plugins and 256-color sessions.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -notransfills. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -notransfills -bs"

10.2.2.7.3.3.2. Enabling the Left-Hand Keypad of SPARC Keyboards
Updated: 2009-11-03
If you are using the CDE window manager, you need to configure your server to enable the left-hand keypad
of SPARC keyboards. To do this, you include the bindings file, edit the xmbind.alias file, and edit users
logon scripts, as follows:
To enable the left-hand keypad of SPARC keyboards
1.
Copy the bindings file, included on the XenApp installation media or in the download, to
the /usr/dt/lib/bindings directory. The bindings file contains keyboard mapping information.
2.
Edit the /usr/dt/lib/bindings/xmbind.alias file. This file contains server and bindings file
mapping information. Include the following line in the list of mappings:
"Citrix Systems Inc"

3.
To activate the Find key on the SPARC keypad, you must edit your users logon scripts, as follows:
If you are using a C shell, add the command:
xmodmap -e "keysym F19 = SunFind" >& /dev/null

If you are using a Bourne shell, add the command:
xmodmap -e "keysym F19 = SunFind" 1>/dev/null 2>&1
xmodmap -e "keysym F19 = SunFind" 1>/dev/null 2>&1

Note: For this fix to take effect, you must also ensure that your users are running Version 6 (or later) plugins.
10.2.2.7.3.3.3. Fixing the Disappearing X Cursor Problem
In applications, such as Sunguard Forex, that hide the X cursor and use their own bitmap cursor, problems
with the X cursor can occur over high-latency connections. To fix the disappearing X cursor problem, include the
-notranscursor switch in ctxXtw.sh. This switch stops the application from causing the X cursor to disappear.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -notranscursor. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -notranscursor

-bs"
10.2.2.7.3.3.4. Fixing Screen Refresh Problems
Updated: 2009-11-20
If an application has a complex graphical interface and you encounter screen refresh problems, include the
-frameexpose switch in ctxXtw.sh. This switch forces the server to redraw the application from the servers
frame buffer. With complex screen displays, this method is faster than allowing the application to redraw itself.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -frameexpose. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -frameexpose -bs"

Cadence Applications
For Cadence applications, you must also include the -palette and -noredrawpalette switches because
Cadence uses palette animation that sends one palette change per second. Use the -palette switch to filter
out these unnecessary palette changes. Other palette changes are sent to the client device, but only after a
delay of 1500 milliseconds (1.5 seconds). The -noredrawpalette switch reduces the communication between
the server and the client device, if the application changes colors that are not currently visible in the session.
Note: A possible side-effect of including the -palette switch is that the sending of palette changes from
server to client device is delayed. This means that it can take longer for objects to appear properly and, at
first, objects may appear in unexpected colors until the new palette is sent. For example, you may see
this effect when a splash screen first appears or when CDE first appears. This is normal.
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -frameexpose

-palette 1500 -noredrawpalette"
If this setting does not improve performance sufficiently, use -palette 3500 instead:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -frameexpose

-palette 3500 -noredrawpalette"
Tip: You may also find it beneficial to switch on backing store.
10.2.2.7.3.3.5. Fixing NUM LOCK Problems
Some applications may behave unexpectedly when NUM LOCK is in the modifier map. By default, the NUM
LOCK modifier map entry is enabled. To disable it, include the -nonumlockmodmap switch in ctxXtw.sh.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -nonumlockmodmap. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -nonumlockmodmap

-bs"
10.2.2.7.3.3.6. Fixing Java Application Splash Screen Problems
If a user clicks on a splash screen displayed by a Java application, the splash screen may hang or the
application may start slowly. This is caused by the Java application and the window manager repeatedly
setting the input focus of the X server. You can address this issue by reducing the CPU usage. To do this,
include the -ipfocussleepinterval switch in ctxXtw.sh and set it to the length of time in microseconds that the
X server should sleep. You can set this value to between zero and 1000 microseconds. Normally
100 microseconds is sufficient, but you may need to experiment to determine the best value.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -ipfocussleepinterval. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate

-ipfocussleepinterval 100 -bs"
10.2.2.7.3.3.7. Disabling Color Cursor Support
XenApp supports color cursors by default. Color cursors can be any two colors of your choice. To disable
this feature, include the -nocolorcursors switch in ctxXtw.sh.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -nocolorcursors. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -nocolorcursors

-bs"
10.2.2.7.3.3.8. Disabling Scrollmouse Support
You can turn off the X servers capability to handle any scrollmouse events sent from the client device
by including the -noscrollmouse switch in ctxXtw.sh.
In ctxXtw.sh, find the line that begins with XTW_OPTS and add -noscrollmouse. For example:
XTW_OPTS="-session $CITRIX_SESSION_ID -terminate -noscrollmouse

-bs"
10.2.2.7.4. Color Depth Limitations
Updated: 2009-11-20
The limitations relaating to color depth depend on the types of applications to which users connect.
Applications Requiring Writable Palettes
Some X applications require writable palettes, known as PseudoColor visuals, for color or image
manipulation. However, XenApp supports only writable palettes in ICA sessions using a color depth of 256
colors. Therefore, applications requiring PseudoColor visuals will not work in ICA sessions using High Color
and True Color color depths. This is because High Color and True Color sessions use TrueColor visuals, in
which colors are predefined and cannot be changed.
If users connect to applications that require PseudoColor visuals, ensure that the ICA connection uses a
color depth of 256 colors. If a connection is made at a higher color depth, the application may display an
error message. To check if an application requires PseudoColor visuals, refer to the applications
documentation, or test the application on the server console or in a published desktop to ensure that it works.
To configure an application to use a color depth of 256 colors when connecting using the Web Interface, use the
ctxappcfg tool with the Color Depth option.
Applications Requiring 16-bit High Color
XenApp supports 15-bit High Color connections, although some plugins refer to High Color as 16-bit in
the Window Color property settings.
Some applications explicitly require a 16-bit display and will, therefore, not run in a 15-bit High Color
connection. Other applications that require a 16-bit display may attempt to run in a 15-bit connection and
fail, causing screen corruption. If you require a high color resolution to run these applications, use a True
Color (24-bit) connection instead.
10.2.2.7.5. Multimonitor Display Limitations
Updated: 2009-11-05
The limitations of multimonitor display depend upon whether users connect to applications running
in multimonitor mode using seamless or remote desktop windows.
Limitations Using Seamless Windows

If you use a seamless window, the primary monitor must be the left-most and top-most monitor. If you
attempt to use a seamless window in multimonitor mode with another configuration, the ICA session reverts
to running a full-screen window that spans the virtual desktop.
The color depth of an ICA session is limited by the lowest color depth in the display. For example, on a
dual-monitor system, if one graphics card is configured to display 256 colors and the other graphics card
is configured to display 24-bit color, the ICA session color depth is limited to 256 colors, regardless of the
monitor on which the session appears.
If you are using graphics card drivers that create a virtual desktop, ICA sessions are maximized to fill the
virtual desktop.
Pop-up message boxes, dialog boxes, and windows displayed by applications running in a seamless window
may appear centered relative to the center of the entire desktop. When using graphics card drivers that create
a virtual desktop, these elements are centered relative to the center of the virtual desktop.
Limitations Using Remote Desktop Windows
If you use a remote desktop window, pop-up message boxes, dialog boxes, and windows appear centered in
the session window, regardless of how the ICA session window appears across multiple monitors.
10.2.2.8. Advanced Topics
Updated: 2009-11-30
These topics describe advanced system administration and include information about the following:
Configuring anonymous user settings
Configuring XenApp security
Understanding and configuring the ICA Browser Service
Load balancing published applications
Configuring ICA gateways
Using ICA with network firewalls
Configuring the TCP/IP port number
Configuring session status logging
Configuring the operating system for a large number of connections
Configuring non-English language support
10.2.2.8.1. Configuring Anonymous Users

During installation, you can create a special user group called ctxanon on the server, together with 15
local anonymous user accounts. These accounts allow 15 users guest access to applications that you publish
for anonymous use.
Anonymous user accounts do not usually require further maintenance; however, their properties can be
displayed and modified using the ctxanoncfg command.
Note: You must be root to display and update anonymous user settings.
10.2.2.8.1.1. Displaying Anonymous User Settings
Updated: 2009-11-05
Use ctxanoncfg to display the current number of anonymous user accounts, the naming of the accounts,
the anonymous user group name, and the idle time-out period.
To display anonymous user settings
1.
Log on to the server as the root user.
2.
At a command prompt, run ctxanoncfg with the -l option to display anonymous user settings:
2.
ctxanoncfg -l
10.2.2.8.1.2. Configuring Anonymous User Settings

You can use ctxanoncfg to change the number of anonymous user accounts, the names of the anonymous
user accounts, and the idle time-out period for anonymous user sessions. You can also use ctxanoncfg to
specify a particular shell or assign user ids to anonymous user accounts.
Tip: The ctxanoncfg command displays what it is doing at each stage, together with any errors that
may occur. To suppress the display of this information, use the -q (quiet) option with the ctxanoncfg
command. For example, type: ctxanoncfg -n 20 -q
10.2.2.8.1.2.1. Changing the Number of Anonymous Users
Updated: 2009-11-20
Use ctxanoncfg with the -n option to change the number of anonymous user accounts. You can create
any number of anonymous user accounts, but the number you can use simultaneously is limited by your
licensed user count.
Further options are available that allow you to change the naming of anonymous user accounts and the idle
time-out period.
Important: You must stop XenApp on the server before you create anonymous users. If XenApp is
running, use the ctxshutdown command to stop it.
To create anonymous users
1.
2.
Ensure XenApp is not running on the server and log on as root.

At a command prompt, use ctxanoncfg with the -n option to specify the new number of anonymous
user accounts you require:
ctxanoncfg -n number
where number is the new number of anonymous user accounts.
3.
Start XenApp, using the ctxsrv command.
Examples
To specify 20 anonymous user accounts, type:

ctxanoncfg -n 20
To delete all anonymous user accounts, type:
ctxanoncfg -n 0
10.2.2.8.1.2.2. Changing the Naming of Anonymous User Accounts
Updated: 2009-11-18
Use ctxanoncfg with the -b option to change how anonymous user accounts are named. By default, the
ctxanon group contains 15 user accounts with names in the format anonx, where x is a number from one to
15. User account names can have a maximum of eight characters.
Note: You can use the -b option only when creating new anonymous user accounts; -b cannot be used
to change existing anonymous user accounts.
To change how anonymous user accounts are named

1.
After stopping XenApp, log on as root.
2.

ctxanoncfg -n number -b name
where number is the new number of anonymous user accounts, and name is the new name of the accounts.
Example
To create 25 anonymous user accounts called guest1, guest2 ... up to guest 25, type:
ctxanoncfg -n 25 -b guest
10.2.2.8.1.2.3. Setting an Idle Time-Out Period
Updated: 2009-11-30
Use ctxanoncfg with the -t option to specify the idle time-out period, in minutes, for anonymous user sessions.
If there is no user activity within this time, a warning message informs users that they will be logged off after
five minutes, unless they resume use of the session. The default idle time-out period is 10 minutes.
To specify an idle time-out period
1.
2.

ctxanoncfg -n number -t minutes
where number is the new number of anonymous user accounts and minutes is the idle time-out period.
Examples
To create 25 anonymous user accounts with a time-out period of 30 minutes, type:
ctxanoncfg -n 25 -t 30
To alter only the time-out period to 20 minutes, type:
ctxanoncfg -t 20
10.2.2.8.1.2.4. Specifying a Particular Shell for Anonymous Users
Updated: 2009-11-30
When anonymous user accounts are created, the default system shell is assigned to these accounts; for
example: /bin/sh. However, you can specify a particular shell to use for anonymous user accounts, using
ctxanoncfg with the -s option.
To specify a particular shell
1.
2.

ctxanoncfg -n number -s shell
where number is the new number of anonymous user accounts and shell is the shell you want to assign
to these accounts.
Example
To create 25 anonymous user accounts that use the C shell, type:
ctxanoncfg -n 25 -s /bin/csh
10.2.2.8.1.2.5. Specifying User Ids for Anonymous Users
When anonymous user accounts are created, XenApp automatically assigns available user ids to these
accounts. However, you can assign specific user ids to anonymous user accounts. To do this, you use ctxanoncfg
with the -u option and specify the first user id in the range.
To assign specific user ids
Updated: 2009-11-18
1.
2.

ctxanoncfg -n number -u uid-number
where number is the new number of anonymous user accounts and uid-number is the first user id
you want to generate.
Example
To create 10 anonymous user accounts with user ids 10,027 to 10,036, type:
ctxanoncfg -n 10 -u 10027
10.2.2.8.1.3. Troubleshooting Anonymous User Accounts
Updated: 2010-03-26
If you experience problems with anonymous user accounts, delete the current anonymous user
configuration, using ctxanoncfg with the -clear option, and then create new anonymous user accounts. The
-clear option removes all internal anonymous user account configuration, such as the home directories
and entries in the password file.
To delete all anonymous user account configuration
1. After stopping XenApp, log on as root.
2. At a command prompt, type:
ctxanoncfg -clear
Anonymous User Accounts and NIS Domains

All anonymous user accounts are created as local (non-NIS) accounts, with home directories in /usr/anon.
Citrix recommends that you do not attempt to reconfigure these accounts to be NIS accounts, or move the
home directories for these users onto non-local (for example, NFS) file systems.
To create user home directories on another file system, create a symbolic link from /usr/anon to the desired
file system.
10.2.2.8.2. Configuring XenApp Security
Updated: 2009-11-20
When you install XenApp, default security settings automatically control user access to various commands.
By default, users can log on, send messages, and shadow other sessions, but they are denied access to all
other commands.
XenApp security lets you tighten or relax user access to commands and sessions. With XenApp security you can:
Change the default security settings. For example, by default, all users can shadow other users
sessions, but you may want to prevent this.
Provide groups of users with access to commands and sessions. For example, you may want to give
the helpdesk user group the rights to connect, disconnect, and reset other users sessions.
Deal with exceptions on an individual user basis. For example, you may want to prevent a particular
user from being able to send messages to other users sessions.
10.2.2.8.2.1. Security Overview

Updated: 2009-11-19
Which Users Are Affected by Security?
XenApp security controls user access to specific commands and sessions.
However, security does not control administrator access to commands and sessions. This means the
ctxadm group is unaffected by XenApp security. Security controls the access rights of the root user and
ordinary users (explicit and anonymous users).
Who Can Do What in XenApp
The following table provides a brief summary of which users can do what in XenApp. Only the functions
indicated by ctxsecurity are controlled using security.
Functions/commands
root user
ctxadm
Other users
Install and remove XenApp
Yes
No
No
Start and stop server processes
Yes
Yes
No
Configure the server
No
Yes
No
Log on to the server
ctxsecurity
Yes
ctxsecurity
Query who is on the server
Yes
Yes
Yes
Perform actions on others sessions, such

as shadowing or resetting sessions
ctxsecurity
Yes
ctxsecurity
Perform actions on their own sessions
Yes
Yes
Yes
Send messages
ctxsecurity
Yes
ctxsecurity
Note: If root is unable to log on at the server, this may be due to the CONSOLE setting in the
/etc/default/login file (the /etc/security/user file on AIX), that can be used to prevent root logging on at
a terminal other than the one specified. The ctxsecurity command cannot be used to override the
CONSOLE setting.
Which Functions Can ctxsecurity Control?
XenApp security controls access to specific functions called secured functions. The secured functions are shown
in the following table:

Secured function Security determines...
login
Which users can log on to the XenApp server.
sendmsg
Which users can use ctxmsg to send messages to other users sessions.
connect
Which users can use ctxconnect to connect to other users sessions.
disconnect
Which users can use ctxdisconnect to disconnect other users sessions.
logoff
Which users can use ctxlogoff to log off other users sessions.
reset
Which users can use ctxreset to reset other users sessions.
shadow
Which users can use ctxshadow to shadow other users sessions.
cdm
Which users can use client drive mapping to access their local drives.
Controlling Security at Different Levels

Security can be controlled at the:
User levelthat is, UNIX user level
Group levelthat is, UNIX group level
Global levelthat is, UNIX global level
A global security setting exists for every secured function. When you install XenApp, security is
automatically controlled at the global level for each secured function. For example, by default, all users can
send messages to other sessions.
However, you can also configure security for individual users or for groups of users. For example:
If you want to prevent a user from sending messages to other sessions, you can set up user-level
security to deny access to ctxmsg
You can set up group-level security for the Support group to allow members of this group to reset
other users sessions using ctxreset
If no user or group-level security exists, the global security level determines user access rights.
The Security Checking Process
To configure XenApp security or troubleshoot security, you need to understand how the security checking
process works.
When a user attempts to run a secured function, XenApp checks whether or not the user has the rights to do
so. It first checks the user security level, then, depending on the result, the group security level. If neither
user nor group-level security exists, a final check is made at global security level.
The following diagram shows each step in the security checking process, using the example of a user
attempting to run the ctxshadow command:
10.2.2.8.2.2. Default Security Settings

Updated: 2009-11-24
A global security setting always exists for each secured function. The global setting acts as the default,
when neither user level nor group level security exists. Because the primary function of security is to deny
access to unauthorized users, the global security setting can be thought of as the last line of defense.
After installation, the default settings are:
Secured function
Default global setting
Login
Allow
Sendmsg (ctxmsg)
Allow Deny for

anonymous users
Connect (ctxconnect)
Deny
Disconnect (ctxdisconnect)
Deny
Logoff (ctxlogoff)
Deny
Reset (ctxreset)
Deny
Shadow (ctxshadow)
Allow Deny for

anonymous users
Cdm
Allow
Note: By default, root cannot log on to the server from a client device. However, if your super user has
a different account name from root or multiple account names, the super user can log on from a client device.
To change the default settings, see Configuring Security Settings.
10.2.2.8.2.3. Displaying Security Settings for a Function
Updated: 2009-11-18
Use the -l (list) option with the ctxsecurity command to display security settings for a particular function.
You must specify the secured function for which you want to display settings. All levels of security (user,
group, and global) appear for the function.
To display security settings for a function
1.
2.

ctxsecurity secured-function -l
where secured-function is one of: login, sendmsg, connect, disconnect, logoff, reset, shadow, or cdm
.
Example
To display security settings for the ctxshadow function, type:
ctxsecurity shadow -l
Security settings such as the following appear:
global allow
group users deny
10.2.2.8.2.4. Configuring Security Settings
You can use the ctxsecurity command to change the global security settings or to configure user and group
level security.
10.2.2.8.2.4.1. To change a global security setting
Updated: 2009-11-18
You can use the ctxsecurity command with the -a (all) option to change the global security setting for a
secured function.
1.
2.

ctxsecurity secured-function -a allow|deny
.
Example
To change the global security setting for the ctxshadow tool to deny, type:
ctxsecurity shadow -a deny
10.2.2.8.2.4.2. To configure security for a user
Updated: 2009-11-18
You can use the ctxsecurity command with the -u (user) option to configure security at the user level.
For example, you might want to allow a particular user access to a function that is denied at the global level.
1.
1.
2.

ctxsecurity secured-function -u user-name allow|deny
.
Example
To allow the user fred to use the ctxreset command to reset other users sessions, type:
ctxsecurity reset -u fred allow
10.2.2.8.2.4.3. To configure security for a group of users
Updated: 2009-11-18
You can use the ctxsecurity command with the -g (group) option to configure security at the group level.
For example, you might want to allow a group of users access to a function that is denied at the global level.
1.
2.

ctxsecurity secured-function -g group-name allow|deny
.
Example
To allow the group Support to use the ctxreset command to reset other users sessions, type:
ctxsecurity reset -g support allow
10.2.2.8.2.4.4. To inherit a security setting
Updated: 2009-11-18
You can use the inherit option with the ctxsecurity command to remove previously set security settings.
This option is useful when you want to remove settings that are exceptional cases.
For example, the Management group is allowed to shadow other sessions, but the user Fred, a member of
this group, is an exception and has been denied access to shadowing. When it is later decided to allow Fred
to shadow, the administrator can use inherit to reinstate the groups security setting. In effect, inherit
removes Freds user-level security setting, and picks up the security setting from group level.
Users can inherit settings from the group or global level, while a group can inherit settings from the global
level. Global security settings cannot inherit values.
1.
2.

ctxsecurity secured-function {-u user-name|-g group-name} inherit
.
Example
To remove Freds user-level security setting for the ctxshadow command and reinstate the groups
security setting, type:
ctxsecurity shadow -u fred inherit
The result is that Fred inherits a security setting. XenApp checks which groups Fred belongs to, and whether
any of these groups have a group level security setting. If at least one group level setting exists that
allows shadowing, Fred inherits the right to shadow. Otherwise, if at least one group level setting exists
that denies shadowing, Fred is not permitted to shadow. If no group level setting exists, Fred inherits rights
from the global level.
10.2.2.8.2.5. Examples
Updated: 2009-11-06
In the following examples, security is tightened and then used to provide a group of users access to a
particular function.
Example 1: Locking Down Security
After installation, the default security settings allow users to shadow other users sessions. However,
the administrator decides to tighten security to prevent this.
The administrator does this by changing the global security setting for the shadowing function:
ctxsecurity shadow -a deny
Exmaple 2: Giving Rights to a Group of Users
Security is configured so that users are prevented from shadowing other users sessions. However, the
helpdesk group needs to be able to shadow so they can help users with problems.
The administrator uses security to provide the helpdesk user group access to the shadowing function:
ctxsecurity shadow -g helpdesk allow
10.2.2.8.3. XenApp for UNIX and the ICA Browser Service
The ICA browser maintains data about published applications and XenApp servers. The ICA browser consists of
a master browser, member browsers, and plugins. The ICA browser uses directed packets to communicate
with other ICA Browser Services running on servers.
Citrix plugins query the browser service to obtain a list of published applications and XenApp servers. The
plugin queries the browser service for the network address of servers and published applications when a
session is launched.
10.2.2.8.3.1. Controlling the Master Browser
Updated: 2009-11-06
Every server runs the ICA Browser Service. One XenApp server is elected the master browser; all other
XenApp servers on the network are member browsers. The master browser is a browser acting as a
central information store. The master browser keeps track of the following information:
The available servers
The available published applications
Performance and load information for servers
The master browser for each network is chosen by a master browser election. If the current master browser on
a network is not responding, a new master browser election is held automatically. This provides high reliability
for the browser service.
In general use, the browser service is invisible to you and does not affect the continued operation of
XenApp. However, you may want to manipulate the possibility of a particular server becoming the
master browser, because:
Servers running different versions of XenApp provide different versions of the browser service when
they are master browser. This can affect the features available to users. In particular, if you have
servers running XenApp for Windows in your network, you may want to ensure that a server
running XenApp for UNIX in the network does not become the master browser.
The master browser service consumes more resources and may respond slowly if it is running on a
heavily loaded server. Therefore, you may want to make sure that servers that receive many
connections are less likely to become the master browser. If necessary, you can configure the settings
of one or more dedicated servers in the network so that one of them is more likely to become the
master browser.
To locate the master browser

You can use the ctxqserver command with the -master option to locate the server acting as the master browser.
1.
2.

ctxqserver -master
The address of the master browser on the local subnet appears. If no master browser is running, for
example during a browser election, the error message Error obtaining requested information appears.
10.2.2.8.3.2. Manipulating Master Browser Elections
Updated: 2010-03-26
The browsers on a network subnet elect a master browser under any of the following conditions:
The current master browser does not respond to another browser
The current master browser does not respond to a plugin
A XenApp server is started
Two master browsers are detected on the same network subnet
A combination of factors affect the outcome of the election. The two main factors are:
The version of XenApp running on the server
The master browser preference setting for each server
You set this preference using the ctxbrcfg tool for XenApp for UNIX servers. Servers can be set to:
neutral The default value of no preference behavior in elections.
always Always attempt to become master browser.
never Never attempt to become master browser.
Other factors, such as the length of time a server has been running and whether the server is also a Windows
NT domain controller (not applicable to XenApp for UNIX), can also affect an election result.
Tip: You can force a master browser election using the ctxqserver -election command.
10.2.2.8.3.3. Introducing a New Server
Introducing any type of XenApp server into your network forces an election.
The default master browser preference setting for a XenApp for UNIX server is neutral; that is,
unbiased. If you add a server with this default setting to a network that includes XenApp for
Windows servers in mixed mode that are also configured as unbiased in elections, the XenApp for
UNIX server will not become the master browser. Under these circumstances, a XenApp for Windows
server in mixed mode automatically has preference to become the master browser.
If you add a XenApp for UNIX server to a network that includes only other such servers, it may
become master browser if all the other servers are set to neutral.
Important: It is the combination of settings for all servers on the network that decides the results of
an election. A XenApp for UNIX server could still win a master browser election with a XenApp for
Windows server if the master browser preference on the Windows server is set to never.
10.2.2.8.3.3.1. Biasing the Results of Elections
Updated: 2009-11-24
If you do not mind which server becomes master browser
1.
Leave the master browser preference setting on each server to the default setting of neutral or
no preference, as appropriate for the type of server.
If you want a particular server to be the master browser

1.
Configure the master browser preference on the server you want to become master browser to be always
. Use the ctxbrcfg command for XenApp for UNIX servers. For XenApp for Windows servers, see the
Citrix XenApp Administrators Guide.
2.
Leave the master browser preference on the other servers to be neutral or no preference,
as appropriate for the type of server. Do not set the other servers to be neverreserve this setting for
a particular server that should never become master browser.
The changes you make using ctxbrcfg will cause a master browser election to occur. Wait a few moments for
the election to take place and then check the master browser status using the ctxmaster command.
If you want to stop a particular server from becoming the master browser
1.
Configure the master browser preference on the server that you do not want as the master browser to be
never, using the ctxbrcfg command.
Important: Do not set the master browser preference on all servers in a network to be never
because unpredictable election results will occur.
2.
Leave the master browser preference on the other servers that can become the master browser to be
neutral or no preference as appropriate for the type of server. Any changes you make using the ctxbrcfg
command will cause a master browser election to occur.
Note: If the XenApp for UNIX server has more than one network interface card and is connected on more
than one subnet, restrict the server to one subnet; for details, see If a Server Uses Multiple Network
Interface Cards.
10.2.2.8.3.3.2. Configuring the ICA Browser
Updated: 2009-11-06
The ICA browser maintains data about published applications and XenApp servers. You can display and
change the browser settings on a server using the ctxbrcfg tool. Any changes you make using ctxbrcfg
will cause a master browser election to take place.
To control how the ICA browser behaves during browser elections
1.
2.
To
Use the command
Configure the server so that it always attempts to become

the master browser in an election, subject to the presence
and actions of other browsers.
ctxbrcfg -m always
Configure the server so that it refrains from participating in

an election. Note that the server can still become the
master browser under some circumstances.
ctxbrcfg -m never
Configure the default behavior of no preference.
ctxbrcfg -m neutral
The refresh period controls how often the browser on this server updates the master browser. The
browser updates the master browser after the specified amount of time elapses. A short refresh period makes
the master browser data more accurate, but increases CPU and network load.
To view or change the refresh interval for the ICA Browser Service
1.
2.
To
Use the command
Display the current refresh interval.
ctxbrcfg -r list
Set a period (in minutes) at which the local browser service

will update the master browser.
ctxbrcfg -r set=num
Note: The default settings work for most installations. Change them only when you understand the
implication of each setting.
10.2.2.8.3.3.3. Starting and Stopping the ICA Browser
Updated: 2009-11-06
You can start and stop the ICA browser process on a server, without having to stop and start all the
XenApp processes, using the ctxsrv tool.
If you stop the browser on a server, users cannot connect to published applications on this server, although
they will still be able to connect to the server desktop. If you stop the browser process on the master browser,
a master browser election will occur among the other servers on the network.
To start or stop the ICA browser using ctxsrv
1.
2.

ctxsrv {start|stop} browser
10.2.2.8.3.3.4. If a Server Uses Multiple Network Interface Cards

Updated: 2009-11-06
If a XenApp server has more than one network interface card (NIC) and is connected on more than one
subnet, problems may occur if this server attempts to become master browser on a subnet. If the server
becomes master browser on one subnet, it may assume it is also master browser on another subnet that
already has a master browser.
To prevent this from occurring, you must configure the server so that the browser communicates only with
other browsers on a particular subnet or NIC. This means that you must bind the server to a particular subnet
or NIC.
To do this, you use the ctxbrcfg command with the -b option.
To restrict the ICA browser to a particular subnet or NIC
1.
2.
Stop the browser by typing:

ctxsrv stop browser
3.

ctxbrcfg -b set=address
where address is the IP address or subnet address you want to restrict the ICA browser to, in aaa.bbb.
ccc.ddd formatfor example, 10.20.123.123.
4.
Restart the browser by typing:
4.
ctxsrv start browser
To remove a restriction on an ICA browser

1.
2.

ctxsrv stop browser
3.

ctxbrcfg -b unset
4.
Restart the browser by typing:

To display current restrictions on an ICA browser

1.
2.

ctxbrcfg -b list
If there are no restrictions, the message No address specified, binding to all available adapters appears.
If there are restrictions, the message Browser bound to adapter address aaa.bbb.ccc.ddd appears (where
aaa.bbb.ccc.ddd is the IP address or subnet address to which the ICA browser is restricted).
Troubleshooting Multiple Network Interface Cards

If you bind the server to a subnet, make sure that there is only one NIC on this subnet, or the browser will
not start and an error will be written to the system log. Instead, bind to a specific NIC rather than the network.
10.2.2.8.4. Load Balancing Published Applications
This topic introduces load balancing and explains how to tune load balancing in your XenApp installation.
Load balancing determines which servers are least busy and can best run an application. The master
browser keeps track of the load levels and the number of users connected on each server. When a
published application or desktop is launched from a client device, the master browser selects which server will
run the application or desktop session, based on server load. For more information about the master browser, see
XenApp for UNIX and the ICA Browser Service.
Load balancing also offers increased availability. By configuring a pool of servers capable of running your
users applications, you can easily bring servers off-line for maintenance or add more servers for
increased performance without affecting application availability.
If you are deploying applications using the Web Interface, load balancing works in the normal way. The
Web Interface contacts the XML Service, which in turn contacts the master browser. The master browser
then distributes connections among the servers, taking load factors into account.
10.2.2.8.4.1. Load Balancing a Group of Servers
Updated: 2009-11-06
By default, XenApp automatically monitors the number of users connected to each server and sends
new connections to the server that is least busy.
However, if a user already has a disconnected session on a server, the disconnected session is
reconnected, regardless of how busy the server is.
To load balance a group of servers
1.
2.
Publish the application on each server.
2.
Allow users to connect to the published application. Connections are distributed among all the servers
on which the application is published.
Note: Load balancing works by identifying the names of published applications. Therefore, make
sure that the application you want to load balance over a group of servers is given the same name in
ctxappcfg on each server.
10.2.2.8.4.2. Tuning Load Balancing

Updated: 2009-11-30
Different types of serversfor example, with different processor speeds or available memorycan accept
a different number of connections before becoming busy. If you find that some servers become busier than
others with evenly distributed connections, you can tune load balancing so that this is taken into account.
You can bias the distribution of connections to take into account the relative speed and power of a server. To
do this, you use ctxcfg with the -k loadfactor option to adjust the load factor.
By default, each server has a load factor of 100. However, if you have a server that is more powerful relative
to the other servers in the group, you can increase the load factor to ensure that this server receives
more connections. Likewise, if you have a server that is less powerful, you can decrease the load factor to
ensure that it receives fewer connections. The load factor can be any number between 1 and 10000.
To tune the load on each server
1.

ctxsrv stop browser
2.

ctxcfg -k loadfactor=num
where num is a load factor value between 1 and 10000.
3.
Start the browser by typing:

Alternatively, you can use ctxcfg with the -l option to control the number of connections permitted on
each server.
Examples
Example 1
There are 10 servers in a server farm, each running XenApp for UNIX. One server has a higher than
average processor than the others, and you estimate that it can handle 50% more load than the other servers.
On the more powerful server, allow 50% more load than on the other servers in the group. At a command
prompt type:
ctxsrv stop browser ctxcfg -k loadfactor=150 ctxsrv start browser
Example 2
There are five servers in a server farm, each running XenApp for UNIX. One server has a lower than
average processor, and you estimate that it can handle 25% less load than the others.
On the less powerful server, allow 25% less load than on the other servers in the group. At a command
prompt type:
ctxsrv stop browser ctxcfg -k loadfactor=75 ctxsrv start browser
To tune the number of connections on each server
1.
When a user experiences problems running a session, use the ctxqsession command to identify
1.
the server to which the user is connected.
2.
Count the active number of sessions on the server that is causing the problem, and then limit
the maximum number of users who can log on to the server using ctxcfg and the -l option.
3.
Limit the maximum number of users who can log on, on the other servers, in a similar way. For
best results, set a value on each server.
Example
A word-processing application is published on a number of servers. Occasionally, a server becomes
overloaded. This is due to a high number of users concurrently using the application (rather than that
the application places a high demand on server resources, such as in the case of a CAD application).
Therefore, you decide to limit the number of connections permitted on each server to 200.
On each server on which the application is published, restrict the number of connections to a maximum of 200.
ctxcfg -l max=200
To display the load factor
If you tuned the load using ctxcfg -k loadfactor, you can display the current load factor setting for a
server using the ctxcfg -g command.
1.
At a command prompt, type: ctxcfg -g | grep loadfactor
To display the load

You can display the load for a particular server or application using the ctxqserver -app command.
1.
At a command prompt, type: ctxqserver -app [application-name | server-name]

where application-name is the name of a published application, and server-name is the name of the
server for which you want to display the load.
10.2.2.8.4.3. Troubleshooting Load Balancing

If users frequently disconnect and reconnect to sessions on load balanced servers rather than logging off, the
load may not be distributed evenly among the servers.
Also, if users are using plugins that support session sharing and they start multiple applications, the plugins
will attempt to start subsequent applications within the existing session, rather than create a new session.
This may lead to uneven application load distribution among the servers.
10.2.2.8.5. Configuring ICA Gateways
Updated: 2009-11-09
For servers or client devices to contact XenApp servers on a different network, an ICA gateway must
be configured.
The master browser maintains the browse list and periodically receives updates from other browsers
(XenApp servers) on the same network. The exchange of information between the master browser and the
other browsers takes place over the local subnet. To communicate and exchange information with other
networks, you must establish an ICA gateway on the participating networks.
If you have more than one network subnetfor example, if you use a router or a WAN to connect two
networksyou need to set up an ICA gateway to allow the master browsers on each network to share
information about available servers and published applications.
An ICA gateway consists of at least two XenApp servers. The local server is responsible for contacting the
other network and setting up a link between the master browsers on each network. The remote server is a
server on the other network that communicates with the local server to establish the ICA gateway.
To display the ICA gateways configured on a server
1.
2.

ctxbrcfg -g list
To add or remove an ICA gateway

2. At a command prompt:
To
Use the command
Add a gateway host name or IP address to the list.
ctxbrcfg -g add=gateway
Remove a gateway host name or IP address

from the list.
ctxbrcfg -g remove=gateway
Note: You can also use the ctxqserver -gateway command to display information about the ICA
gateways known to each server on the network; see the Command Reference for details.
10.2.2.8.6. Using ICA with Network Firewalls
Updated: 2009-11-20
Network firewalls can allow or block packets based on the destination address and port. If you are using
ICA through a network firewall, use the information provided in this topic to configure the firewall.
ICA TCP/IP Connection Sequence
1.
The client device sends a packet to port 1494 on the XenApp server requesting a response to a
randomly selected port above 1023.
2.
The server responds by sending packets to the client device with the destination port set to the
port requested in Step 1.
If you have a firewall or other TCP/IP network security, configure it to allow TCP/IP packets on port 1494 to
pass to servers on your network.
Configure the firewall to allow TCP/IP packets on outbound ports above 1023 to pass to client devices.
If the firewall is not configured to pass ICA packets, users may receive the error message There is no route
to the specified subnet address.
Note: You can configure the XenApp server to use a different port number from 1494, using the ctxalt -a
command. Plugins must be configured to use the different port; see the documentation for the plugins you
plan to deploy.
The ICA Browser
The ICA Browser Service uses UDP port 1604. Browser responses are sent to a high port number above 1023.
The firewall must be configured to allow inbound UDP port 1604 packets to XenApp servers for load balancing
and ICA server browsing to function correctly.
Citrix recommends you use the XML Service to avoid passing UDP through the firewall; for more information see
Using the Citrix XML Service.
Caution: Allowing untrusted access to the ICA Browser Service entails some security risk. Configure
the firewall to pass browser data only if load balancing and server browsing across the firewall are essential.
10.2.2.8.7. ICA Browsing with Network Address Translation
Updated: 2009-11-20
Some firewalls use IP address translation to convert private (intranet) IP addresses into public (Internet)
IP addresses. Public IP addresses are called external addresses because they are external to the
firewall, whereas private IP addresses are said to be internal addresses.
Hosts on the internal network have one set of addresses that is translated to another set when passing
through the firewall. For example, an internal host has a private address 192.168.12.3. The firewall
translates this into a different public address such as 206.103.132.20.
To browse published applications and XenApp servers, the plugin contacts a server and requests the address
of the master browser. If the plugin is external to the firewall, it must be configured to use the public address of
a XenApp server. The server returns the IP address of the current master browser to the plugin. By default, the
IP address returned to the plugin is the internal address.
If the client device is outside the firewall and the firewall is configured for address translation, the IP
address returned to the plugin for the master browser will be incorrect.
Returning External Addresses to Client Devices
Use the ctxalt command to configure the browser to return the external IP address to client devices. You
must configure every server that can be elected as the master browser.
The ctxalt command sets an alternate address for the browser on that computer. The external address for
the server is specified as the alternate address. The plugin requests the alternate address when
contacting servers inside the firewall. The alternate address must be specified for each server.
To set an alternate address for a server
1.
Determine the correct external IP address.
2.
At a command prompt, type ctxalt -a browser-address alternate-address.
3.
Repeat on each server.
In addition to specifying the alternate address on the server, the plugin must be configured to request
the alternate address when contacting the master browser. For information about configuring plugins to
request the alternate address, see the documentation for the plugins you plan to deploy.
10.2.2.8.8. Configuring the TCP/IP Port Number
Updated: 2009-11-19
By default, the TCP/IP port number used by the ICA protocol is 1494. You can change the port number using the
ctxcfg command with the -P option.
The port number should be in the range 102465535 and must not conflict with other port numbers being
used. Whenever the port number is changed, the server must be restarted for the new value to take effect.
Important: If you change the port number on the server, you must also change it on every plugin that
will connect to that server. For instructions about changing the port number on client devices, see
the documentation for the plugins that you plan to deploy.
To display the current TCP/IP port number
1.
2.

ctxcfg -P list
To change the TCP/IP port number

1.
2.
To set
Use the command
The port number to the value num
ctxcfg -P set=num
The port number back to the default, 1494 ctxcfg -P reset
Examples
To set the TCP/IP port number to 5000:
ctxcfg -P set=5000
To reset the port number to 1494:
ctxcfg -P reset
10.2.2.8.9. Configuring Session Status Logging
Updated: 2009-11-19
This topic explains how to configure the logging of session events in the system log file. Using the ctxcfg
command with the -k option, you can control the logging of session logons, logoffs, disconnects, and
reconnects. To do this, use the following keywords: logonlogging, logofflogging, reconnectlogging, and
disconnectlogging. Set each keyword to one of the following values:
0. Do not log the event.
1. Enable the short form of logging. This provides default syslog information, such as the date and time, and
the user name.
2. Enable detailed logging. This provides default syslog information, the user name, the session id, client
device name, and information about what is running, such as a published application name or desktop.
To configure session event logging
1.
2.
To
Use the command
Log session logons
ctxcfg -k logonlogging={0|1|2}
Log session logoffs
ctxcfg -k logofflogging={0|1|2}
Log session reconnects
ctxcfg -k reconnectlogging={0|1|2}
Log session disconnects
ctxcfg -k disconnectlogging={0|1|2}
Example
To enable detailed logging for reconnects, type:
ctxcfg -k reconnectlogging=2
10.2.2.8.10. Configuring the Operating System for a Large Number of Connections
Updated: 2009-11-09
You may need to configure your system for a large number of connections. A large number of
connections consumes resources; therefore, it is important that you choose the optimum values for
your environment. Configuration instructions differ, depending on your operating system. For each
operating system, a large number of connections is defined, as follows:
Operating Systems No. of connections
Solaris
30+
HP-UX
10+
AIX
30+
10.2.2.8.10.1. Configuring a Solaris System

Updated: 2009-11-09
If you are configuring a Solaris system to support more than 30 connections, you may need to configure the
total number of pseudo-terminals or increase the limits on the number of files. You may also need to increase
the number of concurrent CDE sessions that can be run. By default, this number is limited.
For further information about how best to configure your system, see your Solaris documentation.
Caution: Be careful when using the set command in /etc/systemit causes unchecked, arbitrary,
and automatic changes to variables in the kernel. If the server will not start and you suspect a problem
with /etc/system, use the boot -a command. See the boot man page for more information.
Updated: 2009-11-09
In a large number of ICA connections, the number of ptys (pseudo-terminals) can easily surpass the default
value (usually a session has at least one pty).
To change the number of pseudo-terminals
1.
Add the following lines to the /etc/system file:
# set limit on pseudo-terminals

set pt_cnt = 500
Note: Do not set pt_cnt above 3000.
2.
Shut down the serverfor example, type:

init 0
3.
Restart the server:

boot -r
10.2.2.8.10.1.2. Increasing File Limits

Updated: 2009-11-09
There is a limit to the number of files a process can have open; the default value is 64. To increase the file
limits for an individual process, use the ulimit command in a script before launching the process, as in
the following example.
To change the file descriptor limits for all processes
1.
Add the following lines to the /etc/system file:
# set hard limit on file descriptors

set rlim_fd_max = 4096
# set soft limit on file descriptors
set rlim_fd_cur = 256
2.
Restart the server:

boot -r
10.2.2.8.10.1.3. Increasing the Number of Concurrent CDE Sessions

Updated: 2009-11-09
With the default configuration of Solaris, there is a limit to the number of concurrent CDE sessions that can be
run (approximately 60, depending upon session configuration). This is due to the tooltalk database reaching
a limit of available file descriptors. However, you can increase the number of possible concurrent CDE sessions.
The procedure for increasing the limit on concurrent CDE sessions depends on whether or not the
file /usr/dt/bin/rpc.ttdbserverd is a link to /usr/openwin/bin/rpc.ttdbserverd. Check this before you make
any changes.
To increase the limit on concurrent CDE sessions if the file is link
1.
Remove the file /usr/dt/bin/rpc.ttdbserverd:

rm /usr/dt/bin/rpc.ttdbserverd
2.
Replace the link with the following script file. In this example, ulimit is used to increase the limit to 1024:
#!/bin/sh
ulimit -n 1024
exec /usr/openwin/bin/rpc.ttdbserverd
3.
Make the file executable:

/bin/chmod a+x /usr/dt/bin/rpc.ttdbserverd
4.
Kill the currently running rpc.ttdbserverd process.
5.
Restart rpc.ttdbserverd to ensure the new limit is applied.
To increase the limit on concurrent CDE sessions if the file is not a link
1.
Edit the file /usr/dt/bin/rpc.ttdbserverd and change the limit.
2.
3.
10.2.2.8.10.1.4. If the Database Gets Corrupted

Updated: 2009-11-20
Files in /TT_DB occasionally get corrupted, and messages such as the following may appear in
your /var/adm/messages file:
/usr/dt/bin/ttsession[11627]: Error: rpc.ttdbserverd on 127.0.0.1 is not running

/usr/dt/bin/ttsession[11627]: _Tt_db_client::connectToDb(): fcntl(F_SETFD): Bad file number
/usr/dt/bin/ttsession[11627]: _Tt_db_file::_Tt_db_file(): _file_cache->insert(<your hostname>:/
/usr/dt/bin/ttsession[11627]: _Tt_db_file::_Tt_db_file(): _file_cache->insert(<your hostname>:/

If you suspect that the database is corrupted, do the following:
1.
Remove all the files in the /TT_DB directory
2.
3.
Restarting the server automatically creates new database files.

10.2.2.8.10.2. Configuring an HP-UX System
Updated: 2009-11-09
This topic provides guidelines for configuring your HP-UX system for more than 10 connections.
For further information about how best to configure your system, see the relevant white papers on
Hewlett-Packards Web site at http://docs.hp.com/.
To configure your HP-UX system for more than 10 connections
1.
Choose System_Admin from the Application Manager.
2.
Choose Sam.
3.
Enter the root password at the prompt. The System Administration Manager dialog box appears.
4.
Choose Kernel Configuration.
5.
Choose Configurable Parameters. The Kernel Configuration dialog box appears.
6.
Update your system with the following settings. This tunes your system to run multiple processes (each
of which may have many threads and open files) and increases the number of users that can log
on concurrently.
Note: Change the value of maxusers firstthis allows you to update the other settings.
Parameter
Setting
Description
maxusers
1000 (or as required) Allocates system resources for macros on

expected maximum users.
dbc_max_pct
20
Maximum dynamic buffer cache.
max_thread_proc
2048
Maximum threads per process.
maxfiles
2048
Soft limit of files per process.
maxfiles_lim
2048
Hard limit of files per process.
maxssiz
401604608
Maximum process storage segment size.
maxssiz_64bit
1073741824
Maximum process storage segment size64-bit.
maxswapchunks
4096
Maximum swap space configurable on the system.
nflocks
3461
Maximum number of file locks on the system.
npty
2000
Maximum number of ptys (pseudo-terminals) on

the system.
10.2.2.8.10.3. Configuring an AIX System

Updated: 2009-11-09
If you are configuring an AIX system to support more than 30 connections, you may need to configure the
total number of pseudo-terminals or increase the limits on the number of processes per user.
For further information about how best to configure your system, see the relevant white papers on IBMs Web
site at: http://www.ibm.com/.

Updated: 2009-11-09
In a large number of ICA connections, the number of ptys (pseudo-terminals) can easily surpass the default
value (usually an ICA session has at least one pty).
To change the number of pseudo-terminals
1.
Log on as root on the server that you want to configure.
2.
Type smit. The System Management Interface Tool dialog box appears.
3.
Choose Devices.
4.
Choose PTY.
5.
Choose Change/Show Characteristics of the PTY.
6.
Change the number of Pseudo-Terminals.
7.
Select OK. pty0 changed appears.
10.2.2.8.10.3.2. Increasing the Number of Processes Per User

Updated: 2009-11-10
On AIX, by default, there is a limit to the number of processes a user can have running simultaneously.
The default is 128 processes per user.
If a user runs out of processes, the user cannot run any commands or log off from the session until
more processes are made available. For example, this situation may occur in a training scenario where
several users are logged on to the server using only the one training user id.
You can increase the number of processes a user can run simultaneously using SMIT.
To increase the number of processes per user
1.
Log on as root on the server.
2.
Type smit. The System Management Interface Tool dialog box appears.
3.
Choose System Environments.
4.
Choose Change/Show Characteristics of Operating System.
5.
Increase the value of Maximum number of PROCESSES allowed per user (Num).
10.2.2.8.11. Configuring Non-English Language Support

Updated: 2009-11-24
XenApp dialog boxes and system messages appear in US English, which is the default language. However,
you can run XenApp in a non-English locale by configuring the server so that dialog boxes and system
messages appear in French, German, or Spanish. The XenApp Login screen, user dialog boxes, and
system messages that appear in ICA sessions appear in the language appropriate to your users.
Configuring XenApp for non-English language support is a simple process that involves editing the ctxenv.
sh script to change the locale in which the server runs. For information about configuring the server for
non-English language support, see Changing the Locale.
Before you edit ctxenv.sh, the server starts in the currently active locale; that is, the server starts in the
locale that is active when you log on to the console. If this locale provides non-English language support
(see below for details of locales that provide non-English language support), ICA connections appear in
the appropriate language: French, German, or Spanish. If the currently active locale does not provide nonEnglish language support, ICA connections appear in US English.
To ensure the server uses the appropriate locale, you must edit the ctxenv.sh file and restart the server. If you
do not edit ctxenv.sh, the server uses the locale that is active when it starts, and this may produce
unexpected results. For information about editing ctxenv.sh, see Changing the Locale.
10.2.2.8.11.1. Which Locales Provide Non-English Language Support?

XenApp provides non-English language support for the following locales:
French ISO 8859-1, ISO 8859-15
German ISO 8859-1, ISO 8859-15
Spanish ISO 8859-1, ISO 8859-15
For example, if the server is configured to use the French ISO 8859-1 locale, French dialog boxes and
system messages appear to client users.
10.2.2.8.11.2. Limitations of Non-English Language Support
Updated: 2009-11-09
Only French, German, or Spanish language support is provided. Although XenApp will run in other locales,
no language support is provided. For example, the server can run in an Italian locale and support
Italian keyboards, but dialog boxes and system messages appear in US English, not Italian.
If you configure the server for non-English language support, this localizes only the Login screen, dialog
boxes, and system messages that appear within ICA sessions. This does not localize the commands you use
to administer XenApp, or the man pages and shell scripts.
In addition, only the messages within dialog boxes appear in the appropriate language. Other information,
such as dates and times, may be incorrect. For example, an incorrect date and time may appear in the
Reconnect dialog box.
Getting More Information about Language Support
To fully localize your installation in a language other than US English, you need to:
Deploy appropriate language versions of the plugin software. You can download plugins from http:
//www.citrix.com/download/. For information about how to install, configure, and deploy plugins to
end-users, see the appropriate plugin documentation.
Deploy appropriate language versions of applicationsfor information about how to publish
applications, see Publishing Applications and Desktops.
If your users are using non-English keyboards, ensure they select the appropriate keyboard in the
plugin software. For information about supported keyboards, see Configuring Non-English
Language Support; for information about selecting keyboards, see the documentation for the
appropriate plugin.
10.2.2.8.11.3. Changing the Locale

Updated: 2010-03-26
To configure the server for non-English language support, you edit the ctxenv.sh script to change the locale
in which the server runs. This script is located in the following directories:
/opt/CTXSmf/slib directory
On AIX:
/usr/lpp/CTXSmf/slib directory
To make this process as simple as possible, the ctxenv.sh script includes standard entries for commonly
used locales. To change the locale in which the server runs, you uncomment the line for the appropriate locale
in ctxenv.sh.
The following example shows the standard entries in ctxenv.sh on the Solaris platform:
To change the locale

2. Stop the server using the ctxshutdown command.
3.
Open the ctxenv.sh file and locate the following lines:
# Reset all environment variables so inherited values are ignored.

# UNCOMMENT THE NEXT LINE and the line for your chosen locale.
#LANG=;LC_MESSAGES=;LC_TIME=;LC_NUMERIC=;LC_CTYPE=;LC_MONETARY=;LC_COLLATE=;LC_ALL=
4. Remove the # character from the start of the line beginning with #LANG=.
5. Find the line containing the locale you want to apply and remove the # character from the start of this
line. Note that you can apply only one locale. For example, to choose the French ISO 8859-1
locale, remove the # character from the following line:
#LANG=fr_FR.ISO8859-1;LC_MESSAGES=fr
6. Save the changes to the ctxenv.sh file.
7.
Start the server using the ctxsrv start all command.
The server starts in the appropriate locale.
Example: To use the German ISO 8859-15 locale

1.
Remove the # character from the start of the following line:
#LANG=;LC_MESSAGES=;LC_TIME=;LC_NUMERIC=;LC_CTYPE=;LC_MONETARY=;LC_COLLATE=;LC_ALL=
2.
Include the following line:
LANG=de_DE.ISO8859-1;LC_MESSAGES=de
If the Locale You Require Is not Listed in ctxenv.sh

If the locale you require is not included in the ctxenv.sh script, you can edit ctxenv.sh to include this locale.
Make sure you remove the # character from the start of the #LANG= line (as described in the above
procedure), and that you apply only the one locale.
Note: Only the locales listed in Which Locales Provide Non-English Language Support? provide nonEnglish language support. If you include a locale that is not listed, US English appears by default.
10.2.2.8.11.4. Troubleshooting Non-English Language Support
Updated: 2009-11-09
Cannot Find ctxenv.sh
The ctxenv.sh script is located in the following directories:
For HP-UX and Solaris:
/opt/CTXSmf/slib
For AIX:
/usr/lpp/CTXSmf/slib
After Editing ctxenv.sh, Information Still Appears in English
If you configure the server to display in French, German, or Spanish, only the Login screen, user
dialog boxes, and system messages that appear in ICA sessions appear in the appropriate language.
The commands that you use to administer XenApp, and the man pages and shell scripts remain in
US English. For more information about configuring your server console for non-English language
support, see your UNIX software documentation.
If you select a locale that is not supported by XenApp, US English is used by default.
Dialog Boxes and System Messages Appear in the Wrong Language
Check that the ctxenv.sh script was edited correctly, otherwise the server uses the locale that is
active when the server starts, and this may produce unexpected results.
Ensure that users start-up scripts do not contain locale settings. If a users start-up script overrides
the servers locale setting, information may appear in more than one language.
Dates and Times Are Incorrect
Only the messages in user dialog boxes are in French, German, or Spanish. This means that the date and time
for the locale may be incorrect and should, therefore, be disregarded. For example, an incorrect date and
time may appear in the Reconnect dialog box.
The Locale Selection Menu Does not Appear on the Login Screen
XenApp supports only the use of one locale at a time, and does not offer per-session selection.
How Do I Find Out My Current Locale?
Use the locale command to display information about the current locale environment. For more information
about the locale command, see the locale man page or consult your UNIX software documentation.
10.2.2.9. Using the Citrix XML Service
Updated: 2009-11-20
The Citrix XML Service for XenApp for UNIX runs as a daemon on all servers in a server farm. The key
features and benefits of using the XML Service include:
Web-based application deployment. Using the XML Service, you can deploy applications published on
XenApp servers to your users through the Web. The XML Service communicates information about the
UNIX applications published in a server farm to the Citrix Web Interface. The Web Interface provides users
with an HTML-based presentation of the server farm. Users can access their published applications using
a standard Web browser. You can specify the name and icon used to display the link to each application in
the Web page and the default window settings for the application when run. For more information about the
Web Interface, see the Web Interface Administrators Guide.
Ticketing. The XML Service provides support for ticketing, which offers enhanced authentication security
by eliminating user credentials from the ICA files sent from the Web server to client devices. The use of the
Web Interfaces ticketing feature eliminates the danger of an attacker intercepting user credential information
and using this to access a XenApp server. For more information about how to use ticketing in your Web
Interface deployment, see the Web Interface Administrators Guide.
HTTP browsing. You can provide your users with HTTP (HyperText Transport Protocol) browsing. The
plugin uses HTTP to communicate with the Citrix XML Service to fulfill browser requests. HTTP browsing uses
the standard HTTP port on the firewallport 80to allow users to browse applications and servers that exist
on the other side of a firewall. This means that, provided port 80 is not being used by a Web server running
on the server, there is no need to open an additional port on the firewall for browser requests.
SSL Relay support. The XML Service provides SSL Relay support. SSL Relay provides the ability to secure
data communications using Version 4.0 of the Secure Sockets Layer (SSL) protocol. SSL provides
server authentication, encryption of the data stream, and message integrity checks. You can use SSL Relay
to secure communications in a Web Interface deployment between the Web server and the XenApp server.
For more information about configuring and using SSL Relay, see the Citrix XenApp SSL Relay for
UNIX Administrators Guide.
Server Farm Considerations
For XenApp for UNIX servers to be included in a farm, they need to be on the same subnet or connected by
Citrix ICA gateways. For more information, see Multiple Farms and Subnet Considerations.
You can make applications published in XenApp for UNIX server farms appear in the same location as
applications published on XenApp for Windows farms. To do this, you use the multiple server farm functionality
in the Web Interface. Multiple server farm functionality is transparent to users because they are not informed
that their application set is an aggregation from multiple server farms. Applications from multiple server
farms appear in the same way as a single farm; folders appear first, followed by application icons. For
more information, see the Web Interface Administrators Guide.
10.2.2.9.1. Getting Started with the Citrix XML Service
Updated: 2009-11-30
The Citrix XML Service is included automatically when you install XenApp for UNIX, and the XML process
starts automatically. If you create a server farm, the XML Service runs on each server in the farm.
Configuration information required by the XML Service is stored in ctxxmld.cfg.
Typically, little or no configuration is required to get the XML Service up and running quickly in your
installation. However, you may need to configure the XML Service to use port numbers other than the defaults
or to enable DNS address resolution. This section explains what configuration is required and where to find
more information.
Configuring display settings. You can configure your applications for use with the Web Interface using
the ctxappcfg command. Using ctxappcfg, you can configure display settings that include the name of the
folder containing the application and the icon that the Web Interface displays, and the window size and
color depth. For more information about configuring application display settings, see Publishing Applications
and Desktops.
Configuring the XML Service port. By default, the Web server communicates with the XML Service using
port 80. If port 80 is already in use on the server running the XML Service, assign the XML Service to an
unused port. See Configuring the Server Port for more information.
Configuring the SSL Relay port. To enable your users to make SSL-secure connections to applications
through the Web Interface, you must configure the XML Service for use with SSL Relay. To do this, you use
the ctxappcfg command to specify whether SSL is used to secure connections on all published applications or on
a particular application only (see Publishing Applications and Desktops for more information). If you are not
using TCP port 443, which is the standard port for SSL-secured communications, you must specify the
port number that SSL Relay listens for connections on using the ctxnfusesrv command. For information about
how to do this, see Configuring the XML Service for Use with SSL Relay.
Note: If you configured a particular server to be the master browser, Citrix recommends that you direct
the Web Interface to this server. For more information about the ICA browser, see XenApp for UNIX and
the ICA Browser Service. Also, if plugins are using HTTP browsing, it is best to direct plugins to the
master browser server. See your plugin documentation for more information.
10.2.2.9.2. Starting and Stopping the Citrix XML Service
Updated: 2009-11-10
When you start and stop XenApp, the Citrix XML Service automatically starts and stops. Using the ctxsrv
command, you can start and stop the Citrix XML Service on the local server.
To start the Citrix XML Service
1.
2.

ctxsrv start msd
Starting a server causes an election, and the master browser may change. The master browser takes some
time to acquire information about applications available on the farm. If the Citrix XML Service is started at
the same time as a XenApp server, it can take up to 10 minutes before these applications are visible through
the Web Interface.
To stop the Citrix XML Service
1.
2.

ctxsrv stop msd
10.2.2.9.3. Configuring the Server Port

Updated: 2009-11-10
By default, the Web Interface communicates with the Citrix XML Service using port 80. If port 80 is already in
use on the server running the XML Service, assign the XML Service to an unused port.
Note: The XML Service port number must be unique. If the port is already in use by another process,
results may be unpredictable. You must configure the Web Interface to use the same port number as
you specified for the XML Servicesee the Web Interface Administrators Guide for information about how to
do this.
To configure the Citrix XML Service port

1.
2.

ctxnfusesrv -port portnumber
where portnumber is an unused port; for example, 8080.
Note: You must restart the XML Service for the new port to be used.
To display the current port number

1.
At a command prompt, use ctxnfusesrv with the -l (list) option: ctxnfusesrv -l
10.2.2.9.4. Configuring the XML Service for Use with SSL Relay
Updated: 2009-11-20
SSL Relay is included automatically when you install XenApp for UNIX.
To allow users who connect to the server through the Web Interface to make SSL-secure connections
to applications, you must configure the XML Service for use with SSL Relay. To do this you use the:
ctxappcfg command to specify whether SSL is used to secure connections on all published applications
or on a particular application only. ctxnfusesrv command to specify the port number on which SSL
Relay listens for connections. You need to run this command only if you are not using TCP port 443,
which is the standard port for SSL-secured communications. The SSL Relay port number you specify
must be the same on every server in the farm.
For more information about configuring and using SSL Relay, see the Citrix XenApp SSL Relay for
To configure the SSL Relay port number
1.
2.

If SSL Relay listens for connections on a port other than 443, specify this port number. At a
command prompt, type:
ctxnfusesrv -ssl-port port-number
where port-number is the port number on which SSL Relay listens for connections. For example, if
SSL Relay listens on port 444, type:
ctxnfusesrv -ssl-port 444
Troubleshooting SSL
If you configured your server to use NIS for name resolution, the server cannot support SSL-enabled
ICA connections because NIS does not supply the fully qualified domain name (FQDN). The FQDN is required
by the XML Service to direct requests from the Web Interface and client devices.
To solve this problem, configure the server to use DNS, in preference to NIS, for name resolution, because
DNS supplies the FQDN.
10.2.2.9.5. Configuring DNS Address Resolution
Updated: 2009-11-10
By default, servers reply to browsing requests with an IP address. However, a server can respond with the
fully qualified domain name. This feature, called Domain Name System (DNS) address resolution, is available
to client devices using the XML Service. In most situations, the use of IP addresses works well and with
less overhead.
You can enable DNS address resolution using the ctxnfusesrv -dns command.
To enable DNS address resolution
1.
2.
2.
ctxnfusesrv -dns enable
Note: If DNS addressing is enabled, client devices can connect reliably to servers only if they can resolve
the fully qualified domain name. If the plugin is not configured correctly, it cannot connect. Ping a server
with its DNS host name to verify this.
To display the current DNS address resolution setting

You can display the current DNS address resolution setting using ctxnfusesrv and the -l (list) option.
1.
At a command prompt, type: ctxnfusesrv -l
10.2.2.10. Using Client Drive Mapping

Updated: 2009-11-20
The client drive mapping feature enables users to access their local drives from within an ICA session. When
a user makes an ICA connection to a XenApp server, the users local drives are mounted automatically, such
as floppy disk drives, network drives, CD-ROM drives, and hard disk drives.
These drives are available for the duration of the session. When a session is disconnected, all the mapped
drives belonging to the session are released immediately. If you shadow a userss session using ctxshadow,
you can also access the local, mapped drives belonging to the shadowed session.
For users to take advantage of client drive mapping:
Users must be running Version 6.0 or later plugins.
Use the ctxcfg command to enable client drive mapping. By default, the client drive mapping feature
is disabled because it consumes server resources, and so that you can be certain that no one is
moving files between the server and client devices.
10.2.2.10.1. Enabling Client Drive Mapping

Updated: 2009-11-30
By default, when you install XenApp, client drive mapping is disabled. Therefore, before users can take
advantage of this feature, you must enable it on the server. When you enable client drive mapping, you
must choose whether to enable the mapped drives with read-write access or with read-only access.
You use the ctxcfg tool with the -D option to enable client drive mapping.
You can also enable client drive mapping on a global basis using the ctxsrv command. For example, if you
need to re-enable client drive mapping after you stop it for all users temporarily during a virus scare. For
more information, see Re-Enabling Client Drive Mapping.
Important: Client drive mapping can also be configured using options available within the plugin.
Therefore, for client drive mapping to work, you must ensure that the settings in the plugin are consistent
with the settings on the XenApp server. To enable client drive mapping, you must enable it in the plugin,
and on the server, and ensure the settings do not conflict. For example, if the plugin is configured to
mount only drive C, mounting drive A on the server will have no effect. For more information about
configuring client drive mapping in the plugin, see the documentation for the appropriate plugin.
Note: To use client drive mapping when running XenApp for UNIX on the AIX operating system, ensure
option nfs_use_reserved_ports is set to 1 using the nfso command.
To enable client drive mapping

1.
2.

ctxcfg -D enable,access={ro|rw}
where ro is read-only access, and rw is read-write access.
When client drive mapping is enabled, it is enabled for all users and all their available local drives. However,
you can restrict access on a user or group level basis using the ctxsecurity security command. For example,
to prevent anonymous users (the ctxanon group) from using client drive mapping, use the ctxsecurity
command to deny this group access.
You can also restrict user access to specific drives using the ctxmount command. For example, you can
configure client drive mapping so that users can access only drive C. You can do this for all users or for
particular users.
Note: The access policy you implement using ctxcfg takes precedence over any settings configured using
ctxmount, including any settings in the ctxsession.sh file. For example, if you enable access as read-only using
ctxcfg, this cannot be overridden using ctxmount.
10.2.2.10.2. Configuring Access to Specific Drives
Updated: 2009-11-24
When you enable client drive mapping using ctxcfg, all the local drives available to a user are mapped.
However, you can configure access to particular mapped drives using the ctxmount command, which you
include in the ctxsession.sh script. You can do this for particular users or for every user who connects to
the server.
For example, you can configure the system so that in an ICA session:
The user Fred cannot access drive A
Freds drive C is read-only
All users cannot access drive C
All users drives A are read-only
If you configure access to specific drives for particular users the procedure you use differs, depending on
whether or not you trust those users.
To use the ctxmount command, you modify it within the ctxsession.sh script. The ctxmount command
is contained within ctxsession.sh because ctxmount affects only the session in which it runs. ctxsession.sh
runs after a user logs on, so you can use it to customize the local environment for a session.
Note: Settings configured using ctxcfg take precedence over any settings configured using ctxmount.
For example, if you enable read-only access to mapped drives using ctxcfg, read-write access cannot
be granted using ctxmount.
You can also configure access to client drive mapping on a user or group level basis, using the security function
ctxsecurity.
10.2.2.10.2.1. To configure access to specific drives for every user
Updated: 2009-11-19
Use this procedure to configure access to specific drives for every user who logs on to the server.
1.
2.
2.
$CTXMOUNT
3.
Update the ctxmount command:
$CTXMOUNT [ -d | -ro ] [ drivelist ]

The following table explains the options:
Option
Use this to:
-d
Disconnect a drive.
-ro
Configure access to a drive as read-only. If you specify a

currently connected drive, this drive is made read-only.
drivelist
Specify the drive letters to which you want to configure access: (A B C ... Z
) or all to specify all available drives. If you do not specify a drivelist,
the default of all is used.
Examples
To connect all drives as read-only, use the command:
$CTXMOUNT -ro
To connect drive C only, use the command:
$CTXMOUNT C
To connect all drives except drive C, use the commands:
$CTXMOUNT all
$CTXMOUNT -d C
To disconnect all drives, use the command:
$CTXMOUNT -d
To disconnect drives M, N, and T, use the command:
$CTXMOUNT -d M N T
10.2.2.10.2.2. To configure access to specific drives for a particular trusted user

Updated: 2009-11-24
If you trust your users, use the following procedure to allow users to configure access to specific drives.
Important: With this method users can overwrite these settings using the ctxmount command.
1.
2.

#. $HOME/.ctx.session.sh
#fi
3.
Under here, insert lines similar to the following (in this example, the user bill is given read/write
access to drives A, C, and E, mandy is given read-only access to drive C, and for all other users
drives are disconnected):
case $USER in
case $USER in
bill)
ctxmount ACE
;;
mandy)
ctxmount -ro C
;;
*)
ctxmount -d
;;
esac
Note: This script is run for every session.
Users can modify the .ctx.session.sh file and run any commands that they choose.
10.2.2.10.2.3. To configure access to specific drives for a particular untrusted user

Updated: 2009-11-24
If you do not trust your users, use the following procedure to configure access to specific drives. With
this method, users cannot overwrite these settings using the ctxmount command.
1.
2.

#. $HOME/.ctx.session.sh
#fi
3.
Remove the # character from the start of each line, so that these lines are no longer commented out.
4.
In the users home directory, create a file called .ctx.session.sh.
5.
In the .ctx.session.sh file, include the ctxmount command with the appropriate options:
ctxmount [ -d | -ro ] [ drivelist ]

Note:
If you do not trust your users, and do not want them to use client drive mapping, except as you define here,
do not give them access to a command prompt from which they can run ctxmount. That is, give your
users access only to published applications.
10.2.2.10.3. Disabling Client Drive Mapping

Updated: 2009-11-24
How you disable client drive mapping depends upon whether you want to disable it for new connections only,
or disable it for all connections including any existing ones.
To disable client drive mapping for new connections only, use the ctxcfg command. Client drive
mapping will still be available for existing connections.
To disable client drive mapping for all connections, including any existing connections, use the ctxsrv stop
command. This command immediately stops the client drive mapping process on the server. For
example, use this method to immediately disable client drive mapping for all users during a virus scare.
To disable client drive mapping for new connections

1.
2.

ctxcfg -D disable
To disable client drive mapping for all connections, including existing ones
1.
2.

ctxsrv stop cdm
Re-Enabling Client Drive Mapping

How you re-enable client drive mapping depends upon how you disabled it, as follows:
If you disabled client drive mapping using ctxcfg, use ctxcfg to re-enable it.
If you disabled client drive mapping on the server using ctxsrv stop, use ctxsrv start to restart it.
To re-enable client drive mapping (if disabled using ctxcfg)

1.
2.

ctxcfg -D enable,access={ ro|rw }
where ro is read-only access, and rw is read-write access.
To restart client drive mapping (if disabled using ctxsrv)

1.
2.

ctxsrv start cdm
Tip: Use ctxcfg -D list to display whether client drive mapping is currently enabled or disabled.
Note, however, that this shows only the enabled or disabled status configured using the ctxcfg command
it does not display whether client drive mapping is enabled or disabled using ctxsrv.
10.2.2.10.4. Features and Limitations of Client Drive Mapping
Updated: 2009-11-10
These topics provides further information about how client drive mapping works. They tell you about the
/ctxmnt directory and the $CTXCLIENT environment variable. They also provide information that you and
your users need to know about file names, permissions, and formats, and about the limitations of client
drive mapping in this release.
10.2.2.10.4.1. How Does Client Drive Mapping Work?
When you install XenApp, the /ctxmnt directory is created on the server. When client drive mapping is
enabled, this directory holds information about clients mapped drives for each session that connects to the server.
When a user makes a connection to the server, the users drive mappings are held in this directory as:
/ctxmnt/username/default/driveletters
If a user starts additional sessions that run concurrently with the users first session, the additional
drive mappings are held as:
/ctxmnt/username/$CITRIX_SESSION_ID/driveletters
Each session uses the $CTXCLIENT environment variable to point to the appropriate drive mappings on the server.
For example, within an ICA session the user Fred accesses a file on his hard disk called: C:
\accounts\expenses.txt. This file is mapped as /ctxmnt/fred/default/C/accounts/expenses.txt. If Fred
starts another session, the session id is used to map additional files and directories; for
example, /ctxmnt/fred/20/C/accounts/payments.txt.
10.2.2.10.4.2. File Names
File names permitted in one operating system may not be permitted in another. For example, the
Windows operating system does not allow file names that match devices. Likewise, some operating systems
do not permit file names that contain certain characters, such as: \ / : * ? < >. File names containing
non-English characters can also appear differently between the client and the server.
Client drive mapping does not take the case of file names into consideration; for example, the files readme.
txt and README.TXT are treated as the same file. Client drive letters, however, are always converted to
upper case.
If you are using the Citrix Delivery Clients for Windows, do not use an asterisk (*) within quotation marks in
file names. For example, if you want to change directory to New Folder, either type the full name of the file,
or type:
cd /ctxmnt/username/default/driveletter/Ne*
10.2.2.10.4.3. File Permissions
File permissions are set at the user name level; therefore, only the user who owns the file can access and
update files on their local, mapped drives. You cannot change the permissions on files in the /ctxmnt
directory using chmod or chown. Execute permissions cannot be set on any files served by client drive mapping.
Files that are executable locally cannot be executed within a mapped client drive. For example, on a local
UNIX computer, you have a file called a.out. When you run ls -l on the local computer, the file permissions
are listed as rwxr-xr-x. However, if you run ls -l on the mapped drive, the file permissions are listed as rw-------.
Caution: UNIX permissions prevent users from being able to display and access each others files. However,
if you use ctxcfg -a to allow automatic logon, your users can see directory listings of each others files
(for example, using the ls command in UNIX) and they can access and display the contents of the files
because users are logged on under the same user id. To prevent this, do not use ctxcfg -a with client
drive mapping.
10.2.2.10.4.4. File Attributes
File attributes that apply on one operating system may be ignored on another. For example, files that are
hidden in Windows may appear when displayed in a different operating system, such as UNIX. DOS file
attributes (with the exception of read-only) are ignored in UNIX.
10.2.2.10.4.5. File Formats
Although client drive mapping provides users with access to their local drives, file format conversion does
not occur automatically. This means that files stored on local client devices may appear differently in an
ICA connection that uses client drive mapping. Similarly, files stored on the server may appear differently
when saved to the local client device.
For example, files created on a DOS file system may contain both carriage returns and line feeds as
line terminators, while files created on a UNIX system may contain line feeds only.
10.2.2.10.5. Troubleshooting Client Drive Mapping
Updated: 2009-11-10
These topics describe problems that you and your users may experience, or typical questions that may be
asked about client drive mapping, and provide possible solutions and answers to these.
10.2.2.10.5.1. Client Drive Mapping Does not Work

Updated: 2009-11-19
The following diagram shows the steps you need to perform on the server if client drive mapping does not work:
Tip: Remember to check also that client drive mapping is enabled on the client, and that these settings
are consistent with the settings on the server.
Invalid Directory or Stale File Error Messages
10.2.2.10.5.2. When a session is disconnected, all the mapped drives belonging to the session are
immediately released. However, some applications store the paths of files on which a user recently worked. If
a session is disconnected and later reconnected, the path to a file may be invalid in the reconnected session.
For example, in an application running in an ICA connection, Fred edits a file that is mapped
as /ctxmnt/fred/default/C/accounts/expenses.txt. However, Freds connection breaks and he reconnects
the session. This time the system maps the file as /ctxmnt/fred/10/C/accounts/expenses.txt. Therefore,
when Fred attempts to access expenses.txt in the application, the path is no longer valid and error messages such as invalid
10.2.2.10.5.3. Problems Accessing and Updating Files
File names permitted in one operating system may not be permitted in another. For example, the
Windows operating system does not allow file names that match devices, so users of Windows clients
may experience problems attempting to write files called com1.txt, lpt1, aux, and so on.
Some operating systems do not permit file names that contain certain characters; for example, in Windows
these characters are: \ / : * ? < >
File names containing non-English characters may also appear differently due to mismatches in the
character encoding used by the client and the server. For example, a user has a file on a hard drive
called results.txt; however, when viewing this file in an ICA session the user sees ?results.txt. To
access files that contain characters that are not available on the keyboard, use wildcards; for example, vi
*results.txt.
10.2.2.10.5.4. A File Looks Different when Displayed in an ICA Session
File format conversion does not occur automatically. This means that files stored on local client devices
may appear differently in an ICA connection that uses client drive mapping. Similarly, files stored on the
server may appear differently when saved to the local client device.
For example, a user has a text file on a local Windows client device. When the user displays this file in an
ICA connection, ^M appears at the end of each line. This is due to the different text file formats in the
operating systems. Therefore, before the user can work with the file, the file format must be converted;
for example, using a utility such as dos2unix.
10.2.2.10.5.5. NFS Error Messages
Updated: 2009-11-10
You may receive errors relating to NFS when using XenApp for UNIX.
Not Responding Error Message
In the unlikely event that the client drive mapping process on the server is slow in responding, an error
message (such as NFS server CDM server not responding still trying or NFS server 127.0.0.1 not
responding still trying) appears.
Normally, this request is fulfilled and the message NFS server CDM server ok or NFS server 127.0.0.1
ok appears. However, if the problem persists, you must restart the client drive mapping process on the server.
Tip: To interrupt the request and get a command prompt, press CTRL+C or send a SIGINT to the process.
To restart client drive mapping

1.
2.
Ensure that there are no users in the /ctxmnt directory (users should not be reading or writing to
this directory, nor should it be their current directory). For example, you may want to ask your users to
log off from the server; to do this, use the ctxmsg -a command to send a message to all users.
Stop client drive mapping. At a command prompt, type:
ctxsrv stop cdm
3.
Restart client drive mapping. At a command prompt, type:

ctxsrv start cdm
Stale NFS Handle Error Message

If you disconnect while your current directory is within a mapped directory tree and then reconnect,
all subsequent accesses to the mapped directories will result in the error message Stale NFS Handle.
This happens because information about the mapped drive is lost when the drive is disconnected.
In the reconnected session, change directory so that you are no longer in the mapped drive; for example,
by typing cd to go back to the home directory.
10.2.2.11. Command Reference
Updated: 2009-10-20
These topics describe the XenApp for UNIX and XML Service for UNIX command-line utilities.
10.2.2.11.1. XenApp Commands
Updated: 2009-10-20
The XenApp commands are as follows:

ctx3bmouse
configure 3-button mouse emulation
ctxalt
alternate address configuration for ICA browsers
ctxanoncfg
configure anonymous users
ctxappcfg
configure published applications
ctxbrcfg
configure ICA browser settings
ctxcapture
graphics copy and paste (between ICA and local applications)
ctxcfg
configure server settings
ctxconnect
connect to a session
ctxcreatefarm create a server farm. See ctxfarm.

ctxdisconnect disconnect from a session
ctxfarm
create a farm, join a farm, remove a server from a farm, or change the farms secret key
and passphrase.
ctxgrab
graphics copy and paste (from ICA to local applications)
ctxjoinfarm
join a server farm. See ctxfarm.
ctxlogoff
log off from a server
ctxlpr
print to a client printer
ctxlsdcfg
configure communication with a license server
ctxmaster
show master ICA browser
ctxmount
configures user access to mapped drives
ctxmsg
send a message
ctxprinters
list printers installed on the client device
ctxqserver
display information about servers
ctxqsession
display session details
ctxquery
display session details or details in a different format
ctxquser
display session user details
ctxreset
reset a session
ctxsecurity
configure security
ctxshadow
start a shadowing session
ctxshutdown
shut down the server processes
ctxsrv
start up or stop the server processes
10.2.2.11.1.1. ctx3bmouse
Updated: 2009-09-29
Description
ctx3bmouse configures 3-button mouse emulation.
You may need to use XenApp to deploy UNIX applications that are designed for use with a 3button
mouse. However, many plugins run on devices that have only a 2-button mouse, 1-button mouse, or
pointing device available.
To do this, you publish another version of the application for use by these plugins. This version of the
application is published using a script file that includes ctx3bmouse settings. The ctx3bmouse command lets
users represent a missing mouse button by combining an existing mouse button with a modifier key.
For example, a missing button might be simulated by clicking the left mouse button and pressing the SHIFT key.
By running a script file that includes ctx3bmouse settings, you ensure the application is run in a session with
the appropriate mouse mappings.
Syntax
ctx3bmouse
missing_button=mouse_button,number_of_modifier_key
ctx3bmouse
-r
ctx3bmouse
-c
Options
-r
Display mouse mappings for the current session.
-c
Clear all mouse mappings for the current session.
Parameters
missing_button
The missing button that is to be emulated: left| middle| right
mouse_button
The existing mouse button which, when pressed with the modifier key,
simulates the missing mouse button.
number_of_ modifier_key Number of modifier to use. Use the xmodmap command to show which
keys correspond to which modifiers.
Remarks
With xmodmap it is possible to remap almost any aspect of the keyboard and mouse. Take care when
using xmodmap with ctx3bmouse because the combination may be confusing.
Middle mouse button emulation is included in Version 6.20, or later, of the Citrix XenApp Plugin for Hosted
Apps for Windows. If users are connecting to a XenApp server using this plugin, disable any ctx3bmouse
settings configured on the server.
10.2.2.11.1.2. ctxalt
Updated: 2009-09-29
Description
ctxalt specifies alternate address configuration for ICA browsers
Syntax
ctxalt
-l
ctxalt
-d alt_addr
ctxalt
-a browser_addr alt_addr
ctxalt
-r addr
ctxalt
-h
Options
-l
List current alternate address configuration.
-d
Set the default alternate address.
-a
Set an alternate address.
-r
Remove an alternate address.
-h
Display usage message
Parameters
alt_addr
Specifies the alternate address.With the exception of the -r option, all

addresses must be supplied in standard IP address format. The -r option
also accepts the (case-insensitive) keyword DefaultAddress to erase the
default address setting.
browser_addr
Specifies the default alternate address.
Remarks
You must be an administrator to run this command.
10.2.2.11.1.3. ctxanoncfg
Updated: 2009-09-29
Description
ctxanoncfg configures anonymous users.
Syntax
ctxanoncfg
-l [-q]
ctxanoncfg
-n number [-b anonymous_user_name ] [-t minutes] [-s shell] [-u user-id

] [-g group] [-d path] [-q]
ctxanoncfg
-t minutes [-q]
ctxanoncfg
-clear
ctxanoncfg
-h
Options
-l
List current anonymous user settings.
-q
Quiet mode. Use with the other options to suppress the display of error
messages and what the command is doing at each stage.
-n
Specify the number of anonymous user accounts.
-b
Change how anonymous user accounts are named. Use this option only
when creating new anonymous user accountsdo not use it to change
existing accounts.
-t
Specify the idle time-out period, in minutes, for anonymous user sessions. If
there is no activity within this time, a warning message appears stating that
the user will be logged off if the session remains inactive for a further five minutes.
-s
Specify a particular shell for anonymous user accounts.
-u
Assign specific user ids to anonymous user accounts, where user-id is the first
id in the range.
-g
Specify the name of the anonymous user group. By default the group name
is ctxanon.
-d
Specify the home directory for anonymous user accounts. By default

all anonymous user accounts are created with home directories in /usr/anon.
-clear
Remove all anonymous user configuration.
-h
Display help message.
Parameters
number
New number of anonymous user accounts.
anonymous_user_name
New name of anonymous user accounts. By default, account names are in

the format anonx where x is a number from 1,2 ... and so on.
minutes
Idle time-out period, in minutes.
shell
Shell you want to assign to anonymous user accountsfor example: /bin/csh.
user-id
First user id from which you want to start generating anonymous user accounts.
group
Name of the anonymous user group. This must be eight characters or less.
path
Home directory for anonymous user accounts. You do not need to specify
the trailing forward slash (/).
Remarks
You must be root to run this command.
You must stop the XenApp process on the server before you configure anonymous users.
See also
ctxshutdownto stop the XenApp process.
10.2.2.11.1.4. ctxappcfg
Updated: 2009-09-29
Description
ctxappcfg is an interactive command that allows you to publish and configure applications.
Syntax
ctxappcfg
Usage
When you run ctxappcfg, the App Config> command prompt appears and you can enter the following commands:
list
Displays a list of published application names.
publish
Allows you to publish an application. You are prompted for the following details:
Name - the name used to refer to the published application.
Command Line - the command line used to launch the application. To
publish the desktop, press ENTER without specifying a command line.
Working Directory - the working directory used by the application. To
specify the users home directory, leave this blank.
Anonymous - whether the application is for use by anonymous or explicit
users. Enter yes if the application is for use by anonymous users only, or no if
it is for explicit users only.
Description - an optional description that can be displayed on the users
Web page. If the description includes spaces, enclose it within quotes.
Folder - a folder containing the application.
Icon File - the icon file displayed against a published application.
Window Size - the window size and type of window. Specify window size as
widthxheight; for example, 1024x768; or % (percentage) of a desktop;
for example, 70%. Specify type of window as seamless (the window size
is controlled by the client device) or fullscreen (full screen display).
Color Depth - the number of colors used to display the application. Choose from
16, 256, 4bit, 8bit, 16bit, and 24bit.
Enable SSL security - type yes to use SSL to secure connections to
this application, or no if you do not want to use SSL.
User name - the user names of users permitted to access this application.
Type one user name per line. Enter a blank line to complete the list. If you do
not enter any user or group names, the application cannot be
published successfully.
Group name - the names of user groups or netgroups permitted to access
this application. Type one group name per line. Leave a blank line to complete
the list. To denote a netgroup, use an at symbol (@) as the first character of
the name; for example @netgroup1. If you do not enter any user or group
names, the application cannot be published successfully.
Server name - the names of servers in the farm that will publish this
application. Type one server name per line. Leave a blank line to complete
the list. To specify all current servers in the farm, type an asterisk (*). To
specify all current and future servers in the farm, type a plus sign (+).
select [name]
Allows you to configure a published application. If you do not specify the name
of the application you want to configure, you are prompted for it. Note that
the application name is case-sensitive. After you select an application, the
prompt changes to the name of the application and you can enter the
following commands:
list - lists the configuration details of the selected application.
set - allows you to change the configuration. The full syntax is: set [cmd={
cmd_line}, dir={dir_name}, anonymous={yes|no}, enabled=
{yes|no}, description={description}, folder={folder name}, window_size={
window size}, color_depth={color depth},ssl_enabled={yes|no}] OR
set server={server_name}, [cmd={cmd_line}, dir={dir_name}] where
the parameters are as follows:
cmd - the command line required for the program to run.
dir - the initial working directory.
anonymous - indicates if the application is for use by anonymous or
explicit users.
enabled - indicates if the application is enabled or disabled.
description - the description displayed on the users Web page. If the
description includes spaces, enclose it within quotes.
folder - the name of a folder containing the program.
window_size - the window size (width x height or percentage of a desktop)
and type of window (desktop or seamless).
color_depth - the number of colors used to display the application. Specify
16, 256, 4bit, 8bit, 16bit, or 24bit.
ssl_enabled - specifies whether or not SSL is used to secure connections to
the application. Type yes to use SSL, or no if you do not want to use SSL.
server - the name of the server you want to configure. This option applies only
to the command line and working directory.
list users - lists the users who are allowed to access the published application.
list groups - lists groups of users who are allowed to access the
add users - adds users who are allowed to access the published application.
Type one user name per line. Leave a blank line to complete the list.
add groups - adds groups of users or netgroups who are allowed to access
the published application. Type one group per line. Leave a blank line to
complete the list. To denote a netgroup, use an at symbol (@) as the
first character of the name; for example @netgroup1. Note that if you specify
a netgroup, only the presence of a user in a netgroup is checked; the host
and domain fields are ignored.
remove users - prevents users from accessing the published application.
Type one user name per line. Leave a blank line to complete the list.
select [name]
remove groups - prevents groups of users from accessing the

published application. Type one group per line. Leave a blank line to complete
the list.
list servers - lists all servers in the farm that publish the application.
add servers - publish the application on another server in the farm. Type
one server name per line. Leave a blank line to complete the list. To specify
all current servers in the farm, type an asterisk (*). To specify all current
and future servers in the farm, type a plus sign (+). Note that an application
must be installed on a server before it can be published.
remove servers - remove the published application from one or more servers
in the farm. Type one server name per line. Leave a blank line to complete the list.
export icon - export the current icon to a file that you can later view. You
are prompted for the file name.
import icon - specify a different icon file for the published application. You
are prompted for the file name.
copy - creates a new published application by copying the configuration of
the current application. You are prompted to enter a name for the
new application. The new configuration is saved and selected automatically.
save - saves the changes you make.
delete - deletes the currently selected application and returns you to the
App Config> prompt.
drop - clears the current application and returns you to the App Config> prompt.
help / ? - displays a brief usage message.
exit - exits the command.
default
Allows you to display and configure the default settings for all
published applications in the server farm. To change the default settings, use the
set command, which has the following syntax:
set [folder=[folder name], window_size={window size}, color_depth={color depth
}, ssl_enabled]
where the parameters are as follows:
folder - the name of a folder containing the published application.
window_size - the window size (width x height or percentage of a desktop)
and type of window (desktop or seamless).
color_depth - the number of colors used to display the application. Specify
16, 256, 4bit, 8bit, 16bit, or 24bit.
ssl_enabled - specifies whether or not SSL is used to secure connections to
the application. Type yes to use SSL, or no if you do not want to use SSL.
export icon - export the current icon to a file that you can later view.
import icon - specify a different default icon file for the published application.
save - saves the changes you make.
drop - clears the current application and returns you to the App Config> prompt.
help / ?
Displays a brief usage message.
exit
Exits the command.
Remarks
See also
ctxqserverto list all published applications on the network.
10.2.2.11.1.5. ctxbrcfg
Updated: 2009-11-20
Description
ctxbrcfg configures ICA browser settings.
Syntax
ctxbrcfg
-g [add=gateway,] [remove=gateway
,] [list]
ctxbrcfg
-m [always | never | neutral,] [list]
ctxbrcfg
-r [set=num,] [list]
ctxbrcfg
-b [set=address | unset | list]
ctxbrcfg
-h
Options
-g
Gateways. Allows you to add or remove ICA Gateways.
-m
Master election. Allows you to influence the criteria used for the master election.
always makes the local browser try to become the master. never instructs
the browser to refrain from standing in an election. neutral reinstates the
default behavior of no preference.
-r
Refresh period. Allows you to specify the interval (in minutes) at which the
local browser will update the master browser.
-b
Restrict the ICA browser to one subnet. If a XenApp server has more than
one network interface card (NIC) and is connected on more than one
subnet, configure the server so that the browser listens on only one subnet
and ignores broadcasts on the others. Use set to restrict the browser to a
subnet. Use unset to remove a restriction. Use list to display current restrictions.
-h
Display usage message.
Parameters
num
Specifies the interval (in minutes) at which the local browser will update
the master browser.
gateway
Specifies the gateway host name or IP address.
address
The IP address or subnet address to which you want to restrict the browser,
in aaa.bbb.ccc.ddd formatthat is, 10.20.123.123.

Remarks
If you bind the server to a subnet, make sure that there is only one NIC on this subnet. For more information, see
To restrict the ICA browser to a particular subnet or NIC
See also
ctxqserverto display information about gateways and the master browser.
10.2.2.11.1.6. ctxcapture
Updated: 2009-09-29
Description
ctxcapture lets you:
Capture windows or screen areas and copy them between an application in an ICA session window and
an application running on the local client device, including non-ICCCM-compliant applications.
Copy graphics between the client device and the X graphics manipulation utility XV. XV is a
shareware utility that is available for download from the Internet.
ctxcapture is available from the command prompt; it is also available when you connect to published
applications through the ctxwm window manager, if your administrator made it available, as follows:
In a seamless window, right click the
button in the top, left hand corner of the screen to display
a menu and choose the Screen Grab option
In a full screen window, right click to display the ctxwm menu and choose the Screen Grab option
When ctxcapture starts, a dialog box appears.
Syntax
ctxcapture
See also
ctxgraba simple tool to cut and paste graphics from ICA applications to applications running locally on the
client device.
10.2.2.11.1.7. ctxcfg
Updated: 2009-09-29
Description
ctxcfg configures server settings.
Syntax
ctxcfg
-a [ERASE | [[prompt={TRUE | FALSE},] [INHERIT | [user=name,] [pass]] [list]
ctxcfg
-l [max={UNLIMITED | num }] [list]
ctxcfg
-t [connect={NONE | minutes},] [disconnect={NONE | minutes

},] [disclogoff={NONE | minutes},] [authentication={NONE | minutes
},][idle={NONE | minutes},] [clientcheck={NONE | seconds
},] [clientresponse={NONE | seconds},] [list]
ctxcfg
-c [broken={DISCONNECT | RESET | LOGOFF},] [reconnect={ORIGINAL

| ANY},] [list]
ctxcfg
-p [enable | disable] [list]
ctxcfg
-C [enable | disable] [list]
ctxcfg
-P [set=num | reset] [list]
ctxcfg
-g
ctxcfg
-e {none | basic} [list]
ctxcfg
-i [ INHERIT | PUBONLY | ([prog=name,][wd=dir])] [list]
ctxcfg
-s enable [,input={on|off}] [,notify={on|off}] -s disable -s list
ctxcfg
-D enable,access={ro | rw} -D disable -D list
ctxcfg
-k [loadfactor=num] | [lognohome= {0|1}] | [autoreconnect= {0|1}]

| [logonlogging= {0|1|2}] | [logofflogging= {0|1|2}]
| [reconnectlogging= {0|1|2}] | [disconnectlogging= {0|1|2}]
| [nomorelogons= {0|1}] | [disablescrollmouse= {0|1}]
ctxcfg
-m [enable | disable] [lowerthreshold=num] [upperthreshold=num] [list]
ctxcfg
-o [set=n] [reset] [list]
ctxcfg
-h
Options
-a
Allows you to set automatic logon details. Use INHERIT to make the server
use logon details specified in the plugin, rather than setting a user name
and password for the server using user and pass.
Alternatively you can specify a user name and/or password for all users who
log on to the server. Set prompt to TRUE to prompt users for a
password, regardless of whether one is specified on the server or the plugin.
Use the pass option to prompt users for a logon password. Note that using -g
with the list option will not display the password.
ERASE erases any user name and password details that were set using the user
and pass options and makes the server use logon details specified in the plugin.
-l
Logons. Allows you to limit the number of users who can be logged
on concurrently to the server. Specify an unsigned number or the keyword
UNLIMITED to allow an unlimited number of users to log on.
-t
Timers. Allows you to specify time-out intervals (in minutes) for

connected, disconnected, and idle sessions. Only new sessions are affected
by changes to the time-out intervals. For example, to specify a time-out
interval of 10 minutes for disconnected sessions, use -t disconnect=10.
To specify that a timed-out session be logged off rather than reset, use t disclogoff=num in addition to the -t disconnect setting. Use authentication
to specify the maximum duration that a session in the connected state exists
on the server, prior to the user logging on or reconnecting. When the
specified duration elapses, the session is reset. Use the keyword NONE to
disable all time-out settings. Use client check to specify the maximum period
of time a client device can be unresponsive before the server checks that
the client device is still connected. Use client response to specify the
maximum period of time the server waits for a response from a client
device before disconnecting sessions automatically.
Note: You must configure both client check and client response options
to disconnect sessions interrupted by network failure automatically.
-c
Connections. Allows you to define how the server handles timed out or
broken sessions.
Set broken to DISCONNECT to disconnect sessions that are broken; set to

RESET to terminate broken sessions. Set broken to LOGOFF to log off
broken sessions. Logging off sessions allows some applications to exit
more cleanly than with RESET. A RESET is performed on the session after
30 seconds if logging off does not fully terminate the session.
Note: Use the LOGOFF and RESET options with care because users will not
be prompted to save their data before sessions are logged off or reset in this way.
Set reconnect to ORIGINAL to allow reconnection only to a broken or timed
out session from the original terminal; set to ANY to allow reconnection to
the session from any terminal.
-p
Client printing. Use to enable or disable client printing.
-C
Client clipboard. Use to enable or disable the client clipboard.
-P
Port number. Use to specify a TCP/IP port number on which the server can
listen for connections. Use set to use a specific number or reset to use
the default number. You must restart the server for the new value to take effect.
-g
Generate. This generates a list of commands that, if executed, restores

all settings to their current values (except the password). You can redirect
these commands to a file that you can later execute as a shell script. -g cannot
be used with any other argument.
-e
Encryption. Use to force client devices to use encryption and prevent

client devices who do not use encryption from connecting.
-i
Initial program. Use to specify a program, and path if necessary, to run when
the plugin initially connects. INHERIT uses the program and path specified in
the plugin. PUBONLY restricts users so that they can connect only to
published applications, and prevents users from connecting to the server
by name, or to the server desktop.
-s
Shadowing. Use to enable or disable shadowing. Set input to on to allow

the shadower to interact with the shadowed session using the keyboard
and mouse. Set notify to on to give users the option to approve or deny
the shadowing of their session.
Note that when enabling shadowing, the default for input is on and the
default for notify is on.
-D
Client drive mapping. Use to enable or disable client drive mapping, where ro
is read-only access, and rw is read-write access. When client drive mapping
is enabled, it is enabled for all users and all their available local drives.
However, you can restrict access using ctxsecurity and ctxmount.
-k
Switch that allows you to turn features on and off (for example, the ability to
log on without a home directory) and set numeric factors (such as the load factor).
To tune the load factor on a server, use ctxcfg -k loadfactor=num, where num
is a load factor value between one and 10000. By default, each server has a
load factor of 100.
To allow users whose home directories are unavailable to log on, set
lognohome=1. To prevent users from logging on without a home directory, set
lognohome=0.
To allow sessions interrupted by network errors to be automatically
reconnected, set autoreconnect=1. To prevent sessions interrupted by
network errors from being automatically reconnected, set autoreconnect=0.
To control the logging of session logons, logoffs, disconnects, and reconnects
in the system log file, set logonlogging, logofflogging, reconnectlogging, or
disconnectlogging to one of the following values: 0 = disable logging. 1
= enable the short form of logging. Provides default syslog information, such
as the date and time, and the user name. 2 = enable detailed logging. As
above plus the session id, client name, and information about what is
running, such as a published application name or desktop. For example, to
enable detailed logging of session logons, set logonlogging=2.
To prevent any new logons to the server, set nomorelogons=1. Users can
still reconnect to existing disconnected sessions; but new sessions are
not created. To reallow new logons on the server, set nomorelogons=0.
Note that this value is reset to 0 each time XenApp is restarted.
To disable scrollmouse support, set disablescrollmouse=1. All
subsequent sessions will not claim this capability.
-m
Mouse-click feedback. Use this option to enable and disable mouse-click

feedback. Mouse-click feedback is enabled by default.
You can also configure the thresholds in which mouse-click feedback operates
by setting upper and lower threshold values, in milliseconds. The thresholds
are like switches that determine when mouse-click feedback is on or off.
By default, the upper threshold is 500 milliseconds and the lower threshold is
150 milliseconds.
To display the current settings, use the list option.
-o
Allows you to set the length of delay (in milliseconds) for buffering of
graphics. Use set=n to specify the delay and reset to reset the current setting
to 100ms. To display the current setting, use the list option.
-h
Remarks
ctxcfg -t has no effect on anonymous users.
Caution: UNIX permissions prevent users from being able to display and access each others files. However,
if you use ctxcfg -a to allow automatic logon, your users can see directory listings of each others files
(for example, using the ls command in UNIX) and they can access and display the contents of the files
because users are logged on under the same user id. To prevent this, do not use ctxcfg -a with client
drive mapping.
See also
ctxanoncfgto specify an idle time-out period for anonymous users.
ctxsecurityto restrict access to client drive mapping on a user or group-level basis.
ctxmountto restrict user access to specific mapped drives.
10.2.2.11.1.8. ctxconnect
Updated: 2009-09-29
Description
ctxconnect lets you connect to a session.
Syntax
ctxconnect id
ctxconnect -h
Options
-h
Parameters
id
Specifies the session id to which to connect.
Remarks
By default, Citrix administrators can connect to any session; other users can connect only to their own sessions.
See also
ctxsecurityto control which users can connect to other users sessions.
10.2.2.11.1.9. ctxcreatefarm
ctxcreatefarm is an alias of ctxfarmsee the ctxfarm command for more information.
10.2.2.11.1.10. ctxdisconnect
Updated: 2009-09-29
Description
ctxdisconnect lets you disconnect a session. You can disconnect sessions on the local server or on other
servers in the farm.
Syntax
ctxdisconnect [ id | servername:id ]
Parameters
id
Specifies the session id to disconnect.
servername
Specifies the name of a server in the farm to disconnect. For example, server1:
34 means session 34 running on server1.
Remarks
If you do not specify a session id, your own session is disconnected. By default, administrators can disconnect
any session; other users can disconnect only their own sessions.
See also
ctxsecurityto control which users can disconnect other users sessions.
10.2.2.11.1.11. ctxfarm
Updated: 2009-09-29
Description
ctxfarm lets you create a server farm, join a server to a farm, remove servers from the farm, or change the
farms passphrase and secret key. XenApp for UNIX uses this secret key to communicate between the servers
in the farm.
The ctxcreatefarm and ctxjoinfarm commands are aliases of ctxfarm.
Syntax
ctxfarm
ctxcreatefarm
ctxjoinfarm
-c | -j | -k | -l | -r [server-name]
Options
-c
Create a server farm. Alternatively, use ctxcreatefarm.
-j
Join a server to a farm. Alternatively, use ctxjoinfarm.
-k
Change the farms secret key and passphrase. .
-l
Lists servers in a farm and specifies which server is the Management

Service Master.
-r
Remove a server from the farm.
Usage
When you run ctxfarm, ctxcreatefarm, or ctxjoinfarm, you are prompted for, or you can enter, the
following information:
Farm name
If you are creating a farm, specify the name you want to give the farm.
If you are joining a farm, specify the name of the farm you want the server to join.
If the server is already in a farm, type the name of the farm you want the server
to join and then confirm you want to move the server to the new farm.
Farm passphrase
If you are creating a farm, specify a passphrase. This is required by

administrators whenever they want to join servers to this farm.
If you are joining a farm, this is the passphrase specified when the farm was
first created.
If you are changing the secret key and passphrase, specify the new passphrase.
The secret key update happens at the same time as the passphrase update.
Server name
If you are joining a farm, specify the name or IP address of a server already in
this farm.
Optionally, if you are removing a server from a farm, you can specify the server
you want to remove. If you do not specify a server name, the local server is
removed from the farm.
Remarks
The server that you create the farm on will become the Management Service Master, so ensure that you
create the farm on an appropriate server.
Caution: You must remember the passphrase, because the passphrase you specify when you create the
farm is required by administrators whenever they want to join servers to this farm. If you lose the
passphrase, you cannot add servers to the farm.
If you update the secret key and passphrase, the command notifies you when the change has been
completed successfully. You are also notified of any servers ctxfarm could not reach to update. If ctxfarm
cannot contact a reasonable proportion of servers in the farm, the update fails.
10.2.2.11.1.12. ctxgrab
Updated: 2009-09-29
Description
ctxgrab lets you capture dialog boxes or screen areas and copy them from an application in an ICA
session window to an application running on the local client device.
ctxgrab is available from a command prompt or, if you are using a published application, from the ctxwm
window manager, as follows:
In a seamless window, right click the button in the top, left hand corner of the screen to display a
menu and choose the Screen Grab option
In a full screen window, right click to display the ctxwm menu and choose the Screen Grab option
When ctxgrab starts, a dialog box appears.
Syntax
ctxgrab
See also
ctxcapturea more extensive tool that lets you cut and paste graphics between ICA applications and
applications running on the client device.
10.2.2.11.1.13. ctxjoinfarm
ctxjoinfarm is an alias of ctxfarmsee the ctxfarm command for more information.
10.2.2.11.1.14. ctxlogoff
Updated: 2009-09-29
Description
ctxlogoff logs off a user from a XenApp server. You can log off sessions on the local server or on other servers
in the farm.
Syntax
ctxlogoff [servername:id | id]
ctxlogoff -h
Options
-h
Parameters
id
Specifies the session id to log off.
servername:id
Specifies the session id to log off on a particular server, where servername is

the name of a server in the farm. For example, server1:34 means session
34 running on server1.
Remarks
If a user is not specified, you are logged off.
By default, administrators can log off any user; other users can log off only themselves.
See also
ctxsecurityto control which users can log off other users sessions.
10.2.2.11.1.15. ctxlpr
Updated: 2009-09-29
Description
ctxlpr prints to a client printer.
Syntax
ctxlpr
[-P printerName] [-b] [-n] [file1, ...file10

]
ctxlpr
-h
Options
-P
Print a file to a printer (or printer port) other than the default. This is the
printer name or printer port shown in the first column of the output from
ctxprinters.
-b
Print the job in the background.
-n
Only one print job can be handled at a time in any one session. If a call is made
to ctxlpr while a previous job is still printing, the default behavior is for the
second command to wait for the first job to end before continuing. Use the -n
option to cause a second print job to fail rather than wait. Use this to
stop applications from waiting while other printer jobs are handled.
-h
Parameters
file
Specifies the name of a file to print. Up to 10 files can be specified; each file
is treated as a separate print job. If no files are specified, ctxlpr takes its
input from standard input (stdin).
printerName
Name of the printer (or printer port) other than the default.
See also
ctxprintersto list printers installed on the client device.
10.2.2.11.1.16. ctxlsdcfg
Updated: 2009-09-29
Description
ctxlsdcfg configures communication with the license server.
You can run this command interactively or non-interactively. Use the ctxlsdcfg command to
configure communication with the license server interactively, using the License Config> command prompt.
Use the ctxlsdcfg command with the required options to configure communication with the license server
non-interactively.
Syntax
ctxlsdcfg -s server_name
ctxlsdcfg -p port_number
ctxlsdcfg -e edition
ctxlsdcfg -c compatibilty
ctxlsdcfg -m mode
ctxlsdcfg -h
Options
-s
Specify the name of the license server.
-p
Specify the port number of the license server.
-e
Specify the current product edition (either Enterprise or Platinum).
-c
Specify whether XenApp for UNIX can share licenses with servers running
Citrix Presentation Server 4.0 or earlier, or with servers running

Citrix Presentation Server 4.5 or later (either 4.0 or post4.0).
-m
Specify whether XenApp runs in feature pack or base mode

(either FeaturePack1or Base).
-h
Usage
When you run the ctxlsdcfg command interactively, the License Config> command prompt appears and you
can enter the following commands:
list
Display the current license server name, port number, and product edition.
server server_name
Specify the name of the license server.
port port_number
Specify the port number of the license server.
edition product_edition
Specify the current product edition (either Enterprise or Platinum).
compatibility
compatibility
Specify whether XenApp for UNIX can share licenses with servers running
Citrix Presentation Server 4.0 or earlier, or with servers running
Citrix Presentation Server 4.5 or later (either 4.0 or post4.0).
mode mode
Specify whether XenApp runs in feature pack or base mode

(either FeaturePack1or Base).
exit
Exit the program.
Remarks
Settings for compatiblity and mode options are propagated to all servers in the farm only if Citrix XenApp
4.0, with Feature Pack 1, for UNIX is installed on the Management Service Master server.
10.2.2.11.1.17. ctxmaster
Updated: 2009-09-29
Description
ctxmaster shows the master ICA browser address.
Syntax
ctxmaster [-h]
Options
-h
Remarks
Citrix recommends you use the ctxqserver -master command instead to display the server acting as the
master browser.
See also
ctxqserverto display the master browser address.
10.2.2.11.1.18. ctxmount
Updated: 2009-09-29
Description
ctxmount configures user access to specific mapped drives.
When you enable client drive mapping using ctxcfg, all the local drives available to a user are mapped.
However, you can configure access to particular mapped drives using the ctxmount command. You can do
this for particular users or for every user who connects to a XenApp server.
To use the ctxmount command, you modify it within the ctxsession.sh script.
Syntax
ctxmount [ -d | -ro ] [ drivelist | all ]
Options
-d
Disconnect a drive.
-ro
Configure access to a drive as read-only. If you specify a currently

connected drive, this drive is made read-only.
Parameters
drivelist
Specify the drive letters to which you want to configure access (A B C ... Z) or all
to specify all available drives. If you do not specify a drivelist, the default of all
is used.
Remarks
Settings configured using ctxcfg take precedence over any settings configured using ctxmount. For example,
if you enable read-only access to mapped drives using ctxcfg, read-write access cannot be granted using
ctxmount.
See also
ctxcfgto enable or disable client drive mapping for all users and all available local drives.
ctxsecurityto restrict access to client drive mapping on a user or group level basis.
10.2.2.11.1.19. ctxmsg
Updated: 2009-09-29
Description
ctxmsg sends a message to a particular session or to all sessions, either on the local server or in the
entire server farm.
Syntax
ctxmsg
[-w] {id | servername:id} message [timeout

]
ctxmsg
-a message
ctxmsg
-s servername message
ctxmsg
-S message
ctxmsg
-h
Options
-w
Suspends the ctxmsg program until the message either times out or the
user dismisses it. That is, the command prompt returns only when the
user responds or the message times out.
-a
Send a message to all users on the local server.
-s
Send a message to all users on a particular server.
-S
Send a message to all users on all servers in the farm.
-h
Parameters
id
Session id of the user to whom you want to send the message.
servername
Name of a server in the farm. For example, server1:34 means session 34

running on server1.
message
The text you want to send. To send a message that contains spaces, enclose
it within double quotes.
timeout
Specify a time-out (in seconds) for the message. If no time-out is specified, or

the time-out is specified to be zero, the message dialog box remains
displayed until dismissed by the user.
See also
ctxquser or ctxqsessionto display users session IDs.
ctxsecurityto control which users can send messages to other users sessions.
ctxshutdownto inform users that the server is about to shut down.
10.2.2.11.1.20. ctxprinters
Updated: 2009-10-01
Description
ctxprinters lists printers installed on the client device and indicates which is the default.
For each printer, the list displays:
The printer name or printer port (for example, lpt1). You can use this in the ctxlpr -P command to
specify a printer other than the default.
The name of the device driver.
The name of the port to which the printer is attached.
Syntax
ctxprinters [-h]
Options
-h
See also
ctxlprto print to a client printer.
10.2.2.11.1.21. ctxqserver
Updated: 2009-10-01
Description
ctxqserver displays information about XenApp servers on the network.
Note: Some options, such as -license, display information only for servers running versions prior to
Version 4.0 that use the previous licensing method. For information about the new Citrix Licensing method, see
Getting Started with Citrix Licensing.
Syntax
ctxqserver
[server_name]
ctxqserver
-addr server_name
ctxqserver
-app [application_name | server_name]
ctxqserver
-disc [application_name | client_name]
ctxqserver
-gateway [server_name]
ctxqserver
-gatewaylicense:IP_address
ctxqserver
-license [server_name]
ctxqserver
-load server_name
ctxqserver
-master
ctxqserver
-netlicense
ctxqserver
-ping [-count:value] [-size: value]

server_name
ctxqserver
-reset server_name
ctxqserver
-serial [server_name]
ctxqserver
-stats server_name
ctxqserver
-tcpserver:x
ctxqserver
-h
Options
-addr
Display the network address of a specific server.
-app
List all published applications and the server load. Specify the name of
an application or server to narrow the list.
-disc
List all disconnected sessions. Specify the name of an application or client

device to narrow the list.
-gateway
List the ICA gateways known to each server. Specify a server name to narrow
the list.
-gatewaylicense
Display the number of remote licenses available from a gateway. Specify the
IP address of the gateway; that is, ctxqserver -gatewaylicense:12.12.123.12.
-license
List the licenses on each server. Mach displays the number of licenses kept
local to the server; Pool displays the number of pooled licenses; Total shows
the sum of the local and pooled licenses.
Specify a server name to narrow the list.
-load
Display the loading for a particular server.
-master
Display the IP address of the master browser.
-netlicense
Display information about the number of licenses installed and in use on the
local network. The number of licenses kept local to the server and the
number pooled is also shown.
-ping
Ping the named server.
-reset
Reset statistics about the activities of the browser (for example,

elections sent/received, packets sent/received) for the named server.
-serial
Display the licenses on each server. Specify a server name to narrow the list.
-stats
Display statistics about the activities of the browser for a particular server.
-tcpserver:x
Sets the TCP/IP default server address to x.
-h
Parameters
server_name
Name of a specific server.
application_name
Name of a published application.
-count:value
Use with the ping option to specify the number of packets to send. The default
is five packets.
-size: value
Use with the ping option to specify the packet size. The default is 256 bytes.
IP_address
TCP/IP address of a server.
10.2.2.11.1.22. ctxqsession
Updated: 2009-10-01
Description
ctxqsession displays a default listing of session details.
ctxqsession displays information about ICA connections to the local server, another server in the farm, or
the entire server farm. The information includes, where appropriate, user name, session ID, state, type,
and device.
Syntax
ctxqsession [-s servername]
ctxqsession -S
ctxqsession -h
Options
-s
Display information about a particular server.
-S
Display information about all servers in the farm.
-h
Parameters
servername Name of a specific server.
See also
ctxquserto display session user details.
ctxqueryto display additional session details or details in a different format.
10.2.2.11.1.23. ctxquery
Updated: 2009-10-01
Description
ctxquery allows you to display a comprehensive list of session details and to configure the display of
these details.
ctxquery displays information about connections to one or more XenApp servers in a farm. This
includes information about users, sessions, client devices, servers, and published applications. You can also
use ctxquery to produce machine-readable output.
Syntax
ctxquery
{-f short_format_options | -o long_format_options} [-m]
ctxquery
{-f short_format_options | -o long_format_options} [-m] [user username

]
ctxquery
{-f short_format_options | -o long_format_options} [-m] -s servername

[user username]
ctxquery
{-f short_format_options | -o long_format_options} [-m] -S [user

username]
ctxquery
-h
Options
-f
Configure the display format using characters to indicate the information

that should be shown.
-o
Configure the display format using keywords to indicate the information

that should be shown.
-m
Produce machine-readable output. Spaces are removed from column headers

so that a constant number of columns is displayed on every line.
-s
-S
-h
Parameters
short_format_options
Characters that indicate the information you want to display. See the
following table for details.
long_format_options
Keywords that indicate the information you want to display. See the
following table for details.
servername
user username
Name of a particular user you want to query
Long Format Options
Short
Format Options
Description
addr
Client address. The hardware address of the client device.
app
Published application name.
dev
Client device name.
id
Session ID. This is in the format servername:id, where

servername is the name of a server in the farm, and id is
the session identifier.
idle
Idle time. The length of time since there was user activity
in this session. It may take some time to display
this, depending on the number of users and how they
are distributed across servers.
logon
Logon time. The time the user logged on to the system.
sess
Session name; for example: tcp#41.
sess#
Session number only. Use to display the session

number without the servername: prefix.
srvr
Server name. The name of a server in the farm.
state
Session state:
listen - indicates the session that is listening for new

incoming connections.
active - indicates an established, active connection.
connq - indicates a brief session initialization phase
that occurs before the logon prompt appears and
during reconnect.
init - a brief session initialization phase.
conn - indicates a session that is being connected.
disc - indicates a disconnected session.
down - indicates a broken session.
shadow - indicates that the user of this session is
shadowing another.
reset - indicates a session currently being reset.
type
Session type. wdica indicates that the ICA protocol is

being used.
user
User name.
xdpy
X display number.
Xdpy
X display number, without the leading colon (:).
See also
ctxqsessionto display a default list of session details.
ctxquserto display a default list of session user details.
10.2.2.11.1.24. ctxquser
Updated: 2009-10-01
Description
ctxquser displays a default listing of session user details.
ctxquser displays information about users logged on to the local server, another server in the farm, or the
entire server farm. The information displayed includes the user name, the session ID, the state, the time the
user has been idle, and the total time the user has been logged on.
Syntax
ctxquser
[user username]
ctxquser
-s servername [user username]
ctxquser
-S [user username]
ctxquser
-h
Options
-s
-S
-h
Parameters
servername
user username Name of a particular user you want to query.

See also
ctxqsessionto display session details.
ctxqueryto display additional session details or details in a different format.
10.2.2.11.1.25. ctxreset
Updated: 2009-10-01
Description
ctxreset resets a session.
ctxreset resets an ICA connection on the local server or another server in the farm. You specify the session to
be reset using its session id.
Syntax
ctxreset {id | servername:id }
ctxreset -h
Parameters
id
Session id of the session you want to reset.
servername
Name of a server in the farm. For example, server1:34 means session 34

running on server1.
-h
Remarks
By default, administrators can reset any session; other users can reset only their own sessions.
See also
ctxqsessionto display the current sessions.
ctxquserto display session user details.
ctxsecurityto control which users can use ctxreset to reset other users sessions.
10.2.2.11.1.26. ctxsecurity
Updated: 2009-10-01
Description
ctxsecurity configures XenApp security.
XenApp security controls a users access to commands and sessions. When you install XenApp, default
security settings are applied that automatically control access at a global level to XenApp-secured
functions. Security can also be controlled at user and group levels.
Syntax
ctxsecurity
secured_function -l
ctxsecurity
secured_function -a {allow | deny}
ctxsecurity
secured_function -u {user_name} {allow | deny}
ctxsecurity
secured_function -g {group_name} {allow | deny}
ctxsecurity
secured_function {-u user_name | -g group_name

} inherit
ctxsecurity
-h
Options
-l
Display security settings for a particular secured function.
-a
Change the global security setting for a secured function.
-u
Change security at user level for a secured function.
-g
Change security at group level for a secured function.
-h
Parameters
secured_function
A particular tool; for example, shadow. The secured functions are shown in
the following table.
allow
Permit access to the secured function.
deny
Prevent access to the secured function.
user_name
User account name.
group_name
Group name to which the user belongs.
inherit
Remove previous user or group security settings and inherit settings from
the level above.
Secured Fucntions
The following table lists the secured functions together with their default settings after installation.
Secured function
XenApp security determines
Default global setting
login
Which users can log on to the server.
Allow
sendmsg (ctxmsg)
Which users can use ctxmsg to send

messages to other users sessions.
Allow
Deny for anonymous users
connect (ctxconnect) Which users can use ctxconnect to connect

to other users sessions.
Deny
disconnect (ctxdisconnect)
Which users can use ctxdisconnect
to disconnect other users sessions.
Deny
logoff (ctxlogoff)
Which users can use ctxlogoff to log off

other users sessions.
Deny
reset (ctxreset)
Which users can use ctxreset to reset

other users sessions.
Deny
shadow (ctxshadow) Which users can use ctxshadow to

shadow other users sessions.
Allow
Deny for anonymous users
cdm
Which users can use client drive mapping

to access their local drives.
Remarks
See also
ctxcfgto enable and disable shadowing and client drive mapping.
Allow
10.2.2.11.1.27. ctxshadow
Updated: 2009-10-01
Description
ctxshadow starts a shadowing session. Shadowing lets you monitor and interact with another active session.
The session that issues the ctxshadow command is referred to as the shadower, and the session being
shadowed is called the shadowed session.
Syntax
ctxshadow
{id | servername:id} [-v] [-h[[a][c][s]

+]x]
Options
-v
Verbose output. Displays additional information.
-h
Use with a session id to configure a hotkey combination to end shadowing;

for example, ctxshadow id [-h[[a][c][s]+]x] Or Specify ctxshadow -h
to display a usage message.
Parameters
id Or servername:id
Specify the session to be shadowed using its session ID.

Alternatively, specify the local server name and ID; for example, server1:
34 means session 34 running on server1. Note that you cannot shadow a
session on another server.
{a|c|s}+x
Specify the hotkey combination you want to use to end shadowing. Choose
this combination from:
a|c|s where a = ALT; c = CTRL; s = SHIFT x where x is an
alphanumeric character (a to z and 0 to 9)
Note: You can use any combination of a, c, and s, including all or none.
For example, to begin shadowing and to specify a hotkey combination of ALT
and q to stop shadowing, type: ctxshadow {id | name} -h a+q
To End a Shadowing Session

By default, you can end shadowing by holding down the CTRL key and pressing the asterisk (*) key on
your keyboards numeric keypad. However, if you cannot use this hotkey combination or you prefer to use
an alternative, you can configure a different combination using the -h option.
Remarks
Note that virtual channel data (instructions to the server that affect only the shadowed session) is not
shadowed. For example, if you print a file while shadowing a session, the file is queued at the shadowed session
s printer.
You may also get some unexpected results using the clipboard channel. The user of the shadowed session can
use the clipboard to copy and paste between the ICA session and applications running locally. As shadower,
you cannot access the contents of the shadowed sessions clipboardinformation in the clipboard belongs to
the shadowed session. However, if you copy information to the clipboard while shadowing, this information
is available to the shadowed session for pasting.
See also
ctxcfgfor shadowing configuration at the server.
ctxquser or ctxqsessionto display session ID.
ctxsecurityto control which users can shadow other users sessions.

10.2.2.11.1.28. ctxshutdown
Updated: 2009-10-01
Description
ctxshutdown stops the XenApp processes.
Syntax
ctxshutdown
[-q] [-m seconds] [-l seconds] [message

]
ctxshutdown
-h
Options
-q
Quiet mode. Use to reduce the amount of information displayed to

the administrator by the ctxshutdown command.
-m
Specify when the shut down process will begin, and how long the message
will appear, in seconds. The default is 60 seconds. When this period expires
and the shut down process begins, applications that have registered
window hints (the WM_DELETE_WINDOW attribute) will attempt to
interactively log the user off. Applications that have not registered window
hints will terminate immediately.
-l
Specify how long applications that have registered window hints have
to interactively log users off. The default is 30 seconds. When this period
expires, any remaining sessions are terminated automatically, users are logged
off automatically, and the XenApp process stops.
-h
Parameters
message
Specify the message displayed to all users logged on to the server. If you do
not specify a message, the default message Server shutting down. Auto logoff in
x seconds appears, where x = the number of seconds specified in the -m
option (or the default of 60 seconds if this is not specified).
Remarks
See also
ctxsrvto stop the XenApp processes on a server.
10.2.2.11.1.29. ctxsrv
Updated: 2009-10-01
Description
ctxsrv starts up or stops the server processes.
You can use ctxsrv to start up and stop all the processes on the server, or to start up and stop an
individual process, such as the ICA browser or SSL Relay.
Syntax
ctxsrv
start [browser|sslrelay|cdm|lsd|msd|server|all]
ctxsrv
stop [browser|sslrelay|cdm|lsd|msd|server|all]
ctxsrv
-h
Options
browser
The Citrix ICA Browser Service.
sslrelay
SSL Relay.
cdm
Client drive mapping. If you stop client drive mapping using ctxsrv stop,
this immediately stops the client drive mapping process on the server,
and disables client drive mapping for all connections, including any
existing connections.
lsd
License Service daemon.
msd
Management Service daemon.
server
The connection server.
all
All server processes.
-h
Remarks
Citrix recommends you use the ctxshutdown command to stop the XenApp processes on a server. If you
use ctxsrv to stop XenApp, and sessions are still active when the server is stopped, the sessions are
terminated and unsaved applications or user data can be lost.
You must be root or an administrator to run this command.
Do not run the commands ctxsrv start all, ctxsrv stop all, ctxsrv start cdm and ctxsrv stop cdm from
within the /ctxmnt directory, or the client drive mapping process fails.
See also
ctxshutdownto shut down the processes on a server.
ctxcfgto disable client drive mapping for new connections only.
10.2.2.11.2. XML Service Commands
Updated: 2009-10-20
The XML Service commands are as follows:
ctxnfusesrv configure the Citrix XML Service HTTP port, enable publishing mode, DNS address resolution,
and specify the SSL Relay port
10.2.2.11.2.1. ctxnfusesrv
Updated: 2009-10-01
Description
ctxnfusesrv configures the server listening port, or lists the current listening port. ctxnfusesrv can also be
used to enable users to make secure connections using SSL and to enable and disable DNS address resolution.
Syntax
ctxnfusesrv
{l | port portnumber}
ctxnfusesrv
-ssl-port portnumber
ctxnfusesrv
-dns [ enable | disable ]
ctxnfusesrv
-bind {all | subnet-address [subnet-mask

]}
Options
port
Configures the HTTP server listening port. The default port number is 80.
-l
Lists the current HTTP server listening port, the publishing mode, the SSL
port number, and the DNS address resolution setting.
-ssl-port
Specifies the port number on which SSL Relay listens for connections (this is
the SSL port you configured using the SSL Relay configuration tools). You need
to run this command only if you are not using TCP port 443, which is the
standard port for SSL-secured communications.
-dns
Enables and disables Domain Name System (DNS) address resolution. By

default, DNS is disabled and XenApp servers reply to browsing requests with an
IP address.
-bind
Restricts ICA master browser broadcasts made by the XML Service to one
subnet. If the server has more than one network interface and is connected
to more than one network or subnet, this option configures the network to
which ICA master browser broadcasts are sent. If the network is subnetted,
the appropriate subnet network mask must be specified. By default, ICA
master browser requests are broadcast locally on all available interfaces.
Parameters
portnumber
TCP port number.
enable
Enables DNA address resolution.
disable
Disables DNA address resolution.
subnet-address
Specifies the subnet or interface address to which ICA master browser

broadcasts are sent. The format of the subnet address is aaa.bbb.ccc.ddd;
for example, 10.20.131.123.
subnet-mask
Specifies the netmask corresponding to the subnet address. The format of

the subnet mask is aaa.bbb.ccc.ddd; for example, 255.255.240.0.
Remarks
If you make changes using ctxnfusesrv -port, you must stop and restart the XML Service using ctxsrv {start
| stop} msd for the changes to take effect.
See also
ctxsrvto start and stop the XML Service.
10.2.3. SSL Relay for UNIX Administration
Updated: 2010-01-22
This section of the library provides up-to-date product information about SSL Relay for UNIX, which is
a component of Citrix XenApp for UNIX. The section is for system administrators who are responsible
for installing, configuring, and maintaining SSL Relay, Citrix XenApp for UNIX, and the Web Interface.
These topics assume you have knowledge of:
Citrix XenApp for UNIX
Citrix XML Service for XenApp for UNIX
Web Interface
Features of SSL Relay
Installing a Server Certificate on a Server
Overview of Security, SSL, and Cryptography Configuring SSL Relay Ready for Use
Planning Your SSL Relay Deployment
Changing the SSL Relay Configuration
Generating or Renewing a Certificate
Managing Your Server Certificates
10.2.3.1. Introducing SSL Relay

Updated: 2010-01-22
SSL Relay provides the ability to secure data communications using the Secure Sockets Layer (SSL) protocol.
SSL provides server authentication, encryption of the data stream, and message integrity checks.
You can use SSL Relay to secure communications:
In a Web Interface deployment, between the Web server and the XenApp server.
Between an SSL-enabled plugin and a XenApp server.
In a Web Interface Deployment
If you enable SSL on a server running the Web Interface and SSL Relay on a XenApp server, the data
passed between the Web server and XenApp is secured using SSL encryption. SSL Relay uses a TCP port to
listen for SSL-secured connections. When it receives a connection, it decrypts the data before redirecting the
data to the Citrix XML Service.
Between an SSL-enabled Plugin and a XenApp Server
If you enable SSL Relay on a XenApp server and deploy SSL-enabled plugins, data passed between the
client device and the XenApp server is encrypted using SSL. SSL Relay uses a TCP port to listen for SSLsecured connections. When it receives an SSL connection, it decrypts the data before redirecting the data to
the server or, if the plugin selected SSL+HTTPS browsing, to the Citrix XML Service.
The following diagram shows how you can use SSL Relay to secure communications at various points in
your Citrix installation.
SSL Relay for UNIX is included automatically when you install Citrix XenApp for UNIX.
Before you can begin using SSL Relay, you must plan how to use SSL to secure communications in your
XenApp installation, obtain digital certificates, and configure the SSL Relay. These steps are described in
this manual.
If you are unfamiliar with the SSL protocol and the concepts of cryptography on which SSL is based,
we recommend that you read the section "Overview of Security, SSL, and Cryptography".
SSL Relay Features
This section describes the key features and benefits of using Citrix XenApp SSL Relay for UNIX.
Encryption of the data streamSSL encrypts information to ensure its confidentiality and to
prevent eavesdropping. One of the main benefits of using SSL to secure communications is that it allows you
to choose the type of encryption you want to use. SSL Relay supports a range of encryption types. You
choose the type of encryption you want to use by selecting a ciphersuite. A ciphersuite defines the
cipher algorithm and parameters to be used, such as the size of the keys.
Authentication of the serverusing SSL, users can verify the identity of a XenApp server. This guards
against the possibility of a third party masquerading as the intended recipient. Some of the checks that the
plugin performs include:
A check for the root certificate. If there is no root certificate, the connection fails.
A check that the root certificate has not expired.
SSL Relay and SSL-enabled plugins do not perform certificate revocation checking.
Message integrity checksSSL ensures that the contents of a message remains intact until it reaches
its intended destination. This prevents accidental or intentional data manipulation.
Special account for SSL Relay administrationSSL Relay requires you to create a special user account
for SSL administration, called the ctxssl user. The ctxssl user is part of the Citrix server administrator
group account ctxadm. Only the ctxssl user can run the SSL Relay commands and access the SSL
Relay directories and files. For information about creating this account, see the Citrix XenApp for
Support for VeriSign and Baltimore root certificatessupport for VeriSign and Baltimore root certificates
is already built into SSL-enabled plugins and servers running the Web Interface. Therefore, there is no need
to obtain and install root certificates on the client device or on the server running the Web Interface if you
are using these Certificate Authorities. In addition to this support, SSL Relay enables you to add additional
root certificates, for example, from an in-house authority.
Tool for generating certificate requests SSL Relay includes the certificate request generation utility
ctxcertreq that creates a certificate request file that you can send to a CA. The utility prompts you for
the required information and generates a private/public key pair, and a certificate signing request for
verification by the CA.
10.2.3.1.1. Overview of Security, SSL, and Cryptography
This section is intended for users who are unfamiliar with SSL and the concepts of cryptography on which SSL
is based. The section discusses what the main threats to secure communications are and how SSL is designed
to tackle these threats. Also discussed are the differences between SSL and Citrix SecureICA Services.
10.2.3.1.1.1. Understanding the Threats to Secure Communications
Updated: 2009-10-23
With Citrix XenApp and the Web Interface, you can instantly extend the reach of any application to any
user, using any device in any location, regardless of client device hardware or network connectivity.
However, with this ability there is the concern of how you safeguard the security of data transmission
between devices.
The three main types of threat to secure communications are: eavesdropping, misrouting, and data
manipulation. The following describes these threats in the context of a XenApp and Web Interface installation.
Eavesdropping
The contents of a message may be read as it is transmitted over a network. Eavesdropping on
sensitive information, such as user ids and passwords, is therefore a serious threat to security.
For example, during communication between a client device and a XenApp server, user login credentials
are transmitted. The credentials are encrypted, but the encryption strength depends on the settings in the
plugin. If an attacker can crack the binary ICA protocol, they can eavesdrop on this information and use it to
gain unauthorized access to the server.
Misrouting
A message could, in theory, be intercepted along its path and re-routed to an unauthorized user or a
counterfeit server.
For example, in a Web Interface deployment, user credentials and application set information is passed
between the Java objects on the Web server and the Citrix XML Service on the XenApp server. In a typical
Web Interface session, the Java objects pass credentials to the XML Service for user authentication and the
XML Service returns application set information. The Web server and server farm use a TCP/IP connection and
the Web Interface XML protocol to pass the information.
The Web Interface XML protocol uses clear text to exchange all data with the exception of passwords, which
it passes using Basic encryption. The XML communication is therefore vulnerable to attack. An attacker
can impersonate the XenApp server and intercept authentication requests.
Data Manipulation
The contents of a message might be deliberately modified or corrupted as it travels along its path.
For example, during Web Interface communication, data is passed between the Web browser on the client
device and the Web server. An attacker may intercept and modify this data.
10.2.3.1.1.2. Using SSL to Tackle Security Threats
Updated: 2009-10-23
The following describes how SSL counteracts the threats to secure communications by providing three types
of security control: authentication, confidentiality, and integrity.
Authentication
SSL addresses the threat of misrouting by providing authentication of the XenApp server. With SSL, users
can verify the true identity of a server or Web site. This guards against the possible misrouting of a message.
Confidentiality
SSL addresses the threat of eavesdropping by ensuring the confidentiality of information as it traverses
a network. SSL prevents possible eavesdropping by creating a secure connection over which the user can
pass their credentials and data. The connection is secure because it is encrypted using negotiated keys, to
which a third party cannot gain access.
Integrity
SSL addresses the threat of data manipulation by ensuring the integrity of information. Using SSL you
can prevent accidental or intentional data manipulation by ensuring that the contents of a message remain
intact as it traverses the network, until it reaches its intended destination.
10.2.3.1.1.3. Comparing SSL with Citrix SecureICA
Using Citrix SecureICA Services, you can encrypt the information sent between a XenApp server and a
client device. This makes it virtually impossible for unauthorized users to open an encrypted transmission and,
in the unlikely event that an attack succeeded, SecureICA ensures that the attacker only sees meaningless
screen commands and not sensitive information.
Therefore, Citrix SecureICA Services provides confidentiality to guard against the threat of
eavesdropping. However, as the previous discussion shows, there are other security risks and using encryption
is only one aspect of a comprehensive security policy.
Unlike SSL, SecureICA does not provide authentication of the XenApp server, therefore information could,
in theory, be intercepted as it crosses the network and re-routed to a counterfeit server. Also, SecureICA does
not provide integrity checking.
Note: Citrix SecureICA is not available for XenApp for UNIX servers.
10.2.3.1.1.4. About Cryptography
Updated: 2009-10-28
SSL uses cryptography to secure communications. Cryptography provides the ability to encode messages
to ensure confidentiality. Cryptography is also used to authenticate the identity of a message 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 also allows the sender to include special information in the message that only the sender
and receiver know. When the receiver sees this special information, they know that the message is authentic.
Cryptography also ensures that the contents of a message have not been 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.
The sender also includes a secret value, known only to the sender and receiver. When the message arrives at
its destination, the receiver calculates the hash function. If the receivers hash function value is the same as
the senders, then the integrity of the message is assured.
Types of Cryptography
There are two main types of cryptography:
Secret key cryptography
Public key cryptography
The following section describes how these types of cryptography work and why they are often combined, as
in SSL.
Secret key cryptography. 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 scrambled by the sender using the key, and unscrambled 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. And there is also the problem of
how you communicate the secret key securely.
Public key cryptography. Public key cryptography is also known also as Asymmetric Key Cryptography.
With this type of cryptography, one key is used to scramble the message and another key is used to
unscramble it. There are always two keys: a public key and a private key. The public key is made available
to everyone, while the private key is kept secret. Messages scrambled with one key can only be
unscrambled using the other key. The following example illustrates how public key cryptography works:
1.
Phil wants to communicate secretly with Velma. Phil encrypts his message using Velmas public key
(which Velma has made available to everyone) and Phil sends the scrambled message to Velma.
2.
When Velma receives the message she uses her private key to unscramble the message so that
the message can be read.
3.
When Velma sends a reply to Phil, she scrambles the message using Phils public key.
4.
When Phil receives Velmas reply, he uses his private key to unscramble her message.
Public key cryptography has a major advantage over secret key cryptographythere is no need to
communicate secret keys up-front. Provided the private key is kept secret, confidential communication is
possible using the public keys.
Combining Public Key and Secret Key Cryptography. The main disadvantage of public key cryptography
is that the process of encrypting a message 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:
1.
Velma wants to communicate secretly with Phil, so she obtains Phils public key. She also
1.
generates random numbers that she will use just for this session, known as a session key.
2.
Velma uses Phils public key to scramble the session key.
3.
Velma sends the scrambled message and the scrambled session key to Phil.
4.
Phil uses his private key to unscramble Velmas message and extract the session key.
Once Velma and Phil have successfully exchanged the session key, they no longer need public key
cryptography; communication can take place using just the session key. In other words, public key encryption
is used to send the secret key then, once the secret key has been 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.
Certificates and Certificate Authorities
The sender of a message must be sure that they have the public key belonging to the receiver. To address
this, SSL uses public key certificates and Certificate Authorities.
A certificate is a digital file issued by a trusted organization known as a Certificate Authority (CA). A certificate
is basically proof of identity. Certificates generally have a common format, usually based on ITU standards.
The certificate contains information that includes the:
Issuerthis is the organization that issues the certificates.
Period of validitythe certificates start date and expiry date.
Public keythe secret key used to encrypt data.
Issuers signaturethe CA digitally signs the certificate to guarantee its authenticity.
A number of companies and organizations act as Certificate Authorities, including VeriSign, Baltimore and
their affiliates.
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, because the private key has been compromised. Therefore, to trust
a public key, you must also ensure that its certificate has not been revoked.
10.2.3.1.2. Getting Started - A Summary of the Steps
Updated: 2009-10-28
The following section summarizes the steps required to get SSL Relay up and running in a XenApp installation.
A typical example is used to illustrate these steps.
Note: This section is intended as an overview onlyit is important that you read the section "Planning
Your SSL Relay Deployment" to ensure that you accurately estimate the type and number of digital
certificates required for your SSL Relay deployment.
In the following example, the Citrix administrator wants to use SSL Relay to secure communications
between client devices and a XenApp for UNIX server . The server is called bagpuss; the server is on a LAN
and there are no firewalls. The server has been installed with Citrix XenApp for UNIX. The administrator
has deployed SSL-enabled plugins on the client devices that access bagpuss.
10.2.3.1.2.1. To get SSL Relay up and running
Updated: 2009-10-28
1.
The administrator reads the section about Planning Your SSL Relay Deployment. From her reading,
she determines that a server certificate is required for bagpuss, and she decides to apply to VeriSign
for this certificate.
The administrator logs on to bagpuss as the ctxssl user and runs ctxcertreq to generate a
certificate request file. She labels the file citrix.
ctxcertreq citrix
At the prompt, she specifies the password secret to protect the file. Since the -filename option is
not specified, the certificate request is written to citrix.req in the current directory.
2.
The administrator sends the certificate request file to VeriSign via a Web browser.
3.
VeriSign process the certificate request and issue a server certificate. The administrator is notified
by email when the signed certificate is ready, and the administrator retrieves the signed certificate via
a Web browser. The administrator saves the certificate file on bagpuss in: /tmp/citrix.pem.
4.
The administrator logs on to bagpuss as the ctxssl user and uses ctxcertmgr to install the
certificate. She includes the -response option, that indicates that the certificate is a response to
a certificate request generated using ctxcertreq.
ctxcertmgr -response /tmp/citrix.pem
The system prompts for the password secret that is used to protect the file.
5.
To configure SSL Relay to listen for connections on port 443, and to configure the forwarding list to
permit redirection to ports 1494 and 80, the administrator types:
ctxsslcfg -add 443 -certificate citrix -forward add bagpuss:1494 -forward add bagpuss:80
The system prompts for the password secret. Since no ciphersuite is specified, the default ALL is applied (
ALL includes both the commercial and government suites, ordered such that commercial is
given preference).
6.
To start SSL Relay on bagpuss, the administrator types:

ctxsrv start sslrelay
SSL Relay is now up and running on the server and SSL-enabled plugins can make secure connections to
the server.
Updated: 2009-10-28
Before you can begin using SSL Relay, you must plan how you will deploy SSL to secure communications in
your XenApp installation, and obtain the appropriate digital certificates. For information, see Planning Your
SSL Relay Deployment.
10.2.3.2. Planning Your SSL Relay Deployment
Updated: 2009-10-26
This section helps you to determine whether you need to deploy SSL Relay in your Citrix XenApp installation,
and it considers the steps in planning an SSL Relay deployment. Topics covered in this section include:
Determining whether SSL Relay is the appropriate solution
Obtaining digital certificates
Configuring ctxssl access to commands
Planning for an attack on your security
Planning the renewal of expired certificates
Before you can begin using SSL Relay, you must:
Evaluate what the security risks are and determine the most appropriate solution
Plan how you will deploy SSL in your XenApp installation
Obtain the appropriate digital certificates
Consider the protection of your private keys
Install the digital certificates
Plan how you will deal with security attacks
Plan the renewal of expired certificates
This section guides you through each step of the planning process and discusses the issues that you need
to consider before you can configure and use SSL Relay.
10.2.3.2.1. Choosing an Appropriate Security Solution
The first step in planning an SSL Relay deployment is to evaluate what the security risks are and then
determine the most appropriate solution for your XenApp installation.
The main threats to security are:
Eavesdroppingeavesdropping on sensitive information, such as user ids and passwords, is a
serious threat to security as an unauthorized user could use these credentials to gain access to the
XenApp installation.
Misroutinga message could, in theory, be intercepted during its transmission and re-routed to
a counterfeit Web site.
Data manipulationthe contents of a message might be lost, deliberately modified, or
accidentally corrupted during transmission.
Denial of Servicein Denial of Service attacks, access to a system or application is prevented
or interrupted.
Knowing the threats, you then need to consider whether your XenApp installation is at risk of a security attack.
You may not need to be concerned about secure communications if, for example, the servers running the
Web Interface, XenApp, and the Citrix XML Service are in a protected machine room and there is no
reasonable way of attacking the link. Or you may decide that the additional burden of deploying a
security solution outweighs the benefits.
If you consider that your XenApp installation is at risk of attack, a solution such as IPSec may be
more appropriate than SSL Relay. IPSec provides secure communications between the Web server and
the XenApp server, therefore, if your organization has already standardized on IPSec, SSL Relay is not required.
If you consider that your XenApp installation is at risk of attack, and your organization has not standardized
on IPSec, we recommend you use SSL Relay.
10.2.3.2.2. Obtaining a Digital Certificate
Updated: 2009-10-28
The next step in planning your SSL Relay deployment is to determine the number and type of digital
certificates that are required, and to obtain these from a suitable source.
A certificate is a digital file issued by a trusted organization known as a Certificate Authority (CA). For
more information about certificates and CAs, see Certificates and Certificate Authorities.
Obtaining a digital certificate can be an involved process, therefore it is important to accurately estimate
how many digital certificates you will require up-front, and to allow enough time for the process of obtaining
the certificates.
This section helps you identify the number and type of certificates you will require, and the considerations
you should make when deciding where to obtain certificates from.
10.2.3.2.2.1. Determining the Certificates Required
Updated: 2009-10-29
There are two main types of digital certificate:
Identity certificate
This identifies a specific machinefor example, a XenApp server.

The type of identity certificate that is required by SSL Relay is called a
Server Certificate.
Root certificate
This identifies the CA that signed the identity certificate. The

root certificate belongs to the CA.
For SSL Relay to work, you require a server certificate at one end of the connection and a root certificate at
the other end.
A server certificate must be installed on every XenApp server on which you plan to use SSL Relay and, in
some cases, on the server running the Web Interface.
A root certificate must be installed on the client device and on the server running the Web Interface.
Certificates Required Between SSL-enabled Plugins and a Web Interface Server
In a Web Interface deployment, the security of the connection between the client device and the Web Interface
is dependant on the abilities and configuration of the server running the Web Interface and the client device
s Web browser. The majority of Web browsers and Web servers support SSL, but configuration is required
before the connection is secured. To do this, you require:
A root certificate on the client device that can verify the signature of the CA on the server certificate.
The root certificate is usually part of the Web browser itself, so there is no need to obtain and install a
root certificate here.
A server certificate on the server running the Web Interfacefor more information about installing
a server certificate, see your Web server documentation.
The following diagram shows the server and root certificates required to secure communications between
SSL-enabled plugins and the server running the Web Interface:
Certificates Required Between a Web Interface Server and a XenApp Server

In a Web Interface deployment, you can use SSL to secure the connection between the Web Interface server
and the XenApp for UNIX server. To do this, you require:
A root certificate on the server running the Web Interface specifically for the Java objects. Support
for VeriSign and Baltimore root certificates is already built into the Web Interface server, so there is
no need to obtain and install root certificates for these CAs. However, if you choose a different CA, you
will need to obtain and install the root certificates yourself.
A server certificate on the XenApp for UNIX server.

Since the Web Interface server and XenApp servers are different machines, you will require separate
server certificates. You cannot use the same server certificate on both machines.
The following diagram shows the certificates required to secure communications between a Web Interface
server and a XenApp server:
Typically, in a Web Interface deployment, one server runs the Citrix XML Service that provides Web
Interface information. However, there may also be a backup of this server. In this case, you would deploy SSL
on the main XenApp server and the backup server, therefore, you will require a separate server certificate
on each of these servers.
Certificates Required Between SSL-enabled Plugins and a XenApp Server
You can use SSL to secure connections between plugins and a XenApp server. To do this you deploy SSLenabled plugins and install SSL Relay on the server. The following certificates are required:
A root certificate on every SSL-enabled plugin that will access the XenApp server. Support for VeriSign
and Baltimore root certificates is already built into the plugins, so there is no need to obtain and install
root certificates on the client device for these CAs. However, if you choose a different CA, you will need
to obtain and install the root certificates yourself.
A server certificate on the XenApp server.
The following diagram shows the certificates required to secure communications between SSL-enabled
plugins and a XenApp server:
Certificates Required for a Fully Secured Installation

To use SSL to fully secure all communications in your XenApp installation, you must:
Deploy an SSL-capable Web browser and SSL-capable Web server.
Use SSL to secure communications between the Web Interface server and the XenApp server.
Use SSL to secure communications between SSL-enabled plugins and the XenApp server.
The following diagram shows the certificates required to secure communications at all points in your XenApp
and Web Interface installation.
10.2.3.2.2.2. Using SSL with Load Balancing

Updated: 2009-11-13
If you are using Load Manager, ensure that you obtain and install server certificates for every load
balanced server to which plugins could connect using SSL.
For example, if you have 10 load balanced XenApp servers that are capable of running your users
applications, you will require 10 server certificates. Without the appropriate certificates, an SSL-secure
connection will be unable to connect to a XenApp server.
For more information about load balancing, see the Citrix XenApp for UNIX Administrators Guide.
10.2.3.2.2.3. Where Do I Get Certificates From?
Updated: 2009-10-26
Once you have identified the number and type of certificates required for your SSL Relay deployment, you
must decide where to obtain the certificates from.
Where you choose to obtain certificates will depend on a number of factors, including:
Whether your organization is a Certificate Authority (CA). This is likely to be the case only in very
large corporations.
Whether your organization has already established a business relationship with a public CA.
The fact that SSL Relay includes support for the VeriSign and Baltimore public Certificate
Authoritiessupport for these root certificates is built into the SSL-enabled plugins and the server
running the Web Interface.
The cost of certificates, the reputation of a particular public CA, and so on.
If your organization is a Certificate Authority
If your organization is running its own Certificate Authority, you must determine whether it is appropriate to
use your companys certificates for the purpose of securing communications in your XenApp installation.
Citrix recommend that you contact your Corporate Security department to discuss this, and to get
further instructions on how to obtain the certificates.
If you are unsure if your organization is a Certificate Authority, contact your Corporate Security department.
If your organization is not a Certificate Authority
If your organization is not running its own Certificate Authority, you need to obtain your certificates from a
public CA, such as VeriSign or Baltimore.
Obtaining a digital certificate from a public CA involves a verification process in which:
Your organization provides corporate information so that the CA can verify that your organization is who
it claims to be. This may involve other departments in your organization, such as Accounts, 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.
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 who they can call if there are queries.
Therefore, obtaining a digital certificate from a public CA can be an involved process.
Important: If you require an additional certificate for another server, you will have to repeat the CA
s verification process. You cannot obtain a certificate for one server and use it on another. Therefore, it
is important to decide at the start how many certificates you require and to allow enough time for the
process of obtaining these.
Obtaining a Root Certificate from a CA
Support for VeriSign and Baltimore root certificates is already built into SSL-enabled plugins and the
server running the Web Interface. Therefore, there is no need to obtain and install root certificates on the
client device or on the Web Interface server if you are using these CAs. However, if you decide to use a
different CA, you will need to obtain and install the root certificates yourself.
CAs tend to assume that you already have the appropriate root certificates (this is because most Web
browsers have root certificates built-in as standard) so you will need to specifically request the root
certificate. Also, there are different types of root certificatefor example; VeriSign have approximately 12
root certificates that they use for different purposesso ensure that you obtain the correct root certificate
from the CA.
10.2.3.2.2.4. Configuring ctxssl Access to Commands
Updated: 2009-10-28
Before you can use the SSL Relay command-line tools, such as ctxcertreq to generate a certificate request
file, you must configure your system so that the ctxssl user can run the commands from the server console
or from an ICA session. To do this, you add the /opt/CTXSssl/sbin directory (when using Solaris and HPUX), or the /usr/lpp/CTXSssl/sbin directory (when using AIX) to the PATH variable.
To configure ctxssl access to SSL Relay commands
If you are using a C shell, use a .login file for the ctxssl user, and add the path to the commands.
For example, for HP-UX and Solaris:
setenv PATH ${PATH}:/opt/CTXSssl/sbin

For AIX:
setenv PATH ${PATH}:/usr/lpp/CTXSssl/sbin

If you are using a Bourne, or similar, shell use a .profile file for the ctxssl user, and add the path to
the commands. For example, for HP-UX and Solaris:
PATH=${PATH}:/opt/CTXSssl/sbin
export PATH
For AIX:
PATH=${PATH}:/usr/lpp/CTXSssl/sbin
export PATH
10.2.3.2.2.5. Generating or Renewing a Certificate

Updated: 2009-10-28
Once you have decided which CA to get your certificates from, the next step is to use the ctxcertreq utility
to create a certificate signing request (CSR) file that you can send to the CA.
The ctxcertreq utility prompts you for the information it requires, and generates a keypair (a private key
and corresponding public key). The private key is encrypted and stored locally, and the public key is used
to create the CSR file.
You can also use ctxcertreq to generate a certificate renewal request file that you can send to the CA. To do
this, you include the -clone option.
The following section explains how to use ctxcertreq to generate a new CSR file or a certificate renewal
request file. For more information about renewing certificates, see Planning the Renewal of Expired Certificates.
What information is prompted for?
When you run ctxcertreq, you are prompted for the following information:
The distinguished name of the subject requesting the certificatein this case, the XenApp server.
Note: When you generate a certificate renewal request, you can either accept the default details that
are displayed for the distinguished name, or override these. This enables you to generate a number
of requests by specifying a common name for each server, without having to re-enter all the details.
The distinguished name consists of the following information:
Abbreviation
Description:
CN
Common Name. This must be set to the servers Fully Qualified Domain
Name (FQDN). The FQDN is the name that plugins use, rather than the
name that local machines use. This parameter is the only one required
by ctxcertreq, however, your CA may also require the following parameters
to be present.
Country. This is a two letter country code; for example GB.
ST
State or Province.
Locality.
Organization.
OU
Organizational Unit (for example, a department).
Caution: You must provide the exact information for the distinguished name because it is not
validated by ctxcertreq. If the information you provide is incorrect, the certificate becomes useless and
a new certificate request will be required which will incur an additional payment to the CA.
A database password that will be used to encrypt the private key.
A number of random keystrokes. These keystrokes are used to generate the keypair.
10.2.3.2.2.5.1. To generate a CSR file

Updated: 2009-10-28
1.
Log on to the server as the ctxssl user.
2.
At the command prompt, type:

ctxcertreq identifier [ -filename filename ] [ -clone clone-identifier ]
3.
Option
Use this option to:
identifier
Give the certificate request a unique label to identify it. This label is
used by the SSL Relay tools and is not included in the certificate
request file that you send to the CA.
-filename
Specify the file the certificate request is written to, where filename is
the name of the file. If you do not include this option, the
certificate request is written to identifier.req in the current
directory (where identifier is the label you specified using the
identifier option).
-clone
Renew a certificate that is due to expire, where clone-identifier is

the identifier of the existing server certificate. The distinguished
name information in the existing certificate can be copied to the
certificate request file. This option can be used to request a group
of similar certificates, as well as renewing a certificate.
At the prompt, type in the distinguished name parameters. If you are generating a certificate
renewal request, you can accept the default distinguished name by pressing ENTER.
4.
At the prompt, type in the database password that will be used to encrypt the private key.
5.
Confirm the database password.
6.
At the prompt, start typing. It does not matter what keys you press; you can type letters,
numbers, symbols, punctuation marks, and control characters. Keep typing until ctxcertreq tells you
to stop.
10.2.3.2.2.6. Sending a Certificate Signing Request file to a CA

After you create the CSR file, the next step is to send this file to the CA for verification and signing.
For information about submitting a CSR, contact the CA or visit their Web site.
10.2.3.2.3. Preparing for an Attack on Your Security
Updated: 2009-11-13
When planning your SSL Relay deployment, you must consider how you will monitor for attacks made on
your security, once SSL Relay is up and running on your system.
If your organization has a standard monitoring and audit procedure, you must determine how SSL Relay will
fit into this procedure. If you are currently operating a third party Intrusion Detection System (IDS), you can
use this to monitor the SSL Relay server. Note however that SSL Relay does not currently support
automatic integration with any third party IDSs.
This section discusses points to consider when preparing for an attack on your security, and describes
what happens in misrouting, which is the most common type of attack.
Misrouting
If a message is intercepted during its transmission and re-routed to a counterfeit Web site, this is known as
misrouting. If misrouting occurs:
Between the client device and the Web Interface server, an error is displayed on the client
device. To ensure users cannot continue regardless, use the client lock down feature of your Web
browser, so that the connection cannot proceed. For information about the client lock down feature,
see the documentation that accompanies your Web browser.
Between the Web Interface server and the XenApp for UNIX server, the Web Interface server
logs an error message. For information about error messages, see the Web Interface documentation.
Between the client device and the XenApp for UNIX server, the plugin displays a specific
error message.
10.2.3.2.4. Planning the Renewal of Expired Certificates

Updated: 2009-10-28
Digital certificates expire after a period of time; usually a year. Typically, your CA will send you a
reminder. Therefore, when planning your SSL Relay deployment, you should also plan for the renewal of
your certificates.
If your digital certificates are issued by a public CA, you must submit a certificate renewal request to the
CA, together with the appropriate billing information. If your organization is a Certificate Authority, contact
your Corporate Security department for information about renewing certificates.
The process of renewing a certificate can be involved, therefore, it is important to allow enough time for
this process, before your existing certificates expire.
You may also have to plan for a suitable overlap period, to allow adequate time to transfer from old certificates
to new ones. For example, if an existing certificate expires on the 6th of June, you may want the new
certificate to start on the 4th of June, to allow time to switch to the new certificate.
When a certificate expires, you can use a different CA, rather than renewing the existing certificate.
Renewing a Certificate
To generate a certificate renewal request file that you can send to the CA, use ctxcertreq with the -clone
option. For information, see Generating or Renewing a Certificate.
For more information about renewing certificates, go to your CAs website.
For information about displaying certificate expiration dates, see To display server certificate information.
Note: Root certificates also expire after a period of time, however, they are typically valid for up to 10 years.
Updated: 2009-10-28
After you have planned your SSL Relay deployment and obtained the appropriate digital certificates, the next
step is to install the certificates. See Installing Digital Certificates for more information.
10.2.3.3. Installing Digital Certificates
Updated: 2009-10-26
This section describes how to install server certificates on a XenApp for UNIX server.
The issuing of certificates is an online process. Once you have received a signed certificate from the CA, the
next step is to install the certificate on the appropriate machine.
The following section describes how to install a server certificate on a XenApp server. It also tells you where
to find information about installing root and server certificates on a server running the Web Interface or on
SSL-enabled plugins. The section also discusses the importance of protecting the private keys.
10.2.3.3.1. Protecting the Private Key
Because SSL is based upon public key cryptography (also known as asymmetric key cryptography) there
are always two keys:
A public key that is made available to everyone.
A private key that is kept secret.
The server certificate contains both the public and private keys; each of these keys must be installed on
the server running SSL Relay.
You must protect the private key at all times. If you do not protect this key, not only is your
security compromised but you have no legal redress in the event of a security attack.
If your organization already has a strategy for protecting and managing private keys, contact your
Corporate Security department to discuss the correct procedures. If your organization currently has no
methods for managing and protecting keys, you will need to formulate a strategy before installing
your certificates.
To ensure private keys are kept secret, SSL Relay protects your keys using UNIX operating system security.
Keys are stored in a directory that requires special permissions and that only the ctxssl user can access.
Caution: Although SSL Relay attempts to protect your private keys to the maximum possible extent, if
an unauthorized user can access the XenApp server that holds the private key and log on as root, they can
get hold of the private key. This also has implications for backupsif you back up the XenApp server,
the private key is also backed up. Therefore, you must consider how you will protect your backups;
for example, by keeping them in a secure store.
10.2.3.3.2. Installing a Server Certificate on a Server
Updated: 2009-10-28
Certificates are installed using the ctxcertmgr command. You install a certificate from the certificate file that
you receive from the CA. Server certificates are installed in the /var/CTXSssl directory of the XenApp server.
How you install a certificate depends upon whether you used ctxcertreq to generate the certificate request
or not.
Note: Before you can use the SSL Relay command-line tools, you must configure your system so that the
ctxssl user can run the commands. Configure this now, if you have not already done so; for information, see
Configuring ctxssl Access to Commands.
10.2.3.3.2.1. To install a server certificate requested using ctxcertreq
Updated: 2009-10-26
If you use ctxcertreq to generate a certificate request, ctxcertreq generates a private key and prompts you for
a password to protect the file. When you receive the signed certificate from the CA, you need to install
the certificate on the XenApp server and match it to the private key and password.
To do this, you use ctxcertmgr to install the certificate and include the -response option. The -response
option indicates that the certificate is a response to a certificate request generated using ctxcertreq. A
new certificate is created which is stored on the XenApp server.
1.
2.

ctxcertmgr -response filename [ -dbpassword db-password ]
where filename specifies the certificate file supplied by the CA.
The following table describes the options:

Option
Use this option:
-response
To indicate the certificate is a response to a certificate request generated

using ctxcertreq.
-dbpassword
To specify the password used to protect the certificate on the XenApp server. This
is the database password you supplied when you ran ctxcertreq. If you include the
-dbpassword option, you must use the db-password parameter to specify the
new password, which should be no larger than 255 characters.Note that this option
is only used if you are including commands in a shell script; otherwise you
are prompted for the password. Using -dbpassword will display the password on
the terminal, and enter it into the users command line history.
Example
Using ctxcertreq, a new certificate request file is generated with the identifier citrix. A private key is
also generated and the password secret specified to protect the file. The new certificate is received from
the CAthis file is called cert.pem and it is saved in the /ssl directory on the XenApp server.
To add the certificate to the server and match it to the private key and password, type:
ctxcertmgr -response /ssl/cert.pem
You are prompted for the db-password secret.
10.2.3.3.2.2. To install a server certificate not requested using ctxcertreq
Updated: 2009-10-28
If you generated the certificate request using a tool other than ctxcertreq, use ctxcertmgr with the -import
option to install the certificate.
1.
2.

ctxcertmgr -import identifier -filename filename [-format format ] [ -keyfilename key-filename
] [ -dbpassword db-password ] [ -filepassword [ file-password ]

Option
Use this option:
-import
To add a certificate to the XenApp server. Use the identifier parameter to give
your certificate a unique label. This label is used to easily identify the certificate
in future.
-filename
To specify the certificate file supplied by the CA, where filename is the location of
the file. If the CA supplies the certificate as two separate files (one file containing
the private key; the other containing plaintext information about the certificate)
use the -filename option to specify the location of the file containing
plaintext information.
-format
To specify the format of the certificate file supplied by the CA. You can import
PEM, NET, DER, PKCS12, and MKS file formats. If you do not specify a format,
the system attempts to auto-detect the format; if it cannot detect the format,
an error message is displayed.
-keyfilename
If the CA supplies the certificate as two separate files (one file containing the
private key; the other containing plaintext information about the certificate). Use the
key-filename parameter to specify the location of the file containing the private
key. Note that, in this case, you would use the -filename option to specify
the location of the file containing plaintext information.
-dbpassword
To specify the new password that you will use to protect the certificate on the
XenApp server. If you include the -dbpassword option, you must use the db-password
parameter to specify the new password. This should be no larger than 255 characters.
-filepassword
To specify the password that the CA used to protect the certificate file. When a
CA sends you a certificate, the certificate is protected using a password. You
need this password to extract the certificate from the file. The CA may supply
this password in a separate email. If you include the -filepassword option, you
must use the file-password parameter to specify the CAs password.
10.2.3.3.2.3. Example - the CA emails the server certificate as one file

Updated: 2009-11-13
The CA sends you a signed certificate file in PEM format. You save this file in the /certs directory on your
server, and call it file1.pem. The private key is protected with the password secret.
To install the server certificate on your server, using the new password confidential and the
identifier my_certificate, type the command:
ctxcertmgr -import my_certificate -filename /certs/ctxssl/file1.pem
You are prompted for the db-password confidential and the file-password secret.
10.2.3.3.2.4. Example - the CA emails the server certificate as two files
Updated: 2009-11-13
The CA sends you the server certificate as two separate files. One file contains plaintext information about
the certificate; the other contains the private key which the CA protects with the password secret. The files
are in PEM format. You call the plaintext file file1.pem and store it in the /ssl directory. You call the private
key file file2.pem and save it to the home directory /home/ctxssl that only you can read.
To install the server certificate on your server, using the new password confidential and the
identifier my_certificate, type the command:
ctxcertmgr -import my_certificate -filename /ssl/file1.pem -keyfilename /home/ctxssl/file2.pem
-dbpassword confidential -filepassword secret
Only use -dbpassword and -filepassword if you are including commands in a shell script.
Note: For information about installing server certificates on a server running the Web Interface, see the
Web Interface documentation.
10.2.3.3.3. Installing a Root Certificate
Updated: 2009-11-13
A root certificate must be installed on every SSL-enabled plugin or on the server running the Web
Interface, depending upon how you plan to use SSL Relay in your XenApp installation.
Installing Root Certificates on SSL-enabled Plugins
A root certificate is required on every SSL-enabled plugin that will access the XenApp server. This means
that when you roll out plugins to your users, you will need to bundle the root certificate along with the plugin files.
Support for VeriSign and Baltimore root certificates is already built into SSL-enabled plugins, so there is no
need to install root certificates on the client device for these CAs. However, if you choose a different CA, you
will need to install the root certificates yourself.

Note: If the client device is using the Windows Operating System, the root certificates are
automatically available for many public CAs. However, the root certificates are not, by default, available
for your own organizations CA. It is the responsibility of your Corporate Security Department to install these
in Windows. For more information about administering these root certificates, see the online plug-in or Plugin for Hosted Apps documentation.
Installing Root Certificates on a Web Interface Server
By default, the Citrix Web Interface Extension (on the server running the Web Interface) contains root
certificates for VeriSign and Baltimore. Therefore, if you have chosen to use VeriSign or Baltimore as your
CA, you do not have to install root certificates on the server running the Web Interface.
However, if you have chosen to use a CA other than VeriSign or Baltimore, you must add the CAs root
certificate to the Citrix Web Interface Extensionsee the Web Interface documentation for information about
how to do this.
Updated: 2009-10-28
After you have installed the appropriate digital certificates, the next step is to configure SSL Relay and get it
up and running. See To configure SSL Relay ready for use for more information.
10.2.3.4. Configuring SSL Relay
Updated: 2009-10-26
This section describes how to enable and configure SSL Relay ready for use. Also explained is how to
maintain SSL Relay and the digital certificates stored on the XenApp server.
10.2.3.4.1. To enable or disable SSL Relay
Updated: 2009-10-26
You can enable or disable SSL Relay at any time after installation by modifying the SSL_ENABLED parameter
in /var/CTXSmf/ssl/config.
Note: You must stop and restart SSL Relay using the ctxsrv stop sslrelay and ctxsrv start sslrelay
commands for these changes to take effect.
1.
Do one of the following:

To enable SSL Relay, write SSL_ENABLED=1 to /var/CTXSmf/ssl/config.
To disable SSL Relay, write SSL_ENABLED=0 to /var/CTXSmf/ssl/config.
10.2.3.4.2. Configuring SSL Relay Ready for Use

Updated: 2009-10-29
After you have obtained and installed your digital certificates, the next step is to configure the SSL Relay
ready for use. The following section describes in detail what you must configure on the XenApp server,
and explains how to use the ctxsslcfg command to do this.
What Do I Need to Configure?
Before you can use SSL Relay for the first time, you must:
Specify the TCP port that SSL Relay will listen for connections on.
Configure the ciphersuite (encryption type) that SSL Relay will accept.
Configure the forwarding list (the port numbers and addresses that plugins can connect to).
You must also specify the server certificate you installed previously on the XenApp server, together with
the password you used to protect the private key.
Specifying the TCP Port that SSL Relay Listens On

You must specify the port that SSL Relay will listen for connections on. By default, SSL Relay listens on TCP
port 443, which is the standard port for SSL-secured communications.
You can configure SSL Relay to listen on a different port; for example, you may have to do this if there is
already a secure Web server (such as IIS) running on the server that uses port 443. However, ensure that
the port you choose is open on any firewalls between the Web server and the server running SSL Relay.
Note: Use TCP port 443 for SSL-secured communications, whenever possible. If you configure SSL Relay
to listen on a port other than 443, you must also configure the other parts of your installation
accordingly. Therefore, if you are using the Web Interface, you must configure the Web server to use a
port other than 443. For SSL-enabled plugins, you must configure each plugin, on a per-application basis,
to use the different port number.
Configuring the Ciphersuite
The process of establishing a secure connection involves negotiating the ciphersuite that will be used
during communications. A ciphersuite defines the encryption type that will be used; it defines the cipher
algorithm and its parameters, such as the size of the keys.
Negotiation of the ciphersuite involves the plugin telling SSL Relay the ciphersuites it is capable of handling,
and SSL Relay telling the plugin the ciphersuite that will be used during communication. Therefore, you
must configure SSL Relay to use the appropriate ciphersuite for your communications.
SSL Relay supports two main categories of ciphersuite: COM (commercial) and GOV (government). The ALL
option includes both the commercial and government suites, ordered such that commercial is given preference.
COM (commercial)the commercial ciphersuites are:
SSL_RSA_WITH_RC4_128_MD5 or {0x00,0x04}
SSL_RSA_WITH_RC4_128_SHA or {0x00,0x05}
GOV (government). Some organizations, including US government organizations, require the use
of government-approved cryptography to protect sensitive but unclassified data. The
government ciphersuite is:
SSL_RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}
Configuring the Forwarding List
When SSL Relay receives an SSL-secured connection, it decrypts the data and redirects the connection, usually
to the XenApp processes or to the Citrix XML Service.
By default, XenApp listens for ICA connections on port number 1494, and the XML Service communicates with
the Web Interface server on port number 80. Therefore, you must configure SSL Relay to permit redirection
to these ports (or to different port numbers you assigned to ICA and the XML Service), as shown in the
following diagram:
You can also configure SSL Relay to control which addresses plugins can connect to. For example, you may
want to restrict access to a particular set of addresses.
The ports and addresses you permit access to are known as the forwarding list for the TCP port.
Caution: Citrix recommend that you configure SSL Relay to restrict access to specific ports only. If,
instead, you configure SSL Relay to allow access to ports other than those used by ICA and the XML
Service, you may allow users to connect to SSL Relay and gain access to unauthorized ports on the server.
10.2.3.4.2.1. To configure SSL Relay ready for use
Updated: 2009-10-28
You use the ctxsslcfg command to configure SSL Relay.
1.
2.

ctxsslcfg -add port [ -certificate identifier ] [ -dbpassword db-password ] [ -ciphersuite { GOV
| COM | ALL } ] [ -forward { add | remove } { * | { hostname | IP-address | * }:{ port | * } } ]

Option
Use this option to:
-add
Add the port number that SSL Relay will listen for connections on. Specify the
port number using the port parameter. For example: -add 443 specifies
port number 443.
-certificate
Specify the server certificate to be used during secure communications.

This certificate must be installed on the server. Use the identifier parameter
to specify the certificate using the label you gave the certificate. For example
if you installed a certificate labelled citrix, type:
-certificate citrix.
-dbpassword
Specify the password with which the certificates private key is decrypted.
This password must match the password you specified using the db-password
parameter when you installed the certificate. For example, if you specified
a password of confidential when you installed the certificate, type: dbpassword confidential
If you do not include the -dbpassword option in the command, you are
prompted for a password.
-ciphersuite
Specify the ciphersuite that will be used during secure communications

COM, GOV or ALL. If you do not specify a ciphersuite, ALL is used by default.
-forward
Configure the forwarding list for this port number. The forwarding list defines
the port numbers (typically 1494 and 80) and addresses that SSL Relay
permits access to. Use the add parameter to specify that you are adding an
entry to the forwarding list. For example, on the server mandix to allow
access on ports 1494 and 80, type: -forward add mandix:1494 -forward
add mandix:80
You can use an * (asterisk) as a wildcard to mean all port numbers or
all addresses. However, because the asterisk represents zero or more
characters in UNIX, remember to include quotation marks. For example, to
allow access to all addresses on port 1494, type: -forward add *:1494
A single * (asterisk) is equivalent to specifying *:*. For example, to allow
access to all addresses and all ports, type: -forward add *
Do not use the term localhost as the hostname.
After you have configured SSL Relay ready for use, you are ready to start SSL Relay on the XenApp server; see
To start the SSL Relay for more information.
Example
On the server radish, you want to configure the SSL Relay to listen for connections on port 443, using
the identity certificate labelled citrix, and to allow access to ports 1494 and 80. Type:
ctxsslcfg -add 443 -certificate citrix -forward add radish:1494 -forward add radish:80
Because no password is specified, you are prompted for one. And, since no ciphersuite is specified, the default of
ALL is used (the ALL suite includes both commercial and government suites, ordered such that commercial
is given preference).
10.2.3.4.3. To start the SSL Relay
Updated: 2009-10-28
To start SSL Relay on a XenApp for UNIX server, use the ctxsrv start command.
1.
2.

ctxsrv start sslrelay
SSL Relay runs as a daemon on the XenApp for UNIX server. In future, when XenApp is started on the server,
the SSL Relay daemon also starts automatically.
10.2.3.4.4. To stop the SSL Relay
Updated: 2009-10-28
Use the ctxsrv stop command to stop SSL Relay on a XenApp for UNIX server.
1.
2.

ctxsrv stop sslrelay
If all the XenApp processes are stopped on the server using ctxsrv stop all, the SSL Relay daemon also stops.
10.2.3.4.5. Displaying a TCP Ports Configuration
Using the ctxsslcfg -list command, you can display summary information about all the TCP ports configured
for incoming SSL Relay connections on a XenApp server, or information about a particular TCP ports configuration.
10.2.3.4.5.1. To display summary information for all the ports
1.
2.

ctxsslcfg -list
10.2.3.4.5.2. To display a particular ports configuration

1.
2.

ctxsslcfg -list port
where port is the port number you want to display details for.
10.2.3.4.6. Changing the SSL Relay Configuration

You can change the configuration of SSL Relay on a server using the ctxsslcfg command. You can add,
edit, move, copy, and remove a TCP ports configuration, or change a ports forwarding list. You can also
update the server certificate or change the ciphersuite.
Important: You must stop and restart SSL Relay using the ctxsrv stop sslrelay and ctxsrv start sslrelay
command for these changes to take effect.
10.2.3.4.6.1. To add a new TCP port
Updated: 2009-10-28
You can add a new TCP port to the list of ports on which SSL Relay listens for incoming connections.
1.
2.

ctxsslcfg -add port [ -certificate identifier ] [ -dbpassword db-password ] [ -ciphersuite { GOV
| COM | ALL } ] [ -forward { add | remove } { * | { hostname | IP-address | * }:{ port | * } } ]
3.
Stop and restart SSL Relay.
For more information about the options and parameters, see To configure SSL Relay ready for use.
10.2.3.4.6.2. To edit a ports configuration
Updated: 2009-10-28
You can edit a particular TCP ports configuration, or the configuration of every TCP port that listens for
SSL connections, using the ctxsslcfg -edit command.
1.
2.
Do one of the folowing:

To edit a particular port's configuration, at the command prompt type:
ctxsslcfg -edit port [ -certificate identifier ] [ -dbpassword db-password ] [ -ciphersuite
{ GOV | COM | ALL } ] [ -forward { add | remove } { * | { hostname | IP-address | * }:{
port | * } } -force ]
where:
port is the port number of the TCP port you want to edit.
-force disconnects any existing connections that are illegal as a result of your changes.
To edit the configuration of all ports, at the command prompt type:
ctxsslcfg -edit all [ -certificate identifier ] [ -dbpassword db-password ] [ -ciphersuite
{ GOV | COM | ALL } ] [ -forward { add | remove } { * | { hostname | IP-address | * }:{
port | * } } -force ]
For more information about the options and parameters, see To configure SSL Relay ready for use.
3.
10.2.3.4.6.3. To move a ports configuration

Updated: 2009-10-27
You can move an existing ports configuration to another port on the XenApp server.
For example, if you decide to install a secure Web server on port 443, you must move the SSL Relay port
to another port.
1.
2.

ctxsslcfg -move old_port new_port
where:
old_port is the port number containing the configuration you want to move.
new_port is the new port number you want to move the configuration to.
3.
Example
To move the configuration for TCP port 443 to port 444, type:
ctxsslcfg -move 443 444
10.2.3.4.6.4. To copy a ports configuration
Updated: 2009-10-27
You can copy an existing ports configuration to another port on the server.
1.
2.

ctxsslcfg -copy old_port new_port
where:
old_port is the port number containing the configuration you want to copy.
new_port is the new port number you want to copy the configuration to.
3.
Example
To copy the configuration for TCP port 444 to port 443, type:
ctxsslcfg -copy 444 443
10.2.3.4.6.5. To remove a ports configuration
Updated: 2009-10-27
You can delete a ports configuration on the server.

1.
2.

ctxsslcfg -remove port
where:
port is the port number you want to delete.
3.
Example
To remove TCP port 443s configuration, type:
ctxsslcfg -remove 443
10.2.3.4.7. Managing Your Server Certificates
This section describes how to display information about the server certificates installed on a XenApp server,
how to export a server certificate to another server, and how to remove a certificate.
10.2.3.4.7.1. To display server certificate information
Updated: 2009-10-28
You can display information about the server certificates stored on a XenApp server using the
ctxcertmgr command. Only non-encrypted information is displayed, such as the certificates expiry date.
The private key is never displayed.
1.
2.

ctxcertmgr -list
About Start and Expiry Dates

Each server certificate issued by a CA includes a period of validity field. The period of validity includes a:
not before time. This is the certificates start dateuntil this period is reached, the certificate is
considered invalid.
not after time. This is the certificates expiry dateafter this period, the certificate is considered invalid.
10.2.3.4.7.2. To export a certificate to another server

Updated: 2009-10-29
You can export a copy of a server certificate to another XenApp server using the ctxcertmgr command.
For example, you want to replace an existing server running SSL Relay with a new machine. You install
XenApp on the new machine. However, to enable SSL Relay on the new machine, you must export the
server certificate from the old machine onto the new machine. To do this, you use the ctxcertmgr command
to export the certificate to a file. Then, you use the ctxcertmgr command to import the certificate from this
file to the new server.
Passwords are used to protect the certificate at each stage of the transfer.
1.
Log on as the ctxssl user to the server where the certificate is currently installed.
2.
To export a certificate to a file, at the command prompt, type:

ctxcertmgr -export identifier -filename filename [-format { PEM | DER} ] [ -keyfilename
key-filename ] [ -dbpassword db-password ] [ -filepassword file-password ]
Option
Use this option:
-export
To export a certificate. The identifier parameter is the label you

assigned the certificate when you installed it.
-filename
To specify the name of the file that you want to export the certificate to.
To export the certificate as two separate files (one file containing
the private key; the other containing plaintext information about
the certificate) use the -filename option to specify the name of the
file containing plaintext information.
-format
-keyfilename
To specify the format of the export file. For export, files must be in PEM
or DER format. If you do not specify a format, the certificate is exported
in PEM format.
To export the certificate as two separate files (one file containing
the private key; the other containing plaintext information). Use the
key-filename parameter to specify the name of the file containing
the private key. Note that, in this case, you would use the -filename
option to specify the name of the file containing plaintext information.
If you export the certificate in PEM format, you can export to a single
file or to two separate files, therefore -keyfilename is optional. If
you export the certificate in DER format, you must export to two
separate files, therefore -keyfilename is a required option.
-dbpassword
To specify the password that currently protects the certificate. If

you include the -dbpassword option, use the db-password parameter
to specify the password. If you do not include the -dbpassword option,
you are prompted for a password.
-filepassword
To specify a new password to protect the file. If you include the

-filepassword option, use the file-password parameter to specify
the password. If you do not include the -filepassword option, you
are prompted for a password.

3.
To import a certificate to a new server (from the file that you exported the certificate to) at the
command prompt, type:
ctxcertmgr -import identifier -filename filename [-format format ] [ -keyfilename key-filename ]
where:
filename is the file that you exported the certificate to.
You are prompted for:
file-password which is the password that protects the file.
db-password which is the new password that will protect the certificate.
For more information about importing certificates, and for a full description of the options, see Installing
a Server Certificate on a Server.
Example
You want to export a server certificate that has the identifier Citrix to another XenApp server. You export
the certificate to a file called citrix_systems.pem. The certificate is currently protected on the server using
the password cabbage. You use the new password broccoli to protect the file.
To export the certificate, type:
ctxcertmgr -export Citrix -format pem -filename citrix_systems.pem
You are prompted for the db-password cabbage and file-password broccoli.
Next, you import the certificate from the citrix_systems.pem file to the new server. You use the new
password carrot to protect the file. Type:
ctxcertmgr -import Citrix -format pem -filename citrix_systems.pem
You are prompted for the file-password broccoli and db-password carrot.
The following diagram shows the use of the db-password and file-password:
10.2.3.4.7.3. To remove a stored certificate

Updated: 2009-10-27
You can delete a certificate from a XenApp server using the ctxcertmgr command.
1.
2.

ctxcertmgr -remove identifier
where identifier is the label you assigned the certificate when you installed it.
Example
To remove a server certificate that has the identifier Citrix, type:
ctxcertmgr -remove Citrix

10.2.3.5. SSL Relay Command Reference
Updated: 2009-11-13
This section describes the Citrix XenApp SSL Relay for UNIX command-line utilities. The commands listed in
this section are:
ctxcertmgr Install and manage server certificates
ctxcertreq Generate a new certificate request file or a certificate renewal request file
ctxsslcfg Configure SSL Relay
Note: For information about the ctxsrv command, see the Citrix XenApp for UNIX Administrators Guide.
10.2.3.5.1. ctxcertmgr
Updated: 2009-10-27
Description
ctxcertmgr manages server certificates.
Using ctxcertmgr you can add server certificates on a XenApp server. You can also display information
about certificates, export a certificate to another server, and remove a certificate.
Syntax
ctxcertmgr
[ -server | -root ] { -import identifier | -export identifier } -filename

filename [ -format format ] [ -keyfilename key-filename ] [ -dbpassword
db-password ] [ -filepassword file-password ]
ctxcertmgr
[ -server ] -response filename [ -dbpassword db-password ]
ctxcertmgr
[ -server | -root ] -list
ctxcertmgr
[ -server | -root ] -remove identifier
Options
-server
Specifies that the certificate is a server certificate. This is the default.
-root
Specifies that the certificate is a root certificate. SSL Relay does not require
root certificates to be installed on the server. However, if you want to
use ctxcertmgr to maintain a store of root certificates, use the -root option.
-import
Adds a certificate and its private key to the server.
-export
Exports a certificate and its private key to a file.
-filename
If you are adding a certificate to the server using the -response option, use the
-filename option to specify the signed certificate file supplied by the CA.
If you are adding a certificate to the server using the -import option, use the
-filename option to specify the certificate file supplied by the CA, and use the
-keyfilename option to specify the file containing the private key.
If you are exporting a copy of a certificate to another server using the -export
option, use the -filename option to specify the file that you want to export
the certificate to.
-format
Specify the format of the certificate file.

If you are adding a certificate to the server using the -import option, and you
do not specify a format, the system attempts to auto-detect the format; if it
cannot detect the format, an error message is displayed.

If you are exporting a certificate to file using the -export option, the format
must be PEM or DER. Note that every format, except PEM and DER, requires
the private key and the server certificate to be in the one file. With PEM format,
the private key and server certificate can be in one file or in separate files.
With DER format, the private key and server certificate must be in separate files.
-keyfilename
If you are adding a certificate to the server using the -import option, and the
CA supplies the certificate as two separate files (one file containing the private
key; the other containing plaintext information about the certificate) use the
-keyfilename option to specify the file containing the private key. Note that,
in this case, you would use the -filename option to specify the file containing
the certificate information.
If you are exporting a certificate to file using the -export option, use the
-keyfilename option to export the certificate as two separate files (one
file containing the private key; the other containing certificate information).
Use the key-filename parameter to specify the name of the file containing
the private key. Note that, in this case, you would use the -filename option
to specify the name of the file containing plaintext information.
-dbpassword
Use this option if you are including the ctxcertmgr command in a shell
script; otherwise you are prompted for the password.
If you are adding a certificate to the server using the -import option, use
this option to specify the new password that you will use to protect the certificate.
If you are exporting a certificate to file using the -export option, use this option
to specify the password you used to protect the certificate.
If you are installing a certificate using the -response option, use this option
to specify the database password you supplied when you ran ctxcertreq.
If you include the -dbpassword option, you must use the db-password
parameter to specify the password.
-filepassword
If you are adding a certificate to the server using the -import option, use
this option to specify the password that the CA used to protect the file.
The certificate management software may have supplied this password in
a separate email.
If you are exporting a certificate to file using the -export option, use this option
to specify a new password to protect the file.
If you include the -filepassword option, you must use the file-password
parameter to specify the password.
-response
Indicates the certificate is a response to a certificate request generated

using ctxcertreq.
-list
Displays information about the server certificates stored on the server. Only
non-confidential information is displayed, such as the certificates expiry date.
The private key is never displayed.
-remove
Removes a certificate from the server.
Parameters
identifier
A unique label you give your certificate. This label can be used to easily identify
the certificate in future.
filename
The name of the file you are importing from or exporting to.
format
The format of the certificate filePEM, NET, DER, PKCS12, and MKS formats
are supported if you are importing a certificate; PEM and DER formats
are supported if you are exporting a certificate.
key-filename
The file containing the private key.
db-password
The new password used to protect the certificate while it is installed on the server.
file-password
The password you used to protect the file, or a new password you want to use
to protect the file, depending upon whether you are importing or exporting
a certificate.
Remarks
You must be the ctxssl user to run this command.
10.2.3.5.2. ctxcertreq
Updated: 2009-10-27
Description
ctxcertreq generates a certificate request file.
Using ctxcertreq you can create a Certificate Signing Request (CSR) file that you can send to a CA. You can
create a CSR file for a new certificate, or for a certificate that you want to renew.
ctxcertreq prompts you for the distinguished name of the subject requesting the certificate (in this case,
the XenApp server), and a database password that will be used to protect the private key.
Syntax
ctxcertreq
identifier [ -filename filename ] [ -clone clone-identifier

]
Options
-filename
The file the CSR is written to. If you do not include this option, the CSR is written to
identifier.req in the current directory, where identifier is the unique label you
give the certificate.
-clone
Use this option to generate a CSR based upon an existing certificate. The
existing certificate is used as a template for the CSR. This is useful when you
want to create a number of similar CSRs, or renew an existing certificate.
At the prompts, the distinguished name information defaults to the
information contained in the existing certificate. Press Enter to accept the
defaults, or change the information as required. Remember to change the
Common Name for each server.
Parameters
identifier
A unique label you give the certificate to easily identify it in future. This label is
used by the SSL Relay tools and is not included in the CSR file that you send to
the CA.
filename
The name of the file you are writing the CSR to.
clone-identifier
The identifier of the existing server certificate.
Remarks
10.2.3.5.3. ctxsslcfg
Updated: 2009-10-27
Description
ctxsslcfg configures SSL Relay.
Using ctxsslcfg you can specify a TCP port that SSL Relay listens for connections on, configure the ciphersuite
that SSL Relay will use, and specify the TCP ports forwarding list.
You cannot make changes to SSL Relay dynamically. You must stop and restart SSL Relay for any changes to
take effect. You must be the ctxssl user to run this command.
Syntax
ctxsslcfg
-add port [ -certificate identifier ] [ -dbpassword db-password ] [

-ciphersuite { GOV | COM | ALL } ] [ -forward add { * | { hostname |
IP-address | * }:{ port | * } } ]
ctxsslcfg
-edit { port | all } [ -certificate identifier ] [ -dbpassword db-password ] [

-ciphersuite { GOV | COM | ALL } ] [ -forward { add | remove } { * | {
hostname | IP-address | * }:{ port | * } } ]
ctxsslcfg
-move old-port new-port
ctxsslcfg
-copy old-port new-port
ctxsslcfg
-remove port
ctxsslcfg
-list [ port ]
Options
-add
Adds a port that SSL Relay will listen for connections on.
-certificate
Specifies the server certificate to be used during secure communications.

This certificate must be installed on the XenApp server using the
ctxcertmgr command.
-dbpassword
Specifies the password with which the certificates private key is decrypted.
-dbpassword is optional; if you do not include it, you are prompted for a password.
-ciphersuite
Specifies the ciphersuite that will be used during secure communicationsCOM, GOV
, or ALL. If you do not specify a ciphersuite, ALL is used by default.
-forward
Specifies a TCP ports forwarding list. The forwarding list defines the port
numbers and addresses that SSL Relay permits access to.
-edit
Edits a particular TCP ports SSL Relay configuration, or the SSL Relay
configuration of every TCP port that listens for SSL connections.
-move
Moves an existing ports configuration to another port on the server.
-copy
Copies an existing ports configuration to another port on the server.
-remove
Removes a ports configuration from the server.
-list
Displays summary information about all the TCP ports configured for incoming
SSL Relay connections on a server. Specify a TCP port number to display
information about a particular TCP ports configuration.
Parameters
port
TCP port number.
identifier
Specifies the certificate using the unique label you gave the certificate when it
was added using the ctxcertmgr command.
db-password
The password that decrypts the certificates private key. This is the password
you specified when you installed the certificate.
GOV
The government ciphersuite: SSL_RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}
COM
The commercial ciphersuites: - SSL_RSA_WITH_RC4_128_MD5 or {0x00,0x04}

- SSL_RSA_WITH_RC4_128_SHA or {0x00,0x05}
ALL
Both the commercial and government suites, ordered such that commercial is
given preference.
add
Specifies that you are adding an entry to the forwarding list.
remove
Specifies that you are removing an entry from the forwarding list.
An * (asterisk) can be used as a wildcard to mean all port numbers or all

addresses. However, because the asterisk represents zero or more characters
in UNIX, remember to include quotation marks. For example, to allow access to
all addresses on port 1494, type: -forward add *:1494
A single * (asterisk) is equivalent to specifying *:*
hostname
The hostname of the server that you are permitting access to; in other words,
the server SSL Relay is running on.
IP-address
The IP address of the server that you are permitting access to.
all
All ports configured for incoming SSL Relay connections.
old-port
TCP port number of an existing port that you want to copy or move.
new-port
The new TCP port number that you want to create using an existing port
s configuration.
Remarks
You must stop and restart SSL Relay for any changes to take effect.
10.2.3.6. Glossary
Updated: 2009-10-27
asymmetric cryptography
See public key cryptography.
authentication
A security service that verifies the identity of a communicating party.
Baltimore
An organization which operates a public Certification Authority. Support for Baltimore root certificates
is already built into SSL-enabled plugins and the server running the Web Interface.
CA
See certificate authority.
certificate
A digital file issued by a certificate authority. A certificate acts as a proof of identity.
certificate authority
A trusted organization that issues certificates.
certificate hierarchy
In a certificate hierarchy, a CA designates one or more subordinates who in turn can designate
further subordinates. The lowest subordinates in the hierarchy certify the end users.
certificate revocation list

A list distributed by a CA of certificates that can no longer be trusted.
certificate signing request
A file that is sent to a CA for verification and signing. You can create a CSR file for a new certificate, or
for a certificate that you want to renew.
cipher
A secret code used to scramble a message so that the message cannot be understood by parties other
than the sender and the receiver.
cipher algorithm
A set of cryptographic options.
ciphersuite
A cipher algorithm and the parameters to be used, such as the size of the keys.
Citrix SecureICA Services
The Citrix management product that provides end-to-end encryption of business-critical data
and applications.
confidentiality
A security service that protects data from being read or copied by an unauthorized user.
CRL
See certificate revocation list.
cryptography
The practise of encoding messages to ensure confidentiality.
CSR
See certificate signing request.
ctxcertreq
A command line tool for generating a certificate request file that can be sent to a CA. You can
use ctxcertreq to create a request for a new certificate, or a request to renew a certificate that is about
to expire.
ctxcertmgr
A command line tool for managing certificates.
ctxsrv
A command-line tool for starting up or stopping the server processes on a XenApp for UNIX server.
ctxsrvr
Default member of the Citrix server administrator group.
ctxssl
A special user account for SSL Relay administration. The ctxssl user is part of the Citrix
server administrator group account ctxadm. Only the ctxssl user can run the SSL Relay commands
and access the SSL Relay directories and files.
ctxsslcfg
A command line tool for configuring SSL Relay.
daemon
A UNIX process that runs in the background for a specific purpose.
denial of service
A security attack in which access to a system or application is prevented or interrupted.
distinguished name
A field in a digital certificate that identifies the issuer of the certificate or the subject of the certificate
(such as a XenApp server).
forwarding list
The port numbers and addresses that you permit SSL Relay to redirect to.
hash function
A mathematical representation of information, similar to the checksums found in communication protocols.
identity certificate
A certificate that identifies a subject. There are different types of identity certificate, the most common
of which are server certificates and client certificates.
IDS
Intrusion Detection System.
IETF
Internet Engineering Task Force. This organization develop Internet protocol standards.
IIS
Internet Information Server. The Web server built into Microsoft Windows.
integrity
A security service that prevents a message from being modified during its transmission.
IPSec
IP Security. IPSec provides secure communications between the Web server and the XenApp server.
IPSec is a standard feature of Microsoft Windows.
issuer
The organization that issued the certificate.
MKS
Microsoft Key Storage. A supported certificate file format.
pass-phrase
A long password used to encrypt the private key.
PEM
Privacy Enhanced Mail. A standard for secure email on the Internet. The PEM format is supported by
SSL Relay for certificate files.
period of validity
A field contained in the digital certificate. The period of validity includes the certificates start date
and expiry date.
plaintext
Non-encrypted information.
private keys
One of the keys used in public key cryptography. The private key must be kept secret.
public keys
One of the keys used in public key cryptography. The public key can be distributed without
compromising security.
public key cryptography
A type of cryptography in which one key is used to scramble the message and another key is used
to unscramble it. There are always two keys: a public key and a private key. Messages scrambled with
one key can only be unscrambled using the other key. Public key cryptography is also known also
as Asymmetric Key Cryptography.
root certificate
A type of certificate that identifies the CA that signed the server certificate.
secret key cryptography
A type of cryptography in which both the sender and the receiver know the same secret key. Messages
are scrambled by the sender using the secret key, and unscrambled by the receiver using the same
secret key. Secret key cryptography is also known as Symmetric Key Cryptography.
SecureICA Services
See Citrix SecureICA Services.
server certificate
A type of identity certificate that identifies a specific machine; for example, a XenApp for UNIX server.
session key
A cryptographic key used for communication between two parties. The session key is valid for the
one session only.
SSL
Secure Sockets Layer.
SSL Relay
A Citrix product that provides the ability to secure data communications using the SSL protocol.
SSL provides server authentication, encryption of the data stream, and message integrity checks.
symmetric key cryptography
See secret key cryptography.
VeriSign
A public Certificate Authority that provides certificates for public key users. Support for VeriSign
root certificates is already built into SSL-enabled plugins and the server running the Web Interface.
Web Interface
The Web Interface is an application portal technology that provides organizations with the ability
to integrate and publish interactive applications into any standard Web browser. The Web Interface is
a three-tier solution that includes a XenApp server, a Web server, and a client device with a Web browser.
XML Service
The Citrix XML Service communicates information about the applications published in a server farm to
the Web server component of the Web Interface deployment. The XML Service for UNIX runs as a
daemon on the servers in a server farm.

Xenapp PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Xenapp PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Citrix

eDocs product documentation library

8.5.6.1.1. Connecting to the Data Store

8.7.1.6. Enabling Citrix Administrators to Manage Farms Remotely

8.7.4.8. Configuring Policies and Filters for Web Access

8.7.6.2. Securing the Data Store

8.7.7.13. Removing and Reinstalling XenApp

8.7.9.1. Configuring Printing

8.7.11.3.1.2. Drives Folder

8.8.2.5.8. To specify pre-launch and post-exit scripts

8.8.4.2.4. To configure an .MSI package using transforms

8.11.1. Citrix XenApp Components That Work with Secure Gateway

8.11.6.5. Preventing Indexing by Search Engines

8.12.12. To specify where recordings are stored

9.2.3.1. How the Components in Sample Deployment C Interact

10.2.2.2.10. What to Do Next

10.2.2.6.9.3. Printing from Applications

10.2.2.8.3.3.2. Configuring the ICA Browser

10.2.3.4.5.1. To display summary information for all the ports

SmartAccess powered by Citrix Access Gateway

EasyCall voice services

Service Monitoring (EdgeSight)

Load testing services

Power and Capacity Management

Workflow Studio orchestration

Designing a XenApp Deployment

System Requirements for XenApp 6 for

Enhancing the User Experience With HDX

Readme for Citrix Online Plug-in 12 for Windows

Readme for Citrix Offline Plug-in 6 and

Issues Fixed in the Offline Plug-in 6 for

Other XenApp Features

SmartAccess powered by Citrix Access Gateway

EasyCall voice services

Load testing services

Power and Capacity Management

XenApp Connector for Configuration Manager 2007 R2

XenApp Printing Optimization Pack

Service Monitoring (EdgeSight)

XenApp 6 Migration Tool

Workflow Studio orchestration

HDX Plug-n-Play for USB storage devices

HDX IntelliCache for XenApp optimization over WAN

Online Plug-in for Windows 12.0.x

Licensing Your Product

Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6

Other XenApp Features

Service Monitoring (EdgeSight)

EasyCall voice services

Load testing services

Workflow Studio orchestration

SmartAccess powered by Citrix Access Gateway

SmartAccess powered by Citrix Access Gateway

EasyCall voice services

Service Monitoring (EdgeSight)

Load testing services

Workflow Studio orchestration

5. XenApp 5 for Windows Server 2008

New Features, Capabilities, and Changes in the XenApp

Readme for Citrix XenApp 5.0 for Windows

New Features and Changes in XenApp 5

Readme for Citrix Offline Plug-in 5.2 and

Compare Features of XenApp Product Editions