You are on page 1of 510

Citrix

eDocs product documentation library
http://edocs.citrix.com
©2011, Citrix Systems, Inc. All rights reserved.
XenApp 6 for Windows Server 2008 R2
Contents
1. Readme for XenApp for Windows Server 2008 R2
2. System Requirements for XenApp 6 for Windows Server 2008 R2
3. Designing a XenApp Deployment
3.1. Farm Terminology and Concepts
3.2. Planning a Successful User Experience
3.3. Farm Hardware Considerations
3.4. Planning for Applications and Server Loads
3.4.1. Assessing Applications for XenApp Compatibility
3.4.2. Evaluating Application Delivery Methods
3.4.3. Planning for Application Streaming
3.4.4. Placing Applications on Servers
3.5. Determining the Number of XenApp Servers to Deploy
3.6. Deciding How Many Farms to Deploy
3.7. Planning Controllers
3.7.1. Planning the XenApp Data Store
3.7.1.1. Database Server Hardware Performance Considerations
3.7.1.2. Replication Considerations
3.7.1.3. Planning for Configuration Logging and IMA Encryption
3.7.2. Planning for Data Collectors
3.7.3. Designing Zones for a XenApp Deployment
3.7.4. Planning for the Web Interface and XML Broker
3.8. Planning for Accounts and Trust Relationships
3.9. Recommendations for Active Directory Environments
3.10. Planning for System Monitoring and Maintenance
3.11. Planning for UAC
3.12. Planning for Shadowing
3.13. Securing Delivery and Access
3.14. Planning for Supported Languages and Windows MUI Support
3.15. Planning for Passthrough Client Authentication
4. Installing and Configuring XenApp
4.1. Preparing to Install and Configure XenApp
4.2. Installing XenApp Using the Wizard-Based Server Role Manager
4.3. Installing XenApp from the Command Line
4.4. Configuring XenApp Using the Wizard-based Server Configuration Tool
4.5. Configuring XenApp from the Command Line
4.5.1. Command Syntax
4.6. Preparing for XenApp 6 Imaging and Provisioning
4.7. Data Store Database Reference
4.7.1. Microsoft SQL Server Database
4.7.2. Oracle Database
5. XenApp 6 Migration Tool
5.1. Requirements and Installation
5.2. Using the XenApp 6 Migration Tool Cmdlets
5.3. Cmdlet Reference
5.4. Advanced Cmdlets
6. Administration
6.1. Management Consoles and Other Tools
6.1.1. To start the console and discover servers
6.1.2. To view zones
6.1.3. To refresh user data automatically
6.2. Managing Citrix Administrators
6.2.1. Delegating Tasks to Custom Administrators
6.3. Publishing Resources
6.3.1. Publishing Resources for Users
6.3.1.1. To configure servers to publish for multiple users
6.3.1.2. To publish a resource using the Publish Application wizard
6.3.1.3. Publishing App-V Sequences in XenApp
6.3.1.4. To select a resource type and delivery method
6.3.1.5. To configure locations of published applications
6.3.1.6. To configure locations of published content
6.3.1.7. To disable command-line validation
6.3.2. Managing Streamed Applications
6.3.2.1. Publishing Streamed Applications
6.3.2.2. To select a streaming delivery method
6.3.2.3. To force a delivery method for streamed applications
6.3.2.4. To provide HTTP or HTTPS delivery method
6.3.2.5. Configuring Offline Access
6.3.3. Configuring Content Redirection
6.3.3.1. To enable content redirection from server to client
6.3.3.2. To configure content redirection from client to server
6.3.4. Managing Application Properties
6.3.4.1. To rename a published application
6.3.4.2. To configure locations of servers for published resources
6.3.4.3. To specify locations of applications for streaming
6.3.4.4. To enable an application for offline access
6.3.4.5. To configure user access to applications
6.3.4.6. Granting Access to Explicit or Anonymous Users
6.3.4.7. To configure shortcuts for user devices
6.3.4.8. To configure access controlled by the Access Gateway
6.3.4.9. To associate published applications with file types
6.3.4.10. To update file type associations
6.3.4.11. To configure alternate profiles
6.3.4.12. To pass parameters to published applications
6.3.4.13. To reduce user privileges for a streamed application
6.3.4.14. To configure application limits and importance
6.3.4.15. To configure audio and encryption options for published applications
6.3.4.16. To configure application appearance
6.3.4.17. To disable or enable a published application
6.3.4.18. To delete a published application
6.3.4.19. To move a published application to another folder
6.3.4.20. To duplicate published application settings
6.3.4.21. To export published application settings to a file
6.3.4.22. To import published application settings from a file
6.3.5. Making Virtual IP Addresses Available to Applications
6.3.5.1. How Virtual IP Addressing Works
6.3.5.2. Binding Applications
6.3.5.3. To determine whether an application needs to use virtual IP addresses
6.3.5.4. To make virtual IP addresses available to applications running in sessions
6.3.5.5. To make a virtual loopback address available to applications running in sessions
6.3.5.6. To supply client IP addresses to published applications on a server
6.4. Working with Citrix Policies
6.4.1. Navigating Citrix Policies and Settings
6.4.2. Creating Citrix Policies
6.4.3. Configuring Policy Settings
6.4.3.1. To add settings to a policy
6.4.4. Applying Policies
6.4.4.1. To apply a policy
6.4.5. Using Multiple Policies
6.4.5.1. Prioritizing Policies and Creating Exceptions
6.4.6. Determining Which Policies Apply to a Connection
6.4.6.1. To simulate connection scenarios with Citrix policies
6.4.6.2. Troubleshooting Policies With No Configured Settings
6.4.7. Applying Policies to Access Gateway Connections
6.4.8. Enabling Scanners and Other TWAIN Devices
6.5. Managing Session Environments and Connections
6.5.1. Defining User Environments in XenApp
6.5.1.1. Controlling the Appearance of User Logons
6.5.1.2. Controlling Access to Devices and Ports
6.5.1.2.1. To enable user execute permissions on mapped drives
6.5.1.3. Displaying Local Special Folders in Sessions
6.5.1.4. Configuring Audio for User Sessions
6.5.1.4.1. To enable or disable audio for published applications
6.5.1.4.2. To configure bandwidth limits for audio
6.5.1.4.3. To configure audio compression and output quality
6.5.1.4.4. To enable support for microphones and speakers
6.5.1.4.5. To use and set sound quality for digital dictation devices
6.5.1.5. Ensuring Session Continuity for Mobile Workers
6.5.1.6. Maintaining Session Activity
6.5.1.6.1. Configuring Session Reliability
6.5.1.6.2. Configuring Automatic Client Reconnection
6.5.1.6.3. Configuring ICA Keep-Alive
6.5.2. Managing and Monitoring XenApp Sessions
6.5.2.1. Monitoring Session Information
6.5.2.2. Viewing User Sessions
6.5.2.2.1. Viewing User Sessions with the Shadow Taskbar
6.5.2.2.2. Enabling Logging for Shadowing
6.5.2.2.3. Enabling User-to-User Shadowing with Policies
6.5.3. Controlling Client Connections in XenApp
6.5.3.1. Preventing Specific Client Connection Types
6.5.3.2. Specifying Connection Limits
6.5.3.2.1. Limiting Connections to a Server Farm
6.5.3.2.2. Sharing Sessions and Connections
6.5.3.2.3. Limiting Application Instances
6.5.3.2.4. Logging Connection Denial Events
6.5.3.3. Configuring the ICA Listener
6.5.3.4. Preventing User Connections During Farm Maintenance
6.5.4. Optimizing User Sessions for XenApp
6.5.4.1. Optimizing Audio and Video Playback
6.5.4.1.1. Configuring HDX MediaStream Multimedia Acceleration
6.5.4.2. Optimizing Flash Content
6.5.4.3. Optimizing Throughput of Image Files
6.5.4.4. Optimizing Display of Image Files
6.5.4.5. Optimizing Keyboard and Mouse Responsiveness
6.5.4.5.1. Configuring SpeedScreen Latency Reduction
6.5.4.5.2. Adjusting SpeedScreen Latency Reduction for an Application
6.5.4.5.3. To configure latency reduction settings for input fields in an application
6.5.4.5.4. To create exception entries for non-standard input fields in an application
6.5.4.6. Configuring HDX Broadcast Display Settings
6.6. Securing Server Farms
6.6.1. Securing Access to Your Servers
6.6.2. Securing the Data Store
6.6.3. Securing Client-Server Communications
6.6.3.1. Using SecureICA
6.6.3.2. Enabling SSL/TLS Protocols
6.6.3.3. To configure session data encryption
6.6.3.4. To set a policy for ICA encryption
6.6.4. Configuring SSL/TLS Between Servers and Clients
6.6.4.1. Obtaining and Installing Server and Root SSL Certificates
6.6.4.2. Choosing an SSL Certificate Authority
6.6.4.3. Acquiring a Signed SSL Certificate and Password
6.6.4.4. To enable the SSL Relay and select the relay credentials
6.6.4.5. Using the SSL Relay with the Microsoft Internet Information Service (IIS)
6.6.4.6. Configuring the Relay Port and Server Connection Settings
6.6.4.7. To run the SSL Relay on port 443 without using HTTPS
6.6.4.8. Configuring the Ciphersuites Allowed by the SSL Relay
6.6.5. Using the Secure Gateway
6.6.6. Using the Secure Ticket Authority
6.6.7. Securing Network Communications
6.6.7.1. Configuring TCP Ports
6.6.7.2. Using Proxy Servers
6.6.7.3. Configuring Authentication for Workspace Control
6.6.8. Using Smart Cards with XenApp
6.6.9. Configuring Kerberos Logon
6.6.10. Logging Administrative Changes to a XenApp Farm
6.6.10.1. Setting up the Configuration Logging Database
6.6.10.2. Defining Database Permissions for Configuration Logging
6.6.10.3. To configure the connection to the Configuration Logging database
6.6.10.4. To set Configuration Logging properties
6.6.10.5. Clearing Entries from the Configuration Logging Database
6.6.10.6. Encrypting Configuration Logging Data
6.6.10.6.1. To generate a key and enable IMA encryption on the first server in a farm
6.6.10.6.2. To load a key on servers that join the farm
6.6.10.6.3. Managing IMA Encryption
6.6.11. XenApp Service Account Privileges
6.7. Maintaining Server Farms
6.7.1. To search for objects in your farm
6.7.2. To change a server's desktop settings
6.7.3. To limit the number of server connections per user
6.7.4. To disable and re-enable server logons
6.7.5. Restarting Servers at Scheduled Times
6.7.6. Removing and Reinstalling XenApp
6.7.6.1. To move or remove a server
6.7.6.2. To rename a XenApp server
6.7.7. Monitoring Server Performance with Health Monitoring & Recovery
6.7.7.1. Modifying Health Monitoring and Recovery Actions
6.7.7.2. Developing Custom Health Monitoring & Recovery Tests
6.7.8. Using Citrix Performance Monitoring Counters
6.7.9. Using Worker Groups for Enhanced Resource Access
6.7.9.1. To create a worker group
6.7.9.2. Creating and Prioritizing Load Balancing Policies
6.7.9.3. Enhancing the Performance of a Remote Group of Servers
6.7.10. Using Preferential Load Balancing
6.7.10.1. Resource Allotment
6.7.10.2. Multiple Published Applications in the Same Session
6.7.11. Managing CPU Usage
6.7.12. Deploying virtual memory optimization
6.7.13. Managing Farm Infrastructure
6.7.13.1. Maintaining the Local Host Cache
6.7.13.2. Tuning Local Host Cache Synchronization
6.7.13.3. To configure zones and back-up data collectors
6.7.14. Updating Citrix License Server Settings
6.7.15. To set the product edition
6.7.16. Configuring the Citrix XML Service Port and Trust
6.7.16.1. To manually change the XML Service port to use a port different from IIS after installation
6.7.16.2. To manually configure Citrix XML Service to share the TCP port with IIS
6.8. Understanding XenApp Printing
6.8.1. Introduction to Windows Printing Concepts
6.8.1.1. Local and Remote Print Job Spooling
6.8.2. XenApp Printing Concepts
6.8.2.1. Overview of Client and Network Printing Pathways
6.8.2.2. Provisioning Printers for Sessions
6.8.2.2.1. Auto-Creating Client Printers
6.8.2.2.2. Auto-Creating Network Printers
6.8.2.2.3. Letting Users Provision Their Own Printers
6.8.2.3. Device or Session-Based Print Settings
6.8.2.3.1. Device-Based Print Settings
6.8.2.3.2. Controlling Printing Settings and User Preferences
6.8.2.4. Setting Default Printers
6.8.2.5. Printing and Mobile Workers
6.8.2.6. Optimizing Printing Performance by Routing
6.8.2.7. Managing Printer Drivers
6.8.3. Planning Your Printing Configuration
6.8.3.1. Default Printing Behavior
6.8.3.2. Printing Policy Configuration
6.8.3.3. Printing Security
6.8.3.4. Purchasing Printing Hardware
6.9. Configuring and Maintaining XenApp Printing
6.9.1. Configuring Printer Autocreation Settings
6.9.2. Configuring Citrix Universal Printing
6.9.3. Configuring Network Printers for Users
6.9.3.1. To add a network printer while configuring the Session printers setting
6.9.3.2. To specify a default printer for a session
6.9.3.3. To edit the printer settings in the sessions policy
6.9.3.4. To configure server local printers
6.9.4. Configuring Printers for Mobile Workers
6.9.5. Changing Network Print Job Routing
6.9.6. Providing Tools for User Provisioning
6.9.7. To store users’ printer properties
6.9.8. To synchronize properties from the printer
6.9.9. Controlling Printer Driver Automatic Installation
6.9.10. Configuring Universal Printer Drivers on Farm Servers
6.9.11. Mapping Client Printer Drivers
6.9.12. Increasing Printing Speed and Session Performance
6.9.13. Displaying Printers
6.9.13.1. Managing Printers Using the Network Printing Pathway
6.9.13.2. Displaying Printers Using the Client Printing Pathway
6.10. XenApp Server Utilities Reference
6.10.1. ALTADDR
6.10.2. APP
6.10.3. AUDITLOG
6.10.4. CHANGE CLIENT
6.10.5. CTXKEYTOOL
6.10.6. CTXXMLSS
6.10.7. DSCHECK
6.10.8. DSMAINT
6.10.9. ENABLELB
6.10.10. ICAPORT
6.10.11. IMAPORT
6.10.12. QUERY FARM
6.10.13. QUERY PROCESS
6.10.14. QUERY SESSION
6.10.15. QUERY TERMSERVER
6.10.16. QUERY USER
6.11. Performance Counters Reference
6.11.1. Citrix CPU Utilization Mgmt User Counters
6.11.2. Citrix IMA Networking Counters
6.11.3. Citrix Licensing Counters
6.11.4. Citrix MetaFrame Presentation Server Counters
6.11.5. ICA Session Counters
6.11.6. Secure Ticket Authority Counters
6.12. Policy Settings Reference
6.12.1. Policy Settings: Quick Reference Table
6.12.2. ICA Policy Settings
6.12.2.1. Audio Policy Settings
6.12.2.2. Auto Client Reconnect Policy Settings
6.12.2.3. Bandwidth Policy Settings
6.12.2.4. Desktop UI Policy Settings
6.12.2.5. End User Monitoring Policy Settings
6.12.2.6. Graphics Policy Settings
6.12.2.6.1. Image Compression Policy Settings
6.12.2.7. File Redirection Policy Settings
6.12.2.8. HDX MediaStream for Flash Policy Settings
6.12.2.9. Keep Alive Policy Settings
6.12.2.10. HDX Multimedia for Flash Policy Settings
6.12.2.11. Multimedia Policy Settings
6.12.2.12. Multimedia Policy Settings
6.12.2.13. Ports Policy Settings
6.12.2.14. Printing Policy Settings
6.12.2.14.1. Client Printers Policy Settings
6.12.2.14.2. Drivers Policy Settings
6.12.2.14.3. Universal Printing Policy Settings
6.12.2.15. Security Policy Settings
6.12.2.16. Server Limits Policy Settings
6.12.2.17. Session Limits Policy Settings
6.12.2.18. Session Reliability Policy Settings
6.12.2.19. Shadowing Policy Settings
6.12.2.20. Time Zone Control Policy Settings
6.12.2.21. TWAIN Devices Policy Settings
6.12.2.22. USB Devices Policy Settings
6.12.2.23. Virtual IP Policy Settings
6.12.2.23.1. Virtual IP Policy Settings
6.12.2.23.2. Image Compression Policy Settings
6.12.3. Licensing Policy Settings
6.12.4. Multi-Stream Connections Policy Settings
6.12.5. Server Policy Settings
6.12.5.1. Connection Limits Policy Settings
6.12.5.2. Connection Limits Policy Settings
6.12.5.3. Health Monitoring and Recovery Policy Settings
6.12.5.4. Memory Optimization Policy Settings
6.12.5.5. Offline Applications Policy Settings
6.12.5.6. Reboot Behavior Policy Settings
6.12.6. Server Session Settings
6.12.7. Virtual IP Policy Settings
6.12.8. XML Service Policy Settings
7. Application Streaming
7.1. Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6
7.2. New Features in This Release
7.3. System Requirements for Application Streaming
7.4. Components for Application Streaming
7.5. Deciding Which Plug-ins to Use for Application Streaming
7.6. Providing Single Sign-on for Streamed Applications
7.7. Creating Application Profiles
7.7.1. Targets Overview
7.7.1.1. Service Pack Level
7.7.1.2. System Drive Letter
7.7.1.3. Operating System Language
7.7.1.4. Inter-Isolation Communication Overview
7.7.2. Isolating Services
7.7.3. Specifying Trusted Servers for Streamed Services and Profiles
7.7.4. Managing Isolation Environment Rules
7.7.4.1. Types of Isolation Environment Rules
7.7.4.2. Restrictions and Limitations for Rules
7.7.4.3. Creating Isolation Environment Rules for a Target
7.7.4.4. To create an isolation environment rule
7.7.4.5. To modify a rule
7.7.4.6. Using Environment Variables to Construct Rules
7.7.5. Preparing a Workstation for Profiling Applications
7.7.5.1. Known Limitations for Profiling
7.7.5.2. To install the profiler
7.7.5.3. To disable and enable profile signing
7.7.5.4. To start the profiler
7.7.6. Creating a Profile and Its Initial Target
7.7.6.1. To create a profile and target
7.7.6.2. To allow users to update applications
7.7.6.3. To set up inter-isolation communication
7.7.6.4. To select an install option
7.7.6.5. To install multiple applications through Advanced Install
7.7.6.6. To choose an installation program for the application
7.7.6.7. To install Internet Explorer plug-ins
7.7.6.8. To include files and folders in a target
7.7.6.9. To include registry settings
7.7.6.10. To install an application in the profile
7.7.6.11. To run an application in the profiler
7.7.6.12. To select applications for listing in the profile
7.7.6.13. To sign a profile
7.7.7. Editing Profiles
7.7.7.1. To view profile information
7.7.7.2. To edit the profile name, description, or location
7.7.7.3. To view details about applications in a profile
7.7.7.4. To view File Type Associations set in a profile
7.7.7.5. To check for launch prerequisites
7.7.7.6. To check for prerequisite registry entries
7.7.7.7. To check for prerequisite applications and files
7.7.7.8. To specify pre-launch and post-exit scripts
7.7.7.9. To add a target to a profile
7.7.7.10. To resolve target conflicts
7.7.7.11. To resolve invalid shortcuts
7.7.7.12. To delete a target from a profile
7.7.7.13. To delete a folder from a profile
7.7.7.14. To delete a profile in a linked profile
7.7.8. Editing Targets
7.7.8.1. To edit the target name and description
7.7.8.2. To modify the application properties in the target
7.7.8.3. To modify the operating system and language properties of a target
7.7.8.4. To update a target
7.7.8.5. To remove an old version of an updated target
7.7.9. Profile Contents on the Server
7.7.9.1. Manifest File
7.7.9.2. Targets
7.7.9.3. Digital Signature
7.7.9.4. Icons
7.7.9.5. Scripts
7.8. Publishing Resources
7.8.1. Publishing Resources for Users
7.8.1.1. To configure servers to publish for multiple users
7.8.1.2. To publish a resource using the Publish Application wizard
7.8.1.3. Publishing App-V Sequences in XenApp
7.8.1.4. To select a resource type and delivery method
7.8.1.5. To configure locations of published applications
7.8.1.6. To configure locations of published content
7.8.1.7. To disable command-line validation
7.8.2. Managing Streamed Applications
7.8.2.1. Publishing Streamed Applications
7.8.2.2. To select a streaming delivery method
7.8.2.3. To force a delivery method for streamed applications
7.8.2.4. To provide HTTP or HTTPS delivery method
7.8.2.5. Configuring Offline Access
7.8.3. Configuring Content Redirection
7.8.3.1. To enable content redirection from server to client
7.8.3.2. To configure content redirection from client to server
7.8.4. Managing Application Properties
7.8.4.1. To rename a published application
7.8.4.2. To configure locations of servers for published resources
7.8.4.3. To specify locations of applications for streaming
7.8.4.4. To enable an application for offline access
7.8.4.5. To configure user access to applications
7.8.4.6. Granting Access to Explicit or Anonymous Users
7.8.4.7. To configure shortcuts for user devices
7.8.4.8. To configure access controlled by the Access Gateway
7.8.4.9. To associate published applications with file types
7.8.4.10. To update file type associations
7.8.4.11. To configure alternate profiles
7.8.4.12. To pass parameters to published applications
7.8.4.13. To reduce user privileges for a streamed application
7.8.4.14. To configure application limits and importance
7.8.4.15. To configure audio and encryption options for published applications
7.8.4.16. To configure application appearance
7.8.4.17. To disable or enable a published application
7.8.4.18. To delete a published application
7.8.4.19. To move a published application to another folder
7.8.4.20. To duplicate published application settings
7.8.4.21. To export published application settings to a file
7.8.4.22. To import published application settings from a file
7.8.5. Making Virtual IP Addresses Available to Applications
7.8.5.1. How Virtual IP Addressing Works
7.8.5.2. Binding Applications
7.8.5.3. To determine whether an application needs to use virtual IP addresses
7.8.5.4. To make virtual IP addresses available to applications running in sessions
7.8.5.5. To make a virtual loopback address available to applications running in sessions
7.8.5.6. To supply client IP addresses to published applications on a server
7.9. Managing the Offline Plug-in
7.9.1. Citrix Offline Plug-in Overview
7.9.2. Deciding Which Plug-ins to Use for Application Streaming
7.9.3. Using the Merchandising Server and Citrix Receiver to Deploy the Plug-ins
7.9.4. Installing the Offline Plug-in
7.9.4.1. To install the Citrix offline plug-in
7.9.4.2. To configure the cache size of the offline plug-in
7.9.4.3. To deploy the Citrix offline plug-in
7.9.4.4. To deliver the AppHubWhiteList to user devices
7.9.4.5. To configure an .MSI package for the offline plug-in using transforms
7.9.4.6. To deploy the offline plug-in to user devices through Active Directory
7.9.4.7. To deploy applications to user devices
7.9.4.8. To clear the streamed application cache on user devices
7.9.4.9. To clear merged rules for linked profiles on user devices
8. Enhancing the User Experience With HDX
8.1. Configuring HDX MediaStream for Flash
8.1.1. Configuring HDX MediaStream for Flash Settings
8.1.1.1. Configuring HDX MediaStream for Flash on the Server
8.1.1.2. Configuring HDX MediaStream for Flash on the User Device
8.2. Configuring Audio
8.2.1. Avoiding Echo During Multimedia Conferences With HDX RealTime
8.3. Multimedia Conferencing with HDX RealTime
8.4. Increasing 2D and 3D Application Scalability and Performance
9. Enterprise Management
9.1. Management Pack for System Center Operations Manager 2007
9.1.1. System Requirements for the Management Pack
9.1.2. To install the Management Pack
9.1.3. Management Pack Post-Installation Tasks
9.1.4. Uninstalling the Management Pack
9.1.5. Security Considerations for the Management Pack
9.1.5.1. Troubleshooting Query Errors in Operations Manager
9.1.6. Citrix Managed Objects Included in the Management Pack
9.1.7. Citrix Views Included in the Management Pack
9.1.7.1. To view state monitors and processing rules
9.1.7.2. Viewing XenApp Alert and Event Information
9.1.7.3. Viewing XenApp Deployment State Information
9.1.7.4. Viewing Citrix Presentation Server Topology Diagrams
9.1.7.4.1. To reconfigure security settings on zone data collectors
9.1.7.5. Viewing XenApp Performance Information
9.1.7.6. Viewing License Server Information
9.1.8. Configuring and Enabling Site-specific Monitors
9.1.9. To open the Access Management Console or Delivery Services Console from the Operations
Manager Console
9.2. Installation Manager
9.2.1. Requirements and Installation
9.2.2. Using the Installation Manager Console
9.2.3. Using Installation Manager PowerShell Cmdlets
9.2.4. Installation Manager Messages Reference
9.3. Managing Providers and WMI
9.3.1. XenApp Provider Overview
9.3.2. Licensing Provider Overview
9.3.3. Installing the XenApp Provider
9.3.4. Installing the Licensing Provider
9.3.5. Starting the Provider Services
9.3.6. Security Considerations
9.3.7. Uninstalling the Providers
9.3.8. WMI Schema
9.3.8.1. XenApp Provider WMI Schema (Part 1 of 3)
9.3.8.2. XenApp Provider WMI Schema (Part 2 of 3)
9.3.8.3. XenApp Provider WMI Schema (Part 3 of 3)
9.3.8.4. Citrix Licensing Provider WMI Schema
10. Load Management
10.1. Working with Load Evaluators
10.1.1. To change the properties of a load evaluator
10.1.2. To create a new load evaluator
10.1.3. To add a rule to a load evaluator
10.1.3.1. List of Load Management Rules
10.1.4. Assigning Load Evaluators to Servers and Applications
10.1.5. Scheduling Server Availability
11. Power and Capacity Management
11.1. Understanding Power and Capacity Management
11.1.1. Power and Capacity Management System Components
11.1.2. Setpoints
11.1.3. Power and Capacity Management Schedules
11.1.4. Server Profiles
11.1.5. Server Control Mode
11.1.6. Concentrator Operations
11.1.7. Virtual Machine Management
11.1.8. Dynamic Capacity Estimation
11.1.9. What Happens During Power Management Operations
11.1.10. What Happens During Load Consolidation
11.2. Installing Power and Capacity Management
11.2.1. System Requirements for Power and Capacity Management
11.2.2. Considerations for Installing the Concentrator
11.2.3. Interactively Installing Components
11.2.4. Silently Installing Components
11.2.5. Removing Components
11.3. Configuring Power and Capacity Management
11.4. Task Descriptions
12. Secure Gateway
12.1. Citrix XenApp Components That Work with Secure Gateway
12.1.1. Secure Gateway Features
12.2. System Requirements for Secure Gateway
12.3. Certificate Requirements
12.4. Planning a Secure Gateway Deployment
12.4.1. Deploying the Secure Gateway in a Single-Hop DMZ
12.4.1.1. Running the Web Interface behind the Secure Gateway in the Demilitarized Zone
12.4.1.2. Locking Down Internet Information Services
12.4.1.3. Running the Web Interface Parallel with the Secure Gateway
12.4.1.4. Setting Up the Web Interface and the Secure Gateway in a Single-Hop Demilitarized Zone
12.4.2. Deploying the Secure Gateway in a Double-Hop DMZ
12.4.2.1. Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ
12.4.2.2. Publishing the Web Address for the Secure Gateway in a Double-Hop Demilitarized Zone
12.4.3. Setting Up and Testing a Server Farm
12.4.4. Installing the Secure Ticket Authority
12.4.5. Testing Your Deployment
12.5. Installing and Configuring the Secure Gateway and Secure Gateway Proxy
12.5.1. Upgrading Secure Gateway or Secure Gateway Proxy
12.5.2. Using Firewall Software with the Secure Gateway or Secure Gateway Proxy
12.5.3. Installing the Secure Gateway or Secure Gateway Proxy
12.5.3.1. To install the Secure Gateway or Secure Gateway Proxy
12.5.4. Configuring the Secure Gateway or Secure Gateway Proxy
12.5.4.1. To start the configuration wizard manually
12.5.4.2. To select a configuration level (Secure Gateway)
12.5.4.3. To select a configuration level (Secure Gateway Proxy)
12.5.4.4. Task Summary for Secure Gateway, Advanced or Standard Configuration
12.5.4.5. Task Summary for Secure Gateway Proxy, Advanced or Standard Configuration
12.5.4.6. To select a server certificate
12.5.4.7. To configure secure protocol settings
12.5.4.8. To configure inbound client connections
12.5.4.9. To configure outbound connections
12.5.4.9.1. To configure an access control list for outbound connections
12.5.4.9.2. To configure servers running the Secure Gateway Proxy
12.5.4.10. To add the Secure Ticket Authority details
12.5.4.11. To configure connection parameters
12.5.4.12. To configure logging exclusions
12.5.4.13. To add the Web Interface server details
12.5.4.14. To configure the logging parameters
12.5.4.15. To complete the configuration
12.5.4.15.1. To stop the Secure Gateway/Secure Gateway Proxy service
12.5.5. To uninstall the Secure Gateway
12.6. Managing the Secure Gateway
12.6.1. Viewing Session and Connection Information with the Secure Gateway Console
12.6.2. Viewing Secure Gateway Performance Statistics
12.6.2.1. To view the Secure Gateway performance statistics
12.6.2.2. Performance Counters Available for the Secure Gateway
12.6.3. Generating the Secure Gateway Diagnostics Report
12.6.4. Viewing the Secure Gateway Events
12.6.5. Viewing the Secure Gateway Access Logs
12.6.6. Secure Gateway Configuration Wizard
12.7. Secure Gateway Optimization and Security Guidelines
12.7.1. Configuring Firewalls for the Secure Gateway
12.7.2. Ensuring High Availability of the Secure Gateway
12.7.2.1. Load Balancing Multiple Secure Gateway Servers
12.7.2.2. Load Balancing an Array of the Secure Gateway Proxy
12.7.2.3. Certificate Requirements for Load Balancing Secure Gateway Servers
12.7.2.4. Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers
12.7.3. Coordinating Keep-Alive Values Between the Secure Gateway and Citrix XenApp
12.7.3.1. Setting Connection Keep-Alive Values and the Secure Gateway
12.7.4. Improving Security (Recommendations)
12.7.5. Preventing Indexing by Search Engines
12.8. Troubleshooting the Secure Gateway
12.8.1. To check your certificates
12.8.2. Client Connections Launched from IP Addresses in the Logging Exclusions List Fail
12.8.3. Load Balancers Do Not Report Active Client Sessions if Connections Are Idle
12.8.4. Performance Issues with Transferring Files Between a User Device and a Citrix XenApp Server
12.8.5. Gateway Client Connections Fail When Using Windows XP Service Pack 2
12.8.6. Failed Client Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log
12.8.7. Placing the Secure Gateway Behind a Reverse Web Proxy Causes an SSL Error 4
12.8.7.1. Run the Secure Gateway Parallel to the Reverse Web Proxy
12.8.7.2. Use a Network Address Translator Instead of a Reverse Web Proxy
12.9. Digital Certificates and the Secure Gateway
12.9.1. Understanding Cryptography
12.9.1.1. Types of Cryptography
12.9.1.2. Combining Public Key and Secret Key Cryptography
12.9.2. Understanding Digital Certificates and Certificate Authorities
12.9.2.1. Certificate Chains
12.9.2.2. Certificate Revocation Lists
12.9.3. Deciding Where to Obtain Certificates
12.9.4. Obtaining and Installing Server Certificates
12.9.5. Obtaining and Installing Root Certificates
12.9.6. Support for Wildcard Certificates with the Secure Gateway
13. SmartAuditor
13.1. System Requirements for SmartAuditor
13.2. Example Usage Scenarios
13.3. Getting Started with SmartAuditor
13.3.1. Planning Your Deployment
13.3.2. Security Recommendations
13.3.2.1. Installing Certificates
13.3.3. Scalability Considerations
13.3.4. Important Deployment Notes
13.3.5. Pre-Installation Checklist
13.3.6. To install SmartAuditor
13.3.7. Automating Installations
13.3.8. To configure SmartAuditor to play and record sessions
13.4. Granting Access Rights to Users
13.5. Creating and Activating Recording Policies
13.5.1. Using System Policies
13.5.2. Creating Custom Recording Policies
13.5.2.1. To create a new policy
13.5.2.2. To modify a policy
13.5.2.3. To delete a policy
13.5.3. To activate a policy
13.5.4. Understanding Rollover Behavior
13.6. To disable or enable recording
13.7. To configure the connection to the SmartAuditor Server
13.8. Creating Notification Messages
13.9. Enabling Custom Event Recording
13.10. To enable or disable live session playback
13.11. To enable or disable playback protection
13.12. To enable and disable digital signing
13.13. To specify where recordings are stored
13.14. Specifying File Size for Recordings
13.15. Viewing Recordings
13.15.1. To launch the SmartAuditor Player
13.15.2. To open and play recordings
13.15.3. To search for recorded sessions
13.15.4. To play recorded sessions
13.15.5. To use events and bookmarks
13.15.6. To change the playback display
13.15.7. To display or hide window elements
13.15.8. To cache recorded session files
13.15.9. To change SmartAuditor Servers
13.16. Troubleshooting SmartAuditor
13.16.1. Verifying Component Connections
13.16.1.1. Testing IIS Connectivity
13.16.1.2. Troubleshooting Certificate Issues
13.16.2. SmartAuditor Agent Cannot Connect
13.16.3. SmartAuditor Server Cannot Connect to the SmartAuditor Database
13.16.4. Sessions are not Recording
13.16.5. Searching for Recordings in the Player Fails
13.16.5.1. Troubleshooting MSMQ
13.16.6. Unable to View Live Session Playback
13.16.7. To change your communication protocol
13.17. Reference: Managing Your Database Records
14. VM Hosted Apps
14.1. About This Release
14.2. System Requirements
14.3. Plan
14.4. Install and Set Up
14.4.1. Installing and Removing Server Components for VM Hosted Apps
14.4.2. To configure a VM hosted apps site
14.4.2.1. To replace the default XenServer SSL certificate
14.4.3. Installing and Removing the Virtual Desktop Agent
14.4.3.1. To configure firewalls manually
14.4.3.2. To deploy the Virtual Desktop Agent using Active Directory Group Policy Objects
14.4.4. To use Windows XP virtual desktops with Single Sign-on
14.5. Manage
14.5.1. Working With Machine Catalogs and Desktop Groups
14.5.2. To create an application desktop group
14.5.3. Managing Application Desktop Groups
14.5.4. Working With Applications
14.5.5. To create an application
14.5.6. To modify applications
14.5.7. To manage applications sessions
14.5.8. Organizing Applications with Folders and Tags
14.6. Customize
14.6.1. Configuring USB Support for VM Hosted Apps
15. XenApp Connector for Configuration Manager 2007 R2
15.1. Systems Requirements for XenApp Connector for Configuration Manager 2007 R2
15.2. Install and Set Up XenApp Connector for Configuration Manager 2007 R2
15.3. Enabling and Disabling Power and Capacity Management with XenApp Connector for Configuration
Manager 2007 R2
15.4. Uninstalling XenApp Connector for Configuration Manager 2007 R2
15.5. Deploying Applications to XenApp servers
15.6. To publish applications with XenApp Connector for Configuration Manager 2007 R2
15.7. Maintaining Log Files
16. XenApp Printing Optimization Pack
17. Single Sign-on
18. Secure Application Access
19. Service Monitoring for XenApp
20. Branch Optimization
21. Easy Call Voice Services
22. Manage and Dynamically Provision Servers with Provisioning Services
23. Automate IT Processes with Workflow Studio
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
Licensing Your Product
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 SmartAuditor
Load testing services VM Hosted Apps
Power and Capacity Management XenApp Connector for Configuration Manager 2007 R2
Provisioning Services XenApp Printing Optimization Pack
Service Monitoring (EdgeSight) XenApp 6 Migration Tool
Single Sign-on Workflow Studio orchestration
Can’t find what you’re looking for? If you’re 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. Readme for XenApp for Windows Server 2008 R2
Updated: 2011-02-15
Readme Version: 2
Contents
Finding Documentation
Getting Support
Installation Issues
Other Known Issues
Finding Documentation
To access complete and up-to-date product information, in Citrix eDocs, expand the topics for your product.
Licensing Documentation
To access licensing documentation, go to http://support.citrix.com/proddocs/topic/technologies/lic-library-
. node-wrapper.html
Getting Support
Citrix provides technical support primarily through Citrix Solutions Advisors. Contact your supplier for first-
line support or use Citrix Online Technical Support to find the nearest Citrix Solutions Advisor.
Citrix offers online technical support services on the . The Support page includes links Citrix Support Web site
to downloads, the Citrix Knowledge Center, Citrix Consulting Services, and other useful support pages.
Installation Issues
If you install a role component from the Autorun menu by selecting Manually Install Components and
then install the XenApp server role from Autorun, you may be prompted during XenApp role
configuration for the location of that component's server, even though you did not select that
component during XenApp server role installation. Re-enter the server information you specified during
the manual installation. This also applies during a command-line XenApp role configuration; you
must specify the server information for all the installed components. [#229147]
The Provisioning Services Target Device software resets your network connection during install. As a
result, you may see user interface crashes or other failures if you select this component to install from
a network location. Citrix recommends that you install the Provisioning Services Target Device
software using one of the following methods [#229881]:
Install from a local DVD image or ISO
Copy the installation media locally before performing the installation
Select Manually Install Components from the Autorun menu
Install with a command-line installation
You must install the Provisioning Services role and the Provisioning Services Target Device component
on separate servers. If you select both on the same server, the installation fails. [#229999]
If you install the XenApp server role and then uninstall it, Citrix recommends that you re-image the
server with a clean operating system before installing the XenApp server role again. Re-installation of
the XenApp server role on a machine where it was previously uninstalled may fail in the
following conditions [#228363, 224925]:
If you previously created a farm on this machine
If you had IIS installed on the machine previously and/or chose to install XML Service
Integration with IIS
If you specify an unsupported Microsoft SQL Server database version during XenApp server
role configuration, the configuration fails but the error message may not state the cause. For
supported database versions, see the system requirements topic and http://support.
. [#225264] citrix.com/article/CTX114501
To install the EdgeSight for XenApp Agent, either install it at the same time you install the XenApp
server role (and then restart the server after you configure XenApp), or, if you have already installed
the XenApp server role, install the agent from the installation media using the MSI file in
Service Monitoring\Installers\Agent\. Then restart the XenApp server. If you installed the XenApp
server role and later installed the EdgeSight for XenApp Agent using the Server Role Manager, you are
not prompted for the agent configuration, and the agent does not report to your EdgeSight server.
To provide the proper configuration in this case, uninstall the agent and reinstall it from the
installation media. [#229617, 229778]
If the network connection fails or disconnects during a wizard-based XenApp installation, you may see
the error message "Citrix eXtensible Meta Installer has stopped working." This is typically a non-fatal
error; restart the XenApp Server Role Manager and finish your installation or configuration. You can
also avoid this issue by copying the installation media locally or installing from the DVD. [#227578]
After installing the Delivery Services Console, if you use the Autorun menu to install Applications on
Virtual Machines and select Install optional components > Upgrade Management Consoles, a
separate console is installed, rather than adding a "VM Hosted Apps" node to the Delivery
Services Console. [#226895]
When installing the XenApp server role, if the required IIS role services are deployed on the server and
you choose not to enable IIS integration by deselecting the XML Service IIS Integration component in
a wizard-based installation, or by omitting the XA_IISIntegration option in a command-line installation,
you must change the XML service port (to a port other than 80) when configuring the XenApp
role. [#230674]
When you select both the XenApp and Web Interface roles to install, and the IIS role services are
not deployed on the server, the Web Interface role automatically deploys the IIS server roles.
However, the XML Service IIS Integration component checkbox is not selected by default. Either select
this checkbox or specify an XML Service port other then 80 when you configure XenApp. [#230683]
Launching the Server Configuration Tool by double-clicking XenAppConfiguration.exe is not
supported. Launch the Server Configuration Tool through the Server Role Manager. [#230819]
When using the Server Role Manager to install and configure the SmartAuditor server role from a
network share that requires authentication, after restarting the server, log on to the network
share [#231084]
XenApp Connector for Configuration Manager 2007 R2 Issues
If you change the name of a worker group in your XenApp deployment and are using
Configuration Manager, it creates a collection based on the new name of the worker group, but the
original collection associated with the prior work group name remains. If you have used the
original collection as the target of an advertisement, manually change the advertisement to target the
new collection.
When there are no servers in a target (due to no successful advertisements yet), an error
message displays indicating a browser name error or that no servers were in the collection. This is
normal and the error ceases after a server in the target has a successful advertisement. [#234879]
When using the publishing wizard to specify the command line that launches the application, if
the command line includes quotation marks, type the command line manually instead of browsing to
it. [#235821]
Ignore this error message in the Publish.log file: "Write-Host : The OS handle's position is not
what FileStream expected. Do not use a handle simultaneously in one FileStream and in Win32 code
or another FileStream. This may cause data loss." This error message does not indicate that
XenApp Connector is not functioning properly.
Single Sign-on Issues
Saving a Single sign-on plug-in installation image in the protected directories (for example, C:\ or
C:\Windows) on a computer running Windows 7 results in an installation failure. To avoid this
issue, designate a location (for example, create a folder under C:\ or a user's document folder) in which
to save the image. [#224612]
Installing the Single sign-on plug-in with XenApp from the wizard-based Server Role Manager does
not allow you to install and configure optional plug-in features, such as Self-Service and Data Integrity.
To successfully install the Single sign-on plug-in with these features, from the XenApp Autorun menu,
click Manually install components > Server Components > Miscellaneous > Single sign-on > Single sign-
on Plug-in. Dialog boxes appear during this installation process letting you select and configure
the features. [#226801]
If you use custom alerts in Citrix Service monitoring for XenApp (formerly Citrix EdgeSight for XenApp),
or other event log rollup utilities, you must change the source name of Citrix Password Manager to
Citrix Single Sign-On. [#222720]
The Single sign-on 4.8 plug-in may not start after it has been upgraded from Password Manager Agent
4.5. An error message appears stating that Syncmgr.vrs is missing. To ensure a successful
installation, uninstall Password Manager Agent 4.5 prior to installing Single sign-on 4.8 plug-in. If
the Single sign-on 4.8 plug-in is already installed, run the Repair feature from the Programs section of
the Control Panel. [#230824]
Network credential dialog boxes on Windows Server 2008 R2 and Windows 7 are not recognized by
the Citrix Single sign-on plug-in. Users are not prompted to store their user IDs and passwords.
An application template, Windows 7 Network Authentication Dialog, available at http:
, resolves this problem for environments where a single set //citrix.thinkbuilddeploy.com/index.php
of credentials is used for each user. [#221161]
Other Known Issues
On Windows Server 2008 R2 platforms, logging off MSN Messenger using the X button on the
Messenger window fails to close the application. When you do so, the application minimizes to the
system taskbar, which is not accessible with Windows Server 2008 R2.
As a workaround, with administrative privileges, you can configure Messenger to run in Windows
XP compatibility mode for all users. To do this, from the Windows Start > All Programs menu,
select Windows Live Messenger. From the right-click menu, select Properties. On the Compatibility
tab, choose "Change settings for all users." Then check "Run this program in compatibility mode for"
and choose "Windows XP (Service Pack 3)." [#228845]
When using XenApp in a Novell Directory Services for Windows environment, XenApp servers
experience reduced performance when enumerating published resources and during application
launch when resolution to the least-loaded server occurs. As a workaround, modify the following
registry key:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix/IMA\
Value Type: DWORD (32-bit)
Value Name: DisablePasswordExpiryCheck
1.
2.
3.
4.
Be sure to set access control lists (ACLs) for the Network Service account to "Read." When this
workaround is implemented, the number of simultaneous user logons is reduced. Therefore, users
might experience longer logon times during peak usage periods. [#228841]
The Cumulative Server Load counter (available as part of the Citrix MetaFrame Presentation
Server performance monitor counters) might not display the same values as the XenApp command
query farm /load (also known as qfarm /load) when querying the same server running Citrix XenApp
if there are pending connections to this server. The counter and command should display
identical information once all sessions are active. [#228466, 228842]
In some instances, when a user launches a published application, two Status Indicator icons might
appear on the Windows Taskbar for the single published application. The second icon disappears after
a few seconds. No workaround exists for this issue and it does not interfere with published
application functionality. [#221203]
If an administrator specifies a specific Windows theme for users through a Personalization group
policy template, the Windows theme might not appear to be applied when launching a published
application configured for seamless or non-seamless windows. (Any configured themes are
correctly applied when launching published desktop.) To ensure themes are applied, administrators
can modify the Windows registry. For details, see in the http://support.citrix.com/article/CTX124407
Citrix Knowledge Center. [#228080]
On XenApp servers running the German language version of Windows, after configuring Citrix
policy settings for a Group Policy Object, the Settings report for the Group Policy Object does not
display the Citrix policy setting values when generated. As a workaround, use a language version
of Windows other than German to view the policy settings values. [#223303]
The Group Policy Results report does not include Citrix policy settings when run on a Group Policy
Object (GPO) that meets one of the following conditions:
The GPO contains both a Citrix administrative template (.adm) and Citrix policy settings
The GPO containing Citrix policy settings inherits the settings of another GPO that contains a
Citrix administrative template
To resolve this issue, use separate GPOs for Citrix policy settings and administrative templates and
ensure these GPOs do not inherit settings. [#230497]
In user environments where Citrix Receiver is installed and Microsoft Windows 7 Specialized
Security Limited Functionality (SSLF) templates are applied, Citrix Receiver might not run automatically
at user logon or startup. Additionally, any installed Citrix plug-in and client software might not
launch automatically at user logon or startup. The suggested workaround for this scenario
for administrators is to remove the CitrixReceiver entry from the registry
key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and deploy the
Citrix Receiver software through the user's Startup shortcut. [#230500]
When installing the Citrix online plug-in on a user device, pass-through authentication is not
automatically configured. To ensure pass-through authentication is enabled for users accessing
XenApp Services sites:
On the XenApp server, enable the pass-through authentication method for the XenApp Services site.
Ensure that on the user device, Internet Explorer has the URL to Web Interface added to the
local Intranet Zone.
On the user device, add the icaclient.adm file using the Group Policy Editor and configure
the following settings:
Enable Local user name and password and then select Enable pass-through authentication
Disable Kerberos authentication
After configuration, run gpupdate /force, log off the user device, and log back on.
For detailed instructions about configuring these settings, see http://support.citrix.com/article/CTX113004
in the Citrix Knowledge Center. [#230082, 230078]
When using Remote Desktop IP Virtualization in per session mode on servers with dual network
adapters, virtual IPs are not assigned when sessions are created. This is an issue in Windows Server
2008 R2 that might occur if you use virtual IPs with XenApp. To work around this issue, configure
Remote Desktop IP Virtualization to assign virtual IPs on a per program basis. [#228288]
1.
2.
The "Pass-through with smart card from Access Gateway" feature cannot be used with XenApp
6.0. Because of an issue with XenApp 6.0, smart card users logging on to Access Gateway
integrated XenApp Web sites are unable to access resources when the pass-through with smart card
from Access Gateway feature is enabled. Users clicking on a link in the XenApp Web site to access
a resource delivered by XenApp 6.0 see the error message "An error occurred while making the
requested connection." You can avoid this issue by configuring the site to prompt smart card users for
their PIN each time they access a resource. [#230942]
Changes to worker groups might not be reflected accurately in the registry when a worker group
is renamed or deleted. The registry entry for the worker group
in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\WorkerGroups subkey is
not automatically updated. [#231048]
As a workaround:
Create a new temporary worker group with all servers in the farm, which forces the registry
to update for the renamed or deleted worker groups.
Delete the temporary worker group.
When generating the Settings report of a Group Policy Object (GPO) linked to the domain, the Group
Policy Management console stops working. To work around this issue, access the original GPO, under
the Group Policy Objects node, to generate the Settings report. [#261163]
For changes to Health Monitoring and Recovery to take effect, in Windows Component Services,
Services (Local), restart the Citrix Health Monitoring and Recovery Service. [230902]
For instructions about creating server-side content fetching whitelists for HDX MediaStream for
Flash, search Citrix eDocs (this Web site) for the topic "Configuring HDX MediaStream for Flash on the
User Device." Instructions found in the HDX administrative templates are outdated. [#229985]
Windows Media Player, when installed on a XenApp server, occasionally hides video behind a black
Media Player screen on a user device running Windows 7. To correct this, users should change their
Media Player view to Skin Mode. Alternatively, they can minimize and maximize the Media Player
(more than once might be necessary) to refresh the video. [#230238]
Installing the HDX MediaStream for Flash version 1.1.0 package
(CitrixHDXMediaStreamForFlash-ServerInstall.msi) using Active Directory Software Installation might
fail. To prevent this failure, use a start-up script to deploy the package. [#229263]
After performing a Repair on Citrix HDX MediaStream for Flash-Server, the HDX MediaStream for
Flash service might fail to restart. To avoid this issue, uninstall Citrix HDX MediaStream for Flash -
Server and reinstall it. [#228502]
The Session Shadowing feature in XenApp 6 is supported only in single-monitor configurations for
both computers. If either the shadowing or shadowed computer is configured with multiple
monitors, shadowing is not supported. [#251490]
2. System Requirements for XenApp 6 for Windows Server 2008 R2
Updated: 2011-01-24
System requirements for XenApp features and related technologies are described in their respective
System Requirements documentation; that includes plug-ins and agents, Web Interface, Single Sign-on,
Service Monitoring, EdgeSight, SmartAuditor, Application Session Recording, Provisioning Services, and
Power and Capacity Management.
Citrix recommends using the latest Citrix License Server.
To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your
users, install the most recent version of any plug-ins you use.
Important: Do not join servers running XenApp 6 for Windows Server 2008 R2 to a deployment with
servers running previous versions of XenApp.
Deploying Prerequisites
During a wizard-based installation, the XenApp Server Role Manager (using the Server Role
Installer), automatically installs prerequisites for the selected roles.
For command-line installations, deploy the prerequisites before initiating XenApp role installation.
Citrix recommends you deploy prerequisites (such as IIS role services) using the Microsoft
ServerManagerCmd.exe command or Powershell, which Microsoft provides for Windows operating system roles.
XenApp for Windows Server 2008 R2
Supported operating system: Microsoft Windows Server 2008 R2, except the Web Server edition and the
core installation option.
Most servers running Microsoft Windows Server 2008 R2 meet the hardware requirements for XenApp with
ample processing power to host user sessions accessing the published resources. However, additional
research may be needed to determine if current hardware meets the requirements.
Technology Requirement
CPU
64-bit architecture with Intel Pentium
Xeon family with Intel Extended Memory 64 Technology
AMD Opteron family
AMD Athlon 64 family
Compatible processor
Memory 512MB RAM (minimum)
Disk space 32GB (minimum)
The XenApp Server Role Manager deploys the following software (except as noted), if it is not already installed:
.NET Framework 3.5 SP1 (this is a prerequisite for the XenApp Server Role Manager; it is
deployed automatically when you choose to add the XenApp server role from the Autorun menu)
Windows Server Remote Desktop Services role (if you do not have this prerequisite installed, the
Server Role Manager installs it and enables the RDP client connection option; you will be asked to
restart the server and resume the installation when you log on again)
Windows Application Server role
Microsoft Visual C++ 2005 SP1 Redistributable (x64)
Microsoft Visual C++ 2008 SP1 Redistributable (x64)
If the server already has the following IIS role services installed, the Citrix XML Service IIS
Integration component is selected by default in the wizard-based XenApp installation, and the Citrix XML
Service and IIS share a port (default = 80). If the IIS role services are not installed, the Citrix XML Service
IIS Integration component is not selected by default in the wizard-based installation. In this case, if you
select the checkbox, the Server Role Manager installs the following IIS role services. (If you do not install
these services, the Citrix XML Service defaults to standalone mode with its own port settings, which you
can configure using the XenApp Server Configuration Tool.)
Web Server (IIS) > Common HTTP Features > Default Document (selecting this role service
automatically selects Web Server (IIS) > Management Tools > Management Console, which is not
required or checked for XenApp installation)
Web Server (IIS) > Application Development > ASP.NET (selecting this role service automatically
selects Web Server (IIS) > Application Development > .NET Extensibility; although not checked for
XenApp installation, .NET Extensibility is required by ASP.NET)
Web Server (IIS) > Application Development > ISAPI Extensions
Web Server (IIS) > Application Development > ISAPI Filters
Web Server (IIS) > Security > Windows Authentication
Web Server (IIS) > Security > Request Filtering
Web Server (IIS) > Management Tools > IIS 6 Management Compatibility (which includes IIS 6
Metabase Compatibility, IIS 6 WMI Compatibility, IIS 6 Scripting Tools, and IIS 6 Management Console)
If you plan to use Philips SpeechMike devices with XenApp, you may need to install drivers on the servers
hosting sessions that record audio, before installing XenApp. For more information, see Citrix information on
the Philips web site.
If installation of a required Windows role or other software requires a restart (reboot), restart the server
before starting the XenApp server role installation.
Important: Do not install XenApp on a domain controller. Citrix does not support installing XenApp on
a domain controller.
XenApp Management
XenApp Management includes the Delivery Services Console. By default, the console is installed on the
same server where you install the XenApp server role; however, you can install and run the console on a
separate computer. To install the Delivery Services Console on a workstation, from the XenApp Autorun
menu, select . > > Manually Install Components Common Components Management Consoles
Supported operating systems:
Windows Server 2008 R2
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 XP Professional, 64-bit edition, with Service Pack 2
Windows Vista (Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions, with Service Pack 1
Windows 7, 32-bit and 64-bit editions
Requirements:
Disk space: 25MB
Microsoft Management Console (MMC):
For Windows Vista, Windows 7, and Windows Server 2008 R2: MMC 3.0 (installed by default)
For other supported Windows operating systems: MMC 2.0 or 3.0
The XenApp Server Role Manager deploys the following software, if it is not already installed:
Microsoft .NET Framework 3.5 SP1
Microsoft Windows Installer (MSI) 3.0
Microsoft Windows Group Policy Management Console
Microsoft Visual C++ 2005 SP1 Redistributable (x64)
Microsoft Visual C++ 2008 SP1 Redistributable (x64)
Microsoft Visual C++ 2008 SP1 Redistributable
Microsoft Visual C++ 2005 SP1 Redistributable
Microsoft Primary Interoperability Assemblies 2005
If you install the Delivery Services Console on a computer that previously contained the Microsoft Group
Policy Management Console (GPMC) and an earlier version of the Delivery Services Console, you may also need
to uninstall and reinstall the Citrix XenApp Group Policy Management Experience (x64) program in order to
use the GPMC to configure Citrix policies.
Data Store Databases
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
The following databases are supported for the data store:
Microsoft SQL Server 2008 Express (can be deployed for you by the XenApp Server Configuration
Tool when creating a new XenApp farm)
Microsoft SQL Server 2005
Microsoft SQL Server 2008
Oracle 11g R2
For information about supported versions, see . CTX114501
3. Designing a XenApp Deployment
Updated: 2011-01-31
XenApp is the central software component of the Citrix Windows Application Delivery Infrastructure. The goals
of XenApp and the Citrix Windows Application Delivery Infrastructure are to deliver on-demand applications
to both physical and virtual desktops, and to determine and provide the best method of delivery. XenApp
offers three methods for delivering applications to user devices, servers, and virtual desktops:
Server-side application virtualization: applications run inside the Data Center. XenApp presents
each application interface on the user device, and relays user actions from the device, such as
keystrokes and mouse actions, back to the application.
Client-side application virtualization: XenApp streams applications on demand to the user device from
the Data Center and runs the application on the user device.
VM hosted application virtualization: problematic applications or those requiring specific operating
systems run inside a desktop in the Data Center. XenApp presents each application interface on the
user device and relays user actions from the device, such as keystrokes and mouse actions, back to
the application.
To provide these types of application delivery, you have many choices of deployment designs and
XenApp features, which you can tailor for your users' needs. A typical process for planning a XenApp
farm includes:
Becoming familiar with XenApp and XenApp Setup by creating a small, one-server or two-server test farm.
Deciding which applications to deliver to users.
Determining how you want to deliver applications - this includes testing and evaluating the applications
and peripheral requirements.
Determining application to application communication, where to install the applications on XenApp
servers, and which applications can be collocated.
Determining the number of servers you need for applications.
Determining the total number of servers you need for your farm and evaluating hardware requirements.
Creating the network infrastructure design.
Defining the installation processes.
Creating and testing a pre-production pilot farm based on your farm design.
Releasing the farm into production.
To help you understand how a XenApp deployment delivers applications so you can complete planning
tasks, consider the following diagram.
A XenApp deployment consists of three deployment groups: user device (represented in this diagram by
Citrix Receiver and Citrix Dazzle), Access Infrastructure, and Virtualization Infrastructure.
On the left of this diagram are Citrix Dazzle and Citrix Receiver, which represent the set of devices
on which you can install client software. Citrix Dazzle provides your users with a selection of
applications you have made available to them. Citrix Receiver manages the client software plug-ins
that enable your users to interact with virtualized applications. When designing a XenApp deployment,
you consider how your users work, their devices, and their locations.
Access Infrastructure represents secure entry points deployed within your DMZ and provide access
to resources published on XenApp servers. When designing a XenApp deployment, you provide
secure access points for the different types of users in your organization.
Virtualization Infrastructure represents a series of servers that control and monitor
application environments. When designing a XenApp deployment, you consider how applications
are deployed based on your user types and their devices, the number of servers you need, and
which features you want to enable in order to provide the support, monitoring, and management
your organization requires.
The following diagram shows the access infrastructure in greater detail.
In this access infrastructure diagram:
All of your users use Citrix Dazzle to choose applications they want to run. Citrix Receiver plug-ins
run them.
Onsite users within your corporate firewall interact directly with the XenApp Web and Services Site.
Remote-site users access applications through sites replicated by Citrix Branch Repeater.
Off-site users access applications though secure access, such as Access Gateway.
The Merchandising Server makes available self-service applications to your users through Citrix Dazzle.
EasyCall Voice Services enables your users to initiate telephone calls by clicking on telephone
numbers displayed in their applications.
The XML Service relays requests and information between the Access Infrastructure and the
Virtualization Infrastructure.
The following diagram shows the virtualization infrastructure in greater detail.
In this virtualization infrastructure diagram:
The XML service relays information and requests.
Based on Active Directory profiles and policies, the XenApp servers invoke the correct application
delivery type for the user. The XenApp servers provide server-side application virtualization and
session management. Session and deployment configuration information are stored in data collectors and
a central data store represented by the deployment data store.
The App Hub provides Streamed Application Profiles, which are client-side virtualization
applications housed in your enterprise storage.
The VM Hosted Apps server isolates problematic applications inside a seamless desktop, which,
depending on the user profile, can be virtualized on the user device or on the server. The desktop
images are provisioned through Provisioning Server. Session and server configuration information
are stored in the enterprise database.
Provisioning Services delivers desktops to servers, which are stored as desktop images in your
enterprise database.
SmartAuditor provides session monitoring. Recorded sessions are stored in your enterprise storage
and configuration information is stored in the deployment data store.
Service Monitoring enables you to test server loads so you can estimate how many servers you need
for your deployment and to monitor those servers once they are deployed.
Power and Capacity Management enables you to reduce power consumption and manage server
capacity by dynamically scaling the number of online servers.
Single Sign-on provides password management for virtualized applications. Passwords are stored in
the account authority.
3.1. Farm Terminology and Concepts
Updated: 2011-01-31
Terminology
The XenApp planning documentation uses the following terminology:
Multi-user environment
An environment, including XenApp and Remote Desktop Services, where applications are published
on servers for use by multiple users simultaneously.
Production farm
A farm that is in regular use and accessed by users.
Design validation farm
A farm that is set up in a laboratory environment, typically as the design or blueprint for the
production farm.
Pilot farm
A preproduction pilot farm used to test a farm design before deploying the farm across the organization.
A true pilot is based on access by select users, and then adding users until all users access the farm
for their everyday needs.
About Controllers
XenApp farms have two types of infrastructures:
The virtualization infrastructure consists of the XenApp servers that deliver virtualized applications and
VM hosted Applications, and controllers that support sessions and administration, such as the data
store, data collector, Citrix XML Broker, Citrix License Server, a computer for profiling
applications, Configuration Logging database (optional), Load Testing Services database (optional),
and Service Monitoring agents, players, and database.
Access infrastructure consists of controllers such as the Web Interface, Secure Gateway (optional),
and Access Gateway (optional) that provide access administration.
In small deployments, you can group one or more controllers together. In large deployments, you
provide services on one or more dedicated servers.
Factors other than size can affect how you group controllers. Security concerns, virtualized servers, and user
load play a part in determining which functions can be collocated.
This illustration depicts controllers in a large farm. The Web Interface, XML Service, data collector, and data
store are deployed on separate servers.
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 servers hosting controllers. For example, in a
small farm with a Microsoft SQL Server Express 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 controllers 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.
About Virtualization Infrastructure
The virtualization infrastructure, which is the center of a XenApp deployment, concerns the following concepts:
Application enumeration
Application enumeration is when Citrix client software lists virtualized applications available on the
XenApp servers. The client software transmits data to locate servers on the network and
retrieves information about the published applications. For example, during enumeration, the
XenApp online plug-in communicates through Citrix XML Service with the XenApp server to
determine applications available for that user.
Application publishing
To deliver an application to your users through Citrix Dazzle and the XenApp online or offline plug-
ins, whether virtualized on the desktop or the server, you use the Delivery Services Console to publish
the application.
Citrix Licensing
A Citrix License Server is required for all XenApp deployments. Install the license server on either a
shared or stand-alone server, depending on your farm’s 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 when you create the farm and all
other servers are configured with equal rights to become the data collector if the data collector fails.
When the zone’s 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 a controller and applications are typically not published on it.
Zones
A is a grouping of XenApp servers that communicate with a common data collector. In large zone
farms with multiple zones, each zone has a server designated as its data collector. Data collectors in
farms with more than one zone function as communication gateways with the other zone data collectors.
The data collector maintains all load and session information for the servers in its zone. All farms have
at least one zone, even small ones. The fewest number of zones should be implemented, with one
being optimal. Multiple zones are necessary only in large farms that span WANs.
Streaming Profiles
You can deliver applications to users by either virtualizing them on the desktop (streaming) or
by virtualizing them on the server (hosting). If you are virtualizing applications on the desktop,
either streaming to the client or server, create a streaming profile server in your environment. To
virtualize applications on the desktop, you create profiles of the application and then store the profile on
a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines
the profile, as well as the target files, a hash key file, the icons repository (Icondata.bin), and a
scripts folder for pre-launch and post-exit scripts.
Web Interface
The Web Interface is a required component in any environment where users access their applications
using either the online plug-in 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 user’s 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 user’s 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 user’s 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 user’s request to launch an application, the broker locates the servers in the
farm that host this application and identifies which of these is the optimal server to service
this connection based on several factors. The XML Broker returns the address of this server to
the Web Interface.
The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on
every server during XenApp installation. However, only the XML Service on the server specified in the
Web Interface functions as the broker. (The XML Service on other farm servers is still running but is
not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on
a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be
configured on one or more dedicated servers.
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 controller functions.
3.2. Planning a Successful User Experience
Updated: 2010-02-17
Two key factors impact your users' satisfaction when working in a multi-user environment: how quickly
sessions start, and how easily users can print.
Session Start-up Times
Certain factors can cause sessions to start slower than necessary.
Printer autocreation policy settings - Consider limiting the number of printers that are autocreated
if session start time is a factor.
Network activities occurring independently of sessions - Operations such as logging on to Active
Directory, querying Lightweight Directory Access Protocol (LDAP) directory servers, loading user
profiles, executing logon scripts, mapping network drives, and writing environment variables to
the registry, can affect session start times. Also, connection speed and programs in the Startup
items within the session, such as virus scanners, can affect start times.
Roaming profile size and location - When a user logs onto a session where Microsoft roaming profiles
and home folders are enabled, the roaming profile contents and access to that folder are mapped
during logon, which uses additional resources. In some cases, this can consume significant amounts of
the CPU usage. Consider using home folders with redirected personal folders to mitigate this problem.
Whether the data collector has sufficient resources to make load balancing decisions efficiently -
In environments with collocated infrastructure servers, Citrix suggests hosting the Citrix XML Broker on
the data collector to avoid delays.
License server location - For WANs with multiple zones, where the license server is in relation to the zone.
Printing Configuration
Your printing configuration directly affects how long sessions take to start and the traffic on your
network. Planning your printing configuration includes determining the printing pathway to use, how to
provision printers in sessions, and how to maintain printer drivers.
Consider these recommendations:
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.
3.3. Farm Hardware Considerations
Updated: 2010-02-09
The number of users a XenApp server can support depends on several factors, including:
The server’s 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 user’s Remote Desktop Services profile
is loaded on the server, consider that large numbers of user profiles can use gigabytes of disk space on
the server. You must have enough disk space for these profiles on the server.
3.4. Planning for Applications and Server Loads
Updated: 2010-02-09
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 farm’s hardware and operating system configuration:
Can I run the applications? Citrix recommends testing non-Vista-compliant applications before you
publish them on your farm. Some non-Vista-compliant applications run using the Application
Compatibility feature.
How many users do I anticipate will want to connect to each application during peak and off-peak
hours? Do I need to allocate servers for load balancing?
Will users be accessing certain applications frequently? Do I want to publish all of these applications on
the same server to facilitate session sharing and reduce the number of connections to a server? If
you want to use session sharing, you might also want users to run applications in seamless windows. .
Will my organization need to provide proof of regulatory compliance for certain applications? Will
any applications undergo a security audit? If you intend to use SmartAuditor to record sessions on
these servers, install the SmartAuditor agent on these servers. In addition, make sure the servers
have sufficient system resources to ensure adequate performance.
Will any of my applications be graphically intensive? If so, consider using the XenApp
SpeedScreen, Memory Utilization Management, or CPU Utilization Management features as well as
more robust hardware for sessions hosted on these servers.
3.4.1. Assessing Applications for XenApp Compatibility
Updated: 2010-06-07
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
server’s scalability. Before testing applications for compatibility, investigate how the application works
with Remote Desktop Services or XenApp. Remote Desktop Services-compliant and Windows Logo
certified applications experience few, if any, issues compared with noncompliant applications.
Initial application compatibility testing typically involves publishing the application so that 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 Microsoft’s 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.
3.4.2. Evaluating Application Delivery Methods
Updated: 2010-11-30
The application delivery method is a factor in determining the number of servers in a farm and their
individual hardware requirements.
How you choose to deliver applications depends on your organization's needs and end-users' requirements.
For example, some organizations use XenApp to streamline administration. In other organizations, the
existing hardware infrastructure might affect the delivery method selected, as can the types of applications to
be delivered. In addition, some end-users might run all applications while connected to the company
network, while others might work in remote locations and run applications while disconnected from the network.
Method/Description Advantages Considerations
Installed on the server:
Applications are installed on
the server, where
the processing takes place,
and accessed from the
server. This is the
traditional XenApp
application delivery model.
For many organizations,
this provides the lowest cost
of ownership for IT
resources because it
provides the greatest scalability.
This method provides
a consistent user
experience regardless of
the user device.
You manage
applications centrally.
User devices do not
require extensive
resources, such as
excessive memory or hard
drive space. This
delivery method supports
thin clients.
This method is effective
for applications with
components that are
intertwined with the
operating system (such as a
.NET framework).
Farm servers
require sufficient
resources to support
the applications.
Users must be connected
to the server or network
to run the applications
(no offline access).
Streamed to server:
Executables for applications
are put in profiles and stored
on a file server or Web
server (the App Hub);
however, when launched,
they stream to the server,
and application processing
takes place on the
server. Unlike
installed applications,
streamed applications
are stored in the App Hub
and provide application
isolation by design.
This method has
similar advantages as
for installed
applications, including
a consistent user
experience,
central management, and use
of server resources instead
of those of the user device.
In many cases, streaming
to server lets
conflicting applications, such
as multiple versions of the
same application, run on
the same server without
needing to silo them.
Updating applications
is simplified because you
update only a single
application profile.
Farm servers
require sufficient
resources to support
the applications.
Users must be connected
to the server or network
(no offline access).
Some applications are
not candidates for
profiling, such as those
using a .NET framework.
Streamed to desktop:
Users can have the
local application experience,
User devices must
have sufficient resources
Executables for applications
are put in profiles and stored
on a file server or Web
server (the App Hub).
When launched, the
files required to execute
the application are streamed
to the user device,
and application processing
takes place on the user
device instead of the
XenApp server.
When applications are
streamed to the user
device, the user experience
is similar to running
applications locally.
After applications are cached
on the user device, users
can continue running the
apps after disconnecting
from the network (referred to
as offline access).
but you manage the
applications centrally.
Users might have a
better experience when
resource-intensive
applications, such as
graphics applications,
are streamed to desktops.
Using application
properties and Citrix policies
and filters for
Offline Applications, you
control the applications
and users that have
offline access, as well as
the license period for offline use.
to run the
applications locally; the
user devices cannot be
thin clients.
User devices must
run Windows
operating systems,
including Windows 7, XP,
or Vista.
Dual mode delivery:
When you select "streamed
if possible, otherwise
accessed from a
server" (referred to as
dual mode or fallback),
XenApp tries to stream
the application to the
user device first, but uses
the backup access method
if streaming to desktop is
not supported on the
user device. For example,
you can specify that
some users, such as
sales personnel,
run applications streamed
to desktop when they
are accessing the
applications from
Windows devices, and run
them as installed
applications when they
are accessing them
from handheld mobile or
kiosk-type devices.
This method provides the
most versatility for
application delivery, offering
all the advantages of
streaming to desktops
for supported user devices,
plus a backup delivery
method for the rest.
You control delivery
options centrally using
Citrix policies and filters, such
as the server's Load
Balancing Policies for
Streamed App Delivery.
For the backup method
to occur, ensure that
the application is
either installed on
the XenApp server or
the streaming profile
is configured for a
target operating system
that matches the server.
Choosing Between Published Desktops and Published Applications
Before selecting the method for delivering applications, decide if you want to publish the desktop or
publish applications.
Publishing the desktop - Presents users with an entire Windows Server desktop when they log
onto XenApp. (For security, the desktop should be locked down .)
Publishing applications - Publishes specific applications and delivers only those applications to users.
This option provides greater administrative control and is used most frequently.
You can use policies to prevent users from accessing server drives and features with both methods of
application delivery.
3.4.3. 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.
3.4.4. Placing Applications on Servers
When designing your farm, consider the following:
The servers on which the applications are installed
If load balancing or preferential load balancing changes your need to dedicate servers to mission-critical
or highly used applications
The geographic location of the servers delivering applications (for WANs and organizations with
branch offices)
Grouping Applications on Servers
Traditionally, two strategies for grouping applications on servers are applications and siloing not siloing
applications.
When applications are siloed on farm servers, each server has a limited number of applications. Some
servers might have only one application; others might have a set of interrelated applications. For example,
you might install a medical application on Server A, and on Server B install an enterprise resource planning
(ERP) application. However, if the ERP application is integrated with email, you might also have an email client
on Server B. Siloing is sometimes required when applications have unique hardware requirements, for
business reasons, to segregate mission-critical applications, or to separate frequently-updated
applications. However, siloing applications is not as efficient as nonsiloed applications for hardware use
and network traffic.
With a nonsiloed approach, you install all applications on each server. Applications can be installed traditionally
or in isolation (installing them in separate profiles).
Citrix recommends installing applications that interact with each other on the same server, or including them
in the same streaming profile. For example, if an application interacts with an email client by letting users
send email notifications, install the application and the email client on the same server. Likewise, if
applications share settings and preferences (such as Microsoft Office), install them on the same server.
Advantages Disadvantages
Siloed It is easy to track the application’
s location and usage
Centralization makes it is easy
to configure and maintain the application
Other applications do not interfere
with the installed application
Can be useful for mission-
critical applications
Additional servers are required
to ensure sufficient redundancy
Nonsiloed Reduces the number of servers
required for applications in small-
to medium-sized farms
Might simplify user permissions
and ensure consistent settings
during application installation
A single server is accessed by each
user and session sharing is ensured
Cannot be used when
applications conflict with
other applications
By using features such as Load Manager and Preferential Load Balancing, you might not need to silo
mission-critical applications or applications with high levels of peak usage.
When an application conflicts with other applications, rather than silo it on one server, consider streaming
the application. Streaming the application effectively isolates it, which allows conflicting applications to run on
a single server, reducing the need for silos.
Planning Server Loads
Consider how you want to balance server loads. You might want to load balance resource-intensive,
mission-critical, or high-availability applications. XenApp offers two methods of load balancing:
Load Manager - Lets you balance new connections to the server. When a user launches the first
published application, that user session is established on the least loaded server in the farm, based
on criteria you configured. When the user launches a second application that is published on the
same server, the existing session is shared, and no load management occurs. However, if that
application is not published on the same server, Load Manager is invoked and another load-
balancing decision is made.
Load-balancing is enabled by default. When you publish an application on multiple servers, load
balancing automatically ensures that the user is sent to the least-loaded server.
Preferential Load Balancing - Lets you allocate a specific portion of CPU resources to a specific session
or application. You can use Preferential Load Balancing to assign importance levels (Low, Normal, or
High) to specific users and applications. For example, doctors in a hospital could be specified as
important users and MRI scans or X-rays could be specified as important applications. These
important users and applications with higher levels of service have more computing resources available
to them. By default, a Normal level of service is assigned to all users and applications. Different
application workloads can co-exist on a server; simply assign important applications a higher
importance level.
The key difference between the Load Manager and Preferential Load Balancing features is that the
Preferential Load Balancing can be used to treat each session differently, whereas Load Manager treats
each session the same.
Although you can use applications as the basis for Load Manager decisions, Citrix does not recommend it.
Citrix recommends invoking Load Manager based on the server only.
Citrix does not recommend load balancing across zones on a WAN.
Centralizing or Distributing Application Servers
For organizations with geographically dispersed sites, application servers might be located centrally with
the infrastructure servers (for example, in a data center) or decentrally, near the users who access
the applications or in the same geographic region as the users.
Citrix recommends placing application servers logically near any data sources. For example, for an
enterprise resource planning application, collocate those XenApp servers within the same data center.
Another example is a multinational corporation that uses Microsoft Exchange 2007 as the data source for
email. Although the company could centralize all the Exchange servers at the primary data center, they would
be more likely to enable the Exchange servers within each region and then locate the XenApp servers
hosting Outlook there as well.
Advantages Disadvantages
Servers centralized at
one site
Centralized server administration
and support.
Centralized application management.
Potentially better physical
security than in branch offices.
Single point of failure; if
the site loses
connectivity, users have
no alternative access.
Servers distributed
across multiple sites
Enhanced business continuity
and redundancy; if one site
loses connection, it does not
affect all application access.
When data is maintained at
different sites, placing servers
at those sites provides users
with local access to the data.
Sites can administer their
own servers.
Zone Preference and Failover can
be invoked if multiple zones.
Server-to-
server communication
crosses the WAN.
If users need access
to multiple sites, you
might need to coordinate
and replicate domains,
trusts, user profiles, and data.
Sites might need added
local administration
and support.
Determining How to Install Applications
In large farms, installing applications on servers can be time consuming. Also, applications on load-
balanced servers require identical configuration options and settings. To solve these issues, you can install
these applications by using Installation Manager, installation scripts, Microsoft System Center
Configuration Manager (formerly known as Systems Management Server (SMS)), or streaming the applications.
3.5. Determining the Number of XenApp Servers to Deploy
Updated: 2010-03-02
After you identify the applications you are delivering to your users and their methods of delivery, you
can estimate the number of XenApp servers required for your deployment.
For applications virtualized on the server, the number of servers required depends on the following factors:
The processing requirements of the applications and the processing capacity and available RAM of
your servers. To determine the processing requirements for an application, see its product documentation.
The native operating system of the applications. Running 32-bit applications on 64-bit operating
systems requires more RAM than running a 32-bit application on a 32-bit operating system.
Whether you are streaming applications to the server or installing the applications on the
server. Depending on the network topography and the application being delivered, a deployment
where applications are installed on the servers can service more users than a deployment with an
equal number of servers where the applications are streamed to the servers.
The size of the files with which your users work and how they use them.
Using this data you can roughly estimate the number of servers to deploy in your test farm.
After setting up your test farm, use Load Testing Services on the XenApp servers to simulate how your users
run applications on your servers. With Load Testing Services, you can track a variety of Perfmon counters,
such as Total Processor Time, Thread Queue Length, Memory Consumption, and Pages Per Second, to
determine the resource limits of the servers in your environment. This will help you determine the number
of servers to deploy in your production environment.
3.6. Deciding How Many Farms to Deploy
Updated: 2010-02-17
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 server-
to-server communication.
Site-based farms eliminate the need
to open firewall ports for server-to-
server communication.
Server-to-
server Communication
Data store information is synchronized
with member servers through
notifications and queries. When a farm
has multiple zones, data
collectors communicate dynamic
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.
information such as logons and
application use across the farm.
Management Tools You can monitor and configure the
farm from a single management
console and need to log on to only one
farm to do so.
You can monitor and configure
multiple farms from
management console.
Communicating with multiple farms
from the console requires logging on
to each farm.
Sharing Components Between Farms
Some Citrix components can be shared between multiple farms; consequently, it is not necessary to
consolidate all servers in one farm to prevent deploying these components multiple times:
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.
3.7. Planning Controllers
Updated: 2010-02-17
Regardless of your farm size, Citrix recommends having at least one server dedicated to controller
functions, which are deployment functions other than those related to running published applications.
Publishing applications on a controller slows down application enumeration. If you decide to install
controller 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 factor 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 controller 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 controller 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.
3.7.1. Planning the XenApp Data Store
Updated: 2010-05-07
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
The lists the databases you can use for the farm data store. For information System Requirements
about supported database versions, see . http://support.citrix.com/article/CTX114501
Choosing a Database
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 or Oracle
Whether or not you foresee the enterprise expanding, which would result in expanding the size
and maintenance of the database
Any database maintenance requirements, such as backup, redundancy, and replication
General recommendations are listed below, based on the following size table.
Small Medium Large Enterprise
Servers 1-50 25-100 50-100 100 or more
Named Users < 150 < 3000 < 5000 > 3000
Applications < 100 < 100 < 500 < 2000
Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all
large and enterprise environments. When deploying large farms across a WAN, you can obtain
a performance advantage by replicating the data store and distributing the load over multiple
database servers. SQL Server and Oracle are suitable for large farms and support replication.
Do not install XenApp on the SQL Server or Oracle database server.
SQL Server Express is suitable for all small and many medium environments located in one
physical location, which do not have branch offices across a WAN.
See the database product documentation for hardware requirements for the database server.
Important: Ensure that the data store is backed up regularly. If the data store database is lost, you
must recreate the farm. You cannot recreate the data store from an existing farm.
3.7.1.1. Database Server Hardware Performance Considerations
Updated: 2010-02-09
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 management console performance, how long
it takes to add (configure) and remove a server from the farm, and how long it takes to start multiple
servers simultaneously.
In the following chart, five sample farm configurations (A through E) are listed, with measurements of
various metrics in the farm.
Configuration A B C D E
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 5 5 5 5 5
Printer drivers installed per server 25 25 25 25 25
Network print servers with printers 5 5 5 5 5
Number of Load Manager load evaluators 10 10 10 10 10
Number of application folders in management console 10 10 10 10 10
Number of server folders in management c onsole 8 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 A B C D E
Dual Pentium 4/1.6GHz with 2GB RAM X X X
Dual Pentium 4/3.0GHz with 4GB RAM X X X X
Quad Pentium 4/3.0GHz with 4GB RAM X X X X X
The actual performance of a farm’s data store varies depending on the database engine and the level
of performance tuning achieved.
3.7.1.2. Replication Considerations
Updated: 2010-02-10
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 plug-in to access
the published management tools.
3.7.1.3. Planning for Configuration Logging and IMA Encryption
Updated: 2010-02-10
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 documentation contains more information about IMA Securing Server Farms
encryption, Configuration Logging, and when to enable these features.
To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the
key, use CTXKEYTOOL, which is available on the installation media.
For custom installations or provisioning servers in large environments, consider:
Deploying XenApp by using images, and including the key file as part of the server image
Generating a key, putting the key in a folder on your network, using a UNC path to specify the
location, and performing an unattended installation
If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.
3.7.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.
3.7.3. Designing Zones for a XenApp Deployment
Updated: 2010-02-03
A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All servers must belong
to a zone. Unless otherwise specified during XenApp Setup, all servers in the farm belong to the same
zone, which is named . Default Zone
Zones have two purposes:
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.
This illustration depicts a server farm with multiple zones. Each zone’s data collector communicates with the
other data collectors across the WAN link.
Because session and load information within a XenApp farm can become large in enterprise deployments—up
to several megabytes—to ensure a scalable and resilient XenApp farm, it is imperative that you design
zones based on your network topology.
XenApp member servers replicate their dynamic data to the ZDC designated for their zone. XenApp uses a
star topology for replication among zones—each ZDC replicates all of its zone dynamic data to all other ZDCs
in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.
When designing zones, the most important variables to consider are latency and bandwidth. The amount
of bandwidth and the impacts of latency are highly dependent on your XenApp deployment. The lower
the bandwidth and the higher the latency, the longer a farm takes to resynchronize the dynamic data
among zones after an election.
In farms distributed across WANs, zones enhance performance by grouping geographically related
servers together. Citrix does not recommend having more than one zone in a farm unless it has servers
in geographically distributed sites. Zones are not necessary to divide large numbers of servers. There are
1000-server farms that have only one zone.
Data collectors generate a lot of network traffic because they communicate with each other constantly:
Each zone data collector has an open connection to all data collectors in the farm.
During a zone update, member servers update the data collector with any requests and changed data.
Data collectors relay changes to the other data collectors. Consequently, data collectors have the
session information for all zones.
In general, Citrix recommends using the fewest number of zones possible, with one being optimal. If all
farm servers are in one location, configuring only one zone for the farm does not reduce performance or make
the farm harder to manage. However, in large networks, such as organizations with data centers on
different continents, grouping geographically-related servers in zones can improve farm performance.
Keep in mind that data collectors must replicate changes to all other data collectors in the farm. Also,
bandwidth consumption and network traffic increase with the number of zones.
Separate zones are not required for remote sites, even ones on separate continents; latency is the biggest
factor in determining if servers should be put in their own zone. For large farms with servers in
different geographic regions, create zones based on the location of significant numbers of servers.
Also decide if you want to configure failover zones or preferred zones. If a zone fails, you can configure for
user connections to be redirected to another zone (failover) or control to which zones specific users
connect (preference). Failover requirements might determine the number of zones required.
For example, an organization with 20 farm servers in London, 50 servers in New York, and three servers
in Sydney could create two or three zones. If the Sydney location has good connectivity to either New York
or London, Citrix recommends grouping Sydney with the larger location. Conversely, if the WAN
connection between Sydney and the other locations is poor or zone preference and failover is required,
Citrix recommends configuring three zones.
Consider these zone design guidelines:
Minimize the number of zones in your farm.
Create zones for major datacenters in different geographic regions.
If a site has a small number of servers, group that site in a larger site’s 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.
3.7.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 user’s 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.
3.8. Planning for Accounts and Trust Relationships
Updated: 2010-07-13
Consider how users will access resources. When multiple servers host the same published application, users
could be connected to any of these servers when they access the resource. Therefore, if a user does not
have permissions for all servers, the user might not be able to access the resource. To avoid these issues,
you might need to establish domain trust relationships between users or servers.
Also, in a farm with multiple, untrusted domains, when servers are load balanced, users can be routed to a
server in a domain in which they do not have access permissions. To ensure your users are routed only to
servers in domains in which they have access permissions:
Publish copies of an application in each domain, and allow users access only to the copy of the
application in the domain in which they have access permissions.
Create a Worker Group Preference and Failover policy that routes users to servers in domains in which
the users have access permissions.
System Account Considerations
Consider the following when deciding how to configure your Citrix administrator accounts:
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 Delivery
Services 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.
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 Web Interface
Enumerating users and groups
Resolving users or groups when adding users to published application, printer auto-creation lists,
or defining new Citrix administrators
Requests to enumerate applications are routed to a server that has the required domain trust relationship if
the originating server does not.
Substituting Domain Accounts for User Accounts
By default, XenApp creates local accounts to run the following XenApp services:
XenApp Service Default Local User Account
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 installation is not supported.
Install XenApp as a domain administrator to ensure the accounts are created correctly. If you are changing
the accounts for services and your farm has servers in multiple domains, the domains must have
trust relationships with each other.
3.9. Recommendations for Active Directory Environments
Updated: 2010-03-02
Citrix recommends the following configuration for server farms with Active Directory:
XenApp servers are in their own Organizational Units (OUs).
Create OUs for application silos, keeping servers from different silos organized in their own OUs. (You
can, however, create application silos that span multiple OUs.)
All servers reside in the same domain.
The server farm domain has no trust relationships with non-Active Directory domains, as this can
affect operations requiring trusted domains.
The server farm is in a single Active Directory forest. If your farm has servers in more than one
forest, users cannot log on by entering user principal names (UPNs).
UPN logons use the format @ . With Active Directory, UPN logons do not require username UPN identifier
a domain to be specified, because Active Directory can locate full UPN logons in the directory. However,
if the server farm has multiple forests, problems occur if the same UPN identifier exists in two domains
in separate forests.
Important: Citrix XenApp does not support UPN logons if a server farm spans multiple Active
Directory forests.
Active Directory User Permission
Active Directory security groups can affect authenticating to published applications or the management
console. The tables that follow contain best practice guidance.
Also, if a user is a member of a domain local group, the group is in the user’s 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 user’s logon request is sent to a server in the same domain as the domain local group.
Network configurations do not affect authentication to the management console because that console allows
only pass-through authentication.
Domain Global Groups
Authenticating to published applications No adverse effects
Authenticating to management console 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 management console
Recommendation: If a user is a Citrix administrator only by membership in
a domain local group, the user must connect the console to a server in the
same domain as the domain local group.
Rationale: If the user connects the console to a server in a different domain
than the domain local group, the user is denied access to the console
because the domain local group is not in the user’s security token.
Universal Groups
Authenticating to
published applications
Recommendation: If universal groups are assigned permission to the
application, all servers that manage the application must be in an
Active Directory domain.
Rationale: A server in a non-Active Directory domain could authenticate the
user to run the application. In this case, universal groups are not in the 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 management console
Recommendation: If a user is authenticating to the console and is a
Citrix administrator only by membership in a universal group, the console
must connect to a server that belongs to an Active Directory domain in
the universal group’s forest.
Rationale: Non-Active Directory domain controllers and domains outside
a universal group’s forest have no information about the universal group.
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:
When installing XenApp on each server in your farm, ensure the port sharing with IIS option and
ensure that IIS is configured to support HTTPS; see for more information. System Requirements
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.
3.10. 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.
3.11. Planning for UAC
Updated: 2010-02-10
Consider the following suggestions if you will be installing XenApp on a system with User Account control
(UAC) enabled.
Instruct the Windows server to elevate the UAC level automatically, without prompting, by configuring
a Local Security Policy setting.
Instruct Windows to elevate the UAC level without prompting, through an Active Directory Default
Domain Policy. This avoids having to enable this setting on each server before installation, provided
you join the domain before installing XenApp. When a computer joins the domain, the domain policy
is applied automatically.
Enable the role so you can manage printer drivers and print queues on clients. Print Services
The following XenApp management features and tools require users be domain administrators,
delegated administrators, or part of the Administrators group on the local computer:
Delivery Services Console
XenApp Commands
SSL Relay tool
Speedscreen Latency Reduction Manager
These permissions are in addition to any requirements for the feature, such as having a Citrix
administrator account.
To allow multiuser access to an application, install the application as a built-in administrator or enable the
setting when prompted by UAC. Create Users
3.12. Planning for Shadowing
Updated: 2010-02-10
Session shadowing monitors and interacts with user sessions. When you shadow a user session, you can
view everything that appears on the user’s session display. You can also use your keyboard and mouse
to remotely interact with the user session. Shadowing can be a useful tool for user collaboration,
training, troubleshooting, and monitoring by supervisors, help desk personnel, and teachers.
Shadowing is protocol-specific. This means you can shadow ICA sessions over ICA and Remote Desktop
Protocol (RDP) sessions over RDP only. Shadowing is a server-level setting.
Important: By default, shadowing is enabled. Shadowing restrictions are permanent. If you
disable shadowing, or change shadowing features when configuring XenApp, you cannot change those
settings later. You must reinstall and reconfigure XenApp on the server to change shadowing restrictions.
Any user policies you create to enable user-to-user shadowing are subject to the restrictions you place
on shadowing during XenApp configuration.
Citrix does not recommend disabling shadowing as a substitute for user and group connection policies.
3.13. Securing Delivery and Access
Updated: 2010-02-10
XenApp allows secure access to resources by users. It also enables administrators to control and monitor
access to each resource and component. See the documentation for details. 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 user’s 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: XenApp installation and configuration opens Windows firewall ports to allow incoming
connections, such as those from ICA traffic, Citrix Independent Management Architecture service, the
Citrix XML Service, and SQL Server Express (if that database is specified during XenApp configuration).
3.14. Planning for Supported Languages and Windows MUI Support
Updated: 2010-10-19
XenApp 6 supports all languages of Windows Server (both native and Language Packs), providing six XenApp
user interface languages. The XenApp user interface language is selected based on the language locale set in
the Windows Server operating system when XenApp is installed. The following table indicates which XenApp
user interface language is installed for each Windows System Language locale setting.
Windows Server 2008 R2 Language Locale XenApp User Interface Language
English and languages other than those listed
in this table
English
French French
German German
Japanese Japanese
Simplified Chinese Simplified Chinese
Spanish Spanish
Before installing XenApp, install the target Windows Language Pack on the Windows Server, and change
the language options (such as system locale and display language) to the target language. For information
about installing the Language Pack and changing language options, see the Microsoft documentation.
(Changing the Windows system locale after installing and configuring the XenApp server role may cause
data store issues.)
3.15. Planning for Passthrough Client Authentication
Updated: 2010-02-10
Citrix recommends enabling . When the user connects to applications passthrough client authentication
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 Citrix online plug-in on each
XenApp server. If you are deploying the plug-in as the client for users, install the plug-in on your server as
the passthrough client.
4. Installing and Configuring XenApp
Updated: 2010-03-01
XenApp installation and configuration are separate tasks available through a graphical user interface or
command line.
For a wizard-based XenApp installation or configuration, use the Server Role Manager.
For a command-line installation, use the XenAppSetupConsole command to install XenApp roles and
the XenAppConfigConsole command to configure XenApp roles.
This task division provides flexibility when using provisioning tools and disk imaging:
Use startup scripts to install and configure XenApp when a disk image is launched.
Install XenApp on the disk image and use startup scripts to configure XenApp when the instance
is launched.
Install and configure XenApp on the disk image and run startup scripts that modify the configuration
when the image is launched. You can use this option to modify your XenApp configuration on the
fly, without having to reconfigure or reimage disks.
For information about provisioning and imaging using Citrix products, see the Citrix Web site.
Using the Server Role Manager
XenApp for Windows Server 2008 R2 uses for XenApp features and technologies. The XenApp Server roles
Role Manager provides a graphical user interface that guides you through installing (that is, adding)
certain XenApp roles, using the Server Role Installer. In addition to expediting prerequisite and role
installation, this tool detects the deployment phase for each role and displays the next task required to
complete the installation and configuration of that role. From the Server Role Manager, you can:
Add server roles
Launch installers for partially-integrated roles
Automatically install many role prerequisites
Launch configuration tools such as the XenApp Server Configuration Tool to configure the XenApp server
Initiate a XenApp server restart (reboot)
You can run the XenApp Server Role Manager at any time. It initially runs from the XenApp installation
media. After you install a role, the Server Role Manager is installed locally, and runs every time you log on to
the XenApp server (you can disable this feature by selecting a checkbox on the main Server Role Manager
page). You can also rerun it from its Program Files location (Program Files
(x86)\Citrix\XenApp\ServerRoleManager\XenAppServerRoleManager). If a Server Role Manager is installed
locally and you invoke a different one from the XenApp installation media, the version on the installation media
is used.
Each XenApp role has an integration level:
Integration Level Description
Full Role prerequisites and the role software install automatically. Fully integrated
roles include XenApp, Citrix License Server, Web Interface, Single sign-on service,
and Provisioning Server.
Partial Role prerequisites install automatically. The role is added to the Server Role
Manager task list, where you can launch the role installer (that is, the wizard for
that role). Partially integrated roles include Secure Gateway, Power and
Capacity Management Administration, SmartAuditor Server, and EdgeSight Server.
Information-only
or media-only
Roles you cannot install using the Server Role Manager. Information-only roles
include Merchandising Server, which is a virtual appliance that requires a
virtual machine.
The XenApp installation media contains installation files for media-only roles. See
the role documentation for installation instructions.
Using the Command Line
For command-line installation or configuration, enter the command with valid options and properties at
a Windows Server command prompt.
4.1. Preparing to Install and Configure XenApp
Updated: 2010-08-20
Review the XenApp Readme for late-breaking issues.
You must be in the Administrators group to install and configure the XenApp software. (Elevating your privilege
to local administrator through User Account Control is not a substitute for Administrators group membership.)
Important: Do not install XenApp on a domain controller. Citrix does not support installing XenApp on
a domain controller.
To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your
users, install the most recent version of any plug-ins you use.
1.
2.
3.
4.
When installing roles or role components other than XenApp server, see the role documentation for details
about information requested during installation and configuration.
Important: Do not join servers running XenApp 6 for Windows Server 2008 R2 to a deployment with
servers running previous versions of XenApp.
Note: To prepare XenApp for server imaging and provisioning, you can use the XenApp Server
Configuration Tool included on the XenApp 6 for Windows Server 2008 R2 installation media. However,
the preparation process is streamlined and more effective if you use the updated XenApp Server
Configuration Tool, which you can install on the server with . If you install the updated CTX124981
XenApp Server Configuration Tool after you install XenApp, you must use the same user account that was
used to install XenApp.
Before Installing XenApp
Review the installation process (wizard-based or command-line) to learn what information you
must provide.
Review the system requirements for the XenApp server and for other roles you plan to install.
Wizard-based installations include automatic installation of prerequisite software and
required Windows roles.
For command-line installations, you must install the prerequisite software and Windows roles
before initiating XenApp installation. You can deploy prerequisites with PowerShell cmdlets,
the Microsoft ServerManagerCmd.exe command, or the Microsoft Deployment Image Servicing
and Management (DISM) tool.
Ensure the Microsoft Windows Server has the latest Microsoft hotfixes and that the operating system
clock has the correct time.
Prepare for Windows Multilingual User Interface (MUI) support, if needed.

Important: By default, the XenApp server installation process creates install logs in the
user's temporary directory (%TEMP%). On Windows Server 2008 R2 servers, the session's
temporary directory is deleted by default when the server restarts. If you encounter problems
during installation or want to preserve those log files, use one of the following options:
Copy the logs from the %TEMP% location to a safe place before the server restarts.
Before installing the XenApp server role, change your local computer policy to prevent deletion
of the temporary directories.
Go to , then type . > Start Run gpedit.msc
Navigate to > > Computer Configuration Administrative Templates
> > Windows Components Remote Desktop Services Remote Desktop Session Host
. > Temporary folders
Verify that is set. Do not delete temp folder upon exit
Restart the server.
For a command-line installation, use the option to specify an installation log file in /logfile:path
a different directory.
Before Configuring XenApp
Review the configuration process (wizard-based or command-line) to learn what information you
must provide.
During configuration, you specify the database to be used for the XenApp farm data store: Microsoft
SQL Server Express, Microsoft SQL Server, or Oracle. See for supported versions. CTX114501
If you use a Microsoft SQL Server Express database, XenApp configuration installs it automatically.
If you use a Microsoft SQL Server or Oracle database, install and configure the database
before initiating XenApp configuration. (For an Oracle database, this includes installing an
Oracle client on the XenApp server and restarting the server.)
1.
2.
3.
4.
5.
6.
7.
8.
9.
If you use a Microsoft SQL Server or Oracle database for the farm data store, and use command-
line XenApp configuration, create a Data Source Name (DSN) file before configuring XenApp. (A
wizard-based configuration creates the DSN file for you.) Each server in the farm must have the DSN
file. You can create the file and copy it to other servers, or put it on a network share, provided you
remove the value for any workstation-specific information (such as the Oracle WSID). Use the /DsnFile:
option to specify the file location on the XenApp configuration command line. dsn_file
If you plan to use the Configuration Logging feature and encrypt the data being logged, you must load
the encryption key on servers that join the farm after configuring XenApp but before restarting the server.
4.2. Installing XenApp Using the Wizard-Based Server Role Manager
Updated: 2010-03-01
To install XenApp using the wizard-based Server Role Manager:
On the installation media, double-click . The Autorun menu launches. autorun.exe
Select . The Server Role Manager launches and checks if any roles are Install XenApp Server
already installed.
Select . Add server roles
Select your XenApp edition.
Accept the End User License Agreement.
Select the roles you want to add. (The Server Role Manager displays only the roles supported in
the XenApp edition you selected. Some roles may require current Subscription Advantage membership.)
Select role subcomponents.
Roles may have default and optional components such as management tools, plug-ins, or agents.
Certain subcomponents may be selected by default when you select a role to add.
For example, when you select the XenApp role, the XenApp Management subcomponent is selected
by default; this subcomponent includes the Delivery Services Console. If you prefer not to install
the console on this server, you can deselect it. You can also select other available role subcomponents.
If you are installing the XenApp role, the Optional Components list includes XML Service IIS
Integration. When selected, the Citrix XML Service and IIS share a port (default = 80).
If the server on which you are installing XenApp has IIS installed, the XML Service IIS
Integration component is selected by default.
If IIS is not installed, the component checkbox is not selected. In this case, if you select
the checkbox, the Server Role Installer installs IIS. (If you do not install the XML Service
IIS Integration component, the Citrix XML Service defaults to standalone mode with its own
port settings, which you can configure using the XenApp Server Configuration Tool.)
The Citrix online plug-in and Citrix offline plug-in are installed automatically when you install the
XenApp role. These plug-ins do not appear in the components lists, and you cannot disable
these installations during a wizard-based installation.
Review the prerequisites summary, which indicates which role or subcomponent needs the
prerequisite, and whether the Server Role Installer installs it or you must install it. For software you
must install, the display indicates whether the XenApp installation media contains the software or you
must obtain it elsewhere.
Review the summary, which lists the selected roles and subcomponents to be installed or prepared. It
also lists prerequisites which will be automatically deployed for all selected roles.
After you click , a display indicates installation progress and the result. Install
Important: When installing the XenApp role, the IMA Service is not started, nor are any configuration
options set, such as creating or joining a farm and data store database information.
After the installation result displays and you click , the Server Role Manager task list displays. For each Finish
role you selected, the task list indicates the next task necessary for installation or configuration.
For installed fully integrated roles that require configuration, click to launch the Configure
configuration tool for that role.
For partially integrated roles, click to launch the installer for that role. See the role Install
documentation for details.
4.3. Installing XenApp from the Command Line
Updated: 2010-08-03
Command Syntax
On the server where you want to install XenApp or other roles, from the "XenApp Server Setup\bin\" directory
on the XenApp media, type the following at a command prompt:
XenAppSetupConsole.exe options_properties
Options and Properties
/help
Displays command help.
/logfile:path
Path for the log file generated during the installation.
/install:items
Comma-delimited list of components, features, or technologies to install. Valid values are:
. EdgeSight Server. EdgeSightServer
. Citrix Licensing Server. Licensing
. Merchandising Server. MerchandisingServer
. Power and Capacity Management administration components. PCMAdmin
. Provisioning Services. Provisioning
. Secure Gateway. Secure Gateway
. SmartAuditor server. SmartAuditorServer
. Single sign-on service. SsonService
. Web Interface. WebInterface
. XenApp server. XenApp
If you select XenApp, the Delivery Services Console, Citrix online plug-in, and Citrix offline plug-
in are installed by default. You can also specify one or more of the following options to
install, separated by commas. If you do not specify an option, it is not installed.
Option Description
XA_IISIntegration If the server has IIS role services installed, this option
is installed by default and the Citrix XML Service and
IIS share a port (default = 80). If the server does not
have the IIS role services installed, XA_IISIntegration is
not installed by default, and the Citrix XML Service
defaults to standalone mode with its own port
settings, which you can change during XenApp configuration.
EdgeSightAgentFeature EdgeSight agent.
SmartAuditorAgentFeature SmartAuditor agent.
SSONAgentFeature Single sign-on plug-in.
PCMAgentFeature Power and Capacity Management agent.
PVDeviceFeature Provisioning Services target device.
/exclude:items
(Valid only when installing the XenApp server) Comma-separated list of sub-features to be omitted
1.
2.
3.
from the installation. Valid values are:
. Omits the automatic installation of the Delivery Services Console when you install XA_Console
the XenApp role.
. Exclude this sub-feature if the server has IIS role services installed, but XA_IISIntegration
you choose to use a nondefault XML port (default = 80) for your installation. If the server has
the IIS role services installed and you do not specify /exclude:XA_IISIntegration, the default
XML port is selected and you cannot reconfigure this setting later.
/edition
Specifies the XenApp edition. Valid values are:
Platinum
Enterprise
Advanced
If no edition is specified, the default is /Platinum.
/logfile:path
Specifies where to create a log file.
INSTALLDIR=directory
Specifies where to install the items. Default: C:\Program Files\Citrix
ONLINE_PLUGIN_INSTALLDIR=directory
Specifies where to install the Citrix online plug-in. Default: C:\Program Files\Citrix\ICA Client
Examples
The following command installs the XenApp server Platinum Edition in its default location.
XenAppSetupConsole.exe /install:XenApp /Platinum
The following command installs the XenApp server Platinum edition and the Web Interface in C:
\Program Files\Citrix (which is the default location).
XenAppSetupConsole.exe /install:XenApp,WebInterface
INSTALLDIR=C:\Program Files\Citrix
The following command installs the XenApp server Platinum Edition and the Single sign-on plug-in, and
excludes installation of the Delivery Services Console.
XenAppSetupConsole.exe
/install:XenApp,SSONAgentFeature /exclude:XA_Console
4.4. Configuring XenApp Using the Wizard-based Server Configuration Tool
Updated: 2010-05-07
Note: This procedure applies to configuring XenApp servers for the first time, unless otherwise indicated.
To configure XenApp using the wizard-based Server Configuration Tool:
Access the XenApp Server Role Manager.
The XenApp Server Role Manager runs every time you log on to the XenApp server, unless you disable
that feature. You can run the XenApp Server Role Manager from Program Files
(x86)\Citrix\XenApp\XenAppServerRoleManager\XenAppServerRoleManager.
In the XenApp Server Role Manager task list, click under XenApp. The Server Configure
Configuration Tool launches.
Indicate the task you want to perform. If you have not yet configured the XenApp server role, you
can create a farm or add the server to (join) an existing farm. The remainder of this procedure
assumes you are creating a new farm or adding a server to an existing farm; see the Note for
3.
4.
5.
6.
7.
8.
information about other scenarios.
When you install XenApp for Windows Server 2008 R2 on the first server, that server is where
you create a new farm.
After you install XenApp on other servers, you add each server to (join) an existing farm.
Note:
If you previously configured the XenApp server role, and you are using the XenApp
Server Configuration Tool from the XenApp 6 for Windows Server 2008 R2 installation media,
you can create a farm, add the server to (join) an existing farm, or leave (remove the
server from) the farm. If you choose to create a farm or add the server to an existing farm,
the server will be removed from its current farm before creating or joining another farm.
If you previously configured the XenApp server role, and you installed the updated XenApp
Server Configuration Tool, you can prepare the server for imaging and provisioning, or
leave (remove the server from) the farm.
When creating a farm, on the page: Enter basic information
Enter a farm name, up to 32 characters (can include spaces). If you are using Oracle as
your Configuration Logging database, do not use hyphens in the farm name.
Specify the domain and username for a user who will be the first Citrix administrator.
The administrator has full permissions to the farm and can create additional administrator accounts.
When creating a farm, specify Citrix License Server information. Choose one of the options:
To use an existing license server, enter the license server name. By default, the license server
uses port 27000 unless you deselect that option and specify a different port number.
Defer specifying license server information.
For complete information, see the licensing documentation.
Select the data store database type and connection information.
If you choose
the entry for
Action
New database When creating a farm, the Server Configuration Tool installs the Microsoft
SQL Server Express database automatically, with the instance
name CITRIX_METAFRAME and database name MF20; the database
uses Windows authentication.
Existing Microsoft
SQL Server database
You are prompted for the instance name, the database name, and
the authentication method. This database can be located on a remote
SQL server.
Existing
Oracle database
You are prompted for the Net Service name. (The Oracle entry appears only
if the Oracle client is installed on the server where you are configuring
the XenApp role.)
Specify the database credentials. Specify the user name in the form <DBMACHINE>\<USER>
or <DOMAIN>\<USER>.
SQL Server Express requires an existing Windows account, but it does not need to be a server or
system administrator. The XenApp Server Configuration Tool adds two database administrators to
SQL Server Express: (local)\administrators and the supplied credentials for the local or domain user.
When adding a server to (joining) a farm, you can optionally test the connection to the database.
The result does not affect Server Configuration Tool operations.
The default session shadowing settings (which allow shadowing) are recommended for most
8.
9.
farms. Shadowing settings supplied during XenApp configuration override system or domain policy for
user-to-user shadowing.
Important: Shadowing features are permanent and should be changed only if you wish to
permanently prevent system or domain policy from affecting that setting. If you disable shadowing
or change shadowing features during configuration, you cannot reconfigure them later.
Option Description
Prohibit shadowing
of user session on
this server
Disables user session shadowing on this server. If selected,
shadowing cannot be enabled on this server through policies. Default
= unselected
Allow shadowing of
user sessions on
this server
Enables user session shadowing on this server. Default = selected
When you enable shadowing, you can apply the following
features (default = all unselected):
. If selected: Prohibit remote control
Authorized users can view sessions but do not
have keyboard and mouse input
Remote control is permanently prohibited; this cannot
be enabled on this server through policies.
. If selected: Force a shadow acceptance prompt
Authorized users must send an acceptance prompt
when attempting to shadow a session.
A shadow acceptance prompt is shown on every
shadowing attempt; this cannot be disabled on this
server through policies.
. If selected: Force logging of all shadow connections
All shadowing attempts, successes, and failures are
logged in the Windows event log.
Shadow connections are always logged; this cannot
be disabled on this server through policies.
If you do not change the following server settings, the Server Configuration Tool uses default values.
Setting Description
License Server
(Displays only when adding a server to (joining) a farm). Choose one
of the options:
Enter the name of an existing license server name
(NetBIOS computer name, fully-qualified domain name (FQDN),
or IP address). By default, the license server uses port
27000 unless you deselect that option and specify a different
port number.

(Default) To use the global farm settings for the license
server, select this option.
Zone The default zone name is ‘Default Zone.’ To create a custom zone
name, select the checkbox and enter the name.
XML Service By default, XenApp server role installation configures the Citrix
9.
10.
11.
XML Service and Internet Information Service (IIS) to share the
same TCP/IP port (80) for communications. In this case, you
cannot change the XML Service setting. See System Requirements
for more information.
Online plug-in
Server name or URL of the Web Interface server used by the Citrix
online plug-in.
Remote Desktop Users
Only members of the Remote Desktop Users group can connect
to published applications. Until you add users to this group,
only administrators can connect remotely to the server. Select one
or more of the following.
. Adds anonymous users to the Add Anonymous users
Remote Desktop Users group. Default = selected
. Adds current (and future) Add the Authenticated users
domain accounts in the Windows Users group to the
Remote Desktop Users group. Default = unselected
. Adds all Add the list of users from the Users group
current users from the Users group to the Remote Desktop
Users group. If you add users later, you must add them
manually to the Remote Desktop Users group. Default = selected
If you installed the plug-in (or agent) for Single sign-on, SmartAuditor, EdgeSight, or Power and
Capacity Management on this server, specify the requested information to enable communications
with them. (The plug-in (or agent) roles use separate tools for their configuration.)
Review the summary page and click . Apply
After configuration completes, you are returned to the XenApp Server Role Manager task list, which indicates
if any requirements remain, such as a server restart. The XenApp Server Role Manager updates the task list
after any task completes.
To initiate a server restart, click . Reboot
To change a role configuration, click . Edit Configuration
4.5. Configuring XenApp from the Command Line
Updated: 2010-05-07
Note: The topic lists and describes all XenApp configuration command-line options. This Command Syntax
topic contains information about using the XenApp configuration command and its options.
Command Conventions
Several options use Boolean values (true or false).
If you omit an option that requires a Boolean value, the default value is used. For example, if you do
not include the /AddLocalAdmin:True|False option in the command, the default value (false) is used
(that is, a local administrator is not added).
If you specify an option that requires a Boolean value but you omit the value, the option default value
is true. For example, for the /AddLocalAdmin:True|False option, if you specify only /AddLocalAdmin
(with no :True or :False value), the option is true (that is, a local administrator is added).
You can use environment variables to represent one or more command-line options. For example, you can
group the standard Pause, Confirm, and NotStrict options as a single environment variable. You can also
use environment variables in the command-line option values. For example, /ServerName:%
currentServer%, where currentServer is defined as an environment variable.
Command Option Categories
The following table lists options that affect the same subject, feature, or object. It also indicates when an
option is required. (The table does not contain option arguments; see for full Command Syntax
option descriptions.)
Subject, Feature, or Object Options
Configuration process
/NotStrict
/Confirm
/Pause
/LogFilename
XML Service Information
/CustomXMLServicePort
General farm information
/ExecutionMode - required when creating, joining, or leaving a farm
/FarmName - required when creating a farm
/CitrixAdministratorAccount - required when creating a farm
/LicenseServerName
/LicenseServerPort
/ZoneName
/AddLocalAdmin
Database used for the
XenApp farm data store
/SqlExpressRootDir
/SimpleDB - this option and /DsnFile are mutually exclusive
/ServerName - required when joining a farm if you specified
/SimpleDB when creating the farm
/DsnFile - required when creating or joining a farm if you are using
a SQL Server or Oracle database; this option and /SimpleDB
are mutually exclusive
/AuthenticationType
/OdbcUserName - required when creating and joining a farm
/OdbcPassword - required when creating and joining a farm
If you use a Microsoft SQL Server Express database, you can
simplify configuration by using the /SimpleDB option when creating
the XenApp farm. When joining a farm that uses a Microsoft SQL
Server Express database, use the /ServerName: option to server_name
specify the name of the XenApp server on which you created the farm.
Session shadowing
Shadowing is enabled by default.
Important: Citrix recommends using the default values (that is, do
not specify them in this command). Shadowing settings specified
during XenApp configuration override system or domain policy for user-to-
user shadowing. Shadowing features are permanent and should be
changed only if you wish to permanently prevent system or domain
policy from affecting that setting. If you disable shadowing or
change shadowing features during configuration, you cannot reconfigure
them later.
/ProhibitShadowing
/ProhibitRemoteControl
/ForceShadowPopup
/ForceShadowLogging
Remote Desktop Users Group
/AddAnonymousUsersToRemoteDesktopUserGroup
/AddUsersGroupToRemoteDesktopUserGroup
/AddAuthenticatedUsersToRemoteDesktopUserGroup
XenApp image preparation
and provisioning
ExecutionMode:ImagePrep
Requires the updated XenApp Server Configuration Tool; see . CTX124981
Return Codes
The XenAppConfigConsole command supports the following return codes:
Value Meaning
0 Success
1 Invalid command-line options - for example, the command includes the options /ServerName:
and /ExecutionMode:Create (an option that is valid only when joining a farm server_name
was specified when creating a farm)
2 Unmatched parameters - an unrecognized option was specified
3 Invalid parameters - for example, for an option that requires a Boolean value (that is, True
or False), you specified 'Bob'
4 Commit failed - the configuration process did not complete; check the log file for details
Mapping of Earlier XenApp Version Properties to Options
Earlier XenApp versions supported installation and configuration properties. Some of those properties
have equivalent options in XenApp for Windows Server 2008 R2.
Property in Earlier XenApp Version Option in XenApp for Windows Server 2008 R2
CTX_MF_FARM_SELECTION /ExecutionMode
CTX_MF_NEW_FARM_NAME /FarmName
CTX_MF_DOMAIN_NAME, CTX_MF_USER_NAME /CitrixAdministratorAccount:domain\user
CTX_MF_SILENT_DSNFILE /DsnFile
CTX_MF_ODBC_USER_NAME /OdbcUserName
CTX_MF_ODBC_PASSWORD /OdbcPassword
CTX_MF_LICENSE_SERVER_NAME /LicenseServerName
CTX_MF_LICENSE_SERVER_PORT /LicenseServerPort
CTX_MF_ZONE_NAME /ZoneName
CTX_MF_XML_PORT_NUMBER, CTX_MF_XML_CHOICE /CustomXmlServicePort
CTX_MF_SHADOWING_CHOICE:yes /ProhibitShadowing:false
CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA /ProhibitRemoteControl
CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION /ForceShadowPopup
CTX_MF_SHADOW_PROHIBIT_NO_LOGGING /ForceShadowLogging
CTX_MF_ADD_ANON_USERS /AddAnonymousUsersToRemoteDesktopUserGroup
CTX_MF_CREATE_REMOTE_DESKTOP_USERS /AddUsersGroupToRemoteDesktopUserGroup
4.5.1. Command Syntax
Updated: 2010-05-07
Command Syntax
On the server where the XenApp server role is installed, from C:\Program Files (x86)
\Citrix\XenApp\ServerConfig, type the following at a command prompt:
XenAppConfigConsole.exe [ ] options
Options
/help
Displays command help.
/NotStrict
Allows the executable to continue processing even if options do not apply in the current context.
/Confirm
Displays a confirmation message before modifying the server. This can be useful when testing for
correct use of command options.
/Pause
Pauses the executable after processing completes. This prevents the command prompt from closing
when launching the command from a batch file.
/LogFilename:file
Logs the progress of the executable to a log file. In the log, the symbols >> indicate a function call;
the symbols << indicate a function return
/SqlExpressRootDir:sql_express_install_src_dir
Specifies the location of the SQL Server Express source installation directory. Default = C:\Program
Files (x86)\Citrix\XenApp\ServerConfig\SqlExpress_2008.
/ExecutionMode:Create | Join | Leave | ImagePrep
Specifies the task you want to perform. If you have not yet configured the XenApp server role, you
can create a farm or add the server to (join) an existing farm.
Task Description
Create If you have not yet configured the XenApp server role on this server: After
you install XenApp on the first server, that server is where you Create a new
farm during configuration and add the server to the farm.
If you previously configured the XenApp server role on this server, specifying
Create removes the server from its current farm before creating another farm.
Join If you have not yet configured the XenApp server role on this server: After
you install XenApp on other servers, you Join a farm when you configure each
of those servers and add each server an existing farm.
If you previously configured the XenApp server role on this server, specifying
Join removes the server from its current farm before joining another farm.
Leave (Valid only if you previously configured the XenApp server role on this server to
join an existing farm) Specify Leave if you want to remove the server from the farm.
ImagePrep (Valid only with the updated XenApp Server Configuration Tool and if you
previously configured the XenApp server role on this server to join an existing
farm) For information about this task, see Preparing for XenApp 6 Imaging
. and Provisioning
/FarmName:farm_name
Valid only with /ExecutionMode:Create) Specifies the farm name, up to 32 characters (can include
spaces). If you are using Oracle for the Configuration Logging database, do not use hyphens in the
farm name.
/CitrixAdministratorAccount: \ domain_name user_name
(Valid only with /ExecutionMode:Create) Specifies the domain and username for the user who will be
the first Citrix administrator. The administrator has full permissions to the farm and can create
additional administrator accounts.
/SimpleDB
Indicates the farm uses a SQL Server Express database for the data store.
/ServerName:server_name
(Valid only with /ExecutionMode:Join and /SimpleDB) Specifies the name of the server where the
XenApp farm was created (that is, where the SQL Server Express database was installed).
/DsnFile:dsn_file
Specifies the path to the DSN file used to connect to the data store.
/AuthenticationType:Windows | Sql
(Valid only when using a SQL Server database for the farm data store) Specifies the authentication
type. Default = Windows
/OdbcUserName:odbc_user_name
Specifies the database user name in the form <DBMACHINE>\<USER> or <DOMAIN>\<USER>.
SQL Server Express requires an existing Windows account, but it does not need to be a server or
system administrator. XenApp configuration adds two database administrators to SQL Server
Express: (local)\administrators and the supplied credentials for the local or domain user.
Specify the database user password with the /OdbcPassword option.
/OdbcPassword:odbc_password
Specifies the database user password.
Specify the database user name with the /OdbcUserName option.
/LicenseServerName:license_server_name
Specifies the name of the existing license server.
/LicenseServerPort:license_server_port
Specifies the license server port. Default = 27000
/ProhibitShadowing:True | False
Disables or enables session shadowing. Default = False (shadowing is enabled)
Important: Citrix recommends using the default values (that is, do not specify them in this
command). Shadowing settings specified during XenApp configuration override system or domain
policy for user-to-user shadowing. Shadowing features are permanent and should be changed only if
you wish to permanently prevent system or domain policy from affecting that setting. If you
disable shadowing or change shadowing features during configuration, you cannot reconfigure them later.
/ProhibitRemoteControl:True | False
(Valid only if shadowing is enabled) Prohibits or allows remote control shadowing. When this option is
true, authorized users can view sessions but do not have keyboard and mouse input. Default = False
Important: Citrix recommends using the default values (that is, do not specify them in this
command). Shadowing settings specified during XenApp configuration override system or domain
policy for user-to-user shadowing. Shadowing features are permanent and should be changed only if
you wish to permanently prevent system or domain policy from affecting that setting. If you
disable shadowing or change shadowing features during configuration, you cannot reconfigure them later.
/ForceShadowPopup:True | False
(Valid only if shadowing is enabled) Enables or disables sending a shadowing acceptance popup. When
this option is true, authorized users must send an acceptance prompt when attempting to shadow
a session. Default = False
Important: Citrix recommends using the default values (that is, do not specify them in this
command). Shadowing settings specified during XenApp configuration override system or domain
policy for user-to-user shadowing. Shadowing features are permanent and should be changed only if
you wish to permanently prevent system or domain policy from affecting that setting. If you
disable shadowing or change shadowing features during configuration, you cannot reconfigure them later.
/ForceShadowLogging:True | False
(Valid only if shadowing is enabled) Enables or disables logging of all shadow connections. When this
option is true, all shadowing attempts, successes, and failures are logged to the Windows event
log. Default = False
Important: Citrix recommends using the default values (that is, do not specify them in this
command). Shadowing settings specified during XenApp configuration override system or domain
policy for user-to-user shadowing. Shadowing features are permanent and should be changed only if
you wish to permanently prevent system or domain policy from affecting that setting. If you
disable shadowing or change shadowing features during configuration, you cannot reconfigure them later.
/ZoneName:zone_name
Specifies the zone name. Default = Default Zone
/CustomXmlServicePort:port_number
Specifies the port number to be used by the Citrix XML Service. By default, the Citrix XML Service
and Internet Information Service (IIS) use the same TCP/IP port (80) for communications. Specify
this option if you do not want those services to share the port (for example, if you install the Citrix
XML Service on a dedicated XML server). See for more information. Default = 80 System Requirements
/SkipXmlSetting:True | False
When this option is true, the Citrix XML service and IIS port numbers are not configured (that is,
the default port 80 is not used). Default = False
/AddAnonymousUsersToRemoteDesktopUserGroup:True | False
Enables or disables adding anonymous users to the Remote Desktop Users group. Default = True
/AddUsersGroupToRemoteDesktopUserGroup:True | False
Enables or disables adding all current users from the Users group to the Remote Desktop Users group.
If you add users later, you must add them manually to the Remote Desk-top Users group. Default = True
/AddAuthenticatedUsersToRemoteDesktopUserGroup:True | False
Enables or disables adding current (and future) domain accounts in the Windows Users group to
the Remote Desktop Users group. Default = False
/AddLocalAdmin:True | False
Enables or disables creation of Citrix administrator accounts for all user accounts in the local
Administrators group. Default = False
/SmartAuditorServerName:smart_auditor_server_name
(Required if you installed the SmartAuditor agent on the XenApp server) Specifies the name of
the SmartAuditor server.
/SsoPluginUncPath:path_to_central_store
UNC path to Single sign-on central store. Default = use Active Directory
/OnlinePluginServerUrl:wi_url_or_servername
Server name or URL of the Web Interface server used by the Citrix online plug-in.
/PcmFarmName:pcm_farm_name
Power and Capacity Management farm name.
/PcmWorkloadName:pcm_workload_name
Power and Capacity Management workload name.
1.
2.
3.
4.
5.
EdgeSightCompanyName:edgesight_company_name
EdgeSight company name.
/EdgeSightServerName:edgesight_server_name
EdgeSight server name.
/EdgeSightServerPort:edgesight_server_port
EdgeSight server port. Default = 80
/RemoveCurrentServer:True | False
(Valid only with /ExecutionMode:ImagePrep and updated XenApp Server Configuration Tool) Enables
or disables removing the current server intance from the XenApp farm. Default = True
/PrepMsmq:True | False
(Valid only with /ExecutionMode:ImagePrep and updated XenApp Server Configuration Tool) Enables
or disables resetting the MSMQ ID during resealing. Default = True
4.6. Preparing for XenApp 6 Imaging and Provisioning
Updated: 2010-05-14
Primary deployment methods for XenApp servers include server imaging, virtualization, and provisioning.
In XenApp 6 for Windows Server 2008 R2, XenApp server role installation and configuration are separate
tasks; this offers flexibility in deciding when to capture (create) XenApp images.
Provisioning a XenApp server uses one of three typical approaches; the approach you use depends on when
you configure XenApp (earlier or later) in your preparation steps. The XenApp server joins its farm on the
first restart (reboot) after configuration; this ensures that the XenApp server image joins or rejoins the farm
after it has been cloned with its final identity.
Important: Cloning is not supported for the first server in the farm (where you created the farm
during configuration), and should be used only for creating new member servers for an existing farm.
The following descriptions assume you already created a XenApp farm containing at least one server. You
need the data store database information and credentials for the farm.
Approach 1: Capture an image after XenApp installation, but before configuration and restart
In this approach, you install the XenApp server role, but wait to configure XenApp (join a farm) until after
the server is cloned and booted. XenApp server configuration is automated, using a script.
This approach is not supported in Citrix Provisioning Services using Shared Image mode.
Install the XenApp server role, but do not configure the server. You may want to restart the server
to ensure the system path is updated properly before installing other applications. Deploying
prerequisites such as Remote Desktop Services roles may require a server restart before you can
install XenApp.
Install your applications and configure the settings you want in your image.
Run the generalization tools you normally run.
Set up a script to run when each cloned server boots. This script configures the XenApp server
(including farm information) using the command line (XenAppConfigConsole.exe). The script then
restarts the server, whereupon the server joins the farm.
You can set up scripts using typical methods such as Active Directory startup scripts or the
RunOnce registry key.
Capture an image of the server.
Approach 2: Capture an image after XenApp installation and configuration, but before restart
In this approach, you install and configure the XenApp server role, but wait to restart the server until after it
is cloned. When the server restarts as a clone of the original image, it joins the farm with its new identity.
You do not need direct access to your database server or network during configuration, so this approach can
be used to prepare XenApp images for remote deployments. If you do not or cannot verify your
database credentials, and they are invalid, XenApp will not join the farm when the server restarts. In that
1.
2.
3.
4.
5.
1.
2.
3.
4.
1.
2.
3.
5.
6.
case, run the XenApp Server Configuration Tool, providing correct credentials, and then recapture an image.
Install your applications and configure the settings you want in your image.
Install the XenApp server role. Deploying prerequisites such as Remote Desktop Services roles
may require a server restart before you can install XenApp.
Configure the XenApp server to add the server to (join) a farm, but do not restart the server.
Run the generalization tools you normally run.
Capture an image of the server.
Note: If you are using the SmartAuditor agent or other features that depend on Microsoft Messaging
Queuing (MSMQ), use the updated XenApp Server Configuration Tool and the procedure in Approach 3.
Approach 3: Capture or update an image after XenApp installation, configuration, and restart
If you require XenApp to be installed and working before you create a final image, you must remove the
server fromthe farm, then rejoin the farm before your final shutdown (for example, after sysprep), so that
the server will join the farm on the next restart, with its new identity.
Note: You can use this approach with the XenApp Server Configuration Tool included on the XenApp 6
for Windows Server 2008 R2 installation media. However, the process is streamlined and more effective if
you use the updated XenApp Server Configuration Tool (see ) before installing XenApp. CTX124981
Install the XenApp server role.
Optionally, install the Provisioning Services Target Device software. This software resets your
network connection during installation. Failures may occur if you install this component from a
network location. Although these failures are not commonly harmful, Citrix recommends installing
the Provisioning Services Target Device software from a DVD, mounted ISO, or local copy of the
installation media.
Configure XenApp to join a farm, and then restart (reboot) the server.
Install your applications and configure the settings you want in your image.
If you are using the Server Configuration Tool from the XenApp 6 for Windows Server 2008 R2
installation media:
From the XenApp Server Role Manager, edit your configuration and choose the task to remove
the server from the farm. (For a command-line configuration, specify the /ExecutionMode:
Leave option.)
If you are provisioning the XenApp server with SmartAuditor agent or other features that depend
on MSMQ, you must enable MSMQ (manually or scripted) to reset its identifier when the
server image boots.
Edit your configuration to join the farm again (this requires providing database credentials).
If you installed the updated XenApp Server Configuration Tool, edit your XenApp configuration and
select the task . (For a command-line Prepare this server for imaging and provisioning
configuration, specify the /ExecutionMode:ImagePrep option.)
If you are working with an image template that you do not want to keep in the current farm,
enable the checkbox. (For a command- Remove this current server instance from the farm
line configuration, use the /RemoveCurrentServer:True option.)
If you are provisioning the XenApp server with SmartAuditor or other features that depend
on MSMQ, enabling the checkbox ensures Prepare Microsoft Messaging Queuing provisioning
a new unique machine identifier when the server image boots. (For a command-line
configuration, use the /PrepMsmq:True option.)
Run the generalization tools you normally run.
Capture an image of the server.
The server joins the farm when the image boots.
Resealing an image
If a golden image requires updating (for example, with Citrix or Windows hotfixes, or third-party applications
1.
2.
3.
and patches), you can reseal the image. This procedure is similar to approach 3.
Boot into the image to make modifications. The XenApp server will try to join the farm if it can.
Modify the server as needed.
Proceed with step 4 in Approach 3.
During the resealing process, the updated Server Configuration Tool:
Removes server-specific information, such as WSID in MF20.dsn, WSID in RadeOffline.dsn.
Creates a unique Secure Ticket Authority (STA) ID in CtxSta.config, using the MAC address.
Resets the local databases and removes the Servers setting from the Independent
Management Architecture (IMA) data store by clearing the IMA local host cache and RadeOffLine databases.
Places the following configuration information into the Local Group Policy Object (LGPO) if they
have nondefault values (nondefault values appear as configured, default values appear as not configured).
Product feature and server edition
License server hostname
License server port number
XML Service port
Installation and Configuration Considerations
For provisioning purposes, you can install the XenApp server role using the wizard-based XenApp Server
Role Manager or the command line. For wizard-based installations, do not proceed to configuring the
XenApp server role until you are ready, based on the approach you select.
When preparing a XenApp server for imaging and provisioning:
The server should not be the only server in the XenApp farm.
The server should not be the data collector.
The server should not have the data store database installed on it.
The server should not have the Citrix License Server installed on it.
Important: When provisioning XenApp, you must remove the server SSL certificate before
running XenConvert; otherwise, the SSL certificate will be distributed to all provisioned XenApp servers.
For example, the following command, issued from the root of the installation media, installs the XenApp
server role and the Provisioning Services target device, and excludes installation of the Delivery Services Console.
\XenApp Server Setup\bin\XenAppSetupConsole.exe
/install:XenApp,PVDeviceFeature /exclude:XA_Console
Configuring the XenApp server after it is instanced (approach 1) should be automated using the command
line. You can use the wizard-based XenApp Server Configuration Tool or the command line to configure
the XenApp server if you choose approach 2 or 3.
For example, the following command, issued from the typical XenApp Server Configuration Tool location
(C:\Program Files (x86)\Citrix\XenApp\ServerConfig\XenAppCOnfigConsole.exe), joins the server to the
farm, specifying database credentials and the DSN file location, license server information, log file location,
and Remote Desktop User Group configuration settings.
“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\
-XenAppConfigConsole.exe" /ExecutionMode:Join
/OdbcUserName:administrator /OdbcPassword:somepasswd
/LicenseServerName:somelicenseserver
/LicenseServerPort:27000 /ZoneName:some_zone_name
/DsnFile:"c:\somepath\to\example.dsn"
/Log:c:\SomewhereConfigLog.txt /CustomXmlServicePort:8080
/AddAnonymousUsersToRemoteDesktopUserGroup:True
/AddUsersGroupToRemoteDesktopUserGroup:True
/AddAuthenticatedUserstoRemoteDesktopUserGroup:True
The following command prepares XenApp for imaging and provisioning. The server will be removed from
the current farm, and when the server image boots, it will contain a unique MSMQ machine identifier.
“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\
-XenAppConfigConsole.exe" /ExecutionMode:ImagePrep
/RemoveCurrentServer=True /PrepMsmq:True
4.7. Data Store Database Reference
Updated: 2010-02-05
See the database vendor documentation before installing, configuring, and using the database software.
contains information about supported database versions. CTX114501
If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp
configuration automatically installs it.
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.
Maintaining, Backing up, and Restoring a XenApp Data Store
Most database maintenance requires running the and commands on XenApp farm servers. dsmaint dscheck
The XenApp documentation contains syntax and use details. Commands Reference
Use to: dsmaint
Upgrade the XenApp data store
Move the data in the data store to a different database server
Change the name of the DSN file
If the data store fails, each farm server can run from the data in its Local Host Cache indefinitely, provided it
can contact the license server. However, you cannot make any modifications to the farm or use the
Delivery Services Console.
Create a backup copy of the data store ( ). Without a backup, you must manually recreate all dsmaint backup
of the farm policies, settings, accounts, and other persistent data in the data store.
To restore a backup database or to migrate to a new server, use the command. Without dsmaint migrate
a backup, prepare a new data store the way you did before configuring XenApp and run the Server
Configuration Tool from any farm server. After running the Server Configuration Tool, manually reenter the
lost settings. If you use the same name as the previous data store, you do not need to reconfigure the
farm servers.
4.7.1. Microsoft SQL Server Database
Updated: 2010-01-26
The server hosting the Microsoft SQL Server database should meet the following minimum requirements:
Approximately 100MB of disk space for every 250 servers and 50 published applications in the
XenApp farm. Provide more disk space for greater numbers of published applications.
Set the "temp" database to automatically grow on a partition with at least 1GB of free disk space.
Citrix recommends 4GB if the farm is large and includes multiple print drivers.
The default database installation settings and database sizes usually suffice for XenApp data store needs.
Microsoft SQL Server supports Windows and Microsoft SQL Server authentication. For high-security
environments, Citrix recommends using Windows authentication only.
The user account for installing, upgrading, or applying hotfixes to the data store must have database
owner (db_owner) rights to the database. When you finish installing the database with database owner rights,
1.
2.
3.
4.
5.
set the user permissions to read/write only to increase the security of the database. Change the rights back
to database owner before installing service packs or feature releases; installations can fail if the user
account used to authenticate to the data store during Setup does not have database owner rights.
When using Microsoft SQL Server in a replicated environment, use the same user account for the data store
on each Microsoft SQL Server.
Each farm requires a dedicated database. However, multiple databases can be running on a single server
running Microsoft SQL Server. Do not configure the farm to use a database that is shared with any
other client/server applications.
Back up the database regularly and follow Microsoft recommendations for configuring database and
transaction logs for recovery (for example, setting the option to control log space). Truncate log on Checkpoint
Using Sockets to Connect to a Microsoft SQL Server Database
Two protocols used to connect to a database are TCP/IP sockets and named pipes. Named pipes is
an authenticated communication protocol, so any time you attempt to open a connection to the SQL
Server database using this protocol, the Windows authentication process occurs. TCP/IP sockets do not rely
on Windows authentication to establish a connection, but do provide user/password authentication to
the database after the connection is established. Windows authentication reduces the possibility of an
error occurring when the server hosting SQL Server and the XenApp server do not have the correct domain
or Active Directory trust relationship. Therefore, Citrix recommends using TCP/IP sockets.
If you use named pipes, manually enable the named pipes option on the database server using the Surface
Area Configuration tool packaged with SQL Server.
Creating a Microsoft SQL Server Data Source Connection
On the screen, enter the data source description and Create a New Data Source to SQL Server
select the SQL Server to which to connect.
Select or . Windows NT Authentication SQL Server Authentication
Click . Client Configuration
Select from the available network libraries. TCP/IP
After installing XenApp, modify the Data Source Name (DSN) created during configuration and change
its client configuration to use TCP/IP.
To modify a DSN, use the Windows ODBC Data Source Administrator utility to open the File DSN, which
is located by default in the %ProgramFiles(x86)%\Citrix\Independent Management Architecture folder,
and select TCP/IP as the connection protocol for the client configuration.
Using Failover with Microsoft SQL Server
For fault tolerance with Microsoft SQL Server, use Microsoft clustering, which provides failover and failback
for clustered systems. Failover of the SQL Server database in a clustered environment is transparent to XenApp.
The database files for an instance of Microsoft SQL Server are placed in a single cluster group owned by the
node on which the instance is installed. If a node running an instance of Microsoft SQL Server fails, the
cluster group containing the data files for that instance is switched to another node. The new node already
has the executable files and registry information for that instance of Microsoft SQL Server on its local disk
drive, so it can start up an instance of Microsoft SQL Server and start accepting connection requests for
that instance.
Microsoft Cluster Services clustering does not support load balancing among clustered servers because
it functions in active/passive mode only.
Using Distributed Databases with Microsoft SQL Server
XenApp supports distributed (replicated) databases. Replicated databases are useful when too many
read requests to the data store create a processing bottleneck. Microsoft SQL Server uses replication to create
the distributed database environment.
XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is
1.
2.
3.
required for storing data in the database. When configuring Microsoft SQL Server for a two-phase commit, use
the Immediate Updating Subscriber model.
When configuring Microsoft SQL Server, you may need to increase the value of the Max Text Replication
Size property to improve replication performance.
Caution: To avoid corruption, do not use merged replication.
To set up a distributed environment for an existing XenApp farm:
Configure a Publisher (the Microsoft SQL Server currently hosting the data store) and Subscribers
(remote sites) using Microsoft SQL Server Enterprise Manager.
Run the command on a server in the farm. This executes the necessary dsmaint publishsqlds
SQL statements to create the published articles on the current Microsoft SQL Server (Publisher).
Configure the remote sites (Subscribers) to subscribe to the published articles created in the previous step.
4.7.2. Oracle Database
Updated: 2010-05-07
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. Provide more disk space for greater numbers of published applications.
20 MB minimum tablespace size.
Oracle supports Windows and Oracle authentication. Oracle for Solaris supports Oracle authentication only;
it does not support Windows authentication.
In the Oracle sqlnet.ora file, set SQLNET.AUTHENTICATION_SERVICES= (NONE). The default setting (NTS)
will cause connection failures.
Do not install XenApp on a server hosting an Oracle database.
Install the Oracle client on the server where you will be installing XenApp and then restart the server before
you install XenApp.
The Oracle user account must be the same for every server in the farm because all XenApp servers share
a common schema.
If you are using one database to hold information for multiple farms, each farm represented in the database
must have a different user account because the data store information is stored in the Oracle user account.
The account used to connect to the data store database has the following Oracle permissions:
Connect
Resource
Unlimited Tablespace (optional)
Consider the following guidelines when configuring an Oracle server.
Use Shared/Multi-Threaded Server mode to reduce the number of processes in farms with more than
100 servers (performance may be affected during periods of high data store load).
If you are using Multi-Threaded Server mode, verify that values in the Init.ora file are greater than or
equal to the following values. If you are running multiple farms on the same Oracle database, include
all XenApp servers in the calculations. Round up fractional values.
shared_servers = / 10 Number of servers
max_shared_servers = / 5 Number of servers
Where is the total number of servers running XenApp. Number of servers
When using an Oracle server in dedicated mode, add one additional process for each server
connected directly to the Oracle database. For example, if the Oracle server uses 100 processes
before installing XenApp, and the farm has 50 servers, set the processes value to at least 150 in the
Init.ora file on the Oracle server.
Create online backups using Archivelog mode, which reduces the recovery time of an
unresponsive database.
If you are using the same Oracle database for multiple server farms, create a unique tablespace with
its own user name and password for added security for each farm. Do not use the default system
account within Oracle.
Maintain a standby database for quick disaster recovery. A standby database maintains a copy of
the production database in a permanent state of recovery.
Using Distributed Databases with Oracle
Oracle uses replication to create the distributed database environment. To reduce the load on a single
database server, install read/write replicas and distribute the farm servers evenly across the master and replicas.
XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is
required for writes to the database.
Using Oracle as a distributed database solution has the following requirements:
All participating databases must be running Oracle.
All participating databases must be running in Multi-Threaded Server/Shared mode (rather than
Dedicated mode).
All Oracle clients (XenApp servers that connect directly to the Oracle database) must be SQL*Net Version
2 or Net8.
Install the farm data store database first on the master site, then configure replication at the sites used
for database replication snapshots.
Replicate all objects contained in the data store user schema (tables, indexes, and stored procedures).
If the performance at the replicated database site is significantly slower, verify that all the indexes for the 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.
5. XenApp 6 Migration Tool
Updated: 2010-07-06
The XenApp 6 Migration Tool comprises PowerShell cmdlets packaged as a PowerShell 2.0 module. The
Migration Tool pulls data from a legacy XenApp farm and imports (adds) it to your new XenApp 6 server farm.
You install the Migration Tool and run the cmdlets on a server in the new XenApp 6 farm. When you start
a migration, you point to a remote server in the legacy XenApp 5 farm. The Migration Tool uses MFCOM
to communicate with that remote server; the Migration Tool uses XenApp 6 commands to communicate with
the new XenApp 6 farm.
Citrix recommends performing the migration entirely from a server in the new XenApp 6 farm; this is called a
migration. However, if your deployment does not allow this, see for information direct Advanced Cmdlets
about indirect migrations.
Settings are grouped as . You can migrate all object types at once, or include and exclude object types
object types and named objects in the migration. You can specify new values for migrated object
properties. Servers in the legacy farm are migrated to worker groups in the new farm according to
you specify. server mappings
Repeat the migration as additional servers in the legacy farm become ready for reimaging in the new
farm. During subsequent migrations, the XenApp 6 Migration Tool compares newly-migrated objects from
the legacy farm with previously-migrated object in the new farm. Previously-migrated objects in the new farm
are updated if needed.
For example, assume you migrate applications from the legacy farm in June, then change the configuration
of Application XYZ in the legacy farm in September. When you migrate applications again in December,
the configuration of Application XYZ is updated in the new farm.
However, if you migrate settings, then change them in the new farm, a later migration of the same objects
will overwrite the new settings with the legacy farm values.
As the migration of more legacy farm servers continues, use the Web Interface user roaming feature to
help ensure that users can access applications and resources.
Objects You Can Migrate
You can migrate the following XenApp object types.
Object Type Description
Application All applications are enumerated; however, for the corresponding worker group to
be associated with the application, the application must be published to one of
the servers specified in the server mapping file. Only users that can be resolved on
the server in the new farm (account authorities that are trusted in the new farm)
are migrated.
Folder Includes application folders and server folders. Server folders are migrated so
that server permissions can be copied; however, the server objects are not migrated.
Load evaluator Load evaluators and their rules are migrated. Migrated load evaluators are attached
to applications (where applicable), but they are not attached to servers.
Policy Policies are migrated by creating an IMA (Independent Management Architecture)
User GPO (Group Policy Object) with the same name as the policy. Server filters
are migrated by using the Server Group (worker group) filter for the servers in
the mapping file. For user filters, only the accounts that can be resolved on the
target server in the new farm (account authorities that are trusted in the new farm)
are migrated.
The Zone Preference and Failover policy is converted to a Worker Group Preference
and Failover policy. Servers in the zone that are specified in the server mapping
file resolve to a worker group.
Server configuration Configuration settings for servers specified in the server mapping file are migrated
by creating an IMA Machine GPO named "WorkerGroup " where is the name name
name of the worker group specified in the server mapping file. This policy is filtered
by worker group. Worker groups are created as necessary, but they are not
associated with servers or OUs (Organizational Units).
Farm configuration Farm configuration settings are migrated by creating an IMA Machine GPO
named "Farm." This policy is unfiltered.
Administrator Only Citrix administrators whose accounts can be resolved on the server in the new
farm are migrated (the corresponding account authorities are trusted in the new farm
or they represent Citrix built-in accounts).
Farm and server settings from the legacy farm are compared against the default values used when the
new XenApp farm was created. The corresponding setting in the policy in the new farm is set to "Not
Configured" if it matches the default value for the same setting in the new farm.
Health Monitoring and Recovery (HMR) test executables are not copied; however, HMR test configurations
are migrated into policies in the new farm.
You cannot transfer the following settings using the Migration Tool:
Zones
Printer management
Configuration Logging settings
Only settings that reside in the IMA data store are migrated; settings that reside only in the server registry
are not migrated.
The migration process ignores the following settings:
Deprecated settings, such as AIE (Application Isolation Environment).
Permissions that do not exist in the XenApp 6 for Windows Server 2008 R2 release, whether
they correspond to a deprecated feature or a configuration setting that is now supported as a policy.
5.1. Requirements and Installation
Updated: 2010-07-06
You can migrate a single XenApp 5 farm (multiple farm consolidation to a single farm is not supported).
You should be familiar with MFCOM and PowerShell.
Requirements for the Legacy Farm
The servers in the legacy farm must be running XenApp 5 for Windows Server 2003 with Hotfix
Rollup Pack 5 (HRP5) or XenApp 5 for Windows Server 2008.
The legacy farm server from which you are exporting must have network COM+ access enabled.
To access the XenApp 5 server in the legacy farm using a remote connection, you must be a member
of the DCOM users group, and you must be a Citrix administrator with at least view-only privileges in
the legacy farm.
When migrating from a 32-bit XenApp farm to a XenApp 6 farm, network printers used by policies
(session printers) must have a 64-bit driver installed in the print server; otherwise, those printers will
not be migrated.
Requirements for the New Farm
The servers in the new farm must be running XenApp 6 for Windows Server 2008 R2.
To install the Citrix XenApp Migration Module, you must have permission to install components. To run
the XenApp 6 Migration Tool cmdlets, you must be a Citrix administrator with full privileges.
You must have write access to the folder where the migrationoptions.xml file (containing server
mappings, migration options, and object property overrides) and the exported data from the legacy farm
is placed. By default, this is a folder named Data, located under the XenApp 6 Migration Tool
installation files in C:\Users\ \appdata\local\citrix\citrix.xenapp.migration). You can specify a user
different folder with the -DataFolderPath option in the cmdlet. Set-XAMigrationOption
By default, execution of PowerShell scripts is disabled. To run the XenApp 6 Migration Tool cmdlets,
sign the scripts or enable the scripts to run ( ). You are Set-ExecutionPolicy RemoteSigned
prompted during installation if this has not been done.
If your legacy farm uses file type association for published applications, update the new farm with file
type associations (using the task in the Delivery Services Update file types from registry
Console) before you migrate applications. This allows the migration process to create the associations
in the new farm.
Create worker groups in the new farm for server and application silos. (However, if a worker
group specified in a server mapping does not exist, the XenApp 6 Migration Tool creates it.)
1.
2.
3.
1.
The following software is required to install the Citrix XenApp Migration Module and run the cmdlets.
This software is required for XenApp server installation and configuration, so it is likely to already
be installed.
.NET Framework 3.5 SP1
MSI 3.0
PowerShell 2.0
If you installed the beta version of the XenApp 6 Migration Tool, manually uninstall it and then delete
the folder \users\ \AppData\Local\Citrix\Citrix.XenApp.Migration before installing the newer version user
of the tool.
Installing the XenApp 6 Migration Tool
Install the XenApp 6 Migration Tool on one server in the new farm. In most cases, this is the server where
you installed and configured XenApp 6 to create the farm.
Download the XenApp 6 Migration Tool from My Citrix.
Double-click Citrix.XenApp.Migration.exe; the self-extracting executable launches an MSI that installs
the module. During installation, you are prompted to set the PowerShell execution policy to unrestricted,
if the current policy setting differs.
The installer creates shortcuts in the Start menu. Clicking (launching) the shortcut opens PowerShell
and loads the module. (If you do not use the shortcut, open a PowerShell console and type
.) Import-Module Citrix.XenApp.Commands
When launching the XenApp 6 Migration Tool, restart the server if you receive the following error message:
Import-Module: The specified module 'Citrix.XenApp.Migration' was not loaded because no
. valid module file was found in any module directory
Note: Citrix recommends performing the migration entirely from a server in the new farm. If your
deployment does not allow this, see . Advanced Cmdlets
5.2. Using the XenApp 6 Migration Tool Cmdlets
Updated: 2010-07-06
Run the XenApp 6 Migration Tool cmdlets from the PowerShell console.
Before starting a migration, use the following cmdlets to build a file containing server mappings
and optionally, migration options and property value overrides.
Use the cmdlet to map servers in the legacy farm to worker groups in Add-XAServerMapping
the new farm. The servers in the mapping are representative servers chosen from each server silo
in the legacy farm. Server mappings are not required, but a XenApp farm cannot be
completely migrated without them (without server mappings, no data about the servers will
be migrated; for example, server settings, application servers, or Zone Preference and
Failover policy).
To display the server mappings you specified, use the cmdlet. Get-XAServerMapping
To remove a server mapping, use the cmdlet. Remove-XAServerMapping
Use the cmdlet to tailor the migration. Setting migration options Set-XAMigrationOption
is optional; it offers flexibility in tailoring your migration.
You can specify a remote server name; this is the name of the server in the legacy farm from
which objects will be migrated. Specifying the remote server name as a migration option
eliminates having to specify it each time you start a migration.
You can also optionally specify a nondefault folder location where the exported data from the
legacy farm is stored, and object types or named objects to include or exclude from the migration.
To display the migration options you specified, use the cmdlet. Get-XAMigrationOption
Use the cmdlet to specify values for individual object properties, if you Add-XASettingOverride
1.
2.
3.
do not want to use the migrated values in the new farm. Specifying setting overrides is optional.
To display the names of object properties you can specify with the Add-XASettingOverride
cmdlet, use the cmdlet. Get-XALegacySettingName
To display the property override values you specified, use the Get-XASettingOverride
cmdlet.
To remove a property override value you specified, use the Remove-XASettingOverride
cmdlet.
Launch the migration with the cmdlet. Start-XAMigration
To see what would happen during the migration (for example, which objects are migrated
and updated, and changes to property values) without actually performing the action, use the
-PendingReportOnly option. This option provides more detailed output than the -WhatIf
PowerShell common parameter.
After running a migration, use the cmdlet to display a count of the objects in the legacy and new farms. This helps monitor equivalency between the new farm and the legacy farm. You can tailor the display to report differences from an existing snapshot. Get-XAMigrationObjectCount
Subsequent migrations (using the cmdlet) will use the current specifications in the Start-XAMigration
server mappings, migration options, and property value overrides file.
Post-migration Tasks
Associate servers or OUs with worker groups.
Associate application folders with worker groups.
Attach load evaluators to servers.
Assign zones.
Configure printer settings.
Initiate Configuration Logging in the new farm.
Configure Health Monitoring settings.
Optionally, add new servers in the old server folder hierarchy to preserve delegated permissions.
To enable streamed-to-server applications to launch after migrating from a 32-bit XenApp farm to
a XenApp 6 farm, rebuild profiled applications.
5.3. Cmdlet Reference
Updated: 2010-06-04
Cmdlet Summary
For PowerShell help, type . Get-Help cmdlet-name
To see examples, use the -examples option.
For detailed information, use the -detailed option.
For technical information, use the -full option.
Cmdlet Description
Add-XAServerMapping Adds a server mapping.
Add-XASettingOverride Specifies a value for an object property.
Get-XALegacySettingName Outputs the settings you can use with the Add-
XASettingOverride cmdlet.
Get-XAMigrationObjectCount Outputs a count of objects in the legacy and new farms.
Get-XAMigrationOption Outputs the list of migration options.
Get-XAServerMapping Outputs the list of server mappings.
Get-XASettingOverride Outputs the list of object property value overrides.
Remove-XAServerMapping Removes a server mapping.
Remove-XASettingOverride Removes an object property value override.
Set-XAMigrationOption Sets migration options.
Start-XAMigration Starts the migration.
The Migration Tool cmdlets support the PowerShell common parameters. In particular, -Confirm and -Verbose
can be helpful in the migration process.
Although the -WhatIf common parameter is supported, using the -PendingReportOnly option with the
cmdlet provides more detailed information. Start-XAMigration
Add-XAServerMapping
Adds a mapping between a server in the legacy farm and a worker group in the new farm. You must specify
the following options:
Option Description
-ServerName server-name MFCOM name of the server in the legacy farm.
-WorkerGroupName name Name of the worker group in the new farm. If the worker
group does not exist, it is created.
For example, the following cmdlet maps the server named OfficeApps5 to the worker group named DenverAcctg.
Add-XAServerMapping -ServerName OfficeApps5
-WorkerGroupName DenverAcctg
Add-XASettingOverride
Specifies a value for an object property (setting). This value is used for the object property in the new
farm, regardless of the value of the property in the legacy farm (it overrides the setting in the legacy farm).
To display the names of object properties you can specify with the cmdlet, use the Add-XASettingOverride
cmdlet. Get-XALegacySettingName
You can specify the following options:
Option Description
-PropertyName
property-name
Property name. You can use wildcards.
-ObjectType
object-type
Object type.
Valid values are: Administrator, Application, FarmConfiguration, Folder,
LoadEvaluator, Policy, and ServerConfiguration. You can use wildcards.
-Value New property value.
-MatchValue Original property value to match before overriding the setting with the new value. If
the value does not match, the override is skipped.
If this option is omitted, the override always occurs.
-ObjectName
object-name
Object name.
For example, the following cmdlet specifies a CPU priority level of "high" for migrated applications in the new farm.
Add–XASettingOverride CpuPriorityLevel High
The following cmdlet changes the CommandLineExecutable property value to C:\Program Files\Test\Test.
exe when its current value is C:\ProrgramFiles (x86)\Test\Test.exe.
Add-XASettingOverride -PropertyName
CommandLineExecutable -ObjectType Application
-Value "C:\Program Files\Test\Test.exe"
-MatchValue "C:\Program Files (x86)\Test\Test.exe"
Get-XALegacySettingName
Outputs the settings you can use with the Add-XASettingOverride cmdlet. You can specify the following options:
Option Description
-PropertyName property-name Property name. You can use wildcards.
-ObjectType object-type Object type.
Valid values are: Administrator, Application, FarmConfiguration,
Folder, LoadEvaluator, Policy, and ServerConfiguration. You can
use wildcards.
For example, the following cmdlet gets a list of valid settings that contain "LicenseServer" in the property name.
Get-XALegacySettingName *LicenseServer*
The following cmdlet gets a list of valid settings for object types that start with "Server" and that
contain "LicenseServer" in the property name.
Get-XALegacySettingName *LicenseServer*
-ObjectType Server*
Get-XAMigrationObjectCount
Outputs counts of objects in the legacy and new farms. Use the -ImportOnly option to generate the
differences from an existing snapshot.
Get-XAMigrationOption
Outputs the list of migration options (that is, the migration options previously specified with
cmdlets). Set-XAMigrationOption
Get-XAServerMapping
Outputs the list of all server mappings (that is, the mappings previously specified with Add-XAServerMapping
cmdlets).
Get-XASettingOverride
Outputs the list of setting overrides (that is, object property values previously specified with
cmdlets). Add–XASettingOverride
Remove-XAServerMapping
Removes a server mapping (that is, a mapping previously specified with an cmdlet). Add-XAServerMapping
Remove-XASettingOverride
Removes a setting override (that is, an object property value previously specified with an
cmdlet). Add-XASettingOverride
Set-XAMigrationOption
Sets migration options.
Option Description
-RemoteServerName name Name of the server in the legacy farm from which objects will
be exported. This value is used if you do not specify the
-RemoteServerName option in the cmdlet. Start-XAMigration
If you do not specify the -RemoteServerName option in the
or cmdlet, the Start-XAMigration Set-XAMigrationOption
migration ends.
-DataFolderPath path
Path to the folder where exported data from the legacy farm is placed.
If the folder does not exist, the Migration Tool will attempt to create it.
If you do not specify this option, exported data is moved to the
Data folder located under the Migration Tool installation files.
-ObjectType object-type Object type. This option is used with the –Include and –Exclude
options, which specify object names.
Valid values are: Administrator, Application, FarmConfiguration,
Folder, LoadEvaluator, Policy, and ServerConfiguration.
-Include object-name Object names to include in the migration. This option is used with the
–ObjectType option. Separate multiple object names with commas.
You can use wildcards.
-Exclude object-name Object names to exclude from the migration. This option is used with
the –ObjectType option. Separate multiple object names with
commas. You can use wildcards.
-Enabled $false | $true Provides an alternative to using the -Exclude * option to exclude
all objects specified with the -ObjectType option from the migration.
For example, the following cmdlet uses the -ObjectType and -Exclude options to exclude applications named
"A1" and "A2" from the migration.
Set-XAMigrationOption –ObjectType Application
–Exclude A1, A2
The following cmdlet uses the -ObjectType, -Include, and -Exclude options to include all applications with a
name containing "Microsoft" except "Office."
Set-XAMigrationOption –ObjectType Application
–Include *Microsoft* –Exclude *Office*
The following cmdlet uses the -ObjectType and -Enabled options to disable migration of all applications.
Set-XAMigrationOption –ObjectType Application
–Enabled $false
Start-XAMigration
1.
1.
2.
3.
4.
5.
Launches the migration. You can specify the following options:
Option Description
-RemoteServerName name Name of the server in the legacy farm from which objects will
be exported.
If you do not specify this option, but you specified a
-RemoteServerName option in the Set-XAMigrationOption
cmdlet, that name is used.
If you do not specify the -RemoteServerName option in the
or cmdlet, the Start-XAMigration Set-XAMigrationOption
migration ends.
-PendingReportOnly Generates records that indicate which objects will be migrated
and which values will be changed, but does not actually perform
the migration.
This option provides more detail than the standard PowerShell -
WhatIf option.
-ExportOnly Exports objects from the legacy farm to a file, but does not
import them to the new farm.
This option is generally used only when MFCOM cannot be
used between the legacy farm and the new farm. In this case, use a
cmdlet on a server in the Start-XAMigration –ExportOnly
legacy farm.
-ImportOnly Imports objects to the new farm.
This option is generally used only when MFCOM cannot be
used between the legacy farm and the new farm. In this case, use a
cmdlet on a server in the Start-XAMigration –ExportOnly
legacy farm, collecting exported information in a file. Then, use a
cmdlet on a server in the Start –XAMigration –ImportOnly
new farm to import the objects, using the exported information.
5.4. Advanced Cmdlets
Updated: 2010-07-06
Using the Migration Tool on Separate Servers (Indirect Migration)
Citrix recommends performing the migration entirely from a server in the new farm (a direct
migration). However, if you cannot use MFCOM to communicate between the legacy farm and the new
farm, perhaps because the two farms are in different domains that do not have a trust relationship, you
can perform an indirect migration. In this case, you must also install the XenApp 6 Migration Tool on a server
in the legacy farm, in addition to installing it on a server in the new farm. For an indirect migration, after
you install the XenApp 6 Migration Tool on a server in the new farm:
On a server in the legacy farm:
Install the required software (.NET Framework 3.5 SP1, MSI 3.0, and PowerShell 2.0).
Download the XenApp 6 Migration Tool from My Citrix.
Install the XenApp 6 Migration Tool (32-bit or 64-bit version, depending on the legacy
server operating system).
Build a file containing server mappings, migration options, and property value overrides,
as described in . Using the XenApp 6 Migration Tool Cmdlets
Export settings using the cmdlet with the -ExportOnly option. The output is Start-XAMigration
1.
5.
2.
3.
a series of XML files.
Copy the XML files to the server in the new farm, replacing the files on that server. This includes the
file containing server mappings, migration options, and property value overrides.
From the new farm, issue a cmdlet to import the settings (using the cmdlet with the Start-XAMigration
-ImportOnly option or using one of the advanced import cmdlets .
Advanced Import Cmdlets
The cmdlet is intended for scripted, unattended migrations. For interactive testing, Start-XAMigration
the XenApp 6 Migration Tool includes additional object-specific import cmdlets. These cmdlets offer alternatives
to using the –ImportOnly option with the cmdlet and the -ObjectType and -Include Start-XAMigration
options with the cmdlet. Set-XAMigrationOption
You can also use these cmdlets during indirect migrations.
These cmdlets use the configured server mappings, migration options, and object property value overrides.
For complete PowerShell syntax, type . Get-Help cmdlet
Import-XAApplication
Import-XAFolder
Import-XALoadEvaluator
Import-XAPolicy
Import-XAServerConfiguration
Import-XAFarmConfiguration
Import-XAAdministrator
Advanced XALegacy Cmdlets
Using the advanced XALegacy cmdlets can be helpful if an object did not migrate as expected. The
Get-XALegacy* cmdlets connect to the legacy farm and read the settings for an object in the legacy farm.
You can use the Convert-XALegacyObject, New-XALegacyConnection, and Remove-XALegacyConnection
cmdlets when creating a custom migration script that does not use the Import-XA* or Start-XAMigration cmdlets.
For complete PowerShell syntax, type . Get-Help cmdlet
Get-XALegacyAdministrator
Get-XALegacyApplication
Get-XALegacyFarmConfiguration
Get-XALegacyFolder
Get-XALegacyHmrTest
Get-XALegacyLoadEvaluator
Get-XALegacyPolicy
Get-XALegacyPolicyConfiguration
Get-XALegacyPolicyFilter
Get-XALegacyServer
Get-XALegacyServerConfiguration
Get-XALegacySessionPrinter
Convert-XALegacyObject
New-XALegacyConnection
Remove-XALegacyConnection
These advanced cmdlets include objects that cannot be migrated alone (for example, session printers that
are inside a user policy, and HMR tests that are inside farm or server settings). This greater granularity may
be helpful when troubleshooting migration, because these objects are more complex, with multiple sets
of properties.
6. XenApp Administration
Updated: 2010-02-09
The administration of your Citrix XenApp environment consists of performing tasks in the console to
administer servers, manage administrators, and publish resources. You can also administer and modify
your environment through policy-based settings.
Before you install Citrix XenApp, review the , installation, and administration topics. Readme for Citrix XenApp
6.1. Management Consoles and Other Tools
Updated: 2010-03-08
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 menu. Start
Delivery Services Console
The Delivery Services Console is a tool that snaps into the Microsoft Management Console (MMC) and enables
you to perform a number of management functions.
For Citrix XenApp, you can set up and monitor servers, server farms, published resources, and
sessions. Configure application access (both through the Web Interface and the Citrix online plug-in) and set
up policies and printers.
In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your farms, view
hotfix information for your Citrix products, and track administrative changes.
My Views are configurable displays that give you quick access to items you must examine regularly or items
in different parts of the 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.
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
If your deployment includes multiple XenApp farms (such as one farm comprising servers running XenApp 6
for Windows Server 2008 R2, and another farm comprising servers running XenApp 5), you can use one
MMC console that has separate Delivery Services Console snap-ins to manage each farm.
License Administration Console
Use this console to manage and track Citrix software licenses. For more information about licensing, see
the License Administration console Help and the in Getting Started with Citrix Licensing Guide 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.
6.1.1. To start the console and discover servers
Updated: 2010-03-08
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.
1.
2.
3.
1.
2.
3.
1.
If you are logging on to 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.
Click . Start > All Programs > Citrix > Management Consoles > Citrix Delivery Services Console
The first time you open the 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.
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.
After this, run the discovery process only if you want to refresh the view of your deployment. The console
tree refreshes automatically each time you add, remove, or modify items in your deployment.
When using discovery to connect to your XenApp deployment, you must specify the name or IP address of
at least one server in each farm that you want to manage. When discovery is complete, the console tree
displays the items that you specified.
You can configure discovery only for some components. The configuration process can vary among
components. The task appears in the Actions pane only for Configure and run discovery
configurable components; otherwise, only the is available. Run discovery task
In the console tree, select or the product or component whose objects you want Citrix Resources
to discover.
Click , or to run discovery without any configuration, click Configure and run discovery Run discovery.
When discovering XenApp deployments, specify the name or IP address of at least one server
running XenApp in each farm that you want to manage.
6.1.2. To view zones
Updated: 2010-01-28
Zones can be viewed and configured in the console. For information on configuring zones, see To configure
. zones and back-up data collectors
Depending on the version of XenApp you have installed, from the menu, select Start All Programs
and choose . > Citrix > Management Consoles Citrix Delivery Console
In the left pane, expand the node. Zones
Under , select a zone. The results pane displays the servers in the chosen zone. Zones
6.1.3. To refresh user data automatically
Updated: 2010-12-08
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 Delivery Services Console. The auto-
refresh settings apply only to the 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 affect performance.
In the left pane, select one of these nodes (depending on what type of user data you want to
refresh automatically):
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.
3.
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
1.
2.
In the Actions pane or from the Other Tasks section (depending on the node that you selected), click
and choose one of these options: Refresh user data
Automatically refresh user data for servers. Selecting this option enables automatic
refreshing of each server’s configuration and connection information. After selection, the
associated Refresh rate field becomes available.
Automatically refresh user data for farms and server folders. Selecting this option
enables automatic refreshing of the folder organization for farm and server. After selection,
the associated Refresh rate field becomes available.
Automatically refresh user data for applications. Selecting this option enables
automatic refreshing of each published application’s configuration and connection information.
After selection, the associated Refresh rate field becomes available.
In the box, select the number of seconds between each update (10, 30, 60, Refresh rate (seconds)
or 90).
6.2. Managing Citrix Administrators
Updated: 2010-10-13
Citrix administrators are individuals tasked with managing server farms.
To create a Citrix administrator
You can make any member of a Windows or Novell Domain Services for Windows account authority a
Citrix administrator.
From the menu, select Start All Programs > Citrix > Management Consoles > Delivery
. Services Console
In the left pane, expand and select a farm. Citrix Resources > XenApp
From the pane on the right, click . Actions Add administrator
Click and select the configured user or user group account to designate as a Citrix administrator. Add
On the page, select the authority level you want to grant the administrator account. Privileges
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
From the menu, select Start All Programs > Citrix > Management Consoles > Delivery
. Services Console
From the left pane, , expand and the farm, then choose the Citrix Resources > XenApp Administrators
node.
On the Administrators tab, select the administrator whose properties you want to change.
On the Actions pane, click . Administrator properties
Choose from the following options:
To change an administrator's privilege level, open the page Privileges
To assign or update custom permissions, open the page Permissions
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.
Select the administrator whose privileges you want to disable.
On the Actions pane, click . Disable
1.
1.
2.
1.
2.
3.
4.
5.
6.
7.
8.
9.
When an administrator is disabled, the administrator icon appears in grey and an task becomes available. Enable
To re-enable a Citrix administrator
Select the administrator whose privileges you want to enable and then, on the Actions pane, click . Enable
To remove a Citrix administrator
Remove a Citrix administrator if you want to delete the account and settings. Only administrators with full
access can disable or remove other Citrix administrator accounts.
Important: If only one Citrix administrator account with full access remains on the list, you cannot remove it.
Select the administrator or administrators whose account you want to remove.
On the Actions pane, click . Delete administrator
6.2.1. Delegating Tasks to Custom Administrators
Updated: 2010-01-27
You can delegate tasks through the Delivery Services Console by associating custom Citrix administrator
accounts with to perform select tasks. permissions
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
option when you create the new folder. permissions from the parent folder
To delegate tasks to existing custom administrators
From the menu, select Start All Programs > Citrix > Management Consoles > Citrix
. Delivery Services Console
From the left pane, expand and the farm, then choose the Citrix Resources > XenApp Administrators
node.
On the Administrators tab, select the administrator to whom you want to delegate tasks.
From the right pane, under , click . Actions Administrator properties
In the Citrix Administrator Properties dialog box, on the Privileges pane, if is not selected, select it. Custom
Click to view the task permissions assigned to the administrator. Permissions
Click on a folder in the list to view additional tasks. Folders
To select the tasks to which the administrator has access, select or clear the check boxes, as appropriate.
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 administrator’s OBDA permissions, he or she must manually rerun discovery.
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
To assign folder permissions
To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the
farm level. To view and change permission on objects, such as printers, you must be a Citrix administrator
with full access to view and change object permissions.
From the menu, select Start All Programs > Citrix > Management Consoles > Citrix
. Delivery Services Console
From the left pane, select the folder under the farm to which you want to grant access.
From the Actions pane, select , then . The resulting dialog box lists Other Tasks Permissions
the administrators who currently have access to the selected folder.
To give access to an administrator that is not on the Administrators list, click and then click the Add
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 to create the administrator. Add
To assign or change object permissions
To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the
farm level. To view and change permission on objects, such as printers, you must be a Citrix administrator
with full access to view and change object permissions.
From the menu, select Start All Programs > Citrix > Management Consoles > Citrix
. Delivery Services Console
From the left pane, select the farm to whose objects you want to grant access.
From the right pane, under , choose , then . Actions Other Tasks Set permission on objects
Select the object whose permissions you want to change and click . Permissions
Under , you can see the administrators who have access to tasks related to the object. Administrators
From the list select the administrator to whom you want to assign additional or Administrators
change existing folder permissions. If the administrator you want is not on the list, click and select Add
the administrator.
If the administrator you want is not a custom administrator, click and change the Edit
administrator's privilege level to . This allows you to change the administrator's permissions. Custom
With the administrator selected, use the check boxes to change specific permissions in the pane. Tasks
If the folder contains subfolders, the following options become available:
Choose to copy Copy the permissions of this administrator for this folder to its subfolders
newly configured permissions to all folders nested in the selected folder for the custom administrator.
Choose to copy Copy the permissions of all administrators for this folder to its subfolders
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
or the Copy the permissions of this administrator for this folder to its subfolders Copy
function to copy the permissions of all administrators for this folder to its subfolders
the permissions again.
6.3. Publishing Resources
Updated: 2010-04-02
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 , so users can access all of the resources available on the server. server desktops
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.
Citrix recommends installing applications that interact with each other on the same group of servers (called
a silo). If you have multiple applications silos, Citrix recommends using separate organizational units, so they
can be convenient targets for policies and worker groups. For more guidance about planning for applications
and server loads, see the eDocs section about designing a XenApp deployment.
Important: Before you begin, refer to the system requirements for supported platforms and
system prerequisites.
6.3.1. Publishing Resources for Users
Updated: 2010-04-07
When you publish an application, configuration information for the application is stored in the data store for
the server farm. The configuration information includes which types of files are associated with the
application; users who can connect to the application; importance level for Preferential Load Balancing; and
client-side session properties that include window size, number of colors, level of encryption, and audio 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 Domain Services for Windows 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.
6.3.1.1. To configure servers to publish for multiple users
Updated: 2010-06-07
To ensure applications are enabled for multiple users, install the applications using one of the following methods:
Install applications as the Built-in Administrator
Select an “install for multiple users” option in the installation wizard for the application, if the Setup for
the application provides this option
Install the application for all users from a command line
1.
2.
3.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
To install an application for all users, after enabling Remote Desktop Services, use these steps before
installing the application:
Open a command prompt so that you are running it with Administrator privileges; for example, right-
click the command prompt and select . Run as Administrator
Run the following command at a command prompt: change user /install
From the command prompt, run the Setup executable for the application.
6.3.1.2. To publish a resource using the Publish Application wizard
Updated: 2010-09-16
Open the XenApp 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.
From the XenApp console, under the node, expand the farm or server to which you want XenApp
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.
Select the node and from the pane choose . Name the folder for Applications Actions Create folder
the application you are publishing.
Select the folder you created and from the pane choose . Actions Publish application
In the Publish Application wizard, on the page, provide a display name (maximum 256 Name
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.
On the page, specify the type of resource you want to publish and the delivery method. Three Type
types of resources can be published ( , , and ). The next few steps in server desktop content application
the wizard differ based on which type you select. For more details, see To select a resource type
and . and delivery method To select a streaming delivery method
On the page, add the command-line and working directory (optional) to locate the application. Location
On the page, add the individual servers or worker groups on which the published application Servers
runs when accessed by an ICA connection.
Note: If you add a worker group, make sure that all the servers in the worker group are running
the application you are publishing.
On the page, create the list for users or groups who have access to Users Configured users
the application. Use the options to allow access to configured user accounts only or to anonymous users.
On the page, select the icon for the application and choose how the application Shortcut presentation
is enumerated on the user device. The console has a limit of 1,000 unique application icons. When
that limit is exceeded, the console displays a generic icon for all new applications.
On the page, choose whether or not to make the published application Publish immediately
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
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.
6.3.1.3. Publishing App-V Sequences in XenApp
1.
2.
1.
2.
3.
3.
1.
2.
3.
Updated: 2010-09-09
You can deliver the Microsoft Application Virtualization (App-V) sequences to users by publishing the sequences
in XenApp and delivering the Microsoft Application Virtualization Desktop client through Citrix
Merchandising Server and Citrix Receiver.
To deliver App-V sequences using the Citrix application streaming feature, Citrix provides a conduit utility
that supports a execution. With dual-mode, users launch applications as they normally do, and dual mode
the conduit checks for presence of the App-V client. If the App-V client is installed, the App-V sequence
streams to the user device; if not, the application launches from a XenApp server and streams to the user device.
System requirements:
Citrix supports App-V sequences on all operating systems supported by Microsoft App-V.
Citrix Receiver for Windows supports App-V clients 4.5 and 4.6.
User devices must have the Citrix offline plug-in 6.0 installed locally.
Citrix recommends the following process:
Deliver the App-V client to users through Citrix Merchandising Server and Citrix Receiver
Publish App-V sequences for virtualizing on user devices if possible, otherwise virtualizing on
XenApp servers
Users can then launch the App-V sequences on their desktops by clicking on the icons delivered through XenApp.
Before you start, locate the following files and have them available:
installer (setup.exe) from your Microsoft Microsoft Application Virtualization Desktop Client
Desktop Optimization Pack (MDOP) installation media, to upload to the Merchandising Server.
from Citrix ( App-V Integration Kit https://www.citrix.com/English/ss/downloads/details.
). asp?downloadId=1863811
Save the unzipped contents locally:
Save the folder on your App Hub (the server where you App Streaming To AppV Conduit
store your profiles). The folder contains a pre-created AppStreamingToAppVConduit.profile file,
as well as the required support files for the profile. This single profile can be used to publish
an unlimited number of App-V sequences.
Upload the files and the App-V client's file to the App-V MetaData setup.exe
Merchandising Server to create an App-V client. Citrix provides these files to add the functionality
to the client needed for Citrix Receiver. These files include:
AppV_MetaData.xml
AppVReg.msi
AppVReg_MetaData.xml
Save the folder locally. These files are not needed to Streaming Conduit - source code
publish your applications, but you can use them to modify the conduit, if needed. This
folder contains the source code for the conduit.
To deliver the App-V client with the Citrix Merchandising Server and Citrix Receiver
In the Merchandising Server Administrator Console, navigate to the > page. Plug-in Upload
To upload the App-V_Reg plug-in components:
For the , click to navigate to the unzipped location of Metadata File Browse
. AppVReg_MetaData.xml
For the , click to navigate to the unzipped location of . Plug-in File Browse AppVReg.msi
Click . Upload
To upload the App-V client components:
For the , click to where you downloaded . Metadata File Browse App-V_MetaData.xml
For the , click to navigate to the location of the Microsoft Plug-in File Browse
Application Virtualization Desktop Client installer, . setup.exe
3.
3.
4.
1.
2.
3.
4.
5.
6.
Click . Upload
Configure a delivery to communicate with your App-V server. (For additional information on creating
and scheduling deliveries, see the documentation.) Merchandising Server
An overview of the entire plug-in upload and delivery process when using Merchandising Server 1.0 can
be viewed at . http://www.citrix.com/tv/#videos/773
If users have Citrix Dazzle, they can add published App-V sequences as they normally add applications.
To publish App-V sequences for streaming to desktops
The conduit utility (which is the pre-created Citrix .profile) provides pre- AppStreamingToAppVConduit
launch and post-exit scripts that enable a delivery method. This delivery method uses the App-V dual-mode
client to stream the application to the user device. If the user device does not support streaming or lacks the
App-V client, the conduit triggers the secondary method and delivers the application to a XenApp server,
which then delivers the application through session virtualization using a remote display protocol. The
application can be locally installed on the XenApp server, or streamed through Citrix application streaming
using the App-V client installed on the server.
In the XenApp Delivery Services Console, open the application publishing wizard and follow the on-
screen instructions.
Name the application with a name familiar to users, such as "Microsoft PowerPoint 2007."
On the Type page, configure the dual-mode delivery method:
Select . Application
For application type, select the dual-mode option: Streamed if possible, otherwise
. accessed from a server
For the server application type, select the secondary delivery method, such as
. Installed application
On the Location page:
Browse to your App-V server where both the conduit utility and App-V sequence are located.
The application to launch is . AppStreamingToAppVConduit
Add the command-line parameters to locate the specific App-V sequence on your App-V server.
For : Command Line
Enter the full path to your Microsoft Application Virtualization Client executable, followed by
the location of your App-V sequence, such as:
"C:\\Program Files\Microsoft Application Virtualization Client\sfttray.
exe" "\\appv\content\Off2k7\Microsoft Office PowerPoint 2007 12.0.6425.0000.osd"
On the Shortcut presentation page, manually select the icon from your icons directory (no icon by
default), such as the icon for Microsoft PowerPoint.
Finish the publishing wizard as you normally do.
For more information about the AppStreamingToAppVConduit utility, see http://support.
in the Citrix Knowledge Center. citrix.com/article/CTX124860
To launch the App-V sequences
When users log on:
Citrix Receiver informs them of plug-in updates, and if they accept the App-V client, it installs silently
in the background.
If they use Citrix Dazzle, they can subscribe to App-V sequences through Dazzle.
Users launch applications as they normally do, and the conduit checks for presence of the App-V client:
If the App-V client is installed, the App-V sequence streams to the user device, where it runs in the App-
V isolation environment.
If the client is not installed (or the device does not support streaming for other reasons), the
1.
2.
conduit triggers the Citrix offline plug-in to initiate a XenApp server session where the application
executes and is presented to the user over a remote display protocol.
6.3.1.4. To select a resource type and delivery method
Updated: 2009-11-19
In the Publish Application wizard, select the resource type that you want to deliver and the delivery method.
To view the setting, from the menu, select and then select . Action Application properties Type
To change the resource type, from the menu, select > Action Other Tasks Change application type
and follow the instructions in the wizard.
Select one of the following resource types:
Server desktop. Publishes the entire Windows desktop of a server in the farm. When the plug-
in connects to the server, the user sees a desktop interface from which any application installed
on that server can be started. After selecting this application type, you must specify the server
that you want to publish.
To publish a desktop, you must be running XenApp. If you are running the 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 to Browse
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
). Grants users access to a profiled application that streams from the mode streaming
file share to their user devices and launches locally from within an isolation
environment. Alternatively, for user devices that do not support streamed applications
(for example, if the offline plug-in is not installed), this setting allows the use of an
ICA connection to access the application installed on or streamed from a XenApp server.
Streamed to client. Grants users access to a profiled application that streams from the
file share to their user devices and launches locally from within an isolation environment.
With this option, the application uses client resources instead of server resources. Users
must have the offline plug-in installed and access the application using online plug-in or
a Web Interface site. If selected, user devices that do not support client-side
application virtualization (such as, they use a non-Windows client) or do not have the
offline plug-in installed locally cannot launch the application.
If you selected or Accessed from a server Streamed if possible, otherwise accessed from a server
, you also need to select the . These are: Server application type
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.
6.3.1.5. To configure locations of published applications
Updated: 2010-01-22
To access this option in the XenApp console, from the Publish Application wizard, continue to the Location
page. Alternatively, to modify a location, select a published application and under , select Common Tasks
> > > . Modify application properties Modify all properties Basic Location
When you publish an application, specify the command-line and working directory (optional) for the application:
. The full path of the application's executable file. Append the symbols “%*” (percent Command-line
and star symbols enclosed in double quotation marks) to the end of the command-line to act as
a placeholder for client-supplied application parameters. When a plug-in makes a connection request,
the server replaces the symbol “%*” in the command-line with application parameters provided by
the plug-in.
If the path to the application's executable includes directory names with spaces, enclose the command
line for the application in double quotation marks. Include a space between the closing quotation mark
and the double quotation marks around the percent and star symbols. An example of the format to
use with a path with spaces and a placeholder is:
“C:\Program Files\Windows Media Player\mplayer1.exe” “%*”
Important: Changing the command-line text removes all file type associations from the application.
If you change the command-line text, modify the Content Redirection application property page to
select the file types you want to associate with the application for client to server content redirection.
. By default, this path is the same as the path in the field. To run Working directory Command line
the application from a different directory, add an absolute path to this field.
6.3.1.6. 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)
6.3.1.7. To disable command-line validation
Updated: 2010-04-05
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.
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 page of Location
the application properties, append the symbols “%**” (percent and two star symbols enclosed in
double quotation marks) to the command-line parameter.
6.3.2. 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 XenApp 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.
Streaming Applications to User Devices
If you deliver streamed applications directly to user desktops, users can launch the streamed applications,
which run in an isolation environment on their desktops and use local resources to run the applications.
This delivery method offers the full set of application streaming options including desktop integration and
offline access.
Before publishing an application to be streamed to client desktops, complete the following tasks:
Install the offline plug-in locally, where it runs in the background to enable application streaming.
Install the latest version of online plug-in locally.
To stream to client devices across a network protected by a firewall, configure firewall policies to
allow those applications access.
After all of these tasks are complete, publish the application as . Streamed to client
Streaming Applications to a XenApp Server
To simplify application delivery to servers in a server farm, stream applications to a XenApp server and
virtualize the applications through an ICA connection to user devices.
For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site
to the Trusted sites list in Internet Explorer on the user devices.
Before publishing an application that is streamed to server, ensure your Web Interface sites and Citrix
XenApp sites are configured to run one of the following application types:
Remote applications only, or
Dual mode streaming (streamed if possible, otherwise accessed from a server)
For information about managing application types on Web Interface sites, see . Technologies > Web Interface
After you ensure all of these tasks are complete, publish the application as . Streamed to a server
6.3.2.1. Publishing Streamed Applications
Updated: 2011-01-17
To stream applications to user devices, start by reviewing the . System Requirements for Application Streaming
Before publishing an application for streaming, you must use the Citrix Streaming Profiler, a stand-alone utility,
to create a streaming application profile and save the profile on a network file share or Web server (your
App Hub). For instructions, search for . In particular, see Creating Application Profiles To create a profile and target
, as well as other topics in that section.
1.
2.
3.
After creating the application profile, continue by publishing the application to make it available to users.
When you publish an application, you make choices about how to deliver the application and its properties.
Use the Publish Application wizard in the Delivery Services Console, the same wizard you use to publish
installed applications. To review the general steps in the wizard, see To publish a resource using the
. Publish Application wizard
In the wizard, select the delivery options to publish the application for streaming. For guidance, see To select
. Continue by locating the application profile stored in your App Hub and finish a streaming delivery method
the wizard.
In addition, refer to other topics about application properties and preferences and how to configure offline
access (optional).
Finally, to prepare user devices for streaming, see , Deciding Which Plug-ins to Use for Application Streaming
as well as other topics about the Citrix Plug-ins.
Important: To launch streamed applications, user devices must have sufficient RAM locally.
6.3.2.2. To select a streaming delivery method
Updated: 2010-03-09
You select the resource type in the XenApp console while running the Publish Application wizard.
Important: For users to stream applications through a Web site using an Internet Explorer or Firefox
browser, add the site to the Trusted sites list in Internet Explorer on the user devices.
To open the Publish Application wizard, from the XenApp console, under the node, expand XenApp
the farm or server to which you want to publish an application. Select the node, and Applications
from the pane, choose and follow the instructions in the wizard. Actions Publish application
Optionally, to change the delivery method after publishing an application, from the menu, select Action
> and follow the instructions in the wizard. Other Tasks Change application type
In the Publish Application wizard, on the page, select . Type Application
Select a delivery method from the list: Application type
Accessed from a server. Users launch the application that runs on a XenApp server and
uses shared server resources, or launch it from a Web browser using a Web Interface site
you create. If you choose this option, you must then enter the location of the executable file for
the application and the XenApp server on which it will run. This is the typical application type
unless you intend to stream your applications to the client desktop. With this method, users
access the applications using the online plug-in or Web plug-in. This method does not
support desktop integration or offline access to applications.
From the list, select the delivery method: Server application type
Installed application. Users launch the application installed on a XenApp server.
Streamed to server. The application in the profile is streamed from the App Hub to
the XenApp server, where the offline plug-in is installed by default. The application
displays on the user devices using the online plug-in or Web plug-in; the offline plug-in is
not required on the user device. With this method, users access the applications using
the online plug-in or Web plug-in. This method does not support desktop integration or
offline access to applications.
Streamed if possible, otherwise accessed from a server (called ). dual mode streaming
Grants users access to a profiled application that streams from the file share to their user
devices and launches locally from within an isolation environment. Alternatively, user devices that
do not support streamed applications (such as when they do not have the offline plug-in
installed) instead use an ICA connection to access the application installed on or streamed from
a XenApp server.
From the list, select the delivery method for clients that do Server application type alternative
not support streaming to user device:
Installed application. Users launch the application installed on a XenApp server.
3.
1.
2.
3.
4.
Streamed to server. The application in the profile is streamed from the App Hub to
the XenApp server, where the offline plug-in is installed by default. The application
displays on the user devices using the online plug-in or Web plug-in; the offline plug-in is
not required on the user device. With this method, users access the applications using
the online plug-in or Web plug-in. This method does not support desktop integration or
offline access to applications.
Streamed to client. With this method, you make available the full set of application
streaming features. When you stream applications directly to client desktops, some of
the application files are cached locally and the application runs locally from within an
isolation environment using the resources of the user device.
Users must have both the offline plug-in and online plug-in installed locally.
With this delivery method, you can configure the application and users for offline access
. When this configuration is completed, the entire application is fully cached on the
user device. Users can disconnect from the network and continue using the application for
the time specified in the offline license.
User devices that do not support client-side application virtualization (such as, they use
a non-Windows client) or do not have the offline plug-in installed locally cannot launch
the application.
Note: You can also force a delivery method for applications published as "Streamed to
client" based on filters. To do this, configure the Load Balancing policy setting (located in
the Delivery Services Console) for . The policy setting overrides Streamed App Delivery
the selection in the publishing wizard.
6.3.2.3. To force a delivery method for streamed applications
Updated: 2010-03-05
Use the Load Balancing Policies to apply settings to sessions that are filtered for Web access, specific users,
client devices, IP addresses, or server. Use the delivery method policy to override the delivery method
of applications published as stream to client.
If you disable the policy setting or do not configure it, the delivery method specified in the Publish
Application wizard is used
From the Delivery Services Console, select the farm.
Under the server, select . Load Balancing Policies
From the pane, configure the policy settings for . Actions Streamed App Delivery
Select one of the following options:
(default setting). Allow applications to stream to the client or run on a Terminal Server
Force applications to stream to the client. User devices always stream the application from
the App Hub to the user devices. Users must have the offline plug-in installed and access
the application using the online plug-in or a Web Interface site. For example, you might use
this setting to prevent the use of server resources. User devices without the offline plug-in
and either the online or Web plug-in cannot launch the application.
Do not allow applications to stream to the client. Users always launch streamed
applications from the server. For example, you might use this option to prevent applications
from streaming to specific clients. In addition:
If you publish a streaming application with Streamed if possible, otherwise
(dual mode streaming), users always launch the application accessed from a server
from the server using the alternative method you selected.
If you publish an application as (without dual mode), the connection fails. Streamed to client
This table describes the default delivery of each application type and the results of setting the policy. The
policy setting overrides the delivery protocol for applications that are published as “streamed to client.”
1.
2.
Application type No policy (default delivery) With policy:
Do not
allow stream
to client
With policy:
Force stream
to client
Streamed to client Citrix offline plug-in
streams application to desktop.
Connection fails. Connection works.
Accessed from a server:
—Installed application
Citrix online plug-in virtualizes
the application installed on
XenApp (not streamed).
Policy does
not apply.
Policy does
not apply.
—Streamed to server Offline plug-in streams
application from file share to
XenApp and any online 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):
—Installed application
Dual mode: Offline plug-in
streams application to desktop.
Otherwise, the online plug-in
connects to the application
installed on server (not streamed).
Online plug-
in always
connects
to
application
installed on server.
Offline plug-
in always
streams
application
to desktop.
—Streamed to server Dual mode: Offline plug-in
streams application to desktop.
Otherwise, offline plug-in
streams application to the server.
Offline plug-
in always
streams
application to
the server.
Offline plug-
in always
streams
application
to desktop.
6.3.2.4. To provide HTTP or HTTPS delivery method
Updated: 2010-03-05
To stream a profile using the HTTP or HTTPS protocol delivery method, use the following example to configure
a virtual directory on the Web server.
These steps assume that you already profiled the application and saved it to a file share using a UNC path.
To stream from an HTTPS address, see the additional steps at the end of this procedure. Note that
HTTPS requires additional certificate setup. For assistance, contact your network administrator.
The Basic authentication scheme for HTTP is not allowed by default. To allow Basic authentication, create
the following registry key:
For 32-bit systems: HKEY_LOCAL_MACHINE\Software\Citrix\Rade\AllowUnsecuredHttpAuth
For 64-bit systems:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\Rade\AllowUnsecuredHttpAuth
Type: REG_DWORD
Value: 1
In the following example, the XenApp server, Web server, and file server are located on the same physical
server. This is not a requirement.
To configure the Web server:
Create a file share, if one does not already exist. For example: Web server name: WebServer
Physical location on Web server: The share name: An administrator c:\webProfiles webProfiles
must share this folder with the “everyone” group assigned READ access and the “administrators”
group assigned WRITE access at both the share level and NTFS level. UNC path:
\\WebServer\webProfiles
On the Web site hosting the profile, add the following MIME type information:
2.
3.
4.
1.
2.
3.
4.
5.
5.
6.
7.
8.
9.
10.
11.
1.
2.
3.
4.
5.
1.
2.
3.
4.
Extension:*
MIME type: application/octet-stream
Set "Execute Permissions" to NONE
You can set this information for the Web site hosting the profiles or for a specific folder in the
virtual directory that holds the profiles.
In addition, if the profile includes pre-launch or post-exit scripts, also add the following MIME
Extension: type information for the file extension of each script, such as .bat or .com. <file extension>
, and MIME type: application/octet-stream
In the directory hosting the profiles:
Open and select the tab. Properties Directory
In the Configuration area, keep one application file extension (it doesn't matter which one
you keep) and remove all the rest of the file extensions.
Create a placeholder extension for application mapping; for example, ".testcitrix," which should
not occur in the profile.
Copy the settings from the file extension that remains (Step 4b) to the placeholder extension.
Delete the file extension that remained in Step 4b, leaving only the placeholder extension from
Step 4c.
Create a virtual Web site that points to the file share using the UNC path. For best results, do not
use spaces in the URL. For example: HTTP (or HTTPS) path of virtual directory: http:
//WebServer.domain.com/webProfiles
Turn on Directory Browsing on the virtual Web site. Now you can test the configuration; continuing
the example, browse to http://WebServer.
. If the Web server is domain.com/webProfiles/myApplication/myApplication.profile
configured correctly, the .profile file opens looking like an xml file (not an error message). For HTTP,
you have now completed the configuration of the Web server.
For HTTPS, additional binding configuration of the Web server is required. See the additional
steps following this procedure, based on your operating system.
In the XenApp console, publish the application as , , or Streamed to client Streamed to server
and continue in the wizard. Streamed if possible, otherwise accessed from a server
On the page, enter the full URL path (starting with HTTP or HTTPS) to the profile (browsing to Location
an HTTP location is not supported at this time). Use a fully qualified domain name, not a relative
domain name.
Click in the field titled to Application to launch from the Citrix streaming application profile
select the application.
Finish the remaining pages of the wizard. The application is ready to stream to the client device using
the HTTP delivery method.
To stream from an HTTPS address from Windows Server 2008 additional configuration is required on the
Web server. An appropriate Web Server Certificate must be already installed:
From IIS, edit the for the Web Site. Bindings
In the dialog, click . Site Bindings Add
Under , choose . Type https
For , choose the installed Web Server Certificate. SSL certificate
Using the previous example, browse to on the Web server, which https://WebServer/webProfiles
must be a member of the domain and have the root certificate installed.
To stream from an HTTPS address from Windows Server 2003, install a Web Server Certificate from a
domain certificate authority:
From IIS, open for the virtual Web site. Properties
Click the tab. Directory Security
Under , click . Server Communications Server Certificate
4. Complete the Web Server Certificate wizard, and using the previous example, browse to
on the Web server, which must be a member of the domain and https://WebServer/webProfiles
have the root certificate installed.
6.3.2.5. Configuring Offline Access
Updated: 2010-02-19
Administrators can configure applications that are published to stream to desktops for . This offline access
feature allows users to disconnect from the company network and continue to run their applications in
offline mode for a specified length of time. No additional configuration is needed while profiling the application
to create application profiles or targets that can be accessed offline.
After you configure the offline application policy settings and configure a streamed application for offline
access, the next time the user device connects to XenApp, the offline plug-in downloads the application
and caches it on the user device.
Important: Before you configure offline access, refer to System Requirements for Application Streaming
for the supported platforms and system prerequisites for user devices.
Step 1: Configure policy settings for offline access
Step 2: Install the online and offline plug-ins on user devices
Step 3: Publish the application for offline access
You can complete these steps in any order, but users cannot run applications in offline mode until all steps
are completed.
Step 1: Configure Policy Settings for Offline Applications
Configure these Citrix policy settings for : Offline Applications
Offline app users (required). Create a list of users or groups who have offline access permission and
add that list both when creating the policy for Offline app users and when publishing the application.
Users or groups listed in the offline app users policy setting and who are also configured for the
application have permission to run offline-enabled applications in online and offline mode. Users who
are configured for the application, but who are not added to the policy list can access the
application online, but not offline.
Users or groups on this list use an offline license to launch applications regardless of whether they
are connected to the network or disconnected.
Offline app license period (required). Specify the number of days applications can work offline
before users have to renew the license (21 days by default, but can range from 2 to 365 days).
For versions 1.0 through 5.1 of the plug-in, the license for each application in the profile is activated
when the user launches the application the first time, for online or offline use. Beginning with version 5.2
of the plug-in, when the user launches an application in the profile for the first time, for online or
offline use, the offline license is activated for all other applications in the profile, as well. This occurs at
the farm level. Thus, the offline license for all applications in the profile expires based on the date of
the first application launched the first time, regardless of when the other applications are launched.
To configure licenses, administrators can use the License Management Console or command-line
tools. They must also ensure they have a sufficient number of licenses to support the total number of
users with offline access permission. Users who run XenApp hosted applications can also
stream applications to user devices without requiring a separate license. For general information, in
the topics for , see . Licensing Your Product Getting Started with Citrix Licensing
When users with offline access log on using the online plug-in, they automatically either check out
an offline license or renew a license already checked out. If users stay logged on, licenses are
renewed automatically each day. If the license is near its expiration date while a user is running
the application in offline mode, a notice appears reminding the user to log on (that is, change to
online mode). When the user logs on, the offline license is renewed automatically if a license is available.
If the license expires and no license is available, the user cannot launch the application offline.
(optional). Use this setting to enable offline application clients that Offline app client trust
1.
have disconnected to recreate sessions when reconnecting, without authenticating again.
(optional). Use this setting to enable logging of offline application events Offline app event logging
to the event log on the server.
Step 2: Install the Online and Offline Plug-ins on User Devices
To use the offline access feature, install both the offline and online plug-ins on the user device. The offline plug-
in caches each streamed application on the hard drive of the user device. After the application is cached, the
user can disconnect from the network or server and continue to run the application in offline mode for the
period of time specified in the license.
Step 3: Publish the Application for Offline Access
The offline access feature is available only for applications that you publish as or Streamed to client
. Streamed if possible, otherwise accessed from a server
In addition, when publishing an application for offline access, check the application's documentation and Web
site to determine whether any special configuration is required on the user device to enable offline access of
that application. For example, to stream Microsoft Outlook to the user device for offline access, users must
enable the Microsoft Exchange Setting to "Use Cached Exchange Mode."
Configure the application for offline access while publishing the application or later using the
application properties:
Enable the application for offline access and select the caching preference.
Create a list of users or groups who have offline access permission and add that list both when creating
the policy for Offline app users and when publishing the application.
6.3.3. Configuring Content Redirection
Updated: 2009-12-16
The capability to redirect application and content launching from server to client or client to server is referred
to as . content redirection
Content redirection allows you to control whether users access information with applications published on
servers or with applications running locally on client devices.
Note: For your users to access content published with a specified universal naming convention (UNC) path
and through the Web Interface, you must publish and configure an application for content redirection so it
is associated with the file type of the published content.
6.3.3.1. To enable content redirection from server to client
Updated: 2010-03-04
When you enable server to client content redirection, embedded URLs are intercepted on the XenApp server
and sent to the client device and the Web browser or multimedia players on the client device open these
URLs. This feature frees servers from processing these types of requests by redirecting application launching
for supported URLs from the server to the local client device. The browser locally installed on the client device
is used to navigate to the URL. Users cannot disable this feature. Accessing published content with local
client desktops does not use XenApp resources or licenses because local viewer applications do not use
XenApp sessions to display the published content.
For example, users may frequently access Web and multimedia URLs they encounter when running an
email program published on a server. If you do not enable content redirection from server to client, users
open these URLs with Web browsers or multimedia players present on servers running XenApp.
Note: If the client device fails to connect to a URL, the URL is redirected back to the server.
Complete the following configurations:
From the Microsoft Management Console (MMC), locate the Citrix policy setting for Category_ICA >
. Set to enable file type associations for URLs and File Redirection Host to client redirection
1.
2.
1.
2.
3.
some media content to be opened on the user device (disabled by default). When disabled, content
opens on the server.
From the XenApp console, publish the content file and select the users or groups that can access it.
The following URL types are opened locally through user devices for Windows and Linux when this type of
content redirection is enabled:
HTTP (Hypertext Transfer Protocol)
HTTPS (Secure Hypertext Transfer Protocol)
RTSP (Real Player and QuickTime)
RTSPU (Real Player and QuickTime)
PNM (Legacy Real Player)
MMS (Microsoft Media Format)
If content redirection from server to client is not working for some of the HTTPS links, verify that the user
device has an appropriate certificate installed. If the appropriate certificate is not installed, the HTTP ping
from the client device to the URL fails and the URL is redirected back to the server. For legacy plug-ins,
content redirection from server to client requires Internet Explorer Version 5.5 with Service Pack 2 on
systems running Windows 98 or higher.
6.3.3.2. To configure content redirection from client to server
Updated: 2010-02-25
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 online plug-in open all files of the associated type with applications published on the
server. Content redirection from client to server is available only for users connecting with the online plug-in.
For example, if you have users who run applications such as email programs locally, use the content
redirection capability with XenApp to redirect application launching from the user device to the server.
When users double-click attachments encountered in an email application running locally, the attachment
opens in an application that is published on the server, associated with the corresponding file type, and
assigned to the user.
Complete the following configurations:
On the Web Interface server, configure Web Interface to allow content redirection for the farm.
In the Delivery Services Console, as you publish the application, associate it with file types and select
the users or groups that can connect to it. When users launch the application, the file type association
is changed to reference the published application in the Windows registry on the user device.
For example, if you publish a Microsoft Word document, make sure to also publish Microsoft Word on
a XenApp server so that the .doc file can open in Word.
Note: When you associate a file type with a published application, several file extensions can
be affected. For example, when you associate the Word document file type, file extensions in addition
to the .doc extension are associated with the published application.
Verify that the User policy setting is enabled, either for the entire farm, Client drive redirection
for specific servers, or for specific users or groups.
When you configure content redirection from client to server, context menu commands available from
within Windows Explorer function differently than on user devices that do not use this feature. For example, if
you right-click a file in Windows Explorer on a user device with content redirection from client to server
enabled for the file type, the command opens the file with the remote application on XenApp. For Open
a streamed application, the file could be opened either on the user device or on the XenApp server, depending
on the delivery configuration.
Most commands on the Windows Explorer context menu are unaffected because they are not configured
under keys modified by XenApp. Context menu items are generally defined by each application when installed.
1.
2.
3.
4.
5.
6.3.4. Managing Application Properties
Updated: 2009-11-20
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 menu, select . Action Application properties
Important: The resource type you publish (application, content, or server desktop) determines your
path through the Publish Application wizard; consequently, the properties associated with the resource
may vary.
6.3.4.1. To rename a published application
Updated: 2010-09-16
Use the property to change the application name and description that you selected in the Name
Publish Application wizard. Changes take effect after the user reconnects or refreshes the user device.
This feature can distinguish among multiple versions of the same application.
In the left pane of the console, select the published application.
From the menu, select and then select . Action Application properties Name
The is the name users see on their user device, and it must be unique within the Display name
folder. XenApp supports application names that use Latin-1 and Unicode character sets,
including characters used in Japanese, Chinese, and Korean.
The appears in the console and should be unique within a farm (maximum Application name
38 characters). When the application is published, this name is the same as the display name by default.
The appears in Web Interface. Application description
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.
6.3.4.2. To configure locations of servers for published resources
Updated: 2009-11-19
Choose the server on which the published application or desktop is available through the page of Servers
the Publish Application wizard. To modify the setting, from the menu, select Action Application properties
and then select . Servers
Important: For installed applications, select the server where the published application is installed.
For streamed-to-server applications, select the server to which the profiled application will stream and execute.
The list displays the servers that belong to the farm. Initially, all servers in the farm appear. Use Servers
a filter to display only servers running a particular operating system or Citrix version.
Note: If you apply a filter (in the dialog box), the filter settings remain in effect Select Servers
each time the Publish Application wizard is run until the filter is removed or changed.
Use the option to import an application server list file (*.asl). You export the server Import from file
list of a previously published application and then import this settings file when creating a new
published application.
1.
2.
3.
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.
6.3.4.3. To specify locations of applications for streaming
Updated: 2010-01-22
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:
. Provide the location of the manifest file (.profile). Citrix streaming application profile address
For example, enter the Full Universal Naming Convention (UNC) path (such as
\\citrixserver\profiles\Adobe Reader\Adobe Reader.profile).
. After this field populates Application to launch from the Citrix streaming application profile
with files, choose the application from the drop-down menu.
. (Optional) These parameters are used when the profiled Extra command-line parameters
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.
6.3.4.4. To enable an application for offline access
Updated: 2010-01-22
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 check Enable offline access
box on the page. Offline Access
In Application Properties, select > > . Click the Basic Streaming settings Offline Access Enable
check box to enable the feature. offline access
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:
. Caches the application when the user logs on (selected by Pre-cache application at login
default). However, concurrent logons may slow network traffic.
. Caches the application when users launch it. Use this option if Cache application at launch time
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.
6.3.4.5. To configure user access to applications
1.
2.
3.
Updated: 2010-04-07
Choose the user accounts that can access applications through the page of the Publish Application Users
wizard. To modify user accounts, from the menu, select and then select . Action Application properties 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.
Select how to configure user accounts:
Select to let all users log on anonymously and start the Allow anonymous users
streamed application without specifying a user name, domain name, and password (selected
by default). This selection disables the remaining options on the page.
Select to allow only configured users to start the application. Allow only configured users
For example, select this option for all streamed applications.
Selecting this option enables the drop-down list, which allows you Select directory type
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.
Use the drop-down box to select either or Select directory type Citrix User Selector
. Operating System User Selector
Click . Add
If you selected , complete the following tasks in the Citrix User Selector Select Users or Groups
dialog box:
Select your account authority from the drop-down list. The drop-down list contains Look in
all trusted account authorities configured on the servers in the farm. These include Novell
Domain Services for Windows (NDSfW) domains, Windows NT domains, Active Directory
domains, and local servers. (NDSfW domains appear only if previously configured.) When you
select an account authority, the user accounts that are part of the selected authority appear in
the window below the drop-down list. By default, only user groups appear.
Select to display all user names in the selected domain. This option displays every Show users
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
and use semicolons (;) to separate names. of Names
If you selected , use the standard Windows dialog box to select Operating System User Selector
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 list. Changes take effect the next time the Configured Accounts
user launches the application.
6.3.4.6. Granting Access to Explicit or Anonymous Users
1.
2.
3.
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 is any user who is not a member of the Anonymous group. Explicit users have user accounts explicit user
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 . By default, anonymous 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.
6.3.4.7. To configure shortcuts for user devices
Updated: 2010-01-22
Configure or modify the application shortcut presented to user devices on the page Shortcut presentation
of the Application Publishing wizard. To modify the setting, from the menu, select Action Application properties
and then select . Shortcut presentation
To select a new icon for the application, click and use the options on the window. Change icon
To organize applications within folders on the user device, under , enter a Client application folder
folder name for this application. When users view their applications, this application is listed in the
folder you entered.
To specify the placement of the application shortcut, in the Application shortcut placement
section, select one or more of these options:
Add to the client’s Start menu. Creates a shortcut to this application in the user’s 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 client’s desktop. Creates a shortcut to this application on the user’s
local desktop.
Changes take effect after the user reconnects or refreshes the user device.
6.3.4.8. To configure access controlled by the Access Gateway
Updated: 2010-01-22
If Access Gateway (Version 4.0 or later) is installed, use the page of the Publish Access Control
Application wizard specify the type of connections that allow the application to appear in the list of
published applications on the user device. To modify the setting, from the menu, select Action
and then select . Application properties Access control
For example, if Access Gateway is installed and the application has software requirements, define a filter
in Access Gateway and apply the filter to the published application using XenApp.
Important: To use this feature, set your servers that receive XML requests to trust those requests.
Use this page to view or modify connection types:
This Allow connections made through Access Gateway Advanced Edition (Version 4.0 or later).
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.
Allows all connections except those made through Access Gateway Allow all other connections.
(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.
6.3.4.9. To associate published applications with file types
Updated: 2009-11-19
As you publish applications, you associate the published item with certain file types present in the
Windows registry on the server. Associate published applications with file types initially from the
Publish Application wizard. To modify the file types, from the menu, select Action Application properties
and then select . Content redirection
By associating published applications with file types and then assigning the applications to users, you
implement the following automatically:
Content redirection from user device to server. Users running a Citrix plug-in open all files of
an associated type with a specific published application and delivery method. For example, when
users double-click an email attachment, the attachment opens in an application based on the file type
and delivery method set for those users.
Note: If you do not want specific users to launch published applications automatically when
opening published content, do not assign published applications associated with file types to those users.
Content publishing. Users connecting through the Web Interface or using the online plug-in 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.
1.
2.
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 the online plug-
in can open published content with published applications.
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.
To list all file types associated with the application, click Show all available file types for
. Clear the check box to display only the selected file types. this application
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.
6.3.4.10. To update file type associations
Updated: 2010-03-10
File types are associated with applications in a server’s 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. To verify which file types are associated with a published application, from the menu, select Action
and then select . Application properties Content redirection
Use to associate these file types with the application in the server farm’s data store. Update file types
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.
If needed, update file types for the farm or for an individual server:
In the console, select a farm in the left pane and from the menu, select > Action Other Tasks
. Update file types
Select a server in the left pane and from the menu, select > Action Other Tasks Update file
. types from registry
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 you publish applications to be hosted on more than one server, be sure to update the file types on each server.
6.3.4.11. To configure alternate profiles
Updated: 2010-01-22
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 menu, select Action
> > > . Modify application properties Modify all properties Advanced Alternate profiles
When you click , enter the starting and ending IP range for which the alternate profile applies. Add
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.
6.3.4.12. To pass parameters to published applications
Updated: 2009-11-19
Use the page of the Publish Application wizard to enter the command line and pass parameters Location
to published applications. To modify the setting, from the menu, select and Action Application properties
then select . Location
When you associate a published application with file types, the symbols “%*” (percent and star symbols
enclosed in double quotation marks) are appended to the end of the command line for the application.
These symbols act as a placeholder for parameters passed to user devices.
If a published application does not launch when expected, verify that its command line contains the
correct symbols. By default, XenApp validates parameters supplied by user devices when the symbols “%*”
are appended. For published applications that use customized parameters supplied by the user device,
the symbols “%**” are appended to the command line to bypass command-line validation. If you do not
see these symbols in a command line for the application, add them manually.
If the path to the executable file includes directory names with spaces (such as “C:\Program Files”), you
must enclose the command line for the application in double quotation marks to indicate that the space belongs
in the command line. To do this, follow the instructions below for adding quotation marks around the %*
symbols and then add a double quotation mark at the beginning and the end of the command line. Be sure
to include a space between the closing quotation mark for the command line and the opening quotation mark
for the %* symbols.
For example, change the command line for the published application Windows Media Player to the following:
“C:\Program Files\Windows Media Player\mplayer1.exe” “%*”
6.3.4.13. To reduce user privileges for a streamed application
For applications configured to stream to client devices, only, use this setting to reduce the user privileges for
the application, thus reducing security risks. From the page of the Publish Application wizard User privileges
or from the menu, select > > . Action 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 (not selected by default). This setting Run application as a least-privileged user account
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.
6.3.4.14. To configure application limits and importance
When a user starts a published application, the plug-in establishes a connection to a server in the farm
and initiates a session. If the user then starts another published application without logging off from the
first application, the user has two concurrent connections to the server farm. Use this page to limit the number
of concurrent connections that users can make.
You can configure application limits and importance from the Publish Application wizard page, or from the Limits
menu > > > > . Action Modify application properties Modify all properties Advanced Limits
Under , select from the following options: Concurrent instances
and then enter the numerical limit in Limit instances allowed to run in server farm
Maximum instances
Allow only one instance of application for each user
If Preferential Load Balancing is available in your XenApp edition, this setting (along with the session
importance policy setting) determines the Resource Allotment associated with the session. The higher
the Resource Allotment of the session, the higher the percentage of CPU cycles allotted to it.
In the list box, set the priority that is used with the setting Application Importance Session Importance
to determine the level of service for the session in the XenApp farm: , , and . High Normal Low
6.3.4.15. To configure audio and encryption options for published applications
Updated: 2010-06-07
For applications published for an online connection, use the page of the Publish Application Client options
wizard to configure the Citrix plug-in audio and encryption options for when users connect to a
published application. To modify the setting, from the menu, select and Action Application properties
then select . Client options
The settings that Citrix plug-ins use to communicate with a published application vary according to the type
of plug-in. 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 Remote Desktop Server Configuration 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
Remote Desktop Server Configuration tool or connection policies cannot be higher than the application
publishing setting.
If the encryption level for an application is lower than any settings you specified for Remote Desktop
Server Configuration and connection policies, those settings override the application settings. If the
minimum requirements check box is selected and the plug-in connection does not meet the most restrictive
level of encryption, the server rejects the connection when the plug-in tries to connect to the application. If
the minimum requirements check box is selected, the plug-in setting is always used. However, the plug-in
setting must be as secure as the server setting or the connection is denied.
If you select under the Encryption list box, plug-ins can connect to the Minimum requirement
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 options: Client audio
Enable legacy audio. Select this option to allow audio support for applications to which
HDX MediaStream Multimedia Acceleration does not apply.
Note: By default, audio is disabled on the user device. To allow users to listen to audio
in sessions, turn on audio or give the users permission to turn on audio themselves in the plug-
in interface they are using, such as Citrix XenApp.
Minimum requirement. Select this option to allow plug-ins to connect to the published
application only if they have audio support. The check box under the Minimum requirement
Client audio list box applies only to the legacy audio setting. It does not apply to HDX
MediaStream Multimedia Acceleration.
In the section, select one or more of the following options: Connection encryption
Select to request the use of the Secure Sockets Layer (SSL) Enable SSL and TLS protocols
and Transport Layer Security (TLS) protocols for plug-ins connecting to the published application.
Select to apply the RC5 encryption level for the connection. Encryption
In the section, select or clear Printing Start this application without waiting for printers to
. be created Selecting this option can allow the plug-in to connect faster. However, if you select
this option, the printers may take a few seconds to be created; do not select this option for
applications that print to the printer immediately after being launched.
6.3.4.16. To configure application appearance
Updated: 2009-11-19
Define how the application appears to the user through the Appearance page of the Publish Application wizard,
or from the menu, select and then select . Action Application properties Appearance
To set the default window size, select the . Specify window size as a Session window size
standard resolution, custom resolution, percentage of the screen, or full screen.
To set the color depth for the application, select the . The available options Maximum color quality
are Better appearance (32-bit), Better speed (16-bit), or 256-color (8-bit).
To hide the application title bar and maximize the application at startup, change the setting in the
. Application Startup Settings
6.3.4.17. To disable or enable a published application
Updated: 2010-03-05
Take published applications offline temporarily or indefinitely when you are maintaining a published
application, such as applying an upgrade or a service pack to it. While an application is offline, it is not
accessible to users. You can disable multiple applications simultaneously.
You can initially disable an application as you publish it in the publishing wizard or enable or disable it
anytime from the console.
From the Publish Application wizard, continue to the page and select the Publish immediately
check box. When checked, the application is published, but users Disable application initially
cannot access it until you enable it.
In the console, select the application in the navigation pane, and from the menu, select Action
or . Enable application Disable application
In the console, select the application in the navigation pane, and to modify the file types, from the Action
menu, select and then select . On this page, select . Application properties Name Disable application
Note: If the option is selected and cannot be cleared, either the Disable application initially
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.
6.3.4.18. To delete a published application
As you publish updated applications on your servers, delete the older or less-frequently used
applications. Deleting a published application does not uninstall the application. It simply removes access to
the application through plug-in connections. You can delete multiple applications simultaneously.
1.
2.
1.
2.
3.
1.
2.
3.
1.
2.
In the left pane of the console, select the application.
On the menu, select . Action Delete application
6.3.4.19. To move a published application to another folder
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 or folders under Applications Applications
. Similarly, servers can be moved only to or folders under . You can move multiple Servers Servers
applications simultaneously.
In the left pane of the console, select the application.
On the menu, select . Action Move to folder
Use the folder dialog box to change the location of the application. Select destination
Alternatively, drag applications into a new folder.
6.3.4.20. To duplicate published application settings
Use the settings of a published application as a template to publish other applications. For example, if
you published an application with a specified user list, you might want to apply the same user list to a
new application hosted on the same set of servers. If so, copy the first published application, change the
name and location to those of the second application, and thereby publish a different application with the
same user and server properties. You can duplicate multiple applications simultaneously.
In the left pane of the console, select the application.
From the menu, select and a copy of the application appears under Action Duplicate application
the Applications node.
Select the duplicated application and change the required properties.
6.3.4.21. To export published application settings to a file
Updated: 2009-11-19
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.
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.
From the menu, select > . Select what Action Other Tasks Export application settings to a file
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.
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 on the page of Import from file Servers
the Publish Application wizard.
Note: This task is available only for applications that have servers associated with them. For
2.
3.
1.
2.
3.
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.
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.
6.3.4.22. To import published application settings from a file
Updated: 2009-11-19
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.
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.
From the menu, select > . Action Other Tasks Import application settings from a file
Use the dialog box to locate the settings file you want to import. Open
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 to confirm that you want to overwrite existing settings. The imported ASL or AUL Yes
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.
6.3.5. Making Virtual IP Addresses Available to Applications
Updated: 2010-01-11
Some applications, such as CRM and CTI, use an IP address for addressing, licensing, identification, or
other purposes and thus require a unique IP address or a loopback address in sessions. Other applications
may bind to a static port, which, because the port is already in use, causes the failure of multiple attempts
to launch an application in a multiuser environment. For such applications to function correctly in a
XenApp environment, a unique IP address is required for each device.
Use the virtual IP address feature to allow a dynamically-assigned IP address to each session so that
configured applications running within that session appear to have a unique address.
Processes require virtual IP if either:
They use a hard-coded TCP port number, or
They do of the following: both
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.
6.3.5.1. How Virtual IP Addressing Works
Updated: 2010-01-11
The Microsoft Remote Desktop (RD) IP Virtualization feature works as follows:
In Microsoft Server Manager, expand > Remote Desktop Services RD Session Host Connections
to enable the feature and configure the settings. For details, refer to Microsoft RD IP Virtualization
help and documentation, including the Microsoft TechNet Web site.
Once the feature is enabled, at session start-up, the server requests dynamically-assigned
IP addresses from the Dynamic Host Configuration Protocol (DHCP) server.
Based on your Virtual IP policy and the settings you configure, the RD IP Virtualization
feature assigns IP addresses to remote desktop connections on a per session or per program
basis. If you assign IP addresses for multiple programs, they share a per-session IP address.
After an address is assigned to a session, it uses the virtual address rather than the primary
IP address for the system whenever the following calls are made:
Bind¸closesocket¸connect, WSAConnect, WSAAccept, getpeername, getsockname,
sendto, WSASendTo, WSASocketW, gethostbyaddr, getnameinfo, getaddrinfo
XenApp extends the Windows virtual IP feature by allowing the API to return the virtual gethostbyname
IP address. In addition, XenApp adds virtual loopback to all APIs.
Note: All processes that require the XenApp feature must be added to the programs list for the Virtual
IP policy that you enable. Child processes do not inherit this functionality automatically. Processes can
be added with full paths or just the executable name. For security reasons, Citrix recommends that
you use full paths.
6.3.5.2. Binding Applications
Updated: 2010-01-11
Using the Microsoft IP virtualization feature within the Remote Desktop session hosting configuration,
applications are bound to specific IP addresses by inserting a “filter” component between the application
and Winsock function calls. The application then sees only the IP address it is supposed to use. Any attempt
by the application to listen for TCP or UDP communications is bound to its allocated virtual IP address
(or loopback address) automatically, and any originating connections opened by the application are
originated from the IP address bound to the application.
In functions that return an address such as (controlled by a XenApp policy) and GetHostByName() GetAddrInfo()
(controlled by a Windows policy), if the local host IP address is requested, virtual IP looks at the returned
IP address and changes it to the virtual IP address of the session. Applications that try to get the IP address
of the local server through such name functions see only the unique virtual IP address assigned to that
session. This IP address is often used in subsequent socket calls (such as bind or connect).
Often an application requests to bind to a port for listening on the address 0.0.0.0. When an application does
this and uses a static port, you cannot launch more than one instance of the application. The virtual IP
address feature also looks for 0.0.0.0 in these types of calls and changes the call to listen on the specific virtual
IP address. This enables more than one application to listen on the same port on the same computer
because they are all listening on different addresses. Note this is changed only if it is in an ICA session and
the virtual IP address feature is turned on. For example, if two instances of an application running in
different sessions both try to bind to all interfaces (0.0.0.0) and a specific port, such as 9000, they are bound to
and and there is no conflict. VIPAddress1:9000 VIPAddress2:9000
1.
2.
3.
6.3.5.3. To determine whether an application needs to use virtual IP addresses
Updated: 2009-12-11
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:
Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specific IP addresses
and ports.
Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.
Launch the application and, using TCPView, note which IP addresses and ports are opened by
the application and which process names are opening these ports.
To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0,
or 127.0.0.1.
To ensure that an application does not open the same IP address on a different port, launch an additional instance of the application.
6.3.5.4. To make virtual IP addresses available to applications running in sessions
Updated: 2010-01-15
Enable these Virtual IP policy settings to add additional support to the Windows IP Virtualization feature.
Virtual IP addresses provide published applications with unique IP addresses for use in sessions. This is
especially important for Computer Telephony Integration (CTI) applications that are widely used in call
centers. Users can access these applications on a XenApp server in the same way that they access any
other published application. For more information, see To determine whether an application needs to use
. virtual IP addresses
Before you begin, in Microsoft Server Manager console, enable the Remote Desktop IP Virtualization
feature and configure it to dynamically assign IP addresses using the DHCP server on a per-session or
per-program basis.
To extend the IP virtualization feature, configure the following Citrix policy settings for : Virtual IP
. Use this setting if your application uses the Virtual IP enhanced compatibility GetHostByName
API. When enabled, calls to within a session return the virtual IP address for the GetHostByName
session (disabled by default). The feature applies only for the applications listed in the virtual
IP compatibility programs list.
. Lists the applications that use the virtual IP Virtual IP compatibility programs list
enhanced compatibility policy.
. Use this setting if your application returns a large number Virtual IP adapter address filtering
of addresses, which slows down performance. When enabled, the list of addresses returned by
includes only the session virtual IP address and the loopback address, which GetAdaptersAddresses
can improve performance (disabled by default). The feature is enabled only for the applications listed in
the virtual IP filter adapter addresses programs list.
. Lists the applications that use the IP Virtual IP filter adapter addresses programs list
adaptor address filtering policy.
6.3.5.5. To make a virtual loopback address available to applications running in sessions
Updated: 2010-01-15
Use the virtual loopback policy for applications that use a loopback address for interprocess
communication. Enabling this virtual IP policy setting allows each session to have its own loopback address
for communication. When an application uses the localhost address (127.0.0.1) in a Winsock call, the
virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X, where X.X.X is a representation of the
session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that the session ID exceeds
1.
2.
the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0) to the maximum
of 127.255.255.255.
The virtual loopback feature does not require any additional configuration other than specifying in the
programs list which processes use the feature. Virtual loopback has no dependency on Virtual IP, so no
Microsoft server configuration is needed to enable virtual loopback.
For more information, see . To determine whether an application needs to use virtual IP addresses
Configure the following Citrix policy settings for : Virtual IP
. Use this setting to allow each session to have its own virtual Virtual IP loopback support
loopback address for communication (disabled by default). The feature is enabled only for the
applications listed in the Virtual IP virtual loopback programs list.
. Lists the applications that use the Virtual IP Virtual IP virtual loopback programs list
loopback support policy.
6.3.5.6. To supply client IP addresses to published applications on a server
Updated: 2010-03-09
Use the Client IP Address feature if an application fails because it requires a unique address strictly
for identification or licensing purposes, and the application does not require a virtual address for
communication. This feature hooks only calls that return a host IP address, such as gethostbyname(). Only
use this feature with applications that send the value in this type of call to the server application for
identification or licensing.
If you deploy this feature, consider the IP addresses used by each client device. For example, if two remote
users use the same IP address, a conflict will arise due to the duplicate address.
When these values are configured, configure either the Virtual IP Processes or Virtual Loopback Processes
with the same process names in the setting or Virtual IP compatibility programs list Virtual IP
setting for the policy. This function creates and manages the following virtual loopback programs list
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.
On the server on which the applications reside, start regedit.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to
reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use
of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the
registry before you edit it.
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
2.
3.
4.
1.
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\.
Close regedit and restart your server.
After making the prescribed registry modifications, add the application process in the programs list for
the policy. Do not configure the use of client IP addresses if:
Plug-ins connect using network protocols other than TCP/IP
Plug-ins reconnect to disconnected sessions from different client devices
Sessions use a pass-through plug-in
6.4. Working with Citrix Policies
Updated: 2010-04-07
To control user access or session environments, configure a Citrix policy. Citrix policies are the most
efficient method of controlling connection, security, and bandwidth settings.
You can create policies for specific groups of users, devices, or connection types. Each policy can contain
multiple settings. For example, you can configure settings to:
Configure farm settings such as Virtual IP, Health Monitoring and Recovery, and multimedia acceleration
Control sound quality for client devices
Allow users to access the Documents folder on their local client device
Allow or prevent remote users from being able to save to their hard drives from a session
Allow or prevent users from accessing the Windows clipboard
Set a required encryption level for Citrix plug-ins
Set the session importance level, which, along with the application importance level, determines
resource allotment for Preferential Load Balancing
You can work with policies through the Group Policy Editor in Windows or the Delivery Services Console
in XenApp. The console or tool you use to do this depends on whether or not your network environment
includes Microsoft Active Directory and whether or not you have the appropriate permissions to manage
Group Policy Objects (GPOs).
Using the Group Policy Editor
If your network environment includes Active Directory and you have the appropriate permissions to
manage Group Policy, use the Group Policy Editor to create policies for your farm. The settings you
configure affect the GPOs you specify through the Group Policy Management console.
Using the Delivery Services Console
If your environment includes a different directory service (such as Novell Directory Services for Windows) or
you are a Citrix administrator without permission to manage Group Policy, use the Delivery Services Console
to create policies for your farm. The settings you configure are stored in a farm GPO in the data store.
Note: In Active Directory environments, the farm GPO takes precedence over the local GPO on the server
in the event policy settings conflict. However, Active Directory GPOs take precedence over the farm GPO.
Tips for Working with Policies
If you create more than one policy in your environment, make sure that you prioritize the policies so that it
is clear which policy should take precedence in the event of a conflict.
The process for configuring policies is:
1.
2.
3.
4.
Create and name the policy.
Configure policy settings.
Apply the policy to connections by adding filters.
Prioritize the policy.
In general, Citrix 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.
6.4.1. Navigating Citrix Policies and Settings
Updated: 2010-03-17
In Active Directory, policy settings are collected into two main categories: Computer Configuration and
User Configuration. Computer configuration settings pertain to servers, regardless of who logs on.
User configuration settings pertain to users accessing the server, regardless of where they log on.
XenApp policies and settings are collected into similar categories: Computer and User. Computer policy
settings pertain to XenApp servers and are applied when the server is rebooted. User policy settings pertain
to user sessions and are applied for the duration of the session.
Accessing Policies and Settings
In the Delivery Services Console, you can access policies and settings by clicking the node from Policies
the console tree and then selecting either the or tabs in the middle pane. In the Group Computer User
Policy Editor, you can access policies and settings by clicking the node under Citrix Policies
or in the tree pane. Computer Configuration User Configuration
The Computer and User tabs each display a list of the policies that have been created. Beneath this list,
the following tabs are displayed:
displays the settings and filters currently configured for the selected policy Summary
displays by category the available and configured settings for the selected policy Settings
displays the available and configured filters for the selected policy Filters
Searching Policies and Settings
From these consoles, you can search the policies you create and their settings and filters. All searches find
items by name as you type. You can perform searches from the following places:
For searching policies, use the search tool near the list of Citrix policies
For searching settings, use the search tool on the tab Settings
For searching filters, use the search tool on the tab Filters
You can refine your search by:
On the or tabs, selecting or Active Filters, respectively, to search Settings Filters Active Settings
only the settings or filters that have been added to the selected policy.
On the tab, selecting a category such as or to search Settings Auto Client Reconnect Bandwidth
only the settings in that category.
To search the entire catalog of settings or filters, select or . All Settings All Filters
6.4.2. Creating Citrix Policies
Updated: 2010-03-17
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
1.
2.
3.
4.
5.
6.
appropriate settings instead of creating another policy. Avoid creating a new policy solely to enable a
specific setting or to exclude the policy from applying to certain users.
To create a policy
Depending on the console you use to manage Citrix policies:
From the Delivery Services Console, select the node in the left pane and then select the Policies
or tab. Computer User
From the Group Policy Editor, select the node in the left pane. Citrix Policies
Click . The New Policy wizard appears. New
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.
Choose the policy settings you want to configure.
Choose the filters you want to apply to the policy.
Elect to leave the policy enabled or clear the checkbox to disable the policy. Enable this policy
Enabling the policy allows it to be applied immediately to users logging on to the farm. Disabling the
policy prevents it from being applied. If you need to prioritize the policy or add settings at a later
time, consider disabling the policy until you are ready to apply it to users.
6.4.3. Configuring Policy Settings
Updated: 2010-03-18
Policies contain settings that are applied to connections when the policy is enforced. Policy settings can
be enabled, disabled, or not configured. By default, policy settings are not configured, meaning they are
not added to a policy. Settings can be applied only when they are added to a policy.
Some policy settings can be in one of the following states:
Allowed or allows or prevents the action controlled by the setting. Prohibited
Enabled or turns the setting on or off. If you disable a setting, it is not enabled in lower- Disabled
ranked policies.
For settings that are or , the action controlled by the setting is either allowed or Allowed Prohibited
prevented. In some cases, users are allowed or prevented from managing the setting's action in the session.
For example, if the setting is set to , users can control menu animations in their Menu animation Allowed
client environment.
In addition, some settings control the effectiveness of dependent settings. For example, the Client
controls whether or not users are allowed to access the drives on their devices. drive redirection setting
To allow users to access their network drives, both this setting and the setting must Client network drives
be added to the policy. If the setting is disabled, users cannot access their Client drive redirection
network drives even if the is enabled. Client network drives setting
In general, Computer policy setting changes go into effect when the server reboots. User policy setting
changes go into effect the next time the relevant users establish a connection. Policy setting changes can
also take effect when XenApp re-evaluates policies at 90 minute intervals.
Default Values of Settings
For some policy settings, you can enter a value or you can choose a value from a list when you add the setting
to a policy. You can limit configuration of the setting by selecting . Selecting this Use default value
option disables configuration of the setting and allows only the setting's default value to be used when the
policy is enforced. This occurs regardless of the value that was entered before selecting . Use default value
For example, for the setting, the default value is . When you add this Lossy compression level Medium
setting to a policy and select , medium compression is always applied to images when Use default value
the policy is enforced, even if the setting was previously configured as or . High None
Default values for all Citrix policy settings are located in the . Policy Settings Reference
1.
2.
Best Practices for Policy Settings
Citrix recommends the following when configuring policy settings:
Assign policies to groups rather than individual users. If you assign policies to groups, assignments
are updated automatically when you add or remove users from the group.
Do not enable conflicting or overlapping settings in Remote Desktop Session Host Configuration. In
some cases, Remote Desktop Session Host Configuration provides similar functionality to Citrix
policy settings. When possible, keep all settings consistent (enabled or disabled) for ease
of troubleshooting.
Disable unused policies. Policies with no settings added create unnecessary processing.
6.4.3.1. To add settings to a policy
Updated: 2011-02-15
Policy settings can be enabled, disabled, or not configured. By default, policy settings are not configured,
meaning they are not added to a policy. Settings can be applied only when they are added to a policy.
You can add settings to policies using one of the following methods:
Using the New Policy wizard, when creating a new policy
Using the Settings tab of the Edit Policy dialog box, when modifying an existing policy
Using the Settings tab of the AppCenter or Group Policy Editor (located beneath the policies list),
when modifying an existing policy
Note: When you modify a policy using the Settings tab on the console, the changes you make are applied
to the policy immediately after you configure the selected setting. However, when you modify a policy using
the Edit Policy dialog box, changes you make are applied to the policy only after you click on the Edit OK
Policy dialog box.
Select a setting you want to add to the policy and click . Add The dialog box Add Setting
appears, displaying the setting's default value, if applicable. You can accept or change this value
according to your policy requirements. If no default value is present, enter the appropriate value for
your environment.
Click to add the setting to the policy. OK The configured setting appears on the tab of Settings
the console in the view. Active Settings
6.4.4. Applying Policies
Updated: 2010-03-18
When you add a filter to a policy, the policy's settings are applied to connections according to specific criteria
or rules. If no filter is added, the policy is applied to all connections.
You can add as many filters as you want to a policy, based on a combination of criteria. The availability of
certain filters depends on whether you are applying a Computer policy or a User policy. The following table
lists the available filters:
Filter Name Filter Description Policy Scope
Access ControlApplies a policy based on the access control conditions through which a
client is connecting.
User policies only
Client
IP Address
Applies a policy based on the IP address (IPv4 or IPv6) of the user
device used to connect to the session.
User policies only
Client Name Applies a policy based on the name of the user device from which the
session is connected.
User policies only
User Applies a policy based on the user or group membership of the
user connecting to the session.
User policies only
Worker GroupApplies a policy based on the worker group membership of the server
hosting the session.
Computer policies
User policies
When a user logs on, XenApp identifies the policies that match the filters for the connection. XenApp sorts
the identified policies into priority order, compares multiple instances of any policy setting, and applies the
policy setting according to the priority ranking of the policy. XenApp recalculates the policy every 90 minutes
after the user logs on to the farm.
Any policy setting that is disabled takes precedence over a lower-ranked setting that is enabled. Policy
settings that are not configured are ignored.
Unfiltered Policies
By default, XenApp provides Unfiltered policies for Computer and User policy settings. The settings added to
this policy apply to all connections.
If you use Active Directory in your environment and use the Group Policy Editor to manage Citrix policies,
settings you add to the Unfiltered policy are applied to all farm servers and connections that are within the
scope of the Group Policy Objects (GPOs) that contain the policy. For example, the Sales OU contains a
GPO called Sales-US that includes all members of the US sales team. The Sales-US GPO is configured with
an Unfiltered policy that includes several user policy settings. When the US Sales manager logs on to the
farm, the settings in the Unfiltered policy are automatically applied to the session because the user is a
member of the Sales-US GPO.
If you use the Delivery Services Console to manage Citrix policies, settings you add to the Unfiltered policy
are applied to all servers and connections in the farm.
Filter Modes
A filter's mode determines whether or not the policy is applied only to connections that match all the filter
criteria. If the mode is set to (the default), the policy is applied only to connections that match the Allow
filter criteria. If the mode is set to , the policy is applied if the connection does not match the filter Deny
criteria. The following examples illustrate how filter modes affect Citrix policies when multiple filters are present.
Example: Filters of Like Type with Differing Modes
In policies with two filters of the same type, one set to and one set to , the filter set to Allow Deny Deny
takes precedence, provided the connection satisfies both filters. For example:
Policy 1 includes the following filters:
Filter A is a User filter that specifies the Sales group and the mode is set to . Allow
Filter B is a User filter that specifies the Sales manager's account and the mode is set to . Deny
Because the mode for Filter B is set to , the policy is not applied when the Sales manager logs on to Deny
the farm, even though the user is a member of the Sales group.
Example: Filters of Differing Type with Like Modes
In policies with two or more filters of differing types, set to , the connection must satisfy at least one Allow
filter of each type in order for the policy to be applied. For example:
Policy 2 includes the following filters:
Filter C is a User filter that specifies the Sales group and the mode is set to . Allow
Filter D is a Client IP Address filter that specifies 10.8.169.* (the corporate network) and the mode is set to
. Allow
When the Sales manager logs on to the farm from the office, the policy is applied because the connection
satisfies both filters.
Policy 3 includes the following filters:
1.
2.
3.
1.
Filter E is a User filter that specifies the Sales group and the mode is set to . Allow
Filter F is an Access Control filter that specifies Access Gateway connection conditions and the mode is
set to . Allow
When the Sales manager logs on to the farm from the office, the policy is not applied because the
connection does not satisfy Filter F.
6.4.4.1. To apply a policy
Updated: 2010-03-10
You must add at least one filter to a policy for that policy to be applied.
From the policy wizard, select the filter you want to apply and click . Add
From the New Filter dialog box, click to configure filter elements. Add
Select the mode for the filter.
The policy is applied the next time the relevant users establish a connection.
6.4.5. Using Multiple Policies
Updated: 2010-03-09
You can use multiple policies to customize 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 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.
Note: When managing policies through the Delivery Services Console, be aware that making frequent
changes can adversely impact server performance. When you modify a policy, the XenApp server
synchronizes its copy of the farm Group Policy Object (GPO) with the data store, propagating the change
to other servers in the farm. For example, if you make changes to five policies, the server synchronizes
the farm GPO five times. In a large farm with multiple policies, this frequent synchronization can result
in delayed server responses to user requests. To ensure server performance is not impacted by needed
policy changes, arrange to make these changes during off-peak usage periods.
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.
Citrix policies interact with policies you set in your operating system. Some Windows policies take
precedence over Citrix policies. For some policy settings, such as Secure ICA, the settings in policies must
match the settings in the operating system. If a higher priority encryption level is set elsewhere, the Secure
ICA policy settings that you specify in the policy or when you are publishing an application can be overridden.
For example, the encryption settings that you specify when you are publishing an application should be at
the same level as the encryption settings you specified throughout your environment.
6.4.5.1. Prioritizing Policies and Creating Exceptions
Updated: 2010-03-02
Prioritizing policies allows you to define the precedence of policies when they contain conflicting settings.
The process XenApp uses to evaluate policies is as follows:
1.
2.
1.
2.
3.
When a user logs on, all policies that match the filters for the connection are identified.
XenApp sorts the identified policies into priority order and compares multiple instances of any
setting, applying the setting according to the priority ranking of the policy.
You prioritize policies by giving them different priority numbers. By default, new policies are given the
lowest priority. If policy settings conflict, a policy with a higher priority (a priority number of 1 is the
highest) overrides a policy with a lower priority. Settings are merged according to priority and the
setting's condition; for example, whether the setting is disabled or enabled. Any disabled setting overrides
a lower-ranked setting that is enabled. Policy settings that are not configured are ignored and do not override
the settings of lower-ranked settings.
When you create policies for groups of users, client devices, or servers, you may find that some members of
the group require exceptions to some policy settings. You can create exceptions by:
Creating a policy only for those group members who need the exceptions and then ranking the
policy higher than the policy for the entire group
Using the mode of a filter added to the policy Deny
A filter with the mode set to tells XenApp to apply the policy to connections that do not match the Deny
filter criteria. For example, a policy contains the following filters:
Filter A is a Client IP address filter that specifies the range 208.77.88.* and the mode is set to . Allow
Filter B is a User filter that specifies a particular user account and the mode is set to . Deny
The policy is applied to all users who log on to the farm with IP addresses in the range specified in Filter
A. However, the policy is not applied to the user logging on to the farm with the user account specified in Filter
B, even though the user's computer is assigned an IP address in the range specified in Filter A.
To change the priority of a policy
From the console tree, choose to view Citrix Computer Policies or Citrix User Policies.
From the middle pane, select the policy you want to prioritize.
Click or as appropriate until the policy has the preferred rank. Increase Priority Decrease Priority
6.4.6. Determining Which Policies Apply to a Connection
Updated: 2010-03-17
Sometimes a connection does not respond as expected because multiple policies apply. If a higher priority
policy also applies to a connection, it can override the settings you configure in the original policy. You
can determine how final policy settings are merged for a connection by calculating the Resultant Set of Policy.
You can calculate the Resultant Set of Policy in the following ways:
Use the Citrix Policy Modeling Wizard to simulate a connection scenario and discern how Citrix
policies might be applied
Use Group Policy Results to produce a report describing the Citrix policies in effect for a given user
and server.
You can launch both tools from the Group Policy Management console in Windows. If your XenApp
environment does not include Active Directory, you can launch the Citrix Group Policy Modeling Wizard from
the Actions pane of the Delivery Services Console.
Using the Citrix Policy Modeling Wizard
With the Citrix Group Policy Modeling Wizard, you can specify conditions for a connection scenario such as
domain controller, users, Citrix policy filter evidence values, and simulated environment settings such as
slow network connection. The report that the wizard produces lists the Citrix policies that would likely take
effect in the scenario.
If you are logged on to the server as a domain user and your environment includes Active Directory, the
wizard calculates the resultant set of policy by including settings from Active Directory Group Policy
1.
2.
Objects (GPOs). If you run the wizard from the Delivery Services Console, the farm GPO residing on the server
is included in this calculation as well. However, if you are logged on to the server as a local user and run
the wizard from the Delivery Services Console, the wizard calculates the Resultant Set of Policy using only
the farm GPO.
Using Group Policy Results
The Group Policy Results tool helps you evaluate the current state of GPOs in your environment and generates
a report that describes how these objects, including Citrix policies, are currently being applied to a particular
user and server.
6.4.6.1. To simulate connection scenarios with Citrix policies
Updated: 2010-03-12
Depending on your XenApp environment, open the Citrix Group Policy Modeling Wizard:
From the Delivery Services Console, click the node in the console tree and then click Policies
from the Actions pane. Run the modeling wizard
From the Group Policy Management console, right-click the node Citrix Group Policy Modeling
in the console tree and then select Citrix Group Policy Modeling Wizard.
Follow the wizard to select the domain controller, users, computers, environment settings, and Citrix
filter criteria you want to use in the simulation.
When you click , the wizard produces a report of the modeling results. In the Delivery Services Finish
Console, the report appears as a node in the console tree, underneath the Policies node. The Modeling Results
tab in the middle pane displays the report, grouping effective Citrix policy settings under User Configuration
and Computer Configuration headings.
6.4.6.2. Troubleshooting Policies With No Configured Settings
Updated: 2010-03-17
Because settings configured in some policies can conflict with settings configured in others and policies can
have multiple filters, a policy may not behave as expected or it may not run at all. Users, IP addresses, and
other filtered objects can have more than one policy that applies to them simultaneously. In this case,
XenApp merges these policies’ settings to effectively form a new policy resulting from the existing ones.
This combination of settings is known as the policy. When there are multiple policies that can apply to resultant
a session, it is the resultant policy that XenApp enforces.
When you run the Citrix Group Policy Modeling Wizard or the Group Policy Results tool, you might create
a resultant policy that has no configured settings. When this happens, users connecting to their
applications under conditions that match the policy evaluation criteria are not affected by any policy rules.
This occurs when:
No policies have filters that match the policy evaluation criteria
Policies that match the filter do not have any settings configured
Policies that match the filter are disabled
If you want to apply policy settings to the connections that meet the specified criteria:
Make sure the policies that you want to apply to those connections are enabled
Make sure the policies that you want to apply have the appropriate settings configured
6.4.7. Applying Policies to Access Gateway Connections
Updated: 2010-03-12
You can create a policy that is applied to Access Gateway connections or to Access Gateway connections
with certain properties.
You can create Citrix policies to accommodate different access scenarios based on factors such as
1.
2.
3.
4.
5.
6.
7.
8.
1.
2.
9.
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. See the Access Gateway section of Citrix eDocs for
more information about creating filters.
Note: You must be using Access Gateway Advanced Edition (Version 4.0 or later) or Access
Gateway Enterprise Edition (Version 9.1 or later) to create filters that work with XenApp.
For published applications, select Allow connections made through Access Gateway
in the application properties. Advanced Edition
Ensure that your farm is configured to allow Access Gateway connections, which it is by default.
Create a Computer policy within XenApp that has the policy setting enabled. Trust XML requests
Create a User policy within XenApp that includes a filter referencing Access Gateway filters.
To apply a policy filter based on Access Gateway connections
Depending on the console you use to manage Citrix policies:
From the Delivery Services Console, select the node in the left pane and then select the Policies
tab in the middle pane. User
From the Group Policy Editor, under in the left pane, select the User Configuration Citrix Policies
node.
Select an existing User policy or create a new User policy.
Follow the policy wizard to the filters page or click the tab in the middle pane of the console. Filters
Select and then click . Access Control Add
Click to configure the filter. Add
Select . With Access Gateway
To apply the policy to connections made through Citrix Access Gateway without considering
Access Gateway policies, accept the default entries in the and fields. AG farm name Access condition
To apply the policy to connections made through Citrix Access Gateway based on existing Access
Gateway policies, perform the following actions:
In , enter one of the following items: AG farm name
If using Access Gateway Advanced Edition, enter the name of the Access Gateway farm.
If using Access Gateway Enterprise Edition, enter the virtual server name of the
Access Gateway appliance.
In , enter one of the following items: Access condition
If using Access Gateway Advanced Edition, enter the name of the Access Gateway filter
for XenApp to use.
If using Access Gateway Enterprise Edition, enter the name of the endpoint session policy
for XenApp to use.
Important: XenApp does not validate Access Gateway farm, server, and filter names, so
always verify this information with the Access Gateway administrator.
To apply the policy to every connection except those made through Access Gateway, in the list Mode
box, select . Deny The filter's mode tells XenApp whether or not to apply the policy to connections
that match the filter criteria. Selecting tells XenApp to apply the policy to connections that do Deny
9.
not match the filter criteria.
6.4.8. Enabling Scanners and Other TWAIN Devices
Updated: 2010-06-08
XenApp lets users control client-attached TWAIN imaging devices, such as scanners and cameras, from
published applications. This feature is known as because XenApp provides TWAIN support TWAIN redirection
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 user device and have the associated vendor-
supplied TWAIN driver installed locally.
Citrix online plug-in 11. or later or the Citrix offline plug-in. x
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 policy setting must be added to the appropriate policy. Client TWAIN device redirection
To configure image compression, add the setting and select the TWAIN compression level
appropriate compression level.
The following table lists the TWAIN hardware and software tested with XenApp. While other TWAIN devices
may work, only those listed are supported.
Scanners and Scanning Devices Canon CanoScan 3200F
Canon CanoScan 8000F
Canon CanoScan LiDE600F
Fujitsu fi-6140
HP ScanJet 8250
Software Microsoft Office Publisher 2007
Microsoft Office Word 2007 Clip Organizer
OmniPage SE
Consider the following after enabling TWAIN redirection:
Configure bandwidth limits for image transfers. You can add the TWAIN device redirection
or the settings to the policy bandwidth limit TWAIN device redirection bandwidth limit percent
and enter the appropriate values denoting the maximum bandwidth allowed for image transfers.
Some applications are not Remote Desktop Session Host aware and look for Twain32.dll in the
\Windows directory of the user profile (by default, C:\Documents and Settings\UserName
\Windows). Copying Twain32.dll into the \Windows directory of each user profile resolves this issue.
You can also correct this by adding the application to the Remote Desktop Session Host
application compatibility list with the following two flags specified:
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 transfer mode is not supported. disk file
6.5. Managing Session Environments and Connections
Updated: 2010-01-18
Provide user access to your farm’s 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 refers to a particular instance of a user’s activity on the session
server; sessions are the virtualization of the user’s 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 . Users access published resources through client connection
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 device’s 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.
6.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 the Citrix online plug-in, you can also customize the user’s 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
online plug-in and the Web Interface documentation.
6.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 server’s
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 group policies on local
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.
6.5.1.2. Controlling Access to Devices and Ports
Updated: 2010-02-26
The Citrix online plug-in 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 plug-in reports the available client drives and COM ports to the server. By default, client
drives appear as network resources so the drives appear to be directly connected to the server. The client’s
drives are displayed with descriptive names so they are easy to locate among other network resources.
These drives are used by Windows Explorer and other applications like any other network drive.
In Citrix policies, settings are used for mapping. redirection
Redirecting Client COM Ports and Audio
Client COM port redirection allows a remote application running on the server to access devices attached to
COM ports on the user device. COM port and audio redirection are configured with the Client COM
and User policy settings. port redirection Client audio redirection
For more information, see the documentation for the plug-ins you plan to deploy.
6.5.1.2.1. To enable user execute permissions on mapped drives
Updated: 2010-07-23
In general, XenApp displays client drive letters as they appear on the user device; for example, the user
device's hard disk drive appears as "C: on ," where is the name of the user device. ClientName ClientName
1.
2.
3.
4.
5.
This allows the user to access client drive letters in the same way locally and within sessions.
You can turn off client drive redirection through XenApp policies. In doing so, you also turn off mapping to
client floppy disk drives, hard drive, CD-ROM drives, or remote drives regardless of the policy settings for
those individual devices.
As a security precaution, when a user logs on to XenApp, by default, the server maps client drives without
user execute permission. To enable users to execute files residing on mapped client drives, override this
default by editing the registry on a XenApp server.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall
your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry
Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
After installing XenApp, open the Registry Editor.
Find the
key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\picadm\Parameters\ExecuteFromMappedDrive.
To grant users execute permission on mapped drives, set to . ExecuteFromMappedDrive 1
To deny users execute permission on mapped drives, set to . ExecuteFromMappedDrive 0
Restart the server.
6.5.1.3. Displaying Local Special Folders in Sessions
Updated: 2010-01-18
To make it easier for your users to save files to their special folders locally, you can enable Special
Folder Redirection. is a Microsoft term that refers to Windows folders such as , Special folders Documents
, and the . Computer Desktop
Without Special Folder Redirection enabled, the and icons that appear in a session point Documents Desktop
to the user’s Documents and Desktop folders on the server. Special Folder Redirection actions, such redirects
as opening or saving a file, so that when users save or open files from special folders, they are accessing
the special folder on their local computers. In addition, for the Citrix online plug-in, the Documents folder in the
menu maps to the Documents folder on the client device. Start
To use Special Folder Redirection, users must access the farm with the Citrix online plug-in 11. or later or x
the Web Interface.
Restrictions
Do not enable Special Folders Redirection in situations when a user connects to the same session from
multiple client devices simultaneously. For Special Folder Redirection to work, the user must log off from
the session on the first client device and start a new session on the second client device. If users must
run multiple sessions simultaneously, use roaming profiles or set a home folder for that user in the
in Active Directory. User Properties
Because Special Folder Redirection must interact with the client device, some settings prevent Special
Folder Redirection from working. You cannot have policy settings that prevent users from accessing or saving
to their local hard drives.
Currently, for seamless and published desktops, Special Folder Redirection works only for the Documents
folder. For seamless applications, Special Folder Redirection only works for the Desktop and Documents
folders. Citrix does not recommend using Special Folder Redirection with published Windows Explorer.
Special Folder Redirection requires access to the Documents and Desktop folders on the user’s local
computer. When a user launches an application through the Web Interface and uses to select File Security
in the dialog box in Connection Center, access is denied to the user’s local No Access File Security
workstation drives, including the user’s local Documents and Desktop folders. As a result, some
applications might be unstable when trying to perform read/write operations to the denied folders. To avoid
this, always grant full local access when Special Folder Redirection is enabled.
Caution: Special Folder Redirection does not redirect public folders on Windows Vista and Windows
Server 2008. If users are connecting to servers that are not in their domain, instruct users not to save to
public folders. If users save documents to public folders, they are saving them to a local folder on the
1.
2.
3.
1.
2.
3.
4.
1.
2.
server hosting the published application. In large environments where many servers host the same
application, it could be difficult to determine which server contains the public folder where the user saved
the document.
To enable Special Folder Redirection
Special Folder Redirection support is enabled by default, but you must provide this feature to users through
the Citrix online plug-in and Web Interface. You can either enable Special Folder Redirection for all users
or configure that users must enable the feature themselves in their client settings.
You can allow or prevent specific users from having redirected special folders with the Special
policy setting. folders redirection
Enable the Special Folder Redirection policy setting and apply filters to ensure the setting is applied to
the users you want accessing local special folders.
To prevent local special folders from being redirected, ensure a filter is configured that targets the
users you do not want accessing local special folders.
Decide if you want to let users turn this feature on and off in their sessions.
Instructions for users are provided in their plug-in help.
Ensure you do not have any policy settings enabled that are not supported with Special Folder
Redirection (such as preventing accessing or writing to local hard drives).
If you enable Special Folder Redirection without success, use to determine if any settings conflict Search
with this feature.
Tip: Let your users know that other Special Folders, such as Music or Recent Documents, still point to
the server. If users save documents to these folders, they are saved to the server.
To enable Special Folder Redirection for Web Interface
This procedure requires that you already created a XenApp Web site.
From the Delivery Services Console, select > > Citrix Resources Configuration Tools Web Interface
> . XenApp Web Site Name
From the menu, choose . Action Manage session preferences
In the Managing Session Preferences page, select > . Remote Connection Local Resources
Select the correct options.
To Select the options
Enable Special Folder Redirection by default and let users turn
it off in their session options.
Provide Special Folder Redirection
to all users
Allow users to customize
Special Folder Redirection
Disable Special Folder Redirection by default, but let users turn
it on in their session options
Allow users to customize
Special Folder Redirection
Enable Special Folder Redirection by default and prevent
users from turning it on or off
Provide Special Folder Redirection
to all users
To enable Special Folder Redirection for the Citrix online plug-in
This procedure requires that you already created a XenApp Services site.
From the Delivery Services Console, select > > Citrix Resources Configuration Tools Web Interface
> > . XenApp Services Site Name config.xml
2.
3.
4.
1.
2.
From the menu, choose . Action Change session options
In the Change Session Options page, select > . Remote Connection Local Resources
Select the correct options.
To Select the options
Enable Special Folder Redirection by default and let users turn
it off in their session options.
Provide Special Folder Redirection
to all users
Allow users to customize
Special Folder Redirection
Disable Special Folder Redirection by default, but let users turn
it on in their session options
Allow users to customize
Special Folder Redirection
Enable Special Folder Redirection by default and prevent
users from turning it on or off
Provide Special Folder Redirection
to all users
6.5.1.4. Configuring Audio for User Sessions
Updated: 2010-01-19
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 policy settings you configure for specific connection types
Audio settings the user configures on the user device
For example, you can use audio-related connection policy settings to control bandwidth usage and server
CPU utilization. You can configure a policy setting to enable audio for connections where audio is essential,
and configure another setting to disable audio for connections where it is not essential. Use policy settings
to control the availability of speakers and microphones in sessions.
Important: To use audio in sessions, users must also enable audio on the user device.
When audio is enabled, you can also use policy settings to set compression levels and bandwidth allocation.
6.5.1.4.1. To enable or disable audio for published applications
Updated: 2010-01-19
If you disable audio for a published application, audio is not available within the application under any
condition. If you enable audio for an application, you can use policy settings and filters to further define
under what conditions audio is available within the application.
In the Delivery Services Console, select the published application for which you want to enable or
disable audio, and select . Action > Application properties
In the dialog box, click . Select or clear the Application Properties Advanced > Client options
check box. Enable legacy audio
6.5.1.4.2. To configure bandwidth limits for audio
Updated: 2010-01-25
Use policy settings to configure the amount of bandwidth you want to allocate to audio transfers between
servers and client devices. For example, you might want to create separate policy settings for groups of dial-
up users and for those who connect over a LAN, accommodating the different amounts of bandwidth each
group will have available.
1.
1.
In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such
as servers or users.
Configure the following Citrix User policy settings:
. Specify the bandwidth available for audio in kilobits Audio redirection bandwidth limit
per second.
. Limit the bandwidth available for audio to Audio redirection bandwidth limit percent
a percentage of the overall bandwidth available. If you configure this setting, you must enable the
setting. Overall session bandwidth limit
6.5.1.4.3. To configure audio compression and output quality
Updated: 2010-01-25
Use Citrix policy settings to configure the compression levels to apply to sound files. Generally, higher
sound quality requires more bandwidth and higher server CPU utilization. You can use sound compression
to balance sound quality and overall session performance.
Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. Over dial-up connections, where bandwidth typically is limited, users likely care more about download speed than sound quality. For such users, create a policy for dial-up connections that applies high compression levels to sound and another for LAN connections that applies lower compression levels.
In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such
as servers or users.
Configure the Citrix User policy setting with one of the following options: Audio quality
Low - for low-speed connections. This causes any sounds sent to the client device to
be compressed to a maximum of 16Kbps. This compression results in a significant decrease in
the quality of the sound. The CPU requirements and benefits of this setting are similar to those
of the Medium setting; however, the lower data rate allows reasonable performance for a
low-bandwidth connection.
. This is recommended for most LAN-based connections. Medium - optimized for speech
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.
. This is recommended for connections where bandwidth is High - high definition audio
plentiful and sound quality is important. This setting allows client devices to play a sound file at
its native data rate. Sounds at the highest quality level require about 1.3Mbps of bandwidth to
play clearly. Transmitting this amount of data can increase bandwidth requirements, and result
in increased CPU utilization and network congestion.
6.5.1.4.4. To enable support for microphones and speakers
Updated: 2010-01-25
For users to use speaker and microphones in sessions, both audio input (for microphones) and output
(for speakers) must be enabled. Audio input and output are controlled by two policy settings; you must
configure both to ensure that audio input and output are enabled.
Note: Microphone input is supported on the Citrix online plug-in for Windows, Windows CE, and Linux.
This allows you to implement separate connection policies; for example, for users of mobile devices and for
users who connect over a LAN. For the mobile user group, you may want to enable audio input but disable
audio output. This lets mobile users record notes from the field, but prevents the server from sending audio to the mobile devices, ensuring better session performance. Enabling audio input and output also enables support for digital dictation.
On the client device, users control audio input and output in a single step—by selecting an audio quality
level from the > dialog box. Options Session Options
By default, when you configure these settings, audio input is enabled on client devices. Web Interface users
can override the policy and disable their microphones by selecting in the dialog box, No Audio Security
which they access from the Citrix Connection Center.
In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such
1.
2.
1.
2.
3.
4.
as servers or users.
To enable audio input for sessions, configure the Citrix User policy setting. Client microphone redirection
To enable audio output for sessions, configure the Citrix User policy setting. Client audio redirection
6.5.1.4.5. To use and set sound quality for digital dictation devices
Updated: 2010-01-19
If you have enabled microphone and speaker support, XenApp requires no additional configuration to allow
users to record audio using a standard microphone. However, to allow users to use digital dictation devices
such as Philips SpeechMike devices and dictation software such as WinScribe Internet Author and Internet
Typist, you must install and configure the associated software and set session sound quality to
accommodate them.
To enable Phillips SpeechMike devices, go to the Philips web site for information and software downloads.
Note: The Citrix plug-ins for Linux and Windows CE do not support Philips SpeechMike products.
To make Philips SpeechMike devices or similar products available in user sessions, install the device
drivers associated with the products on the XenApp server and on client devices. To make dictation software
such as WinScribe Internet Author and Internet Typist available, install this software on the XenApp server.
After installation, you might be required to enable the controls for the dictation device within the
dictation software. Refer to the product documentation for instructions.
Set sound quality to at least medium quality. To enable the use of Philips SpeechMagic Speech Recognition
server with WinScribe software, set sound quality to high to enable accurate speech-to-text translation.
From Citrix Web Interface Management, select the XenApp Services site you want to configure.
In the Action pane, select . Session Options
Select . Color and Sound
In the Sound area, select one of:
Medium - optimized for speech
High - high definition audio
6.5.1.5. Ensuring Session Continuity for Mobile Workers
Updated: 2010-01-19
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 online plug-in, you can configure—
and allow users to configure—these 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 online plug-in.
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 hospital’s 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 the Web
Interface documentation.
6.5.1.6. 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
6.5.1.6.1. Configuring Session Reliability
Updated: 2010-01-29
Session Reliability keeps sessions active and on the user’s 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 user’s 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 the Citrix online plug-in cannot override the server setting.
Note: You can use Session Reliability with Secure Sockets Layer (SSL).
By default, Session Reliability is enabled through policy settings. You can customize the policy settings for
this feature as appropriate. You can edit the port on which XenApp listens for session reliability traffic and edit
the amount of time Session Reliability keeps an interrupted session connected.
The Citrix Computer policy setting allows or prevents session reliability. Session reliability connections
The setting has a default of 180 seconds, or three minutes. Though you can Session reliability timeout
extend the amount of time Session Reliability keeps a session open, this feature is designed to be convenient
to the user and it does not, therefore, prompt the user for reauthentication. If you extend the amount of time
a session is kept open indiscriminately, chances increase that a user may get distracted and walk away from
the client device, potentially leaving the session accessible to unauthorized users.
Incoming session reliability connections use port 2598, unless you change the port number with the
Citrix Computer policy setting. Session reliability port number
If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, use
the Auto Client Reconnect feature. You can configure the Citrix Computer policy Auto client
setting to prompt users to reauthenticate when reconnecting to interrupted sessions. reconnect authentication
If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence.
Session Reliability closes, or disconnects, the user session after the amount of time you specify in the
Citrix Computer policy setting. After that, the Auto Client Reconnect policy Session reliability timeout
settings take effect, attempting to reconnect the user to the disconnected session.
6.5.1.6.2. Configuring Automatic Client Reconnection
Updated: 2010-01-25
The Auto Client Reconnect feature allows Citrix plug-ins 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.
Configure Auto Client Reconnect with the following Citrix Computer policy settings:
Auto client reconnect. Enables or disables automatic reconnection by the same client after a
connection has been interrupted.
Auto client reconnect authentication. Enables or disables the requirement for user authentication
upon automatic reconnection
Auto client reconnect logging. Enables or disables logging of reconnection events in the event
log. Logging is disabled by default. When enabled, the server's System log captures information
about successful and failed automatic reconnection events. Each server stores information
about reconnection events in its own System log; the server farm does not provide a combined log
of reconnection events for all servers.
Auto Client Reconnect incorporates an authentication mechanism based on encrypted user credentials. When
a user initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory, and
creates and sends a cookie containing the encryption key to the plug-in. The plug-in submits the key to the
server for reconnection. The server decrypts the credentials and submits them to Windows logon
for authentication. When cookies expire, users must reauthenticate to reconnect to sessions.
Cookies are not used if you enable the setting. Instead, Auto client reconnection authentication
XenApp 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.
Disable Auto Client Reconnect on the Citrix plug-in for Windows by using the icaclient.adm file. For
more information about plug-in configuration, see the online plug-in documentation.
Settings for connections also affect Auto Client Reconnect.
Configuring Connections for Automatic Client Reconnection
By default, Auto Client Reconnect is enabled through policy settings on the farm level. User reauthentication
is not required. However, if a server’s ICA TCP connection is configured to reset sessions with a
1.
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 refers to a XenApp’s virtual port (rather than an actual ICA TCP connection
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 plug-in.
The connection can be configured to , or log off, sessions with broken or timed out connections. When reset
a session is reset, attempting to reconnect initiates a new session; rather than restoring a user to the same
place in the application in use, the application is restarted.
If XenApp is configured to reset sessions, Auto Client Reconnect creates a new session. This process
requires users to enter their credentials to log on to the server.
Automatic reconnection can fail if the plug-in submits incorrect authentication information, which might
occur during an attack or the server determines that too much time has elapsed since it detected the
broken connection.
6.5.1.6.3. Configuring ICA Keep-Alive
Updated: 2010-06-07
Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled,
if XenApp detects no activity (for example, no clock change, no mouse movement, no screen updates),
this feature prevents Remote Desktop Services from disconnecting that session. XenApp sends keep-alive
packets every few seconds to detect if the session is active. If the session is no longer active, XenApp marks
the session as disconnected.
However, the ICA Keep-Alive feature does not work if you are using Session Reliability. Session Reliability has
its own mechanisms to handle this issue. Only configure ICA Keep-Alive for connections that do not use
Session Reliability.
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 ICA Keep-Alive values on
XenApp servers. Doing so allows ICA sessions to be changed from active to disconnected as intended.
ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy.
Configure the following Citrix Computer policy settings:
. Specifies the interval (1-3600 seconds) used to send ICA keep- ICA keep alive timeout
alive messages. Do not configure this option if you want your network monitoring software to
close inactive connections in environments where broken connections are so infrequent that
allowing users to reconnect to sessions is not a concern.
The 60 second default interval causes ICA Keep-Alive packets to be sent to client devices every
60 seconds. If a client device does not respond in 60 seconds, the status of the ICA
sessions changes to disconnected.
. Sends or prevents sending ICA keep-alive messages periodically. ICA keep alives
6.5.2. Managing and Monitoring XenApp Sessions
Updated: 2010-03-09
You can interact directly with sessions by resetting, disconnecting or logging off sessions, or sending messages
to users. You can monitor sessions through console displays or directly through shadowing.
Disconnecting and Resetting Sessions
A disconnected session is still active and its applications continue to run, but the client device is no
longer communicating with the server. A user can reconnect to a disconnected session from a different
client device without loss of data. For example, you might disconnect users’ sessions if they experience
problems on their client device and do not want to lose data from their applications.
1.
2.
3.
4.
1.
2.
3.
4.
1.
2.
3.
4.
1.
2.
3.
4.
When you disconnect a session, you close the connection between the client device and the server. However,
this does not log off the user, and programs that were running in the session are still running on the
server. (Some applications that rely on virtual channels, such as media players, may behave differently.
For example, if you disconnect from a session running Media Player while playing audio, the audio stops
playing because the audio virtual channel is no longer available.) When a session is disconnected, session
state displays indicate . If the client user then connects to the server (by selecting a Disconnected
published application or custom connection to the server), the disconnected session is reconnected.
You can log off users from their sessions. You can also reset a user’s client session or a disconnected session.
You can also connect to a user’s 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 support the same video resolution as the disconnected session.
Resetting a session terminates all processes that are running in that session. You can reset a session to
remove remaining processes in the case of a session error; however, resetting a session can cause applications
to close without saving data.
When you reset a disconnected session, session state displays indicate . When you refresh the Down
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 indicate in session state displays. If Listening
you reset a listener session, the server resets all sessions that use the protocol associated with the listener.
For example, if you reset the ICA listener session, you reset the ICA sessions of all users connected to the server.
To use session controls
From the Delivery Services Console:
To reset a session:
Caution: Resetting effectively deletes the session and results in loss of data for the user. Only reset
a session when it malfunctions or is not responding.
Select the server to which the user is connected.
In the results pane, click the tab. Sessions
Select the session you want to reset. (You can select one or more sessions.)
In the Actions pane, select . Reset
To disconnect a session:
Select the server to which the user is connected.
In the results pane, click the tab. Sessions
Select the session you want to reset. (You can select one or more sessions.)
In the Actions pane, select . Disconnect
To logoff from a session:
Caution: Ending user sessions using Logoff can result in loss of data if users do not close
their applications first. Before initiating the logoff, send a message to warn users to exit all applications.
Select the server to which the user is connected.
In the results pane, click the tab. Sessions
Select the session you want to log off. (You can select one or more sessions.)
In the Actions pane, select . Confirm the logoff when prompted. Log off
To terminate processes in a user session:
Caution: Terminating a process may abruptly end a critical process and leave the server in an
unusable state.
Select the server to which the user is connected.
In the results pane, click the tab and select the session for which you want to terminate Users
a process.
In the lower portion of the results pane, click the tab and select the process you want Processes
to terminate.
In the Actions pane, select . Terminate
1.
2.
3.
4.
1.
2.
3.
To send a message to one or more users from the Delivery Services Console
Sending a message that appears in user sessions can be helpful in situations such as broadcasting
information about new applications and upgrades, requesting a shadowing session, or warning of a logoff
or system shutdown.
From the Delivery Services Console, select the server to which the users are connected. To send
a message to all user sessions in the farm, select a farm node instead of a server.
In the results pane, click the tab and select one or more sessions. Users
In the Actions pane, select . The dialog box appears. Send Message Send Message
Edit the title of the message, if required, and enter the message text.
6.5.2.1. Monitoring Session Information
Updated: 2010-01-19
From the Delivery Services Console, select the server on which you want to monitor sessions.
In the results pane, click the tab. The display lists all sessions running on the server. Sessions
By default, the upper portion of the results pane includes the following information for all sessions (click
to specify which columns to display and the display order): Choose columns
Field Description
User Name of the user account that initiated the session. For anonymous connections,
the user name is a string beginning with "Anon" followed by a session number.
Session ID Unique number that begins with 0 for the first connection to the console.
Listener sessions are numbered from 65,537 and numbered backward sequentially.
Application Name of the published application running in the session.
Type Session type: ICA or RDP
State Active, Listen, Idle, Disconnected, or Down.
Client Name Name of the client device that is running the session.
Logon Time When the user logged on.
Idle Time How long the session has been idle.
Server Server on which the application is running.
Select a session. Depending on the session you select:
Tasks become available in the Actions pane; these can include , , , and Reset Log off Disconnect
. Send Message
The lower portion of the results pane displays tabs containing additional information: , Information
, , , and . Client Cache Session Information Client Modules Processes
6.5.2.2. Viewing User Sessions
Updated: 2010-06-07
You can view another user’s session on another device by using . When shadowing, you can shadowing
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 user’s 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 user’s 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
Delivery Services Console or the Shadow Taskbar.
You enable shadowing on a server when you configure XenApp and select the default option, which
allows shadowing on all connections on the server. If you do not leave the shadowing option enabled
1.
2.
1.
2.
1.
2.
during configuration, you must reinstall XenApp to get shadowing functionality.
By default, the user is notified of the pending shadowing and asked to allow or deny shadowing.
Important: Your client device and shadowing ICA session must support the video resolution of the user’s
ICA session (the shadowed session). If not, the operation fails. You cannot shadow a system console
from another session.
For shadowing options by connection type, such as keyboard, mouse, and user notification options, use
the Remote Desktop Server Configuration tool.
6.5.2.2.1. Viewing User Sessions with the Shadow Taskbar
Updated: 2010-01-19
Use the Shadow Taskbar to shadow multiple ICA sessions from a single location, including the server console.
Use the button to start shadowing one or more users. The Shadow Taskbar uses the client to launch Shadow
an ICA session to monitor a user. A separate ICA session is started for each shadowed user.
You must enter your user name and password to start an ICA session on the server running the Shadow Taskbar.
Note the following:
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
From the menu, choose > > > Start All Programs Citrix Administration Tools Shadow Taskbar
To configure shadowing options, right-click an empty area of the Shadow Taskbar or press SHIFT +
F10. To switch to a shadow session, click its button in the Shadow Taskbar.
To close the Shadow Taskbar, right-click an empty area of the Shadow Taskbar and select . Exit
To select users and initiate shadowing
On the Shadow Taskbar, click the button. The dialog box appears. Shadow Shadow Session
The list shows user sessions that can be selected for shadowing in the Available Users
current domain. User sessions are organized by servers, published applications, and users. You
can shadow only client user sessions. .
The list shows user sessions selected for shadowing and existing Shadowed Users
shadow sessions; it also displays the user name of currently shadowed users next to the
shadow icon.
In the list, select one or more users to shadow and click . Available Users Add The selected users move
to the list. Shadowing is initiated for all users in the list when Shadowed Users Shadowed Users
you click . OK
To end a shadowing session
On the Shadow Taskbar, click the button. The dialog box appears. Shadow Shadow Session
In the Shadowed Users list, select the users to stop shadowing and click . Remove
2.
1.
2.
3.
1.
2.
3.
Tip: You can end a shadow session by right-clicking the session’s task button on the Shadow
Taskbar and clicking . You can end all shadow sessions by right-clicking the Stop Shadow
Shadow Taskbar and clicking . Stop All Shadowed Sessions
6.5.2.2.2. Enabling Logging for Shadowing
Updated: 2010-01-25
After configuring XenApp, you can enable shadow logging and configure shadow logging output to one of
two locations on the server:
In a central file. Configuring this option records a limited number of logging events, such as when
and who started a shadowing session and who is being shadowed. When you configure shadow
logging through the Shadow Taskbar, the logged events are not recorded in the Windows Event
log. Instead, they go to a file that you specify.
In the Windows Event log. Configuring this option logs several different event types in the
Application log of the Windows Event log. These include user shadowing requests, such as when users
stop shadowing, failure to launch shadowing, and access to shadowing denied. However, these events
are logged as they occur and it can be cumbersome to see a shadowing history because the events
are strewn throughout the Event log.
For ease of management, consider logging events in a central file. Only shadowing events go in to this file,
so they are more centralized and easier to review.
To configure shadow logging to log in a central file
Click on an empty area of the Shadow Taskbar and press SHIFT + F10.
Click . Logging Options
Select the check box and specify a log file path. Enable Logging
Click to empty the current log file. Clear Log
To enable shadow logging in the Windows Event log
Configure the Citrix User policy setting. Log shadow attempts
6.5.2.2.3. Enabling User-to-User Shadowing with Policies
Updated: 2010-02-22
You can create a user policy to enable user-to-user shadowing, which allows users to shadow other users
without requiring them to be members of the Citrix administrator group. With user-to-user shadowing,
multiple users from different locations can view presentations and training sessions, allowing one-to-many,
many-to-one, and many-to-many online collaboration. Also, you can enable Help Desk personnel to shadow
users’ sessions or allow your Sales Department to hold an online meeting to review sales leads.
Important: You configure shadowing settings during XenApp configuration. If you choose to
prohibit shadowing during configuration, you cannot enable shadowing with user policies.
You enable user-to-user shadowing by creating policies that define users who can and cannot shadow. You
then assign the policies to the users to be shadowed.
The list of users permitted to shadow is exclusive for each user for whom a policy is assigned. For example, if
you create a policy that permits User A to shadow User B, this policy allows only User A to shadow User B,
unless you add more users to the list of users who can shadow in the same policy’s Property sheet.
To create a policy to define users who can shadow
Create a user policy that identifies the users who can shadow other users’ sessions.
Assign the policy to the users to be shadowed.
3.
1.
2.
3.
4.
5.
6.
Publish the Citrix Shadow Taskbar and assign it to the users who will shadow. Be sure to instruct
these users how to initiate shadowing from their client devices.
Note: Instruct users not to launch the Shadow taskbar in seamless mode. The Shadow taskbar cannot
function in seamless mode.
Example: To create a user policy for user-to-user shadowing and assign it to users
This example demonstrates how to enable user-to-user shadowing by creating a policy for your “Sales”
user group that allows them to shadow the department manager for online collaboration on sales leads.
This procedure shows the creation of a shadowing policy.
Create a new policy named “Sales Group Shadowing.”
Add the Citrix Computer policy setting and set it to . Shadowing Allowed
Because the Sales Manager may work with sensitive data, add the Notify user of pending
Citrix User policy setting and set it to . If the Sales Manager does not shadow connections Enabled
want other users to be able to take control of his mouse and keyboard, add the Input from
Citrix User policy setting and set it to . shadow connections Prohibited
Add the Citrix User policy setting, and select the users who Users who can shadow other users
can shadow the Sales Manager.
To specify users who cannot shadow the Sales Manager, add the Users who cannot shadow other users
Citrix User policy setting, and select users.
Add the User filter and select the users who can receive shadowing requests.
6.5.3. Controlling Client Connections in XenApp
Updated: 2010-02-10
You can control XenApp client connections in different places:
XenApp policies
Application Publishing
Active Directory
XenApp policies
Policies let you define how you want clients to connect, including SSL or encryption requirements, and
the properties for the user’s environments after the connection is established.
Citrix recommends using XenApp policies whenever possible to control connections. Connection settings
defined through XenApp policies also supersede all other connection settings in your environment, including
those specified at the operating system level and when you publish an application
Application Publishing
You can define connection settings on a per-application basis when you are publishing a resource. Settings
you can define include the maximum number of connections to an application, importance level of the
application, maximum number of instances an application can run in the farm, types of connections that
can access an application, audio properties, and encryption requirements.
Active Directory
Citrix provides a Group Policy Object (GPO) template, 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. For more
information, see the Citrix online plug-in documentation.
6.5.3.1. Preventing Specific Client Connection Types
Updated: 2010-01-25
1.
You can specify the types of client connections from which users can start sessions. For example, to
increase security, you can specify that users must connect through Access Gateway Advanced Edition
(Version 4.0 or later). This allows you to benefit from filters created in Access Gateway.
To configure connection access control
Configure the Computer policy setting with one of the following options: Connection access control
Any connections allows access to published applications through any connection.
Citrix Access Gateway, Citrix online plug-in, 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).
6.5.3.2. Specifying Connection Limits
Updated: 2010-01-21
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
Computer policy settings. (You cannot configure connection limits in the plug-ins.)
There are two types of connection limits:
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.
6.5.3.2.1. Limiting Connections to a Server Farm
Updated: 2010-02-01
To conserve resources, you can limit the number of concurrent connections that users are permitted to
establish. Limiting connections can help prevent over-consumption of server resources by a few users.
Active sessions and disconnected sessions are counted for the total number of concurrent connections.
For example, you can set a limit of three concurrent connections for users. If a user has three
concurrent connections and tries to establish a fourth, the limit you set prevents the additional connection.
A message tells the user that a new connection is not allowed.
Connection control affects users only if a connection attempt is prevented. If a user’s number of
connections exceeds a connection limit, the plug-in displays a message that describes why the connection is
not available.
You can also limit the number of connections on a farm by ensuring that session sharing is enabled.
To specify the total number of sessions that can logon to a server
When this setting is used, users can still launch additional sessions, as long as the limit has not been reached.
1.
1.
Configure the following Citrix Computer policy settings:
. The maximum number of concurrent connections a user can establish, in Limit user sessions
the range 0-8192. A value of 0 indicates no connections.
. Enables or disables connection limit enforcement for Limits on administrator sessions
Citrix administrators. Limiting connections for Citrix administrators can adversely affect their
ability to shadow other users.
Local administrators are exempt from the limit so they can establish as many connections as necessary.
To specify the maximum number of connections a user can make to the server farm at a given time
When this setting is used and the specified number is reached, the user cannot launch additional sessions, even
if the server has availability.
Configure the Citrix User Policy setting. Concurrent logon limit
6.5.3.2.2. Sharing Sessions and Connections
Updated: 2010-01-21
Depending on the plug-in, when a user opens an application, it can either appear in a or seamless non-seamless
window. These window modes are available for most plug-ins, including the Web Interface and Citrix online
plug-in.
In seamless window mode, published applications and desktops are not contained within an ICA
session window. Each published application and desktop appears in its own resizable window, as if it
is physically installed on the client device. Users can switch between published applications and the
local desktop.
In non-seamless window mode, published applications and desktops are contained within an ICA
session window. This creates the effect of the application appearing in two windows.
The mode that you choose typically depends on the type of client device that your users will be using and
whether you are publishing a desktop or individual applications. Desktops are typically published in non-
seamless window mode. This table provides examples of when you might want to publish desktops
and applications.
If your users will be using... 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 plug-in establishes a connection to a XenApp server
and initiates a session. If session sharing is not configured, a new session is opened on the server each time
a user opens an application. Likewise, every time a user opens a new application, a new client connection
is created between the client device and the server.
Session sharing is a mode in which more than one published application runs on a single connection.
Session sharing occurs when a user has an open session and launches another application that is published on
the same server; the result is that the two applications run in the same session. For session sharing to
occur, both applications must be hosted on the same server. Session sharing is configured by default when
you specify that applications appear in seamless window mode. If a user runs multiple applications with
session sharing, the session counts as one connection.
If you want to share sessions, ensure all applications are published with the same settings. Inconsistent
results may occur when applications are configured for different requirements, such as encryption.
1.
2.
3.
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 management does not transfer the user’s request
to another server where the second application is published.
6.5.3.2.3. Limiting Application Instances
Updated: 2010-01-21
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
From the Delivery Services Console, select the farm, then select . Applications
Select the application or desktop you want to modify. In the Action menu, select . Application properties
In the Properties tree, select . Select one or both of the following options: Limits
Limit instances allowed to run in server farm. Enter the maximum number of instances that
can run at one time in the server farm without regard to who launches the application.
For example, if you enter 10 and a user tries to launch the application when 10 instances
are running, the server denies the connection request and records the time and the name of
the published application in the System log.
Allow only one instance of application for each user. Prevents any user from running
more than one instance of this application at the same time.
6.5.3.2.4. Logging Connection Denial Events
Updated: 2010-01-25
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
Application instance limits
Application instances per user
To enable or disable logging of connection denial events, configure the Logging of logon limit events
1.
2.
Citrix Computer policy setting.
6.5.3.3. Configuring the ICA Listener
Updated: 2010-09-24
To configure the ICA listener, use the Citrix ICA Client Configuration Tool (CtxICACfg.exe). For more
information, see . CTX125139
Important: Do not use Microsoft Remote Desktop Services tools to configure the ICA listener.
6.5.3.4. Preventing User Connections During Farm Maintenance
Updated: 2010-01-21
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
From the Delivery Services Console, select the server.
In the Actions pane, select . Other Tasks > Disable logon
Note: To reenable disabled logons, select . Other Tasks > Enable logon
6.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:
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.
. Allows you to improve interactivity when displaying high-detail images HDX 3D Progressive Display
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.
. Helps reduce a user’s perception of latency when typing and SpeedScreen Latency Reduction
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.
6.5.4.1. Optimizing Audio and Video Playback
Updated: 2010-03-10
HDX MediaStream Multimedia Acceleration improves the user’s experience of accessing published audio-
visual applications and content. Enabling this feature increases the quality of audio and video rendered from
the server to a level that compares with audio and video played locally on a client device. In addition, it
reduces use of network bandwidth and server processing and memory because compressed multimedia files
are intercepted and forwarded to the client to be uncompressed. This feature optimizes multimedia
playback through published instances of Internet Explorer, Windows Media Player, and RealOne Player. It
offers significant performance gains in these areas:
User Experience. Multimedia playback in sessions is much smoother.
Server CPU Utilization. The client device decompresses and renders multimedia content, freeing
server CPU utilization.
Multimedia content is passed over the network in compressed form, Network Bandwidth.
reducing bandwidth consumption.
Note: With HDX MediaStream Multimedia Acceleration enabled, RealOne Player’s built-in volume and
balance controls do not work within client sessions. Instead, users can adjust volume and balance from
the volume controls available from the device notification area.
Without HDX MediaStream Multimedia Acceleration, the cumulative cost of several users playing
multimedia content in sessions simultaneously is high, both in terms of server CPU utilization and
network bandwidth consumption. When you play multimedia content in a session, the server decompresses
and renders the multimedia file, which increases the server’s CPU utilization. The server sends the file over
the network in uncompressed form, which consumes more bandwidth than the same file requires in
compressed form.
With HDX MediaStream Multimedia Acceleration, the server streams multimedia to the client in the
original, compressed form. This reduces bandwidth consumption and leaves the media for the client device
to decompress and render, thereby reducing server CPU utilization.
HDX MediaStream Multimedia Acceleration optimizes multimedia files that are encoded with codecs
(compression algorithms) that adhere to Microsoft’s DirectShow, DirectX Media Objects (DMO), and
Media Foundation standards. DirectShow and Media Foundation are application programming interfaces
(APIs) that allow, among other things, multimedia playback. To play back a given multimedia file, a
codec compatible with the encoding format of the multimedia file must be present on the client device.
Generally, if you can play back a given multimedia file locally on a given client device, you can play back
the same file on the same client device within a session. Users can download a wide range of codecs, such
as those supported by Windows Media Player or RealOne Player, from vendor Web sites.
Users accessing audio-visual applications on servers on which HDX MediaStream Multimedia Acceleration
is enabled use a little more memory but far less bandwidth than when this feature is disabled. Users use only
a little more memory or bandwidth when accessing audio-visual applications compared to regular
enterprise applications.
To allow users to run multimedia applications in ICA sessions, turn on audio or give the users permission to
turn on audio themselves in Citrix online plug-in. By default, all other plug-ins and methods are configured
with audio enabled and optimized for speech sound quality.
Other requirements for using HDX MediaStream Multimedia Acceleration are:
Users must be running a Citrix online plug-in.
The user device must have the same memory and processing speed as is needed for playing
multimedia locally.
The correct codec to decompress the media file type used (MPEG for example) must reside on the
user device. Windows devices have the most common codecs already installed. If you need
additional codecs, you can download them from the Web sites of the manufacturers of media players.
1.
Note: To make Windows Media Player 11 and Media Foundation components available on your XenApp
server, install and configure the Microsoft Windows Server 2008 Desktop Experience in the Server Manager.
Applications and media formats supported by HDX MediaStream Multimedia Acceleration are:
Applications based on Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation
filter technologies such as Windows Media Player, RealPlayer.
Applications like Internet Explorer and Microsoft Encarta are also supported, as they leverage
Windows Media Player.
Both file-based and streaming (URL-based) media formats: WAV, all variations of MPEG,
unprotected Windows Media Video (WMV), and Windows Media Audio (WMA).
Note: HDX MediaStream Multimedia Acceleration does not support media files protected with Digital
Rights Management (DRM).
When the quality of media playing on a user device deteriorates, possible solutions are:
If video appears in slowly changing slides while audio is intact or audio becomes choppy, this is caused
by low bandwidth. Arrange for users to play media on the network where more bandwidth is available.
If audio and video are not synchronized, generally only the video or audio is played using
HDX MediaStream Multimedia Acceleration. This can happen if a client device lacks a codec for either
video or audio. Install the needed codec on the client or use media content on the server for which
clients have both codecs.
By default, HDX MediaStream Multimedia Acceleration is enabled at the server farm level.
6.5.4.1.1. Configuring HDX MediaStream Multimedia Acceleration
Updated: 2010-01-25
Configure HDX MediaStream Multimedia Acceleration in a Citrix policy.
Note: By default, audio is disabled on the client. To allow users to run multimedia applications in sessions,
turn on audio or give the users permission to turn on audio themselves on their user devices.
Configure the following Citrix Computer policy setting:
. Enables or disables the feature. HDX MediaStream Multimedia Acceleration
. Specifies the buffer size HDX MediaStream Multimedia Acceleration default buffer size
in seconds, in the range 1-10; requires enabling the HDX MediaStream Multimedia
Acceleration default buffer size use option. You can see how much server memory the
selected buffer can use by changing the buffer time.
. Enables or disables use HDX MediaStream Multimedia Acceleration default buffer size use
of a buffer. When this option is enabled, specify the buffer size with the HDX
MediaStream Multimedia Acceleration default buffer size option
6.5.4.2. Optimizing Flash Content
Updated: 2010-01-25
HDX MediaStream server-side Flash functionality allows you to optimize the way XenApp renders and
delivers Adobe Flash content to users. To display Flash content in sessions, you must have the Flash plug-in
and the corresponding ActiveX control installed in the Web browser before you publish it.
Users playing Flash content in published applications might observe poor rendering quality of the animation,
slow session responsiveness, or a combination of both. This occurs when Adobe Flash Player, which renders
the content on the server, starts in high-quality mode by default. While this guarantees the highest
possible rendering mode for each frame, it also means that each frame consumes considerable bandwidth on
its way to the user.
HDX MediaStream server-side Flash functionality improves the user’s session responsiveness by forcing the
1.
2.
1.
Flash Player to use simpler graphics (for example, no smoothing or anti-aliasing). This feature also reduces
the amount of processing power that is required to render Flash content.
By default, HDX MediaStream server-side Flash functionality is enabled at the server farm level. However, if
HDX MediaStream client-side Flash functionality is enabled, server-side rendering is overridden.
Configure the Citrix User policy setting with one of the following options: Flash quality adjustment
. Select this option to Optimize Adobe Flash animation options for all connections
always reduce the amount of Flash data sent to users. The result is minimized CPU usage on
the servers on which users are using Flash within Internet Explorer.
. Select Optimize Adobe Flash animation options for low bandwidth connections only
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.
. Select this option if bandwidth is not limited. Do not optimize Adobe Flash animation options
To reduce bandwidth consumption and improve video playback and server scalability, configure the
Citrix Computer policy setting for . Configuring this setting can cause animations Queueing and tossing
to become choppy due to dropped frames.
6.5.4.3. Optimizing Throughput of Image Files
Updated: 2010-01-25
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 user’s
session while downloading and rendering. Using lossy image compression, SpeedScreen Image Acceleration
lets you find a balance between the quality of photographic image files as they appear on client devices and
the amount of bandwidth the files consume on their way from server to client.
SpeedScreen Image Acceleration applies a lossy compression scheme to reduce the size of image files that
the server sends to the client for faster throughput. The compression scheme removes redundant or
extraneous data from the files while attempting to minimize the loss of information. Under most
circumstances, the data loss is minimal and its effect nominal. However, Citrix recommends that you
use discretion in applying this feature where preservation of image data may be vital, as in the case, for
example, of X-ray images.
This feature is enabled by default. Use policy settings to override the default settings and accommodate
different user needs by applying different levels of image compression to different connections.
Configure the Citrix User policy setting with one of the following options: Lossy compression level
Level Image quality Bandwidth requirements
High Low Lowest
Medium (default) Good Lower
Low High Higher
None Same as original Highest
Choose none or low compression for users who need to view images at original or near original quality levels.
If this policy setting is not configured, medium compression is used for all connections, which amounts to
slightly better performance due to slightly lower image quality.
To configure Image Acceleration without enabling Progressive Display, after configuring the policy setting for
the lossy compression level, configure the Citrix User policy setting with the Progressive compression level
option. None
6.5.4.4. Optimizing Display of Image Files
Updated: 2010-01-25
You can enable Progressive Display to increase the performance of displaying images or parts of images that
are changing.
Progressive Display speeds the initial display of an image file by choosing an increased compression level while
an image is dynamic. This initial display is then sharpened up to normal quality in the background if the image
is not immediately changed or overwritten in the application. The quality of the final image is controlled by
Image Acceleration.
Progressive Display can improve the performance not only of applications that render and display images,
but also those parts of an image that are dynamic, such as when scrolling through a PDF or similar document.
Configure the Citrix User policy setting with the desired level (Low, Progressive compression level
Medium, High, Very high, or Ultra high), and configure the Citrix User policy setting to Lossy compression level
. None
6.5.4.5. Optimizing Keyboard and Mouse Responsiveness
Updated: 2010-02-08
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 user’s request. When the user clicks the mouse, the ICA software immediately changes
the mouse pointer to an hourglass to show that the user’s 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.
6.5.4.5.1. Configuring SpeedScreen Latency Reduction
Updated: 2010-02-10
SpeedScreen Latency Reduction Manager, a tool provided with XenApp, allows you to configure
SpeedScreen Latency Reduction settings for a XenApp server, for single or multiple instances of an application,
as well as for individual input fields within an application. You can also use it as a troubleshooting tool to fine-
tune SpeedScreen Latency Reduction behavior for applications, or input fields within an application, that
exhibit incompatibility with this SpeedScreen feature.
SpeedScreen Latency Reduction Manager must be installed on a XenApp server, and can be used to
customize SpeedScreen Latency Reduction settings only on that server.
To launch SpeedScreen Latency Reduction Manager, select SpeedScreen Latency Reduction Manager from the
program group in the Start menu. Citrix > Administration Tools
Note: To run the Speedscreen Latency Reduction Manager with the User Account Control (UAC) enabled,
you must be a domain administrator, delegated administrator, or part of the Administrators group on the
local computer, or you will be prompted for administrator credentials.
1.
2.
3.
4.
5.
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.
6.5.4.5.2. Adjusting SpeedScreen Latency Reduction for an Application
Updated: 2010-02-08
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.
From the menu, select > > > Start All Programs Citrix Administration Tools SpeedScreen
. Latency Reduction Manager
From the menu of SpeedScreen Latency Reduction Manager, select to start the Applications New
wizard and follow the prompts.
Use the screen to select an application instance on the server. To specify Define the Application
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 button and navigate to the application. Browse
Specify whether Local Text Echo is enabled or disabled on the application by selecting or clearing the
check box. Enable local text echo for this application For a definition of Local Text Echo, see
Optimizing Keyboard and Mouse Responsiveness
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
when configuring Local Text Echo Apply settings to all installations of the selected application
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.
1.
2.
3.
1.
2.
3.
4.
1.
To configure latency reduction settings for all applications on a server
From the menu, select > > > Start All Programs Citrix Administration Tools SpeedScreen
. Latency Reduction Manager
From the menu, select Application Server Properties. The dialog box Server Properties
containing existing settings for the selected server appears.
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
From the menu, select > > > Start All Programs Citrix Administration Tools SpeedScreen
. Latency Reduction Manager
In the SpeedScreen Latency Reduction Manager, select the application.
From the menu, select Application Properties. The tab containing Application Properties
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.
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.
6.5.4.5.3. To configure latency reduction settings for input fields in an application
Updated: 2010-02-08
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.
From the menu, select > > > Start All Programs Citrix Administration Tools SpeedScreen
1.
2.
3.
4.
1.
2.
. Latency Reduction Manager
Select an application.
From the menu, select . The window appears. Applications Properties Application Settings
Select the tab, then configure these settings as needed. Input Field Configuration
The displays the list of configured input fields. SpeedScreen Configured Input Field List
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 to run the Advanced Input Field Compatibility wizard to add a new input field. New
This wizard guides you through the process of configuring SpeedScreen Latency
Reduction settings for an input field.
Click to delete the selected input field from the Configured Input Field List. Delete
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%.
forces non-standard input fields to use system default Use system default colors
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 to apply system default colors to both text Both the text and background
and background.
Choose to apply system default colors only to the background. The background only
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 if you want Local Text Echo for such input Hidden characters denoted by “*”
fields to be replaced by asterisks.
Choose if you want Local Text Echo for Hidden characters denoted by spaces
password input fields to be replaced by spaces.
6.5.4.5.4. To create exception entries for non-standard input fields in an application
Updated: 2010-02-08
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.
Start the application.
2.
3.
4.
5.
1.
2.
6.
1.
2.
3.
4.
5.
Select > > > > Start All Programs Citrix Administration Tools SpeedScreen Latency
. Reduction Manager
From the menu in SpeedScreen Latency Reduction Manager, select . The Applications Properties
window appears. Application Settings
Select the tab. Click to start the wizard and follow the prompts. Input Field Configuration New
With the application running, select the input field you want to configure and complete these steps:
Drag the pointer onto the input field window for which SpeedScreen behavior needs to
be customized.
If the SpeedScreen Latency Reduction Manager window is obscuring the target input field, check the
check box. This causes the SpeedScreen Hide SpeedScreen Latency Reduction Manager
Latency Reduction Manager window to be hidden from view.
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.
Use this level of compatibility for input fields that are incompatible Medium Compatibility.
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
6.5.4.6. Configuring HDX Broadcast Display Settings
Updated: 2010-01-25
To configure HDX Broadcast display settings
To improve the response when graphics are sent to the client, configure the Citrix Computer policy
setting. Queued images that are replaced by another image are discarded. This Queueing and tossing
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.
To make scrolling smoother because sections of an image can be retrieved from the cache, configure
the Citrix Computer policy setting. Image caching
Enter the maximum memory to be used on the server for each client connection with the Citrix
Computer policy setting. Display memory limit
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 connections with these settings.
For the Citrix Computer policy setting, configure one of the Display mode degrade preference
following options:
Degrade color depth first. Select this option if you want color depth to be reduced
before resolution is lowered when the session memory limit is reached.
Degrade resolution first. Select this option if you want resolution to be lowered before color
depth when the session memory limit is reached.
5. To display a brief explanation to the user when a session is degraded, configure the Citrix Computer policy
setting. Notify user when display mode is degraded Possible reasons for degradation
include exceeding the memory limit and connecting with a client that cannot support the
requested parameters.
6.6. Securing Server Farms
Consult with your organization’s 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 for more information about the template http://technet.microsoft.com
and related settings.
6.6.1. Securing Access to Your Servers
Updated: 2010-01-28
An important first step in securing your server farm is securing access to the servers.
Securing the Delivery Services Console
You can use the Delivery Services Console to connect to any server in your farm. Use it only in
environments where packet sniffing cannot occur. Also, ensure that only administrators can access it. You can
set NTFS permissions so that non-administrators do not have Execute permission for the console executable.
Using NTFS partitions
To ensure that appropriate access control can be enforced on all files installed by XenApp, install XenApp only
on NTFS-formatted disk partitions.
Trusted Server Configuration
This feature identifies and enforces trust relations involved in client connections. This can be used to increase
the confidence of client administrators and users in the integrity of data on client devices and to prevent
the malicious use of client connections. When this feature is enabled, clients can specify the requirements
for trust and determine whether or not they trust a connection to the server.
6.6.2. Securing the Data Store
Updated: 2010-05-07
Protecting the data store involves not only protecting the data in the data store database but also restricting
who can access it. In general:
Users who access your farm’s servers do not require and should not be granted any access to the
data store.
All farm servers share a single user account and password for accessing the data store. Select a
password that is not easy to deduce. Keep the user name and password secure and give it
to administrators only to install XenApp.
Caution: If the user account for accessing the database is changed at a later time, the Citrix IMA Service
fails to start on all servers configured with that account. To reconfigure the Citrix IMA Service password,
use the command on each affected server. Be sure to create a backup of your data dsmaint config
store before changing the password on your data store.
Consult the database vendor documentation for more information.
Microsoft SQL Server
The user account that is used to access the data store on Microsoft SQL Server has public and db_owner roles
on the server and database. System administrator account credentials are not needed for data store access;
do not use a system administrator account because this poses an additional security risk.
If the Microsoft SQL Server is configured for mixed mode security, meaning that you can use either Microsoft
SQL Server authentication or Windows authentication, you may want to create a Microsoft SQL Server
user account for the sole purpose of accessing the data store. Because this Microsoft SQL Server user
account would access only the data store, there is no risk of compromising a Windows domain if the user’
s password is compromised. For high-security environments, Citrix recommends using only
Windows authentication.
Important: For improved security, you can change the user account’s 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 XenApp service pack
or feature release.
Microsoft SQL Server Express
Windows authentication is supported for the Microsoft SQL Server Express database. For security
reasons, Microsoft SQL Server authentication is not supported. The user name and password typically are
those for the local system administrator account. If users have access to the data store server, change
the password with the command and keep the information in a safe place. dsmaint config
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.
6.6.3. Securing Client-Server Communications
Updated: 2010-06-07
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 not perform any authentication.
SSL/TLS protocols. SSL/TLS protocols can protect you from internal and external threats, depending
on your network configuration. Citrix recommends that you enable SSL/TLS protocols. Enabling
SSL/TLS ensures the confidentiality, authentication, and integrity of session data.
If you enable protection against both internal and external threats, you must enable SSL encryption.
Using SecureICA with SSL or TLS provides end-to-end encryption.
Both protocols are enabled on the server side, when you publish an application or resource. The Web
Interface and Citrix online plug-in 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 Remote Desktop Server Configuration
The XenApp policy setting that applies to the connection
The client-server setting (that is, the level you set when you publish a resource)
The Microsoft Group Policy
When you set an encryption level, make sure that it is consistent with the encryption settings you
specified elsewhere. For example, any encryption setting you specify in the TSCC or connection policies cannot
be higher than the application publishing setting.
If the encryption level for an application is lower than what you specified through the TSCC and
connection policies, the TSCC settings and the policies override the application settings.
6.6.3.1. Using SecureICA
Updated: 2009-11-19
By default, client-server communications are obfuscated at a basic level through the SecureICA feature,
which can be used to encrypt the ICA protocol.
Plug-ins 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 plug-in 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.
6.6.3.2. Enabling SSL/TLS Protocols
Updated: 2010-01-28
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
setting when you publish an application. Enable SSL and TLS protocols
If you are using Web Interface with the Secure Gateway, see the information about SSL in the Secure
1.
2.
3.
4.
1.
Gateway and Web Interface administrator documentation.
6.6.3.3. To configure session data encryption
Updated: 2010-03-10
The following procedure explains how to increase the level of encryption by enabling SecureICA (ICA
protocol encryption) or SSL/TLS (Secure Sockets Layer and Transport Layer Security) encryption after you
publish an application.
From the , select a published application in the left pane. Delivery Services Console
From the menu, select . Action Application properties
In the dialog box, select . Application Properties Advanced > Client options
In the Connection encryption section, select one or more of the following:
Select the check box. This option requests the use of the SSL Enable SSL and TLS protocols
and TLS protocols for clients connecting to the published application.
In the Encryption section, select a higher level of encryption from the drop-down list box.
If you are using SecureICA and you want to ensure that ICA traffic is always encrypted at a certain level, you
can set a policy for encryption. Creating a SecureICA policy prevents you from accidentally publishing a
resource at a lower level of encryption. If this policy is enabled and you publish a resource at a lower level
of encryption than the policy requires, the server rejects client connections. For plug-ins that take their
encryption settings from the server, such as the Web Interface and the Citrix online plug-in, 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.
6.6.3.4. To set a policy for ICA encryption
Updated: 2010-01-28
The settings you specify for client-server encryption can interact with any other encryption settings in XenApp
and your Windows operating system. If a higher priority encryption level is set on either a server or client
device, settings you specify for published resources can be overridden.
SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for
your server farm, use SecureICA with SSL/TLS encryption. SecureICA does not use FIPS-compliant algorithms.
If this is an issue, configure the server and plug-ins to avoid using SecureICA.
Configure the Citrix User policy setting with one of the SecureICA minimum encryption level
following options:
. Encrypts the client connection using a non-RC5 algorithm. It protects the data stream Basic
from being read directly, but it can be decrypted.
. Encrypts the logon data with RC5 128-bit encryption and the RC5 (128 bit) logon only
client connection using Basic encryption.
RC5 (40 bit). Encrypts the client connection with RC5 40-bit encryption.
. Encrypts the client connection with RC5 56-bit encryption. RC5 (56 bit)
. Encrypts the client connection with RC5 128-bit encryption. RC5 (128 bit)
6.6.4. Configuring SSL/TLS Between Servers and Clients
Updated: 2010-01-28
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 plug-in and the Citrix XML
Service running on each server. Each plug-in authenticates the SSL Relay by checking the relay’s
server certificate against a list of trusted certificate authorities. After this authentication, the plug-in 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 plug-in, 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 :\Program Files (x86)\Citrix\SSLRelay, where is the drive C C
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.
Installing and Configuring the SSL Relay Tool
If you configure the SSL Relay tool with the User Account Control (UAC) feature of Microsoft Windows
enabled, you might be prompted for administrator credentials. To run the SSL Relay tool, you must have
the following privileges and associated permissions:
Domain administrator
Delegated administrator
Administrator group of the local computer where you are installing the tool
6.6.4.1. 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 organization’s 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.
6.6.4.2. 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
1.
2.
3.
4.
5.
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.
6.6.4.3. 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.
6.6.4.4. To enable the SSL Relay and select the relay credentials
On the server where you installed Citrix SSL Relay, click > > All Programs Citrix Administration Tools
> . Citrix SSL Relay Configuration Tool
Click the tab. Relay Credentials
Select the check box to enable the relay features. Enable SSL relay
Select the check box to display the certificate’s friendly name, if available. Display Friendly Name
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 certificate’s subject common name is used (which is typically the server name). If
is not checked, the entire subject name is used. Display Friendly Name
Select the server certificate from the drop-down box (used to identify the SSL Server Certificate
Relay identity).
6.6.4.5. 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.
1.
2.
1.
2.
3.
1.
2.
3.
1.
To change the SSL port for Internet Information Services, see the relevant Microsoft documentation.
6.6.4.6. Configuring the Relay Port and Server Connection Settings
Updated: 2010-02-03
The SSL Relay relays packets only to the target computers listed on the tab of the Citrix SSL Connection
Relay Configuration Tool. By default, the SSL Relay is configured to relay packets only to the target computer
on which the SSL Relay is installed. You can add other computers in the same server farm for redundancy.
Use the tab to configure the listener port and allowed destinations for the SSL Relay. The SSL Connection
Relay relays packets only to the target computers listed on the tab. The target server and Connection
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.
Note: You can configure the SSL Relay to relay packets to any port and any server, but this is
not recommended because it is a security vulnerability.
See for a list of ports used in a server farm. Configuring TCP ports
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 Citrix online plug-in icaclient.adm file. For more information about plug-in settings, see
the plug-in administrator documentation.
To modify the destination server list
On the server where you installed Citrix SSL Relay, click > > All Programs Citrix Administration Tools
. > Citrix SSL Relay Configuration Tool
Click the tab. Connection
To add a server to the destination server list:
Click . New
Type the FQDN of the computer in the box or click to allow connections Server Name Any
to any server. (These additional servers must also be specified in the configuration of
servers running the Web Interface.)
Type the port number of the Citrix XML Service in the box and click . Destination ports Add
To change the port for a server listed in the destination server list:
Select the server entry and click . Edit
In the dialog box, select a destination port to remove and click Target Server Properties
. Delete
In the field below , type the number of the new destination port and click Destination ports
. (To allow connections to any port on any server, click .) Add Any
6.6.4.7. To run the SSL Relay on port 443 without using HTTPS
Updated: 2010-01-28
Stop the Microsoft Internet Information Service.
2.
3.
1.
2.
Configure and start the SSL Relay service.
Restart the Microsoft Internet Information Service.
The SSL Relay uses port 443 before IIS, including when the server is restarted.
Note: When you configure XenApp, members of the User group are allowed to edit registry entries in
the registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Secure\Citrix\Citrix SSL Relay,
or HKEY_LOCAL_MACHINE\SOFTWARE\Secure\Citrix\Citrix SSL Relay on XenApp, 32-bit Edition. You can
use the Microsoft Security Configuration and Analysis tool to prevent members of the User group from
editing these registry entries.
6.6.4.8. Configuring the Ciphersuites Allowed by the SSL Relay
Updated: 2010-01-28
Use the Citrix SSL Relay Configuration Tool to configure which combinations of ciphersuites the SSL Relay
will accept from the client (a server running the Web Interface or Citrix online plug-in). 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 organization’s 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
On the server where you installed Citrix SSL Relay, click > > All Programs Citrix Administration Tools
> . Click the tab. Citrix SSL Relay Configuration Tool Ciphersuites
Select a ciphersuite from either the left column and click to allow it or from the right column and click Add
to disallow it. Remove
6.6.5. Using the Secure Gateway
Updated: 2010-01-28
Use the Secure Gateway to provide SSL/TLS encryption between a secure Internet gateway server and an
SSL-enabled client, combined with encryption of the HTTP communication between the Web browser and the
Web server. Using the Secure Gateway makes firewall traversal easier and improves security by providing a
single point of entry and secure access to your server farms.
In general, use the Secure Gateway when:
You want to hide internal IP addresses
You want to secure public access to your farm’s 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
1.
2.
3.
4.
5.
6.
7.
to use SSL Relay to secure the traffic between the gateway and the servers running XenApp, including the
servers hosting the Citrix XML Service.
For more information, see the Secure Gateway for Windows administrator documentation.
6.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.
Access the Performance Monitor.
Right-click in the right pane and click . Add Counters
For the location of the performance counters, select . Use local computer counters
From the drop-down list, select . Performance Object Secure Ticket Authority
Select the performance counters you want to monitor and click . Add
Click . Close
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 is the year, is the month, and is the day of the log file creation. yyyy mm dd
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.
6.6.7. Securing Network Communications
Updated: 2010-01-28
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:
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.
6.6.7.1. Configuring TCP Ports
Updated: 2010-05-07
This table lists the TCP/IP ports that the servers, Citrix online 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
Delivery
Services
Console/Access Management Console
135 Not configurable
Citrix SSL Relay 443 See Using the SSL Relay with the Microsoft Internet
Information Server (IIS)
Citrix XML Service 80 See Installing and Configuring XenApp
Client-to-server
(directed UDP)
1604 Not configurable
ICA sessions (clients
to servers)
1494 See for information about XenApp Command Reference
using the ICAPORT command
License
Management Console
8082 See Licensing Your Product
Server to license server 27000 In the console, open the farm or server properties page,
and select License Server
Server to Microsoft
SQL Server or
Oracle server
139, 1433,
or 443 for
MS-SQL
See the documentation for the database software
Server to server 2512 See for information about XenApp Command Reference
using the IMAPORT command
Session reliability 2598 See Configuring Session Reliability
6.6.7.2. Using Proxy Servers
Updated: 2010-01-28
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 Citrix online plug-in documentation.
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
6.6.7.3. Configuring Authentication for Workspace Control
Updated: 2010-01-28
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 the Citrix
online plug-in by typing in their credentials.
To set up the trust relationship, configure the Citrix Computer policy setting. The Citrix Trust XML requests
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.
6.6.8. Using Smart Cards with XenApp
Updated: 2010-01-28
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 smart card reader device. The reader can be connected to the host computer by the serial, USB,
or PCMCIA port.
Citrix supports the use of PC/SC-based cryptographic smart cards. These cards include support for
cryptographic operations such as digital signatures and encryption. Cryptographic cards are designed to
allow secure storage of private keys such as those used in Public Key Infrastructure (PKI) security systems.
These cards perform the actual cryptographic functions on the smart card itself, meaning the private key
and digital certificates never leave the card.
In addition, Citrix supports two-factor authentication for increased security. Instead of merely presenting
the smart card (one factor) to conduct a transaction, a user-defined PIN (a second factor), known only to
the user, is employed to prove that the cardholder is the rightful owner of the smart card.
Note: XenApp does not support the RSA Security Inc. PKCS (Public-Key Cryptography Standard)
#11 functional specification for personal cryptographic tokens.
You can also use smart cards with the Web Interface for XenApp. For details, see the Web Interface
administrator documentation.
Smart Card Requirements
Before using smart cards with XenApp, consult your smart card vendor or integrator to determine
detailed configuration requirements for your specific implementation.
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 Citrix 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.
Configuring XenApp for Smart Cards
A complete and secure smart card solution can be complex and Citrix recommends that you consult your
smart card vendor or integrator for details. Configuration of smart card implementations and configuration
of third-party security systems, such as certificate authorities, are beyond the scope of this documentation.
Smart cards are supported for authenticating users to published applications or for use within
published applications that offer smart card functionality. Only the former is enabled by default upon
installation of XenApp.
The following XenApp clients and plug-ins support smart cards:
Citrix online plug-in
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 plug-in or client documentation.
6.6.9. Configuring Kerberos Logon
Updated: 2010-05-25
The Citrix online plug-in 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 , an option you configure through the Active Directory trusted for delegation
Users and Computers management tool.
Kerberos logon is not available:
If you use the following Remote Desktop Services options:
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.
User Access Control and Administrator Sessions
The User Access Control feature prompts users to enter credentials when all of the following requirements
are met:
Kerberos logon is enabled on the server running XenApp
Users logging on to the computer running XenApp are members of the Administrator group on
that computer
After logon, Administrator group users attempt to access network resources such as shared folders
and printers
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
Configure the Citrix Computer policy setting. 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:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon\ DisableSSPI = 1
You can configure the Citrix online plug-ins to use Kerberos with or without pass-through authentication.
6.6.10. Logging Administrative Changes to a XenApp Farm
Updated: 2010-01-28
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:
Delivery Services Console
some command-line utilities
tools custom built with SDKs
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.
Important: To securely store the credentials used for accessing the Configuration Logging database, you
can enable the IMA encryption feature when you deploy your server farm. After this is enabled, however,
you cannot disable it without losing the data it encrypted. Citrix recommends that you configure IMA
encryption before the Configuration Logging feature is configured and used.
To enable the Configuration Logging feature:
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
The Configuration Logging feature, after it is properly enabled, runs in the background as administrative
changes trigger entries in the Configuration Logging database. The only activities that are initiated by the
user are generating reports, clearing the Configuration Logging database, and displaying the
Configuration Logging properties.
To generate a configuration logging report, use the PowerShell command . Get-CtxConfigurationLogReport
For more information, see help for or Windows PowerShell with Get-CtxConfigurationLogReport
Common Commands.
6.6.10.1. Setting up the Configuration Logging Database
Updated: 2011-02-16
The Configuration Logging feature supports Microsoft SQL Server and Oracle databases; for information
about supported versions, see . CTX114501
The Configuration Logging database must be set up before Configuration Logging can be enabled. Only
one Configuration Logging database is supported per server farm, regardless of how many domains are in
the farm. When the Configuration Logging database is set up, you also must ensure that the appropriate
database permissions are provided for XenApp so that it can create the database tables and stored
procedures (preceded by “CtxLog_AdminTask_”) needed for Configuration Logging. Do this by creating
a database user who has “ddl_admin” or “db_owner” permissions for SQL Server, or a user who has the
"connect" and "resource" roles and "unlimited tablespace" system privilege for Oracle. This is used to
provide XenApp full access to the Configuration Logging data.
The Configuration Logging feature does not allow you to use a blank password to connect to the
Configuration Logging database.
Each server in the server farm must have access to the Configuration Logging database.
Considerations for SQL Server
Only one server farm is supported per Configuration Logging database. To store Configuration
Logging information for a second farm, create a second Configuration Logging database.
When using Windows Integrated Authentication, only fully qualified domain logons are valid. Local user
account credentials will fail to authenticate on the database server that hosts the Configuration Logging database.
Ensure that all Citrix administrators accessing the same farm are configured to use the same default schema.
The database user who will create the Configuration Logging tables and stored procedures must be the owner
of the default schema. If you are using dbo as the default schema, the database user must have
db_owner permissions. If you are using ddl_admin as the default schema, the database user must
have ddl_admin permissions.
See the SQL Server documentation for information about managing and using schemas.
Considerations for Oracle
Only one farm is supported per schema. To store Configuration Logging information for a second farm in
the same database instance, use a different schema. Tables and stored procedures are created in the
schema associated with the user who initially configured the Configuration Logging feature. For information
about managing and using a different schema, see the Oracle documentation.
Important: To use an Oracle database for configuration logging, the 32-bit Oracle client must be installed
on the Delivery Services Console.
Before running the Delivery Services Console, update the Oracle tnsnames.ora client file to include
the connectivity information needed to access the available databases.
6.6.10.2. Defining Database Permissions for Configuration Logging
Updated: 2010-05-07
The first time the Configuration Logging feature is enabled, it connects to the Configuration Logging database
and discovers that the database schema does not exist. XenApp then creates the database schema, tables,
and stored procedures. To create a database schema, XenApp needs full access to the database. After
the database schema is created, full access is no longer necessary and you have the option of creating
additional users with fewer permissions.
The following table lists the minimum permissions required to perform the Configuration Logging tasks.
Configuration Logging task Database permissions needed
To create log entries in
the database tables
INSERT for the database tables
EXECUTE for the stored procedures
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
SQL Server: for and sysobjects sysusers
Oracle: for , and for sequence objects sys.all_objects
and the "create session" system privilege
To clear the log
DELETE/INSERT for the database tables
EXECUTE for the GetFarmData stored procedure
SELECT
SQL Server: for and sysobjects sysusers
Oracle: for , and for sequence objects sys.all_objects
and the "create session" system privilege
To create a report
EXECUTE for the Configuration Logging stored procedures
SELECT
SQL Sever: for and sysobjects sysusers
Oracle: for , and for sequence objects sys.all_objects
and the "create session" system privilege
The Configuration Logging components must have access to the GetFarmData stored procedure to find out if
a Configuration Logging database is associated with a farm. If you do not have permission to execute an
existing GetFarmData stored procedure, this farm is invisible to the Configuration Logging components.
Considerations for SQL Server
Before you configure the Configuration Logging database connection, grant EXECUTE permission to
the sp_databases system stored procedure to list the databases on the database server.
The authentication mode must be the same for the database user who creates log entries in the database
tables and the database user who clears the log.
6.6.10.3. To configure the connection to the Configuration Logging database
Updated: 2010-05-07
After the Configuration Logging database is set up by your database administrator and the appropriate
database credentials are provided to XenApp, use the Configuration Logging Database wizard to configure
the connection to the database.
From the Delivery Services Console, select a farm.
From the Action menu, select . Farm properties
Click . Configuration Logging
Click . The wizard opens. Configure Database
Select the connection type ( or ). For SQL Server, use the drop-down list to select SQL Server Oracle
a SQL Server; for Oracle, select a net service name (from the Oracle tnsnames.ora client file). You can
also type the entry.
(SQL Server only). Select an authentication mode: Windows integrated security (recommended) or
SQL Server authentication.
Enter a valid user name and password for the database. Credentials are always required (even if you
are using Windows Integrated Authentication with SQL Server). The credentials are stored using the
IMA encryption feature. Each server that creates log entries uses the credentials to connect to
the Configuration Logging database.
(SQL Server only). Select or type the name of the database.
Configure connection options and connection pooling options. You can use the default values for
these settings. (For SQL Server, the possible exception is . For security reasons, Use encryption
9.
10.
1.
2.
3.
4.
5.
the default value is ; however, if the database server to which you are connecting does not Yes
support encryption, the connection will fail. Click on the summary page Test Database Connection
to check for encryption support.)
Click . A display indicates whether or not the connection Test Database Connection
established successfully.
After you configure the connection to the Configuration Logging database, you cannot set the database back to
. To stop logging, clear the check box None Log administrative tasks to Configuration Logging database
in the dialog box. Configuration Logging
6.6.10.4. To set Configuration Logging properties
Updated: 2010-01-28
Before you set Configuration Logging properties, configure the database and the connection to the
database. Otherwise, the Configuration Logging property fields are not active.
Full Citrix administrators can edit the Configuration Logging settings and clear the log, or they can authorize
other administrators to perform these tasks by assigning them the delegated administration Edit
Configuration Logging Settings permission. Without this permission, ordinary administrators cannot perform
these functions.
From the Delivery Services Console, select a farm.
From the Action menu, select . Farm properties
Click . Configuration Logging
To enable Configuration Logging, select the Log administrative tasks to Configuration
check box. Logging database If you want administrators to be able to make changes to the server
farm when log entries cannot be saved to the Configuration Logging database, select the Allow
check box. changes to the farm when logging database is disconnected
To prompt administrators to enter their credentials before clearing the log, select the
check box. Require administrators to enter database credentials before clearing the log
6.6.10.5. Clearing Entries from the Configuration Logging Database
Updated: 2010-09-28
It may become necessary to clear the entries in the Configuration Logging database if the population of the
tables becomes too large.
To manage which database users can clear the configuration log, Citrix recommends that you enable the
check box in Require administrators to enter database credentials before clearing the log
the Configuration Logging properties. Anyone attempting to clear the log is prompted for database credentials.
The credentials must correspond to the authentication mode you selected when you connected to the
database initially. Specifically:
For SQL authentication, credentials with permissions for the Configuration Logging database on the
SQL server are required
For Windows Integrated authentication, XenApp impersonates the database user when it connects to
the SQL database, so credentials for the Windows user account are required
Use one of the following methods to clear log entries from the Configuration Logging database:
From the Delivery Services Console, expand the farm node and select . Select History Clear history
in the Actions pane or the Action menu.
Use the PowerShell command . For more information, see help for Clear-XAConfigurationLog
or Windows PowerShell with Common Commands. Clear-XAConfigurationLog
6.6.10.6. Encrypting Configuration Logging Data
Updated: 2010-01-29
1.
2.
3.
1.
2.
Independent Management Architecture (IMA) is the underlying architecture used in XenApp for
configuring, monitoring, and operating all XenApp functions. The IMA data store stores all XenApp configurations.
IMA encryption protects administrative data used by Configuration Logging. This information is stored in the
IMA data store. For IT environments with heightened security requirements, using IMA encryption provides
a higher degree of security for Configuration Logging. One example would include environments that require
strict separation of duties or where the Citrix Administrator should not have direct access to the
Configuration Logging database.
IMA encryption is a farm-wide setting that applies to all servers in the farm after encryption is
enabled. Consequently, to use IMA encryption, you must enable it on all servers in the farm. IMA encryption
has the following components:
Component Description
CTXKEYTOOL Also known as the IMA encryption utility, CTXKEYTOOL is a command-line utility
you use to manage IMA encryption and generate key files. CTXKEYTOOL is in
the Support folder of the XenApp media.
Key file The key file contains the encryption key used to encrypt sensitive IMA data.
You create the key file using CTXKEYTOOL. To preserve the integrity of the
encryption, Citrix recommends that you keep the key file in a secure location and
that you do not freely distribute it.
Key The same valid IMA encryption key must be loaded on all servers in the farm if
IMA encryption is enabled. After copying the key file to a server, you load the key
by using CTXKEYTOOL.
Configuring IMA encryption includes the following tasks:
On the first server in a farm (that is, the server on which you create the farm during
XenApp configuration), generate a key file, load the key, and enable it
Make the key file accessible to other servers in the farm or put it on a shared network location
Load the key onto other servers in the farm (that is, the servers that join the farm during configuration)
Citrix recommends that if you are enabling IMA encryption in environments that have multiple farms, you give
the key for each farm a different name.
Storing CTXKEYTOOL Locally
Copy the CTXKEYTOOL.exe file from the Support folder of XenApp media to your local computer.
Create a folder named Resource at the same level in your directory structure as the CTXKEYTOOL file.
Copy the entire Support\Resource\en folder to the new Resource folder.
You can store the CTXKEYTOOL.exe file and the Resource\en folder anywhere on your computer, provided
you maintain the same relative directory structure used on the media.
6.6.10.6.1. To generate a key and enable IMA encryption on the first server in a farm
Updated: 2010-02-02
Before enabling IMA encryption on the first server in the XenApp farm (that is, the server on which you
created the farm), install and configure XenApp, and restart the server.
On the server where you created the XenApp farm, run CTXKEYTOOL with the option, generate
specifying the full UNC or absolute path (including the file name of the key you want to generate) to
the location where you want to store the file key.
Citrix suggests naming the key after the farm on which it will be used; for example, farmakey.ctx.
Citrix also suggests saving the key to a folder that uses the name of your farm; for example, Farm A Key.
If the key file generates successfully, the message “Key successfully generated" appears.
To obtain the key from the file and put it in the correct location on the server, run CTXKEYTOOL with the
option on the server on which you want to add the key, specifying the full UNC or absolute load
2.
3.
1.
2.
3.
1.
2.
3.
If the key path (including the key file name) to the location where you stored the key file.
loaded successfully, the message “Key successfully loaded” appears.
Run CTXKEYTOOL with the option to use the currently loaded key and enable the key. newkey If
IMA encryption is enabled successfully, the message “The key for this farm has been replaced.
IMA Encryption is enabled for this farm” appears.
Storing the Key File on a Shared Network Location
If you choose to store the key on a shared network location, Citrix recommends the following:
Give the folder a meaningful name that specifies the name of the farm for which the key was created.
This is important in situations when you follow the Citrix best practice recommendation of creating a
unique key for the farm.
Ensure that the account you use to generate the key is the same as the account that will be used
to configure all the servers in the farm. You must use the same account for both tasks.
When you generate the key file, save it to a local directory (as you normally would).
After enabling IMA encryption on the server where you generated the key, copy the key file to the
shared network location.
Grant Read/Execute access to the key file for each server that will be joining the farm, and to
the administrator performing the installation.
6.6.10.6.2. To load a key on servers that join the farm
Updated: 2010-01-29
Before enabling IMA encryption on servers you are joining to a XenApp farm, install and configure XenApp, but
do not restart the server.
If you do not have the key file on a shared network location, load the key file to the server.
To obtain the key from the file and put it in the correct location on the server, run CTXKEYTOOL with the
option, specifying the full UNC or absolute path (including the key file name) to the location load
where you stored the key file. If the key loaded successfully, the message “Key successfully
loaded” appears. You do not need to enable IMA encryption on this server, because you already enabled
it on the first server in the farm
Restart the server.
Repeat this procedure on all servers you configure to join the farm.
Changing Farms
If you move a server that has IMA encryption to a farm that has IMA encryption enabled, run CTXKEYTOOL
with the option (specifying the key that was generated for the new farm) on that server is configured load
but before it is restarted.
If you move a server that has IMA encryption enabled to a farm that does not have IMA encryption enabled,
IMA encryption is disabled automatically on the server being moved.
6.6.10.6.3. Managing IMA Encryption
Updated: 2010-01-29
IMA encryption includes other features that you can use as needed:
Citrix strongly recommends backing up the farm key to a safe, secondary location, such as a
CD, immediately after you generate a key. You can create a copy of the key file when you create it, or
you can back up the farm key by running CTXKEYTOOL with the option. backup
You can recreate a key file that you accidentally deleted, lost, or overwrote. All servers in the same
farm use the same key, so you can obtain a key from another server on the farm; however, XenApp
does not allow you to access keys. You must recreate the entire key file by running CTXKEYTOOL with the
option on any server in the farm that has the key and is functioning properly. backup
You can disable IMA encryption by running CTXKEYTOOL with the option. Because IMA disable
encryption is a farm-wide feature, disabling it on one server disables the feature on all servers.
If you disable IMA encryption, to access the Configuration Logging database, you must reenter
the password for the Configuration Logging database. In addition, no configuration information is
logged until you reenter your database credentials.
To reenable IMA encryption after you disabled it, run CTXKEYTOOL with the option. After enable
enabling IMA encryption, Citrix recommends that you run CTXKEYTOOL with the option to query
verify that IMA encryption is enabled.
For more information about CTXKEYTOOL, see the documentation. XenApp Command Reference
6.6.11. XenApp Service Account Privileges
Updated: 2011-03-07
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 tab for the service. Dependencies
Licensing services, which are not listed here, might also appear if the license server is installed on the
same server as XenApp.
Display
Name
(Service Name)
Executable Logon Account
/ Startup Type
Description Dependencies
Citrix 64-bit
Virtual
Memory Optimization
ctxsfosvc64.exe Local System/ Manual Dynamically optimizes 64-bit applications running on a XenApp server. None
Citrix Client
Network (CdmService)
cdmsvc.exe Local System/ Automatic Maps client
drives
and peripherals
for access
in sessions.
Client
Drive
Mapping
(CDM), Windows Management Instrumentation Driver Extensions, Workstation
Citrix CPU
Utilization Mgmt/CPU Rebalancer (CTXCPUBal)
ctxcpubal.exe .\ctx_cpuuser/Manual Enhances
resource management across multiple CPUs. Installed only on servers that have multiple CPUs.
None
Citrix CPU
Utilization Mgmt/Resource Mgmt (ctxcpuSched)
ctxcpusched.exe Local System/ Manual Manages
resource consumption to enforce entitlement policies.
Remote Procedure Call (RPC)
Citrix
Diagnostic
Facility COM
Server (CdfSvc)
CdfSvc.exe NT
AUTHORITY\
Network Service/Automatic
Manages
and
controls
diagnostic
trace
sessions,
which
diagnose
problems on
a XenApp server.
Remote Procedure Call (RPC)
Citrix
Encryption Service
encsvc.exe NT AUTHORITY\
Local Service/ Automatic
Enables
secure communication with RC5 128-bit encryption between Citrix plug-ins and XenApp.
Windows Management Instrumentation Driver Extensions
Citrix End SemsService.exe Local Service/ Manual Collects and Citrix
User
Experience Monitoring (Citrix EUEM)
collates end-
user
experience measurements.
SMC
Support Driver
Citrix
Health
Monitoring
and
Recovery (CitrixHealthMon)
HCAService.exe NT AUTHORITY\
Local Service/ Automatic
Provides
health
monitoring
and
recovery services
in the
event
problems occur.
Citrix Independent Management Architecture service
Citrix
Independent Management Architecture (IMAService)
ImaSrv.exe NT
AUTHORITY\ NetworkService/ Automatic
Provides management services in the XenApp farm. Citrix
Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC)m TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation
Citrix
MFCOM
Service (MFCom)
mfcom.exe NT
AUTHORITY\ NetworkService/ Automatic
Provides
COM services
that allow
remote
connections
from
the
management tools.
Remote Procedure Call (RPC), Citrix Independent Management Architecture service, Citrix Services Manager service
Citrix Print
Manager
Service (cpsvc)
CpSvc.exe Local Service/Automatic Manages
the creation
of printers
and driver
usage
within
XenApp
sessions.
Supports the
Citrix
Universal
Printing features.
Print
Spooler, Remote Procedure Call (RPC)
Citrix
Secure
Gateway
Proxy (CtxSecGwy)
CtxSGSvc.exe NT
AUTHORITY\
Network
Service/ Automatic
Proxy to the
Citrix
Secure
Gateway server.
None
Citrix
Services
Manager (IMAAdvanceSrv)
IMAAdvanceSrv.exe Local System /Automatic Provides
XenApp with
an interface to
the
operating
system.
Other services
use this services
for
elevated operations.
None
Citrix
Streaming
Service (RadeSvc)
RadeSvc.exe .
\Ctx_StreamingSvc /Automatic
Manages the
Citrix offline plug-
in when
streaming applications.
Remote Procedure Call (RPC)
Citrix
Virtual
Memory Optimization
CTXSFOSvc.exe Local System /Manual Dynamically optimizes applications running on a XenApp server to free up server memory. None
Citrix WMI
Service (CitrixWMIservice)
ctxwmisvc.exe NT AUTHORITY\
Local Service/Manual
Provides the
Citrix WMI
classes
Citrix Independent Management Architecture service , Citrix Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC), TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation
for information
and
management purposes.
Citrix XML
Service (CtxHttp)
ctxxmlss.exe Network
Service /Automatic
Services XML
data requests
sent by
XenApp components
None
Citrix XTE
Server (CitrixXTEServer)
XTE.exe NT
AUTHORITY\ NetworkService /Manual
Services
network requests
for session
reliability and
SSL from
XenApp components.
None
Caution: Citrix does not recommend altering account permissions and privileges. If you delete the accounts
or alter their permissions incorrectly, XenApp might not function correctly.
Permissions for Service User Accounts
This table lists the permissions associated with accounts XenApp services use.
Account Name 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_ConfigMgr Domain or local user Acts as a Power User
Ctx_CpuUser Domain or local user Acts as a User
Privileges for Service User Accounts
If your organization requires that service accounts run as domain accounts and not as local accounts, you
can create domain accounts to replace the Ctx_ConfigMgr and Ctx_CpuUser accounts before installing
XenApp. Citrix does not support changing the account for the Citrix Streaming Service
(Ctx_StreamingSvc). Ensure the new account has the same privileges as the default account.
Privileges Local ServiceNetwork ServiceCtx_StreamingSvc Ctx_ConfigMgr Ctx_CpuUser
Change
the system time
x x
Generate security audits x x
Increase quotas x x
Log on as
a batch job
x x x x x
Log on as
a service
x x x x x
Replace
a process
level token
x x x
Restore
files
and directories
x
1.
2.
3.
1.
Debug programs x
Increase scheduling priority x
6.7. Maintaining Server Farms
Updated: 2010-01-21
A server farm is a group of servers running Citrix XenApp and managed as a single entity. The servers in
the server farm share a single IMA-based data store.
Citrix recommends performing farm maintenance tasks from the data collector, assuming no applications
are published on the data collector, because this updates farm data faster. Performing farm maintenance
tasks from a server hosting published applications can slow down users trying to connect to published
applications and take longer to update in the data store.
The Delivery Services Console provides a wide variety of summary information about the farm and each server
in the farm. You can customize your view and group applications or servers in folders to make navigating
through their 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.
From the menu, select and choose Start All Programs > Citrix > Management Consoles Citrix
. Delivery Services Console
When you select an item in the navigation pane, the pane provides quick access to related options Actions
for the selected item.
In addition, configure Citrix policy settings in the Delivery Services Console or the Local Group Policy
Editor, depending on whether or not you use Active Directory in your XenApp environment. Use these settings
to maintain the farm, including scheduling restarts, optimizing and monitoring server performance, and
setting the port for the Citrix XML Service and License Server. For more information, see the Policy
. Settings Reference
6.7.1. To search for objects in your farm
Updated: 2010-01-26
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.
From the Delivery Services Console, in the navigation pane, select , and in the pane, select Search Actions
. Search for items
In the dialog box, in the box, select one of the following: Advanced Search Find
Discovered items. Searches discovered items.
Sessions By User. Lists the sessions to which a specific user is connected. Type a user name in the
box. Name
. Lists the applications that the specified user is using. Type a user name Applications By User
in the box. Name
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 box. Name
Use the button to select one of the Citrix Resources locations to search in. Browse
6.7.2. To change a server's desktop settings
Updated: 2010-06-07
To perform administrator tasks on a server's desktop, you can access a server’s desktop only if the desktop of
the selected server is published. Configure connection settings to your servers through the Microsoft
Management Console (MMC) using Remote Desktop Server Configuration.
1.
2.
3.
4.
1.
2.
Configure the Citrix policies setting for to . If it is set to , Desktop launches Allowed Prohibited
this feature fails.
From the , select a server. Delivery Services Console
In the pane, select > , and choose one of the following settings: Actions Other Tasks Connect to server
Connect to server’s published desktop
Connect directly to server's desktop
In the dialog box, choose from the following selections. The selections Launch ICA Desktop Session
you make here become the new default settings.
Accept the and values (800 x 600 by default) or specify a different resolution. Width Height
Colors (Better Speed by default). Select the color depth for the application. The available
options are 256 colors (8-bit), Better Speed (16-bit), or Better Appearance (32-bit).
Encryption. Select one of the following options from the list.
Basic encrypts the connection using a non-RC5 algorithm (default setting). Basic
encryption protects the data stream from being read directly but can be decrypted.
128-Bit Login Only (RC5) encrypts the logon data with RC5 128-bit encryption and the
ICA connection with basic encryption.
40-Bit (RC5) encrypts the connection with RC5 40-bit encryption.
56-Bit (RC5) encrypts the connection with RC5 56-bit encryption.
128-Bit (RC5) encrypts the connection with RC5 128-bit encryption.
6.7.3. To limit the number of server connections per user
Updated: 2010-01-27
When a user starts a published application, the client establishes a connection to a server in the farm and
initiates a client session. If the user then starts another published application without logging off from the
first application, the user has two concurrent connections to the server farm. To conserve resources, you can
limit the number of concurrent connections that users can make.
Configure the Citrix policy for > by setting the following options: Server Settings Connection Limits
. Specify the maximum number of connections a user can make to any single Limit User sessions
server at the same time.
. Enable this setting to extend the connection limit to Limits on administrator sessions
Citrix administrators.
Important: Limiting connections for Citrix administrators can adversely affect their ability to
shadow other users.
. Enable this setting to record information about denied connection Logging of logon limit events
events in the server’s system log.
6.7.4. To disable and re-enable server logons
Updated: 2010-02-17
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. When you disable logons, current
sessions remain active until the users log off.
From the , select the server. Delivery Services Console
In the pane, select one of the following: Actions
Other Tasks > Disable logon
Other Tasks > Enable logon
6.7.5. Restarting Servers at Scheduled Times
Updated: 2010-01-27
To optimize performance, you can restart servers automatically at specified intervals by creating a
restart schedule.
Restart schedules are based on the local time for each server to which they apply. This means that if you apply
a schedule to servers that are located in more than one time zone, the restarts do not happen
simultaneously; each server is restarted at the selected time in its own time zone.
When the Citrix Independent Management Architecture (IMA) service starts after a restart, it establishes
a connection to the data store and updates the local host cache. This update can vary from a few
hundred kilobytes of data to several megabytes of data, depending on the size and configuration of the
server farm.
To reduce the load on the data store and to reduce the IMA service start time, Citrix recommends
maintaining restart groups of no more than 100 servers. In large server farms with hundreds of servers, or
when the database hardware is not sufficient, restart servers in groups of approximately 50, with at least
10 minute intervals between groups.
Configure the Citrix policy for by setting the following options: Reboot Behavior
(disabled by default). Enable this setting to apply a restart schedule and warnings. Scheduled reboots
Continue by configuring related reboot policy settings for scheduling restarts, including settings
for warnings to users and the schedules by frequency and start date.
6.7.6. Removing and Reinstalling XenApp
Updated: 2010-02-16
Tasks you might need to perform to remove servers from your farm or remove XenApp software from a
server include:
Moving a server to another farm
Renaming a server
Removing a server from your farm
Removing XenApp from a computer in your farm or forcing its removal
Removing a server from your farm if the hardware hosting XenApp fails
To accomplish these tasks, you might need to remove XenApp from its host computer, remove it from the farm
or from the list of farm servers in the Delivery Services Console, or repair the installation.
In addition, see the procedures in this section for related tasks, including moving or removing a server from
the farm and renaming a XenApp server.
Removing XenApp
Citrix recommends that you remove XenApp by using > while Control Panel Programs and Features
the server is still connected to the farm and the network. Select , click . Citrix XenApp <version> Uninstall
After the program is finished, restart the server.
This method removes the host information from the farm data store and removes the server from the
farm properties displayed in the management tools.
To remove XenApp remotely, you can do so from within a Remote Desktop Connection (RDC) session or
using tools such as Microsoft Configuration Manager 2007 (formerly Systems Management Server (SMS)).
If you want to remove only specific components of XenApp, do so in the following order:
Citrix Access Management Console or Delivery Services Console
XenApp Advanced Configuration or Presentation Server Console
Citrix XenApp
Citrix Web Interface
Citrix Licensing
Forcing the Removal of XenApp
1.
2.
1.
2.
To force the removal of XenApp from a computer, you can use on a command line to add the property: msiexec
. Set its value to . CTX_MF_FORCE_SUBSYSTEM_UNINSTALL Yes
The following sample command line enables logging of the uninstallation operation and forces the removal
of XenApp:
msiexec /x /L*v c:\output.log CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=Yes mps.msi
where is the name and location of the msi package. mps.msi
Repairing a XenApp Installation
Before you start, log off from all sessions and exit any applications running on the server. After you finish,
restart the server when prompted.
When you run the repair utility from > , XenApp overwrites all files Control Panel Programs and Features
and settings with those from the original installation. If you customized any of the files or features in your
XenApp installation, running the repair utility replaces your customizations with the original files and settings.
Reinstalling XenApp Due to Hardware Failure
If the hardware for a server fails and needs to be replaced, change its name to the same name as the
failed server before you connect its replacement server to your network. Assigning the replacement server
the failed server’s name lets the replacement have the same properties and functionality as the failed
XenApp server. The records in the data store for the old server apply to its replacement of the same name.
Ensure that the replacement server settings are identical to the failed server, including:
Server name
Operating system
Settings for applications made during installation or when the application was published
User accounts
Backing Up and Restoring the XenApp Data Store
Many data store maintenance tasks are performed using the DSMAINT and DSCHECK commands. For
more information, see the and documentation. Command Reference Data Store Database Reference
6.7.6.1. To move or remove a server
Updated: 2010-02-16
To move a XenApp server from the farm or join the server to another farm, use XenApp Server Configuration
Tool accessed through the Server Role Manager. Alternatively, use the command-line
through XenAppConfigConsole.exe. Both methods remove the server from the farm data store and from the
lists of servers displayed in the consoles.
If the hardware for a server fails or it cannot be started to run the uninstall program, remove the server.
Citrix recommends that you use the Delivery Service Console to remove a server from the farm only in
cases where the server cannot be started to run the Windows uninstall program.
Caution: If you remove all servers belonging to a single domain and have Citrix administrators in the
domain, their user accounts cannot be enumerated by the console and appear as a question mark (?) in the
list of Citrix administrators.
To remove a server from a farm
With the server connected to the network and online in the farm, remove XenApp from the server from
by selecting and selecting Control Panel > Programs and Features Citrix XenApp <version>
. Uninstall
On a different server in the farm, open the Delivery Services Console, run or rerun Discovery, and
If the server from which you check that the server was removed from the farm successfully.
removed XenApp still appears in the console:
In the left pane, select the server.
From the menu, select > . Action Other Tasks Remove from farm
3.
4.
5.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
After you ensure the server no longer appears in the farm, disconnect the server from the network.
Caution: Do not reconnect the server to the network until you re-image it or remove its
XenApp software. If it reconnects to the network, it can corrupt your farm.
Run the command on the data store to repair any consistency errors. dscheck
Perform a new installation of operating system (that is, a “clean” installation and not an upgrade)
and XenApp (if you want to reuse the hardware for that server).
6.7.6.2. To rename a XenApp server
Updated: 2010-02-16
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.
Create a Citrix local administrator account on the server you want to rename.
On the server you want to rename, run to prevent users from logging on to the server. chglogon /disable
Open the Access Management Console or Delivery Services Console on a different server, and remove
the server to be renamed from published applications assigned to that server.
On the server you want to rename, stop the Citrix Independent Management Architecture service.
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, 32-
bit 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.
Change the name of the server in the server operating system and restart the server.
Log on to the console using the local administrator account you created.
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.
Expand the Servers folder and remove the old server name from the list of servers.
Add the new server name to the list of configured servers for published applications.
6.7.7. Monitoring Server Performance with Health Monitoring & Recovery
Updated: 2010-06-07
You can use Health Monitoring and Recovery to run tests on the servers in a server farm to monitor their
state and discover any health risks. Citrix provides a standard set of tests; you have the option of
importing additional tests, including custom tests that you develop. The Citrix tests included with XenApp
allow you to monitor several services and activities including Remote Desktop Services, XML Service, Citrix
IMA Service, and logon/logoff cycles.
By default, Health Monitoring and Recovery is enabled on all of the servers in your farm, and the tests that
are included run on all servers, including the data collector. Typically, you do not need to run these tests on
the data collector because, particularly in a large farm, the data collector is not used for serving applications.
If you do not want Health Monitoring & Recovery to run on the data collector, you must disable it manually.
Store all custom tests in the following location:
\Citrix\HealthMon\Tests\Custom\ %Program Files%
where is the location in which you installed XenApp. When saving custom tests, do not %Program Files%
include spaces in the file names.
Configure the Citrix policy for by setting the following options: Health Monitoring and Recovery
(enabled by default). Use this setting to allow the Health Monitoring and Health monitoring
Recovery feature.
. Use this setting to specify which tests to run. Select from a standard set Health monitoring tests
of Citrix tests (described below) or add your own customized tests. For descriptions of recovery
actions, see . Modifying Health Monitoring and Recovery Actions
(10 percent by default). Use this setting to specify the number Maximum percent of offline servers
of servers that the Health Monitoring and Recovery feature can exclude from load balancing.
Use the load balancing feature of XenApp with Health Monitoring and Recovery to ensure that if a server in
the farm experiences a problem (for example the Citrix IMA Service is down), the state of that server does
not interfere with the user’s ability to access the application because the user’s connection to that application
is redirected through another server. For more information about load balancing and using Load Manager, see the
section in eDocs. Load Management
Citrix Tests
Citrix IMA Service test
This test queries the service to ensure that it is running by enumerating the applications available on
the server.
Logon monitor test
This test monitors session logon/logoff cycles to determine whether or not there is a problem with
session initialization or possibly an application failure. If there are numerous logon/logoff cycles within
a short time period, the threshold for the session is exceeded and a failure occurs. The session
time, interval, and threshold can be configured by modifying the parameters in the field. Test file
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.
Remote Desktop Services test
This test enumerates the list of sessions running on the server and the session user information, such
as user name.
XML Service test
This test requests a ticket from the XML service running on the server and prints the ticket.
Check DNS test
This test performs a forward DNS lookup using the local host name to query the local DNS server in
the computer’s environment for the computer’s IP address. A failure occurs if the returned IP address
does not match the IP address that is registered locally. To perform reverse DNS lookups in addition
to forward DNS lookups, use the flag /rl when running this test.
Check Local Host Cache test
Citrix does not recommend running this test unless you have problems with corrupted local host
caches. This test ensures the data stored in the XenApp server’s 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 file located in C:\Program Files LHCTestACLsUtil.exe
(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.
6.7.7.1. Modifying Health Monitoring and Recovery Actions
Updated: 2010-01-22
The Health Monitoring and Recovery tests included with XenApp are configured with default settings. You
can modify the settings for each test. Monitor error messages in the Events log. For a description of the
Citrix tests, see Monitoring Server Performance with Health Monitoring & Recovery.
To set recovery actions, configure the Citrix policy settings for > Health Monitoring and Recovery
. Health monitoring tests
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 command-line utility. enablelb
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.
1.
2.
3.
1.
2.
3.
4.
5.
6.
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.
6.7.7.2. Developing Custom Health Monitoring & Recovery Tests
Updated: 2010-02-12
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.
After developing the custom test:
Save the test in the custom test location, such as c:\program files (x86)\Citrix\HealthMon\Tests\Custom
Specify the custom test in a Citrix policy
To specify custom tests in a Citrix policy
Configure the Citrix policy setting for to enable the feature. Health monitoring
Configure the Citrix policy setting for , and select . Health monitoring tests Add Custom
In the Add Custom Test dialog box:
Provide a name for the test.
Provide the file location using the following example:
If the file location is: c:\program files (x86)\Citrix\HealthMon\Tests\Custom\mytest.exe
The path you enter is: Custom\mytest.exe
The rest of the path is added by the Health Monitoring & Recovery feature based on the
installed location.
Complete the remaining options as preferred.
6.7.8. Using Citrix Performance Monitoring Counters
Updated: 2009-11-24
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
On the server where XenApp is installed, open the console. Server Manager
In the Tree view, select . Diagnostics > Performance > Monitoring Tools > Performance Monitor
From the menu bar, selection > Action Properties.
In the dialog box, select the tab. Performance Monitors Data
Click . Add
6.
7.
8.
9.
10.
In the dialog box, from the drop-down list, ensure Add Counters Select counters from computer
is selected. Local computer
In the list, select . Available counters ICA Session
To add all ICA counters, in the list, select . Available counters ICA Session To add one or more
ICA counters, click the plus sign next to and select the individual counters to be added. ICA Session
Select to enable all instances of the selected ICA counters, , or All instances No instance
and highlight only the instances you need. Select instances from list 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.
Click and then click . Add 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.
6.7.9. Using Worker Groups for Enhanced Resource Access
Updated: 2010-03-02
Worker groups are collections of XenApp servers, residing in the same farm, that are managed as a single
unit. Using worker groups, you can:
Streamline application publishing to multiple farm servers
Load balance access to published resources
Filter policies so that settings are applied only to sessions hosted on a specific set of farm servers
When using worker groups, consider the following:
A farm server can belong to multiple worker groups
A worker group can include any number of XenApp servers or none at all
Only servers that belong to the same XenApp farm are included in a worker group
Publishing Applications
When publishing an application, you can use worker groups to specify the servers hosting the application.
To increase capacity for the application, you can add more servers to the worker group rather than modify
the application properties. If your environment includes Active Directory, you can create the worker group
based on the Organizational Unit (OU) that includes the servers hosting the application. To increase capacity
for the application, you add servers to the OU. New servers that you add to the OU are automatically included
in the worker group.
When adding servers to worker groups for application publishing, all XenApp servers in the worker group
must have the application installed. When a user attempts to launch an application, XenApp checks to ensure
the application is installed on the farm servers in the worker group. If the application is not installed,
the application does not launch and an error is logged to the Application event log on the data collector.
Load Balancing Access to Published Resources
To ensure an optimal experience for users accessing published resources, XenApp provides load balancing
policies to direct users to the least-loaded XenApp server hosting the resource. You can use load
balancing policies to:
Reduce WAN traffic by directing users to the closest regional server
Direct users to a backup server in the event of an outage
Direct a specific group of users to a group of dedicated servers
Load balancing policies consist of the following elements:
A filter to determine when the policy is applied
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
6.
A worker group preference list to determine the servers to which users are directed when logging on
When you create a load balancing policy, configure a filter so that the load balancing policy can be applied
to users when they access published resources. If you do not configure a filter, the load balancing policy will
have no effect when users log on. As with other Citrix policies, you can filter based on access control, client
IP address, client name, and users.
Additionally, to ensure users are directed to the appropriate servers, create a worker group preference list
to prioritize the servers that users can access. A priority of 1 is considered the highest priority. When a
user launches a published application, the load balancing policy directs the user to servers in the highest
priority worker groups first. Users are directed to servers in lower priority worker groups if servers in the
higher priority worker groups are offline or have reached maximum capacity. Users are not directed to servers
in worker groups that are not included in the worker group preference list. If a user attempts to launch
an application that is not installed on any servers in any of the listed worker groups, regardless of priority,
the launch attempt fails and an error is logged to the Application event log on the data collector.
After you create load balancing policies, you prioritize them just as you would any other Citrix policy. If
multiple load balancing policies apply to a single user, XenApp uses the worker group preference list from
the highest priority policy to direct the user. Preference lists from lower priority load balancing policies are
not considered.
Using Worker Groups to Filter Policies
You can use worker groups as filters in Citrix policies to apply policy settings to connections. When adding
the filter, you specify the worker group by name only. If the worker group is subsequently renamed or
deleted, XenApp no longer recognizes the filter and the policy is not applied to any connections.
6.7.9.1. To create a worker group
Updated: 2010-02-25
From the Delivery Services Console, select the node in the left pane. Worker Groups
From the Actions pane, click . Create Worker Group
In the dialog box, type a name for the worker group. Create Worker Group
In , select the server grouping and then click . For example, select Select source Add
to add servers based on their OU membership in Active Directory. Organizational Units
Note: If you do not use Active Directory in your environment, select to add Farm Servers
individual XenApp servers to the worker group.
Select the groups of servers you want to add to the worker group. For example, if you selected
in the previous step, select the organizational units that contain the servers Organizational Units
you want to add to the worker group.
Note: Only XenApp servers that reside in the same farm are included in the worker group. If
an organizational unit contains XenApp servers that reside in other farms, those servers are
not considered part of the worker group.
6.7.9.2. Creating and Prioritizing Load Balancing Policies
Updated: 2010-02-25
From the Delivery Services Console, select the node in the left pane. Load Balancing Policies
From the Actions pane, click Create load balancing policy.
Under , select the filter to use to determine when the load balancing policy is applied. Filters
Under , select and then select Load Balancing Policies Worker Group Preference
. Configure application connection preference based on worker group
Click and select the worker group you want to include. Add
Click to add the worker group to the list. Each worker group you add is automatically assigned Add
6.
7.
1.
2.
3.
a priority, from highest (1) to lowest.
To adjust the priority of the worker groups in the list, select a worker group and then perform one of
the following actions:
Click and enter the priority level you want for the worker group. Entering a priority Set priority
for a worker group does not affect the priority of any other worker group in the list. Multiple
worker groups can share the same priority.
Click or to adjust incrementally the priority of the Increase Priority Decrease Priority
worker group.
To adjust the priority of a load balancing policy
From the Delivery Services Console, select the node in the left pane. Load Balancing Policies
From the middle pane, select a load balancing policy.
From the Actions pane, perform one of the following actions:
Click and enter the priority level you want for the policy. Set priority
Click or as appropriate to adjust incrementally the priority Increase priority Decrease priority
of the policy.
6.7.9.3. Enhancing the Performance of a Remote Group of Servers
Updated: 2010-02-12
For business continuity, you can specify that if all servers in a worker group go offline, XenApp redirects
user connections to a backup worker group. This feature is known as Worker Group Preference and Failover;
you configure it in the XenApp console through the . Load Balancing Policies
As a best practice, to keep ICA traffic from going over the WAN, you should:
Direct requests for applications by specifying a Worker Group connection order in the Load
. Balancing Policies
Create a policy that applies to connections from a worker group. Then, specify that worker group as
the Primary Group in the policy. This makes XenApp route incoming connection requests from users to
that worker group first.
For more information about worker groups, see . Creating Worker Groups
6.7.10. Using Preferential Load Balancing
Updated: 2010-02-23
Preferential Load Balancing assigns importance levels (Low, Normal, or High) to specific users and
applications. For example, doctors and nurses in a hospital are specified as important users and MRI scans and
X-rays are specified as important applications. These important users and applications with higher levels
of service connect to their sessions more quickly and have more computing resources available to them.
By default, a Normal level of service is assigned to all users and applications.
Preferential Load Balancing calculates importance levels based on the for each session. Resource Allotment
The Resource Allotment is determined by the of both the session and the published importance levels
application that the session is running.
To enable Preferential Load Balancing, configure the policy setting and select CPU management server level
. Preferential Load Balancing
Continue by configuring the setting. Sessions with higher importance levels are directed Session importance
to servers with lower resource allotments.
Finally, set the application importance level when publishing the application. You can modify an
application's importance level in the Limits section of the application properties.
6.7.10.1. Resource Allotment
Updated: 2010-01-19
Resource Allotment is calculated based on the published application importance level and the result of the
XenApp policy engine for that session. The policy engine bases the session result on the session importance
policy setting.
A session’s Resource Allotment determines the level of service it experiences in comparison with other
sessions on the same XenApp server, as well as sessions on other XenApp servers. The higher a session’
s Resource Allotment, the higher service it receives compared with those other sessions.
The figure illustrates a XenApp farm running sessions with different Resource Allotments. It illustrates how
a session’s Resource Allotment affects its competition with other sessions on the same server and on
different servers. Session 1 on Server 2 has a relatively high Resource Allotment compared with all other
sessions in the farm. As a result Session 1 gets the highest percentage of CPU cycles (90%) of any
session running in the farm, and at the same time has to compete with fewer sessions on that server (there
are only two sessions on Server 2, as opposed to three). Any new session would be assigned to Server 1
because it has the lowest Resource Allotment of the three servers.
The session with the highest Resource Allotment gets the highest percentage of CPU cycles of any
sessions running in the farm.
The three application importance settings have Resource Allotment values associated with them, as do the
three session importance policy settings. To determine the effective Resource Allotment associated with a
session running the published application, multiply the application importance value by the session
importance policy value. The most powerful session is one with a high importance policy setting (3) running
a high importance application (3), with a total Resource Allotment of 9 (3x3). Conversely, the least
powerful session is one with a low importance policy setting (1) running a low importance application (1), with
a total Resource Allotment of 1 (1x1).
Use this table to help determine how to set your importance levels for applications and sessions.
Resource Allotments based on importance levels
Application Importance Session Importance (from policy) Session Resource Allotment
Low (1) Low (1) 1
Low (1) Normal (2) 2
Low (1) High (3) 3
Normal (2) Low (1) 2
Normal (2) Normal (2) 4
Normal (2) High (3) 6
High (3) Low (1) 3
High (3) Normal (2) 6
High (3) High (3) 9
6.7.10.2. Multiple Published Applications in the Same Session
Updated: 2010-01-19
Session sharing allows multiple published applications to run in the same session. During session sharing,
the Resource Allotment is calculated based on the maximum application importance level setting of all
the published applications running in the session multiplied by the session importance policy setting.
When an application is launched in an existing session, the importance level of the new application is
compared with the maximum of all current application importance levels. If the importance level of the
new application is greater, the session’s Resource Allotment is recalculated and the session’s CPU
entitlement adjusted upwards. Similarly, when an application is closed, if the maximum importance level of
the remaining applications is lower, the session’s Resource Allotment is recalculated and the session’s
CPU entitlement adjusted downward.
6.7.11. Managing CPU Usage
Updated: 2010-02-16
The CPU utilization management feature can be used to improve the ability of a farm to manage resources
and normalize CPU peaks when the farm’s performance becomes limited by CPU-intensive operations. When
you enable CPU utilization management, the server manages the share of the CPU allocated to each user.
By default, this is an equal share. This prevents one user from impacting the productivity of other users
and allows more users to connect to a server. This feature allows you to control the share.
The CPU utilization management feature ensures that CPU resources are equitably shared among users by
having the server allocate an equal share of the CPU to each user. This is accomplished by providing
CPU reservation and CPU shares.
CPU reservation is a percentage of your server’s CPU resource that is available to a user. If all of
a reserved allocation is not being used, other users or processes can use the available resource, as
needed. Up to 20% of the work capability of a single CPU on a server is always set aside for the
local system account and is not available to users.
CPU shares are percentages of the CPU time. By default, CPU utilization management allocates four
shares for each user. If two users are logged on to a server and the local system account does not
need any of the resources on the system, each user receives 50% of the CPU time. If there are four
users, each user receives 25% of the CPU time.
Important: The range for CPU share is 1 through 64 percent. For CPU reservation, the total cannot be
more than 99%, which represents the entire CPU resource on the computer.
If you enable CPU utilization management, you must disable the Microsoft Dynamic Fair Share Scheduling (DFSS).
Do not enable CPU utilization management on farms or servers that host:
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
1.
2.
1.
2.
3.
4.
CPU restrictions.
To enable CPR utilization management
You can enable CPU utilization management using Citrix policy settings. This feature is not enabled by default.
Important:
The Dynamic Fair Share Scheduling (DFSS) aspect of the Windows Remote Desktop Services role
is incompatible with CPU utilization management. Ensure that DFSS is disabled on each server where
CPU Utilization Management is enabled.
Configure the Citrix policy settings for . Choose one Memory/CPU > CPU management server level
of the following settings:
Select to allocate an equal share of the CPU to each user. Fair sharing of CPU between sessions
Select to allocate shares based on importance levels. Preferential Load Balancing
Continue by applying one or more filters to the policy based on worker groups or organizational units.
6.7.12. Deploying virtual memory optimization
Updated: 2010-02-16
You can enhance system speed, performance, and scalability by improving virtual memory utilization for a
server using the Citrix memory optimization service. The service improves how DLLs are shared
among applications running on the server, saving virtual and real memory. The service changes the location
that individual DLLs are loaded in memory to increase the amount of possible sharing. The process is called
. rebasing
Memory optimization is especially useful when user demand exceeds available RAM and causes farm
performance to degrade. Performance degradation can occur during peak times when users run memory-
intensive applications in multiple sessions.
For a variety of reasons, not all applications can be successfully optimized. You can add those applications
that cannot be optimized to an exclusion list to bypass optimization. You do not want to enable memory
utilization management on farms or servers that exclusively host signed or certified applications because
these cannot be optimized. XenApp can detect only some published applications that are signed or certified.
The memory optimization feature includes the ability to set the schedule for DLL rebasing and to exclude
specific applications from DLL rebasing. Rebasing is composed of two parts: A scanning component that
locates modules that are candidates to be rebased, and a rewriting component that performs the optimization.
If you enable memory optimization, the scanning component runs regularly on the server. However, the
rewriting component runs only when scheduled.
To enable memory optimization
Configure the Citrix policy setting for > to enable the feature. Memory/CPU Memory optimization
Continue by creating a memory optimization schedule for when a server rebases DLLs and, if needed,
an exclusion list of applications that cannot be optimized. To create the list, test the feature on a test server.
To test memory optimization before deployment
Using a test server hosting your published applications, enable memory optimization.
Schedule memory optimization.
After memory optimization completes, run all published applications.
Add to the exclusion list those applications that fail.
To create an exclusion list of applications
Not all applications can be optimized successfully. The process automatically excludes some
applications. However, if published applications fail after enabling and running memory optimization,
exclude those applications from memory optimization by adding them to the exclusion list.
Some types of application that cannot be optimized include:
Applications that reside on network shares (automatically excluded).
Applications that have digitally signed components.
Applications whose DLLs are protected by Windows Rights Management. For example, applications such
as Office 2003 do not benefit from this feature.
Applications whose executable programmatically checks the DLL after it is loaded.
Applications that require a fixed DLL address.
In general, if an application was working, but it stops working after you enable this feature, add the application
to the exclusion list and see if the problem is resolved.
With memory optimization enabled, to exclude additional applications, configure the Citrix policy settings for
> by adding the full path and Memory/CPU Memory optimization application exclusion list
executable name for the application, for example:
C:\\ \ProgramName.exe %Program Files%
where is the full path to the application. %Program Files%
To create a memory optimization schedule
After you enable virtual memory optimization, the server rebases DLLs automatically at server start-up. When
the service rebases, it changes the location that individual DLLs are loaded in memory to increase the amount
of possible sharing.
You can create an additional virtual memory optimization schedule that identifies other times when a
server rebases DLLs for greater operating efficiency. As a best practice, schedule virtual memory optimization at
a time when your servers have their lightest loads.
With memory optimization enabled, configure these Citrix policy settings for : Memory/CPU
. Set the frequency internal to daily (default), weekly, monthly, or Memory optimization interval
only when you restart your server. If you choose to run the program weekly or monthly, specify the day
of the week or month.
(1 by default). Enter the day of the month using Memory optimization schedule: day of month
values 1-31. Note that if the specified day does not occur in a given month, such as day "31" in
June, memory optimization does not run in that month. This setting is used only if you set the interval
to Monthly.
(Sunday by default). Select the day of the week Memory optimization schedule: day of week
that memory optimization runs. This setting is used only if you set the interval to Weekly.
(3:00 AM by default). This setting is used only if you set Memory optimization schedule: time
the interval to Daily, Weekly, or Monthly.
6.7.13. Managing Farm Infrastructure
Updated: 2010-01-18
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 farm’s size and requirements.
Farms comprise at least one or grouping of servers. Multiple zones are sometimes used to improve zone
the performance on geographically segmented farms. Within the zone, there is a , which data collector
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
6.7.13.1. Maintaining the Local Host Cache
Updated: 2010-02-17
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 farm’s 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 server’s local host cache was last updated. If changes were made, the server requests the
changed information.
Refreshing the Local Host Cache
You can force a manual refresh of a server’s local host cache by executing from a dsmaint refreshlhc
command prompt. This action forces the local host cache to read all changes immediately from the farm’s
data store. Refreshing the local host cache is useful, for example, if the Citrix Independent
Management Architecture (IMA) Service is running, but published applications do not appear correctly when
users browse for application sets.
A discrepancy in the local host cache occurs only if the IMA Service on a server misses a change event and is
not synchronized correctly with the data store.
Recreating the Local Host Cache
You can manually create the local host cache from the farm’s data store. If the IMA Service fails to start or
you have a corrupt local host cache, you may need to recreate it.
To recreate the local host cache, stop the IMA Service and then run the command . dsmaint recreatelhc
Running this command performs three actions:
Sets the value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ RUNTIME\PSRequired to 1.
Deletes the existing local host cache (Imalhc.mdb)
Creates an empty local host cache (Imalhc.mdb)
You must restart the IMA Service after running . When the IMA Service starts, the dsmaint recreatelhc
local host cache is populated with fresh data from the data store.
The data store server must be available for to work. If the data store is not available, dsmaint recreatelhc
the IMA Service fails to start.
6.7.13.2. Tuning Local Host Cache Synchronization
Updated: 2010-02-22
You can adjust the interval by which member servers query the farm's data store for missed changes. The
default interval is 30 minutes. In most cases, this default setting is sufficient.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall
your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry
Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
You can configure the interval by creating the following registry key on each server you want to adjust, with
the value expressed in hexadecimal notation:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ DCNChangePollingInterval (DWORD)
Value: 0x1B7740 (default 1,800,000 milliseconds)
You must restart the IMA Service for this setting to take effect.
Most changes made through the Delivery Services 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 (IMA)
Service running on this server performs all reads and write operations to the data store for the console.
If the data store is experiencing high CPU usage when few read or write operations to the data store
are occurring, it is possible that the data store is not powerful enough to manage a query interval of 30
minutes. To determine whether or not the data store query interval is causing the high CPU usage on the
data store, you can set the query interval to a very large number and test CPU usage. If the CPU usage returns
to normal after you set a large query interval, the data store query interval is probably the cause of the high
CPU usage. You can adjust the query interval based on performance testing.
1.
2.
1.
2.
3.
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 farm’s member servers.
6.7.13.3. To configure zones and back-up data collectors
Updated: 2010-05-25
To optimize IMA traffic, after Setup, you can continue creating zones, moving servers between zones,
and renaming zones. For design considerations for zones, including whether to create zones for small groups
of remote servers, see the topics . Designing a XenApp Deployment
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. Do not install XenApp
on a domain controller. Citrix does not support installing XenApp on a domain controller.
From the Delivery Services Console, select the farm.
Expand the server node and select to view the existing zones for the farm. Zones
To create new zones
To create or modify zones, on the menu, under , click to open the wizard. Follow Actions Zones New
the instructions to name the zone, select servers.
On the , click and select the ranking for the server Set server's election preferences page Edit
by choosing from the following election options:
. The server is always the first choice to become the data collector. It Most Preferred
is recommended that only one server per zone be given this setting.
. When electing a new data collector, XenApp elects the next collector from the Preferred
Preferred servers if the Most Preferred server is not available.
. The default setting for all servers. The next collector is selected from Default Preference
the Default servers if neither a Most Preferred server nor a Preferred server is available.
. Apply this setting to servers that you do not want to become the data collector Not Preferred
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).
Restart the servers to apply the changes.
Zones are listed in the middle pane according to their election preference.
Also from the pane, select the option to move the selected server Actions Set server's zone membership
to another zone, or select the option to move the selected server Change server's zone membership
to another zone.
6.7.14. Updating Citrix License Server Settings
Updated: 2010-02-17
XenApp servers must point to the license server where license files are stored. The license server settings
include the name of the license server that your farm accesses to check out licenses and the port number
the license server uses to communicate.
1.
2.
3.
You can set the license server settings with the XenApp Server Configuration tool when creating or joining a
farm, or you can change the settings through a Citrix policy by specifying the name of the license server or
port number that the license server uses to communicate in the section of the policy and apply Licensing
the policy through filters.
You may want to change these settings in the following instances:
You rename your license server.
You want to point to a second license server to relieve some of the traffic to the first license server.
For example, you have many connections and you find that it is slowing down the network, or you
would like to add a second license server to the farm and point half of the connections to it.
You want to specify another license server to point to individual servers to segregate licenses. For
example, you want to host the accounting department’s licenses on a server other than the
human resources department.
The default port number (27000) is already in use.
You have a firewall between the license server and the computers running your Citrix products, and
you must specify a static Citrix vendor daemon port number.
To change the name of the license server or port number that it uses to communicate, configure the Citrix
policy for by setting the following options: Licensing
Enter the of the server hosting XenApp licenses. License server host name
Enter the number (default 27000). License server port
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 server’s host name, if you change the
license server name, you must download a license file that is generated for the new license server. This
may involve returning and reallocating the licenses. To return and reallocate your licenses, go to www.
. mycitrix.com
If you change the port number, specify the new number in all license files on the server.
For additional information, see . Technologies > Licensing Your Product
6.7.15. To set the product edition
Updated: 2010-02-12
The product editions of XenApp support different features. To activate the features available with a
particular edition installed on each server, set the product edition on each server through Citrix policies.
The product edition also determines which type of license a server requests from the license server. Make
sure the edition you set match the licenses you installed.
Locate the Citrix policies for , and configure the setting. Server Settings XenApp product edition
Create a filter to apply the policy to specific worker groups.
To apply the change, you must restart each server affected by the policy.
6.7.16. Configuring the Citrix XML Service Port and Trust
Updated: 2010-02-18
The Citrix XML Service is used by user devices connecting over the TCP/IP+HTTP protocol and the Web Interface.
By default, XenApp server role installation configures the Citrix XML Service and Internet Information
Service (IIS) to share the same TCP/IPport (80) for communications. In this case, you cannot change the
XML Service setting.
During the installation of Citrix XenApp on your server, you configured the XML Service to either share the
port with your Microsoft Internet Information Server or to use a particular port. For details about the XenApp
and Web Server (IIS) server roles, refer to the . System Requirements for XenApp for Windows Server 2008 R2
1.
2.
1.
2.
1.
2.
If you specified a custom XML Service port during installation, you can change the XML port number if necessary.
Note: The port option appears only if you entered a different port number than the default Share with IIS
during the Web Interface installation. Use the policy setting to change the port number. XML Service
To change the XML service port
Locate Citrix policy setting for . XML Service
Configure the setting. Citrix recommends using port 8080. XML service port
To enable XenApp to trust requests sent to the XML Service
The trust setting is needed only for Smooth Roaming when users authenticate using pass-through or smart-
card authentication with Web Interface, or for smart-card authentication with the online plug-in. Trust is
not required for explicit authentication.
Locate Citrix policy setting for . XML Service
Configure the setting (disabled by default). Trust XML requests
If you do not trust XML requests, certain features of XenApp are not available. Trusting requests sent to the
XML Service means:
Smooth Roaming works when connecting with the Web Interface using pass-through or smart
card authentication, and when connecting with the online plug-in using smart card authentication or
the Kerberos pass-through option.
For example, you can use workspace control to assist health-care workers in a hospital using smart
cards, who need to move quickly among workstations and be able to pick up where they left off
in published applications.
XenApp can use the information passed on from Access Gateway (Version 4.0 or later) to
control application access and session policies. This information includes Access Gateway filters that can
be used to control access to published applications and to set XenApp session policies. If you do not
trust requests sent to the XML Service, this additional information is ignored.
Before enabling the Citrix XML Service to trust requests it receives, use IPSec, firewalls, or another technology
to ensure that only trusted services communicate with the Citrix XML Service.
To avoid security risks, enable the setting only under the following conditions:
Some users connecting to their sessions using the Web Interface are also using pass-
through authentication or smart cards.
The same users need to move from one client device to another and still be able to pick up where they
left off in published applications.
You implemented IPSec, firewalls, or any technology that ensures that only trusted services
communicate with the XML Service.
You are selecting this setting only on servers that are contacted by the Web Interface.
You are restricting access to the XML Service to the servers running the Web Interface. When
Internet Information Services (IIS) and the XML Service share a port, you can use IIS to restrict
port access to include the IP addresses of servers running the Web Interface only.
6.7.16.1. To manually change the XML Service port to use a port different from IIS after installation
Updated: 2010-02-05
Note: This setting takes effect only after the XML Service restarts.
The XML Service port set using a Group Policy Object takes precedence over the port you set using the
command-line in this method.
At a command prompt, stop IIS by typing: net stop w3svc
Delete the following files from the IIS scripts directory on your Web server:
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
ctxadmin.dll
CtxConfProxy.dll
ctxsta.dll
radexml.dll
wpnbr.dll
The XML Service no longer shares a At a command prompt, restart IIS by typing: net start w3svc
port with IIS.
To ensure the XML Service is stopped, at a command prompt, type: net stop ctxhttp
At a command prompt, to unload the XML Service from memory, type: ctxxmlss /u
where is the number of the port you want to use; To install the XML service, type: ctxxmlss /rnn nn
for example, forces the Citrix XML Service to use TCP/IP port 88. ctxxmlss /r88
At a command prompt, start the XML Service by typing: net start ctxhttp
6.7.16.2. To manually configure Citrix XML Service to share the TCP port with IIS
Updated: 2011-03-01
You must have Administrator priviledges to configure the Citrix XML Service.
At a command prompt, stop the XML Service by typing: net stop ctxhttp
At a command prompt, to unregister the Citrix XML Service, type: ctxxmlss /u
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 (x86)\Citrix\System32 during XenApp installation. The
default scripts directory is \Inetpub\AdminScripts.
In the IIS scripts directory, create a folder called ctxadmin and copy the file ctxadmin.dll from
\Program Files (x86)\Citrix\System32 to \Inetpub\AdminScripts\ctxadmin.
Use Internet Service Manager to give the files read and write access.
This setting takes effect At a command prompt, stop and restart the Web server by typing: iisreset
after the Web server restarts.
6.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:
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).
Configure your printing environment, including creating the policies necessary to deploy your
printing design.
Test a pilot printing deployment before rolling it out to users.
Maintain your Citrix printing environment, including updating policies when new employees or servers
are added and maintaining drivers on your farm servers.
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.
6.8.1. Introduction to Windows Printing Concepts
Updated: 2010-06-07
This section provides a limited overview of basic printing concepts in a standard (non-Remote Desktop
Services) Windows environment. However, Citrix recommends reviewing the Windows documentation
about network printing, print servers, and Remote Desktop Services printing before learning about Citrix
printing concepts.
In a Windows environment, you can either print from your computer to a locally attached desktop printer
(for example, a printer on LPT1 or COM1) or you can print to a that is managed by a . network printer 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 refers to the physical printer (that is, the printing device
hardware device to which you send print jobs).
Printers
The term refers to the software representation of a printing device. Computers must printer
store information about printers so they can find and interact with printing devices. When you see
1.
2.
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 is sometimes used to denote the software representation of a printer object
printing device.
Printer driver
The is the software program that lets the computer communicate with this hardware printer driver
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 . Jobs are queued to print job
the printer in a specific sequence, which the controls. When this sequence appears, it print spooler
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 refers to dedicated computers that are running a Windows server operating print server
system and hosting number of shared printers. Print servers provide client workstations with drivers x
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.
6.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 , the local Windows computer processes the job. The application creates locally
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:
The application tells the local spooler to create a print job and an associated spool file on the
local computer.
On the local computer, Windows writes the application’s drawing commands to the local spool file.
This process of writing commands occurs repeatedly until the job is completely spooled.
3.
4.
1.
2.
3.
4.
The local spooler processes the job with the printer driver in a process known as . rendering
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 , the Windows print server processes the print job. remotely
A typical printing process for remotely spooled print jobs is
The application tells the remote spooler to create a print job on the print server and an associated spool file.
On the local computer, Windows writes the application’s drawing commands to the remote spool file.
This process of writing commands across the network occurs repeatedly until the job is completely spooled.
The remote spooler processes the job with the printer driver in a process known as . rendering
The print server delivers the rendered data to the printing device (typically a network printer).
Key Differences Between Remote and Local Spooling
Unlike remote spooling, local spooling does not use any network resources. Remote spooling requires that
the local computer and the remote printer exchange many messages across the network. Even in a non-
Citrix environment, if a WAN has substantial latency, users will have a poor user experience if the print jobs
are spooled remotely across the WAN.
However, in some situations, for example when the resources on the local computer are needed for other
tasks, remote spooling is preferable. In remote spooling, the print job is processed on the print server, which
off-loads processing from the local computer.
6.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 user’s 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 , XenApp: Print
Determines what printers (that is, printer objects) to provide to the user. This is known as
. printer provisioning
Restores the user’s 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 , the types of printer provisioning (static and dynamic), printer printer provisioning
autocreation, and user self-provisioning
Print job routing and when changing it can improve utilization
The basics of printer driver management
6.8.2.1. Overview of Client and Network Printing Pathways
1.
2.
3.
4.
Updated: 2010-03-08
An important concept in XenApp is the printing pathway. The term encompasses both the printing pathway
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 refers to print jobs that are routed from the farm server hosting the user’ network printing pathway
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:
The application tells the remote spooler to create a print job and an associated spool file.
The Windows Print Provider sends the spool file to the print server.
The print server processes the spool file.
The print server then sends the print job to the appropriate network printer.
Server Local Printers
The term refers to a configuration that uses the network printing pathway where server local printers
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.
1.
2.
3.
4.
5.
Client Printing Pathway
The term refers to print jobs that are routed over the ICA protocol through the client printing pathway
client device to the printer (either a printer connected directly to the client device or connected through a
print server) and spooled on the Citrix online plug-in.
When using the client printing pathway, a virtual printer is constructed in the session that redirects to the
printer object on the client device. The client device, in turn, sends the print job to the printing device.
Importantly, because all processing occurs on the XenApp server, when users print a document from a
published application, they are actually starting that print job on the XenApp server. These jobs are
spooled locally on the XenApp server.
There are two different configurations of the client printing pathway: one for printers attached directly to
the client device and another for network printers.
Locally Attached Client Printers
The simplest configuration is the one where the printer is attached directly to the client device. In
this configuration, the application server sends the print job back to the client/client device. The client device
then relays it to a locally attached printer.
This diagram shows a simplified XenApp client printing example: Printing begins on the server where
the application is published. XenApp sends the print job over the connection to the client device. The client
device then routes the print job to the printer connected locally to the client device.
When a print job is spooled to a client along the client printing pathway, it uses this process:
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.
On the host server, Windows writes the application’s drawing commands to the local spool file.
(This process of writing commands occurs repeatedly until the job is completely spooled.)
The local spooler processes the job with the printer driver in a process known as . rendering
The rendered data is delivered to the client device through the ICA protocol.
5.
1.
2.
3.
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:
The application server sends the print job to the client for processing.
The client processes the spooled job and sends it to the Windows print server for processing.
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 server’s
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.
6.8.2.2. Provisioning Printers for Sessions
Updated: 2010-03-18
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.
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 wizard on the server Add Printer
(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 refers to printers XenApp creates automatically, at the beginning of each session, based autocreation
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.
6.8.2.2.1. Auto-Creating Client Printers
Updated: 2010-03-18
The autocreation feature creates a list of printers that a user can use after logging on. When the user logs
in, their print drivers will be installed and all printers returned in this list will be available for use.
XenApp can auto-create redirected client printers in two different ways:
By creating a one-to-one match with printers on the client device
By creating one generic printer, the Citrix Universal Printer, that represents all (or any) printers on
the client device
In many environments, especially large ones, Citrix recommends that you auto-create only one default
printer. Auto-creating a smaller number of printers creates less overhead on the server and is better for
CPU utilization.
However, in environments where users with limited computer skills need to print to a wide variety of local
printing devices, you may want to leave the default autocreation setting so that all printers are created on logon.
If you do not want large numbers of printers created at the beginning of each session, consider specifying
for XenApp to use the Citrix Universal Printer.
Auto-Creating Printers from the Client Device
At the start of a session, XenApp auto-creates all printers on the client device by default. You can control what,
if any, types of printers are provisioned to users and prevent autocreation entirely.
The Citrix policy setting lets you control autocreation and specify that: Auto-create client printers
All printers visible to the client device, including network and locally attached printers, are
created automatically at the start of each session
All non-network printers physically attached to the client device are created automatically
Only the default printer for the client device is created automatically
No printers visible to the client device are created automatically
When configuring policies for printer autocreation, ensure:
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 online plug-
in or the Citrix offline plug-in.
The Citrix Universal Printer does not work if plug-ins are not connecting through the ICA channel, such
as when you are using the Citrix offline plug-in and streaming applications to the client.
If you want to use a universal printing solution for non-Windows plug-ins, use one of the other
universal printer drivers that are based on postscript/PCL and installed automatically with XenApp.
The Citrix Universal printer driver might also create smaller print jobs than older or less advanced
printer drivers. However, sometimes it might be better to use a device-specific driver because the
driver might be able to optimize print jobs for its associated printer.
Note: If you want the Citrix Universal Printer to appear in sessions, make sure that the Citrix policy setting
is not set to in any policies affecting those sessions. Client printer names Legacy printer names
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. or Version 10. x x
, Citrix XenApp Plugin for Hosted Apps 11.0, the Citrix online plug-in, the Citrix XenApp Plug-in for
Streamed Apps, and the Citrix offline plug-in. This feature is available in Presentation Server 4.0 to XenApp 6.
Citrix Universal Printer
The Citrix Universal Printer is a generic printer created at the beginning of sessions that can be used with
almost any printing device. This printer can print to and communicate, through the client, with any client-
side printer.
You may also want to use the Citrix Universal Printer because the printer name does not change when
users reconnect. Changing printer names can cause problems for some applications.
The Citrix Universal Printer is created on a per-session basis. When used with a Citrix Universal Printer driver,
it can greatly reduce the resource usage at the start of a session from printer autocreation. When you use
the Universal Printer, you can specify that only the Universal Printer be auto-created for each printer on the
client device.
When the Citrix Universal Printer is enabled, an extra printer is created in the session with the name
. To use only the Citrix Universal Printer in sessions Citrix UNIVERSAL Printer in session number of session
and not auto-create any printers on the client device, enable the Universal Printer through the registry
and configure the Citrix policy setting to . Auto-create client printers Do not auto-create client printers
The user experience varies depending on the type of Citrix Universal Printer.
Because the Citrix Universal Printer is not tied to a specific printing device, both the EMF-based and XPS-
based Citrix Universal Printers provide ways to preview and select settings:
EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display a Print
Previewer before printing. Clicking in the Citrix Print Previewer is the only way users Local Settings
can select a different printer, control the device settings for the printer hardware, and preview the
print job. You control whether or not the button is available to users. If you do not Local Settings
allow users to change their printer through the button, the Citrix Universal Printer prints Local Settings
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 Microsoft’s XPS “electronic paper” format.
Note: The Print Previewer cannot be controlled by the administrator unless users have the Citrix
Presentation Server Client, Version 10.100 or later, the Citrix XenApp Plug-in for Hosted Apps, Version 11 , x
or the Citrix online plug-in.
6.8.2.2.2. Auto-Creating Network Printers
Updated: 2010-03-18
By default, any network printing devices on the client device are created automatically at the beginning
of sessions. However, if possible, XenApp always tries to route jobs directly from XenApp to the print server
and not through the client connection.
To specify that specific printers are created in sessions rather than auto-create all the network printing
devices available from the client device, configure the Citrix policy setting . Session printers
Network printers created with the setting can vary according to conditions where the Session printers
session was initiated, such as location (by filtering on objects such as subnets).
Note: For printers in domains that do not have a trust relationship with the XenApp farm, disable the
Citrix policy setting . When this setting is disabled, print jobs are Direct connections to print servers
routed through the client using the client printing pathway.
6.8.2.2.3. Letting Users Provision Their Own Printers
Updated: 2010-03-18
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 because they are retained printers
created again (or remembered) at the start of the next session. When XenApp recreates a retained printer at
the start of a session, it considers all Citrix policy settings except . Auto-create client printers
Retained printers appear in sessions on that device until the client printer within the session is deleted
manually, the remembered printer connection is removed from the client’s properties store, or the client-
side printer is inaccessible.
Users might need to use the PrintCfg.exe tool to add printers if they cannot browse to the printer from within
the session or cannot access their client desktop. If they use this tool, the printers are routed along the
client printing pathway.
6.8.2.3. Device or Session-Based Print Settings
Updated: 2010-03-18
By default, all changes users make to the printer device settings and preferences, whether in a session or
working on their local computer, are saved and used locally and in a session. This means that printer settings
and preferences are always the same on the client device and in a session. Citrix policy settings let you
change the way XenApp software saves and applies printer device settings and preferences.
You can configure sessions to obtain print settings, specifically user printing preferences, from either the
printer object or the printing device.
XenApp can write printer settings to the printer object at the end of a session or to a client printing
device, provided the user’s network account has sufficient permissions. By default, XenApp plug-ins use
the settings stored in the printer object in the session, before looking in other locations for settings
and preferences.
The main reason you want sessions to obtain their print settings from the printing device is if Windows
users make changes to local printers outside of sessions (that is, on their local computer offline). Non-
Windows plug-ins synchronize changes made out of sessions automatically.
6.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
your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry
Editor can be solved. Use Registry Editor at your own risk.
If you have Windows users with locally attached printers who work on applications locally and on the server,
you might want to retain changes to the printer settings the users make locally outside of a session. To do
so, create and set the Win32FavorRetainedPrinterSettings registry key to False, as described in To
. synchronize properties from the printer
When the registry key is modified, the plug-in gives priority to settings from the printer, rather than
retained settings. Settings in the session stay synchronized with settings on the printing device. If a change
was made to the printer out of a session, the change is picked up. If a change is made to the printer inside
the session, the plug-in attempts to write the change back to the printer on the client device when logging off.
You must have the same driver on the client device and server. If you do not, only a subset of settings
is exchanged between the real printer and the virtual printer in the session. Some device independent
settings are inherited and others are not.
6.8.2.3.2. Controlling Printing Settings and User Preferences
Updated: 2010-02-02
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
the Control Panel and selecting . For example, if is selected as Printing Preferences Landscape
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
1.
2.
3.
page orientation, are often stored inside documents. These settings are often referred to as
. For example, when you queue a document to print, Microsoft Word typically stores Document Settings
the printing preferences you specified, such as page orientation and the printer name, inside
the document. These settings appear by default the next time you print that document.
From changes a user made during a session. XenApp keeps only changes to the printing settings of
an auto-created printer if the change was made in the the Control Panel in the session; that is, on
the server.
On the server. These are the default settings associated with a particular printer driver on the server.
If you want to control user printing preferences, it is important to understand that the settings preserved in
any Windows-based environment vary according to where the user made the changes. This also means that
the printing settings that appear in one place, such as in a spreadsheet program, can be different than those
in others, such as documents. As result, printing settings applied to a specific printer can change throughout
a session.
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:
XenApp checks for retained printer settings.
If XenApp finds retained settings, it applies these settings when the user prints.
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.
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 user’s 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. and higher to store user-modified x
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 user’s 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 user’s 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 user’s 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.
6.8.2.4. Setting Default Printers
Updated: 2010-03-18
The printer that XenApp selects for a session’s 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 Citrix policy setting Default printer
. See for details. To specify a default printer for a session
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.
6.8.2.5. Printing and Mobile Workers
Updated: 2010-03-18
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 Citrix policy setting . Default printer
Proximity Printing can make administration easier even if you do not have mobile workers. For example, if a
user moves from one department or floor to another, you do not need to assign additional printers to that user
if Proximity Printing is implemented. When the workstation is recognized within the new location’s 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 workstation’s location
Your network’s IP addresses, if they correlate with user locations
6.8.2.6. Optimizing Printing Performance by Routing
Updated: 2010-03-10
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 plug-in. This is accomplished by auto-creating the network printer but specifying its jobs
to route through the plug-in.
Over the network. This is accomplished either by leaving the default settings so that the network
printer is auto-created (or configuring a policy to do this) or by provisioning the network printer
through the Session printers policy rule.
Routing jobs along the network printing pathway is ideal for fast local networks and when you want users to
have the same user experience that they have on their local client device (that is, when you want the
printer names to appear the same in every session).
However, print jobs relayed using the network printing pathway are not suited to WANs. The spooling of print
jobs using the network printing pathway method uses more bandwidth than using the client pathway;
many packets are exchanged between the host server and the print server. Consequently, users might
experience latency while the print jobs are spooling over the WAN. Also, the print job traffic from the server
to the print server is not compressed and is treated as regular network traffic.
When printing jobs across a network with limited bandwidth, Citrix recommends routing jobs through the
client device so that the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting
. Direct connections to print servers
6.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 accessible on the client device. The printer driver on the client device relays the print job to the print spooler on the client device, which in turn routes the print job to the local printer.
The printer driver on the server and the driver used by the client device must match exactly. If not, printing
fails. As a result, XenApp provides features to manage drivers, install them automatically, and replicate
them across your farm.
The following problems can arise from not managing client printer drivers correctly:
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 user’s 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
6.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 (user’s 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.
6.8.3.1. Default Printing Behavior
Updated: 2010-03-10
By default, if you do not configure any policy rules, XenApp printing behavior is as follows:
All printers configured on the client device are created automatically at the beginning of each session.
This behavior is equivalent to configuring the Citrix policy setting with the Auto-create client printers
option. Auto-create all client printers
XenApp routes all print jobs queued to printers locally attached to client devices as client print jobs (that
is, over the ICA channel and through the client device).
XenApp routes all print jobs queued to network printers directly from the server hosting the
published application. If XenApp cannot route the jobs over the network, it will route them through
the client device as a redirected client print job. This behavior is equivalent to disabling the Citrix
policy setting . Direct connection to print servers
XenApp retains all properties and settings users configure for printers they provision themselves
in sessions. XenApp stores printing properties on the client device. If the client device does not support
this operation, XenApp stores printing properties in the user profile for that user. This behavior
is equivalent to configuring the Citrix policy setting with the Printer properties retention Held in
option. profile only if not saved on client
XenApp uses the Windows version of the printer driver if it is available on the server hosting
the application. If the printer driver is not available, the XenApp server attempts to install the driver
from the Windows operating system. If the driver is not available in Windows, it uses one of the
Citrix Universal printer drivers. This behavior is equivalent to enabling the Citrix policy setting
and configuring the setting Automatic installation of in-box printer drivers Universal printing
with the . Use universal printing only if requested driver is unavailable
Note: If you are unsure about what the shipping defaults are for printing, display them by creating a
new policy and setting all printing policy rules to Enabled. The option that appears is the default.
6.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
for configuration details. Maintaining XenApp Printing
6.8.3.3. Printing Security
Updated: 2010-07-13
Client printing can, potentially, let a user from one session use another user’s 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 user’s 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
Processes running in the SYSTEM account such as the spooler
Processes running in the user’s 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.
6.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 printers use the processor on the host computer to generate print jobs; they host-based printer
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
6.9. Configuring and Maintaining XenApp Printing
Updated: 2010-03-19
Most XenApp printing functions are configured through the following Citrix policy categories and settings:
Client printers. The settings in this category affect the client redirected printers and printing using
the client printing pathway.
Drivers. The settings in this category control driver management.
Printer redirection bandwidth limit. This setting restricts the bandwidth allocated to printers.
Session printers. This setting configures how network printers are provisioned.
If you do not enable any settings that affect printing, XenApp uses the default printing behavior that is
described in . Planning Your Printing Configuration
Printing settings follow standard Citrix policy behavior:
Printing settings are evaluated during initial logon and remain in force throughout the session. Any
new printers added to a policy or a user device during a session do not appear in the session until the
user logs off and logs on, creating a new session.
The policies are filtered on standard objects that apply to all Citrix policy settings. Therefore,
when configuring printing settings, determine which filter objects best achieve your goals. Filtering
on Client Device Name is useful if you are trying to configure proximity printing. Filtering on Client
IP address is useful when associating network printers with specific workstations.
Policy prioritization
All printing policy settings follow standard XenApp prioritization. Citrix policies always take precedence
over Windows policies in a XenApp environment.
Policy maintenance
Changes in your network often result in the need to update printing policy configurations. For example,
users changing departments or workstation locations require that you update the printing policies associated
with that user. Adding or removing printers from your network require that you update any configured
Session printers policy settings.
6.9.1. Configuring Printer Autocreation Settings
Updated: 2010-03-18
Configure the Citrix policy setting to control how or if printers are Auto-create client printers
created automatically at the start of sessions. By default, this setting is not enabled, so XenApp creates
all printers on the user device.
To modify printer auto-creation behavior
Configure one of the following in the setting: Auto-create client printers
Client printers are not auto-created. Do not auto-create client printers.
Only the client’s default printer attached to or Auto-create the client’s default printer only.
mapped from the client preconfigured in the is auto-created in the session. Control Panel
Any non-network printers attached to the Auto-create local (non-network) client printers only.
client device preconfigured in the are auto-created in the session. Control Panel
All network printers and any printers attached to or mapped from Auto-create all client printers.
the user device preconfigured in the are auto-created in the session. Control Panel
To configure legacy client printer support
To auto-create client printers with legacy printer names and preserve backward compatibility for users or
groups using MetaFrame 3.0 or earlier, choose the option from the Citrix policy Legacy printer names
setting. Client printer names
6.9.2. Configuring Citrix Universal Printing
Updated: 2010-03-18
There are several different Universal Printing solutions. You can configure:
Citrix XPS Universal Printer driver
Citrix Universal Printer driver, which is EMF-based
Auto-created Citrix Universal Printer with a Citrix Universal printer driver
Configuring only a Universal printer driver will not improve session start time (printers on the client device
are still enumerated and auto-created at the beginning of sessions). However, configuring a Universal
printer driver does improve printer driver performance.
To configure universal printing
1.
2.
1.
2.
Configure the Citrix policy setting by using the following settings: Universal Printing
Enables or disables the auto-creation of the Citrix Auto-create generic universal printer.
Universal Printer generic printing object. By default, generic universal printers are not auto-created.
Specifies the order in which XenApp attempts to use universal printer Universal driver priority.
drivers, beginning with the first entry in the list. You can add, edit, or remove drivers and change the
order of the drivers in the list.
Specifies when to use universal printing. Universal printing.
Specifies whether to use the print preview function for Universal printing preview preference.
auto-created or generic universal printers.
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.
For more information, see . Configuring Universal Printer Drivers on Farm Servers
6.9.3. Configuring Network Printers for Users
Updated: 2010-03-05
If automatic printer creation fails for network printers on a client device or for session printers because
the corresponding drivers are not installed automatically by Windows (because you configured a policy
setting preventing auto-installation or they are third-party drivers), you must add the corresponding drivers
to your farm servers manually.
Add printers to the XenApp server by manually installing the printers. You can use the Add Printer
wizard in Windows or browse to the server on which the printer is installed and double click the
printer, which forces Windows to place the drivers in its local driver store.
Delete the printers. Deleting the printers ensures that they are created only when intended; that is, only
if the client has that network printer installed or the GPO with configured uses Session printers
filtering and applies to only a subset of all users of the XenApp server.
6.9.3.1. To add a network printer while configuring the Session printers setting
Updated: 2010-03-01
In the Citrix policy setting for , add a network printer using one of the following methods: Session printers
Enter the path using the format \\servername\printername. Printer UNC path.
Locate a printer on the network. Browse.
Enter the server name using the format \\servername Browse for printers on a specific server.
and click . Browse
Important: The server merges all enabled session printer settings for all applied policies, starting from
the highest to lowest priorities. When a printer is configured in multiple policy objects, custom default
settings are taken from only the highest priority policy object in which that printer is configured.
6.9.3.2. To specify a default printer for a session
Updated: 2010-04-23
To specify a network printer, it must already be added to the policy in which you are enabling the Citrix
policy setting . Default printer
Complete the procedure, . To add a network printer while configuring the Session printers setting
On the settings page, from the drop-down list, Default printer Choose client’s default printer
choose one of the following:
2.
3.
1.
2.
3.
4.
5.
1.
2.
Name of the network printer you want to be default for this policy. Printers that were added with the
policy setting are displayed in this drop-down menu and can be specified as Session printers
the default printer.
Set default printer to the client’s main printer. Sets the default printer for the session to
the client’s current default printer. If the client's main printer is not mapped, this option has
no effect.
Important: Mapping for the client’s main printer can also be disabled through other
policies, group policies, or Remote Desktop Services settings.
Do not adjust the user’s default printer. Uses the current Remote Desktop Services or
Windows user profile setting for the default printer. If you choose this option, the default printer
is not saved in the profile and it does not change according to other session or client properties.
You can use this option to present users with the nearest printer through profile
settings (functionality known as Proximity Printing).
When is selected, the default printer in a session will Do not adjust the user’s default printer
be the first printer autocreated in the session, which is either:
The first printer added locally to the Windows server in the Control Panel
The first autocreated printer, if there are no printers added locally to the server
Apply the policy to the group of users (or other filtered objects) you want to affect.
6.9.3.3. To edit the printer settings in the sessions policy
Updated: 2010-01-25
On the settings page, select the name of the printer for which you want to modify Session printers
the settings.
Click . Settings
Check . Apply customized settings
Change the settings for , , , and . Paper Size Copy Count Print Quality Orientation
To ensure that the settings you specify here are restored in concurrent sessions even if users modify
them in their initial session, select the check box. Apply customized settings at every logon
This check box applies to additional sessions opened while the user’s 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 as a custom Orientation setting, the check box is selected, a Landscape
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 , XenApp carries the user’s Apply customized settings at every logon
changes into Session2 so the Orientation is Portrait.
After clicking , the value in the list of printers on page changes to . OK Settings Session printers Modified
6.9.3.4. To configure server local printers
Updated: 2010-02-25
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:
On the server where the printer is physically connected, in Control Panel > Hardware > Devices
, right-click the printer you want to share. and Printers
2.
3.
1.
2.
3.
4.
Choose . Printer Properties
In the tab, select these check boxes: Sharing
Share this printer
Render print jobs on client computers
Sharing the printer allows creation of the printer when a session on that server is launched.
6.9.4. Configuring Printers for Mobile Workers
Updated: 2010-02-18
When you want to make sure that users always see the closest printer to their client device in a
session, configure the Proximity printing solution. Proximity printing enables users within a specified IP
address range to automatically access the network printing devices that exist within that same range.
The ability to configure proximity printing assumes that your network is designed as follows:
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
Create a separate policy for each subnet (or to correspond with printer location).
In each policy, add the printers in that subnet’s geographic location to the setting. Session printers
Set the setting to Default printer Do not adjust the user's default printer.
Filter the policies by Client IP address.
6.9.5. Changing Network Print Job Routing
Updated: 2010-02-05
By default, XenApp routes jobs to network printers from the application server directly to the print server
(along the network printing pathway).
Note: Print jobs sent over the network printing pathway are not compressed. When routing printing jobs
across a network with limited bandwidth, Citrix recommends routing jobs through the client device so that
the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting Direct connection to
. print servers
6.9.6. Providing Tools for User Provisioning
Updated: 2009-11-20
The following groups of users cannot add printers to sessions unless you publish printer provisioning tools
for them:
Windows users who do not have access to the Add Printer wizard on the local client device or
any applications that let them browse to printers
Non-Windows plug-in users
If you want these users to add printers on their own, publish either:
The ICA Client Printer Configuration Tool (PrintCfg.exe). This tool lets Windows CE and DOS users
add printers.
The Add Printer wizard. Publishing this Windows wizard lets users with Windows plug-ins add printers
that are on the local client device or network. Publishing this wizard is also referred to sometimes
as publishing the Print Manager.
1.
2.
1.
2.
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.
Create the following folder at the root level of one of the XenApp server’s drives: :\Printers. C
{2227A280-3AEA-1069-A2DE-08002B30309D} where represents a drive on the XenApp server. C
When you press , the folder icon changes to a printer icon. Enter
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
Follow the instructions for publishing an application in To publish a resource using the Publish
. Application wizard
On the page, enter the path for the ICA Client Printer Configuration tool (printcfg.exe) on Location
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.
6.9.7. To store users’ printer properties
Updated: 2010-06-07
To store user printer properties, configure the Citrix policy setting by Printer properties retention
choosing from the following settings:
. Selected by default. Allows the system to determine Held in profile only if not saved on client
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 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 plug-ins and is not constrained by bandwidth or logon performance.
. Stores printer properties only on the client device. If users Saved on the client device only
are assigned a Remote Desktop Services mandatory profile or roaming profile, select this option.
. Stores printer properties in the user profile on the server and Retained in user profile only
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 plug-ins. Use this option with MetaFrame Presentation Server 3.0 or earlier and
MetaFrame Presentation Server Client 8. or earlier. Note that this is applicable only if a Remote x
Desktop Services roaming profile is used.
. Does not retain printer properties. Do not retain printer properties
6.9.8. To synchronize properties from the printer
To obtain printer properties directly from the printer itself, rather than from the properties store, use the
1.
2.
3.
following procedure. This procedure ensures that changes made offline to printers on the local computer are
used next time a user starts a session.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall
your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry
Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
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
Create the following registry key: Name:Win32FavorRetainedPrinterSettings Data Type: REG_SZ
Value Data: false
Restart the Citrix Print Manager Service.
6.9.9. Controlling Printer Driver Automatic Installation
Updated: 2010-03-18
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 Citrix policy setting Automatic
. installation of in-box printer drivers
To specify how client printer drivers are installed on XenApp servers
To specify how client printer drivers are installed on the XenApp servers, configure the following Citrix
policy settings:
. Controls whether Windows native drivers Automatic installation of in-box printer drivers
are automatically installed when auto-creating either a client or network printer. Disabling this
setting prevents the automatic installation of printer drivers.
. Lists driver substitution settings for auto-created Printer driver mapping and compatibility
printers. Allows or prevents printers to be created with the specified driver. Additionally, you can
allow created printers to use only universal printer drivers.
To control the automatic installation of printer drivers
Configure the Citrix policy setting (enabled by default). Automatic installation of in-box printer drivers
This setting allows XenApp to install Windows native printer drivers (those present in driver.cab)
automatically when auto-creating either a client or network printer.
Caution: Enabling this option might result in the installation of a large number of native drivers.
To add or remove drivers or edit driver names in the compatibility list
Configure the Citrix policy setting to specify whether printers can Printer driver mapping and compatibility
be created with specific drivers or not or with universal printer drivers. You can use this setting to add a
driver mapping, edit an existing mapping, remove a mapping, or change the order of driver entries in the list.
You can turn the setting into a whitelist by specifying only Printer driver mapping and compatibility
the allowed drivers, adding an additional entry using a wildcard * for the driver name, and specifying Do
for all drivers other than those specified. Alternatively, you can use the not create Create with
option in the setting to allow only universal drivers for drivers that are not universal driver only
explicitly specified.
6.9.10. Configuring Universal Printer Drivers on Farm Servers
Updated: 2010-02-24
If you configure a Universal printer driver for sessions, by default, XenApp always uses the Citrix Universal
(EMF) Printer driver, when it is available. If it is not available, XenApp uses the XPS Universal Printer driver.
The XPS Universal printer driver can be configured as the default by configuring the Citrix policy setting
. Universal driver priority
The Citrix Universal printer drivers are listed in the Print Management MMC snap-in. Provided all prerequisites
for the driver were installed when you ran XenApp Setup, the following drivers appear:
Citrix Universal Printer, which is the .EMF driver
Citrix XPS Universal Printer
HP Color LaserJet 2800 PS (Citrix PS Universal Printer Driver)
If you need a Universal driver that does not appear in this list, you must install it.
To specify the Universal Printer driver for sessions
Configure the Citrix policy setting by choosing one of the following: Universal printing
. Specifies that the client printer uses only the native Use only printer model specific drivers
drivers that are autocreated at logon. If the native driver of the printer is unavailable, the client
printer cannot be autocreated.
. Specifies that the client printer uses the universal printer driver Use universal printing only
only. Select this option if you do not want to use native drivers.
Uses native drivers for client Use universal printing only if requested driver is unavailable.
printers if they are available. If the driver is not available on the server, the client printer is
created automatically with the highest available universal driver, as specified in the Universal
setting. driver priority policy
. Specifies that the Use printer model specific drivers only if universal printing is unavailable
client printer uses universal printer driver if it is available. If the driver is not available on the server,
the client printer is created automatically with the appropriate native printer driver.
To change the default Citrix Universal Printer driver
To force XenApp to use the Citrix XPS Universal Printer driver before the EMF-based Citrix Universal Printer
driver, configure the Citrix policy setting and move XPS to the top of the list. Universal driver priority
6.9.11. Mapping Client Printer Drivers
Updated: 2011-03-01
1.
2.
3.
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 the printer driver name the client provides and mapping,
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 outdated or corrupted drivers
Specific Windows printer drivers for manufacturer’s client printer drivers
A driver that is available on Windows server for a client driver name
Each client provides information about client-side printers during logon, including the printer model name.
During client printer autocreation, Windows server printer driver names are selected that correspond to
the printer model names provided by the client. The autocreation process then employs the identified,
available printer drivers to construct redirected client print queues.
To map client printer drivers to server printer drivers
Configure the Citrix policy setting by adding the client printer Printer driver mapping and compatibility
driver name and selecting the server driver that you want to substitute for the client printer driver from the
menu. You can use wildcards in this setting. For example, to force all HP printers to use Find printer driver
a specific driver, specify in the policy setting. HP*
To edit printing settings for mapped client printer drivers
After you have added a client printer driver to the list of mapped drivers, you can modify the printing settings
for the driver. This setting overrides retained printer settings the user set during a previous session.
You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If
you specify a printing option that the printer driver does not support, that option has no effect.
On the settings page, select the printer driver for which Printer driver mapping and compatibility
you want to modify the settings.
Click . Settings
Specify the printer settings.
6.9.12. Increasing Printing Speed and Session Performance
Updated: 2010-02-24
While printing files from published applications to client printers, other virtual channels (such as video)
may experience decreased performance due to competition for bandwidth especially if users are accessing
servers through slower networks or dial-up connections. To prevent such degradation, you can limit
the bandwidth used by client printing.
Important: The printer bandwidth limit is always enforced, even when no other channels are in use.
By limiting the data transmission rate for printing, you make more bandwidth available in the ICA data stream
for transmission of video, keystrokes, and mouse data. More available bandwidth can help prevent degradation
of the user experience during printing.
There are two ways you can limit printing bandwidth in client sessions using printer settings in the Bandwidth
category:
Use the Citrix policy printer settings in the Delivery Services Console to enable and disable Bandwidth
the printing bandwidth session limit for the farm.
Use individual server settings to limit printing bandwidth in the server farm. You can perform this
task using gpedit.msc locally on each server to configure the Citrix policy printer settings. Bandwidth
You can use the Citrix Session Monitoring and Control Console (included in the WFAPI SDK) to obtain real-
time information about printing bandwidth. The print spooling virtual channel control (that is, the CTXCPM
Client printer mapping virtual channel control) lets you set a priority and bandwidth limit for bandwidth control
of this virtual channel.
To configure a printing bandwidth setting in an existing policy
Configure one of the options in the Citrix policy setting. If you enter values for both settings, Bandwidth
the most restrictive setting (with the lower value) is applied.
to specify the bandwidth available for printing in kilobits per Printer redirection bandwidth limit
second (kbps).
to limit the bandwidth available for printing to Printer redirection bandwidth limit percent
a percentage of the overall bandwidth available.
Note: If you want to specify bandwidth as a percentage using the Printer redirection bandwidth
setting, you must enable the as well. limit percent Overall session bandwidth limit
To limit printer bandwidth for a server
Using the Window Group Policy Editor locally on a server, configure one of the options in the Citrix policy
setting. If you enter values for both settings, the most restrictive setting (with the lower value) Bandwidth
is applied.
to specify the bandwidth available for printing in kilobits per Printer redirection bandwidth limit
second (kbps).
to limit the bandwidth available for printing to Printer redirection bandwidth limit percent
a percentage of the overall bandwidth available.
Note: If you want to specify bandwidth as a percentage using the Printer redirection bandwidth
setting, you must enable the as well. limit percent Overall session bandwidth limit
6.9.13. Displaying Printers
Updated: 2010-02-25
The following table summarizes where you can manage and modify print queues and display printers in a
XenApp environment. For definitions of the terms and , see client printing pathway network printing pathway
. Client printing pathway is not synonymous with Overview of Client and Network Printing Pathways
printers attached to client devices.
Printing Pathway UAC Enabled? Location
Client printers (Printers attached
to the client device)
Client
printing pathway
On Print Management snap-in in
the Microsoft Management Console
Off Control Panel
Network printers (Printers on
a network print server)
Client
printing pathway
On Print Management snap-in in
the Microsoft Management Console
Off Control Panel
Network printers (Printers on
a network print server)
Network
printing pathway
On Print Server > Print Management
snap-in in the
Microsoft Management Console
Off Print Server > Control Panel
Server local printers
(Shared printers locally attached
to a XenApp server)
N/A On Control Panel
Off Control Panel
Local network server Network On Control Panel
1.
2.
3.
1.
printers (Printers from a
network print server that
are added to server
running XenApp)
printing pathway
Off Control Panel
6.9.13.1. Managing Printers Using the Network Printing Pathway
Updated: 2010-02-25
If you want to modify or manage a user’s network print queue that a user printed to across the network
printing pathway, you must manage it through on the print server with the correct level Control Panel
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 role that has Server Manager Snap-in > Print and Document Services
the following syntax:
on (from ) in session PrinterName PrintServer clientname n
where:
PrinterName is the name of the printer being redirected
PrintServer is the name of the print server with which the printer is associated
clientname is the name of the client through which the print job is being rerouted
n is the session ID for that ICA connection
For example, . Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2
6.9.13.2. Displaying Printers Using the Client Printing Pathway
If UAC is not enabled, you can, however, display and manage redirected client print queues and server
local printers through Control Panel > Printers of individual servers. The client printers displayed on a
server fluctuate based on what sessions are active on a server because XenApp creates these printers based
on the printers on the connecting client devices. You can display client printers in . Control Panel > Printers
To display printers that use the client printing pathway when UAC is enabled
On the XenApp server that is hosting the session for which you want to display the printers, install the
server role. Print Services
In , open the stand-alone snap-in. Administrative Tools Print Management
To display client redirected printers, in the Print Management tree, select > Print Management
> . Custom Filters All Printers The snap-in displays the client printers Print Management
redirected from all clients connected to that server. You can display and manage the print queues for
these printers and select in the Print Management Tree to display active jobs Printers With Jobs
on redirected printers.
To display printers that use the client printing pathway without UAC enabled
On the XenApp server, open . Control Panel > Printers
The screen displays the local printers mapped to the ICA session. By default, the name of the Printers
printer takes the form (from ) in session ; for example, “printer01 (from machine01) printername clientname x
in session 7.” is the name of the printer on the client device, is the unique name given Printername clientname
to the client device or the Web Interface, and is the SessionID of the user’s session on the server. x
6.10. XenApp Server Utilities Reference
Updated: 2010-08-20
Citrix XenApp server utilities provide an alternative method to using the console for maintaining and
configuring servers and farms. Citrix XenApp server utilities must be run from a command prompt on a
server running Citrix XenApp.
Command Description
altaddr Specify server alternate IP address.
app Run application execution shell.
auditlog Generate server logon/logoff reports.
change client Change client device mapping.
ctxkeytool Generate farm key for IMA encryption.
ctxxmlss Change the Citrix XML Service port number.
dscheck Validate the integrity of the server farm data store.
dsmaint Maintain the server farm’s 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.
query View information about server farms, processes, ICA sessions, and users.
6.10.1. ALTADDR
Use to query and set the alternate (external) IP address for a server running Citrix XenApp. The altaddr
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 is specified, is assigned only to adapteraddress alternateaddress
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.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
The server subsystem reads the 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 altaddr
Architecture service for the new setting to take effect.
If is run without any parameters, it displays the information for alternate addresses configured on altaddr
the current server.
Examples
Set the server’s alternate address to 1.1.1.1:
altaddr /set 1.1.1.1
Set the server’s alternate address to 2.2.2.2 on the network interface card whose adapter address is 1.1.1.1:
altaddr /set 2.2.2.2 1.1.1.1
Security Restrictions
None.
6.10.2. APP
App is a script interpreter for secure application execution. Use to read execution scripts that App
copy standardized .ini type files to user directories before starting an application, or to perform application-
related cleanup after an application terminates. The script commands are described below.
Syntax
app scriptfilename
Parameters
scriptfilename
The name of a script file containing app commands (see script commands below).
Script Commands
copy sourcedirectory\filespec targetdirectory
Copies files from to . specifies the files to copy and can include sourcedirectory targetdirectory Filespec
wild cards (*,?).
deletedirectory\filespec
Deletes files owned by a user in the directory specified. specifies the files to delete and can Filespec
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 is specified, displays an error message. scriptfilename app
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
Security Restrictions
None.
6.10.3. AUDITLOG
Auditlog generates reports of logon/logoff activity for a server based on the Windows Server security event
log. To use , you must first enable logon/logoff accounting. You can direct the auditlog output to a file. auditlog
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 . You can back up the current log auditlog
from the Event Log Viewer by using . auditlog /clear: filename
/before:mm/dd/yy
Reports on logon/logoff activity only before . mm/dd/yy
/after:mm/dd/yy
Reports on logon/logoff activity only after . mm/dd/yy
/write:filename
Specifies the name of an output file. Creates a comma-delimited file that can be imported into
an application, such as a spreadsheet, to produce custom reports or statistics. It generates a report
of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. If
filename exists, the data is appended to the file.
/time
Generates a report of logon/logoff activity for each user, displaying logon/logoff times and total
time logged on. Useful for gathering usage statistics by user.
/fail
Generates a report of all failed logon attempts.
/all
Generates a report of all logon/logoff activity.
/detail
Generates a detailed report of logon/logoff activity.
/clear:filename
Saves the current event log in filename and clears the Event log. This command does not work if filename
already exists.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
Auditlog provides logs you can use to verify system security and correct usage. The information can be
extracted as reports or as comma-delimited files that can be used as input to other programs.
You must enable logon/logoff accounting on the local server to collect the information used by . auditlog
To enable logon/logoff accounting, log on as a local administrator and enable logon/logoff accounting with
the Audit Policy in Microsoft Windows.
Security Restrictions
To run , you must have Windows administrator privileges. auditlog
6.10.4. 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 , , or . /default /default_drives /default_printer
/noremap
If is specified, client drives that conflict with server drives are not mapped. /noremap
/persistent
Saves the current client drive mappings in the client device user’s profile.
/force_prt_todef
Sets the default printer for the client session to the default printer on the client’s Windows desktop.
/delete host_device
Deletes the client device mapping to . host_device
/? (help)
Displays the syntax for the utility and information about the utility’s options.
Remarks
Typing with no parameters displays the current client device mappings; it is equivalent to typing change client
. change client /current
Use to create a client drive mapping. This maps the change client host_device client_device client_device
drive letter to the letter specified by ; for example, maps client drive C to host_device change client v: c:
drive V on the server.
The option displays the share name, the share type, and a comment describing the mapped /view
device. Sample output for follows: change client /view
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 option flushes the client drive cache. This cache is used to speed access to client disk drives /flush
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 option maps the drives and printers on the client device to mapped drives and printers on /default
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 option resets printer mappings to defaults. attempts a one-to- /default_printers /default_printers
one mapping of all client printers; for example, the client’s LPT1 and LPT2 ports are mapped to the server’s
LPT1 and LPT2 ports. If the option is specified, the mapping is done in ascending order. /ascending
The option resets host drive mappings to defaults. attempts a one-to- /default_drives /default_drives
one 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 option is specified, the mapping is done in /ascending
ascending order.
The option causes the mapping to occur in ascending drive letter order. For example, if the first /ascending
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 option causes the mapping to skip drive letters occupied on the server. For example, if the /noremap
server has a drive C but no drive D , the client’s drive C is mapped to D on the server, but the client’s drive D
is not mapped.
The option causes the current device mappings to be saved in the user’s profile. Drive conflicts /persistent
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 option sets the default printer for the ICA session to the default printer on the client’ /force_prt_todef
s Windows desktop.
Security Restrictions
None.
6.10.5. CTXKEYTOOL
Use to enable and disable the IMA encryption feature and generate, load, replace, enable, disable, ctxkeytool
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 . This command alone is not sufficient to enable filepath
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: , , and . On each subsequent server in the generate load newkey
farm, you just need to the key. After you activate the IMA encryption feature on one server, the feature load
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 option on backup
another server in the same farm that still has its key. This command recreates the key file. After recreating
the key file, use to load it to the server on which it was lost. load
After using the option to disable the IMA encryption feature, you must reenter the configuration disable
logging database password. If you want to activate the IMA encryption feature again, run on any enable
server in the farm.
Security Restrictions
You must be a Citrix administrator with local administrator privileges to run . ctxkeytool
6.10.6. CTXXMLSS
Updated: 2010-02-10
Use to change the Citrix XML Service port number. ctxxmlss
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 seconds. The default is nine seconds. nnn
/b:a
Binds the service to all network interfaces. This is the default setting.
/b:l
Binds the service to localhost only.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
Remarks
For more information, see . System Requirements
6.10.7. DSCHECK
Updated: 2010-02-10
Use to validate the consistency of the database used to host the server farm’s data store. You can dscheck
then repair any inconsistencies found. is often used after running . dscheck dsmaint
Syntax
dscheck [/clean] [/?]
Options
/clean
Attempts to fix any consistency error that is found.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
Dscheck performs a variety of tests to validate the integrity of a server farm’s data store. When run
without parameters, only these tests are run. Run on a server in the farm that has a direct dscheck
connection to the data store.
When you run with the option, the utility runs tests and removes inconsistent data dscheck /clean
(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 option. /clean
When you run the utility with the option, you may need to run the command with the /clean dsmaint
parameter on each server in the farm to update the local host caches. Running this command recreatelhc
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, returns an error code of zero for a successful scan (no errors are found) and an error code of dscheck
one if any problems are encountered.
Dscheck looks primarily at three data store objects: servers, applications, and groups. For each of these
object types, performs a series of tests on each object instance. dscheck
For example, for each server object in the data store, verifies that there is a corresponding dscheck
common server object and then further verifies that both objects have matching host IDs and host names.
Examples
To run consistency checks only:
dscheck
To check consistency and fix errors:
dscheck /clean
6.10.8. DSMAINT
Updated: 2011-01-10
Run on farm servers to perform XenApp data store maintenance tasks, including backing up the dsmaint
data store, migrating the data store to a new server, and compacting the XenApp data store or the
Streaming Offline database. Not all commands apply to all database types. dsmaint
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 compactdb [/lhc]
dsmaint migrate [{/srcdsn:dsn1 /srcuser:user1 /srcpwd:pwd1}] [{/dstdsn:dsn2 /dstuser:user2
/dstpwd:pwd2}]
dsmaint publishsqlds {/user:username /pwd:password}
dsmaint recover
dsmaint recreatelhc
dsmaint recreaterade
dsmaint verifylhc [/autorepair]
dsmaint [/?]
Parameters
destination_path
Path for the backup data store. Do not use the same path as the original database.
dsn1
The name of the DSN file for the source data store.
dsn2
The name of the DSN file for the destination data store.
filename
The name of the data store.
password
The password to connect to the data store.
pwd1
The source data store password.
pwd2
The destination data store password.
user1
The source data store user logon.
user2
The destination data store user logon.
username
The name of the user to use when connecting to the data store.
Options
1.
2.
3.
4.
config
Changes configuration parameters used to connect to the data store. Enter the full path to the DSN file
in quotation marks. For example,
dsmaint config /user:ABCnetwork\administrator /pwd:Passw0rd101
/dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"
Stop the Citrix Independent Management Architecture service before using with the option. config /pwd
Caution: Specify a for or you will change the security context for access to /dsn dsmaint config
the SQL Server or Oracle database.
/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 SQL Server Express database that is the farm’s data store. Run
this command on the server that hosts the data store. Requires a path or share point to which the
backup database file will be copied. Do not use this parameter to back up SQL Server or Oracle data stores.
Caution: When running , specifying the same path as the existing data store dsmaint backup
can damage it irreparably.
compactdb
Compacts the local database file. During database compaction, the database is temporarily unavailable
for both reading and writing. The compacting time can vary from a few seconds to a few
minutes, depending on the size of the database and the usage.
/lhc
Compacts the local host cache on the server where this parameter is run. Run after dsmaint /lhc
your farm has been running for a long period of time as a maintenance task.
migrate
Migrates data from one data store database to another. Run this command on any XenApp server that
has a connection to the data store. Use this command to move a data store to another server, rename
a data store in the event of a server name change, or migrate the data store to a different type
of database (for example, migrate from SQL Server Express to SQL Server).
To migrate the data store to a new server:
Prepare the new database server using the steps you did before running XenApp Setup for the
first time.
Create a DSN file for this new database server on the server where you will be running
. dsmaint migrate
Run on any server with a connection to the data store. dsmaint migrate
Run on each server in the farm to point it to the new database. dsmaint config
/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 data store from which the data is migrating.
/dstdsn:dsn2
The name of the data store to which to migrate the data.
/dstuser:user2
The user name that allows you to connect to the data store to which you are migrating the source
data store.
/dstpwd:pwd2
The password that allows you to connect to the data store to which you are migrating the source data store.
publishsqlds
Publishes a SQL Server data store for replication. Run only from the server that created publishsqlds
the farm. The publication is named MFXPDS.
recover
Restores a SQL Server Express data store to its last known good state. Run this directly on the server
while the Citrix Independent Management Architecture service is not running.
recreatelhc
Recreates the local host cache database. Run if prompted after running . After dsmaint verifylhc
running dsmaint recreatelhc, restart the IMA Service. When the IMA Service starts, the local host cache
is populated with fresh data from the data store.
recreaterade
Recreates the application streaming offline database. Run as a troubleshooting step if the
Citrix Independent Management Architecture service stops running and the local host cache is
not corrupted.
verifylhc
Verifies the integrity of the local host cache. If the local host cache is corrupt, you are prompted with
the option to recreate it. With the option, the local host cache is verifylhc /autorepair
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 , Citrix recommends running to check the integrity of the data on the XenApp dsmaint dscheck
data store.
Security Restrictions
The and commands can be run only by a user with the correct user name dsmaint config dsmaint migrate
and password for the database.
6.10.9. 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.
Security Restrictions
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.
6.10.10. ICAPORT
Updated: 2009-11-19
Use to query or change the TCP/IP port number used by the ICA protocol on the server. icaport
Syntax
icaport {/query | /port:nnn | /reset} [/?]
Options
/query
Queries the current setting.
/port:nnn
Changes the TCP/IP port number to nnn.
/reset
Resets the TCP/IP port number to 1494, which is the default.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
The default port number is 1494. The port number must be in the range of 0–65535 and must not conflict
with other well-known port numbers.
If you change the port number, restart the server for the new value to take effect. If you change the port
number on the server, you must also change it on every plug-in that will connect to that server. For
instructions for changing the port number on plug-ins, see Citrix eDocs for the plug-ins 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
Security Restrictions
Only Citrix administrators with Windows administrator privileges can run . icaport
6.10.11. IMAPORT
Updated: 2010-02-03
Use to query or change the IMA port. imaport
Syntax
imaport {/query | /set {IMA:nnn | ds:nnn}* | /reset {IMA | DS | ALL} } [/?]
Options
/query
Queries the current setting.
/set
Sets the designated TCP/IP port to a specified port number.
ima:nnn
Sets the IMA communication port to a specified port number.
ds:nnn
Sets the data store server port to a specified port number.
/reset
Resets the specified TCP/IP port to the default.
ima
Resets the IMA communication port to 2512.
ds
Resets the data store server port to 2512.
all
Resets all of the applicable ports to the defaults.
/?
Displays the syntax for the utility and information about the utility’s options.
6.10.12. 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 as a qfarm
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.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
Query farm returns information for IMA-based servers within a server farm.
Security Restrictions
You must be a Citrix administrator to run . query farm
6.10.13. QUERY PROCESS
Use query to display information about processes within the network.
Syntax
query process [ * | processid | username | sessionname | /id:nn | programname ]
[ /server:servername ] [ /system ]
query process [/?]
Parameters
*
Displays all visible processes.
processid
The three- or four-digit ID number of a process running within the farm.
programname
The name of a program within a farm.
servername
The name of a server within the farm.
sessionname
The name of a session, such as ica-tcp#7.
username
The name of a user connected to the farm.
Options
process
Displays information about processes running on the current server.
process *
Displays all visible processes on the current server.
process processid
Displays processes for the specified processid.
process username
Displays processes belonging to the specified user.
process sessionname
Displays processes running under the specified session name.
process /id:nn
Displays information about processes running on the current server by the specified ID number.
process programname
Displays process information associated with the specified program name.
process /server:servername
Displays information about processes running on the specified server. If no server is specified,
the information returned is for the current server.
process /system
Displays information about system processes running on the current server.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
6.10.14. QUERY SESSION
Updated: 2010-06-07
Use query to display information about sessions within the network.
Syntax
query session [sessionname | username | sessionid]
query session [/server:servername] [/mode] [/flow] [/connect] [/counter]
query session [/?]
Parameters
servername
The name of a server within the farm.
sessionname
The name of a session, such as “ica-tcp#7”.
sessionid
The two-digit ID number of a session.
username
The name of a user connected to the farm.
Options
session sessionname
Identifies the specified session.
session username
Identifies the session associated with the user name.
session sessionid
Identifies the session associated with the session ID number.
session /server: servername
Identifies the sessions on the specified server.
session /mode
Displays the current line settings.
session /flow
Displays the current flow control settings.
session /connect
Displays the current connection settings.
session /counter
Displays the current Remote Desktop Services counter information.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
6.10.15. QUERY TERMSERVER
Use query to display information about terminal servers within the network.
Syntax
query termserver [servername] [/domain:domain] [/address] [/continue]
query termserver [/?]
Parameters
servername
The name of a server within the farm.
domain
The name of a domain to query.
Options
termserver servername
Identifies a Terminal Server.
/address
Displays network and node addresses.
/continue
Do not pause after each page of output.
/domain: domain
Displays information for the specified domain. Defaults to the current domain if no domain is specified.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
If no parameters are specified, query termserver lists all Terminal Servers within the current domain.
Security Restrictions
None.
6.10.16. QUERY USER
Use query to display information about users within the network.
Syntax
query user [ username | sessionname | sessionid ] [ /server:servername ]
query user [/?]
Parameters
servername
The name of a server within the farm.
sessionname
The name of a session, such as “ica-tcp#7”.
sessionid
The ID number of a session.
username
The name of a user connected to the farm.
Options
user username
Displays connection information for the specified user name.
user sessionname
Displays connection information for the specified session name.
user sessionid
Displays connection information for the specified session ID.
user /server: servername
Defines the server to be queried. The current server is queried by default.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
If no parameters are specified, displays all user sessions on the current server. You can use query user quser
as a shortened form of the command. query user
Security Restrictions
None.
6.11. Performance Counters Reference
Performance monitoring counters that directly relate to the performance of sessions, networking, and security
are installed with XenApp. You can access these counters from the Performance Monitor, which is part of
Windows operating systems. Use performance monitoring to obtain system performance data and the effects
of configuration changes on system throughput.
Using the standard Windows procedure, you can add and then view the following categories of XenApp-
related counters, called in Performance Monitor: performance objects
Citrix CPU Utilization Mgmt User
Citrix IMA Networking
Citrix Licensing
Citrix MetaFrame Presentation Server
ICA Session
Secure Ticket Authority
6.11.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.
6.11.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.
6.11.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.
6.11.4. Citrix MetaFrame Presentation Server Counters
Updated: 2009-12-04
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.
Cumulative Server Load The combined processor utilization and connected XenApp user
session loads for this server.
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 that were 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.
ICA Roundtrip Latency Median The median time of ICA roundtrip latency for all sessions on the server.
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 Web-
based 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 that are currently being executed.
Resolution WorkItem Queue
Ready Count
The number of resolution work items that are ready to be executed.
WorkItem Queue Executing Count The number of work items that are currently being executed.
WorkItem Queue Pending Count The number of work items that are not yet ready to be executed.
WorkItem Queue Ready Count The number of work items that are ready to be executed.
Zone Elections The number of zone elections. This value starts at zero each time
the IMA Service starts and is incremented each time a zone
election takes place.
Zone Elections Triggered The number of times a server triggers a zone election.
Zone Elections Won The number of times a server wins a zone election.
6.11.5. ICA Session Counters
Updated: 2009-12-10
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 The bandwidth, measured in bps, used when routing a print
job through an ICA session that does not support a spooler to a
client printer attached to the client COM 2 port.
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 HDX Mediastream for Flash
Data Bandwidth
The bandwidth, measured in bps, used when streaming Flash data
in an HDX-enabled 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 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.
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 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.
Output COM 2 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 2 port.
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 HDX Mediastream for
Flash Data Bandwidth
The bandwidth, measured in bps, used when streaming Flash data
in an HDX-enabled session.
Output LPT 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 LPT 1 port.
Output LPT 2 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 LPT 2 port.
Output Management Bandwidth The bandwidth, measured in bps, used when performing
management functions.
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.
Resource Shares The total number of shares used by the session.
6.11.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
received during the lifetime of the STA.
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
received during the lifetime of the STA.
STA Good Ticket Request Count The total number of successful ticket generation requests
received during the lifetime of the STA.
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.
6.12. Policy Settings Reference
Updated: 2010-02-08
Policies contain settings that are applied when the policy is enforced. You configure these settings using
the Delivery Services Console or the Local Group Policy Editor, depending on whether or not you use
Active Directory in your XenApp environment.
The descriptions for each policy setting include the following information:
The name of the policy setting
The Citrix products to which the policy setting applies
The additional settings, if applicable, required to enable a particular feature
Other settings that are similar to the policy setting in question, if applicable
6.12.1. Policy Settings: Quick Reference Table
Updated: 2010-03-11
The following tables present settings you can configure within a policy. Find the task you want to perform in
the left column, then locate its corresponding setting in the right column.
Graphics & Multimedia
Task: Use this policy setting:
Control the amount of memory allocated for
displaying graphics in a session
Display memory limit
Control how a user's display degrades in response
to memory limits and whether or not to notify the user
Display mode degrade preference
Notify user when display mode is degraded
Control compression of images for use in sessions
of limited bandwidth
Lossy compression level
Lossy compression level threshold value
Progressive compression level
Progressive compression threshold value
Control whether or not Flash content is rendered
in sessions
Flash acceleration
Control whether or not Web sites can display
Flash content when accessed in sessions
Flash server-side content fetching whitelist
Flash URL blacklist
Desktop UI
Task: Use this policy setting:
Control whether or not Desktop wallpaper is used
in users' sessions
Desktop wallpaper
View window contents while a window is dragged View window contents while dragging
User Devices
To limit bandwidth used for: Use this policy setting:
Client audio mapping Audio redirection bandwidth limit, or
Audio redirection bandwidth limit percent
Cut-and-paste using local clipboard Clipboard redirection bandwidth limit, or
Clipboard redirection bandwidth limit percent
Devices connected to a local COM port COM port redirection bandwidth limit, or
COM port redirection bandwidth limit percent
Access in a session to local client drives File redirection bandwidth limit, or
File redirection bandwidth limit percent
Printers connected to the client LPT port LPT port redirection bandwidth limit, or
LPT port redirection bandwidth limit percent
Custom devices connected to the client through
OEM virtual channels
OEM channels bandwidth limit, or
OEM channels bandwidth limit percent
Client session Overall session bandwidth limit
Printing Printer redirection bandwidth limit, or
Printer redirection bandwidth limit percent
TWAIN device (such as a camera or scanner) TWAIN device redirection bandwidth limit, or
TWAIN device redirection bandwidth
limit percent
Audio
Task: Use this policy setting:
Control whether or not to allow audio input
from microphones on the user device
Client microphone redirection
Control audio quality on the user device Audio quality
Control audio mapping to speakers on the user device Client audio redirection
User drives and devices
Task: Use this policy setting:
Control whether or not drives on the user device
are connected when users log on to the server
Auto connect client drives
Control how drives map from the user device Client drive redirection
Improve the speed of writing and copying files to a
client disk over a WAN
Use asynchronous writes
Control whether or not user devices attached to
local COM ports are available in a session
Client COM port redirection
Control whether or not client printers attached to
local LPT ports are available in a session
Client LPT port redirection
Control whether or not users' local hard drives
are available in a session
Client fixed drives, and
Client drive redirection
Control whether or not users' local floppy drives
are available in a session
Client floppy drives, and
Client drive redirection
Control whether or not users' network drives
are available in a session
Client network drives, and
Client drive redirection
Control whether or not users' local CD, DVD, or Blu-
ray drives are available in a session
Client optical drives, and
Client drive redirection
Control whether or not users' local removable drives
are available in a session
Client removable drives, and
Client drive redirection
Control whether or not users' TWAIN devices, such
as scanners and cameras, are available in a session
and control compression of image data transfers
Client TWAIN device redirection
TWAIN compression level
Control cut-and-paste data transfer between the
server and the local clipboard
Client clipboard redirection
Control use of custom devices, such as an electronic
pen (stylus)
OEM channels
Printing
Task: Use this policy setting:
Control creation of client printers on the user device Auto-create client printers, and
Client printer redirection
Allow use of legacy printer names and
preserve backward compatibility with prior versions
of the server
Client printer names
Control the location where printer properties are stored Printer properties retention
Control whether print requests are processed by
the client or the server
Direct connections to print servers
Control whether or not users can access
printers connected to their user devices
Client printer redirection
Control installation of native Windows drivers
when automatically creating client and network printers
Automatic installation of in-box printer drivers
Control when to use the Universal Printer Driver Universal printing
Choose a printer based on a roaming user’s
session information
Default printer
Content redirection
Task: Use this policy setting:
Control whether or not to use content redirection
from the server to the user device
Host to client redirection
Time Zone Control
Task: Use this policy setting:
Control whether or not to use the server’s time
zone instead of the client’s estimated local time zone
Local Time Estimation
Control whether to use the server’s time zone or
the client’s time zone
Use local time of client
User Connections and Shadowing
Task: Use this policy setting:
Limit the number of sessions that a user can run at
the same time
Concurrent logon limit
Control whether or not shadowing is allowed Shadowing
Allow or deny permission for users to shadow connections Users who can shadow other users
Users who cannot shadow other users
Single Sign-On
Task: Use this policy setting:
Identify which credential repository to use when
using Single Sign-On
Single Sign-On central store
Allow or prevent use of Single Sign-On Single Sign-On
Offline Applications
Task: Use this policy setting:
Allow or prevent offline application users to
reconnect without reauthentication
Offline app client trust
Allow or deny permission for users to access
offline applications
Offline app users
Security
Task: Use this policy rule:
Require that connections use a specified encryption level SecureICA minimum encryption level
6.12.2. ICA Policy Settings
Updated: 2010-03-10
The ICA section contains policy settings related to ICA listener connections, mapping to the Clipboard and
custom channels, connecting to server desktops, and controlling the launch behavior of non-published programs.
ICA listener connection timeout
This setting specifies the maximum wait time for a connection using the ICA protocol to be completed. By
default, the maximum wait time is 120000 milliseconds, or two minutes.
ICA listener port number
This setting specifies the TCP/IP port number used by the ICA protocol on the server.
The default port number is 1494. The port number must be in the range of 0–65535 and must not conflict
with other well-known port numbers.
If you change the port number, restart the server for the new value to take effect. If you change the port
number on the server, you must also change it on every plug-in that connects to the server.
Client clipboard redirection
This setting allows or prevents the Clipboard on the user device to be mapped to the Clipboard on the server.
By default, clipboard redirection is allowed.
To prevent cut-and-paste data transfer between a session and the local Clipboard, select . Users can Prohibit
still cut and paste data between applications running in sessions.
After allowing this setting, configure the maximum allowed bandwidth the Clipboard can consume in a
client connection using the or the Clipboard redirection bandwidth limit Clipboard redirection
settings. bandwidth limit percent
Related Policy Settings
Clipboard redirection bandwidth limit
Clipboard redirection bandwidth limit percent
Desktop launches
This setting allows or prevents non-administrative users to connect to a desktop session on the server.
When allowed, non-administrative users can connect. By default, non-administrative users cannot connect
to desktop sessions.
Launching of non-published programs during client connection
This setting specifies whether or not to launch initial applications or published applications through ICA or RDP
on the server. By default, only published applications are allowed to launch.
OEM Channels
This setting allows or prevent custom (OEM) devices attached to ports on the user device to be mapped to
ports on the server. By default, mapping of custom devices is allowed.
After allowing this setting, configure the maximum amount of bandwidth the OEM’s virtual channel can
consume in a client connection using the or the OEM channels bandwidth limit OEM channels
settings. bandwidth limit percent
Related Policy Settings
OEM channels bandwidth limit
OEM channels bandwidth limit percent
6.12.2.1. Audio Policy Settings
Updated: 2010-03-10
The Audio section contains policy settings you can configure to permit user devices to send and receive audio
in sessions without reducing performance.
Audio Quality
Use the projected figures for each level of sound quality to calculate the bandwidth potentially consumed
in connections to specific servers. For example, if 25 users record at Medium on one server, the bandwidth
used in the connections to that server is over 52,500 bytes per second.
Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the
bandwidth consumption is doubled.
To control sound quality, choose one of the following options:
Select for low-bandwidth connections. Sounds sent to the client Low - for low speed connections
are compressed up to 16 Kbps. This compression results in a significant decrease in the quality of
the sound but allows reasonable performance for a low-bandwidth connection. With both audio
playback and recording total bandwidth consumption is 22 Kbps at maximum.
Select for most LAN-based connections. Sounds sent to the client Medium - optimized for speech
are compressed up to 64 Kbps. With both audio playback and recording total bandwidth consumption
is 33.6 Kbps at maximum.
Select for connections where bandwidth is plentiful and sound quality High - high definition audio
is important. Clients can play sound at its native rate. Sounds can use up to 1.3 Mbps of bandwidth to
play clearly. Transmitting this amount of data can result in increased CPU utilization and
network congestion.
Related Policy Settings
Audio redirection bandwidth limit
Audio redirection bandwidth limit percent
Client audio redirection
This setting allows or prevents applications hosted on the server to play sounds through a sound device
installed on the user device. This setting also allows or prevents users from recording audio input.
After allowing this setting, you can limit the bandwidth consumed by playing or recording audio. Limiting
the amount of bandwidth consumed by audio can improve application performance but may also degrade
audio quality. Bandwidth is consumed only while audio is recording or playing. If both occur at the same time,
the bandwidth consumption doubles.
To specify the maximum amount of bandwidth, configure the or the Audio redirection bandwidth limit
settings. Audio redirection bandwidth limit percent
Related Policy Settings
Audio redirection bandwidth limit
Audio redirection bandwidth limit percent
Client microphone redirection
Client microphone redirection
This setting enables or disables client microphone redirection. When enabled, users can use microphones
to record audio input in a session.
For security, users are alerted when servers that are not trusted by their devices try to access
microphones. Users can choose to accept or not accept access. Users can disable the alert on the Citrix
online plug-in.
If the setting is disabled on the user device, this rule has no effect. Client audio redirection
Related Policy Settings
Client audio redirection
Audio redirection bandwidth limit
Audio redirection bandwidth limit percent
6.12.2.2. Auto Client Reconnect Policy Settings
Updated: 2010-03-10
The Auto Client Reconnect section contains policy settings for controlling automatic reconnection of sessions.
Auto client reconnect
This setting allows or prevents automatic reconnection by the same client after a connection has
been interrupted. By default, automatic reconnection is allowed.
Allowing automatic reconnection allows users to resume working where they were interrupted when a
connection was broken. Automatic reconnection detects broken connections and then reconnects the users
to their sessions.
However, automatic reconnection can result in a new session being launched (instead of reconnecting to
an existing session) if a plug-in’s cookie, containing the key to the session ID and credentials, is not used.
The cookie is not used if it has expired, for example, because of a delay in reconnection, or if credentials must
be reentered. Auto client reconnect is not triggered if users intentionally disconnect.
Auto client reconnect authentication
This setting requires authentication for automatic client reconnections. By default, authentication is not required.
When a user initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory
and creates a cookie containing the encryption key which is sent to the plug-in. When this setting is
added, cookies are not used. Instead, XenApp displays a dialog box to users requesting credentials when the
plug-in attempts to reconnect automatically.
Auto client reconnect logging
This setting enables or disables recording of auto client reconnections in the event log. By default, logging
is disabled.
When logging is enabled, the server’s System log captures information about successful and failed
automatic reconnection events. The server farm does not provide a combined log of reconnection events for
all servers.
6.12.2.3. Bandwidth Policy Settings
Updated: 2010-03-11
The Bandwidth section contains policy settings you can configure to avoid performance problems related to
client session bandwidth use.
Audio redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for playing or recording audio in
a user session. If you enter a value for this setting and a value for the Audio redirection bandwidth
setting, the most restrictive setting (with the lower value) is applied. limit percent
Audio redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth limit for playing or recording audio as a percent of
the total session bandwidth. If you enter a value for this setting and a value for the Audio
setting, the most restrictive setting (with the lower value) is applied. redirection bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
Clipboard redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for data transfer between a
session and the local Clipboard. If you enter a value for this setting and a value for the Clipboard
setting, the most restrictive setting (with the lower value) is applied. redirection bandwidth limit percent
Clipboard redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for data transfer between a session and the local
Clipboard as a percent of the total session bandwidth. If you enter a value for this setting and a value for the
setting, the most restrictive setting (with the lower value) is applied. Clipboard redirection bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
COM port redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a COM port in a
client connection. If you enter a value for this setting and a value for the COM port redirection
setting, the most restrictive setting (with the lower value) is applied. bandwidth limit percent
COM port redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for accessing COM ports in a client connection as a
percent of the total session bandwidth. If you enter a value for this setting and a value for the COM
setting, the most restrictive setting (with the lower value) is applied. port redirection bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
File redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a client drive in a
user session. If you enter a value for this setting and a value for the File redirection bandwidth limit
, the most restrictive setting (with the lower value) takes effect. percent setting
File redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth limit for accessing client drives as a percent of the
total session bandwidth. If you enter a value for this setting and a value for the File redirection
setting, the most restrictive setting (with the lower value) is applied. bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
LPT port redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for print jobs using an LPT port in
a single user session. If you enter a value for this setting and a value for the LPT port redirection
setting, the most restrictive setting (with the lower value) is applied. bandwidth limit percent
LPT port redirection bandwidth limit percent
This setting specifies the bandwidth limit for print jobs using an LPT port in a single client session as a percent
of the total session bandwidth. If you enter a value for this setting and a value for the LPT port
setting, the most restrictive setting (with the lower value) is applied. redirection bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
OEM channels bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for custom (OEM) virtual channels.
If you enter a value for this setting and a value for the setting, OEM channels bandwidth limit percent
the most restrictive setting (with the lower value) is applied.
OEM channels bandwidth limit percent
This setting specifies the maximum allowed bandwidth for custom (OEM) virtual channels as a percent of the
total session bandwidth. If you enter a value for this setting and a value for the OEM channels bandwidth limit
setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
Overall session bandwidth limit
This setting specifies the total amount of bandwidth available in kilobits per second for user sessions. Limiting
the amount of bandwidth consumed by a client connection can improve performance when other
applications outside the client connection are competing for limited bandwidth.
Printer redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing client printers in a
user session. If you enter a value for this setting and a value for the Printer redirection bandwidth
setting, the most restrictive setting (with the lower value) is applied. limit percent
Printer redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for accessing client printers as a percent of the
total session bandwidth. If you enter a value for this setting and a value for the Printer redirection
setting, the most restrictive setting (with the lower value) is applied. bandwidth limit
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
TWAIN device redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for controlling TWAIN
imaging devices from published applications. If you enter a value for this setting and a value for the
setting, the most restrictive setting (with the TWAIN device redirection bandwidth limit percent
lower value) is applied.
TWAIN device redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for controlling TWAIN imaging devices from
published applications as a percent of the total session bandwidth. If you enter a value for this setting and a
value for the setting, the most restrictive setting (with the TWAIN device redirection bandwidth limit
lower value) is applied.
If you configure this setting, you must also configure the setting Overall session bandwidth limit
which specifies the total amount of bandwidth available for client sessions.
6.12.2.4. Desktop UI Policy Settings
Updated: 2010-03-10
The Desktop UI section contains policy settings that control visual effects, such as desktop wallpaper,
menu animations, and drag-and-drop images, to manage the bandwidth used in client connections. You
can improve application performance on a WAN by limiting bandwidth usage.
Desktop wallpaper
By default, user sessions can show wallpaper. To turn off desktop wallpaper and reduce the bandwidth required
in user sessions, select when adding this setting to a policy. Prohibited
Menu animation
Menu animation is a Microsoft personal preference setting that causes a menu to appear after a short
delay, either by scrolling or fading in. When this policy setting is set to , an arrow icon appears at Allowed
the bottom of the menu. The menu appears when you mouse over that arrow.
By default, menu animation is allowed.
View window contents while dragging
This policy setting controls the display of window contents when dragging a window across the screen.
When set to , the entire window appears to move when you drag it. When set to , only Allowed Prohibited
the window outline appears to move until you drop it. By default, viewing window contents is allowed.
6.12.2.5. End User Monitoring Policy Settings
Updated: 2010-03-11
The End User Monitoring section contains policy settings for measuring session traffic.
ICA round trip calculation
This setting determines whether or not ICA round trip calculations are performed for active connections.
By default, calculations for active connections are enabled.
By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates
user interaction. This delay can be indefinite in length and is designed to prevent the ICA roundtrip
measurement being the sole reason for ICA traffic.
ICA round trip calculation interval (Seconds)
This setting specifies the frequency, in seconds, at which ICA round trip calculations are performed. By
default, ICA round trip is calculated every 15 seconds.
ICA round trip calculations for idle connections
This setting determines whether or not ICA round trip calculations are performed for idle connections. By
default, calculations are not performed for idle connections.
By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates
user interaction. This delay can be indefinite in length and is designed to prevent the ICA roundtrip
measurement being the sole reason for ICA traffic.
6.12.2.6. Graphics Policy Settings
Updated: 2010-03-10
The Graphics section contains policy settings for controlling how images are handled in user sessions.
Display memory limit
This setting specifies the maximum video buffer size in kilobytes for the session. By default, the display
memory limit is 32768 kilobytes.
Specify an amount in kilobytes from 128 to 65536. Using more color depth and higher resolution for
connections requires more memory. If the memory limit is reached, the display degrades according to the
setting. Display mode degrade preference
Display mode degrade preference
This setting specifies that color depth or resolution degrades first when the session display memory limit
is reached.
When the session memory limit is reached, you can reduce the quality of displayed images by choosing
whether color depth or resolution is degraded first. When color depth is degraded first, displayed images
use fewer colors. When resolution is degraded first, displayed images use fewer pixels per inch. By default,
color depth is degraded first.
To notify users when either color depth or resolution are degraded, configure the Notify user when
setting. display mode is degraded
Image caching
This setting enables or disables caching of images in sessions. When needed, the images are retrieved in
sections to make scrolling smoother. By default, image caching is enabled.
Maximum allowed color depth
This setting specifies the maximum color depth allowed for a session. By default, the maximum allowed
color depth is 32 bits per pixel.
Setting a high color depth requires more memory. To degrade color depth when the memory limit is
reached, configure the setting. When color depth is degraded, Display mode degrade preference
displayed images use fewer colors.
Notify user when display mode is degraded
This setting displays a brief explanation to the user when the color depth or resolution is degraded. By
default, notifying users is disabled.
Queuing and tossing
This setting discards queued images that are replaced by another image. This improves response when
graphics are sent to the client. Configuring this setting can cause animations to become choppy due to
dropped frames. By default, queuing and tossing is enabled.
6.12.2.6.1. Image Compression Policy Settings
Updated: 2010-03-10
The Image compression section contains settings that enable you to remove or alter compression. When
client connections are limited in bandwidth, downloading images without compression can be slow.
Lossy compression level
This setting controls the degree of lossy compression used on images delivered over client connections that
are limited in bandwidth. In such cases, displaying images without compression can be slow. By default,
medium compression is selected.
For improved responsiveness with bandwidth-intensive images, use high compression. Where preserving
image data is vital; for example, when displaying X-ray images where no loss of quality is acceptable, you
may not want to use lossy compression.
Related Policy Settings
Lossy compression threshold value
Progressive compression level
Progressive heavyweight compression level
Lossy compression threshold value
This setting represents the maximum bandwidth in kilobits per second for a connection to which
lossy compression is applied. By default, the threshold value is 2000 kilobits per second.
Adding the setting to a policy and including no specified threshold can improve Lossy compression level
the display speed of high-detail bitmaps, such as photographs, over a LAN.
Related Policy Settings
Lossy compression level
Progressive compression level
This setting provides a less detailed but faster initial display of images. The more detailed image, defined by
the normal lossy compression setting, appears when it becomes available. Use very high or ultra
high compression for improved viewing of bandwidth-intensive graphics such as photographs.
For progressive compression to be effective, its compression level must be higher than the Lossy
setting; by default, progressive compression is not applied. compression level
Note: The increased level of compression associated with progressive compression also enhances
the interactivity of dynamic images over client connections. The quality of a dynamic image, such as a
rotating three-dimensional model, is temporarily decreased until the image stops moving, at which time
the normal lossy compression setting is applied.
Related Policy Settings
Progressive compression threshold value
Lossy compression level
Progressive heavyweight compression
Progressive compression threshold value
The maximum bandwidth in kilobits per second for a connection to which progressive compression is applied.
This is applied only to client connections under this bandwidth. By default, the threshold value is 1440 kilobits
per second.
Related Policy Settings
Progressive compression level
Progressive heavyweight compression
This setting enables or disables reducing bandwidth beyond progressive compression without losing image
quality by using a more advanced, but more CPU-intensive, graphical algorithm. By default,
progressive heavyweight compression is disabled.
If enabled, heavyweight compression applies to all lossy compression settings. It is supported on the Citrix
online plug-in but has no effect on other plugins.
Related Policy Settings
Lossy compression level
Progressive compression level
6.12.2.7. File Redirection Policy Settings
Updated: 2010-03-10
The File Redirection section contains policy settings relating to client drive mapping and client drive optimization.
Auto connect client drives
This setting allows or prevents automatic connection of client drives when users log on. By default,
automatic connection is allowed. When allowing this setting, make sure to enable the settings for the drive
types you want automatically connected. For example, to allow automatic connection of users' CD-ROM
drives, configure this setting and the setting. Client optical drives
Related Policy Settings
Client drive redirection
Client floppy drives
Client optical drives
Client fixed drives
Client network drives
Client removable drives
Client drive redirection
This setting enables or disables drive redirection to and from the user device. When enabled, users can save
files to all their client drives. When disabled, all file redirection is prevented, regardless of the state of
the individual file redirection settings such as and . By default, Client floppy drives Client network drives
file redirection is enabled.
Related Policy Settings
Client floppy drives
Client optical drives
Client fixed drives
Client network drives
Client removable drives
Client fixed drives
This setting allows or prevents users from accessing or saving files to fixed drives on the user device. By
default, accessing client fixed drives is allowed.
When allowing this setting, make sure the setting is present and set to . Client drive redirection Allowed
If these settings are disabled, client fixed drives are not mapped and users cannot access these drives
manually, regardless of the state of the setting. Client fixed drives
To ensure fixed drives are automatically connected when users log on, configure the Auto connect client drives
setting.
Related Policy Settings
Client drive redirection
Auto connect client drives
Client floppy drives
This setting allows or prevents users from accessing or saving files to floppy drives on the user device. By
default, accessing client floppy drives is allowed.
When allowing this setting, make sure the setting is present and set to . Client drive redirection Allowed
If these settings are disabled, client floppy drives are not mapped and users cannot access these drives
manually, regardless of the state of the setting. Client floppy drives
To ensure floppy drives are automatically connected when users log on, configure the Auto connect
setting. client drives
Related Policy Settings
Client drive redirection
Auto connect client drives
Client network drives
This setting allows or prevents users from accessing and saving files to network (remote) drives through the
user device. By default, accessing client network drives is allowed.
When allowing this setting, make sure the setting is present and set to . Client drive redirection Allowed
If these settings are disabled, client network drives are not mapped and users cannot access these
drives manually, regardless of the state of the setting. Client network drives
To ensure network drives are automatically connected when users log on, configure the Auto connect
setting. client drives
Related Policy Settings
Client drive redirection
Auto connect client drives
Client optical drives
This setting allows or prevents users from accessing or saving files to CD-ROM, DVD-ROM, and BD-ROM drives
on the user device. By default, accessing client optical drives is allowed.
When allowing this setting, make sure the setting is present and set to . Client drive redirection Allowed
If these settings are disabled, client optical drives are not mapped and users cannot access these
drives manually, regardless of the state of the setting. Client optical drives
To ensure optical drives are automatically connected when users log on, configure the Auto connect
setting. client drives
Related Policy Settings
Client drive redirection
Auto connect client drives
Client removable drives
This setting allows or prevents users from accessing or saving files to USB drives on the user device. By
default, accessing client removable drives is allowed.
When allowing this setting, make sure the setting is present and set to . Client drive redirection Allowed
If these settings are disabled, client removable drives are not mapped and users cannot access these
drives manually, regardless of the state of the setting. Client removable drives
To ensure removable drives are automatically connected when users log on, configure the Auto connect
setting. client drives
Related Policy Settings
Client drive redirection
Auto connect client drives
Host to client redirection
This setting enables or disables file type associations for URLs and some media content to be opened on the
user device. When disabled, content opens on the server. By default, file type association is disabled.
These URL types are opened locally when you enable this setting:
Hypertext Transfer Protocol (HTTP)
Secure Hypertext Transfer Protocol (HTTPS)
Real Player and QuickTime (RTSP)
Real Player and QuickTime (RTSPU)
Legacy Real Player (PNM)
Microsoft’s Media Format (MMS)
Special folder redirection
This setting allows or prevents Citrix online plug-in and Web Interface users to see their local Documents
and Desktop special folders from a session. By default, special folder redirection is allowed.
This setting prevents any objects filtered through a policy from having special folder redirection, regardless
of settings that exist elsewhere. When you allow this setting, any related settings specified for the Web
Interface or Citrix online plug-in are ignored.
To define which users can have special folder redirection, select and include this setting in a Allowed
policy filtered on the users you want to have this feature. This setting overrides all other special folder
redirection settings throughout XenApp.
Because special folder redirection must interact with the user device, policy settings that prevent users
from accessing or saving files to their local hard drives also prevent special folder redirection from working. If
you enable the setting, make sure the setting is enabled as well. Special folder redirection Client fixed drives
For seamless applications and seamless and published desktops, special folder redirection works for
Documents and Desktops folders. Citrix does not recommend using special folder redirection with
published Windows Explorer.
Related Policy Settings
Client fixed drives
Auto connect client drives
Use asynchronous writes
This setting enables or disables asynchronous disk writes. By default, asynchronous writes are disabled.
Asynchronous disk writes can improve the speed of file transfers and writing to client disks over WANs, which
are typically characterized by relatively high bandwidth and high latency. However, if there is a connection or
disk fault, the client file or files being written may end in an undefined state. If this happens, a pop-up
window informs the user of the files affected. The user can then take remedial action, such as restarting
an interrupted file transfer on reconnection or when the disk fault is corrected.
Citrix recommends enabling asynchronous disk writes only for users who need remote connectivity with good
file access speed and who can easily recover files or data lost in the event of connection or disk failure.
When enabling this setting, make sure that the setting is present and set to Client drive redirection Allowed
. If this setting is disabled, asynchronous writes will not occur.
Related Policy Settings
Client drive redirection
6.12.2.8. HDX MediaStream for Flash Policy Settings
Updated: 2010-09-15
The HDX MediaStream for Flash section contains policy settings for handling Flash content in user sessions.
Flash acceleration
This setting enables or disables Flash content rendering on user devices instead of the server. By default,
client-side Flash content rendering is enabled.
When enabled, this setting reduces network and server load by rendering Flash content on the user
device. Additionally, the setting forces Flash content from specific Web sites to be Flash URL blacklist
rendered on the server.
When this setting is disabled, Flash content from all Web sites, regardless of URL, is rendered on the server.
To allow only certain Web sites to render Flash content on the user device, configure the Flash server-
setting. side content fetching whitelist
Flash event logging
This setting allows or prevents Flash events to be recorded in the Windows application event log. By
default, logging is allowed.
Flash latency threshold
This setting specifies a threshold between 0-30 milliseconds to determine where Adobe Flash content is
rendered. By default, the threshold is 30 milliseconds.
During startup, HDX MediaStream for Flash measures the current latency between the server and user device.
If the latency is under the threshold, HDX MediaStream for Flash is used to render Flash content on the
user device. If the latency is above the threshold, the network server renders the content if an Adobe Flash
player is available there.
Flash server-side content fetching whitelist
This setting specifies Web sites whose Flash content is allowed to be downloaded to the server and
then transferred to the user device for rendering. Flash content on unlisted Web sites is downloaded directly
to the client.
When adding this setting to a policy, make sure the setting is present and set to Flash acceleration Enabled
. Otherwise, Web sites listed in the whitelist are ignored.
Listed URL strings do not need the https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid
at the beginning and end of a URL.
Flash URL blacklist
This setting specifies Web sites whose Flash content is rendered on the server. Flash content on unlisted
Web sites is rendered on the user device.
When adding this setting to a policy, make sure the setting is present and set to Flash acceleration Enabled
. Otherwise, Web sites listed in the URL blacklist are ignored.
Listed URL strings do not need the https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid
at the beginning and end of a URL.
6.12.2.9. Keep Alive Policy Settings
Updated: 2010-06-07
The Keep Alive section contains policy settings for managing ICA keep-alive messages.
ICA keep alive timeout
This setting specifies the number of seconds between successive ICA keep-alive messages. By default,
the interval between keep-alive messages is 60 seconds.
Specify an interval between 1-3600 seconds in which to send ICA keep-alive messages. Do not configure
this setting if your network monitoring software is responsible for closing inactive connections. If using
Citrix Access Gateway, set keep-alive intervals on the Access Gateway to match the keep-alive intervals
on XenApp.
ICA keep alives
This setting enables or disables sending ICA keep-alive messages periodically. By default, keep-alive
messages are not sent.
Enabling this setting prevents broken connections from being disconnected. If XenApp detects no activity,
this setting prevents Remote Desktop Services from disconnecting the session. XenApp sends keep-
alive messages every few seconds to detect if the session is active. If the session is no longer active,
XenApp marks the session as disconnected.
ICA Keep-Alive does not work if you are using Session Reliability. Configure ICA Keep-Alive only for
connections that are not using Session Reliability.
Related Policy Settings
Session reliability connections
6.12.2.10. HDX Multimedia for Flash Policy Settings
Updated: 2010-03-12
The HDX Multimedia for Flash section contains policy settings for handling Flash content on session hosts.
Flash quality adjustment
This setting adjusts the quality of Flash content rendered on session hosts to improve performance. By
default, Flash content is optimized for low bandwidth connections only.
6.12.2.11. Multimedia Policy Settings
Updated: 2010-03-10
The Multimedia section contains policy settings for managing streaming audio and video in user sessions.
HDX MediaStream Multimedia Acceleration
This setting controls and optimizes the way XenApp servers deliver streaming audio and video to users.
By default, this setting is allowed.
Allowing this setting increases the quality of audio and video rendered from the server to a level that
compares with audio and video played locally on a client device. XenApp streams multimedia to the client in
the original, compressed form and allows the client device to decompress and render the media.
HDX MediaStream multimedia acceleration optimizes multimedia files that are encoded with codecs that adhere
to Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation standards. To play back a
given multimedia file, a codec compatible with the encoding format of the multimedia file must be present on
the client device.
By default, audio is disabled on the Citrix online plug-in. To allow users to run multimedia applications in
ICA sessions, turn on audio or give the users permission to turn on audio themselves in their plug-in interface.
Select only if playing media using multimedia acceleration appears worse than when rendered Prohibited
using basic ICA compression and regular audio. This is rare but can happen under low bandwidth conditions;
for example, with media in which there is a very low frequency of key frames.
HDX MediaStream Multimedia Acceleration default buffer size
This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size
is 5 seconds.
HDX MediaStream Multimedia Acceleration default buffer size use
This setting enables or disables using the buffer size specified in the HDX MediaStream
setting. By default, the buffer size specified is used. Multimedia Acceleration default buffer size
Multimedia conferencing
This setting allows or prevents support for video conferencing applications. By default, video conferencing
support is enabled.
When adding this setting to a policy, make sure the setting HDX Mediastream Multimedia Acceleration
is present and set to . Allowed
When using multimedia conferencing, make sure the following conditions are met:
Manufacturer-supplied drivers for the web cam used for multimedia conferencing must be installed.
The web cam must be connected to the client device before initiating a video conferencing session.
XenApp uses only one installed web cam at any given time. If multiple web cams are installed on the
client device, XenApp attempts to use each web cam in succession until a video conferencing session
is created successfully.
An Office Communicator server must be present in your farm environment.
The Office Communicator client software must be published on the server.
6.12.2.12. Multimedia Policy Settings
Updated: 2010-10-26
The Multimedia section contains policy settings for managing streaming audio and video in user sessions.
HDX MediaStream Multimedia Acceleration
This setting controls and optimizes the way XenApp servers deliver streaming audio and video to users.
By default, this setting is allowed.
Allowing this setting increases the quality of audio and video rendered from the server to a level that
compares with audio and video played locally on a client device. XenApp streams multimedia to the client in
the original, compressed form and allows the client device to decompress and render the media.
HDX MediaStream multimedia acceleration optimizes multimedia files that are encoded with codecs that adhere
to Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation standards. To play back a
given multimedia file, a codec compatible with the encoding format of the multimedia file must be present on
the client device.
By default, audio is disabled on the Citrix online plug-in. To allow users to run multimedia applications in
ICA sessions, turn on audio or give the users permission to turn on audio themselves in their plug-in interface.
Select only if playing media using multimedia acceleration appears worse than when rendered Prohibited
using basic ICA compression and regular audio. This is rare but can happen under low bandwidth conditions;
for example, with media in which there is a very low frequency of key frames.
HDX MediaStream Multimedia Acceleration buffer size
This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size
is 5 seconds.
HDX MediaStream Multimedia Acceleration buffer size use
This setting enables or disables using the buffer size specified in the HDX MediaStream
setting. By default, the buffer size specified is used. Multimedia Acceleration default buffer size
6.12.2.13. Ports Policy Settings
Updated: 2010-03-10
The Ports section contains policy settings for client LPT and COM port mapping.
Auto connect client COM ports
This setting enables or disables automatic connection of COM ports on user devices when users log on to
the farm. By default, client COM ports are not automatically connected.
Related Policy Settings
Client COM port redirection
Auto connect client LPT ports
This setting enables or disables automatic connection of LPT ports on user devices when users log on to the
farm. By default, client LPT ports are not connected automatically.
Related Policy Settings
Client LPT port redirection
Client COM port redirection
This setting allows or prevents access to COM ports on the user device. By default, COM port redirection
is allowed.
Related Policy Settings
Auto connect client COM ports
COM port redirection bandwidth limit
COM port redirection bandwith limit percent
Client LPT port redirection
This setting allows or prevents access to LPT ports on the user device. By default, LPT port redirection is allowed.
LPT ports are used only by legacy applications that send print jobs to the LPT ports and not to the print objects
on the client device. Most applications today can send print jobs to printer objects. This policy setting is
necessary only for servers that host legacy applications that print to LPT ports.
Related Policy Settings
Auto connect client LPT ports
LPT port redirection bandwidth limit
LPT port redirection bandwith limit percent
6.12.2.14. Printing Policy Settings
Updated: 2010-06-07
The Printing section contains policy settings for managing client printing.
Client printer redirection
This setting allows or prevents client printers to be mapped to a server when a user logs on to a session.
By default, client printer mapping is allowed.
Related Policy Settings
Auto-create client printers
Default printer
This setting specifies how the default printer on the user device is established in a session. By default, the
user's current printer is used as the default printer for the session.
To use the current Remote Desktop Services or Windows user profile setting for the default printer, select Do
. If you choose this option, the default printer is not saved in the not adjust the user’s default printer
profile and it does not change according to other session or client properties. The default printer in a session
will be the first printer autocreated in the session, which is either:
The first printer added locally to the Windows server in Control Panel > Printers
The first autocreated printer, if there are no printers added locally to the server
You can use this option to present users with the nearest printer through profile settings (known as
Proximity Printing).
Printer auto-creation event log preference
This setting specifies the events that are logged during the printer auto-creation process. You can choose to
log no errors or warnings, only errors, or errors and warnings. By default, errors and warnings are logged.
An example of a warning is an event in which a printer’s native driver could not be installed and the
universal printer driver is installed instead. To allow universal printer drivers to be used in this scenario,
configure the setting to or Universal printing Use universal printing only Use universal printing only
. if requested driver is unavailable
Related Policy Settings
Universal printing
Session printers
This setting specifies the network printers to be auto-created in a session. You can add printers to the list,
edit the settings of a list entry, or remove printers from the list. You can apply customized settings for the
current session at every logon.
Wait for printers to be created (desktop)
This setting allows or prevents a delay in connecting to a session so that desktop printers can be auto-created.
By default, a connection delay does not occur. This setting does not apply to published applications or
published desktops.
6.12.2.14.1. Client Printers Policy Settings
Updated: 2010-06-07
The Client Printers section contains policy settings for client printers, including settings to autocreate
client printers, use legacy printer names, retain printer properties, and connect to print servers.
Auto create client printers
This setting specifies the client printers that are auto-created. This setting overrides default client printer
auto-creation settings. By default, all client printers are auto-created.
This setting takes effect only if the setting is present and set to . Client printer redirection Allowed
When adding this setting to a policy, select an option:
Auto-create all client printers automatically creates all printers on a user device.
Auto-create the client’s default printer only automatically creates only the printer selected as
the default printer on the user device.
Auto-create local (non-network) client printers only automatically creates only printers
directly connected to the user device through an LPT, COM, USB, or other local port.
Do not auto-create client printers turns off autocreate for all client printers when users log on.
This causes the Remote Desktop Services settings for autocreating client printers to override this setting
in lower priority policies.
Related Policy Settings
Client printer redirection
Client printer names
This setting selects the naming convention for auto-created client printers. By default, standard printer names
are used.
For most configurations, select which are similar to those created by native Standard printer names
Remote Desktop Services, such as “HPLaserJet 4 from clientname in session 3.”
Select to use old-style client printer names and preserve backward compatibility Legacy printer names
for users or groups using MetaFrame Presentation Server 3.0 or earlier. An example of a legacy printer name
is “Client/clientname#/HPLaserJet 4.” Because this option is less secure, use it only to provide
backward compatibility for users or groups using MetaFrame Presentation Server 3.0 or earlier.
Direct connections to print servers
This setting enables or disables direct connections from the host to a print server for client printers hosted on
an accessible network share. By default, direct connections are enabled.
Allow direct connections if the network print server is not across a WAN from the host. Direct
communication results in faster printing if the network print server and host server are on the same LAN.
If this setting is disabled, print jobs are routed through the user device, where it is redirected to the network
print server. Use this option if the network is across a WAN or has substantial latency or limited bandwidth.
Data sent to the user device is compressed, so less bandwidth is consumed as the data travels across the WAN.
If two network printers have the same name, the printer on the same network as the user device is used.
Printer properties retention
This setting specifies whether or not to store printer properties and where to store them. By default, the
system determines if printer properties are to be stored on the user device, if available, or in the user profile.
When adding this setting to a policy, select an option:
Held in profile only if not saved on client allows the system to determine where printer properties
are stored. Printer properties are stored either on the client device, if available, or in the user
profile. Although this option is the most flexible, it can also slow logon time and use extra bandwidth
for system-checking.
Saved on the client device only is for user devices that have a mandatory or roaming profile that is
not saved. Choose this option only if all the servers in your farm are running XenApp 5 and above and
your users are using Citrix XenApp online plug-in versions 9.x and above.
Retained in user profile only is for user devices constrained by bandwidth (this option reduces
network traffic) and logon speed or for users with legacy plug-ins. This option stores printer properties
in the user profile on the server and prevents any properties exchange with the client device. Use
this option with MetaFrame Presentation Server 3.0 or earlier and MetaFrame Presentation Server Client 8.x
or earlier. Note that this is applicable only if a Remote Desktop Services roaming profile is used.
Retained and restored client printers
This setting enables or disables the retention and re-creation of printers on the user device. By default,
client printers are auto-retained and auto-restored.
Retained printers are user-created printers that are created again, or remembered, at the start of the
next session. When XenApp recreates a retained printer, it considers all policy settings except the Auto-
setting. create client printers
Restored printers are printers fully customized by an administrator, with a saved state that is
permanently attached to a client port.
6.12.2.14.2. Drivers Policy Settings
Updated: 2010-03-10
The Drivers section contains policy settings related to printer drivers.
Automatic installation of in-box printer drivers
This setting enables or disables the installation of Windows native drivers on the user device as needed.
By default, native drivers are installed when users log on.
Printer driver mapping and compatibility
This setting specifies driver substitution rules for auto-created printers. When you define these rules, you
can allow or prevent printers to be created with the specified driver. Additionally, you can allow created
printers to use only universal printer drivers.
Driver substitution overrides (or maps) printer driver names the client provides, substituting an equivalent
driver on the server. This gives server applications access to client printers that have the same drivers as
the server but different driver names.
You can add a driver mapping, edit an existing mapping, remove a mapping, or change the order of driver
entries in the list. When adding a mapping, enter the client printer driver name and then select the server
driver you want to substitute.
Related Policy Settings
Universal printing
Auto-create client printers
6.12.2.14.3. Universal Printing Policy Settings
Updated: 2010-03-10
The Universal Printing section contains policy settings for managing universal printing.
Auto-create generic universal printer
This setting enables or disables auto-creation of the Citrix Universal Printer generic printing object. By
default, generic universal printers are not auto-created.
Universal driver priority
This setting specifies the order in which XenApp attempts to use Universal Printer drivers, beginning with the
first entry in the list. You can add, edit, or remove drivers, and change the order of drivers in the list.
Universal printing
This setting specifies when to use universal printing. Universal printing consists of a generic printer object
(Citrix Universal Printer) and universal printer drivers that work with both Windows and non-Windows clients.
By default, universal printing is used only if the requested driver is unavailable.
When adding this setting to a policy, select an option:
Use universal printing only if requested driver is unavailable uses native drivers for client printers
if they are available. If the driver is not available on the server, the client printer is created
automatically with the appropriate universal driver.
Use only printer model specific drivers specifies that the client printer use only the native drivers
that are auto-created at logon. If the native driver of the printer is unavailable, the client printer cannot
be auto-created.
Use universal printing only specifies that no native drivers are used.
Use printer model specific drivers only if universal printing is unavailable uses the universal
printer driver if it is available. If the driver is not available on the server, the client printer is
created automatically with the appropriate native printer driver.
Universal printing preview preference
This setting specifies whether or not to use the print preview function for auto-created or generic
universal printers. By default, print preview is not used for auto-created or generic universal printers.
6.12.2.15. Security Policy Settings
Updated: 2010-03-10
The Security section contains policy settings for configuring session encryption and password requirements.
Prompt for password
This setting requires the user to enter a password for all server connections regardless of access scenario.
By default, users are prompted for passwords only for specific types of connections.
SecureICA Encryption
This setting specifies the minimum level at which to encrypt session data sent between the server and a
user device.
When adding this setting to a policy, select an option:
Basic encrypts the client connection using a non-RC5 algorithm. It protects the data stream from
being read directly, but it can be decrypted. By default, the server uses Basic encryption for client-
server traffic.
RC5 (128 bit) logon only encrypts the logon data with RC5 128-bit encryption and the client
connection using Basic encryption.
RC5 (40 bit) encrypts the client connection with RC5 40-bit encryption.
RC5 (56 bit) encrypts the client connection with RC5 56-bit encryption.
RC5 (128 bit) encrypts the client connection with RC5 128-bit encryption.
The settings you specify for client-server encryption can interact with any other encryption settings in XenApp
and your Windows operating system. If a higher priority encryption level is set on either a server or user
device, settings you specify for published resources can be overridden.
You can raise encryption levels to further secure communications and message integrity for certain users. If
a policy requires a higher encryption level, plug-ins using a lower encryption level are denied connection.
SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for
your server farm, use SecureICA with SSL/TLS encryption.
SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server and plug-ins to
avoid using SecureICA.
6.12.2.16. Server Limits Policy Settings
Updated: 2010-03-10
The Server Limits section contains policy settings for controlling idle connections.
Server idle timer interval
This setting determines, in milliseconds, how long an uninterrupted user session will be maintained if there is
no input from the user. By default, idle connections are not disconnected (Server idle timer interval = 0).
6.12.2.17. Session Limits Policy Settings
Updated: 2010-03-10
The Session Limits section contains policy settings you can use to control the number of connections users
can make and how long sessions remain connected before they are forced to log off.
Concurrent logon limit
This setting specifies the maximum number of connections a user can make to the server farm at any given
time. The user’s active and disconnected sessions are counted for the user’s total number of
concurrent connections. This setting reduces the number of client connection licenses in use and
conserves resources. By default, there is no limit on concurrent connections.
Related Policy Settings
Limits on administrator sessions
Limit user sessions
6.12.2.18. Session Reliability Policy Settings
Updated: 2010-03-10
The Session Reliability section contains policy settings for managing session reliability connections.
Session reliability connections
This setting allows or prevents sessions to remain open during a loss of network connectivity. By default,
session reliability is allowed.
Session Reliability keeps sessions active when network connectivity is interrupted. Users continue to see
the application they are using until network connectivity resumes.
When connectivity is momentarily lost, the session remains active on the server. The user’s display freezes
and the cursor changes to a spinning hourglass until connectivity resumes. The user continues to access
the display during the interruption and can resume interacting with the application when the network
connection is restored. Session Reliability reconnects users without reauthentication prompts.
If you do not want users to be able to reconnect to interrupted sessions without having to
reauthenticate, configure the setting to require authentication. Users Auto client reconnect authentication
are then prompted to reauthenticate when reconnecting to interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence.
Session Reliability closes, or disconnects, the user session after the amount of time you specify in the
setting. After that, the settings you configure for Auto Client Reconnect take Session reliability timeout
effect, attempting to reconnect the user to the disconnected session.
Related Policy Settings
Auto client reconnect
Auto client reconnect authentication
Session reliability port number
This setting specifies the TCP port number for incoming session reliability connections.
Session reliability timeout
This setting specifies the length of time in seconds the session reliability proxy waits for a client to
reconnect before allowing the session to be disconnected.
The default length of time is 180 seconds, or three minutes. Though you can extend the amount of time a
session is kept open, this feature is designed to be convenient to the user and it does not prompt the user
for reauthentication. If you extend the amount of time a session is kept open indiscriminately, chances
increase that a user may get distracted and walk away from the client device, potentially leaving the
session accessible to unauthorized users.
If you do not want users to be able to reconnect to interrupted sessions without having to
reauthenticate, configure the setting to require authentication. Users Auto client reconnect authentication
are then prompted to reauthenticate when reconnecting to interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence.
Session Reliability closes, or disconnects, the user session after the amount of time you specify in the
setting. After that, the settings you configure for Auto Client Reconnect take Session reliability timeout
effect, attempting to reconnect the user to the disconnected session.
Related Policy Settings
Auto client reconnect
Auto client reconnect authentication
6.12.2.19. Shadowing Policy Settings
Updated: 2010-03-10
The Shadowing section contains policy settings related to user-to-user shadowing. Shadowing is useful
for training purposes and for viewing presentations. You can also allow help desk personnel to shadow users
so they can troubleshoot user problems.
Input from shadow connections
This setting allows or prevents shadowing users to take control of the keyboard and mouse of the user
being shadowed during a shadowing session. By default, the person shadowing can send input to the
session being shadowed.
Log shadow attempts
This setting allows or prevents recording of attempted shadowing sessions in the Windows event log. By
default, shadowing attempts are logged.
Several different event types are recorded in the Windows Event log. These include user shadowing
requests, such as when users stop shadowing, failure to launch shadowing, and access to shadowing denials.
Notify user of pending shadow connections
This setting allows or prevents shadowed users from receiving notification of shadowing requests from
other users. When a user receives a shadowing request, the user can accept or deny the request. By
default, users are not notified when they are being shadowed.
Shadowing
This setting allows or prevents users from shadowing other users’ sessions. By default, administrators can
shadow users’ sessions. When you add this setting to a policy, specify the users allowed to shadow by
configuring the and Users who can shadow other users Users who cannot shadow other users
policy settings.
Session shadowing monitors and interacts with user sessions. When you shadow a user session, you can
view everything that appears on the user’s session display. You can also use your keyboard and mouse
to remotely interact with the user session.
Shadowing is protocol-specific. This means you can shadow ICA sessions over ICA and Remote Desktop
Protocol (RDP) sessions over RDP only.
Shadowing restrictions are set at install time and are permanent. If you enable or disable shadowing, or
certain shadowing features during Setup, you cannot change these restrictions later. You must reinstall
XenApp on the server to change shadowing restrictions.
Any user policies you create to enable user-to-user shadowing are subject to the restrictions you place
on shadowing during Setup.
Users who can shadow other users
This setting specifies the users who are allowed to shadow other users.
Users who cannot shadow other users
This setting specifies the users who are not allowed to shadow other users.
6.12.2.20. Time Zone Control Policy Settings
Updated: 2010-08-02
The Time Zone Control section contains policy settings related to using local time in sessions.
Local Time Estimation
This setting enables or disables estimating the local time zone of user devices that send inaccurate time
zone information to the server. By default, the server estimates the local time zone when necessary.
Use local time of client
This setting determines the time zone setting of the user session. When enabled, the administrator can choose
to default the user session’s time zone settings to that of the user’s time zone settings. By default, the server’
s time zone is used for the session.
For this setting to take effect, enable the setting in the Remote Desktop Allow time zone redirection
Session Host node of the Group Policy Management Editor ( > Administrative Templates
> > > Windows Components Remote Desktop Services Remote Desktop Session Host Device
). For more information about time zone redirection, refer to the Citrix and Resource Redirection
Knowledge Center.
6.12.2.21. TWAIN Devices Policy Settings
Updated: 2010-03-10
The TWAIN devices section contains policy settings related to mapping client TWAIN devices, such as
digital cameras or scanners, and optimizing image transfers from server to client.
Client TWAIN device redirection
This setting allows or prevents users from accessing TWAIN devices on the user device from published
image processing applications. By default, TWAIN device redirection is allowed.
Related Policy Settings
TWAIN compression level
TWAIN device redirection bandwidth limit
TWAIN device redirection bandwidth limit percent
TWAIN compression level
This setting specifies the level of compression of image transfers from client to server. Use for best Low
image quality, for good image quality, or for low image quality. By default, no compression applied. Medium High
6.12.2.22. USB Devices Policy Settings
Updated: 2010-09-24
The USB devices section contains policy settings for managing file redirection for USB devices.
Client USB device redirection
This setting allows or prevents redirection of USB devices to and from the client (workstation hosts only).
By default, USB devices are not redirected.
Client USB device redirection rules
This setting specifies redirection rules for USB devices.
When a user plugs in a USB device, the host device checks it against each policy rule in turn until a match
is found. The first match for any device is considered definitive. If the first match is an Allow rule, the device
is remoted to the virtual desktop. If the first match is a Deny rule, the device is available only to the
local desktop. If no match is found, default rules are used. For more information about the default
policy configuration for USB devices, refer to CTX119722, “Creating USB Policy Rules,” in the Citrix
Knowledge Center.
Policy rules take the format {Allow:|Deny:} followed by a set of tag= value expressions separated by
whitespace. The following tags are supported:
VID
Vendor ID from the device descriptor
PID
Product ID from the device descriptor
REL
Release ID from the device descriptor
Class
Class from either the device descriptor or an interface descriptor
SubClass
Subclass from either the device descriptor or an interface descriptor
Prot
Protocol from either the device descriptor or an interface descriptor
When creating new policy rules, be aware of the following:
Rules are case-insensitive.
Rules may have an optional comment at the end, introduced by #.
Blank and pure comment lines are ignored.
Tags must use the matching operator =. For example, VID=1230.
Each rule must start on a new line or form part of a semicolon-separated list.
Refer to the USB class codes available from the USB Implementers Forum, Inc. Web site.
Examples of administrator-defined USB policy rules
Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive
Deny: Class=08 subclass=05 # Mass Storage
To create a rule that denies all USB devices, use “DENY:” with no other tags.
6.12.2.23. Virtual IP Policy Settings
Updated: 2010-03-10
The Virtual IP section contains policy settings for configuring Virtual IP support for applications.
Virtual IP adapter address filtering
This setting enables or disables filtering of the list of addresses returned by the GetAdaptersAddresses()
function to only include the session virtual IP address and the loopback address. By default, the list of
adapter addresses is not filtered.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. Additionally, enable the policy setting. If these Virtual IP enhanced compatibility
settings are not configured, filtering does not occur.
After enabling this setting, configure the to add Virtual IP filter adapter addresses programs list
the applications whose overhead can be reduced through adapter address filtering.
Virtual IP compatibility programs list
This setting specifies the application processes that can use virtual IP addresses. When adding programs to
the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP enhanced compatibility
This setting enables or disables additional support of Windows Remote Desktop IP virtualization. This allows
calls to the gethostbyname() function within sessions to return the assigned virtual IP address for the session.
By default, this setting is disabled.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. If this setting is not configured, additional support does not occur.
After enabling this setting, configure the setting to add Virtual IP enhanced compatibility programs list
the applications that can use virtual IP addresses.
Virtual IP filter adapter addresses programs list
This setting specifies the application executables that can use filter adapter addresses. When adding programs
to the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP loopback support
This setting enables or disables the use of virtual loopback addresses in sessions. By default, sessions do not
have virtual loopback addresses.
After enabling this setting, configure the to add the applications Virtual IP virtual loopback programs list
that can use virtual loopback addresses.
Virtual IP virtual loopback programs list
This setting specifies the application executables that can use virtual loopback addresses. When adding
programs to the list, specify only the executable name. It is not necessary to specify the entire path.
6.12.2.23.1. Virtual IP Policy Settings
Updated: 2010-03-10
The Virtual IP section contains policy settings for configuring Virtual IP support for applications.
Virtual IP adapter address filtering
This setting enables or disables filtering of the list of addresses returned by the GetAdaptersAddresses()
function to only include the session virtual IP address and the loopback address. By default, the list of
adapter addresses is not filtered.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. Additionally, enable the policy setting. If these Virtual IP enhanced compatibility
settings are not configured, filtering does not occur.
After enabling this setting, configure the to add Virtual IP filter adapter addresses programs list
the applications whose overhead can be reduced through adapter address filtering.
Virtual IP compatibility programs list
This setting specifies the application processes that can use virtual IP addresses. When adding programs to
the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP enhanced compatibility
This setting enables or disables additional support of Windows Remote Desktop IP virtualization. This allows
calls to the gethostbyname() function within sessions to return the assigned virtual IP address for the session.
By default, this setting is disabled.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. If this setting is not configured, additional support does not occur.
After enabling this setting, configure the setting to add Virtual IP enhanced compatibility programs list
the applications that can use virtual IP addresses.
Virtual IP filter adapter addresses programs list
This setting specifies the application executables that can use filter adapter addresses. When adding programs
to the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP loopback support
This setting enables or disables the use of virtual loopback addresses in sessions. By default, sessions do not
have virtual loopback addresses.
After enabling this setting, configure the to add the applications Virtual IP virtual loopback programs list
that can use virtual loopback addresses.
Virtual IP virtual loopback programs list
This setting specifies the application executables that can use virtual loopback addresses. When adding
programs to the list, specify only the executable name. It is not necessary to specify the entire path.
6.12.2.23.2. Image Compression Policy Settings
Updated: 2010-03-10
The Image compression section contains settings that enable you to remove or alter compression. When
client connections are limited in bandwidth, downloading images without compression can be slow.
Lossy compression level
This setting controls the degree of lossy compression used on images delivered over client connections that
are limited in bandwidth. In such cases, displaying images without compression can be slow. By default,
medium compression is selected.
For improved responsiveness with bandwidth-intensive images, use high compression. Where preserving
image data is vital; for example, when displaying X-ray images where no loss of quality is acceptable, you
may not want to use lossy compression.
Related Policy Settings
Lossy compression threshold value
Progressive compression level
Progressive heavyweight compression level
Lossy compression threshold value
This setting represents the maximum bandwidth in kilobits per second for a connection to which
lossy compression is applied. By default, the threshold value is 2000 kilobits per second.
Adding the setting to a policy and including no specified threshold can improve Lossy compression level
the display speed of high-detail bitmaps, such as photographs, over a LAN.
Related Policy Settings
Lossy compression level
Progressive compression level
This setting provides a less detailed but faster initial display of images. The more detailed image, defined by
the normal lossy compression setting, appears when it becomes available. Use very high or ultra
high compression for improved viewing of bandwidth-intensive graphics such as photographs.
For progressive compression to be effective, its compression level must be higher than the Lossy
setting; by default, progressive compression is not applied. compression level
Note: The increased level of compression associated with progressive compression also enhances
the interactivity of dynamic images over client connections. The quality of a dynamic image, such as a
rotating three-dimensional model, is temporarily decreased until the image stops moving, at which time
the normal lossy compression setting is applied.
Related Policy Settings
Progressive compression threshold value
Lossy compression level
Progressive heavyweight compression
Progressive compression threshold value
The maximum bandwidth in kilobits per second for a connection to which progressive compression is applied.
This is applied only to client connections under this bandwidth. By default, the threshold value is 1440 kilobits
per second.
Related Policy Settings
Progressive compression level
Progressive heavyweight compression
This setting enables or disables reducing bandwidth beyond progressive compression without losing image
quality by using a more advanced, but more CPU-intensive, graphical algorithm. By default,
progressive heavyweight compression is disabled.
If enabled, heavyweight compression applies to all lossy compression settings. It is supported on the Citrix
online plug-in but has no effect on other plugins.
Related Policy Settings
Lossy compression level
Progressive compression level
6.12.3. Licensing Policy Settings
Updated: 2010-03-10
The Licensing section contains policy settings for configuring Citrix Licensing.
License server host name
This setting specifies the name of the server hosting XenApp licenses.
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 server’s host name, you must download
a license file that is generated for the new license server if you decide to change the server’s name. This
may involve returning and reallocating the licenses.
License server port
This setting specifies the port number of the server hosting XenApp licenses.
If you change the port number of the license server, specify a new number in all the license files on the server.
6.12.4. Multi-Stream Connections Policy Settings
Updated: 2010-10-27
The Multi-Stream section contains policy settings for managing Quality of Service (QoS) prioritization for
multiple ICA connections in a session.
Multi-Port Policy
This setting specifies the TCP ports to be used for ICA traffic and establishes the network priority for each port.
By default, the primary port (1494) has a High priority.
When you configure additional ports, you can assign the following priorities:
Very High
High
Medium
Low
You might assign a Very High priority when real-time responsiveness is required, such as for audio and
video conferencing. As well, you might assign a Low priority to background processes such as printing. Each
port must have a unique priority. For example, you cannot assign a Very High priority to both CGP port 1 and
CGP port 3.
This setting takes effect only in sessions that have the Multi-Stream Computer policy setting enabled.
Related Policy Settings:
Multi-Stream Policy (Computer Configuration)
Multi-Stream Policy (Computer Configuration)
This setting enables or disables multi-stream on the XenApp server. By default, Multi-Stream is disabled.
Multi-Stream Policy (User Configuration)
This setting enables or disables multi-stream on the user device. By default, this setting is enabled.
This setting takes effect only on hosts where the Multi-Stream Computer policy setting is enabled.
Related Policy Settings:
Multi-Stream Policy (User Configuration)
6.12.5. Server Policy Settings
Updated: 2010-03-10
The Server Settings section contains policy settings for configuring access control, DNS address resolution,
icon handling, and XenApp edition.
Connection access control
This setting specifies the types of client connections from which users can start sessions.
When adding this setting to a policy, select an option:
Any connections (selected by default) allows access to published applications through any connection.
allows access Citrix Access Gateway, Citrix online plug-in, and Web Interface connections only
to published applications through the listed connections, including any version of Access Gateway.
This option denies access through any other connection.
Citrix Access Gateway connections only allows access to published applications only through
Access Gateway Advanced Edition servers (Version 4.0 or later).
DNS address resolution
This setting enables or disables the server to return fully qualified domain names to clients using the Citrix
XML Service.
DNS address resolution works only in server farms that contain servers running MetaFrame XP Feature Release
1 or later, and clients must be using Presentation Server Client Version 6.20.985 or later or Citrix XenApp
Plugin for Hosted Apps version 11. . x
Full icon caching
This setting enables or disables the caching of larger, high resolution published application icons on farm
servers. By default, icons are cached.
To ensure only specific farm servers are affected by this setting, configure a worker group that includes only
the servers you specify. Then, include the worker group in the filter you add to the policy. If no filter is
specified, this setting affects all farm servers.
Consider disabling this setting if caching icons impacts performance of the server. However, do not disable
this setting on servers acting as XML brokers for the farm.
XenApp product edition
This setting specifies the XenApp product edition.
Setting the product edition activates the features available with a particular edition. The product edition
also determines which type of license a server requests from the license server. Make sure the edition you
set matches the licenses that are installed.
6.12.5.1. Connection Limits Policy Settings
Updated: 2010-03-10
The Connection Limits section contains policy settings for controlling user and administrator sessions and
logon event logging.
Limit user sessions
This setting specifies the maximum number of connections that users can establish, in the range 0-8192. A
value of 0 indicates no connections.
When a user tries to establish a connection in excess of this limit, a message tells the user the connection is
not allowed. When a connection request is denied, the server records the user’s name and time in the System log.
Related Policy Settings
Concurrent logon limit
Limits on administrator sessions
This setting enables or disables connection limit enforcement for Citrix administrators. Limiting connections
for Citrix administrators can adversely affect their ability to shadow other users. By default, administrators
are exempt from connection limits.
Logging of logon events
This setting enables or disables the logging of events (to the server event log) about connection attempts
that were denied because they exceeded logon limits. By default, these events are not logged.
6.12.5.2. Connection Limits Policy Settings
Updated: 2010-03-10
The Connection Limits section contains policy settings for controlling user and administrator sessions and
logon event logging.
Limit user sessions
This setting specifies the maximum number of connections that users can establish, in the range 0-8192. A
value of 0 indicates no connections.
When a user tries to establish a connection in excess of this limit, a message tells the user the connection is
not allowed. When a connection request is denied, the server records the user’s name and time in the System log.
Related Policy Settings
Concurrent logon limit
Limits on administrator sessions
This setting enables or disables connection limit enforcement for Citrix administrators. Limiting connections
for Citrix administrators can adversely affect their ability to shadow other users. By default, administrators
are exempt from connection limits.
Logging of logon events
This setting enables or disables the logging of events (to the server event log) about connection attempts
that were denied because they exceeded logon limits. By default, these events are not logged.
6.12.5.3. Health Monitoring and Recovery Policy Settings
Updated: 2010-06-07
The Health Monitoring and Recovery section contains policy settings for configuring Health Monitoring
and Recovery tests and server load balancing exclusions.
Health monitoring
This setting allows or prevents running Health Monitoring and Recovery tests on the farm servers. By
default, Health Monitoring and Recovery tests are allowed to run.
Health monitoring tests
This setting specifies which Health Monitoring Tests to run. You can add or remove tests. You can also edit
the configuration of a test (name, location, description, interval, threshold, time-out and recovery action).
By default, the following Citrix tests are run:
Citrix IMA Service
Logon Monitor
XML Service
Remote Desktop Services
Maximum percent of offline servers
This setting specifies the maximum percentage of servers that Health Monitoring and Recovery can exclude
from load balancing. By default, ten percent of servers are excluded.
6.12.5.4. Memory Optimization Policy Settings
Updated: 2010-03-10
The Memory/CPU section contains policy settings for managing CPU utilization and memory optimization.
CPU management server level
This setting specifies the level of CPU utilization management on the server. Managing CPU resources
can normalize CPU peaks and reduce the resources required to handle CPU spikes. By default, CPU utilization
is not managed.
When adding this setting to a policy, select an option:
No CPU utilization management disables CPU utilization management on the server.
Fair sharing of CPU between sessions ensures that CPU resources are equitably shared among users
by having the server allocate an equal share of CPU to each user.
Preferential Load Balancing allocates more CPU resources to one user over another based on
the resource allotment for each session. The resource allotment is determined by the importance levels
of both the published application running in the session and the session itself.
Note: To use CPU Utilization Management, ensure the Fair Share CPU Scheduling (DFSS) feature of
Remote Desktop Services is disabled on the server.
Related Policy Settings
Session importance
Memory optimization
This setting enables or disables memory optimization. Enabling memory optimization improves the ability
to manage DLL allocation in both real and overall virtual memory by creating shared DLLs for applications that
are open in multiple sessions. By default, this setting is disabled.
Memory optimization application exclusion list
This setting specifies the applications that memory optimization should ignore. You can add, edit, or
delete applications in the list.
Memory optimization interval
This setting specifies the interval for running memory optimization. By default, memory optimization runs daily.
When adding this setting to a policy, make sure the setting is present and set to . Memory optimization Enabled
Memory optimization schedule: day of month
This setting specifies the day of the month that memory optimization runs, in the range 1-31. By default,
memory optimization is scheduled for the first day of each month.
When adding this setting to a policy, make sure the following policy settings are present:
Memory optimization, set to Enabled
Memory optimization interval, set to Monthly
If the specified day does not occur in a given month (for example, the 30th day in February, or the 31st day
in April or June), memory optimization does not run in that month.
Memory optimization schedule: day of week
This setting specifies the day of the week that memory optimization runs. By default, memory optimization
runs on Sundays.
When adding this setting to a policy, make sure the following policy settings are present:
Memory optimization, set to Enabled
Memory optimization interval, set to Weekly
Memory optimization schedule: time
This setting specifies the time at which memory optimization runs. The time format is H:MM TT, where H is
the hour, MM is the minute, and TT is the time of day (AM or PM). By default, memory optimization runs at 3:
00 AM.
When adding this setting to a policy, make sure the following policy settings are present:
Memory optimization, set to Enabled
Memory optimization interval, set to or Daily, Weekly, Monthly
Memory optimization times are scheduled in the local time zone of the server and use a 12-hour clock. If
you enter a time according to a 24-hour clock, the time is converted automatically to a 12-hour clock. If
you enter a time without a TT value, the time defaults to AM.
6.12.5.5. Offline Applications Policy Settings
Updated: 2010-03-10
The Offline Applications section contains policy settings for controlling offline application access, licensing,
and logging.
Offline app client trust
This setting enables or disables the ability of offline application clients to recreate sessions when
reconnecting, without authenticating again. By default, users must authenticate when reconnecting to
offline applications.
Offline app event logging
This setting enables or disables logging of offline application events to the event log on the server. By
default, offline application events are not logged.
Offline app license period
This setting specifies the number of days applications can work offline before users have to renew the license.
The license period, 21 days by default, can range from 2 to 365 days. Licenses automatically renew at login
and every day while logged in. Changes to the license period occur when the license is renewed.
To configure licenses, administrators can use the License Administration Console or command-line tools.
They must also ensure they have a sufficient number of licenses to support the total number of users with
offline access permission.
Offline app users
This setting specifies the users who have permission to access offline applications. You can add or delete
users from this list.
Users in this group can continue using configured applications after disconnecting from the network for
the number of days specified in the setting. You must configure the applications Offline app license period
for offline access in the application properties.
The total number of users with offline access permission should not exceed the total number of licenses
available for offline access.
6.12.5.6. Reboot Behavior Policy Settings
Updated: 2010-03-10
The Reboot Behavior section contains policy settings for scheduling server restarts, disabling logons,
and configuring warning messages.
Reboot custom warning
This setting enables or disables sending a custom warning message (in addition to the standard restart
message) to users before a scheduled server restart. To specify the text for this warning, configure the
setting. By default, only the standard warning message is sent. Reboot custom warning text
Reboot custom warning text
This setting specifies the text in the custom warning message sent to users before a scheduled server restart.
To send a custom message, the setting must be enabled. Reboot custom warning
Reboot logon disable time
This setting specifies the number of minutes before a scheduled server restart that logons to the server
are disabled. By default, logons are disabled 60 minutes prior to server restart.
Reboot schedule frequency
This setting specifies the frequency, in days, that scheduled server restarts occur. By default, scheduled
restarts occur every 7 days (once each week).
Reboot schedule start date
This setting specifies the date on which scheduled server restarts begin, in the form MM/DD/YYYY.
Reboot schedule time
This setting specifies the time at which scheduled server restarts occur in the form H:MM TT, where H is the
hour, MM is the minute, and TT is the time of day (AM or PM). Restart times are scheduled in the local time
zone of the server and use a 12-hour clock.
If you enter a time according to a 24-hour clock, the time is converted automatically to a 12-hour clock. If
you enter a time without a TT value, the time of day defaults to AM.
Reboot warning interval
This setting specifies how often standard and custom warning messages are sent to users before a
scheduled restart. By default, messages are sent every 15 minutes.
Configure the setting to specify when to start sending the warning messages. Reboot warning start time
Reboot warning start time
This setting specifies the number of minutes before a scheduled server restart to send standard or
custom warnings to users. By default, messages are sent 60 minutes prior to server restart.
Configure the setting to specify how often the warning is sent. Reboot warning interval
Reboot warning to users
This setting enables or disables sending a standard warning message to users before a scheduled server
restart. By default, messages are not sent to users prior to server restarts.
To send a custom warning message (in addition to the standard message), enable the Reboot custom warning
setting and specify the text in the setting. Reboot custom warning text
Scheduled reboots
This setting enables or disables scheduled server restarts. You can configure automatic restarts at specific
times and frequencies, as well as the starting date of the schedule. By default, server reboots are not scheduled.
6.12.6. Server Session Settings
Updated: 2010-03-10
The Server Session Settings section contains policy settings for configuring session importance and Single
Sign-On.
Session importance
This setting specifies the importance level at which a session is run.
If the setting is configured for , CPU management server level No CPU utilization management
sessions with higher importance levels are allowed to use more CPU cycles than sessions with lower
importance levels.
If the setting is configured for , sessions CPU management server level Preferential Load Balancing
with higher importance levels are directed to servers with lower resource allotments.
Related Policy Settings
CPU Management Server Level
Single Sign-On
This setting enables or disables the use of Single Sign-on when users connect to servers or published
applications in a XenApp farm. By default, Single Sign-On is enabled.
Single Sign-On central store
This setting specifies the UNC path of the Single Sign-On central store to which users are allowed to connect.
Policies apply only to shared folders you configure to be Single Sign-On central stores. If you want this setting
to use the central store specified by the Single Sign-On plug-in, leave this field blank.
Server farm zone failover preferences apply only to published objects, not to central stores. If the user’s
preferred zone is not operating and the connection fails over to a backup zone, the user cannot access
published objects using Single Sign-On if the central store is in the failed zone.
6.12.7. Virtual IP Policy Settings
Updated: 2010-03-10
The Virtual IP section contains policy settings for configuring Virtual IP support for applications.
Virtual IP adapter address filtering
This setting enables or disables filtering of the list of addresses returned by the GetAdaptersAddresses()
function to only include the session virtual IP address and the loopback address. By default, the list of
adapter addresses is not filtered.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. Additionally, enable the policy setting. If these Virtual IP enhanced compatibility
settings are not configured, filtering does not occur.
After enabling this setting, configure the to add Virtual IP filter adapter addresses programs list
the applications whose overhead can be reduced through adapter address filtering.
Virtual IP compatibility programs list
This setting specifies the application processes that can use virtual IP addresses. When adding programs to
the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP enhanced compatibility
This setting enables or disables additional support of Windows Remote Desktop IP virtualization. This allows
calls to the gethostbyname() function within sessions to return the assigned virtual IP address for the session.
By default, this setting is disabled.
Before enabling this setting, make sure is enabled in Remote Desktop Session IP Virtualization
Host Configuration. If this setting is not configured, additional support does not occur.
After enabling this setting, configure the setting to add Virtual IP enhanced compatibility programs list
the applications that can use virtual IP addresses.
Virtual IP filter adapter addresses programs list
This setting specifies the application executables that can use filter adapter addresses. When adding programs
to the list, specify only the executable name. It is not necessary to specify the entire path.
Virtual IP loopback support
This setting enables or disables the use of virtual loopback addresses in sessions. By default, sessions do not
have virtual loopback addresses.
After enabling this setting, configure the to add the applications Virtual IP virtual loopback programs list
that can use virtual loopback addresses.
Virtual IP virtual loopback programs list
This setting specifies the application executables that can use virtual loopback addresses. When adding
programs to the list, specify only the executable name. It is not necessary to specify the entire path.
6.12.8. XML Service Policy Settings
Updated: 2010-03-10
The XML Service section contains policy settings for configuring the Citrix XML Service.
Trust XML requests
This setting specifies whether the Citrix XML Service should trust requests it receives. Before enabling this
rule, avoid security risks by using IPSec, firewalls, or another technology that ensures only trusted
services communicate with the Citrix XML Service.
XML Service port
This setting specifies the port number to use for the Citrix XML Service. To disable the port, enter 0 as the
port number. By default, the port is disabled.
When specifying the XML Service port number, the range of values you can enter is 1024-65535.
Citrix recommends using port 8080.
7. Application Streaming
Updated: 2009-12-01
Application streaming simplifies application delivery to users by virtualizing applications on client
devices. Administrators can install and configure an application centrally and deliver it to any desktop on demand.
Use the application streaming feature to install and configure an application on one file server in your App
Hub, publish the application using the XenApp publishing wizard, and deliver it to any desktop or server
on demand. To upgrade or patch an application, you make the updates only in the location where you stored
the application. Application streaming augments application delivery not only to user desktops, but also to
servers in your server farms.
Application streaming offers the following features:
Install once, deliver anywhere
Provides the ability to install an application once on a profiler workstation and have it replicated to file
servers within the existing enterprise infrastructure. Once there, the applications are delivered to client
devices that request access to the application, on-demand, as a result of end-user activity.
Seamless updates
No need to profile applications again. Updates are as simple as updating an application on a desktop using
the update program supplied by the manufacturer. The update is performed once on the profiler workstation
and delivered to client devices in a manner similar to that used in the initial delivery.
Application isolation
All streamed applications run within isolation environments that keep the applications from interfering with
others running on the same client device. The isolation environment is specific for the application and
user session, regardless of whether the user streams to the local client or virtualizes the streamed
application from a server. The specific data files of the application, such as INI files and registry keys, are
all isolated and maintained centrally for the streamed application.
Application caching
Application files can be cached on the client device to allow faster access the next time the application
is launched. Before an application runs, cached files are updated automatically if there is a newer version on
the file server. Note that application caching is strictly for performance reasons; there is no requirement to
have the application cached for the application to run.
Wide range of target environments
Nearly any modern Windows platform can host a streamed application. Specifically, supported operating
systems include Windows XP Professional, Windows Server 2003 and 2008, Windows Vista, and Windows 7.
With dual mode streaming, target environments are 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.
7.1. Readme for Citrix Offline Plug-in 6 and Streaming Profiler 6
Updated: 2010-11-03
Readme Version: 1.1
For a list of issues fixed in this version and hotfixes for the offline plug-in, see http://support.
in the Citrix Knowledge Center. citrix.com/article/CTX124164
To take full advantage of all the hotfixes for the offline plug-in 6.0. , download the latest version from x
. http://www.citrix.com/English/ss/downloads/
Contents
Finding Documentation
Getting Support
Known Issues
Finding Documentation
To access complete and up-to-date product information, in Citrix eDocs, expand the topics for your product.
Licensing Documentation
To access licensing documentation, go to http://support.citrix.com/proddocs/topic/technologies/lic-library-
. node-wrapper.html
Getting Support
Citrix provides technical support primarily through Citrix Solutions Advisors. Contact your supplier for first-
line support or use Citrix Online Technical Support to find the nearest Citrix Solutions Advisor.
Citrix offers online technical support services on the . The Support page includes links Citrix Support Web site
to downloads, the Citrix Knowledge Center, Citrix Consulting Services, and other useful support pages.
Known Issues
To install the Streaming Profiler with the required Visual C## redistributables, manually install
the CitrixStreamingProfiler.exe from the installation media. If you install the Streaming Profiler from
the Autorun menu, such as by selecting Manually Install Components > Common Components > Plug-
ins, Streaming Profiler, and Documentation > Streaming Profiler, Autorun launches the .msi
installer instead of the .exe installer. As a result, the redistributables are not installed. [#231179]
When using RadeDeploy -p /delete command to delete cached offline applications from user devices,
it deletes the contents from the Deploy folder, but does not delete the corresponding offline
application names from the registry or from the list of offline apps on the user device. [#224182]
On Windows Server 2008 R2 platforms, the session information in the Delivery Services Console might
be incomplete or inaccurate for applications streamed to clients. For example, session information does
not include the application names or client names. In addition, when users run multiple sessions,
properties for all sessions are overwritten with the most current session properties. There is no
workaround for these issues. [#223417, 223863, 223872]
After editing the isolation rules for a profile with inter-isolation communication (IIC), confirm whether
or not the dependent profiles are still linked with each other. If the link is missing, add the
dependent profiles again to the IIC profile. [#224742]
When creating profiles in the Profiler 6.0, inter-isolation communication is allowed only with other
profiles created (or updated) in version 6.0 of the profiler. Linking to profiles created in earlier versions
of the profiler is not supported. To update profiles, simply open and re-save them in Profiler 6.0.
Then proceed to add the updated profiles to the IIC profile. [#227331]
Uninstalling the offline plug-in from a XenApp server uninstalls two .dll files that the server
needs: radeapphook64.dll and radeapphook.dll. Before uninstalling the plug-in, make a backup of
these files, or locate them on another server. After uninstalling the plug-in, copy the two .dll files on
the server to C:\Program Files\Citrix\system32 directory, and restart the server. [#224537]
On XenApp 5 for Windows 2003, if you publish Application Isolation Environment (AIE) applications, do
not install the offline plug-in 6.0 or higher on the XenApp server. If you install it, AIE applications
run slowly or do not launch successfully; no error message appears to explain the failure. This issue
occurs because the AIE functionality is deprecated in offline plug-in 6.0, making application streaming
the preferred method of application isolation, and the plug-in does not support AIE applications.
Because the application streaming technology shares binary files with the deprecated AIE
technology, installing the offline plug-in 6.0 or higher on the XenApp server over-writes shared files
and causes the AIE applications to fail.
As a best practice, remove your AIE applications and adopt application streaming technology,
including profiling and re-publishing your applications for streaming. Alternatively, you can silo
your servers for either AIE applications or streamed applications. You can have both types in the
same farm, just not on the same server. For more details, see . http://support.citrix.com/article/CTX127234
Issues for Profiling and Streaming Microsoft Applications
For best practices for streaming Office 2007 applications, see Customizing Microsoft Office 2007 for
at . streaming environments http://support.citrix.com/article/CTX118396
For information about delivering Microsoft Application Virtualization (App-V) sequences to users, see the
eDocs topic . To publish App-V sequences
Streamed Office Project 2007 has the following known issues:
Creating Visual Reports in Project 2007 is not supported when users stream Project to
their desktops. [#223304]
Running Microsoft Office Web Components in Project 2007 is not supported on Windows 7
operating systems [#223553]
There are no workarounds for these issues.
When using the RadeCache.exe "flushall" command to clear the Office 2007 cache on user devices, in
some cases, the target is not fully deleted. This occurs when svchost.exe (running outside isolation) is
still running processes from the target. If this occurs, restart the computer and then run the
flushall command again. [#227323]
In addition, for service-based applications, if that application uses a network service, then
flushing RadeCache might not delete all the registry keys, but this will not impact the next
application launch. [#230383]
On Windows 7 operating systems, if Office 2007 is installed locally, streamed Office 2007
applications sometimes fail to launch or launch with errors. For example, Outlook 2007 signatures do
not appear. There is no workaround for this issue. [#229723]
On the following operating systems, issues occur when profiling the Microsoft MSN Messenger toolbar as
an Internet Explorer plug-in. Use the following workarounds: [#228314]
On Windows Server 2008 R2 platforms, deselect the "Live Writer" component from the installation.
If you try to include the Live Writer component, the toolbar installation fails.
On XP SP3 (32-bit) platforms, if an error message appears, click OK and the wizard
continues normally.
Microsoft Office 2010. The offline plug-in 6.0 and streaming profiler 6.0 have been tested to support
profiling and streaming Office 2010 applications. This testing was completed through the release candidate
of Office 2010. It is possible that the final version of Office 2010 will change compared to the release
candidate, causing a required change to the offline plug-in; the scope of any such change cannot be
anticipated prior to release.
For best practices for customizing Office 2010 applications for streaming environments, see http://support.
. citrix.com/article/CTX124565
Known issues for profiling and streaming Office 2010 release candidate applications:
Profiling and launching streamed Office 2010 applications on Windows Server 2003 and XP
operating systems require Microsoft hotfixes. Symptoms of missing hotfixes include error
messages appearing while profiling Office 2010 applications, or application launch on the user
device consuming 100% of the CPU on the device. This third-party issue occurs if you install
Microsoft security update KB956572, but not the hotfixes KB973573 or KB978835 that correct a
problem. [#229982, 227925]
To profile or stream Office 2010 applications, install these hotfixes on profiler workstations and
user devices:
On Windows XP 32-bit platforms, install hotfix KB978835.
On Windows XP 64-bit or Windows 2003 32-bit and 64-bit platforms, install hotfix KB973573.
For more information, see . http://support.citrix.com/article/CTX124563
For streamed Office 2010 applications, some fonts might not appear immediately, such as Elephant
font. You might have to restart the application for the font to appear. [#222823]
7.2. New Features in This Release
Updated: 2010-08-04
In addition to improved application compatibility on Microsoft Windows Server 2008 R2 and Windows 7,
this release provides the following enhancements:
for application streaming features, including inter- Support for Windows Server 2008 R2
isolation communication, differential synchronization, streaming profiles using HTTP/HTTPS,
and RadeDeploy commands.
Compatibility with Microsoft Office 2010. Create streaming profiles for 32-bit Office 2010
applications, including the services they require.
Isolation of services in profiles. Use this new feature in the Streaming Profiler to install services
in application profiles so they run in isolation on user devices. After you create a whitelist of
approved servers and edit the registry on user devices, users can stream profiles with services
from approved locations.
. Enable the function RadeRun RadeRun command to stream apps without using a license
to execute without a license so that applications can be streamed without being published. This
feature eliminates the implementation of XenApp infrastructure as a streaming requirement.
Streaming licensing is still enforced through the EULA.
However, when the offline plug-in launches a published application from a XenApp server
and communicates with XenApp servers, it uses a license. Also, the offline license period still applies
to offline applications.
. With this change, profiled applications Change from .CAB files to directory locations
(especially those in Office 2010 and 2007) are no longer packaged in .CAB files. Instead, locate
the application files in directory subfolders for the application.
. To take advantage of the latest updates in application streaming, Backward compatibility
Citrix recommends installing the Streaming Profiler 6.0 and the current versions of the Citrix plug-
ins included in this release. This release provides backward compatibility for streaming profiles created
with profilers in earlier releases, including 1. through 5. . x x
However, profiles created in the Streaming Profiler 6.0 are supported only with the Citrix offline plug-in
6.0 in this release and online plug-in versions 11.2 through 12. . x
7.3. System Requirements for Application Streaming
Updated: 2010-11-23
The Citrix offline plug-in 6.0 and the Streaming Profiler 6.0 are supported on the following Microsoft
operating systems:
Windows XP Home and Professional editions, 32-bit edition, with Service Pack 3
Windows XP Home and Professional editions, 64-bit edition, with Service Pack 2
Windows Server 2008, 32- and 64-bit editions
Windows Server 2003 R2
Windows Server 2008 R2
Windows Vista (Home, Business, Enterprise, and Ultimate editions), 32- and 64-bit editions, with
Service Pack 1
Windows 7, 32-bit and 64-bit (Enterprise, Professional, Ultimate)
The current offline plug-in supports Citrix Receiver 1.0, 1.1, and 1.2.
The profiler workstation and user devices 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, see . http://support.microsoft.com/kb/931534
The profiler workstation must provide a run-time environment that is as close to your users' environment
as possible:
To stream applications to user devices, 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.
To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-
isolation communication, install .NET Framework 2.0 (3.0 or 3.5 optional).
If you install the offline plug-in and profiler on the same computer, they must be the same exact version.
Install the profiler in a path with single-byte characters only. Double-byte characters in the installation path
are not supported.
The user devices must meet the following requirements:
A network connection to the server farm, such as a network interface card (NIC).
A supported browser: Microsoft Internet Explorer 6.0, 7.0, or 8.0.
To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for inter-
isolation communication, install .NET Framework 2.0 (3.0 or 3.5 is optional).
Manually uninstall any previous version of the Streaming Client and Program Neighborhood Agent on
user devices.
To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to
your users, install the most recent version of the online and offline plug-ins:
Citrix recommends using Citrix Receiver on user devices to install (and uninstall) Citrix plug-ins.
To stream applications to user desktops, install both the Citrix offline plug-in and online plug-in
on user devices.
To stream applications to a server, install the online plug-in or Web plug-in on user devices.
The offline plug-in is not required. If streaming to a Web Interface site, add the site to the list
of trusted sites.
7.4. Components for Application Streaming
Updated: 2010-03-11
The components related to a server farm that make applications available for streaming can be separated
into four categories. Each of these functional areas consists of software running on one or more workstations
or servers. Before you install the components for application streaming, refer to the system requirements
for application streaming.
The components that support virtualization on the user device, as shown in the diagram, include the
XenApp server, Citrix Licensing, Streaming Profiler workstation, file servers, Web Interface, and Citrix plug-ins.
1.
2.
3.
Licensing. Consists of the license server and License Management Console. Use the License
Management Console to manage licensing. To install Citrix Licensing, see the licensing section in
the Technologies node of Citrix eDocs.
For more information about licensing application streaming and offline access, see Application
. Streaming Licensing Explained (CTX112636)
Administration (server farm). Consists of the following components:
Farm servers.
IMA database.
The Web Interface.
The console, depending on your XenApp version. Use the console to configure and manage
the server delivery and publish applications for streaming.
Delivery Services Console
Access Management Console
3.
4.
Citrix Streaming Profiler. Creates and maintains streaming application profiles. The Streaming Profiler
is an independent application that enables you to profile Windows applications, Web applications,
browser plug-ins, files, folders, and registry settings that can be streamed to user devices and servers.
Use the profiler to create one or more targets within an application profile that can match all the
platforms of your users. This strategy creates a single profile that can accommodate a variety of
user platforms. The profiler can also update applications in the profile and provide other resources
that your users need.
Citrix plug-ins. The Citrix offline plug-in is the new name for the Streaming Client. To support
streaming applications to the user's desktop, as well as offline access to applications and dual-
mode streaming, install both the offline plug-in and online plug-in on user devices. When a user runs
a published application enumerated by Citrix Receiver or Citrix online plug-in or through a Web
Interface site, the offline plug-in finds the correct target in the profile in the App Hub, sets up the
isolation environment on the user device, and then streams the application from the profile location to
the safety of the isolation environment set up on the user device.
To support streaming applications to the server, install either the online plug-in or Web plug-in on
user devices. These applications must be published as "stream to server." When users run an application,
it streams to the server and launches using an ICA connection on the user device. To stream using the
Web plug-in, the Web Interface site must be added to the list of trusted sites.
7.5. Deciding Which Plug-ins to Use for Application Streaming
Updated: 2009-10-01
The delivery method for streaming that you select for published applications determines the plug-ins users
must install on their user devices.
Streamed to client desktops. With this method, you make available the full set of application
streaming features. You can publish applications as "streamed to client" or any other method for streaming.
When you stream applications directly to client desktops, some of the application files are cached locally and
the application runs using the resources of the user device.
Install both the online and offline plug-ins on user devices: CitrixOnlinePluginFull.exe and CitrixOfflinePlugin.exe.
This plug-in combination enables you to:
Enumerate published applications in the desktop menu and create shortcuts on the desktop. Start
Provide dual-mode streaming. When you select "Streamed if possible, otherwise accessed from a
server" and "Streamed to server," if streaming to the client desktop fails, applications automatically
stream to a XenApp server and launch using the online plug-in.
Configure the application and users for . When this configuration is completed, the offline access
entire application is fully cached on the user device. Users can disconnect from the network and
continue using the application for the time specified in the offline license.
The profile is streamed from the App Hub to the XenApp server, where the offline Accessed from a server.
plug-in is installed by default. The application displays on the user devices using the online plug-in or Web
plug-in; the offline plug-in is not required on the user device. When you publish applications as "Accessed from
a server" and "Streamed to server," users access the applications using the online plug-in or Web plug-in.
This method does not support desktop integration or offline access to applications.
Select the online plug-in package that fits your corporate needs:
Install CitrixOnlinePluginFull.exe to stream applications to XenApp servers and launch them with the
online plug-in, which provides transparent integration on desktops, or launch them from a Web
browser using a Web Interface site you create. Users have the full online plug-in feature set.
Install CitrixOnlinePluginWeb.exe to stream applications to XenApp servers and launch them from a
Web browser using a Web Interface site you create. Users have a limited online plug-in feature set.
Important: For users to stream applications through a Web site using an Internet Explorer or Firefox
browser, add the site to the Trusted sites list in Internet Explorer on the user devices.
7.6. Providing Single Sign-on for Streamed Applications
Updated: 2009-10-06
Citrix extends the Single Sign-on feature for streamed applications. When Single Sign-on is installed locally,
it recognizes streamed applications, even when launched in isolation environments, and manages logons
as expected.
For Microsoft Internet Explorer, however, the Single Sign-on feature must install a file called BHO.dll. To
allow this, when creating your application profile for Internet Explorer plug-ins, select the option to Enable
(formerly called security), which is deselected by default. User Updates Relaxed
By enabling user updates for Internet Explorer, the application can download vendor-supplied updates over
the Internet. These updates are stored within the user profile and are unique to that user. The next time the
user device connects to the profiled Internet Explorer on a server or file share, the streamed application does
not overwrite the updates, and Internet Explorer runs using the updates. Also with this setting, installers can
run inside isolation, where they are able to install new add-ons or software updates to Internet Explorer.
Local add-ons are compatible with Internet Explorer if you profile it with the default isolation rule of Isolate.
Local add-ons might not install correctly if you change the isolation rule for the Internet Explorer profile to
Strictly Isolate.
7.7. Creating Application Profiles
Updated: 2010-03-04
A is an application packaged for streaming using the Citrix Streaming Profiler. A profile can contain a profile
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 within a profile represent one or more defined user environments. The initial target matches targets
the environment of the profiling workstation; however, you can create multiple targets to match specific
user environments. For example, some commercial applications are capable of running on multiple
operating systems and languages, while others, such as custom applications, might be capable of running only
on a particular target operating system and language.
Important: Applications compiled as 64-bit applications are not supported for streaming. However, 32-
bit applications can be profiled on 64-bit systems and configured to be streamed to 64-bit systems.
Depending on the environment of your users, you have the option to profile prerequisites, such as Java
Runtime Environment, with the profiled application. In some cases, you might find it necessary to profile
certain applications together to ensure functionality among applications or to apply a range of
compatibility settings to ensure profiled applications launch and run successfully. In addition, you can use
the profiler to link existing profiles using so that applications interact as inter-isolation communication
needed, even though they are running in isolation environments.
After you create a profile and save it to a file share in your App Hub, configure users and publish the
application in the profile for streaming using the console included with your version of XenApp: Delivery
Services Console or Access Management Console. When a user launches an application published to stream to
the user device, 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 Security in Application Streaming for Desktops at http://support.citrix.com/article/CTX110304
Application Streaming Delivery and Profiling Best Practices for XenApp at http://support.
citrix.com/article/CTX118623
Additionally, select your product version of XenApp on the support Web site, click the tab, Technotes
and then click . Application Streaming
Note: The Streaming Profiler SDK offers a set of COM objects and .NET interfaces that give Citrix
customers, distributors, and partners a programmatic interface into the profiler. For information, download
the SDK and Readme from the Citrix Developer Network Web site at . http://community.citrix.com/
7.7.1. Targets Overview
Updated: 2010-03-11
A is a collection of disk files, registry data, and other information used to represent an application target
isolation environment. In addition, each target denotes a combination of operating system, service pack
level, system drive letter, and language. Applications can be profiled for each combination of these values
to support separate targets; for example: Microsoft Vista for all service packs, drive letter C, and English.
There can be multiple executables inside a target including multiple applications that normally receive an entry
on the Start menu. As an example, “Microsoft Office” is a profile and “Microsoft Word” is an application inside
that profile. A profile can support multiple targets where the target is a separate installation of the profile-
level software targeted for execution on a specific version of the operating system or language. For
example, create one target for Windows Vista and another target for Windows Server 2008.
User devices select targets for execution based on the computer configuration you specify while creating
the target. By default, a target matches the operating system and configuration of the profiling workstation,
but you can select different operating systems as well.
In addition, refer to information about the following selection criteria for creating targets:
Service Pack Level
System Drive Letter
Operating System Language
Inter-Isolation Communication Overview
You use the profiler to set criteria for each target in a profile. One or more administrators can run the
profiler multiple times and from different packaging environments to achieve a complete set of
differentiating targets. For many common scenarios, a single installation image supports a variety of
computer configurations, which simplifies profile creation.
The criteria associated with each target is stored in a profile manifest, a .profile file, stored with the profile files.
Overlapping definitions are not permitted: only one target in a profile can be a correct match for any
computer configuration at application launch.
An administrator can update a profile and target at any time without affecting already active executions on
user devices. The cost for this support is that file-server disk space is consumed to maintain old versions.
The profiler provides no facility to delete old versions of targets. Instead, manually delete old versions of
targets to reclaim server-side disk space. When deleting targets, it is the responsibility of the administrator
to ensure that the deleted versions are sufficiently old that no users are employing the target.
For the list of supported operating systems for application streaming, see the system requirements. By
design, future operating systems are not supported, and the execution environment refuses to execute
an application if the user device has an unsupported operating system.
7.7.1.1. Service Pack Level
Updated: 2010-03-11
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: