XenApp 6.5 for Windows Server 2008 R2

XenApp 6.5 for Windows Server 2008 R2
XenApp 6.5 for Windows Server 2008
R2
© 2011 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement
Contents
XenApp 6.5 for Windows Server 2008 R2
XenApp 6.5 for Windows Server 2008 R2
23
About This Release
26
Known Issues
29
System Requirements
34
Plan
39
Design and Plan
43
Farm Terminology and Concepts
47
Planning a Successful User Experience
51
Farm Hardware Considerations
53
Planning for Applications and Server Loads
54
Assessing Applications for XenApp Compatibility
55
Evaluating Application Delivery Methods
56
Planning for Application Streaming
59
Placing Applications on Servers
60
Determining the Number of XenApp Servers to Deploy
64
Deciding How Many Farms to Deploy
65
Planning Server Functions
67
Planning the XenApp Data Store
2
22
68
Database Server Hardware Performance Considerations
70
Replication Considerations
72
Planning for Configuration Logging and IMA Encryption
73
Planning for Data Collectors
74
Designing Zones for a XenApp Deployment
75
Planning for Application Access
78
Planning for Accounts and Trust Relationships
80
Recommendations for Active Directory Environments
82
Planning for System Monitoring and Maintenance
85
Planning for UAC
86
Planning for Shadowing
87
Securing Delivery and Access
88
Planning for Supported Languages and Windows MUI Support
89
Planning for Passthrough Client Authentication
90
Install and Configure
Install and Configure
Preparing to Install and Configure XenApp
93
94
Before Installing XenApp
95
Before Configuring XenApp
97
Installing XenApp Using the Wizard-Based Server Role Manager
99
Installing XenApp from the Command Line
101
Configuring XenApp Server Role License Information
104
Configuring XenApp Using the Wizard-based Server Configuration Tool
106
Configuring XenApp from the Command Line
110
Configuration Command Syntax
112
Preparing for XenApp Imaging and Provisioning
118
Removing Roles and Components
123
Data Store Database Reference
126
Microsoft SQL Server Database
127
Oracle Database
130
Migrate
133
XenApp Migration Center
135
Migration Center Interfaces
137
Objects You Can Migrate
139
Requirements and Installation
141
Migrating XenApp Using the Graphical Interface
144
Migrating XenApp Using the Command Line Interface
146
Cmdlet Reference
148
Post-migration Tasks
154
Indirect Migrations and Advanced Cmdlets
155
Manage
158
XenApp 6 for Windows 2008 R2
Management Consoles and Other Tools
160
162
To start the AppCenter and discover servers
164
To view zones
165
To refresh user data automatically
166
Managing Citrix Administrators
3
91
167
Delegating Tasks to Custom Administrators
169
Delivering XenApp to Software Services Subscribers
172
To enable Windows 7 look and feel and control desktop
customization
Working with Citrix Policies
177
Navigating Citrix Policies and Settings
179
Creating Citrix Policies
181
Working with Citrix Policy Templates
183
Creating Policy Templates
185
Importing and Exporting Policy Templates
187
Comparing Policies and Templates
189
Configuring Policy Settings
To add settings to a policy
Applying Citrix Policies
To add filters to a policy
Managing Multiple Policies
Prioritizing Policies and Creating Exceptions
Determining Which Policies Apply to a Connection
To simulate connection scenarios with Citrix policies
190
192
193
196
197
198
200
202
Applying Policies to Access Gateway Connections
203
Enabling Scanners and Other TWAIN Devices
205
Managing Session Environments and Connections
207
Defining User Environments in XenApp
209
Controlling the Appearance of User Logons
210
Controlling Access to Devices and Ports
211
To enable user execute permissions on mapped drives
4
175
212
Displaying Local Special Folders in Sessions
213
Configuring Audio for User Sessions
216
To enable or disable audio for published applications
217
To configure bandwidth limits for audio
218
To configure audio compression and output quality
219
To enable support for microphones and speakers
220
To use and set sound quality for digital dictation devices
221
Ensuring Session Continuity for Mobile Workers
222
Maintaining Session Activity
224
Configuring Session Reliability
225
Configuring Automatic Client Reconnection
226
Configuring ICA Keep-Alive
228
Session Linger
Managing and Monitoring XenApp Sessions
230
Monitoring Session Information
233
Viewing User Sessions
234
Viewing User Sessions with the Shadow Taskbar
235
Enabling Logging for Shadowing
237
Enabling User-to-User Shadowing with Policies
238
Controlling Client Connections in XenApp
240
Preventing Specific Client Connection Types
241
Specifying Connection Limits
242
Limiting Connections to a Server Farm
243
Sharing Sessions and Connections
244
Limiting Application Instances
246
Logging Connection Denial Events
247
Configuring the ICA Listener
248
Preventing User Connections During Farm Maintenance
249
Optimizing User Sessions for XenApp
Optimizing Audio and Video Playback
Configuring Windows Media Redirection
250
251
253
Optimizing Flash Content
254
Optimizing Throughput of Image Files
255
Optimizing Display of Image Files
256
Optimizing Keyboard and Mouse Responsiveness
257
Configuring SpeedScreen Latency Reduction
258
Adjusting SpeedScreen Latency Reduction for an
Application
259
To configure latency reduction settings for input fields
in an application
262
To create exception entries for non-standard input
fields in an application
264
Configuring HDX Broadcast Display Settings
Enhancing the User Experience With HDX
Configuring HDX MediaStream Flash Redirection
266
267
268
Configuring HDX MediaStream Flash Redirection on the
Server
270
Configuring HDX MediaStream Flash Redirection on the User
Device
275
Configuring Audio
Avoiding Echo During Multimedia Conferences With HDX
RealTime
5
229
280
284
Video Conferencing with HDX RealTime Webcam Video
Compression
285
Increasing 2D and 3D Application Scalability and Performance
287
Assigning Priorities to Network Traffic
288
Adding Dynamic Windows Preview Support
290
Configuring Read-Only Access to Mapped Client Drives
291
Securing Server Farms
Securing Access to Your Servers
293
Securing the Data Store
294
Securing Client-Server Communications
296
Using SecureICA
297
Enabling SSL/TLS Protocols
298
To configure session data encryption
299
To set a policy for ICA encryption
300
Configuring SSL/TLS Between Servers and Clients
6
292
301
Obtaining and Installing Server and Root SSL Certificates
303
Choosing an SSL Certificate Authority
304
Acquiring a Signed SSL Certificate and Password
305
To enable the SSL Relay and select the relay credentials
306
Using the SSL Relay with the Microsoft Internet Information
Service (IIS)
307
Configuring the Relay Port and Server Connection Settings
308
To run the SSL Relay on port 443 without using HTTPS
310
Configuring the Ciphersuites Allowed by the SSL Relay
311
Using the Secure Gateway
312
Using the Secure Ticket Authority
313
Securing Network Communications
315
Configuring TCP Ports
316
Using Proxy Servers
317
Configuring Authentication for Workspace Control
318
Using Smart Cards with XenApp
319
Configuring Kerberos Logon
321
Logging Administrative Changes to a XenApp Farm
323
Setting up the Configuration Logging Database
325
Defining Database Permissions for Configuration Logging
327
To configure the connection to the Configuration Logging
database
329
To set Configuration Logging properties
330
Clearing Entries from the Configuration Logging Database
331
Encrypting Configuration Logging Data
To generate a key and enable IMA encryption on the
first server in a farm
334
To load a key on servers that join the farm
335
Managing IMA Encryption
336
XenApp Service Account Privileges
337
Maintaining Server Farms
342
To search for objects in your farm
343
To change a server's desktop settings
344
To limit the number of server connections per user
345
To enable or deny logons to servers
346
Restarting Servers at Scheduled Times
347
Removing and Reinstalling XenApp
348
To rename a XenApp server
350
To move or remove a server
351
Monitoring Server Performance with Health Monitoring &
Recovery
352
Using Citrix Performance Monitoring Counters
355
Using Worker Groups for Enhanced Resource Access
357
To create a worker group
360
Creating and Prioritizing Load Balancing Policies
361
Enhancing the Performance of a Remote Group of Servers
362
Using Preferential Load Balancing
363
Resource Allotment
364
Multiple Published Applications in the Same Session
367
Managing CPU Usage
368
Deploying virtual memory optimization
370
Managing Farm Infrastructure
373
Maintaining the Local Host Cache
374
Tuning Local Host Cache Synchronization
375
To configure zones and back-up data collectors
376
Updating Citrix License Server Settings
378
To set the product edition
379
Configuring the Citrix XML Service Port and Trust
380
To manually change the XML Service port to use a port
different from IIS after installation
382
To manually configure Citrix XML Service to share the TCP
port with IIS
383
Manage Server and Resource Loads
7
332
384
To create a new load evaluator
List of Load Management Rules
387
Assigning Load Evaluators to Servers and Applications
389
Scheduling Server Availability
391
Power and Capacity Management
392
About Load Consolidation and Power Management
394
Installing Power and Capacity Management
396
System Requirements for Power and Capacity Management
397
Interactively Installing Components
401
Silently Installing Components
403
Upgrading Administration Components
409
Removing Components
410
Configuring and Using Power and Capacity Management
411
Configuring a Server Profile
415
Configuring Server Properties
417
Setting Global Configuration Values
419
Configuring Sites
420
Adding Virtual Machine Managers
421
Managing the Concentrator
423
Creating Setpoints and Schedules
425
Enabling Load Consolidation and Power Management
428
Understanding XenApp Printing
Introduction to Windows Printing Concepts
Local and Remote Print Job Spooling
XenApp Printing Concepts
429
430
432
434
Overview of Client and Network Printing Pathways
435
Provisioning Printers for Sessions
440
Auto-Creating Client Printers
442
Auto-Creating Network Printers
446
Letting Users Provision Their Own Printers
447
Device or Session-Based Print Settings
8
386
448
Device-Based Print Settings
449
Controlling Printing Settings and User Preferences
450
Setting Default Printers
453
Printing and Mobile Workers
454
Optimizing Printing Performance by Routing
456
Managing Printer Drivers
457
Planning Your Printing Configuration
Default Printing Behavior
460
Printing Policy Configuration
461
Printing Security
462
Purchasing Printing Hardware
463
Configuring and Maintaining XenApp Printing
464
Configuring Printer Autocreation Settings
465
Configuring Citrix Universal Printing
466
Configuring Network Printers for Users
468
To add a network printer while configuring the Session
printers setting
469
To specify a default printer for a session
470
To edit the printer settings in the sessions policy
471
To configure server local printers
472
Configuring Printers for Mobile Workers
473
Changing Network Print Job Routing
474
Providing Tools for User Provisioning
475
To store users’ printer properties
477
To synchronize properties from the printer
478
Controlling Printer Driver Automatic Installation
479
Configuring Universal Printer Drivers on Farm Servers
482
Mapping Client Printer Drivers
484
Improving Session Performance by Limiting Printing Bandwidth
486
Displaying Printers
488
Managing Printers Using the Network Printing Pathway
489
Displaying Printers Using the Client Printing Pathway
490
XenApp Server Utilities Reference
9
459
491
ALTADDR
492
APP
494
AUDITLOG
497
CTXKEYTOOL
500
CTXXMLSS
502
DSCHECK
504
DSMAINT
506
ICAPORT
511
IMAPORT
513
QUERY FARM
515
QUERY PROCESS
518
QUERY SESSION
520
QUERY TERMSERVER
522
QUERY USER
524
Performance Counters Reference
Citrix CPU Utilization Mgmt User Counters
527
Citrix IMA Networking Counters
528
Citrix Licensing Counters
529
Citrix MetaFrame Presentation Server Counters
530
ICA Session Counters
532
Secure Ticket Authority Counters
535
Policy Settings Reference
536
Policy Settings: Quick Reference Table
537
ICA Policy Settings
543
Audio Policy Settings
545
Auto Client Reconnect Policy Settings
547
Bandwidth Policy Settings
548
Client Sensors Policy Settings
553
Desktop UI Policy Settings
555
End User Monitoring Policy Settings
556
File Redirection Policy Settings
557
Flash Redirection Policy Settings
562
Graphics Policy Settings
566
Caching Policy Settings
10
526
568
Keep Alive Policy Settings
569
Legacy Server Side Optimizations Policy Settings
570
Mobile Experience Policy Settings
571
Multimedia Policy Settings
573
Multi-Stream Connections Policy Settings
575
Port Redirection Policy Settings
577
Printing Policy Settings
579
Client Printers Policy Settings
581
Drivers Policy Settings
584
Universal Printing Policy Settings
586
Security Policy Settings
589
Server Limits Policy Settings
591
Session Limits Policy Settings
592
Session Reliability Policy Settings
594
Shadowing Policy Settings
596
Time Zone Control Policy Settings
598
TWAIN Devices Policy Settings
599
USB Devices Policy Settings
600
Visual Display Policy Settings
602
Moving Images Policy Settings
603
Still Images Policy Settings
604
Licensing Policy Settings
606
Power and Capacity Management Policy Settings
607
Server Policy Settings
608
Connection Limits Policy Settings
611
Database Policy Settings
612
Health Monitoring and Recovery Policy Settings
614
Memory Optimization Policy Settings
615
Offline Applications Policy Settings
618
Reboot Behavior Policy Settings
619
Server Session Settings
622
Virtual IP Policy Settings
623
XML Service Policy Settings
625
Publish
626
Publish
628
Publishing in XenApp
11
629
Evaluating Application Delivery Methods
630
Publishing Resources using the AppCenter
633
To configure servers to publish for multiple users
635
To publish a resource using the Publish Application wizard
636
To select a resource type and delivery method
638
To configure locations of published applications
640
To configure locations of published content
641
To disable command-line validation
642
To pre-launch applications to user devices
643
Publishing Applications for Streaming
646
New Features in This Release
648
System Requirements for Application Streaming
649
Application Streaming Overview
652
Components for Application Streaming
654
Deciding Which Receiver or Plug-in to Use for Application
Streaming
657
Providing Single Sign-on for Streamed Applications
659
Creating Application Profiles
660
Targets Overview
Service Pack Level
664
System Drive Letter
665
Operating System Language
666
Inter-Isolation Communication Overview
667
Isolating Services
668
Specifying Trusted Servers for Streamed Services and
Profiles
669
Managing Isolation Environment Rules
672
Types of Isolation Environment Rules
673
Restrictions and Limitations for Rules
675
Creating Isolation Environment Rules for a Target
676
To create an isolation environment rule
677
To modify a rule
678
Using Environment Variables to Construct Rules
679
Preparing a Workstation for Profiling Applications
12
662
681
Known Limitations for Profiling
683
To install the profiler
684
To disable and enable profile signing
685
To start the profiler
686
Creating a Profile and Its Initial Target
687
To create a profile and target
688
To allow users to update applications
691
To set up inter-isolation communication
692
To select an install option
694
To install multiple applications through Advanced
Install
695
To choose an installation program for the
application
696
To create a virtual hard disk
698
To support legacy plug-ins
700
To install Internet Explorer plug-ins
701
To include files and folders in a target
702
To include registry settings
703
To install an application in the profile
704
To run an application in the profiler
705
To select applications for listing in the profile
706
To sign a profile
Editing Profiles
708
To view profile information
709
To edit the profile name, description, or location
710
To view details about applications in a profile
711
To view File Type Associations set in a profile
712
To check for launch prerequisites
713
To check for prerequisite registry entries
714
To check for prerequisite applications and files
716
To specify pre-launch and post-exit scripts
717
To add a target to a profile
718
To resolve target conflicts
719
To resolve invalid shortcuts
721
To delete a target from a profile
722
To delete a folder from a profile
723
To remove a profile from a linked profile
724
Editing Targets
725
To edit the target name and description
726
To modify the application properties in the target
727
To modify the operating system and language
properties of a target
729
To update a target
730
To remove an old version of an updated target
731
Profile Contents on the Server
13
707
732
Manifest File
733
Targets
734
Digital Signature
735
Icons
736
Scripts
737
Publishing Streamed Applications
738
To select a streaming delivery method
739
To force a delivery method for streamed applications
741
To provide HTTP or HTTPS delivery method
743
Configuring Offline Access
746
Offline Plug-in 6.5 for Windows
749
New Features in This Release
750
System Requirements for Application Streaming
751
Citrix Offline Plug-in Overview
754
Deciding Which Receiver or Plug-in to Use for
Application Streaming
755
Specifying Trusted Servers for Streamed Services and
Profiles
757
Using the Merchandising Server and Citrix Receiver
Updater to Deploy the Plug-ins
760
To install the Offline Plug-in
761
To deliver the AppHubWhiteList to user devices
763
To configure the cache size of the Offline Plug-in
764
To deploy the Offline Plug-in using the command-line
765
To configure an .MSI package for the Offline Plug-in
using transforms
767
To deploy the Offline Plug-in to user devices through
Active Directory
768
To deploy applications to user devices
769
To clear the streamed application cache on user devices
771
To clear merged rules for linked profiles on user devices
773
Configuring Content Redirection
To enable content redirection from server to client
775
To configure content redirection from client to server
777
Managing Application Properties
14
774
778
To rename a published application
779
To configure locations of servers for published resources
780
To specify locations of applications for streaming
781
To enable an application for offline access
782
To configure user access to applications
783
Granting Access to Explicit or Anonymous Users
785
To configure shortcuts for user devices
786
To configure access controlled by the Access Gateway
787
To associate published applications with file types
788
To update file type associations
790
To configure alternate profiles
792
To pass parameters to published applications
793
To reduce user privileges for a streamed application
794
To configure application limits and importance
795
To configure audio and encryption options for published
applications
796
To configure application appearance
798
To disable or enable a published application
799
To delete a published application
800
To move a published application to another folder
801
To duplicate published application settings
802
To export published application settings to a file
803
To import published application settings from a file
804
Making Virtual IP Addresses Available to Applications
How Virtual IP Addressing Works
806
Binding Applications
807
To determine whether an application needs to use virtual IP
addresses
808
To make virtual IP addresses available to applications
running in sessions
809
To make a virtual loopback address available to applications
running in sessions
810
To supply client IP addresses to published applications on a
server
811
VM Hosted Apps
813
System Requirements
816
Plan
817
Install and Set Up
820
Installing and Removing Server Components for VM Hosted
Apps
821
To configure a VM hosted apps site
823
To replace the default XenServer SSL certificate
Installing and Removing the Virtual Desktop Agent
826
828
To configure firewalls manually
830
To deploy the Virtual Desktop Agent using Active
Directory Group Policy Objects
831
To use Windows XP virtual desktops with Single Sign-on
Manage
832
833
Working With Machine Catalogs and Desktop Groups
834
To create an application desktop group
836
Managing Application Desktop Groups
837
Working With Applications
838
To create an application
840
To modify applications
842
To manage applications sessions
844
Organizing Applications with Folders and Tags
846
Customize
Configuring USB Support for VM Hosted Apps
Publishing App-V Sequences in XenApp
15
805
847
848
852
XenApp Connector for Configuration Manager 2007
System Requirements for XenApp Connector for Configuration
Manager 2007
857
Install and Set Up XenApp Connector
859
Uninstalling XenApp Connector
863
Enabling Power and Capacity Management for XenApp Connector
864
Deploying Applications to XenApp Servers and Publishing
Applications with XenApp Connector
866
To publish applications with XenApp Connector for Configuration
Manager 2007
869
Deploying WSUS Updates to XenApp Servers with XenApp
Connector
871
Viewing and Maintaining Log Files
872
Enterprise Management
Enterprise Management
Management Pack for System Center Operations Manager 2007
874
875
877
System Requirements for the Management Pack
879
To install the Management Pack
880
Management Pack Post-Installation Tasks
881
Uninstalling the Management Pack
882
Security Considerations for the Management Pack
883
Troubleshooting Query Errors in Operations Manager
884
Citrix Managed Objects Included in the Management Pack
885
Citrix Views Included in the Management Pack
886
To view state monitors and processing rules
887
Viewing XenApp Alert and Event Information
888
Viewing XenApp Deployment State Information
889
Viewing Citrix Presentation Server Topology Diagrams
890
To reconfigure security settings on zone data collectors
894
Viewing XenApp Performance Information
895
Viewing License Server Information
896
Configuring and Enabling Site-specific Monitors
897
To open the AppCenter from the Operations Manager Console
899
Installation Manager
900
Requirements and Installation
902
Using the Installation Manager Console
905
Using Installation Manager PowerShell Cmdlets
909
Installation Manager Messages Reference
915
Managing Providers and WMI
16
856
921
XenApp Provider Overview
922
Licensing Provider Overview
923
Installing the XenApp Provider
924
Installing the Licensing Provider
925
Starting the Provider Services
926
Security Considerations
927
Uninstalling the Providers
928
WMI Schema
929
XenApp Provider WMI Schema (Part 1 of 3)
930
XenApp Provider WMI Schema (Part 2 of 3)
931
XenApp Provider WMI Schema (Part 3 of 3)
932
Citrix Licensing Provider WMI Schema
933
Optimize WAN Access
934
Provision
935
Secure Enterprise Network
936
Secure Gateway
Citrix XenApp Components That Work with Secure Gateway
Secure Gateway Features
938
939
System Requirements for Secure Gateway
943
Certificate Requirements
945
Planning a Secure Gateway Deployment
947
Deploying the Secure Gateway in a Single-Hop DMZ
948
Running the Web Interface behind the Secure Gateway in the
Demilitarized Zone
950
Locking Down Internet Information Services
952
Running the Web Interface Parallel with the Secure Gateway
953
Setting Up the Web Interface and the Secure Gateway in a
Single-Hop Demilitarized Zone
954
Deploying the Secure Gateway in a Double-Hop DMZ
955
Setting Up the Secure Gateway and the Secure Gateway
Proxy in a Double-Hop DMZ
958
Publishing the Web Address for the Secure Gateway in a
Double-Hop Demilitarized Zone
959
Setting Up and Testing a Server Farm
960
Installing the Secure Ticket Authority
961
Testing Your Deployment
962
Installing and Configuring the Secure Gateway and Secure Gateway
Proxy
Upgrading Secure Gateway or Secure Gateway Proxy
17
937
963
964
Using Firewall Software with the Secure Gateway or Secure
Gateway Proxy
965
Installing the Secure Gateway or Secure Gateway Proxy
966
To install the Secure Gateway or Secure Gateway Proxy
Configuring the Secure Gateway or Secure Gateway Proxy
968
To start the configuration wizard manually
969
To select a configuration level (Secure Gateway)
970
To select a configuration level (Secure Gateway Proxy)
971
Task Summary for Secure Gateway, Advanced or Standard
Configuration
972
Task Summary for Secure Gateway Proxy, Advanced or
Standard Configuration
973
To select a server certificate
974
To configure secure protocol settings
975
To configure inbound client connections
976
To configure outbound connections
977
To configure an access control list for outbound
connections
978
To configure servers running the Secure Gateway Proxy
980
To add the Secure Ticket Authority details
981
To configure connection parameters
982
To configure logging exclusions
983
To add the Web Interface server details
984
To configure the logging parameters
985
To complete the configuration
986
To stop the Secure Gateway/Secure Gateway Proxy
service
To uninstall the Secure Gateway
Managing the Secure Gateway
18
967
987
988
989
Viewing Session and Connection Information with the Secure
Gateway Console
990
Viewing Secure Gateway Performance Statistics
992
To view the Secure Gateway performance statistics
993
Performance Counters Available for the Secure Gateway
994
Generating the Secure Gateway Diagnostics Report
998
Viewing the Secure Gateway Events
999
Viewing the Secure Gateway Access Logs
1001
Secure Gateway Configuration Wizard
1002
Secure Gateway Optimization and Security Guidelines
1003
Configuring Firewalls for the Secure Gateway
1004
Ensuring High Availability of the Secure Gateway
1005
Load Balancing Multiple Secure Gateway Servers
1007
Load Balancing an Array of the Secure Gateway Proxy
1008
Certificate Requirements for Load Balancing Secure Gateway 1009
Servers
Using Load Balancers and SSL Accelerator Cards with Secure
Gateway Servers
1010
Coordinating Keep-Alive Values Between the Secure Gateway and 1011
Citrix XenApp
Setting Connection Keep-Alive Values and the Secure
Gateway
Improving Security (Recommendations)
1013
Preventing Indexing by Search Engines
1017
Troubleshooting the Secure Gateway
1018
To check your certificates
1019
Client Connections Launched from IP Addresses in the Logging
Exclusions List Fail
1020
Load Balancers Do Not Report Active Client Sessions if
Connections Are Idle
1021
Performance Issues with Transferring Files Between a User
Device and a Citrix XenApp Server
1022
Gateway Client Connections Fail When Using Windows XP Service
Pack 2
1023
Failed Client Connections to the Secure Gateway Result in
Duplicate Entries in the Secure Gateway Log
1024
Placing the Secure Gateway Behind a Reverse Web Proxy Causes
an SSL Error 4
1025
Run the Secure Gateway Parallel to the Reverse Web Proxy
1026
Use a Network Address Translator Instead of a Reverse Web
Proxy
1027
Digital Certificates and the Secure Gateway
Understanding Cryptography
19
1012
1028
1029
Types of Cryptography
1030
Combining Public Key and Secret Key Cryptography
1031
Understanding Digital Certificates and Certificate Authorities
1032
Certificate Chains
1034
Certificate Revocation Lists
1036
Deciding Where to Obtain Certificates
1037
Obtaining and Installing Server Certificates
1039
Obtaining and Installing Root Certificates
1041
Support for Wildcard Certificates with the Secure Gateway
1042
Secure Application Access
1043
Monitor
1044
Record
1045
Record
20
1046
System Requirements for SmartAuditor
1049
Example Usage Scenarios
1052
Getting Started with SmartAuditor
1053
Planning Your Deployment
1055
Security Recommendations
1058
Installing Certificates
1059
Scalability Considerations
1060
Important Deployment Notes
1063
Pre-Installation Checklist
1064
To install SmartAuditor
1065
Automating Installations
1067
To configure SmartAuditor to play and record sessions
1068
Granting Access Rights to Users
1070
Creating and Activating Recording Policies
1071
Using System Policies
1072
Creating Custom Recording Policies
1073
To create a new policy
1075
To modify a policy
1076
To delete a policy
1077
To activate a policy
1078
Understanding Rollover Behavior
1079
To disable or enable recording
1080
To configure the connection to the SmartAuditor Server
1081
Creating Notification Messages
1082
Enabling Custom Event Recording
1083
To enable or disable live session playback
1084
To enable or disable playback protection
1085
To enable and disable digital signing
1086
To specify where recordings are stored
1087
Specifying File Size for Recordings
1089
Viewing Recordings
1090
To launch the SmartAuditor Player
1091
To open and play recordings
1092
To search for recorded sessions
1094
To play recorded sessions
1096
To use events and bookmarks
1099
To change the playback display
1102
To display or hide window elements
1104
To cache recorded session files
1105
To change SmartAuditor Servers
1107
Troubleshooting SmartAuditor
Verifying Component Connections
1109
Testing IIS Connectivity
1111
Troubleshooting Certificate Issues
1113
SmartAuditor Agent Cannot Connect
1114
SmartAuditor Server Cannot Connect to the SmartAuditor
Database
1115
Sessions are not Recording
1116
Searching for Recordings in the Player Fails
1117
Troubleshooting MSMQ
1118
Unable to View Live Session Playback
1119
To change your communication protocol
1120
Reference: Managing Your Database Records
1122
Single Sign-on
1124
Automate
1125
XenApp 6.5 Mobility Pack 1.0
1126
XenApp 6.5 Mobility Pack Technical Preview
21
1108
1128
About This Release
1130
System Requirements
1132
Installing XenApp 6.5 Mobility Pack
1133
Configuring Policies for Mobility Pack
1135
Mobile Application SDK
1137
XenApp 6.5 for Windows Server 2008 R2
About This Release
Publishing Resources
Known Issues for XenApp 6.5
Enhancing the User Experience With HDX
System Requirements for XenApp 6.5
Delivering XenApp to Software Services
Subscribers (Windows Desktop Experience
Integration)
Issues Fixed for XenApp 6.5
Power and Capacity Management
Installing and Configuring XenApp 6.5
Profile Management
XenApp Migration Center
Licensing Your Product
Designing a XenApp Deployment
Web Interface
Receiver For Windows
Receiver (Updater) for Windows
Self-service Plug-in
Receiver (Updater) for Macintosh
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.
22
Desktop Director
VM Hosted Apps
Provisioning Services
XenApp Connector for Configuration Manager
2007 R2
Service Monitoring (EdgeSight)
Smart Auditor
Single Sign-on
Load testing services
Branch optimization powered by Citrix
Branch Repeater
Secure Gateway
SmartAccess powered by Citrix Access
Gateway™
XenVault
Doc Finder
Workflow Studio orchestration
About Citrix XenApp 6.5 for Windows
Server 2008 R2
This release includes several new features and enhancements to Citrix XenApp.
23
XenApp 6.5 for Windows Server 2008 R2
What's New
●
Server Platform Support
The XenApp software can be installed on the following platforms. For all system
requirements, see System Requirements.
●
●
Microsoft Windows Server 2008 R2
●
Microsoft Windows Server 20008 R2 Service Pack 1
Windows Desktop Experience Integration
Installed by default when installing the XenApp server role, this feature provides a
Windows 7 look and feel including desktop customization. PowerShell script options
enable administrators to control desktop and environment defaults while allowing end
users to customize their desktops.
When installed and enabled, this feature also removes the Windows Server Manager
Console from the XenApp server's toolbar and relocates the Citrix XenApp
administrative tools such as the AppCenter to the Start menu's Administrative
Tools\Citrix folder. See Delivering XenApp to Software Services Subscribers for more
information.
●
Citrix AppCenter
The AppCenter provides a streamlined interface for performing management functions.
From the AppCenter, you can manage components administered through other Citrix
products, such as Citrix Secure Access and Citrix Single Sign-On. For Citrix XenApp, you
can configure and monitor servers, server farms, published resources, and sessions.
●
Session Pre-launch, Session Linger, and Fast Reconnect
This collection of features improves the user experience by eliminating delays when
launching and maintaining sessions. By using configurable Session Pre-launch policy
settings, a session is started automatically when a user logs on to the farm. By
implementing Session Linger policy settings, sessions remain alive for a configurable
period before termination, rather than terminating when users close applications.
Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays
when users reconnect to existing sessions.
●
Citrix HDX Enhancements
XenApp includes the latest HDX enhancements:
24
●
HDX MediaStream Flash Redirection
●
Audio Settings
●
Multimedia Conferencing with HDX RealTime
●
Increased 2D and 3D Application Scalability and Performance
●
Assigning Priorities to Network Traffic
XenApp 6.5 for Windows Server 2008 R2
●
●
Dynamic Windows Preview Support
Migration Center with Graphical User Interface
With the choice of using a PowerShell cmdlet command line or graphical user interface,
XenApp administrators can import application, folder, server configuration, and other
XenApp object types from farms running previous versions of XenApp into XenApp 6.5
farms. See XenApp Migration Center for requirement and installation information.
●
Improved Performance for Pooled Desktops
Application launch time in pooled desktop environments is improved through the use of
virtual hard disks. Using the Streaming Profiler, virtual hard disks can be created when
profiling an application. When the application is launched for the first time, the virtual
hard disk is mounted and all the profile contents are copied to the virtual hard disk. For
all subsequent launches, the application is launched from the virtual hard disk,
resulting in a speedier launch.
●
Printing Optimization
XenApp printing features include improved print session performance, lower bandwidth
required for printing, and improved user experience when printing to redirected client
printers. Universal Printing policy settings enable the administrator to control print
quality, spooling, and optimization defaults. See the printing topics in the Manage node
of this documentation for more information.
●
Receiver Storefront
Receiver Storefront authenticates users to XenDesktop sites and XenApp farms,
enumerating and aggregating available desktops and applications into stores that users
access through Citrix Receiver or a Web page.
If your XenApp installation media or download package contains the Citrix Receiver
Storefront folder, you can install the Receiver Storefront through the XenApp Server
Role Manager provided in that media/package. If your installation media or download
package does not contain the Citrix Receiver Storefront folder, you can download an
updated XenApp package from My Citrix.
25
About Citrix XenApp 6.5 for Windows
Server 2008 R2
This release includes several new features and enhancements to Citrix XenApp.
26
About This Release
What's New
●
Server Platform Support
The XenApp software can be installed on the following platforms. For all system
requirements, see System Requirements.
●
●
Microsoft Windows Server 2008 R2
●
Microsoft Windows Server 20008 R2 Service Pack 1
Windows Desktop Experience Integration
Installed by default when installing the XenApp server role, this feature provides a
Windows 7 look and feel including desktop customization. PowerShell script options
enable administrators to control desktop and environment defaults while allowing end
users to customize their desktops.
When installed and enabled, this feature also removes the Windows Server Manager
Console from the XenApp server's toolbar and relocates the Citrix XenApp
administrative tools such as the AppCenter to the Start menu's Administrative
Tools\Citrix folder. See Delivering XenApp to Software Services Subscribers for more
information.
●
Citrix AppCenter
The AppCenter provides a streamlined interface for performing management functions.
From the AppCenter, you can manage components administered through other Citrix
products, such as Citrix Secure Access and Citrix Single Sign-On. For Citrix XenApp, you
can configure and monitor servers, server farms, published resources, and sessions.
●
Session Pre-launch, Session Linger, and Fast Reconnect
This collection of features improves the user experience by eliminating delays when
launching and maintaining sessions. By using configurable Session Pre-launch policy
settings, a session is started automatically when a user logs on to the farm. By
implementing Session Linger policy settings, sessions remain alive for a configurable
period before termination, rather than terminating when users close applications.
Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays
when users reconnect to existing sessions.
●
Citrix HDX Enhancements
XenApp includes the latest HDX enhancements:
27
●
HDX MediaStream Flash Redirection
●
Audio Settings
●
Multimedia Conferencing with HDX RealTime
●
Increased 2D and 3D Application Scalability and Performance
●
Assigning Priorities to Network Traffic
About This Release
●
●
Dynamic Windows Preview Support
Migration Center with Graphical User Interface
With the choice of using a PowerShell cmdlet command line or graphical user interface,
XenApp administrators can import application, folder, server configuration, and other
XenApp object types from farms running previous versions of XenApp into XenApp 6.5
farms. See XenApp Migration Center for requirement and installation information.
●
Improved Performance for Pooled Desktops
Application launch time in pooled desktop environments is improved through the use of
virtual hard disks. Using the Streaming Profiler, virtual hard disks can be created when
profiling an application. When the application is launched for the first time, the virtual
hard disk is mounted and all the profile contents are copied to the virtual hard disk. For
all subsequent launches, the application is launched from the virtual hard disk,
resulting in a speedier launch.
●
Printing Optimization
XenApp printing features include improved print session performance, lower bandwidth
required for printing, and improved user experience when printing to redirected client
printers. Universal Printing policy settings enable the administrator to control print
quality, spooling, and optimization defaults. See the printing topics in the Manage node
of this documentation for more information.
●
Receiver Storefront
Receiver Storefront authenticates users to XenDesktop sites and XenApp farms,
enumerating and aggregating available desktops and applications into stores that users
access through Citrix Receiver or a Web page.
If your XenApp installation media or download package contains the Citrix Receiver
Storefront folder, you can install the Receiver Storefront through the XenApp Server
Role Manager provided in that media/package. If your installation media or download
package does not contain the Citrix Receiver Storefront folder, you can download an
updated XenApp package from My Citrix.
28
Known Issues for XenApp 6.5 for
Windows Server 2008 R2
Readme Version: 1.0
Contents
29
●
Installation Issues
●
SmartAuditor Issues
●
Application Streaming Issues
●
Single Sign-on Issues
●
Other Known Issues
Known Issues
Installation Issues
●
●
●
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
If you are installing the Configuration Manager Console Extension component of the
XenApp Connector for Configuration Manager 2007 on a computer that has a remote
Configuration Manager console installed, this warning might display: “Configuration
Manager Console Extension is selected, but ConfigMgr 2007 R2 or higher is not installed.
Install will continue, but the console extension feature will not be operable without
ConfigMgr.” If the installed Configuration Manager console is from Microsoft System
Center Configuration Manager 2007 R2 or R3, ignore this warning and continue installing
the Configuration Manager Console Extension. The Configuration Manager Console
Extension operates normally after installation. [#0034277]
After installing the Windows Desktop Experience Integration role through the XenApp
Server Role Manager on a computer running a non-English operating system and
configuring the CtxStartMenuTaskbarUser Group Policy Object (GPO), the PowerShell
and Server Manager icons are not removed from the Taskbar as expected. Additionally,
the Internet Explorer and Windows Media Player icons are not added to the Taskbar.
This occurs because the script Enable-CtxDesktopExperienceUser.ps1 does not run
correctly on non-English operating systems. To resolve this issue, download the updated
Enable-CtxDesktopExperienceUser.ps1 script from CTX130208 in the Citrix Knowledge
Center and replace the script on the XenApp server. [#261892]
SmartAuditor Issues
●
The SmartAuditor Player might fail to correctly display sessions launched with Citrix
Receiver for Windows 3.0, instead showing a black screen in the Player window. To
prevent this, disable the gradient fill feature on the XenApp server hosting the sessions
by creating this DWORD registry on the server and setting its value to 1:
HKLM\SOFTWARE\Citrix\Ica\Thinwire\DisableGdiPlusSupport.
Caution: Editing the Registry incorrectly can cause serious problems that may require
you to reinstall your operating system. Citrix cannot guarantee that problems
resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor
at your own risk. Be sure to back up the registry before you edit it.
Sessions recorded after this change is made display correctly. [#254644]
30
Known Issues
●
The SmartAuditor Player might fail to play sessions launched with the Citrix Online
Plug-in for Windows 12.1 or Citrix Receiver for Windows 3.0. To play these sessions,
edit this text in the SmAudPlayer.exe.config file: <add key=”Windows”
value=”12.00.9999”/>. To view sessions launched with Online Plug-in for Windows
12.1, change ”12.00.9999” to ”12.99.9999”. To view sessions launched with
Receiver for Windows 3.0, change ”12.00.9999” to ”13.00.9999”. [#254795,
#255780]
●
If SmartAuditor Administration components are installed on a XenApp server, the Citrix
AppCenter console might not be able to complete discovery on the server. To resolve
this issue, run: %SystemDrive%\Program Files
(x86)\Citrix\System32\mfreg.exe /regserver.[#260133]
Application Streaming Issues
Issues for streaming Microsoft Office applications:
●
Profiling Microsoft Office 2010 SP1 is not supported in this release.
For best practices for streaming Office 2010 applications, see
http://support.citrix.com/article/CTX124565 in the Citrix Knowledge Center.
●
Although the fonts for Office 2010 applications do not load during profiling, the fonts
load correctly when the applications are launched on the user device. [#262124]
●
While profiling Microsoft Office 2010 applications, the option to Enable User Updates
fails if the applications are published to stream to client desktops. To prevent this
issue, do not use that profiling option for Office 2010 applications. [#259362]
●
When using the RadeCache flushall command, you might receive an Access Denied error
for Microsoft Office applications that are streamed to server.
If this occurs, restart the server and run the flushall command again. [#262465]
●
When profiling Office 2010 on Windows 7 using the streaming profiler, if the operating
system fails with a blue screen, the profiling workstation is probably missing Windows
updates and a Microsoft Hotfix. To fix the issue, update the profiling workstation with
the latest Windows updates and install the Microsoft Hotfix located at
http://support.microsoft.com/kb/2359223/en-US. [#248727]
●
Streamed Office Project 2007 has the following known issues:
●
Creating Visual Reports in Project 2007 is not supported when users stream Project
to their desktops, even when Excel 2007 is also streamed. [#223304]
Running Office Web Components in Project 2007 is not supported on Windows 7
operating systems. [#223553]
There are no workarounds for these issues.
●
Third-party known issues for application streaming:
●
31
This release does not support streaming IBM Personal Communications 4.2 or IBM
ClearQuest. [#259830]
Known Issues
●
This release does not support streaming to clients through Web Interface on the
following browsers: [#262650, 257135]
●
Microsoft Internet Explorer 9
Mozilla Firefox 4.0
Other known issues for application streaming:
●
●
Launching the streamed application SAP 7.20 or earlier versions on a non-English
platform displays the user interface in English. In addition, the language drop-down
located at File > Options > General > Language is blank.
As a workaround, install the SAP application in the profile, and after installation, open
the command prompt inside the Profiler. Navigate to the Lang folder (C:\Program
Files\SAP\FrontEnd\SAPgui\Lang\) and copy all the files to location C:\Lang\.
[#260029]
●
After creating the first target, you cannot modify the "Enable User Updates" setting for
the profile. The setting that you select for the first target applies to all other targets
that you add to this profile, even if you manually select a different setting for
subsequent targets. [#252225]
●
The Load Balancing policy fails to prevent a fallback option for delivery of an
application published for dual-mode streaming (streamed if possible, otherwise stream
accessed from a server).
The Load Balancing policy is supposed to be able to override the dual mode and force
one or the other delivery method, disallowing the other, for the specified groups of
users. In this release, the policy fails to prevent the fallback option, and the application
will be delivered as specified in the publishing process. There is no workaround for this
issue. [#258537]
●
An application that is streamed to the server cannot support more than one extra
parameter when there is a space character in one of the parameters. While profiling, if
you add an extra parameter that has spaces, only one parameter is supported. If there
are no spaces in the parameter, multiple parameters are supported. [#262752]
●
The AppHubWhiteList is sometimes deleted when you update the Offline Plug-in. After
updating the plug-in, verify that the AppHubWhiteList is still included with the plug-in,
and if missing, add it manually. [#262709]
Single Sign-on Issues
32
●
Features that require the Single Sign-on Service might fail if the Single Sign-on Plug-in
5.0 is installed on user devices that do not have the Visual C++ 8.0 runtime library
installed. To prevent this, ensure that the Visual C++ 8.0 runtime library is installed on
the user device before installing the Single Sign-on Plug-in. [#261051]
●
On user devices that are running double-byte character language operating systems and
have the Single Sign-on Plug-in 5.0 installed, Input Method Editor (IME) might fail
against the question-based authentication dialog boxes for self-service password reset
and self-service account unlock. To allow users to use account self-service from these
user devices, ensure that their answers to security questions are in languages that do
not require IME. [#262856]
Known Issues
Other Known Issues
●
XenApp servers might stop responding when multiple users are making frequent
connections to the servers. Installing Service Pack 1 for Windows Server 2008 R2 or
Microsoft Hotfix Windows.1-KB2383928-x64 on the server prevents this from occurring.
See Microsoft Knowledge Base article #2383928 for more information. [#254069]
●
Adobe Flash content playback is poor when using server-side content fetching over a
slow WAN connection. This may result in response failures for the Flash window or Web
browser and extremely long buffer times and pauses. To avoid this issue, use
server-rendered Flash delivery for user devices using WAN connections. [#261879]
●
When using Secure Gateway in an environment where data is encrypted using SSL
protocol, SSL-secured sessions might disconnect unexpectedly, reporting an SSL Library
Error 45. [#259611]
●
When publishing content to a XenApp server, the access control settings appear
differently depending on whether you view them with the AppCenter console or with
the XenApp command Get-XAApplication. For example, while the AppCenter might
correctly display default settings, the XenApp command Get-XAApplication might
display that no Access Gateway connections are allowed. This issue affects only the
display of these settings; users can access the published content normally.
To ensure a consistent display of access control settings, use the XenApp SDK to
configure and publish content applications. [#261283]
●
Published applications might fail to launch, displaying a black window in place of the
application window, if system memory is low. This condition is indicated by this system
event log message, with picadd as its source: "The Citrix Thinwire driver stopped
because it cannot allocate the required memory. You may need to manually disconnect
and restart any existing sessions." [#261647]
Citrix Systems, Inc.
851 West Cypress Creek Road
Fort Lauderdale, Florida 33309 USA
954-267-3000
http://www.citrix.com
33
System Requirements for XenApp 6.5
System requirements for the XenApp server role and the Citrix AppCenter are described
below. System requirements for other XenApp features, components, and related
technologies are described in their respective system requirements documentation; that
includes receivers, plug-ins and agents, Web Interface, Single Sign-on, Service Monitoring,
EdgeSight, SmartAuditor, Application Session Recording, Provisioning Services, and Power
and Capacity Management.
To ensure the availability of XenApp 6.5 features and correct operation:
●
Use the Citrix License Server Version 11.9 (minimum).
●
Install the most recent version of any receivers, plug-ins, and agents you use. At the
time of its release, XenApp 6.5 was tested with Receiver for Windows 3.0 (with plug-in
13.0). The Citrix Online Plug-in (Web and Full) 12.1 was also tested and can be used,
but some XenApp 6.5 features will not be available.
You must be in the Administrators group to install and configure the XenApp server role.
Elevating your privilege to local administrator through User Account Control is not a
substitute for Administrators group membership.
Important:
●
Do not install XenApp on a domain controller. Citrix does not support installing XenApp
on a domain controller.
●
Do not join servers running this XenApp version to a deployment with servers running
previous XenApp versions (including early release and Technical Preview versions).
●
You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix
does not support using a console from a previous XenApp release to manage XenApp 6.5
farms. (However, you can use the AppCenter from the XenApp 6.5 media to manage a
XenApp 6.0 farm.)
●
See Installing and Configuring XenApp for additional guidance, including tasks to
complete before installing and configuring XenApp.
Deploying Prerequisites
During a wizard-based installation, the XenApp Server Role Manager (using the Server Role
Installer) automatically installs XenApp prerequisites, as noted below.
For command-line installations, you must install the prerequisite software and Windows
roles before installing XenApp (except as noted). You can deploy prerequisites with
PowerShell cmdlets, the Microsoft ServerManagerCmd.exe command, or the Microsoft
Deployment Image Servicing and Management (DISM) tool.
34
System Requirements
If installation of a required Windows role or other software requires a restart (reboot),
restart the server before starting the XenApp server role installation.
XenApp Server Role
Supported operating systems: Windows Server 2008 R2 and Windows Server 2008 R2 SP1
(Enterprise, Standard, Datacenter, and Foundation).
Most servers running the supported operating systems meet the hardware requirements for
XenApp with ample processing power to host user sessions accessing the published
resources. However, additional research may be needed to determine if current hardware
meets the requirements.
●
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: up to 3.2GB
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)
When you install the XenApp server role, XML and Internet Integration Service (IIS)
integration is an optional component. When this component is installed, the Citrix XML
Service and IIS share a port (default = 80). When this component is not installed, the Citrix
XML Service defaults to standalone mode with its own port settings. You can change the
port during or after XenApp configuration. The Server Role Installer checks for installed IIS
role services and whether the component is selected or specified. For complete
information, see Before Installing XenApp. The IIS role services are listed below.
35
System Requirements
●
Web Server (IIS) > Common HTTP Features > Default Document (selecting this
automatically selects Web Server (IIS) > Management Tools > Management Console,
which is not required or checked for XenApp installation)
●
Web Server (IIS) > Application Development > ASP.NET (selecting this automatically
selects Web Server (IIS) > Application Development > .NET Extensibility; although not
checked for XenApp installation, ASP.NET requires .NET Extensibility)
●
Web Server (IIS) > Application Development > ISAPI Extensions
●
Web Server (IIS) > Application Development > ISAPI Filters
●
Web Server (IIS) > Security > Windows Authentication
●
Web Server (IIS) > Security > Request Filtering
●
Web Server (IIS) > Management Tools > IIS 6 Management Compatibility (includes IIS 6
Metabase Compatibility, IIS 6 WMI Compatibility, IIS 6 Scripting Tools, and IIS 6
Management Console)
If you plan to use Philips SpeechMike devices with XenApp, you may need to install drivers
on the servers hosting sessions that record audio before installing XenApp. For more
information, see Citrix information on the Philips web site.
AppCenter
XenApp Management includes the AppCenter. By default, the AppCenter is installed on the
same server where you install the XenApp server role; however, you can install and run the
AppCenter on a separate computer. To install the AppCenter on a workstation, from the
XenApp Autorun menu, select Manually Install Components > Common Components >
Management Consoles.
Supported operating systems:
●
Windows Server 2008 R2, 64-bit edition, SP1
●
Windows Server 2008 R2, 64-bit edition
●
Windows Server 2008 Enterprise, 32-bit edition, SP2
●
Windows Server 2003 R2, 32-bit and 64-bit editions
●
Windows Server 2003, 32-bit and 64-bit editions, SP2
●
Windows 7 Enterprise, 32-bit and 64-bit editions, SP1
●
Windows Vista Enterprise, 32-bit and 64-bit editions, SP2
●
Windows XP Professional, 32-bit edition, SP3
●
Windows XP Professional, 64-bit edition, SP2
Requirements:
36
System Requirements
●
Disk space: 25MB
●
Microsoft Management Console (MMC):
●
For Windows Vista, Windows 7, Windows Server 2008 R2, and Windows Server 2008
R2 SP1: MMC 3.0 (installed by default)
For other supported Windows operating systems: MMC 2.0 or 3.0
The XenApp Server Role Manager deploys the following software, if it is not already
installed:
●
●
Microsoft .NET Framework 3.5 SP1
●
Microsoft Windows Installer (MSI) 3.0
●
Microsoft Windows Group Policy Management Console
●
Microsoft Visual C++ 2005 SP1 Redistributable (x64)
●
Microsoft Visual C++ 2008 SP1 Redistributable (x64)
●
Microsoft Visual C++ 2008 SP1 Redistributable
●
Microsoft Visual C++ 2005 SP1 Redistributable
●
Microsoft Primary Interoperability Assemblies 2005
If you install the AppCenter on a computer that previously contained the Microsoft Group
Policy Management Console (GPMC) and a Citrix Delivery Services Console earlier than the
version delivered with XenApp 6.0, you may also need to uninstall and reinstall the Citrix
XenApp Group Policy Management Experience (x64) program in order to use the GPMC to
configure Citrix policies.
Data Store Database
The following databases are supported for the XenApp data store:
●
Microsoft SQL Server 2008 Express R2
●
Microsoft SQL Server 2008 Express SP3
●
Microsoft SQL Server 2008 R2
●
Microsoft SQL Server 2008 SP2
●
Microsoft SQL Server 2005 SP4
●
Oracle 11g R2 32-bit Enterprise Edition
Microsoft SQL Server 2008 Express can be deployed for you by the XenApp Server
Configuration Tool when creating a XenApp farm.
37
System Requirements
For information about the latest supported database versions, see CTX114501. For
information about requirements, see Data Store Database Reference.
38
Design and Plan
XenApp is the central software component of the Citrix Windows Application Delivery
Infrastructure. The goals of XenApp and the Citrix Windows Application Delivery
Infrastructure are to deliver on-demand applications to both physical and virtual desktops,
and to determine and provide the best method of delivery. XenApp offers three methods for
delivering applications to user devices, servers, and virtual desktops:
●
Server-side application virtualization: applications run inside the Data Center. XenApp
presents each application interface on the user device, and relays user actions from the
device, such as keystrokes and mouse actions, back to the application.
●
Client-side application virtualization: XenApp streams applications on demand to the
user device from the Data Center and runs the application on the user device.
●
VM hosted application virtualization: problematic applications or those requiring
specific operating systems run inside a desktop on the Data Center. XenApp presents
each application interface on the user device and relays user actions from the device,
such as keystrokes and mouse actions, back to the application.
To provide these types of application delivery, you have many choices of deployment
designs and XenApp features, which you can tailor for your users' needs. A typical process
for planning a XenApp farm includes:
1. Becoming familiar with XenApp and XenApp Setup by creating a small, one-server or
two-server test farm.
2. Deciding which applications to deliver to users.
3. Determining how you want to deliver applications - this includes testing and evaluating
the applications and peripheral requirements.
4. Determining application to application communication, where to install the applications
on XenApp servers, and which applications can be collocated.
5. Determining the number of servers you need for applications.
6. Determining the total number of servers you need for your farm and evaluating
hardware requirements.
7. Creating the network infrastructure design.
8. Defining the installation processes.
9. Creating and testing a pre-production pilot farm based on your farm design.
10. Releasing the farm into production.
To help you understand how a XenApp deployment delivers applications so you can
complete planning tasks, consider the following diagram.
39
Plan
A XenApp deployment consists of three deployment groups: user device (represented in this
diagram by Citrix Receiver), Access Infrastructure, and Virtualization Infrastructure.
●
On the left of this diagram is Citrix Receiver, which represents the set of devices on
which you can install client software. Citrix Receiver manages the client software that
enables your users to interact with virtualized applications. When designing a XenApp
deployment, you consider how your users work, their devices, and their locations.
●
Access Infrastructure represents secure entry points deployed within your DMZ and
provide access to resources published on XenApp servers. When designing a XenApp
deployment, you provide secure access points for the different types of users in your
organization.
●
Virtualization Infrastructure represents a series of servers that control and monitor
application environments. When designing a XenApp deployment, you consider how
applications are deployed based on your user types and their devices, the number of
servers you need, and which features you want to enable in order to provide the
support, monitoring, and management your organization requires.
The following diagram shows the access infrastructure in greater detail.
40
Plan
In this access infrastructure diagram:
●
Citrix Receiver runs the applications.
●
Onsite users within your corporate firewall interact directly with the XenApp Web and
Services Site.
●
Remote-site users access applications through sites replicated by Citrix Branch
Repeater.
●
Off-site users access applications though secure access, such as Access Gateway.
●
The Merchandising Server makes available self-service applications to your users
through Citrix Dazzle.
●
The XML Service relays requests and information between the Access Infrastructure and
the Virtualization Infrastructure.
The following diagram shows the virtualization infrastructure in greater detail.
In this virtualization infrastructure diagram:
41
●
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
Plan
server configuration information are stored in the enterprise database.
42
●
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.
Farm Terminology and Concepts
Terminology
The XenApp planning documentation uses the following terminology:
Multi-user environment
An environment where applications are published on servers for use by multiple users
simultaneously.
Production farm
A farm that is in regular use and accessed by users.
Design validation farm
A farm that is set up in a laboratory environment, typically as the design or blueprint for
the production farm.
Pilot farm
A preproduction pilot farm used to test a farm design before deploying the farm across
the organization. A true pilot is based on access by select users, and then adding users
until all users access the farm for their everyday needs.
About Infrastructures
XenApp farms have two types of infrastructures:
●
The virtualization infrastructure consists of the XenApp servers that deliver virtualized
applications and VM hosted Applications, and XenApp servers that support sessions and
administration, such as the data store, data collector, Citrix XML Broker, Citrix License
Server, Configuration Logging database (optional), Load Testing Services database
(optional), and Service Monitoring components.
●
Access infrastructure consists of server roles such as the Receiver Storefront, Web
Interface, Secure Gateway (optional), and Access Gateway (optional) that provide
access administration.
In small deployments, you can group one or more server functions together. In large
deployments, you provide services on one or more dedicated servers.
Factors other than size can affect how you group server functions. Security concerns,
virtualized servers, and user load play a part in determining which functions can be
collocated.
43
Design and Plan
Typically, in larger farms, you segregate session and administrative functions onto distinct
servers. For small farms, you might have one server hosting infrastructure functions and
multiple servers hosting published applications.
Small farms that require redundancy might have one or two servers hosting session and
administrative functions. For example, in a small farm, the data store might be configured
on the same server as the data collector and the XML Broker and, perhaps also the Citrix
License Server.
Medium and large farms might group similar functions. For example, the XML Broker might
be grouped with the data collector. In some larger deployments, each infrastructure service
would likely have one or more dedicated servers.
About Virtualization Infrastructure
The virtualization infrastructure, which is the center of a XenApp deployment, concerns the
following concepts:
Application enumeration
Application enumeration is when Citrix client software lists virtualized applications
available on the XenApp servers. The client software transmits data to locate servers on
the network and retrieves information about the published applications. For example,
during enumeration, Citrix Receiver communicates through the Citrix XML Service with
the XenApp server to determine applications available for that user.
Application publishing
To deliver an application to your users, whether virtualized on the desktop or the server,
use the AppCenter to publish the application.
Citrix Licensing
A Citrix License Server is required for all XenApp deployments. Install the license server
on either a shared or stand-alone server, depending on your 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.
44
Design and Plan
By default, the data collector is configured on the first server when you create the farm,
and all other servers configured with the controller server mode have equal rights to
become the data collector if the data collector fails. When the 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.
Applications are typically not published on the data collector.
Zones
A zone is a grouping of XenApp servers that communicate with a common data collector.
In large farms with multiple zones, each zone has a server designated as its data
collector. Data collectors in farms with more than one zone function as communication
gateways with the other zone data collectors.
The data collector maintains all load and session information for the servers in its zone.
All farms have at least one zone, even small ones. The fewest number of zones should be
implemented, with one being optimal. Multiple zones are necessary only in large farms
that span WANs.
Streaming Profiles
You can deliver applications to users by either virtualizing them on the desktop
(streaming) or by virtualizing them on the server (hosting). If you are virtualizing
applications on the desktop, either streaming to the client or server, create a streaming
profile server in your environment. To virtualize applications on the desktop, you create
profiles of the application and then store the profile on a file or Web server. The profile
consists of the manifest file (.profile), which is an XML file that defines the profile, as
well as the target files, a hash key file, the icons repository (Icondata.bin), and a scripts
folder for pre-launch and post-exit scripts.
Receiver Storefront
Receiver Storefront authenticates users to XenDesktop sites and XenApp farms,
enumerating and aggregating available desktops and applications into stores that users
access through Citrix Receiver or a Web page. The Receiver Storefront database records
details of resource subscriptions and shortcuts to enable synchronization of users'
desktops and applications across their devices.
Web Interface
You can use the Web Interface in any environment where users access their applications
using either Receiver or a Web browser. Install the Web Interface on a stand-alone
computer; however, where resources are limited, the Web Interface can be collocated
with other functions.
XenApp Web and XenApp Services Sites
XenApp Web and XenApp Services sites (formerly known as Access Platform and Program
Neighborhood Agent Services sites, respectively) provide an interface to the server farm
from the client device. When a user authenticates to a XenApp Web or XenApp Services
site, either directly or through Receiver or the Access Gateway, the site:
●
45
Forwards the user’s credentials to the Citrix XML Service
Design and Plan
●
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 Broker and the Web Interface
The Citrix XML Broker functions as an intermediary between the other servers in the farm
and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:
●
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 functions.
46
Farm Terminology and Concepts
Terminology
The XenApp planning documentation uses the following terminology:
Multi-user environment
An environment where applications are published on servers for use by multiple users
simultaneously.
Production farm
A farm that is in regular use and accessed by users.
Design validation farm
A farm that is set up in a laboratory environment, typically as the design or blueprint for
the production farm.
Pilot farm
A preproduction pilot farm used to test a farm design before deploying the farm across
the organization. A true pilot is based on access by select users, and then adding users
until all users access the farm for their everyday needs.
About Infrastructures
XenApp farms have two types of infrastructures:
●
The virtualization infrastructure consists of the XenApp servers that deliver virtualized
applications and VM hosted Applications, and XenApp servers that support sessions and
administration, such as the data store, data collector, Citrix XML Broker, Citrix License
Server, Configuration Logging database (optional), Load Testing Services database
(optional), and Service Monitoring components.
●
Access infrastructure consists of server roles such as the Receiver Storefront, Web
Interface, Secure Gateway (optional), and Access Gateway (optional) that provide
access administration.
In small deployments, you can group one or more server functions together. In large
deployments, you provide services on one or more dedicated servers.
Factors other than size can affect how you group server functions. Security concerns,
virtualized servers, and user load play a part in determining which functions can be
collocated.
47
Farm Terminology and Concepts
Typically, in larger farms, you segregate session and administrative functions onto distinct
servers. For small farms, you might have one server hosting infrastructure functions and
multiple servers hosting published applications.
Small farms that require redundancy might have one or two servers hosting session and
administrative functions. For example, in a small farm, the data store might be configured
on the same server as the data collector and the XML Broker and, perhaps also the Citrix
License Server.
Medium and large farms might group similar functions. For example, the XML Broker might
be grouped with the data collector. In some larger deployments, each infrastructure service
would likely have one or more dedicated servers.
About Virtualization Infrastructure
The virtualization infrastructure, which is the center of a XenApp deployment, concerns the
following concepts:
Application enumeration
Application enumeration is when Citrix client software lists virtualized applications
available on the XenApp servers. The client software transmits data to locate servers on
the network and retrieves information about the published applications. For example,
during enumeration, Citrix Receiver communicates through the Citrix XML Service with
the XenApp server to determine applications available for that user.
Application publishing
To deliver an application to your users, whether virtualized on the desktop or the server,
use the AppCenter to publish the application.
Citrix Licensing
A Citrix License Server is required for all XenApp deployments. Install the license server
on either a shared or stand-alone server, depending on your 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.
48
Farm Terminology and Concepts
By default, the data collector is configured on the first server when you create the farm,
and all other servers configured with the controller server mode have equal rights to
become the data collector if the data collector fails. When the 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.
Applications are typically not published on the data collector.
Zones
A zone is a grouping of XenApp servers that communicate with a common data collector.
In large farms with multiple zones, each zone has a server designated as its data
collector. Data collectors in farms with more than one zone function as communication
gateways with the other zone data collectors.
The data collector maintains all load and session information for the servers in its zone.
All farms have at least one zone, even small ones. The fewest number of zones should be
implemented, with one being optimal. Multiple zones are necessary only in large farms
that span WANs.
Streaming Profiles
You can deliver applications to users by either virtualizing them on the desktop
(streaming) or by virtualizing them on the server (hosting). If you are virtualizing
applications on the desktop, either streaming to the client or server, create a streaming
profile server in your environment. To virtualize applications on the desktop, you create
profiles of the application and then store the profile on a file or Web server. The profile
consists of the manifest file (.profile), which is an XML file that defines the profile, as
well as the target files, a hash key file, the icons repository (Icondata.bin), and a scripts
folder for pre-launch and post-exit scripts.
Receiver Storefront
Receiver Storefront authenticates users to XenDesktop sites and XenApp farms,
enumerating and aggregating available desktops and applications into stores that users
access through Citrix Receiver or a Web page. The Receiver Storefront database records
details of resource subscriptions and shortcuts to enable synchronization of users'
desktops and applications across their devices.
Web Interface
You can use the Web Interface in any environment where users access their applications
using either Receiver or a Web browser. Install the Web Interface on a stand-alone
computer; however, where resources are limited, the Web Interface can be collocated
with other functions.
XenApp Web and XenApp Services Sites
XenApp Web and XenApp Services sites (formerly known as Access Platform and Program
Neighborhood Agent Services sites, respectively) provide an interface to the server farm
from the client device. When a user authenticates to a XenApp Web or XenApp Services
site, either directly or through Receiver or the Access Gateway, the site:
●
49
Forwards the user’s credentials to the Citrix XML Service
Farm Terminology and Concepts
●
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 Broker and the Web Interface
The Citrix XML Broker functions as an intermediary between the other servers in the farm
and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:
●
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 functions.
50
Planning a Successful User Experience
Two key factors impact your users' satisfaction when working in a multi-user environment:
how quickly sessions start, and how easily users can print.
Session Start-up Times
Certain factors can cause sessions to start slower than necessary.
●
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:
51
●
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.
Planning a Successful User Experience
●
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.
52
Farm Hardware Considerations
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.
●
53
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.
Planning for Applications and Server
Loads
Before you can determine how many servers you need in your farm and on which servers to
install applications, decide which applications you want to deliver and how you want to
deliver them.
Consider these factors when defining your farm’s hardware and operating system
configuration:
54
●
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.
Assessing Applications for XenApp
Compatibility
Ensure applications are compatible with the server operating system and are multiuser
compatible. Application compatibility drives the application delivery method (for example,
accessed from the server, streamed to server, or streamed to client desktops).
Evaluate whether or not applications are compatible with multiuser environments and, if
so, the application 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
it is installed and hosted on a server in a test farm and having multiple test users connect
to it. Applications that function correctly should be tested for conflicts with other
applications you want to install on the server and, then, scalability.
Applications that do not function correctly might not have been designed for multiuser,
multiapplication environments. Applications not designed for these environments can
conflict with other applications or have scalability or performance issues. Registry settings,
attempts to share files or DLLs, requirements for the exclusive use of files or DLLs, or other
functionality within an application can make it incompatible. You can resolve some
application issues through streaming, using features like Virtual IP, or siloing the
application.
After testing, if these solutions do not work, you might need to find and fix the root cause
of the problem. To identify root applications issues, consider using tools like the Microsoft
Application Compatibility Toolkit (ACT) or 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.
55
Evaluating Application Delivery Methods
The application delivery method is a factor in determining the number of servers in a farm
and their individual hardware requirements.
How you choose to deliver applications depends on your organization's needs and end-users'
requirements. For example, some organizations use XenApp to streamline administration. In
other organizations, the existing hardware infrastructure might affect the delivery method
selected, as can the types of applications to be delivered. In addition, some end-users
might run all applications while connected to the company network, while others might
work in remote locations and run applications while disconnected from the network.
Method/Description
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.
56
●
This method provides a
consistent user experience
regardless of the user
device.
●
Farm servers require
sufficient resources to
support the
applications.
●
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.
Users must be
connected to the server
or network to run the
applications (no offline
access).
●
This method is effective
for applications with
components that are
intertwined with the
operating system (such as
a .NET framework).
Evaluating Application Delivery Methods
Streamed to server:
Executables for
applications are put in
profiles and stored on a
file server or Web server
(the App Hub); however,
when launched, they
stream to the server, and
application processing
takes place on the
server. Unlike installed
applications, streamed
applications are stored in
the App Hub and provide
application isolation by
design.
Streamed to desktop:
Executables for
applications are put in
profiles and stored on a
file server or Web server
(the App Hub). When
launched, the files
required to execute the
application are streamed
to the user device, and
application processing
takes place on the user
device instead of the
XenApp server. When
applications are
streamed to the user
device, the user
experience is similar to
running applications
locally. After
applications are cached
on the user device, users
can continue running the
apps after disconnecting
from the network
(referred to as offline
access).
57
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.
●
Farm servers require
sufficient resources to
support the
applications.
●
Users must be
connected to the server
or network (no offline
access).
●
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.
●
Some applications are
not candidates for
profiling, such as those
using a .NET
framework.
●
Updating applications is
simplified because you
update only a single
application profile.
●
Users can have the local
application experience,
but you manage the
applications centrally.
●
●
Users might have a better
experience when
resource-intensive
applications, such as
graphics applications, are
streamed to desktops.
User devices must have
sufficient resources to
run the applications
locally; the user
devices cannot be thin
clients.
●
User devices must run
Windows operating
systems, including
Windows 7, XP, or
Vista.
●
●
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.
Evaluating Application Delivery Methods
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.
58
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.
59
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 siloing applications
and not siloing applications.
When applications are siloed on farm servers, each server has a limited number of
applications. Some servers might have only one application; others might have a set of
interrelated applications. For example, you might install a medical application on Server A,
and on Server B install an enterprise resource planning (ERP) application. However, if the
ERP application is integrated with email, you might also have an email client on Server B.
Siloing is sometimes required when applications have unique hardware requirements, for
business reasons, to segregate mission-critical applications, or to separate
frequently-updated applications. However, siloing applications is not as efficient as
nonsiloed applications for hardware use and network traffic.
With a nonsiloed approach, you install all applications on each server. Applications can be
installed traditionally or in isolation (installing them in separate profiles).
Citrix recommends installing applications that interact with each other on the same server,
or including them in the same streaming profile. For example, if an application interacts
with an email client by letting users send email notifications, install the application and the
email client on the same server. Likewise, if applications share settings and preferences
(such as Microsoft Office), install them on the same server.
Advantages
60
Disadvantages
Placing Applications on Servers
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
●
Reduces the number of servers
required for applications in smallto medium-sized farms
●
Might simplify user permissions
and ensure consistent settings
during application installation
●
Additional servers are
required to ensure sufficient
redundancy
●
Cannot be used when
applications conflict with
other applications
Nonsiloed
A single server is accessed by each
user and session sharing is ensured
By using features such as Load Manager and Preferential Load Balancing, you might not
need to silo mission-critical applications or applications with high levels of peak usage.
●
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.
●
61
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
Placing Applications on Servers
example, doctors in a hospital could be specified as important users and MRI scans or
X-rays could be specified as important applications. These important users and
applications with higher levels of service have more computing resources available to
them. By default, a Normal level of service is assigned to all users and applications.
Different application workloads can co-exist on a server; simply assign important
applications a higher importance level.
The key difference between the Load Manager and Preferential Load Balancing features is
that the Preferential Load Balancing can be used to treat each session differently, whereas
Load Manager treats each session the same.
Although you can use applications as the basis for Load Manager decisions, Citrix does not
recommend it. Citrix recommends invoking Load Manager based on the server only.
Citrix does not recommend load balancing across zones on a WAN.
Centralizing or Distributing Application Servers
For organizations with geographically dispersed sites, application servers might be located
centrally with the infrastructure servers (for example, in a data center) or decentrally,
near the users who access the applications or in the same geographic region as the users.
Citrix recommends placing application servers logically near any data sources. For example,
for an enterprise resource planning application, collocate those XenApp servers within the
same data center. Another example is a multinational corporation that uses Microsoft
Exchange 2007 as the data source for email. Although the company could centralize all the
Exchange servers at the primary data center, they would be more likely to enable the
Exchange servers within each region and then locate the XenApp servers hosting Outlook
there as well.
Advantages
Servers centralized
at one site
62
●
Centralized server
administration and support.
●
Centralized application
management.
●
Potentially better physical
security than in branch
offices.
Disadvantages
●
Single point of failure; if
the site loses
connectivity, users have
no alternative access.
Placing Applications on Servers
Servers distributed
across multiple sites
●
Enhanced business continuity
and redundancy; if one site
loses connection, it does not
affect all application access.
●
When data is maintained at
different sites, placing servers
at those sites provides users
with local access to the data.
●
Sites can administer their own
servers.
●
●
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.
Zone Preference and Failover
can be invoked if multiple
zones.
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.
63
Determining the Number of XenApp
Servers to Deploy
After you identify the applications you are delivering to your users and their methods of
delivery, you can estimate the number of XenApp servers required for your deployment.
For applications virtualized on the server, the number of servers required depends on the
following factors:
●
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.
64
Deciding How Many Farms to Deploy
Most organizations deploy a single farm. However, there are some circumstances in which
deploying multiple farms makes sense. The decision to implement a single farm or multiple
farms is influenced by:
●
Location and needs of the users or your organization - If your organization is a service
provider, you might want to dedicate a farm to each organization for which you provide
service. Multiple farms might make it easier to demonstrate compliance with specific
service level agreements.
●
Geographic layout of your organization - If your IT infrastructure is organized by region
and managed in a decentralized manner, multiple farms could improve farm
performance. Multiple farms could also save time when coordinating farm
administration and simplify troubleshooting farm-wide issues.
●
Network infrastructure limitations - In WANs with high latency or error rates, multiple
farms may perform better than a single farm with multiple zones.
●
Organizational security policies concerning server communications - Consider multiple
farms if your organization needs to segregate data based on security level. Likewise,
you might need multiple farms for regulatory compliance.
There is no exact formula for determining the ideal number of farms, but general guidelines
can help:
●
In general, a single farm meets the needs of most deployments. A significant benefit to
deploying a single farm is needing only one data store database.
●
Consider using multiple farms when you have geographically dispersed data centers that
can support their own data store database, or when you do not want communication
between servers within the farm to cross a firewall or WAN. For very large deployments
with thousands of servers, breaking the environment into multiple farms can increase
performance.
Citrix regularly tests farm scalability based on 1000-server farms.
65
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.
Deciding How Many Farms to Deploy
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
information such as logons and
application use across the farm.
Multiple farms might improve
performance over a single farm
when server-to-server traffic
crosses a WAN link or when the
farm is very large.
Management
Tools
You can monitor and configure
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:
66
●
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.
Planning Server Functions
Regardless of your farm size, Citrix recommends having at least one server dedicated to
functions other than those related to running published applications. Publishing applications
on a server that also hosts administrative functions slows down application enumeration. If
you decide to install administrative functions on a server hosting published applications,
choose a server that hosts an infrequently used and not resource-intensive application (or
lower the load threshold for that server so that it accepts fewer connections).
While farm size (small, medium, large) as determined by the number of servers, can
indicate the general category of your farm, consider the number of user connections.
Because applications can scale differently from server to server (some servers might
support 100 user connections, others might support only ten), looking solely at the number
of servers might be misleading. Determine how you want to group functions by designing an
initial configuration, then fine tune the design after testing the pilot farm.
As you add user connections in your test configuration, watch the Windows Performance
Monitor counters:
●
When the peak number of users is connecting simultaneously to the farm.
●
When the peak number of users is connected to the farm.
If the counters exceed the values listed in the table, move the administrative functions on
to separate servers until the counter metric no longer exceeds the value.
67
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 evaluated
only in large farms)
Planning the XenApp Data Store
When you deploy your server farm, it must have an associated data store. When servers in a
farm come online, they query the data store for configuration information. The data store
provides a repository of persistent information, including:
●
Farm configuration information
●
Published application configurations
●
Server configurations
●
Citrix administrator accounts
●
Printer configurations
The System Requirements lists the databases you can use for the farm data store. For
information about supported database versions, see
http://support.citrix.com/article/CTX114501.
Choosing a Database
Consider these factors before deciding which database product to use:
●
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
●
68
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
Planning the XenApp Data Store
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.
69
Database Server Hardware Performance
Considerations
Increasing the CPU power and speed of the database server can improve the response time
of queries made to the data store when:
●
Starting the Citrix IMA Service on multiple servers simultaneously
●
Adding a server to the farm
●
Removing a server from the farm
The response time of other events (such as starting the IMA Service on a single server,
recreating the local host cache, or replicating printer drivers to all servers in the farm) is
affected more by the farm size than by the data store response time.
Adding processors to the server hosting the data store can improve response time when
executing multiple simultaneous queries. In environments with large numbers of servers
coming online simultaneously and at frequent intervals, additional processors can service
requests faster.
The capabilities of the processor on the database server affect 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.
70
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
console
8
16
25
50
50
Database Server Hardware Performance Considerations
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
Dual Pentium 4/1.6GHz with 2GB RAM
X
X
X
Dual Pentium 4/3.0GHz with 4GB RAM
X
X
X
D
E
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.
71
Replication Considerations
When you join a new server to a XenApp farm, a significant amount of time can be spent
waiting for the server's Citrix Independent Management Architecture (IMA) service to start
and come online. As a result, you might choose to configure SQL data store replication at
each remote site, to allow member servers to point to their local SQL subscriber and avoid
the slowness of traversing the WAN. However, as your farm expands geographically, the
overhead of administering SQL subscribers at each of your sites becomes a burden.
In XenApp 6.5, you can configure servers in session-host mode (also known as session-only
mode). This server mode allows XenApp servers to join a farm in significantly less time with
substantial bandwidth savings.
When a XenApp server joins a farm, it performs numerous read and write operations to the
IMA data store as well as a download of the farm data to its Local Host Cache (LHC). In
previous releases of XenApp, all member servers of the farm were required to download all
farm data to their LHC during a join, resulting in a large amount of data store transactions
and bandwidth consumption. In XenApp 6.5, you can dedicate a select few servers as
XenApp controllers which are responsible for farm management tasks, while the remaining
member servers are session-only servers whose sole task is to host user sessions. XenApp
controllers must synchronize all of the farm data, while session-only servers must
synchronize only a subset of the information to their LHC. These changes result in fewer
database transactions, less bandwidth consumption, and faster IMA startup performance.
While session-only XenApp servers can host XenApp user sessions, they cannot perform the
role of data collectors, nor can they participate in or trigger a data collector zone election.
The XML service does not run on session-only XenApp servers; therefore, the Web Interface
cannot use them to perform application enumerations. Additionally, management tasks
such as AppCenter discovery or PowerShell tasks cannot be run directly on a session-only
server. However, with proper planning and placement of XenApp controller servers,
leveraging the session-only model can optimize your farm performance and reduce IMA
bandwidth and server provisioning time.
You specify the XenApp server mode through the Server Role Manager when you configure
the XenApp role to join a farm. For more information, see the XenApp Server Mode section
in Before Configuring XenApp.
If you used data store replication in previous XenApp deployments, note that in XenApp 6.5:
●
Replication is no longer required because IMA architectural changes have significantly
improved WAN performance.
●
Future versions of Microsoft SQL Server may not support the replication model that
XenApp supports (transactional replication with immediate updating subscribers).
Therefore, although you can replicate a XenApp 6.5 data store on SQL Server 2008 R2 and
earlier versions, you do not need to, and you may not be able to with later SQL Server
versions.
72
Planning for Configuration Logging and
IMA Encryption
The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive
data in the IMA data store. Enabling IMA encryption provides an additional layer of security
for the data preserved by the Configuration Logging feature.
If you do not enable IMA encryption, XenApp uses the standard encryption used in previous
versions of XenApp. The Securing Server Farms documentation contains more information
about IMA encryption, Configuration Logging, and when to enable these features.
To enable IMA encryption, you specify a key which is used for all the servers in your farm.
To generate the key, use CTXKEYTOOL, which is available on the installation media.
For custom installations or provisioning servers in large environments, consider:
●
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.
73
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.
74
Designing Zones for a XenApp
Deployment
A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All
servers must belong to a zone. Unless otherwise specified during XenApp Setup, all servers
in the farm belong to the same zone, which is named Default Zone.
Zones have two purposes:
●
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.
75
Designing Zones for a XenApp Deployment
When designing zones, the most important variables to consider are latency and bandwidth.
The amount of bandwidth and the impacts of latency are highly dependent on your XenApp
deployment. The lower the bandwidth and the higher the latency, the longer a farm takes
to resynchronize the dynamic data among zones after an election.
In farms distributed across WANs, zones enhance performance by grouping geographically
related servers together. Citrix does not recommend having more than one zone in a farm
unless it has servers in geographically distributed sites. Zones are not necessary to divide
large numbers of servers. There are 1000-server farms that have only one zone.
Data collectors generate a lot of network traffic because they communicate with each
other constantly:
●
Each zone data collector has an open connection to all data collectors in the farm.
●
During a zone update, member servers update the data collector with any requests and
changed data.
●
Data collectors relay changes to the other data collectors. Consequently, data
collectors have the session information for all zones.
In general, Citrix recommends using the fewest number of zones possible, with one being
optimal. If all farm servers are in one location, configuring only one zone for the farm does
not reduce performance or make the farm harder to manage. However, in large networks,
such as organizations with data centers on different continents, grouping
geographically-related servers in zones can improve farm performance.
Keep in mind that data collectors must replicate changes to all other data collectors in the
farm. Also, bandwidth consumption and network traffic increase with the number of zones.
Separate zones are not required for remote sites, even ones on separate continents; latency
is the biggest factor in determining if servers should be put in their own zone. For large
farms with servers in different geographic regions, create zones based on the location of
significant numbers of servers.
Also decide if you want to configure failover zones or preferred zones. If a zone fails, you
can configure for user connections to be redirected to another zone (failover) or control to
which zones specific users connect (preference). Failover requirements might determine
the number of zones required.
For example, an organization with 20 farm servers in London, 50 servers in New York, and
three servers in Sydney could create two or three zones. If the Sydney location has good
connectivity to either New York or London, Citrix recommends grouping Sydney with the
larger location. Conversely, if the WAN connection between Sydney and the other locations
is poor or zone preference and failover is required, Citrix recommends configuring three
zones.
Consider these zone design guidelines:
76
●
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.
Designing Zones for a XenApp Deployment
77
●
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.
Planning for Application Access
Planning for Receiver Storefront
See the planning information in the Receiver Storefront documentation.
Planning for the Web Interface and XML Broker
The Web Interface and the XML Broker are complementary services. The Web Interface
provides users with access to applications. The XML Broker determines which applications
appear in the Web Interface, based on the 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 Receiver.
When users access the Web Interface from the Internet, Citrix recommends locating the
Web Interface server on the internal network and the Citrix XML Broker with the XenApp
farm. Shielding the XML Broker from the external Internet protects the XML Broker and the
farm from Internet security threats.
If you must place the Web Interface in the DMZ and want to secure the connection between
the XML Broker and the Web Interface, put the Web Interface server in the DMZ with Secure
Gateway or Access Gateway. This configuration requires putting the Web Interface on a
separate Web server. Install a certificate on the Web Interface server and configure SSL
Relay on the servers hosting the Citrix XML Broker.
78
Planning for Application Access
In very small farms, configuring the Web Interface and the XML Broker on the same server
eliminates having to secure the link from the Web Interface to the farm. This deployment is
used primarily in environments that do not have users connecting remotely. However, this
might not be possible if your organization does not want Web servers such as Internet
Information Services (IIS) in the farm.
79
Planning for Accounts and Trust
Relationships
Consider how users will access resources. When multiple servers host the same published
application, users could be connected to any of these servers when they access the
resource. Therefore, if a user does not have permissions for all servers, the user might not
be able to access the resource. To avoid these issues, you might need to establish domain
trust relationships between users or servers.
Also, in a farm with multiple, untrusted domains, when servers are load balanced, users can
be routed to a server in a domain in which they do not have access permissions. To ensure
your users are routed only to servers in domains in which they have access permissions:
●
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 AppCenter to set up Citrix administrator
accounts.
●
To create effective Citrix administrator accounts, ensure that all users you are going to
add as Citrix administrators are Domain Users for the domain in which your farm
resides. Users who are Citrix administrators who take server snapshots must also be
authorized Windows Management Instrumentation (WMI) users on each server for which
they are taking snapshots.
Including Servers from Other Domains
XenApp supports trust-based routing; servers in domains that do not trust each other can be
members of the same farm.
When a server needs to perform one of the following operations on an untrusted domain,
the server determines from the data store which servers can perform the operation and
routes the request to the most accessible server:
80
Planning for Accounts and Trust Relationships
●
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
Ctx_ConfigMgr
Service
Citrix strongly recommends that if you want to change local accounts to domain accounts,
you do so before installing XenApp. Changing service accounts after installation is not
supported.
Install XenApp as a domain administrator to ensure the accounts are created correctly. If
you are changing the accounts for services and your farm has servers in multiple domains,
the domains must have trust relationships with each other.
81
Recommendations for Active Directory
Environments
Citrix recommends the following configuration for server farms with Active Directory:
●
XenApp servers are in their own Organizational Units (OUs).
●
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 [email protected] identifier. With Active Directory, UPN logons
do not require a domain to be specified, because Active Directory can locate full UPN
logons in the directory. However, if the server farm has multiple forests, problems
occur if the same UPN identifier exists in two domains in separate forests.
Important: Citrix XenApp does not support UPN logons if a server farm spans multiple
Active Directory forests.
Active Directory User Permission
Active Directory security groups can affect authenticating to published applications or the
management console. The tables that follow contain best practice guidance.
Also, if a user is a member of a domain local group, the group is in the 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
82
Authenticating to published applications
No adverse effects
Authenticating to management console
No adverse effects
Recommendations for Active Directory Environments
Domain Local Groups
Authenticating to
published applications
Recommendation: All servers that load balance an application
must be in the same domain if a domain local group is
authorized to use the application.
Rationale: Domain local groups assigned to an application must
be from the common primary domain of all the load balancing
servers. When you publish applications, domain local groups
appear in the accounts list if the condition above is met and
accounts from the common primary domain are displayed. If a
published application has users from any domain local groups
and you add a server from a different domain, domain local
groups are removed from the configured users list, because all
servers must be able to validate any user with permission to
run the application.
Authenticating to
management console
Recommendation: If a user is a Citrix administrator only by
membership in a domain local group, the user must connect the
console to a server in the same domain as the domain local
group.
Rationale: If the user connects the console to a server in a
different domain than the domain local group, the user is
denied access to the console because the domain local group is
not in the 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.
83
Recommendations for Active Directory Environments
Active Directory Federated Services
XenApp supports Active Directory Federated Services (AD FS) when used with the Citrix Web
Interface. If you need to provide a business partner with access to published applications,
AD FS might be a better alternative than creating multiple new user accounts on the
enterprise domain. If you plan to use AD FS with XenApp, Citrix recommends:
●
When installing XenApp on each server in your farm, ensure the port sharing with IIS
option and ensure that IIS is configured to support HTTPS; see System Requirements for
more information.
●
Set up a trust relationship between the server running the Web Interface and any other
servers in the farm communicating with the Web Interface through the Citrix XML
Broker. The Web Interface must be able to access the certificate revocation list (CRL)
for the Certificate Authority used by the federation servers.
●
If you are provisioning the farm by imaging, configure trust requests on the server
before you take the image. These trust requests must be enabled on each server in the
farm and cannot be set at a farm level.
●
To prevent external users from having unauthorized access to services on farm servers,
configure all XenApp servers for constrained delegation. To provide users with access to
resources on those servers, add the relevant services to the Services list using the MMC
Active Directory Users and Computers snap-in.
For more information about configuring support for AD FS, see the Web Interface
documentation.
84
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.
85
Planning for UAC
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 Print Services role so you can manage printer drivers and print queues on
clients.
The following XenApp management features and tools require users be domain
administrators, delegated administrators, or part of the Administrators group on the local
computer:
●
AppCenter
●
XenApp Commands
●
SSL Relay tool
●
Speedscreen Latency Reduction Manager
These permissions are in addition to any requirements for the feature, such as having a
Citrix administrator account.
To allow multiuser access to an application, install the application as a built-in
administrator or enable the Create Users setting when prompted by UAC.
86
Planning for Shadowing
Session shadowing monitors and interacts with user sessions. When you shadow a user
session, you can view everything that appears on the 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.
87
Securing Delivery and Access
XenApp allows secure access to resources by users. It also enables administrators to control
and monitor access to each resource and component. See the Securing Server Farms
documentation for details.
Complementary XenApp technologies help provide end-to-end security, including Citrix
Single Sign-on, Citrix Access Gateway, and Secure Gateway. If you use one of these
technologies to control remote access to the farm, set your firewall ports to communicate
with the technology and the server farm.
If users will connect to your farm over the Internet, consider:
●
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 Citrix Receiver to users, especially if they connect
from airport kiosks or other public locations.
●
Securing connections to published applications with SSL/TLS. If Receiver communicates
with your farm across the Internet, Citrix recommends enabling SSL/TLS encryption
when you publish a resource. If you want to use SSL/TLS encryption, use either the SSL
Relay feature (for farms with fewer than five servers) or the Secure Gateway to relay
ICA traffic to the XenApp server. You can also use SSL Relay to secure Citrix XML Broker
traffic.
Important: XenApp installation and configuration opens Windows firewall ports to allow
incoming connections, such as those from ICA traffic, Citrix Independent Management
Architecture service, the Citrix XML Service, and SQL Server Express (if that database is
specified during XenApp configuration).
88
Planning for Supported Languages and
Windows MUI Support
XenApp 6 supports all languages of Windows Server (both native and Language Packs),
providing six XenApp user interface languages. The XenApp user interface language is
selected based on the language locale set in the Windows Server operating system when
XenApp is installed. The following table indicates which XenApp user interface language is
installed for each Windows System Language locale setting.
Windows Server 2008 R2 Language
Locale
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.)
89
Planning for Passthrough Client
Authentication
Citrix recommends enabling passthrough client authentication. When the user connects to
applications published on different servers, passthrough client authentication enables
XenApp to automatically pass user credentials from the initial server to the server hosting
the next application. This prevents the user from having to re-authenticate when opening
applications on different servers.
In this illustration, XenApp passes the user credentials from the server hosting Microsoft
Outlook to the server hosting Microsoft Excel when the user opens the Microsoft Excel
attachment from an email message hosted on a different server
(The passthrough authentication functionality described in this topic is not the same
functionality provided by Citrix Single Sign-on or password management applications in
general.)
Enabling passthrough authentication requires configuring components on all XenApp
application servers and enabling passthrough authentication in the Citrix Receiver installed
on end-user client devices. If the passthrough authentication feature is not enabled before
deploying the Receiver to end users, users must reinstall the Receiver with this feature
enabled before passthrough authentication will work.
To configure passthrough authentication functionality on the server, install a Citrix Receiver
on each XenApp server. If you are deploying the Receiver as the client for users, install the
Receiver on your server as the passthrough client.
90
Installing and Configuring XenApp
XenApp installation and configuration are separate tasks. This task division provides
flexibility when using provisioning tools and disk imaging.
●
For a wizard-based XenApp installation or configuration, use the XenApp Server Role
Manager.
●
From the command line, use the XenAppSetupConsole.exe command to install the
XenApp server role and the XenAppConfigConsole.exe command to configure the
XenApp server role.
XenApp uses roles for XenApp features and related technologies. The wizard-based XenApp
Server Role Manager uses the Server Role Installer to help you add certain XenApp roles. It
detects the deployment phase for each role and displays the next task required to complete
the installation and configuration of that role. From the XenApp Server Role Manager, you
can:
●
Install role prerequisites
●
Install fully-integrated server roles (such as XenApp, Citrix licensing, Single sign-on
service, and Provisioning Server)
●
Launch installers for partially-integrated roles (such as Power and Capacity Management
Administration, SmartAuditor Server, EdgeSight Server)
●
Launch the Citrix License Configuration Tool to configure the XenApp role license
parameters (mode, server, and port)
●
Launch the XenApp Server Configuration Tool to configure the XenApp server role
●
Launch configuration tools for other roles
●
Initiate a XenApp server restart (reboot)
●
Remove a server from a farm
●
Prepare a server for imaging and provisioning
●
Remove fully-integrated XenApp 6.5 roles and components
●
Upgrade roles (other than the XenApp server role) in XenApp 6 deployments
For command-line installation or configuration, enter the command with valid options and
properties at a Windows Server command prompt.
91
Install and Configure
Accessing the Server Role Manager
The XenApp Server Role Manager runs initially from the XenApp installation media. After
you install a role, the Server Role Manager is installed locally and runs every time you log
on to the XenApp server (you can disable this feature by selecting a checkbox on the main
Server Role Manager page). You can also run the Server Role Manager from Start > All
Programs > Administrative Tools > Citrix > XenApp Server Role Manager, or from its
Program Files location (Program Files
(x86)\Citrix\XenApp\ServerRoleManager\XenAppServerRoleManager). If a Server Role
Manager is installed locally and you invoke a different one from the XenApp installation
media, the version on the installation media is used.
Using the XenApp Media to Install and Upgrade
Citrix recommends using the XenApp 6.5 media to perform a clean install of the XenApp
server role on a Windows Server 2008 R2 or Windows Server 2008 R2 SP1 server. Clean
install means that there is no previous version of the XenApp server role installed on the
server. If you have an earlier XenApp version installed (including an early release or
Technical Preview version), reimage the server before installing the XenApp 6.5 server role.
If you cannot coordinate that recommended process, Citrix provides a XenApp 6.0 to 6.5
Upgrade Utility that you can customize for your servers; see CTX130614.
After you install and configure XenApp 6.5, you can migrate settings from a server running a
XenApp 5 or XenApp 6.0 to the new XenApp 6.5 farm. For details, see XenApp Migration
Center.
You can also remove a XenApp server role that was installed using the XenApp 6.5 media;
however, you cannot use this functionality to remove an earlier version of the XenApp
server role.
If you run the Server Role Manager from the XenApp 6.5 media on a XenApp 6.0 server, new
software may be available for installed roles and components other than the XenApp server
role. In these cases, the Server Role Manager will display Upgrade next to the role or
component; clicking that link starts the upgrade process.
Important: Do not attempt to upgrade components and features in a XenApp 6.0
deployment using MSIs from the XenApp 6.5 media, unless explicitly instructed to do so.
92
Preparing to Install and Configure
XenApp
Review Known Issues for late-breaking information.
You must be in the Administrators group to install and configure the XenApp software.
(Elevating your privilege to local administrator through User Account Control is not a
substitute for Administrators group membership.)
Important:
●
Do not install XenApp on a domain controller. Citrix does not support installing XenApp
on a domain controller.
●
Do not join servers running this version of XenApp to a deployment with servers running
previous versions of XenApp.
●
You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix
does not support using a console from a previous XenApp release.
To ensure availability of the features and functionality of XenApp to your users, install the
most recent version of receivers, plug-ins, and agents you use.
When installing roles or role components other than XenApp server, see the role
documentation for details about information you must provide during installation and
configuration.
For items to consider and tasks to complete before installing or configuring XenApp, see:
93
●
Before Installing XenApp
●
Before Configuring XenApp
Preparing to Install and Configure
XenApp
Review Known Issues for late-breaking information.
You must be in the Administrators group to install and configure the XenApp software.
(Elevating your privilege to local administrator through User Account Control is not a
substitute for Administrators group membership.)
Important:
●
Do not install XenApp on a domain controller. Citrix does not support installing XenApp
on a domain controller.
●
Do not join servers running this version of XenApp to a deployment with servers running
previous versions of XenApp.
●
You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Citrix
does not support using a console from a previous XenApp release.
To ensure availability of the features and functionality of XenApp to your users, install the
most recent version of receivers, plug-ins, and agents you use.
When installing roles or role components other than XenApp server, see the role
documentation for details about information you must provide during installation and
configuration.
For items to consider and tasks to complete before installing or configuring XenApp, see:
94
●
Before Installing XenApp
●
Before Configuring XenApp
Before Installing XenApp
●
Review the installation topics (wizard-based or command-line) to learn what
information you must provide.
●
Review the XenApp System Requirements and the system requirements for other roles
you plan to install.
●
In most cases, wizard-based XenApp installations include automatic installation of
prerequisite software and required Windows roles.
For command-line XenApp installations, you must install the prerequisite software
and Windows roles before installing XenApp. You can deploy prerequisites with
PowerShell cmdlets, the Microsoft ServerManagerCmd.exe command, or the
Microsoft Deployment Image Servicing and Management (DISM) tool.
Deploying prerequisites may require a server restart before you can install the XenApp
server role.
●
●
Ensure there is no other instance of the XenApp server role installed on the server.
●
Ensure the server has the latest Microsoft hotfixes and that the operating system clock
has the correct time.
●
Prepare for Windows Multilingual User Interface (MUI) support, if needed. Before
installing XenApp, install the target Windows Language Pack on the server, and change
language options (such as system locale and display language) to the target language.
For more information, see the Microsoft documentation. (Changing the Windows system
locale after installing and configuring the XenApp server role may cause data store
issues.)
Citrix XML and IIS Integration
When you install the XenApp role, XML and IIS integration is an optional component.
●
When this component is installed, the Citrix XML Service and IIS share a port (default =
80). You cannot change the Citrix XML port during XenApp configuration.
●
When this component is not installed, the Citrix XML Service defaults to standalone
mode with its own port settings, which you can change during XenApp configuration.
You must configure a nondefault port only if you do not integrate with IIS and if IIS (or
any other software) is using port 80.
The Server Role Installer checks if certain IIS role services are installed on the server, as
well as options you specify.
●
95
In a wizard-based installation, installing the integration XML and IIS integration
component is controlled through a checkbox.
Before Installing XenApp
●
In a command-line installation, installing the component is controlled through the
/install:XA_IISIntegration and /exclude:XA_IISIntegration options, and their smart
defaults. Citrix recommends you use these options to help prevent potential confusion
in the future when the presence of IIS role services on the server or image may be
unknown.
The following table describes the possible combinations, results, and defaults. For a list of
IIS role services, see XenApp System Requirements.
IIS role
services
installed?
Wizard-based install
Command-line install
Yes
Select the XML IIS Integration
component checkbox (default).
The component is installed.
Specify the /install:XA_IISIntegration
option. The component is installed.
This is the recommended
configuration.
Yes
Clear the XML IIS Integration
component checkbox. The
component is not installed.
Do not specify the
/install:XA_IISIntegration option. The
component is installed (default).
Yes
-
Specify the
/exclude:XA_IISIntegration option.
The component is not installed.
No
Do not select the XML IIS
Integration component
checkbox (default). The
component is not installed
Do not specify the
/install:XA_IISIntegration option. The
component is not installed.
No
Select the XML IIS Integration
Specify the /install:XA_IISIntegration
component checkbox. The
option. The Server Role Installer
Server Role Installer installs the
installs the IIS role services and the
IIS role services and the
component.
component.
When the XML and IIS integration component is installed and the XML Service Policy is
disabled, XenApp uses the installed integration component defaults. If the XML Service
policy is enabled and contains a different port number setting, unexpected results may
occur.
96
Before Configuring XenApp
●
Review the configuration topics (wizard-based or command-line) to learn what
information you must provide.
●
During configuration, you specify the database to be used for the XenApp farm data
store: Microsoft SQL Server Express, Microsoft SQL Server, or Oracle. See CTX114501 for
supported versions. Additional information is available at Data Store Database
Reference.
●
If you use a Microsoft SQL Server Express database, XenApp configuration installs it
automatically.
If you use a Microsoft SQL Server or Oracle database, install and configure the
database before configuring XenApp. For an Oracle database, ensure that you also
install an Oracle client on the XenApp server and restart the server.
If you use a Microsoft SQL Server or Oracle database for the farm data store, and use
command-line XenApp configuration, create a Data Source Name (DSN) file before
configuring XenApp. (A wizard-based configuration creates the DSN file for you.) Each
server in the farm must have the DSN file. You can create the file and copy it to other
servers, or put it on a network share, provided you remove the value for any
workstation-specific information (such as the Oracle WSID). Use the /DsnFile:dsn_file
option to specify the file location on the XenApp configuration command line.
●
●
If you are using a custom DSN file, the file must have write permission for the Network
Service.
●
If you plan to use the Configuration Logging feature and encrypt the data being logged,
you must load the encryption key on servers that join the farm after configuring XenApp
but before restarting the server.
XenApp Server Mode
All XenApp servers can host sessions. The XenApp server mode specifies whether the server
can only host sessions (session-host only mode, also called session-only) or if it can also
perform the controller functions of being elected a data collector and hosting the XML
broker (controller and session-host mode, also called controller).
While configuring servers as session-only can improve performance (particularly in large
farms with multiple zones), ensure you have sufficient servers configured in controller
mode that can serve as backup data collectors for your zones.
97
●
A XenApp server configured in controller mode monitors other controller servers in the
XenApp farm and triggers data collector elections when necessary.
●
The Citrix XML Service must run on a server configured in controller mode.
●
Application enumeration and resolution are invoked only on servers configured in
controller mode.
Before Configuring XenApp
●
The AppCenter can discover and connect only to servers configured in controller mode.
●
Every zone and every farm must have at least one server configured in controller mode.
●
If you plan to migrate an earlier XenApp version to XenApp 6.5, the migration operation
must be run on a XenApp 6.5 server configured in controller mode.
When you create a XenApp farm, the XenApp Server Configuration Tool automatically
configures the server in controller mode; you cannot configure session-only on the first
server in a XenApp farm. This ensures that the XenApp farm has at least one data collector.
When you configure another server to join that farm, you can choose the mode. By default,
a server joins the farm in controller mode. (In earlier XenApp versions, server mode was not
configurable; all XenApp servers operated in controller mode.)
The following table shows how to specify the server mode during XenApp configuration.
Wizard-based configuration
Server can host sessions,
and be a data collector and
XML broker (default)
Server can host sessions,
but cannot be a data
collector or XML broker
Select Enable Controller
and Session-host modes
Select Enable Session-host
mode only
Command-line
Specify
Specify
configuration
/ImaWorkerMode:False
/ImaWorkerMode:True
To change the configured server mode, you must leave and then rejoin the XenApp farm,
specifying the desired mode.
98
Installing XenApp Using the
Wizard-Based Server Role Manager
To install XenApp using the wizard-based Server Role Manager:
1. On the installation media, double-click autorun.exe. The Autorun menu launches.
2. Select Install XenApp Server. The Server Role Manager launches and checks if any roles
are already installed.
3. Select Add server roles.
If you already installed roles other than XenApp, select Add or remove server roles,
then select Add server roles.
4. Select your XenApp edition.
5. Accept the End User License Agreement.
6. Select the roles you want to add. (The Server Role Manager displays only the roles
supported in the XenApp edition you selected. Some roles may require current Citrix
Subscription Advantage membership.)
7. Select role components. Roles may have default and optional components.
●
When you select a role, its default components are selected automatically. The
XenApp role has the following default components:
●
XenApp Management, which includes the Citrix AppCenter.
Windows Desktop Experience Integration, which configures a XenApp server to
deliver remote desktops containing Windows 7 features and Microsoft
applications. For more information, see Delivering XenApp to Software Services
Subscribers.
If you do not want to install a default component, clear its checkbox.
●
99
●
For information about the XML Service IIS Integration optional component, see
Citrix XML and IIS Integration. If IIS role services are installed on the server, this
optional component is selected by default.
●
If you plan to use role agents/plug-ins on this server (EdgeSight Agent, SmartAuditor
Agent, Single Sign-on Plug-in, Power and Capacity Management Agent, or
Provisioning Services Target Device), install them at the same time you install the
XenApp server role. Otherwise, install these components from the packages on the
XenApp media.
●
The Citrix Receiver for Windows (formerly the online plug-in) and the Citrix Offline
Plug-in are installed automatically when you install the XenApp role. These items
do not appear in the components lists, and you cannot disable these installations.
Installing XenApp Using the Wizard-Based Server Role Manager
8. Review the prerequisites summary, which indicates which role or component needs the
prerequisite, and whether the Server Role Installer installs it or you must install it. For
software you must install, the display indicates whether the XenApp installation media
contains the software or you must obtain it elsewhere.
9. Review the summary, which lists the selected roles and components to be installed or
prepared. It also lists prerequisites which will be automatically deployed for all
selected roles.
After you click Install, a display indicates installation progress and the result.
Important: When installing the XenApp role, the IMA Service is not started, nor are any
configuration options set, such as creating or joining a farm and data store database
information.
After the installation result displays and you click Finish, the Server Role Manager task list
displays. For each role you selected, the task list indicates the next task necessary for
installation or configuration.
100
●
If you have not configured the license parameters for the XenApp role, click Specify
Licensing, which launches the Licensing Configuration Tool. Run the Licensing
Configuration Tool before configuring the XenApp server role.
●
For installed fully integrated roles that require configuration, click Configure to launch
the configuration tool for that role.
●
For partially integrated roles, click Install to launch the installer for that role. See the
role documentation for details.
Installing XenApp from the Command
Line
Command Syntax
On the server where you want to install XenApp or other roles, from the "XenApp Server
Setup\bin\" directory on the XenApp media, type the following at a command prompt:
XenAppSetupConsole.exe options_properties
The following table describes installation command options.
Installation options and properties
/help
Displays command help.
/logfile:path
Path for the log file generated during the installation. Default = c:\Windows\Temp
101
Installing XenApp from the Command Line
/install:items
Comma-delimited list of roles, components, features, or technologies to install. Valid
values are:
●
EdgeSightServer. EdgeSight Server.
●
Licensing. Citrix Licensing Server.
●
PCMAdmin. Power and Capacity Management administration components.
●
Provisioning. Provisioning Services.
●
SecureGateway. Secure Gateway.
●
SmartAuditorServer. SmartAuditor server.
●
SsonService. Single sign-on service.
●
ReceiverStorefront. Receiver Storefront.
●
WebInterface. Web Interface.
●
XenApp. XenApp server.
If you specify XenApp, the Server Role Manager automatically installs the Citrix
AppCenter, Citrix Receiver for Windows (formerly online plug-in), Citrix Offline
Plug-in, and Windows Desktop Experience Integration feature (for more
information, see Delivering XenApp to Software Services Subscribers). You can also
specify one or more of the following optional components to install, separated by
commas. Except as noted, if you do not specify the following optional
components, they are not installed.
102
●
XA_IISIntegration. IIS and XML Service integration. For more information, see
Citrix XML and IIS Integration. If IIS role services are installed on the server,
this component is installed regardless of whether you specify it on the
command line, unless you use the /exclude option to exclude it.
●
EdgeSightAgentFeature. EdgeSight Agent.
●
SmartAuditorAgentFeature. SmartAuditor Agent.
●
SSONAgentFeature. Single Sign-on Plug-in.
●
PCMAgentFeature. Power and Capacity Management Agent.
●
PVDeviceFeature. Provisioning Services Target Device.
Installing XenApp from the Command Line
/exclude:items
(Valid only when installing the XenApp server role) Comma-separated list of
components to be omitted from the installation. Valid values are:
●
XA_Console. Excludes installation of the AppCenter.
●
XA_IISIntegration. Excludes installation of the XML IIS Integration component. For
more information, see Citrix XML and IIS Integration.
XenAppEnhancedDesktopExperience. Excludes installation of the Windows Desktop
Experience Integration feature.
You cannot exclude the installation of the Receiver for Windows or the Offline Plug-in.
●
/edition
Specifies the XenApp edition. Valid values are:
●
Platinum (default)
●
Enterprise
●
Advanced
INSTALLDIR=directory
Specifies where to install the items. Default: C:\Program Files\Citrix
ONLINE_PLUGIN_INSTALLDIR=directory
Specifies where to install the Citrix Receiver for Windows. Default: C:\Program
Files\Citrix\ICA Client
Examples
The following command installs the XenApp server Platinum Edition in its default location.
XenAppSetupConsole.exe /install:XenApp /Platinum
The following command installs the XenApp server Platinum edition and the Receiver
Storefront in C:\Program Files\Citrix (which is the default location).
XenAppSetupConsole.exe /install:XenApp,ReceiverStorefront
INSTALLDIR=C:\Program Files\Citrix
The following command installs the XenApp server Platinum Edition and the Single Sign-on
Plug-in, and excludes installation of the AppCenter.
XenAppSetupConsole.exe
/install:XenApp,SSONAgentFeature /exclude:XA_Console
103
Configuring XenApp Server Role License
Information
XenApp server role license information must be specified before a XenApp server can
accept connections.
●
From the Server Role Manager, use the wizard-based Licensing Configuration Tool after
installing the XenApp server role.
●
From the command line, include license server information in the XenApp server role
configuration command (XenAppConfigConsole.exe).
See Licensing Your Product for complete Citrix licensing information.
Configuring XenApp License Information using the
Wizard-based Licensing Configuration Tool
If you are using the Server Role Manager, launch the Licensing Configuration Tool before
configuring the XenApp role.
1. After installing the XenApp role, access the XenApp Server Role Manager.
2. Click Specify licensing. The Licensing Configuration Tool launches.
3. On the Enter License Server Information page, select one of the following:
●
Connect to existing license server. Specify the case-sensitive license server name.
If you do not change the license server port value, the default value 27000 is used.
Click Test Connection to verify that the specified license server is running and
using a compatible software version, and to check if the license server has any
licenses.
●
Configure later via a policy.
4. On the Select Licensing Model page, you can select a licensing model option or defer
the selection to a later time.
If you clicked Test Connection on the previous page, recommendations are noted on
the Select Licensing Model page, based on licenses found on the license server.
Important: Select the licensing model best suited to your planned deployment, which
may differ from the recommendation, which is based on the licenses currently on the
license server.
●
104
XenApp. Select this model if you plan to use only XenApp licenses. This option is
recommended if the Test Connection operation discovered no licenses, only XenApp
licenses, or a mixture of unique XenApp and XenDesktop licenses on the license
Configuring XenApp Server Role License Information
server.
●
XenDesktop concurrent system. Select this model if you plan to use XenDesktop
concurrent user licenses. This option is recommended if the Test Connection
operation discovered only XenDesktop concurrent licenses on the license server.
●
XenDesktop user/device. Select this model if you plan to use XenDesktop user or
device licenses. This option is recommended if the Test Connection operation
discovered XenDesktop user/device licenses or both XenDesktop user/device and
XenDesktop concurrent licenses.
To change license server and licensing model information later, click Edit Licensing in the
XenApp Server Role Manager.
Configuring XenApp License Information from the
Command Line
From the command line, you can configure XenApp license information when you configure
the XenApp server role with the XenAppConfigConsole.exe command. Use the
/LicenseServerName, /LicenseServerPort, and /LicenseModel options. For more
information, see License server options.
105
Configuring XenApp Using the
Wizard-based Server Configuration Tool
To configure XenApp using the wizard-based XenApp Server Configuration Tool:
1. Access the Server Role Manager.
2. Click Configure under XenApp. The Server Configuration Tool launches.
3. Select the task to perform.
●
Create. After you install XenApp on the first server, that server is where you create
a new farm during configuration.
●
Join. After you install XenApp on other servers, you add each server to (join) an
existing farm.
●
Prepare this server for imaging and provisioning. (Valid only if the XenApp server
role was previously configured) Prepares the server for imaging.
Leave. (Valid only if the XenApp server role was previously configured) Removes
the server from the farm.
The remainder of this procedure assumes you are creating a new farm or adding a
server to a farm.
●
4. When creating a farm, on the Enter basic information page:
●
Enter a farm name, up to 32 characters (can include spaces). If you are using Oracle
as your Configuration Logging database, do not use hyphens in the farm name.
Specify the domain and username for a user who will be the first Citrix
administrator. The administrator has full permissions to the farm and can create
additional administrator accounts.
5. Select the data store database type and connection information.
●
106
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.)
Configuring XenApp Using the Wizard-based Server Configuration Tool
6. Specify the database credentials. Specify the user name in the form
<DBMACHINE>\<USER> or <DOMAIN>\<USER>.
SQL Server Express requires an existing Windows account, but it does not need to be a
server or system administrator. The Server Configuration Tool adds two database
administrators to SQL Server Express: (local)\administrators and the supplied
credentials for the local or domain user.
When adding a server to (joining) a farm, you can optionally test the connection to the
database. The result does not affect Server Configuration Tool operations.
7. The default session shadowing settings (which allow shadowing) are recommended for
most farms. Shadowing settings supplied during XenApp configuration override system
or domain policy for user-to-user shadowing.
Important: Shadowing features are permanent and should be changed only if you
want to permanently prevent system or domain policy from affecting that setting. If
you disable shadowing or change shadowing features during configuration, you cannot
reconfigure them later.
Option
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):
●
Prohibit remote control. If selected:
●
Authorized users can view sessions but do not have
keyboard and mouse input
Remote control is permanently prohibited; this
cannot be enabled on this server through policies.
Force a shadow acceptance prompt. If selected:
●
●
●
Authorized users must send an acceptance prompt
when attempting to shadow a session.
A shadow acceptance prompt is shown on every
shadowing attempt; this cannot be disabled on this
server through policies.
Force logging of all shadow connections. If selected:
●
●
●
All shadowing attempts, successes, and failures are
logged in the Windows event log.
Shadow connections are always logged; this cannot
be disabled on this server through policies.
8. If you do not change the following server settings, the Server Configuration Tool uses
default values.
●
107
Configuring XenApp Using the Wizard-based Server Configuration Tool
Setting
Description
Data Collection
Specify the server mode and zone name.
●
(Displayed only when joining a farm) Select a server
mode:
●
Enable controller and Session-host modes
(default). This server can host sessions and serve as
a data collector or XML broker.
Enable Session-host mode only. This server can
host sessions but cannot serve as a data collector
or XML broker.
For more information about server modes, see XenApp
Server Mode.
●
●
The default zone name is ‘Default Zone.’ To create a
custom zone name, select the checkbox and enter the
name.
XML Service
Citrix XML Service port. For more information, see Citrix
XML and IIS Integration.
Receiver
Server name or URL of the Web Interface server used by
the Citrix Receiver.
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.
●
Add Anonymous users. Adds anonymous users to the
Remote Desktop Users group. Default = selected
●
Add the Authenticated users. Adds current (and
future) domain accounts in the Windows Users group to
the Remote Desktop Users group. Default = unselected
Add the list of users from the Users group. Adds all
current users from the Users group to the Remote
Desktop Users group. If you add users later, you must
add them manually to the Remote Desktop Users group.
Default = selected
9. If you installed a plug-in or agent for the Single sign-on, SmartAuditor, EdgeSight, or
Power and Capacity Management features on this server, specify the requested
information to enable communications with them. (The feature roles use separate tools
for their configuration.)
●
10. Review the summary page.
After you click Apply, a display indicates configuration progress and the result. If the
configuration fails, click View Log to display the configuration log.
After configuration completes, you are returned to the XenApp Server Role Manager, which
indicates if any requirements remain.
108
Configuring XenApp Using the Wizard-based Server Configuration Tool
109
●
If you have not yet configured XenApp license information, click Specify licensing.
●
To initiate a server restart, click Reboot.
Configuring XenApp from the Command
Line
Note: The Configuration Command Syntax topic lists and describes the XenApp
configuration command-line options. This topic contains information about using the
XenApp configuration command and its options.
Command Conventions
Several options use Boolean values (true or false).
●
If you omit an option that requires a Boolean value, the default value is used. For
example, if you do not include the /AddLocalAdmin:True|False option in the command,
the default value (false) is used (that is, a local administrator is not added).
●
If you specify an option that requires a Boolean value but you omit the value, the
option default value is true. For example, for the /AddLocalAdmin:True|False option, if
you specify only /AddLocalAdmin (with no :True or :False value), the option is true
(that is, a local administrator is added).
You can use environment variables to represent one or more command-line options. For
example, you can group the standard Pause, Confirm, and NotStrict options as a single
environment variable. You can also use environment variables in the command-line option
values (for example, /ServerName:%currentServer%, where currentServer is defined as an
environment variable).
Return Codes
The XenAppConfigConsole command supports the following return codes:
110
Value
Meaning
0
Success
1
Invalid command-line options - for example, the command includes the
options /ServerName:server_name and /ExecutionMode:Create (an option
that is valid only when joining a farm was specified when creating a farm)
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
Configuring XenApp from the Command Line
Mapping of Earlier XenApp Version Properties to
Options
XenApp versions earlier than 6.0 supported installation and configuration properties. Some
of those properties have equivalent options in XenApp 6.
111
Property in Earlier XenApp Version
Option in XenApp 6
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
Configuration Command Syntax
On the server where the XenApp server role is installed, from C:\Program Files
(x86)\Citrix\XenApp\ServerConfig, type the following at a command prompt:
XenAppConfigConsole.exe [options]
The following tables describe configuration command options, grouped by category.
Note: You can also use this command to remove the XenApp server role; see Removing
Roles and Components.
Configuration process and command-related options
/help
Displays command help.
/NotStrict
Allows the executable to continue processing even if options do not apply in the
current context.
/Confirm
Displays a confirmation message before modifying the server. This can be useful when
testing for correct use of command options.
/Pause
Pauses the executable after processing completes. This prevents the command prompt
from closing when launching the command from a batch file.
/LogFilename:file
Logs the progress of the executable to a log file. In the log, the symbols >> indicate a
function call; the symbols << indicate a function return. Default: C:\Windows\Temp
General farm information options
112
Configuration Command Syntax
/ExecutionMode:Create | Join | Leave | ImagePrep
(Required) Specifies the task to perform.
●
Create. After you install XenApp on the first server, that server is where you
create a new farm during configuration.
●
Join. After you install XenApp on other servers, you add each server to (join) an
existing farm.
●
ImagePrep. (Valid only if the XenApp server role was previously configured)
Prepares the server for imaging.
●
Leave. (Valid only if the XenApp server role was previously configured) Removes
the server from the farm.
/FarmName:name
(Required and valid only with /ExecutionMode:Create) Specifies the farm name, up to
32 characters (can include spaces). If you are using Oracle for the Configuration
Logging database, do not use hyphens in the farm name.
/CitrixAdministratorAccount:domain\user
(Required and valid only with /ExecutionMode:Create) Specifies the domain and
username for the user who will be the first Citrix administrator. The administrator has
full permissions to the farm and can create additional administrator accounts.
/ZoneName:name
Specifies the zone name. Default = Default Zone
/AddLocalAdmin:True | False
Enables or disables creation of Citrix administrator accounts for all user accounts in
the local Administrators group. Default = False
/ImaWorkerMode: True | False
(Valid only with /ExecutionMode:Join) Enables or disables ability of the server to be a
data collector or XML broker. For more information, see XenApp Server Mode. Default
= False (server can be a data collector or XML broker)
Database used for farm data store options
If you use a Microsoft SQL Server Express database, you can simplify configuration by
using the /SimpleDB option when creating the XenApp farm. When joining a farm that
uses that database, use the /ServerName option to specify the name of the XenApp
server on which you created the farm.
/SqlExpressRootDir:ir
Specifies the location of the SQL Server Express source installation directory. Default =
C:\Program Files (x86)\Citrix\XenApp\ServerConfig\SqlExpress_2008.
/SimpleDB
Indicates the farm uses a SQL Server Express database for the data store.
113
Configuration Command Syntax
/ServerName:name
(Valid only with /ExecutionMode:Join and required with /SimpleDB) Specifies the
name of the server where the XenApp farm was created (that is, where the SQL Server
Express database was installed).
/DsnFile:file
Specifies the path to the DSN file used to connect to the data store.
/AuthenticationType:Windows | Sql
(Valid only when using a SQL Server or Oracle database for the farm data store)
Specifies the authentication type. Default = Windows
/OdbcUserName:name
(Required when creating or joining a farm) Specifies the database user name in the
form <DBMACHINE>\<USER> or <DOMAIN>\<USER>. SQL Server Express requires an
existing Windows account, but it does not need to be a server or system administrator.
XenApp configuration adds two database administrators to SQL Server Express:
(local)\administrators and the supplied credentials for the local or domain user.
Specify the database password with the /OdbcPassword option.
/OdbcPassword:password
(Required when creating or joining a farm) Specifies the database user password.
Specify the database user name with the /OdbcUserName option.
License server options
For more information, see Licensing Your Product.
/LicenseServerName:name
Specifies the name of the existing license server.
/LicenseServerPort:port
Specifies the license server port. Default = 27000
/LicenseModel:model
Specifies the licensing model. Valid values are:
●
XA. Specify this model if you plan to use only XenApp licenses.
●
XDC. Specify this model if you plan to use XenDesktop concurrent user licenses.
●
XDUD. Specify this model if you plan to use XenDesktop user or device licenses.
Default = XA
Session shadowing options
114
Configuration Command Syntax
Important: Citrix recommends using the default values (that is, do not specify them in
this command). Shadowing settings specified during XenApp configuration override
system or domain policy for user-to-user shadowing. Shadowing features are
permanent and should be changed only if you wish to permanently prevent system or
domain policy from affecting that setting. If you disable shadowing or change
shadowing features during configuration, you cannot reconfigure them later.
/ProhibitShadowing:True | False
Disables or enables session shadowing. Default = False (shadowing is enabled)
/ProhibitRemoteControl:True | False
(Valid only if shadowing is enabled) Prohibits or allows remote control shadowing.
When this option is true, authorized users can view sessions but do not have keyboard
and mouse input. Default = False
/ForceShadowPopup:True | False
(Valid only if shadowing is enabled) Enables or disables sending a shadowing
acceptance popup. When this option is true, authorized users must send an
acceptance prompt when attempting to shadow a session. Default = False
/ForceShadowLogging:True | False
(Valid only if shadowing is enabled) Enables or disables logging of all shadow
connections. When this option is true, all shadowing attempts, successes, and failures
are logged to the Windows event log. Default = False
Citrix XML service port options
For information about the XML IIS Service Integration component, see Citrix XML and IIS
Integration.
/CustomXmlServicePort:port
Specifies the port number to be used by the Citrix XML Service. Default = 80
/SkipXmlSetting:True | False
When this option is true, the Citrix XML service and IIS port numbers are not
configured (that is, the default port 80 is not used). Default = False
Remote Desktop Users Group options
Only members of the Remote Desktop Users Group can connect to published applications.
Until you add users to this group, only administrators can connect remotely to the
server. Specify one or more of the following options.
/AddAnonymousUsersToRemoteDesktopUserGroup:True | False
Enables or disables adding anonymous users to the Remote Desktop Users group.
Default = True
/AddAuthenticatedUsersToRemoteDesktopUserGroup:True | False
Enables or disables adding current (and future) domain accounts in the Windows Users
group to the Remote Desktop Users group. Default = False
115
Configuration Command Syntax
/AddUsersGroupToRemoteDesktopUserGroup:True | False
Enables or disables adding all current users from the Users group to the Remote
Desktop Users group. If you add users later, you must add them manually to the
Remote Desk-top Users group. Default = True
Image preparation and provisioning options
For more information, see Preparing for XenApp Imaging and Provisioning.
/RemoveCurrentServer:True | False
(Valid only with /ExecutionMode:ImagePrep) Enables or disables removing the current
server instance from the XenApp farm. Default = True
/PrepMsmq:True | False
(Valid only with /ExecutionMode:ImagePrep) Enables or disables resetting the MSMQ ID
during resealing. Default = True
/ClearLocalDatabaseInformation:True | False
(Valid only with /ExecutionMode:ImagePrep) Enables or disables removing the server,
database, and failover partner entries from the DSN file and setting the equivalent
LGPO settings to NotConfigured. Default = True
Important: If you enable removal of the database information, XenApp assumes an
Active Directory policy will provide database settings. If a policy is not applied, the
server will not restart.
Feature and component options
/SmartAuditorServerName:name
(Required if you installed the SmartAuditor agent on the XenApp server) Specifies the
name of the SmartAuditor server.
/SsoPluginUncPath:path
UNC path to the Single sign-on central store. Default = use Active Directory
/OnlinePluginServerUrl:name_url
Server name or URL of the Web Interface server used by the Citrix Receiver.
/PcmFarmName:farm
Power and Capacity Management farm name.
/PcmWorkloadName:name
Power and Capacity Management workload name.
/EdgeSightCompanyName:name
EdgeSight company name.
116
Configuration Command Syntax
/EdgeSightServerName:name
EdgeSight server name.
/EdgeSightServerPort:port
EdgeSight server port. Default = 80
Other options
/CreateAnonymousUserAccounts:True | False
Creates anonymous Citrix accounts Anon000-Anon014. Default = True
/RemoveAnonymousCitrixAccounts:True | False
Removes anonymous Citrix accounts Anon000-Anon014. Default = False
Example
The following command, issued from the typical XenApp Server Configuration Tool location
(C:\Program Files (x86)\Citrix\XenApp\ServerConfig\XenAppConfigConsole.exe), joins the
server to the farm, specifying database credentials and the DSN file location, license server
and model information, log file location, and Remote Desktop User Group configuration
settings.
“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\
-XenAppConfigConsole.exe" /ExecutionMode:Join
/OdbcUserName:administrator /OdbcPassword:somepasswd
/LicenseServerName:somelicenseserver
/LicenseServerPort:27000 /LicenseModel:XA
/ZoneName:some_zone_name
/DsnFile:"c:\somepath\to\example.dsn"
/Log:c:\SomewhereConfigLog.txt /CustomXmlServicePort:8080
/AddAnonymousUsersToRemoteDesktopUserGroup:True
/AddUsersGroupToRemoteDesktopUserGroup:True
/AddAuthenticatedUserstoRemoteDesktopUserGroup:True
117
Preparing for XenApp Imaging and
Provisioning
Primary deployment methods for XenApp servers include server imaging, virtualization, and
provisioning. Separation of the XenApp server role installation and configuration tasks offers
flexibility in deciding when to capture (create) XenApp images.
Provisioning a XenApp server uses one of three typical approaches; the approach you use
depends on when you configure XenApp (earlier or later) in your preparation steps. The
XenApp server joins its farm on the first restart (reboot) after configuration; this ensures
that the XenApp server image joins or rejoins the farm after it has been cloned with its
final identity.
Important: Cloning is not supported for the first server in the farm (where you created
the farm during configuration), and should be used only for creating new member servers
for an existing farm.
The following descriptions assume you already created a XenApp farm containing at least
one server. You need the data store database information and credentials for the farm.
Approach 1: Capture an image after XenApp
installation, but before configuration and restart
In this approach, you install the XenApp server role, but wait to configure XenApp (join a
farm) until after the server is cloned and booted. XenApp server configuration is
automated, using a script.
This approach is not supported in Citrix Provisioning Services using Shared Image mode.
1. Install the XenApp server role, but do not configure the server. You may want to restart
the server to ensure the system path is updated properly before installing other
applications.
2. Install your applications and configure the settings you want in your image. Deploying
prerequisites such as Remote Desktop Services roles may require a server restart before
you can install XenApp.
3. Run the generalization tools you normally run.
4. Set up a script to run when each cloned server boots. This script configures the XenApp
server (including farm information) using the XenAppConfigConsole.exe command. The
script then restarts the server, whereupon the server joins the farm.
You can set up scripts using typical methods such as Active Directory startup scripts or
the RunOnce registry key.
118
Preparing for XenApp Imaging and Provisioning
5. Capture an image of the server.
Approach 2: Capture an image after XenApp
installation and configuration, but before restart
In this approach, you install and configure the XenApp server role, but wait to restart the
server until after it is cloned. When the server restarts as a clone of the original image, it
joins the farm with its new identity.
You do not need direct access to your database server or network during configuration, so
this approach can be used to prepare XenApp images for remote deployments. If you do not
or cannot verify your database credentials, and they are invalid, XenApp will not join the
farm when the server restarts. In that case, run the XenApp Server Configuration Tool,
providing correct credentials, and then recapture an image.
1. Install your applications and configure the settings you want in your image.
2. Install the XenApp server role. Deploying prerequisites such as Remote Desktop Services
roles may require a server restart before you can install XenApp.
3. Configure the XenApp server to add the server to (join) a farm, but do not restart the
server.
4. Run the generalization tools you normally run.
5. Capture an image of the server.
Note: If you are using the SmartAuditor agent or other features that depend on Microsoft
Messaging Queuing (MSMQ), use Approach 3.
Approach 3: Capture or update an image after XenApp
installation, configuration, and restart
If you require XenApp to be installed and working before you create a final image, you must
remove the server from the farm, then rejoin the farm before your final shutdown (for
example, after sysprep), so that the server will join the farm on the next restart, with its
new identity.
1. Install the XenApp server role.
Optionally, install the Provisioning Services Target Device software. This software
resets your network connection during installation. Failures may occur if you install this
component from a network location. Although these failures are not commonly harmful,
Citrix recommends installing the Provisioning Services Target Device software from a
DVD, mounted ISO, or local copy of the installation media.
2. Configure XenApp to join a farm, and then restart (reboot) the server.
3. Install your applications and configure the settings you want in your image.
119
Preparing for XenApp Imaging and Provisioning
4. Edit your XenApp configuration and select the task Prepare this server for imaging and
provisioning. (For a command-line configuration, specify the
/ExecutionMode:ImagePrep option.)
●
If you are working with an image template that you do not want to keep in the
current farm, select the Remove this current server instance from the farm
checkbox. (For a command-line configuration, use the /RemoveCurrentServer:True
option.)
●
If you are provisioning the XenApp server with SmartAuditor or other features that
depend on MSMQ, selecting the Prepare Microsoft Messaging Queuing provisioning
checkbox ensures a new unique machine identifier when the server image boots.
(For a command-line configuration, use the /PrepMsmq:True option.)
●
If you select the Clear database location settings from this server checkbox, the
default database information is removed from local settings (server, database, and
failover partner entries are removed from the DSN file; LGPO is set to
NotConfigured). This ensures that cloned servers can join only a XenApp farm that
is specified with inherited group policy settings. (For a command-line configuration,
use the /ClearLocalDatabaseInformation:True option.)
Important: If you select this checkbox, XenApp assumes an Active Directory
policy will provide database settings. If a policy is not applied, the IMA Service
will not start.
5. Run the generalization tools you normally run.
6. Capture an image of the server.
The server joins the farm when the image boots.
Resealing an image
If a golden image requires updating (for example, with Citrix or Windows hotfixes, or
third-party applications and patches), you can reseal the image. This procedure is similar to
approach 3.
1. Boot into the image to make modifications. The XenApp server will try to join the farm
if it can.
2. Modify the server as needed.
3. Proceed with step 4 in Approach 3.
During the resealing process, the Server Configuration Tool:
120
●
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
Preparing for XenApp Imaging and Provisioning
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 NotConfigured).
●
Product feature and server edition
●
License server hostname
●
License server port number
●
XML Service port
●
Database server, database, and failover partners (if that checkbox was selected)
Installation and Configuration Considerations
For provisioning purposes, you can install the XenApp server role using the wizard-based
XenApp Server Role Manager or the command line. For wizard-based installations, do not
proceed to configuring the XenApp server role until you are ready, based on the approach
you select.
Configuring the XenApp server after it is instanced (approach 1) should be automated using
the command line. You can use the wizard-based XenApp Server Configuration Tool or the
command line to configure the XenApp server if you choose approach 2 or 3.
When preparing a XenApp server for imaging and provisioning:
●
The server should not be the only server in the XenApp farm.
●
The server should not be the data collector.
●
The server should not have the data store database installed on it.
●
The server should not have the Citrix License Server installed on it.
Important: When provisioning XenApp, you must remove the server SSL certificate before
running XenConvert; otherwise, the SSL certificate will be distributed to all provisioned
XenApp servers.
For example, the following command, issued from the root of the installation media,
installs the XenApp server role and the Provisioning Services target device, and excludes
installation of the AppCenter.
\XenApp Server Setup\bin\XenAppSetupConsole.exe
/install:XenApp,PVDeviceFeature /exclude:XA_Console
The following command prepares XenApp for imaging and provisioning. The server will be
removed from the current farm, and when the server image boots, it will contain a unique
MSMQ machine identifier. Database identification information will be removed from the DSN
file.
121
Preparing for XenApp Imaging and Provisioning
“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\
-XenAppConfigConsole.exe" /ExecutionMode:ImagePrep
/RemoveCurrentServer:True /PrepMsmq:True
/ClearLocalDatabaseInformation:True
122
Removing Roles and Components
You can remove the following XenApp 6.5 roles and some components using the
wizard-based Server Role Manager or the command line:
●
XenApp
●
Receiver Storefront
●
Web Interface
●
Licensing
●
Single sign-on service
●
Provisioning server
Important: Although you can use Windows Programs & Features to remove the XenApp
6.5 roles listed above, Citrix strongly recommends using the Server Role Manager.
To remove other roles (such as EdgeSight server, SmartAuditor server, Power and Capacity
Management administration components, Secure Gateway), use Windows Programs &
Features.
You cannot use the XenApp 6.5 Server Role Manager to remove fully-integrated roles in an
earlier XenApp version deployment (including early release or Technical Preview versions).
In those cases, Citrix recommends reimaging the server and then installing XenApp.
When you remove the XenApp server role, the process automatically removes the server
from the XenApp farm.
123
Removing Roles and Components
Removing Roles and Components Using the
Wizard-based Server Role Manager
1. Access the XenApp Server Role Manager.
2. Select Add or remove server roles.
3. On the Select a task page, select Remove server roles.
4. Select one or more roles to remove.
If you select a role that has default components, those default components are
automatically selected; you cannot change this (that is, you cannot remove the role
without also removing its default components). To remove only a default component
(for example, to remove the AppCenter but leave the XenApp server role installed),
select only the component, not the role. You cannot remove the XenApp XML IIS
Integration default component or the Windows Enhanced Desktop Experience optional
component.
Required role components are not listed. The Receiver for Windows and the Offline
Plug-in are automatically installed with the XenApp server role; you cannot remove
them using the Server Role Manager unless you also remove the XenApp server role.
5. Review the summary, which lists the roles and components to be removed.
After you click Remove, a display indicates the progress and the result.
Removing XenApp Roles and Components Using the
Command Line
On the server where you want to remove a role or component, from either the
“%PROGRAMDATA%\Citrix\XenAppUninstall\” or “XenApp Server Setup\bin\” directory, type
the following at a command prompt:
XenAppSetupConsole.exe options
Valid options are:
/help
Displays command help.
/logfile:path
Path for the log file generated during the removal.
124
Removing Roles and Components
/uninstall:items
Comma-delimited list of roles and components to remove. Valid values are:
●
ReceiverStorefront. Receiver Storefront.
●
WebInterface. Web Interface role.
●
Licensing. License server role.
●
SsonService. Single sign-on service role.
●
Provisioning. Provisioning Services role.
●
XenApp. XenApp server role.
●
XA_Console. AppCenter.
●
EdgeSightAgentFeature. EdgeSight agent.
●
SmartAuditorAgentFeature. SmartAuditor agent.
●
SSONAgentFeature. Single Sign-on Plug-in.
●
PCMAgentFeature. Power and Capacity Management agent.
●
PVDeviceFeature. Provisioning Services target device.
Note: You cannot remove the XenApp XML IIS Integration or Enhanced Desktop
Experience components. The Receiver for Windows and the Offline Plug-in are
removed when you remove the XenApp server role.
Important: When using the XenAppSetupConsole.exe command to remove roles or
components, do not specify options that configure the XenApp role.
Examples
The following command removes the XenApp server role and all its default components.
XenAppSetupConsole.exe /uninstall:XenApp
The following command removes the Receiver Storefront and the XenApp server role.
XenAppSetupConsole.exe /uninstall:XenApp,ReceiverStorefront
The following command removes the SmartAuditor agent component.
XenAppSetupConsole.exe /uninstall:SmartAuditorAgentFeature
125
Data Store Database Reference
See the database vendor documentation before installing, configuring, and using the
database software. CTX114501 contains information about supported database versions.
If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp
configuration automatically installs it.
Important:
●
Citrix does not support case-sensitive databases.
●
To avoid corruption, do not directly edit data in the data store database with utilities
or tools other than those provided by Citrix.
Maintaining, Backing up, and Restoring a XenApp
Data Store
Most database maintenance requires running the dsmaint and dscheck server utilities on
XenApp farm servers. The XenApp Server Utilities Reference contains syntax and use
details.
Use dsmaint to:
●
Upgrade the XenApp data store
●
Move the data in the data store to a different database server
●
Change the name of the DSN file
If the data store fails, each farm server can run from the data in its Local Host Cache
indefinitely, provided it can contact the license server. However, you cannot make any
modifications to the farm or use the AppCenter.
Create a backup copy of the data store (dsmaint backup). Without a backup, you must
manually recreate all of the farm policies, settings, accounts, and other persistent data in
the data store.
To restore a backup database or to migrate to a new server, use the dsmaint migrate
utility. Without a backup, prepare a new data store the way you did before configuring
XenApp and run the XenApp Server Configuration Tool from any farm server. After running
the Server Configuration Tool, manually reenter the lost settings. If you use the same name
as the previous data store, you do not need to reconfigure the farm servers.
126
Microsoft SQL Server Database
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, set the user permissions to read/write only to increase the
security of the database. Change the rights back to database owner before installing service
packs or feature releases; installations can fail if the user account used to authenticate to
the data store during Setup does not have database owner rights.
When using Microsoft SQL Server in a replicated environment, use the same user account
for the data store on each Microsoft SQL Server.
Each farm requires a dedicated database. However, multiple databases can be running on a
single server running Microsoft SQL Server. Do not configure the farm to use a database that
is shared with any other client/server applications.
Back up the database regularly and follow Microsoft recommendations for configuring
database and transaction logs for recovery (for example, setting the Truncate log on
Checkpoint option to control log space).
127
Microsoft SQL Server Database
Using Sockets to Connect to a Microsoft SQL Server
Database
Two protocols used to connect to a database are TCP/IP sockets and named pipes. Named
pipes is an authenticated communication protocol, so any time you attempt to open a
connection to the SQL Server database using this protocol, the Windows authentication
process occurs. TCP/IP sockets do not rely on Windows authentication to establish a
connection, but do provide user/password authentication to the database after the
connection is established. Windows authentication reduces the possibility of an error
occurring when the server hosting SQL Server and the XenApp server do not have the
correct domain or Active Directory trust relationship. Therefore, Citrix recommends using
TCP/IP sockets.
If you use named pipes, manually enable the named pipes option on the database server
using the Surface Area Configuration tool packaged with SQL Server.
Creating a Microsoft SQL Server Data Source
Connection
1. On the Create a New Data Source to SQL Server screen, enter the data source
description and select the SQL Server to which to connect.
2. Select Windows NT Authentication or SQL Server Authentication.
3. Click Client Configuration.
4. Select TCP/IP from the available network libraries.
5. After installing XenApp, modify the Data Source Name (DSN) created during
configuration and change its client configuration to use TCP/IP.
To modify a DSN, use the Windows ODBC Data Source Administrator utility to open the
File DSN, which is located by default in the %ProgramFiles(x86)%\Citrix\Independent
Management Architecture folder, and select TCP/IP as the connection protocol for the
client configuration.
Using Failover with Microsoft SQL Server
For fault tolerance with Microsoft SQL Server, use Microsoft clustering, which provides
failover and failback for clustered systems. Failover of the SQL Server database in a
clustered environment is transparent to XenApp.
The database files for an instance of Microsoft SQL Server are placed in a single cluster
group owned by the node on which the instance is installed. If a node running an instance of
Microsoft SQL Server fails, the cluster group containing the data files for that instance is
switched to another node. The new node already has the executable files and registry
information for that instance of Microsoft SQL Server on its local disk drive, so it can start
128
Microsoft SQL Server Database
up an instance of Microsoft SQL Server and start accepting connection requests for that
instance.
Microsoft Cluster Services clustering does not support load balancing among clustered
servers because it functions in active/passive mode only.
Using Distributed Databases with Microsoft SQL
Server
XenApp supports distributed (replicated) databases. Replicated databases are useful when
too many read requests to the data store create a processing bottleneck. Microsoft SQL
Server uses replication to create the distributed database environment.
XenApp requires data coherency across multiple databases. Therefore, a two-phase commit
algorithm is required for storing data in the database. When configuring Microsoft SQL
Server for a two-phase commit, use the Immediate Updating Subscriber model.
When configuring Microsoft SQL Server, you may need to increase the value of the Max Text
Replication Size property to improve replication performance.
Caution: To avoid corruption, do not use merged replication.
To set up a distributed environment for an existing XenApp farm:
1. Configure a Publisher (the Microsoft SQL Server currently hosting the data store) and
Subscribers (remote sites) using Microsoft SQL Server Enterprise Manager.
2. Run the dsmaint publishsqlds command on a server in the farm. This executes the
necessary SQL statements to create the published articles on the current Microsoft SQL
Server (Publisher).
3. Configure the remote sites (Subscribers) to subscribe to the published articles created
in the previous step.
129
Oracle Database
The server hosting the Oracle database should meet the following minimum requirements:
●
Approximately 100MB of disk space for every 250 servers and 50 published applications
in the farm. 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 = Number of servers / 10
max_shared_servers = Number of servers / 5
130
Oracle Database
Where Number of servers is the total number of servers running XenApp.
●
When using an Oracle server in dedicated mode, add one additional process for each
server connected directly to the Oracle database. For example, if the Oracle server
uses 100 processes before installing XenApp, and the farm has 50 servers, set the
processes value to at least 150 in the Init.ora file on the Oracle server.
●
Create online backups using Archivelog mode, which reduces the recovery time of an
unresponsive database.
●
If you are using the same Oracle database for multiple server farms, create a unique
tablespace with its own user name and password for added security for each farm. Do
not use the default system account within Oracle.
●
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:
131
●
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.
Oracle Database
132
●
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.
XenApp Migration Center
The XenApp Migration Center pulls data from a server in a source XenApp server farm and
imports (adds) it to a new XenApp server farm. The data is grouped as object types.
The following table lists the supported XenApp versions for the source farm and the new
farm.
Source farm
New Farm
XenApp 5 for Windows Server 2003 (with
minimum HRP5) or XenApp 5 for Windows
Server 2008
XenApp 6.5
XenApp 6.0
XenApp 6.5
XenApp 6.5 deployed in a test/pilot farm
XenApp 6.5 deployed in a production farm
In all migrations, Citrix recommends you first use the XenApp 6.5 media to perform a clean
install of the XenApp server role on one or more Microsoft Windows Server 2008 R2 or
Microsoft Windows Server 2008 R2 SP1 servers. Then, use the XenApp Server Configuration
Tool to create a new farm or join servers to that new farm. (Clean install means that there
is no previous version of the XenApp server role installed on the server.)
If you cannot coordinate that recommended process, Citrix provides a XenApp 6.0 to 6.5
Upgrade Utility that you can customize for your servers; see CTX130614.
After you configure and restart the new XenApp server, use the Migration Center installed
on that server to import objects from the source farm.
●
If you are migrating a XenApp 5 source farm, servers in that source farm are migrated
to worker groups in the new farm according to server-to-worker-group mappings you
specify before starting the migration. Servers in the mapping are representative servers
chosen from each server silo in the XenApp 5 farm.
●
If you are migrating a XenApp 6.0 source farm or a XenApp 6.5 test/pilot source farm,
worker groups already exist, so you do not need to set up server mappings before the
migration.
You can preview (analyze) a migration; that is, the Migration Center indicates which objects
will be imported during a migration, without actually performing the migration.
You can repeat the migration as additional servers in the source farm become ready for
reimaging in the new farm. During subsequent migration previews, the Migration Center
compares source farm objects with objects in the new farm, and lists differences. If you
then migrate those objects, the current value in the new farm is overwritten with the
current value in the source farm.
As the migration of more source farm servers continues, use the Web Interface user
roaming feature to help ensure that users can access applications and resources.
Citrix recommends performing the entire migration from a server in the new XenApp farm;
this is a direct migration. However, if your deployment does not allow this, you can
133
Migrate
perform an indirect migration. In this case, you split the migration process by installing and
using the Migration Center on a server in the source farm to export settings. Then, using the
Migration Center installed on a server in the new XenApp farm, you import the settings into
the new farm.
134
Migration Center Interfaces
The Migration Center comprises a PowerShell module. You can use the Migration Center
through a graphical interface or a command-line interface.
The interfaces use different terminology:
●
The graphical interface refers to the server in the source farm; error messages and the
command-line interface refer to the remote server in the legacy farm.
●
The graphical interface refers to the XenApp 6.5 farm as the target farm; the
command-line interface uses new farm.
The following table summarizes the differences between the interfaces.
Graphical interface
Command-line interface
Application that guides you through a
series of set up, display, preview, and
other action screens.
A collection of PowerShell cmdlets that
you issue in a recommended sequence to
set up, display, preview, and other
actions.
Imports all objects from the source farm
into the new farm. *
You can specify object types and named
objects to include and exclude from the
migration. You can also explicitly specify
32-bit applications to be migrated; their
paths will be converted to \Program Files
(x86)\ so they will launch properly in the
64-bit farm environment.
Imports all property values (settings) for
all objects. *
You can override an object property value
(setting). For example, you can specify a
CPU priority level for applications
imported to the new farm, regardless of
the CPU priority level in the source farm.
Supports direct migrations.
Supports direct and indirect migrations,
and can specify a different location where
the data exported from the source farm is
placed before importing it into the new
farm.
* Although you cannot specify setting overrides, objects to include or exclude, or other
customizations in the graphical interface, you can configure them through the
command-line interface, and then use the graphical interface to preview and run the
migration. (Both interfaces honor Migration Center settings configured from either
interface. For example, if you specify a source server in the graphical interface, the
command-line interface uses that value for subsequent actions, if not explicitly
overridden with a different server name in the command line.)
The following table summarizes how to perform migration tasks in each interface.
Action
135
Command-line interface
Graphical interface
XenApp Migration Center
136
Add, display, or remove
a server mapping (valid
only when migrating a
XenApp 5 farm)
Add-XAServerMapping,
Get-XAServerMapping,
Remove-XAServerMapping
Worker group mappings
Specify a source farm
server name
Set-XAMigrationOption
–RemoteServerName or
Start-XAMigration
-RemoteServerName
Choose a source farm
Specify a nondefault
data folder location
Set-XAMigrationOption
-DataFolderPath
(configure in command-line
interface)
Specify objects to
include or exclude
Set-XAMigrationOption
–ObjectType –Include –Exclude
(configure in command-line
interface)
Display migration
options
Get-XAMigrationOption
(display in command-line
interface)
Specify, display, or
remove a value for an
individual object
property
Add-XASettingOverride,
Get-XASettingOverride,
Remove-XASettingOverride
(configure in command-line
interface)
Preview a migration
Start-XAMigration
–PendingReportOnly
Analyze Farms
Migrate
Start-XAMigration
Migrate to Target Farm
Import only or export
only
Start-XAMigration {-ExportOnly
| -ImportOnly}
(use command-line
interface)
Migration Center Interfaces
The Migration Center comprises a PowerShell module. You can use the Migration Center
through a graphical interface or a command-line interface.
The interfaces use different terminology:
●
The graphical interface refers to the server in the source farm; error messages and the
command-line interface refer to the remote server in the legacy farm.
●
The graphical interface refers to the XenApp 6.5 farm as the target farm; the
command-line interface uses new farm.
The following table summarizes the differences between the interfaces.
Graphical interface
Command-line interface
Application that guides you through a
series of set up, display, preview, and
other action screens.
A collection of PowerShell cmdlets that
you issue in a recommended sequence to
set up, display, preview, and other
actions.
Imports all objects from the source farm
into the new farm. *
You can specify object types and named
objects to include and exclude from the
migration. You can also explicitly specify
32-bit applications to be migrated; their
paths will be converted to \Program Files
(x86)\ so they will launch properly in the
64-bit farm environment.
Imports all property values (settings) for
all objects. *
You can override an object property value
(setting). For example, you can specify a
CPU priority level for applications
imported to the new farm, regardless of
the CPU priority level in the source farm.
Supports direct migrations.
Supports direct and indirect migrations,
and can specify a different location where
the data exported from the source farm is
placed before importing it into the new
farm.
* Although you cannot specify setting overrides, objects to include or exclude, or other
customizations in the graphical interface, you can configure them through the
command-line interface, and then use the graphical interface to preview and run the
migration. (Both interfaces honor Migration Center settings configured from either
interface. For example, if you specify a source server in the graphical interface, the
command-line interface uses that value for subsequent actions, if not explicitly
overridden with a different server name in the command line.)
The following table summarizes how to perform migration tasks in each interface.
Action
137
Command-line interface
Graphical interface
Migration Center Interfaces
138
Add, display, or remove
a server mapping (valid
only when migrating a
XenApp 5 farm)
Add-XAServerMapping,
Get-XAServerMapping,
Remove-XAServerMapping
Worker group mappings
Specify a source farm
server name
Set-XAMigrationOption
–RemoteServerName or
Start-XAMigration
-RemoteServerName
Choose a source farm
Specify a nondefault
data folder location
Set-XAMigrationOption
-DataFolderPath
(configure in command-line
interface)
Specify objects to
include or exclude
Set-XAMigrationOption
–ObjectType –Include –Exclude
(configure in command-line
interface)
Display migration
options
Get-XAMigrationOption
(display in command-line
interface)
Specify, display, or
remove a value for an
individual object
property
Add-XASettingOverride,
Get-XASettingOverride,
Remove-XASettingOverride
(configure in command-line
interface)
Preview a migration
Start-XAMigration
–PendingReportOnly
Analyze Farms
Migrate
Start-XAMigration
Migrate to Target Farm
Import only or export
only
Start-XAMigration {-ExportOnly
| -ImportOnly}
(use command-line
interface)
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.
When migrating from a XenApp 6.5 test/pilot farm, this includes
pre-launched applications.
When migrating from a 32-bit XenApp 5 platform, the application
path is not translated.
Folder
Includes application folders and server folders. Server folders are
migrated so that server permissions can be copied; however, the
server objects are not migrated.
Load 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.
When migrating from a XenApp 6.0 farm or a XenApp 6.5 test/pilot
farm, this includes load balancing policies.
Citrix policies in the source farm that are configured in XenApp
Management (Delivery Services Console or AppCenter) can be
migrated. Citrix policies that are configured in Active Directory using
the Group Policy Management Console are not migrated.
Server
configuration
When migrating from XenApp 5, configuration settings for servers
specified in the server mapping file are migrated by creating an IMA
Machine GPO named "WorkerGroupname" where name is the name of
the worker group specified in the server mapping file. This policy is
filtered by worker group. Worker groups are created as necessary, but
they are not associated with servers or OUs (Organizational Units).
When migrating from a XenApp 6.0 farm or a XenApp 6.5 test/pilot
farm, this includes worker groups.
139
Objects You Can Migrate
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 source farm are compared against the default values
used when the new farm was created. The corresponding setting in the policy in the new
farm is set to "Not Configured" if it matches the default value for the same setting in the
new farm.
Health Monitoring and Recovery (HMR) test executables are not copied; however, HMR test
configurations are migrated into policies in the new farm.
Session printers are migrated, but the printer path is not validated on the new farm.
For zones and load evaluators:
●
When migrating from a XenApp 5 farm, zones and load evaluator attachments to servers
are not migrated; however, the Zone Preference and Failover policy is converted to a
load balancing policy that is filtered by worker groups. The conversion uses the server
mappings specified for the migration.
●
When migrating worker groups from a XenApp 6.0 farm, if all servers in a worker group
are in the same zone, a group policy is created for the initial zone, and a filter by
worker group is applied. If all servers are not in the same zone, an initial zone policy is
not created, and a warning appears. Similarly, if all servers in a worker group have the
same load evaluator, a policy is created.
●
When migrating from a XenApp 6.5 test/pilot farm, it is assumed that the source farm
has zone and load evaluator policies, so they are copied.
The following settings are not migrated:
●
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:
140
●
Deprecated settings, such as AIE (Application Isolation Environment).
●
Permissions that do not exist in the XenApp 6.5 release, whether they correspond to a
deprecated feature or a configuration setting that is now supported as a policy.
Requirements and Installation
You can migrate a single XenApp farm.
Requirements for a XenApp 5 Source Farm
●
The servers in the XenApp 5 farm must be running XenApp 5 for Windows Server 2003
with at least Hotfix Rollup Pack 5 (HRP5), or XenApp 5 for Windows Server 2008.
●
The source server must have network COM+ access enabled, and the MFCOM service
must be available.
●
To access the source server using a remote connection, you must be a member of the
DCOM users group, and a Citrix administrator with at least view-only privileges.
●
When migrating from a 32-bit XenApp 5 farm, network printers used by policies (session
printers) must have a 64-bit driver installed in the print server; otherwise, those
printers will not be migrated.
Requirements for a XenApp 6.0 Source Farm or a
XenApp 6.5 Test/Pilot Source Farm
141
●
The servers in the farm must be running XenApp 6.0 (in the XenApp 6.0 farm) or XenApp
6.5 (in the XenApp 6.5 test/pilot farm).
●
You must be a Citrix administrator with at least view-only privileges.
●
The XACOM service must be available.
Requirements and Installation
Requirements for the New XenApp 6.5 Farm
●
The XenApp 6.5 server role must be installed and configured on the Microsoft Windows
Server 2008 R2 or Microsoft Windows Server 2008 R2 SP1 server where you will use the
Migration Center. The XenApp server must be configured with the XenApp controller
server mode. (You cannot use the Migration Center on a XenApp 6.5 server configured
with the XenApp session-only server mode.) Restart the server after configuration.
●
The IMA and XACOM services must be running.
●
You must be a Citrix administrator with full privileges.
●
You must have write access to the folder where the exported data from the source farm
is placed before being imported into the new farm. This folder also contains the
migrationoptions.xml file containing any migration options and property overrides you
set through the Migration Center command-line interface, plus server mappings (when
migrating a XenApp 5 farm). By default, this is a folder named Data, located under the
XenApp Migration Center installation files in
C:\Users\user\appdata\local\citrix\citrix.xenapp.migration). You can specify a different
folder in the command-line interface with the Set-XAMigrationOption cmdlet.
●
By default, execution of PowerShell scripts is disabled. Set the PowerShell execution
policy to AllSigned (Set-ExecutionPolicy AllSigned) or above.
●
The following software is required to run the Migration Center. This software is
required for XenApp server installation and configuration, so it is likely to already be
installed.
●
●
●
.NET Framework 3.5 SP1
●
MSI 3.0
●
PowerShell 2.0
If the source farm uses file type association for published applications, update the new
farm with file type associations (using the Update file types from registry task in the
Citrix AppCenter) before you migrate applications. This allows the migration process to
create the associations in the new farm.
If you are migrating from a XenApp 5 farm, create worker groups in the new farm for
server and application silos. (However, if a worker group you specify in a server
mapping does not exist, the Migration Center creates it.)
Installing the Migration Center
The XenApp Migration Center is installed automatically when you install and configure the
XenApp 6.5 server role.
If you need to re-install the Migration Center at a later date, use the installation file on the
XenApp 6.5 media. In the Administration\Delivery Services Console\setup folder,
double-click Citrix.XenApp.Migration.Install_x64.msi.
Note: Citrix recommends performing direct migrations, entirely from a server in the new
farm. If your deployment does not allow this, see Indirect Migrations and Advanced
142
Requirements and Installation
Cmdlets for additional installation information about indirect migrations.
143
Migrating XenApp Using the Graphical
Interface
1. From the Start menu, select All Programs > Citrix > XenApp Migration > Citrix XenApp
Migration Center. The application launches and the environment initializes.
2. If you have not specified a server in the source farm (for a previous migration or
preview), the Choose a source farm dialog box appears.
a. Enter the name or IP address of the server in the XenApp source farm.
b. Click Check. If the specified server is found, the display indicates the XenApp farm
name to which the server belongs, and the XenApp version (the display for servers
in a XenApp 5 farm may indicate XenApp 4.5).
3. After you specify a server in the source farm, the welcome page appears. From the
welcome page, you can change the source server, manage server-to-worker-group
mappings (if you are migrating a XenApp 5 farm), or preview a migration.
Important: If you previously used the command-line interface to configure a
migration with setting overrides, object inclusions or exclusions, and other
customizations, those customizations are applied when you use the graphical
interface to preview or migrate. In this case, the welcome page indicates that
customizations were previously configured.
4. To change the source server, click Change source farm, enter the name or IP address
of the server in the source farm, and click Check. If the specified server is found, the
display indicates the XenApp farm name to which the server belongs, and the XenApp
version (the display for servers in a XenApp 5 farm may indicate XenApp 4.5).
If you change the source server, be sure to update any previously-configured custom
migration options and worker group mappings that refer to objects or locations in the
source farm, if needed.
5. To manage server mappings (if you are migrating a XenApp 5 farm), click Worker group
mappings. The Configure worker group mappings dialog box appears, listing all
previously-configured mappings. Each mapping specifies a representative server chosen
from a server silo in the source farm.
Important: Before migrating a XenApp 5 farm for the first time, you must configure
mappings. Although mappings are not required, a XenApp 5 farm migration is not
complete without them, because no data about the servers will be migrated (for
example, server settings, application servers, or the Zone Preference and Failover
policy).
144
●
To add a mapping, click Add. Enter the name or IP address of a server in the source
farm and the name of a worker group in the new (target) farm, or browse for the
server and worker group.
●
To edit a mapping, select the entry and click Edit and then change values.
Migrating XenApp Using the Graphical Interface
●
To delete a mapping, select the entry and click Remove.
6. To preview a migration (that is, see what will happen during a migration, without
taking any action), click Analyze Farms.
During the analysis, if you select the Automatically perform migration if analysis is
successful checkbox, the actual migration will start automatically if the analysis
completes successfully and identifies differences between the farms.
Remember: Any customizations you configured previously using the command-line
interface are used when you preview or migrate in the graphical interface.
If the analysis completes successfully, the display identifies new and changed objects
(that is, different objects and objects with different setting values in the source farm
and the target farm).
7. After the analysis completes, you can:
●
Click Migrate to Target Farm to start the migration. For changed objects, the
current value of each setting in the new farm is overwritten with the current value
from the source farm. New objects are added to the new farm.
●
Click Analyze Farms Again to start another preview.
●
Click Change analysis settings to return to the welcome page, leaving the
differences unchanged.
●
Click View log to display the PowerShell log containing details of the analysis.
Exit the application, and use the command-line interface to customize the
migration to accommodate any differences you want to retain, or objects you want
to expressly include or exclude during subsequent migrations. Then, when you
launch another preview or a migration from either interface, those customizations
will be applied.
After a migration, continue with Post-migration Tasks.
●
145
Migrating XenApp Using the Command
Line Interface
Note: See Cmdlet Reference for information about cmdlet options and properties.
1. From the Start menu, select All Programs > Citrix > XenApp Migration > Windows
PowerShell with Citrix XenApp Migration Module. The PowerShell console launches.
2. Before starting a migration, use the following cmdlets to build a file containing
server-to-worker-group mappings (if migrating from XenApp 5) and optionally, migration
options and property value overrides.
●
Use the Add-XAServerMapping cmdlet to map servers in the XenApp 5 farm to
worker groups in the new farm. The servers in the mapping are representative
servers chosen from each server silo in the legacy farm.
Important: Before migrating a XenApp 5 farm for the first time, you must
configure server mappings. Although mappings are not required, a XenApp 5 farm
migration is not complete without them, because no data about the servers will
be migrated (for example, server settings, application servers, or the Zone
Preference and Failover policy).
●
To display the server mappings you specified, use the Get-XAServerMapping
cmdlet.
To remove a server mapping, use the Remove-XAServerMapping cmdlet.
Use the Set-XAMigrationOption cmdlet to customize the migration. Setting
migration options is optional.
●
●
You can specify:
●
A remote server name; this is the name of the server in the source farm from
which objects will be migrated. Specifying the remote server name as a
migration option eliminates having to specify it each time you start a migration.
If you change the source server, be sure to update any previously-configured
custom migration options and worker group mappings that refer to objects or
locations in the source farm, if needed.
●
A nondefault folder location where the exported data from the legacy farm is
stored.
●
Object types and named objects to include or exclude from the migration.
32-bit applications to be migrated to the 64-bit farm; their paths will be
converted from \Program Files\ to \Program Files (x86)\.
To display the migration options you specified, use the Get-XAMigrationOption
cmdlet.
●
146
Migrating XenApp Using the Command Line Interface
●
Use the Add-XASettingOverride cmdlet to specify values for individual object
properties, if you do not want to migrate specific values from the source farm to
the new farm. Specifying setting overrides is optional.
●
To display the names of object properties you can specify with the
Add-XASettingOverride cmdlet, use the Get-XALegacySettingName cmdlet.
●
To display the property override values you specified, use the
Get-XASettingOverride cmdlet.
To remove a property override value you specified, use the
Remove-XASettingOverride cmdlet.
Remember: Previews and migrations launched from either interface will use the
customizations (and mappings, if migrating from XenApp 5) specified in the
command-line interface, unless expressly overridden.
●
3. To preview the migration (that is, see what will happen during a migration, without
taking any action), enter Start-XAMigration -PendingReportOnly.
4. Launch the migration with the Start-XAMigration cmdlet.
5. After running a migration, use the Get-XAMigrationObjectCount cmdlet to display a
count of the objects in the legacy and new farms. This helps monitor equivalency
between the new farm and the legacy farm. You can tailor the display to report
differences from an existing snapshot.
After a migration, continue with Post-migration Tasks.
Note: Subsequent migrations (launched from either interface) will use the current
migration options, and property value overrides file.
147
Cmdlet Reference
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.
The Migration Center cmdlets support the PowerShell common parameters. In particular,
-Confirm and -Verbose can be helpful in the migration process.
Although the -WhatIf common parameter is supported, using the -PendingReportOnly option
with the Start-XAMigration cmdlet provides more detailed information when previewing a
migration.
Add-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Adds a mapping between a server in the
source farm and a worker group in the new farm. You must specify the following options:
Option
Description
-ServerName server-name
MFCOM name of the server in the source 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 source farm (it overrides the
setting in the source farm). To display the names of object properties you can specify with
the Add-XASettingOverride cmdlet, use the Get-XALegacySettingName cmdlet.
148
Cmdlet Reference
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:\ProgramFiles (x86)\Test\Test.exe.
Add-XASettingOverride -PropertyName
CommandLineExecutable -ObjectType Application
-Value "C:\Program Files\Test\Test.exe"
-MatchValue "C:\Program Files (x86)\Test\Test.exe"
Get-XALegacySettingName
Lists the settings you can use with the Add-XASettingOverride cmdlet. You can specify the
following options:
Option
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.
149
Cmdlet Reference
For example, the following cmdlet gets a list of valid settings that contain "LicenseServer"
in the property name.
Get-XALegacySettingName *LicenseServer*
The following cmdlet gets a list of valid settings for object types that start with "Server"
and that contain "LicenseServer" in the property name.
Get-XALegacySettingName *LicenseServer*
-ObjectType Server*
Get-XAMigrationObjectCount
Displays counts of objects in the source and new farms. Use the -ImportOnly option to
generate the differences from an existing snapshot.
Get-XAMigrationOption
Lists migration options (that is, migration options previously specified with
Set-XAMigrationOption cmdlets).
Get-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Lists server-to-worker-group mappings (that is,
mappings previously specified with Add-XAServerMapping cmdlets).
Get-XASettingOverride
Lists setting overrides (that is, object property values previously specified with
Add–XASettingOverride cmdlets).
Remove-XAServerMapping
(Valid only when migrating a XenApp 5 farm) Removes a server-to-worker-group mapping
(that is, a mapping previously specified with an Add-XAServerMapping cmdlet).
Remove-XASettingOverride
Removes a setting override (that is, an object property value previously specified with an
Add-XASettingOverride cmdlet).
150
Cmdlet Reference
Set-XAMigrationOption
Sets migration options.
Option
Description
-RemoteServerName name
Name of the server in the source farm from which
objects will be exported. This value is used if you do not
specify the -RemoteServerName option in the
Start-XAMigration cmdlet, or a server in the source farm
when using the graphical interface.
If you do not specify the -RemoteServerName option in
the Start-XAMigration or Set-XAMigrationOption cmdlet,
or if you did not specify a server name in the source farm
using the graphical interface, the migration ends.
If you change the source server, be sure to update any
previously-configured custom migration options and
worker group mappings that refer to objects or locations
in the source farm, if needed.
-DataFolderPath path
Path to the folder where exported data from the source
farm is placed. If the folder does not exist, the Migration
Center will attempt to create it.
If you do not specify this option, exported data is moved
to the Data folder located under the Migration Center
installation files.
-ObjectType object-type
Object type. This option is used with the –Include and
–Exclude options, which specify object names.
Valid values are: Administrator, Application,
FarmConfiguration, Folder, LoadEvaluator, Policy, and
ServerConfiguration.
If you exclude folder objects from the migration,
application folders that contain applications will be
migrated, in order to preserve the structure and prevent
duplication. However, server folders and application
folders that do not contain applications will not be
migrated.
151
-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.
Cmdlet Reference
-X86ApplicationList
application
32-bit application to be migrated. The path for this
application will be converted from \Program Files\ to
\Program Files (x86)\. Separate multiple application
names with commas. You can use wildcards.
For example, the following cmdlet uses the -ObjectType and -Exclude options to exclude
applications named "A1" and "A2" from the migration.
Set-XAMigrationOption –ObjectType Application
–Exclude A1, A2
The following cmdlet uses the -ObjectType, -Include, and -Exclude options to include all
applications with a name containing "Microsoft" except "Office."
Set-XAMigrationOption –ObjectType Application
–Include *Microsoft* –Exclude *Office*
The following cmdlet uses the -ObjectType and -Enabled options to disable migration of all
applications.
Set-XAMigrationOption –ObjectType Application
–Enabled $false
The following cmdlet uses the -X86ApplicationList option to migrate the 32-bit applications
app1 and app2, plus all 32-bit applications with names containing "office;" the paths for
these applications will be converted to \Program Files (x86)\.
Set-XAMigrationOption -X86ApplicationList
app1, app2, *office*
Start-XAMigration
Starts a migration or migration preview. You can specify the following options:
Option
Description
-RemoteServerName name
Name of the server in the source farm from which
objects will be exported.
If you do not specify this option, but you specified a
-RemoteServerName option in the Set-XAMigrationOption
cmdlet, or a server in the source farm when using the
graphical interface, that name is used.
If you do not specify the -RemoteServerName option in
the Start-XAMigration or Set-XAMigrationOption cmdlet,
or if you did not specify a server name in the source
farm using the graphical interface, the migration ends.
If you change the source server, be sure to update any
previously-configured custom migration options and
worker group mappings that refer to objects or locations
in the source farm, if needed.
152
Cmdlet Reference
-PendingReportOnly
Generates records that indicate which objects will be
migrated and which values will be changed, but does not
actually perform the migration. Use this option to
preview a migration.
This option provides more detail than the standard
PowerShell -WhatIf option.
-ExportOnly
Exports objects from the source farm to a file, but does
not import them to the new farm.
This option is generally used only during an indirect
migration; see Indirect Migrations and Advanced
Cmdlets.
-ImportOnly
Imports objects to the new farm.
This option is generally used only during an indirect
migration; see Indirect Migrations and Advanced
Cmdlets.
153
Post-migration Tasks
After a migration completes, check the log to confirm success. Items that do not migrate
successfully generate descriptive log entries, such as Skipped invalid File type
<file-type>. To view the log:
●
From the graphical interface, select View Log.
●
From the command-line interface, look in the Data folder under
c:\Users\user\AppData\Local\Citrix\Citrix.XenApp.Migration (or an alternate location
you specified before the migration with the -SetXAMigrationOption cmdlet)
Note: In command-line displays and the log, the Policy object refers to IMA policies
configured in a XenApp 5 source farm. The Group Policy object refers to policies
configured using XenApp Management (AppCenter or Delivery Services Console) in a
XenApp 6.x farm.
After you confirm that the migration completed successfully:
154
●
Associate servers or OUs with worker groups.
●
Create load evaluator policies.
●
Create zone policies.
●
Configure printer settings.
●
Initiate Configuration Logging in the new farm.
●
Copy Health Monitoring test executables to the new farm and configure Health
Monitoring settings.
●
Optionally, add new servers in the old server folder hierarchy to preserve delegated
permissions.
●
After migrating a 32-bit XenApp 5 farm, rebuild profiled applications, to enable
streamed-to-server applications to launch.
Indirect Migrations and Advanced
Cmdlets
Indirect Migrations
Important: Indirect migrations to XenApp 6.5 from previous XenApp versions are not
supported.
Citrix recommends performing the migration entirely from a server in the new XenApp farm
(a direct migration). However, if the source farm and new farm cannot communicate,
perhaps because they are in different domains that do not have a trust relationship, you
can perform an indirect migration. In an indirect migration, you run the Migration Center
from a server in the source farm to export settings, then import the settings using the
Migration Center on a server in the new farm. In this case, you must install the Migration
Center on a server in the source farm. You must use the command-line interface for an
indirect migration.
1. On a server in the source farm:
a. Complete the requirements for the source farm, as described in Requirements and
Installation. Additionally:
●
Ensure the IMA service is running (for XenApp 6.0 source farms, the XACOM
service must also be running).
●
You must have write access to the folder where the exported data from the
source farm is placed.
●
Set the PowerShell execution policy to AllSigned (Set-ExecutionPolicy AllSigned)
or above.
Install the required software (.NET Framework 3.5 SP1, MSI 3.0, and PowerShell
2.0).
b. Install the Migration Center from the XenApp 6.5 media. From the
Administration\Delivery Services Console\setup folder:
●
●
Double-click Citrix.XenApp.Migration.Install_x64.msi to install the Migration
Center on a 64-bit computer.
Double-click Citrix.XenApp.Migration.Install_x86.msi to install the Migration
Center on a 32-bit computer.
c. From the Start menu, select All Programs > Citrix > XenApp Migration > Windows
PowerShell with Citrix XenApp Migration Module. (Select Citrix XenApp Migration
Module x86 on a 32-bit server.)
●
d. Build a file containing server mappings (if you are migrating a XenApp 5 farm),
migration options, and property value overrides, as described in Migrating XenApp
Using the Command Line Interface.
155
Indirect Migrations and Advanced Cmdlets
e. Export settings with a Start-XAMigration -ExportOnly cmdlet. The output is a series
of XML files.
2. Copy the XML files to the server in the new farm, replacing the files on that server. This
includes the file containing server mappings, migration options, and property value
overrides.
3. From a server in the new farm, launch the Migration Center, and import the settings
with a Start-XAMigration -ImportOnly cmdlet or one of the advanced import cmdlets.
Advanced Import Cmdlets
The Start-XAMigration cmdlet is intended for scripted, unattended migrations. For
interactive testing, the Migration Center includes additional object-specific import cmdlets.
These cmdlets offer alternatives to using the –ImportOnly option with the Start-XAMigration
cmdlet and the -ObjectType and -Include options with the Set-XAMigrationOption cmdlet.
You can also use these cmdlets during indirect migrations.
These cmdlets use the configured server mappings (when migrating a XenApp 5 farm),
migration options, and object property value overrides.
For complete PowerShell syntax, type Get-Help cmdlet.
●
Import-XAAdministrator
●
Import-XAApplication
●
Import-XAFarmConfiguration
●
Import-XAFolder
●
Import-XALoadBalancingPolicy *
●
Import-XALoadEvaluator
●
Import-XAPolicy
●
Import-XAServerConfiguration
●
Import-XAWorkerGroup *
* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm.
Advanced XALegacy Cmdlets
Using the advanced XALegacy cmdlets can be helpful if an object did not migrate as
expected. The Get-XALegacy* cmdlets connect to the legacy farm and read the settings for
an object in the legacy farm. You can use the Convert-XALegacyObject,
New-XALegacyConnection, and Remove-XALegacyConnection cmdlets when creating a
custom migration script that does not use the Import-XA* or Start-XAMigration cmdlets.
156
Indirect Migrations and Advanced Cmdlets
For complete PowerShell syntax, type Get-Help cmdlet.
●
Get-XALegacyAdministrator
●
Get-XALegacyApplication
●
Get-XALegacyFarmConfiguration
●
Get-XALegacyFolder
●
Get-XALegacyHmrTest
●
Get-XALegacyLoadBalancingPolicy *
●
Get-XALegacyLoadEvaluator
●
Get-XALegacyPolicy
●
Get-XALegacyPolicyConfiguration
●
Get-XALegacyPolicyFilter
●
Get-XALegacyServer
●
Get-XALegacyServerConfiguration
●
Get-XALegacySessionPrinter
●
Get-XALegacyWorkerGroup *
●
Convert-XALegacyObject
●
New-XALegacyConnection
●
Remove-XALegacyConnection
* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm.
These advanced cmdlets include objects that cannot be migrated alone (for example,
session printers that are inside a user policy, and HMR tests that are inside farm or server
settings). This greater granularity may be helpful when troubleshooting migration, because
these objects are more complex, with multiple sets of properties.
157
Managing and Administering Your
XenApp Environment
The management and administration of your Citrix XenApp environment consists of
performing tasks in the console to administer servers, manage administrators, and publish
resources. You can also administer and modify your environment through policy-based
settings.
Management Console and
Other Tools
Describes the Citrix tool set for managing servers, farms,
published resources, and connections. You can launch all
tools by accessing the Citrix program group on the Start
menu.
Managing Citrix
Administrators
How to create, modify, and delete farm administrators.
Delivering XenApp to
Software Service Subscribers
How to implement the Windows Desktop Experience,
includng a Windows 7 look and feel to desktops.
Working with Citrix Policies
How to control the XenApp experience through specific
policies and policy settings.
Citrix Policies Reference
Managing Session
Environments and
Connections
Manage, define, monitor, and optimize the XenApp end
user sessions.
Securing Server Farms
Maintain a secure XenApp environment.
Maintaining Server Farms
Describes XenApp farm maintenance tasks, such as
monitoring CPU usage, updating the License Server
settings, using Worker Groups, and so on.
Understanding XenApp
Printing
Provides XenApp printing concepts and how to implement
printing in your XenApp environment.
Configuring and Maintaining
XenApp Printing
158
Manage Power and Capacity
Describes XenApp Power and Capacity Management to
help reduce power consumption and manage XenApp
server capacity by dynamically scaling up or scaling down
the number of online XenApp servers.
Manage Loads
How to set up, manage, and monitor server and
published application loads in a server farm so that users
can run the published applications they need quickly and
efficiently.
Configure HDX
Describes a broad set of technologies designed to provide
a high-definition user experience
XenApp Server Utilities
Reference
Describes the XenApp server utilities, which provide an
alternative method to using the console for maintaining
and configuring servers and farms.
Manage
Performance Counters
Reference
159
Describes how to use the Window Performance Monitor to
observe performance counters associated with sessions,
networking, and security.
Management Consoles and Other Tools
Citrix provides a comprehensive set of tools for managing servers, farms, published
resources, and connections.
You can launch all tools by accessing the Citrix program group on the Start menu.
Citrix AppCenter
The AppCenter (formerly Delivery Services Console) is a tool that snaps into the Microsoft
Management Console (MMC) and enables you to perform a number of management
functions.
For XenApp, you can set up and monitor servers, server farms, published resources, and
sessions. Configure application access (both through the Web Interface and the Citrix Online
Plug-in) and set up policies and printers.
In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your
farms, view hotfix information for your Citrix products, and track administrative changes.
My Views are configurable displays that give you quick access to items you must examine
regularly or items in different parts of the AppCenter tree that you want to group together.
For example, create a My View display to monitor your preferred performance data for two
sets of servers in different server farms. The performance-related information in a My View
display is refreshed at regular intervals.
With Hotfix Management, check which hotfixes are applicable to your Citrix products,
search for particular updates on your system, and identify servers where up-to-date
hotfixes must be applied. In the left pane of the AppCenter, select Citrix Resources >
Configuration Tools > Hotfix Management.
If your deployment includes multiple XenApp farms (such as one farm comprising servers
running the latest version of XenApp, and another farm comprising servers running a legacy
version of XenApp), you can use one MMC console that has separate AppCenter snap-ins to
manage each farm.
License Administration Console
Use this console to manage and track Citrix software licenses. For more information about
licensing, see the License Administration console Help and Getting Started with Citrix
Licensing in Licensing Your Product.
Citrix SSL Relay Configuration Tool
Use this tool to secure communication between a server running the Web Interface and your
farm.
160
XenApp 6 for Windows 2008 R2
Shadow Taskbar
Shadowing allows users to view and control other users’ sessions remotely. Use the Shadow
Taskbar to shadow sessions and to switch among multiple shadowed sessions. You can also
shadow ICA sessions with the AppCenter.
SpeedScreen Latency Reduction Manager
Use this tool to configure local text echo and other features that improve the user
experience on slow networks.
161
Management Consoles and Other Tools
Citrix provides a comprehensive set of tools for managing servers, farms, published
resources, and connections.
You can launch all tools by accessing the Citrix program group on the Start menu.
Citrix AppCenter
The AppCenter (formerly Delivery Services Console) is a tool that snaps into the Microsoft
Management Console (MMC) and enables you to perform a number of management
functions.
For XenApp, you can set up and monitor servers, server farms, published resources, and
sessions. Configure application access (both through the Web Interface and the Citrix Online
Plug-in) and set up policies and printers.
In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your
farms, view hotfix information for your Citrix products, and track administrative changes.
My Views are configurable displays that give you quick access to items you must examine
regularly or items in different parts of the AppCenter tree that you want to group together.
For example, create a My View display to monitor your preferred performance data for two
sets of servers in different server farms. The performance-related information in a My View
display is refreshed at regular intervals.
With Hotfix Management, check which hotfixes are applicable to your Citrix products,
search for particular updates on your system, and identify servers where up-to-date
hotfixes must be applied. In the left pane of the AppCenter, select Citrix Resources >
Configuration Tools > Hotfix Management.
If your deployment includes multiple XenApp farms (such as one farm comprising servers
running the latest version of XenApp, and another farm comprising servers running a legacy
version of XenApp), you can use one MMC console that has separate AppCenter snap-ins to
manage each farm.
License Administration Console
Use this console to manage and track Citrix software licenses. For more information about
licensing, see the License Administration console Help and Getting Started with Citrix
Licensing in Licensing Your Product.
Citrix SSL Relay Configuration Tool
Use this tool to secure communication between a server running the Web Interface and your
farm.
162
Management Consoles and Other Tools
Shadow Taskbar
Shadowing allows users to view and control other users’ sessions remotely. Use the Shadow
Taskbar to shadow sessions and to switch among multiple shadowed sessions. You can also
shadow ICA sessions with the AppCenter.
SpeedScreen Latency Reduction Manager
Use this tool to configure local text echo and other features that improve the user
experience on slow networks.
163
To start the AppCenter and discover
servers
When you install the first server in a new server farm, you provide credentials for a full
authority Citrix administrator. This account has the authority to manage and administer all
areas of farm management. If you are logging on to the AppCenter for the first time, use
this account to log on and to add other individuals to the Citrix administrators group.
Important: Citrix recommends that you use a domain account to run the AppCenter. You
can use your local administrator account, but the user name and password should be the
same for all local administrator accounts for all servers in your farms.
Citrix supports using the AppCenter only with this version of Citrix XenApp. Using the
AppCenter with servers running a previous version of XenApp is not supported. Likewise,
using a previous version of the console with this version of XenApp is not supported.
Click Start > All Programs > Administrative Tools > Citrix > Management Consoles > Citrix
AppCenter.
The first time you open the AppCenter you are automatically prompted to start the
discovery process: you select the components you want, configure the discovery process,
and find the items to manage.
Discovery is an important operation that checks for items (such as devices or applications)
that were added to or removed from your XenApp environment. Appropriate changes then
appear in the AppCenter tree.
After this, run the discovery process only if you want to refresh the view of your
deployment. The AppCenter tree refreshes automatically each time you add, remove, or
modify items in your deployment.
When using discovery to connect to your XenApp deployment, you must specify the name or
IP address of at least one server in each farm that you want to manage. When discovery is
complete, the AppCenter tree displays the items that you specified.
You can configure discovery only for some components. The configuration process can vary
among components. The Configure and run discovery task appears in the Actions pane only
for configurable components; otherwise, only the Run discovery task is available.
1. In the AppCenter tree, select Citrix Resources or the product or component whose
objects you want to discover.
2. Click Configure and run discovery, or to run discovery without any configuration, click
Run discovery.
3. When discovering XenApp deployments, specify the name or IP address of at least one
server running XenApp in each farm that you want to manage.
164
To view zones
Zones can be viewed and configured in the console. For information on configuring zones,
see To configure zones and back-up data collectors.
1. From the AppCenter, in the left pane, expand the Zones node.
2. Under Zones, select a zone. The results pane displays the servers in the chosen zone.
165
To refresh user data automatically
Refreshing user data automatically is disabled by default. You can control the frequency of
automatic updates to server, server folder, and published application information on the
Citrix AppCenter. The auto-refresh settings apply only to the AppCenter you are running
and not other instances of the AppCenter on your network.
Note: Do not enable this feature if you have many sessions, because it can affect
performance.
1. In the left pane, select one of these nodes (depending on what type of user data you
want to refresh automatically):
●
The farm for which you want to refresh the user data automatically
●
The server for which you want to refresh the user data automatically
●
The application for which you want to refresh the user data automatically
2. In the Actions pane or from the Other Tasks section (depending on the node that you
selected), click Refresh user data and choose one of these options:
●
Automatically refresh user data for servers. Selecting this option enables
automatic refreshing of each 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.
3. In the Refresh rate (seconds) box, select the number of seconds between each update
(10, 30, 60, or 90).
●
166
Managing Citrix Administrators
Citrix administrators are individuals tasked with managing server farms.
To create a Citrix administrator
You can make any member of a Windows or Novell Domain Services for Windows account
authority a Citrix administrator.
1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix
AppCenter.
2. In the left pane, expand Citrix Resources > XenApp and select a farm.
3. From the Actions pane on the right, click Add administrator.
4. Click Add and select the configured user or user group account to designate as a Citrix
administrator.
5. On the Privileges page, select the authority level you want to grant the administrator
account.
6. If you are creating a custom administrator account, in the Tasks pane, select the tasks
you want to delegate to the custom administrator.
To modify a Citrix administrator
1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix
AppCenter.
2. From the left pane, , expand Citrix Resources > XenApp and the farm, then choose the
Administrators node.
3. On the Administrators tab, select the administrator whose properties you want to
change.
4. On the Actions pane, click Administrator properties.
5. Choose from the following options:
167
●
To change an administrator's privilege level, open the Privileges page
●
To assign or update custom permissions, open the Permissions page
Managing Citrix Administrators
To disable a Citrix administrator
Disable a Citrix administrator if you want to temporarily remove access for an administrator
but retain the account and settings.
1. Select the administrator whose privileges you want to disable.
2. On the Actions pane, click Disable.
When an administrator is disabled, the administrator icon appears in grey and an Enable
task becomes available.
To re-enable a Citrix administrator
1. Select the administrator whose privileges you want to enable and then, on the Actions
pane, click Enable.
To remove a Citrix administrator
Remove a Citrix administrator if you want to delete the account and settings. Only
administrators with full access can disable or remove other Citrix administrator accounts.
Important: If only one Citrix administrator account with full access remains on the list,
you cannot remove it.
1. Select the administrator or administrators whose account you want to remove.
2. On the Actions pane, click Delete administrator.
168
Delegating Tasks to Custom
Administrators
You can delegate tasks through the Citrix AppCenter by associating custom Citrix
administrator accounts with permissions to perform select tasks.
Citrix recommends you create Windows, Active Directory, or NDS groups to assign these
permissions. When you create custom Citrix administrators, simply select the group instead
of individual users. This allows you to add and remove users to these groups without
reconfiguring all of the permissions.
Permissions you set on nodes apply farm wide. Permissions you set on folders (applications,
servers, and any folders within) apply only to the applications and servers contained within
the selected folder.
You cannot grant permissions to applications and servers directly. To grant permissions to
applications and servers, you must first place the applications or servers in folders and then
grant permissions at the folder level. Therefore, before you delegate tasks for applications
and servers, make sure you group the applications and servers in folders that allow you to
delegate the tasks in a meaningful way.
Note: To apply the same permissions to a new folder as to its parent folder, select the
Copy permissions from the parent folder option when you create the new folder.
169
Delegating Tasks to Custom Administrators
To delegate tasks to existing custom administrators
1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix
AppCenter.
2. From the left pane, expand Citrix Resources > XenApp and the farm, then choose the
Administrators node.
3. On the Administrators tab, select the administrator to whom you want to delegate
tasks.
4. From the right pane, under Actions, click Administrator properties.
5. In the Citrix Administrator Properties dialog box, on the Privileges pane, if Custom is
not selected, select it.
6. Click Permissions to view the task permissions assigned to the administrator.
7. Click on a folder in the Folders list to view additional tasks.
8. To select the tasks to which the administrator has access, select or clear the check
boxes, as appropriate.
9. If you set permissions on a node or a folder that contains a subfolder, the Copy to
Subfolders button becomes active. Click this button if you want to copy the permissions
from the parent node or folder to the constituent folder.
Note: If you change an administrator’s OBDA permissions, he or she must manually rerun
discovery.
To assign folder permissions
To allow custom administrators to perform specific tasks in the farm, you assign object
permissions at the farm level. To view and change permission on objects, such as printers,
you must be a Citrix administrator with full access to view and change object permissions.
1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix
AppCenter.
2. From the left pane, select the folder under the farm to which you want to grant access.
3. From the Actions pane, select Other Tasks, then Permissions. The resulting dialog box
lists the administrators who currently have access to the selected folder.
4. To give access to an administrator that is not on the Administrators list, click Add and
then click the check box to allow access to the folder.
If the administrator to whom you want to give access does not appear in the Add
Access to folder dialog box, click Add to create the administrator.
170
Delegating Tasks to Custom Administrators
To assign or change object permissions
To allow custom administrators to perform specific tasks in the farm, you assign object
permissions at the farm level. To view and change permission on objects, such as printers,
you must be a Citrix administrator with full access to view and change object permissions.
1. From the Start menu, select All Programs > Citrix > Management Consoles > Citrix
AppCenter.
2. From the left pane, select the farm to whose objects you want to grant access.
3. From the right pane, under Actions, choose Other Tasks, then Set permission on
objects.
4. Select the object whose permissions you want to change and click Permissions.
Under Administrators, you can see the administrators who have access to tasks related
to the object.
5. From the Administrators list select the administrator to whom you want to assign
additional or change existing folder permissions. If the administrator you want is not on
the list, click Add and select the administrator.
If the administrator you want is not a custom administrator, click Edit and change the
administrator's privilege level to Custom. This allows you to change the administrator's
permissions.
6. With the administrator selected, use the check boxes to change specific permissions in
the Tasks pane.
If the folder contains subfolders, the following options become available:
●
Choose Copy the permissions of this administrator for this folder to its subfolders to
copy newly configured permissions to all folders nested in the selected folder for the
custom administrator.
●
Choose Copy the permissions of all administrators for this folder to its subfolders to
copy the newly configured permissions of each custom administrator who has access to
the selected folder to the folders nested within it.
Note: If you change the permissions later in the top level folder, the changes are not
automatically copied to the nested folders. When you make changes to top level
folders, use either the Copy the permissions of this administrator for this folder to
its subfolders or the Copy the permissions of all administrators for this folder to its
subfolders function to copy the permissions again.
171
Delivering XenApp to Software Services
Subscribers
XenApp enables service providers to deliver hosted desktops and applications through the
Infrastructure Setup and Enhanced Desktop Experience features. Additionally, images
displayed through hosted desktops and applications are optimized for low-bandwidth
connections.
The PowerShell scripts used to install and configure these features are located at %Program
Files (x86)%\Citrix\App Delivery Setup Tools.
Infrastructure Setup
The Infrastructure Setup feature enables service providers to deploy XenApp farms quickly,
add tenants, and add servers as needed to manage farm capacity. To do this, the server
administrator or user with an administrator account on the primary server can execute
PowerShell scripts to install and configure a XenApp farm consisting of the following
components:
●
Data collector and backup data collector
●
Web Interface configured to use Access Gateway
The following components must be present in your environment and configured prior to
executing the scripts:
172
●
Active Directory
●
Database server running Microsoft SQL Server 2008 or later, or Microsoft SQL Server
Express 2008 or later
●
Citrix Licensing server
●
Access Gateway
●
Servers running Windows Server 2008 R2, joined to the domain
●
Windows PowerShell Remoting enabled on the servers, to facilitate remote
configuration
●
Firewall
Delivering XenApp to Software Services Subscribers
Enhanced Desktop Experience
The Enhanced Desktop Experience feature enables service providers to deploy hosted
desktops with the Windows 7 look and feel and to control desktop customization by users
through Group Policy.
Installed as the Windows Desktop Experience Integration component, this feature is
selected by default when you choose to install the XenApp server role. The installation
sequence performs the following tasks:
●
Adds the Desktop Experience and XPS Viewer features to the Windows server
configuration
●
Moves the Citrix folder items in the Start menu to the Administrative Tools folder
(including the Citrix AppCenter)
●
Creates a new Windows Theme file and sets the default wallpaper
●
Starts the Windows Themes service and configures it to start automatically
Usage Reporting
Premium Edition service providers have the option to use Citrix EdgeSight to monitor
XenApp user sessions and application usage, and generate reports. More information on
using EdgeSight for tenant usage reporting is included in the Citrix Service Provider Toolkit,
available from the Citrix Web site.
Optimized Image Display
Extra color compression improves the display of images based on a bandwidth threshold
being reached. This feature provides a flexible means for Citrix Service Providers to
optimize image display according to users' connections.
If the client connection bandwidth falls below the specified threshold, such as with
low-bandwidth WAN connections, extra color compression is applied. When this occurs,
images appear clearer and session bandwidth is minimized, compared to turning off
compression entirely. For high-bandwidth connections, such as in a LAN environment, this
compression is not applied as such connections exceed the bandwidth threshold.
To configure extra color compression, create or edit a User policy and enable the Extra
Color Compression setting. Add the Extra Color Compression Threshold setting and enter
the value, in kilobits per second, below which compression is applied.
Additional Information for Service Providers
For more information about delivering hosted desktops, refer to the following resources:
173
Delivering XenApp to Software Services Subscribers
174
●
Citrix Cloud App Delivery Setup Tools Administration Guide provides information about
the Infrastructure Setup and Enhanced Desktop Experience features, including
requirements and script usage. This PDF document is available for download through
the Citrix Service Provider CDN Web site.
●
Script help provides detailed information about each script and its parameters within
the PowerShell command window. Help is available by typing Get-Help
.\scriptname.ps1 at the PowerShell command line.
●
The Citrix Service Provider CDN Web site (http://community.citrix.com/p/csp) provides
information about the Citrix Service Provider program, access to technical resources,
and access to the Citrix Service Provider community.
To enable Windows 7 look and feel and
control desktop customization
After the Windows Desktop Experience Integration role is installed through the Server Role
Manager, you can deploy hosted desktops with the Windows 7 look and feel and control
desktop customization through Group Policy.
To perform this task, you need to run the New-CtxManagedDesktopGPO.ps1 script located
at %Program Files (x86)%\Citrix\App Delivery Setup Tools.
1. Run the New-CtxManagedDesktopGPO.ps1 script at the PowerShell command line. This
script creates the following GPOs:
●
CtxStartMenuTaskbarUser enables the Windows 7 look and feel for published
desktops. It also changes the pinned shortcuts on the Taskbar and configures the
user's Start menu to match the Windows 7 environment. This GPO includes a script
that executes when a user logs on to the server for the first time. To ensure the
script executes correctly, the PowerShell execution policy on the server must be set
to AllSigned.
●
CtxPersonalizableUser configures the user account that is accessing the XenApp
server. It configures Windows policies to limit the available Control Panel applets
and restricts users from installing programs, viewing properties, scheduling tasks, or
shutting down the server.
●
CtxRestrictedUser includes most of the policies from the CtxPersonalizableUser
GPO. Additionally, this GPO configures the Desktop wallpaper policy to prevent
users from personalizing their desktops and prevents users from modifying settings
for the Start menu and Taskbar.
CtxRestrictedComputer configures certain restrictions on the XenApp servers
allocated to the tenant. This GPO restricts users from accessing Windows Update or
removable server drives.
2. In the Active Directory Users and Computers console, link the User GPOs to the OU
containing the tenant's user accounts.
●
3. Link the CtxRestrictedComputer GPO to the OU containing the XenApp servers allocated
to the tenant.
4. In the Group Policy Management Editor, for each User GPO, add the user accounts to
the GPO's scope.
5. Add the XenApp servers to the scope of the CtxRestrictedComputer GPO.
When configuring user sessions, apply either the CtxPersonalizableUser or the
CtxRestrictedUser GPO to the user account. Some Microsoft hotfixes may be required for all
policies to function appropriately. For additional information about these GPOs, see the
help included with the New-CTXManagedDesktopGPO script.
175
To enable Windows 7 look and feel and control desktop customization
Important: Be aware that applying these policies is only one step in the process of
delivering secure, locked-down desktops. You still need to follow your organization’s
security best practices for ensuring the servers, and the desktops they deliver, are
protected.
176
Working with Citrix Policies
To control user access or session environments, configure a Citrix policy. Citrix policies are
the most efficient method of controlling connection, security, and bandwidth settings.
You can create policies for specific groups of users, devices, or connection types. Each
policy can contain multiple settings.
You can work with policies through the Group Policy Management Console in Windows or
the AppCenter in XenApp (formerly the Delivery Services Console). The console or tool you
use to do this depends on whether or not your network environment includes Microsoft
Active Directory and whether or not you have the appropriate permissions to manage Group
Policy Objects (GPOs).
Using the Group Policy Management Editor
If your network environment includes Active Directory and you have the appropriate
permissions to manage Group Policy, use the Group Policy Management Editor to create
policies for the XenApp servers in your environment. The settings you configure affect the
GPOs you specify through the Group Policy Management Console.
Using the AppCenter
If your environment includes a different directory service (such as Novell Domain Services
for Windows) or you are a Citrix administrator without permission to manage Group Policy,
use the AppCenter to create policies for your farm. The settings you configure are stored in
a farm GPO in the data store.
Policy Processing and Precedence
Group Policy settings are processed in the following order:
1. Local GPO
2. XenApp farm GPO (stored in the farm data store)
3. Site-level GPOs
4. Domain-level GPOs
5. Organizational Units
177
Working with Citrix Policies
However, in the event of a conflict, policy settings that are processed last can overwrite
those that are processed earlier. This means that policy settings take precedence in the
following order:
1. Organizational Units
2. Domain-level GPOs
3. Site-level GPOs
4. XenApp farm GPO (stored in the farm data store)
5. Local GPO
For example, a Citrix administrator creates a policy (Policy A) through the AppCenter that
enables client file redirection for the company's sales employees. Meanwhile, another
administrator creates a policy (Policy B) through the Group Policy Management Editor that
disables client file redirection for the sales employees. When the sales employees log on to
the farm, Policy B is applied and Policy A is ignored. This happens because Policy B was
processed at the domain level and Policy A was processed at the XenApp farm GPO level.
Active Directory Functional Levels
Citrix policies are supported for use in Active Directory environments running at the
Windows 2000 domain functional level, at a minimum. To ensure Citrix policy settings are
included in reports when Resultant Set of Policy is calculated, at least one domain
controller running Windows Server 2003 must be present in the forest.
Workflow for Citrix Policies
The process for configuring policies is as follows:
1. Create the policy.
2. Configure policy settings.
3. Apply the policy to connections by adding filters.
4. Prioritize the policy.
5. Verify the effective policy by running the Citrix Group Policy Modeling wizard.
178
Navigating Citrix Policies and Settings
In Active Directory, policy settings are collected into two main categories: Computer
Configuration and User Configuration. Computer configuration settings pertain to servers,
regardless of who logs on. User configuration settings pertain to users accessing the server,
regardless of where they log on.
XenApp policies and settings are collected into similar categories: Computer and User.
Computer policy settings pertain to XenApp servers and are applied when the server is
rebooted. User policy settings pertain to user sessions and are applied for the duration of
the session.
Accessing Policies and Settings
In the AppCenter console, you can access policies and settings by clicking the Policies node
from the console tree and then selecting either the Computer or User tabs in the middle
pane. In the Group Policy Management Editor, you can access policies and settings by
clicking the Citrix Policies node under Computer Configuration or User Configuration in
the tree pane.
The Computer and User tabs each display a list of the policies that have been created.
Beneath this list, the following tabs are displayed:
●
Summary displays the settings and filters currently configured for the selected policy
●
Settings displays by category the available and configured settings for the selected
policy
●
Filters displays the available and configured filters for the selected policy
Searching Policies and Settings
From these consoles, you can search the policies you create and their settings and filters.
All searches find items by name as you type. You can perform searches from the following
places:
●
For searching policies, use the search tool near the list of Citrix policies
●
For searching settings, use the search tool on the Settings tab
●
For searching filters, use the search tool on the Filters tab
You can refine your search by:
●
179
On the Settings or Filters tabs, in the Settings to show box, selecting a product version
to display only the settings or filters that are supported in the selected version.
Navigating Citrix Policies and Settings
●
On the Settings or Filters tabs, selecting Active Settings or Active Filters,
respectively, to search only the settings or filters that have been added to the selected
policy.
●
On the Settings tab, selecting a category such as Auto Client Reconnect or Bandwidth
to search only the settings in that category.
To search the entire catalog of settings or filters, select All Settings or All Filters.
180
Creating Citrix Policies
Before you create a policy, decide which group of users or devices you want it to affect.
You may want to create a policy based on user job function, connection type, client device,
or geographic location. Alternatively, you can use the same criteria that you use for
Windows Active Directory group policies.
If you already created a policy that applies to a group, consider editing the policy and
configuring the appropriate settings instead of creating another policy. Avoid creating a
new policy solely to enable a specific setting or to exclude the policy from applying to
certain users.
You can create policies using the following methods:
●
Create a new policy using the New Policy wizard
●
Create a new policy based on the settings included in a policy template
To create a new policy with the New Policy wizard
The New Policy wizard enables you to create a new, empty policy to which you can add the
settings you need.
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane and then select the
Computer or User tab.
From the Group Policy Management Editor, select the Citrix Policies node in the
left pane.
2. Click New. The New Policy wizard appears.
●
3. Enter the policy name and, optionally, a description. Consider naming the policy
according to who or what it affects; for example, Accounting Department or Remote
Users.
4. Choose the policy settings you want to configure.
5. Choose the filters you want to apply to the policy.
6. Elect to leave the policy enabled or clear the Enable this policy checkbox to disable
the policy. Enabling the policy allows it to be applied immediately to users logging on
to the farm. Disabling the policy prevents it from being applied. If you need to
prioritize the policy or add settings at a later time, consider disabling the policy until
you are ready to apply it to users.
181
Creating Citrix Policies
To create a new policy based on a template
By default, the new policy includes all the same settings as the original template. However,
you can choose to accept these settings or to customize the policy according to your needs.
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. Click the Templates tab and select the template from which you want to create the
policy.
●
3. Click New Policy. The New Policy wizard appears.
4. Enter a unique name for the new policy or accept the default name that XenApp
generates automatically.
Note: If you enter a name that is in use by an existing policy, no policy is created.
The settings you selected are retained; however, you must re-run the policy wizard.
If you use the Copy-Item PowerShell cmdlet to create a policy from a template, and
you specify the same name as an existing policy, the -Force switch allows you to
merge the settings you selected into the existing policy.
5. Choose whether or not to customize the policy. If you choose not to customize the
policy, proceed to Step 7.
6. If you choose to customize the policy, add or remove the settings you want.
7. Select and configure a filter for the new policy.
8. Elect to leave the policy enabled or clear the Enable this policy checkbox to disable
the policy. Enabling the policy allows it to be applied immediately to users logging on
to the farm. Disabling the policy prevents it from being applied. If you need to
prioritize the policy or add settings at a later time, consider disabling the policy until
you are ready to apply it to users.
182
Working with Citrix Policy Templates
Policy templates allow you to configure Citrix policies quickly and deploy them to your
XenApp environment. Templates consist of pre-configured settings that can apply to a
server or to a user session. You can use templates in the following ways:
●
As a source for creating other policies
●
As a tool with which to compare existing policies
●
As a method for delivering or receiving policy configurations from Citrix Support or
trusted third parties
You can perform the following tasks with policy templates:
●
Create new templates using existing templates or policies
●
Create new policies using existing templates
●
Import and export templates
●
Compare settings, including default values, of selected policies and templates
Templates tab
Policy templates are displayed on the Templates tab in the AppCenter console and the
Group Policy Management Editor. In the AppCenter, templates for both Computer and User
settings are displayed in a single list. In the Group Policy Management Editor, Computer
templates are displayed when you are working with Computer policies. Likewise, User
templates are displayed when you are working with User policies.
Built-in Templates
XenApp comes with the following built-in templates:
183
●
Citrix High Definition User Experience templates include Computer and User settings
for providing high quality audio, graphics, and video to users.
●
Citrix High Server Scalability templates include Computer and User settings for
providing an optimized user experience while hosting more users per server.
●
Citrix Optimized Bandwidth for WAN templates include Computer and User settings for
providing an optimized experience to users with low bandwidth or high latency
connections.
Working with Citrix Policy Templates
●
Citrix Security and Control templates include User settings for disabling on user
devices access to peripheral devices, drive mapping, port redirection, and Flash
acceleration.
You can use these templates as a model for creating new policies or templates. Built-in
templates are created and updated by Citrix. You cannot modify or delete these templates.
However, you can modify or delete templates that you create or import through the
AppCenter or the Group Policy Management Editor.
Template Information
When selected, each template displays the following information tabs beneath the
templates list:
184
●
Settings displays a list of all the configured settings and their values in the selected
template. You can also view the default values for each setting alongside the
configured values.
●
Properties displays information such as the template creator, description, and
modification date, if applicable.
●
Prerequisites displays information pertaining to additional requirements needed for the
settings in the template to be effective when applied in a policy. This tab is displayed
only when a built-in template is selected.
Creating Policy Templates
You create templates from an existing template or an existing policy. The new template is
then populated with the same settings as the original template or policy. Filters assigned to
the original policy are not included in the template.
Templates can include either Computer settings or User settings. You cannot include both
types of settings in a template.
To create a new template based on an existing
template
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. Click the Templates tab and then select the template from which you want to create
the new template.
●
3. Click New Template. The New Template wizard appears.
4. Enter a name for the template.
5. Select and configure the policy settings you want to include in the template. Remove
any existing settings that should not be included.
6. Click Create. The new template appears on the Templates tab.
185
Creating Policy Templates
To create a new template based on an existing policy
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane and then select the
Computer or User tab.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. On the Policies tab, select the policy from which you want to create the template.
●
3. Click Actions and select Save as Template. The Save as Template dialog box appears.
4. Enter a name and a description for the new template.
5. Click Save. The new template appears on the Templates tab.
186
Importing and Exporting Policy Templates
Policy templates are local to the computer on which you are running the console to manage
your farm. You can transfer policy configurations between environments, including other
farms that you manage on the computer running the console.
You transfer templates by importing or exporting them. This allows you to perform the
following tasks:
●
Implement policy configurations from XenApp servers in other farms
●
Create backups of your template files to aid recovery of policy configurations
●
Supply policy configurations from your farm to aid Citrix Support in troubleshooting
issues
●
Implement policy configurations created by Citrix Support to resolve issues in your farm
To import a template
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. Click the Templates tab and then click Actions > Import . The Import Template dialog
box appears.
●
3. Select the template file you want to import and click Open. The imported template
appears in the templates list.
Note: If you import a template with the same name as an existing template, you can
choose to overwrite the existing template or save the template with a different name
that is generated automatically. If you are importing a template through the Group
Policy Management Editor, and the template is a different type (for example,
importing a Computer template while viewing User templates), a message appears,
notifying you the imported template is located in the appropriate templates list.
187
Importing and Exporting Policy Templates
To export a template
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. Click the Templates tab and then select the template you want to export.
●
3. Click Actions > Export. The Export Template dialog box appears.
4. Select the location where you want to save the template and click Save. A .gpt file is
created in the location you specified.
188
Comparing Policies and Templates
In some cases, you might need to compare the settings in a policy or template with those in
other policies or templates. For example, you might need to verify setting values to ensure
compliance with best practices for your environment.
You can display policy templates in two views: List View and Compare View. List View
displays policy templates in a list similar to that shown for Computer or User policies.
Compare View displays the settings of selected policies and templates in a side-by-side
view.
You can access these views by clicking the List View or Compare View buttons on the right
side of the console, just above the template list.
To compare policies and templates
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane.
From the Group Policy Management Editor, expand the Computer Configuration or
User Configuration nodes, expand the Policies node, and then select Citrix
Policies.
2. Click the Templates tab and then click the Compare View icon. The Compare
Templates and Policies dialog box appears.
●
3. Select the policies or templates you want to include. To include default values in the
comparison, select the Compare to setting defaults checkbox.
4. Click Compare. The configured settings for the selected items are displayed in
columns. Default values, if selected, are displayed in the second column by default.
Note: To change the position of the Configured Settings and Defaults columns, drag
and drop the columns to the positions you want.
5. To modify the comparison, click the Configured Settings arrow and select Add/Remove
Columns.
6. To compare all available settings for the selected items, click the Configured Settings
arrow and select Show All Settings.
To view additional information about policies or templates included in the comparison,
select the column header of the policy or template. For templates, the properties and
prerequisites appear in tabs beneath the Compare View. For policies, the properties and
filters appear.
189
Configuring Policy Settings
Policies contain settings that are applied to connections when the policy is enforced. Policy
settings can be enabled, disabled, or not configured. By default, policy settings are not
configured, meaning they are not added to a policy. Settings can be applied only when they
are added to a policy.
Some policy settings can be in one of the following states:
●
Allowed or Prohibited allows or prevents the action controlled by the setting.
●
Enabled or Disabled turns the setting on or off. If you disable a setting, it is not
enabled in lower-ranked policies.
For settings that are Allowed or Prohibited, the action controlled by the setting is either
allowed or prevented. In some cases, users are allowed or prevented from managing the
setting's action in the session. For example, if the Menu animation setting is set to
Allowed, users can control menu animations in their client environment.
In addition, some settings control the effectiveness of dependent settings. For example, the
Client drive redirection setting controls whether or not users are allowed to access the
drives on their devices. To allow users to access their network drives, both this setting and
the Client network drives setting must be added to the policy. If the Client drive
redirection setting is disabled, users cannot access their network drives even if the Client
network drives setting is enabled.
In general, Computer policy setting changes go into effect when the server reboots. User
policy setting changes go into effect the next time the relevant users establish a
connection. Policy setting changes can also take effect when XenApp re-evaluates policies
at 90 minute intervals.
Default Values of Settings
For some policy settings, you can enter a value or you can choose a value from a list when
you add the setting to a policy. You can limit configuration of the setting by selecting Use
default value. Selecting this option disables configuration of the setting and allows only the
setting's default value to be used when the policy is enforced. This occurs regardless of the
value that was entered before selecting Use default value.
For example, for the Lossy compression level setting, the default value is Medium. When
you add this setting to a policy and select Use default value, medium compression is always
applied to images when the policy is enforced, even if the setting was previously configured
as High or None.
Default values for all Citrix policy settings are located in the Policy Settings Reference.
190
Configuring Policy Settings
Best Practices for Policy Settings
Citrix recommends the following when configuring policy settings:
191
●
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.
To add settings to a policy
Policy settings can be enabled, disabled, or not configured. By default, policy settings are
not configured, meaning they are not added to a policy. Settings can be applied only when
they are added to a policy.
You can add settings to policies using one of the following methods:
●
Using the New Policy wizard, when creating a new policy
●
Using the Settings tab of the Edit Policy dialog box, when modifying an existing policy
●
Using the Settings tab of the AppCenter or Group Policy Management Editor (located
beneath the policies list), when modifying an existing policy
Note: When you modify a policy using the Settings tab on the console, the changes you
make are applied to the policy immediately after you configure the selected setting.
However, when you modify a policy using the Edit Policy dialog box, changes you make
are applied to the policy only after you click OK on the Edit Policy dialog box.
1. Select a setting you want to add to the policy and click Add. The Add Setting dialog
box appears, displaying the setting's default value, if applicable. You can accept or
change this value according to your policy requirements. If no default value is present,
enter the appropriate value for your environment.
2. Click OK to add the setting to the policy. The configured setting appears on the
Settings tab of the console in the Active Settings view.
192
Applying Citrix Policies
When you add a filter to a policy, the policy's settings are applied to connections according
to specific criteria or rules. If no filter is added, the policy is applied to all connections.
You can add as many filters as you want to a policy, based on a combination of criteria. The
availability of certain filters depends on whether you are applying a Computer policy or a
User policy. The following table lists the available filters:
Name
Filter Description
Policy Scope
s Control
Applies a policy based on the access control conditions through
which a client is connecting.
User policies only
h Repeater
Applies a policy based on whether or not a user session was
launched through Citrix Branch Repeater.
User policies only
Applies a policy based on the IP address of the user device used to
connect to the session.
User policies only
IP Address
IPv4 Examples:
●
12.0.0.0
●
12.0.0.*
●
12.0.0.1-12.0.0.70
●
12.0.0.1/24
IPv6 Examples:
Name
izational
or Group
●
2001:0db8:3c4d:0015:0:0:abcd:ef12
●
2001:0db8:3c4d:0015::/54
Applies a policy based on the name of the user device from which
the session is connected.
Applies a policy based on the organizational unit (OU) of the
desktop hosting the session.
User policies only
●
Computer policies
●
User policies
Note: The Organizational Unit filter is applicable o
context of the XenApp farm and is configurable on
AppCenter console. If you manage Citrix policies t
Group Policy Management Editor, this filter is not
Applies a policy based on the user or group membership of the user
connecting to the session.
193
User policies only
er Group
Applying Citrix Policies
Applies 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 Management
Editor to manage Citrix policies, settings you add to the Unfiltered policy are applied to all
farm servers and connections that are within the scope of the Group Policy Objects (GPOs)
that contain the policy. For example, the Sales OU contains a GPO called Sales-US that
includes all members of the US sales team. The Sales-US GPO is configured with an
Unfiltered policy that includes several user policy settings. When the US Sales manager logs
on to the farm, the settings in the Unfiltered policy are automatically applied to the session
because the user is a member of the Sales-US GPO.
If you use the AppCenter console to manage Citrix policies, settings you add to the
Unfiltered policy are applied to all servers and connections in the farm.
Filter Modes
A filter's mode determines whether or not the policy is applied only to connections that
match all the filter criteria. If the mode is set to Allow (the default), the policy is applied
only to connections that match the filter criteria. If the mode is set to Deny, the policy is
applied if the connection does not match the filter criteria. The following examples
illustrate how filter modes affect Citrix policies when multiple filters are present.
Example: Filters of Like Type with Differing Modes
In policies with two filters of the same type, one set to Allow and one set to Deny, the
filter set to Deny takes precedence, provided the connection satisfies both filters. For
example:
Policy 1 includes the following filters:
●
194
Filter A is a User filter that specifies the Sales group and the mode is set to Allow.
Applying Citrix Policies
●
Filter B is a User filter that specifies the Sales manager's account and the mode is set to
Deny.
Because the mode for Filter B is set to Deny, the policy is not applied when the Sales
manager logs on to the farm, even though the user is a member of the Sales group.
Example: Filters of Differing Type with Like Modes
In policies with two or more filters of differing types, set to Allow, the connection must
satisfy at least one filter of each type in order for the policy to be applied. For example:
Policy 2 includes the following filters:
●
Filter C is a User filter that specifies the Sales group and the mode is set to Allow.
●
Filter D is a Client IP Address filter that specifies 12.0.0.* (the corporate network) and
the mode is set to Allow.
When the Sales manager logs on to the farm from the office, the policy is applied because
the connection satisfies both filters.
Policy 3 includes the following filters:
●
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.
195
To add filters to a policy
To apply a policy according to specific criteria, you must add at least one filter. If no filter
is added, the policy applies to all connections.
You can add filters using one of the following methods:
●
Using the New Policy wizard, when creating a new policy
●
Using the Filters tab of the Edit Policy dialog box, when modifying an existing policy
●
Using the Filters tab of the AppCenter or Group Policy Management Editor (located
beneath the policies list), when modifying an existing policy
Note: When you modify filters using the Filters tab on the console, the changes you make
are applied to the policy immediately after you configure the selected filter. However,
when you modify filters using the Edit Policy dialog box, changes you make are applied to
the policy only after you click OK on the Edit Policy dialog box.
1. Select the filter you want to apply and click Add.
2. From the New Filter dialog box, click Add to add the criteria you want XenApp to
evaluate when determining if the policy should be applied.
3. Select the mode for the filter.
4. Leave the Enable this filter element checkbox selected. This allows the filter criteria
to be considered when the policy is evaluated.
5. Click OK to save the filter criteria.
6. Click OK to add the filter to the policy.
Depending on the type of policy created, the policy is applied the next time the server is
rebooted (in the case of a Computer policy) or the next time users log on to the server (in
the case of a User policy). To force an immediate update, open a Command Prompt window
and type gpupdate /force.
196
Managing Multiple Policies
You can use multiple policies to meet users’ needs based on their job functions, geographic
locations, or connection types. For example, compliance with security protocols may
require you to place restrictions on user groups who work regularly with highly sensitive
data. You can create a policy that requires a high level of encryption for sessions and
prevents users from saving sensitive files on their local client drives. However, if some
people in the user group do need access to their local drives, you can create another policy
for only those users. You then rank or prioritize the two policies to control which one takes
precedence in the event of a conflict.
Note: When managing policies through the AppCenter, be aware that making frequent
changes can adversely impact server performance. When you modify a policy, the XenApp
server synchronizes its copy of the farm Group Policy Object (GPO) with the data store,
propagating the change to other servers in the farm. For example, if you make changes to
five policies, the server synchronizes the farm GPO five times. In a large farm with
multiple policies, this frequent synchronization can result in delayed server responses to
user requests. To ensure server performance is not impacted by needed policy changes,
arrange to make these changes during off-peak usage periods.
In general, policies override similar settings configured for the entire server farm, for
specific servers, or on the client. The exception to this principle is security. The highest
encryption setting in your environment, including the operating system and the most
restrictive shadowing setting, always overrides other settings and policies.
Citrix policies interact with policies you set in your operating system. In a XenApp
environment, Citrix settings override the same settings configured in an Active Directory
policy or using Remote Desktop Session Host Configuration. This includes settings that are
related to typical Remote Desktop Protocol (RDP) client connection settings such as Desktop
wallpaper, Menu animation, and View window contents while dragging. For some policy
settings, such as Secure ICA, the settings in policies must match the settings in the
operating system. If a higher priority encryption level is set elsewhere, the Secure ICA
policy settings that you specify in the policy or when you are publishing an application can
be overridden.
For example, the encryption settings that you specify when you are publishing an
application should be at the same level as the encryption settings you specified throughout
your environment.
197
Prioritizing Policies and Creating
Exceptions
Prioritizing policies allows you to define the precedence of policies when they contain
conflicting settings. The process XenApp uses to evaluate policies is as follows:
1. When a user logs on, all policies that match the filters for the connection are
identified.
2. XenApp sorts the identified policies into priority order and compares multiple instances
of any setting, applying the setting according to the priority ranking of the policy.
You prioritize policies by giving them different priority numbers. By default, new policies
are given the lowest priority. If policy settings conflict, a policy with a higher priority (a
priority number of 1 is the highest) overrides a policy with a lower priority. Settings are
merged according to priority and whether the setting is disabled or enabled. Any disabled
setting overrides a lower-ranked setting that is enabled.
When you create policies for groups of users, client devices, or servers, you may find that
some members of the group require exceptions to some policy settings. You can create
exceptions by:
●
Creating a policy only for those group members who need the exceptions and then
ranking the policy higher than the policy for the entire group
●
Using the Deny mode of a filter added to the policy
A filter with the mode set to Deny tells XenApp to apply the policy to connections that do
not match the filter criteria. For example, a policy contains the following filters:
●
Filter A is a Client IP address filter that specifies the range 12.0.0.* and the mode is set
to Allow.
●
Filter B is a User filter that specifies a particular user account and the mode is set to
Deny.
The policy is applied to all users who log on to the farm with IP addresses in the range
specified in Filter A. However, the policy is not applied to the user logging on to the farm
with the user account specified in Filter B, even though the user's computer is assigned an
IP address in the range specified in Filter A.
198
Prioritizing Policies and Creating Exceptions
To change the priority of a policy
1. From the console tree, choose to view Citrix Computer Policies or Citrix User Policies.
2. From the middle pane, select the policy you want to prioritize.
3. Click Increase Priority or Decrease Priority as appropriate until the policy has the
preferred rank.
199
Determining Which Policies Apply to a
Connection
Sometimes a connection does not respond as expected because multiple policies apply. If a
higher priority policy also applies to a connection, it can override the settings you configure
in the original policy. You can determine how final policy settings are merged for a
connection by calculating the Resultant Set of Policy.
You can calculate the Resultant Set of Policy in the following ways:
●
Use the Citrix Policy Modeling Wizard to simulate a connection scenario and discern
how Citrix policies might be applied
●
Use Group Policy Results to produce a report describing the Citrix policies in effect for
a given user and server.
You can launch both tools from the Group Policy Management console in Windows. If your
XenApp environment does not include Active Directory, you can launch the Citrix Group
Policy Modeling Wizard from the Actions pane of the AppCenter.
Using the Citrix Policy Modeling Wizard
With the Citrix Group Policy Modeling Wizard, you can specify conditions for a connection
scenario such as domain controller, users, Citrix policy filter evidence values, and simulated
environment settings such as slow network connection. The report that the wizard produces
lists the Citrix policies that would likely take effect in the scenario.
If you are logged on to the server as a domain user and your environment includes Active
Directory, the wizard calculates the resultant set of policy by including settings from Active
Directory Group Policy Objects (GPOs). If you run the wizard from the AppCenter, the farm
GPO residing on the server is included in this calculation as well. However, if you are logged
on to the server as a local user and run the wizard from the AppCenter, the wizard
calculates the Resultant Set of Policy using only the farm GPO.
Using Group Policy Results
The Group Policy Results tool helps you evaluate the current state of GPOs in your
environment and generates a report that describes how these objects, including Citrix
policies, are currently being applied to a particular user and server.
200
Determining Which Policies Apply to a Connection
Troubleshooting Policies
Users, IP addresses, and other filtered objects can have multiple policies that apply
simultaneously. This can result in conflicts where a policy may not behave as expected.
When you run the Citrix Group Policy Modeling Wizard or the Group Policy Results tool, you
might discover that no policies are applied to user connections. When this happens, users
connecting to their applications under conditions that match the policy evaluation criteria
are not affected by any policy settings. This occurs when:
●
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:
201
●
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
To simulate connection scenarios with
Citrix policies
1. Depending on your XenApp environment, open the Citrix Group Policy Modeling Wizard:
●
From the AppCenter, click the Policies node, and then click Run the modeling
wizard from the Actions pane.
From the Group Policy Management console, right-click the Citrix Group Policy
Modeling node in the console tree and then select Citrix Group Policy Modeling
Wizard.
2. Follow the wizard to select the domain controller, users, computers, environment
settings, and Citrix filter criteria you want to use in the simulation.
●
When you click Finish, the wizard produces a report of the modeling results. In the
AppCenter, the report appears as a node in the AppCenter tree, underneath the Policies
node. The Modeling Results tab in the middle pane displays the report, grouping effective
Citrix policy settings under User Configuration and Computer Configuration headings.
202
Applying Policies to Access Gateway
Connections
You can create a policy that is applied to Access Gateway connections or to Access Gateway
connections with certain properties.
You can create Citrix policies to accommodate different access scenarios based on factors
such as authentication strength, logon point, and client device information such as endpoint
analysis. You can selectively enable client-side drive mapping, cut and paste functionality,
and local printing based on the logon point used to access the published application.
Prerequisites for Filtering on Access Gateway
Connections
For Citrix XenApp to filter on Access Gateway connections, you must complete all of the
following:
●
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.
203
●
For published applications, select Allow connections made through Access Gateway
Advanced Edition in the application properties.
●
Ensure that your farm is configured to allow Access Gateway connections, which it is by
default.
●
Create a Computer policy within XenApp that has the Trust XML requests policy setting
enabled.
●
Create a User policy within XenApp that includes a filter referencing Access Gateway
filters.
Applying Policies to Access Gateway Connections
To apply a policy filter based on Access Gateway
connections
1. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node in the left pane and then select the
User tab in the middle pane.
From the Group Policy Management Editor, under User Configuration in the left
pane, select the Citrix Policies node.
2. Select an existing User policy or create a new User policy.
●
3. Follow the policy wizard to the filters page or click the Filters tab in the middle pane
of the console.
4. Select Access Control and then click Add.
5. Click Add to configure the filter.
6. Select With Access Gateway.
7. To apply the policy to connections made through Citrix Access Gateway without
considering Access Gateway policies, accept the default entries in the AG farm name
and Access condition fields.
8. To apply the policy to connections made through Citrix Access Gateway based on
existing Access Gateway policies, perform the following actions:
a. In AG farm name, enter one of the following items:
●
If using Access Gateway Advanced Edition, enter the name of the Access
Gateway farm.
If using Access Gateway Enterprise Edition, enter the virtual server name of the
Access Gateway appliance.
b. In Access condition, enter one of the following items:
●
●
If using Access Gateway Advanced Edition, enter the name of the Access
Gateway filter for XenApp to use.
●
If using Access Gateway Enterprise Edition, enter the name of the endpoint
session policy for XenApp to use.
Important: XenApp does not validate Access Gateway farm, server, and filter
names, so always verify this information with the Access Gateway administrator.
9. To apply the policy to every connection except those made through Access Gateway, in
the Mode list box, select Deny. The filter's mode tells XenApp whether or not to apply
the policy to connections that match the filter criteria. Selecting Deny tells XenApp to
apply the policy to connections that do not match the filter criteria.
204
Enabling Scanners and Other TWAIN
Devices
XenApp lets users control client-attached TWAIN imaging devices, such as scanners and
cameras, from published applications. This feature is known as TWAIN redirection because
XenApp provides TWAIN support by redirecting commands sent from a published application
on the server to the client device.
Users can connect regardless of connection type. However, XenApp requires the following
for TWAIN support:
●
The imaging device must be connected locally to the user device and have the
associated vendor-supplied TWAIN driver installed locally.
●
Citrix Receiver 3.0, Citrix Online Plug-in 11.x or later, or the Citrix Offline Plug-in.
●
XenApp 32-bit and 64-bit servers support TWAIN redirection for 32-bit TWAIN
applications only. XenApp does not support 16-bit TWAIN drivers.
●
The Client TWAIN device redirection policy setting must be added to the appropriate
policy. To configure image compression, add the TWAIN compression level setting and
select the appropriate compression level.
The following table lists the TWAIN hardware and software tested with XenApp. While other
TWAIN devices may work, only those listed are supported.
Scanners and Scanning
Devices
Canon CanoScan 3200F
Canon CanoScan 8000F
Canon CanoScan LiDE600F
Fujitsu fi-6140
Fujitsu ScanSnap 9510
HP ScanJet 8250
IRIScan Express 2
Software
Microsoft Office Publisher 2007
Microsoft Office Word 2007 Clip Organizer
OmniPage SE
Consider the following after enabling TWAIN redirection:
●
205
Configure bandwidth limits for image transfers. You can add the TWAIN device
redirection bandwidth limit or the TWAIN device redirection bandwidth limit
percent settings to the policy and enter the appropriate values denoting the maximum
bandwidth allowed for image transfers.
Enabling Scanners and Other TWAIN Devices
●
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-based 32-bit application: 0x00000008
Return system \Windows directory instead of user \Windows directory for
GetWindowsDir: 0x00000400
For more information about using compatibility flags, see the article "Program
compatibility flags" on the Microsoft TechNet Web site at
http://technet.microsoft.com.
●
●
This feature supports the following modes of TWAIN information transfer:
●
Native
●
Buffered Memory (most scanning software works by default in Buffered Memory
mode)
Note: The disk file transfer mode is not supported.
206
Managing Session Environments and
Connections
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 session refers to a particular
instance of a user’s activity on the 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 client connection. Users access
published resources through client connections, inside of sessions.
As an administrator, you can customize users’ environments, including whether or not users
can access mapped drives, such as the local client 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.
207
Managing Session Environments and Connections
XenApp provides settings to ensure sessions remain reliable. You can also monitor users’
sessions, and their sessions’ status, by shadowing.
208
Defining User Environments in XenApp
XenApp provides different ways to control what users experience in their session
environments. You can customize user environments in the following ways:
●
By suppressing the number of progress bars users see when they first open an
application, so that XenApp appears to be an integrated part of their everyday
environment.
●
By either allowing or preventing users from accessing their local devices or ports during
a session. You can also prevent users from accessing devices and ports during remote
sessions.
●
By defining whether or not users can hear audio or use microphones during sessions. If
you enable audio support, you can specify the level of audio compression and limit
bandwidth, if necessary. You can control audio either at the group level through
policies or at the published application level.
●
By ensuring that mobile workers, such as travelling salespeople or workers inside a
hospital, always have the most appropriate printers and devices available to them
inside of a session.
For the Citrix Receiver, you can also customize the 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 Receiver and the Web Interface documentation.
209
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 local group
policies on servers. Therefore, when you install XenApp on servers that belong to an Active
Directory domain, those Active Directory policies may prevent XenApp from suppressing the
status screens generated by the Windows operating systems of the individual servers. In
that case, users see the status screens generated by the Windows operating system when
connecting to that server. For optimal performance, do not configure these group policies
in Active Directory.
210
Controlling Access to Devices and Ports
Citrix Receiver supports mapping devices on client computers so users can access the
devices within sessions. Client device mapping provides:
●
Access to local drives and ports
●
Cut-and-paste data transfer between a session and the local clipboard
●
Audio (system sounds and .wav files) playback from the session
During logon, Receiver reports the available client drives and COM ports to the server. By
default, client drives appear as network resources so the drives appear to be directly
connected to the server. The client drives are displayed with descriptive names so they are
easy to locate among other network resources. These drives are used by Windows Explorer
and other applications like any other network drive.
In Citrix policies, redirection settings are used for mapping.
Redirecting Client COM Ports and Audio
Client COM port redirection allows a remote application running on the server to access
devices attached to COM ports on the user device. COM port and audio redirection are
configured with the Client COM port redirection and Client audio redirection User policy
settings.
For more information, see the Receiver documentation.
211
To enable user execute permissions on
mapped drives
In general, XenApp displays client drive letters as they appear on the user device; for
example, the user device's hard disk drive appears as "C: on ClientName," where
ClientName is the name of the user device. This allows the user to access client drive
letters in the same way locally and within sessions.
You can turn off client drive redirection through XenApp policies. In doing so, you also turn
off mapping to client floppy disk drives, hard drive, CD-ROM drives, or remote drives
regardless of the policy settings for those individual devices.
As a security precaution, when a user logs on to XenApp, by default, the server maps client
drives without user execute permission. To enable users to execute files residing on
mapped client drives, override this default by editing the registry on a XenApp server.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
1. After installing XenApp, open the Registry Editor.
2. Find the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\picadm\Parameters\ExecuteFromMappedDrive
3. To grant users execute permission on mapped drives, set ExecuteFromMappedDrive to 1.
4. To deny users execute permission on mapped drives, set ExecuteFromMappedDrive to 0.
5. Restart the server.
212
Displaying Local Special Folders in
Sessions
To make it easier for your users to save files to their special folders locally, you can enable
Special Folder Redirection. Special folders is a Microsoft term that refers to Windows
folders such as Documents, Computer, and the Desktop.
Without Special Folder Redirection enabled, the Documents and Desktop icons that appear
in a session point to the user’s Documents and Desktop folders on the server. Special Folder
Redirection redirects actions, such as opening or saving a file, so that when users save or
open files from special folders, they are accessing the special folder on their local
computers. In addition, for the Citrix Receiver, the Documents folder in the Start menu
maps to the Documents folder on the client device.
To use Special Folder Redirection, users must access the farm with the Citrix online plug-in
11.x or later or the Web Interface.
Restrictions
Do not enable Special Folders Redirection in situations when a user connects to the same
session from multiple client devices simultaneously. For Special Folder Redirection to work,
the user must log off from the session on the first client device and start a new session on
the second client device. If users must run multiple sessions simultaneously, use roaming
profiles or set a home folder for that user in the User Properties in Active Directory.
Because Special Folder Redirection must interact with the client device, some settings
prevent Special Folder Redirection from working. You cannot have policy settings that
prevent users from accessing or saving to their local hard drives.
Currently, for seamless and published desktops, Special Folder Redirection works only for
the Documents folder. For seamless applications, Special Folder Redirection only works for
the Desktop and Documents folders. Citrix does not recommend using Special Folder
Redirection with published Windows Explorer.
Special Folder Redirection requires access to the Documents and Desktop folders on the
user’s local computer. When a user launches an application through the Web Interface and
uses File Security to select No Access in the File Security dialog box in Connection Center,
access is denied to the user’s local 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 server hosting the published application. In
large environments where many servers host the same application, it could be difficult to
213
Displaying Local Special Folders in Sessions
determine which server contains the public folder where the user saved the document.
To enable Special Folder Redirection
Special Folder Redirection support is enabled by default, but you must provide this feature
to users through the Citrix Receiver and Web Interface. You can either enable Special
Folder Redirection for all users or configure that users must enable the feature themselves
in their client settings.
You can allow or prevent specific users from having redirected special folders with the
Special folders redirection policy setting.
1. Enable the Special Folder Redirection policy setting and apply filters to ensure the
setting is applied to the users you want accessing local special folders.
To prevent local special folders from being redirected, ensure a filter is configured that
targets the users you do not want accessing local special folders.
2. Decide if you want to let users turn this feature on and off in their sessions.
Instructions for users are provided in their plug-in help.
3. Ensure you do not have any policy settings enabled that are not supported with Special
Folder Redirection (such as preventing accessing or writing to local hard drives).
If you enable Special Folder Redirection without success, use Search to determine if any
settings conflict with this feature.
Tip: Let your users know that other Special Folders, such as Music or Recent Documents,
still point to the server. If users save documents to these folders, they are saved to the
server.
To enable Special Folder Redirection for Web
Interface
This procedure requires that you already created a XenApp Web site.
1. From the AppCenter, select Citrix Resources > Configuration Tools > Web Interface >
XenApp Web Site Name.
2. From the Action menu, choose Manage session preferences.
3. In the Managing Session Preferences page, select Remote Connection > Local
Resources.
4. Select the correct options.
To
214
Select the options
Displaying Local Special Folders in Sessions
Enable Special Folder Redirection by
default and let users turn it off in their
session options.
Provide Special Folder Redirection to all
users
Allow users to customize Special Folder
Redirection
Disable Special Folder Redirection by
default, but let users turn it on in their
session options
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 Citrix
Receiver
This procedure requires that you already created a XenApp Services site.
1. From the AppCenter, select Citrix Resources > Configuration Tools > Web Interface >
XenApp Services Site Name > config.xml.
2. From the Action menu, choose Change session options.
3. In the Change Session Options page, select Remote Connection > Local Resources.
4. Select the correct options.
To
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
215
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
Configuring Audio for User Sessions
XenApp provides tools to manage and control the availability of sound in sessions, both in
terms of quality and cost in resources, including:
●
Audio properties you configure for individual published applications
●
Audio related 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.
216
To enable or disable audio for published
applications
If you disable audio for a published application, audio is not available within the application
under any condition. If you enable audio for an application, you can use policy settings and
filters to further define under what conditions audio is available within the application.
1. In the AppCenter, select the published application for which you want to enable or
disable audio, and select Action > Application properties.
2. In the Application Properties dialog box, click Advanced > Client options. Select or
clear the Enable legacy audio check box.
217
To configure bandwidth limits for audio
Use policy settings to configure the amount of bandwidth you want to allocate to audio
transfers between servers and client devices. For example, you might want to create
separate policy settings for groups of dial-up users and for those who connect over a LAN,
accommodating the different amounts of bandwidth each group will have available.
In this procedure, you are editing settings for a policy that applies to a specific group of
filtered objects, such as servers or users.
1. Configure the following Citrix User policy settings:
218
●
Audio redirection bandwidth limit. Specify the bandwidth available for audio in
kilobits per second.
●
Audio redirection bandwidth limit percent. Limit the bandwidth available for
audio to a percentage of the overall bandwidth available. If you configure this
setting, you must enable the Overall session bandwidth limit setting.
To configure audio compression and
output quality
Use Citrix policy settings to configure the compression levels to apply to sound files.
Generally, higher sound quality requires more bandwidth and higher server CPU utilization.
You can use sound compression to balance sound quality and overall session performance.
Consider creating separate policies for groups of dial-up users and for those who connect
over a LAN. Over dial-up connections, where bandwidth typically is limited, users likely
care more about download speed than sound quality. For such users, create a policy for
dial-up connections that applies high compression levels to sound and another for LAN
connections that applies lower compression levels.
In this procedure, you are editing settings for a policy that applies to a specific group of
filtered objects, such as servers or users.
1. Configure the Audio quality Citrix User policy setting with one of the following options:
219
●
Low - for low-speed connections. This causes any sounds sent to the client device
to be compressed to a maximum of 16Kbps. This compression results in a significant
decrease in the quality of the sound. The CPU requirements and benefits of this
setting are similar to those of the Medium setting; however, the lower data rate
allows reasonable performance for a low-bandwidth connection.
●
Medium - optimized for speech. This is recommended for most LAN-based
connections. This setting causes any sounds sent to the client device to be
compressed to a maximum of 64Kbps. This compression results in a moderate
decrease in the quality of the sound played on the client device.
●
High - high definition audio. This is recommended for connections where
bandwidth is plentiful and sound quality is important. This setting allows client
devices to play a sound file at its native data rate. Sounds at the highest quality
level require about 1.3Mbps of bandwidth to play clearly. Transmitting this amount
of data can increase bandwidth requirements, and result in increased CPU
utilization and network congestion.
To enable support for microphones and
speakers
For users to use speaker and microphones in sessions, both audio input (for microphones)
and output (for speakers) must be enabled. Audio input and output are controlled by two
policy settings; you must configure both to ensure that audio input and output are enabled.
Note: Microphone input is supported on the Citrix Receiver for Windows, and the
Windows CE and Linux plug-ins.
This allows you to implement separate connection policies; for example, for users of mobile
devices and for users who connect over a LAN. For the mobile user group, you may want to
enable audio input but disable audio output. This lets mobile users record notes from the
field, but prevents the server from sending audio to the mobile devices, ensuring better
session performance. Enabling audio input and output also enables support for digital
dictation.
On the client device, users control audio input and output in a single step—by selecting an
audio quality level from the Options > Session Options dialog box.
By default, when you configure these settings, audio input is enabled on client devices.
Web Interface users can override the policy and disable their microphones by selecting No
in the Audio Security dialog box, which they access from the Citrix Connection Center.
In this procedure, you are editing settings for a policy that applies to a specific group of
filtered objects, such as servers or users.
1. To enable audio input for sessions, configure the Client microphone redirection Citrix
User policy setting.
2. To enable audio output for sessions, configure the Client audio redirection Citrix User
policy setting.
220
To use and set sound quality for digital
dictation devices
If you have enabled microphone and speaker support, XenApp requires no additional
configuration to allow users to record audio using a standard microphone. However, to
allow users to use digital dictation devices such as Philips SpeechMike devices and dictation
software such as WinScribe Internet Author and Internet Typist, you must install and
configure the associated software and set session sound quality to accommodate them.
To enable Phillips SpeechMike devices, go to the Philips web site for information and
software downloads.
Note: The Citrix plug-ins for Linux and Windows CE do not support Philips SpeechMike
products.
To make Philips SpeechMike devices or similar products available in user sessions, install
the device drivers associated with the products on the XenApp server and on client devices.
To make dictation software such as WinScribe Internet Author and Internet Typist available,
install this software on the XenApp server. After installation, you might be required to
enable the controls for the dictation device within the dictation software. Refer to the
product documentation for instructions.
Set sound quality to at least medium quality. To enable the use of Philips SpeechMagic
Speech Recognition server with WinScribe software, set sound quality to high to enable
accurate speech-to-text translation.
1. From Citrix Web Interface Management, select the XenApp Services site you want to
configure.
2. In the Action pane, select Session Options.
3. Select Color and Sound.
4. In the Sound area, select one of:
221
●
Medium - optimized for speech
●
High - high definition audio
Ensuring Session Continuity for Mobile
Workers
The Workspace Control feature provides users with the ability to disconnect quickly from all
running applications, to reconnect to applications, or to log off from all running
applications. Workspace Control enables users to move among client devices and gain
access to all of their open applications when they log on.
For example, you can use Workspace Control to assist health-care workers in a hospital who
need to move quickly between workstations and access the same set of applications each
time they log on to XenApp. If you configure Workspace Control options to allow it, these
workers can disconnect from multiple applications at one client device and then reconnect
to open the same applications at a different client device.
For users accessing applications through the Web Interface or Citrix Receiver, you can
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 Citrix Receiver.
User policies, client drive mappings, and printer configurations change appropriately when
a user moves to a new client device. Policies and mappings are applied according to the
client device where the user is currently logged on to the session. For example, if a health
care worker logs off from a client device in the emergency room of a hospital and then logs
on to a workstation in the 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.
222
Ensuring Session Continuity for Mobile Workers
You can customize what printers appear to users when they change locations as well as
control whether they can print to local printers, how much bandwidth is consumed when
users connect remotely, and other aspects of their printing experiences.
For more information about enabling and configuring Workspace Control for users, see the
Web Interface documentation.
223
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.
224
●
Session Reliability
●
Auto Client Reconnect
●
ICA Keep-Alive
Configuring Session Reliability
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.
Citrix Receiver users cannot override the server setting.
Note: You can use Session Reliability with Secure Sockets Layer (SSL).
By default, Session Reliability is enabled through policy settings. You can customize the
policy settings for this feature as appropriate. You can edit the port on which XenApp
listens for session reliability traffic and edit the amount of time Session Reliability keeps an
interrupted session connected.
The Citrix Computer policy Session reliability connections setting allows or prevents
session reliability.
The Session reliability timeout setting has a default of 180 seconds, or three minutes.
Though you can extend the amount of time Session Reliability keeps a session open, this
feature is designed to be convenient to the user and it does not, therefore, prompt the user
for reauthentication. If you extend the amount of time a session is kept open
indiscriminately, chances increase that a user may get distracted and walk away from the
client device, potentially leaving the session accessible to unauthorized users.
Incoming session reliability connections use port 2598, unless you change the port number
with the Citrix Computer policy Session reliability port number setting.
If you do not want users to be able to reconnect to interrupted sessions without having to
reauthenticate, use the Auto Client Reconnect feature. You can configure the Citrix
Computer policy Auto client reconnect authentication setting to prompt users to
reauthenticate when reconnecting to interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in
sequence. Session Reliability closes, or disconnects, the user session after the amount of
time you specify in the Citrix Computer policySession reliability timeout setting. After
that, the Auto Client Reconnect policy settings take effect, attempting to reconnect the
user to the disconnected session.
225
Configuring Automatic Client
Reconnection
The Auto Client Reconnect feature allows Citrix Receiver for Windows and plug-ins for Java
and Windows CE to detect broken connections and automatically reconnect users to
disconnected sessions. When Receiver or a plug-in detects an involuntary disconnection of a
session, it attempts to reconnect the user to the session until there is a successful
reconnection or the user cancels the reconnection attempts.
When a connection breaks, it may leave the server session in an active state. Users can
reconnect only to sessions that are in a disconnected, or inactive, state. Cookies containing
keys to user credentials and session IDs are created on the client device when sessions are
started. Because users can be reconnected only to disconnected sessions, Auto Client
Reconnect uses the cookie on the client device to disconnect an active session before
attempting to reconnect.
Configure Auto Client Reconnect with the following Citrix Computer policy settings:
●
Auto client reconnect. Enables or disables automatic reconnection by the same client
after a connection has been interrupted.
●
Auto client reconnect authentication. Enables or disables the requirement for user
authentication upon automatic reconnection
●
Auto client reconnect logging. Enables or disables logging of reconnection events in
the event log. Logging is disabled by default. When enabled, the server's System log
captures information about successful and failed automatic reconnection events. Each
server stores information about reconnection events in its own System log; the server
farm does not provide a combined log of reconnection events for all servers.
Auto Client Reconnect incorporates an authentication mechanism based on encrypted user
credentials. When a user initially logs on to a server farm, XenApp encrypts and stores the
user credentials in memory, and creates and sends a cookie containing the encryption key
to Receiver or the plug-in. Receiver or the plug-in submits the key to the server for
reconnection. The server decrypts the credentials and submits them to Windows logon for
authentication. When cookies expire, users must reauthenticate to reconnect to sessions.
Cookies are not used if you enable the Auto client reconnection authentication setting.
Instead, XenApp displays a dialog box to users requesting credentials when Receiver or the
plug-in attempts to reconnect automatically.
Note: For maximum protection of users’ credentials and sessions, use SSL encryption for
all communication between clients and the server farm.
Disable Auto Client Reconnect on Citrix Receiver for Windows by using the icaclient.adm
file. For more information, see the Citrix Receiver or plug-in documentation.
Settings for connections also affect Auto Client Reconnect.
226
Configuring Automatic Client Reconnection
Configuring Connections for Automatic Client
Reconnection
By default, Auto Client Reconnect is enabled through policy settings on the farm level. User
reauthentication is not required. However, if a server’s ICA TCP connection is configured to
reset sessions with a broken communication link, automatic reconnection does not occur.
Auto Client Reconnect works only if the server disconnects sessions when there is a broken
or timed out connection.
In this context, the ICA TCP connection refers to a XenApp’s virtual port (rather than an
actual network connection) that is used for sessions on TCP/IP networks.
By default, the ICA TCP connection on a XenApp server is set to disconnect sessions with
broken or timed out connections. Disconnected sessions remain intact in system memory
and are available for reconnection by Receiver.
The connection can be configured to reset, or log off, sessions with broken or timed out
connections. When a session is reset, attempting to reconnect initiates a new session;
rather than restoring a user to the same place in the application in use, the application is
restarted.
If XenApp is configured to reset sessions, Auto Client Reconnect creates a new session. This
process requires users to enter their credentials to log on to the server.
Automatic reconnection can fail if Receiver or the plug-in submits incorrect authentication
information, which might occur during an attack or the server determines that too much
time has elapsed since it detected the broken connection.
227
Configuring ICA Keep-Alive
Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected.
When enabled, if XenApp detects no activity (for example, no clock change, no mouse
movement, no screen updates), this feature prevents Remote Desktop Services from
disconnecting that session. XenApp sends keep-alive packets every few seconds to detect if
the session is active. If the session is no longer active, XenApp marks the session as
disconnected.
However, the ICA Keep-Alive feature does not work if you are using Session Reliability.
Session Reliability has its own mechanisms to handle this issue. Only configure ICA
Keep-Alive for connections that do not use Session Reliability.
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.
1. Configure the following Citrix Computer policy settings:
●
ICA keep alive timeout. Specifies the interval (1-3600 seconds) used to send ICA
keep-alive messages. Do not configure this option if you want your network
monitoring software to close inactive connections in environments where broken
connections are so infrequent that allowing users to reconnect to sessions is not a
concern.
The 60 second default interval causes ICA Keep-Alive packets to be sent to client
devices every 60 seconds. If a client device does not respond in 60 seconds, the
status of the ICA sessions changes to disconnected.
●
228
ICA keep alives. Sends or prevents sending ICA keep-alive messages periodically.
Session Linger
A user session ends after user processes and visible windows end (for example, when a user
exits from an application, the session ends). You can use session linger to provide a better
user experience by eliminating the launch delay between applications.
To use session linger for named user sessions, configure the following Citrix User policy
settings:
●
Linger Terminate Timer Interval specifies the number of minutes a session remains
active after the last application terminates. If a new application starts during this
interval, the user session returns to the active monitoring state. If no application starts
during this interval, the session ends.
If this policy setting is not used, session linger is disabled.
●
Linger Disconnect Timer Interval specifies the number of minutes to wait after
lingering begins before disconnecting the session. If a new application starts during this
interval, the user session returns to the active monitoring state. It is possible that other
factors may cause a session to be disconnected before the Linger Disconnect Timer
Interval expires.
If this policy setting is not used, a lingering session will not disconnect.
Anonymous user sessions do not have a disconnected state; they are either active or
terminated. Therefore, if the Linger Terminate Timer Interval and Linger Disconnect Timer
Interval policy settings are used, the effective Linger Terminate Timer Interval setting is
the same as the Linger Disconnect Timer Interval setting.
For a non-seamless named user session, the disconnected session remains in the
disconnected state until the Linger Terminate Timer Interval expires.
229
Managing and Monitoring XenApp
Sessions
You can interact directly with sessions by resetting, disconnecting or logging off sessions, or
sending messages to users. You can monitor sessions through AppCenter displays or directly
through shadowing.
Disconnecting and Resetting Sessions
A disconnected session is still active and its applications continue to run, but the client
device is no longer communicating with the server. A user can reconnect to a disconnected
session from a different client device without loss of data. For example, you might
disconnect users’ sessions if they experience problems on their client device and do not
want to lose data from their applications.
When you disconnect a session, you close the connection between the client device and the
server. However, this does not log off the user, and programs that were running in the
session are still running on the server. (Some applications that rely on virtual channels, such
as media players, may behave differently. For example, if you disconnect from a session
running Media Player while playing audio, the audio stops playing because the audio virtual
channel is no longer available.) When a session is disconnected, session state displays
indicate Disconnected. If the client user then connects to the server (by selecting a
published application or custom connection to the server), the disconnected session is
reconnected.
You can log off users from their sessions. You can also reset a user’s client session or a
disconnected session.
You can also connect to a user’s disconnected session when you are using the AppCenter
from within a client session on a XenApp server. To connect, you must know the password
of the user who started the session. Your session must support the same video resolution as
the disconnected session.
Resetting a session terminates all processes that are running in that session. You can reset a
session to remove remaining processes in the case of a session error; however, resetting a
session can cause applications to close without saving data.
When you reset a disconnected session, session state displays indicate Down. When you
refresh the AppCenter display or when the next automatic refresh occurs, the session no
longer appears in the list of sessions.
Special sessions that listen for requests to connect to the server indicate Listening in
session state displays. If you reset a listener session, the server resets all sessions that use
the protocol associated with the listener. For example, if you reset the ICA listener session,
you reset the ICA sessions of all users connected to the server.
230
Managing and Monitoring XenApp Sessions
To use session controls
From the AppCenter:
●
To reset a session:
Caution: Resetting effectively deletes the session and results in loss of data for the
user. Only reset a session when it malfunctions or is not responding.
1. Select the server to which the user is connected.
2. In the results pane, click the Sessions tab.
3. Select the session you want to reset. (You can select one or more sessions.)
●
4. In the Actions pane, select Reset.
To disconnect a session:
1. Select the server to which the user is connected.
2. In the results pane, click the Sessions tab.
3. Select the session you want to reset. (You can select one or more sessions.)
●
4. In the Actions pane, select Disconnect.
To logoff from a session:
Caution: Ending user sessions using Logoff can result in loss of data if users do not
close their applications first. Before initiating the logoff, send a message to warn
users to exit all applications.
1. Select the server to which the user is connected.
2. In the results pane, click the Sessions tab.
3. Select the session you want to log off. (You can select one or more sessions.)
●
4. In the Actions pane, select Log off. Confirm the logoff when prompted.
To terminate processes in a user session:
Caution: Terminating a process may abruptly end a critical process and leave the
server in an unusable state.
1. Select the server to which the user is connected.
2. In the results pane, click the Users tab and select the session for which you want to
terminate a process.
3. In the lower portion of the results pane, click the Processes tab and select the
process you want to terminate.
4. In the Actions pane, select Terminate.
231
Managing and Monitoring XenApp Sessions
To send a message to one or more users from the
AppCenter
Sending a message that appears in user sessions can be helpful in situations such as
broadcasting information about new applications and upgrades, requesting a shadowing
session, or warning of a logoff or system shutdown.
1. From the AppCenter, select the server to which the users are connected. To send a
message to all user sessions in the farm, select a farm node instead of a server.
2. In the results pane, click the Users tab and select one or more sessions.
3. In the Actions pane, select Send Message. The Send Message dialog box appears.
4. Edit the title of the message, if required, and enter the message text.
232
Monitoring Session Information
1. From the AppCenter, select the server on which you want to monitor sessions.
2. In the results pane, click the Sessions tab. The display lists all sessions running on the
server.
By default, the upper portion of the results pane includes the following information for
all sessions (click Choose columns to specify which columns to display and the display
order):
Field
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.
3. Select a session. Depending on the session you select:
233
●
Tasks become available in the Actions pane; these can include Reset, Log off,
Disconnect, and Send Message.
●
The lower portion of the results pane displays tabs containing additional
information: Information, Client Cache, Session Information, Client Modules, and
Processes.
Viewing User Sessions
You can view another user’s session on another device by using shadowing. When
shadowing, you can monitor the session activity as if you are watching the screen of the
client device that initiated the session. If configured, you can also use your keyboard and
mouse to control the 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 AppCenter or the Shadow Taskbar.
You enable shadowing on a server when you configure XenApp and select the default
option, which allows shadowing on all connections on the server. If you do not leave the
shadowing option enabled during configuration, you must reinstall XenApp to get shadowing
functionality.
By default, the user is notified of the pending shadowing and asked to allow or deny
shadowing.
Important: Your client device and shadowing ICA session must support the video
resolution of the 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 Session Host Configuration tool.
234
Viewing User Sessions with the Shadow
Taskbar
Use the Shadow Taskbar to shadow multiple ICA sessions from a single location, including
the server console. Use the Shadow button to start shadowing one or more users. The
Shadow Taskbar uses the client to launch an ICA session to monitor a user. A separate ICA
session is started for each shadowed user.
You must enter your user name and password to start an ICA session on the server running
the Shadow Taskbar.
Note the following:
●
The client uses a license to log on to the server and start shadowing a user.
●
The Shadow Taskbar shows sessions on the server or domain you logged on to. You can
view servers in a different domain by logging on to an account in that domain and
restarting the Shadow Taskbar.
●
Each shadow session consumes memory on the server, so limit the number of
simultaneous shadow sessions.
Each shadowed session is represented by a task button on the Shadow Taskbar. Use this
button to switch quickly between the shadowing sessions you have open.
To start the Shadow Taskbar
1. From the Start menu, choose All Programs > Citrix > Administration Tools > Shadow
Taskbar.
2. To configure shadowing options, right-click an empty area of the Shadow Taskbar or
press SHIFT + F10. To switch to a shadow session, click its button in the Shadow
Taskbar.
To close the Shadow Taskbar, right-click an empty area of the Shadow Taskbar and select
Exit.
235
Viewing User Sessions with the Shadow Taskbar
To select users and initiate shadowing
1. On the Shadow Taskbar, click the Shadow button. The Shadow Session dialog box
appears.
●
The Available Users list shows user sessions that can be selected for shadowing in
the current domain. User sessions are organized by servers, published applications,
and users. You can shadow only client user sessions.
The Shadowed Users list shows user sessions selected for shadowing and existing
shadow sessions; it also displays the user name of currently shadowed users next to
the shadow icon.
2. In the Available Users list, select one or more users to shadow and click Add. The
selected users move to the Shadowed Users list. Shadowing is initiated for all users in
the Shadowed Users list when you click OK.
●
To end a shadowing session
1. On the Shadow Taskbar, click the Shadow button. The Shadow Session dialog box
appears.
2. In the Shadowed Users list, select the users to stop shadowing and click Remove.
Tip: You can end a shadow session by right-clicking the session’s task button on the
Shadow Taskbar and clicking Stop Shadow. You can end all shadow sessions by
right-clicking the Shadow Taskbar and clicking Stop All Shadowed Sessions.
236
Enabling Logging for Shadowing
After configuring XenApp, you can enable shadow logging and configure shadow logging
output to one of two locations on the server:
●
In a central file. Configuring this option records a limited number of logging events,
such as when and who started a shadowing session and who is being shadowed. When
you configure shadow logging through the Shadow Taskbar, the logged events are not
recorded in the Windows Event log. Instead, they go to a file that you specify.
●
In the Windows Event log. Configuring this option logs several different event types in
the Application log of the Windows Event log. These include user shadowing requests,
such as when users stop shadowing, failure to launch shadowing, and access to
shadowing denied. However, these events are logged as they occur and it can be
cumbersome to see a shadowing history because the events are strewn throughout the
Event log.
For ease of management, consider logging events in a central file. Only shadowing events
go in to this file, so they are more centralized and easier to review.
To configure shadow logging to log in a central file
1. Click on an empty area of the Shadow Taskbar and press SHIFT + F10.
2. Click Logging Options.
3. Select the Enable Logging check box and specify a log file path.
Click Clear Log to empty the current log file.
To enable shadow logging in the Windows Event log
Configure the Citrix User policy Log shadow attempts setting.
237
Enabling User-to-User Shadowing with
Policies
You can create a user policy to enable user-to-user shadowing, which allows users to
shadow other users without requiring them to be members of the Citrix administrator
group. With user-to-user shadowing, multiple users from different locations can view
presentations and training sessions, allowing one-to-many, many-to-one, and many-to-many
online collaboration. Also, you can enable Help Desk personnel to shadow users’ sessions or
allow your Sales Department to hold an online meeting to review sales leads.
Important: You configure shadowing settings during XenApp configuration. If you choose
to prohibit shadowing during configuration, you cannot enable shadowing with user
policies.
You enable user-to-user shadowing by creating policies that define users who can and
cannot shadow. You then assign the policies to the users to be shadowed.
The list of users permitted to shadow is exclusive for each user for whom a policy is
assigned. For example, if you create a policy that permits User A to shadow User B, this
policy allows only User A to shadow User B, unless you add more users to the list of users
who can shadow in the same policy’s Property sheet.
To create a policy to define users who can shadow
1. Create a user policy that identifies the users who can shadow other users’ sessions.
2. Assign the policy to the users to be shadowed.
3. Publish the Citrix Shadow Taskbar and assign it to the users who will shadow. Be sure to
instruct these users how to initiate shadowing from their client devices.
Note: Instruct users not to launch the Shadow taskbar in seamless mode. The Shadow
taskbar cannot function in seamless mode.
Example: To create a user policy for user-to-user shadowing
and assign it to users
This example demonstrates how to enable user-to-user shadowing by creating a policy for
your “Sales” user group that allows them to shadow the department manager for online
collaboration on sales leads. This procedure shows the creation of a shadowing policy.
1. Create a new policy named “Sales Group Shadowing.”
2. Add the Shadowing Citrix Computer policy setting and set it to Allowed.
238
Enabling User-to-User Shadowing with Policies
3. Because the Sales Manager may work with sensitive data, add the Notify user of
pending shadow connections Citrix User policy setting and set it to Enabled. If the
Sales Manager does not want other users to be able to take control of his mouse and
keyboard, add the Input from shadow connections Citrix User policy setting and set it
to Prohibited.
4. Add the Users who can shadow other users Citrix User policy setting, and select the
users who can shadow the Sales Manager.
5. To specify users who cannot shadow the Sales Manager, add the Users who cannot
shadow other users Citrix User policy setting, and select users.
6. Add the User filter and select the users who can receive shadowing requests.
239
Controlling Client Connections in XenApp
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, icaclient.adm, that contains
Citrix-specific rules for securing client connections. This GPO template lets you configure
rules for network routing, proxy servers, trusted server configuration, user routing, remote
client devices, and the user experience. For more information, see the Citrix Receiver for
Windows documentation.
240
Preventing Specific Client Connection
Types
You can specify the types of client connections from which users can start sessions. For
example, to increase security, you can specify that users must connect through Access
Gateway Advanced Edition (Version 4.0 or later). This allows you to benefit from filters
created in Access Gateway.
To configure connection access control
1. Configure the Connection access control Computer policy setting with one of the
following options:
241
●
Any connections allows access to published applications through any connection.
●
Citrix Access Gateway, Citrix Receiver, and Web Interface connections only
allows access to published applications through the listed connections, including
any version of Access Gateway. Denies access through any other connection.
●
Citrix Access Gateway connections only allows access to published applications
only through Access Gateway Advanced Edition servers (Version 4.0 or later).
Specifying Connection Limits
To help maintain the availability of resources in a server farm, you can limit the number of
connections to servers and published applications. Setting connection limits helps prevent:
●
Performance degradation and errors resulting from individual users who run more than
one instance of a published application at the same time
●
Denial-of-service attacks by malicious users who run multiple application instances that
consume server resources and connection license counts
●
Over-consumption of resources by non-critical activities such as Web browsing
Connection limits, including the option to log denials resulting from connection limits, are
configured in 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.
242
Limiting Connections to a Server Farm
To conserve resources, you can limit the number of concurrent connections that users are
permitted to establish. Limiting connections can help prevent over-consumption of server
resources by a few users.
Active sessions and disconnected sessions are counted for the total number of concurrent
connections. For example, you can set a limit of three concurrent connections for users. If
a user has three concurrent connections and tries to establish a fourth, the limit you set
prevents the additional connection. A message tells the user that a new connection is not
allowed.
Connection control affects users only if a connection attempt is prevented. If a 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. Configure the following Citrix Computer policy settings:
●
Limit user sessions. The maximum number of concurrent connections a user can
establish, in the range 0-8192. A value of 0 indicates no connections.
Limits on administrator sessions. Enables or disables connection limit enforcement
for Citrix administrators. Limiting connections for Citrix administrators can
adversely affect their ability to shadow other users.
Local administrators are exempt from the limit so they can establish as many
connections as necessary.
●
To specify the maximum number of connections a user can
make to the server farm at a given time
When this setting is used and the specified number is reached, the user cannot launch
additional sessions, even if the server has availability.
1. Configure the Citrix User Policy Concurrent logon limit setting.
243
Sharing Sessions and Connections
Depending on the Receiver or plug-in, when a user opens an application, it can either
appear in a seamless or non-seamless window. These window modes are available for Citrix
Receiver for Windows, Web Interface, and other plug-ins.
●
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, Receiver or the plug-in establishes a
connection to a XenApp server and initiates a session. If session sharing is not configured, a
new session is opened on the server each time a user opens an application. Likewise, every
time a user opens a new application, a new client connection is created between the client
device and the server.
Session sharing is a mode in which more than one published application runs on a single
connection. Session sharing occurs when a user has an open session and launches another
application that is published on the same server; the result is that the two applications run
in the same session. For session sharing to occur, both applications must be hosted on the
same server. Session sharing is configured by default when you specify that applications
appear in seamless window mode. If a user runs multiple applications with session sharing,
the session counts as one connection.
If you want to share sessions, ensure all applications are published with the same settings.
Inconsistent results may occur when applications are configured for different requirements,
such as encryption.
Note: Session sharing is not supported on PocketPC clients.
244
Sharing Sessions and Connections
Session sharing takes precedence over load balancing, except when a server is fully loaded.
245
Limiting Application Instances
By default, XenApp does not limit the number of instances of a published application that
can run at one time in a farm. By default, a user can launch more than one instance of a
published application at the same time.
You can specify the maximum number of instances that a published application can run at
one time or concurrently in the server farm. For example, you can publish an application
and set a limit of 30 concurrent instances in the farm. Once 30 users are running the
application at the same time, no more users can launch the application because the limit of
30 concurrent instances was reached.
Another connection control option lets you prevent any user from running multiple
instances of a particular published application. With some applications, running more than
one instance in a single user context can cause errors.
You can apply application limits independently to each published application. For example,
you can apply the limitations on total concurrent instances and multiple instances by a
single user to one published application. You can limit only the total concurrent instances
of another application. You can configure a third application to limit launching of multiple
instances by individual users.
Note: Connection control options apply to published applications and published desktops
only and do not affect published content such as documents and media files that execute
on the client device.
To specify a limit for a published application or
desktop
1. From the AppCenter, select the farm, then select Applications.
2. Select the application or desktop you want to modify. In the Action menu, select
Application properties.
3. In the Properties tree, select Limits. Select one or both of the following options:
●
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.
●
246
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.
Logging Connection Denial Events
Event logging records an entry in the System log each time a server denies a user
connection because of a connection control limit. Each server records the data in its own
System log. By default, this type of event logging is disabled.
You can configure XenApp to log when limits are reached (and connections denied) for the
following:
●
Maximum connections per user
●
Application instance limits
●
Application instances per user
To enable or disable logging of connection denial events, configure the Logging of logon
limit events Citrix Computer policy setting.
247
Configuring the ICA Listener
To configure the ICA listener, use the Citrix ICA Client Configuration Tool (CtxICACfg.exe).
For more information, see CTX125139.
Important: Do not use Microsoft Remote Desktop Services tools to configure the ICA
listener.
248
Preventing User Connections During
Farm Maintenance
You might want to prevent logons to a server when you install software or perform other
maintenance or configuration tasks. This is helpful when you are installing applications that
require there be no active sessions on the server. It also lets you restart the server without
having to wait for users to disconnect.
By default, logons are enabled when you install XenApp and users can launch an unlimited
number of sessions and instances of published applications. You can prevent users from
connecting to a server in the farm by disabling logons.
To disable logons on a server
1. From the AppCenter, select the server.
2. In the Actions pane, select Other Tasks > Logon Control > Prohibit logons only.
Note: To reenable disabled logons, select Other Tasks > Logon Control > Allow logons
and reconnections.
249
Optimizing User Sessions for XenApp
XenApp includes various HDX features that allow you to enhance user experience by
maintaining session activity and improving session responsiveness.
Network latency and bandwidth availability can impact the performance of connections to
published applications and content. These HDX technologies allow you to improve
connection speed and responsiveness during user sessions. Instructions for configuring these
features are provided in the corresponding topics:
250
●
MDX MediaStream Multimedia Acceleration. Allows you to control and optimize the
way XenApp servers deliver streaming audio and video to users.
●
HDX MediaStream Flash. Allows you to control and optimize how XenApp servers
deliver Adobe Flash animations to users.
●
HDX 3D Image Acceleration. Enables you to adjust the quality of photographic image
files as they appear on client devices and the amount of bandwidth the files consume
on their way from the server to the client.
●
HDX 3D Progressive Display. Allows you to improve interactivity when displaying
high-detail images by temporarily increasing the level of compression (decreasing the
quality) of the image when it is first transmitted over a limited bandwidth connection,
providing a fast (but low quality) initial display. If the image is not immediately
changed or overwritten by the application, it is then improved in the background to
produce the normal quality image, as defined by the normal lossy compression level.
●
SpeedScreen Latency Reduction. Helps reduce a user’s perception of latency when
typing and clicking. It provides visual feedback for mouse clicks and Local Text Echo; a
feature that accelerates the display of input text, effectively shielding the user from
experiencing latency on the network.
●
HDX Broadcast Display. HDX Broadcast Display provides control over settings that let
you reserve bandwidth by limiting session-memory usage and discarding obsolete
queued images on the client.
●
HDX Broadcast Browser. HDX Broadcast Browser provides control over whether or not
the servers in your network will respond to broadcast messages sent from Citrix
Receiver. You may reduce bandwidth consumption if you disable these options.
Optimizing Audio and Video Playback
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.
●
Network Bandwidth. Multimedia content is passed over the network in compressed
form, 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.
251
Optimizing Audio and Video Playback
To allow users to run multimedia applications in ICA sessions, turn on audio or give the
users permission to turn on audio themselves in Citrix Receiver. By default, all other
plug-ins and methods are configured with audio enabled and optimized for speech sound
quality.
Other requirements for using HDX MediaStream Multimedia Acceleration are:
●
Users must be running Citrix Receiver.
●
The user device must have the same memory and processing speed as is needed for
playing multimedia locally.
●
The correct codec to decompress the media file type used (MPEG for example) must
reside on the user device. Windows devices have the most common codecs already
installed. If you need additional codecs, you can download them from the Web sites of
the manufacturers of media players.
Note: To make Windows Media Player 11 and Media Foundation components available on
your XenApp server, install and configure the Microsoft Windows Server 2008 Desktop
Experience in the Server Manager.
Applications and media formats supported by HDX MediaStream Multimedia Acceleration
are:
●
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.
252
Configuring Windows Media Redirection
Configure Windows Media Redirection in a Citrix policy.
Note: By default, audio is disabled on the client. To allow users to run multimedia
applications in sessions, turn on audio or give the users permission to turn on audio
themselves on their user devices.
1. Configure the following Citrix Computer policy setting:
253
●
Windows Media Redirection. Enables or disables the feature.
●
Windows Media Redirection buffer size. Specifies the buffer size in seconds, in the
range 1-10; requires enabling the Windows Media Redirection default buffer size
use option. You can see how much server memory the selected buffer can use by
changing the buffer time.
●
Windows Media Redirection buffer size use. Enables or disables use of a buffer.
When this option is enabled, specify the buffer size with the Windows Media
Redirection default buffer size option
Optimizing Flash Content
HDX MediaStream server-side Flash functionality allows you to optimize the way XenApp
renders and delivers Adobe Flash content to users. To display Flash content in sessions, you
must have the Flash plug-in and the corresponding ActiveX control installed in the Web
browser before you publish it.
Users playing Flash content in published applications might observe poor rendering quality
of the animation, slow session responsiveness, or a combination of both. This occurs when
Adobe Flash Player, which renders the content on the server, starts in high-quality mode by
default. While this guarantees the highest possible rendering mode for each frame, it also
means that each frame consumes considerable bandwidth on its way to the user.
HDX MediaStream server-side Flash functionality improves the user’s session responsiveness
by forcing the Flash Player to use simpler graphics (for example, no smoothing or
anti-aliasing). This feature also reduces the amount of processing power that is required to
render Flash content.
By default, HDX MediaStream server-side Flash functionality is enabled at the server farm
level. However, if HDX MediaStream client-side Flash functionality is enabled, server-side
rendering is overridden.
1. Configure the Flash quality adjustment Citrix User policy setting with one of the
following options:
●
Optimize Adobe Flash animation options for all connections. Select this option to
always reduce the amount of Flash data sent to users. The result is minimized CPU
usage on the servers on which users are using Flash within Internet Explorer.
●
Optimize Adobe Flash animation options for low bandwidth connections only.
Select this option to improve responsiveness when Flash content is sent to users on
restricted bandwidth connections (under 150Kbps). On restricted bandwidth
connections, such as over a WAN, less data is downloaded and the quality of Flash
content is lower. When bandwidth is not limited, for example on a LAN, users get
higher quality Flash animation.
Do not optimize Adobe Flash animation options. Select this option if bandwidth is
not limited.
2. To reduce bandwidth consumption and improve video playback and server scalability,
configure the Citrix Computer policy setting for Queueing and tossing. Configuring this
setting can cause animations to become choppy due to dropped frames.
●
254
Optimizing Throughput of Image Files
The size of image files affects the amount of time the files take to travel from server to
client. Often, image files contain redundant or extraneous data that is of little benefit to
the user and slows down the 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.
1. Configure the Lossy compression level Citrix User policy setting with one of the
following options:
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 Progressive compression level
Citrix User policy setting with the None option.
255
Optimizing Display of Image Files
You can enable Progressive Display to increase the performance of displaying images or
parts of images that are changing.
Progressive Display speeds the initial display of an image file by choosing an increased
compression level while an image is dynamic. This initial display is then sharpened up to
normal quality in the background if the image is not immediately changed or overwritten in
the application. The quality of the final image is controlled by Image Acceleration.
Progressive Display can improve the performance not only of applications that render and
display images, but also those parts of an image that are dynamic, such as when scrolling
through a PDF or similar document.
Configure the Progressive compression level Citrix User policy setting with the desired
level (Low, Medium, High, Very high, or Ultra high), and configure the Lossy compression
level Citrix User policy setting to None.
256
Optimizing Keyboard and Mouse
Responsiveness
SpeedScreen Latency Reduction is a collective term used to describe features such as Local
Text Echo and Mouse Click Feedback that help enhance user experience on a slow network.
Mouse Click Feedback
On high latency connections, users often click the mouse multiple times because there is no
visual feedback that a mouse click resulted in an action. Mouse Click Feedback, which is
enabled by default, changes the appearance of the pointer from idle to busy after the user
clicks a link, indicating that the system is processing the 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.
257
Configuring SpeedScreen Latency
Reduction
SpeedScreen Latency Reduction Manager, a tool provided with XenApp, allows you to
configure SpeedScreen Latency Reduction settings for a XenApp server, for single or
multiple instances of an application, as well as for individual input fields within an
application. You can also use it as a troubleshooting tool to fine-tune SpeedScreen Latency
Reduction behavior for applications, or input fields within an application, that exhibit
incompatibility with this SpeedScreen feature.
SpeedScreen Latency Reduction Manager must be installed on a XenApp server, and can be
used to customize SpeedScreen Latency Reduction settings only on that server.
To launch SpeedScreen Latency Reduction Manager, select SpeedScreen Latency Reduction
Manager from the Citrix > Administration Tools program group in the Start menu.
Note: To run the Speedscreen Latency Reduction Manager with the User Account Control
(UAC) enabled, you must be a domain administrator, delegated administrator, or part of
the Administrators group on the local computer, or you will be prompted for
administrator credentials.
Through SpeedScreen Latency Reduction Manager, you can configure common SpeedScreen
Latency Reduction settings for all applications on a server or select custom settings for
individual applications. Before you can configure any settings, you must add the
application.
258
Adjusting SpeedScreen Latency
Reduction for an Application
If a published application exhibits abnormal behavior after it is configured to use
SpeedScreen Latency Reduction, you can use the Add New Application wizard included with
SpeedScreen Latency Reduction Manager to adjust latency reduction functionality for the
selected application, or all instances of the selected application on the server. To optimize
usability of the application, use this wizard to adjust, turn on, or turn off SpeedScreen
Latency Reduction for the application.
Note: The application must be running before you can use this wizard to modify existing
settings.
To adjust SpeedScreen Latency Reduction for an
application
If a published application exhibits abnormal behavior after it is configured to use
SpeedScreen Latency Reduction, you can use the Add New Application wizard included with
SpeedScreen Latency Reduction Manager to adjust latency reduction functionality for the
selected application, or all instances of the selected application on the server. To optimize
usability of the application, use this wizard to adjust, turn on, or turn off SpeedScreen
Latency Reduction for the application.
Note: The application must be running before you can use this wizard to modify existing
settings.
Before you can adjust Speedscreen Latency Reduction for an application, you must add the
application to the Speedscreen Latency Reduction Manager.
1. From the Start menu, select All Programs > Citrix > Administration Tools >
SpeedScreen Latency Reduction Manager.
2. From the Applications menu of SpeedScreen Latency Reduction Manager, select New to
start the wizard and follow the prompts.
3. Use the Define the Application screen to select an application instance on the server.
To specify the application, use one of these methods:
●
Click the icon at the bottom of the page and drag the pointer onto the window of
an application. The application must be running when you select it.
Click the Browse button and navigate to the application.
4. Specify whether Local Text Echo is enabled or disabled on the application by selecting
or clearing the Enable local text echo for this application check box. For a definition
of Local Text Echo, see Optimizing Keyboard and Mouse Responsiveness
●
259
Adjusting SpeedScreen Latency Reduction for an Application
5. Specify whether the setting you selected in the previous step should be applied to all
instances of the application on the server or just the instance selected.
Test all aspects of an application with Local Text Echo in a non-production environment
before enabling it to ensure that the display is acceptable to users.
When you configure SpeedScreen Latency Reduction Manager on a particular server, the
settings are saved in the ss3config folder in the Citrix installation directory of that server.
You can propagate the settings to other servers by copying this folder and its contents to
the same location on the other servers.
Note: If you plan to propagate SpeedScreen Latency Reduction Manager settings to other
servers, select Apply settings to all installations of the selected application when
configuring Local Text Echo through the wizard. Paths to published applications might
differ from one server to another; therefore, applying the settings to all instances of the
selected application ensures that the settings apply regardless of where the application is
located on the destination server.
To configure latency reduction settings for all
applications on a server
1. From the Start menu, select All Programs > Citrix > Administration Tools >
SpeedScreen Latency Reduction Manager.
2. From the Application menu, select Server Properties. The Server Properties dialog
box containing existing settings for the selected server appears.
3. Configure the SpeedScreen Latency Reduction settings that you want to be applied to
all of the applications on the server. All users connecting to the server benefit from the
SpeedScreen options you set here. Changes made to SpeedScreen Latency Reduction
settings at an application level override any server-wide settings.
●
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.
●
260
Adjusting SpeedScreen Latency Reduction for an Application
To configure custom latency reduction settings for an
individual application
1. From the Start menu, select All Programs > Citrix > Administration Tools >
SpeedScreen Latency Reduction Manager.
2. In the SpeedScreen Latency Reduction Manager, select the application.
3. From the Application menu, select Properties. The Application Properties tab
containing existing SpeedScreen Latency Reduction settings for the selected application
appears. It contains this information:
●
Application Name. The application executable name appears here; for example,
Excel.exe.
Path to Application. The path to the application executable appears here; for
example, C:\Microsoft Office\Excel.exe.
4. If desired, configure application settings:
●
261
●
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.
To configure latency reduction settings for
input fields in an application
Input fields in an application are fields where text can be added. You can use SpeedScreen
Latency Reduction Manager to set latency reduction behavior for selected input fields in a
configured application to reduce delays between when users enter text at the keyboard and
when it is echoed or displayed on the screen.
1. From the Start menu, select All Programs > Citrix > Administration Tools >
SpeedScreen Latency Reduction Manager.
2. Select an application.
3. From the Applications menu, select Properties. The Application Settings window
appears.
4. Select the Input Field Configuration tab, then configure these settings as needed.
●
The Configured Input Field List displays the list of configured input fields.
SpeedScreen Latency Reduction uses a window hierarchy to identify the input fields
that need special settings. The entries shown in the tree view are the window class
names of the configured fields. For example, _WwG is the window class name of
the main document window in Microsoft Word.
●
Click New to run the Advanced Input Field Compatibility wizard to add a new
input field. This wizard guides you through the process of configuring
SpeedScreen Latency Reduction settings for an input field.
Click Delete to delete the selected input field from the Configured Input Field
List.
Enable local text echo for this input field enables Local Text Echo. If this check
box is selected, you can apply more Local Text Echo settings to the selected field.
●
●
●
Limit local text echo forces behavior in input fields in nonstandard applications
that may not behave correctly. Select one of the two available settings:
●
Display text in place ensures text is echoed in place.
Display text in a floating bubble ensures text is echoed within a floating
bubble.
Reduce font size forces input fields in non-standard applications to display text at
a reduced font size. Use this setting when input fields in non-standard applications
display misaligned text, oversized fonts, or other undesirable font behavior. Choose
the percentage by which to reduce the font size. Percentage values available are
10%, 20%, and 30%.
●
●
●
262
Use system default colors forces non-standard input fields to use system default
colors. SpeedScreen Latency Reduction tries to auto-detect the text and
background colors used in input fields; however, non-standard input fields
To configure latency reduction settings for input fields in an application
sometimes report incorrect or inadequate information. As a result, text echo in
input fields on nonstandard applications can appear corrupted. This setting turns
off auto-detection and controls how system default colors are applied to input
fields.
●
Choose Both the text and background to apply system default colors to both
text and background.
Choose The background only to apply system default colors only to the
background.
Input field is a password controls how hidden characters are displayed in
non-standard input fields. Typically, hidden characters are located in password
entry fields. Text echo in non-standard input fields might make these hidden
characters appear as normal text, compromising security. This setting forces hidden
characters to display as asterisks or spaces.
●
●
263
●
Choose Hidden characters denoted by “*” if you want Local Text Echo for such
input fields to be replaced by asterisks.
●
Choose Hidden characters denoted by spaces if you want Local Text Echo for
password input fields to be replaced by spaces.
To create exception entries for
non-standard input fields in an application
Some input fields do not conform to standard Windows behavior and thus do not work
correctly with SpeedScreen Latency Reduction. You can create exception entries for such
fields, while still providing minimal latency reduction functionality for the rest of the
application. The Input Field Compatibility wizard included with SpeedScreen Latency
Reduction Manager guides you through the process of selecting non-standard input fields
and creating exception entries for them.
Note: The application must be running before you can configure an input field within it.
1. Start the application.
2. Select Start > All Programs > Citrix > Administration Tools > SpeedScreen Latency
Reduction Manager.
3. From the Applications menu in SpeedScreen Latency Reduction Manager, select
Properties. The Application Settings window appears.
4. Select the Input Field Configuration tab. Click New to start the wizard and follow the
prompts.
5. With the application running, select the input field you want to configure and complete
these steps:
a. Drag the pointer onto the input field window for which SpeedScreen behavior needs
to be customized.
b. If the SpeedScreen Latency Reduction Manager window is obscuring the target input
field, check the Hide SpeedScreen Latency Reduction Manager check box. This
causes the SpeedScreen Latency Reduction Manager window to be hidden from
view.
6. To define the level of compatibility for the input field, select the level of SpeedScreen
Latency Reduction compatibility to apply to the selected input field. Use the slider bar
to select the desired compatibility level. The default compatibility level is Auto, which
provides full SpeedScreen Latency Reduction functionality. However, because the field
being configured is not displaying the desired behavior, downgrade the latency
reduction functionality level to Medium, Low, or Off.
264
●
Medium Compatibility. Use this level of compatibility for input fields that are
incompatible with the default Auto setting. Text echo appears in place with limited
acceleration.
●
Low Compatibility. If an input field is incompatible with both the Auto and Medium
compatibility settings, select Low. Text echo appears in a floating text bubble
rather than within the input field.
To create exception entries for non-standard input fields in an application
●
265
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.
Configuring HDX Broadcast Display
Settings
To configure HDX Broadcast display settings
1. To improve the response when graphics are sent to the client, configure the Citrix
Computer policy Queueing and tossing setting. Queued images that are replaced by
another image are discarded. This is useful when bandwidth is limited. A drawback to
selecting this option is that it can cause animations to become choppy because
intermediate frames get dropped.
2. To make scrolling smoother because sections of an image can be retrieved from the
cache, configure the Citrix Computer policy Image caching setting.
3. Enter the maximum memory to be used on the server for each client connection with
the Citrix Computer policy Display memory limit setting.
You can specify an amount in kilobytes from 128 to 131072. Using more color depth and
higher resolution for connections requires more memory. You can calculate the
maximum memory required by using this equation:
(color depth in bits per pixel / 8) * vertical resolution in pixels * horizontal resolution in
pixels = memory required in bytes
For example, if the color depth is 24, the vertical resolution is 600, and the horizontal
resolution is 800, the maximum memory required is:
(24bpp / 8) * 600 pixels * 800 pixels = 1440000 bytes of memory required
You can specify 1440KB in maximum memory to handle connections with these settings.
4. For the Citrix Computer policy Display mode degrade preference setting, configure
one of the following options:
●
Degrade color depth first. Select this option if you want color depth to be reduced
before resolution is lowered when the session memory limit is reached.
Degrade resolution first. Select this option if you want resolution to be lowered
before color depth when the session memory limit is reached.
5. To display a brief explanation to the user when a session is degraded, configure the
Citrix Computer policy Notify user when display mode is degraded setting. Possible
reasons for degradation include exceeding the memory limit and connecting with a
client that cannot support the requested parameters.
●
266
Enhancing the User Experience With
HDX
Citrix HDX includes a broad set of technologies designed to provide a high-definition user
experience. HDX builds on existing technologies in Citrix products, extending them with
new innovations for today’s media-rich user environments.
Quick Links
267
●
Configuring HDX MediaStream Flash Redirection
●
Configuring Audio
●
Multimedia Conferencing with HDX RealTime
●
Increasing 2D and 3D Application Scalability and Performance
●
Assigning Priorities to Network Traffic
●
Adding Dynamic Windows Preview Support
Configuring HDX MediaStream Flash
Redirection
HDX MediaStream Flash Redirection allows you to move the processing of most Adobe Flash
content to LAN- and WAN-connected users' Windows devices rather than using server
resources. This processing includes animations, videos, and applications. By moving the
processing to the user device, Flash Redirection helps reduce server and network load,
resulting in greater scalability while ensuring a high definition user experience.
Note: Two types of Adobe Flash Players are required to use Flash Redirection. One type is
used with Windows Internet Explorer and is identified by Adobe as Flash Player for
Windows Internet Explorer. This player is sometimes referred to as an ActiveX player.
The second type is used with non-Internet Explorer browsers and is identified by Adobe as
Flash Player for Windows - Other Browsers. This player is sometimes referred to as an
NPAPI (Netscape Plugin Application Programming Interface) Flash Player.
Second Generation Flash Redirection
Flash Redirection has been revised for use with:
●
Citrix XenApp 6.5
●
Citrix XenDesktop 5.5
●
Citrix Receiver 3.0
New second generation Flash Redirection features include:
●
WAN-connected user support.
●
The second generation and legacy versions of Flash Redirection are complete and run in
separate virtual channels.
●
Intelligent Fallback, which allows Flash sessions, on a per-instance basis, to be
determined to be more efficient when rendered on the server.
●
The Flash URL Compatibility List replaces the original Flash URL Blacklist setting. Listed
URLs can now be blocked or specified for rendering on the user device or the server.
System Requirements for Flash Redirection
The following is accurate at the time this content was published. See
https://www.citrix.com/support/product-lifecycle/product-matrix for more information
about supported versions of Citrix products.
268
Configuring HDX MediaStream Flash Redirection
For user devices:
●
Citrix Receiver 3.0 (formerly called the online plug-in) is required on the user device to
use the second generation Flash Redirection features. Online plug-in 12.1 is supported
on the user device for the original, or legacy, Flash Redirection features only.
●
A network connection exists and is enabled. To use XenDesktop Virtual Desktop Agents,
establish a network connection between the user's Windows device and the agent.
●
Adobe Flash Player 10.1 or above for Windows - Other Browsers is installed on the user
device.
Note: If an earlier version of the Flash Player is installed on the user device, or the
Flash Player cannot be installed on the user device, Flash content is rendered on the
server.
For servers running Citrix XenApp 6.5 or Citrix XenDesktop 5.5:
●
Flash Player 10.1 or above for Windows Internet Explorer is installed on the servers running XenApp and
XenDesktop's Virtual Desktop Agents.
●
Internet Explorer 9, Internet Explorer 8, or Internet Explorer 7.
Second generation Flash Redirection on XenDesktop 5.5 supports Internet Explorer 9.
In order to enable support for Internet Explorer 9 on the XenApp 6.5 server, an edit to the registry of the
XenApp server is required.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall
your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of
Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry
before you edit it.
●
For a 32-bit operating system:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HdxMediaStreamForFlash\Server\PseudoServer
Add the entry named IEBrowserMaximumMajorVersion with a DWORD value = 00000009.
●
For a 64-bit operating system
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\HdxMediaStreamForFlash\Server\PseudoServ
Add the entry named IEBrowserMaximumMajorVersion with a DWORD value = 00000009.
Caution: Flash Redirection requires significant interaction between the user device and
server components. Therefore, this feature should be used only in environments where
security separation between the user device and server is not needed. User devices
should be configured to use the Flash Redirection feature only with trusted servers. Flash
Redirection requires the Flash Player to be installed on the user device. Therefore, Flash
Redirection should be enabled only if the Flash Player itself is secured.
269
Configuring HDX MediaStream Flash
Redirection on the Server
You can configure HDX MediaStream Flash Redirection settings on the server through the
Policies node of Citrix Desktop Studio or Citrix AppCenter. You control the Flash Redirection
features through the following Citrix User Policy settings:
●
Flash backwards compatibility
●
Flash default behavior
●
Flash intelligent fallback
●
Flash latency threshold
●
Flash server-side content fetching URL list
●
Flash URL compatibility list
●
Flash event logging
●
Flash acceleration
●
Flash background color list
To enable backward compatibility
The second generation of Flash Redirection can be configured to be backward compatible
with its legacy features, supporting user devices with earlier versions of the online plug-in
(now the Citrix Receiver). Those devices can access the legacy Flash Redirection features
only. This is done by providing two separate virtual channels, one for each generation of
Flash Redirection, on the servers and user devices. The following table shows the resulting
level of functionality when using a mix of Flash Redirection modes.
Connection
Result
Second generation on a user device
and second generation on a server
Second generation
Legacy mode on a user device and
second generation on a server
Legacy mode
Second generation on a user device
Legacy mode
and Legacy mode on a server
The Enable HDX MediaStream Flash Redirection on the user device setting on the user
device must also be enabled.
270
Configuring HDX MediaStream Flash Redirection on the Server
To use the backward compatibility feature:
●
On the server running Desktop Studio or AppCenter, enable the Citrix User Policy
setting Flash backwards compatibility.
●
On the user device, enable the Enable HDX MediaStream for Flash on the user device
setting, selecting the Always or Ask options.
Note: Backwards compatibility is not available if the Only with Second Generation
option is selected.
To establish the Flash acceleration default behavior
The Citrix User Policy setting Flash Default Behavior lets you establish the default behavior
of Flash acceleration. The default behavior can be overridden for individual Web pages and
Flash instances based on the configuration of the Flash URL Compatibility List. In addition,
on the user device, enable the Enable HDX MediaStream Flash Redirection on the user
device setting.
Three options are available in this second generation feature.
Option
Behavior
Block Flash
player
The user cannot view any Flash content. Second generation and
Legacy mode Flash Redirection, and server-side rendering are not
used.
Disable Flash
acceleration
The user can view server-side rendered Flash content if Flash Player
for Windows Internet Explorer compatible with the content is installed
on the server. Second generation and Legacy mode Flash Redirection
is not used.
Enable Flash
acceleration
Flash Redirection is used. Second Generation is available where its
requirements are met. Legacy mode is available when backwards
compatibility is enabled.
Enable Flash acceleration is the default and will be used if no option is selected.
To set Flash intelligent fallback
Use this setting if you do not want all instances of Flash content to be redirected for
rendering on the user device. Typically, small Flash movies are frequently used to play
advertisements. Flash intelligent fallback detects these instances and renders the content
on the server. Using this Citrix User Policy setting causes no interruption or failure in the
loading of the Web page or the Flash application.
Configure the Flash intelligent fallback setting by selecting Enabled, which is the default,
or Disabled.
271
Configuring HDX MediaStream Flash Redirection on the Server
To set the Flash latency threshold
The Flash latency threshold policy setting only applies to Legacy mode features. This Citrix
User Policy is only applicable if Flash backwards compatibility is enabled.
Flash Redirection Legacy mode measures the round trip latency between the server and
user device the first time an individual browser or browser tab accesses an embedded Flash
Player. This measurement includes both the latency of the network connection and any
other latency in the data path. If the latency is determined to be within an acceptable
threshold, Flash Redirection Legacy mode is used to render Flash content on the user
device. If the latency is above this threshold, the Flash content is rendered on the network
server if a Flash player is available there and delivered over the virtual channels.
The default threshold setting is 30 milliseconds. Increasing the value over 30 milliseconds
may result in a degraded user experience. For typical use, it is best practice not to increase
the latency threshold setting.
Configure the Flash latency threshold setting by typing a value between 0 and 30 in the
Value field.
To identify Web sites for server-side content fetching
Flash Redirection downloads Flash content to the user device where it is played. The Flash
server-side content fetching URL list setting allows you to specify Web sites whose Flash
content can be downloaded to the server then sent to the user device. While server-side
content fetching works with most Internet sites, it is intended for use with Intranet sites
and internal Flash applications.
Note: Server-side content fetching does not support Flash applications using Real Time
Messaging Protocols (RTMP). Instead, server-side rendering for such sites is used.
This setting works with the Enable server-side content fetching setting on the user device.
This setting is frequently used when the user device does not have direct access to the
Internet. The XenApp or XenDesktop server provides that connection.
Consider the following when configuring the Flash server-side content fetching URL list
setting:
●
Add the URL of the Flash application; not the top-level .html page that instantiates the
Flash Player to the list.
●
Use an asterisk character at the beginning or end of the URL as a wildcard to expand
your list.
●
Use a trailing wildcard to allow all child URLs, for example
http://www.sitetoallow.com/*.
●
The prefixes http:// or https:// are used when present, but they are not required.
Configure the Flash server-side content fetching URL list setting by clicking New to add
new URLs to the list.
272
Configuring HDX MediaStream Flash Redirection on the Server
Important: You must enable the Enable server-side content fetching setting on the user
device for the Flash server-side content fetching URL list on the server to work.
To specify where Flash content renders
The second generation of Flash Redirection lets you specify whether Flash content from
listed Web sites is:
●
Rendered on the user device.
●
Rendered on the server.
●
Blocked from rendering.
Consider the following when configuring the Flash URL compatibility list setting:
●
Prioritize the list with the most important URLs, actions, and rendering locations at the
top.
●
Use an asterisk character at the beginning or end of the URL as a wildcard to expand
your list.
●
Use a trailing wildcard to refer to all child URLs, for example
http://www.sitetoblock.com/*).
●
The prefixes http:// or https:// are used when present, but they are not required.
●
Add sites containing Flash content that does not render correctly on the user device to
the list, using the Render on Server or Block options.
To configure the Flash URL compatibility list setting:
1. Click New to open the Add Flash URL Compatibility list entry dialog box.
2. Select an action (Render on Client, Render on Server, or Block).
3. In the URL Pattern box, type the URL of the Web site upon which you want to act.
4. Select the Flash instance you want to serve as a trigger.
●
Select Any: The action occurs any time any Flash instance connects with the listed
Web site.
●
Select Specific: Type the Flash player ID. The action occurs only when this specific
Flash instance connects with the listed Web site.
To enable server-side event logging
Flash Redirection uses Windows event logging on the server to log Flash events. You can
review the event log to determine whether Flash Redirection is being used and to gather
details about any issues. The following are common to all events logged by Flash
Redirection:
273
Configuring HDX MediaStream Flash Redirection on the Server
●
Flash Redirection reports events to the Application log.
●
The Source value is Flash.
●
The Category value is None.
In addition to the Windows event log, on computers with Windows 7 or Windows Vista, a
Flash Redirection-specific log appears in the Applications and Services Logs node. Flash
Redirection-specific log is also available on Windows Server 2008 R2 computers running this
Early Release version of XenApp. If Windows XP is used, Flash Redirection log information is
found only in the Windows application event log.
Configure the Flash event logging setting for Legacy mode by selecting Enabled, which is
the default, or Disabled.
Configuration is not available for Second Generation Flash Redirection.
To enable and disable the Legacy mode HDX
MediaStream Flash Redirection from the server
Legacy mode Flash Redirection is enabled on the server for client-side rendering by default.
You can enable and disable Legacy mode Flash Redirection from the server through the
Citrix User Policy setting Flash acceleration, in the Flash Redirection category.
Configure the Flash acceleration setting by selecting Enabled, which is the default, or
Disabled.
When Enabled is selected, all Flash content from sites not blocked by the Flash URL
compatibility list is rendered on the user device using Legacy mode. If Disabled is selected,
all Flash content is rendered on the server.
To enable matching between the Web page and Flash
instances
Using the Flash background color list Citrix User Policy setting, you can match the colors of
Web pages and Flash instances. This can improve the appearance of the Web page when
using Flash Redirection.
Click New and type the Web site URL followed by the appropriate 24-bit Web color
hexadecimal number. For example, you can use: http://www.sitetomatch.com/ FF0000.
For best results, consider using a color not typically used on the Web page, such as black.
Use a trailing wildcard to enable matching in all child URLs, for example,
http://www.sitetomatch.com/* FF0000.
274
Configuring HDX MediaStream Flash
Redirection on the User Device
You can change the default settings on the user device with the Group Policy Object Editor.
To configure HDX MediaStream Flash Redirection on
the User Device with Group Policy Objects
1. Create or select an existing Group Policy Object.
2. Import and add the HDX MediaStream Flash Redirection - Client administrative template
(HdxFlash-Client.adm), available in:
●
For 32-bit computers: %Program Files%\Citrix\ICA Client\Configuration\language.
●
For 64-bit computers: %Program Files (x86)%\Citrix\ICA
Client\Configuration\language.
Note: For details on creating Group Policy Objects and importing and adding
templates, see the Microsoft Active Directory documentation at
http://www.microsoft.com.
To enable Flash Redirection on the user device
Configure Enable HDX MediaStream Flash Redirection on the user device to determine
whether Flash Redirection is enabled on your users' Windows devices. If no configuration is
set, one of the following will occur, based on your users' environment:
●
Desktop Lock is used: Flash Redirection is enabled by default.
●
All other conditions: The user receives a dialog box the first time they access Flash
content in each session in which the user can enable HDX MediaStream Flash
Redirection.
1. In the Group Policy Object Editor, expand either the Computer Configuration or User
Configuration node.
2. Expand the Administrative Templates and Classic Administrative Templates (ADM)
nodes and select HDX MediaStream Flash Redirection - Client.
3. From the Setting list, select Enable HDX MediaStream Flash Redirection on the user
device and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
275
Configuring HDX MediaStream Flash Redirection on the User Device
5. If you selected Enabled, from the Use HDX MediaStream Flash Redirection list, select
Always, Ask, Never, or Only with Second Generation.
Note: Selecting Ask results in users receiving the Citrix Receiver - Flash dialog box
the first time they access Flash content in each session in which the user can enable
Flash Redirection. If the user does not enable Flash Redirection, the Flash content is
played on the server. Selecting Always, Never, and Only with Second Generation
does not result in this dialog box. Select Always to always use Flash Redirection to
play Flash content on the user device. Select Never to never use Flash Redirection
and have Flash content play on the server. Select Only with Second Generation to
use the latest Flash Redirection functionality when the required configuration is
present and revert to server-side rendering when the required configuration is not
present.
6. For the policy to take effect:
●
Computer Configuration: Changes take effect as computers in the organizational
unit restart.
●
User Configuration: Users in the organizational unit must log off and then log on to
the network.
Controlling the Citrix Receiver - Flash Dialog Box
Display specific choices for the user in the Citrix Receiver - Flash dialog box based on how
you configure Flash Redirection on the user device. The following all refer to configuring
Enable HDX MediaStream Flash Redirection on the user device:
276
●
If Citrix Receiver detects the user device does not have the required version of the
Adobe Flash Player (Flash Player for Windows - Other Browsers, sometimes referred to
as an NPAPI (Netscape Plugin Application Programming Interface Flash Player)), the
Citrix Receiver - Flash dialog box offers the user the opportunity to obtain and install a
copy of the correct player. Before downloading, an explanation of why the player is
needed appears.
●
If Enabled and Ask are selected, the Citrix Receiver - Flash dialog box appears. At this
point, the user can choose whether or not to optimize Flash content for the rest of
their session. Don't ask me again is not visible. The dialog box appears the first time
the user encounters Flash content each session.
●
XenApp only: If Not Configured is selected, the Citrix Receiver - Flash dialog box
appears the first time the user accesses Flash content in each session. At this point, the
user can choose whether or not to optimize Flash content for the rest of the session. If
the user selects Don't ask me again, the optimization choice will be used in future
sessions. The dialog box does not appear in the future. Changing this setting requires
editing the user device registry.
●
XenDesktop only: If the user opens the Citrix Receiver - Desktop Viewer Preferences
dialog box and selects the Flash tab, a page with contents similar to the Citrix Receiver
- Flash dialog box appears. The user can choose whether or not to optimize Flash
content in future sessions on this page. If the user selects Ask me later, the Citrix
Receiver - Flash dialog box appears the first time the user encounters Flash content
each session. Don't ask me again is not visible. The user can change this setting at the
Configuring HDX MediaStream Flash Redirection on the User Device
Citrix Receiver - Desktop Viewer Preferences dialog box.
To synchronize client-side HTTP cookies with the
server-side
Enable synchronization of the client-side HTTP cookies with the server-side in order to
download HTTP cookies from the server. These HTTP cookies are then used for client-side
content fetching and are available to be read, as needed, by sites containing Flash content.
Client-side cookies are not replaced during the synchronization; they remain available if the
synchronization policy is later disabled.
1. In the Group Policy Object Editor, expand either the Computer Configuration or User
Configuration node.
2. Expand the Administrative Templates and Classic Administrative Templates (ADM)
nodes and select HDX MediaStream Flash Redirection - Client.
3. From the Setting list, select Enable synchronization of the client-side HTTP cookies
with the server-side and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. For the policy to take effect:
●
Computer Configuration: Changes take effect as computers in the organizational
unit restart.
●
User Configuration: Users in the organizational unit must log off and then log on to
the network.
To enable server-side content fetching
By default, HDX MediaStream Flash Redirection downloads Adobe Flash content to and plays
the content on the user device. Enabling server-side content fetching causes the Flash
content to download to the server and then be sent to the user device. Unless there is an
overriding policy, such as a site blocked through the Flash URL compatibility list policy
setting, the content will play on the user device.
This setting is frequently used when:
●
The user device does not have direct access to the Internet.
●
The user device connects to internal sites through Citrix Access Gateway.
Note: Server-side content fetching does not support Flash applications using Real Time
Messaging Protocols (RTMP). Instead, server-side rendering for such sites is used.
The second generation of Flash Redirection introduces three new enabling options as
described in the following table. Two of these options include the ability to cache
server-side content on the user device. This improves performance because content that is
277
Configuring HDX MediaStream Flash Redirection on the User Device
reused is already available on the user device for rendering.
Note: The contents of this cache are stored separately from other HTTP content cached
on the user device.
Also introduced in the second generation is server-side content fetching fallback. When one
of the three Enabled options is selected, server-side content fetching automatically begins
if client-side fetching of .swf files fails.
Option
Description
Disabled
Disables server-side content fetching, overriding the Flash server-side
content fetching URL list setting on the server. Server-side content
fetching fallback is also disabled.
Enabled
Enables server-side content fetching for Web pages and Flash
applications identified in the Flash server-side content fetching URL
list. Server-side content fetching fallback is available. Flash content is
not cached.
Enabled
(persistent
caching)
Enables server-side content fetching for Web pages and Flash
applications identified in the Flash server-side content fetching URL
list. Server-side content fetching fallback is available. Content
obtained through server-side fetching is cached on the user device and
stored from session to session.
Enabled
(temporary
caching)
Enables server-side content fetching for Web pages and Flash
applications identified in the Flash server-side content fetching URL
list. Server-side content fetching fallback is available. Content
obtained through server-side fetching is cached on the user device and
deleted at the end of the session.
Important: The Flash server-side content fetching URL list setting on the server must
be enabled and populated with target URLs for server-side content fetching to work.
1. In the Group Policy Object Editor, expand either the Computer Configuration or User
Configuration node.
2. Expand the Administrative Templates and Classic Administrative Templates (ADM)
nodes and select HDX MediaStream Flash Redirection - Client.
3. From the Setting list, select Enable server-side content fetching and click policy
setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you enabled this setting, choose an option:
●
Disabled
●
Enabled
●
Enabled (persistent caching)
Enabled (temporary caching)
6. For the policy to take effect:
●
278
Configuring HDX MediaStream Flash Redirection on the User Device
●
Computer Configuration: Changes take effect as computers in the organizational
unit restart.
●
User Configuration: Users in the organizational unit must log off and then log on to
the network.
To redirect user devices to other servers for
client-side content fetching
You can redirect an attempt to obtain Flash content using the URL rewriting rules for
client-side content fetching setting which is a second generation Flash Redirection
feature. When configuring this feature, you provide two URL patterns using Perl regular
expression. If the user device attempts to fetch content from a Web site matching the first
pattern (the matching pattern) , it is redirected to the Web site specified by the second
pattern (the replacement pattern).
You can use this setting to compensate for content delivery networks (CDN). Some Web
sites delivering Flash content use CDN redirection to enable the user to obtain the content
from the nearest of a group of servers containing the same content. When using the Flash
Redirection client-side fetching feature, the Flash content is requested from the user
device, while the rest of the Web page on which the Flash content resides is requested by
the server. If CDN is in use, the server request is redirected to the closest server and the
user device request follows to the same location. This may not be the location closest to
the user device, however. Depending on distance, a delay between the loading of the Web
page and Flash content can occur.
1. In the Group Policy Object Editor, expand either the Computer Configuration or User
Configuration node.
2. Expand the Administrative Templates and Classic Administrative Templates (ADM)
nodes and select HDX MediaStream Flash Redirection - Client.
3. From the Setting list, select URL rewriting rules for client-side content fetching and
click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you enabled this setting, click Show and using Perl regular expression syntax, type
the matching pattern in the Value name box and the replacement pattern in the Value
box.
6. For the policy to take effect:
279
●
Computer Configuration: Changes take effect as computers in the organizational
unit restart.
●
User Configuration: Users in the organizational unit must log off and then log on to
the network.
Configuring Audio
You can configure audio through the Policies node of Citrix Desktop Studio (Citrix
XenDesktop) or Citrix AppCenter (Citrix XenApp). You control the settings for the audio
features through the following Citrix User Policy settings:
●
Audio Plug-n-Play (XenApp only)
●
Audio quality
●
Client audio redirection
●
Client microphone redirection
●
Audio redirection bandwidth limit
●
Audio redirection bandwidth limit percent
●
Audio over UDP Real-timeTransport (XenDesktop only)
●
Audio UDP Port Range (XenDesktop only)
Most audio features are transported using the ICA stream and are secured in the same way
as other ICA traffic. User Datagram Protocol (UDP) audio uses a separate, unsecured,
transport mechanism.
To set audio quality
Generally, higher sound quality requires more bandwidth and greater server CPU
utilization. You can use sound compression to balance sound quality and overall session
performance. Use policy settings to configure the compression levels you want to apply to
sound files.
Consider creating separate policies for groups of dial-up users and for those who connect
over a LAN or WAN. Over dial-up connections, where bandwidth typically is limited, users
likely care more about download speed than sound quality. For such users, create a policy
for dial-up connections that applies high compression levels to sound and another for LAN or
WAN connections that applies lower compression levels.
Configure the Audio quality setting by choosing from these audio quality levels:
●
●
280
Low - for low-speed connections for low-bandwidth connections. Sounds sent to the
client are compressed up to 16Kbps. This compression results in a significant decrease
in the quality of the sound but allows reasonable performance for a low-bandwidth
connection.
Configuring Audio
Select Medium - optimized for speech for delivering Voice over IP applications. Audio
sent to the client is compressed up to 64Kbps. This compression results in a moderate
decrease in the quality of the audio played on the client device, but provides low
latency and consumes very low bandwidth. Currently, Real-time Transport (RTP) over
UDP is only supported when this audio quality is selected. Use this audio quality even
for delivering media applications for the challenging network connections like very low
(less than 512Kbps) lines and when there is congestion and packet loss in the network.
●
Select High - high definition audio when delivering media applications. This setting
provides high fidelity stereo audio but consumes more bandwidth than the Medium
quality setting. Use this setting when network bandwidth is plentiful and sound quality
is important.
Note: High definition increases bandwidth requirements by sending more audio data
to user devices and increases server CPU utilization.
Important: You must also enable audio on Client audio settings on the user device.
To redirect audio reception
You can allow users to receive audio from an application on a server through speakers or
other sound devices, such as headphones, on their user devices. Client audio mapping may
cause more load on the servers and the network than is preferred.
Configure the Client audio redirection setting by choosing Allowed, the default, or
Prohibited.
Important: When Client audio redirection is disabled, all audio functionality is disabled.
When using XenApp, the Audio Plug-n-Play setting must be enabled to use multiple audio
devices.
Important: You must also enable audio on Client audio settings on the user device.
To activate user device microphones
You can allow users to record audio using input devices such as microphones on the user
device. To record audio, the user device needs either a built-in microphone or a device that
can be plugged into the microphone jack or USB port.
If audio is disabled on the client software, this setting has no effect.
The Client audio redirection setting must be enabled for an enabled Client microphone
redirection to work.
For security, users are alerted when servers that are not trusted by their user devices try to
access microphones. Users can choose to accept or reject access prior to using the
microphone. Users can disable the alert on the Citrix Receiver, formerly the Citrix online
plug-in.
281
Configuring Audio
Configure the Client microphone redirection setting by choosing Allowed, the default, or
Prohibited.
When using XenApp, the Audio Plug-n-Play setting must be enabled to use multiple input
devices.
Important: You must also enable audio on Client audio settings on the user device.
To set audio redirection bandwidth limits
You can set limits on the allowed bandwidth in kilobits for playing and recording audio. Use
the Audio redirection bandwidth limit setting to identify a specific maximum kilobit per
second bandwidth for a session. Use the Audio redirection bandwidth limit percent to
identify the maximum percentage of the total available bandwidth to be used. If both
settings are configured, the one with the lowest bandwidth limit is used.
Configure the Audio redirection bandwidth limit and Audio redirection bandwidth limit
percent by typing a number in the Value field.
Important: You must also enable audio on Client audio settings on the user device.
To send and receive audio with UDP
XenDesktop allows you to send and receive lossy audio with UDP using RTP.
Important: Audio data transmitted with UDP is not encrypted.
If Voice over IP (VoIP) quality is unsatisfactory at medium quality on the Audio quality
setting, you can enable the Audio over UDP Real-time Transport user policy setting.
By default, UDP audio on XenDesktop uses two consecutive ports within the range of ports
16500 to 16509 to pass through the Windows firewall. To use other ports, configure the
Audio UDP Port Range machine policy setting by typing the port number or range into the
Value field.
UDP is not available on XenApp.
Important: You must also enable audio on Client audio settings on the user device.
282
Configuring Audio
To configure audio on the user device
1. In the Group Policy Object Editor, expand either the Computer Configuration or User
Configuration node.
2. Expand the Administrative Templates and Classic Administrative Templates (ADM)
nodes and select Citrix Component > Citrix Receiver > User Experience.
3. From the Setting list, select Client Audio Settings and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you selected Enabled, select Enable audio.
6. Select a High, Medium, or Low sound quality. For UDP audio, use Medium only.
7. For UDP audio only, select Enable Real-Time Transport.
8. For UDP audio only, set the range of ports to use to pass through the Windows firewall.
This range must be consistent with the range set in the Audio UDP Port Range machine
policy.
283
Avoiding Echo During Multimedia
Conferences With HDX RealTime
When users take part in audio or video conferences, they may hear an echo in their audio.
Echoes usually occur when speakers and microphones are too close to each other. For that
reason, Citrix recommends the use of headsets for audio and video conferences.
HDX RealTime provides an echo cancellation option, enabled by default, which minimizes
echo during a conference. For echo cancellation to be most effective, the user should
select either Medium - optimized for speech or Low - for low-speed connections audio
quality. The High - high definition audio setting is intended for music playback, rather than
conference speech and should be avoided for conferences.
The effectiveness of echo cancellation is sensitive to the distance between the speakers
and the microphone. These devices must not be too close to each other or too far from
each other.
Echo cancellation is available with Citrix Receiver 3.0 for Windows and Citrix Online Plug-in
12.1 for Windows, as well as Web Interface 5.3.
To enable or disable echo cancellation
1. For 32-bit computers: On the user device, open the registry and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA
Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.
For 64-bit computers: On the user device, open the registry and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA
Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.
Caution: Editing the Registry incorrectly can cause serious problems that may require
you to reinstall your operating system. Citrix cannot guarantee that problems
resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor
at your own risk. Be sure to back up the registry before you edit it.
2. In the Value data field, type TRUE or FALSE to enable or disable echo cancellation.
284
Video Conferencing with HDX RealTime
Webcam Video Compression
HDX RealTime provides your users with a complete desktop multimedia conferencing
feature.
System Requirements for HDX RealTime Webcam
Video Compression
The following is accurate at the time this content was published. See
https://www.citrix.com/support/product-lifecycle/product-matrix for more information
about supported versions of Citrix products.
The following conditions are required to use the HDX RealTime Webcam Video Compression:
●
Install Citrix Receiver 3.0 for Windows, formerly Citrix online plug-in, or Citrix Online
Plug-in 12.1 for Windows on the user device.
●
Install Microsoft Office Communications Server 2007 in the same environment as the
computer running XenApp. This is not a published application.
Note: Best practice indicates installing Microsoft Office Communications Server 2007
on a different computer than XenApp.
●
Publish Microsoft Office Communicator 2007 on your XenApp server.
●
Ensure the user device has the appropriate hardware to produce sound.
●
Assign one processor per user per session, whether physical or virtual devices are used
for video conferencing.
●
Use the web camera default settings.
●
Enable the following policies settings:
●
Client audio redirection
●
Client microphone redirection
●
Multimedia conferencing
Windows Media Redirection
Install Drivers for web cameras on the user device. Where possible, use drivers obtained
from the camera manufacturer, rather than from a third party.
●
●
285
Video Conferencing with HDX RealTime Webcam Video Compression
Note: Only one web camera is supported at a time. If a device has multiple web
cameras attached, HDX RealTime tries the first camera found, continuing in
succession until a connection is made.
Configuring Client Audio redirection
Client audio redirection is a Citrix User Policy setting. It allows or prevents the redirection
of sound from a hosted application to a sound device on the user device. Client audio
redirection is enabled by default.
Configuring Client Microphone Redirection
Client microphone redirection is a Citrix User Policy setting. It allows or prevents the
redirection of microphones. Client microphone redirection is enabled by default.
Configuring Multimedia Conferencing
Multimedia conferencing is a Citrix Computer Policy setting. This policy allows or prevents
support for multimedia conferencing applications. By default, Multimedia conferencing is
enabled.
Configuring Windows Media Redirection
Windows Media Redirection is a Citrix Computer Policy setting. Use this setting to allow or
prohibit the delivery of streaming audio and video to users. Windows Media Redirection is
enabled by default.
286
Increasing 2D and 3D Application
Scalability and Performance
HDX 3D allows graphics-heavy applications running on XenApp on a physical server to render
on the server's graphics processing unit (GPU). By moving DirectX, Direct3D and Windows
Presentation Foundation (WPF) rendering to the server's GPU, the server's central
processing unit (CPU) is not slowed by graphics rendering. Additionally, the server is able to
process more graphics because the workload is split between the CPU and GPU. This feature
is only available on servers with a GPU that supports a display driver interface (DDI) version
of 9ex, 10, or 11. DirectX and Direct3D require no special settings.
To enable WPF applications to render using the server's GPU, in the
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple
Monitor Hook subkey in the registry of the server running XenApp, create the
EnableWPFHook key with a key type of REG_DWORD and set its value to 1.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
287
Assigning Priorities to Network Traffic
With XenApp and XenDesktop, priorities are assigned to network traffic across multiple
connections for a session with quality of service (QoS)-supported routers. Four Transmission
Control Protocol (TCP) connections are available to carry ICA traffic between the user
device and the server (XenDesktop provides an additional User Datagram Protocol (UDP)
connection). Each virtual channel is associated with a specific priority and transported in
the corresponding TCP connection. You can set the channels independently, based on the
TCP port number used for the connection. The four priorities are:
●
Very High: for realtime activities, such as webcam conferences.
●
High: for interactive elements, such as the screen, keyboard, and mouse.
●
Medium: for bulk processes, such as Client Drive Mapping (CDM).
●
Low: for background activities, such as printing.
XenDesktop supports multiple channel streaming connections only for Virtual Desktop
Agents installed on Windows 7 environments. Work with your company's network
administrator to ensure the Common Gateway Protocol (CGP) ports configured in the
Multi-Port Policy setting are assigned correctly on the network routers.
The Secure Sockets Layer (SSL) connections are only supported when the connections are
traversing an Access Gateway that supports multi-stream. When running on an internal
corporate network, multi-stream connections with SSL are not supported (this includes SSL
Relay, on the XenApp server).
Quality of service is supported only when multiple session reliability ports, or the CGP
ports, are configured.
Caution: Use transport security when using this feature. Citrix recommends using
Internet Protocol Security (IPsec) or Secure Sockets Layer ( SSL).
To assign priorities to network traffic
To set quality of service for multiple streaming connections, you must configure:
288
●
Multi-Stream, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer
Policy setting in XenApp.
●
Multi-Port Policy, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer
Policy setting in XenApp.
●
Multi-Stream, a Citrix Users Policy setting in XenDesktop and a Citrix User Policy setting
in XenApp.
Assigning Priorities to Network Traffic
1. In Machine settings (XenDesktop) or Computer settings (XenApp), open the Multi-Port
Policy Add Setting dialog box.
2. From the CGP default port priority list, select a priority.
3. Type additional CGP ports in CGP port1, CGP port2, and CGP port3, as needed, and
identify priorities for each.
4. In Machine settings (XenDesktop) or Computer settings (XenApp), open the
Multi-Stream Add Setting dialog box and select Enabled or Disabled.
5. In Users settings (XenDesktop) or User settings (XenApp), open the Multi-Stream
Connections Add Setting dialog box and select Enabled or Disabled.
Important: Firewalls on Virtual Desktop Agents or XenApp Server must be explicitly
configured to allow the additional TCP traffic as part of the Multi-Port Policy setting.
For the policies to take effect, users must log off and then log on to the network.
289
Adding Dynamic Windows Preview
Support
With the Dynamic Windows Preview feature enabled, the following Windows Aero preview
options are available to XenApp users with published applications:
●
Taskbar Preview
When the user hovers over a window's taskbar icon, an image of that window appears
above the taskbar.
●
Windows Peek
When the user hovers over a taskbar preview image, a full-sized image of the window
appears on the screen.
●
Flip
When the user presses ALT+TAB, small preview icons are shown for each open window.
●
Flip 3D
When the user presses TAB+Windows logo key, large images of the open windows
cascade across the screen.
Dynamic Windows Preview is available for user devices running:
●
Citrix Receiver 3.0 for Windows
●
Windows 7 configured for Aero
To configure Dynamic Windows Preview
Dynamic Windows Preview is enabled by default. You can disable and then enable the
feature with the Dynamic Windows Preview computer policy setting on the XenApp server.
290
Configuring Read-Only Access to Mapped
Client Drives
With the Citrix User Policy setting Read-only client drive access, you can control whether
users can copy files from their virtual environments to their user devices. This policy setting
is only applicable for XenDesktop 5.5 Virtual Desktop Agent and XenApp 6.5 VM Hosted Apps
sessions.
When enabled, files and folders on mapped client-drives cannot be added or modified from
within the session. Files and folders on mapped client-drives are available in read-only
mode only.
When disabled, files and folders on mapped client-drives are available in read/write mode
from within the session. By default, the setting is disabled.
Important: When using this setting, be sure to include Client drive redirection in the
policy and that it is set to Allowed.
291
Securing Server Farms
Consult with your organization’s security experts for a comprehensive security strategy that
best fits your needs.
The Citrix Receiver is compatible with and functions in environments where the Microsoft
Specialized Security - Limited Functionality (SSLF) desktop security template is used. These
templates are supported in the Microsoft Windows XP and Vista platforms. Refer to the
Windows XP and Windows Vista security guides available at http://technet.microsoft.com
for more information about the template and related settings.
In deployments where the XenApp server is part of an organization unit (OU) to which a
Microsoft Specialized Security Limited Functionality Member Server
(WS08R2-SSLF-Member-Server 1.0) or Enterprise Configuration Member Server
(WS08R2-EC-Member-Server 1.0) security template is applied, applications might fail to
launch for anonymous users or domain users. To avoid this, add the following groups to the
Allow Logon through Remote Desktop Services setting for servers in the OU.
292
●
For anonymous users: server-name\Anonymous for each XenApp server in the farm,
where server-name is the name of the XenApp server
●
For domain users: domain-name\Domain Users for each XenApp server in the farm,
where domain-name is the name of the domain
Securing Access to Your Servers
An important first step in securing your server farm is securing access to the servers.
Securing the AppCenter
You can use the AppCenter to connect to any server in your farm. Use it only in
environments where packet sniffing cannot occur. Also, ensure that only administrators can
access it. You can set NTFS permissions so that non-administrators do not have Execute
permission for the AppCenter executable.
Using NTFS partitions
To ensure that appropriate access control can be enforced on all files installed by XenApp,
install XenApp only on NTFS-formatted disk partitions.
Trusted Server Configuration
This feature identifies and enforces trust relations involved in client connections. This can
be used to increase the confidence of client administrators and users in the integrity of
data on client devices and to prevent the malicious use of client connections. When this
feature is enabled, clients can specify the requirements for trust and determine whether or
not they trust a connection to the server.
293
Securing the Data Store
Protecting the data store involves not only protecting the data in the data store database
but also restricting who can access it. In general:
●
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 dsmaint config command on each affected
server. Be sure to create a backup of your data store before changing the password on
your data store.
Consult the database vendor documentation for more information.
Microsoft SQL Server
The user account that is used to access the data store on Microsoft SQL Server has public
and db_owner roles on the server and database. System administrator account credentials
are not needed for data store access; do not use a system administrator account because
this poses an additional security risk.
If the Microsoft SQL Server is configured for mixed mode security, meaning that you can use
either Microsoft SQL Server authentication or Windows authentication, you may want to
create a Microsoft SQL Server user account for the sole purpose of accessing the data store.
Because this Microsoft SQL Server user account would access only the data store, there is no
risk of compromising a Windows domain if the 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.
294
Securing the Data Store
Microsoft SQL Server Express
Windows authentication is supported for the Microsoft SQL Server Express database. For
security reasons, Microsoft SQL Server authentication is not supported. The user name and
password typically are those for the local system administrator account. If users have
access to the data store server, change the password with the dsmaint config command and
keep the information in a safe place.
Oracle
Give the Oracle user account employed for the server farm "connect" and "resource"
permissions only. System administrator (system or sys) account permissions are not needed
for data store access.
295
Securing Client-Server Communications
There are two methods for encrypting the session data transmitted between clients and
servers: SecureICA and SSL/TLS encryption.
By default, all ICA communications are set to Basic ICA protocol encryption. The Basic
setting obfuscates data but does not provide industry standard encryption. You can increase
the level of SecureICA encryption up to 128-bit and/or add SSL/TLS encryption.
The difference between the two types of client-server encryption is as follows:
●
SecureICA. The SecureICA feature encrypts the session data sent between a server
running XenApp and a client. In general, increase the level of ICA protocol encryption
when you want to encrypt internal communication within a LAN or a WAN, or you want
to encrypt internal access to an intranet. Increasing the level of ICA protocol encryption
prevents session data from being sent in clear text, but it does not perform any
authentication.
●
SSL/TLS protocols. SSL/TLS protocols can protect you from internal and external
threats, depending on your network configuration. Citrix recommends that you enable
SSL/TLS protocols. Enabling SSL/TLS ensures the confidentiality, authentication, and
integrity of session data.
If you enable protection against both internal and external threats, you must enable SSL
encryption. Using SecureICA with SSL or TLS provides end-to-end encryption.
Both protocols are enabled on the server side, when you publish an application or resource.
The Web Interface and Citrix Receiver automatically detect and use the settings specified
on the server (that is, when you publish a resource).
The settings you specify for client-server encryption can interact with any other encryption
settings in XenApp and your Windows operating system. If a higher priority encryption level
is set on either a server or client device, settings you specify for published resources can be
overridden. The most secure setting out of any of the settings below is used:
●
The setting in Remote Desktop Session Host Configuration
●
The XenApp policy setting that applies to the connection
●
The client-server setting (that is, the level you set when you publish a resource)
●
The Microsoft Group Policy
When you set an encryption level, make sure that it is consistent with the encryption
settings you specified elsewhere. For example, any encryption setting you specify in the
TSCC or connection policies cannot be higher than the application publishing setting.
If the encryption level for an application is lower than what you specified through the TSCC
and connection policies, the TSCC settings and the policies override the application
settings.
296
Using SecureICA
By default, client-server communications are obfuscated at a basic level through the
SecureICA feature, which can be used to encrypt the ICA protocol.
Citrix Receiver uses the ICA protocol to encode user input (keystrokes and mouse clicks) and
address it to a server farm for processing. Server farms use the ICA protocol to format
application output (display and audio) and return it to the client device.
You can increase the level of encryption for the ICA protocol when you publish a resource or
after you publish a resource.
In addition to situations when you want to protect against internal security threats, such as
eavesdropping, you may want to use ICA encryption in the following situations:
●
You need to secure communications from devices that use Microsoft DOS or run on
Win16 systems
●
You have older devices running software that cannot be upgraded to use SSL
●
As an alternative to SSL/TLS encryption, when there is no risk of a “man-in-the-middle”
attack
When traversing public networks, Citrix does not recommend SecureICA as your only
method of encryption. Citrix recommends using SSL/TLS encryption for traversing public
networks. Unlike SSL/TLS encryption, SecureICA, used on its own, does not provide
authentication of the server. Therefore information could be intercepted as it crosses a
public network and then be rerouted to a counterfeit server. Also, SecureICA does not
check data integrity.
297
Enabling SSL/TLS Protocols
If client devices in your environment communicate with your farm across the Internet,
Citrix recommends enabling SSL/TLS encryption when you publish a resource. If you want to
use SSL/TLS encryption, you must use either the SSL Relay feature or the Secure Gateway
to relay ICA traffic to the computer running XenApp.
The nature of your environment may determine the way in which you enable SSL:
●
For client devices communicating with your farm remotely, Citrix recommends that you
use the Secure Gateway to pass client communications to the computer running
XenApp. The Secure Gateway can be used with SSL Relay on the computer running
XenApp to secure the Secure Gateway to XenApp traffic, depending on your
requirements.
●
For client devices communicating with your farm internally, you can do one of the
following to pass client communications to the computer running XenApp:
●
Use the Secure Gateway with an internal firewall and place your farm behind the
firewall
Use the SSL Relay feature to secure the traffic between servers in your farm
In larger environments, it may not be convenient to use SSL Relay because doing so requires
storing certificates on every server in your farm. In large environments, you may want to
use the Secure Gateway with an internal firewall if you are concerned with internal threats.
●
Regardless of whether you use the Secure Gateway or SSL Relay, if you want to use SSL, you
must select the Enable SSL and TLS protocols setting when you publish an application.
If you are using Web Interface with the Secure Gateway, see the information about SSL in
the Secure Gateway and Web Interface administrator documentation.
298
To configure session data encryption
The following procedure explains how to increase the level of encryption by enabling
SecureICA (ICA protocol encryption) or SSL/TLS (Secure Sockets Layer and Transport Layer
Security) encryption after you publish an application.
1. From the AppCenter, select a published application in the left pane.
2. From the Action menu, select Application properties.
3. In the Application Properties dialog box, select Advanced > Client options.
4. In the Connection encryption section, select one or more of the following:
●
Select the Enable SSL and TLS protocols check box. This option requests the use of
the SSL and TLS protocols for clients connecting to the published application.
●
In the Encryption section, select a higher level of encryption from the drop-down
list box.
If you are using SecureICA and you want to ensure that ICA traffic is always encrypted at a
certain level, you can set a policy for encryption. Creating a SecureICA policy prevents you
from accidentally publishing a resource at a lower level of encryption. If this policy is
enabled and you publish a resource at a lower level of encryption than the policy requires,
the server rejects client connections. For software that takes its encryption settings from
the server, such as the Web Interface and Citrix Receiver, this can be problematic.
Therefore, Citrix recommends as a best practice, that if you enable an encryption policy,
you publish applications (or resources) by replicating an existing published application and
editing it so as to replace the application with the new application you want to publish.
299
To set a policy for ICA encryption
The settings you specify for client-server encryption can interact with any other encryption
settings in XenApp and your Windows operating system. If a higher priority encryption level
is set on either a server or client device, settings you specify for published resources can be
overridden.
SecureICA does not perform authentication or check data integrity. To provide end-to-end
encryption for your server farm, use SecureICA with SSL/TLS encryption. SecureICA does not
use FIPS-compliant algorithms. If this is an issue, configure the server and Citrix Receiver to
avoid using SecureICA.
1. Configure the Citrix User policy SecureICA minimum encryption level setting with one
of the following options:
300
●
Basic. Encrypts the client connection using a non-RC5 algorithm. It protects the
data stream from being read directly, but it can be decrypted.
●
RC5 (128 bit) logon only. Encrypts the logon data with RC5 128-bit encryption and
the client connection using Basic encryption.
●
RC5 (40 bit). Encrypts the client connection with RC5 40-bit encryption.
●
RC5 (56 bit). Encrypts the client connection with RC5 56-bit encryption.
●
RC5 (128 bit). Encrypts the client connection with RC5 128-bit encryption.
Configuring SSL/TLS Between Servers
and Clients
For XenApp to accept connections encrypted with SSL or TLS, you must use SSL Relay to
configure support on each XenApp server.
Citrix SSL Relay can secure communications between clients, servers running the Web
Interface, and XenApp servers that are using SSL or TLS. Data sent between the two
computers is decrypted by the SSL Relay and then redirected using SOCKSv5 to the Citrix
XML Service.
SSL Relay operates as an intermediary in the communications between Citrix Receiver and
the Citrix XML Service running on each server. Each Receiver authenticates the SSL Relay by
checking the relay’s server certificate against a list of trusted certificate authorities. After
this authentication, Receiver and SSL Relay negotiate requests in encrypted form. SSL Relay
decrypts the requests and passes them to the server.
When returning the information to Receiver, the server sends all information through SSL
Relay, which encrypts the data and forwards it to the client to be decrypted. Message
integrity checks verify that each communication is not tampered with.
In general, use SSL Relay for SSL/TLS support when you:
●
Want to secure communications with servers that host the Citrix XML Service.
●
Have a small number of servers to support (five or fewer). To use SSL/TLS to protect
against internal threats in larger farms, consider configuring SSL/TLS support with
Secure Gateway.
●
Do not need to secure access at a DMZ.
●
Do not need to hide server IP addresses or you are using Network Address Translation
(NAT).
●
Need end-to-end encryption of data between clients and servers.
Configure SSL Relay and the appropriate server certificate on each XenApp server in the
server farm. By default, SSL Relay is installed with XenApp in C:\Program Files
(x86)\Citrix\SSLRelay, where C is the drive where you installed XenApp.
The Citrix XML Service provides an HTTP interface for enumerating applications available on
the server. It uses TCP packets instead of UDP, which allows connections to work across
most firewalls. The Citrix XML Service is included in the server. The default port for the
Citrix XML Service is 80.
301
Configuring SSL/TLS Between Servers and Clients
Installing and Configuring the SSL Relay Tool
If you configure the SSL Relay tool with the User Account Control (UAC) feature of Microsoft
Windows enabled, you might be prompted for administrator credentials. To run the SSL
Relay tool, you must have the following privileges and associated permissions:
302
●
Domain administrator
●
Delegated administrator
●
Administrator group of the local computer where you are installing the tool
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.
303
Choosing an SSL Certificate Authority
You can obtain and install certificates for your servers and client devices in the following
ways:
304
●
Certificates from a CA bundled with the operating system. Some of the newer Windows
operating systems include native support for many CAs. If you choose to install the
certificate from a bundled CA, double-click the certificate file and the Windows
Certificate Store wizard installs the server certificate on your server. For information
about which operating systems include native support, see your Microsoft
documentation.
●
Certificates from an enterprise CA. If your organization makes a CA accessible to you
for use, that CA appears in your list of CAs. Double-click the certificate file and the
Windows Certificate Store wizard installs the server certificate on your server. For more
information about whether or not your company uses an enterprise CA, consult your
security team.
●
Certificates from a CA not bundled with the operating system. Certificates from CAs
that are not bundled with your operating system or made accessible to you by your
organization must be installed manually on both the server running Citrix SSL Relay and
on each client device. For instructions about installing certificates from an external CA,
see the documentation for the servers and clients in your configuration. Alternatively,
you can install certificates using Active Directory or the IIS snap-in:
●
If your computers belong to an Active Directory server, you can install the
certificates using Active Directory. For instructions about how to use Active
Directory to install your certificates, see your Microsoft documentation.
●
You can use the Microsoft Web Server Certificate wizard in the IIS snap-in to
request and import a certificate. For more information about using this wizard, see
your Microsoft documentation.
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.
305
To enable the SSL Relay and select the
relay credentials
1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix >
Administration Tools > Citrix SSL Relay Configuration Tool.
2. Click the Relay Credentials tab.
3. Select the Enable SSL relay check box to enable the relay features.
4. Select the Display Friendly Name check box to display the certificate’s friendly name,
if available. This check box determines which information from the certificate appears
in the Server Certificate list. Some certificates contain an additional friendly name
field. If you check this box and no friendly name exists, the certificate’s subject
common name is used (which is typically the server name). If Display Friendly Name is
not checked, the entire subject name is used.
5. Select the server certificate from the Server Certificate drop-down box (used to
identify the SSL Relay identity).
306
Using the SSL Relay with the Microsoft
Internet Information Service (IIS)
To use the SSL Relay and Microsoft Internet Information Services (IIS) on the same server,
for example, if you install the Web Interface and XenApp on the same server, you must
change the port number that IIS or the SSL Relay use. SSL Relay uses TCP port 443, the
standard port for SSL connections. Most firewalls open this port by default. Optionally, you
can configure the SSL Relay to use another port. Be sure that the port you choose is open on
any firewalls between the client devices and the server running the SSL Relay.
Microsoft IIS is installed by default on Windows Server 2003 and allocates port 443 for SSL
connections. It is not installed by default on Windows Server 2008. To run SSL Relay on a
server running Windows Server 2003 or 2008 (with Web Server IIS installed and enabled),
you must:
●
Install a server certificate on IIS before you change the port number. You can use the
same server certificate with IIS and the SSL Relay.
●
Configure IIS to use a different port or configure the SSL Relay to use a different port.
To change the SSL port for Internet Information Services, see the relevant Microsoft
documentation.
307
Configuring the Relay Port and Server
Connection Settings
The SSL Relay relays packets only to the target computers listed on the Connection tab of
the Citrix SSL Relay Configuration Tool. By default, the SSL Relay is configured to relay
packets only to the target computer on which the SSL Relay is installed. You can add other
computers in the same server farm for redundancy.
Use the Connection tab to configure the listener port and allowed destinations for the SSL
Relay. The SSL Relay relays packets only to the target computers listed on the Connection
tab. The target server and port specified on your server running the Web Interface or Citrix
Receiver must be listed on this tab. By default, no servers are listed.
See Configuring TCP ports for a list of ports used in a server farm.
Once a certificate is added, the default ICA and Citrix XML Service ports are added for the
local computer.
●
Relay Listening Port. The TCP port where SSL clients connect to the SSL Relay. The
default port number is 443. If your server has multiple IP addresses, this port is used on
all of them. If you change this value, you must make the same change on the client
device. You may also need to open the port on any firewalls between the client device
and the SSL Relay.
●
Encryption Standard. SSL Relay can be configured to use either SSL or TLS. The
protocol that is required is configured using the SSL Relay configuration tool.
●
Server Name. The fully qualified domain name (FQDN) of the server to which to relay
the decrypted packets. If certificates are not configured, no servers are listed. If
certificates are configured, the FQDN of the server on which the SSL Relay is running
appears here.
●
Ports. The TCP ports where ICA and the Citrix XML Service are listening.
Important: If you change the default Citrix SSL Relay port, you must set SSLProxyHost to
the new port number in the Citrix Receiver icaclient.adm file. For more information, see
the Receiver administrator documentation.
308
Configuring the Relay Port and Server Connection Settings
To modify the destination server list
1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix >
Administration Tools > Citrix SSL Relay Configuration Tool.
2. Click the Connection tab.
●
To add a server to the destination server list:
a. Click New.
b. Type the FQDN of the computer in the Server Name box. (This additional server
must also be specified in the configuration of servers running the Web
Interface.)
●
c. Type the port number of the Citrix XML Service in the Destination ports box
and click Add.
To change the port for a server listed in the destination server list:
a. Select the server entry and click Edit.
b. In the Target Server Properties dialog box, select a destination port to remove
and click Delete.
c. In the field below Destination ports, type the number of the new destination
port and click Add.
309
To run the SSL Relay on port 443 without
using HTTPS
1. Stop the Microsoft Internet Information Service.
2. Configure and start the SSL Relay service.
3. Restart the Microsoft Internet Information Service.
The SSL Relay uses port 443 before IIS, including when the server is restarted.
Note: When you configure XenApp, members of the User group are allowed to edit
registry entries in the registry hive
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Secure\Citrix\Citrix SSL Relay, or
HKEY_LOCAL_MACHINE\SOFTWARE\Secure\Citrix\Citrix SSL Relay on XenApp, 32-bit
Edition. You can use the Microsoft Security Configuration and Analysis tool to prevent
members of the User group from editing these registry entries.
310
Configuring the Ciphersuites Allowed by
the SSL Relay
Use the Citrix SSL Relay Configuration Tool to configure which combinations of ciphersuites
the SSL Relay will accept from the client (a server running the Web Interface or Citrix
Receiver). The Ciphersuites dialog box lists the available and allowed ciphersuites. The SSL
Relay accepts connections only from clients that support at least one of the allowed
ciphersuites. Installing additional ciphersuites is not supported.
Available ciphersuites are grouped into GOV (Government) or COM (Commercial). Note that
GOV ciphersuites are normally used when TLS is specified. However, any combination of
ciphersuite and security protocol can be used. Contact your 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
1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix >
Administration Tools > Citrix SSL Relay Configuration Tool. Click the Ciphersuites
tab.
2. Select a ciphersuite from the left column. To allow it, click Add. To disallow it, from
the right column, click Remove.
311
Using the Secure Gateway
Use the Secure Gateway to provide SSL/TLS encryption between a secure Internet gateway
server and an SSL-enabled client, combined with encryption of the HTTP communication
between the Web browser and the Web server. Using the Secure Gateway makes firewall
traversal easier and improves security by providing a single point of entry and secure access
to your server farms.
In general, use the Secure Gateway when:
●
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 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.
312
Using the Secure Ticket Authority
The Secure Ticket Authority (STA) is responsible for issuing session tickets in response to
connection requests for published resources on XenApp. These session tickets form the basis
of authentication and authorization for access to published resources.
When you install XenApp, you also install the STA. The STA is embedded within the Citrix
XML Service.
Important: If you are securing communications between the Secure Gateway and the
STA, ensure that you install a server certificate on the server running the STA and
implement SSL Relay. In most cases, internally generated certificates are used for this
purpose.
To display STA performance statistics
In addition to monitoring the performance of the server running the Secure Gateway, Citrix
recommends monitoring the performance of the server running the Secure Ticket Authority
(STA) as part of your administrative routine.
1. Access the Performance Monitor.
2. Right-click in the right pane and click Add Counters.
3. For the location of the performance counters, select Use local computer counters.
4. From the Performance Object drop-down list, select Secure Ticket Authority.
5. Select the performance counters you want to monitor and click Add.
6. Click Close.
7. Use the Windows Performance Console controls that appear at the top of the right pane
to switch views and add counters.
Identifying Entries in the STA Log
The STA logs fatal errors to its application log, which is located in the \inetpub\scripts
directory. When creating a log, the STA uses the following format for naming log files:
stayyyymmdd-xxx.log
313
Using the Secure Ticket Authority
where yyyy is the year, mm is the month, and dd is the day of the log file creation.
The first time the STA is loaded, it creates a log file.
To view entries in the STA log, use a plain-text editor to open the log file.
If the STA does not create a log file, it may be due to lack of write privileges to the
\inetpub\scripts directory.
314
Securing Network Communications
Network communication between servers and client devices can be a security risk in any
enterprise environment. In addition to physically securing servers, most organizations install
network security measures including firewalls to isolate servers running XenApp and Web
browsers from the Internet and publicly accessible networks. To deploy XenApp on internal
networks, secure communications between the client and server by means of SSL/TLS or
other security measures.
Depending on your security needs, you can incorporate the following network
communication security components when designing XenApp deployments:
●
At the client-server level inside your network:
●
By encrypting the Independent Computing Architecture (ICA) protocol using
SecureICA
Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption
At the network level, when clients are communicating with your farm remotely across
the Internet:
●
●
●
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.
●
315
Configuring TCP Ports
This table lists the TCP/IP ports that the servers, Citrix Receiver, IMA Service, and other
Citrix services use in a server farm. This information can help you configure firewalls and
troubleshoot port conflicts with other software.
316
Communication
Default port
Configuration
Citrix AppCenter
135
Not configurable
Citrix SSL Relay
443
See Using the SSL Relay with the Microsoft
Internet Information Service (IIS)
Citrix XML Service
80
See Install and Configure
Client-to-server
(directed UDP)
1604
Not configurable
ICA sessions (clients
to servers)
1494
See ICAPORT
License Management
Console
8082
See the licensing documentation
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 IMAPORT
Remote AppCenter
to server
2513
See IMAPORT
Session reliability
2598
See Configuring Session Reliability
Using Proxy Servers
A proxy server accepts connection requests from client devices and redirects those requests
to the appropriate XenApp servers. Using a proxy server, much like using a firewall, gives
you more control over access to the XenApp servers and provides a heightened level of
security for your network. A proxy server, as opposed to a firewall, uses a different port
from that used by the XenApp servers.
For information about using proxy servers with the Citrix Receiver, see the Citrix Receiver
documentation.
Supported proxy servers are:
317
●
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
Configuring Authentication for Workspace
Control
If users log on using smart cards or pass-through authentication, you must set up a trust
relationship between the server running the Web Interface and any server in the farm that
the Web Interface accesses for published applications. Without the trust relationship, the
Disconnect, Reconnect, and Log Off (“Workspace Control”) commands fail for those users
logging on with smart card or pass-through authentication. For more information about
Workspace Control, see Ensuring Session Continuity for Mobile Workers.
You do not need to set up a trust relationship if your users authenticate to the Web
Interface or Citrix Receiver by typing in their credentials.
To set up the trust relationship, configure the Citrix Computer policy Trust XML requests
setting. The Citrix XML Service communicates information about published applications
among servers running the Web Interface and servers running XenApp.
If you configure a server to trust requests sent to the Citrix XML Service, consider these
factors:
318
●
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.
Using Smart Cards with XenApp
You can use smart cards in your XenApp environment. Smart cards are small plastic cards
with embedded computer chips.
In a XenApp environment, smart cards can be used to:
●
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.
319
Using Smart Cards with XenApp
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 Receiver or
client:
●
PC/SC software
●
Smart card reader software drivers
●
Smart card reader
Your Windows server and client operating systems may come with PC/SC, CSP, or smart
card reader drivers already present. See your smart card vendor for information about
whether these software components are supported or must be replaced with
vendor-specific software.
You do not need to attach the smart card reader to your server during CSP software
installation if you can install the smart card reader driver portion separately from the CSP
portion.
If you are using pass-through authentication to pass credentials from your client device to
the smart card server session, CSP software must be present on the client device.
Configuring XenApp for Smart Cards
A complete and secure smart card solution can be complex and Citrix recommends that you
consult your smart card vendor or integrator for details. Configuration of smart card
implementations and configuration of third-party security systems, such as certificate
authorities, are beyond the scope of this documentation.
Smart cards are supported for authenticating users to published applications or for use
within published applications that offer smart card functionality. Only the former is
enabled by default upon installation of XenApp.
The following Citrix Receivers and clients support smart cards:
●
Receiver for Windows
●
Receiver for Linux
●
Receiver for MacIntosh
●
Client for Windows-based terminals
To configure smart card support for Receiver or client users, see the Receiver or client
documentation.
320
Configuring Kerberos Logon
Citrix Receiver features enhanced security for pass-through authentication. Rather than
sending user passwords over the network, pass-through authentication leverages Kerberos
authentication. Kerberos is an industry-standard network authentication protocol built into
the Windows operating systems. Kerberos logon offers security-minded users the
convenience of pass-through authentication combined with secret-key cryptography and
data integrity provided by industry-standard network security solutions.
System requirements
Kerberos logon works only between clients and servers that belong to the same or to
trusted Windows domains. Servers must also be trusted for delegation, an option you
configure through the Active Directory Users and Computers management tool.
Kerberos logon is not available:
●
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:
321
●
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
Configuring Kerberos Logon
Limitations of Kerberos Pass-through Authentication
to XenApp
Windows supports two authentication protocols, Kerberos and NTLM, so applications such as
Windows Explorer, Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome,
Microsoft Office, and others, can use Windows pass-through authentication to access
network resources without explicit user authentication prompts.
When Kerberos pass-through authentication is used to start a XenApp session, there are
technical limitations that may affect application behavior.
●
Applications running on XenApp that depend on the NTLM protocol for authentication
generate explicit user authentication prompts or fail.
Most applications and network services that support Windows pass-through
authentication accept both Kerberos and NTLM protocols, but some do not. In addition,
Kerberos does not operate across certain types of domain trust links in which case
applications automatically use the NTLM protocol. However the NTLM protocol does not
operate in a XenApp session that is started using the Kerberos pass-through
authentication, preventing applications that cannot use Kerberos from authenticating
silently.
●
Kerberos pass-through authentication for applications expires if the XenApp session is
left running for a very long time (typically one week) without being disconnected and
reconnected.
Kerberos is based on security tickets issued by domain controllers, which impose a
maximum refresh period (typically one week). When the maximum refresh period has
ended, Windows obtains a new Kerberos ticket automatically by using the cached
network credentials that are required for the NTLM protocol. However, these network
credentials are not available when the XenApp session was started using Kerberos
pass-through authentication.
To enable Citrix XML Service DNS address resolution
Configure the Citrix Computer policy DNS address resolution setting.
To disable Kerberos logon to a server
Caution: Using Registry Editor can cause serious problems that can require you to
reinstall the operating system. Citrix cannot guarantee that problems resulting from
incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
To prevent Kerberos authentication for users on a specific server, create the following
registry key as a DWORD Value on the server:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon\ DisableSSPI = 1
You can configure Citrix Receiver to use Kerberos with or without pass-through
authentication.
322
Logging Administrative Changes to a
XenApp Farm
The Configuration Logging feature allows you to keep track of administrative changes made
to your server farm environment. By generating the reports that this feature makes
available, you can determine what changes were made to your server farm, when they
were made, and which administrators made them. This is especially useful when multiple
administrators are modifying the configuration of your server farm. It also facilitates the
identification and, if necessary, reversion of administrative changes that may be causing
problems for the server farm.
When this feature is enabled for a licensed server farm, administrative changes initiated
from the following components lead to the creation of log entries in a central Configuration
Logging database:
●
Citrix AppCenter
●
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:
323
●
Set up the Configuration Logging database
●
Define the Configuration Logging database access permissions
●
Configure the Configuration Logging database connection
●
Set the Configuration Logging properties
Logging Administrative Changes to a XenApp Farm
●
Delegate administrative permissions, as needed
The Configuration Logging feature, after it is properly enabled, runs in the background as
administrative changes trigger entries in the Configuration Logging database. The only
activities that are initiated by the user are generating reports, clearing the Configuration
Logging database, and displaying the Configuration Logging properties.
To generate a configuration logging report, use the PowerShell command
Get-CtxConfigurationLogReport. For more information, see help for
Get-CtxConfigurationLogReport or Windows PowerShell with Common Commands.
324
Setting up the Configuration Logging
Database
The Configuration Logging feature supports Microsoft SQL Server and Oracle databases; for
information about supported versions, see CTX114501.
The Configuration Logging database must be set up before Configuration Logging can be
enabled. Only one Configuration Logging database is supported per server farm, regardless
of how many domains are in the farm. When the Configuration Logging database is set up,
you also must ensure that the appropriate database permissions are provided for XenApp so
that it can create the database tables and stored procedures (preceded by
“CtxLog_AdminTask_”) needed for Configuration Logging. Do this by creating a database
user who has “ddl_admin” or “db_owner” permissions for SQL Server, or a user who has the
"connect" and "resource" roles and "unlimited tablespace" system privilege for Oracle. This is
used to provide XenApp full access to the Configuration Logging data.
The Configuration Logging feature does not allow you to use a blank password to connect to
the Configuration Logging database.
Each server in the server farm must have access to the Configuration Logging database.
Considerations for SQL Server
Only one server farm is supported per Configuration Logging database. To store
Configuration Logging information for a second farm, create a second Configuration Logging
database.
When using Windows Integrated Authentication, only fully qualified domain logons are
valid. Local user account credentials will fail to authenticate on the database server that
hosts the Configuration Logging database.
Ensure that all Citrix administrators accessing the same farm are configured to use the
same default schema. The database user who will create the Configuration Logging tables
and stored procedures must be the owner of the default schema. If you are using dbo as the
default schema, the database user must have db_owner permissions. If you are using
ddl_admin as the default schema, the database user must have ddl_admin permissions.
See the SQL Server documentation for information about managing and using schemas.
Considerations for Oracle
Only one farm is supported per schema. To store Configuration Logging information for a
second farm in the same database instance, use a different schema. Tables and stored
procedures are created in the schema associated with the user who initially configured the
Configuration Logging feature. For information about managing and using a different
schema, see the Oracle documentation.
325
Setting up the Configuration Logging Database
The user name connecting to the Oracle database should not begin with a number;
otherwise, you cannot display the log from the AppCenter.
Important: To use an Oracle database for configuration logging, the 32-bit Oracle client
must be installed on the AppCenter.
Before running the AppCenter, update the Oracle tnsnames.ora client file to include the
connectivity information needed to access the available databases.
326
Defining Database Permissions for
Configuration Logging
The first time the Configuration Logging feature is enabled, it connects to the Configuration
Logging database and discovers that the database schema does not exist. XenApp then
creates the database schema, tables, and stored procedures. To create a database schema,
XenApp needs full access to the database. After the database schema is created, full access
is no longer necessary and you have the option of creating additional users with fewer
permissions.
The following table lists the minimum permissions required to perform the Configuration
Logging tasks.
Configuration Logging task
To create log entries in the
database tables
To clear the log
To create a report
Database permissions needed
●
INSERT for the database tables
●
EXECUTE for the stored procedures
●
SELECT
●
SQL Server: for sysobjects and sysusers
●
Oracle: for sys.all_objects, and for sequence
objects and the "create session" system privilege
●
DELETE/INSERT for the database tables
●
EXECUTE for the GetFarmData stored procedure
●
SELECT
●
SQL Server: for sysobjects and sysusers
●
Oracle: for sys.all_objects, and for sequence
objects and the "create session" system privilege
●
EXECUTE for the Configuration Logging stored
procedures
●
SELECT
●
SQL Sever: for sysobjects and sysusers
Oracle: for sys.all_objects, and for sequence
objects and the "create session" system privilege
The Configuration Logging components must have access to the GetFarmData stored
procedure to find out if a Configuration Logging database is associated with a farm. If you
do not have permission to execute an existing GetFarmData stored procedure, this farm is
invisible to the Configuration Logging components.
●
327
Defining Database Permissions for Configuration Logging
Considerations for SQL Server
Before you configure the Configuration Logging database connection, grant EXECUTE
permission to the sp_databases system stored procedure to list the databases on the
database server.
The authentication mode must be the same for the database user who creates log entries in
the database tables and the database user who clears the log.
328
To configure the connection to the
Configuration Logging database
After the Configuration Logging database is set up by your database administrator and the
appropriate database credentials are provided to XenApp, use the Configuration Logging
Database wizard to configure the connection to the database.
1. From the AppCenter, select a farm.
2. From the Action menu, select Farm properties.
3. Click Configuration Logging.
4. Click Configure Database. The wizard opens.
5. Select the connection type (SQL Server or Oracle). For SQL Server, use the drop-down
list to select a SQL Server; for Oracle, select a net service name (from the Oracle
tnsnames.ora client file). You can also type the entry.
6. (SQL Server only). Select an authentication mode: Windows integrated security
(recommended) or SQL Server authentication.
7. Enter a valid user name and password for the database. Credentials are always required
(even if you are using Windows Integrated Authentication with SQL Server). The
credentials are stored using the IMA encryption feature. Each server that creates log
entries uses the credentials to connect to the Configuration Logging database.
8. (SQL Server only). Select or type the name of the database.
9. Configure connection options and connection pooling options. You can use the default
values for these settings. (For SQL Server, the possible exception is Use encryption. For
security reasons, the default value is Yes; however, if the database server to which you
are connecting does not support encryption, the connection will fail. Click Test
Database Connection on the summary page to check for encryption support.)
10. Click Test Database Connection. A display indicates whether or not the connection
established successfully.
After you configure the connection to the Configuration Logging database, you cannot set
the database back to None. To stop logging, clear the Log administrative tasks to
Configuration Logging database check box in the Configuration Logging dialog box.
329
To set Configuration Logging properties
Before you set Configuration Logging properties, configure the database and the connection
to the database. Otherwise, the Configuration Logging property fields are not active.
Full Citrix administrators can edit the Configuration Logging settings and clear the log, or
they can authorize other administrators to perform these tasks by assigning them the
delegated administration Edit Configuration Logging Settings permission. Without this
permission, ordinary administrators cannot perform these functions.
1. From the AppCenter, select a farm.
2. From the Action menu, select Farm properties.
3. Click Configuration Logging.
4. To enable Configuration Logging, select the Log administrative tasks to Configuration
Logging database check box. If you want administrators to be able to make changes to
the server farm when log entries cannot be saved to the Configuration Logging
database, select the Allow changes to the farm when logging database is
disconnected check box.
5. To prompt administrators to enter their credentials before clearing the log, select the
Require administrators to enter database credentials before clearing the log check
box.
330
Clearing Entries from the Configuration
Logging Database
It may become necessary to clear the entries in the Configuration Logging database if the
population of the tables becomes too large.
To manage which database users can clear the configuration log, Citrix recommends that
you enable the Require administrators to enter database credentials before clearing the
log check box in the Configuration Logging properties. Anyone attempting to clear the log is
prompted for database credentials.
The credentials must correspond to the authentication mode you selected when you
connected to the database initially. Specifically:
●
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:
331
●
From the AppCenter, expand the farm node and select History. Select Clear history in
the Actions pane or the Action menu.
●
Use the PowerShell command Clear-XAConfigurationLog. For more information, see help
for Clear-XAConfigurationLog or Windows PowerShell with Common Commands.
Encrypting Configuration Logging Data
Independent Management Architecture (IMA) is the underlying architecture used in XenApp
for configuring, monitoring, and operating all XenApp functions. The IMA data store stores
all XenApp configurations.
IMA encryption protects administrative data used by Configuration Logging. This information
is stored in the IMA data store. For IT environments with heightened security requirements,
using IMA encryption provides a higher degree of security for Configuration Logging. One
example would include environments that require strict separation of duties or where the
Citrix Administrator should not have direct access to the Configuration Logging database.
IMA encryption is a farm-wide setting that applies to all servers in the farm after encryption
is enabled. Consequently, to use IMA encryption, you must enable it on all servers in the
farm. IMA encryption has the following components:
Component
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.
332
Encrypting Configuration Logging Data
Storing CTXKEYTOOL Locally
1. Copy the CTXKEYTOOL.exe file from the Support folder of XenApp media to your local
computer.
2. Create a folder named Resource at the same level in your directory structure as the
CTXKEYTOOL file.
3. Copy the entire Support\Resource\en folder to the new Resource folder.
You can store the CTXKEYTOOL.exe file and the Resource\en folder anywhere on your
computer, provided you maintain the same relative directory structure used on the media.
333
To generate a key and enable IMA
encryption on the first server in a farm
Before enabling IMA encryption on the first server in the XenApp farm (that is, the server on
which you created the farm), install and configure XenApp, and restart the server.
1. On the server where you created the XenApp farm, run CTXKEYTOOL with the generate
option, specifying the full UNC or absolute path (including the file name of the key you
want to generate) to the location where you want to store the file key.
Citrix suggests naming the key after the farm on which it will be used; for example,
farmakey.ctx. Citrix also suggests saving the key to a folder that uses the name of your
farm; for example, Farm A Key.
If the key file generates successfully, the message “Key successfully generated"
appears.
2. To obtain the key from the file and put it in the correct location on the server, run
CTXKEYTOOL with the load option on the server on which you want to add the key,
specifying the full UNC or absolute path (including the key file name) to the location
where you stored the key file. If the key loaded successfully, the message “Key
successfully loaded” appears.
3. Run CTXKEYTOOL with the newkey option to use the currently loaded key and enable
the key. If IMA encryption is enabled successfully, the message “The key for this farm
has been replaced. IMA Encryption is enabled for this farm” appears.
Storing the Key File on a Shared Network Location
If you choose to store the key on a shared network location, Citrix recommends the
following:
●
Give the folder a meaningful name that specifies the name of the farm for which the
key was created. This is important in situations when you follow the Citrix best practice
recommendation of creating a unique key for the farm.
●
Ensure that the account you use to generate the key is the same as the account that
will be used to configure all the servers in the farm. You must use the same account for
both tasks.
1. When you generate the key file, save it to a local directory (as you normally would).
2. After enabling IMA encryption on the server where you generated the key, copy the key
file to the shared network location.
3. Grant Read/Execute access to the key file for each server that will be joining the farm,
and to the administrator performing the installation.
334
To load a key on servers that join the farm
Before enabling IMA encryption on servers you are joining to a XenApp farm, install and
configure XenApp, but do not restart the server.
1. If you do not have the key file on a shared network location, load the key file to the
server.
2. To obtain the key from the file and put it in the correct location on the server, run
CTXKEYTOOL with the load option, specifying the full UNC or absolute path (including
the key file name) to the location where you stored the key file. If the key loaded
successfully, the message “Key successfully loaded” appears. You do not need to enable
IMA encryption on this server, because you already enabled it on the first server in the
farm
3. Restart the server.
Repeat this procedure on all servers you configure to join the farm.
Changing Farms
If you move a server that has IMA encryption to a farm that has IMA encryption enabled, run
CTXKEYTOOL with the load option (specifying the key that was generated for the new farm)
on that server is configured but before it is restarted.
If you move a server that has IMA encryption enabled to a farm that does not have IMA
encryption enabled, IMA encryption is disabled automatically on the server being moved.
335
Managing IMA Encryption
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
backup option.
●
You can recreate a key file that you accidentally deleted, lost, or overwrote. All servers
in the same farm use the same key, so you can obtain a key from another server on the
farm; however, XenApp does not allow you to access keys. You must recreate the entire
key file by running CTXKEYTOOL with the backup option on any server in the farm that
has the key and is functioning properly.
●
You can disable IMA encryption by running CTXKEYTOOL with the disable option.
Because IMA encryption is a farm-wide feature, disabling it on one server disables the
feature on all servers.
If you disable IMA encryption, to access the Configuration Logging database, you must
reenter the password for the Configuration Logging database. In addition, no
configuration information is logged until you reenter your database credentials.
To reenable IMA encryption after you disabled it, run CTXKEYTOOL with the enable
option. After enabling IMA encryption, Citrix recommends that you run CTXKEYTOOL
with the query option to verify that IMA encryption is enabled.
For more information about CTXKEYTOOL, see the XenApp Command Reference
documentation.
336
XenApp Service Account Privileges
These tables provide information about the services installed by default with XenApp, their
accounts, associated permissions, and privileges.
XenApp Services Overview
This table lists the display name for the service, which is the name that appears in the
Services panel. When the display name and the service name differ, the table provides
service name in (parentheses). The Dependencies column lists the system components, such
as Windows services, Citrix services, or drivers, on which the service depends. The
Dependencies column also includes subdependencies that might not appear on the
Dependencies tab for the service.
Licensing services, which are not listed here, might also appear if the license server is
installed on the same server as XenApp.
337
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/ManualEnhances
resource
management
across multiple
CPUs. Installed
only on servers
that have
multiple CPUs.
None
XenApp Service Account Privileges
338
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
Receiver and
XenApp.
Windows
Management
Instrumentation
Driver
Extensions
Citrix End User
Experience
Monitoring
(Citrix EUEM)
SemsService.exe
Local Service/
Manual
Collects and
collates
end-user
experience
measurements.
Citrix SMC
Support
Driver
Citrix Health
HCAService.exe
Monitoring and
Recovery
(CitrixHealthMon)
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)
NT AUTHORITY\
NetworkService/
Automatic
Provides
management
services in the
XenApp farm.
Citrix
Services
Manager
service,
IPsec Policy
Agent,
Remote
Procedure
Call (RPC),
TCP/IP
Protocol
Driver,
Server,
Windows
Management
Instrumentation
Driver
Extensions,
Workstation
ImaSrv.exe
XenApp Service Account Privileges
Citrix MFCOM
Service
(MFCom)
mfcom.exe
NT AUTHORITY\
NetworkService/
Automatic
Provides COM
services that
allow remote
connections
from the
management
tools.
Remote
Procedure
Call (RPC),
Citrix
Independent
Management
Architecture
service,
Citrix
Services
Manager
service
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
Provides
XenApp with an
interface to
the operating
system. Other
services use
this services for
elevated
operations.
None
Citrix Services
IMAAdvanceSrv.exeLocal System
Manager
/Automatic
(IMAAdvanceSrv)
339
Citrix
Streaming
Service
(RadeSvc)
RadeSvc.exe
.\Ctx_StreamingSvc Manages the
/Automatic
Citrix Offline
Plug-in when
streaming
applications.
Remote
Procedure
Call (RPC)
Citrix Virtual
Memory
Optimization
CTXSFOSvc.exe
Local System
/Manual
None
Dynamically
optimizes
applications
running on a
XenApp server
to free up
server memory.
XenApp Service Account Privileges
Citrix WMI
ctxwmisvc.exe
Service
(CitrixWMIservice)
NT AUTHORITY\
Local
Service/Manual
Provides the
Citrix WMI
classes for
information
and
management
purposes.
Citrix
Independent
Management
Architecture
service ,
Citrix
Services
Manager
service,
IPsec Policy
Agent,
Remote
Procedure
Call (RPC),
TCP/IP
Protocol
Driver,
Server,
Windows
Management
Instrumentation
Driver
Extensions,
Workstation
Citrix XML
Service
(CtxHttp)
Network Service
/Automatic
Services XML
data requests
sent by XenApp
components
None
NT AUTHORITY\
NetworkService
/Manual
Services
network
requests for
session
reliability and
SSL from
XenApp
components.
None
ctxxmlss.exe
Citrix XTE
XTE.exe
Server
(CitrixXTEServer)
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.
340
Account Name
Permissions
Notes
Local Service
Limited
NT AUTHORITY\LocalService
Network Service
Limited, network resources
NT AUTHORITY\NetworkService
Local System
Administrator
NT AUTHORITY\System
XenApp Service Account Privileges
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. Ensure the new account has the same privileges as the
default account.
Privileges
Local
Service
Network
Service
Change the
system time
x
x
Generate
security audits
x
x
Increase
quotas
x
x
Log on as a
batch job
x
Log on as a
service
Replace a
process level
token
Debug
programs
Ctx_ConfigMgr
Ctx_CpuUser
x
x
x
x
x
x
x
x
x
x
Increase
x
scheduling
priority
Citrix does not support changing the account for the Citrix Streaming Service
(Ctx_StreamingSvc), which has the privileges: log on as a batch job, log on as a service,
backup files and directories, restore files and directories, deny log on locally, deny remote
log on, and take ownership of files or other objects.
341
Maintaining Server Farms
A server farm is a group of servers running Citrix XenApp and managed as a single entity.
The servers in the server farm share a single IMA-based data store.
Citrix recommends performing farm maintenance tasks from the data collector, assuming
no applications are published on the data collector, because this updates farm data faster.
Performing farm maintenance tasks from a server hosting published applications can slow
down users trying to connect to published applications and take longer to update in the
data store.
The Citrix AppCenter provides a wide variety of summary information about the farm and
each server in the farm. You can customize your view and group applications or servers in
folders to make navigating through their AppCenter listings easier. Folders are also useful
for Object Based Delegated Administration. Grouping servers into folders can facilitate the
process of delegating administrative tasks to Citrix administrators.
From the Start menu, select All Programs > Citrix > Management Consoles and choose
Citrix AppCenter.
When you select an item in the navigation pane, the Actions pane provides quick access to
related options for the selected item.
In addition, configure Citrix policy settings in the AppCenter or the Local Group Policy
Editor, depending on whether or not you use Active Directory in your XenApp environment.
Use these settings to maintain the farm, including scheduling restarts, optimizing and
monitoring server performance, and setting the port for the Citrix XML Service and License
Server. For more information, see the Policy Settings Reference.
342
To search for objects in your farm
XenApp provides an advanced search feature so that you can search for the objects in your
farm such as discovered items, sessions or applications by user, and servers that do not
have a specific hotfix applied to them.
1. From the Citrix AppCenter, in the navigation pane, select Search, and in the Actions
pane, select Search for items.
2. In the Advanced Search dialog box, in the Find box, select one of the following:
●
Discovered items. Searches discovered items.
●
Sessions By User. Lists the sessions to which a specific user is connected. Type a
user name in the Name box.
●
Applications By User. Lists the applications that the specified user is using. Type a
user name in the Name box.
Servers without hotfix. Lets you search for all of the servers missing a specific
hotfix. This feature is useful if you want to check that you applied a hotfix to all
servers in your farm. Type a hotfix number in the Name box.
3. Use the Browse button to select one of the Citrix Resources locations to search in.
●
343
To change a server's desktop settings
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 Session
Host Configuration.
1. Configure the Citrix policies setting for Desktop launches to Allowed. If it is set to
Prohibited, this feature fails.
2. From the Citrix AppCenter, select a server.
3. In the Actions pane, select Other Tasks > Connect to server, and choose one of the
following settings:
●
Connect to server’s published desktop
Connect directly to server's desktop
4. In the Launch ICA Desktop Session dialog box, choose from the following selections.
The selections you make here become the new default settings.
●
344
●
Accept the Width and Height values (800 x 600 by default) or specify a different
resolution.
●
Colors (Better Speed by default). Select the color depth for the application. The
available options are 256 colors (8-bit), Better Speed (16-bit), or Better Appearance
(32-bit).
●
Encryption. Select one of the following options from the list.
●
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.
To limit the number of server connections
per user
When a user starts a published application, the client establishes a connection to a server in
the farm and initiates a client session. If the user then starts another published application
without logging off from the first application, the user has two concurrent connections to
the server farm. To conserve resources, you can limit the number of concurrent
connections that users can make.
Configure the Citrix Computer policy for Server Settings > Connection Limits by setting
the following options:
●
Limit user sessions. Specify the maximum number of concurrent connections a user can
make to any single server at the same time (value range 0 - 8192).
●
Limits on administrator sessions. Enable or disable connection limit enforcement for
Citrix administrators.
Important: Limiting connections for Citrix administrators can adversely affect their
ability to shadow other users.
●
345
Logging of logon limit events. Enable or disable the logging of events (to the server
log) about connection attempts that are denied because they exceed logon limits.
To enable or deny logons to servers
By default, logons are enabled for each server in a farm, allowing connections,
reconnections, and session sharing. Before taking a server offline, such as for maintenance,
use these options to reroute logons to other servers.
Citrix recommends that you drain the server slowly by denying new logons (rerouting them
to other servers), but allowing users to reconnect to disconnected sessions and close
applications cleanly, thus preventing loss of user data.
Important: Citrix strongly recommends that you use these Logon control options (instead
of the Windows Remote Desktop Services options) to control logons to XenApp servers.
1. From the Citrix AppCenter, select the server.
2. From the Actions menu, select Other Tasks > Logon control and one of the following:
●
Allow logons and reconnections. Enable all logons, reconnections, and session
sharing (default setting).
●
Prohibit logons and reconnections. Reroute all logons, reconnections, and session
sharing to other servers.
●
Prohibit logons only. Reroute new connections and session sharing, but allowing
users to reconnect to disconnected sessions. This state persists until you change it
manually.
Prohibit logons until server restart. Reroute new connections and session sharing,
as above, but after restarting the server, the setting automatically changes back to
Allow logons and reconnections.
After resetting logon control, the selected option does not appear in the list.
●
346
Restarting Servers at Scheduled Times
To optimize performance, you can restart servers automatically at specified intervals by
creating a restart schedule.
Restart schedules are based on the local time for each server to which they apply. This
means that if you apply a schedule to servers that are located in more than one time zone,
the restarts do not happen simultaneously; each server is restarted at the selected time in
its own time zone.
When the Citrix Independent Management Architecture (IMA) service starts after a restart,
it establishes a connection to the data store and updates the local host cache. This update
can vary from a few hundred kilobytes of data to several megabytes of data, depending on
the size and configuration of the server farm.
To reduce the load on the data store and to reduce the IMA service start time, Citrix
recommends maintaining restart groups of no more than 100 servers. In large server farms
with hundreds of servers, or when the database hardware is not sufficient, restart servers
in groups of approximately 50, with at least 10 minute intervals between groups.
To create a server restart schedule, enable the Scheduled reboots setting and configure
related policy settings for frequency, start date and time, and warnings to users.
Additionally, configure the Reboot schedule randomization interval setting which prevents
servers in the same local time zone from restarting at the same time. The interval value
represents the number of minutes before or after the scheduled restart time at which the
servers can be restarted. When added to a policy, this setting distributes server restarts in
a uniform manner within the interval specified. For example, if the reboot schedule time is
11:00 PM and the randomization interval is 15 minutes, the servers can be restarted
between 10:45 PM and 11:15 PM.
347
Removing and Reinstalling XenApp
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 Citrix AppCenter, or repair
the installation.
In addition, see the procedures in this section for related tasks, including moving or
removing a server from the farm and renaming a XenApp server.
Removing XenApp
Citrix recommends that you remove XenApp by using Control Panel > Programs and
Features while the server is still connected to the farm and the network. Select Citrix
XenApp <version>, click Uninstall. After the program is finished, restart the server.
This method removes the host information from the farm data store and removes the server
from the farm properties displayed in the management tools.
To remove XenApp remotely, you can do so from within a Remote Desktop Connection
(RDC) session or using tools such as Microsoft Configuration Manager 2007 (formerly Systems
Management Server (SMS)).
If you want to remove only specific components of XenApp, do so in the following order:
348
●
Citrix Management (such as Citrix AppCenter)
●
XenApp Advanced Configuration utility or Presentation Server Console, if installed
●
Citrix XenApp
●
Citrix Web Interface
●
Citrix Licensing
Removing and Reinstalling XenApp
Forcing the Removal of XenApp
To force the removal of XenApp from a computer, you can use msiexec on a command line
to add the property: CTX_MF_FORCE_SUBSYSTEM_UNINSTALL. Set its value to Yes.
The following sample command line enables logging of the uninstallation operation and
forces the removal of XenApp:
msiexec /x mps.msi /L*v c:\output.log
CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=Yes
where mps.msi is the name and location of the msi package.
Repairing a XenApp Installation
Before you start, log off from all sessions and exit any applications running on the server.
After you finish, restart the server when prompted.
When you run the repair utility from Control Panel > Programs and Features, XenApp
overwrites all files and settings with those from the original installation. If you customized
any of the files or features in your XenApp installation, running the repair utility replaces
your customizations with the original files and settings.
Reinstalling XenApp Due to Hardware Failure
If the hardware for a server fails and needs to be replaced, change its name to the same
name as the failed server before you connect its replacement server to your network.
Assigning the replacement server the failed 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 Command Reference and Data Store Database
Reference documentation.
349
To rename a XenApp server
Caution: Using Registry Editor incorrectly can cause serious problems that can require
you to reinstall the operating system. Citrix cannot guarantee that problems resulting
from incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Make sure you back up the registry before you edit it.
1. Create a Citrix local administrator account on the server you want to rename.
2. On the server you want to rename, run chglogon /disable to prevent users from logging
on to the server.
3. Open Citrix AppCenter on a different server, and remove the server to be renamed from
published applications assigned to that server.
4. On the server you want to rename, stop the Citrix Independent Management
Architecture (IMA) service.
5. In the Registry, set the HKEY_LOCAL_MACHINE\SOFTWARE\
Wow6432Node\Citrix\IMA\RUNTIME\PSRequired registry value to 1.
Caution: Not changing the PSRequired registry value to 1 can result in incomplete
records in the data store. Changing this value to 1 forces the Citrix Independent
Management Architecture service to communicate with the data store and create a
record for the newly named server.
The value for PSRequired reverts to 0 the next time the Citrix Independent Management
Architecture service restarts.
6. Change the name of the server in the server operating system and restart the server.
7. Log on to the console using the local administrator account you created.
8. Update all references to the old server to the new server name. For versions prior to
6.0, this might require logging on to the XenApp Advanced Configuration tool or
Presentation Server Console as well.
Important: Before removing the old server name, change all objects that reference
the old name to the new server name, including data collector ranking, published
application references, load evaluators, and zone settings.
9. Expand the Servers folder and remove the old server name from the list of servers.
10. Add the new server name to the list of configured servers for published applications.
350
To move or remove a server
To move a XenApp server from the farm or join the server to another farm, use XenApp
Server Configuration Tool accessed through the Server Role Manager. Alternatively, use the
command-line through XenAppConfig.exe. Both methods remove the server from the farm
data store and from the lists of servers displayed in the AppCenter.
If the hardware for a server fails or it cannot be started to run the uninstall program,
remove the server. Citrix recommends that you use the Citrix AppCenter to remove a server
from the farm only in cases where the server cannot be started to run the Windows
uninstall program.
Caution: If you remove all servers belonging to a single domain and have Citrix
administrators in the domain, their user accounts cannot be enumerated by the
AppCenter and appear as a question mark (?) in the list of Citrix administrators.
To remove a server from a farm
1. With the server connected to the network and online in the farm, remove XenApp from
the server from Control Panel > Programs and Features by selecting Citrix XenApp
<version> and selecting Uninstall.
2. On a different server in the farm, open the AppCenter, run or rerun Discovery, and
check that the server was removed from the farm successfully. If the server from which
you removed XenApp still appears in the AppCenter:
a. In the left pane, select the server.
b. From the Action menu, select Other Tasks > Remove from farm.
3. After you ensure the server no longer appears in the farm, disconnect the server from
the network.
Caution: Do not reconnect the server to the network until you re-image it or remove
its XenApp software. If it reconnects to the network, it can corrupt your farm.
4. Run the dscheck command on the data store to repair any consistency errors.
5. Perform a new installation of operating system (that is, a “clean” installation and not
an upgrade) and XenApp (if you want to reuse the hardware for that server).
351
Monitoring Server Performance with
Health Monitoring & Recovery
You can use Health Monitoring and Recovery to run tests on the servers in a server farm to
monitor their state and discover any health risks. Citrix provides a standard set of tests; you
have the option of importing additional tests, including custom tests that you develop. The
Citrix tests included with XenApp allow you to monitor several services and activities
including Remote Desktop Services, XML Service, Citrix IMA Service, and logon/logoff
cycles.
By default, Health Monitoring and Recovery is enabled on all of the servers in your farm,
and the tests that are included run on all servers, including the data collector. Typically,
you do not need to run these tests on the data collector because, particularly in a large
farm, the data collector is not used for serving applications. If you do not want Health
Monitoring & Recovery to run on the data collector, you must disable it manually.
Store all custom tests in the following location:
%Program Files%\Citrix\HealthMon\Tests\Custom\
where %Program Files% is the location in which you installed XenApp. When saving custom
tests, do not include spaces in the file names.
Configure the Citrix Computer policy for Server Settings > Health Monitoring and
Recovery by setting the following options:
●
Health monitoring (enabled by default). Use this setting to allow or prevent the Health
Monitoring and Recovery feature.
●
Health monitoring tests. Use this setting to specify which tests to run. Select from a
standard set of Citrix tests (described below) or add your own customized tests. For
descriptions of recovery actions, see Modifying Health Monitoring and Recovery
Actions.
●
Maximum percent of servers with logon control (10 percent by default). Use this
setting to specify the percentage of servers that can be offline and excluded from load
balancing.
For information about draining a server before taking it offline, see To enable or deny
logons to servers.
Use the load balancing feature of XenApp with Health Monitoring and Recovery to ensure
that if a server in the farm experiences a problem (for example the Citrix IMA Service is
down), the state of that server does not interfere with the 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 Load
Management section in eDocs.
352
Monitoring Server Performance with Health Monitoring &amp; Recovery
Citrix Tests
Citrix IMA Service test
This test queries the service to ensure that it is running by enumerating the applications
available on the server.
Logon monitor test
This test monitors session logon/logoff cycles to determine whether or not there is a
problem with session initialization or possibly an application failure. If there are
numerous logon/logoff cycles within a short time period, the threshold for the session is
exceeded and a failure occurs. The session time, interval, and threshold can be
configured by modifying the parameters in the Test file field. These parameters are
listed and described in the following table.
Logon monitor test
parameter
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.
353
Monitoring Server Performance with Health Monitoring &amp; Recovery
Before running this test, ensure the permissions of the files and registry keys that the
test accesses are set properly. To do this, run the LHCTestACLsUtil.exe file located in
C:\Program Files (x86)\Citrix\System32 of the XenApp server. To run this utility, you must
have local administrator privileges.
Check XML Threads test
This test inspects the threshold of the current number of worker threads running in the
Citrix XML Service. When running this test, use a single integer parameter to set the
maximum allowable threshold value. The test compares the current value on the XenApp
server with the input value. A failure occurs if the current value is greater than the input
value.
Citrix Print Manager Service test
This test enumerates session printers to determine the health of the Citrix Print Manager
service. A failure occurs if the test cannot enumerate session printers.
Microsoft Print Spooler Service test
This test enumerates printer drivers, printer processors, and printers to determine
whether or not the Print Spooler Service in Windows Server 2008 is healthy and ready for
use
ICA Listener test
This test determines whether or not the XenApp server is able to accept ICA connections.
The test detects the default ICA port of the server, connects to the port, and sends test
data in anticipation of a response. The test is successful when the server responds to the
test with the correct data.
354
Using Citrix Performance Monitoring
Counters
Performance monitoring counters for ICA data are installed with XenApp and can be
accessed from Performance Monitor, which is part of the Windows operating system.
Performance monitoring provides valuable information about utilization of network
bandwidth and helps determine if a bottleneck exists.
By using Performance Monitor, you can monitor the following counters:
●
Bandwidth and compression counters for ICA sessions and computers running XenApp
●
Bandwidth counters for individual virtual channels within an ICA session
●
Latency counters for ICA sessions
1. On the server where XenApp is installed, open the Server Manager console.
2. In the Tree view, select Diagnostics > Performance > Monitoring Tools > Performance
Monitor.
3. From the menu bar, selection Action > Properties.
4. In the Performance Monitors dialog box, select the Data tab.
5. Click Add.
6. In the Add Counters dialog box, from the Select counters from computer drop-down
list, ensure Local computer is selected.
7. In the Available counters list, select ICA Session.
8. To add all ICA counters, in the Available counters list, select ICA Session. To add one
or more ICA counters, click the plus sign next to ICA Session and select the individual
counters to be added.
9. Select All instances to enable all instances of the selected ICA counters, No instance,
or Select instances from list and highlight only the instances you need. In Performance
Monitor, the instance list contains all active ICA sessions, which includes any session
(shadower) that is shadowing an active ICA session (shadowee). An active session is one
that is logged on to successfully and is in use; a shadowing session is one that initiated
shadowing of another ICA session.
Note: In a shadowing session, although you can select ICA counters to monitor, you
see no performance data for that session until shadowing is terminated.
10. Click Add and then click Close.
355
Using Citrix Performance Monitoring Counters
You can now use Performance Monitor to view and analyze performance data for the
ICA counters you added. For more information about using Performance Monitor, see
your Windows documentation.
356
Using Worker Groups for Enhanced
Resource Access
Worker groups are collections of XenApp servers, residing in the same farm, that are
managed as a single unit. Using worker groups, you can:
●
Streamline application publishing to multiple farm servers
●
Load balance access to published resources
●
Filter policies so that settings are applied only to sessions hosted on a specific set of
farm servers
●
Assign load evaluators to multiple farm servers
When using worker groups, consider the following:
●
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:
357
Using Worker Groups for Enhanced Resource Access
●
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
●
A worker group preference list to determine the servers to which users are directed
when logging on
When you create a load balancing policy, configure a filter so that the load balancing policy
can be applied to users when they access published resources. If you do not configure a
filter, the load balancing policy will have no effect when users log on. As with other Citrix
policies, you can filter based on access control, client IP address, client name, and users.
Important: Load balancing policies that are filtered based on client name have no effect
on sessions created through Web Interface. This is because Web Interface does not
provide the actual client name during load balancing. Instead, Web Interface overrides
the client name when load balancing policies are evaluated, prior to session launch.
When the session launches, Web Interface provides the correct client name.
Additionally, to ensure users are directed to the appropriate servers, create a worker group
preference list to prioritize the servers that users can access. A priority of 1 is considered
the highest priority. When a user launches a published application, the load balancing
policy directs the user to servers in the highest priority worker groups first. Users are
directed to servers in lower priority worker groups if servers in the higher priority worker
groups are offline or have reached maximum capacity. Users are not directed to servers in
worker groups that are not included in the worker group preference list. If a user attempts
to launch an application that is not installed on any servers in any of the listed worker
groups, regardless of priority, the launch attempt fails and an error is logged to the
Application event log on the data collector.
After you create load balancing policies, you prioritize them just as you would any other
Citrix policy. If multiple load balancing policies apply to a single user, XenApp uses the
worker group preference list from the highest priority policy to direct the user. Preference
lists from lower priority load balancing policies are not considered.
Using Worker Groups to Filter Policies
You can use the Worker Group filter in Citrix policies to apply policy settings to
connections. When adding the filter, you can specify worker groups by entering the name or
by selecting worker groups from a list.
When entering worker groups by name, be aware that the policy engine does not check to
ensure the accuracy of the entry. If the worker group name is entered incorrectly, or if the
worker group is renamed or deleted, the policy engine does not recognize the filter and the
policy filter is not applied.
To ensure the worker groups specified are correctly entered, click the Browse button on
the Add Filter Element dialog box. This enables XenApp to assemble a current list of
358
Using Worker Groups for Enhanced Resource Access
worker groups in the farm. Although you can add multiple worker groups to the filter, you
can select only one worker group from the list at a time.
Note: When adding worker groups to the filter for the first time, the list of available
worker groups appears after a delay of several seconds. However, this delay is reduced
when adding subsequent worker groups to the filter.
Using Worker Groups to Assign Load Evaluators
To participate in load management, each XenApp server must have a load evaluator
assigned to it. When assigning a load evaluator to farm servers, you add the Load Evaluator
Name policy setting to a new or existing Citrix policy and select the load evaluator you
want to assign. To specify the XenApp servers to be managed, you add the Worker Group
filter to the policy and specify the worker group by name.
359
To create a worker group
1. From the Citrix AppCenter, select the Worker Groups node in the left pane.
2. From the Actions pane, click Create Worker Group.
3. In the Create Worker Group dialog box, type a name for the worker group.
4. In Select source, select one of the following options:
●
Select Active Directory Containers to add servers based on organizational unit
membership.
●
Select Active Directory Server Groups to add servers based on membership in a
specific group.
Select Farm Servers to add individual XenApp servers to the worker group. Use this
option if you do not use Active Directory in your environment.
5. Click Add.
●
6. Select the groups of servers you want to add to the worker group. For example, if you
selected Active Directory Containers in the previous step, select the organizational
units that contain the servers you want to add to the worker group.
Note: Only XenApp servers that reside in the same farm are included in the worker
group. If an organizational unit contains XenApp servers that reside in other farms,
those servers are not considered part of the worker group.
360
Creating and Prioritizing Load Balancing
Policies
1. From the Citrix AppCenter, select the Load Balancing Policies node in the left pane.
2. From the Actions pane, click Create load balancing policy.
3. Under Filters, select the filter to use to determine when the load balancing policy is
applied.
4. Under Load Balancing Policies, select Worker Group Preference and then select
Configure application connection preference based on worker group.
5. Click Add and select the worker group you want to include.
6. Click Add to add the worker group to the list. Each worker group you add is
automatically assigned a priority, from highest (1) to lowest.
7. To adjust the priority of the worker groups in the list, select a worker group and then
perform one of the following actions:
●
Click Set priority and enter the priority level you want for the worker group.
Entering a priority for a worker group does not affect the priority of any other
worker group in the list. Multiple worker groups can share the same priority.
●
Click Increase Priority or Decrease Priority to adjust incrementally the priority of
the worker group.
To adjust the priority of a load balancing policy
1. From the AppCenter, select the Load Balancing Policies node in the left pane.
2. From the middle pane, select a load balancing policy.
3. From the Actions pane, perform one of the following actions:
361
●
Click Set priority and enter the priority level you want for the policy.
●
Click Increase priority or Decrease priority as appropriate to adjust incrementally
the priority of the policy.
Enhancing the Performance of a Remote
Group of Servers
For business continuity, you can specify that if all servers in a worker group go offline,
XenApp redirects user connections to a backup worker group. This feature is known as
Worker Group Preference and Failover; you configure it in the Citrix AppCenter through the
Load Balancing Policies.
As a best practice, to keep ICA traffic from going over the WAN, you should:
●
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.
362
Using Preferential Load Balancing
Preferential Load Balancing assigns importance levels (Low, Normal, or High) to specific
users and applications. For example, doctors and nurses in a hospital are specified as
important users and MRI scans and X-rays are specified as important applications. These
important users and applications with higher levels of service connect to their sessions
more quickly and have more computing resources available to them. By default, a Normal
level of service is assigned to all users and applications.
Preferential Load Balancing calculates importance levels based on the Resource Allotment
for each session. The Resource Allotment is determined by the importance levels of both
the session and the published application that the session is running.
To enable Preferential Load Balancing, configure the Citrix Computer policy setting for
Server Settings > Memory/CPU > CPU management server level and select Preferential
Load Balancing.
Continue by configuring the Citrix User policy setting for Server Session Settings > Session
importance by setting the Value (High, Normal, Low). Sessions with higher importance
levels are directed to servers with lower resource allotments.
Finally, set the application importance level when publishing the application. You can
modify an application's importance level in the Limits section of the application properties.
363
Resource Allotment
Resource Allotment is calculated based on the published application importance level and
the result of the XenApp policy engine for that session. The policy engine bases the session
result on the session importance policy setting.
A 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.
364
Resource Allotment
The three application importance settings have Resource Allotment values associated with
them, as do the three session importance policy settings. To determine the effective
Resource Allotment associated with a session running the published application, multiply
the application importance value by the session importance policy value. The most
powerful session is one with a high importance policy setting (3) running a high importance
application (3), with a total Resource Allotment of 9 (3x3). Conversely, the least powerful
session is one with a low importance policy setting (1) running a low importance application
(1), with a total Resource Allotment of 1 (1x1).
Use this table to help determine how to set your importance levels for applications and
sessions.
Resource Allotments based on importance levels
365
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
Resource Allotment
366
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
Multiple Published Applications in the
Same Session
Session sharing allows multiple published applications to run in the same session. During
session sharing, the Resource Allotment is calculated based on the maximum application
importance level setting of all the published applications running in the session multiplied
by the session importance policy setting.
When an application is launched in an existing session, the importance level of the new
application is compared with the maximum of all current application importance levels. If
the importance level of the new application is greater, the 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.
367
Managing CPU Usage
The CPU utilization management feature can be used to improve the ability of a farm to
manage resources and normalize CPU peaks when the 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 CPU restrictions.
To enable CPU utilization management
You can enable CPU utilization management using Citrix policy settings. This feature is not
enabled by default.
Important:
The Dynamic Fair Share Scheduling (DFSS) aspect of the Windows Remote Desktop Services
role is incompatible with CPU utilization management. Ensure that DFSS is disabled on each
server where CPU Utilization Management is enabled.
368
Managing CPU Usage
1. Configure the Citrix Computer policy settings for Memory/CPU > CPU management
server level. Choose one of the following settings:
●
Select Fair sharing of CPU between sessions to allocate an equal share of the CPU
to each user.
Select Preferential Load Balancing to allocate shares based on importance levels.
2. Continue by applying one or more filters to the policy based on worker groups or
organizational units.
●
369
Deploying virtual memory optimization
You can enhance system speed, performance, and scalability by improving virtual memory
utilization for a server using the Citrix memory optimization service. The service improves
how DLLs are shared among applications running on the server, saving virtual and real
memory. The service changes the location that individual DLLs are loaded in memory to
increase the amount of possible sharing. The process is called rebasing.
Memory optimization is especially useful when user demand exceeds available RAM and
causes farm performance to degrade. Performance degradation can occur during peak times
when users run memory-intensive applications in multiple sessions.
For a variety of reasons, not all applications can be successfully optimized. You can add
those applications that cannot be optimized to an exclusion list to bypass optimization. You
do not want to enable memory utilization management on farms or servers that exclusively
host signed or certified applications because these cannot be optimized. XenApp can detect
only some published applications that are signed or certified.
The memory optimization feature includes the ability to set the schedule for DLL rebasing
and to exclude specific applications from DLL rebasing. Rebasing is composed of two parts:
A scanning component that locates modules that are candidates to be rebased, and a
rewriting component that performs the optimization. If you enable memory optimization,
the scanning component runs regularly on the server. However, the rewriting component
runs only when scheduled.
To enable memory optimization
Configure the Citrix Computer policy setting for Memory/CPU > Memory optimization to
enable the feature.
Continue by creating a memory optimization schedule for when a server rebases DLLs and,
if needed, an exclusion list of applications that cannot be optimized. To create the list,
test the feature on a test server.
To test memory optimization before deployment
1. Using a test server hosting your published applications, enable memory optimization.
2. Schedule memory optimization.
3. After memory optimization completes, run all published applications.
4. Add to the exclusion list those applications that fail.
370
Deploying virtual memory optimization
To create an exclusion list of applications
Not all applications can be optimized successfully. The process automatically excludes some
applications. However, if published applications fail after enabling and running memory
optimization, exclude those applications from memory optimization by adding them to the
exclusion list.
Some types of application that cannot be optimized include:
●
Applications that reside on network shares (automatically excluded).
●
Applications that have digitally signed components.
●
Applications whose DLLs are protected by Windows Rights Management. For example,
applications such as Office 2003 do not benefit from this feature.
●
Applications whose executable programmatically checks the DLL after it is loaded.
●
Applications that require a fixed DLL address.
In general, if an application was working, but it stops working after you enable this feature,
add the application to the exclusion list and see if the problem is resolved.
With memory optimization enabled, to exclude additional applications, configure the Citrix
policy settings for Memory/CPU > Memory optimization application exclusion list by
adding the full path and executable name for the application, for example:
C:\\%Program Files%\ProgramName.exe
where %Program Files% is the full path to the application.
To create a memory optimization schedule
After you enable virtual memory optimization, the server rebases DLLs automatically at
server start-up. When the service rebases, it changes the location that individual DLLs are
loaded in memory to increase the amount of possible sharing.
You can create an additional virtual memory optimization schedule that identifies other
times when a server rebases DLLs for greater operating efficiency. As a best practice,
schedule virtual memory optimization at a time when your servers have their lightest loads.
With memory optimization enabled, configure these Citrix Computer policy settings for
Memory/CPU:
371
●
Memory optimization interval. Set the frequency internal to daily (default), weekly,
monthly, or only when you restart your server. If you choose to run the program weekly
or monthly, specify the day of the week or month.
●
Memory optimization schedule: day of month (1 by default). Enter the day of the
month using values 1-31. Note that if the specified day does not occur in a given month,
such as day "31" in June, memory optimization does not run in that month. This setting
is used only if you set the interval to Monthly.
Deploying virtual memory optimization
372
●
Memory optimization schedule: day of week (Sunday by default). Select the day of
the week that memory optimization runs. This setting is used only if you set the interval
to Weekly.
●
Memory optimization schedule: time (3:00 AM by default). This setting is used only if
you set the interval to Daily, Weekly, or Monthly.
Managing Farm Infrastructure
All farms include infrastructure functions to support the servers hosting published
applications. Whether you configure these functions on shared or stand-alone servers
depends on your farm’s size and requirements.
Farms comprise at least one zone or grouping of servers. Multiple zones are sometimes used
to improve the performance on geographically segmented farms. Within the zone, there is a
data collector, which contains information about other servers in the farm, and servers
designated as backup data collectors. If the data store fails, each server on the farm also
contains a backup of all data store information, known as the local host cache.
373
Maintaining the Local Host Cache
A subset of data store information, the local host cache, exists on each server in the farm,
providing each member server with quick access to data store information. The local host
cache also provides redundancy of the data store information, if for example, a server in
the farm loses connectivity to the data store.
When a change is made to the 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 dsmaint
refreshlhc from a 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 dsmaint recreatelhc. When the IMA Service
starts, the local host cache is populated with fresh data from the data store.
The data store server must be available for dsmaint recreatelhc to work. If the data store
is not available, the IMA Service fails to start.
374
Tuning Local Host Cache Synchronization
You can adjust the interval by which member servers query the farm's data store for missed
changes. The default interval is 30 minutes. In most cases, this default setting is sufficient.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
You can configure the interval by creating the following registry key on each server you
want to adjust, with the value expressed in hexadecimal notation:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ DCNChangePollingInterval
(DWORD)
Value: 0x1B7740 (default 1,800,000 milliseconds)
You must restart the IMA Service for this setting to take effect.
Most changes made through the Citrix AppCenter are written to the data store. When you
open one of these tools, it connects to a specified server. The Citrix Independent
Management Architecture (IMA) Service running on this server performs all reads and write
operations to the data store for the AppCenter.
If the data store is experiencing high CPU usage when few read or write operations to the
data store are occurring, it is possible that the data store is not powerful enough to manage
a query interval of 30 minutes. To determine whether or not the data store query interval is
causing the high CPU usage on the data store, you can set the query interval to a very large
number and test CPU usage. If the CPU usage returns to normal after you set a large query
interval, the data store query interval is probably the cause of the high CPU usage. You can
adjust the query interval based on performance testing.
To test the query interval, set the interval to 60 minutes and then restart all the servers in
the farm. If the data store is still experiencing constant high CPU usage, increase the query
interval further. If the CPU usage returns to normal, you can try a smaller value. Continue
these adjustments until data store CPU usage is normal.
Important: Do not set the data store query interval higher than necessary. This interval
serves as an important safeguard against lost updates. Setting the interval higher than
necessary can cause delays in updating the local host cache of the farm’s member
servers.
375
To configure zones and back-up data
collectors
A zone is a configurable grouping of XenApp servers. You can create zones during XenApp
installation or after installation. For design considerations concerning zones and data
collectors, see the topics Designing a XenApp Deployment.
By default, all servers in the farm belong to the same zone, named Default Zone. Each zone
in a server farm contains one server that is designated as the data collector for the zone.
Data collectors store information about the servers and published applications in the zone.
They act as communication gateways between zones in server farms that have more than
one zone. Zones are view-only in the AppCenter, where, if needed, you can create new
zones. Each zone must have at least one server; empty zones are automatically removed.
When you create a server farm and whenever a new server joins a zone, a server is elected
as the data collector for that zone. If the data collector for the zone becomes unavailable,
a new data collector is elected for the zone based on a simple ranking of servers in the
zone.
Important: A primary domain controller or backup domain controller must not become
the data collector for a zone. This situation may arise if XenApp is installed on Windows
domain controllers. Citrix does not support installing XenApp on a domain controller.
1. From the AppCenter, select the farm.
2. Expand the server node and select Zones to view the existing zones for the farm.
3. To create or modify zones, on the Actions menu, under Zones, click New > Create a
new zone to open the wizard (this option appears only if two or more servers exist in
the farm). Follow the instructions to name the zone and add or remove servers.
4. On the Set server's election preferences page, select a server and click Edit to select
the ranking for the server by choosing from the following election options:
●
Most Preferred. The server is always the first choice to become the data collector.
It is recommended that only one server per zone be given this setting.
●
Preferred. When electing a new data collector, XenApp elects the next collector
from the Preferred servers if the Most Preferred server is not available.
●
Default Preference. The default setting for all servers. The next collector is
selected from the Default servers if neither a Most Preferred server nor a Preferred
server is available.
Not Preferred. Apply this setting to servers that you do not want to become the
data collector for the zone. This setting means that this server becomes the data
collector only when no servers are available with any of the other three settings
(Most Preferred, Preferred, Default Preference).
5. Restart the affected servers to apply the changes. This is required to update the data
collector information for each zone.
●
376
To configure zones and back-up data collectors
Zones are listed in the middle pane according to their election preference.
To modify an existing zone
377
●
To rename a zone, from the Zones node, right-click the zone name and select Rename.
●
To reset the ranking, right-click a server in the zone and select Change display >
Election Preference.
●
To move the selected server to another zone, right-click a server in the zone and select
Change server's zone membership.
Updating Citrix License Server Settings
XenApp servers must point to the license server where license files are stored. The license
server settings include the name of the license server that your farm accesses to check out
licenses and the port number the license server uses to communicate.
For details about setting the license server, see the installation topic Configuring XenApp
Server Role License Information.
You can change the settings through a Citrix Computer policy by specifying the name of the
license server or port number that the license server uses to communicate in the Licensing
section of the policy and apply the policy through filters.
You may want to change these settings in the following instances:
●
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 Computer policy for Licensing by setting the following options:
●
Enter the License server host name of the server hosting XenApp licenses.
●
Enter the License server port number (default 27000).
Changing the settings on this page is only one part of the procedure, however.
If you decide to change the license server name, ensure that a license server with the new
name already exists on your network. Because license files are tied to the license 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.
378
To set the product edition
The product editions of XenApp support different features. To activate the features
available with a particular edition installed on each server, set the product edition on each
server through Citrix policies.
The product edition also determines which type of license a server requests from the
license server. Make sure the edition you set match the licenses you installed.
1. Locate the Citrix Computer policies for Server Settings, and configure the XenApp
product edition setting.
2. Create a filter to apply the policy to specific worker groups.
3. To apply the change, you must restart each server affected by the policy.
379
Configuring the Citrix XML Service Port
and Trust
The Citrix XML Service is used by user devices connecting over the TCP/IP+HTTP protocol
and the Web Interface.
By default, XenApp server role installation configures the Citrix XML Service and Internet
Information Service (IIS) to share the same TCP/IPport (80) for communications. In this
case, you cannot change the XML Service setting.
During the installation of Citrix XenApp on your server, you configured the XML Service to
either share the port with your Microsoft Internet Information Server or to use a particular
port. For details about the XenApp and Web Server (IIS) server roles, refer to the System
Requirements topic for your version of XenApp.
If you specified a custom XML Service port during installation, you can change the XML port
number if necessary.
Note: The port option appears only if you entered a different port number than the
default Share with IIS during the Web Interface installation. Use the XML Service policy
setting to change the port number.
To change the XML service port
1. Locate Citrix Computer policy setting for XML Service.
2. Configure the XML service port setting. Citrix recommends using port 8080.
To enable XenApp to trust requests sent to the XML
Service
The trust setting is needed only for Smooth Roaming when users authenticate using
pass-through or smart-card authentication with Web Interface, or for smart-card
authentication with the Citrix Receiver (formerly called the Online Plug-in). Trust is not
required for explicit authentication.
1. Locate Citrix Computer policy setting for XML Service.
2. Configure the Trust XML requests setting (disabled by default).
If you do not trust XML requests, certain features of XenApp are not available. Trusting
requests sent to the XML Service means:
380
Configuring the Citrix XML Service Port and Trust
●
Smooth Roaming works when connecting with the Web Interface using pass-through or
smart card authentication, and when connecting with the Receiver using smart card
authentication or the Kerberos pass-through option.
For example, you can use workspace control to assist health-care workers in a hospital
using smart cards, who need to move quickly among workstations and be able to pick up
where they left off in published applications.
●
XenApp can use the information passed on from Access Gateway (Version 4.0 or later)
to control application access and session policies. This information includes Access
Gateway filters that can be used to control access to published applications and to set
XenApp session policies. If you do not trust requests sent to the XML Service, this
additional information is ignored.
Before enabling the Citrix XML Service to trust requests it receives, use IPSec, firewalls, or
another technology to ensure that only trusted services communicate with the Citrix XML
Service.
To avoid security risks, enable the setting only under the following conditions:
381
●
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.
To manually change the XML Service port
to use a port different from IIS after
installation
Note: This setting takes effect only after the XML Service restarts.
The XML Service port set using a Group Policy Object takes precedence over the port you
set using the command-line in this method.
1. At a command prompt, stop IIS by typing: net stop w3svc
2. Delete the following files from the IIS scripts directory on your Web server:
●
ctxadmin.dll
●
CtxConfProxy.dll
●
ctxsta.dll
●
radexml.dll
●
wpnbr.dll
3. At a command prompt, restart IIS by typing: net start w3svc The XML Service no
longer shares a port with IIS.
4. To ensure the XML Service is stopped, at a command prompt, type: net stop
ctxhttp
5. At a command prompt, to unload the XML Service from memory, type: ctxxmlss /u
6. To install the XML service, type: ctxxmlss /rnn where nn is the number of the port
you want to use; for example, ctxxmlss /r88 forces the Citrix XML Service to use
TCP/IP port 88.
7. At a command prompt, start the XML Service by typing: net start ctxhttp
382
To manually configure Citrix XML Service
to share the TCP port with IIS
You must have Administrator privileges to configure the Citrix XML Service.
1. At a command prompt, stop the XML Service by typing: net stop ctxhttp
2. At a command prompt, to unregister the Citrix XML Service, type: ctxxmlss /u
3. Copy the following files to the IIS scripts directory on your Web server:
●
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.
●
4. In the IIS scripts directory, create a folder called ctxadmin and copy the file
ctxadmin.dll from \Program Files (x86)\Citrix\System32 to
\Inetpub\AdminScripts\ctxadmin.
5. Ensure that you have read and write permission to the files in the IIS scripts directory;
for example, use Windows Explorer to view and change the permissions.
6. At a command prompt, stop and restart the Web server by typing: iisreset This
setting takes effect after the Web server restarts.
383
Manage Server and Resource Loads
You can set up, manage, and monitor server and published application loads in a server
farm so that users can run the published applications they need quickly and efficiently.
XenApp calculates the load on a server using load evaluators and rules. Each load evaluator
contains one or more rules. Each rule defines an operational range for the server or
published application to which its evaluator is assigned. For detailed descriptions of these
rules, see List of Load Management Rules.
The following load evaluators are included in XenApp:
●
Default. XenApp assigns the Default load evaluator to each server after you add your
license to the server farm. It contains two rules: Server User, which reports a full load
when 100 users log on to the attached server; and Load Throttling, which specifies the
impact that logging on has on load and limits the number of concurrent connection
attempts the server is expected to handle.
●
Advanced. This load evaluator contains the CPU Utilization Load, Memory Usage, Page
Swaps, and Load Throttling rules.
When a user selects a published application to run, the client on the user device contacts
the server farm to locate the address of a server that hosts the published application.
XenApp maintains a list of available host servers within the server farm. Upon receiving the
client’s request, XenApp selects the server with the lowest load and returns its address to
the client. The client starts a session on that server and launches the published application.
XenApp calculates a server load using the load evaluators attached to a server or published
application. When any rule for any relevant load evaluator reports full load or exceeds its
threshold, XenApp removes the load-managed server from the internal list of available
servers. The next request for an ICA connection to a published application is routed to the
next available load-managed server in the list.
Working with Load Evaluators
To access the load evaluators in XenApp, you select the Load Evaluators node in the left
pane of the AppCenter. The following tabs are displayed:
384
●
Load Evaluators displays all the load evaluators created for the farm in a list. Beneath
this list, the Current Settings tab displays at-a-glance the state of all the available load
evaluator rules.
●
Usage by Application displays the load evaluators that are attached to the farm's
published applications.
●
Usage by Server displays the load evaluators that are attached to each server in the
farm.
Manage Server and Resource Loads
Considerations
When using load evaluators, consider the following:
385
●
You cannot modify or delete the Default or Advanced load evaluators.
●
You cannot modify or delete existing rules. Additionally, you cannot create custom
rules.
●
Each server or application participating in load management can have only one load
evaluator assigned.
●
To assign load evaluators to servers, use Group Policy. You can assign load evaluators to
individual applications on the server.
●
Every XenApp server in the farm is included in the load calculation regardless of the
network protocol unless the server reports full load. If a server reports full load, it is no
longer available for load management until its load is reduced (for example, users log
off from the server or server processes consume less CPU time). After the load is
reduced, the server is added automatically to the list. Servers are continuously added
to and removed from the list as server load and user activity fluctuate.
To create a new load evaluator
1. From the AppCenter, select Load Evaluators in the left pane.
2. From the Actions pane, select New > Add load evaluator.
3. On the Add Load Evaluator dialog box, type a name and description for the new load
evaluator.
4. Select one or more rules from the Rules list and configure it as required.
To change the load evaluator's rules at any time, select the load evaluator you want to
modify and then, from the Actions pane, click Modify load evaluator properties.
386
List of Load Management Rules
These load management rules are included in XenApp:
Application User Load
Limits the number of users allowed to connect to a selected published application. This
rule monitors the number of active ICA sessions using the published application. The
default value to report full load is 100.
Context Switches
Defines a range of context switches per second for a selected server. A context switch
occurs when the operating system switches from one process to another. The default
value to report full load is 16000. The default value to report no load is 900—at that
value this rule is ignored. This rule uses the System: Context Switches/sec performance
counter to determine load.
CPU Utilization
Defines a range of processor utilization, as a percentage, for a selected server. The
default value to report full load is 90 percent. The default value to report no load is 10
percent—at that value this rule is ignored. This rule uses the Processor: % Processor Time
performance counter to determine load.
Disk Data I/O
Defines a range of data throughput, in kilobytes per second, for a selected server. The
default full load value is 32767 kilobytes per second. The default no load value is 0
kilobytes per second—at that value this rule is ignored. This rule uses the PhysicalDisk:
Disk Bytes/sec performance counter to determine load.
Disk Operations
Defines a range of disk operation, in read/write cycles per second, for a selected server.
The default full load value is 100 operations per second. The default no load value is
0—at that value this rule is ignored. This rule uses the PhysicalDisk: Disk Writes/sec and
Disk Reads/sec performance counters to determine load.
IP Range
Defines a range of allowed or denied client IP addresses for a published application. It
controls access to a published application based on the IP addresses of the clients. You
can define ranges of IP addresses, then select to allow or deny access if the client IP
addresses are within the defined ranges.
This rule must be used in conjunction with another.
Load Throttling
387
List of Load Management Rules
Limits the number of concurrent connection attempts that a server handles. This
prevents the server from failing when many users try to connect to it simultaneously.
The default setting (High impact) assumes that logons affect server load significantly.
This rule affects only the initial logon period, not the main part of a session.
The Load Throttling rule can be applied only to a server, not to an individual application.
Memory Usage
Defines a range of memory usage by a server. The default full load value is 90. The
default no load value is 10—at that value this rule is ignored. This rule uses the Memory:
% Committed Bytes in Use performance counter to determine load.
Page Fault
Defines a range of page faults per second for a selected server. A page fault occurs when
the operating system tries to access data that was moved from physical memory to disk.
The default full load value is 2000. The default no load value is 0—at that value this rule
is ignored. This rule uses the Memory: Page Faults/sec performance counter to
determine load.
Page Swaps
Defines a range of page swaps per second for a selected server. A page swap occurs when
the operating system moves data between physical memory and the swap file. The
default full load value is 100. The default no load value is 0—at that value this rule is
ignored. This rule uses the Memory: Pages/sec performance counter to determine load.
Scheduling
Schedules the availability of selected servers or published applications. This rule sets the
weekly days and hours during which the server or published application is available to
users and can be load managed.
Server User Load
Limits the number of users allowed to connect to a selected server. The default full load
value is 100 and represents the maximum number of users the system can support on a
server. Load Manager user loads are calculated using active ICA sessions only.
388
Assigning Load Evaluators to Servers and
Applications
To participate in load management, each server or published application must have a load
evaluator assigned to it. Each server or published application can have only one load
evaluator attached.
To assign a load evaluator to a XenApp server, configure the Load Evaluator Name policy
setting and filter the policy by worker group. You can assign load evaluators that are
available in any XenApp farm. The rules and their settings determine how the load of a
particular server or published application is managed.
For example, if you have a published application that uses a significant percentage of a
server’s memory and processing capabilities, you can add the Load Evaluator Name setting
to a policy, specify the Advanced load evaluator, and filter the policy by the worker group
that contains all the XenApp servers hosting the application. XenApp then distributes the
available memory and processor demand across the load-managed servers.
When you assign a load evaluator through Citrix policies, XenApp does not validate the load
evaluator name when the policy is applied to user sessions. Therefore, if the load evaluator
is later renamed or deleted, the load cannot be calculated. Instead, XenApp logs an error to
the Event Log and the affected servers report a load index of 10,000 (full load).
Additionally, the Usage by Server tab in the middle pane of the AppCenter does not
indicate the load evaluator is assigned. To ensure the policy references the correct load
evaluator name, modify the Load Evaluator Name policy setting and select the correct load
evaluator name from the list of available load evaluators.
If the policy containing the Load Evaluator Name setting is deleted, and no other policy
applied to the server specifies an alternate load evaluator, XenApp uses the Default load
evaluator instead.
To assign a load evaluator to a server
1. Create a new Computer policy or select an existing Computer policy you want to
modify. Depending on the console you use to manage Citrix policies:
●
From the AppCenter, select the Policies node and then select the Computer tab.
From the Group Policy Management Editor, select Computer Configuration >
Policies > Citrix Policies.
2. From the settings list, locate the Load evaluator name policy setting and click Add.
●
3. Select a load evaluator from the drop-down list and then click OK.
4. Add the Worker Group filter to the policy and specify the worker group containing the
servers to which you want to assign the load evaluator.
389
Assigning Load Evaluators to Servers and Applications
To assign a load evaluator to a published application
1. From the AppCenter, select the Applications node in the left pane.
2. Select the published application to which you want to attach a load evaluator.
3. From the Actions pane, select Other Tasks > Attach application to load evaluator.
4. On the Assign Load Evaluator dialog box, select the load evaluator to attach.
390
Scheduling Server Availability
Use the Scheduling rule to determine when a server or published application is available to
users and can be load managed. If this rule is included in a load evaluator and attached to a
server or published application, the server or published application is available only during
the days and times set in this rule.
The Scheduling rule must be used with at least one other rule. It cannot be the only rule in
a load evaluator.
You cannot apply the Scheduling rule to any custom ICA connections that connect to
specific servers. Custom ICA connections cannot be controlled using the Scheduling rule.
To configure the Scheduling rule
1. In the AppCenter, select Load Evaluators in the left pane.
2. In the middle pane, select the load evaluator you want to change.
3. From the Actions pane, select Modify load evaluator properties.
4. From the Rules list, select the Scheduling rule.
5. In the Scheduling Settings panel, use the Add and Remove buttons to select the days
and times that you want the server or published application to be available (Monday
through Friday, 8:00 AM to 6:00 PM, by default).
391
Power and Capacity Management
Citrix XenApp Power and Capacity Management can help reduce power consumption and
manage XenApp server capacity by dynamically scaling up or scaling down the number of
online XenApp servers. Consolidating sessions onto fewer online servers improves server
utilization, helps minimize power consumption, and helps provide sufficient capacity to
handle server loads.
As users log on to the system and reduce the idle capacity (the amount of capacity
available for additional sessions), other servers in the workload are powered up. As users
log off and idle capacity increases, idle servers are powered down. This helps optimize
capacity for XenApp workloads.
Scheduling provides an automated approach. An administrator defines specific times for
powering on and powering off workloads. For example, a schedule powers on servers at 8 in
the morning and powers them down at 7 in the evening, from Monday through Friday. The
administrator can manually override capacity and schedule settings to accommodate
unexpected demand.
Load consolidation and power management operate in unison; load consolidation ensures
sessions are not spread across online servers, which provides a better opportunity to power
off excess servers later, using power management.
Use Power and Capacity Management to observe and record utilization and capacity levels.
Console monitoring and report generation provide valuable information, even if you do not
enable power management and load consolidation.
Power and Capacity Management respects all configured XenApp server settings, farm
settings, and policies.
System Components
The Power and Capacity Management system comprises the following components. (From a
Windows installer viewpoint, these are features; this documentation uses the term
components.)
392
Component
Description
Concentrator
A Windows service and the central component of the Power
and Capacity Management system. It coordinates system
states and operations for the managed XenApp servers. You
can have one or more concentrators; if you have more than
one, and one fails, another assumes control.
Database
An instance of a Microsoft SQL Server database. It provides
the common store for information such as managed server
inventory, workload assignments, schedules, metric data, and
configuration settings.
Power and Capacity Management
Reporting
Subfeature of the database component. Reports are hosted on
Microsoft SQL Server Reporting Services. The administrator
generates reports for historical system loads, capacities, and
utilization summaries.
Management console
A Microsoft Managed Console (MMC) snap-in to manage,
monitor, and configure the Power and Capacity Management
system.
Agent
A Windows service installed on each XenApp server. The agent
reports capacity and system states, and acts on operations
and commands issued by the concentrator.
The concentrator, database, reporting, and management console components are the
administration components.
393
About Load Consolidation and Power
Management
Concepts and Terminology
For XenApp Power and Capacity Management, capacity is expressed as a number of sessions
(or session count).
The XenApp servers being managed by Power and Capacity Management are called a farm.
This farm may include some or all of the servers in a XenApp farm, or it may contain
XenApp servers from different XenApp farms (for example, in a XenApp farm that covers
multiple sites, you might have a Power and Capacity Management farm for the XenApp
servers in each site). The Power and Capacity Management farm name is distinct from the
XenApp farm name.
A workload is a logical grouping of servers that all host the same application or set of
applications. (In XenApp terms, this is referred to as an application silo.) The workload is
named when the Power and Capacity Management agent is configured.
You use setpoints in the schedule to control how servers are power managed and how load
is consolidated within the workload. A setpoint represents a target number of sessions or
the number of online servers.
In a Power and Capacity Management farm, a XenApp server's control mode (configured in
server properties) affects whether the server is eligible for power management or
participating in load consolidation. (You also enable power management and load
consolidation for the workload.)
What Happens during Load Consolidation
Load consolidation has the opposite effect to traditional XenApp load balancing. Its goal is
to consolidate sessions onto fewer servers instead of spreading load evenly across many
servers. By consolidating sessions, there is greater opportunity to power down excess
servers, saving power and reducing operating costs. Greater consolidation of sessions
equates to higher levels of utilization per server while online.
Load consolidation works by continually monitoring the number of active sessions and
remaining capacity for each server. The goal is to load new sessions onto small groups of
servers to a level that the servers can handle well; this level is the optimal load (set in
global configuration). Once a server reaches its optimal load, an additional server in the
workload is enabled to accept new session load. When power management is used, this
additional server will be powered on automatically if it is currently powered off.
For load consolidation to work effectively, the capacity level of each server must be
measured. Because the remaining capacity can change as load on the server fluctuates,
capacity levels are continually re-evaluated. This is known as dynamic capacity estimation.
394
About Load Consolidation and Power Management
Dynamic capacity estimation calculates individual server capacities based on the load on
each server. The capacity of each server more accurately reflects the actual number of
sessions it can handle. The load on each server is determined by its assigned XenApp load
evaluator; therefore, consider the desired load criteria when configuring the assigned
evaluators. The Power and Capacity Management agent regularly monitors the load and
updates the estimated capacity on its server.
Depending on the load, the estimation may determine that a server is capable of holding
more sessions than the configured typical capacity. To allow the dynamic capacity
estimation to set capacities higher than the typical value, you can set the estimated
capacity limit to any value higher than the typical capacity.
The typical session capacity and estimate session capacity limit are configured in the server
profile.
What Happens during Power Management
When Power and Capacity Management determines that a power on or power off operation
is required, it considers a server's power controller preference (configured in server
properties). XenApp servers installed on virtual machines can also have a site-specific
power controller preference (configured for the site); sites are specified when configuring
virtual machine managers. For a power on operation, the selection algorithm chooses a
server with a higher power controller preference before a server with a lower preference.
For a power off operation, the algorithm chooses a server with a lower power controller
preference before a server with a higher preference. For best practice, configure the
preference of more power-efficient servers higher than older, less power-efficient servers.
When Power and Capacity Management selects a XenApp server for power off and that
server is currently hosting sessions, the server is placed into PCM drain mode (which is
separate from XenApp drain mode). When a server is in PCM drain mode, load balancing
attempts to avoid starting new sessions on that server. All valid servers in a worker group
(online, hosting the desired application, and with available load) that are not in PCM drain
mode are used before any servers at that worker group priority level that are in PCM drain
mode. However, if no servers meet that criteria, the session is started on the server in PCM
drain mode. Sessions hosted on a server in PCM drain mode can use session sharing. A server
in PCM drain mode allows reconnection of disconnected sessions. If you disable power
management for a workload, any servers currently in drain mode revert out of drain mode.
In meeting capacity setpoints, Power and Capacity Management ignores the load from
servers that are currently draining or powering off, as well as servers currently being
evaluated for draining/power off. A server in drain mode powers off only when no sessions
remain. If the agent loses connection to the concentrator, the agent reverts drain mode on
draining servers.
When Power and Capacity Management issues a power off or power on control, a timer
starts (with a value configured in the server profile). If the operation does not complete
successfully before the timer expires, the management console displays the failure. When a
power control operation completes successfully, all control errors associated with that
server are cleared.
395
Installing Power and Capacity
Management
To install Power and Capacity Management components, you can:
●
Use the XenApp media to launch an interactive installation.
●
Point to the XenApp media and issue commands for a silent installation.
●
Use the XenApp Server Role Manager.
Important: When using the wizard-based Server Role Manager, install the Power and
Capacity Management agent when you install the XenApp server role. If you do not
install them at the same time, install the agent using another method.
The following MSI packages contain the Power and Capacity Management components.
Installation Package
Description
XenAppPCMAgent64.msi
Installer for the agent.
XenAppPCMAdmin.msi
Combined installer for the administration components;
use this MSI to install the database, reports, and
management console on a supported 32-bit computer.
XenAppPCMAdmin64.msi
Combined installer for the administration components;
use this MSI to instal the database, reports,
concentrator, and management console on a supported
64-bit computer.
Install the agent on each XenApp server.
You can install all the administration components on a single computer, or you can install
one or more administration components on separate computers. If you are not installing all
the administration components at the same time on the same computer, install them in the
following order:
1. Database
2. Reports (Reports is a subfeature of the database feature; therefore, you can install
reports only if you are also installing the database component, or if you previously
installed the database component)
3. Concentrator
4. Management console
396
System Requirements for Power and
Capacity Management
Supported Platforms
A Power and Capacity Management farm can comprise physical and virtual XenApp servers:
●
Wake-on-LAN (WoL) power control is supported for physical XenApp servers on the same
subnet.
●
Power-on commands to virtual computers hosting XenApp servers (in one or more
clusters) are supported for the following platforms, or subsequent compatible versions:
●
Citrix XenServer 4.0
●
Microsoft Hyper-V 1.0
●
Microsoft SCVMM 2008
●
VMware ESX and vCenter 4.0
Component Requirements
Unless otherwise noted, 32-bit and 64-bit operating system editions are supported.
Component
Support and Requirements
Database
Requirements:
●
Microsoft .NET Framework 3.5 SP1
●
Microsoft SQL Server 2005 SP3 and SP4 or Microsoft SQL Server
2008 R2; see CTX114501 for the latest supported versions
●
Microsoft SQL Server Reporting Services
●
Internet Information Services (IIS) 6.0 and ASP.NET (required only
if using Reporting Services on Microsoft SQL Server 2005)
Use Microsoft Internet Explorer to view reports.
397
System Requirements for Power and Capacity Management
Concentrator
Supported operating systems:
●
Windows Server 2008 R2 (64-bit)
●
Windows Server 2008 R2 SP1 (64-bit)
Requirement: Microsoft .NET Framework 3.5 SP1
For XenApp servers on the Microsoft SCVMM 2008 platform, the
Microsoft SCVMM 2008 console must be installed on each server hosting
a concentrator (master and slaves).
Agent
Supported operating systems:
●
Windows Server 2008 R2 (64-bit)
●
Windows Server 2008 R2 SP1 (64-bit)
Requirements:
Management
console
●
Microsoft .NET Framework 3.5 SP1
●
XenApp 6.5
Supported operating systems:
●
Windows Server 2008 R2 (64-bit)
●
Windows Server 2008 R2 SP1 (64-bit)
●
Windows Server 2003 R2
●
Windows Server 2003 (32-bit)
●
Windows 7 Enterprise SP1
●
Windows Vista SP2
●
Windows XP SP3 (32-bit), SP2 (64-bit)
Requirements:
●
Microsoft .NET Framework 3.5 SP1
MMC 3.0 Update: http://support.microsoft.com/kb/907265
(pre-installed on Windows Vista, Windows 7, and Windows Server
2008 R2 systems)
Identify the XenApp servers you want in the Power and Capacity Management farm. For
optimal operation, Power and Capacity Management should register (discover) all servers in
the XenApp farm. You can then change the control mode (in server properties) for servers
that are not power controlled. This practice prevents the possibility of session load being
sent to XenApp farm servers that Power and Capacity Management is not managing or has
not discovered.
●
The XenApp servers on which you install the Power and Capacity agent, and the computers
on which you install the concentrator and management console must all belong to the same
398
System Requirements for Power and Capacity Management
Active Directory domain. Install the database component either in the same Active
Directory domain as the other components or in a trusted domain.
You do not have to run the installation of the Power and Capacity Management database
component on the server where Microsoft SQL Server is installed. You can either run the
installation process physically on the SQL Server or from any domain member machine. If
you run the installation of the database component from a different server than SQL Server,
the server on which you install the database component does not need to stay powered on.
Using Policies
You can use Citrix group computer policy settings to specify the Power and Capacity
Management farm name and workload name, which apply to agent configuration. For
information about specifying setting values, see Policy Settings Reference. Note the
warning not to enable the Use default value checkbox for the farm name setting.
When using the XenApp Server Role Manager, the Power and Capacity Management farm
name and workload name are not written to local policy, and the Agent service is not
started, until after the XenApp Server Configuration Tool successfully configures the
XenApp server role and the server restarts.
Installing the Concentrator
When installing the concentrator, you specify the database (and the database instance, if
you are not using the default instance). By default, the installer updates the database to
give the concentrator necessary permissions. This action assumes that the user installing
the concentrator has administrator privileges on the SQL Server instance to modify the
permissions of the Power and Capacity Management database.
If the user installing the concentrator does not have administrator privileges on the SQL
Server to modify the permissions of the Power and Capacity Management database:
●
In a wizard-based installation, select the Do not grant DB access to concentrator
check box. (This check box appears only when you are not installing the concentrator
and the database at the same time.)
●
In a silent installation, include the CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes
property.
Then use SQL Server Management Studio to add the necessary permissions to the database:
1. Using SQL Server Management Studio, navigate to the main Security - Logins node.
2. Add a new login for the concentrator identity. If you are running the concentrator as
the default network service, this is domain-name\computer-name$. (If you are entering
a machine account, type the machine account name; do not use the Search button.)
3. Navigate to XenAppPCM database > Security > Users.
399
System Requirements for Power and Capacity Management
4. Add a new user. Citrix recommends the User Name be the same as the Login Name you
specified in step 2. In the role membership list, select ConcentratorRole.
If you plan to use more than one concentrator, after installing the first concentrator on a
machine, install another on a different computer, and repeat as needed. Ensure that you
install only the concentrator. In the wizard based installation, deselect all other
components. In a silent installation, include the ADDLOCAL=Concentrator property.
See Managing the Concentrator for information about manually publishing the concentrator
in Active Directory.
400
Interactively Installing Components
Before interactively installing the Power and Capacity Management components, review the
silent installation properties to learn about information you specify during the interactive
installation.
To interactively install the agent from the XenApp
media
Choose one of the following:
●
On the XenApp media, launch autorun.exe. From the Autorun menu, select Manually
install components > Server Components > Power and Capacity Management > Power
and Capacity Management Agent.
●
On the XenApp media, go to the Power and Capacity Management folder and
double-click XenAppPCMAgent64.msi. Follow the wizard prompts.
To interactively install the administration components
from the XenApp media
Choose one of the following:
●
On the XenApp media, launch autorun.exe. From the Autorun menu, select Manually
install components > Server Components > Power and Capacity Management > Power
and Capacity Management Administration.
●
If you are installing the components on a 32-bit operating system, go to the Power and
Capacity Management folder on the XenApp media and double-click
XenAppPCMAdmin.msi. Follow the wizard prompts.
●
If you are installing the components on a 64-bit operating system, go to the Power and
Capacity Management folder on the XenApp media and double-click
XenAppPCMAdmin64.msi. Follow the wizard prompts.
By default, all administration components are selected in an interactive installation, except
reports.
To interactively install components from the XenApp
Server Role Manager
To use the XenApp Server Role Manager, follow the guidance in Install and Configure.
401
Interactively Installing Components
●
To install the agent, select the Power and Capacity Management Agent check box in
Optional Components. When you configure the XenApp role with the XenApp Server
Configuration Tool, specify the PCM farm and workload names when prompted.
Important: Install the Power and Capacity Management agent at the same time you
install the XenApp server role; otherwise, use another method to install the agent.
●
To install administration components, select the Power and Capacity Management
Administration role. After the Server Role Manager installs other selected roles,
components, and prerequisites, click the Install link next to Power and Capacity
Management. Follow the wizard prompts.
By default, all administration components are selected in an interactive installation,
except reports.
402
Silently Installing Components
To silently install the agent from the XenApp media
Point to the XenApp media and enter the following command:
msiexec /i XenAppPCMAgent.msi /qn CTX_XAPCM_ACCEPT_EULA=yes
CTX_XAPCM_FARM_NAME=farm-name [CTX_XAPCM_WORKLOAD_NAME=workload-name]
[CTX_XAPCM_AGENT_NOSTART=yes] [CTX_XAPCM_AGENT_NOPOLICY=yes]
[CTX_XAPCM_AGENT_ACCOUNT=domain-account]
[CTX_XAPCM_AGENT_PASSWORD=domain-account-password
Agent Installation Properties
CTX_XAPCM_ACCEPT_EULA=yes
Accepts the license agreement. To read the EULA (End User License Agreement),
launch the installation interactively and navigate to the license dialog.
If you omit this property, or if the specified value is not "yes," the installation fails.
CTX_XAPCM_FARM_NAME=farm-name
Farm name, up to 80 characters, and cannot contain: backslash (\), single quote ('),
forward slash (/), double-quote ("), less-than (<), greater than (>), pipe (|), or equal
(=). The collection of XenApp servers being managed by Power and Capacity
Management is known as a farm. This farm may include some or all of the servers in a
XenApp farm or may contain XenApp servers from different XenApp farms. The name
must be unique.
If you omit this property, the installation fails.
CTX_XAPCM_WORKLOAD_NAME=workload-name
Workload name, up to 256 characters. A workload is a logical grouping of servers that
all host the same application or set of applications. In XenApp terms, this is referred
to as an application silo.
If you omit this property, "Unassigned" is used. (You cannot enable power management
or load consolation for an unassigned workload.)
CTX_XAPCM_AGENT_NOSTART=yes
Prohibits the Agent service from starting during installation.
If you omit this property, or if the specified value is not "yes," the Agent service starts
during installation.
403
Silently Installing Components
CTX_XAPCM_AGENT_NOPOLICY=yes
Prohibits the agent installer from writing the farm and workload names to local policy.
If you omit this property, or if the specified value is not "yes," the farm and workload
names are written to local policy.
CTX_XAPCM_AGENT_ACCOUNT=domain-account
Domain account with the following rights:
●
Citrix administrator for the XenApp instance
●
Log on as service
●
Shut down the system
Query rights for Active Directory (to locate the "Citrix XenAppPCM" SCP for the
farm assigned to this agent)
If you specify this property, you must specify a domain account password with the
CTX_XAPCM_AGENT_PASSWORD property. You must also supply a domain account with
the CTX_XAPCM_CONCENTRATOR_ACCOUNT property when installing the concentrator.
(The Concentrator service cannot use a built-in account if the Agent service uses a
domain account; similarly, the Concentrator service cannot use a domain account if
the Agent service uses a built-in account.)
●
If you omit this property, the built-in "Local System" account is used. In this case, do
not specify the CTX_XAPCM_AGENT_PASSWORD property.
CTX_XAPCM_AGENT_PASSWORD=domain-account-password
Password for the domain account. This property is valid only if you specified a domain
account with the CTX_XAPCM_AGENT_ACCOUNT property.
For example, the following command silently installs the agent with:
●
A farm name of "my_farm"
●
A workload name of "my_workload"
●
The agent service running under the domain account "my_domain\my_user" with the
password "my_password"
msiexec /i XenAppPCMAgent.msi /qn
CTX_XAPCM_ACCEPT_EULA=yes CTX_XAPCM_FARM_NAME=my_farm
CTX_XAPCM_WORKLOAD_NAME=my_workload
CTX_XAPCM_AGENT_ACCOUNT=my_domain\my_user
CTX_XAPCM_AGENT_PASSWORD=my_password
To silently install the administration components from
the XenApp media
Point to the XenApp media and enter the following command:
404
Silently Installing Components
msiexec /i XenAppPCMAdmin.msi /qn CTX_XAPCM_ACCEPT_EULA=yes
[ADDLOCAL=components] [CTX_XAPCM_FARM_NAME=farm-name]
[CTX_XAPCM_DB_INSTANCE=db-instance] [CTX_XAPCM_DB_NAME=db-name]
[CTX_XAPCM_REPORT_URL=report-url] [CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes]
[CTX_XAPCM_CONCENTRATOR_ACCOUNT=domain-account]
[CTX_XAPCM_CONCENTRATOR_PASSWORD=domain-account-password
Administration Component Installation Properties
CTX_XAPCM_ACCEPT_EULA=yes
Accepts the license agreement. To read the EULA, launch the installation interactively
and navigate to the license dialog.
If you omit this property, or if the specified value is not "yes," the installation fails.
ADDLOCAL=components
Comma-separated list of components to be installed. Valid values are:
●
DatabaseInstaller
●
Reports
●
Concentrator
Console
Reports is a subfeature of the database component; therefore, you can install reports
only if you are also installing the database component, or if you previously installed
the database component.
●
If you omit this property, the database, concentrator, and management console
components are installed; reports is not installed.
CTX_XAPCM_FARM_NAME=farm-name
Use this property when installing the database component.
Farm name, up to 80 characters, and cannot contain: backslash (\), single quote ('),
forward slash (/), double-quote ("), less-than (<), greater than (>), pipe (|), or equal
(=) . The collection of XenApp servers being managed by Power and Capacity
Management is known as a farm. This farm may include some or all of the servers in a
XenApp farm, or it may contain XenApp servers from different XenApp farms. The
name must be unique.
If you are installing the database component and omit this parameter, the installation
fails.
405
Silently Installing Components
CTX_XAPCM_DB_INSTANCE=db-instance
Use this property when installing the database, reports, and concentrator
components.
Database instance name.
●
If you are installing the database component, this property specifies the instance
name of the SQL Server instance in which the Power and Capacity Management
database schema is to be installed. If you are using the default SQL instance on
this computer, specify "." (dot); otherwise, specify the computer and instance
name (for example, SQLServer\instance1).
If you already installed the database component and are installing the
concentrator, this property specifies the instance name of the SQL Server instance
in which the schema is installed. If the default SQL instance on this computer was
used, specify "." (dot); otherwise, specify the computer and instance name (for
example, SQLServer\instance1").
If you omit this property, "." is used.
●
CTX_XAPCM_DB_NAME=db-name
Use this property when installing the database, reports, and concentrator
components.
Database name, up to 123 characters. and cannot contain: semicolon (;), question
mark (?), colon (:), at (@), ampersand (&), equal (=), plus (+), dollar ($), backslash (\),
asterisk (*), less-than (<), greater-than (>), pipe (|), double-quote ("), forward-slash
(/), single-quote ('), back-tick (`), left square bracket ([), right square bracket (]).
If you omit this property, "XenAppPCM" is used.
CTX_XAPCM_REPORT_URL=report-url
Use this property when installing the reports component.
Report service URL, up to 512 characters.
●
If you are using the default SQL Server instance, specify the server URL http[s]://server_name/ReportServer.
●
If you are using a named SQL Server 2005 instance, specify the server URL
qualified with the instance name
(http[s]://server_name/ReportServer$instance_name.
If you are using a named SQL Server 2008 instance, specify the server URL
qualified with the instance name
(http[s]://server_name/ReportServer_instance_name.
If you omit this property, "http://local_machine_name/ReportServer" is used.
●
406
Silently Installing Components
CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes
Use this property when the person installing the concentrator does not have
administrator rights to the database. In this case, the database administrator must
manually add the correct account to the database.
If you omit this property, or if the specified value is not "yes," the database is
configured to accept connections from the concentrator.
CTX_XAPCM_CONCENTRATOR_ACCOUNT=domain-account
Use this property when installing the concentrator.
Domain account with a userPrincipleName attribute within Active Directory with the
following rights:
●
Log on as service
Read/write rights for Active Directory (to create the "Citrix XenAppPCM" SCP for
the farm this concentrator manages); for example, read/write access to the
Active Directory concentrator computer container (CN)
If you specify this property, you must specify a password with the
CTX_XAPCM_CONCENTRATOR_PASSWORD property. You must also supply a domain
account for the CTX_XAPCM_AGENT_ACCOUNT property when installing the agent.
(The Concentrator service cannot use a built-in account if the Agent service uses a
domain account; similarly, the Concentrator service cannot use a domain account if
the Agent service uses a built-in account.)
●
If you omit this property, the built-in "Network Service" account is used. In this case,
do not specify the CTX_XPCM_CONCENTRATOR _PASSWORD property.
CTX_XAPCM_CONCENTRATOR_PASSWORD=domain-account-password
Use this property when installing the concentrator and only if you specified a domain
account with the CTX_XAPCM_CONCENTRATOR_ACCOUNT property.
Password for the domain account.
For example, the following command silently installs all the administration components
with:
●
A farm name of "my_farm"
●
The default SQL Server instance on a server named "my_db" with a database name of
"my_dbname"
●
Reporting services on "http://my_report_server/reportserver"
●
The concentrator running under the domain account "my_domain\my_user" with the
password "my_password"
msiexec /i XenAppPCMAdmin.msi /qn
CTX_XAPCM_ACCEPT_EULA=yes
ADDLOCAL=Concentrator,Console,DatabaseInstaller,Reports
CTX_XAPCM_FARM_NAME=my_farm
CTX_XAPCM_DB_INSTANCE=my_db CTX_XAPCM_DB_NAME=my_dbname
407
Silently Installing Components
CTX_XAPCM_REPORT_URL=http://my_report_server/reportserver
CTX_XAPCM_CONCENTRATOR_ACCOUNT=my_domain\my_user
CTX_XAPCM_CONCENTRATOR_PASSWORD=my_password
To silently install components using the
XenAppSetupConsole.exe command
To use the XenAppSetupConsole.exe command, follow the guidance in Install and
Configure.
To install the agent, include the PCMAgentFeature property (for example,
/install:XenApp,PCMAgentFeature). When you configure the XenApp role, specify the Power
and Capacity Management farm name and workload name (using the /PcmFarmName and
/PcmWorkloadName options).
To install the administration components, include the PCMAdmin property (for example,
/install:PCMAdmin).
408
Upgrading Administration Components
The Power and Capacity Management component packages on the XenApp 6.5 media are
supported on XenApp 6.5 deployments. You can also use the administration component
packages on that media (XenAppPCMAdmin.msi and XenAppPCMAdmin64.msi) to upgrade all
the administration components previously installed in a XenApp 6.0 deployment.
Important: You must upgrade all of the administration components (concentrator,
database, reports, and management console); upgrading fewer is not supported.
To upgrade the administration components in a XenApp 6.0 deployment, load the XenApp
6.5 media and use one of the following methods:
●
From the XenApp Server Role Manager, click the Upgrade link next to Power and
Capacity Management. Follow the wizard prompts.
●
From the media, follow the same procedure you used to install the Power and Capacity
Management administration components in the XenApp 6.0 deployment.
During the upgrade, the installed components are uninstalled, and the newer version
installed. Repeat as needed on all the computers hosting Power and Capacity Management
administration components in the XenApp 6.0 deployment.
You cannot (and do not need to) upgrade the Power and Capacity Management agents in a
XenApp 6.0 deployment. Continue using the agents you originally installed on the XenApp
6.0 servers.
409
Removing Components
To remove Power and Capacity Management components, use Windows Programs &
Features or Add/Remove Programs.
Removing a Concentrator
Removing an inactive non-master (slave) concentrator through Windows Programs &
Features may not remove the database entry. If this occurs, the concentrator continues to
appear in the Cluster Management window.
To remove the database entry:
1. From the management console, click Cluster Management in the Actions pane.
2. In the Cluster Management dialog box, ensure that the Concentrator service for the
concentrator you want to remove is stopped (State = Service stopped).
3. Select the concentrator and then click Remove Slave.
4. Confirm the removal.
Note: You may still need to manually delete the concentrator's SCP entry from Active
Directory.
410
Configuring and Using Power and
Capacity Management
After installing the components, first-time use of the Power and Capacity Management
system includes specifying configuration values. With a basic setup (using default setpoint
values and without enabling load consolidation or power management), you can monitor the
system and create reports.
1. (Required only if you have more than one Power and Capacity Management farm.)
Connect to the Power and Capacity Management farm. In the Actions pane, click
Connect to XenApp PCM Service, then select the Power and Capacity management
farm you want to manage.
2. Complete the following initial configuration tasks:
●
Configuring a Server Profile
●
Configuring Server Properties
●
Setting Global Configuration Values
●
Configuring Sites
●
Adding Virtual Machine Managers
Managing the Concentrator
3. After the initial setup, observe management console displays and generate reports.
Using the collected information, you can then:
●
●
Creating Setpoints and Schedules
●
Enabling Load Consolidation and Power Management
Understanding Management Console Displays
The management console connects to the master concentrator to obtain data. The menu,
toolbars, and Actions pane are standard MMC 3.0 panes, some of which can be hidden if
required. The workloads and tabs panes comprise the Power and Capacity Management
snap-in.
The workloads pane contains the following information:
Workloads pane columns
Workload
All Workloads, plus names of individual workloads
411
Configuring and Using Power and Capacity Management
Power Managed
Indicates power management status for the system (All Workloads) and for each
workload.
●
Checkmark = enabled ("override" indicates a manual override is in effect)
●
x = disabled (with a notation if a workload does not have a schedule)
Load Consolidated
Indicates load consolidation status for the system (All Workloads) and for each
workload.
●
Checkmark = enabled
●
x = disabled
Utilization
Current utilization shown in meter form and percent text (utilization is the ratio of:
total active sessions/total session capacity available from all online servers)
Sessions
Current number of load, unused, and offline sessions, shown graphically and in
absolute counts.
Servers
Current number of online and offline servers in the workload, shown graphically and in
absolute counts.
The tabs pane contains the following information:
Tabs
Status
Utilization, sessions, and servers information is equivalent to the information for the
selected workload in the workloads pane above it.
With power management enabled, the display includes current setpoint values.
●
For workloads with an empty schedule and no override, the display shows the
default setpoint values.
●
When the power controller is following the schedule for a workload, the display
shows the scheduled setpoint values.
●
When the power controller is following override setpoints for a workload, the
display shows those values.
Performance
Displays metric graphs collected for a specific interval. After you select an interval,
the display shows values collected throughout the interval for utilization, sessions, and
servers, starting with the beginning of the selected interval, and ending with the
current ("Now") value.
412
Configuring and Using Power and Capacity Management
Servers
Lists servers in the workload selected in the workloads pane. Information for each
server includes:
●
Server: DNS name and server profile information.
●
Control mode: Power control mode, site (if there is more than one defined), and
power controller preference.
●
State: Online, Offline, Disconnected, Draining, Stopping, or Starting.
In some cases, state displays vary for XenApp installations on virtual machines,
depending on whether or not a Power and Capacity Management machine manager
is configured and enabled. Using a machine manager results in more detailed state
reporting and displays. For example, on a server without an enabled machine
manager, a state display of 'Starting' indicates that Power and Capacity
Management has instructed the server to power on. On a machine
manager-enabled server, that state display appears as 'Starting: Powering on' or
'Starting: Waiting for connection.'
●
Utilization: Current percentage in graphic and text forms.
●
Sessions. Current counts in graphic and text forms. Hovering over an entry displays
the current session count for that server and the current load consolidation
activity, if any. An icon to the left of the graph represents the current load
consolidation activity (when load consolidation is enabled for the server's
workload):
●
Green triangle = server is accepting new connections and is below optimal
load
●
Yellow triangle = server is accepting new connections but is above optimal
load
Grey circle = server has been set as an undesirable target for new sessions
The Sessions graphic fades for servers in PCM drain mode.
●
●
Session Capacity. Hovering over an entry displays how the dynamic capacity
estimate differs from the typical session capacity value configured in the server
profile (the session capacity value indicates 'calculated').
Capacities
Displays server profile information and the typical session capacity for each server
profile (or Unset if the typical session capacity is not configured). To display the DNS
names of servers that use a profile, select the profile and then click the entry in the
Servers column.
Schedule
Displays the current Monday through Sunday schedule for a workload. (This tab is not
displayed when All Workloads is selected in the workloads pane.) The entry for each
day indicates time and setpoint values.
413
Configuring and Using Power and Capacity Management
To generate a workload or server report
Metrics collection is enabled and disabled in Setting Global Configuration Values.
1. From the management console, select the reporting object:
●
To generate a workload report, select a workload or All Workloads.
●
To generate a server report, click the Servers tab and select a server.
2. In the Actions pane, click Generate Workload Report.
3. Select the report type, period of time the report covers, and the interval.
4. Click Generate Report.
Important: The management console uses Microsoft Internet Explorer to display reports,
overriding the user default browser setting. For optimal display, always use Microsoft
Internet Explorer to view reports.
414
Configuring a Server Profile
Within a workload, servers are grouped by profiles, which contain information the agent
discovers and information you configure.
The agent discovers hardware information such as the CPU type and the amount of memory,
and sends it to the concentrator. The concentrator creates a profile entry in the database
for a new profile (or, if the profile values are the same as those in an existing profile, the
existing profile is reused).
If the hardware configuration changes (for example, more RAM is added to a server), Power
and Capacity Management creates a new profile. The original profile is not altered, because
other servers may still be using it. Also, when a hardware change occurs, server capacity
can change.
Information you configure includes capacity values and the power action timeout.
To configure a server profile
1. From the management console, click the Capacities tab. Select one or more profiles.
2. In the Actions pane, click Server Profile Properties.
3. In the Server Profile Properties dialog box:
●
Enter the typical session capacity value, which specifies the number of XenApp
sessions (on average) that the server can host. A zero value is equivalent to not set.
As new servers connect and report their profiles, they inherit any existing
configured capacity value if they have the same profile as an existing configured
server.
●
Enter the power action timeout (seconds) value, which is used when a power off or
power on control is issued. If the operation does not complete successfully before
the timer expires, Power and Capacity Management assumes the operation failed.
●
Enter the estimated session capacity limit in the range 0-10,000 (0 = not set). This
allows the dynamic session capacity feature to estimate capacity higher than the
typical session capacity value when it detects spare computing resources. This
value must be greater than or equal to the typical session capacity value.
To delete a server profile, server, or workload
You can delete a server profile only if it has no associated servers. You can delete a server
only if it (or the server it represents) is not online with the Power and Capacity
Management agent running. You can delete a workload only if it has no servers associated
with it. Deleting a workload also deletes all associated profiles and schedules.
415
Configuring a Server Profile
Select the server profile (from the Capacities tab), server (from the Servers tab), or
workload. In the Actions pane, click one of the following:
●
Delete server profile
●
Delete server
●
Delete workload
After you delete a server profile, server, or workload that is offline, if Power and Capacity
Management discovers those objects, they will be re-created.
416
Configuring Server Properties
Server properties include the control mode and power controller preference.
Control Modes
The control mode affects whether the server is eligible for power management or
participating in load consolidation.
Control Mode
Description
Unmanaged
The server is not controlled by the Power and Capacity
Management system, and is ignored by the workload to which it
belongs. It does not contribute to the capacity of the workload.
Setting this mode is the easiest way to quickly remove a server
from the scope of system control without affecting the rest of the
workload
Managed (base load)
The server contributes to the capacity of the workload and
meeting its current setpoints; however, it is not controlled. The
power management controller does not power this server off or
on, and the load consolidation controller does not disable this
server to force load onto other servers.
Designate XenApp servers that provide essential services as
managed (base load), as essential services such as the data
collector or the data store should not be taken offline. If power
management has a target of keeping a certain number of servers
online, these servers contribute to meeting that target. Similarly,
if load consolidation keeps two servers available, and there are
two available base load servers, they can be used to meet the
load consolidation need.
Managed
The server is fully controlled by the Power and Capacity
Management system.
When planning:
●
Identify which XenApp servers host essential services and do not host XenApp sessions.
Set the server control mode for these servers to unmanaged (or do not install a Power
and Capacity Management agent on them).
●
Identify which XenApp servers host essential services and host XenApp sessions. Set the
server control mode for these servers to managed (base load).
Configure the server control mode for existing servers in server properties (see below), and
for new servers in global configuration.
417
Configuring Server Properties
Power Controller Preference
When Power and Capacity Management determines a power on or power off operation is
required, it considers a server's power controller preference (and site preference, for
XenApp servers installed on virtual machines). For a power on operation, the selection
algorithm chooses a server with a higher power controller preference before a server with a
lower preference. For a power off operation, the algorithm chooses a server with a lower
power controller preference before a server with a higher preference. For best practice,
specify the preference of more power-efficient servers higher than older, less
power-efficient servers. A typical strategy is to specify the most power-efficient servers as
1st choice.
The power controller preference of a server in a Power and Capacity Management farm can
also be managed by XenApp Connector for Configuration Manager. Changing the preference
for those servers from the Power and Capacity Management console can have undesirable
effects.
To configure server properties
1. From the management console, select a workload or All Workloads.
2. Click the Servers tab, then select one or more servers.
3. In the Actions pane, click Server Properties.
●
If you selected one server, set the desired control mode and power controller
preference in the Server Properties dialog box.
If you selected more than one server, set the desired power controller preference
in the Server Properties dialog box. Select the control mode from the Actions
pane: Set "Managed," Set "Unmanaged," or Set "Managed (base load)."
If the power controller preference of one or more selected servers is currently managed by
XenApp Connector for Configuration Manager, the Server Properties dialog box indicates
the names of the affected servers.
●
418
Setting Global Configuration Values
1. From the management console, click Configuration in the Actions pane.
2. In the XenApp PCM Configuration dialog box:
●
Select the control mode for new servers added to the Power and Capacity
Management farm.
This setting differs from the control mode for existing servers, which is set in server
properties. For information about that setting and a description of all control
modes, see Configuring Server Properties.
●
Select the optimal load, which specifies how close to capacity a server can get
before additional load should be directed to other servers. The load consolidator
uses this value.
The optimal load is expressed as a percentage, with a default value of 70% (load
consolidation will add sessions to a server until it reaches or exceeds 70% of full
server capacity). The remaining 30% of capacity acts as a buffer to ensure existing
sessions on the server have spare computing resources to work with. Tune the
optimal load threshold to find the right balance between performance and
utilization.
●
419
Enable or disable metrics data collection. Select the number of days to retain the
collected metrics data. The default is 365 days (1 year).
Configuring Sites
When Power and Capacity Management determines a power on or power off operation is
required, it considers a server's power controller preference, which is configured in server
properties. If the XenApp server is installed on a virtual machine, the power controller
preference for the site is also considered.
To add a site, from the management console:
1. In the Actions pane, click Sites.
2. In the Server Sites dialog box, click Add.
3. Specify a site name and a power controller preference for servers that belong to this
site.
You can also modify or delete a site from the Server Sites dialog box.
420
Adding Virtual Machine Managers
Power and Capacity Management uses virtual machine management to automatically locate
virtual machines it manages; therefore, you do not need to manually configure associations
between the virtual machines and their managing hosts.
Virtual machine management supports multiple concurrent resource pools. The
concentrator automatically connects to the resource pool, and periodically queries the
inventory of virtual machines. The management console displays the inventory poll results
as a count of the number of virtual machines. The concentrator continually updates the
results.
If you move a virtual machine image from one resource pool to another, Power and
Capacity Management discovers this during its inventory polling.
Note: The list of discovered virtual machines does not necessarily match the servers
being managed by Power and Capacity Management; each machine manager maintains a
list of all virtual machines discovered.
When the concentrator selects a server to power on, it queries all virtual machine managers
for a virtual machine with that server's MAC address.
●
If a match is found, the machine manager issues the appropriate commands to the
resource pool to start a virtual machine.
●
If no virtual machine is found (because its machine manager has not been configured or
connected, or because the server image is hosted on a physical machine), Power and
Capacity Management broadcasts the Wake-on-LAN packet on the network. Then, the
concentrator waits a prescribed interval (power control timeout) for the Power and
Capacity Management agent on the appropriate XenApp server to establish connection
to the concentrator.
Important: Assign unique MAC addresses to virtual machines, even across resource pools.
This is typically done using the auto-generate MAC option when creating the virtual
machine.
To add a virtual machine manager
From the management console:
1. In the Actions pane, click Machine Managers.
2. In the Machine Managers dialog box, click Add.
3. Specify the string or URL to the host, cluster, or resource pool master.
4. Select the virtual machine type (see Supported Platforms for version information).
●
421
Citrix XenServer.
Adding Virtual Machine Managers
●
Microsoft Hyper-V.
●
Microsoft SCVMM 2008. The Microsoft SCVMM 2008 console must be installed on each
server hosting a Power and Capacity Management concentrator (master and slaves);
otherwise, you cannot add a virtual machine manager.
●
VMware ESX & vCenter.
5. Specify the site where the resource pool is located.
6. If you select the Authenticate with user name and password checkbox, specify the
credentials. Do not select this checkbox if you want to use the domain credentials of
the Concentrator service to authenticate.
7. Leave the Enable this machine manager checkbox enabled.
You can also modify or delete a virtual machine manager from the Machine Managers
dialog box.
422
Managing the Concentrator
You can install a Power and Capacity Management concentrator on one or more servers.
One concentrator is the master. All connections from agents on the XenApp servers go to
the current master concentrator; there is no load balancing among multiple concentrators.
Important: Multiple concentrators share a common database.
Concentrators negotiate for mastership and monitor the health of the current master
through the database. If the current master stops updating the database, another
concentrator becomes the master. Failover usually occurs within 60 seconds.
Each concentrator registers an Active Directory Service Connection Point (SCP) as part of
the machine account where the concentrator is installed and records an entry in the
database. When the agent on the XenApp server starts, it queries the SCP to discover all
known concentrators. Each agent then tries to connect to each concentrator, looking for
the master. The management console also performs the same discovery process and
connection attempts.
You can explicitly force a running concentrator to become the master concentrator. This
may be necessary when a master concentrator has planned maintenance.
To explicitly designate a master concentrator
1. From the management console, click Cluster Management in the Actions pane.
2. In the Cluster Management dialog box, select a concentrator and click Set Master.
To change the port the agent uses to communicate
with the concentrator
Edit the PCMConcentrator.exe.config file in the Install directory, then restart the PCM
Concentrator service. (The default port is 11168.)
To manually publish the concentrator
If the account running the Concentrator service does not have sufficient access in Active
Directory (AD) to automatically publish its service information, other Power and Capacity
Management components will not be able locate Power and Capacity Management and the
system will not operate correctly. In this case, the concentrator writes errors to the
application log, and the console will not display the XenApp servers on which the agent has
been installed.
To avoid this issue, manually publish the concentrator within AD.
423
Managing the Concentrator
1. Log onto the computer hosting the concentrator, using an account with sufficient
access in AD to publish the service information.
2. Ensure that the Concentrator service is running.
3. From a command prompt, navigate to the directory where the PCMConcentrator.exe
file is located; by default this is “%SystemDrive%\Program Files\Citrix\ XenApp Power
and Capacity Management\Concentrator\”
4. Run the following command: PCMConcentrator /publish.
5. Restart the Concentrator service.
This creates an AD object only; no AD schema changes are required. This object is created
as a child object of the computer container hosting the concentrator, called “CN=Citrix
XenAppPCM SCP”.
Conversely, you can manually revoke the publishing information by running
PCMConcentrator /revoke. This command deletes the aforementioned object in AD.
424
Creating Setpoints and Schedules
Setpoints
A setpoint defines a target capacity level (number of sessions) or a target number of online
servers. You specify setpoints for each workload in a schedule. The power controller uses
four setpoints. The load consolidator uses only the minimum available servers setpoint.
A new workload has default setpoint values that place the workload in the most available
configuration – all managed servers are online. Thus, a newly discovered workload cannot
be power controlled until you define appropriate setpoints for it (and enable power
management).
The setpoints are:
●
Online session reserve. Specifies the amount of online but unused capacity that must be
maintained above the current load. As the load fluctuates throughout the day, the
system maintains this buffer; this is known as a load following model. In practice, the
Power and Capacity Management system powers on the smallest number of servers that
can hold the target online capacity.
Default: Infinite; all servers are kept online. The management console displays this
value as an infinity symbol.
●
Minimum session capacity and maximum session capacity. These setpoints work as
guards for the online session reserve. The online session reserve setpoint can raise and
lower the online capacity, as long as it remains between the two guards.
●
The minimum session capacity setpoint causes servers to be powered up until the
system has at least the amount of online capacity to meet or exceed the setpoint.
After this setpoint is met or exceeded, the minimum session capacity has no effect;
if the online session reserve setpoint drives online capacity above the minimum
session capacity setpoint value, Power and Capacity Management ignores the
minimum session capacity setpoint.
Default: Zero, which is equivalent to not set.
●
●
425
The maximum session capacity setpoint functions similarly to minimum session
capacity; however, it causes servers to be powered off until the online capacity is
at or below the setpoint. Although the maximum session capacity setpoint is used
less frequently, it can be helpful when preparing for system maintenance. After
online capacity is below the setpoint value, this setpoint has no effect.
Default: Infinite, which is equivalent to not set; the management console displays
this value as an infinity symbol.
Minimum available servers. Works on a per-server basis (the other three setpoints are
capacity based) to ensure a minimum level of service availability, in terms of servers.
This can be helpful in handling redundancy; multiple servers ensure acceptance of new
sessions if a server crashes. It can also help logon rates. Logging on new sessions can
Creating Setpoints and Schedules
quickly increase server load to the point where existing sessions are degraded or new
logons take significantly longer to complete. In such cases, using this setpoint can
ensure you have a sufficient number of servers online to load balance the logon load.
The power controller attempts to keep this many servers online, while the load
consolidator attempts to keep this number of servers available to accept new sessions.
You usually increase this setpoint just before and throughout the times of heaviest
usage to ensure sufficient available servers for the high rate of incoming sessions. If you
do not increase this setpoint for the heaviest usage, the capacity setpoints may ensure
there are enough servers online to host the expected load, but the load consolidator
may keep too many servers disabled. Therefore, the servers that are enabled may
become overloaded while new sessions are logging on.
Default: Zero, which is equivalent to not set.
The system tries to meet the online session reserve setpoint first. It then bounds the output
using the minimum and maximum session capacity setpoints. Finally, the system checks and
ensures that the resulting number of online servers meets the minimum available servers
setpoint. Therefore, setpoints have the following order of importance, from highest to
lowest:
●
Minimum available servers
●
Maximum session capacity
●
Minimum session capacity
●
Online session reserve
Schedules
A schedule usually specifies the online session reserve and the minimum available servers
setpoints.
For example, you have a deployment of 10 servers. Each server has a configured session
capacity of 100, and peak session use occurs at 9:30 a.m.
●
To effectively handle demand, schedule the system to ramp up at 9:00 a.m. by setting
the minimum available servers to 5, and the online session reserve to 300.
●
After peak use (9:30 a.m.), schedule the setpoints to lower values at 10:30 a.m., with
minimum available servers set to 2 and the online session reserve set to 100.
●
After normal working hours, reduce these setpoint values further at 7:00 p.m., with
minimum available servers set to 1 and the online session reserve set to 50.
After you initially set the online session reserve and minimum available servers setpoint
values with scheduled changes throughout the day, observe server and session activity, and
then fine-tune the schedule and setpoint values to optimize server capacity and use.
426
Creating Setpoints and Schedules
To create a schedule
From the management console, select a workload and click the Schedule tab.
●
To create a schedule, select the Allow Edit checkbox. Edit the schedule for one or
more days of the week.
●
To copy the schedule from the previous day, click Copy day's schedule in the day of the
week area.
●
To copy the entire workload schedule to another workload, ensure the workload being
copied has focus, then click Copy Schedule To in the Actions pane.
●
To delete a schedule, click Delete Schedule in the Actions pane.
●
To delete an individual schedule item, select the leftmost cell in the item, then press
the Delete key.
Manual Overrides
After you enable a workload for power management, you can manually override the
schedule with different setpoint values. For example, a manual override can be useful when
there is an unexpected surge in demand on the XenApp workload that is likely to continue
for a few hours. Instead of changing the schedule, you can initiate an override. When the
surge has subsided and the normal conditions have returned, you can cancel the override,
and the scheduled setpoint values are reapplied.
Using a manual override can also be helpful when the schedule requires attention or
maintenance.
Manual override differs from disabling power management. During a manual override,
power management is still active, but the setpoints are controlled by the administrator
instead of the schedule. Disabling power management for a workload is equivalent to
turning off the Power and Capacity Management feature for that workload.
To start or stop a manual override
1. From the management console, select the workload.
2. In the Actions pane, click Power Controller Manual Override.
427
●
To start a manual override, click Start Override.
●
To stop (cancel) a manual override, click Stop Override.
Enabling Load Consolidation and Power
Management
You can enable or disable load consolidation and power management on a global and
per-workload basis. When you enable power management and load consolidation globally
(by selecting All Workloads), you can also enable or disable power management and load
consolidation on a per-workload basis. To enable power management or load consolidation
for one workload, power management or load consolidation must be enabled for All
Workloads.
1. From the management console, select a workload or All Workloads.
2. In the Actions pane, the Action menu, or the right-click menu:
●
To enable power management, click Enable power management.
To enable load consolidation, click Enable load consolidation.
To disable power management or load consolidation, click Disable power management
or Disable load consolidation.
●
428
Understanding XenApp Printing
Managing printers in a XenApp environment is a multistage process. The cycle for managing
printers on a farm requires that you:
1. Design your printing configuration. This includes analyzing your business needs, your
existing printing infrastructure, how your users and applications interact with printing
today, and what a realistic printing management model would look like for your
organization (that is, assessing that the administrative overhead of printing pathway
you choose is realistic in your environment).
2. Configure your printing environment, including creating the policies necessary to deploy
your printing design.
3. Test a pilot printing deployment before rolling it out to users.
4. Maintain your Citrix printing environment, including updating policies when new
employees or servers are added and maintaining drivers on your farm servers.
5. Troubleshoot issues that may arise in your printing environment.
Before you begin planning your deployment, make sure that you understand these major
concepts for printing in XenApp:
●
The concept of printer provisioning in a session and the two major types of provisioning
(auto-created and self-provisioned). To understand these concepts, you need to
understand, among other things, the difference between a printer, a printing device,
and a printer driver.
●
How print jobs can be routed in XenApp.
●
The policies that you can create to manage drivers.
XenApp printing concepts build on Windows printing concepts. To configure and successfully
manage printing in a Citrix environment, you must understand how Windows network and
client printing works and how this translates into printing behavior in a Citrix environment.
429
Introduction to Windows Printing
Concepts
This section provides a limited overview of basic printing concepts in a standard
(non-Remote Desktop Services) Windows environment. However, Citrix recommends
reviewing the Windows documentation about network printing, print servers, and Remote
Desktop Services printing before learning about Citrix printing concepts.
In a Windows environment, you can either print from your computer to a locally attached
desktop printer (for example, a printer on LPT1 or COM1) or you can print to a network
printer that is managed by a print server.
This diagram shows how print jobs are spooled from the client device to a print server and
then sent to the printing device in a Windows network.
Here are a few basic definitions:
Printing Device
In the context of this topic, the term printing device refers to the physical printer (that
is, the hardware device to which you send print jobs).
Printers
The term printer refers to the software representation of a printing device. Computers
must store information about printers so they can find and interact with printing devices.
430
Introduction to Windows Printing Concepts
When you see printer icons in the Printers panel in the Control Panel, you are seeing the
software representation of the printers. (You are not seeing the printer drivers.)
For clarity, the term printer object is sometimes used to denote the software
representation of a printing device.
Printer driver
The printer driver is the software program that lets the computer communicate with this
hardware device. This program converts the information to be printed to a language that
the printing device can process. It also understands the device and job settings of the
printing device and presents a user interface for users to configure these. In Windows
systems, printer drivers are distinct from the software representation of printers.
Print job
When a user prints a document, the data sent to the printer is known as a print job. Jobs
are queued to the printer in a specific sequence, which the print spooler controls. When
this sequence appears, it is known as the print queue.
Print spooler
The spooler is the Windows service that manages printer objects, coordinates drivers,
lets you create new printers, determines where print jobs are processed, and manages
the scheduling of print jobs. The print spooler also determines if the printer prints each
page as it receives it or if the printer waits until it receives all pages to print the job.
Typically, when a print job is spooled to a printer, the spooler loads documents into a
buffer. The printing device then retrieves the print jobs from the buffer when it is ready
to print the job. By storing the job, the computer can perform other operations while the
printing occurs in the background.
Print queue
A sequential, prioritized list of the print jobs waiting to be printed. The spooler
maintains this list for each printer object in the computer.
Print server
A computer that manages the communications between client devices and printers. In
this context, the term print server refers to dedicated computers that are running a
Windows server operating system and hosting x number of shared printers. Print servers
provide client workstations with drivers they need to print and store files, or print jobs,
in a print queue until the printer can print them. A print server is a remote print spooler.
Network printer
A shared printer object accessed through a network print server.
431
Local and Remote Print Job Spooling
Print job spooling is important because where print jobs are spooled to is where print jobs
are processed. Processing location affects network traffic, resource utilization, and has
additional implications in a XenApp context.
Print jobs can be spooled either locally or remotely. Typically, print jobs sent to locally
attached printers are spooled locally, and jobs sent to network printers are spooled
remotely.
Locally Spooled Print Jobs
When print jobs are spooled locally, the local Windows computer processes the job. The
application creates a spooled print job; the local print spooler, aided by the printer driver,
processes the print job, and sends the rendered output to the printing device.
In a Windows environment, when you print to a printer connected to your local computer
(when print jobs are spooled locally), the printer drivers and settings are stored on the
computer itself. A typical printing process for locally spooled print jobs is:
1. The application tells the local spooler to create a print job and an associated spool file
on the local computer.
2. On the local computer, Windows writes the application’s drawing commands to the
local spool file. This process of writing commands occurs repeatedly until the job is
completely spooled.
3. The local spooler processes the job with the printer driver in a process known as
rendering.
4. The local spooler delivers the rendered data to the printing device (for example, a
locally attached printer).
Remotely Spooled Print Jobs
When print jobs are spooled remotely, the Windows print server processes the print job.
A typical printing process for remotely spooled print jobs is
1. The application tells the remote spooler to create a print job on the print server and an
associated spool file.
2. On the local computer, Windows writes the application’s drawing commands to the
remote spool file. This process of writing commands across the network occurs
432
Local and Remote Print Job Spooling
repeatedly until the job is completely spooled.
3. The remote spooler processes the job with the printer driver in a process known as
rendering.
4. The print server delivers the rendered data to the printing device (typically a network
printer).
Key Differences Between Remote and Local Spooling
Unlike remote spooling, local spooling does not use any network resources. Remote spooling
requires that the local computer and the remote printer exchange many messages across
the network. Even in a non-Citrix environment, if a WAN has substantial latency, users will
have a poor user experience if the print jobs are spooled remotely across the WAN.
However, in some situations, for example when the resources on the local computer are
needed for other tasks, remote spooling is preferable. In remote spooling, the print job is
processed on the print server, which off-loads processing from the local computer.
433
XenApp Printing Concepts
In a XenApp environment, all printing is initiated (by the user) on the server. However,
print jobs are not always sent directly from the server to the printing device. Instead, the
print jobs can be redirected through the client device.
Because there is no persistent workspace for users in XenApp (when a session ends, the
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 Print, XenApp:
●
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:
434
●
The difference between the client and network printing pathway and how this is not
the same as local printers and network printers
●
The term printer provisioning, the types of printer provisioning (static and dynamic),
printer autocreation, and user self-provisioning
●
Print job routing and when changing it can improve utilization
●
The basics of printer driver management
Overview of Client and Network Printing
Pathways
An important concept in XenApp is the printing pathway. The term printing pathway
encompasses both the path by which print jobs are routed and the location where print jobs
are spooled. Both aspects of this concept are important. Routing affects network traffic.
Spooling affects utilization of local resources on the device that processes the job.
In XenApp, print jobs can take two different printing pathways:
●
Network printing pathway
●
Client printing pathway
Network Printing Pathway
The term network printing pathway refers to print jobs that are routed from the farm
server hosting the user’s session to a print server and spooled remotely.
This diagram shows a XenApp network printing example: Printing begins on the farm server
hosting the user’s session (where the application is published and executing). XenApp
routes the print job over a network connection to the network print server. The network
print server then routes the print job to an associated network printing device.
When a print job is spooled remotely in a Windows environment, it uses this process:
1. The application tells the remote spooler to create a print job and an associated spool
file.
435
Overview of Client and Network Printing Pathways
2. The Windows Print Provider sends the spool file to the print server.
3. The print server processes the spool file.
4. The print server then sends the print job to the appropriate network printer.
Server Local Printers
The term server local printers refers to a configuration that uses the network printing
pathway where printing devices are attached locally to a XenApp farm server. Server local
printers are shared printing devices that are physically attached to a farm server.
Note: To use a locally attached printer as a server local printer in a XenApp farm, the
printer must be shared; otherwise XenApp does not recognize it.
Server local printers are often a good choice for printing in small farm environments.
However, server local printers are not used widely in enterprise environments because they
require installing the printer drivers on each server in the farm and require additional
resources on the XenApp server. Server local printers are managed and configured in the
same ways as network printers.
This diagram shows a XenApp server local printing example: Printing begins on the farm
server hosting the user’s session and is routed to a printing device attached locally to the
server.
436
Overview of Client and Network Printing Pathways
Client Printing Pathway
The term client printing pathway refers to print jobs that are routed over the ICA protocol
through the client device to the printer (either a printer connected directly to the client
device or connected through a print server) and spooled on the Citrix online plug-in.
When using the client printing pathway, a virtual printer is constructed in the session that
redirects to the printer object on the client device. The client device, in turn, sends the
print job to the printing device.
Importantly, because all processing occurs on the XenApp server, when users print a
document from a published application, they are actually starting that print job on the
XenApp server. These jobs are spooled locally on the XenApp server.
There are two different configurations of the client printing pathway: one for printers
attached directly to the client device and another for network printers.
Locally Attached Client Printers
The simplest configuration is the one where the printer is attached directly to the client
device. In this configuration, the application server sends the print job back to the
client/client device. The client device then relays it to a locally attached printer.
This diagram shows a simplified XenApp client printing example: Printing begins on the
server where the application is published. XenApp sends the print job over the connection
to the client device. The client device then routes the print job to the printer connected
locally to the client device.
When a print job is spooled to a client along the client printing pathway, it uses this
process:
1. The published application tells the local spooler on the server hosting the application
(that is, the host server) to create a print job and an associated spool file on the host
server.
437
Overview of Client and Network Printing Pathways
2. 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.)
3. The local spooler processes the job with the printer driver in a process known as
rendering.
4. The rendered data is delivered to the client device through the ICA protocol.
5. The client device relays the print data to the client-side printing device (a locally
attached printer in this example).
Client Printers on the Network
While client printers are often printers physically attached to client devices, they can also
be printers on the network. In this case, print jobs are routed through the client device to
the print server.
The process is the same as for printing to a local printing device through the client.
However, instead of sending the job to the client device, the job is sent to the network
print server.
This diagram shows client printing to a network printer: Printing begins on the server where
the application is published. XenApp routes the print job over the connection to the client
device. The client device then routes the print job over the network to the print server,
which in turn routes the print job to the network printer.
438
Overview of Client and Network Printing Pathways
When a print job is spooled to a network printer along the client printing pathway, it uses
this process:
1. The application server sends the print job to the client for processing.
2. The client processes the spooled job and sends it to the Windows print server for
processing.
3. The Windows print server then sends the print job to the appropriate network printer.
Configuring XenApp to use the client printing pathway for network printing devices is useful
when a print server is in a domain different from the farm servers (and the client devices
have access to the print 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.
439
Provisioning Printers for Sessions
For a computer to process a print command, it needs both the required printer object and a
printer driver. Because sessions are hosted in a virtual workspace instead of locally on a
hard drive, printers and their drivers are not stored on the local computer. Instead, they
are restored at logon or reconnect. The process by which XenApp makes printers available
in a session is known as provisioning.
You can control printer provisioning and the way you configure it affects what printers users
see in sessions and the speed of the printers.
There are two types of printer provisioning:
●
Static. Server local printers are provisioned only once, when you connect them to the
farm server. After that, they are always created in sessions with the same properties
and do not vary according to policies.
●
Dynamic. The printers that are available in a session are determined as the session is
built. As a result, they can change according to changes to policies, changes in user
location, and changes to the network (provided they are reflected in policies). When
printers are provisioned dynamically, the printers that appear in a session are not
predetermined and stored. Rather, the printers are assembled, based on policies, as
the session is built.
Because provisioning static printers is relatively simple, this topic focuses on provisioning
printers dynamically.
The two most common methods of dynamic printer provisioning are:
●
User provisioning
●
Autocreation
To control what printers users have in their sessions and ensure printers are available when
users start their sessions, provision their printers through autocreation. If you do not want
to specify (and administer) user printers, you can let users self-provision their printers.
If you choose, you can prevent printer autocreation and let users provision printers visible
from their client device.
User Provisioning
You can allow users to add printers to their sessions on their own. Users can map client
printers that are not autocreated by policy manually in a user session through the Windows
Add Printer wizard on the server (in their sessions). If users have thin clients or cannot
access their client devices, they can self-provision by running the ICA Client Printer
Configuration tool (PrintCfg.exe). For users to self-provision with the utility, you must
publish PrintCfg.exe on your farm.
440
Provisioning Printers for Sessions
Autocreation
The term autocreation refers to printers XenApp creates automatically, at the beginning of
each session, based on what printers are configured on the client device and any policies
that apply to the session.
By default, XenApp makes printers available in sessions by creating all printers configured
on the client device automatically, including locally attached and network printers. After
the user ends the session, the printers for that session are deleted. The next time a session
starts, XenApp evaluates any policies for printer creation and enumerates the appropriate
printers from the client device.
You can change the default autocreation policy settings to limit the number or type of
printers that are auto-created. XenApp can auto-create:
●
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.
441
Auto-Creating Client Printers
The autocreation feature creates a list of printers that a user can use after logging on.
When the user logs in, their print drivers will be installed and all printers returned in this
list will be available for use.
XenApp can auto-create redirected client printers in two different ways:
●
By creating a one-to-one match with printers on the client device
●
By creating one generic printer, the Citrix Universal Printer, that represents all (or any)
printers on the client device
In many environments, especially large ones, Citrix recommends that you auto-create only
one default printer. Auto-creating a smaller number of printers creates less overhead on
the server and is better for CPU utilization.
However, in environments where users with limited computer skills need to print to a wide
variety of local printing devices, you may want to leave the default autocreation setting so
that all printers are created on logon.
If you do not want large numbers of printers created at the beginning of each session,
consider specifying for XenApp to use the Citrix Universal Printer.
Auto-Creating Printers from the Client Device
At the start of a session, XenApp auto-creates all printers on the client device by default.
You can control what, if any, types of printers are provisioned to users and prevent
autocreation entirely.
The Citrix policy setting Auto-create client printers lets you control autocreation and
specify that:
●
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:
442
●
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
Auto-Creating Client Printers
●
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:
●
443
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.
Auto-Creating Client Printers
The Citrix Universal Printer does not work if plug-ins are not connecting through the ICA
channel, such as when you are using the Citrix Offline Plug-in and streaming
applications to the client.
If you want to use a universal printing solution for non-Windows plug-ins, use one of the
other universal printer drivers that are based on postscript/PCL and installed
automatically with XenApp.
●
The Citrix Universal printer driver might also create smaller print jobs than older or less
advanced printer drivers. However, sometimes it might be better to use a
device-specific driver because the driver might be able to optimize print jobs for its
associated printer.
Note: If you want the Citrix Universal Printer to appear in sessions, make sure that the
Citrix policy setting Client printer names is not set to Legacy printer names in any
policies affecting those sessions.
Universal printer drivers are installed by default on each farm server; the printer is not
enabled, however. To get the best results when configuring your farm, use both the Citrix
Universal Printer and a Citrix Universal printer driver.
Note: Citrix Universal Printing is available for Citrix Presentation Server Client, Version
9.x or Version 10.x, Citrix XenApp Plugin for Hosted Apps 11.0, the Citrix Online Plug-in,
the Citrix XenApp Plug-in for Streamed Apps, and the Citrix Offline Plug-in. This feature
is available in Presentation Server 4.0 to XenApp 6.
Citrix Universal Printer
The Citrix Universal Printer is a generic printer created at the beginning of sessions that can
be used with almost any printing device. This printer can print to and communicate,
through the client, with any client-side printer.
You may also want to use the Citrix Universal Printer because the printer name does not
change when users reconnect. Changing printer names can cause problems for some
applications.
The Citrix Universal Printer is created on a per-session basis. When used with a Citrix
Universal Printer driver, it can greatly reduce the resource usage at the start of a session
from printer autocreation. When you use the Universal Printer, you can specify that only
the Universal Printer be auto-created for each printer on the client device.
When the Citrix Universal Printer is enabled, an extra printer is created in the session with
the name Citrix UNIVERSAL Printer in session number of session. To use only the Citrix
Universal Printer in sessions and not auto-create any printers on the client device, enable
the Universal Printer through the registry and configure the Citrix policy setting
Auto-create client printers to Do not auto-create client printers.
The user experience varies depending on the type of Citrix Universal Printer.
Because the Citrix Universal Printer is not tied to a specific printing device, both the
EMF-based and XPS-based Citrix Universal Printers provide ways to preview and select
settings:
444
Auto-Creating Client Printers
●
EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display
a print preview before printing. If the Preview on client option is selected in the
printer’s printing preferences, the user sees a preview of the print job and has the
option of choosing a target printer and controlling print device setting. If the Preview
on client option is not selected, no preview is displayed and print job is routed directly
to the default printer on the user device.
●
XPS-based Citrix Universal Printer. Like Microsoft XPS Document Writer, the Citrix XPS
Universal Printer sends documents to Internet Explorer if a user selects Print Preview or
modifies the print settings, displaying them in 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 11x, or the Citrix Online Plug-in.
445
Auto-Creating Network Printers
By default, any network printing devices on the client device are created automatically at
the beginning of sessions. However, if possible, XenApp always tries to route jobs directly
from XenApp to the print server and not through the client connection.
To specify that specific printers are created in sessions rather than auto-create all the
network printing devices available from the client device, configure the Citrix policy setting
Session printers.
Network printers created with the Session printers setting can vary according to conditions
where the session was initiated, such as location (by filtering on objects such as subnets).
Note: For printers in domains that do not have a trust relationship with the XenApp farm,
disable the Citrix policy setting Direct connections to print servers. When this setting is
disabled, print jobs are routed through the client using the client printing pathway.
446
Letting Users Provision Their Own
Printers
If you do not want specific printers to be auto-created at the beginning of each session,
allow users to add their own printers.
By default, provided they can access the network from their client devices, all users can
add printing devices to be used in a session. The only time users cannot add printers to
their sessions is when they cannot access their client device because they are using a thin
client and there are no applications published that let them browse and add printers.
Printers that users create on their own during a session are known as retained printers
because they are created again (or remembered) at the start of the next session. When
XenApp recreates a retained printer at the start of a session, it considers all Citrix policy
settings except Auto-create client printers.
Retained printers appear in sessions on that device until the client printer within the
session is deleted manually, the remembered printer connection is removed from the
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.
447
Device or Session-Based Print Settings
By default, all changes users make to the printer device settings and preferences, whether
in a session or working on their local computer, are saved and used locally and in a session.
This means that printer settings and preferences are always the same on the client device
and in a session. Citrix policy settings let you change the way XenApp software saves and
applies printer device settings and preferences.
You can configure sessions to obtain print settings, specifically user printing preferences,
from either the printer object or the printing device.
XenApp can write printer settings to the printer object at the end of a session or to a client
printing device, provided the 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.
448
Device-Based Print Settings
Caution: Using Registry Editor incorrectly can cause serious problems that may require
you to install your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
If you have Windows users with locally attached printers who work on applications locally
and on the server, you might want to retain changes to the printer settings the users make
locally outside of a session. To do so, create and set the Win32FavorRetainedPrinterSettings
registry key to False, as described in To synchronize properties from the printer.
When the registry key is modified, the plug-in gives priority to settings from the printer,
rather than retained settings. Settings in the session stay synchronized with settings on the
printing device. If a change was made to the printer out of a session, the change is picked
up. If a change is made to the printer inside the session, the plug-in attempts to write the
change back to the printer on the client device when logging off.
You must have the same driver on the client device and server. If you do not, only a subset
of settings is exchanged between the real printer and the virtual printer in the session.
Some device independent settings are inherited and others are not.
449
Controlling Printing Settings and User
Preferences
To understand how printing preferences are retained and applied, you must understand:
●
The locations printing settings can be stored in a XenApp environment
●
The priority XenApp software uses to apply printing preferences from previous sessions
to the printers in a newly created session
●
Where XenApp software stores printing preferences by default and if there are factors
in your environment that will prevent the software from successfully storing them in
this location (that is, when you need to change this setting)
General Locations of Printing Preferences
In Windows printing environments, changes made to printing preferences can be stored on
the local computer or in a document. In a XenApp environment, when users modify printing
settings, the settings are stored in these locations:
●
On the client device itself. The settings are set on the client device by right-clicking
the printer in the Control Panel and selecting Printing Preferences. For example, if
Landscape is selected as page orientation, landscape is saved as the default page
orientation preference for that printer. This type of preference is known as Device
Settings.
●
Inside of a document. In word-processing and desktop-publishing programs, settings,
such as page orientation, are often stored inside documents. These settings are often
referred to as Document Settings. For example, when you queue a document to print,
Microsoft Word typically stores the printing preferences you specified, such as page
orientation and the printer name, inside the document. These settings appear by
default the next time you print that document.
●
From changes a user made during a session. XenApp keeps only changes to the
printing settings of an auto-created printer if the change was made in the the Control
Panel in the session; that is, on the server.
●
On the server. These are the default settings associated with a particular printer driver
on the server.
If you want to control user printing preferences, it is important to understand that the
settings preserved in any Windows-based environment vary according to where the user
made the changes. This also means that the printing settings that appear in one place, such
as in a spreadsheet program, can be different than those in others, such as documents. As
result, printing settings applied to a specific printer can change throughout a session.
450
Controlling Printing Settings and User Preferences
Hierarchy of Users’ Printing Preferences
Because printing preferences can be stored in multiple places, XenApp processes them
according to a specific priority. Also, it is important to note that Device Settings are
treated distinctly from, and usually take precedence over, Document Settings.
XenApp searches for settings in this order:
1. XenApp checks for retained printer settings.
If XenApp finds retained settings, it applies these settings when the user prints.
2. If there are no retained printer settings, XenApp searches for any changes to the printer
settings for the default printer for the client device.
If XenApp finds any changes to printing preferences on the client device, it applies
these settings when the user prints.
3. If there are no retained or client printer settings, XenApp applies the default printer
settings stored on the server when the user prints.
At this point, the printer settings are merged. Generally, XenApp merges any retained
settings and the settings inherited from the client device with the settings for the default
printer driver on the server.
By default, XenApp always applies any printing settings a user modified during a session;
that is, the retained settings, before considering any other settings.
Saving Users’ Printing Preferences
By default, XenApp attempts to store printing properties, a combination of the 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.x and higher to
store user-modified printer properties on the client device.
●
Type of Windows user profile. That is, if you are using local, roaming, or mandatory
profiles on your Windows network.
If you are using a mandatory profile and you want to retain the user’s printer
properties, you must store the properties on the client device.
451
Controlling Printing Settings and User Preferences
●
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.
452
Setting Default Printers
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 To specify a default printer for a session for details.
However, if you specified that XenApp auto-create the default client printer, then, if no
other printers are provisioned in sessions, you might not need to specify a default session
printer.
453
Printing and Mobile Workers
In situations where users move among different workstations or sites, you can make sure
that the closest printers are presented to them wherever they try to print. Examples of
such users include hospital workers who move among workstations in different wings of a
hospital, reconnecting to the same session using a smart card, or employees who travel to
remote business units.
If you have mobile workers and need this type of printing functionality, use one of these
features:
●
SmoothRoaming
●
Proximity Printing
SmoothRoaming
Also known as Workspace control, this feature lets a user disconnect from one session,
move to another device, and reconnect to continue that same session. The printers assigned
on the first client device are replaced on reconnection with the printers designated on the
second client device. As a result, users are always presented with applicable printer options
from wherever they connect.
Proximity Printing
This feature lets you control the assignment of network printers so that the most
appropriate printer is presented, based on the location of the client device.
The Proximity Printing solution is enabled through the 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:
●
454
The name of the workstation, if the name relates to the workstation’s location
Printing and Mobile Workers
●
455
Your network’s IP addresses, if they correlate with user locations
Optimizing Printing Performance by
Routing
In a XenApp environment, you can control how print jobs destined for network printers are
routed. Jobs can take two paths to a network printing device: along the client or network
printing pathway.
By default, XenApp routes print jobs along the client printing pathway as follows:
●
Auto-created client printers. XenApp routes jobs to locally attached printers from the
server, through the client, and then to the print device. The ICA protocol compresses
the print job traffic. When a printing device is attached locally to the client device, the
jobs must be routed through the plug-in.
●
Auto-created network printers. By default, all print jobs destined for network printers
route from the server, across the network, and directly to the print server. However, if
the application server and the print server are on different domains, XenApp
automatically routes the print job through the plug-in.
When network printers are visible from the server, you can use policies to control how print
jobs are routed to network printers. You can configure that jobs be routed to network
printers:
●
Through the 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.
456
Managing Printer Drivers
During printer auto-creation, if XenApp detects a new local printer connected to a client
device, it checks the server hosting the published application (from which the user is trying
to print) for the required printer driver. By default, XenApp automatically installs a native
driver if one is not found on the server hosting the published application.
Because users in a XenApp environment do not have a persistent workspace, drivers cannot
be stored on the client. To print to a local device, XenApp must find the correct driver on:
(a) its server or in the 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:
●
457
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
Managing Printer Drivers
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:
458
●
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
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.
459
Default Printing Behavior
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
Auto-create client printers with the Auto-create all client printers option.
●
XenApp routes all print jobs queued to printers locally attached to client devices as
client print jobs (that is, over the ICA channel and through the client device).
●
XenApp routes all print jobs queued to network printers directly from the server hosting
the published application. If XenApp cannot route the jobs over the network, it will
route them through the client device as a redirected client print job. This behavior is
equivalent to disabling the Citrix policy setting Direct connection to print servers.
●
XenApp retains all properties and settings users configure for printers they provision
themselves in sessions. XenApp stores printing properties on the client device. If the
client device does not support this operation, XenApp stores printing properties in the
user profile for that user. This behavior is equivalent to configuring the Citrix policy
setting Printer properties retention with the Held in profile only if not saved on
client option.
●
XenApp uses the Windows version of the printer driver if it is available on the server
hosting the application. If the printer driver is not available, the XenApp server
attempts to install the driver from the Windows operating system. If the driver is not
available in Windows, it uses one of the Citrix Universal printer drivers. This behavior is
equivalent to enabling the Citrix policy setting Automatic installation of in-box printer
drivers and configuring the Universal printing setting with the Use universal printing
only if requested driver is unavailable.
Note: If you are unsure about what the shipping defaults are for printing, display them by
creating a new policy and setting all printing policy rules to Enabled. The option that
appears is the default.
460
Printing Policy Configuration
When users access printers from published applications, you can configure XenApp policies
to specify:
●
How printers are provisioned (or added to sessions)
●
How print jobs are routed
●
How printer drivers are managed
You can have different printing configurations for different client devices or users or any
other objects on which policies are filtered. You must understand the ramifications of
setting the options in printing policies, so review the information in the printing topics
carefully before configuring them. See Configuring and Maintaining XenApp Printing for
configuration details.
461
Printing Security
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.
462
Purchasing Printing Hardware
Before purchasing printers for your organization, Citrix recommends finding out if the
printer models that you are considering were tested for multiuser environments, such as
Windows Remote Desktop Services environments and Citrix XenApp.
When purchasing a printer, make sure that it is PCL or PS compatible. Also, make sure the
printer is not a host-based printer. Host-based printers use the processor on the host
computer to generate print jobs; they are often labeled as “GDI,” “HOST only,” or “LIDL.”
Because these printers require software on the client device to generate the print job, they
are difficult to run in a XenApp environment.
Whether printers work in a XenApp environment is determined by the printer manufacturer,
not by Citrix. To determine if a printer model supports XenApp, contact the manufacturer
or see the Citrix Ready product guide at www.citrix.com/ready.
463
Configuring and Maintaining XenApp
Printing
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.
464
Configuring Printer Autocreation Settings
Configure the Citrix policy setting Auto-create client printers to control how or if printers
are created automatically at the start of sessions. By default, this setting is not enabled, so
XenApp creates all printers on the user device.
To modify printer auto-creation behavior
Configure one of the following in the Auto-create client printers setting:
●
Do not auto-create client printers. Client printers are not auto-created.
●
Auto-create the client’s default printer only. Only the client’s default printer
attached to or mapped from the client preconfigured in the Control Panel is
auto-created in the session.
●
Auto-create local (non-network) client printers only. Any non-network printers
attached to the client device preconfigured in the Control Panel are auto-created in
the session.
●
Auto-create all client printers. All network printers and any printers attached to or
mapped from the user device preconfigured in the Control Panel are auto-created in
the session.
To configure legacy client printer support
To auto-create client printers with legacy printer names and preserve backward
compatibility for users or groups using MetaFrame 3.0 or earlier, choose the Legacy printer
names option from the Citrix policy Client printer names setting.
465
Configuring Citrix Universal Printing
There are several different Universal Printing solutions. You can configure:
●
Citrix XPS Universal Printer driver
●
Citrix Universal Printer driver, which is EMF-based
●
Auto-created Citrix Universal Printer with a Citrix Universal printer driver
Configuring only a Universal printer driver will not improve session start time (printers on
the client device are still enumerated and auto-created at the beginning of sessions).
However, configuring a Universal printer driver does improve printer driver performance.
To configure universal printing
To configure universal printing, use the following settings:
466
●
Universal print driver usage. Specifies when to use universal printing.
●
Auto-create generic universal printer. Enables or disables auto-creation of the generic
Citrix UNIVERSAL Printer object for sessions when a user device compatible with
Universal Printing is in use. By default, the generic Universal Printer object is not
auto-created.
●
Universal driver preference. Specifies the order in which XenApp attempts to use
universal printer drivers, beginning with the first entry in the list. You can add, edit, or
remove drivers and change the order of the drivers in the list.
●
Universal printing preview preference. Specifies whether to use the print preview
function for auto-created or generic universal printers.
●
Universal printing EMF processing mode. Controls the method of processing the EMF
spool file on the Windows user device. By default, EMF records are spooled directly to
the printer. Spooling directly to the printer allows the spooler to process the EMF
records without prompting the user for additional information, minimizing the
occurrence of illegible output.
●
Universal printing print quality limits. Specifies the maximum dots per inch (dpi)
available for generating printed output in the session. By default, no limit is specified.
●
Universal printing image compression limit. Defines the maximum quality and the
minimum compression level available for images printed with the Universal printer
driver. By default, the image compression limit is set to Best Quality (lossless
compression). If No Compression is selected, compression is disabled for EMF printing
only. Compression is not disabled for XPS printing.
Configuring Citrix Universal Printing
●
Universal printing optimization defaults. Specifies default settings for the Universal
Printer when it is created for a session:
●
Desired image quality. Controls the level of image compression. By default,
Standard quality is selected.
●
Enable heavyweight compression. Enables or disables reducing bandwidth beyond
the compression level set by Desired image quality, without losing image quality.
By default, heavyweight compression is disabled.
●
Allow caching of embedded images. Allows or prevents embedded images to be
cached. By default, image caching is allowed.
●
Allow caching of embedded fonts. Allows or prevents embedded fonts to be
cached. By default, font caching is allowed.
Allow non-administrators to modify these settings. Allows or prevents
non-administrative users from modifying any of these options through the printer
driver's printing preferences. By default, users cannot modify these options.
These options are supported for EMF printing. For XPS printing, only the Desired image
quality option is supported.
●
When Universal printing image compression limit and Universal printing optimization
defaults are both used:
●
If the compression level in the Universal printing compression limit setting is lower
than the level defined in Universal printing optimization defaults setting, images are
compressed at the level defined in the Universal printing compression limits setting.
●
If the Universal printing compression limit setting is set to No Compression, the
Universal printing optimization defaults setting's Desired image quality and Enable
heavyweight compression options have no effect in the policy.
For more information, see Configuring Universal Printer Drivers on Farm Servers.
To change default settings on the Universal Printer
You can change default settings for the Citrix Universal Printer, including settings for paper
size, paper width, print quality, color, duplex, and the number of copies. You override the
default settings of the Citrix Universal Printer and modify these settings by manually setting
registry keys. For a list of the specific registry values, see the Citrix Knowledge Center.
467
Configuring Network Printers for Users
If automatic printer creation fails for network printers on a client device or for session
printers because the corresponding drivers are not installed automatically by Windows
(because you configured a policy setting preventing auto-installation or they are third-party
drivers), you must add the corresponding drivers to your farm servers manually.
1. Add printers to the XenApp server by manually installing the printers. You can use the
Add Printer wizard in Windows or browse to the server on which the printer is installed
and double click the printer, which forces Windows to place the drivers in its local
driver store.
2. Delete the printers. Deleting the printers ensures that they are created only when
intended; that is, only if the client has that network printer installed or the GPO with
Session printers configured uses filtering and applies to only a subset of all users of the
XenApp server.
468
To add a network printer while configuring
the Session printers setting
In the Citrix policy setting for Session printers, add a network printer using one of the
following methods:
●
Printer UNC path. Enter the path using the format \\servername\printername.
●
Browse. Locate a printer on the network.
●
Browse for printers on a specific server. Enter the server name using the format
\\servername and click Browse.
Important: The server merges all enabled session printer settings for all applied policies,
starting from the highest to lowest priorities. When a printer is configured in multiple
policy objects, custom default settings are taken from only the highest priority policy
object in which that printer is configured.
469
To specify a default printer for a session
To specify a network printer, it must already be added to the policy in which you are
enabling the Citrix policy setting Default printer.
1. Complete the procedure, To add a network printer while configuring the Session
printers setting.
2. On the Default printer settings page, from the Choose client’s default printer
drop-down list, choose one of the following:
●
Name of the network printer you want to be default for this policy. Printers that
were added with the Session printers policy setting are displayed in this drop-down
menu and can be specified as the default printer.
●
Set default printer to the 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 Do not adjust the user’s default printer is selected, the default printer in a
session will be the first printer auto-created in the session, which is either:
●
The first printer added locally to the Windows server in the Control Panel
The first auto-created printer, if there are no printers added locally to the
server
3. Apply the policy to the group of users (or other filtered objects) you want to affect.
●
470
To edit the printer settings in the sessions
policy
Use the Citrix policy setting Session printers to override printer's default settings at the
beginning of each session. This setting overrides retained printer settings the user set
during a previous session.
You can set print quality, orientation, color, duplex, scale, copy count, TrueType option,
and paper size. If you specify a printing option that the printer does not support, that
option has no effect.
1. On the Session printers settings page, select the name of the printer for which you
want to modify the settings.
2. Click Settings.
3. Specify the printer settings.
471
To configure server local printers
To let users connecting to the farm print to a printer that is local to a farm server,
physically connect the printer to a farm server and share it as follows:
1. On the server where the printer is physically connected, in Control Panel > Hardware >
Devices and Printers, right-click the printer you want to share.
2. Choose Printer Properties.
3. In the Sharing tab, select these check boxes:
●
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.
●
472
Configuring Printers for Mobile Workers
When you want to make sure that users always see the closest printer to their client device
in a session, configure the Proximity printing solution. Proximity printing enables users
within a specified IP address range to automatically access the network printing devices
that exist within that same range.
The ability to configure proximity printing assumes that your network is designed as
follows:
●
It uses a DHCP server to assign your users’ IP addresses by their location (for example,
floor of a building)
●
All departments/floors within the company have unique designated IP address ranges
●
Network printers are assigned IP addresses within the range of IP addresses for the
department/floor in which they are located
To configure Proximity Printing using IP addresses
1. Create a separate policy for each subnet (or to correspond with printer location).
2. In each policy, add the printers in that subnet’s geographic location to the Session
printers setting.
3. Set the Default printer setting to Do not adjust the user's default printer.
4. Filter the policies by Client IP address.
473
Changing Network Print Job Routing
By default, XenApp routes jobs to network printers from the application server directly to
the print server (along the network printing pathway).
Note: Print jobs sent over the network printing pathway are not compressed. When
routing printing jobs across a network with limited bandwidth, Citrix recommends routing
jobs through the client device so that the ICA protocol compresses the jobs. To do so,
disable the Citrix policy setting Direct connection to print servers.
474
Providing Tools for User Provisioning
The following groups of users cannot add printers to sessions unless you publish printer
provisioning tools for them:
●
Windows users who do not have access to the Add Printer wizard on the local client
device or any applications that let them browse to printers
●
Non-Windows plug-in users
If you want these users to add printers on their own, publish either:
●
The ICA Client Printer Configuration Tool (PrintCfg.exe). This tool lets Windows CE and
DOS users add printers.
●
The Add Printer wizard. Publishing this Windows wizard lets users with Windows
plug-ins add printers that are on the local client device or network. Publishing this
wizard is also referred to sometimes as publishing the Print Manager.
After a user adds printers using either of these methods, XenApp retains the printer
information for the next time a user logs on from that client device. Client printers created
using this process are considered retained printers.
To publish the Windows Add Printer wizard
This procedure assumes that you already published Windows Explorer on the server on
which you want to publish the Add Printer wizard.
1. Create the following folder at the root level of one of the XenApp server’s drives:
C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D} where C represents a drive on
the XenApp server.
When you press Enter, the folder icon changes to a printer icon.
2. Create a published application with the following properties:
Command line. “Path of explorer.exe”
C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}
Working directory. The path where explorer.exe is located.
If you get a path error and cannot access the published printers folder, modify the
command line to include %*. For example,
Command line. “Path of explorer.exe”
%*C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}
475
Providing Tools for User Provisioning
To publish the ICA Client Printer Configuration Tool
1. Follow the instructions for publishing an application in To publish a resource using the
Publish Application wizard.
2. On the Location page, enter the path for the ICA Client Printer Configuration tool
(printcfg.exe) on your server.
On a 64-bit system, the default location for the tool is C:\Program Files
(x86)\Citrix\system32\printcfg.exe.
On a 32-bit system, the default location for the tool is C:\Program
Files\Citrix\system32\printcfg.exe.
476
To store users’ printer properties
To store user printer properties, configure the Citrix policy setting Printer properties
retention by choosing from the following settings:
477
●
Held in profile only if not saved on client allows the system to determine where
printer properties are stored. Printer properties are stored either on the client device,
if available, or in the user profile. Although this option is the most flexible, it can also
slow logon time and use extra bandwidth for system-checking.
●
Saved on the client device only is for user devices that have a mandatory or roaming
profile that is not saved. Choose this option only if all the servers in your farm are
running XenApp 5 and above and your users are using Citrix online plug-in versions 9.x,
10.x, 11.x, and 12.x, or Citrix Receiver 13.x.
●
Retained in user profile only is for user devices constrained by bandwidth (this option
reduces network traffic) and logon speed or for users with legacy plug-ins. This option
stores printer properties in the user profile on the server and prevents any properties
exchange with the user device. Use this option with MetaFrame Presentation Server 3.0
or earlier and MetaFrame Presentation Server Client 8.x or earlier. Note that this is
applicable only if a Remote Desktop Services roaming profile is used.
To synchronize properties from the printer
To obtain printer properties directly from the printer itself, rather than from the properties
store, use the following procedure. This procedure ensures that changes made offline to
printers on the local computer are used next time a user starts a session.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
1. Open the Registry Editor and navigate to one of the following registry locations:
●
For 64-bit, HKLM\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown
Profiles\All Regions\Preferences
For 32-bit, HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown
Profiles\All Regions\Preferences
2. Create the following registry key: Name:Win32FavorRetainedPrinterSettings Data Type:
REG_SZ Value Data: false
●
3. Restart the Citrix Print Manager Service.
478
Controlling Printer Driver Automatic
Installation
Managing printer drivers is important for a successful printing experience. When XenApp
autocreates printers, it determines if their corresponding drivers are missing. By default,
XenApp installs any missing printer drivers from the Windows native printer driver set. If a
problematic printer driver is installed automatically, it can cause issues.
You can either prevent printer drivers from being installed automatically, or, if you want to
have them installed automatically, you can control what drivers are installed on farm
servers by specifying the drivers on a compatibility list:
●
If you know what printer drivers cause problems, you can specify banned printer drivers
in the compatibility list
●
If you do not know what drivers cause problems or you want tighter control over the
drivers on the farm, specify to install only drivers on the compatibility list
When users log on:
●
XenApp checks the client printer driver compatibility list before it sets up the client
printers
●
If a printer driver is on the list of drivers that are not allowed, XenApp does not set up
the printer unless the Universal Printing feature is enabled
●
When the compatibility list prevents setup of a client printer, XenApp writes a message
in the server’s Event log
To prevent drivers from being installed automatically, configure the Printing > Drivers >
Native printer driver auto-install policy rule. See the section "To add or remove drivers or
edit driver names in the compatibility list" in this topic to ban specific printer drivers.
479
Controlling Printer Driver Automatic Installation
To specify how client printer drivers are installed on
farm servers
1. Depending on the version of XenApp you have installed:
●
From the Start menu, open All Programs > Citrix > Administration Tools and
choose XenApp Advanced Configuration.
From the ICA toolbar, open the Presentation Server Console.
2. Select the Policies node.
●
3. On the Contents tab, choose the policy for which you want to configure printing rules.
4. From the Actions menu, choose Properties.
5. In the policy’s Properties dialog box, expand Printing, then Drivers.
6. Under Drivers, you can configure the following rules:
●
Use the Native printer driver auto-install rule to control whether Windows native
drivers are automatically installed when auto-creating either a client or network
printer. Enabling this rule lets you prevent the automatic installation of printer
drivers. See To control the automatic installation of printer drivers.
●
Use the Universal driver rule to specify whether auto-created client printers use
universal printer drivers, model-specific printer drivers, or both. The universal
drivers can enable printing even when model-specific drivers are not available. See
To specify the Universal Printer driver for sessions.
To add or remove drivers or edit driver names in the
compatibility list
1. Depending on the version of XenApp you have installed:
●
From the Start menu, open All Programs > Citrix > Administration Tools and
choose XenApp Advanced Configuration.
●
From the ICA toolbar, open the Presentation Server Console.
2. Select Printer Management > Drivers.
3. On the Actions menu, select Printer Management > Compatibility.
4. Choose the required platform from the drop-down list.
5. Select one of the following Compatibility list options:
●
Allow only drivers in the list. Keeps a list of incompatible drivers that are not
allowed to be used by client printers and allow all others.
Allow all drivers except those in the list. Keeps a list of compatible drivers that
client printers are allowed to use and bans all others.
6. Update the list.
●
480
Controlling Printer Driver Automatic Installation
To control the automatic installation of printer drivers
1. Choose the Native printer driver auto-install policy rule.
2. On the Native printer driver auto-install properties page, select Enabled.
3. Select one of the following:
●
Install Windows native drivers as needed (selected by default). Allows XenApp to
install Windows native printer drivers (those present in driver.cab) automatically
when auto-creating either a client or network printer.
Caution: Enabling this option may result in the installation of a large number of
native drivers.
●
Do not automatically install drivers. Requires administrators to install individual
native printer drivers manually.
To specify the Universal Printer driver for sessions
1. Choose the Printing > Drivers> Universal driver policy rule.
2. On the Universal driver properties page, select Enabled.
3. Select one of the following:
481
●
Use universal driver only. Specifies that the client printer uses the Universal
printer driver only. Select this option if you do not want to use native drivers.
●
Use universal driver only if requested driver is unavailable. Uses native drivers
for client printers if they are available. If the driver is not available on the server,
the client printer is created automatically with the appropriate Universal driver.
●
Use only printer model specific drivers. Specifies that the client printer uses only
the native drivers that are autocreated at logon. If the native driver of the printer
is unavailable, the client printer cannot be autocreated.
Configuring Universal Printer Drivers on
Farm Servers
If you configure a Universal printer driver for sessions, by default, XenApp always uses the
Citrix Universal (EMF) Printer driver, when it is available. If it is not available, XenApp uses
the XPS Universal Printer driver. The XPS Universal printer driver can be configured as the
default by configuring the Citrix policy setting Universal driver preference.
The Citrix Universal printer drivers are listed in the Print Management MMC snap-in.
Provided all prerequisites for the driver were installed when you ran XenApp Setup, the
following drivers appear:
●
Citrix Universal Printer, which is the .EMF driver
●
Citrix XPS Universal Printer
●
HP Color LaserJet 2800 PS (Citrix PS Universal Printer Driver)
If you need a Universal driver that does not appear in this list, you must install it.
To specify the Universal Printer driver for sessions
Configure the Citrix policy setting Universal print driver usage by choosing one of the
following:
●
Use universal printing only if requested driver is unavailable uses standard
model-specific drivers for printer creation if they are available. If the driver is not
available on the server, the client printer is created automatically with the appropriate
universal driver.
●
Use only printer model specific drivers specifies that the client printer use only the
standard model-specific drivers that are auto-created at logon. If the requested driver
is unavailable, the client printer cannot be auto-created.
Use universal printing only specifies that no standard model-specific drivers are
used. Only universal print drivers are used to create printers.
Use printer model specific drivers only if universal printing is unavailable uses the
universal printer driver if it is available. If the driver is not available on the server, the
client printer is created automatically with the appropriate model-specific printer
driver.
●
●
To change the default Citrix Universal Printer driver
482
Configuring Universal Printer Drivers on Farm Servers
To force XenApp to use the Citrix XPS Universal Printer driver before the EMF-based Citrix
Universal Printer driver, configure the Citrix policy setting Universal driver preference and
move XPS to the top of the list.
483
Mapping Client Printer Drivers
If the servers in your farm have the same drivers as the client printers but the drivers
themselves are named differently (for example, “HP LaserJet 4L” versus “HP LaserJet 4”),
XenApp may not recognize the drivers are the same and users will have difficulty printing or
printer autocreation may fail.
You can resolve this issue by overriding, or mapping, the printer driver name the client
provides and substituting an equivalent driver on the server. Mapping client printer drivers
gives server applications access to client printers that have the same drivers as the server
but different driver names.
You can use the printer driver remapping feature to substitute:
●
Good printer drivers for 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 Printer driver mapping and compatibility by adding the
client printer driver name and selecting the server driver that you want to substitute for
the client printer driver from the Find printer driver menu. You can use wildcards in this
setting. For example, to force all HP printers to use a specific driver, specify HP* in the
policy setting.
To edit printing settings for mapped client printer
drivers
After you have added a client printer driver to the list of mapped drivers, you can modify
the printing settings for the driver. This setting overrides retained printer settings the user
set during a previous session.
You can set print quality, orientation, color, duplex, scale, copy count, TrueType option,
and paper size. If you specify a printing option that the printer driver does not support,
that option has no effect.
484
Mapping Client Printer Drivers
1. On the Printer driver mapping and compatibility settings page, select the printer
driver for which you want to modify the settings.
2. Click Settings.
3. Specify the printer settings.
485
Improving Session Performance by
Limiting Printing Bandwidth
While printing files from published applications to client printers, other virtual channels
(such as video) may experience decreased performance due to competition for bandwidth
especially if users are accessing servers through slower networks or dial-up connections. To
prevent such degradation, you can limit the bandwidth used by client printing.
Important: The printer bandwidth limit is always enforced, even when no other channels
are in use.
By limiting the data transmission rate for printing, you make more bandwidth available in
the ICA data stream for transmission of video, keystrokes, and mouse data. More available
bandwidth can help prevent degradation of the user experience during printing.
There are two ways you can limit printing bandwidth in client sessions using printer settings
in the Bandwidth category:
●
Use the Citrix policy Bandwidth printer settings in the Delivery Services Console to
enable and disable the printing bandwidth session limit for the farm.
●
Use individual server settings to limit printing bandwidth in the server farm. You can
perform this task using gpedit.msc locally on each server to configure the Citrix policy
Bandwidth printer settings.
You can use the Citrix Session Monitoring and Control Console (included in the WFAPI SDK)
to obtain real-time information about printing bandwidth. The print spooling virtual
channel control (that is, the CTXCPM Client printer mapping virtual channel control) lets
you set a priority and bandwidth limit for bandwidth control of this virtual channel.
To configure a printing bandwidth setting in an
existing policy
Configure one of the options in the Citrix policy Bandwidth setting. If you enter values for
both settings, the most restrictive setting (with the lower value) is applied.
486
●
Printer redirection bandwidth limit to specify the bandwidth available for printing in
kilobits per second (kbps).
●
Printer redirection bandwidth limit percent to limit the bandwidth available for
printing to a percentage of the overall bandwidth available.
Improving Session Performance by Limiting Printing Bandwidth
Note: If you want to specify bandwidth as a percentage using the Printer redirection
bandwidth limit percent setting, you must enable the Overall session bandwidth
limit as well.
To limit printer bandwidth for a server
Using the Window Group Policy Editor locally on a server, configure one of the options in
the Citrix policy Bandwidth setting. If you enter values for both settings, the most
restrictive setting (with the lower value) is applied.
●
Printer redirection bandwidth limit to specify the bandwidth available for printing in
kilobits per second (kbps).
●
Printer redirection bandwidth limit percent to limit the bandwidth available for
printing to a percentage of the overall bandwidth available.
Note: If you want to specify bandwidth as a percentage using the Printer redirection
bandwidth limit percent setting, you must enable the Overall session bandwidth
limit as well.
487
Displaying Printers
The following table summarizes where you can manage and modify print queues and display
printers in a XenApp environment. For definitions of the terms client printing pathway and
network printing pathway, see Overview of Client and Network Printing Pathways. Client
printing pathway is not synonymous with printers attached to client devices.
Client printers (Printers
attached to the client
device)
Network printers (Printers
on a network print server)
Network printers (Printers
on a network print server)
488
Printing
Pathway
UAC
Enabled?
Location
Client printing
pathway
On
Print Management snap-in
in the Microsoft
Management Console
Off
Control Panel
On
Print Management snap-in
in the Microsoft
Management Console
Off
Control Panel
On
Print Server > Print
Management snap-in in the
Microsoft Management
Console
Off
Print Server > Control
Panel
On
Control Panel
Off
Control Panel
On
Control Panel
Off
Control Panel
Client printing
pathway
Network
printing
pathway
Server local printers
(Shared printers locally
attached to a XenApp
server)
N/A
Local network server
printers (Printers from a
network print server that
are added to server running
XenApp)
Network
printing
pathway
Managing Printers Using the Network
Printing Pathway
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 Control Panel on the print
server with the correct level of Windows administrator privileges. Print queues for network
printers that use the network printing pathway are private and cannot be managed through
XenApp.
Whenever you configure a network printing pathway and the server hosting the application
does not have or cannot install the driver, by default, XenApp sends the print job along the
client printing pathway. You can tell a job sent to the network printer is redirected along
the client printing pathway when you see printers appearing in the Windows Server
Manager Snap-in > Print and Document Services role that has the following syntax:
PrinterName on PrintServer (from clientname) in session n
where:
PrinterName is the name of the printer being redirected
PrintServer is the name of the print server with which the printer is associated
clientname is the name of the client through which the print job is being rerouted
n is the session ID for that ICA connection
For example, Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2.
489
Displaying Printers Using the Client
Printing Pathway
If UAC is not enabled, you can, however, display and manage redirected client print queues
and server local printers through Control Panel > Printers of individual servers. The client
printers displayed on a server fluctuate based on what sessions are active on a server
because XenApp creates these printers based on the printers on the connecting client
devices. You can display client printers in Control Panel > Printers.
To display printers that use the client printing
pathway when UAC is enabled
1. On the XenApp server that is hosting the session for which you want to display the
printers, install the Print Services server role.
2. In Administrative Tools, open the Print Management stand-alone snap-in.
3. To display client redirected printers, in the Print Management tree, select Print
Management > Custom Filters > All Printers. The Print Management snap-in displays
the client printers redirected from all clients connected to that server. You can display
and manage the print queues for these printers and select Printers With Jobs in the
Print Management Tree to display active jobs on redirected printers.
To display printers that use the client printing
pathway without UAC enabled
1. On the XenApp server, open Control Panel > Printers.
The Printers screen displays the local printers mapped to the ICA session. By default, the
name of the printer takes the form printername (from clientname) in session x; for
example, “printer01 (from machine01) in session 7.” Printername is the name of the printer
on the client device, clientname is the unique name given to the client device or the Web
Interface, and x is the SessionID of the user’s session on the server.
490
XenApp Server Utilities Reference
Citrix XenApp server utilities provide an alternative method to using the console for
maintaining and configuring servers and farms. Citrix XenApp server utilities must be run
from a command prompt on a server running Citrix XenApp.
491
Command
Description
altaddr
Specify server alternate IP address.
app
Run application execution shell.
auditlog
Generate server logon/logoff reports.
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.
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.
ALTADDR
Use altaddr to query and set the alternate (external) IP address for a server running Citrix
XenApp. The alternate address is returned to clients that request it and is used to access a
server that is behind a firewall.
Syntax
altaddr [/server:servername] [/set alternateaddress] [/v]
altaddr [/server:servername] [/set adapteraddress alternateaddress] [/v]
altaddr [/server:servername] [/delete] [/v]
altaddr [/server:servername] [/delete adapteraddress] [/v]
altaddr [/?]
Parameters
servername
The name of a server.
alternateaddress
The alternate IP address for a server.
adapteraddress
The local IP address to which an alternate address is assigned.
Options
/server:servername
Specifies the server on which to set an alternate address. Defaults to the current server.
/set
Sets alternate TCP/IP addresses. If an adapteraddress is specified, alternateaddress is
assigned only to the network adapter with that IP address.
492
ALTADDR
/delete
Deletes the default alternate address on the specified server. If an adapter address is
specified, the alternate address for that adapter is deleted.
/v (verbose)
Displays information about the actions being performed.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
The server subsystem reads the altaddr settings for server external IP addresses at startup
only. If you use altaddr to change the IP address setting, you must restart the Citrix
Independent Management Architecture service for the new setting to take effect.
If altaddr is run without any parameters, it displays the information for alternate addresses
configured on the current server.
Examples
Set the 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.
493
APP
App is a script interpreter for secure application execution. Use App to read execution
scripts that copy standardized .ini type files to user directories before starting an
application, or to perform application-related cleanup after an application terminates. The
script commands are described below.
Syntax
app scriptfilename
Parameters
scriptfilename
The name of a script file containing app commands (see script commands below).
Script Commands
copy sourcedirectory\filespec targetdirectory
Copies files from sourcedirectory to targetdirectory. Filespec specifies the files to copy
and can include wild cards (*,?).
deletedirectory\filespec
Deletes files owned by a user in the directory specified. Filespec specifies the files to
delete and can include wild cards (*,?). See the Examples section for more information.
deleteall directory\filespec
Deletes all files in the directory specified.
execute
Executes the program specified by the path command using the working directory
specified by the workdir command.
path executablepath
Executablepath is the full path of the executable to be run.
494
APP
workdir directory
Sets the default working directory to the path specified by directory
Script Parameters
directory
A directory or directory path.
executablepath
The full path of the executable to be run.
filespec
Specifies the files to copy and can include wildcards (*,?).
sourcedirectory
The directory and path from which files are to be copied.
targetdirectory
The directory and path to which files are to be copied.
Remarks
If no scriptfilename is specified, app displays an error message.
The Application Execution Shell reads commands from the script file and processes them in
sequential order. The script file must reside in the %SystemRoot%\Scripts directory.
Examples
The following script runs the program Notepad.exe. When the program terminates, the
script deletes files in the Myapps\Data directory created for the user who launched the
application:
PATH C:\Myapps\notepad.exeWORKDIR C:\Myapps\DataEXECUTEDELETE C:\Myapps\Data\*.*
The following script copies all the .wri files from the directory C:\Write\Files, executes
Write.exe in directory C:\Temp.wri, and then removes all files from that directory when
the program terminates:
495
APP
PATH C:\Wtsrv\System32\Write.exeWORKDIR C:\Temp.wriCOPY C:\Write\Files\*.wri
C:\Temp.wriEXECUTEDELETEALL C:\Temp.wri\*.*
The following example demonstrates using the script file to implement a front-end
registration utility before executing the application Coolapp.exe. You can use this method
to run several applications in succession:
PATH C:\Regutil\Reg.exeWORKDIR C:\RegutilEXECUTEPATH C:\Coolstuff\Coolapp.exeWORKDIR
C:\TempEXECUTEDELETEALL C:\Temp
Security Restrictions
None.
496
AUDITLOG
Auditlog generates reports of logon/logoff activity for a server based on the Windows Server
security event log. To use auditlog, you must first enable logon/logoff accounting. You can
direct the auditlog output to a file.
Syntax
auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy]
[[/write:filename] | [/detail | /time] [/all]]
auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy]
[[/write:filename] | [/detail] | [/fail ] | [ /all]]
auditlog [/clear:filename]
auditlog [/?]
Parameters
filename
The name of the eventlog output file.
session
Specifies the session ID for which to produce a logon/logoff report. Use this parameter to
examine the logon/logoff record for a particular session.
mm/dd/yy
The month, day, and year (in two-digit format) to limit logging.
username
Specifies a user name for which to produce a logon/logoff report. Use this parameter to
examine the logon/logoff record for a particular user.
Options
/eventlog:filename
497
AUDITLOG
Specifies the name of a backup event log to use as input to auditlog. You can back up the
current log from the Event Log Viewer by using auditlog /clear: filename.
/before:mm/dd/yy
Reports on logon/logoff activity only before mm/dd/yy.
/after:mm/dd/yy
Reports on logon/logoff activity only after mm/dd/yy.
/write:filename
Specifies the name of an output file. Creates a comma-delimited file that can be
imported into an application, such as a spreadsheet, to produce custom reports or
statistics. It generates a report of logon/logoff activity for each user, displaying
logon/logoff times and total time logged on. If filename exists, the data is appended to
the file.
/time
Generates a report of logon/logoff activity for each user, displaying logon/logoff times
and total time logged on. Useful for gathering usage statistics by user.
/fail
Generates a report of all failed logon attempts.
/all
Generates a report of all logon/logoff activity.
/detail
Generates a detailed report of logon/logoff activity.
/clear:filename
Saves the current event log in filename and clears the Event log. This command does not
work if filename already exists.
/?
Displays the syntax for the utility and information about the 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
498
AUDITLOG
logon/logoff accounting with the Audit Policy in Microsoft Windows.
Security Restrictions
To run auditlog, you must have Windows administrator privileges.
499
CTXKEYTOOL
Use ctxkeytool to enable and disable the IMA encryption feature and generate, load,
replace, enable, disable, or back up farm key files.
Syntax
ctxkeytool [generate | load | newkey | backup] filepath
ctxkeytool [enable | disable | query]
Options
generate
Generates a new key and saves it to the filepath. This command alone is not sufficient to
enable IMA encryption.
load
Can be used to load:
●
A new key onto a server with no preexisting key
●
The correct key onto a server that has an existing key
A new key onto a computer and the farm
newkey
●
Creates a new encryption key in the data store using the local farm key.
backup
Backs up the existing farm key to a file.
enable
Enables the IMA encryption feature for the farm.
disable
Disables the IMA encryption feature for the farm.
query
500
CTXKEYTOOL
Can be used to check:
●
For a key on the local computer
●
To see if IMA encryption is enabled for the farm
●
If your key matches the farm key
Remarks
The first time you generate a key for the first server on the farm on which you are enabling
IMA encryption, use the following sequence of options: generate, load, and newkey. On
each subsequent server in the farm, you just need to load the key. After you activate the
IMA encryption feature on one server, the feature is enabled for the entire farm.
If you lose the key file for a server, you can get a duplicate key file by running the backup
option on another server in the same farm that still has its key. This command recreates
the key file. After recreating the key file, use load to load it to the server on which it was
lost.
After using the disable option to disable the IMA encryption feature, you must reenter the
configuration logging database password. If you want to activate the IMA encryption feature
again, run enable on any server in the farm.
Security Restrictions
You must be a Citrix administrator with local administrator privileges to run ctxkeytool.
501
CTXXMLSS
Use ctxxmlss to change the Citrix XML Service port number.
Syntax
ctxxmlss [/rnnn] [/u] [/knnn] [/b:a] [/b:l] [/?]
Options
/rnnn
Changes the port number for the Citrix XML Service to nnn.
/u
Unloads Citrix XML Service from memory.
/knnn
Keeps the connection alive for nnn seconds. The default is nine seconds.
/b:a
Binds the service to all network interfaces. This is the default setting.
/b:l
Binds the service to localhost only.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
502
CTXXMLSS
Remarks
For more information, see System Requirements.
503
DSCHECK
Use dscheck to validate the consistency of the database used to host the server farm’s data
store. You can then repair any inconsistencies found. dscheck is often used after running
dsmaint.
Syntax
dscheck [/clean] [/?]
Options
/clean
Attempts to fix any consistency error that is found.
/?
Displays the syntax for the utility and information about the 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 dscheck on a server in the farm
that has a direct connection to the data store.
When you run dscheck with the /clean option, the utility runs tests and removes
inconsistent data (typically servers and applications) from the data store. Because removing
this data can affect the farm’s operation, be sure to back up the data store before using
the /clean option.
When you run the utility with the /clean option, you may need to run the dsmaint command
with the recreatelhc parameter on each server in the farm to update the local host caches.
Running this command sets the PSRequired registry value to 1 in
HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\RUNTIME, or
HKLM\SOFTWARE\Citrix\IMA\RUNTIME on XenApp, 32-bit Edition.
Dscheck reports the results of the tests in several ways. First, it sends any errors found as
well as a summary to the Event log and to the command window. You can also write the
output produced by dscheck to a file.
504
DSCHECK
Second, several performance monitor values are updated under the performance object for
Citrix XenApp. These values include a count of server errors, a count of application errors,
a count of group errors, and an overall flag indicating that errors were detected.
Third, dscheck returns an error code of zero for a successful scan (no errors are found) and
an error code of one if any problems are encountered.
Dscheck looks primarily at three data store objects: servers, applications, and groups. For
each of these object types, dscheck performs a series of tests on each object instance.
For example, for each server object in the data store, dscheck verifies that there is a
corresponding common server object and then further verifies that both objects have
matching host IDs and host names.
Examples
To run consistency checks only:
dscheck
To check consistency and fix errors:
dscheck /clean
505
DSMAINT
Run dsmaint on farm servers to perform XenApp data store maintenance tasks, including
backing up the data store, migrating the data store to a new server, and compacting the
XenApp data store or the Streaming Offline database. Not all dsmaint commands apply to
all database types.
When using this command, user names and passwords may be case-sensitive, depending on
the database and the operating system you are using.
Syntax
dsmaint config [/rade] [/user:username] [/pwd:password] [/dsn:filename]
dsmaint backup destination_path
dsmaint compactdb [/lhc]
dsmaint migrate [{/srcdsn:dsn1 /srcuser:user1 /srcpwd:pwd1}] [{/dstdsn:dsn2 /dstuser:user2
/dstpwd:pwd2}]
dsmaint publishsqlds {/user:username /pwd:password}
dsmaint recover
dsmaint recreatelhc
dsmaint recreaterade
dsmaint verifylhc [/autorepair]
dsmaint [/?]
Parameters
destination_path
Path for the backup data store. Do not use the same path as the original database.
dsn1
The name of the DSN file for the source data store.
dsn2
506
DSMAINT
The name of the DSN file for the destination data store.
filename
The name of the data store.
password
The password to connect to the data store.
pwd1
The source data store password.
pwd2
The destination data store password.
user1
The source data store user logon.
user2
The destination data store user logon.
username
The name of the user to use when connecting to the data store.
Options
config
Changes configuration parameters used to connect to the data store. Enter the full path
to the DSN file in quotation marks. For example,
dsmaint config /user:ABCnetwork\administrator /pwd:Passw0rd101
/dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"
Stop the Citrix Independent Management Architecture service before using config with
the /pwd option.
Caution: Specify a /dsn for dsmaint config or you will change the security context for
access to the SQL Server or Oracle database.
/rade
Compacts the offline data store.
/user:username
The user name to connect to a data store.
507
DSMAINT
/pwd:password
The password to connect to a data store.
/dsn:filename
The filename of an IMA data store.
backup
Creates a backup copy of the SQL Server Express database that is the 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 dsmaint backup, specifying the same path as the existing
data store can damage it irreparably.
compactdb
Compacts the local database file. During database compaction, the database is
temporarily unavailable for both reading and writing. The compacting time can vary from
a few seconds to a few minutes, depending on the size of the database and the usage.
/lhc
Compacts the local host cache on the server where this parameter is run. Run dsmaint
/lhc after your farm has been running for a long period of time as a maintenance task.
migrate
Migrates data from one data store database to another. Run this command on any
XenApp server that has a connection to the data store. Use this command to move a data
store to another server, rename a data store in the event of a server name change, or
migrate the data store to a different type of database (for example, migrate from SQL
Server Express to SQL Server).
To migrate the data store to a new server:
1. Prepare the new database server using the steps you did before running XenApp
Setup for the first time.
2. Create a DSN file for this new database server on the server where you will be
running dsmaint migrate.
3. Run dsmaint migrate on any server with a connection to the data store.
4. Run dsmaint config on each server in the farm to point it to the new database.
/srcdsn:dsn1
The name of the data store from which to migrate data.
/srcuser:user1
The user name to use to connect to the data store from which the data is migrating.
508
DSMAINT
/srcpwd:pwd1
The password to use to connect to the data store from which the data is migrating.
/dstdsn:dsn2
The name of the data store to which to migrate the data.
/dstuser:user2
The user name that allows you to connect to the data store to which you are migrating
the source data store.
/dstpwd:pwd2
The password that allows you to connect to the data store to which you are migrating the
source data store.
publishsqlds
Publishes a SQL Server data store for replication. Run publishsqlds only from the server
that created the farm. The publication is named MFXPDS.
recover
Restores a SQL Server Express data store to its last known good state. Run this directly on
the server while the Citrix Independent Management Architecture service is not running.
recreatelhc
Recreates the local host cache database. Run if prompted after running dsmaint
verifylhc. After running dsmaint recreatelhc, restart the IMA Service. When the IMA
Service starts, the local host cache is populated with fresh data from the data store.
recreaterade
Recreates the application streaming offline database. Run as a troubleshooting step if
the Citrix Independent Management Architecture service stops running and the local host
cache is not corrupted.
verifylhc
Verifies the integrity of the local host cache. If the local host cache is corrupt, you are
prompted with the option to recreate it. With the verifylhc /autorepair option,
the local host cache is automatically recreated if it is found to be corrupted.
Alternatively, you can use dsmaint recreatelhc to recreate the local host cache.
/?
Displays the syntax and options for the utility.
509
DSMAINT
Remarks
After using dsmaint, Citrix recommends running dscheck to check the integrity of the data
on the XenApp data store.
Security Restrictions
The dsmaint config and dsmaint migrate commands can be run only by a user with the
correct user name and password for the database.
510
ICAPORT
Use icaport to query or change the TCP/IP port number used by the ICA protocol on the
server.
Syntax
icaport {/query | /port:nnn | /reset} [/?]
Options
/query
Queries the current setting.
/port:nnn
Changes the TCP/IP port number to nnn.
/reset
Resets the TCP/IP port number to 1494, which is the default.
/?
Displays the syntax for the utility and information about the 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 Receiver or plug-in
that will connect to that server. For instructions for changing the port number on receivers
or plug-ins, see the Receiver or plug-in documentation.
Examples
To set the TCP/IP port number to 5000
511
ICAPORT
icaport /port:5000
To reset the port number to 1494
icaport /reset
Security Restrictions
Only Citrix administrators with Windows administrator privileges can run icaport.
512
IMAPORT
Use imaport to query or change the IMA port.
Syntax
imaport {/query | /set {IMA:nnn | ds:nnn}* | /reset {IMA | DS | ALL} } [/?]
Options
/query
Queries the current setting.
/set
Sets the designated TCP/IP port to a specified port number.
ima:nnn
Sets the IMA communication port to a specified port number.
ds:nnn
Sets the data store server port to a specified port number.
/reset
Resets the specified TCP/IP port to the default.
ima
Resets the IMA communication port to 2512.
ds
Resets the data store server port to 2512.
all
Resets all of the applicable ports to the defaults.
/?
Displays the syntax for the utility and information about the utility’s options.
513
IMAPORT
514
QUERY FARM
Use query to display information about server farms within the network.
Syntax
query farm [server [/addr | /app | /app appname | /load | /ltload]]
query farm [ /tcp ] [ /continue ]
query farm [ /app | /app appname | /disc | /load | /ltload | /lboff | /process]
query farm [/online | /online zonename]
query farm [/offline | /offline zonename]
query farm [/zone | /zone zonename]
query farm [/?]
Parameters
appname
The name of a published application.
server
The name of a server within the farm.
zonename
The name of a zone within the farm.
Options
farm
Displays information about servers within an IMA-based server farm. You can use qfarm
as a shortened form of query farm.
server /addr
515
QUERY FARM
Displays address data for the specified server.
/app
Displays application names and server load information for all servers within the farm or
for a specific server.
/app appname
Displays information for the specified application and server load information for all
servers within the farm or for a specific server.
/continue
Do not pause after each page of output.
/disc
Displays disconnected session data for the farm.
/load
Displays server load information for all servers within the farm or for a specific server.
/ltload
Displays server load throttling information for all servers within the farm or for a specific
server.
/lboff
Displays the names of the servers removed from load balancing by Health Monitoring &
Recovery.
/process
Displays active processes for the farm.
/tcp
Displays TCP/IP data for the farm.
/online
Displays servers online within the farm and all zones. The data collectors are represented
by the notation “D.”
/online zonename
Displays servers online within a specified zone. The data collectors are represented by
the notation “D.”
/offline
Displays servers offline within the farm and all zones. The data collectors are
represented by the notation “D.”
516
QUERY FARM
/offline zonename
Displays servers offline within a specified zone. The data collectors are represented by
the notation “D.”
/zone
Displays all data collectors in all zones.
/zone zonename
Displays the data collector within a specified zone.
/?
Displays the syntax for the utility and information about the 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 .
517
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.
518
QUERY PROCESS
process *
Displays all visible processes on the current server.
process processid
Displays processes for the specified processid.
process username
Displays processes belonging to the specified user.
process sessionname
Displays processes running under the specified session name.
process /id:nn
Displays information about processes running on the current server by the specified ID
number.
process programname
Displays process information associated with the specified program name.
process /server:servername
Displays information about processes running on the specified server. If no server is
specified, the information returned is for the current server.
process /system
Displays information about system processes running on the current server.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
519
QUERY SESSION
Use query to display information about sessions within the network.
Syntax
query session [sessionname | username | sessionid]
query session [/server:servername] [/mode] [/flow] [/connect] [/counter]
query session [/?]
Parameters
servername
The name of a server within the farm.
sessionname
The name of a session, such as “ica-tcp#7”.
sessionid
The two-digit ID number of a session.
username
The name of a user connected to the farm.
Options
session sessionname
Identifies the specified session.
session username
Identifies the session associated with the user name.
session sessionid
520
QUERY SESSION
Identifies the session associated with the session ID number.
session /server: servername
Identifies the sessions on the specified server.
session /mode
Displays the current line settings.
session /flow
Displays the current flow control settings.
session /connect
Displays the current connection settings.
session /counter
Displays the current Remote Desktop Services counter information.
/?
Displays the syntax for the utility and information about the utility’s options.
Security Restrictions
None.
521
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.
522
QUERY TERMSERVER
Remarks
If no parameters are specified, query termserver lists all Terminal Servers within the
current domain.
Security Restrictions
None.
523
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.
524
QUERY USER
user /server: servername
Defines the server to be queried. The current server is queried by default.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
If no parameters are specified, query user displays all user sessions on the current server.
You can use quser as a shortened form of the query user command.
Security Restrictions
None.
525
Performance Counters Reference
Performance monitoring counters that directly relate to the performance of sessions,
networking, and security are installed with XenApp. You can access these counters from the
Performance Monitor, which is part of Windows operating systems. Use performance
monitoring to obtain system performance data and the effects of configuration changes on
system throughput.
Using the standard Windows procedure, you can add and then view the following categories
of XenApp-related counters, called performance objects in Performance Monitor:
526
●
Citrix CPU Utilization Mgmt User
●
Citrix IMA Networking
●
Citrix Licensing
●
Citrix MetaFrame Presentation Server
●
ICA Session
●
Secure Ticket Authority
Citrix CPU Utilization Mgmt User
Counters
The following counters are available through the Citrix CPU Utilization Mgmt User
performance object in Performance Monitor.
527
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.
Citrix IMA Networking Counters
The following counters are available through the Citrix IMA Networking performance object
in Performance Monitor.
528
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.
Citrix Licensing Counters
The following counters are available through the Citrix Licensing performance object in
Performance Monitor.
529
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.
Citrix MetaFrame Presentation Server
Counters
The following counters are available through the Citrix MetaFrame Presentation Server
performance object in Performance Monitor.
530
Counter
Description
Application Enumeration/sec
The number of application enumerations per second.
Application Resolution Time
(ms)
The time in milliseconds that a resolution took to
complete.
Application Resolutions
Failed/sec
The number of application resolutions failed per second.
Application Resolutions/sec
The number of resolutions completed per second.
DataStore Connection Failure
The number of minutes that the XenApp server has been
disconnected from the data store.
DataStore bytes read
The number of bytes read from the data store.
DataStore bytes read/sec
The number of bytes of data store data read per second.
DataStore bytes written/sec
The number of bytes of data store data written per
second.
DataStore reads
The number of times data was read from the data store.
DataStore reads/sec
The number of times data was read from the data store
per second.
DataStore writes/sec
The number of times data was written to the data store
per second.
DynamicStore bytes read/sec
The number of bytes of dynamic store data read per
second.
DynamicStore bytes
written/sec
The number of bytes of dynamic store data written per
second.
DynamicStore Gateway
Update Count
The number of dynamic store update packets sent to
remote data collectors.
DynamicStore Gateway
Update, Bytes Sent
The number of bytes of data sent across gateways to
remote data collectors.
DynamicStore Query Count
The number of dynamic store queries 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.
Citrix MetaFrame Presentation Server Counters
531
DynamicStore Update Bytes
Received
The number of bytes of data received in dynamic store
update packets.
DynamicStore Update
Packets Received
The number of update packets received by the dynamic
store.
DynamicStore Update
Response Bytes Sent
The number of bytes of data sent in response to dynamic
store update packets.
DynamicStore writes/sec
The number of times data was written to the dynamic
store per second.
Filtered Application
Enumerations/sec
The number of filtered application enumerations per
second.
LocalHostCache bytes
read/sec
The number of bytes of IMA local host cache data read
per second.
LocalHostCache bytes
written/sec
The number of bytes of IMA local host cache data written
per second.
LocalHostCache reads/sec
The number of times data was read from the IMA local
host cache per second.
LocalHostCache writes/sec
The number of times data was written to the IMA local
host cache per second.
Maximum number of XML
threads
The maximum number of threads allocated to service
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 that occurred. This value
starts at zero each time the IMA Service starts and is
incremented each time a zone election takes place.
Zone Elections Won
The number of times the server won a zone election.
ICA Session Counters
The following counters are available through the ICA Session performance object in
Performance Monitor.
532
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.
ICA Session Counters
533
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.
ICA Session Counters
534
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.
Secure Ticket Authority Counters
The following performance counters are available for the Secure Ticket Authority (STA).
535
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.
Policy Settings Reference
Policies contain settings that are applied when the policy is enforced. You configure these
settings using the AppCenter or the Group Policy Management Editor, depending on whether
or not you use Active Directory in your XenApp environment.
The descriptions for each policy setting include the following information:
●
The name of the policy setting
●
The Citrix products to which the policy setting applies
●
The additional settings, if applicable, required to enable a particular feature
●
Other settings that are similar to the policy setting in question, if applicable
Important: If you use Windows PowerShell scripts to manage Citrix policies, be aware
that the names and locations of some policy settings have changed in this version of
XenApp. Although you can continue to use your existing scripts, you should verify the
scripts reference the correct setting names and paths for this version of XenApp and
update these references as appropriate. For more information about using PowerShell
scripts to manage Citrix policies, refer to the XenApp PowerShell SDK available from the
Citrix Developer Network Web site (http://community.citrix.com).
536
Policy Settings: Quick Reference Table
The following tables present settings you can configure within a policy. Find the task you
want to perform in the left column, then locate its corresponding setting in the right
column.
Audio
To perform this task:
Use this policy setting:
Control whether or not to allow the use of
multiple audio devices
Audio Plug N Play
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
Bandwidth for User Devices
To limit bandwidth used for:
Use this policy setting:
Client audio mapping
●
Audio redirection bandwidth limit, or
●
Audio redirection bandwidth limit
percent
●
Clipboard redirection bandwidth
limit, or
●
Clipboard redirection bandwidth
limit percent
●
COM port redirection bandwidth
limit, or
●
COM port redirection bandwidth limit
percent
Cut-and-paste using local clipboard
Devices connected to a local COM port
537
Policy Settings: Quick Reference Table
Access in a session to local client drives
●
File redirection bandwidth limit, or
●
File redirection bandwidth limit
percent
●
HDX MediaStream Multimedia
Acceleration bandwidth limit, or
●
HDX MediaStream Multimedia
Acceleration bandwidth limit percent
●
LPT port redirection bandwidth limit,
or
●
LPT port redirection bandwidth limit
percent
HDX MediaStream Multimedia Acceleration
Printers connected to the client LPT port
Client session
Overall session bandwidth limit
Printing
●
Printer redirection bandwidth limit,
or
●
Printer redirection bandwidth limit
percent
●
TWAIN device redirection bandwidth
limit, or
●
TWAIN device redirection bandwidth
limit percent
●
Client USB device redirection
bandwidth limit, or
●
Client USB device redirection
bandwidth limit percent
TWAIN devices (such as a camera or scanner)
USB devices
Redirection of Client Drives and User Devices
538
To perform this 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 cut-and-paste data transfer between
the server and the local clipboard
Client clipboard redirection
Control how drives map from the user device
Client drive redirection
Policy Settings: Quick Reference Table
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
Control whether or not users' local floppy
drives are available in a session
Control whether or not users' network drives
are available in a session
Control whether or not users' local CD, DVD,
or Blu-ray drives are available in a session
Control whether or not users' local
removable drives are available in a session
Control whether or not users' TWAIN devices,
such as scanners and cameras, are available
in a session and control compression of
image data transfers
Control whether or not USB devices are
available in a session
●
Client fixed drives, and
●
Client drive redirection
●
Client floppy drives, and
●
Client drive redirection
●
Client network drives, and
●
Client drive redirection
●
Client optical drives, and
●
Client drive redirection
●
Client removable drives, and
●
Client drive redirection
●
Client TWAIN device redirection
●
TWAIN compression level
●
Client USB device redirection, and
●
Client USB device redirection rules
Control whether or not Plug-and-Play USB
devices, such as a camera or a point-of-sale
device, are available in a session
Client USB Plug and Play device
redirection
Improve the speed of writing and copying
files to a client disk over a WAN
Use asynchronous writes
Content Redirection
539
To perform this task:
Use this policy setting:
Control whether or not to use content
redirection from the server to the user
device
Host to client redirection
Policy Settings: Quick Reference Table
Graphics & Multimedia
To perform this 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
Control compression of images for use in
sessions of limited bandwidth
Control image display optimization based on
whether or not users reach a specified
bandwidth threshold
Control whether or not Flash content is
rendered in sessions
Control whether or not to allow the use of
legacy Flash acceleration for older versions
of Citrix Receiver (fomerly Citrix Online
plug-in)
Control whether or not Web sites can display
Flash content when accessed in sessions
540
●
Display mode degrade preference
●
Notify user when display mode is
degraded
●
Lossy compression level
●
Lossy compression level threshold
value
●
Progressive compression level
●
Progressive compression threshold
value
●
Extra Color Compression, and
●
Extra Color Compression Threshold
●
Flash acceleration (legacy features
with Citrix Online plug-in 12.1)
●
Flash default behavior (second
generation features with Citrix
Receiver)
Flash backwards compatibility
●
Flash server-side content fetching
URL list
●
Flash URL compatibility list
Enable color matching of Flash instances and
the Web pages on which they appear within
a session
Flash background color list
Control whether some Flash content is
rendered automatically on the server when
client-side rendering is either unnecessary or
resource-intensive
Flash intelligent fallback
Policy Settings: Quick Reference Table
Pre-launch and Lingering Sessions
To perform this task:
Control the length of time sessions remain
active after exiting applications
Control the length of time pre-launched
sessions are inactive before disconnecting or
terminating
Use this policy setting:
●
Linger Disconnect Timer Interval
●
Linger Terminate Timer Interval
●
Pre-launch Disconnect Timer Interval
●
Pre-launch Terminate Timer Interval
Prioritizing Multi-Stream Network Traffic
To perform this task:
Use this policy setting:
Specify ports for ICA traffic across multiple
connections and establish network priorities
Multi-Port Policy
Enable support for multi-stream connections
between servers and user devices
Multi-Stream (Computer and User
settings)
Printing
To perform this task:
Control creation of client printers on the
user device
541
Use this policy setting:
●
Auto-create client printers, and
●
Client printer redirection
Allow use of legacy printer names and
preserve backward compatibility with prior
versions 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 print driver usage
Policy Settings: Quick Reference Table
Choose a printer based on a roaming user’s
session information
Default printer
Security
To perform this task:
Use this policy rule:
Require that connections use a specified
encryption level
SecureICA minimum encryption level
User Connections and Shadowing
To perform this 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
542
●
Users who can shadow other users
●
Users who cannot shadow other users
ICA Policy Settings
The ICA section contains policy settings related to ICA listener connections, mapping to the
Clipboard and custom channels, connecting to server desktops, and controlling the launch
behavior of non-published programs.
ICA listener connection timeout
Applicable products: XenApp; XenDesktop
This setting specifies the maximum wait time for a connection using the ICA protocol to be
completed. By default, the maximum wait time is 120000 milliseconds, or two minutes.
ICA listener port number
Applicable products: XenApp; XenDesktop
This setting specifies the TCP/IP port number used by the ICA protocol on the server. The
default port number is 1494.
Valid port numbers must be in the range of 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 Receiver or plug-in that connects to the server.
Client clipboard redirection
Applicable products: XenApp; XenDesktop
This setting allows or prevents the Clipboard on the user device to be mapped to the
Clipboard on the server. By default, clipboard redirection is allowed.
To prevent cut-and-paste data transfer between a session and the local Clipboard, select
Prohibit. Users can still cut and paste data between applications running in sessions.
After allowing this setting, configure the maximum allowed bandwidth the Clipboard can
consume in a client connection using the Clipboard redirection bandwidth limit or the
Clipboard redirection bandwidth limit percent settings.
543
ICA Policy Settings
Desktop launches
Applicable products: XenApp
This setting allows or prevents non-administrative users to connect to a desktop session on
the server. By default, non-administrative users cannot connect to these sessions.
Launching of non-published programs during client
connection
Applicable products: XenApp
This setting specifies whether or not to launch initial applications or published applications
through ICA or RDP on the server. By default, only published applications are allowed to
launch.
544
Audio Policy Settings
The Audio section contains policy settings you can configure to permit user devices to send
and receive audio in sessions without reducing performance.
Audio Plug N Play
Applicable products: XenApp
This setting allows or prevents the use of multiple audio devices to record and play sound.
By default, this setting is allowed.
Audio Quality
Applicable products: XenApp; XenDesktop
This setting specifies the quality level of sound received in user sessions. By default, the
sound quality is set to High - high definition audio.
To control sound quality, choose one of the following options:
●
Select Low - for low speed connections for low-bandwidth connections. Sounds sent to
the client are compressed up to 16 Kbps. This compression results in a significant
decrease in the quality of the sound but allows reasonable performance for a
low-bandwidth connection.
●
Select Medium - optimized for speech for most LAN-based connections. Sounds sent to
the client are compressed up to 64 Kbps.
●
Select High - high definition audio for connections where bandwidth is plentiful and
sound quality is important. Clients can play sound at its native rate. Sounds can use up
to 1.3 Mbps of bandwidth to play clearly. Transmitting this amount of data can result in
increased CPU utilization and network congestion.
Bandwidth is consumed only while audio is recording or playing. If both occur at the same
time, the bandwidth consumption is doubled.
To specify the maximum amount of bandwidth, configure the Audio redirection bandwidth
limit or the Audio redirection bandwidth limit percent settings.
Client audio redirection
Applicable products: XenApp; XenDesktop
545
Audio Policy Settings
This setting allows or prevents applications hosted on the server to play sounds through a
sound device installed on the user device. This setting also allows or prevents users from
recording audio input. By default, redirection is allowed.
After allowing this setting, you can limit the bandwidth consumed by playing or recording
audio. Limiting the amount of bandwidth consumed by audio can improve application
performance but may also degrade audio quality. Bandwidth is consumed only while audio is
recording or playing. If both occur at the same time, the bandwidth consumption doubles.
To specify the maximum amount of bandwidth, configure the Audio redirection bandwidth
limit or the Audio redirection bandwidth limit percent settings.
Client microphone redirection
Applicable products: XenApp; XenDesktop
This setting enables or disables client microphone redirection. When enabled, users can use
microphones to record audio input in a session. By default, redirection is allowed.
For security, users are alerted when servers that are not trusted by their devices try to
access microphones. Users can choose to accept or not accept access. Users can disable the
alert on Citrix Receiver.
If the Client audio redirection setting is disabled on the user device, this rule has no
effect.
546
Auto Client Reconnect Policy Settings
The Auto Client Reconnect section contains policy settings for controlling automatic
reconnection of sessions.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Auto client reconnect
This setting allows or prevents automatic reconnection by the same client after a
connection has been interrupted. By default, automatic reconnection is allowed.
Allowing automatic reconnection allows users to resume working where they were
interrupted when a connection was broken. Automatic reconnection detects broken
connections and then reconnects the users to their sessions.
However, automatic reconnection can result in a new session being launched (instead of
reconnecting to an existing session) if Receiver's cookie, containing the key to the session ID
and credentials, is not used. The cookie is not used if it has expired, for example, because
of a delay in reconnection, or if credentials must be reentered. Auto client reconnect is not
triggered if users intentionally disconnect.
Auto client reconnect logging
This setting enables or disables recording of auto client reconnections in the event log. By
default, logging is disabled.
When logging is enabled, the 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.
547
Bandwidth Policy Settings
The Bandwidth section contains policy settings you can configure to avoid performance
problems related to client session bandwidth use.
Important: Using these policy settings in conjunction with the Multi-Stream policy
settings may produce unexpected results. If you use Multi-Stream settings in a policy,
ensure these bandwidth limit policy settings are not included.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Audio redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for playing or
recording audio in a user session. By default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the Audio redirection bandwidth limit
percent setting, the most restrictive setting (with the lower value) is applied.
Audio redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth limit for playing or recording audio
as a percent of the total session bandwidth. By default, no maximum percentage (zero) is
specified.
If you enter a value for this setting and a value for the Audio redirection bandwidth limit
setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
Client USB device redirection bandwidth limit
This settings specifies the maximum allowed bandwidth, in kilobits per second, for the
redirection of USB devices to and from the client (workstations hosts only)
If you enter a value for this setting and a value for the Client USB device redirection
bandwidth limit percent setting, the most restrictive setting (with the lower value) is
applied.
548
Bandwidth Policy Settings
Client USB device redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for the redirection of USB devices to
and from the client (workstations hosts only) as a percent of the total session bandwidth.
By default, no maximum percentage (zero) is specified.
If you enter a value for this setting and a value for the Client USB device redirection
bandwidth limit setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
Clipboard redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for data
transfer between a session and the local Clipboard. By default, no maximum (zero) is
specified.
If you enter a value for this setting and a value for the Clipboard redirection bandwidth
limit percent setting, the most restrictive setting (with the lower value) is applied.
Clipboard redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for data transfer between a session
and the local Clipboard as a percent of the total session bandwidth. By default, no
maximum percentage (zero) is specified.
If you enter a value for this setting and a value for the Clipboard redirection bandwidth
limit setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
COM port redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a
COM port in a client connection. By default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the COM port redirection bandwidth
limit percent setting, the most restrictive setting (with the lower value) is applied.
549
Bandwidth Policy Settings
COM port redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for accessing COM ports in a client
connection as a percent of the total session bandwidth. By default, no maximum
percentage (zero) is specified.
If you enter a value for this setting and a value for the COM port redirection bandwidth
limit setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
File redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a
client drive in a user session. By default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the File redirection bandwidth limit
percent setting, the most restrictive setting (with the lower value) takes effect.
File redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth limit for accessing client drives as a
percent of the total session bandwidth. By default, no maximum percentage (zero) is
specified.
If you enter a value for this setting and a value for the File redirection bandwidth limit
setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
HDX MediaStream Multimedia Acceleration bandwidth
limit
This setting specifies the maximum allowed bandwidth limit in kilobits per second for
delivering streaming audio and video using HDX MediaStream Multimedia Acceleration. By
default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the HDX MediaStream Multimedia
Acceleration bandwidth limit percent setting, the most restrictive setting (with the lower
value) takes effect.
550
Bandwidth Policy Settings
HDX MediaStream Multimedia Acceleration bandwidth
limit percent
This setting specifies the maximum allowed bandwidth for delivering streaming audio and
video using HDX MediaStream Multimedia Acceleration. By default, no maximum (zero) is
specified.
If you enter a value for this setting and a value for the HDX MediaStream Multimedia
Acceleration bandwidth limit setting, the most restrictive setting (with the lower value)
takes effect.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
LPT port redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for print jobs
using an LPT port in a single user session. By default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the LPT port redirection bandwidth
limit percent setting, the most restrictive setting (with the lower value) is applied.
LPT port redirection bandwidth limit percent
This setting specifies the bandwidth limit for print jobs using an LPT port in a single client
session as a percent of the total session bandwidth. By default, no maximum percentage
(zero) is specified.
If you enter a value for this setting and a value for the LPT port redirection bandwidth
limit setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
Overall session bandwidth limit
This setting specifies the total amount of bandwidth available in kilobits per second for user
sessions. By default, no limit (zero) is specified.
Limiting the amount of bandwidth consumed by a client connection can improve
performance when other applications outside the client connection are competing for
limited bandwidth.
551
Bandwidth Policy Settings
Printer redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for accessing
client printers in a user session. By default, no maximum (zero) is specified.
If you enter a value for this setting and a value for the Printer redirection bandwidth limit
percent setting, the most restrictive setting (with the lower value) is applied.
Printer redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for accessing client printers as a
percent of the total session bandwidth. By default, no maximum percentage (zero) is
specified.
If you enter a value for this setting and a value for the Printer redirection bandwidth limit
setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
TWAIN device redirection bandwidth limit
This setting specifies the maximum allowed bandwidth in kilobits per second for controlling
TWAIN imaging devices from published applications. By default, no maximum (zero) is
specified.
If you enter a value for this setting and a value for the TWAIN device redirection
bandwidth limit percent setting, the most restrictive setting (with the lower value) is
applied.
TWAIN device redirection bandwidth limit percent
This setting specifies the maximum allowed bandwidth for controlling TWAIN imaging
devices from published applications as a percent of the total session bandwidth. By default,
no maximum percentage (zero) is specified.
If you enter a value for this setting and a value for the TWAIN device redirection
bandwidth limit setting, the most restrictive setting (with the lower value) is applied.
If you configure this setting, you must also configure the Overall session bandwidth limit
setting which specifies the total amount of bandwidth available for client sessions.
552
Client Sensors Policy Settings
The Client Sensors section contains policy settings for controlling how mobile device sensor
information is handled in a user session.
These policy settings are applicable to the following Citrix products:
●
XenApp 6.5
Allow applications to use the physical location of the
client device
This setting determines whether applications running in a XenApp session on a mobile
device are allowed to use the physical location of the client device. By default, the use of
location information is prohibited.
When this setting is prohibited, attempts by an application to retrieve location information
return a "permission denied" value.
When this setting is allowed, a user can prohibit use of location information by denying a
Receiver request to access the location. Android and iOS devices prompt at the first request
for location information in each session.
When developing hosted applications that use the Allow applications to use the physical
location of the client device setting, consider the following:
●
A location-enabled application should not rely on location information being available
because:
●
A user might not allow access to location information.
●
The location might not be available or might change while the application is
running.
A user might connect to the application session from a different device that does
not support location information.
A location-enabled application must:
●
●
●
Have the location feature off by default.
●
Provide a user option to allow or disallow the feature while the application is
running.
Provide a user option to clear location data that is cached by the application.
(Receiver does not cache location data.)
A location-enabled application must manage the granularity of the location information
so that the data acquired is appropriate to the purpose of the application and conforms
to regulations in all relevant jurisdictions.
●
●
553
Client Sensors Policy Settings
554
●
A secure connection (for example, using SSL/TLS or a VPN) should be enforced when
using location services. Citrix Receiver should connect to trusted servers.
●
Consider obtaining legal advice regarding the use of location services.
Desktop UI Policy Settings
The Desktop UI section contains policy settings that control visual effects, such as desktop
wallpaper, menu animations, and drag-and-drop images, to manage the bandwidth used in
client connections. You can improve application performance on a WAN by limiting
bandwidth usage.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Desktop wallpaper
This setting allows or prevents wallpaper showing in user sessions. By default, user sessions
can show wallpaper.
To turn off desktop wallpaper and reduce the bandwidth required in user sessions, select
Prohibited when adding this setting to a policy.
Menu animation
This setting allows or prevents menu animation in user sessions. By default, menu animation
is allowed.
Menu animation is a Microsoft personal preference setting that causes a menu to appear
after a short delay, either by scrolling or fading in. When this policy setting is set to
Allowed, an arrow icon appears at the bottom of the menu. The menu appears when you
mouse over that arrow.
View window contents while dragging
This setting allows or prevents the display of window contents when dragging a window
across the screen. By default, viewing window contents is allowed.
When set to Allowed, the entire window appears to move when you drag it. When set to
Prohibited, only the window outline appears to move until you drop it.
555
End User Monitoring Policy Settings
The End User Monitoring section contains policy settings for measuring session traffic.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
ICA round trip calculation
This setting determines whether or not ICA round trip calculations are performed for active
connections. By default, calculations for active connections are enabled.
By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs
that indicates user interaction. This delay can be indefinite in length and is designed to
prevent the ICA roundtrip measurement being the sole reason for ICA traffic.
ICA round trip calculation interval (Seconds)
This setting specifies the frequency, in seconds, at which ICA round trip calculations are
performed. By default, ICA round trip is calculated every 15 seconds.
ICA round trip calculations for idle connections
This setting determines whether or not ICA round trip calculations are performed for idle
connections. By default, calculations are not performed for idle connections.
By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs
that indicates user interaction. This delay can be indefinite in length and is designed to
prevent the ICA roundtrip measurement being the sole reason for ICA traffic.
556
File Redirection Policy Settings
The File Redirection section contains policy settings relating to client drive mapping and
client drive optimization.
Auto connect client drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents automatic connection of client drives when users log on. By
default, automatic connection is allowed.
When allowing this setting, make sure to enable the settings for the drive types you want
automatically connected. For example, to allow automatic connection of users' CD-ROM
drives, configure this setting and the Client optical drives setting.
Related Policy Settings
●
Client drive redirection
●
Client floppy drives
●
Client optical drives
●
Client fixed drives
●
Client network drives
●
Client removable drives
Client drive redirection
Applicable products: XenApp; XenDesktop
This setting enables or disables drive redirection to and from the user device. By default,
file redirection is enabled.
When enabled, users can save files to all their client drives. When disabled, all file
redirection is prevented, regardless of the state of the individual file redirection settings
such as Client floppy drives and Client network drives.
Related Policy Settings
●
557
Client floppy drives
File Redirection Policy Settings
●
Client optical drives
●
Client fixed drives
●
Client network drives
●
Client removable drives
Client fixed drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents users from accessing or saving files to fixed drives on the
user device. By default, accessing client fixed drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and
set to Allowed. If these settings are disabled, client fixed drives are not mapped and users
cannot access these drives manually, regardless of the state of the Client fixed drives
setting.
To ensure fixed drives are automatically connected when users log on, configure the Auto
connect client drives setting.
Client floppy drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents users from accessing or saving files to floppy drives on the
user device. By default, accessing client floppy drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and
set to Allowed. If these settings are disabled, client floppy drives are not mapped and users
cannot access these drives manually, regardless of the state of the Client floppy drives
setting.
To ensure floppy drives are automatically connected when users log on, configure the Auto
connect client drives setting.
Client network drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents users from accessing and saving files to network (remote)
drives through the user device. By default, accessing client network drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and
set to Allowed. If these settings are disabled, client network drives are not mapped and
users cannot access these drives manually, regardless of the state of the Client network
558
File Redirection Policy Settings
drives setting.
To ensure network drives are automatically connected when users log on, configure the
Auto connect client drives setting.
Client optical drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents users from accessing or saving files to CD-ROM, DVD-ROM,
and BD-ROM drives on the user device. By default, accessing client optical drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and
set to Allowed. If these settings are disabled, client optical drives are not mapped and
users cannot access these drives manually, regardless of the state of the Client optical
drives setting.
To ensure optical drives are automatically connected when users log on, configure the Auto
connect client drives setting.
Client removable drives
Applicable products: XenApp; XenDesktop
This setting allows or prevents users from accessing or saving files to USB drives on the user
device. By default, accessing client removable drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and
set to Allowed. If these settings are disabled, client removable drives are not mapped and
users cannot access these drives manually, regardless of the state of the Client removable
drives setting.
To ensure removable drives are automatically connected when users log on, configure the
Auto connect client drives setting.
Host to client redirection
Applicable products: XenApp
This setting enables or disables file type associations for URLs and some media content to
be opened on the user device. When disabled, content opens on the server. By default, file
type association is disabled.
These URL types are opened locally when you enable this setting:
559
●
Hypertext Transfer Protocol (HTTP)
●
Secure Hypertext Transfer Protocol (HTTPS)
File Redirection Policy Settings
●
Real Player and QuickTime (RTSP)
●
Real Player and QuickTime (RTSPU)
●
Legacy Real Player (PNM)
●
Microsoft’s Media Format (MMS)
Preserve client drive letters
Applicable to: XenDesktop
This setting enables or disables mapping of client drives to the same drive letter in the
session. By default, client drive letters are not preserved.
When enabling this setting, make sure the Client drive redirection setting is present and
set to Allowed.
Read-only client drive access
Applicable products: XenApp; XenDesktop
This setting allows or prevents users and applications from creating or modifying files or
folders on mapped client drives. By default, files and folders on mapped client drives can
be modified.
If set to Enabled, files and folders are accessible with read-only permissions.
When adding this setting to a policy, make sure the Client drive redirection setting is
present and set to Allowed.
Special folder redirection
Applicable products: XenApp
This setting allows or prevents Citrix Receiver and Web Interface users to see their local
Documents and Desktop special folders from a session. By default, special folder redirection
is allowed.
This setting prevents any objects filtered through a policy from having special folder
redirection, regardless of settings that exist elsewhere. When you allow this setting, any
related settings specified for the Web Interface or Citrix Receiver are ignored.
To define which users can have special folder redirection, select Allowed and include this
setting in a policy filtered on the users you want to have this feature. This setting overrides
all other special folder redirection settings throughout XenApp.
560
File Redirection Policy Settings
Because special folder redirection must interact with the user device, policy settings that
prevent users from accessing or saving files to their local hard drives also prevent special
folder redirection from working. If you enable the Special folder redirection setting, make
sure the Client fixed drives setting is enabled as well.
For seamless applications and seamless and published desktops, special folder redirection
works for Documents and Desktops folders. Citrix does not recommend using special folder
redirection with published Windows Explorer.
Use asynchronous writes
Applicable products: XenApp; XenDesktop
This setting enables or disables asynchronous disk writes. By default, asynchronous writes
are disabled.
Asynchronous disk writes can improve the speed of file transfers and writing to client disks
over WANs, which are typically characterized by relatively high bandwidth and high latency.
However, if there is a connection or disk fault, the client file or files being written may end
in an undefined state. If this happens, a pop-up window informs the user of the files
affected. The user can then take remedial action, such as restarting an interrupted file
transfer on reconnection or when the disk fault is corrected.
Citrix recommends enabling asynchronous disk writes only for users who need remote
connectivity with good file access speed and who can easily recover files or data lost in the
event of connection or disk failure. When enabling this setting, make sure that the Client
drive redirection setting is present and set to Allowed. If this setting is disabled,
asynchronous writes will not occur.
561
Flash Redirection Policy Settings
The Flash Redirection section contains policy settings for handling Flash content in user
sessions.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Flash acceleration
This setting enables or disables Flash content rendering on user devices instead of the
server. By default, client-side Flash content rendering is enabled.
Note: This setting is used for legacy Flash redirection with Citrix online plug-in 12.1.
When enabled, this setting reduces network and server load by rendering Flash content on
the user device. Additionally, the Flash URL compatibility list setting forces Flash content
from specific Web sites to be rendered on the server.
On the user device, the Enable HDX MediaStream for Flash on the user device setting
must be enabled as well.
When this setting is disabled, Flash content from all Web sites, regardless of URL, is
rendered on the server. To allow only certain Web sites to render Flash content on the user
device, configure the Flash URL compatibility list setting.
Flash background color list
This setting enables you to set key colors for given URLs. By default, no key colors are
specified.
Key colors appear behind client-rendered Flash and help provide visible region detection.
The key color specified should be rare; otherwise, visible region detection might not work
properly.
Valid entries consist of a URL (with optional wildcards at the beginning or end) followed by
a 24-bit RGB color hexadecimal code. For example: http://citrix.com 000003
562
Flash Redirection Policy Settings
Flash backwards compatibility
This setting enables or disables the use of original, legacy Flash redirection features with
older versions of Citrix Receiver (formerly the Citrix online plug-in). By default, this setting
is enabled.
On the user device, the Enable HDX MediaStream for Flash on the user device setting
must be enabled as well.
Second generation Flash redirection features are enabled for use with Citrix Receiver 3.0.
Legacy redirection features are supported for use with the Citrix online plug-in 12.1. To
ensure second generation Flash redirection features are used, both the server and the user
device must have second generation Flash redirection enabled. If legacy redirection is
enabled on either the server or the user device, legacy redirection features are used.
Flash default behavior
This setting establishes the default behavior for second generation Flash acceleration. By
default, Flash acceleration is enabled.
To configure this setting, choose one of the following options:
●
Enable Flash acceleration enables use of second generation features when both the
server and the user device have second generation Flash redirection enabled. Legacy
features are available when the Flash backwards compatibility setting is enabled.
●
Block Flash Player prevents users from viewing Flash content. Second generation and
legacy Flash redirection and server-side content rendering are not used.
●
Disable Flash acceleration enables users to view Flash content rendered on the server,
provided the Flash Player for Internet Explorer is installed on the server. Second
generation and legacy Flash redirection is not used.
This setting can be overridden for individual Web pages and Flash instances based on the
configuration of the Flash URL compatibility list setting. Additionally, the user device must
have the Enable HDX MediaStream for Flash on the user device setting enabled.
Flash event logging
This setting enables or disables Flash events to be recorded in the Windows application
event log. By default, logging is enabled.
On computers running Windows 7 or Windows Vista, a Flash redirection-specific log appears
in the Applications and Services Log node.
563
Flash Redirection Policy Settings
Flash intelligent fallback
This setting enables or disables automatic attempts to employ server-side rendering for
Flash Player instances where client-side rendering is either unnecessary or provides a poor
user experience. By default, this setting is enabled.
Flash latency threshold
This setting specifies a threshold between 0-30 milliseconds to determine where Adobe
Flash content is rendered. By default, the threshold is 30 milliseconds.
During startup, HDX MediaStream for Flash measures the current latency between the
server and user device. If the latency is under the threshold, legacy Flash redirection is
used to render Flash content on the user device. If the latency is above the threshold, the
network server renders the content if an Adobe Flash player is available there.
This setting is used for legacy Flash redirection with Citrix online plug-in 12.1. When adding
this setting to a policy, ensure the Flash backwards compatibility setting is also added to
the policy and enabled.
Flash server-side content fetching URL list
This setting specifies Web sites whose Flash content can be downloaded to the server and
then transferred to the user device for rendering. By default, no sites are specified.
This setting is used when the user device does not have direct access to the Internet; the
server provides that connection. Additionally, the user device must have the Enable
server-side content fetching setting enabled.
Second generation Flash redirection includes a fallback to server-side content fetching for
Flash .swf files. If the user device is unable to fetch Flash content from a Web site, and the
Web site is specified in the Flash server-side content fetching URL list, server-side content
fetching occurs automatically.
When adding URLs to the list:
564
●
Add the URL of the Flash application instead of the top-level HTML page that initiates
the Flash Player.
●
Use an asterisk (*) at the beginning or end of the URL as a wildcard.
●
Use a trailing wildcard to allow all child URLs (http://www.citrix.com/*).
●
The prefixes http:// and https:// are used when present, but are not required for valid
list entries.
Flash Redirection Policy Settings
Flash URL compatibility list
This setting specifies the rules which determine whether Flash content on certain Web sites
are rendered on the user device, rendered on the server, or blocked from rendering. By
default, no rules are specified.
When adding URLs to the list:
565
●
Prioritize the list with the most important URLs, actions, and rendering locations at the
top.
●
Use an asterisk (*) at the beginning or end of the URL as a wildcard.
●
Use a trailing wildcard to refer to all child URLs (http://www.citrix.com/*).
●
The prefixes http:// and https:// are used when present, but are not required for valid
list entries.
●
Add to this list Web sites whose Flash content does not render correctly on the user
device and select either the Render on Server or Block options.
Graphics Policy Settings
The Graphics section contains policy settings for controlling how images are handled in user
sessions.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Display memory limit
This setting specifies the maximum video buffer size in kilobytes for the session. By default,
the display memory limit is 32768 kilobytes.
Specify an amount in kilobytes from 128 to 131072. Using more color depth and higher
resolution for connections requires more memory. If the memory limit is reached, the
display degrades according to the Display mode degrade preference setting.
Display mode degrade preference
This setting specifies that color depth or resolution degrades first when the session display
memory limit is reached. By default, color depth is degraded first.
When the session memory limit is reached, you can reduce the quality of displayed images
by choosing whether color depth or resolution is degraded first. When color depth is
degraded first, displayed images use fewer colors. When resolution is degraded first,
displayed images use fewer pixels per inch.
To notify users when either color depth or resolution are degraded, configure the Notify
user when display mode is degraded setting.
Dynamic Windows Preview
This setting enables or disables the display of seamless windows in Flip, Flip 3D, Taskbar
Preview, and Peek window preview modes. By default, this setting is enabled.
566
Graphics Policy Settings
Image caching
This setting enables or disables caching of images in sessions. When needed, the images are
retrieved in sections to make scrolling smoother. By default, image caching is enabled.
Maximum allowed color depth
This setting specifies the maximum color depth allowed for a session. By default, the
maximum allowed color depth is 32 bits per pixel.
Setting a high color depth requires more memory. To degrade color depth when the
memory limit is reached, configure the Display mode degrade preference setting. When
color depth is degraded, displayed images use fewer colors.
Notify user when display mode is degraded
This setting displays a brief explanation to the user when the color depth or resolution is
degraded. By default, notifying users is disabled.
Queuing and tossing
This setting discards queued images that are replaced by another image. By default,
queuing and tossing is enabled.
This improves response when graphics are sent to the user device. Configuring this setting
can cause animations to become choppy due to dropped frames.
567
Caching Policy Settings
The Caching section contains settings that enable you to cache image data on user devices
when client connections are limited in bandwidth.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Persistent Cache Threshold
This setting caches bitmaps on the hard drive of the user device. This enables re-use of
large, frequently-used images from previous sessions. By default, the threshold is 3000000
kilobits per second.
The threshold value represents the point below which you want the Persistent Cache
feature to take effect. For example, with regard to the default value, bitmaps are cached
on the hard drive of the user device when bandwidth is below 3000000 kbps.
568
Keep Alive Policy Settings
The Keep Alive section contains policy settings for managing ICA keep-alive messages.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
ICA keep alive timeout
This setting specifies the number of seconds between successive ICA keep-alive messages.
By default, the interval between keep-alive messages is 60 seconds.
Specify an interval between 1-3600 seconds in which to send ICA keep-alive messages. Do
not configure this setting if your network monitoring software is responsible for closing
inactive connections. 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
569
Legacy Server Side Optimizations Policy
Settings
The Legacy Server side optimizations section contains policy settings for handling Flash
content on session hosts.
These policy settings are applicable to XenApp.
Flash quality adjustment
This setting adjusts the quality of Flash content rendered on session hosts to improve
performance. By default, Flash content is optimized for low bandwidth connections only.
570
Mobile Experience Policy Settings
The Mobile Experience section contains policy settings for controlling interface behavior
during a user session on a mobile device.
These policy settings are applicable to the following Citrix products:
●
XenApp 6.5
Automatic keyboard display
This setting determines whether the mobile device keyboard opens when an editable field
has the focus. By default, this setting is prohibited and a Receiver user must manually open
the keyboard.
When this setting is allowed:
●
The device keyboard automatically opens when an editable field has the focus.
●
The desktop session scrolls if needed to make the input area visible.
●
Users can change a Receiver for iOS session setting to prevent the keyboard from
automatically opening.
●
If this feature is problematic for an application, put the application in an exclusion list
to disable the feature for it. For information, see "To configure the CtxUiMon exclusion
list" later in this topic.
This setting has been tested with Microsoft Office applications, Internet Explorer, and
various native Windows applications. Before deploying this feature, be sure to verify it with
the hosted applications in your environment.
Launch touch-optimized desktop
This setting determines whether Receiver uses a touch-optimized desktop for mobile
devices. By default, this setting is allowed.
When this setting is allowed, Receiver users can click the icon in the top right corner of the
desktop to toggle between the touch-optimized and Windows desktops.
When this setting is prohibited, Receiver only uses the traditional Windows interface.
571
Mobile Experience Policy Settings
Remote the combo box
This setting determines whether the device-native combo box opens when the user clicks a
Windows combo box control. By default, this setting is prohibited and only the Windows
combo box opens.
When this setting is allowed:
●
The device-native combo box opens.
●
The Windows combo box also opens, but is inactive.
●
Users can change a Receiver for iOS session setting to prevent the display of the
device-native combo box.
●
If this feature is problematic for an application, put the application in an exclusion list
to disable the feature for it. For information, see "To configure the CtxUiMon exclusion
list" later in this topic.
This setting has been tested with Microsoft Office applications, Internet Explorer, and
various native Windows applications. Before deploying this feature, be sure to verify it with
the hosted applications in your environment.
To configure the CtxUiMon exclusion list
The automatic keyboard and mobile combo box features can be problematic for some
applications. For example, when the automatic keyboard feature is enabled, a tap of the
Windows Start menu icon places the focus in the Start menu search box, causing the
keyboard to open. That behavior is prevented by including explorer.exe in the CtxUiMon
exclusion list. Several applications, such as explorer.exe, are added to the exclusion list by
default.
A change to the exclusion list requires an edit to the registry of the XenApp server.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
●
For the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxUiMon
Add the entry named Exclude with a string value containing a list of application file
names, delimited by semi-colons. Example: explorer.exe;myapp.exe
572
Multimedia Policy Settings
The Multimedia section contains policy settings for managing streaming audio and video in
user sessions.
These policy settings are applicable to the following Citrix products, unless otherwise
specified:
●
XenApp
●
XenDesktop
Multimedia conferencing
This setting allows or prevents support for video conferencing applications. By default,
video conferencing support is enabled.
When adding this setting to a policy, make sure the Windows Media Redirection setting is
present and set to Allowed.
When using multimedia conferencing, make sure the following conditions are met:
●
Manufacturer-supplied drivers for the web cam used for multimedia conferencing must
be installed.
●
The web cam must be connected to the client device before initiating a video
conferencing session. XenApp uses only one installed web cam at any given time. If
multiple web cams are installed on the client device, XenApp attempts to use each web
cam in succession until a video conferencing session is created successfully.
●
An Office Communicator server must be present in your farm environment.
●
The Office Communicator client software must be published on the server.
Windows Media Redirection
This setting controls and optimizes the way XenApp servers deliver streaming audio and
video to users. By default, this setting is allowed.
Allowing this setting increases the quality of audio and video rendered from the server to a
level that compares with audio and video played locally on a client device. XenApp streams
multimedia to the client in the original, compressed form and allows the client device to
decompress and render the media.
Windows Media redirection optimizes multimedia files that are encoded with codecs that
adhere to Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation
573
Multimedia Policy Settings
standards. To play back a given multimedia file, a codec compatible with the encoding
format of the multimedia file must be present on the client device.
By default, audio is disabled on Citrix Receiver. To allow users to run multimedia
applications in ICA sessions, turn on audio or give the users permission to turn on audio
themselves in their Receiver interface.
Select Prohibited only if playing media using Windows Media redirection appears worse
than when rendered using basic ICA compression and regular audio. This is rare but can
happen under low bandwidth conditions; for example, with media in which there is a very
low frequency of key frames.
Windows Media Redirection Buffer Size
This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By
default, the buffer size is 5 seconds.
Windows Media Redirection Buffer Size Use
This setting enables or disables using the buffer size specified in the Windows Media
Redirection Buffer Size setting. By default, the buffer size specified is not used.
If this setting is disabled or if the Windows Media Redirection Buffer Size setting is not
configured, the server uses the default buffer size value (5 seconds).
574
Multi-Stream Connections Policy Settings
The Multi-Stream Connections section contains policy settings for managing Quality of
Service (QoS) prioritization for multiple ICA connections in a session.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Multi-Port Policy
This setting specifies the TCP ports to be used for ICA traffic and establishes the network
priority for each port. By default, the primary port (2598) has a High priority.
When you configure ports, you can assign the following priorities:
●
Very High
●
High
●
Medium
●
Low
You might assign a Very High priority when real-time responsiveness is required, such as for
audio and video conferencing. As well, you might assign a Low priority to background
processes such as printing. Each port must have a unique priority. For example, you cannot
assign a Very High priority to both CGP port 1 and CGP port 3.
To remove a port from prioritization, set the port number to 0. You cannot remove the
primary port and you cannot modify its priority level.
When configuring this setting, reboot the server. This setting takes effect only when the
Multi-Stream Computer policy setting is enabled.
Multi-Stream (Computer Configuration)
This setting enables or disables multi-stream on the XenApp server. By default,
Multi-Stream is disabled.
If you use Citrix Branch Repeater with Multi-Stream support in your environment, you do
not need to configure this setting. Configure this policy setting when using third-party
routers or legacy Branch Repeaters to achieve the desired Quality of Service.
575
Multi-Stream Connections Policy Settings
When configuring this setting, reboot the server to ensure changes take effect.
Important: Using this policy setting in conjunction with bandwidth limit policy settings
such as Overall session bandwidth limit may produce unexpected results. When
including this setting in a policy, ensure that bandwidth limit settings are not included.
Multi-Stream (User Configuration)
This setting enables or disables multi-stream on the user device. By default, this setting is
disabled for all users.
This setting takes effect only on hosts where the Multi-Stream Computer policy setting is
enabled.
Important: Using this policy setting in conjunction with bandwidth limit policy settings
such as Overall session bandwidth limit may produce unexpected results. When
including this setting in a policy, ensure that bandwidth limit settings are not included.
576
Port Redirection Policy Settings
The Port Redirection section contains policy settings for client LPT and COM port mapping.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Auto connect client COM ports
This setting enables or disables automatic connection of COM ports on user devices when
users log on to the farm. By default, client COM ports are not automatically connected.
Auto connect client LPT ports
This setting enables or disables automatic connection of LPT ports on user devices when
users log on to the farm. By default, client LPT ports are connected automatically.
Client COM port redirection
This setting allows or prevents access to COM ports on the user device. By default, COM
port redirection is allowed.
Related Policy Settings
●
COM port redirection bandwidth limit
●
COM port redirection bandwith limit percent
Client LPT port redirection
This setting allows or prevents access to LPT ports on the user device. By default, LPT port
redirection is allowed.
LPT ports are used only by legacy applications that send print jobs to the LPT ports and not
to the print objects on the client device. Most applications today can send print jobs to
printer objects. This policy setting is necessary only for servers that host legacy
applications that print to LPT ports.
577
Port Redirection Policy Settings
Related Policy Settings
578
●
LPT port redirection bandwidth limit
●
LPT port redirection bandwith limit percent
Printing Policy Settings
The Printing section contains policy settings for managing client printing.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Client printer redirection
This setting allows or prevents client printers to be mapped to a server when a user logs on
to a session. By default, client printer mapping is allowed.
Related Policy Settings
Auto-create client printers
Default printer
This setting specifies how the default printer on the user device is established in a session.
By default, the user's current printer is used as the default printer for the session.
To use the current Remote Desktop Services or Windows user profile setting for the default
printer, select Do not adjust the user’s default printer. If you choose this option, the
default printer is not saved in the profile and it does not change according to other session
or client properties. The default printer in a session will be the first printer autocreated in
the session, which is either:
●
The first printer added locally to the Windows server in Control Panel > Devices and
Printers
●
The first autocreated printer, if there are no printers added locally to the server
You can use this option to present users with the nearest printer through profile settings
(known as Proximity Printing).
Printer auto-creation event log preference
This setting specifies the events that are logged during the printer auto-creation process.
You can choose to log no errors or warnings, only errors, or errors and warnings. By default,
errors and warnings are logged.
579
Printing Policy Settings
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 Universal print driver usage setting to Use universal
printing only or Use universal printing only if requested driver is unavailable.
Session printers
This setting specifies the network printers to be auto-created in a session. By default, no
printers are specified.
To add printers, enter the UNC path of the printer you want to auto-create. After adding
the printer, you can apply customized settings for the current session at every logon.
Wait for printers to be created (desktop)
This setting allows or prevents a delay in connecting to a session so that desktop printers
can be auto-created. By default, a connection delay does not occur. This setting does not
apply to published applications or published desktops.
580
Client Printers Policy Settings
The Client Printers section contains policy settings for client printers, including settings to
autocreate client printers, use legacy printer names, retain printer properties, and connect
to print servers.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Auto-create client printers
This setting specifies the client printers that are auto-created. This setting overrides
default client printer auto-creation settings. By default, all client printers are
auto-created.
This setting takes effect only if the Client printer redirection setting is present and set to
Allowed.
When adding this setting to a policy, select an option:
●
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 autocreation for all client printers when
users log on. This causes the Remote Desktop Services settings for autocreating client
printers to override this setting in lower priority policies.
Auto-create generic universal printer
This setting enables or disables autocreation of the generic Citrix UNIVERSAL Printer object
for sessions where a user device compatible with Universal Printing is in use. By default,
the generic Universal Printer object is not autocreated.
Related Policy Settings
●
581
Universal print driver usage
Client Printers Policy Settings
●
Universal driver preference
Client printer names
This setting selects the naming convention for auto-created client printers. By default,
standard printer names are used.
For most configurations, select Standard printer names which are similar to those created
by native Remote Desktop Services, such as “HPLaserJet 4 from clientname in session 3.”
Select Legacy printer names to use old-style client printer names and preserve backward
compatibility for users or groups using MetaFrame Presentation Server 3.0 or earlier. An
example of a legacy printer name is “Client/clientname#/HPLaserJet 4.” Because this
option is less secure, use it only to provide backward compatibility for users or groups using
MetaFrame Presentation Server 3.0 or earlier.
Related Policy Settings
●
Auto-create client printers
Direct connections to print servers
This setting enables or disables direct connections from the host to a print server for client
printers hosted on an accessible network share. By default, direct connections are enabled.
You can enable direct connections if the network print server is not across a WAN from the
host. Direct communication results in faster printing if the network print server and host
server are on the same LAN.
You can disable direct connections if the network is across a WAN or has substantial latency
or limited bandwidth. Print jobs are routed through the user device where they are
redirected to the network print server. Data sent to the user device is compressed, so less
bandwidth is consumed as the data travels across the WAN.
If two network printers have the same name, the printer on the same network as the user
device is used.
Printer driver mapping and compatibility
This setting specifies the driver substitution rules for autocreated client printers. By
default, no rules are specified.
When you define driver substitution rules, you can allow or prevent printers to be created
with the specified driver. Additionally, you can allow created printers to use only universal
print drivers. Driver substitution overrides or maps printer driver names the user device
provides, substituting an equivalent driver on the server. This gives server applications
access to client printers that have the same drivers as the server, but different driver
names.
582
Client Printers Policy Settings
You can add a driver mapping, edit an existing mapping, override custom settings for a
mapping, remove a mapping, or change the order of driver entries in the list. When adding
a mapping, enter the client printer driver name and then select the server driver you want
to substitute.
Printer properties retention
This setting specifies whether or not to store printer properties and where to store them.
By default, the system determines if printer properties are to be stored on the user device,
if available, or in the user profile.
When adding this setting to a policy, select an option:
●
Saved on the client device only is for user devices that have a mandatory or roaming
profile that is not saved. Choose this option only if all the servers in your farm are
running XenApp 5 and above and your users are using Citrix online plug-in versions 9.x,
10.x, 11.x, and 12.x, or Citrix Receiver 13.x.
●
Retained in user profile only is for user devices constrained by bandwidth (this option
reduces network traffic) and logon speed or for users with legacy plug-ins. This option
stores printer properties in the user profile on the server and prevents any properties
exchange with the user device. Use this option with MetaFrame Presentation Server 3.0
or earlier and MetaFrame Presentation Server Client 8.x or earlier. Note that this is
applicable only if a Remote Desktop Services roaming profile is used.
●
Held in profile only if not saved on client allows the system to determine where
printer properties are stored. Printer properties are stored either on the client device,
if available, or in the user profile. Although this option is the most flexible, it can also
slow logon time and use extra bandwidth for system-checking.
●
Do not retain printer properties prevents storing printer properties.
Retained and restored client printers
This setting enables or disables the retention and re-creation of printers on the user device.
By default, client printers are auto-retained and auto-restored.
Retained printers are user-created printers that are created again, or remembered, at the
start of the next session. When XenApp recreates a retained printer, it considers all policy
settings except the Auto-create client printers setting.
Restored printers are printers fully customized by an administrator, with a saved state that
is permanently attached to a client port.
583
Drivers Policy Settings
The Drivers section contains policy settings related to printer drivers.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Automatic installation of in-box printer drivers
This setting enables or disables the automatic installation of printer drivers from the
Windows in-box driver set or from driver packages staged on the host using pnputil.exe
/a. By default, these drivers are installed as needed.
Universal driver preference
This setting specifies the order in which universal printer drivers are used, beginning with
the first entry in the list. By default, the preference order is as follows:
●
EMF
●
XPS
●
PCL5c
●
PCL4
●
PS
You can add, edit, or remove drivers, and change the order of drivers in the list.
Universal print driver usage
This setting specifies when to use universal printing. By default, universal printing is used
only if the requested driver is unavailable.
Universal printing employs generic printer drivers instead of standard model-specific
drivers, potentially simplifying the burden of driver management on host computers. The
availability of universal print drivers depends on the capabilities of the user device, host,
and print server software. In certain configurations, universal printing might not be
available.
584
Drivers Policy Settings
When adding this setting to a policy, select an option:
●
Use only printer model specific drivers specifies that the client printer use only the
standard model-specific drivers that are auto-created at logon. If the requested driver
is unavailable, the client printer cannot be auto-created.
●
Use universal printing only specifies that no standard model-specific drivers are used.
Only universal print drivers are used to create printers.
●
Use universal printing only if requested driver is unavailable uses standard
model-specific drivers for printer creation if they are available. If the driver is not
available on the server, the client printer is created automatically with the appropriate
universal driver.
●
Use printer model specific drivers only if universal printing is unavailable uses the
universal printer driver if it is available. If the driver is not available on the server, the
client printer is created automatically with the appropriate model-specific printer
driver.
Related Policy Settings
●
585
Auto-create generic universal printer
Universal Printing Policy Settings
The Universal Printing section contains policy settings for managing universal printing.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Universal printing EMF processing mode
This setting controls the method of processing the EMF spool file on the Windows user
device. By default, EMF records are spooled directly to the printer.
When adding this setting to a policy, select an option:
●
Reprocess EMFs for printer forces the EMF spool file to be reprocessed and sent
through the GDI subsystem on the user device. You can use this setting for drivers that
require EMF reprocessing but that might not be selected automatically in a session.
●
Spool directly to printer, when used with the Citrix Universal Printer driver, ensures
the EMF records are spooled and delivered to the user device for processing. Typically,
these EMF spool files are injected directly to the client's spool queue. For printers and
drivers that are compatible with the EMF format, this is the fastest printing method.
Universal printing image compression limit
This setting specifies the maximum quality and the minimum compression level available
for images printed with the Universal Printer driver. By default, the image compression
limit is set to Best quality (lossless compression). If No Compression is selected,
compression is disabled for EMF printing only.
When adding this setting to a policy, select an option:
586
●
No compression
●
Best quality (lossless compression)
●
High quality
●
Standard quality
●
Reduced quality (maximum compression)
Universal Printing Policy Settings
When adding this setting to a policy that includes the Universal printing optimization
defaults setting, be aware of the following items:
●
If the compression level in the Universal printing image compression limit setting is
lower than the level defined in the Universal printing optimization defaults setting,
images are compressed at the level defined in the Universal printing image
compression limits setting.
●
If compression is disabled, the Desired image quality and Enable heavyweight
compression options of the Universal printing optimization defaults setting have no
effect in the policy.
Universal printing optimization defaults
This setting specifies the default values for printing optimization when the Universal Printer
driver is created for a session.
●
Desired image quality specifies the default image compression limit applied to
universal printing. By default, Standard Quality is enabled, meaning that users can only
print images using standard or reduced quality compression. However, the Universal
printing image compression limit setting overrides the default setting. For example, if
the default setting is set to Best Quality and the Universal printing image
compression limit setting is set to Standard Quality, users can only print images using
standard or reduced quality compression.
●
Enable heavyweight compression enables or disables reducing bandwidth beyond the
compression level set by Desired image quality, without losing image quality. By
default, heavyweight compression is disabled.
●
Image and Font Caching settings specify whether or not to cache images and fonts that
appear multiple times in the print stream, ensuring each unique image or font is sent to
the printer only once. By default, embedded images and fonts are cached. Note that
these settings apply only if the user device supports this behavior.
●
Allow non-administrators to modify these settings specifies whether or not users can
change the default print optimization settings within a session. By default, users are
not allowed to change the default print optimization settings.
Note: These options are supported for EMF printing. For XPS printing, only the Desired
image quality option is supported.
Universal printing preview preference
This setting specifies whether or not to use the print preview function for auto-created or
generic universal printers. By default, print preview is not used for auto-created or generic
universal printers.
When adding this setting to a policy, select an option:
●
587
Do not use print preview for auto-created or generic universal printers
Universal Printing Policy Settings
●
Use print preview for auto-created printers only
●
Use print preview for generic universal printers only
●
Use print preview for both auto-created and generic universal printers
Related Policy Settings
●
Universal print driver usage
Universal printing print quality limit
This setting specifies the maximum dots per inch (dpi) available for generating printed
output in the session. By default, No Limit is enabled, meaning users can select the
maximum print quality allowed by the printer to which they connect.
If this setting is configured, it limits the maximum print quality available to users in terms
of output resolution. Both the print quality itself and the print quality capabilities of the
printer to which the user connects are restricted to the configured setting. For example, if
configured to Medium Resolution (600 DPI), users are restricted to printing output with a
maximum quality of 600 DPI and the Print Quality setting on the Advanced tab of the
Universal Printer dialog box shows resolution settings only up to and including Medium
Quality (600 DPI).
When adding this setting to a policy, select an option:
588
●
Draft (150 DPI)
●
Low Resolution (300 DPI)
●
Medium Resolution (600 DPI)
●
High Resolution (1200 DPI)
●
No limit
Security Policy Settings
The Security section contains policy settings for configuring session encryption and
password requirements.
These policy settings are applicable to XenApp only.
Prompt for password
This setting requires the user to enter a password for all server connections regardless of
access scenario. By default, users are prompted for passwords only for specific types of
connections.
SecureICA minimum encryption level
This setting specifies the minimum level at which to encrypt session data sent between the
server and a user device.
When adding this setting to a policy, select an option:
●
Basic encrypts the client connection using a non-RC5 algorithm. It protects the data
stream from being read directly, but it can be decrypted. By default, the server uses
Basic encryption for client-server traffic.
●
RC5 (128 bit) logon only encrypts the logon data with RC5 128-bit encryption and the
client connection using Basic encryption.
●
RC5 (40 bit) encrypts the client connection with RC5 40-bit encryption.
●
RC5 (56 bit) encrypts the client connection with RC5 56-bit encryption.
●
RC5 (128 bit) encrypts the client connection with RC5 128-bit encryption.
The settings you specify for client-server encryption can interact with any other encryption
settings in XenApp and your Windows operating system. If a higher priority encryption level
is set on either a server or user device, settings you specify for published resources can be
overridden.
You can raise encryption levels to further secure communications and message integrity for
certain users. If a policy requires a higher encryption level, Receivers using a lower
encryption level are denied connection.
SecureICA does not perform authentication or check data integrity. To provide end-to-end
encryption for your server farm, use SecureICA with SSL/TLS encryption.
589
Security Policy Settings
SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server
and Receivers to avoid using SecureICA.
590
Server Limits Policy Settings
The Server Limits section contains policy settings for controlling idle connections.
These policy settings are applicable to XenApp only.
Server idle timer interval
This setting determines, in milliseconds, how long an uninterrupted user session will be
maintained if there is no input from the user. By default, idle connections are not
disconnected (Server idle timer interval = 0).
591
Session Limits Policy Settings
The Session Limits section contains policy settings you can use to control the number of
connections users can make and how long sessions remain connected before they are forced
to log off.
These settings are applicable to XenApp only.
Concurrent logon limit
This setting specifies the maximum number of connections a user can make to the server
farm at any given time. The 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
Linger Disconnect Timer Interval
This setting specifies the number of minutes after the last application exits to disconnect
an existing session. By default, no (zero) minutes are specified; therefore, the session is not
disconnected until the user logs off. To configure this setting, use any positive number.
Once disconnected, the XenApp license is released. If the user launches an application
before the timer interval expires, the Linger Disconnect timer resets.
Linger Terminate Timer Interval
This setting specifies the number of minutes after the last application exits to terminate an
existing session. By default, no (zero) minutes are specified; therefore, session lingering is
disabled. To configure this setting, use any positive number.
If the user launches an application before the timer interval expires, the Linger Terminate
timer resets.
592
Session Limits Policy Settings
Pre-launch Disconnect Timer Interval
This setting specifies the number of minutes to disconnect an existing pre-launched session.
By default, sessions are disconnected after 60 minutes. To configure this setting, use any
positive number.
Once disconnected, the XenApp license is released. If the user launches an application
before the timer expires, the application is launched in the existing session.
Pre-launch Terminate Timer Interval
This setting specifies the number of minutes to terminate an existing pre-launched session.
By default, sessions are terminated after 60 minutes. To configure this setting, use any
positive number.
If the user launches an application before the timer expires, the session is reconnected, if
necessary. The application launches in the existing session. If the timer interval is set to
zero, pre-launched sessions are terminated immediately.
593
Session Reliability Policy Settings
The Session Reliability section contains policy settings for managing session reliability
connections.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Session reliability connections
This setting allows or prevents sessions to remain open during a loss of network
connectivity. By default, session reliability is allowed.
Session Reliability keeps sessions active when network connectivity is interrupted. Users
continue to see the application they are using until network connectivity resumes.
When connectivity is momentarily lost, the session remains active on the server. The 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 Auto client reconnect authentication setting to require
authentication. Users are then prompted to reauthenticate when reconnecting to
interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in
sequence. Session Reliability closes, or disconnects, the user session after the amount of
time you specify in the Session reliability timeout setting. After that, the settings you
configure for Auto Client Reconnect take effect, attempting to reconnect the user to the
disconnected session.
Session reliability port number
This setting specifies the TCP port number for incoming session reliability connections. The
default port number is 2598.
594
Session Reliability Policy Settings
Session reliability timeout
This setting specifies the length of time in seconds the session reliability proxy waits for a
client to reconnect before allowing the session to be disconnected. The default length of
time is 180 seconds, or three minutes.
Though you can extend the amount of time a session is kept open, this feature is designed
to be convenient to the user and it does not prompt the user for reauthentication. If you
extend the amount of time a session is kept open indiscriminately, chances increase that a
user may get distracted and walk away from the client device, potentially leaving the
session accessible to unauthorized users.
If you do not want users to be able to reconnect to interrupted sessions without having to
reauthenticate, configure the Auto client reconnect authentication setting to require
authentication. Users are then prompted to reauthenticate when reconnecting to
interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in
sequence. Session Reliability closes, or disconnects, the user session after the amount of
time you specify in the Session reliability timeout setting. After that, the settings you
configure for Auto Client Reconnect take effect, attempting to reconnect the user to the
disconnected session.
595
Shadowing Policy Settings
The Shadowing section contains policy settings related to user-to-user shadowing.
Shadowing is useful for training purposes and for viewing presentations. You can also allow
help desk personnel to shadow users so they can troubleshoot user problems.
These policy settings are applicable to XenApp only.
Input from shadow connections
This setting allows or prevents shadowing users to take control of the keyboard and mouse
of the user being shadowed during a shadowing session. By default, the person shadowing
can send input to the session being shadowed.
Log shadow attempts
This setting allows or prevents recording of attempted shadowing sessions in the Windows
event log. By default, shadowing attempts are logged.
Several different event types are recorded in the Windows Event log. These include user
shadowing requests, such as when users stop shadowing, failure to launch shadowing, and
access to shadowing denials.
Notify user of pending shadow connections
This setting allows or prevents shadowed users from receiving notification of shadowing
requests from other users. When a user receives a shadowing request, the user can accept
or deny the request. By default, users are notified of shadowing requests.
Shadowing
This setting allows or prevents users from shadowing other users’ sessions. By default,
administrators can shadow users’ sessions. When you add this setting to a policy, specify
the users allowed to shadow by configuring the Users who can shadow other users and
Users who cannot shadow other users policy settings.
Session shadowing monitors and interacts with user sessions. When you shadow a user
session, you can view everything that appears on the user’s session display. You can also
use your keyboard and mouse to remotely interact with the user session.
596
Shadowing Policy Settings
Shadowing is protocol-specific. This means you can shadow ICA sessions over ICA and
Remote Desktop Protocol (RDP) sessions over RDP only.
Shadowing restrictions are set at install time and are permanent. If you enable or disable
shadowing, or certain shadowing features during Setup, you cannot change these
restrictions later. You must reinstall XenApp on the server to change shadowing restrictions.
Any user policies you create to enable user-to-user shadowing are subject to the
restrictions you place on shadowing during Setup.
Users who can shadow other users
This setting specifies the users who are allowed to shadow other users. By default, no users
are specified.
When added to an unfiltered policy, this setting enables the specified users to shadow all
other users. When a filter is applied, the specified users can initiate shadowing sessions
under the conditions specified by the filter. For example, the Sales Manager is allowed to
shadow users from the office, but not when working from home. The Sales Manager is
added to the Users who can shadow other users setting and a Client IP Address filter is
applied that allows connections from 10.8.169.* (the corporate network). When the Sales
Manager logs on to the XenApp farm from home, the ability to initiate shadowing sessions is
not available.
Users who cannot shadow other users
This setting specifies the users who are not allowed to shadow other users. By default, no
users are specified.
This setting overrides the Users who can shadow other users setting under the following
conditions:
●
Both this setting and the Users who can shadow other users setting are added to the
same policy and enabled.
●
The same user is specified in both settings.
When added to an unfiltered policy, this setting prevents the specified users from initiating
shadowing sessions with all other users. However, when a filter is applied, the specified
users can initiate shadowing sessions only under the conditions specified by the filter. For
example, the Sales Manager is allowed to shadow only the users in the US Sales
department. The Sales Manager is added to the Users who cannot shadow other users
setting and a User filter is applied that specifies the users in the Sales-US group. When the
Sales Manager logs on to the XenApp farm and initiates a shadowing session, the Sales
Manager can select only US Sales employees. The Sales Manager cannot initiate shadowing
sessions with anyone else in the company.
597
Time Zone Control Policy Settings
The Time Zone Control section contains policy settings related to using local time in
sessions.
Estimate local time for legacy clients
Applicable to: XenApp
This setting enables or disables estimating the local time zone of user devices that send
inaccurate time zone information to the server. By default, the server estimates the local
time zone when necessary.
Use local time of client
Applicable to: XenApp; XenDesktop
This setting determines the time zone setting of the user session.
When this setting is used with XenApp, the server’s time zone is used for the session by
default. When used with XenDesktop, the time zone of the user's session is used by default.
For this setting to take effect, enable the Allow time zone redirection setting in the
Remote Desktop Session Host node of the Group Policy Management Editor (Administrative
Templates > Windows Components > Remote Desktop Services > Remote Desktop Session
Host > Device and Resource Redirection). For more information about time zone
redirection, refer to the Citrix Knowledge Center.
598
TWAIN Devices Policy Settings
The TWAIN devices section contains policy settings related to mapping client TWAIN
devices, such as digital cameras or scanners, and optimizing image transfers from server to
client.
These policy settings are applicable to XenApp and XenDesktop.
Client TWAIN device redirection
This setting allows or prevents users from accessing TWAIN devices on the user device from
published image processing applications. By default, TWAIN device redirection is allowed.
Related Policy Settings
●
TWAIN compression level
●
TWAIN device redirection bandwidth limit
●
TWAIN device redirection bandwidth limit percent
TWAIN compression level
This setting specifies the level of compression of image transfers from client to server. Use
Low for best image quality, Medium for good image quality, or High for low image quality.
By default, medium compression is applied.
599
USB Devices Policy Settings
The USB devices section contains policy settings for managing file redirection for USB
devices.
Client USB device redirection
Applies to: XenApp; XenDesktop
This setting allows or prevents redirection of USB devices to and from the client
(workstation hosts only). By default, USB devices are not redirected.
Client USB device redirection rules
Applies to: XenApp; XenDesktop
This setting specifies redirection rules for USB devices. By default, no rules are specified.
When a user plugs in a USB device, the host device checks it against each policy rule in turn
until a match is found. The first match for any device is considered definitive. If the first
match is an Allow rule, the device is remoted to the virtual desktop. If the first match is a
Deny rule, the device is available only to the local desktop. If no match is found, default
rules are used. For more information about the default policy configuration for USB devices,
refer to CTX119722, “Creating USB Policy Rules,” in the Citrix Knowledge Center.
Policy rules take the format {Allow:|Deny:} followed by a set of tag= value expressions
separated by whitespace. The following tags are supported:
Tag Name
Description
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:
●
600
Rules are case-insensitive.
USB Devices Policy Settings
●
Rules may have an optional comment at the end, introduced by #.
●
Blank and pure comment lines are ignored.
●
Tags must use the matching operator =. For example, VID=1230.
●
Each rule must start on a new line or form part of a semicolon-separated list.
●
Refer to the USB class codes available from the USB Implementers Forum, Inc. Web site.
Examples of administrator-defined USB policy rules
Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive
Deny: Class=08 subclass=05 # Mass Storage
To create a rule that denies all USB devices, use “DENY:” with no other tags.
Client USB Plug and Play device redirection
Applies to: XenApp
This setting allows or prevents plug-and-play devices such as cameras or point-of-sale (POS)
devices to be used in a client session. By default, plug-and-play device redirection is
allowed.
When set to Allowed, all plug-and-play devices for a specific user or group are redirected.
When set to Prohibited, no devices are redirected.
601
Visual Display Policy Settings
The Visual Display section contains policy settings for controlling the quality of images sent
from virtual desktops.
Max frames per second
Applicable products: XenApp; XenDesktop
This setting specifies the maximum number of frames per second sent to the user device
from the virtual desktop. By default, the maximum is 24 frames per second.
Setting a high number of frames per second (for example, 30) improves the user
experience, but requires more bandwidth. Decreasing the number of frames per second (for
example, 10) maximizes server scalability at the expense of user experience.
602
Moving Images Policy Settings
The Moving Images section contains settings that enable you to remove or alter compression
for dynamic images.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Progressive compression level
This setting provides a less detailed but faster initial display of images. By default, no
progressive compression is applied.
The more detailed image, defined by the normal lossy compression setting, appears when it
becomes available. Use Very High or Ultra High compression for improved viewing of
bandwidth-intensive graphics such as photographs.
For progressive compression to be effective, its compression level must be higher than the
Lossy compression level setting.
Note: The increased level of compression associated with progressive compression also
enhances the interactivity of dynamic images over client connections. The quality of a
dynamic image, such as a rotating three-dimensional model, is temporarily decreased
until the image stops moving, at which time the normal lossy compression setting is
applied.
Related Policy Settings:
●
Progressive compression threshold value
●
Lossy compression level
●
Progressive heavyweight compression
Progressive compression threshold value
This setting represents the maximum bandwidth in kilobits per second for a connection to
which progressive compression is applied. This is applied only to client connections under
this bandwidth. By default, the threshold value is 2147483647 kilobits per second.
603
Still Images Policy Settings
The Image compression section contains settings that enable you to remove or alter
compression. When client connections are limited in bandwidth, downloading images
without compression can be slow.
These policy settings are applicable to the following Citrix products:
●
XenApp
●
XenDesktop
Extra Color Compression
This setting enables or disables the use of extra color compression on images delivered over
client connections that are limited in bandwidth, improving responsiveness by reducing the
quality of displayed images. By default, this setting is disabled.
When enabled, extra color compression is applied only when the client connection
bandwidth is below the Extra Color Compression Threshold value. When the client
connection bandwidth is above the threshold value or Disabled is selected, extra color
compression is not applied.
Extra Color Compression Threshold
This setting represents the maximum bandwidth in kilobits per second for a connection
below which extra color compression is applied. If the client connection bandwidth drops
below the set value, extra color compression, if enabled, is applied. By default, the
threshold value is 8192 kilobits per second.
Heavyweight compression
This setting enables or disables reducing bandwidth beyond progressive compression
without losing image quality by using a more advanced, but more CPU-intensive, graphical
algorithm. By default, heavyweight compression is disabled.
If enabled, heavyweight compression applies to all lossy compression settings. It is
supported on Citrix Receiver but has no effect on other plug-ins.
Related Policy Settings
●
604
Progressive compression level
Still Images Policy Settings
Lossy compression level
This setting controls the degree of lossy compression used on images delivered over client
connections that are limited in bandwidth. In such cases, displaying images without
compression can be slow. By default, medium compression is selected.
For improved responsiveness with bandwidth-intensive images, use high compression.
Where preserving image data is vital; for example, when displaying X-ray images where no
loss of quality is acceptable, you may not want to use lossy compression.
Related Policy Settings
●
Progressive compression level
Lossy compression threshold value
This setting represents the maximum bandwidth in kilobits per second for a connection to
which lossy compression is applied. By default, the threshold value is 2147483647 kilobits
per second.
Adding the Lossy compression level setting to a policy and including no specified threshold
can improve the display speed of high-detail bitmaps, such as photographs, over a LAN.
605
Licensing Policy Settings
The Licensing section contains policy settings for configuring Citrix Licensing.
These policy settings are applicable to XenApp.
License server host name
This setting specifies the name of the server hosting XenApp licenses. By default, no host
name is specified.
If you decide to change the license server name, ensure that a license server with the new
name already exists on your network. Because license files are tied to the license 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. By default,
port 27000 is specified.
If you change the port number of the license server, specify a new number in all the license
files on the server.
606
Power and Capacity Management Policy
Settings
The Power and Capacity Management section contains policy settings for managing Power
and Capacity Management agents.
These policy settings are applicable to XenApp.
Farm name
This setting specifies the name of the collection of XenApp servers managed by Power and
Capacity Management. By default, no farm name is specified.
Valid farm names are unique and may contain up to 80 characters. They do not contain
backslashes (\), single quotes ('), forward slashes (/), double-quotes ("), less-than (<),
greater than (>), backticks (`), pipes (|), or equal signs (=). Additionally, the Value box
cannot be null and a valid entry cannot consist of spaces.
If Use default value is selected when configuring this setting, the XenApp Power and
Capacity Management Agent service does not start.
Workload name
This setting specifies the name of the logical grouping of XenApp servers that host the same
application or set of applications. By default, the workload name is Unassigned. If this
setting is added to a policy with either the Unassigned value or an invalid value, neither
power management nor load consolidation can be enabled.
Valid workload names can be up to 80 characters. Additionally, the Value box cannot be
null and a valid entry cannot consist of spaces.
607
Server Policy Settings
The Server Settings section contains policy settings for configuring access control, DNS
address resolution, icon handling, and XenApp product information for licensing.
These policy settings are applicable to XenApp.
Connection access control
This setting specifies the types of client connections from which users can start sessions.
When adding this setting to a policy, select an option:
●
Any connections (selected by default) allows access to published applications through
any connection.
●
Citrix Access Gateway, Citrix Receiver, and Web Interface connections only allows
access to published applications through the listed connections, including any version of
Access Gateway. This option denies access through any other connection.
●
Citrix Access Gateway connections only allows access to published applications only
through Access Gateway Advanced Edition servers (Version 4.0 or later).
DNS address resolution
This setting enables or disables the server to return fully qualified domain names (FQDN) to
clients using the Citrix XML Service. By default, the server does not use the XML Service to
return FQDNs.
DNS address resolution works only in server farms that contain servers running MetaFrame
XP Feature Release 1 or later, and clients must be using Presentation Server Client Version
6.20.985 or later or Citrix XenApp Plugin for Hosted Apps version 11.x.
Full icon caching
This setting enables or disables the caching of larger, high resolution published application
icons on farm servers. By default, icons are cached.
To ensure only specific farm servers are affected by this setting, configure a worker group
that includes only the servers you specify. Then, include the worker group in the filter you
add to the policy. If no filter is specified, this setting affects all farm servers.
608
Server Policy Settings
Consider disabling this setting if caching icons impacts performance of the server. However,
do not disable this setting on servers acting as XML brokers for the farm.
Initial Zone Name
This setting specifies the name of the zone assigned to the XenApp server when joining a
farm. By default, the Default zone is specified.
If the setting is read by a server in controller mode and the specified zone name does not
exist in the farm, the server creates the zone.
If the setting is read by a server in session-only mode, the specified zone must exist in the
farm before the server attempts to join.
If the XenApp server is already joined to a farm, the setting has no effect.
Load Evaluator Name
This setting specifies the name of the load evaluator to be assigned to servers in a XenApp
farm. By default, no load evaluator names are specified.
You can specify load evaluators stored on the local XenApp server or on a XenApp server in
another farm. To retrieve a list of the load evaluators available, click Retrieve List and
enter the computer name of the farm server you want to use.
When a load evaluator name is specified, XenApp does not validate the name at the time
the policy setting is added. XenApp, however, does attempt to locate the name in the farm
data store when attempting to calculate load. If XenApp cannot locate the load evaluator
name specified in the policy, XenApp registers an error in the Windows Event Log and the
affected servers register full loads. Additionally, the affected servers stop accepting new
connection requests until a valid load evaluator name is specified.
If this setting is added to a policy and the policy is later renamed or deleted, XenApp uses
the Default load evaluator to calculate load.
XenApp product edition
This setting specifies the XenApp product edition. By default, the Platinum edition is
specified.
Setting the product edition activates the features available with a particular edition. The
product edition also determines which type of license a server requests from the license
server. Make sure the edition you set matches the licenses that are installed.
609
Server Policy Settings
XenApp product model
This setting specifies the product model to be activated based on the license stored on the
Citrix Licensing Server. By default, the XenApp product model is specified.
The product model determines the type of license the XenApp server requests from the
Licensing Server. When you configure this setting, ensure the product model you select
matches the licenses that are installed. After you configure this setting, restart the server
so that the appropriate license is applied to the installation.
610
Connection Limits Policy Settings
The Connection Limits section contains policy settings for controlling user and administrator
sessions and logon event logging.
These policy settings are applicable to XenApp.
Limit user sessions
This setting specifies the maximum number of connections that users can establish, in the
range 0-8192. A value of 0 indicates no connections. By default, the limit is 2147483647.
When a user tries to establish a connection in excess of this limit, a message tells the user
the connection is not allowed. When a connection request is denied, the server records the
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 limit events
This setting enables or disables the logging of events (to the server event log) about
connection attempts that were denied because they exceeded logon limits. By default,
these events are not logged.
611
Database Policy Settings
The Database Settings section contains policy settings for specifying the database
connections used when servers join a farm.
These policy settings are applicable to XenApp.
Initial Database Name
This setting specifies the name of the database used when a XenApp server is joined to a
farm. By default, the database name is not specified.
When you specify an initial database name, the value is placed in the ODBC DSN file on the
XenApp server. If you use the Server Configuration tool to define the database name, this
setting has no effect.
Note: If you are using an Oracle database for the farm data store, this setting is not used;
only the Initial Database Server Name setting value is used.
Initial Database Server Name
This setting specifies the name of the server hosting the farm database. By default, no
database server is specified.
When you specify an initial database server name, the value is placed in the ODBC DSN file
on the XenApp server. If you use the XenApp Server Configuration tool to define the
database server name, this setting has no effect.
If you are using an Oracle database for the farm data store, and you want to use this policy
setting, follow the procedure described in Approach 3 of the topic "Preparing for XenApp 6
Imaging and Provisioning" to capture an image after XenApp installation, configuration, and
restart. Select the Clear database location settings from this server checkbox. After you
capture an image of the server, edit the Citrix Initial Database Server name Computer
policy setting with the Oracle database server name, and then apply the policy. When the
image reboots, it will look in that policy for the initial database server name.
Initial Failover Partner
This setting specifies the name of the database server to be used in the event the primary
database server is unavailable. By default, no value is specified.
When you specify a failover database server, the value is placed in the ODBC DSN file on the
XenApp server. This setting is applicable only to farms that use Microsoft SQL Server for the
data store.
612
Database Policy Settings
613
Health Monitoring and Recovery Policy
Settings
The Health Monitoring and Recovery section contains policy settings for configuring Health
Monitoring and Recovery tests and server load balancing exclusions.
These policy settings are applicable to XenApp.
Health monitoring
This setting allows or prevents running Health Monitoring and Recovery tests on the farm
servers. By default, Health Monitoring and Recovery tests are allowed to run.
Health monitoring tests
This setting specifies which Health Monitoring tests to run. You can add or remove tests.
You can also edit the configuration of a test (name, location, description, interval,
threshold, time-out and recovery action). By default, the following Citrix tests are run:
Test Name
Default Interval
(seconds)
Default Threshold
Default Recovery
Action
Citrix IMA Service
Test
60
5
Alert Only
Logon Monitor Test
1
5
Alert Only
Ticketing Test
60
5
Prohibit logons and
connections to the
server
Terminal Services
Test
60
5
Alert Only
Maximum percent of servers with logon control
This setting specifies the maximum percent of servers on which Health Monitoring and
Recovery can prohibit logons. By default, logons are prohibited on ten percent of servers.
When the specified percentage of servers are either offline or are configured to prohibit
logons, the Prohibit logons and connections to the server recovery action has no effect.
To ensure prompt recovery, apply the same limit to all servers in the farm.
614
Memory Optimization Policy Settings
The Memory/CPU section contains policy settings for managing CPU utilization and memory
optimization.
These policy settings are applicable to XenApp.
CPU management server level
This setting specifies the level of CPU utilization management on the server. Managing CPU
resources can normalize CPU peaks and reduce the resources required to handle CPU spikes.
By default, CPU utilization is not managed.
When adding this setting to a policy, select an option:
●
No CPU utilization management disables CPU utilization management on the server.
●
Fair sharing of CPU between sessions ensures that CPU resources are equitably shared
among users by having the server allocate an equal share of CPU to each user.
●
Preferential Load Balancing allocates more CPU resources to one user over another
based on the resource allotment for each session. The resource allotment is determined
by the importance levels of both the published application running in the session and
the session itself.
Note: To use CPU Utilization Management, ensure the Fair Share CPU Scheduling (DFSS)
feature of Remote Desktop Services is disabled on the server.
Related Policy Settings: Session importance
Memory optimization
This setting enables or disables memory optimization. Enabling memory optimization
improves the ability to manage DLL allocation in both real and overall virtual memory by
creating shared DLLs for applications that are open in multiple sessions. By default, this
setting is disabled.
Memory optimization application exclusion list
This setting specifies the applications that memory optimization should ignore. By default,
no applications are specified.
615
Memory Optimization Policy Settings
Memory optimization interval
This setting specifies the interval for running memory optimization. By default, memory
optimization runs daily.
When adding this setting to a policy, make sure the Memory optimization setting is present
and set to Enabled.
Memory optimization schedule: day of month
This setting specifies the day of the month that memory optimization runs, in the range
1-31. By default, memory optimization is scheduled for the first day of each month.
When adding this setting to a policy, make sure the following policy settings are present:
●
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 Daily, Weekly,or Monthly
Memory optimization times are scheduled in the local time zone of the server and use a
12-hour clock. If you enter a time according to a 24-hour clock, the time is converted
616
Memory Optimization Policy Settings
automatically to a 12-hour clock. If you enter a time without a TT value, the time defaults
to AM.
617
Offline Applications Policy Settings
The Offline Applications section contains policy settings for controlling offline application
access, licensing, and logging.
These policy settings are applicable to XenApp.
Offline app client trust
This setting enables or disables the ability of offline application clients to recreate sessions
when reconnecting, without authenticating again. By default, users must authenticate when
reconnecting to offline applications.
Offline app event logging
This setting enables or disables logging of offline application events to the event log on the
server. By default, offline application events are not logged.
Offline app license period
This setting specifies the number of days applications can work offline before users have to
renew the license. The license period, 21 days by default, can range from 2 to 365 days.
Licenses automatically renew at login and every day while logged in. Changes to the license
period occur when the license is renewed.
To configure licenses, administrators can use the License Administration Console or
command-line tools. They must also ensure they have a sufficient number of licenses to
support the total number of users with offline access permission.
Offline app users
This setting specifies the users who have permission to access offline applications. You can
add or delete users from this list. By default, no users are specified.
Users in this group can continue using configured applications after disconnecting from the
network for the number of days specified in the Offline app license period setting. You
must configure the applications for offline access in the application properties.
The total number of users with offline access permission should not exceed the total
number of licenses available for offline access.
618
Reboot Behavior Policy Settings
The Reboot Behavior section contains policy settings for scheduling server restarts,
disabling logons, and configuring warning messages.
These policy settings are applicable to XenApp, Enterprise and Platinum editions only.
Reboot custom warning
This setting enables or disables sending a custom warning message (in addition to the
standard restart message) to users before a scheduled server restart. To specify the text for
this warning, configure the Reboot custom warning text setting. By default, only the
standard warning message is sent.
Reboot custom warning text
This setting specifies the text in the custom warning message sent to users before a
scheduled server restart. By default, no message text is specified.
To send a custom message, the Reboot custom warning setting must be enabled.
Reboot logon disable time
This setting specifies the number of minutes before a scheduled server restart that logons
to the server are disabled. By default, logons are disabled 60 minutes prior to server
restart.
Reboot schedule frequency
This setting specifies the frequency, in days, that scheduled server restarts occur. By
default, scheduled restarts occur every 7 days (once each week).
Reboot schedule randomization interval
This setting specifies the interval, in minutes, in which servers are restarted before or after
the scheduled restart time. This interval prevents all servers in the farm from restarting
simultaneously. By default, the setting is 0.
619
Reboot Behavior Policy Settings
For example, if the Reboot schedule time setting is set to 11:00 PM and the randomization
interval is 15 minutes, the restart can occur at any time between 10:45 PM and 11:15 PM.
Reboot schedule start date
This setting specifies the date on which scheduled server restarts begin, in the form
MM/DD/YYYY. By default, no start date is specified.
Reboot schedule time
This setting specifies the time at which scheduled server restarts occur in the form H:MM
TT, where H is the hour, MM is the minute, and TT is the time of day (AM or PM). Restart
times are scheduled in the local time zone of the server and use a 12-hour clock. By
default, scheduled server restarts occur at 12:00 AM (midnight).
If you enter a time according to a 24-hour clock, the time is converted automatically to a
12-hour clock. If you enter a time without a TT value, the time of day defaults to AM.
Reboot warning interval
This setting specifies how often standard and custom warning messages are sent to users
before a scheduled restart. By default, messages are sent every 15 minutes.
Configure the Reboot warning start time setting to specify when to start sending the
warning messages.
Reboot warning start time
This setting specifies the number of minutes before a scheduled server restart to send
standard or custom warnings to users. By default, messages are sent 60 minutes prior to
server restart.
Configure the Reboot warning interval setting to specify how often the warning is sent.
Reboot warning to users
This setting enables or disables sending a standard warning message to users before a
scheduled server restart. By default, messages are not sent to users prior to server restarts.
To send a custom warning message (in addition to the standard message), enable the
Reboot custom warning setting and specify the text in the Reboot custom warning text
setting.
620
Reboot Behavior Policy Settings
Scheduled reboots
This setting enables or disables scheduled server restarts. By default, server reboots are not
scheduled.
You can configure automatic restarts at specific times and frequencies, as well as the
starting date of the schedule. When this setting is enabled, the values configured for the
following settings take effect when added to a policy:
621
●
Reboot schedule frequency
●
Reboot logon disable time
●
Reboot schedule randomization interval
●
Reboot schedule start date
●
Reboot schedule time
Server Session Settings
The Server Session Settings section contains policy settings for configuring Single Sign-On
and session importance.
These policy settings are applicable to XenApp.
Session importance
This setting specifies the importance level at which a session is run. By default, sessions are
run at the Normal level.
If the CPU management server level setting is configured for No CPU utilization
management, sessions with higher importance levels are allowed to use more CPU cycles
than sessions with lower importance levels.
If the CPU management server level setting is configured for Preferential Load Balancing,
sessions with higher importance levels are directed to servers with lower resource
allotments.
Single Sign-On
This setting enables or disables the use of Single Sign-on when users connect to servers or
published applications in a XenApp farm. By default, Single Sign-On is enabled.
Single Sign-On central store
This setting specifies the UNC path of the Single Sign-On central store to which users are
allowed to connect. By default, no path is specified.
Policies apply only to shared folders you configure to be Single Sign-On central stores. If you
want this setting to use the central store specified by the Single Sign-On plug-in, leave this
field blank.
Server farm zone failover preferences apply only to published objects, not to central stores.
If the 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.
622
Virtual IP Policy Settings
The Virtual IP section contains policy settings for configuring Virtual IP support for
applications.
These policy settings are applicable to XenApp.
Virtual IP adapter address filtering
This setting enables or disables filtering of the list of addresses returned by the
GetAdaptersAddresses() function to only include the session virtual IP address and the
loopback address. By default, the list of adapter addresses is not filtered.
Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop
Session Host Configuration. Additionally, enable the Virtual IP enhanced compatibility
policy setting. If these settings are not configured, filtering does not occur.
After enabling this setting, configure the Virtual IP filter adapter addresses programs list
to add the applications whose overhead can be reduced through adapter address filtering.
Virtual IP compatibility programs list
This setting specifies the application processes that can use virtual IP addresses. By default,
no processes are specified.
When adding programs to the list, specify only the executable name. It is not necessary to
specify the entire path.
Virtual IP enhanced compatibility
This setting enables or disables additional support of Windows Remote Desktop IP
virtualization. This allows calls to the gethostbyname() function within sessions to return
the assigned virtual IP address for the session. By default, this setting is disabled.
Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop
Session Host Configuration. If this setting is not configured, additional support does not
occur.
After enabling this setting, configure the Virtual IP enhanced compatibility programs list
setting to add the applications that can use virtual IP addresses.
623
Virtual IP Policy Settings
Virtual IP filter adapter addresses programs list
This setting specifies the application executables that can use filter adapter addresses. By
default, the executable "outlook.exe" is specified.
When adding programs to the list, specify only the executable name. It is not necessary to
specify the entire path.
Virtual IP loopback support
This setting enables or disables the use of virtual loopback addresses in sessions. By default,
sessions do not have virtual loopback addresses.
After enabling this setting, configure the Virtual IP virtual loopback programs list to add
the applications that can use virtual loopback addresses.
Virtual IP virtual loopback programs list
This setting specifies the application executables that can use virtual loopback addresses.
By default, no executables are specified.
When adding programs to the list, specify only the executable name. It is not necessary to
specify the entire path.
624
XML Service Policy Settings
The XML Service section contains policy settings for configuring the Citrix XML Service.
These policy settings are applicable to XenApp.
Trust XML requests
This setting specifies whether the Citrix XML Service should trust requests it receives. By
default, the XML Service does not automatically trust requests.
Before enabling this rule, avoid security risks by using IPSec, firewalls, or another
technology that ensures only trusted services communicate with the Citrix XML Service.
XML Service port
This setting specifies the port number to use for the Citrix XML Service. To disable the port,
enter 0 as the port number. By default, the port is disabled.
When specifying the XML Service port number, the range of values you can enter is
1024-65535. Citrix recommends using port 8080.
625
Publish Resources
When you publish an application, configuration information for the application is stored in
the data store for the server farm. The configuration information includes which types of
files are associated with the application; users who can connect to the application;
importance level for Preferential Load Balancing; and client-side session properties that
include window size, number of colors, level of encryption, and audio settings.
When delivered to users, published applications appear very similar to applications running
locally on the user device.
Users start applications depending on the delivery options you select while publishing and
the plug-in they are running on their devices. Consult the appropriate sections in eDocs or
other documentation about the Receiver and Plug-ins for more information about the
Plug-in with which your users start published applications.
In This Section
Choose from the following methods to publish your applications:
626
Publishing Resources using the AppCenter
The most commonly used method for
publishing resources to users for access on
any Citrix-enabled user device. This
approach uses the publishing wizard in the
AppCenter to make available hosted and
streamed applications, content, and
desktops across the XenApp environment.
Publishing VM Hosted Apps
Publish applications hosted on virtual or
physical systems (servers or desktops)
through the AppCenter. This approach uses
XenDesktop technology and is ideal for
applications that do not support multi-user
environments or have other specific
requirements that make them unsuitable to
install on or stream to a XenApp server.
Deploying and Publishing Applications
with Microsoft System Center
Configuration Manager 2007
Deploy and publish physical applications and
App-V sequences to XenApp directly through
the System Center Console. By using Power
and Capacity Management to directing
incoming user connections away from servers
set to receive application, deploy
applications to XenApp servers with minimal
to no service interruptions. Deploy Microsoft
Windows Server Update Services (WSUS)
updates to XenApp server the same way.
Publish
Publishing App-V Sequences
Publish App-V virtual application sequences
in the AppCenter for delivery to XenApp
servers or Citrix-enabled user devices.
Similar to Citrix Application Streaming
technology, this approach allows
administrators to prepare the application
environment once and deliver it on-demand
to various devices.
In addition, the XenApp 6 Powershell SDK offers Citrix customers, distributors, and partners
a programmatic interface for publishing applications using the New-XAApplication
command. For information, download the Readme and SDK from the Citrix Developer
Network Web site at http://community.citrix.com/display/xa/XenApp+6+PowerShell+SDK.
627
Publishing Resources
With XenApp, you provide users with access to information by publishing the following types
of resources that can be virtualized on servers or desktops:
●
Applications installed on servers running XenApp. When users access them, the
published applications appear to be running locally on client devices.
●
Streamed applications installed in application profiles and stored on a file server in
your App Hub. Users access the profile and virtualize the applications on their client
desktops. For information about preparing and publishing applications for streaming,
see the topics for Application Streaming.
●
Data files such as Web pages, documents, media files, spreadsheets, and URLs. In
XenApp, the combined total of data types you publish is referred to as content.
●
The server desktops, so users can access all of the resources available on the server.
Note: Citrix recommends that server desktops be locked down to prevent user access
to sensitive areas of the operating system.
Publish all of these resource types using the Publish Application wizard in the Citrix
AppCenter. To further refine how your users launch and access published resources, refer
to information about configuring content redirection and XenApp policies.
Citrix recommends installing applications that interact with each other on the same group
of servers (called a silo). If you have multiple applications silos, Citrix recommends using
separate organizational units, so they can be convenient targets for policies and worker
groups. For more guidance about planning for applications and server loads, see the eDocs
section about designing a XenApp deployment.
Important: Before you begin, refer to the system requirements for supported platforms
and system prerequisites.
628
Publishing Resources
With XenApp, you provide users with access to information by publishing the following types
of resources that can be virtualized on servers or desktops:
●
Applications installed on servers running XenApp. When users access them, the
published applications appear to be running locally on client devices.
●
Streamed applications installed in application profiles and stored on a file server in
your App Hub. Users access the profile and virtualize the applications on their client
desktops. For information about preparing and publishing applications for streaming,
see the topics for Application Streaming.
●
Data files such as Web pages, documents, media files, spreadsheets, and URLs. In
XenApp, the combined total of data types you publish is referred to as content.
●
The server desktops, so users can access all of the resources available on the server.
Note: Citrix recommends that server desktops be locked down to prevent user access
to sensitive areas of the operating system.
Publish all of these resource types using the Publish Application wizard in the Citrix
AppCenter. To further refine how your users launch and access published resources, refer
to information about configuring content redirection and XenApp policies.
Citrix recommends installing applications that interact with each other on the same group
of servers (called a silo). If you have multiple applications silos, Citrix recommends using
separate organizational units, so they can be convenient targets for policies and worker
groups. For more guidance about planning for applications and server loads, see the eDocs
section about designing a XenApp deployment.
Important: Before you begin, refer to the system requirements for supported platforms
and system prerequisites.
629
Evaluating Application Delivery Methods
The application delivery method is a factor in determining the number of servers in a farm
and their individual hardware requirements.
How you choose to deliver applications depends on your organization's needs and end-users'
requirements. For example, some organizations use XenApp to streamline administration. In
other organizations, the existing hardware infrastructure might affect the delivery method
selected, as can the types of applications to be delivered. In addition, some end-users
might run all applications while connected to the company network, while others might
work in remote locations and run applications while disconnected from the network.
Method/Description
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.
630
●
This method provides a
consistent user experience
regardless of the user
device.
●
Farm servers require
sufficient resources to
support the
applications.
●
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.
Users must be
connected to the server
or network to run the
applications (no offline
access).
●
This method is effective
for applications with
components that are
intertwined with the
operating system (such as
a .NET framework).
Evaluating Application Delivery Methods
Streamed to server:
Executables for
applications are put in
profiles and stored on a
file server or Web server
(the App Hub); however,
when launched, they
stream to the server, and
application processing
takes place on the
server. Unlike installed
applications, streamed
applications are stored in
the App Hub and provide
application isolation by
design.
Streamed to desktop:
Executables for
applications are put in
profiles and stored on a
file server or Web server
(the App Hub). When
launched, the files
required to execute the
application are streamed
to the user device, and
application processing
takes place on the user
device instead of the
XenApp server. When
applications are
streamed to the user
device, the user
experience is similar to
running applications
locally. After
applications are cached
on the user device, users
can continue running the
apps after disconnecting
from the network
(referred to as offline
access).
631
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.
●
Farm servers require
sufficient resources to
support the
applications.
●
Users must be
connected to the server
or network (no offline
access).
●
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.
●
Some applications are
not candidates for
profiling, such as those
using a .NET
framework.
●
Updating applications is
simplified because you
update only a single
application profile.
●
Users can have the local
application experience,
but you manage the
applications centrally.
●
●
Users might have a better
experience when
resource-intensive
applications, such as
graphics applications, are
streamed to desktops.
User devices must have
sufficient resources to
run the applications
locally; the user
devices cannot be thin
clients.
●
User devices must run
Windows operating
systems, including
Windows 7, XP, or
Vista.
●
●
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.
Evaluating Application Delivery Methods
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.
632
Publishing Resources using the
AppCenter
With the AppCenter, you provide users with access to information by publishing the
following types of resources that can be virtualized on servers or desktops:
●
Applications installed on servers running XenApp. When users access them, the
published applications appear to be running locally on user devices.
●
Streamed applications installed in application profiles and stored on a file server in
your App Hub. Users access the profile and virtualize the applications on their user
devices.
●
Data files such as Web pages, documents, media files, spreadsheets, and URLs. In
XenApp, the combined total of data types you publish is referred to as content.
●
Server desktops so users can access all of the resources available on the server.
Note: Citrix recommends that server desktops be locked down to prevent user access
to sensitive areas of the operating system.
Publish all of these resource types using the Publish Application wizard. To further refine
how your users launch and access published resources, refer to information about
configuring content redirection and XenApp policies.
Citrix recommends installing applications that interact with each other on the same group
of servers (called a silo). If you have multiple applications silos, Citrix recommends using
separate organizational units, so they can be convenient targets for policies and worker
groups. For more guidance about planning for applications and server loads, see the eDocs
section about designing a XenApp deployment.
Important: Before you begin, refer to the system requirements for supported platforms
and system prerequisites.
633
Publishing Resources using the AppCenter
In This Section
Publishing Hosted Resources
Provide access to users for applications,
content, or desktops that can be
virtualized on servers or desktops.
Publishing Applications for Streaming
Profile and publish applications for
streaming to desktops or servers, and
configure those applications for offline
access.
Managing Application Properties
Manage properties to rename, move,
disable, and delete published applications
and change, duplicate, import, and export
published application settings.
Configuring Content Redirection
Control whether users access information
with applications published on servers or
with applications running locally on client
devices.
Making Virtual IP Addresses Available
Allow a dynamically-assigned IP address to
each session so that configured
applications running within that session
appear to have a unique address.
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:
634
●
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.
To configure servers to publish for
multiple users
To ensure applications are enabled for multiple users, install the applications using one of
the following methods:
●
Install applications as the Built-in Administrator
●
Select an “install for multiple users” option in the installation wizard for the
application, if the Setup for the application provides this option
●
Install the application for all users from a command line
To install an application for all users, after enabling Remote Desktop Services, use these
steps before installing the application:
1. Open a command prompt so that you are running it with Administrator privileges; for
example, right-click the command prompt and select Run as Administrator.
2. Run the following command at a command prompt: change user /install
3. From the command prompt, run the Setup executable for the application.
635
To publish a resource using the Publish
Application wizard
Open the Citrix AppCenter from any computer that can connect to the farm.
Steps and options in the wizard vary depending on the application type you select. This
procedure describes the basic options.
1. From the AppCenter, under the XenApp node, expand the farm or server to which you
want to publish an application.
Tip: To add a server to the list of servers for a published desktop or application (after
publishing the application), drag and drop the server onto the published desktop or
application in the left pane of the AppCenter. You can also drag and drop the
published desktop or application onto the server.
2. Select the Applications node and from the Actions pane choose Create folder. Name
the folder for the application you are publishing.
3. Select the folder you created and from the Actions pane choose Publish application.
4. In the Publish Application wizard, on the Name page, provide a display name (maximum
256 characters) and application description. The name appears on user devices when
users access the application and on the AppCenter for the farm applications. XenApp
supports application names that use Latin-1 and Unicode character sets, including
characters used in Japanese, Chinese, and Korean.
5. On the Type page, specify the type of resource you want to publish and the delivery
method. Three types of resources can be published (server desktop, content, and
application). The next few steps in the wizard differ based on which type you select.
For more details, see To select a resource type and delivery method and To select a
streaming delivery method.
6. On the Location page, add the command-line and working directory (optional) to locate
the application.
7. On the Servers page, add the individual servers or worker groups on which the
published application runs when accessed by an ICA connection.
Note: If you add a worker group, make sure that all the servers in the worker group
are running the application you are publishing.
8. On the Users page, create the Configured users list for users or groups who have
access to the application. Use the options to allow access to configured user accounts
only or to anonymous users.
9. On the Shortcut presentation page, select the icon for the application and choose how
the application is enumerated on the user device. The AppCenter has a limit of 1,000
unique application icons. When that limit is exceeded, the AppCenter displays a generic
636
To publish a resource using the Publish Application wizard
icon for all new applications.
10. On the Publish immediately page, choose whether or not to make the published
application immediately available to users.
●
By default, the published application is available when you click Finish.
To prevent users from accessing the application until you manually enable it
through application properties, select Disable application initially.
11. To view and select advanced options, check Configure advanced application settings
now. Alternatively, modify the advanced settings using the application properties.
●
When you finish, published resources (unless disabled) are available for users.
637
To select a resource type and delivery
method
In the Publish Application wizard, select the resource type that you want to deliver and the
delivery method. To view the setting, from the Action menu, select Application properties
and then select Type.
To change the resource type, from the Action menu, select Other Tasks > Change
application type and follow the instructions in the wizard.
1. Select one of the following resource types:
●
Server desktop. Publishes the entire Windows desktop of a server in the farm.
When the plug-in connects to the server, the user sees a desktop interface from
which any application installed on that server can be started. After selecting this
application type, you must specify the server that you want to publish.
To publish a desktop, you must be running XenApp. If you are running the Citrix
AppCenter on a computer that is not running XenApp, you cannot publish the local
desktop.
●
Content. Publishes nonexecutable information, such as media, Web pages, or
documents. After selecting this application type, you must specify the URL (Uniform
Resource Locator) or UNC (Uniform Naming Convention) path to the file you want to
publish. Click Browse to view available content resources on your network.
●
Application (selected by default). Publishes an application installed on one or more
servers in the farm. Note that if you are running the AppCenter on a computer that
is not a member of the farm, you cannot publish local applications.
You need to indicate one of the following application types:
638
●
Accessed from a server. Grants users access to applications that run on a
XenApp server and use shared server resources. If you choose this option, you
must then enter the location of the executable file for the application and the
XenApp server on which it will run. Choose this option as the application type
unless you intend to stream your applications.
●
Streamed if possible, otherwise accessed from a server (also called dual
mode streaming). Grants users access to a profiled application that streams
from the file share to their user devices and launches locally from within an
isolation environment. Alternatively, for user devices that do not support
streamed applications (for example, if the Offline Plug-in is not installed), this
setting allows the use of an ICA connection to access the application installed
on or streamed from a XenApp server.
●
Streamed to client. Grants users access to a profiled application that streams
from the file share to their user devices and launches locally from within an
isolation environment. With this option, the application uses client resources
To select a resource type and delivery method
instead of server resources. Users must have the Offline Plug-in installed and
access the application using Online Plug-in or a Web Interface site. If selected,
user devices that do not support client-side application virtualization (such as,
they use a non-Windows client) or do not have the Offline Plug-in installed
locally cannot launch the application.
2. If you selected Accessed from a server or Streamed if possible, otherwise accessed
from a server, you also need to select the Server application type. These are:
●
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.
639
To configure locations of published
applications
To access this option in the Citrix AppCenter, from the Publish Application wizard, continue
to the Location page. Alternatively, to modify a location, select a published application
and under Common Tasks, select Modify application properties > Modify all properties >
Basic > Location.
When you publish an application, specify the command-line and working directory
(optional) for the application:
●
Command-line. The full path of the application's executable file. Append the symbols
"%*" (percent and star symbols enclosed in double quotation marks) to the end of the
command-line to act as a placeholder for client-supplied application parameters. When
a Plug-in makes a connection request, the server replaces the symbol "%*" in the
command-line with application parameters provided by the Plug-in.
If the path to the application's executable includes directory names with spaces,
enclose the command line for the application in double quotation marks. Include a
space between the closing quotation mark and the double quotation marks around the
percent and star symbols. An example of the format to use with a path with spaces and
a placeholder is:
"C:\Program Files\Windows Media Player\mplayer1.exe" "%*"
Important: Changing the command-line text removes all file type associations from
the application. If you change the command-line text, modify the Content
Redirection application property page to select the file types you want to associate
with the application for client to server content redirection.
●
640
Working directory. By default, this path is the same as the path in the Command line
field. To run the application from a different directory, add an absolute path to this
field.
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):
641
●
HTML Web site address (http://www.citrix.com)
●
Document file on a Web server (https://www.citrix.com/press/pressrelease.doc)
●
Directory on an FTP server (ftp://ftp.citrix.com/code)
●
Document file on an FTP server (ftp://ftp.citrix.com/code/Readme.txt)
●
UNC file path (file://myServer/myShare/myFile.asf) or
(\\myServer\myShare\myFile.asf)
●
UNC directory path (file://myServer/myShare) or (\\myServer\myShare)
To disable command-line validation
XenApp provides command-line validation for content that is redirected from the client to
the server only. By default, XenApp validates published application command-line
parameters passed from the client to the server. When you use the symbols "%*", XenApp
ensures the parameters are valid before the application launches. If the parameters are
invalid, the application launches without passing the parameters. XenApp records all failed
validation attempts in the server's system log and in the security event log.
If your environment includes published applications that use customized client-supplied
parameters for purposes other than content redirection from client to server, these
applications might not function correctly when command-line validation is enabled. To
ensure client-supplied parameters are passed from client to server, disable command-line
validation for these published applications.
When using command-line validation, add all servers that store content, such as Word
documents or PDF files, to the Trusted Sites list on the XenApp server. When adding servers
to the Trusted Sites list, ensure you are logged on to the XenApp server as Administrator. If
the content servers reside in separate domains, ensure trust relationships are established
between these servers and the XenApp server.
You can disable command-line validation for selected published applications or all
published applications on a server.
642
●
If your environment includes published applications that use customized client-supplied
parameters for purposes other than content redirection from client to server, these
applications might not function correctly when command-line validation is enabled. To
ensure client-supplied parameters are passed from client to server, disable
command-line validation for these published applications.
●
To disable command-line validation for selected published applications, from the
Location page of the application properties, append the symbols “%**” (percent and
two star symbols enclosed in double quotation marks) to the command-line parameter.
To pre-launch applications to user
devices
Use the pre-launch feature to reduce application launch time at high-traffic periods. For
example, if your environment includes a large number of users who launch the same
application within a ten-minute time-frame, the rapid succession of logon requests can
overwhelm servers and slow down application launch for all users. The pre-launch feature
allows a pre-launch session to be created when a user logs on, or at a scheduled time if the
user is already logged on. This pre-launch session reduces the launch time of the first
application. The default application ctxprelaunch.exe runs in the session, but is not visible
to the user.
Considerations:
●
When a pre-launch session is created, it takes up a license immediately, even if the
user does not launch an application.
●
When you enable this feature for an application, the setting applies to all users and
servers configured for the application; in addition, the pre-launch session created for
the application is also available for all other published applications on the listed
servers.
To customize the inactivity behavior for the pre-launch application, configure the Citrix
User policy for Session Limits:
●
Pre-launch Terminate Timer Interval
Maximum amount of time before the pre-launch application exits (60 minutes by
default). Starting a user application in the session also terminates the pre-launch
application. Once the pre-launch application exits, the session remains alive if the
user's applications are running or if you configured session lingering.
●
Pre-launch Disconnect Timer Interval
Amount of time before the pre-launch application disconnects the session (60 minutes
by default). Once disconnected, the session gives up the XenApp license. When a user
launches an application, the session is reconnected. This timer does not disconnect a
session if a user launches an application. If the interval is not configured, the
pre-launch session is not ever disconnected.
Note: Customizing the pre-launch feature using Administrative Templates is not
supported. However, you can change the pre-launch configuration by modifying the
registry values, located at: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA
Client\Prelaunch and HKEY_CURRENT_USER\Software\Citrix\ICA
Client\Prelaunch.
To enable the pre-launch session:
1. In the AppCenter, from the navigation pane, select the server.
643
To pre-launch applications to user devices
2. From the Applications list, select an application.
Note: Select an application that is published for the groups of users and servers that
are eligible for the pre-launch session.
3. From the Actions pane, select Other Tasks > Create pre-launch application.
4. This task creates a copy of the application with all its properties, users, and servers,
and PreLaunch precedes the application name. This "application" is not enumerated to
users. Refer to the table below for the application properties that you can modify.
Properties and tasks for pre-launch applications
The following table lists the properties and tasks that are inherited or configured for
pre-launch applications.
The application name, display name, description, and icon are visible only in the AppCenter
and do not apply to the pre-launch application.
Inherited from the original application. Modifications are applicable
for a pre-launch application.
644
Not applicable for a pre-launch application. Modifications are
used.
To pre-launch applications to user devices
Properties:
Properties:
●
Enable/disable application
●
Hide disabled application: The application is always hidde
●
Servers
●
Application type: The type is always an installed applicat
●
Users
●
●
Location
Working directory: The directory is always set to Systems
folder in XenApp installation location. You can change th
editing the pre-launch application properties.
●
Access conditions
●
Client application folder: The pre-launch application is no
listed on the user device.
●
Access gateway filters
●
Add to client's start menu: The pre-launch application is
visible on the user device.
●
Add shortcut to client's desktop: The pre-launch applicati
not visible on the user device.
●
File types: The pre-launch application does not have any
associated file types.
●
Maximum instances: Always one instance per user.
●
Allow only one instance of application for each user: Alw
only one instance of the pre-launch application. If you co
more than one pre-launch application of the server and u
combination, additional instances are not launched.
●
Application importance: The pre-launch application is alw
the first application launched.
●
Session window size: The pre-launch application is not vis
the user device.
●
Hide application title bar: The pre-launch application is n
visible on the user device.
●
Maximize application at startup: The pre-launch applicati
not visible on the user device.
●
Client audio requirement
●
Connection encryption requirement
●
Encryption level
●
Session window color depth
Tasks:
●
Disable/enable application
●
Duplication application
●
Move to folder
●
Delete application
●
Refresh user data
●
Attach application to a load evaluator
645
Publishing Applications for Streaming
After you create profiles for applications using the Streaming Profiler, you make them
available for streaming to users by publishing the applications.
The Publish Application wizard in the Citrix AppCenter guides you through the process of
selecting the streaming options. Configure the application streaming delivery method as
you publish the application. Choose delivery options based on the users who will access the
applications and their environments.
The profiled applications must be stored on a file share or Web server that is accessible
from your XenApp server so you can publish the application, and it must be accessible by
your users so they can launch the application.
Streaming Applications to User Devices
If you deliver streamed applications directly to user desktops, users can launch the
streamed applications, which run in an isolation environment on their desktops and use
local resources to run the applications. This delivery method offers the full set of
application streaming options including desktop integration and offline access.
Before publishing an application to be streamed to client desktops, complete the following
tasks:
●
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:
646
●
Remote applications only, or
●
Dual mode streaming (streamed if possible, otherwise accessed from a server)
Publishing Applications for Streaming
For information about managing application types on Web Interface sites, see Technologies
> Web Interface.
After you ensure all of these tasks are complete, publish the application as Streamed to a
server.
647
New Features in This Release
In addition to improved application compatibility on Microsoft Windows Server 2008 R2 SP1
and Windows 7 SP1, the 6.5 release provides the following enhancements for application
streaming:
648
●
Increased support for streamed apps in pooled XenDesktop environments. For faster
application launch time on user devices, select the option to "Create a virtual hard disk"
(VHD) while profiling. This feature copies the profile contents into the VHD and mounts
it in the RadeCache location at application launch.
●
Compliance with new FIPS guidelines. The Streaming Profiler in this release uses
SHA-256 to create file hashes. To include SHA-1 hashes required by Offline Plug-ins 6.0,
select the option for "Legacy Offline Plug-in support" while profiling.
●
Enhancements for creating AppHubWhiteList. The registry key for creating the
AppHubWhiteList is now consistent with other Citrix registry keys on 32-bit and 64-bit
operating systems.
●
Ability to deliver AppHubWhiteList using Citrix Receiver Updater. Ensure that
unsigned profiles and services stream only from approved locations
●
AppCenter session reports include the names of streamed applications. The reports
of user sessions now include application names instead of just profile names.
●
Launch time improvements. General performance improvements reduce launch time
for streamed applications, including Microsoft Outlook.
System Requirements for Application
Streaming
Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the
following Microsoft operating systems:
●
Windows XP Home and Professional editions, 32-bit edition, with Service Pack 3
●
Windows XP Home and Professional editions, 64-bit edition, with Service Pack 2
●
Windows Server 2008, 32- and 64-bit editions
●
Windows Server 2003 R2
●
Windows Server 2008 R2
●
Windows Server 2008 R2, with Service Pack 1
●
Windows Vista (Home, Business, Enterprise, and Ultimate editions), 32- and 64-bit
editions, with Service Pack 1 or Service Pack 2
●
Windows 7, 32-bit and 64-bit (Enterprise, Professional, Ultimate)
Version 6.5 of the Citrix Offline Plug-in and Streaming Profiler are supported on the
following Citrix products:
Note: The list is accurate at the time of this release. For more information about
supported versions, see:
http://www.citrix.com/support/product-lifecycle/product-matrix.
●
Citrix XenApp 5, 6, and 6.5.
●
Citrix XenDesktop 4, 5, and 5.5.
●
Citrix XenServer: all supported versions.
●
Citrix Receiver (Updater) for Windows 1.x, 2.x, and 3.0.
●
Citrix Online Plug-in: Citrix recommends 13.0, which is installed with Citrix Receiver
3.0, but past versions 11.2 and 12.x are also supported.
The profiler workstation and user devices must meet the following requirements:
649
●
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.
System Requirements for Application Streaming
●
To profile and stream Microsoft Office applications to Windows Server 2003 operating
systems, install the Windows Data Execution Prevention (DEP) hotfix on the server and
profiling workstation. For information, see http://support.microsoft.com/kb/931534.
The profiler workstation must provide a run-time environment that is as close to your users'
environment as possible. To stream applications to user devices, use the following
guidelines for the profiling workstation:
●
Choose a workstation that is a similar platform to your users' devices.
●
Use a computer that is freshly reimaged so that there are no hidden files or registry
settings for applications that you intend to profile.
●
Install only the standard programs that are part of the company image, such as an
antivirus program.
●
Disable the User Account Control (UAC).
●
To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for
inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 optional).
●
Do not install the Offline Plug-in on the profiler workstation. You can install Citrix
Receiver.
Install the profiler in a path with single-byte characters only. Double-byte characters in the
installation path are not supported.
The user devices must meet the following requirements:
●
A network connection to the server farm, such as a network interface card (NIC).
●
A supported browser: Microsoft Internet Explorer 6.0, 7.0, 8.0, or 9.0.
●
To stream Microsoft Office 2007 or 2010 programs or to stream profiles enabled for
inter-isolation communication, install .NET Framework 2.0 (3.0 or 3.5 is optional).
●
Manually uninstall any previous version of the Streaming Client and Program
Neighborhood Agent on user devices.
●
To ensure availability of the features and functionality of XenApp for Windows Server
2008 R2 to your users, install the Offline Plug-in and the most recent version of Citrix
Receiver (Enterprise), which includes the Online Plug-in. In addition:
●
Citrix recommends using Citrix Receiver Updater on user devices to install (and
uninstall) Citrix plug-ins.
●
To stream applications to user desktops, install both the Offline Plug-in and Citrix
Receiver (Enterprise) on user devices.
To stream applications to a server, install Citrix Receiver (Enterprise) on user
devices. The Offline Plug-in is not required. If users launch applications from a Web
Interface site, install Citrix Receiver (the Enterprise version is not needed) and add
the site to the list of trusted sites.
Microsoft redistributable packages
●
650
System Requirements for Application Streaming
The CitrixOfflinePlugin.exe and CitrixStreamingProfiler.exe installers include the following
redistributables:
●
Microsoft Visual C++ 2005 Redistributable Package 8.0.56336
●
Microsoft Visual C++ 2005 Redistributable Package 8.0.50727.42
●
Microsoft Visual C++ 2008 Redistributable Package 9.0.21022
●
Microsoft Visual C++ 2008 Redistributable Package 9.0.30729
●
Microsoft Visual C++ 2008 Redistributable Package 9.0.30729.4148
Backward compatibility. To take advantage of the latest updates in application streaming,
Citrix recommends installing the most current versions of the Streaming Profiler, Citrix
Plug-ins, and Citrix Receiver.
●
Profiles created in the Streaming Profiler 6.5 are supported with:
●
Offline Plug-in 6.5
●
Offline Plug-in 6.0 (you must select the profiling option to support legacy Offline
Plug-ins)
Note: The Virtual Hard Disk feature is not supported for version 6.0.
Online Plug-in, which is included in Citrix Receiver 3.0 (with this release) or past
versions 11.2 through 12.x.
To continue using existing profiles with the plug-ins in this release, also install the
latest profiler and update them (simply open them in the new profiler and re-save
them).
●
●
●
If upgrading is not possible, this release provides backward compatibility for streaming
profiles created with profiler 5.2 through 6.0.
Streaming Microsoft Office 2007. For best practices for streaming Office 2007
applications, see http://support.citrix.com/article/CTX118396 in the Citrix Knowledge
Center.
Streaming Microsoft Office 2010. For best practices for streaming Office 2010
applications, see http://support.citrix.com/article/CTX124565 in the Citrix Knowledge
Center.
Update the profiler workstation and user devices with the latest Microsoft hotfixes,
including:
651
●
On Streaming Profiler workstations with Windows 7 (32-bit and 64-bit) only, download
the hotfix from http://support.microsoft.com/kb/2359223/en-US (requires a computer
restart).
●
On Windows XP 32-bit platforms, install hotfix KB978835.
●
On all Windows XP or Windows 2003 platforms, install hotfix KB973573. For more
information, see http://support.citrix.com/article/CTX124563 in the Citrix Knowledge
Center.
Application Streaming Overview
Application streaming simplifies application delivery to users by virtualizing applications on
client devices. Administrators can install and configure an application centrally and deliver
it to any desktop on demand.
Use the application streaming feature to install and configure an application on one file
server in your App Hub, publish the application using the XenApp publishing wizard, and
deliver it to any desktop or server on demand. To upgrade or patch an application, you
make the updates only in the location where you stored the application. Application
streaming augments application delivery not only to user desktops, but also to servers in
your server farms.
Application streaming offers the following features:
Install once, deliver anywhere
Provides the ability to install an application once on a profiler workstation and have it
replicated to file servers within the existing enterprise infrastructure. Once there, the
applications are delivered to client devices that request access to the application,
on-demand, as a result of end-user activity.
Seamless updates
No need to profile applications again. Updates are as simple as updating an application on a
desktop using the update program supplied by the manufacturer. The update is performed
once on the profiler workstation and delivered to client devices in a manner similar to that
used in the initial delivery.
Application isolation
All streamed applications run within isolation environments that keep the applications from
interfering with others running on the same client device. The isolation environment is
specific for the application and user session, regardless of whether the user streams to the
local client or virtualizes the streamed application from a server. The specific data files of
the application, such as INI files and registry keys, are all isolated and maintained centrally
for the streamed application.
Application caching
Application files can be cached on the client device to allow faster access the next time the
application is launched. Before an application runs, cached files are updated automatically
if there is a newer version on the file server. Note that application caching is strictly for
performance reasons; there is no requirement to have the application cached for the
application to run.
Wide range of target environments
Nearly any modern Windows platform can host a streamed application. Specifically,
supported operating systems include Windows XP Professional, Windows Server 2003 and
2008, Windows Vista, and Windows 7. With dual mode streaming, target environments are
652
Application Streaming Overview
increased to include all supported XenApp client desktops.
Dual mode streaming
Configure XenApp to stream software to client devices; otherwise, virtualize from a XenApp
server. If launching a streamed application fails on the client device, XenApp seamlessly
streams the application to the server and virtualizes the application on the client device
from XenApp.
Easy delivery of applications to farm servers
When publishing applications in a server farm, choose to virtualize applications from
XenApp, which can simplify application delivery. Instead of installing applications on your
farm servers, you stream them to XenApp from a central file share in your App Hub. Update
the application in the central location, and you update the application on all the farm
servers.
Consistent end-user experience
Applications that can be accessed through the server appear next to other applications that
the user is accustomed to either within the Web Interface, Citrix plug-ins, or on the
desktop. The user does not have to know where and how the application is executing.
Offline access
Once configured and delivered, applications are available to the user while disconnected
from the network.
Easy disaster recovery
On-demand application delivery is a powerful concept for disaster recovery situations
because the application and data are not lost if the profiles can be easily backed up, and
servers and desktops can be replaced easily.
653
Components for Application Streaming
The components related to a server farm that make applications available for streaming can
be separated into four categories. Each of these functional areas consists of software
running on one or more workstations or servers. Before you install the components for
application streaming, refer to the system requirements for application streaming.
The components that support virtualization on the user device, as shown in the diagram,
include the XenApp server, Citrix Licensing, Streaming Profiler workstation, file servers,
Web Interface, Citrix Receiver, and Offline Plug-in.
654
Components for Application Streaming
1. Licensing. Consists of the license server and License Management Console. Use the
License Management Console to manage licensing. To install Citrix Licensing, see the
licensing section in the Technologies node of Citrix eDocs.
For more information about licensing application streaming and offline access, see
Application Streaming Licensing Explained (CTX112636).
2. Administration (server farm). Consists of the following components:
655
●
Farm servers.
●
IMA database.
Components for Application Streaming
●
The Web Interface.
●
The AppCenter, to configure and manage the server delivery and publish
applications for streaming.
3. Citrix Streaming Profiler. Creates and maintains streaming application profiles. The
Streaming Profiler is an independent application that enables you to profile Windows
applications, Web applications, browser plug-ins, files, folders, and registry settings
that can be streamed to user devices and servers.
Use the profiler to create one or more targets within an application profile that can
match all the platforms of your users. This strategy creates a single profile that can
accommodate a variety of user platforms. The profiler can also update applications in
the profile and provide other resources that your users need.
4. Citrix Plug-ins. The Offline Plug-in support streaming applications to the user's desktop.
To provide offline access to applications and dual-mode streaming, install both the
Offline Plug-in and Citrix Receiver (Enterprise), which includes the Online Plug-in, on
user devices. When a user runs a published application enumerated by Citrix Receiver
or through a Web Interface site, the Offline Plug-in finds the correct target in the
profile in the App Hub, sets up the isolation environment on the user device, and then
streams the application from the profile location to the safety of the isolation
environment set up on the user device.
To support streaming applications to the server, install the Citrix Receiver on user
devices. These applications must be published as "stream to server." When users run an
application, it streams to the server and launches using an ICA connection on the user
device. To stream to a Web Interface site, you must the site to the list of trusted sites.
656
Deciding Which Receiver or Plug-in to
Use for Application Streaming
The delivery method for streaming that you select for published applications determines
the Receiver and plug-ins to must install on servers and user devices.
Citrix recommends using the Citrix Receiver Updater to deliver the packages that you want
to install on user devices:
Streamed to client desktops. With this method, you make available the full set of
application streaming features. You can publish applications as "streamed to client" or any
other method for streaming. When you stream applications directly to client desktops,
some of the application files are cached locally and the application runs using the resources
of the user device.
Install both the CitrixReceiverEnterprise.exe and CitrixOfflinePlugin.exe on user devices.
This combination enables you to:
●
Enumerate published applications in the desktop Start menu and create shortcuts on
the desktop.
●
Provide dual-mode streaming. When you select "Streamed if possible, otherwise
accessed from a server" and "Streamed to server," if streaming to the client desktop
fails, applications automatically stream to a XenApp server and launch using the Citrix
Receiver (Enterprise).
●
Configure the application and users for offline access. When this configuration is
completed, the entire application is fully cached on the user device. Users can
disconnect from the network and continue using the application for the time specified
in the offline license.
Accessed from a server. The profile is streamed from the App Hub to the XenApp server,
where the Offline Plug-in is installed by default. The application displays on the user
devices using the Receiver; the Offline Plug-in is not required on the user device. When you
publish applications as "Accessed from a server" and "Streamed to server," users access the
applications using the Receiver. This method does not support offline access to
applications.
Select the package that fits your corporate needs:
657
●
Install CitrixReceiverEnterprise.exe to stream applications to XenApp servers and
launch them with the Receiver if you require native Program Neighborhood Agent
(Applications in folders) or Smart Card authentication.
●
Install CitrixReceiver.exe to stream applications to XenApp servers and launch them
using Citrix Receiver self-service or a Web browser using a Receiver for Web or Web
Interface site you create.
Deciding Which Receiver or Plug-in to Use for Application Streaming
Important: For users to stream applications through a Web site using an Internet Explorer
or Firefox browser, add the site to the trusted sites list in Internet Explorer on the user
devices.
Streaming to a virtual desktop. To deliver applications to pooled XenDesktop
environments, install both Receiver and the Offline Plug-in on the virtual desktop image.
You must profile the applications with the option to create a virtual hard disk. When users
launch the application, the profile contents are mounted in the RadeCache location from
the AppHub.
●
When profiling the application in the streaming profiler, select the option to Create
virtual hard disk.
●
When publishing the application in XenApp, select the delivery option to stream to
client desktop.
Note: Do not configure HTTP delivery for applications that stream to virtual desktops.
Also, offline access is not supported on virtual desktops; if you enable offline access,
the settings are ignored for this deployment.
●
658
When creating the virtual desktop image, install both the CitrixReceiverEnterprise.exe
and CitrixOfflinePlugin.exe.
Providing Single Sign-on for Streamed
Applications
Citrix extends the Single Sign-on feature for streamed applications. When Single Sign-on is
installed locally, it recognizes streamed applications, even when launched in isolation
environments, and manages logons as expected.
For Microsoft Internet Explorer, however, the Single Sign-on feature must install a file
called BHO.dll. To allow this, when creating your application profile for Internet Explorer
plug-ins, select the option to Enable User Updates (formerly called Relaxed security),
which is deselected by default.
By enabling user updates for Internet Explorer, the application can download
vendor-supplied updates over the Internet. These updates are stored within the user profile
and are unique to that user. The next time the user device connects to the profiled Internet
Explorer on a server or file share, the streamed application does not overwrite the updates,
and Internet Explorer runs using the updates. Also with this setting, installers can run inside
isolation, where they are able to install new add-ons or software updates to Internet
Explorer. Local add-ons are compatible with Internet Explorer if you profile it with the
default isolation rule of Isolate. Local add-ons might not install correctly if you change the
isolation rule for the Internet Explorer profile to Strictly Isolate.
659
Creating Application Profiles
A profile is an application packaged for streaming using the Citrix Streaming Profiler. A
profile can contain a single application or suite of applications. For example, you can
profile Microsoft Word by itself or profile the entire Microsoft Office suite in a single
profile, or you can profile applications separately and link them with inter-isolation
communication. To create profiles, you must install the Streaming Profiler on a clean,
independent computer, called the profiler workstation. The profiling wizard records the
installation of applications and the metadata needed to stream the profiled applications.
The profiler bundles files and configuration settings in what becomes the application
profile.
Individual targets within a profile represent one or more defined user environments. The
initial target matches the environment of the profiling workstation; however, you can
create multiple targets to match specific user environments. For example, some
commercial applications are capable of running on multiple operating systems and
languages, while others, such as custom applications, might be capable of running only on a
particular target operating system and language.
Important: Applications compiled as 64-bit applications are not supported for streaming.
However, 32-bit applications can be profiled on 64-bit systems and configured to be
streamed to 64-bit systems.
Depending on the environment of your users, you have the option to profile prerequisites,
such as Java Runtime Environment, with the profiled application. In some cases, you might
find it necessary to profile certain applications together to ensure functionality among
applications or to apply a range of compatibility settings to ensure profiled applications
launch and run successfully. In addition, you can use the profiler to link existing profiles
using inter-isolation communication so that applications interact as needed, even though
they are running in isolation environments.
After you create a profile and save it to a file share in your App Hub, configure users and
publish the application in the profile for streaming using the publishing wizard in the Citrix
AppCenter. When a user launches an application published to stream to the user device, the
Citrix Plug-in running on the user device automatically chooses the correct target that
matches the configuration of the user device.
For information on specific topics, refer to these documents on the Citrix Knowledge
Center:
660
●
Application Streaming FAQs for Administrators at
http://support.citrix.com/article/CTX118181
●
Enhancing Security in Application Streaming for Desktops at
http://support.citrix.com/article/CTX110304
●
Application Streaming Delivery and Profiling Best Practices for XenApp at
http://support.citrix.com/article/CTX118623
●
Additionally, select your product version of XenApp on the support Web site, click the
Technotes tab, and then click Application Streaming.
Creating Application Profiles
Note: The Streaming Profiler SDK offers a set of COM objects and .NET interfaces that
give Citrix customers, distributors, and partners a programmatic interface into the
profiler. For information, download the SDK and Readme from the Citrix Developer
Network Web site at http://community.citrix.com/.
661
Targets Overview
A target is a collection of disk files, registry data, and other information used to represent
an application isolation environment. In addition, each target denotes a combination of
operating system, service pack level, system drive letter, and language. Applications can be
profiled for each combination of these values to support separate targets; for example:
Microsoft Vista for all service packs, drive letter C, and English.
There can be multiple executables inside a target including multiple applications that
normally receive an entry on the Start menu. As an example, “Microsoft Office” is a profile
and “Microsoft Word” is an application inside that profile. A profile can support multiple
targets where the target is a separate installation of the profile-level software targeted for
execution on a specific version of the operating system or language. For example, create
one target for Windows Vista and another target for Windows Server 2008.
User devices select targets for execution based on the computer configuration you specify
while creating the target. By default, a target matches the operating system and
configuration of the profiling workstation, but you can select different operating systems as
well.
In addition, refer to information about the following selection criteria for creating targets:
●
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 empl