Академический Документы
Профессиональный Документы
Культура Документы
5
Apr 27, 20 16
Automated P2V
Known Issues
System Requirements
Plan
Migrate
Manage
Publish
Record
Sample Deployment with Single Sign-on and Secure Gateway (Single Hop)
St oreFront 3.0 - Delivers centralized customization and branding of your users' applications and desktop selection experience across
Receivers for Windows, Mac, and Linux (on desktops) and Receivers for Web, HTML5, and Chrome (on mobile devices). For more information,
see http://docs.citrix.com/en-us/storefront/3/sf-about-30.html.
HDX RealT ime Opt imizat ion Pack 1.8 - For Enterprise and Platinum editions of XenApp, offers clear, crisp high-definition video calls with
Microsoft Skype for Business and Lync. Users can seamlessly participate in audio-video or audio-only calls to and from other HDX RealTime
users and other standards-based video desktop and conference room systems. For more information, see http://docs.citrix.com/en-us/hdx-
optimization/1-8.html.
Direct or 7.6.300 - Includes fixes for issues in Version 7.6.200. For more information, see http://docs.citrix.com/en-us/xenapp-and-
xendesktop/7-6/xad-monitor-article/xad-monitor-director-wrapper.html.To download this component, visit
http://www.citrix.com/downloads/xenapp/product-software/xenapp-65-feature-pack-3-advanced-edition.html.
Provisioning Services 7.6 - For Enterprise and Platinum editions of XenApp. To download this component,
visit https://www.citrix.com/downloads/provisioning-services/product-software/provisioning-services-76.html.
AppDNA 7.6 - For Platinum edition of XenApp. To download this component, visit https://www.citrix.com/downloads/appdna/product-
software/appdna-76.html.
XenServer 6.5 Service Pack 1 - To download this component, visit https://www.citrix.com/downloads/xenserver/product-
software/xenserver-65.html.
Universal Print Server 7.6 - To download this component, visit http://www.citrix.com/downloads/xenapp/components/citrix-universal-
print-server-ups-76.html?_ga=1.134207245.285281709.1418855524.
Prof ile management 5.2.1 - To download this component, visit https://www.citrix.com/downloads/xenapp/components/xenapp-
component-updates-after-xenapp-6-5-feature-pack-2.html.
License Server 11.12.1 - To download this component, visit https://www.citrix.com/downloads/licensing/license-server/license-server-
version-11121-for-windows.html.
Citrix encourages you to migrate your deployment from XenApp 6.5 to XenApp 7.6. To find out more about this, see
http://www.citrix.com/products/xenapp/tech-info/upgrade.html.
To deliver VM hosted apps, download the XenApp 7.6 ISO file and Virtual Delivery Agent (VDA) packages from
http://www.citrix.com/downloads/xenapp.html.
From XenApp 6.5 Feature Pack 2 download page, you can download a zip file that contains features available for all license
editions and install each feature after unpacking the zip file. You can download features in the Enterprise and Platinum
Editions individually from the same XenApp download page.
Downloading features requires that you have a Citrix account associated with your license entitlement for XenApp 6.5. You
only see those features to which you are entitled according to your license. Features are made available to you on the
download page depending on the edition level of your entitlement: Platinum, Enterprise, or Advanced. If you do not have a
Citrix account that is associated with the license entitlement for XenApp 6.5, Citrix Customer Support can assist you.
Redesigned Citrix StoreFront unifies app and desktop access through a seamless user experience, whether on the
corporate network or remote through Citrix NetScaler Gateway.
Updated Citrix Receivers are so easy to install that users can do it themselves. Your users just enter their corporate email
address after installation to automatically configure Receiver.
In the event that your users can't install Receiver on their devices, Receiver for HT ML5 offers a clientless experience and
renders apps and desktops in a browser.
T he OpenGL Software Accelerator is a software rasterizer that provides an alternative to the Microsoft OpenGL rasterizer
that is included with Windows. You can use OpenGL software acceleration with applications where GPU hardware
acceleration is not needed or cannot be cost-justified but where the Microsoft OpenGL software rasterizer is inadequate.
OpenGL software acceleration provides faster rendering performance because it leverages SSE4.1 and AVX— and it
supports OpenGL 2.1, whereas the Microsoft OpenGL software rasterizer is limited to OpenGL 1.1.
HDX 3D with GPU sharing provides a cost-effective solution for power-user 3D viewers and editors:
Provision many users to share a GPU to cost effectively support users that view and edit 3D data and can adequately be
supported by sharing GPU resources (up to 12 GPUs per host)
Exceptional better than local user performance on a LAN
Very interactive user experience over low bandwidth networks with ~1.5 Mbps
Any device access including tablets and Macs with supported versions of Citrix Receiver
Citrix AppDNA accelerates the migration and transformation of desktop and web applications for new environments and
helps manage application change on a day-to-day basis. AppDNA provides automated analysis of applications for different
Windows platforms and suitability for application virtualization through App-V, XenApp, or XenDesktop. Using AppDNA, you
can model complex mixes of new technologies to determine the best plan of action and then automate the
transformations.
XenApp 6.5 Connect or (SP 1) f or Microsof t Syst em Cent er 2012 Configurat ion Manager
T he XenApp Connector for System Center 2012 Configuration Manager enables administrators to orchestrate the tasks
required to deliver applications both to end-users and XenApp Servers seamlessly with Microsoft System Center 2012 (and
SP1).
You can also find additional information in this informative blog: XenApp Connector for System Center 2012 Configuration
Manager Enterprise Setup Considerations.
Use the Mobile SDK for Windows Apps to create mobile-friendly applications hosted on XenApp with mobility features
enabled. With the Mobile SDK and XenApp 6.5 HRP02, your mobilized, touch-enabled applications leverage your existing
Citrix infrastructure while keeping sensitive corporate data secure in the data center and not cached on an easily lost,
misplaced, or stolen mobile device.
XenApp 6.5 HRP02 provides the server-side support for these new features. Once installed on your XenApp servers, they
automatically re-skin Windows applications for more intuitive, touch-friendly use on tablet devices. Tablet-optimized
desktops work with the currently available Receiver for iOS, Receiver for Android, and Receiver for Windows 8/RT.
Cit rix® HDX™ RealT ime Opt imizat ion Pack f or Microsof t ® Lync® 2010
Also available in this feature pack is the Cit rix® HDX™ RealT ime Opt imizat ion Pack 1.4 for Microsoft® Lync® 2010. T his
release of the Optimization Pack provides support for the Meet Now feature of Microsoft® Lync®.
Cit rix® HDX™ RealT ime Opt imizat ion Pack for Microsoft® Lync® offers highly scalable video conferencing and clear,
crisp high-definition audio-video calls in conjunction with Microsoft Lync. Users can seamlessly participate in audio-video or
audio-only calls to and from other HDX RealT ime users and other standards-based video desktop and conference room
systems.
Seamless local app integration enables you to include access to locally installed applications as well as XenApp hosted
applications within a hosted desktop environment. Your users can access in one place local applications that would
otherwise be costly or time-consuming to host or applications that must be accessed in a highly secure manner.
When one of your users logs onto a hosted desktop, it displays shortcuts to locally installed applications and XenApp
hosted applications. When one of your users launches a locally-installed application, it runs on your user's workstation but
appears to your user to run on the hosted desktop. Likewise, when one of your users launches a XenApp hosted
application, it runs from a XenApp environment but appears to your user on the hosted desktop.
With Local App Access, you can bring users onboard more quickly and they can continue using the applications on which
their productivity depends alongside their own hosted applications.
If the performance of OpenGL applications running in virtual machines on XenServer or other hypervisors is an issue, try
using OpenGL Accelerator. For some applications, the OpenGL Accelerator outperforms the Microsoft OpenGL software
rasterizer that is included with Windows because the OpenGL Accelerator leverages SSE4.1 and AVX. OpenGL
Accelerator also supports applications using OpenGL versions up to 2.1.
For applications running on a workstation, first try the default version of OpenGL support provided by the workstation's
graphics adapter. If the graphics card is the latest version, in most cases it will deliver the best performance. If the
graphics card is an old version or does not delivery satisfactory performance, then try the OpenGL Accelerator.
3D OpenGL applications that are not adequately delivered using CPU-based software rasterization may benefit from
OpenGL GPU hardware acceleration. T his feature can be used on bare metal or virtual machines. For more information,
see About OpenGL GPU Sharing.
On 64-bit systems:
Now you can delete and rename files. You may want to deactivate the administrator account. You do not need it for your
daily purposes.
HDX 3D Pro allows graphics-heavy applications to render on the server's GPU. By moving OpenGL rendering to the server's
GPU, the server's central processing unit (CPU) is not slowed by graphics rendering. In addition, the server is able to process
more graphics because the workload is split between the CPU and GPU. T he OpenGL GPU Sharing feature requires no
special settings.
You can install multiple GPUs on a server, either by installing a graphics card with more than one GPU, or by installing multiple
graphics cards with one or more GPUs each. Mixing heterogeneous graphics cards on the server is not recommended.
Note: Virtual machines require direct passthrough access to a GPU, which is available with Citrix XenServer or VMware
vSphere. When HDX 3D Pro is used in conjunction with GPU passthrough, each GPU in the server supports one multi-user
virtual machine.
Most users do not require the rendering performance of a dedicated GPU, so OpenGL GPU Sharing enables multiple
concurrent sessions to share GPU resources. T his functionality does not depend any specific graphics card. When running on
a hypervisor, select a hardware platform and graphics cards that are compatible with your hypervisor's GPU passthrough
implementation. T he list of hardware that has passed certification testing with XenServer GPU Passthrough is available at
http://hcl.vmd.citrix.com/GPUPass-throughDeviceList.aspx. When running on bare metal, the system distributes the user
sessions across eligible GPUs. To guarantee that all installed GPUs are eligible, use identical GPUs.
Scalability using OpenGL GPU Sharing depends on the applications being run, the amount of video RAM they consume, and
the graphics card's processing power. For example, scalability figures in the range of 8-10 users have been reported on
NVIDIA Q6000 and M2070Q cards running applications such as ESRI ArcGIS. T hese cards offer 6 GB of video RAM. Newer
NVIDIA GRID cards offer 8 GB of video RAM and significantly higher processing power (more CUDA cores). Other
applications may scale much higher, achieving 32 concurrent users on a high-end GPU.
Note: Some applications handle video RAM shortages better than others. If the hardware becomes extremely overloaded,
this could cause instability or a crash of the graphics card driver. Limit the number of concurrent users to avoid such issues.
To confirm that GPU acceleration is occurring, use a third-party tool such as GPU-Z. GPU-Z is available at
http://www.techpowerup.com/gpuz/.
You can download the OpenGL GPU sharing feature from XenApp 6.5 Feature Pack 2 download page. T his feature is
available in a zip file that contains all the features available for all license editions of XenApp 6.5 Feature Pack 2.
Viewing and downloading features on the download pages require that you have a Citrix account associated with your
license entitlement for XenApp 6.5. You only see those features to which you are entitled according to your license.
Features are made available to you on the download page depending on the edition level of your entitlement: Platinum,
Enterprise, or Advanced. If you do not have a Citrix account that is associated with the license entitlement for XenApp 6.5,
Citrix Customer Support can assist you.
T his release provides full support for GPU sharing among OpenCL applications running in a user 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.
OpenCL support is disabled by default, but you can enable it by editing the following registry settings:
T his release also provides experimental support for GPU sharing among CUDA applications running in a user session. T his
support is disabled by default, but you can enable it for testing and evaluation purposes.
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.
To use the experimental CUDA acceleration features, enable the following Registry settings:
T here are many things to consider when planning a XenApp application deployment – many of which relate to the
applications themselves. For example:
1. Is the application suitable for running with multiple simultaneous users in separate sessions?
2. Which versions of Windows (server and desktop) is the application compatible with?
3. Is the application suitable for running in a 64-bit server environment?
4. Is the application suitable for virtualization with App-V?
T he answers to these questions will help you determine whether an application is a potential candidate for server-side
application virtualization or whether it is more suitable for client-side application virtualization or hosting on a desktop OS
virtual machine. AppDNA can help you quickly answer these and similar questions.
AppDNA performs an automated static analysis of an application's "DNA" to assess compatibility with a variety of
platforms, including new versions of Windows (for desktop and server), and suitability for shared server-based deployment
with XenApp, and for application virtualization with App-V. When AppDNA detects potential application issues on a
particular platform, where appropriate it provides detailed information about steps that you can take to resolve the issue.
AppDNA is a separate product from XenApp. However, if you have a XenApp Platinum license, you are automatically
entitled to download and install AppDNA and use Server-Based Computing (SBC). SBC provides an answer to the first
question (Is the application suitable for running with multiple simultaneous users in separate sessions?).
Upgrading to a full Standard or Enterprise AppDNA license is easy and you would then be able to also take advantage of
validating your applications against the other platforms that AppDNA supports. For example, if you upgrade to the
Standard edition AppDNA could also provide answers to the second and third questions. If you upgrade to the Enterprise
edition, AppDNA could provide answers to all of the questions. You would then be in a position to plan your XenApp
application deployment. You could use Forward Path to model the various deployment scenarios and determine the best
course of action for each application and, where relevant, automate the packaging (for example, sequencing for App-V).
If you do not have a Platinum license, you may want to consider purchasing AppDNA, so that you can also take advantage
of the AppDNA features for accelerating application deployment through XenApp. You can download a trial version from:
http://store.citrix.com/AppDNAPDTrial.
XenApp Connector provides a bridge between Microsoft System Center Configuration Manager and XenApp, extending the
deployment capabilities of Configuration Manager to enable the delivery of any application, to any user, on virtually any
device.
In addition to the documentation provided in this section of eDocs, be sure to also refer to our XenApp Connector blog
and forum.
T he following diagram and table provide an overview of XenApp Connector usage with Configuration Manager.
2 XenApp Connector optionally uses an active/passive model for high availability: Only one XenApp Connector service
operates at a time per XenApp farm, thus minimizing resource usage while ensuring operation continuity.
XenApp Connector optionally uses the XenApp Power and Capacity Management Concentrator to manage the
power states and load consolidation of XenApp servers when installing Configuration Manager applications or
Windows Software Update Management (SUM) updates, with minimal disruption to user sessions.
3 XenApp Connector orchestrates software installation to XenApp servers, farms, and worker groups using:
MSI-based applications
Microsoft Application Virtualization (App-V) stream-to-server applications
Applications that are part of the XenApp server disk image in the XenApp farm
4 XenApp Connector coordinates application installation, operating system updates, and application updates to
XenApp servers that are manually managed or those that are managed by Citrix Provisioning Services.
XenApp Connector fully integrates with Provisioning Services, allowing you to publish applications that are deployed
to a base vDisk for a XenApp image.
5 XenApp Connector enables you to use the Configuration Manager console to publish XenApp hosted applications
to Citrix Receiver or StoreFront.
6 Users of devices managed by Configuration Manager access XenApp hosted applications from Citrix Receiver and
the Configuration Manager Application Catalog. Policy rules determine whether those managed devices launch
either locally installed applications or Receiver-based applications.
7 Users of unmanaged devices, such as mobile devices and Macs, access applications managed by Configuration
Manager from web sites created in Citrix StoreFront or Citrix Web Interface. An unmanaged device is not managed
by Configuration Manager.
Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page.
Viewing and downloading features on the download pages require that you have a Citrix account associated with your
license entitlement for XenApp 6.5. You only see those features to which you are entitled according to your license.
Features are made available to you on the download page depending on the edition level of your entitlement: Platinum,
Enterprise, or Advanced. If you do not have a Citrix account that is associated with the license entitlement for XenApp 6.5,
Citrix Customer Support can assist you.
XenApp 6.5 Connector (SP2) for Configuration Manager (XenApp Connector) provides the following enhancements:
Support f or Syst em Cent er 2012 R2 Conf igurat ion Manager — You can now deploy XenApp Connector in a
System Center 2012 R2 Configuration Manager environment. Click the link below for details about upgrading from
XenApp 6.5 Connector or XenApp 6.5 Connector (SP1) to this SP2 release.
Support f or St oreF ront 2.1 aggregat ed resources — If your Citrix deployment includes StoreFront 2.1 and is
configured to publish applications from multiple XenApp farms in a single store, Receiver users are presented with an
aggregated list of resources.
Support for the feature is built-in to XenApp 6.5 Connector (SP2) and requires no additional configuration. However,
make sure that each instance of a published application has the same display name in Configuration Manager. Click the
link below for more information about StoreFront resource aggregation.
Cust omer Experience Improvement P rogram — Would you like to help us improve XenApp Connector based on
how you use it? T he XenApp Connector Configuration wizard now allows you to opt in or out of our Customer
Experience Improvement Program. All data collected is 100% anonymous and you can change your participation choice
at any time. We will use the aggregated data about XenApp Connector installation and usage to plan future
enhancements.
XenApp 6.5 Connector (SP2) replaces the SP1 release and includes all features from that release:
Assist ed set up of a Conf igurat ion Manager Maint enance Window — T he XenApp Connector Configuration
wizard now makes it easier to choose the optimum maintenance window for proof-of-concept or production
environments:
Follow the on-screen instructions to choose the setting appropriate for your environment.
After first-time use of the Configuration wizard, run it again to view all maintenance windows for the farm.
If you create a custom maintenance window in the Configuration wizard, use the Configuration Manager console for
future changes.
Support f or t he lat est component s — T his release of XenApp Connector includes support for XenApp 6.5 Feature
Pack 2 for Windows Server 2012 R2, Receiver for Windows 4.0, and App-V Client for Remote Desktop Services, version
5.0, SP1 and SP2.
Simplif ied upgrades — T he installer removes the previous version of XenApp Connector for Configuration Manager
2012. Your existing configuration, except for a maintenance window defined in XenApp Connector, is retained.
To work around this issue, reinstall the Configuration Manager console extension, delete the XenApp deployment types,
and then uninstall the console extension.
If you use the XenApp PCM feature, refer to Install and set up components for Power and Capacity Management for
related system requirements.
Any of the following XenApp releases running on Windows Server 2008 Enterprise R2, 64-bit edition, SP1:
Important: Device requirements differ for managed and unmanaged devices. A managed device is defined as a device with
the Configuration Manager client agent installed. A managed device must be enabled for software distribution. Managed
devices do not include Windows Workgroup computers because Configuration Manager cannot deploy applications
targeted to user collections on those devices.
An unmanaged device is a device without the Configuration Manager client agent installed.
Authentication requirements
Receiver must be configured for single sign-on, which requires the following configuration of user devices and the
StoreFront server (version 2.1 or 2.0):
T he user must be a domain user (not a local machine user).
T he user device must be on the same Active Directory domain as the Storefront stores.
Pass-through authentication must be configured on the Storefront server.
T he StoreFront server URL must be in the Internet Explorer T rusted Zone.
If the store service uses HT T PS, the certificate and trust chain must be correctly configured for the server being used.
XenApp Connector service is the bridge between a XenApp farm and Configuration Manager and performs the following
tasks:
T he XenApp Connector publishing task processes publishing items that are linked to a XenApp deployment type. Items
published to a XenApp device collection appear under the Applications\ConfigMgr12 folder in the XenApp AppCenter
console.
By default, the Publishing task runs every hour. Use the XenApp Connector Configuration wizard to change the publishing
interval. Use the Start menu shortcut (Run Publishing Task) to manually run the task.
T he Connector ensures that applications are not published until all the required XenApp workers have the application
High availabilit y
T he XenApp Connector high availability feature provides a reliable fault tolerance mechanism to ensure service continuity
during disruptions in infrastructure components such as software, hardware, network, and power. To take advantage of
this feature, just install and configure the connector service on multiple servers.
Only one instance of the connector service operates regularly while the other service(s) remain idle as backups. If the
active connector service becomes inoperable, another instance is automatically designated as the active one and takes
over the load. Active instance and related information are stored in the Configuration Manager database for persistence
and are retained during a XenApp Connector upgrade.
T he Configuration Manager console extension enables the Configuration Manager console to work seamlessly with
XenApp. Installing the console extension adds these items to the Configuration Manager console:
A Citrix XenApp Farms node under Assets and Compliance > Device Collections. After synchronizing data from a XenApp
farm, XenApp Connector updates the Citrix XenApp Farms node with all XenApp farms, servers, and worker groups.
Device Collections > Citrix XenApp Farms > farms
Device Collections > Citrix XenApp Farms > farms > Worker Groups > groups
Citrix recommends that you do not delete XenApp farm device collections and that you edit them only if you need to
change a custom maintenance window specified in the XenApp Connector Configuration wizard.
A XenApp Publications folder under Software Library > Application Management. Items in this folder are published to
XenApp. Do not edit or delete the XenApp Publications folder. XenApp Connector requires it.
A Citrix XenApp Client Settings item in Administration > Client Settings, with a Computer Agent setting, Additional
software manages the deployment of applications and software updates, enabled. T hat setting enables the
Configuration Manager idle policy feature.
A Citrix XenApp entry in the T ype drop-down menu in all Configuration Manager console pages where deployment types
are selected, such as in the Create Deployment T ype wizard.
T he XenApp Agent service runs on each server in a XenApp farm. It coordinates application and software installation and
updates by using the following components:
Citrix Provisioning Services. PVS allows computers to be provisioned and re-provisioned in real-time from a single shared-
disk image. T he XenApp Agent service running on a production XenApp vDisk image detects when a new vDisk image is
In preparation for this, the XenApp Agent service orchestrates draining the XenApp workers servers and notifying users
before the next maintenance window to ensure that no users are logged in when the software is being installed. Users
are forcibly logged off if the deployment deadline has passed.
T he XenApp deployment type handler ensures that XepApp delivered applications appear and operate like locally installed
applications on devices managed by Configuration Manager. T hat is, XenApp delivered applications have application icons
on the Start menu and Windows desktop. T he XenApp deployment type handler must be installed on all managed devices.
T he XenApp deployment type handler detects and manages publications associated with an application configured with a
XenApp deployment type. T he handler works with the Configuration Manager client agent to determine whether an
application needs to be installed on a managed device and whether to launch that managed application or a Receiver
version of the application.
Computer group policies configure how the XenApp Agent service handles items such as advanced warning messages,
forced logoff messages, XenApp Agent service maintenance frequency, and Provisioning Services integration. For more
information, see Connector for Configuration Manager Policy Settings.
T he XenApp Agent service running on a production XenApp vDisk image detects when a new vDisk image is available and
delivers the new image during the next maintenance window. T he PVS agent is required only for shared images and must be
installed on the master vDisk image.
T he PCM Concentrator and Agent is used only if you automate server maintenance with the XenApp PCM feature. XenApp
Connector can use PCM to manage the power states and load consolidation of XenApp servers when installing
Configuration Manager applications or Windows Software Update Management (SUM) updates, with minimal disruption to
user sessions. For more information, refer to Deploy SUM updates to XenApp servers.
T he PCM Concentrator monitors and manages the XenApp servers in the PCM farm and interacts with the PCM Agent
running on each XenApp server to get and set the PCM tier and PCM control mode.
T he PCM Agent registers host XenApp servers with the PCM Concentrator and acts on requests issued by the PCM
Concentrator.
For users of unmanaged devices, such as mobile devices and Macs, users access applications deployed to user collections by
navigating in a Web browser to Receiver for Web sites or Web Interface XenApp Services sites. T hose sites display
applications managed by Configuration Manager, including applications deployed with the XenApp deployment type.
A proof of concept deployment includes only one XenApp Connector service machine, configured to point to one XenApp
host. Accepting the defaults during installation results in a proof of concept deployment.
1. A Configuration Manager site manages the servers of a XenApp farm and other devices.
T he Configuration Manager client is required on all workers in the farm.
2. T he XenApp Connector service communicates with the Configuration Manager SMS Provider.
3. T he XenApp Connector service communicates with a XenApp host, which must be a Controller and not a worker
machine.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, the XenApp Connector service communicates with the PCM Concentrator.
5. If you use PCM, the PCM Concentrator communicates with the XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
A high availability deployment includes multiple XenApp Connector service machines. If a XenApp Connector service stops
working for any reason, such as an infrastructure disruption, another XenApp Connector service automatically takes its
place. Only one instance of the XenApp Connector service operates regularly. T he others remain idle as backups.
Adding XenApp Connector service machines does not increase capacity, so a high availability deployment is recommended
regardless of the size of your operation.
2. Any number of XenApp Connector services can point to the Configuration Manager SMS Provider.
Different XenApp Connector services can point to different SMS Providers per Configuration Manager Site to
improve fault tolerance by avoiding a single point of failure on the Configuration Manager side.
T he Configuration Manager Site database is also used to store the High Availability table, which contains information
about which XenApp Connector service is currently the active one for a given farm.
3. XenApp Connector services communicate with one or more XenApp hosts, which must be Controllers and not worker
machines.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, the XenApp Connector services communicate with the PCM Concentrator.
T he XenApp Connector service supports operating against a single PCM Concentrator per PCM site.
5. If you use PCM, the PCM Concentrator communicates with the XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
T he simplest way to use XenApp Connector to manage multiple XenApp farms is to set up one or more XenApp Connector
service machines for each XenApp farm.
Configure each XenApp Connector service independently as if the XenApp farm it points to is the only farm in the
enterprise. XenApp Connector automatically handles the existence of the other farms and operates without conflict.
2. Any number of XenApp Connector services can point to the Configuration Manager SMS Provider.
Different XenApp Connector services can point to different SMS Providers per Configuration Manager Site to
improve fault tolerance by avoiding a single point of failure on the Configuration Manager side.
T he Configuration Manager Site database is also used to store the High Availability table, which contains information
about which XenApp Connector service is currently the active one for a given farm.
3. XenApp Connector services communicate with the XenApp hosts, which must be Controllers and not worker machines.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, set up a dedicated PCM Site per XenApp farm.
T he XenApp Connector service supports operating against a single PCM Concentrator per PCM site.
5. If you use PCM, each PCM Concentrator communicates with a XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
T he following diagram shows a typical deployment of XenApp Connector service machines in a large multi-geography site
hierarchy that uses a Configuration Manager Central Administration Site (CAS) with three Primary Sites (Americas, Europe,
and Asia).
When planning the deployment of the XenApp Connector within a given Configuration Manager topology:
In this deployment, install the XenApp Connector console extension and service as follows:
On machines, such as the CAS server, where the Configuration Manager console is installed and used to manage the
hierarchy, install only the XenApp Connector console extension (and not the XenApp Connector service).
On machines where you install the XenApp Connector service, there is no need to install the XenApp Connector console
extension.
Secondary sites, not shown in the diagram, are managed by their parent Primary Site and therefore by the XenApp
Connector service(s) on or pointing to their respective Primary Site. Do not install XenApp Connector on Secondary Site
machines, as it would serve no purpose.
In addition to considering the optimum maintenance window for your users, be aware that you can specify how users are
notified about maintenance through several group policies. T he policies include how far in advance of maintenance or a
software update that the user is first notified, the interval between subsequent notifications, and the message title and
text. For forced logoff situations, the policies include the grace period between a notification about a forced logoff and
that action, as well as the message title and text.
For a description of all group policies related to XenApp Connector, seeConnector for Configuration Manager Policy
Settings
If those steps are successful, your environment is ready for XenApp Connector.
Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page. T he package name is
XA6.5_Connector_SP2_for_SCCM2012.exe.
Viewing and downloading features on the download pages require that you have a Citrix account associated with your
license entitlement for XenApp 6.5. You only see those features to which you are entitled according to your license.
Features are made available to you on the download page depending on the edition level of your entitlement: Platinum,
Enterprise, or Advanced. If you do not have a Citrix account that is associated with the license entitlement for XenApp 6.5,
Citrix Customer Support can assist you.
Configure Receiver to use pass-through authentication on user devices. (Pass-through authentication is also referred
to as single sign-on authentication.)
For information, refer to the /includeSSON command-line parameter description in the Receiver for Windows
documentation in Citrix eDocs.
Install Receiver per-machine and in the all users mode on all machines.
Install the XenApp deployment type handler on each managed device that has Receiver for Windows installed. T he handler
is an MSI that you can install manually, with a script, or using Configuration Manager.
After you extract the installation package, the XenApp deployment type handler is in Client
Components/XenAppDT Handler_x64[86].msi.
Important: After you have tested a proof-of-concept installation, Citrix recommends that you use Configuration Manager
to deploy this component. For information about deploying MSI applications, refer to Deploy MSI and App-V applications
to XenApp servers.
To verify installation, search for the component in Programs and Features.
Important: After you have tested a proof-of-concept installation, Citrix recommends that you use Configuration
Manager to deploy these components to other XenApp servers. For information about deploying MSI applications, refer
to Deploy MSI and App-V applications to XenApp servers.
To verify installation, search for the component in Programs and Features.
2. Group P olicy hot f ix. On the XenApp server where the Group Policy Management Console is installed, install XenApp
Server Components/XenApp Group Policy Settings.../CitrixGroupPolicyManagement_x64[86].msi.
To verify installation, search for the Connector for Configuration Manager section in the Group Policy Management
Console.
Before you install XenApp Connector, prepare your environment as follows. For supported platforms, refer to System
requirements.
1. Identify the computers in your XenApp Connector installation:
1. Decide where to install the XenApp Connector service. T he component is not supported on servers where XenApp is
installed. You can install it on its own dedicated VM or on the Configuration Manager Site Server.
For environments with multiple XenApp farms, install XenApp Connector on a dedicated VM in each farm and point it
to a controller in the farm. You can then configure each XenApp Connector with the same SMS Provider.
Install the XenApp PowerShell host on the same server as the XenApp Connector service. T he XenApp Connector
service uses the XenApp PowerShell SDK to manage XenApp servers and gather farm data. Ensure this computer is
not managed by Power and Capacity Management.
2. Identify where to install the Configuration Manager console extension. You must install it on a server or workstation
that has the Microsoft System Center 2012 Configuration Manager console installed. You can install the console
extension on the same server as the XenApp Connector service.
2. Enable the XenApp Connector service to communicate with the XenApp PowerShell host and the SMS Provider for the
Configuration Manager site:
1. Determine which port to use as the remote PowerShell port and whether to use an SSL connection.
2. Open the port on the firewalls or routers used by these servers.
3. In the policies of the computer on which you will install the XenApp Connector service, ensure that the Do not allow
storage of passwords and credentials for network authentication option is disabled.
4. Create the XenApp service account (the account that will run the XenApp Connector service) and configure it as follows:
Citrix Full Administrator
Application Administrator on the Configuration Manager 2012 site
Local Administrator on each of the following:
XenApp PowerShell host
SMS Provider for the Configuration Manager 2012 site
In the XenApp farm Administrators node
For information about using AppCenter to add an administrator, refer to "Managing Citrix Administrators" in the
XenApp documentation.
Has "Log on as a service" rights on the computer on which the XenApp Data Connector is installed
Has rights to log on as batch job on the computer on which the XenApp Connector service will be installed.
5. Determine the security role to use for the XenApp Connector administrative user. You can use the Configuration
Manager built-in roles of Full Administrator or Application Administrator, or you can configure a security role in
Configuration Manager with the following permissions:
Application (all permissions)
Client Agent Setting (all permissions)
Configuration Item (all permissions)
Distribution Point (all permissions)
For a small proof-of-concept deployment you can install the XenApp Connector service and the XenApp Connector console
extension on the same Configuration Manager host. To install the console extension on a different server, refer to Install
the XenApp Connector console extension on a different server.
1. On the server on which you want to install the XenApp Connector service, if Configuration Manager is installed, close it.
2. Run the XenApp Connector installer: XA6.5_Connector_SP2_for_SCCM2012.exe.
3. Follow the instructions in the installation wizard.
If the Configuration Manager server where you are installing the XenApp Connector service has the Configuration
Manager console installed, the Configuration Manager Console Extension check box is selected by default. T o install
the console extension on a different Configuration Manager server, clear the check box.
If Launch Configuration when Setup exits is selected on the last screen of the installation wizard, the Configuration
wizard starts when the installation is complete.
If you choose not to run the Configuration wizard now, you can do so later by using the Config Wizard shortcut on
the Start menu or desktop.
Installing the XenApp Connector registers the XenApp deployment type with Configuration Manager 2012, creates the
client agent setting required for idle policy configuration, and installs and starts the XenApp Connector Configuration
wizard.
By default, the console extension installs on the same server as the XenApp Connector service if the server also has the
Configuration Manager console installed. You can install it on different servers or workstations that have the Microsoft
System Center 2012 Configuration Manager console installed.
Credentials for the XenApp Connector service account used to run XenApp Connector service.
T he fully-qualified domain name (FQDN) for the XenApp Controller. T he FQDN must include all three levels
(hostname.subdomain.domain).
Whether to create a maintenance window for the XenApp servers and, if so, the desired start time, end time, and
frequency of that window.
Use the on-screen instructions in the Configuration wizard for guidance as you follow these steps.
1. On the Configuration Manager Site page, specify the site information and then click Next.
2. On the Software Installation Maintenance Window page, select a maintenance window option.
Note: T he following options appear the first-time you run the Configuration wizard. After that, if there is at least one
maintenance window defined, this page displays (for the farm) all maintenance windows created by this Configuration
wizard and the Configuration Manager console.
Creat e a 24 x7 ... — T his option is not recommended for production environments: Software deployment starts
immediately, which can instantly cause down time for users.
Creat e a cust om... — T his option is recommended for production environments. T o change the deployment
schedule later, use the Configuration Manager console.
I will creat e my own... — If you choose this option, be aware that software deployment starts immediately unless
a deployment schedule is already specified in the Configuration Manager console.
3. Complete the remaining Configuration wizard pages. When prompted, choose whether to participate in our Customer
Experience Improvement Program.
4. Review the information on the Settings Summary page.
5. T o edit the following settings, click Advanced Settings.
XenApp farm sync interval – how often the XenApp Connector updates the Configuration Manager database with
new, changed, or removed XenApp farm servers and worker groups
XenApp publication interval – how often the XenApp Connector checks the Configuration Manager database for
new or updated publication information
XenApp power-on interval – how long in advance off-line servers are powered on to receive software updates
P re-requisit es
Open the ports on the firewalls or routers used by the servers running the XenApp Connector service and PCM.
On the server running the PCM Concentrator, make the XenApp service account a Local Administrator.
1. Citrix recommends that you document your current PCM server configuration before enabling XenApp Connector to
modify it.
2. Install PowerShell and enable PowerShell remoting on the servers you plan to use for the following:
XenApp Connector service
SMS Provider for the Configuration Manager site
Power and Capacity Management Concentrator
To enable PowerShell remoting:
I am upgrading or plan to re-install. T his option removes the Program Files > Citrix > XenApp Connector for ConfigMgr
2012 folder and the following components from the Configuration Manager console:
T he XenApp deployment type option as well as Citrix XenApp from the table in the Applications > Deployment T ypes
tab
Application Management > XenApp Publications
I want to uninstall permanently. T he items mentioned above plus the components listed in the Cleanup to perform area.
Let me make selections manually. T his option enables you to choose the components to remove.
Log files and items in the Configuration Manager database are not removed.
To see the results of the uninstall, start the Configuration Manager console.
Important: We recommend that you upgrade the XenApp Connector components before you upgrade to System Center
2012 R2 Configuration Manager.
T his upgrade uninstalls the previous version, installs XenApp 6.5 Connector (SP2), and then runs the Configuration wizard.
We recommend that you perform these steps in the order presented to ensure a successful upgrade.
1. Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page and extract the files.
2. If Configuration Manager is installed on the server on which you want to install the XenApp Connector service, close the
service.
3. On all XenApp servers hosting published applications:
1. Install the XenApp Agent service: XenApp Server Components/XenAppAgent_x64.msi.
2. Install the XenApp deployment type handler: XenApp Server Components/XenAppDT Handler_x64.msi.
If you are using XenApp Connector to deploy XenApp applications only to users running PVS-based shared images, install
those two components on the PVS master vDisk image instead.
4. Run the XenApp 6.5 Connector (SP2) installer: XA6.5_Connector_SP2_for_SCCM2012.exe.
5. Follow the instructions in the installation wizard.
If the Configuration Manager server where you are installing the XenApp Connector service has the Configuration
Manager console installed, the Configuration Manager Console Extension check box is selected by default. T o install
the console extension on a different Configuration Manager server, clear the check box.
If Launch Configuration when Setup exits is selected on the last screen of the installation wizard, the Configuration
wizard starts when the installation is complete.
If you choose not to run the Configuration wizard now, you can do so later by using the Config Wizard shortcut on
the Start menu or desktop.
T he Receiver installer is available from the Citrix downloads site. Be sure to:
Configure Receiver to use pass-through authentication on user devices. For information, refer to information about
the /includeSSON command-line parameter in the Receiver for Windows documentation in Citrix eDocs.
Install Receiver per-machine and in the all users mode on all machines.
To verify that your upgraded environment is working correctly, perform the following steps after you upgrade XenApp
Connector components and again after you upgrade to System Center 2012 R2 Configuration Manager.
If your deployment includes PVS vDisk images or SUM updates, you will follow a different set of steps. For information
about deploying applications and software updates, refer to the following sections:
Important: T he procedures in this section highlight XenApp-specific settings. For detailed information about using the
Configuration Manager console, refer to the Microsoft Documentation Library for System Center 2012 Configuration
Manager.
App-V stream-to-server applications are not physically installed by this procedure. T he XenApp Agent service running on the
XenApp server detects the pending application deployment and interacts with Configuration Manager to deploy the virtual
application by creating a shortcut for it and registering the App-V package on the system.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
5. On the Scheduling page, use the default (as soon as possible) for a proof-of-concept deployment or for XenApp
Controller components. Otherwise, specify a schedule.
6. Follow the on-screen instructions to complete the wizard.
3. Force the application to install on the XenApp farm.
At this point, the application you created has the deployment type that specifies how to install the application. You will
later add to the application a XenApp deployment type, used to publish the application to devices. You must configure
the application so that the deployment type that installs the application is used to deploy it to XenApp servers.
1. In the Deployment T ypes tab, right-click the application you added in Step 1 and choose Properties.
2. In the Properties window, on the Requirements tab, click Add.
3. In the Create Requirement dialog box: From Category, choose Custom.
4. From Condition, choose Citrix XenApp Server Version.
5. From the Rule type drop-down menu, choose Existential.
6. Keep the default setting T he selected global condition must exist on client devices. T hat setting indicates that the
device must be a XenApp server.
App-V stream-to-server applications are not physically installed by this procedure. T he XenApp Agent service running on the
XenApp server detects the pending application deployment and interacts with Configuration Manager to deploy the virtual
application by creating a shortcut for it and registering the App-V package on the system.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
1. Create the application and define the Script Installer deployment type:
1. In the Configuration Manager console, expand Software Library> Application Management and then click
Applications.
2. On the Home tab, click Create Application. T he Create Application Wizard opens.
3. On the General page, click Manually specify the application information and then click Next.
4. Specify a Name. You will need to enter this same name in the next step. Also specify any other information you
require on the General Information and the Application Catalog pages.
5. On the Deployment T ypes page, click Add and then create the Script Installer deployment type with these settings:
Set T ype to Script Installer, click Next, and enter the same Name you entered in step d.
On the Content page, leave the Content location blank.
On the Content page, in Installation program, enter a non-existing filename, such as dummy.exe.
T he application is already installed, so this method prevents an installation.
On the Detection Method page, click Add Clause and then locate the file for the already installed application.
On the User Experience page, set Installation behavior to Install for system and set Logon requirement to Whether
or not a user is logged on.
2. T o deploy the application to a XenApp device collection:
1. In the Applications list, click the application name and then click Home > Deploy.
2. On the General page, across from Collection, click Browse, choose Device Collections, and then select a XenApp
server.
3. On the Deployment Settings page, from the Purpose list, choose Required so that the application will be pushed as a
mandatory deployment.
4. On the Scheduling page, a proof-of-concept deployment would typically use the default (as soon as possible).
Otherwise, specify a schedule.
5. Follow the on-screen instructions to complete the wizard.
3. Force the application to install on the XenApp farm.
At this point, the application you created has the deployment type that specifies how to install the application. You will
later add to the application a XenApp deployment type, used to publish the application to devices. You must configure
the application so that the deployment type that installs the application is used to deploy it to XenApp servers.
1. In the Deployment T ypes tab, right-click the application you added in Step 1 and choose Properties.
2. In the Properties window, on the Requirements tab, click Add.
3. In the Create Requirement dialog box: From Category, choose Custom.
4. From Condition, choose Citrix XenApp Server Version.
5. From the Rule type drop-down menu, choose Existential.
For information about Provisioning Services, refer to “Automating vDisk Updates” in the Provisioning Services
documentation in Citrix eDocs.
1. Prepare a PVS master vDisk image as described in Enable integration with Citrix Provisioning Server.
2. If the application is not already created in Configuration Manager, add it as described in Deploy MSI and App-V
applications to XenApp servers.
3. Create a XenApp deployment type for the application:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard.
T he XenApp deployment type you added appears in the Deployment Types tab.
4. Deploy the applications to a XenApp device collection that includes only the master vDisk image. Updates and
applications will be published to the VM in that collection and will automatically be applied to any new or existing clones
of the PVS vDisk. T he master vDisk image will update according to the schedule configured in the vDisk Update
Management settings.
1. In the Applications list, click the application name and then click Home > Deploy.
2. On the General page, across from Collection, click Browse, choose Device Collections, and then select a XenApp
server.
3. On the Content page, click Add, choose Distribution Point, and select a distribution point.
4. On the Deployment Settings page, from the Purpose list, choose Required so that the application will be pushed as a
mandatory deployment.
5. On the Scheduling page, a proof-of-concept deployment would typically use the default (as soon as possible).
Otherwise, specify a schedule.
6. Follow the on-screen instructions to complete the wizard.
5. After the master vDisk image updates, promote the new master vDisk image, as described in “Promoting Updated
Versions” in the Provisioning Services documentation in Citrix eDocs. T he XenApp servers are updated with the new vDisk
image.
1. If you use PCM, ensure that XenApp Connector is enabled to use PCM on the XenApp servers to receive SUM updates.
See Install and set up components for Power and Capacity Management for details.
T he optional XenApp PCM feature coordinates the power states and load consolidation of the XenApp servers, enabling
XenApp Connector to deploy SUM updates with minimal disruption of user sessions.
2. If you have not already done so, use the XenApp Connector Configuration wizard to configure a maintenance window
for the XenApp servers.
3. Use the Configuration Manager console to deploy one or more SUM updates to servers in the XenApp farm collection.
T he deadline you set for this software update installation is used only if the Connector agent service fails to install the
update before that time.
XenApp Connector can use PCM to drain users from the XenApp servers you targeted to receive a SUM update. At
specified times within the maintenance window, the Connector agent service runs on every targeted XenApp server and
installs the SUM update on XenApp servers that have no user sessions. If the SUM update has not been installed on all
targeted XenApp servers when the software update installation deadline is reached, the Connector agent service forces
the installation on any server that does not yet have the update installed and then restarts the server, even if there are
active user sessions.
To allow PCM to manage power states and load consolidation of XenApp servers, the XenApp Connector changes the
servers' power controller preference and power control mode:
If no deployments are pending for a XenApp server, the server's power controller preference remains at 1st choice, which
is the default ranking for servers managed by Power and Capacity Management.
When you designate an online XenApp server to receive a deployment, XenApp Connector performs the following
operations:
T akes control of the server's power controller preference and changes it to 5th choice.
After the user sessions have completely drained or (after a configurable amount of time) been logged off, triggers the
software install for the pending deployment.
Just before the application is installed, sets the server state to Maintenance.
After the deployment processing completes, changes the server's power controller preference to 1st choice,
relinquishes control of the server's power controller preference, restarts the machine (if needed), and enables the user
to log on.
When you designate an offline XenApp server to receive a deployment, XenApp Connector performs the following
operations:
T akes control of the server's power controller preference and changes it to 6th choice.
Sets the server state to Maintenance and the server control mode to Unmanaged for the duration of the
maintenance window or the processing of all pending deployments, whichever occurs first.
Powers on the server. T he XenApp power-on interval configured in the XenApp Connector Configuration wizard
Note: While a XenApp server's power controller preference is controlled by XenApp Connector, attempting to change the
server's power controller preference using the PCM console results in a warning that doing so might cause undesirable
effects.
Whether you are publishing MSI, App-V, or XenApp applications to devices, you perform the following sequence of steps in
the Configuration Manager console:
1. Add the XenApp deployment type to the application and add a publishing item to the XenApp deployment type.
For each publishing item linked to a XenApp deployment type, the XenApp Connector publishing task creates a XenApp
published application. You can reuse publishing items.
Receivers on non-Windows devices ignore any Configuration Manager-specific settings and manage the applications as
usual.
On devices managed by Configuration Manager (managed devices), you must configure integration with managed
devices to enable an application to be accessed from Receiver.
Important: T he procedures in this section highlight XenApp-specific settings. For detailed information about using the
Configuration Manager console, refer to the Microsoft Documentation Library for System Center 2012 Configuration
Manager.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
1. Add the XenApp deployment type to the application and define a new publishing item:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard. Settings for XenApp deployment types:
Click through the General, T ype, and Location pages to accept the defaults.
If you are using the legacy XenApp ICA client and want to specify a folder location in the Start menu for the
application, on the Presentation page enter the Client application folder.
Click through the remaining pages and make changes as needed for your environment.
T he XenApp deployment type you added appears in the Deployment Types tab.
5. T o allow users of the Configuration Manager Software Center to access the XenApp-published application as if it
were locally installed, increase the priority of the XenApp deployment type to 1: In the Deployment T ypes tab, right-
click the XenApp deployment type and choose Increase Priority. Repeat as needed until its priority is 1.
T he publishing item that you added can be reused when publishing other applications. T he publishing items appear in
Application Management > XenApp Publications.
Note: If you later need to delete a publishing item, use the Configuration Manager console so that both the
Configuration Manager database and the XenApp farm are updated. Using Citrix AppCenter to delete a publishing item
from a XenApp farm does not update the Configuration Manager database.
XenApp administrators might notice that the description field of the published application in AppCenter now has an
additional keyword, ConfigMgr. T hat keyword indicates that the application is available for installation by the XenApp
deployment type handler. Do not remove the keyword.
3. T o verify the deployment, go to Monitoring > Deployments to view the deployment status and then open Receiver on a
target device to subscribe to (if needed) and open the application.
Before publishing an application to devices, you must deploy the application to XenApp servers that publish the application.
For more information, refer to topics under Deploy applications and software updates to XenApp servers.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
1. Add the XenApp deployment type to the application and define a new App-V type publishing item:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard. Settings for XenApp deployment types:
Click through the General page.
On the T ype page, click App-V virtual application.
On the Location page, choose the App-V package and the Application in that package to be published.
If you are using the legacy XenApp ICA client and want to specify a folder location in the Start menu for the
application, on the Presentation page enter the Client application folder.
Click through the remaining pages and make changes as needed for your environment.
T he XenApp deployment type you added appears in the Deployment Types tab.
5. T o allow users of the Configuration Manager Software Center to access the XenApp-published application as if it
were locally installed, increase the priority of the XenApp deployment type to 1: In the Deployment T ypes tab, right-
click the XenApp deployment type and choose Increase Priority. Repeat as needed until its priority is 1.
T he publishing item that you added can be reused when publishing other applications. T he publishing items appear in
Application Management > XenApp Publications.
Note: If you later need to delete a publishing item, use the Configuration Manager console so that both the
Configuration Manager database and the XenApp farm are updated. Using Citrix AppCenter to delete a publishing item
from a XenApp farm does not update the Configuration Manager database.
XenApp administrators might notice that the description field of the published application in AppCenter now has an
additional keyword, ConfigMgr. T hat keyword indicates that the application is available for installation by the XenApp
deployment type handler. Do not remove the keyword.
3. T o verify the deployment, go to Monitoring > Deployments to view the deployment status and then open Receiver on a
T he following procedure describes the required configuration that provides access to applications from Receiver on
managed devices. Following the steps is a description of how the configuration impacts application installation,
uninstallation, and access for both Receiver and Software Center.
T his section also describes other optional configuration, such as changing application shortcut locations.
On managed devices, XenApp-hosted applications published by Configuration Manager are targeted to Software Center.
To also provide access to those applications from Receiver for Windows, you must make Receiver a dependency for the
XenApp deployment type.
1. If Receiver for Windows is not already added to Configuration Manager, add it.
1. In the Configuration Manager console, expand Software Library> Application Management and then click
Applications.
2. On the Home tab, click Create Application.
3. On the General page, click Manually specify the application information and then click Next.
4. Specify a Name. You will need to enter this same name in the next step.
5. On the Deployment T ypes page, click Add and then create the Script Installer deployment type with these settings:
Set T ype to Script Installer, click Next, and enter the same Name you entered in step d.
On the Content page, next to Content location, click Browse, navigate to the folder that contains
CitrixReceiver.exe, and click Select Folder.
Also on the Content page: Next to Installation program, click Browse, select CitrixReceiver.exe, and then click Open.
After "CitrixReceiver.exe" add these two required parameters: /silent /includeSSON.
If your Receiver for Windows deployment plan requires other command-line options, include them too.
On the Detection Method page, click Add Clause, change T ype to Folder, for Path enter
%ProgramFiles(x86)%\Citrix, and for File or folder name enter ICA Client.
On the User Experience page, set Installation behavior to Install for system if resource is device; otherwise install
for user and set Logon requirement to Whether or not a user is logged on. Click through the remaining pages.
2. In the Configuration Manager Applications list, select an application and then click the Deployment T ypes tab.
3. Right-click the XenApp deployment type and choose Properties.
4. Click the Dependencies tab and then click Add.
5. Specify a Dependency group name and then click Add.
6. In the Specify Required Application dialog box, select Receiver in the Available applications list and again in the
Deployment types list.
XenApp hosted applications installed by Configuration Manager appear to a Receiver for Windows user like any other
application, are available for subscription, and appear in the Windows Start menu after the user subscribes to an available
Users can access applications deployed to user or device collections from the Application Catalog. T hese applications
include those deployed with the XenApp deployment type. Applications installed from the Application Catalog appear in
the Windows Start menu.
After Configuration Manager installs an application, Receiver cannot remove the application from that computer. T hus, if
the user attempts to uninstall the application from the Software Center, the application remains installed on the
computer.
By default, applications appear under Start > All Programs. You can specify the relative path under the Programs folder to
contain the shortcuts to subscribed applications. To do that, specify START MENUDIR=Text string on the Receiver for
Windows command-line. For example, to place shortcuts under Start > All Programs > Receiver, specify
START MENUDIR=\Receiver\. Users can change the folder name or move the folder at any time.
You can also control this feature through a registry key. For information, refer to "Configure and install Receiver for
Windows using command-line parameters" in the latest Receiver for Windows documentation in Citrix eDocs.
Applications installed from the Configuration Manager Application Catalog are reported by the XenApp deployment type
handler as installed.
Applications subscribed to by a Receiver user (and thus installed on the local computer) are reported by the XenApp
deployment type handler, by default, as installed in the Application Catalog even if the application was not installed by
Configuration Manager. With this behavior, an administrator can determine from Configuration Manager reporting that the
computer is out of compliance. T his default is controlled on a Windows computer by the registry key
ReportSubscribedAppsAsConfigMgrInstalled.
In case of an application that is installed by Receiver but not by Configuration Manager, that registry key affects
installation and uninstallation as follows:
If ReportSubscribedAppsAsConfigMgrInstalled is T rue and the user tries to uninstall the application from the Application
Catalog, the Application Catalog reports to the user that the uninstallation attempt failed. T he user must unsubscribe
the application from Receiver or use Windows Add/Remove Programs to uninstall it.
If ReportSubscribedAppsAsConfigMgrInstalled is False and the user installs the application from the Application Catalog,
HKLM\SOFT WARE\Citrix\Dazzle
HKCU\SOFT WARE[\Wow6432Node]\Citrix\Dazzle
Note: Applications delivered from older clients that support legacy Web Interface XenApp Services sites are not included in
Configuration Manager reporting.
In an environment that includes mandatory deployments to a user collection, a user in that collection can experience about
a 90-second delay (for about 20 applications) during each log on while XenApp deployment type based apps deploy to the
user’s desktop.
A best practice to reduce this overhead is to use roaming profiles for the user collection experiencing delays. Although a
first-time user will experience the delay, applications will be available almost immediately for subsequent logons.
1. Specify the share location to store a user’s roaming profile: You need elevated domain privileges to perform this task.
1. From within Active Directory Users and Computers, search for the user account and open RoamingUser Properties.
2. Select the Profile tab and specify the location of the share where the user’s roaming profile is to be stored: In Profile
path, enter \\ServerName\ShareName\UserID. T he users must have read/write access to this share. T he user’s
account profile will be stored in a folder contained in the share you specified.
2. Configure Citrix Receiver to also use this network share to store its information so that it will be available from any
machine the user logs into:
1. In the Windows Registry Editor, browse to HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\Dazzle.
2. If the entry Local does not exist, create it: Right-click Dazzle, select New > String Value, enter a Value name of Local,
and enter the Value data %APPDAT A%\Citrix\selfservice\local.
3. Restart Citrix Receiver and log on the user.
XenApp Connector extends the tracing capabilities provided by Configuration Manager by using standard .NET listeners and
registering a CDF module. You can use CDFMonitor, the Configuration Manager log viewer tool CMTrace, or other third-
party tools to view trace information.
Log files use the naming convention ComponentName.CreationT imeStamp.log. For example, log files for the component
Citrix.ConfigMgr.PublishingT ask.exe are named Citrix.ConfigMgr.PublishingT ask.CreationT imeStamp.log.
CDF modules use the naming convention ConfigMgr_ModuleName.
For detailed information about CDFMonitor, refer to CDFMonitor.
Locat ion in % P rogramF iles% \Cit rix\XenApp Connect or f or Conf igMgr 2012\
Config Wizard\Logs
Connector Service\Logs
Citrix.ConfigMgr.HighAvailabilityMonitor
Citrix.ConfigMgr.SynchronizationT ask Verify sync tasks after adding or removing devices or users.
XenApp Agent\Logs
XenApp DT Handler\Logs
T he following table lists the Configuration Manager client and server logs.
AppEnforce Verify that, if AppDiscovery indicates an application did not install, this log starts with
the installation routine.
SMSAdminUI View information about the operation of the Configuration Manager console.
Citrix.ConfigMgr.XenAppDT
Configuration files enable you to specify logging features such as maximum file size and number of files to retain. T he
.config file for each component uses the naming convention ComponentName.exe.config.
Configuration files are under the installation folder (%ProgramFiles%\Citrix\XenApp Connector for ConfigMgr 2012), as
follows:
On the server where the XenApp Connector service is installed:
install\Config Wizard
install\Connector Service
install\XenApp DT Handler
Local App Access seamlessly integrates users' locally installed Windows applications into a hosted desktop environment
without changing from one computer to another. With Local App Access, you can:
Access applications installed locally on a physical laptop, PC, or other device directly from their virtual desktop.
Provide a flexible application delivery solution. If users have local applications that you cannot virtualize or that IT does
not maintain, those applications still behave as though they are installed on a virtual desktop.
Eliminate double-hop latency when applications are hosted separately from the virtual desktop by putting the shortcut
to the published application on the user's Windows device.
Use applications such as:
Video conferencing software such as GoT oMeeting.
Specialty or niche applications that are not yet virtualized.
Applications and peripherals that would otherwise transfer huge amounts of data from a user device to a server and
back to the user device, such as DVD burners and T V tuners.
Limit at ions
Local App Access is only designed for full-screen, virtual desktops spanning all monitors as follows:
User experience could be confusing if Local App Access is used with a virtual desktop that runs in windowed mode or
does not cover all monitors.
For users with multi-monitors, if one monitor is maximized, it becomes the default desktop for all applications
launched in that session, even if the subsequent applications typically launch on the other monitor.
T he feature is designed for use with one VDA; there is no integration with multiple, concurrent VDAs.
Some applications have unexpected behavior, which could impact users:
Some applications have licensing agreements that allow them to run only on workstations and cannot be hosted.
Some applications need to access local devices such as bar code scanners or card readers to function.
Users might be confused with drive letters, such as local C: rather than virtual desktop C: drive.
Printers available in the virtual desktop are not available to local applications.
Applications that require elevated permissions cannot be launched as client-hosted applications.
No special handling for single-instance apps (such as Windows Media Player).
Local applications appear with the Windows theme of the local machine.
Full-screen applications are not supported. T his includes applications that open to the full screen, such as PowerPoint
slide shows, or photo viewers that cover the entire desktop.
Local App Access copies the properties of the local application, such as the shortcuts present on client's desktop and
the Start menu on the VDA. However, it does not copy other properties, such as shortcut keys and read-only
attributes.
Applications that do customize the manipulation of the order of overlapping windows can have unpredictable results.
For example, some windows might be hidden.
Shortcuts are not supported, including My Computer, Recycle Bin, Control Panel, Network Drive shortcuts, and folder
shortcuts.
T o use Local App Access, the hosting environment must have the following components:
Citrix XenApp 6.5
Web Interface 5.4
Citrix StoreFront
For more information about XenApp system requirements, refer to the topic "System Requirements for XenApp 6.5" in Citrix
eDocs.
T o enable Local App Access, the hosting environment must include the following components:
Operating systems for hosted desktops:
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows 7 (32-bit and 64-bit)
Windows 8 (32-bit and 64-bit)
Windows 8.1 (32-bit and 64-bit)
Operating systems for client:
Windows XP SP3 (32-bit)
Windows 7 (32-bit and 64-bit)
Windows 8 (32-bit and 64-bit)
Windows 8.1 (32-bit and 64-bit)
Web Browsers (only the following are supported):
Internet Explorer 8, 9, and 10
Mozilla Firefox 3.5 through 21.0.
Google Chrome 10
Citrix Receiver 4.x
Note: When connecting to hosted desktops, local app access supports only one connection per user device. Additionally,
hosted desktop connections are supported only when using Citrix Desktop Viewer in Full-screen mode across all monitors
attached to the user device.
Installation Issues
General Issues
After upgrading a user device from a previous version of Citrix Receiver to the Seamless App T echnology Client, an error
might result when the user later attempts to launch applications from within a hosted desktop session. Afterward, the
user cannot launch applications from the hosted desktop. T his issue occurs when the Seamless App T echnology client is
installed using the auto-installer rather than the command line. T o work around this issue, perform one of the following
actions:
After upgrading to the Seamless App T echnology Client, on the user device, open the Windows Registry and add the
subkey HKEY_CURRENT _USER\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual
Channels\Control\ClientHostedAppsShortcuts. For Value, enter an asterisk (*).
Log on to the user device as an administrator, remove all instances of Citrix Receiver, and restart the device.
Afterward, perform a fresh install of the Seamless App T echnology Client from the command line, using the parameter
ALLOW_CLIENT HOST EDAPPSSHORT CUT S=1. For more information, refer to the section "Enabling Local App Access
for Subscribers" in the
— Integrating Local User Applications in XenApp 6.5
guide. [#271089]
When the icon for a locally installed application on the user's computer is changed, the original icon appears when the
application is launched from a hosted desktop. [#159588]
When a user launches two hosted desktop sessions on the same user device, shortcuts to local applications in the Start
and Programs menu disappear when the user ends one of the hosted desktop sessions. T his occurs because Local App
Access supports only one hosted desktop session per user on the XenApp server. [#255935]
When URL redirection is enabled, URLs that are not added to either the whitelist or blacklist might not render on the
XenApp server when launched from a hosted desktop session. If the user uses the Run command from within the hosted
desktop to launch these URLs through Internet Explorer, the URLs are displayed in separate instances of Internet
Explorer that is locally installed on the user device. [#261451]
If the taskbar on the user device is in a different location from the taskbar on the hosted desktop, the user device's
taskbar might appear on top of the hosted desktop session when the user's mouse hovers nearby. However, if the user
device's taskbar and hosted desktop's taskbar are in the same location (for example, both are near the bottom of the
screen), the user device's taskbar remains hidden when the user's mouse hovers nearby. T his issue occurs on user devices
running Windows 7 only. [#274153]
Pinning shortcuts to locally-installed applications to the hosted desktop's taskbar or Start menu might result in failed or
incorrect application launches, or incorrect icon grouping. T his occurs because Local App Access does not support pinning
shortcuts to locally-installed applications to the hosted desktop's taskbar or Start menu. [#278595]
When users connect to a hosted desktop on devices running the Japanese version of Windows XP, shortcut icons are
not fully cached. T his results in incomplete shortcut enumeration. [#301197]
When users connect to a hosted desktop on devices running the Japanese version of Windows XP and later terminate
T he user works with the application from within the hosted desktop session window as with any locally-running application.
users can open files, save changes, and print the screen. users can also perform cut and paste operations according to Citrix
Service Provider policy.
In general, multiple instances of a locally-running application behave according to the taskbar settings established for the
hosted desktop, just as with remote applications. However, some shortcuts have the following limitations:
Shortcuts to locally-running applications are not grouped with running instances of those applications. T hey are also not
grouped with running instances of XenApp-hosted applications or pinned shortcuts to XenApp-hosted applications.
Users can only close windows of locally-running applications from the taskbar. Although users can pin local application
windows to the desktop taskbar and Start menu, the applications might not launch consistently when using these
shortcuts.
Locally-running applications are associated with the hosted desktop session for the life of the session. users' shortcuts are
maintained after disconnecting and reconnecting the session, after resizing the session, and after logging off.
When a user launches an application, the application window appears only within the session in which it was launched. If
the user launches another session, the user might not see all currently running application windows.
When a user disconnects from a hosted desktop session, the locally-running applications remain on the user's computer in
local application windows. User-hosted applications also remain on the user's computer in seamless windows.
If a user logs off the session or shuts down the computer, all locally-running application windows in the session are closed,
just as with any other local application.
If the user switches the desktop session from fullscreen to windowed mode, locally-running applications in the session are
minimized to the desktop taskbar. When the user returns the desktop session window to fullscreen mode, all applications
are restored to original window size.
Note: If using multiple monitors, the Desktop Viewer must be in Full-screen mode across all monitors. T his version of Local
App Access does not support an environment in which the Desktop Viewer is in Full-screen mode on one or across some of
the available monitors.
To enable Local App Access for users, CSPs perform the following tasks:
Users must ensure that their computers have Citrix Receiver installed and possess the required registry key. T his registry key
can be created either during a new command-line installation of Receiver or after Receiver has been installed.
users can enable this feature on their computers when installing Citrix Receiver through the command line. T o do this, they
use one of the following parameters:
CitrixReceiver.exe ALLOW_CLIENT HOST EDAPPSSHORT CUT S=1
OR
Users can also enable URL redirection during Receiver installation by appending the ALLOW_URLREDIRECT ION parameter
to the command string. For more information about URL redirection, see Redirecting Web Content in Hosted Desktop
Sessions.
For more information about installing Citrix Receiver from the command line, see the topic: To configure and install the Citrix
Receiver for Windows using command-line parameters.
Users can enable Local App Access on their computers that have Citrix Receiver already installed.
Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system.
Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor
at your own risk. Be sure to back up the registry before you edit it.
1. On the user's computer, open Windows Registry and create the following string keys:
T he shortcuts populate the hosted desktop session when the user connects to the XenApp server.
Note: Users can also enable URL redirection after installing Receiver by creating an additional subkey. For more
information about URL redirection, see Redirecting Web Content in Hosted Desktop Sessions.
You can configure how XenApp retrieves these shortcuts and where they are placed by modifying registry settings on the
XenApp server. users modify a registry setting on their computers that specifies where local Desktop shortcuts are stored.
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.
Use this procedure to enable XenApp to retrieve local Desktop shortcuts from users' computers.
Users use this procedure to specify where their computers store local Desktop shortcuts. XenApp uses this location to
retrieve the shortcuts and place them on the hosted desktop. If XenApp finds a shortcut with the same name in multiple
folders, XenApp retrieves the shortcut found last. If XenApp cannot find the folder path specified, XenApp retrieves
standard Windows desktop shortcuts. If no folder path is specified, XenApp does not retrieve any shortcuts.
Use this procedure to specify the folder where XenApp places local Desktop shortcuts upon retrieval. If the folder name
you specify already exists, no folder is created. If the registry value is blank, no shortcuts are added to the folder.
When a user connects to a hosted desktop, XenApp retrieves shortcuts to local applications and any user-hosted
applications from the local Programs menu and displays them in the Programs menu on the hosted desktop.
You can configure how XenApp retrieves these shortcuts and where they are placed by modifying registry settings on the
XenApp server. users modify a registry setting on their computers that specifies where local Programs shortcuts are stored.
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.
To enable retrieval of local Programs shortcuts
Use this procedure to enable XenApp to retrieve local Programs shortcuts from users' computers.
T o help maintain the availability of resources in your XenApp environment, you can limit the number of shortcuts the
XenApp server enumerates and the number of self-hosted applications a user can launch in a given session. T o do this, you
modify registry entries on the XenApp server and on the user's computer.
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.
To control the number of shortcuts that are available in a session
Use this procedure to specify the number of shortcuts that the XenApp server can enumerate in a session. When users
connect to hosted desktops, XenApp enumerates Desktop shortcuts first, then enumerates shortcuts in the Programs
menu.
To specify the redirection path of content from specific Web sites, you configure the URL whitelist and URL blacklist on the
XenApp server. T hese lists consist of multi-string registry keys that specify the URLs you want to redirect.
T he URL whitelist specifies URLs that are viewed on the default Web browser of the environment in which they are
launched. T he URL blacklist specifies URLs that are redirected to the locally-running default Web browser.
T he following table describes where URLs are redirected when added to these lists:
URL in URL in When launched f rom t he user's When launched f rom t he host ed
Whit elist ? Blacklist ? comput er, t he URL displays in... deskt op, t he URL displays in...
To ensure a URL is always rendered in the default Web browser on the user's computer, add it to the URL blacklist. To
ensure a URL is always rendered on the XenApp server, do not add it to either list.
By default, URL redirection is disabled. Administrators can configure this feature by modifying a registry key on the XenApp
server. users can enable this feature on their computers during a new command-line installation of Citrix Receiver or after
Receiver has been installed.
Note: URL Redirection is supported only for user devices with the Citrix Receiver Enterprise package installed.
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.
When you update the URLs in either of these lists, the updates are sent automatically to users who reconnect to existing
sessions or launch new sessions. For users who are connected to active sessions when the list updates occur, you can
ensure they get the updates without requiring they disconnect and launch a new session. T o do this, on the XenApp server,
open the Command Prompt window and navigate to the C:\Program Files (x86)\Citrix\system32 directory. T ype the
following command and press ENT ER:
VDARedirector.exe /refreshpolicy
users can enable URL redirection on their computers when installing Citrix Receiver Enterprise through the command line.
T hey do this while also enabling Local App Access by using the following command string:
CitrixReceiverEnterprise.exe ALLOW_CLIENTHOSTEDAPPSSHORTCUTS=1 ALLOW_URLREDIRECTION=1
For more information about installing Citrix Receiver from the command line, see the topic: To configure and install the Citrix
Receiver for Windows using command-line parameters.
After installing Citrix Receiver Enterprise, users can enable URL redirection on their computers by modifying a registry key on
their computers.
1. On the user's computer, open Windows Registry and create the following subkey:
When the user connects to the XenApp server, URLs redirect according to the whitelist and blacklist values configured on
the XenApp server.
Developers can use the SDK with the Windows application development framework that best suits their needs. Download
the SDK from the Citrix download pages.
Typical Windows applications are based on an expansive desktop space with access to a keyboard and a mouse. Legacy
Windows applications do not accommodate on-screen keyboards and other features specific to mobile devices. T he Mobile
SDK for Windows Apps enables Windows developers to write new applications and to improve existing applications for
delivery to supported mobile devices.
T he Mobile SDK for Windows Apps enables a Windows application to control mobile device features such as:
But t ons – Get the current button target, set the button target, and specify whether to handle a button press on the
server or the mobile device.
Camera – T ake, download, and remove pictures using the built-in camera of the mobile device. Get picture state
information.
Device propert ies – Retrieve device feature support information.
Display – Get and set mobile device screen metrics such as orientation, scroll mode, and viewport origin to ensure that
text is easy to read and controls are easy to use.
Keyboard – Check the keyboard state and control whether to show or hide the on-screen keyboard. T he keyboard
state includes the keyboard type, keyboard flags, auto-capitalization, return key type, and edit field rectangle.
Not if icat ion – Notify the user about special events using sound, vibration, light, and text.
P hone – Make phone calls based on the contacts list on a server.
P icker cont rol – Select an item from a list using a control that is native to the device.
SMS – Send an SMS from content on a server.
For features such as phone calls, SMS, and camera functions enabled by the Mobile SDK for Windows Apps, Receiver
prompts the user for permission to perform the action so that the user always has the option to protect potentially
sensitive information.
When developing hosted applications that use the Mobile SDK for Windows Apps, consider the following:
A secure connection (for example, using SSL/T LS or a VPN) should be enforced for the applications. Citrix Receiver should
connect to trusted servers.
Consider obtaining legal advice regarding the use of mobile device features, such as the camera, which raise privacy
issues.
Learn more about the Mobile SDK for Windows Apps on the Citrix Developer Network.
XenApp mobility features improve the experience of your mobile device users accessing your published resources.
Features include:
Fixed Issues
T he automatic keyboard and mobile combo box now appear on second use. [253264]
T he policy help text for Automatic keyboard display and Remote the combo box is correct. [256356]
T he error "wfshell shell has stopped working" no longer appears when you start Microsoft Notepad after previously
exiting it before the keyboard opened. [261973]
Known Issues
An application with a .NET 4.0 Calendar control can crash if Microsoft UI Automation monitoring is active in the same
session and the user places the focus on the Calendar control. T his issue results from a missing property
(ComponentResourceKey) in the DataT emplate key for the .NET 4.0 Calendar control. A resource defined at the theme
level must use a ComponentResourceKey as the key.
To avoid this issue with .NET 4.0, set the DataTemplate key for the Calendar control as follows:
T he automatic keyboard feature does not scroll the display to show the input area when an iOS device resolution is set
to a value other than Auto-Fit. [267307]
During some operations, applications can unexpectedly minimize to the touch-optimized desktop taskbar. T ap the
taskbar icon for the application to re-open it. [267606, 267609]
T he following are server, user device, application, and mobile device system requirements.
Environments
Citrix XenApp 6.5 for Windows Server 2008 R2 with HRP02
Microsoft .NET Framework 4.0
Devices
Citrix Receiver for Android 3.x
Citrix Receiver for iOS 5.5.x, 5.6.x, 5.7, and 5.8
Citrix Receiver for Windows 8/RT 1.2 and 1.3
Application
Location sensing is supported for applications that use the Windows 7 Location API and can receive responses based on
the client location sensor.
T he following Citrix user configuration policy settings control mobility feature settings.
By default, the use of location information is prohibited. To allow use of location information, set this policy to Allowed.
When this setting is allowed, a user can prohibit use of location information by denying a Receiver request to access the
location. Android and iOS devices prompt at the first request for location information in each session.
Important: Some features are available only with the Enterprise or Platinum editions of XenApp. For more information, see
Compare XenApp features by edition.
T he initial release of Feature Pack 1 contained the following features. To download, go to the XenApp download page. In
the list find XenApp 6.5 Feature Pack 1, click Log in for more, and provide your Citrix user name and password. Expand
Product Software and the licensed edition of XenApp you have installed.
XenApp 6.5 HRP01 for Windows Server 2008 R2. Provides updates to enable server side content fetching for WAN
connections and enable flash by default for IE9.
XenApp Additional Components. Helps you manage your deployment and application delivery.
Desktop Director 2.1
Merchandising Server
WorkFlow Studio (PDF)
Virtual Desktop Agent Update. T ake advantage of Citrix Mobility Pack support for VM Hosted Apps.
Universal Print Server. Eliminates the need to install numerous network printer drivers on XenApp hosts and enables more
efficient network utilization.
Group Policy Updates. Enables Universal Print Server and Mobility Pack features.
Receivers. Receiver for Windows that replaces previous versions of the Online Plugin.
XenServer virtualization platform. High performance, reliable, and scalable hypervisor with valuable features like
XenMotion and the XenCenter management console.
Full downloads for a wide range of XenApp releases.
T he following features were added or updated from the original Feature Pack 1 release. To download, go to the XenApp
Components download page. In the list find XenApp 6.5 Feature Pack 1, click Log in for more, and provide your Citrix user
name and password. You can download features available for your licensed edition of XenApp.
Profile Management 4.1. Easy, reliable, and high-performance way to manage user personalization settings in virtualized
or physical Windows environments.
Personal vDisk 5.6. Single image management of pooled and streamed desktops while allowing people to install
applications and change their desktop settings.
HDX RealT ime Optimization Pack 1.3 for Microsoft Lync. Enables clear, crisp, high-definition video calls in a virtualized
environment in conjunction with Microsoft Lync.
XenApp 6.5 Connector for System Center 2012 Configuration Manager. Provides a single infrastructure and tool to
manage all enterprise applications including on-demand XenApp applications.
OpenGL GPU Sharing. Allows graphics-heavy applications running on XenApp to render on the server's graphics processing
unit (GPU).
Known Issues for XenApp 6.5 Delivering XenApp to Software Services Subscribers (Windows Desktop Experience
Integration)
Publishing Resources
Citrix XenApp includes additional features in each edition to help enhance the user application virtualization experience. T his
table includes links to the product documentation located in Citrix eDocs or in the Citrix Knowledge Center describing these
features.
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.
Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays when users reconnect to existing
sessions.
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.
Installation Issues
SmartAuditor Issues
Application Streaming Issues
Single Sign-on Issues
Other Known Issues
T he Provisioning Services T arget 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 T arget 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. T he 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 CtxStartMenuT askbarUser Group Policy Object
(GPO), the PowerShell and Server Manager icons are not removed from the T askbar as expected. Additionally, the
Internet Explorer and Windows Media Player icons are not added to the T askbar. T his occurs because the script Enable-
CtxDesktopExperienceUser.ps1 does not run correctly on non-English operating systems. T o resolve this issue, download
the updated Enable-CtxDesktopExperienceUser.ps1 script from CT X130208 in the Citrix Knowledge Center and replace
the script on the XenApp server. [#261892]
T he 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. T o 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]
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. T o 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. T o 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]
T here are no workarounds for these issues.
After creating the first target, you cannot modify the "Enable User Updates" setting for the profile. T he setting that you
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]
T he 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]
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. T o 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. T o 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]
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. T his may
result in response failures for the Flash window or Web browser and extremely long buffer times and pauses. T o 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. T his 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. T his condition is indicated by this system event log message, with picadd as its source: "T he Citrix T hinwire
driver stopped because it cannot allocate the required memory. You may need to manually disconnect and restart any
existing sessions." [#261647]
During session printer enumeration, Adobe Reader 10.1 may fail. As a workaround, edit your Adobe Reader preferences
and uncheck the Enabled Protected Mode at startup checkbox. [#285090]
You can perform session shadowing on XenApp 6 computers only when both computers are configured with single
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 T echnical Preview versions).
You must use the AppCenter from the 6.5 media to manage the XenApp 6.5 farm. Using the AppCenter to manage
servers running a previous version of XenApp is not supported.
See Installing and Configuring XenApp for additional guidance, including tasks to complete before installing and
configuring XenApp.
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.
If installation of a required Windows role or other software requires a restart (reboot), restart the server before starting the
XenApp server role installation.
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 T echnology
T he 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. Also supported are .NET 3.5.1, 4.0, and 4.5)
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. T he Server Role Installer checks for installed IIS role services and whether the component is
selected or specified. For complete information, see Before Installing XenApp. T he IIS role services are listed below.
Web Server (IIS) > Common HT T P Features > Default Document (selecting this automatically selects Web Server (IIS) >
Management T ools > 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 T ools > IIS 6 Management Compatibility (includes IIS 6 Metabase Compatibility, IIS 6
WMI Compatibility, IIS 6 Scripting T ools, 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.
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.
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
T he 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.
Microsoft SQL Server 2008 Express can be deployed for you by the XenApp Server Configuration Tool when creating a
XenApp farm.
For information about the latest supported database versions, see CT X114501. For information about requirements, see
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.
T o 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.
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.
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.
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.
T he virtualization infrastructure, which is the center of a XenApp deployment, concerns the following concepts:
T he XML Broker is a function of the Citrix XML Service. Only the XML Service on the server specified in the Web Interface
functions as the broker. T he server hosting the XML Broker must be configured with the controller XenApp server mode. 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.
T he 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.
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.
Choose printers that are tested with multiuser environments. Printers must be PCL or PS compatible and not host-based.
T he printing manufacturer determines whether printers work in a XenApp environment, not Citrix.
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.
Consider these factors when defining your farm’s hardware and operating system configuration:
Can I run the applications? Citrix recommends testing non-Vista-compliant applications before you publish them on your
farm. Some non-Vista-compliant applications run using the Application Compatibility feature.
How many users do I anticipate will want to connect to each application during peak and off-peak hours? Do I need to
allocate servers for load balancing?
Will users be accessing certain applications frequently? Do I want to publish all of these applications on the same server
to facilitate session sharing and reduce the number of connections to a server? If you want to use session sharing, you
might also want users to run applications in seamless windows.
Will my organization need to provide proof of regulatory compliance for certain applications? Will any applications
undergo a security audit? If you intend to use SmartAuditor to record sessions on these servers, install the SmartAuditor
agent on these servers. In addition, make sure the servers have sufficient system resources to ensure adequate
performance.
Will any of my applications be graphically intensive? If so, consider using the XenApp SpeedScreen, Memory Utilization
Management, or CPU Utilization Management features as well as more robust hardware for sessions hosted on these
servers.
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. T o identify root
applications issues, consider using tools like the Microsoft Application Compatibility T oolkit (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.
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.
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.
St reamed t o deskt op: Users can have the User devices must
local application have sufficient
Executables for applications are put in profiles and stored on a file
experience, but resources to run
server or Web server (the App Hub). When launched, the files required
you manage the the applications
to execute the application are streamed to the user device, and
applications locally; the user
application processing takes place on the user device instead of the
centrally. devices cannot be
XenApp server. When applications are streamed to the user device,
Users might have a thin clients.
the user experience is similar to running applications locally. After
better experience User devices must
applications are cached on the user device, users can continue
when resource- run Windows
running the apps after disconnecting from the network (referred to
intensive operating systems,
as offline access).
applications, such including Windows
as graphics 7, XP, or Vista.
applications, are
streamed to
desktops.
Using application
properties and
Citrix policies and
filters for Offline
Applications, you
control the
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. T his 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.
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.
Siloed It is easy to track the application’s location and usage Additional servers are required to ensure
Centralization makes it is easy to configure and maintain sufficient redundancy
the application
Other applications do not interfere with the installed
application
Can be useful for mission-critical applications
Nonsiloed Reduces the number of servers required for applications Cannot be used when applications
in small- to medium-sized farms conflict with other applications
Might simplify user permissions and ensure consistent
settings during application installation
A single server is accessed by each user and session
sharing is ensured
By using features such as Load Manager and Preferential Load Balancing, you might not need to silo mission-critical
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.
Consider how you want to balance server loads. You might want to load balance resource-intensive, mission-critical, or high-
availability applications. XenApp offers two methods of load balancing:
Load Manager - Lets you balance new connections to the server. When a user launches the first published application,
that user session is established on the least loaded server in the farm, based on criteria you configured. When the user
launches a second application that is published on the same server, the existing session is shared, and no load
management occurs. However, if that application is not published on the same server, Load Manager is invoked and
another load-balancing decision is made.
Load-balancing is enabled by default. When you publish an application on multiple servers, load balancing automatically
ensures that the user is sent to the least-loaded server.
Preferential Load Balancing - Lets you allocate a specific portion of CPU resources to a specific session or application.
You can use Preferential Load Balancing to assign importance levels (Low, Normal, or High) to specific users and
applications. For example, doctors in a hospital could be specified as important users and MRI scans or X-rays could be
specified as important applications. T hese 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.
T he 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.
For organizations with geographically dispersed sites, application servers might be located centrally with the infrastructure
servers (for example, in a data center) or decentrally, near the users who access the applications or in the same geographic
region as the users.
Citrix recommends placing application servers logically near any data sources. For example, for an enterprise resource
planning application, collocate those XenApp servers within the same data center. Another example is a multinational
corporation that uses Microsoft Exchange 2007 as the data source for email. Although the company could centralize all
the Exchange servers at the primary data center, they would be more likely to enable the Exchange servers within each
region and then locate the XenApp servers hosting Outlook there as well.
Servers Centralized server administration and support. Single point of failure; if the site loses
centralized at Centralized application management. connectivity, users have no alternative access.
one site Potentially better physical security than in
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.
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:
T he processing requirements of the applications and the processing capacity and available RAM of your servers. T o
determine the processing requirements for an application, see its product documentation.
T he 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.
T he 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 T ime, T hread Queue Length, Memory Consumption, and Pages Per Second, to determine the resource limits of
the servers in your environment. T his will help you determine the number of servers to deploy in your production
environment.
Most organizations deploy a single farm. However, there are some circumstances in which deploying multiple farms makes
sense. T he 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.
T here 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
Data Store T he farm has one data store. Each farm must have a data store.
Data Store Citrix recommends that you replicate the data store to If each remote site is a farm with its
Replication remote sites when using one farm in a WAN environment. own data store, there is no need for
data store replication.
Load Balancing You can load balance an application across the farm. You cannot load balance an application
across servers in different farms.
Firewall If the farm spans multiple sites, firewall ports must be Site-based farms eliminate the need to
T raversal open for server-to-server communication. open firewall ports for server-to-server
communication.
Server-to- Data store information is synchronized with member Multiple farms might improve
server servers through notifications and queries. When a farm performance over a single farm when
Communication has multiple zones, data collectors communicate dynamic server-to-server traffic crosses a WAN
information such as logons and application use across the link or when the farm is very large.
farm.
Management You can monitor and configure the farm from a single You can monitor and configure multiple
T ools management console and need to log on to only one farms from management console.
farm to do so. Communicating with multiple farms
from the console requires logging on to
each farm.
Some Citrix components can be shared between multiple farms; consequently, it is not necessary to consolidate all servers
in one farm to prevent deploying these components multiple times:
Web Interface - Sharing Web Interface between farms provides central access to applications published on different
farms.
SmartAuditor - With the exception of the SmartAuditor Agent, all components are independent of the server farm. For
example, you can configure multiple farms to use a single SmartAuditor Server.
Citrix Licensing - You can manage multiple farms using one Citrix License Server; however, performance might be affected
if you use only one license server for all servers in a WAN.
EdgeSight - You can use EdgeSight and Resource Manager powered by EdgeSight to monitor multiple farms. Note that
servers running Presentation Servers 4.5 agents appear as endpoints.
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.
T he
— 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/CT X114501.
General recommendations are listed below, based on the following size table.
Named Users < 150 < 3000 < 5000 > 3000
Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all large and enterprise
environments. When deploying large farms across a WAN, you can obtain a performance advantage by replicating the
data store and distributing the load over multiple database servers. SQL Server and Oracle are suitable for large farms
and support replication.
Do not install XenApp on the SQL Server or Oracle database server.
SQL Server Express is suitable for all small and many medium environments located in one physical location, which do not
have branch offices across a WAN.
See the database product documentation for hardware requirements for the database server.
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
T he 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.
T he 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.
T he following table lists suggested hardware for the server hosting the data store, for each configuration in the previous
table.
T he actual performance of a farm’s data store varies depending on the database engine and the level of performance
tuning achieved.
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). T his 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. T hese 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. T he 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.
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).
T herefore, 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.
T he 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. T he
— 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
CT XKEYTOOL, which is available on the installation media.
If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.
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.
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.
T his 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 Zone Data Collector (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. T hus, it is important to design zones so that there is adequate bandwidth among ZDCs.
When designing zones, the most important variables to consider are latency and bandwidth. T he amount of bandwidth and
the impacts of latency are highly dependent on your XenApp deployment. T he 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. T here are 1000-server farms that have only one zone.
Data collectors generate a lot of network traffic because they communicate with each other constantly:
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, and zone preference and failover is required, Citrix recommends configuring three zones.
T he Web Interface and the XML Broker are complementary services. T he Web Interface provides users with access to
applications. T he 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.
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. T his configuration
requires putting the Web Interface on a separate Web server. Install a certificate on the Web Interface server and configure
SSL Relay on the servers hosting the Citrix XML Broker.
In very small farms, configuring the Web Interface and the XML Broker on the same server eliminates having to secure the
link from the Web Interface to the farm. T his 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.
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.
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.
T o 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.
XenApp supports trust-based routing; servers in domains that do not trust each other can be members of the same farm.
When a server needs to perform one of the following operations on an untrusted domain, the server determines from the
data store which servers can perform the operation and routes the request to the most accessible server:
Authenticating a Citrix administrator
Refreshing the display or launching an application in Web Interface
Enumerating users and groups
Resolving users or groups when adding users to published application, printer auto-creation lists, or defining new Citrix
administrators
Requests to enumerate applications are routed to a server that has the required domain trust relationship if the originating
server does not.
By default, XenApp creates local accounts to run the following XenApp services:
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.
Active Directory security groups can affect authenticating to published applications or the management console. T he
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
Local Groups
Authenticating Recommendation: All servers that load balance an application must be in the same domain if a domain
to published local group is authorized to use the application.
applications 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.
Universal
Groups
Authenticating Recommendation: If universal groups are assigned permission to the application, all servers that
to published manage the application must be in an Active Directory domain.
applications 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 Recommendation: If a user is authenticating to the console and is a Citrix administrator only by
to membership in a universal group, the console must connect to a server that belongs to an Active
management Directory domain in the universal group’s forest.
console Rationale: Non-Active Directory domain controllers and domains outside a universal group’s forest
have no information about the universal group.
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 HT T PS; 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. T he 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. T hese
trust requests must be enabled on each server in the farm and cannot be set at a farm level.
T o prevent external users from having unauthorized access to services on farm servers, configure all XenApp servers for
constrained delegation. T o 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.
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.
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. T his
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.
T he 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
T hese 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.
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. T his 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
Citrix does not recommend disabling shadowing as a substitute for user and group connection policies.
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.
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).
XenApp 6.5 supports all languages of Windows Server (both native and Language Packs), providing six XenApp user interface
languages. T he XenApp user interface language is selected based on the language locale set in the Windows Server
operating system when XenApp is installed. T he 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 Int erf ace Language
English and languages other than those listed in this table English
French French
German German
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.)
Citrix recommends enabling pass-through client authentication. When the user connects to applications published on
different servers, pass-through client authentication enables XenApp to automatically pass user credentials from the initial
server to the server hosting the next application. T his 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
(T he pass-through authentication functionality described in this topic is not the same functionality provided by Citrix Single
Sign-on or password management applications in general.)
Enabling pass-through authentication requires configuring components on all XenApp application servers and enabling pass-
through authentication in the Citrix Receiver installed on end-user client devices. If the pass-through authentication
feature is not enabled before deploying the Receiver to end users, users must reinstall the Receiver with this feature
enabled before pass-through authentication will work.
To configure pass-through 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 pass-through client.
XenApp uses roles for XenApp features and related technologies. T he 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 T ool to configure the XenApp role license parameters (mode, server, and port)
Launch the XenApp Server Configuration T ool 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.
T he 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.
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.
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.
You must be in the local 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.
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.)
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.
T he following table describes the possible combinations, results, and defaults. For a list of IIS role services, see XenApp
System Requirements.
Yes Select the XML IIS Integration component checkbox Specify the /install:XA_IISIntegration option. T he
(default). T he component is installed. component is installed. T his is the recommended
configuration.
Yes Clear the XML IIS Integration component checkbox. Do not specify the /install:XA_IISIntegration
T he component is not installed. option. T he component is installed (default).
No Do not select the XML IIS Integration component Do not specify the /install:XA_IISIntegration
checkbox (default). T he component is not installed option. T he component is not installed.
No Select the XML IIS Integration component Specify the /install:XA_IISIntegration option. T he
checkbox. T he Server Role Installer installs the IIS Server Role Installer installs the IIS role services
role services and the component. and the 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.
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 CT X114501 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
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.
All XenApp servers can host sessions. T he 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.
A XenApp server configured in controller mode monitors other controller servers in the XenApp farm and triggers data
collector elections when necessary.
T he 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.
T he 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. T his 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.)
T he following table shows how to specify the server mode during XenApp configuration.
Server can host sessions, and be a dat a Server can host sessions, but cannot be a
collect or and XML broker (def ault ) dat a collect or or XML broker
Wizard-based Select Enable Controller and Session-host modes Select Enable Session-host mode only
configuration
To change the configured server mode, you must leave and then rejoin the XenApp farm, specifying the desired mode.
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
/help
Displays command help.
/logf ile:pat h
Path for the log file generated during the installation. Default = c:\Windows\T emp
You cannot exclude the installation of the Receiver for Windows or the Offline Plug-in.
/edit ion
Specifies the XenApp edition. Valid values are:
Platinum (default)
Enterprise
Advanced
T he following command installs the XenApp server Platinum Edition in its default location.
XenAppSetupConsole.exe /install:XenApp /Platinum
T he following command installs the XenApp server Platinum edition in C:\Program Files (x86)\Citrix, which is the default
location. T he command also installs the Receiver Storefront.
XenAppSetupConsole.exe /install:XenApp,ReceiverStorefront
INSTALLDIR=C:\Program Files (x86)\Citrix
T he 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
If you are using the Server Role Manager, launch the Licensing Configuration T ool before configuring the XenApp role.
1. After installing the XenApp role, access the XenApp Server Role Manager.
2. Click Specify licensing. T he Licensing Configuration T ool 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.
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.
XenApp. Select this model if you plan to use only XenApp licenses. T his 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 server.
XenDesktop concurrent system. Select this model if you plan to use XenDesktop concurrent user licenses. T his 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. T his option is
recommended if the Test Connection operation discovered XenDesktop user/device licenses or both XenDesktop
user/device and XenDesktop concurrent licenses.
Not e: If you purchased XenApp as part of a XenDesktop product edition, your XenApp license model is the same as your
XenDesktop license model. You XenApp licenses appear under th same line item on your XenDesktop licenses.
To change license server and licensing model information later, click Edit Licensing in the XenApp Server Role Manager.
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
7. Select role components. Roles may have default and optional components.
When you select a role, its default components are selected automatically. T he XenApp role has the following default
components:
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 T arget Device), install them at the same time you
install the XenApp server role. Otherwise, install these components from the packages on the XenApp media.
T he Citrix Receiver for Windows (formerly the online plug-in) and the Citrix Offline Plug-in are installed automatically
when you install the XenApp role. T hese items do not appear in the components lists, and you cannot disable these
installations.
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.
If you have not configured the license parameters for the XenApp role, click Specify Licensing, which launches the
Licensing Configuration T ool. Run the Licensing Configuration T ool before configuring the XenApp server role.
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).
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)
3 Invalid parameters - for example, for an option that requires a Boolean value (that is, T rue or False), you
specified 'Bob'
4 Commit failed - the configuration process did not complete; check the log file for details
XenApp versions earlier than 6.0 supported installation and configuration properties. Some of those properties have
equivalent options in XenApp 6.
CT X_MF_NEW_FARM_NAME /FarmName
CT X_MF_ODBC_USER_NAME /OdbcUserName
CT X_MF_ODBC_PASSWORD /OdbcPassword
CT X_MF_LICENSE_SERVER_NAME /LicenseServerName
CT X_MF_LICENSE_SERVER_PORT /LicenseServerPort
CT X_MF_ZONE_NAME /ZoneName
CT X_MF_SHADOWING_CHOICE:yes /ProhibitShadowing:false
XenAppConfigConsole.exe [options]
/help
Displays command help.
/Not St rict
Allows the executable to continue processing even if options do not apply in the current context.
/Conf irm
Displays a confirmation message before modifying the server. T his can be useful when testing for correct use of
command options.
/P ause
Pauses the executable after processing completes. T his prevents the command prompt from closing when launching
the command from a batch file.
/F armName: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.
/Z oneName:name
Specifies the zone name. Default = Default Zone
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.
/SqlExpressRoot Dir: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.
/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).
/OdbcP assword:password
(Required when creating or joining a farm) Specifies the database user password.
Specify the database user name with the /OdbcUserName option.
/LicenseServerName:name
Specifies the name of the existing license server.
/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
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.
For information about the XML IIS Service Integration component, see Citrix XML and IIS Integration.
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.
/OnlineP luginServerUrl:name_url
Server name or URL of the Web Interface server used by the Citrix Receiver.
/P cmWorkloadName:name
Power and Capacity Management workload name.
/EdgeSight CompanyName:name
EdgeSight company name.
/EdgeSight ServerName:name
EdgeSight server name.
T he following command, issued from the typical XenApp Server Configuration T ool 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
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. T he 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.
A provisioned Zone Data Collector without persistent storage is not supported for a XenApp environment. Zone Data
Collectors must be dedicated servers.
T he 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.
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.
T his 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. T his script configures the XenApp server (including farm
information) using the XenAppConfigConsole.exe command. T he 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.
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 T ool,
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.
Note: If you are using the SmartAuditor agent or other features that depend on Microsoft Messaging Queuing (MSMQ),
use Approach 3.
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.
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.
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:T rue 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:T rue 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). T his 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:T rue 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.
If a golden image requires updating (for example, with Citrix or Windows hotfixes, or third-party applications and patches),
you can reseal the image. T his procedure is similar to approach 3.
1. Boot into the image to make modifications. T he 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.
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.
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
T he following command prepares XenApp for imaging and provisioning. T he 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.
“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\
-XenAppConfigConsole.exe" /ExecutionMode:ImagePrep
/RemoveCurrentServer:True /PrepMsmq:True
/ClearLocalDatabaseInformation:True
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.
Required role components are not listed. T he 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.
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:
/help
Displays command help.
/logf ile:pat h
Path for the log file generated during the removal.
Note: You cannot remove the XenApp XML IIS Integration or Enhanced Desktop Experience components. T he 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.
T he following command removes the XenApp server role and all its default components.
XenAppSetupConsole.exe /uninstall:XenApp
T he following command removes the Receiver Storefront and the XenApp server role.
XenAppSetupConsole.exe /uninstall:XenApp,ReceiverStorefront
T he following command removes the SmartAuditor agent component.
XenAppSetupConsole.exe /uninstall:SmartAuditorAgentFeature
If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp configuration automatically
installs the database.
Important:
Citrix does not support case-sensitive databases.
T o avoid corruption, do not directly edit data in the data store database with utilities or tools other than those provided
by Citrix.
Most database maintenance requires running the dsmaint and dscheck server utilities on XenApp farm servers. T he XenApp
Server Utilities Reference contains syntax and use details.
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.
T he 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.
T he 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.
T he 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
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).
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. T herefore, 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.
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 T CP/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 T CP/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.
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.
T he 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. T he new node already has the executable files and registry information
for that instance of Microsoft SQL Server on its local disk drive, so it can start up an instance of Microsoft SQL Server and
start accepting connection requests for that instance.
Microsoft Cluster Services clustering does not support load balancing among clustered servers because it functions in
active/passive mode only.
XenApp requires data coherency across multiple databases. T herefore, 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.
T he 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.AUT HENT ICAT ION_SERVICES= (NONE). T he default setting (NT S) will cause
connection failures.
Install the Oracle client on the server where you will be installing XenApp and then restart the server before you install
XenApp.
T he 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.
T he account used to connect to the data store database has the following Oracle permissions:
Connect
Resource
Unlimited T ablespace (optional)
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.
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. T herefore, a two-phase commit algorithm is required for writes
to the database.
If the performance at the replicated database site is significantly slower, verify that all the indexes for the user’s schema
are successfully replicated.
T he following table lists the supported XenApp versions for the source farm and the new farm.
XenApp 5 for Windows Server 2003 (with minimum HRP5) or XenApp 5 for XenApp 6.5
Windows Server 2008
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. T hen, 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.)
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 perform an indirect migration. In this case, you split the migration
T he 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.
T he source server must have network COM+ access enabled, and the MFCOM service must be available.
T o 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.
T he 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.
T he XACOM service must be available.
T he 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. T he 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.
T he 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. T his 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.
T he following software is required to run the Migration Center. T his 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. T his 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.)
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 Cmdlets for additional installation information about indirect migrations.
Application that guides you A collection of PowerShell cmdlets that you issue in a recommended sequence to set
through a series of set up, up, display, preview, and other actions.
display, preview, and other
action screens.
Imports all objects from the You can specify object types and named objects to include and exclude from the
source farm into the new migration. You can also explicitly specify 32-bit applications to be migrated; their paths
farm. * will be converted to \Program Files (x86)\ so they will launch properly in the 64-bit farm
environment.
Imports all property values You can override an object property value (setting). For example, you can specify a CPU
(settings) for all objects. * 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.)
Add, display, or remove a server mapping (valid Add-XAServerMapping, Get-XAServerMapping, Worker group
only when migrating a XenApp 5 farm) Remove-XAServerMapping mappings
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 Load evaluators and their rules are migrated. Migrated load evaluators are attached to applications
evaluator (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 When migrating from XenApp 5, configuration settings for servers specified in the server mapping file
configuration 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. T his 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.
Farm Farm configuration settings are migrated by creating an IMA Machine GPO named "Farm." T his policy is
configuration unfiltered.
Farm and server settings from the source farm are compared against the default values used when the new farm was
created. T he 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.
Only settings that reside in the IMA data store are migrated; settings that reside only in the server registry are not migrated.
5. T o manage server mappings (if you are migrating a XenApp 5 farm), click Worker group mappings. T he 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).
T o 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.
T o edit a mapping, select the entry and click Edit and then change values.
T o delete a mapping, select the entry and click Remove.
6. T o 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).
1. From the Start menu, select All Programs > Citrix > XenApp Migration > Windows PowerShell with Citrix XenApp
Migration Module. T he PowerShell console starts.
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.
1. Use the Add-XAServerMapping cmdlet to map servers in the XenApp 5 farm to worker groups in the new farm. T he
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).
T o display the server mappings you specified, use the Get-XAServerMapping cmdlet.
T o remove a server mapping, use the Remove-XAServerMapping cmdlet.
2. 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.
3. 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.
T o display the names of object properties you can specify with the Add-XASettingOverride cmdlet, use the Get-
XALegacySettingName cmdlet.
T o display the property override values you specified, use the Get-XASettingOverride cmdlet.
T o remove a property override value you specified, use the Remove-XASettingOverride cmdlet.
Remember: Previews and migrations started from either interface will the customizations (and mappings, if migrating
from XenApp 5) specified in the command-line interface, unless expressly overridden.
3. T o preview the migration (that is, see what will happen during a migration, without taking any action), enter Start-
XAMigration -PendingReportOnly.
4. Start 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. T his helps monitor equivalency between the new farm and the legacy farm. You can tailor the display to
report differences from an existing snapshot.
Note: Subsequent migrations (launched from either interface) will use the current migration options, and property value
overrides file.
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>. T o 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.
T he 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:
T he 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.
(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:
-WorkerGroupName Name of the worker group in the new farm. If the worker group does not exist, it is
name created.
For example, the following cmdlet maps the server named OfficeApps5 to the worker group named DenverAcctg.
Add-XAServerMapping -ServerName OfficeApps5
-WorkerGroupName DenverAcctg
Specifies a value for an object property (setting). T his 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.
-MatchValue Original property value to match before overriding the setting with the new value. If the value
does not match, the override is skipped.
For example, the following cmdlet specifies a CPU priority level of "high" for migrated applications in the new farm.
Add–XASettingOverride CpuPriorityLevel High
T he following cmdlet changes the CommandLineExecutable property value to C:\Program Files\T est\T est.exe when its
current value is C:\ProgramFiles (x86)\T est\T est.exe.
Add-XASettingOverride -PropertyName
CommandLineExecutable -ObjectType Application
-Value " C:\Program Files\Test\Test.exe"
-MatchValue " C:\Program Files (x86)\Test\Test.exe"
Lists the settings you can use with the Add-XASettingOverride cmdlet. You can specify the following options:
For example, the following cmdlet gets a list of valid settings that contain "LicenseServer" in the property name.
Get-XALegacySettingName *LicenseServer*
T he 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*
Displays counts of objects in the source and new farms. Use the -ImportOnly option to generate the differences from an
existing snapshot.
Lists migration options (that is, migration options previously specified with Set-XAMigrationOption cmdlets).
Lists setting overrides (that is, object property values previously specified with Add– XASettingOverride cmdlets).
(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).
Removes a setting override (that is, an object property value previously specified with an Add-XASettingOverride cmdlet).
- Name of the server in the source farm from which objects will be exported. T his value is used if
RemoteServerName you do not specify the -RemoteServerName option in the Start-XAMigration cmdlet, or a server
name in the source farm when using the graphical interface.
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 to the folder where exported data from the source farm is placed. If the folder does not
path 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. T his option is used with the – Include and – Exclude options, which specify object
object-type names.
Valid values are: Administrator, Application, FarmConfiguration, Folder, LoadEvaluator, Policy, and
ServerConfiguration.
If you exclude folder objects from the migration, application folders that contain applications
will be migrated, in order to preserve the structure and prevent duplication. However, server
folders and application folders that do not contain applications will not be migrated.
-Include object- Object names to include in the migration. T his option is used with the – ObjectType option.
-Exclude object- Object names to exclude from the migration. T his option is used with the – ObjectType option.
name Separate multiple object names with commas. You can use wildcards.
-Enabled $false | Provides an alternative to using the -Exclude * option to exclude all objects specified with the -
$true ObjectType option from the migration.
-X86ApplicationList 32-bit application to be migrated. T he path for this application will be converted from \Program
application Files\ to \Program Files (x86)\. Separate multiple application names with commas. You can use
wildcards.
For example, the following cmdlet uses the -ObjectT ype and -Exclude options to exclude applications named "A1" and "A2"
from the migration.
Set-XAMigrationOption –ObjectType Application
–Exclude A1, A2
T he following cmdlet uses the -ObjectT ype, -Include, and -Exclude options to include all applications with a name
containing "Microsoft" except "Office."
Set-XAMigrationOption –ObjectType Application
–Include *Microsoft* –Exclude *Office*
T he following cmdlet uses the -ObjectT ype and -Enabled options to disable migration of all applications.
Set-XAMigrationOption –ObjectType Application
–Enabled $false
T he 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*
Starts a migration or migration preview. You can specify the following options:
- Name of the server in the source farm from which objects will be exported.
RemoteServerName
If you do not specify this option, but you specified a -RemoteServerName option in the Set-
name
XAMigrationOption cmdlet, or a server in the source farm when using the graphical interface,
that name is used.
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.
T his 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.
T his option is generally used only during an indirect migration; see Indirect Migrations and
Advanced Cmdlets.
T his option is generally used only during an indirect migration; see Indirect Migrations and
Advanced Cmdlets.
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:
1. 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).
2. 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.
3. 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.)
4. 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.
5. Export settings with a Start-XAMigration -ExportOnly cmdlet. T he 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. T his 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.
T he Start-XAMigration cmdlet is intended for scripted, unattended migrations. For interactive testing, the Migration Center
includes additional object-specific import cmdlets. T hese cmdlets offer alternatives to using the – ImportOnly option with
the Start-XAMigration cmdlet and the -ObjectType and -Include options with the Set-XAMigrationOption cmdlet.
T hese cmdlets use the configured server mappings (when migrating a XenApp 5 farm), migration options, and object
property value overrides.
* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm.
Using the advanced XALegacy cmdlets can be helpful if an object did not migrate as expected. T he 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.
* Valid only when migrating a XenApp 6.0 farm or a XenApp 6.5 test/pilot farm.
T hese 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). T his greater granularity may be helpful when troubleshooting
migration, because these objects are more complex, with multiple sets of properties.
Management Describes the Citrix tool set for managing servers, farms, published resources, and connections.
Console and Other You can launch all tools by accessing the Citrix program group on the Start menu.
T ools
Delivering XenApp How to implement the Windows Desktop Experience, including a Windows 7 look and feel to
to Software Service desktops.
Subscribers
Working with Citrix How to control the XenApp experience through specific policies and policy settings.
Policies
Citrix Policies
Reference
Managing Session Manage, define, monitor, and optimize the XenApp end user sessions.
Environments and
Connections
Maintaining Server Describes XenApp farm maintenance tasks, such as monitoring CPU usage, updating the License
Farms Server settings, using Worker Groups, and so on.
Understanding Provides XenApp printing concepts and how to implement printing in your XenApp environment.
XenApp Printing
Configuring and
Maintaining XenApp
Printing
Manage Power and Describes XenApp Power and Capacity Management to help reduce power consumption and
Capacity 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
Performance Describes how to use the Window Performance Monitor to observe performance counters
Counters Reference associated with sessions, networking, and security.
Citrix Auto Support Provides a free online troubleshooting platform for your Citrix environment. Citrix Auto Support
quickly analyzes your log files, profiles your environment, and scans for known issues, providing
customized advice for a solution.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the
request.
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 T asks pane, select the tasks you want to delegate to the
custom 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:
T o change an administrator's privilege level, open the Privileges page
T o assign or update custom permissions, open the Permissions page
Disable a Citrix administrator if you want to temporarily remove access for an administrator but retain the account and
settings.
When an administrator is disabled, the administrator icon appears in grey and an Enable task becomes available.
1. Select the administrator whose privileges you want to enable and then, on the Actions pane, click Enable.
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.
You can delegate tasks through the Citrix AppCenter by associating custom Citrix administrator accounts with permissions
Citrix recommends you create Windows, Active Directory, or NDS groups to assign these permissions. When you create
custom Citrix administrators, simply select the group instead of individual users. T his 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. T o grant permissions to applications and servers, you
must first place the applications or servers in folders and then grant permissions at the folder level. T herefore, 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: T o apply the same permissions to a new folder as to its parent folder, select the Copy permissions from the parent
folder option when you create the new folder.
To delegate tasks to existing custom administrators
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. T o 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 T asks, then Permissions. T he resulting dialog box lists the administrators who
currently have access to the selected folder.
4. T o 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.
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. T his allows you to change the administrator's permissions.
6. With the administrator selected, use the check boxes to change specific permissions in the T asks pane.
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. T his
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.
XenApp provides settings to ensure sessions remain reliable. You can also monitor users’ sessions, and their sessions’ status,
by shadowing.
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
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.
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 T emplates > System > Remove Boot / Shutdown / Logon / Logoff status messages
Administrative T emplates > System > Verbose versus normal status messages
However, Active Directory group policies take precedence over equivalent local group policies on servers. T herefore, 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.
T he PowerShell scripts used to install and configure these features are located at %Program Files (x86)%\Citrix\App Delivery
Setup Tools.
T he Infrastructure Setup feature enables service providers to deploy XenApp farms quickly, add tenants, and add servers as
needed to manage farm capacity. T o 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
T he following components must be present in your environment and configured prior to executing the scripts:
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
T he 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. T he 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 T ools folder (including the Citrix AppCenter)
Creates a new Windows T heme file and sets the default wallpaper
Starts the Windows T hemes 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.
Extra color compression improves the display of images based on a bandwidth threshold being reached. T his feature
provides a flexible means for Citrix Service Providers to optimize image display according to users' connections.
To configure extra color compression, create or edit a User policy and enable the Extra Color Compression setting. Add the
Extra Color Compression T hreshold setting and enter the value, in kilobits per second, below which compression is applied.
For more information about delivering hosted desktops, refer to the following resources:
— Citrix Cloud App Delivery Setup Tools Administration Guide
provides information about the Infrastructure Setup and Enhanced Desktop Experience features, including requirements
and script usage. T his 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.
T he 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 perform this task, run the New-CtxManagedDesktopGPO script from a XenApp server in your deployment. T his script is
located at %Program Files (x86)%\Citrix\App Delivery Setup Tools.
CtxStartMenuT askbarUser User Changes the pinned shortcuts on the T askbar and configures the Start menu
to match a Windows 7 environment. T his GPO includes a script that
executes when a user logs on to the server for the first time. T o ensure the
script executes correctly, the PowerShell execution policy on the server must
be set to AllSigned.
CtxPersonalizableUser User Enables users to change the desktop wallpaper. Prevents users from
installing programs, viewing properties, scheduling tasks, or shutting down the
server. Used with the CtxRestrictedComputer GPO.
CtxRestrictedUser User Includes the restrictions in the CtxPersonalizableUser GPO and prevents
users from modifying desktop wallpaper and Start menu and T askbar
settings. Used with the CtxRestrictedComputer GPO.
CtxRestrictedComputer Computer Prevents users from accessing the T ask Manager, Administrative T ools,
Windows Update, Help and Support, and removable drives. Used with either
the CtxPersonalizableUser or CtxRestrictedUser GPOs.
1. On the XenApp server, run the New-CtxManagedDesktopGPO script from the PowerShell command line.
2. Launch the Group Policy Management Console (click Run, then type gpmc.msc).
3. In the left pane, locate the OU containing the tenant's user accounts and perform the following actions:
1. Right-click the OU and select Link an Existing GPO.
2. Select the following GPOs:
CtxStartMenuT askbarUser
CtxPersonalizableUser or CtxRestrictedUser
3. Click OK.
4. Expand the OU and then select each linked GPO. On the Scope tab, verify the tenant's users are included.
4. Locate the OU containing the XenApp servers you want to target and perform the following actions:
1. Right-click the OU and select Link an Existing GPO.
2. Select the CtxRestrictedComputer GPO.
3. Click OK.
4. Expand the OU and then select the linked GPO. On the Scope tab, verify the XenApp servers are included.
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.
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). T he 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).
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. T he settings you
configure affect the GPOs you specify through the Group Policy Management Console.
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. T he settings
you configure are stored in a farm GPO in the data store.
However, in the event of a conflict, policy settings that are processed last can overwrite those that are processed earlier.
T his 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. T his happens because Policy B was processed at the domain level and Policy
A was processed at the XenApp farm GPO level.
Note, however, that when a user launches an ICA or Remote Desktop Protocol (RDP) session, Citrix session settings
override the same settings configured in an Active Directory policy or using Remote Desktop Session Host Configuration.
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.
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.
T he 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
To search the entire catalog of settings or filters, select All Settings or All Filters.
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.
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.
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, the policy is not created. T he settings you selected are
retained; however, you must run the policy wizard again. 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 check box 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.
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
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.
When selected, each template displays the following information tabs beneath the templates list:
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. T his tab is displayed only when a built-in template is selected.
Templates can include either Computer settings or User settings. You cannot include both types of settings in a template.
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. T his 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 T emplates tab and then click Actions > Import . T he Import T emplate dialog box appears.
3. Select the template file you want to import and click Open. T he 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
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 T emplates tab and then select the template you want to export.
3. Click Actions > Export. T he Export T emplate 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.
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 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.
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.
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. T his 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
.s
You can add settings to policies by 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. T he 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. T he configured setting appears on the Settings tab of the console in the
Active Settings view.
You can add as many filters as you want to a policy, based on a combination of criteria. T he availability of certain filters
depends on whether you are applying a Computer policy or a User policy. T he following table lists the available filters:
12.0.0.0
12.0.0.*
12.0.0.1-12.0.0.70
12.0.0.1/24
IPv6 Examples:
2001:0db8:3c4d:0015:0:0:abcd:ef12
2001:0db8:3c4d:0015::/54
User or Group Applies a policy based on the user User policies only
or group membership of the user
connecting to the session.
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. T he 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. T he 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. T he following examples illustrate how filter
modes affect Citrix policies when multiple filters are present.
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:
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.
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:
When the Sales manager logs on to the farm from the office, the policy is applied because the connection satisfies both
filters.
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.
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.
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. T his 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.
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. T his 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.
Prioritizing policies allows you to define the precedence of policies when they contain conflicting settings. T he 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
T he 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.
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.
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.
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.
T he 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.
T he 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.
Troubleshooting Policies
Users, IP addresses, and other filtered objects can have multiple policies that apply simultaneously. T his 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. T his occurs when:
No policies have filters that match the policy evaluation criteria
Policies that match the filter do not have any settings configured
Policies that match the filter are disabled
If you want to apply policy settings to the connections that meet the specified criteria:
Make sure the policies that you want to apply to those connections are enabled
Make sure the policies that you want to apply have the appropriate settings configured
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.
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. T he Modeling Results tab in the middle pane displays the report,
grouping effective Citrix policy settings under User Configuration and Computer Configuration headings.
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.
For Citrix XenApp to filter on NetScaler Gateway connections, you must complete all of the following:
Create one or more filters in NetScaler Gateway. See the NetScaler Gateway section of Citrix eDocs for more
information about creating filters.
Note: You must be using Access Gateway Enterprise Edition version 9.1, 9.2, or 9.3 or NetScaler Gateway versions 10.1 or
10.5 to create filters that work with XenApp.
For published applications, select Allow connections made through Access Gateway Advanced Edition in the application
properties.
Ensure that your farm is configured to allow NetScaler Gateway connections, which it is by default.
Create a Computer policy within XenApp that has the T rust XML requests policy setting enabled.
Create a User policy within XenApp that includes a filter referencing v Gateway filters.
Note
T WAIN 2.0 is not currently supported.
Users can connect regardless of connection type. However, XenApp requires the following for T WAIN support:
T he scanner can be attached locally or added using the network.
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 T WAIN redirection for 32-bit T WAIN applications only. XenApp does not
support 16-bit T WAIN drivers.
T he Client T WAIN device redirection policy setting must be added to the appropriate policy. T o configure image
compression, add the T WAIN compression level setting and select the appropriate compression level.
T he following table lists the T WAIN hardware and software tested with XenApp. While other T WAIN devices may work,
only those listed are supported.
Fujitsu fi-6140
HP ScanJet 8250
IRIScan Express 2
OmniPage SE
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. T his
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.
XenApp provides settings to ensure sessions remain reliable. You can also monitor users’ sessions, and their sessions’ status,
by shadowing.
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. T he client drives are displayed with
descriptive names so they are easy to locate among other network resources. T hese drives are used by Windows Explorer
and other applications like any other network drive.
In Citrix policies,
— redirection
settings are used for mapping.
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.
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. T his 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 run
permission. T o enable users to run 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\SYST EM\CurrentControlSet\services\picadm\Parameters\ExecuteFromMappedDrive.
3. T o grant users run permission on mapped drives, set ExecuteFromMappedDrive to 1.
4. T o deny users run permission on mapped drives, set ExecuteFromMappedDrive to 0.
5. Restart the server.
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.
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 determine which server contains the public folder
where the user saved the document.
To enable Special Folder Redirection
First, enable Special Folder Redirection for XenApp Web sites or XenApp Services sites - you can enable Special Folder
Redirection for all users, and allow users to enable the feature themselves in their client settings. T hen, if you want to allow
or prevent specific users from having redirected special folders, use the Special Folder Redirection Citrix policy setting.
If you enable Special Folder Redirection without success, use Search to determine if any settings conflict with this feature.
T ip: 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.
T his procedure requires that you already created a XenApp Web site.
1. From the Citrix Web Interface Management console, select a XenApp Web site.
2. In the Actions menu, select Session Settings.
3. On the Manage Session Settings - XenApp page, select Local Resources.
4. Select the correct options.
Enable Special Folder Redirection by default and let users turn it off in Provide Special Folder Redirection to all
their session options. users
Disable Special Folder Redirection by default, but let users turn it on in Allow users to customize Special Folder
their session options Redirection
Enable Special Folder Redirection by default and prevent users from Provide Special Folder Redirection to all
turning it on or off users
5. Click OK.
T his procedure requires that you already created a XenApp Services site.
1. From the Citrix Web Interface Management console, select a XenApp Services site.
2. Select Session Options.
3. On the Change Session Options - PNAgent page, select Local Resources.
4. Select the correct options.
Enable Special Folder Redirection by default and let users turn it off in Provide Special Folder Redirection to all
their session options. users
Disable Special Folder Redirection by default, but let users turn it on in Allow users to customize Special Folder
their session options Redirection
Enable Special Folder Redirection by default and prevent users from Provide Special Folder Redirection to all
turning it on or off users
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).
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: T o 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.
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 Delivery Services Console, 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.
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.
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
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:
Low - for low-speed connections. T his causes any sounds sent to the client device to be compressed to a maximum
of 16Kbps. T his compression results in a significant decrease in the quality of the sound. T he 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. T his is recommended for most LAN-based connections. T his setting causes any
sounds sent to the client device to be compressed to a maximum of 64Kbps. T his compression results in a moderate
decrease in the quality of the sound played on the client device.
High - high definition audio. T his is recommended for connections where bandwidth is plentiful and sound quality is
important. T his 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. T ransmitting this amount of data can increase bandwidth
requirements, and result in increased CPU utilization and network congestion.
For users to use speaker and microphones in sessions, both audio input (for microphones) and output (for speakers) must be
enabled. Audio input and output are controlled by two policy settings; you must configure both to ensure that audio input
and output are enabled.
Note: Microphone input is supported on the Citrix online plug-in for Windows, Windows CE, and Linux.
T his 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. T his 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. T o enable audio input for sessions, configure the Client microphone redirection Citrix User policy setting.
2. T o enable audio output for sessions, configure the Client audio redirection Citrix User policy setting.
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
To enable Phillips SpeechMike devices, go to the Philips web site for information and software downloads.
Note: T he 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:
Medium - optimized for speech
High - high definition audio
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. T hrough 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 of f . 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.
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.
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.
T his 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. T he 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.
Note: You can use Session Reliability with Secure Sockets Layer (SSL).
By default, Session Reliability is enabled. You can disable Session Reliability or explicitly enable and customize it with policy
settings:
T he Citrix Computer policy Session reliability connections setting allows or prevents session reliability.
T he Session reliability timeout setting has a default of 180 seconds, or three minutes. T hough 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 policy Session reliability
timeout setting. After that, the Auto Client Reconnect policy settings take effect, attempting to reconnect the user to
the disconnected session.
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 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. T he server decrypts the credentials and submits them to Windows logon for authentication. When cookies
expire, users must reauthenticate to reconnect to sessions.
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.
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.
T he 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. T his process requires users to enter
their credentials to log on to the server.
Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled, if XenApp
detects no activity (for example, no clock change, no mouse movement, no screen updates), this feature prevents Remote
Desktop Services from disconnecting that session. XenApp sends keep-alive packets every few seconds to detect if the
session is active. If the session is no longer active, XenApp marks the session as disconnected.
However, the ICA Keep-Alive feature does not work if you are using Session Reliability. Session Reliability has its own
mechanisms to handle this issue. Only configure ICA Keep-Alive for connections that do not use Session Reliability.
ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy.
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.
T he 60 second default interval causes ICA Keep-Alive packets to be sent to client devices every 60 seconds. If a client
device does not respond in 60 seconds, the status of the ICA sessions changes to disconnected.
ICA keep alives. Sends or prevents sending ICA keep-alive messages periodically.
T o use session linger for named user sessions, configure the following Citrix User policy settings:
Linger T erminate T imer 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 T imer 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 T imer 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. T herefore, if the Linger
Terminate T imer Interval and Linger Disconnect T imer Interval policy settings are used, the effective Linger Terminate T imer
Interval setting is the same as the Linger Disconnect T imer Interval setting.
For a non-seamless named user session, the disconnected session remains in the disconnected state until the Linger
Terminate T imer Interval expires.
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.
When special sessions listen for requests to connect to the server, the session state display specifies that it is Listening. 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.
To reset a session, use the ICA Listener Configuration tool to disable and then enable the ICA Listener. Access this tool at
Start > Administrative Tools > Citrix > Administration Tools.
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. T o 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. T he Send Message dialog box appears.
4. Edit the title of the message, if required, and enter the message text.
To configure the ICA listener, use the Citrix ICA Client Configuration Tool (CtxICACfg.exe). For more information, see
CT X125139.
Important: Do not use Microsoft Remote Desktop Services tools to configure the ICA listener.
To monitor session inf ormation
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.
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.
T he 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.
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 T askbar 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. T he Shadow taskbar cannot function in seamless
mode.
Example: To create a user policy for user-to-user shadowing and assign it to users
T his 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. T his 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.
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. T o 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.
After configuring XenApp, you can enable shadow logging and configure shadow logging output to one of two locations
on the server:
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.
XenApp Policies
Policies let you define how you want users 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 user
connections. T his GPO template lets you configure rules for network routing, proxy servers, trusted server configuration,
user routing, remote user devices, and the user experience. For more information, see the Citrix Receiver for Windows
documentation.
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 NetScaler Gateway. T his allows you to benefit from filters created in
NetScaler Gateway.
1. Configure the Connection access control Computer policy setting with one of the following options:
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).
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.)
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.
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.
You might want to prevent logons to a server when you install software or perform other maintenance or configuration
tasks. T his 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.
Network latency and bandwidth availability can impact the performance of connections to published applications and
content. T hese HDX technologies allow you to improve connection speed and responsiveness during user sessions.
Instructions for configuring these features are provided in the corresponding topics:
MDX MediaStream Multimedia Acceleration. Allows you to control and optimize the way XenApp servers deliver
streaming audio and video to users.
HDX MediaStream Flash. Allows you to control and optimize how XenApp servers deliver Adobe Flash animations to
users.
HDX 3D Image Acceleration. Enables you to adjust the quality of photographic image files as they appear on client
devices and the amount of bandwidth the files consume on their way from the server to the client.
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 T ext 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.
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. T he 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. T his reduces bandwidth consumption and leaves the media for the client device to decompress and render, thereby
reducing server CPU utilization.
HDX MediaStream Multimedia Acceleration optimizes multimedia files that are encoded with codecs (compression
algorithms) that adhere to Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation standards.
DirectShow and Media Foundation are application programming interfaces (APIs) that allow, among other things,
multimedia playback. To play back a given multimedia file, a codec compatible with the encoding format of the multimedia
file must be present on the client device.
Generally, if you can play back a given multimedia file locally on a given client device, you can play back the same file on the
same client device within a session. Users can download a wide range of codecs, such as those supported by Windows
Media Player or RealOne Player, from vendor Web sites.
Users accessing audio-visual applications on servers on which HDX MediaStream Multimedia Acceleration is enabled use a
little more memory but far less bandwidth than when this feature is disabled. Users use only a little more memory or
bandwidth when accessing audio-visual applications compared to regular enterprise applications.
To allow users to run multimedia applications in ICA sessions, turn on audio or give the users permission to turn on audio
themselves in Citrix Receiver. By default, all other plug-ins and methods are configured with audio enabled and optimized for
speech sound quality.
Note: T o 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.
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. T his 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.
Note: By default, audio is disabled on the user device. T o allow users to run multimedia applications in sessions, turn on
audio or give the users permission to turn on audio themselves on their devices.
You can use the following the settings to configure Windows Media Redirection:
Users playing Flash content in published applications might observe poor rendering quality of the animation, slow session
responsiveness, or a combination of both. T his 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). T his 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.
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. T he 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.
T his 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:
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.
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. T his initial display is then sharpened up to normal quality in the background if the image is not immediately
changed or overwritten in the application. T he 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.
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.
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 T ext Echo.
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: T o 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.
T hrough 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.
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
Note: T he 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: T he 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 T ools > 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. T o 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. T he application
must be running when you select it.
Click the Browse button and navigate to the application.
4. Specify whether Local T ext Echo is enabled or disabled on the application by selecting or clearing the Enable local text
echo for this application check box.
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 T ext 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 T ools > SpeedScreen Latency Reduction Manager.
2. From the Application menu, select Server Properties.
T he 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.
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 T ools > SpeedScreen Latency Reduction Manager.
2. Select an application.
3. From the Applications menu, select Properties. T he Application Settings window appears.
4. Select the Input Field Configuration tab, then configure these settings as needed.
T he 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. T he 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. T his 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 T ext Echo. If this check box is selected, you can apply more
Local T ext 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.
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. T he 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: T he application must be running before you can configure an input field within it.
1. Start the application.
2. Select Start > All Programs > Citrix > Administration T ools > SpeedScreen Latency Reduction Manager.
3. From the Applications menu in SpeedScreen Latency Reduction Manager, select Properties. T he Application Settings
window appears.
4. Select the Input Field Configuration tab. Click New to start the wizard and follow the prompts.
5. With the application running, select the input field you want to configure and complete these steps:
1. Drag the pointer onto the input field window for which SpeedScreen behavior needs to be customized.
2. If the SpeedScreen Latency Reduction Manager window is obscuring the target input field, check the Hide
SpeedScreen Latency Reduction Manager check box. T his causes the SpeedScreen Latency Reduction Manager
window to be hidden from view.
6. T o 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.
T he default compatibility level is Auto, which provides full SpeedScreen Latency Reduction functionality. However,
because the field being configured is not displaying the desired behavior, downgrade the latency reduction functionality
level to Medium, Low, or Off.
Medium Compatibility. Use this level of compatibility for input fields that are incompatible with the default Auto
setting. T ext 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.
Quick Links
T he 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.
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\SOFT WARE\Citrix\HdxMediaStreamForFlash\Server\PseudoServer
Caution: Flash Redirection requires significant interaction between the user device and server components. T herefore, 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. T herefore, Flash Redirection should be enabled only if the Flash Player
itself is secured.
T he 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). T hose devices can access the
legacy Flash Redirection features only. T his is done by providing two separate virtual channels, one for each generation of
Flash Redirection, on the servers and user devices. T he 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 and Legacy mode on a server Legacy mode
T he Enable HDX MediaStream Flash Redirection on the user device setting on the user device must also be enabled.
T he Citrix User Policy setting Flash Default Behavior lets you establish the default behavior of Flash acceleration. T he
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.
Option Behavior
Block Flash T he user cannot view any Flash content. Second generation and Legacy mode Flash Redirection, and
player server-side rendering are not used.
Disable T he user can view server-side rendered Flash content if Flash Player for Windows Internet Explorer
Flash compatible with the content is installed on the server. Second generation and Legacy mode Flash
acceleration Redirection is not used.
Enable Flash Flash Redirection is used. Second Generation is available where its requirements are met. Legacy mode is
acceleration available when backwards compatibility is enabled.
Enable Flash acceleration is the default and will be used if no option is selected.
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.
T he Flash latency threshold policy setting only applies to Legacy mode features. T his 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. T his 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.
T he 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.
Flash Redirection downloads Flash content to the user device where it is played. T he 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 T ime Messaging Protocols (RT MP).
Instead, server-side rendering for such sites is used.
T his setting works with the Enable server-side content fetching setting on the user device.
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/*.
T he 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.
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 specif y where Flash content renders
T he 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/*).
T he 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.
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. T he following are common to all events
logged by Flash Redirection:
Flash Redirection reports events to the Application log.
T he Source value is Flash.
T he 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.
To enable and disable the Legacy mode HDX MediaStream Flash Redirection f rom 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.
Using the Flash background color list Citrix User Policy setting, you can match the colors of Web pages and Flash instances.
T his 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.
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: T he 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 T emplates and Classic Administrative T emplates (ADM) nodes and select HDX MediaStream
Flash Redirection - Client.
3. From the Setting list, select Enable HDX MediaStream Flash Redirection on the user device and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you selected Enabled, from the Use HDX MediaStream Flash Redirection list, select Always, Ask, Never, or Only with
Second Generation.
Note: Selecting Ask results in users receiving the Citrix Receiver - Flash dialog box the first time they access Flash content
in each session in which the user can enable Flash Redirection. If the user does not enable Flash Redirection, the Flash
content is played on the server. Selecting Always, Never, and Only with Second Generation does not result in this dialog
box. Select Always to always use Flash Redirection to play Flash content on the user device. Select Never to never use
Flash Redirection and have Flash content play on the server. Select Only with Second Generation to use the latest Flash
Redirection functionality when the required configuration is present and revert to server-side rendering when the
required configuration is not present.
6. For the policy to take effect:
Computer Conf iguration: Changes take effect as computers in the organizational unit restart.
User Conf iguration: Users in the organizational unit must log off and then log on to the network.
Display specific choices for the user in the Citrix Receiver - Flash dialog box based on how you configure Flash Redirection
on the user device. T he following all refer to configuring Enable HDX MediaStream Flash Redirection on the user device:
If Citrix Receiver detects the user device does not have the required version of the Adobe Flash Player (
Enable synchronization of the client-side HT T P cookies with the server-side in order to download HT T P cookies from the
server. T hese HT T P 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 T emplates and Classic Administrative T emplates (ADM) nodes and select HDX MediaStream
Flash Redirection - Client.
3. From the Setting list, select Enable synchronization of the client-side HT T P cookies with the server-side and click policy
setting.
4. Select Not Configured, Enabled, or Disabled.
5. For the policy to take effect:
Computer Conf iguration: Changes take effect as computers in the organizational unit restart.
User Conf iguration: Users in the organizational unit must log off and then log on to the network.
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.
Note: Server-side content fetching does not support Flash applications using Real T ime Messaging Protocols (RT MP).
Instead, server-side rendering for such sites is used.
T he second generation of Flash Redirection introduces three new enabling options as described in the following table. T wo
of these options include the ability to cache server-side content on the user device. T his improves performance because
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 Enables server-side content fetching for Web pages and Flash applications identified in the Flash server-
(persistent side content fetching URL list. Server-side content fetching fallback is available. Content obtained
caching) through server-side fetching is cached on the user device and stored from session to session.
Enabled Enables server-side content fetching for Web pages and Flash applications identified in the Flash server-
(temporary side content fetching URL list. Server-side content fetching fallback is available. Content obtained
caching) through server-side fetching is cached on the user device and deleted at the end of the session.
Important: T he 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 T emplates and Classic Administrative T emplates (ADM) nodes and select HDX MediaStream
Flash Redirection - Client.
3. From the Setting list, select Enable server-side content fetching and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you enabled this setting, choose an option:
Disabled
Enabled
Enabled (persistent caching)
Enabled (temporary caching)
6. For the policy to take effect:
Computer Conf iguration: Changes take effect as computers in the organizational unit restart.
User Conf iguration: Users in the organizational unit must log off and then log on to the network.
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
1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node.
2. Expand the Administrative T emplates and Classic Administrative T emplates (ADM) nodes and select HDX MediaStream
Flash Redirection - Client.
3. From the Setting list, select URL rewriting rules for client-side content fetching and click policy setting.
4. Select Not Configured, Enabled, or Disabled.
5. If you enabled this setting, click Show and using Perl regular expression syntax, type the matching pattern in the Value
name box and the replacement pattern in the Value box.
6. For the policy to take effect:
Computer Conf iguration: Changes take effect as computers in the organizational unit restart.
User Conf iguration: Users in the organizational unit must log off and then log on to the network.
(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:
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. T o 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 device that cannot support the requested parameters.
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.
Generally, higher sound quality requires more bandwidth and greater server CPU utilization. You can use sound compression
to balance sound quality and overall session performance. Use policy settings to configure the compression levels you want
to apply to sound files.
Consider creating separate policies for groups of dial-up users and for those who connect over a LAN or WAN. Over dial-up
connections, where bandwidth typically is limited, users likely care more about download speed than sound quality. For such
users, create a policy for dial-up connections that applies high compression levels to sound and another for LAN or WAN
connections that applies lower compression levels.
Configure the Audio quality setting by choosing from these audio quality levels:
Low - for low-speed connections for low-bandwidth connections. Sounds sent to the client are compressed up to
16Kbps. T his compression results in a significant decrease in the quality of the sound but allows reasonable performance
for a low-bandwidth connection.
Select Medium - optimized for speech for delivering Voice over IP applications. Audio sent to the client is compressed up
to 64Kbps. T his 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 (RT P) 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. T his 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
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.
T he Client audio redirection setting must be enabled for an enabled Client microphone redirection to work.
For security, users are alerted when servers that are not trusted by their user devices try to access microphones. Users can
choose to accept or reject access prior to using the microphone. Users can disable the alert on the Citrix Receiver, formerly
the Citrix online plug-in.
Configure the Client microphone redirection setting by choosing Allowed, the default, or Prohibited.
When using XenApp, the Audio Plug-n-Play setting must be enabled to use multiple input devices.
Important: You must also enable audio on Client audio settings on the user device.
To set audio redirection bandwidth limits
You can set limits on the allowed bandwidth in kilobits for playing and recording audio. Use the Audio redirection bandwidth
limit setting to identify a specific maximum kilobit per second bandwidth for a session. Use the Audio redirection bandwidth
limit percent to identify the maximum percentage of the total available bandwidth to be used. If both settings are
configured, the one with the lowest bandwidth limit is used.
Configure the Audio redirection bandwidth limit and Audio redirection bandwidth limit percent by typing a number in the
Value field.
Important: You must also enable audio on Client audio settings on the user device.
To send and receive audio with UDP
XenDesktop allows you to send and receive lossy audio with UDP using RT P.
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.
Important: You must also enable audio on Client audio settings on the user device.
1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node.
2. Expand the Administrative T emplates and Classic Administrative T emplates (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-T ime T ransport.
8. For UDP audio only, set the range of ports to use to pass through the Windows firewall. T his range must be consistent
with the range set in the Audio UDP Port Range machine policy.
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 RealT ime 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. T he High - high definition audio setting is intended for music playback, rather than conference
speech and should be avoided for conferences.
T he effectiveness of echo cancellation is sensitive to the distance between the speakers and the microphone. T hese
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.
T he 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.
T he following conditions are required to use the HDX RealT ime 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. T his 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.
Note: Only one web camera is supported at a time. If a device has multiple web cameras attached, HDX RealT ime tries
the first camera found, continuing in succession until a connection is made.
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.
Client microphone redirection is a Citrix User Policy setting. It allows or prevents the redirection of microphones. Client
microphone redirection is enabled by default.
Multimedia conferencing is a Citrix Computer Policy setting. T his policy allows or prevents support for multimedia
conferencing applications. By default, Multimedia conferencing is enabled.
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.
HDX 3D allows graphics-heavy applications running on XenApp 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. T his 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.
HDX 3D supports sharing graphics cards by multiple users. When HDX 3D is used in conjunction with XenServer GPU
Passthrough, a single server hosts multiple graphics cards, one per virtual machine.
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.
HDX 3D allows graphics-heavy applications running on XenApp to render on the server's GPU. By moving OpenGL rendering
to the server's GPU, the server's central processing unit (CPU) is not slowed by graphics rendering. In addition, the server is
able to process more graphics because the workload is split between the CPU and GPU. T he XenApp 6.5 OpenGL GPU
Sharing Feature Add-on requires no special settings.
You can install multiple GPUs on a XenApp server, either by installing a graphics card with more than one GPU, or by installing
multiple graphics cards with one or more GPUs each. Mixing heterogeneous graphics cards on the server is not
recommended.
Note: Virtual machines require direct passthrough access to a GPU, which is available with Citrix XenServer or VMware
vSphere. When HDX 3D is used in conjunction with GPU passthrough, each GPU in the server supports one multi-user
XenApp virtual machine.
Most users do not require the rendering performance of a dedicated GPU, so OpenGL GPU Sharing enables multiple
concurrent sessions to share GPU resources. T his functionality does not depend any specific graphics card. When running on
a hypervisor, select a hardware platform and graphics cards that are compatible with your hypervisor's GPU passthrough
implementation. T he list of hardware that has passed certification testing with XenServer GPU Passthrough is available at
http://hcl.vmd.citrix.com/GPUPass-throughDeviceList.aspx. When running on bare metal, XenApp distributes the user
sessions across eligible GPUs; to guarantee that all installed GPUs are eligible, use identical GPUs.
Scalability using OpenGL GPU Sharing depends on the applications being run, the amount of video RAM they consume, and
the graphics card's processing power. For example, scalability figures in the range of 8-10 users have been reported on
NVIDIA Q6000 and M2070Q cards running applications such as ESRI ArcGIS. T hese cards offer 6 GB of video RAM. Newer
NVIDIA GRID cards offer 8 GB of video RAM and significantly higher processing power (more CUDA cores). Other
applications may scale much higher, achieving 32 concurrent users on a high-end GPU.
Note: Some applications handle video RAM shortages better than others. If the hardware becomes extremely overloaded,
this could cause instability or a crash of the graphics card driver. Limit the number of concurrent users to avoid hitting the
ceiling on resource allocation.
You can confirm that GPU acceleration is occurring using a third-party tool such as GPU-Z. GPU-Z is available at
http://www.techpowerup.com/gpuz/.
T he XenApp 6.5 OpenGL GPU Sharing Feature Add-on can be installed on any XenApp 6.5 system, regardless of which
hotfixes are already installed. However, Citrix recommends that you install Hotfix Rollup Pack 1 or above before installing
OpenGL GPU Sharing.
T his feature add-on is packaged with Microsoft Windows Installer 3.0 as a .msp file. For more information about deploying
.msp files, see Microsoft article 884016 or visit the Microsoft Web site and search on keyword msiexec.
T his installer program complies with Microsoft User Account Control (UAC). If UAC is enabled, you must run the installer
To install this feature add-on successfully, servers must not have registry modification restrictions in place.
T his release uses the Hotfix Rollup Pack Installation Wizard to install the feature add-on.
1. Copy the feature add-on package to an empty folder on the hard drive of the XenApp server.
2. Close all applications.
3. Run the executable. T he following files are copied to your system:
%PROGRAMFILES(X86)%\Citrix\System32\CtxGraphicsHelper.dll
%PROGRAMFILES(X86)%\Citrix\System32\CtxGraphicsHelper64.dll
T he following Registry entries are automatically created:
[HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "Flag"=dword:00000014
"FilePathName"="C:\\Program Files (x86)\\Citrix\\system32\\CtxGraphicsHelper64.dll"
[HKEY_LOCAL_MACHINE\SOFT WARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper]
"Flag"=dword:00000014 "FilePathName"="C:\\Program Files (x86)\\Citrix\\system32\\CtxGraphicsHelper.dll"
T his release also provides experimental support for GPU acceleration of CUDA and OpenCL applications running in a user
session. T his support is disabled by default, but you can enable it for testing and evaluation purposes.
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. T o use the experimental CUDA acceleration features, enable the following Registry settings:
[HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "CUDA"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFT WARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper]
"CUDA"=dword:00000001
2. T o use the experimental OpenCL acceleration features, enable the following Registry settings:
[HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] "OpenCL"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFT WARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper]
"OpenCL"=dword:00000001
T he Support Forum is at http://forums.citrix.com/forum.jspa?forumID=1602.
1. From the Start menu, select Control Panel > Programs and Features.
2. Highlight the feature add-on you want to uninstall and click Uninstall.
3. Follow the directions on-screen.
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.
T he 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 traf fic
T o set quality of service for multiple streaming connections, you must configure:
Multi-Stream, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer Policy setting in XenApp.
Multi-Port Policy, a Citrix Machine Policy setting in XenDesktop and a Citrix Computer Policy setting in XenApp.
Multi-Stream, a Citrix Users Policy setting in XenDesktop and a Citrix User Policy setting in XenApp.
1. In Machine settings (XenDesktop) or Computer settings (XenApp), open the Multi-Port Policy Add Setting dialog box.
2. From the CGP default port priority list, select a priority.
3. T ype 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
T CP 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.
Windows Peek
When the cursor 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 enabled by default. You can disable and then enable the feature with the Dynamic Windows
Preview computer policy setting on the XenApp server.
T he Citrix Receiver is compatible with and functions in environments where the Microsoft Specialized Security - Limited
Functionality (SSLF) desktop security template is used. T hese 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. T o avoid this, add the following groups to the Allow Logon through Remote Desktop Services setting for
servers in the OU.
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
An important first step in securing your server farm is securing access to the servers.
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 NT FS permissions so that non-administrators do not
have Execute permission for the AppCenter executable.
To ensure that appropriate access control can be enforced on all files installed by XenApp, install XenApp only on NT FS-
formatted disk partitions.
T his feature identifies and enforces trust relations involved in client connections. T his 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.
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
T he 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.
Microsof t SQL Server Express
Windows authentication is supported for the Microsoft SQL Server Express database. For security reasons, Microsoft SQL
Server authentication is not supported. T he 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.
By default, all ICA communications are set to Basic ICA protocol encryption. T he 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/T LS encryption.
SecureICA. T he 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/T LS protocols can protect you from internal and external threats, depending on your network
configuration. Citrix recommends that you enable SSL/T LS protocols. Enabling SSL/T LS 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 T LS provides end-to-end encryption.
Both protocols are enabled on the server side, when you publish an application or resource. T he Web Interface and Citrix
Receiver automatically detect and use the settings specified on the server (that is, when you publish a resource).
T he 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. T he most secure setting out of any of the settings below is used:
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 T SCC 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 T SCC and connection policies, the
T SCC settings and the policies override the application settings.
Using SecureICA
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.
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/T LS 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/T LS encryption for traversing public networks. Unlike SSL/T LS encryption, SecureICA, used on its
own, does not provide authentication of the server. T herefore 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.
If client devices in your environment communicate with your farm across the Internet, Citrix recommends enabling SSL/T LS
encryption when you publish a resource. If you want to use SSL/T LS encryption, you must use either the SSL Relay feature
or the Secure Gateway to relay ICA traffic to the computer running XenApp.
T he 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. T he 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 T LS 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.
T he following procedure explains how to increase the level of encryption by enabling SecureICA (ICA protocol encryption)
or SSL/T LS (Secure Sockets Layer and Transport Layer Security) encryption after you publish an application.
T herefore, 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.
T he 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/T LS 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:
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.
Citrix SSL Relay can secure communications between clients, servers running the Web Interface, and XenApp servers that
are using SSL or T LS. 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.
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.
T he Citrix XML Service provides an HT T P interface for enumerating applications available on the server. It uses TCP packets
instead of UDP, which allows connections to work across most firewalls. T he Citrix XML Service is included in the server. T he
default port for the Citrix XML Service is 80.
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. T o run the SSL Relay tool, you must have the following privileges and associated
permissions:
Domain administrator
Delegated administrator
Administrator group of the local computer where you are installing the tool
A separate server certificate is required for each XenApp server on which you want to configure SSL or T LS. T he 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
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.
You can obtain and install certificates for your servers and client devices in the following ways:
Certificates from a CA bundled with the operating system. Some of the newer Windows operating systems include
native support for many CAs. If you choose to install the certificate from a bundled CA, double-click the certificate file
and the Windows Certificate Store wizard installs the server certificate on your server. For information about which
operating systems include native support, see your Microsoft documentation.
Certificates from an enterprise CA. If your organization makes a CA accessible to you for use, that CA appears in your list
of CAs. Double-click the certificate file and the Windows Certificate Store wizard installs the server certificate on your
server. For more information about whether or not your company uses an enterprise CA, consult your security team.
Certificates from a CA not bundled with the operating system. Certificates from CAs that are not bundled with your
operating system or made accessible to you by your organization must be installed manually on both the server running
Citrix SSL Relay and on each client device. For instructions about installing certificates from an external CA, see the
documentation for the servers and clients in your configuration. Alternatively, you can install certificates using Active
Directory or the IIS snap-in:
If your computers belong to an Active Directory server, you can install the certificates using Active Directory. For
instructions about how to use Active Directory to install your certificates, see your Microsoft documentation.
You can use the Microsoft Web Server Certificate wizard in the IIS snap-in to request and import a certificate. For
more information about using this wizard, see your Microsoft documentation.
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. T he 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: T he 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.
1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration T ools > Citrix SSL Relay
Configuration T ool.
2. Click the Relay Credentials tab.
3. Select the Enable SSL relay check box to enable the relay features.
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.
Software updates to XenApp 6.5 and to Secure Gateway 3.3 are available that introduce support for Versions 1.1 and 1.2 of
the Transport Layer Security (T LS) protocol. To upgrade your XenApp and/or Secure Gateway deployments, download and
apply the following software updates:
T he 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. T he SSL Relay relays
packets only to the target computers listed on the Connection tab. T he 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. T he T CP port where SSL clients connect to the SSL Relay. T he 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 T LS. T he protocol that is required is configured
using the SSL Relay configuration tool.
Important: T he latest version of T LS (v1.2) is recommended. SSL v3.0 and T LS v1.0/v1.1 are less secure and should only be
used while transitioning Citrix Receiver to the latest versions that support T LS v1.2.
Server Name. T he 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. T he T CP 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.
To modif y the destination server list
T his table lists the T CP/IP ports that the servers, Citrix Receiver, IMA Service, and other Citrix services use in a server farm.
T his information can help you configure firewalls and troubleshoot port conflicts with other software.
Citrix SSL Relay 443 See Using the SSL Relay with the Microsoft Internet
Information Service (IIS)
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 139, 1433, or 443 for See the documentation for the database software
Oracle server MS-SQL
A proxy server accepts connection requests from user 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.
Microsoft Internet Security and Acceleration (ISA) Server 2004 and 2006
iPlanet Web Proxy Server 3.6
Squid 2.6 ST ABLE 4
Microsoft Proxy Server 2.0
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. T he 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:
T he 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. T hese 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. T o 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.
T he 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\SOFT WARE\Wow6432Node\Secure\Citrix\Citrix SSL Relay, or
HKEY_LOCAL_MACHINE\SOFT WARE\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.
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). T he Ciphersuites dialog box lists the available and allowed
ciphersuites. T he SSL Relay accepts connections only from clients that support at least one of the allowed ciphersuites.
Installing additional ciphersuites is not supported.
Note: T LS v1.2 is not supported for Web Interface XML transport type SSL Relay.
Available ciphersuites are grouped into GOV (Government) or COM (Commercial). Note that GOV ciphersuites are normally
used when T LS 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.
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. T he 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.
When you install XenApp, you also install the ST A. T he ST A is embedded within the Citrix XML Service.
Important: If you are securing communications between the Secure Gateway and the ST A, ensure that you install a server
certificate on the server running the ST A and implement SSL Relay. In most cases, internally generated certificates are used
for this purpose.
To display STA perf ormance 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 T icket Authority (STA) as part of your administrative routine.
T he STA logs fatal errors to its application log, which is located in the \inetpub\scripts directory. When creating a log, the
STA uses the following format for naming log files:
stayyyymmdd-xxx.log
where yyyy is the year, mm is the month, and dd is the day of the log file creation.
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.
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/T ransport Layer Security (SSL/T LS) encryption
At the network level, when clients are communicating with your farm remotely across the Internet:
Secure Gateway
Secure T icket 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.
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. T he reader can be connected to the host computer by the serial, USB, or PCMCIA port.
Note: Attach the smart card reader before launching the ICA session. When the reader is attached after the ICA session is
launched, users must disconnect and relaunch the ICA session to use the smart card inside the session. Refer to
http://support.citrix.com/article/CT X132230 for details.
Citrix supports the use of PC/SC-based cryptographic smart cards. T hese 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. T hese 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.
Before using smart cards with XenApp, consult your smart card vendor or integrator to determine detailed configuration
requirements for your specific implementation.
T hese components are required on the device running the supported Citrix Receiver or client:
PC/SC software
Smart card reader software drivers
Smart card reader
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.
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.
To configure smart card support for Receiver or client users, see the Receiver or client documentation.
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 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.
T he User Access Control feature prompts users to enter credentials when all of the following requirements are met:
Kerberos logon is enabled on the server running XenApp
Users logging on to the computer running XenApp are members of the Administrator group on that computer
After logon, Administrator group users attempt to access network resources such as shared folders and printers
Windows supports two authentication protocols, Kerberos and NT LM, 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 NT LM 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
NT LM 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 NT LM protocol. However the NT LM 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
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:
You can configure Citrix Receiver to use Kerberos with or without pass-through authentication.
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
Determine the level of security and control you need over the configuration logs. T his 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. T his requires the permission to Edit Configuration Logging settings.
Important: T o 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:
T he Configuration Logging feature, after it is properly enabled, runs in the background as administrative changes trigger
entries in the Configuration Logging database. T he 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.
T he Configuration Logging feature supports Microsoft SQL Server and Oracle databases; for information about supported
versions, see CT X114501.
T he 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.
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. T he 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 f or 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.
T he user name connecting to the Oracle database should not begin with a number; otherwise, you cannot display the log
from the AppCenter.
Important: T o 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.
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.
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.
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.
It might 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.
T he credentials must correspond to the authentication mode you selected when you connected to the database initially.
Specifically:
Use one of the following methods to clear log entries from the Configuration Logging database:
In 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.
T he following table lists the minimum permissions required to perform the Configuration Logging tasks.
To create a report, the Citrix administrator must have the EXECUT E and SELECT permissions listed
above. When generating a report, the administrator's credentials are passed to the database
software; the account that is configured to log configuration changes is not used.
T he 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.
Before you configure the Configuration Logging database connection, grant EXECUT E permission to the sp_databases
system stored procedure to list the databases on the database server.
T he authentication mode must be the same for the database user who creates log entries in the database tables and the
IMA encryption protects administrative data used by Configuration Logging. T his 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
CT XKEYT OOL Also known as the IMA encryption utility, CT XKEYT OOL is a command-line utility you use to manage
IMA encryption and generate key files. CT XKEYT OOL is in the Support folder of the XenApp media.
Key file T he key file contains the encryption key used to encrypt sensitive IMA data. You create the key file
using CT XKEYT OOL. T o 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 T he 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 CT XKEYT OOL.
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)
Note: 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.
To store the CTXKEYTOOL Locally
1. Copy the CT XKEYT OOL.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 CT XKEYT OOL file.
3. Copy the entire Support\Resource\en folder to the new Resource folder.
You can store the CT XKEYT OOL.exe file and the Resource\en folder anywhere on your computer, provided you maintain
the same relative directory structure used on the media.
To generate a key and enable IMA encryption on the first server in a f arm
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 CT XKEYT OOL with the generate option, specifying the full UNC
If the key file generates successfully, the message “Key successfully generated" appears.
2. T o obtain the key from the file and put it in the correct location on the server, run CT XKEYT OOL 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 CT XKEYT OOL with the newkey option to use the currently loaded key and enable the key. If IMA encryption is
enabled successfully, the message “T he key for this farm has been replaced. IMA Encryption is enabled for this farm”
appears.
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. T his 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.
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. T o obtain the key from the file and put it in the correct location on the server, run CT XKEYT OOL 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 CT XKEYTOOL 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.
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
CT XKEYT OOL 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 CT XKEYT OOL 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 CT XKEYT OOL 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 CT XKEYTOOL with the enable option. After enabling IMA
encryption, Citrix recommends that you run CT XKEYTOOL with the query option to verify that IMA encryption is
enabled.
T his 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). T he Dependencies column lists the system components, such as
Windows services, Citrix services, or drivers, on which the service depends. T he 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.
Citrix End User SemsService.exe Local Service/ Manual Collects and Citrix SMC
Experience collates end- Support Driver
Monitoring (Citrix user
EUEM) experience
measurements.
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 f or Service User Accounts
T his table lists the permissions associated with accounts XenApp services use.
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.
Increase quotas x x
Log on as a service x x x x
Debug programs x
T he ctx_ConfigMgr account is used by Web Interface 4 and earlier, for its centralized configuration feature. It is not used by Web
Interface 5, which does not have this centralized configuration feature. You can disable or delete ctx_ConfigMgr account if this
feature is not required.
T he ctx_StreamingSvc account is used by the Citrix Application Streaming feature. You can disable or delete this account if this
feature is not required. Citrix does not support changing the account for the Citrix Streaming Service, 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.
T he ctx_cpuuser account is used by the Citrix CPU utilization management feature. You can disable or delete this account if this
feature is not required.
T he passwords initially generated for the ctx_ConfigMgr, ctx_StreamingSvc, and ctx_cpuuser accounts are generated to be
compatible with all Group Policy settings for password policy:
Each password is 14 characters long. T hat satisfies Group Policy for Minimum password length, because the maximum possible
value is 14.
Each password is generated to match the Group Policy criteria for Password must meet complexity requirements.
Each password is random.
T here is no automated password change mechanism supplied for these accounts. Password change is not supported for the
ctx_StreamingSvc account.
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.
T he 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
.
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. T ype a user name in the Name box.
Applications By User. Lists the applications that the specified user is using. T ype a user name in the Name box.
Servers without hotfix. Allows you to search for all of the servers missing a specific hotfix. T his feature is useful if you
want to check that you applied a hotfix to all servers in your farm. T ype a hotfix number in the Name box.
3. Use the Browse button to select one of the Citrix Resources locations to search.
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.
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.
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.
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 T asks > 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. T his state persists until you change it manually.
After resetting logon control, the selected option does not appear in the list.
Restart schedules are based on the local time for each server to which they apply. T his 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. T his 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. T he 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.
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.
T his method removes the host information from the farm data store and removes the server from the farm properties
displayed in the management tools.
To remove XenApp remotely, you can do so from within a Remote Desktop Connection (RDC) session or using tools such as
Microsoft Configuration Manager 2007 (formerly Systems Management Server (SMS)).
If you want to remove only specific components of XenApp, do so in the following order:
Citrix Management (such as Citrix AppCenter)
XenApp Advanced Configuration utility or Presentation Server Console, if installed
Citrix XenApp
Citrix Web Interface
Citrix Licensing
Alternatively, to uninstall XenApp and all its components from a command line, use the XenAppSetupConsole.exe
/uninstall:XenApp command. From the server console, run XenAppServerSetup.exe. For more details about using these
commands, see Removing Roles and Components.
To force the removal of XenApp from a computer, you can use msiexec on a command line to add the property:
CT X_MF_FORCE_SUBSYST EM_UNINSTALL. Set its value to Yes.
T he following sample command line enables logging of the uninstallation operation and forces the removal of XenApp:
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.
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. T he 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
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.
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 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\SOFT WARE\ Wow6432Node\Citrix\IMA\RUNT IME\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.
T he 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.
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:
1. In the left pane, select the server.
2. From the Action menu, select Other T asks > Remove from farm.
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.
%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.
Citrix Tests
SessionT ime Defines the maximum session time for a short logon/logoff cycle. Default is five
seconds.
SessionT hreshold T he number of logon/logoff cycles that must occur within the session interval
for the test to fail. Default is 50 cycles.
Ticketing Test
T his test requests a ticket from the XML service running on the server and prints the ticket.
1. On the server where XenApp is installed, open the Server Manager console.
2. In the T ree view, select Diagnostics > Performance > Monitoring T ools > 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. T o add all ICA counters, in the Available counters list, select ICA Session. T o 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.
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.
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.
T o ensure an optimal experience for users accessing published resources, XenApp provides load balancing policies to direct
users to the least-loaded XenApp server hosting the resource. You can use load balancing policies to:
Reduce WAN traffic by directing users to the closest regional server
Direct users to a backup server in the event of an outage
Direct a specific group of users to a group of dedicated servers
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. T his 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,
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.
1. In the Citrix AppCenter, select the Load Balancing Policies node in the left pane.
2. On 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. T o 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.
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:
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.
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.
T o ensure the worker groups specified are correctly entered, click the Browse button on the Add Filter Element dialog box.
T his enables XenApp to assemble a current list of 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
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.
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. T his 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. T hen, specify that worker group as the Primary Group
in the policy. T his makes XenApp route incoming connection requests from users to that worker group first.
Preferential Load Balancing calculates importance levels based on the Resource Allotment for each session. T he 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.
Resource Allotment
Resource Allotment is calculated based on the published application importance level and the result of the XenApp policy
engine for that session. T he 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. T he higher a session’s Resource Allotment, the higher service it
receives compared with those other sessions.
T he 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.
T he session with the highest Resource Allotment gets the highest percentage of CPU cycles of any sessions running in the
farm.
Use this table to help determine how to set your importance levels for applications and sessions.
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.
T he 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. T his 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: T he 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).
You can enable CPU utilization management using Citrix policy settings. T his feature is not enabled by default.
Important:
T he 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.
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.
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.
T he 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.
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.
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.
Not all applications can be optimized successfully. T he 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.
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
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:
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. T his setting is used only if you set the interval to Monthly.
Memory optimization schedule: day of week (Sunday by default). Select the day of the week that memory optimization
runs. T his setting is used only if you set the interval to Weekly.
Memory optimization schedule: time (3:00 AM by default). T his setting is used only if you set the interval to Daily, Weekly,
or Monthly.
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.
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. T he 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.
You can force a manual refresh of a server’s local host cache by executing dsmaint refreshlhc from a command prompt. T his
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.
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.
T o 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\SOFT WARE\Wow6432Node\Citrix\IMA\
RUNT IME\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.
T he data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA Service
fails to start.
You can adjust the interval by which member servers query the farm's data store for missed changes. T he 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:
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. T he 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.
T o 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. T his 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.
XenApp Troubleshooting Tools
Citrix Auto Support is a free online troubleshooting platform for your Citrix environment. Citrix Auto Support quickly
analyzes your log files, profiles your environment, and scans for known issues, providing customized advice for a solution.
Access Citrix Auto Support here to upload your log files.
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. T hey 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. T his
situation may arise if XenApp is installed on Windows domain controllers. Citrix does not support installing XenApp on a
domain controller.
To configure zones and backup data collectors
Zones are listed in the middle pane according to their election preference.
To modif y an existing zone
T o rename a zone, on the Zones node, right-click the zone name and select Rename.
T o reset the ranking, right-click a server in the zone and select Change display > Election Preference.
T o move the selected server to another zone, right-click a server in the zone and select Change server's zone
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.
T o 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. T his 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.
T he 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. T o apply the change, you must restart each server affected by the policy.
By default, XenApp server role installation configures the Citrix XML Service and Internet Information Service (IIS) to share
the same TCP/IP port (80) for communications. In this case, you cannot change the XML Service setting.
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: T he 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 the Citrix Computer policy setting for the XML Service.
2. Configure the XML service port setting. Citrix recommends using port 8080.
T he 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 the Citrix Computer policy setting for the XML Service.
2. Configure the T rust XML requests setting (disabled by default).
If you do not trust XML requests, certain features of XenApp are not available. T rusting requests sent to the XML Service
means:
Smooth Roaming works when connecting with the Web Interface using pass-through or smart card authentication, and
when connecting with the 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 (starting with Version 4.0) to control application
access and session policies. T his information includes Access Gateway filters that can be used to control access to
published applications and to set XenApp session policies. If you do not trust requests sent to the XML Service, this
additional information is ignored.
Before enabling the Citrix XML Service to trust requests it receives, use IPsec, firewalls, or another technology to ensure
that only trusted services communicate with the Citrix XML Service.
To avoid security risks, enable the setting only under the following conditions:
Some users connecting to their sessions using the Web Interface are also using pass-through authentication or smart
To manually change the XML Service port to use a port dif f erent f rom IIS af ter installation
Note: T his setting takes effect only after the XML Service restarts.
T he XML Service port that is set by using a Group Policy Object takes precedence over the port you set using the
command-line in this method.
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
T hese files are installed in \Program Files (x86)\Citrix\System32 during XenApp installation. T he 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
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" in this topic .
Def ault. 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
T hrottling, 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. T his load evaluator contains the CPU Utilization Load, Memory Usage, Page Swaps, and Load T hrottling 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. T he 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. T he next request for an ICA connection to a published application is routed to the next
available load-managed server in the list.
To access the load evaluators in XenApp, you select the Load Evaluators node in the left pane of the AppCenter. T he
following tabs appear:
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.
Considerations
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.
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. T he default value to report full load is 16000. T he default value to report no load is
900— at that value this rule is ignored. T his 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. T he default value to report full load is 90
percent. T he default value to report no load is 10 percent— at that value this rule is ignored. T his rule uses the Processor: %
Processor T ime performance counter to determine load.
Disk Operations
Defines a range of disk operation, in read/write cycles per second, for a selected server. T he default full load value is 100
operations per second. T he default no load value is 0— at that value this rule is ignored. T his 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.
T his rule must be used in conjunction with another.
Load Throttling
Memory Usage
Defines a range of memory usage by a server. T he default full load value is 90. T he default no load value is 10— at that
value this rule is ignored. T his 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. T he default full load value is 2000. T he default no load value is 0
— at that value this rule is ignored. T his 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. T he default full load value is 100. T he default no load value is 0— at that
value this rule is ignored. T his rule uses the Memory: Pages/sec performance counter to determine load.
Scheduling
Schedules the availability of selected servers or published applications. T his rule sets the weekly days and hours during which
the server or published application is available to users and can be load managed.
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. T he 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. T herefore, 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.
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.
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 T asks > Attach application to load evaluator.
4. On the Assign Load Evaluator dialog box, select the load evaluator to attach.
T he 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.
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. T his
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. T he 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
T he Power and Capacity Management system comprises the following components. (From a Windows installer viewpoint,
these are features; this documentation uses the term components.)
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.
Reporting Subfeature of the database component. Reports are hosted on Microsoft SQL Server Reporting
Services. T he administrator generates reports for historical system loads, capacities, and utilization
summaries.
Management A Microsoft Managed Console (MMC) snap-in to manage, monitor, and configure the Power and
console Capacity Management system.
Agent A Windows service installed on each XenApp server. T he agent reports capacity and system states, and
acts on operations and commands issued by the concentrator.
T he concentrator, database, reporting, and management console components are the administration components.
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
Unless otherwise noted, 32-bit and 64-bit operating system editions are supported.
Database Requirements:
Microsoft .NET Framework 3.5 SP1
Microsoft SQL Server 2005 SP3 and SP4 or Microsoft SQL Server 2008 R2; see CT X114501 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)
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).
Requirements:
Microsoft .NET Framework 3.5 SP1
XenApp 6.5
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. T his 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.
T he 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 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.
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. T his 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. (T his check box appears
only when you are not installing the concentrator and the database at the same time.)
In a silent installation, include the CT X_XAPCM_DO_NOT _ADD_ACCOUNT _T O_DB=yes property.
T hen use SQL Server Management Studio to add the necessary permissions to the database:
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.
For XenApp Power and Capacity Management, capacity is expressed as a number of sessions (or session count).
T he XenApp servers being managed by Power and Capacity Management are called a farm. T his 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). T he 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.) T he 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.)
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.
T he 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. T his is known as dynamic
capacity estimation.
Dynamic capacity estimation calculates individual server capacities based on the load on each server. T he capacity of each
server more accurately reflects the actual number of sessions it can handle. T he load on each server is determined by its
assigned XenApp load evaluator; therefore, consider the desired load criteria when configuring the assigned evaluators. T he
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.
T he typical session capacity and estimate session capacity limit are configured in the server profile.
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.
T he following MSI packages contain the Power and Capacity Management components.
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 install the database,
reports, concentrator, and management console on a supported 64-bit computer.
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
By default, all administration components are selected in an interactive installation, except reports.
CTX_XAPCM_ACCEPT_EULA=yes
Accepts the license agreement. T o 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=f arm-name
Farm name, up to 80 characters, and cannot contain: backslash (\), single quote ('), forward slash (/), double-quote ("),
less-than (<), greater than (>), pipe (|), or equal (=). T he collection of XenApp servers being managed by Power and
Capacity Management is known as a farm. T his farm may include some or all of the servers in a XenApp farm or may
contain XenApp servers from different XenApp farms. T he 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.
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
If you specify this property, you must specify a domain account password with the CT X_XAPCM_AGENT _PASSWORD
property. You must also supply a domain account with the CT X_XAPCM_CONCENT RAT OR_ACCOUNT property when
installing the concentrator. (T he 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
CT X_XAPCM_AGENT _PASSWORD property.
CTX_XAPCM_AGENT_PASSWORD=domain-account-password
Password for the domain account. T his property is valid only if you specified a domain account with the
CT X_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"
T he agent service running under the domain account "my_domain\my_user" with the password "my_password"
CTX_XAPCM_ACCEPT_EULA=yes
Accepts the license agreement. T o 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
CTX_XAPCM_FARM_NAME=f arm-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 (=) . T he collection of XenApp servers being managed by Power and
Capacity Management is known as a farm. T his farm may include some or all of the servers in a XenApp farm, or it may
contain XenApp servers from different XenApp farms. T he name must be unique.
If you are installing the database component and omit this parameter, the installation fails.
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").
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.
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 CT X_XAPCM_CONCENT RAT OR_PASSWORD
property. You must also supply a domain account for the CT X_XAPCM_AGENT _ACCOUNT property when installing the
agent. (T he 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
CT X_XPCM_CONCENT RAT OR _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
CT X_XAPCM_CONCENT RAT OR_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"
T he 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"
T he concentrator running under the domain account "my_domain\my_user" with the password "my_password"
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).
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.
Removing a Concentrator
To remove Power and Capacity Management components, use Windows Programs & Features or Add/Remove Programs.
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.
Note: You may still need to manually delete the concentrator's SCP entry from Active Directory.
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, review "Understanding Management Console Displays" and "T o generate a workload or server
report" in this topic. Using the collected information, you can then:
Creating Setpoints and Schedules
Enabling Load Consolidation and Power Management
T he management console connects to the master concentrator to obtain data. T he menu, toolbars, and Actions pane are
standard MMC 3.0 panes, some of which can be hidden if required. T he workloads and tabs panes comprise the Power and
Capacity Management snap-in.
Workload
All Workloads, plus names of individual workloads
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
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.
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.
Perf ormance
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.
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.'
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). T o 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. (T his tab is not displayed when All Workloads is
selected in the workloads pane.) T he entry for each day indicates time and setpoint values.
Important: T he 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.
T he agent discovers hardware information such as the CPU type and the amount of memory, and sends it to the
concentrator. T he 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. T he 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.
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). T his allows the dynamic session capacity
feature to estimate capacity higher than the typical session capacity value when it detects spare computing
resources. T his value must be greater than or equal to the typical session capacity value.
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.
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.
Control Modes
T he control mode affects whether the server is eligible for power management or participating in load consolidation.
Control Description
Mode
Unmanaged T he 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 T he server contributes to the capacity of the workload and meeting its current setpoints; however, it is
(base load) not controlled. T he 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 T he 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.
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.
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.
Select the optimal load, which specifies how close to capacity a server can get before additional load should be
directed to other servers. T he load consolidator uses this value.
T he 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). T he remaining 30% of capacity acts as a buffer to
ensure existing sessions on the server have spare computing resources to work with. Tune the optimal load threshold
to find the right balance between performance and utilization.
Enable or disable metrics data collection. Select the number of days to retain the collected metrics data. T he default
is 365 days (1 year).
You can also modify or delete a site from the Server Sites dialog box.
Virtual machine management supports multiple concurrent resource pools. T he concentrator automatically connects to the
resource pool, and periodically queries the inventory of virtual machines. T he management console displays the inventory
poll results as a count of the number of virtual machines. T he 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: T he 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. T hen, 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. T his is typically done using the
auto-generate MAC option when creating the virtual machine.
You can also modify or delete a virtual machine manager from the Machine Managers dialog box.
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.
T he management console also performs the same discovery process and connection attempts.
You can explicitly force a running concentrator to become the master concentrator. T his may be necessary when a master
concentrator has planned maintenance.
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.
Edit the PCMConcentrator.exe.config file in the Install directory, then restart the PCM Concentrator service. (T he default
port is 11168.)
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.
T his creates an AD object only; no AD schema changes are required. T his 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. T his command
deletes the aforementioned object in AD.
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. T he power controller uses four setpoints. T he 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. T hus, a newly discovered workload cannot be power controlled until you define appropriate setpoints for
it (and enable power management).
T he 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. T he management console displays this value as an infinity symbol.
Minimum session capacity and maximum session capacity. T hese setpoints work as guards for the online session reserve.
T he online session reserve setpoint can raise and lower the online capacity, as long as it remains between the two
guards.
T he 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.
T he 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. T his 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 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.
T he 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. T herefore, the servers that are
enabled may become overloaded while new sessions are logging on.
T he 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. T herefore, setpoints have the following order of importance, from highest to
lowest:
Minimum available servers
Maximum session capacity
Minimum session capacity
Online session reserve
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.
T o 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.
From the management console, select a workload and click the Schedule tab.
T o create a schedule, select the Allow Edit checkbox. Edit the schedule for one or more days of the week.
T o copy the schedule from the previous day, click Copy day's schedule in the day of the week area.
T o copy the entire workload schedule to another workload, ensure the workload being copied has focus, then click Copy
Schedule T o in the Actions pane.
T o delete a schedule, click Delete Schedule in the Actions pane.
T o delete an individual schedule item, select the leftmost cell in the item, then press the Delete key.
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.
1. Design your printing configuration. T his 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. T est 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. T roubleshoot 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:
T he concept of printer provisioning in a session and the two major types of provisioning (auto-created and self-
provisioned). T o 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.
T he 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.
T his 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 LPT 1 or COM1) or you can print to a network printer that is managed by a print server.
T his 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.
Printer driver
T he printer driver is the software program that lets the computer communicate with this hardware device. T his 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
T he 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. T he 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. T he 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. T he spooler maintains this list for each printer object in
the computer.
Print server
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.
When print jobs are spooled locally, the local Windows computer processes the job. T he 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. T he 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. T his process of
writing commands occurs repeatedly until the job is completely spooled.
3. T he local spooler processes the job with the printer driver in a process known as
— rendering
.
4. T he local spooler delivers the rendered data to the printing device (for example, a locally attached printer).
When print jobs are spooled remotely, the Windows print server processes the print job.
1. T he 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. T his process of
writing commands across the network occurs repeatedly until the job is completely spooled.
3. T he remote spooler processes the job with the printer driver in a process known as
— rendering
.
4. T he print server delivers the rendered data to the printing device (typically a network printer).
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.
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.
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:
T he difference between the client and network printing pathway and how this is not the same as local printers and
network printers
T he 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
T he basics of printer driver management
T he 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.
T his 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. T he 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. T he application tells the remote spooler to create a print job and an associated spool file.
2. T he Windows Print Provider sends the spool file to the print server.
3. T he print server processes the spool file.
4. T he print server then sends the print job to the appropriate network printer.
T he 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: T o 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.
T he 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. T he 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. T hese jobs are spooled locally on the XenApp server.
T here are two different configurations of the client printing pathway: one for printers attached directly to the client device
and another for network printers.
T he 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. T he client device then relays it to a locally attached
printer.
T his 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. T he 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. T he 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.
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.
T he 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.
T his 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. T he client device then routes the print job over the
network to the print server, which in turn routes the print job to the network printer.
When a print job is spooled to a network printer along the client printing pathway, it uses this process:
1. T he application server sends the print job to the client for processing.
2. T he client processes the spooled job and sends it to the Windows print server for processing.
3. T he 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. T he client printing
pathway also lets you limit traffic or restrict bandwidth allocated for print jobs.
You can control printer provisioning and the way you configure it affects what printers users see in sessions and the speed
of the printers.
Because provisioning static printers is relatively simple, this topic focuses on provisioning printers dynamically.
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 user device.
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 user 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.
T he term autocreation refers to printers XenApp creates automatically, at the beginning of each session, based on what
printers are configured on the user device and any policies that apply to the session.
By default, XenApp makes printers available in sessions by creating all printers configured on the user device automatically,
including locally attached and network printers. After the user ends the session, the printers for that session are deleted.
T he next time a session starts, XenApp evaluates any policies for printer creation and enumerates the appropriate printers
from the user device.
You can change the default autocreation policy settings to limit the number or type of printers that are auto-created.
T here 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.
Autocreated client printers and user provisioned printers use the client printing pathway. Autocreated network printers use
the network printing pathway.
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 user devices, all users can add printing devices to be used in a
session. T he only time users cannot add printers to their sessions is when they cannot access their user 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.
T he 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.
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.
T he Citrix policy setting Auto-create client printers lets you control autocreation and specify that:
All printers visible to the user device, including network and locally attached printers, are created automatically at the
start of each session
All non-network printers physically attached to the user device are created automatically
Only the default printer for the user device is created automatically
No printers visible to the user device are created automatically
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.
Whether you use a Citrix Universal printing solution depends on various factors:
T he Citrix Universal Printer and printer driver might not work for all user devices or plug-ins in your environment. T he Citrix
Universal Printer and printer driver solution requires the Citrix Online Plug-in or the Citrix Offline Plug-in.
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.
T he 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.
T his feature is available in Presentation Server 4.0 to XenApp 6.
Citrix Universal Printer
T he Citrix Universal Printer is a generic printer created at the beginning of sessions that can be used with almost any
printing device. T his 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.
T he 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 user 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 user
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.
Because the Citrix Universal Printer is not tied to a specific printing device, both the EMF-based and XPS-based Citrix
Universal Printers provide ways to preview and select settings:
EMF-based Citrix Universal Printer. T he 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: T he 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.
Auto-Creating Network Printers
To specify that specific printers are created in sessions rather than auto-create all the network printing devices available
from the user 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.
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.
T he 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.
T he printer that XenApp selects for a session’s default printer can be based on:
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.
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.
On the client device itself . T he 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. T his 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. T hese 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. T hese 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. T hese 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. T his 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.
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
By default, XenApp always applies any printing settings a user modified during a session; that is, the retained settings,
before considering any other settings.
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 prof ile. T hat is, if you are using local, roaming, or mandatory profiles on your Windows network.
If you are using a mandatory profile and you want to retain the user’s printer properties, you must store the properties
on the client device.
Farm Size. If you have a large farm and you are load balancing applications, users will experience inconsistent printing
behavior and properties if you use local profiles. T he 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.
If you have mobile workers and need this type of printing functionality, use one of these features:
SmoothRoaming
Proximity Printing
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. T he 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.
T his 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.
T he 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:
T he name of the workstation, if the name relates to the workstation’s location
Your network’s IP addresses, if they correlate with user locations
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. T he 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. T his is accomplished by auto-creating the network printer but specifying its jobs to route through
the plug-in.
Over the network. T his 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. T he 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.
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. T he diagram that follows shows how the printer driver is used in two places for client printing.
T his diagram shows client printing to a local printer: T he printer driver on the server routes the job over the ICA channel to
the client device. T he client device then routes the print job through the same printer driver, which is accessible on the client
device. T he 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.
T he 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.
T he following problems can arise from not managing client printer drivers correctly:
Any missing drivers can prevent users from printing successfully. If a third-party printer driver has multiple or inconsistent
names across your farm, a session might not be able to find it and a user’s job may fail to print.
Printing to a client printer with a defective driver can cause a fatal system error on a server.
XenApp does not download drivers, including printer drivers, from the print server. For XenApp servers to print across the
network printing pathway, the correct device-specific printer driver for the XenApp server's operating system (version and
bit depth) must be installed on the XenApp server. T wo 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,
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.
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. T his 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. T his 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. T his 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. T his 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. T he option that appears is the default.
When users access printers from published applications, you can configure XenApp policies to specify:
How printers are provisioned (or added to sessions)
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.
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. T he local print provider maintains a single shared namespace for all local printers on a server.
T his 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. T his 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:
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. T his prevents bypassing the spooler and
communicating directly with CpSvc.exe.
As an administrator, if you need to adjust security settings of a printer in another session, you can do so through Windows
Explorer.
Note: If you want to control access to printers in other sessions, add the AdminsCanManageClientPrinters bit flag to
default print flags in the system registry of your server. For more information, see the Citrix Knowledge Center article
— Advanced Printing Configuration in XenApp 6.x and XenDesktop 5.x
.
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.
Client printers. T he settings in this category affect the client redirected printers and printing using the client printing
pathway.
Drivers. T he settings in this category control driver management.
Printer redirection bandwidth limit. T his setting restricts the bandwidth allocated to printers.
Session printers. T his 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 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.
T he policies are filtered on standard objects that apply to all Citrix policy settings. T herefore, 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.
All printing policy settings follow standard XenApp prioritization. Citrix policies always take precedence over Windows
policies in a XenApp environment.
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.
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. T o do so, disable the Citrix policy setting <uicontrol ast:aid="00000023WHG73FF712034GYZ" ast:anno="can">Direct
connection to print servers</uicontrol>.
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.
T o 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.
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.
For more information, see Configuring Universal Printer Drivers on Farm Servers
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.
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 user 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.
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: T he 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.
To allow 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. Select Printer Properties.
3. On 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.
When you want to make sure that users always see the closest printer to their user 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.
T he 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
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:
T he ICA Client Printer Configuration T ool (PrintCfg.exe). T his tool lets Windows CE and DOS users add printers.
T he 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.
T his 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.
If you get a path error and cannot access the published printers folder, modify the command line to include %*. For
example,
1. Follow the instructions for publishing an application in Publishing Resources By Using the AppCenter.
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.
To store user printer properties, configure the Citrix policy setting Printer properties retention by choosing from the
following settings:
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
T o obtain printer properties directly from the printer itself, rather than from the properties store, use the following
procedure. T his 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\SOFT WARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences
For 32-bit, HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences
2. Create the following registry key: Name:Win32FavorRetainedPrinterSettings Data T ype: REG_SZ Value Data: false
3. Restart the Citrix Print Manager Service.
Managing printer drivers is important for a successful printing experience. When XenApp auto-creates 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
To prevent drivers from being installed automatically, configure the Citrix policy setting Automatic installation of in-box
printer drivers.
To specify how client printer drivers are installed on the XenApp servers, configure the following Citrix policy settings:
Automatic installation of in-box printer drivers. Controls whether printer drivers from the Windows in-box driver set or
Configure the Citrix policy setting Automatic installation of in-box printer drivers (enabled by default). T his setting allows
XenApp to install Windows native printer drivers (the Windows in-box driver set or from driver packages staged on the host
using pnputil.exe /a) automatically when auto-creating either a client or network printer.
Caution: Enabling this option might result in the installation of a large number of native drivers.
Configure the Citrix policy setting Printer driver mapping and compatibility to specify whether printers can be created with
specific drivers or not or with universal printer drivers. You can use this setting to add a driver mapping, edit an existing
mapping, remove a mapping, or change the order of driver entries in the list.
You can turn the Printer driver mapping and compatibility setting into a whitelist by specifying only the allowed drivers,
adding an additional entry using a wildcard * for the driver name, and specifying Do not create for all drivers other than
those specified. Alternatively, you can use the Create with universal driver only option in the setting to allow only universal
drivers for drivers that are not explicitly specified.
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. T he XPS Universal printer driver can be
configured as the default by configuring the Citrix policy setting Universal driver preference.
T he 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.
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
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.
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.
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. T he autocreation process then employs the identified, available printer drivers to construct redirected client
print queues.
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.
After you have added a client printer driver to the list of mapped drivers, you can modify the printing settings for the driver.
T his 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.
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.
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. T o prevent such degradation, you can limit the bandwidth used by client printing.
Important: T he printer bandwidth limit is always enforced, even when no other channels are in use.
T here 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. T he print spooling virtual channel control (that is, the CT XCPM Client printer mapping virtual
channel control) lets you set a priority and bandwidth limit for bandwidth control of this virtual channel.
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.
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.
User printers (Printers attached to Client printing On Print Management snap-in in the
the user device) pathway Microsoft Management Console
Network printers (Printers on a Network printing On Print Server > Print Management
network print server) pathway snap-in in the Microsoft
Management Console
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 user printing pathway. You can tell a job sent to the network
printer is redirected along the user printing pathway when you see printers appearing in the Windows Server Manager Snap-
where:
PrintServer is the name of the print server with which the printer is associated
clientname is the name of the user through which the print job is being rerouted
For example, Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2.
If User Access Control (UAC) is not enabled, you can, however, show and manage redirected client print queues and server
local printers through Control Panel > Printers of individual servers. T he use 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 user
devices. You can display user printers in Control Panel > Printers.
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 T ools, open the Print Management stand-alone snap-in.
3. T o display user redirected printers, in the Print Management tree, select Print Management > Custom Filters > All Printers.
T he Print Management snap-in displays the user 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 T ree to
display active jobs on redirected printers.
T he 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 user device, clientname is the unique name given to the user device or the Web Interface, and x
is the SessionID of the user’s session on the server.
After you install the Universal Print Server components and configure the new policy settings, a user can add and
enumerate network printers through the Windows Provider and Citrix Provider interfaces.
You also must install updated Citrix Group Policy Management software on the computer where the Group Policy
Management Console is installed. In general, the Group Policy Management Console can be installed on a XenApp or
XenDesktop host, or another Windows server in your environment.
After you install UPClient on the XenApp server and UPServer on the print server, configure the appropriate policy settings.
See CT X134913 to verify the Universal Print Server configuration.
Do not install the UPServer component on a server that has XenApp or XenDesktop installed. If you
attempt to do so, the installation will fail.
T he UPServer installer enables or installs the following items, if they are not already present:
Print and Document Services role. Enabling this role is provided as a convenience; if enabling this role
fails, the installation proceeds.
Visual C++ 2005 SP1 and 2008 SP1 runtime libraries.
Citrix Client-Side Extension. T his software is required to retrieve and configure Universal Print Server
Note: T his document describes the XenApp Hotfix Rollup Pack (HRP01) and the XenDesktop Virtual
Desktop Agent upgrade required to use the Universal Print Server.
Before installing UPClient, check to ensure .NET 3.0 SP1 Framework (minimum) is installed. XenApp and
XenDesktop installations require this software, so it is likely to already be installed.
T he UPClient installer enables or installs the following items, if they are not already present:
Visual C++ 2005 SP1 and 2008 SP1 runtime libraries.
Citrix Client-Side Extension. T his software is required to retrieve and configure Universal Print Server
policy settings.
1. Download the following items from either the XenDesktop 5.6 Feature Pack 1 or the XenApp 6.5 Feature Pack 1 site on
My Citrix to a shared folder on your network:
Citrix Universal Print Server package (CitrixUniversalPrintSolution.zip). Extract the compressed files: UPServer
(CitrixUPServer_SelfExtractor.exe) and UPClient (CitrixUPClient_SelfExtractor.exe).
Group Policy Management software
For 32-bit platforms: CitrixGroupPolicyManagement_x86.msi
For 64-bit platforms: CitrixGrouPolicyManagement_x64.msi
If you will be using the Universal Print Server in a XenDesktop deployment:
XenDesktop 5.6 Feature Pack 1 Virtual Desktop Agent
For 32-bit platforms: xdsagent_x86.msi
For 64-bit platforms: xdsagent_x64.msi
2. If you will be using the Universal Print Server in a XenApp deployment, download and install the latest hotfix rollup pack.
For a list of the latest hotfix releases see Software Updates at http://support.citrix.com.
Note: T he Universal Print Server download package also contains a XenApp hotfix, XA650W2K8R2X64013.msp, which
you can install instead of the latest HRP to provide updates supporting the Universal Print Server. However, Citrix
recommends installing the latest HRP, which includes these updates and other critical fixes.
3. Save the downloaded software:
Save the Virtual Desktop Agent and the UPClient component on each XenDesktop host.
Save the XenApp 6.5 HRP and the UPClient component on each XenApp host.
Save the Group Policy Management software on the system where you use the Group Policy Management Console.
Save the UPServer component on the print server.
4. Install the software:
On each XenDesktop host:
1. Upgrade the Virtual Desktop Agent on each virtual machine, following the directions in the XenDesktop 5.6 Feature
Pack 1 documentation.
5. On the computer where you use the Citrix Group Policy Management Console, install the Group Policy Management
software by double-clicking the CitrixGroupPolicyManagement MSI and following the on-screen instructions.
6. On the print server, ensure all requirements are met. T hen, install UPServer by double-clicking
CitrixUPServer_SelfExtractor.exe and following the on-screen instructions.
T he UPServer component installs the following services:
XT E Service - Installed under the Network Service account and configured for automatic start (dependent on the
Citrix Print Service).
Citrix Print Service - Installed under the Local Service account and configured for automatic start. After starting, the
Citrix Print Service configures the XT E Service, which then starts.
In XenApp and XenDesktop 7.6 FP3, the UPS package contains updated versions of the standalone UPS client and server
components. For installation instructions, see Provision printers in the XenApp and XenDesktop 7.6 documentation.
If you use the Local Policy Editor or Active Directory to configure the following Citrix policy settings, the policy settings
apply to XenApp, XenDesktop, and the print server. If you configure these policy settings using the Citrix AppCenter, the
policy settings apply only to XenApp and XenDesktop.
Setting Description
Universal Enables or disables the Universal Print Server feature. T his Citrix Computer policy setting applies to
Print Server Organizational Units (OUs) containing XenApp and XenDesktop hosts. Valid values are:
enable Enabled with f allback to Windows native remote printing - Network printer connections are
serviced by the Universal Print Server, if possible. If the Universal Print Server is not available, the
Windows Provider is used. T he Windows Provider continues to handle all printers previously created
with the Windows Provider.
Enabled with no f allback to Windows native remote printing - Network printer connections
are serviced by the Universal Print Server exclusively. If the Universal Print Server is unavailable, the
network printer connection fails. T his setting effectively disables network printing through the
Windows Print Provider. Printers previously created with the Windows print provider are not created
while a policy containing this setting is active.
Disabled (def ault) - T he Universal Print Server feature is disabled. No attempt is made to connect
with the Universal Print Server when connecting to a network printer with a UNC name. Connections
to remote printers continue to use the Windows native remote printing facility.
Universal Specifies the TCP port number used by the Universal Print Server print data stream CGP (Common
Print Server Gateway Protocol) listener. T his Citrix Computer policy setting applies to OUs containing the print
print data server. Valid values: 1-65535. Default: 7229
stream (CGP)
Universal Specifies the TCP port number used by the Universal Print Server listener for incoming HT T P/SOAP
Print Server requests. T his Citrix Computer policy setting must specify the same value for the OUs containing the
web service network print server, plus the XenApp and XenDesktop hosts. Valid values: 0-65535. Default = 8080
(HT T P/SOAP)
port
Universal Specifies the upper bound (in kilobits-per-second) for the transfer rate of print data delivered from
Print Server each XenApp or XenDesktop print job to the Universal Print Server using CGP. T his Citrix User policy
print stream setting applies to OUs containing the XenApp and XenDesktop hosts. Valid values: integers > 0.
input Default: 0 (unlimited)
bandwidth
limit (kbps)
T he Universal Print Server policy settings can affect other Citrix printing policy settings. In the following table, it is assumed
that if the Universal Print Server policy setting is enabled, the Universal Print Server components are installed, and the policy
settings are applied.
Client printer If the Universal Print Server is enabled, client network printers can be created using the Universal
redirection, printer driver, directly to the print server. Otherwise, client network printers can be created if the
Auto-create native driver is installed or through the Universal printer driver as indirect printers.
client printers
Printer auto- Enabling the Universal Print Server may allow creation of otherwise unsupported printers, such as a
creation event Linux client that does not support the EMF or XPS Universal printer driver.
log
Session When using the Citrix Universal print provider, Universal printer driver policy settings are honored. When
printers using the Windows Provider, the legacy session printers are honored, rather than the Universal printer
driver policy.
Direct When the Universal Print Server is enabled and the Universal printer driver usage policy setting is
connections to configured to use universal printing only, a direct network printer can be created to the print server,
print server using the Universal printer driver. (Previously in such cases, the printer was created indirectly through
the client.)
T he new Citrix Universal printer driver used by the UPClient component has the same characteristics and user interface as
the Citrix Universal printer driver it replaces, with the following exceptions.
When using the Universal Printer Server, the Add Printer Wizard for the Citrix Print Provider is the same as the Add Printer
Wizard for the Windows Print Provider, with the following exceptions:
When adding a printer by name or address, you can provide an HT T P/SOAP port number for the print server. T hat port
number becomes a part of the printer name and appears in displays. See the UPS Web service (HT T P/SOAP) port policy
setting description above.
If the Citrix Universal printer driver usage policy setting specifies that universal printing must be used, the Universal printer
driver name appears when selecting a printer. T he Windows Provider cannot use the Universal printer driver.
When using the Universal Print Server, a maximum of 50 active concurrent consumers of print streams is allowed. T his means
that up to 50 print jobs can be handled simultaneously, independent of the number of actual printers in the environment.
When the 51st print job is submitted, it is queued and processed after a currently-running print job completes.
To configure a non-standard HT T P/SOAP port for the Universal Print Server web service, you must use PowerShell cmdlets
to configure the session printer policy. [#268593]
During peak printing activity, printers that are mapped to a Citrix Universal Print Server might appear as offline, or some
applications might become unresponsive or fail when opening a print dialog box. Please see CT X138854 for details.
[#429099]
Command Description
icaport Configure T CP/IP port number used by the ICA protocol on the server.
query View information about server farms, processes, ICA sessions, and users.
Use altaddr to query and set the alternate (external) IP address for a server running Citrix XenApp. T he 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
Options
/server:servername
Specifies the server on which to set an alternate address. Defaults to the current server.
/set
Sets alternate T CP/IP addresses. If an adapteraddress is specified, alternateaddress is assigned only to the network
adapter with that IP address.
/delete
Deletes the default alternate address on the specified server. If an adapter address is specified, the alternate address for
that adapter is deleted.
/v (verbose)
Displays information about the actions being performed.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
T he 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:
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. T he script commands are described below.
Script Commands
copy sourcedirectory\f ilespec targetdirectory
Copies files from sourcedirectory to targetdirectory. Filespec specifies the files to copy and can include wild cards (*,?).
deletedirectory\f ilespec
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\f ilespec
Deletes all files in the directory specified.
execute
Executes the program specified by the path command using the working directory specified by the workdir command.
path executablepath
Executablepath is the full path of the executable to be run.
workdir directory
Sets the default working directory to the path specified by directory
Script Parameters
directory
A directory or directory path.
executablepath
T he full path of the executable to be run.
f ilespec
Specifies the files to copy and can include wildcards (*,?).
sourcedirectory
T he directory and path from which files are to be copied.
targetdirectory
T he directory and path to which files are to be copied.
Remarks
If no scriptfilename is specified, app displays an error message.
T he Application Execution Shell reads commands from the script file and processes them in sequential order. T he script file
must reside in the %SystemRoot%\Scripts directory.
Examples
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
f ilename
T he 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
T he 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:f ilename
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
Remarks
Auditlog provides logs you can use to verify system security and correct usage. T he information can be extracted as reports
or as comma-delimited files that can be used as input to other programs.
You must enable logon/logoff accounting on the local server to collect the information used by auditlog. To enable
logon/logoff accounting, log on as a local administrator and enable logon/logoff accounting with the Audit Policy in
Microsoft Windows.
Security Restrictions
To run auditlog, you must have Windows administrator privileges.
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
newkey
Creates a new encryption key in the data store using the local farm key.
backup
Backs up the existing farm key to a file.
enable
Enables the IMA encryption feature for the farm.
disable
Disables the IMA encryption feature for the farm.
query
Can be used to check:
For a key on the local computer
T o see if IMA encryption is enabled for the farm
If your key matches the farm key
Remarks
T he 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. T his 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.
Syntax
ctxxmlss [/rnnn] [/u] [/knnn] [/b:a] [/b:l] [/?]
Options
/rnnn
Security Restrictions
None.
Remarks
For more information, see
— System Requirements
.
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\SOFT WARE\Wow6432Node\Citrix\IMA\RUNT IME, or HKLM\SOFT WARE\Citrix\IMA\RUNT IME on
XenApp, 32-bit Edition.
Second, several performance monitor values are updated under the performance object for Citrix XenApp. T hese 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.
T hird, 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
Run the dsmaint command 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 might 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
Local path for the backup data store. Do not use the same path as the original database or a share point.
Options
conf ig
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
T he user name to connect to a data store.
/pwd:password
T he password to connect to a data store.
/dsn:f ilename
T he filename of an IMA data store.
backup
Creates a backup copy of the SQL Server Express deployment data store. Run this command on the XenApp server that
hosts the data store. Requires a path to a local folder to which the backup database file is 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
/srcdsn:dsn1
T he name of the data store from which to migrate data.
/srcuser:user1
T he user name to use to connect to the data store from which the data is migrating.
/srcpwd:pwd1
T he password to use to connect to the data store from which the data is migrating.
/dstdsn:dsn2
T he name of the data store to which to migrate the data.
/dstuser:user2
T he user name that allows you to connect to the data store to which you are migrating the source data store.
/dstpwd:pwd2
T he 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. T he
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.
verif ylhc
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
Remarks
After using dsmaint, Citrix recommends running dscheck to check the integrity of the data on the XenApp data store.
Security Restrictions
T he dsmaint config and dsmaint migrate commands can be run only by a user with the correct user name and password for
the database.
Syntax
icaport {/query | /port:nnn | /reset} [/?]
Options
/query
Queries the current setting.
/port:nnn
Changes the T CP/IP port number to nnn.
/reset
Resets the T CP/IP port number to 1494, which is the default.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
T he default port number is 1494. T he 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
icaport /port:5000
To reset the port number to 1494
icaport /reset
Security Restrictions
Only Citrix administrators with Windows administrator privileges can run icaport.
Syntax
imaport {/query | /set {IMA:nnn | ds:nnn}* | /reset {IMA | DS | ALL} } [/?]
Options
/query
Queries the current setting.
/set
Sets the designated T CP/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 T CP/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.
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
T he name of a published application.
server
T he name of a server within the farm.
Options
f arm
Displays information about servers within an IMA-based server farm. You can use qfarm as a shortened form of query farm.
server /addr
Displays address data for the specified server.
/app
Displays application names and server load information for all servers within the farm or for a specific server.
/app appname
Displays information for the specified application and server load information for all servers within the farm or for a specific
server.
/continue
Do not pause after each page of output.
/disc
Displays disconnected session data for the farm.
/load
Displays server load information for all servers within the farm or for a specific server.
/ltload
Displays server load throttling information for all servers within the farm or for a specific server.
/lbof f
Displays the names of the servers removed from load balancing by Health Monitoring & Recovery.
/process
Displays active processes for the farm.
/tcp
Displays T CP/IP data for the farm.
/online
Displays servers online within the farm and all zones. T he data collectors are represented by the notation “D.”
/online zonename
Displays servers online within a specified zone. T he data collectors are represented by the notation “D.”
/of f line
Displays servers offline within the farm and all zones. T he data collectors are represented by the notation “D.”
/of f line zonename
Displays servers offline within a specified zone. T he 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
Security Restrictions
You must be a Citrix administrator to run query farm .
Syntax
query process [ * | processid | username | sessionname | /id:nn | programname ]
[ /server:servername ] [ /system ]
query process [/?]
Parameters
*
Displays all visible processes.
processid
T he three- or four-digit ID number of a process running within the farm.
programname
T he name of a program within a farm.
servername
T he name of a server within the farm.
sessionname
T he name of a session, such as ica-tcp#7.
username
T he name of a user connected to the farm.
Options
process
Displays information about processes running on the current server.
process *
Displays all visible processes on the current server.
process processid
Displays processes for the specified processid.
process username
Displays processes belonging to the specified user.
process sessionname
Displays processes running under the specified session name.
process /id:nn
Displays information about processes running on the current server by the specified ID number.
process programname
Displays process information associated with the specified program name.
Security Restrictions
None.
Syntax
query session [sessionname | username | sessionid]
query session [/server:servername] [/mode] [/flow] [/connect] [/counter]
query session [/?]
Parameters
servername
T he name of a server within the farm.
sessionname
T he name of a session, such as “ica-tcp#7”.
sessionid
T he two-digit ID number of a session.
username
T he name of a user connected to the farm.
Options
session sessionname
Identifies the specified session.
session username
Identifies the session associated with the user name.
session sessionid
Identifies the session associated with the session ID number.
session /server: servername
Identifies the sessions on the specified server.
session /mode
Displays the current line settings.
session /f low
Displays the current flow control settings.
Security Restrictions
None.
Use query to display information about terminal servers within the network.
Syntax
query termserver [servername] [/domain:domain] [/address] [/continue]
query termserver [/?]
Parameters
servername
T he name of a server within the farm.
domain
T he name of a domain to query.
Options
termserver servername
Identifies a T erminal Server.
/address
Displays network and node addresses.
/continue
Do not pause after each page of output.
/domain: domain
Displays information for the specified domain. Defaults to the current domain if no domain is specified.
/?
Displays the syntax for the utility and information about the utility’s options.
Remarks
If no parameters are specified, query termserver lists all Terminal Servers within the current domain.
Security Restrictions
None.
Syntax
query user [ username | sessionname | sessionid ] [ /server:servername ]
query user [/?]
Parameters
servername
T he name of a server within the farm.
sessionname
T he name of a session, such as “ica-tcp#7”.
sessionid
T he ID number of a session.
username
T he name of a user connected to the farm.
Options
user username
Displays connection information for the specified user name.
user sessionname
Displays connection information for the specified session name.
user sessionid
Displays connection information for the specified session ID.
user /server: servername
Defines the server to be queried. T he 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.
Using the standard Windows procedure, you can add and then view the following categories of XenApp-related counters,
called performance objects in Performance Monitor:
T he following counters are available through the Citrix CPU Utilization Mgmt User performance object in Performance
Monitor.
Counter Description
CPU Entitlement T he percentage of CPU resource that Citrix CPU Utilization Management makes
available to a user at a given time.
CPU Reservation T he percentage of total computer CPU resource reserved for a user, should that
user require it.
CPU Usage T he percentage of CPU resource consumed by a user at a given time, averaged
over a few seconds.
Long-term CPU Usage T he percentage of CPU resource consumed by a user, averaged over a longer
period than the CPU Usage counter.
T he following counters are available through the Citrix IMA Networking performance object in Performance Monitor.
Counter Description
T he following counters are available through the Citrix Licensing performance object in Performance Monitor.
Counter Description
Average License Check-In Response T ime (ms) T he average license check-in response time in milliseconds.
Average License Check-Out Response T ime (ms) T he average license check-out response time in milliseconds.
Last Recorded License Check-In Response T ime T he last recorded license check-in response time in milliseconds.
(ms)
Last Recorded License Check-Out Response T he last recorded license check-out response time in milliseconds.
T ime (ms)
License Server Connection Failure T he number of minutes that the XenApp server has been
disconnected from the License Server.
Maximum License Check-In Response T ime T he maximum license check-in response time in milliseconds.
Maximum License Check-Out Response T ime T he maximum license check-out response time in milliseconds.
T he following counters are available through the Citrix MetaFrame Presentation Server performance object in Performance
Monitor.
Counter Description
Application Resolution T ime (ms) T he time in milliseconds that a resolution took to complete.
Cumulative Server Load T he combined processor utilization and connected XenApp user session
loads for this server.
DataStore bytes read T he number of bytes read from the data store.
DataStore bytes read/sec T he number of bytes of data store data read per second.
DataStore bytes written/sec T he number of bytes of data store data written per second.
DataStore reads T he number of times data was read from the data store.
DataStore reads/sec T he number of times data was read from the data store per second.
DataStore writes/sec T he number of times data was written to the data store per second.
DynamicStore bytes read/sec T he number of bytes of dynamic store data read per second.
DynamicStore bytes written/sec T he number of bytes of dynamic store data written per second.
DynamicStore Gateway Update Count T he number of dynamic store update packets sent to remote data
collectors.
DynamicStore Gateway Update, Bytes T he number of bytes of data sent across gateways to remote data
Sent collectors.
DynamicStore Query Count T he number of dynamic store queries that were performed.
DynamicStore Query Request, Bytes T he number of bytes of data received in dynamic store query request
Received packets.
DynamicStore Query Response, Bytes T he number of bytes of data sent in response to dynamic store queries.
Sent
DynamicStore reads/sec T he number of times data was read from the dynamic store per second.
DynamicStore Update Bytes Received T he number of bytes of data received in dynamic store update packets.
DynamicStore Update Packets T he number of update packets received by the dynamic store.
Received
DynamicStore Update Response Bytes T he number of bytes of data sent in response to dynamic store update
Sent packets.
DynamicStore writes/sec T he number of times data was written to the dynamic store per second.
ICA Roundtrip Latency Median T he median time of ICA roundtrip latency for all sessions on the server.
LocalHostCache bytes read/sec T he number of bytes of IMA local host cache data read per second.
LocalHostCache bytes written/sec T he number of bytes of IMA local host cache data written per second.
LocalHostCache reads/sec T he number of times data was read from the IMA local host cache per
second.
LocalHostCache writes/sec T he number of times data was written to the IMA local host cache per
second.
Maximum number of XML threads T he maximum number of threads allocated to service Web-based sessions
since the server restarted.
Resolution WorkItem Queue Executing T he number of resolution work items that are currently being executed.
Count
Resolution WorkItem Queue Ready T he number of resolution work items that are ready to be executed.
Count
WorkItem Queue Executing Count T he number of work items that are currently being executed.
WorkItem Queue Pending Count T he number of work items that are not yet ready to be executed.
WorkItem Queue Ready Count T he number of work items that are ready to be executed.
Zone Elections T he number of zone elections. T his value starts at zero each time the IMA
Service starts and is incremented each time a zone election takes place.
T he following counters are available through the ICA Session performance object in Performance Monitor.
Input Audio Bandwidth T he bandwidth, measured in bps, used when playing sound in an ICA session.
Input Clipboard Bandwidth T he 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 T he 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 T he 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 T he bandwidth, measured in bps, used when sending data to the client
COM port.
Input Control Channel Bandwidth T he bandwidth, measured in bps, used when executing LongCommandLine
parameters of a published application.
Input Drive Bandwidth T he bandwidth, measured in bps, used when performing file operations
between the client and server drives during an ICA session.
Input Font Data Bandwidth T he bandwidth, measured in bps, used when initiating font changes within a
SpeedScreen-enabled ICA session.
Input HDX Mediastream for Flash Data T he bandwidth, measured in bps, used when streaming Flash data in an
Bandwidth HDX-enabled session.
Input Licensing Bandwidth T he 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 T he 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. T his is measured in bps.
Input LPT 2 Bandwidth T he 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. T his is measured in bps.
Input Printer Bandwidth T he bandwidth, measured in bps, used when printing to a client printer
through a client that has print spooler support enabled.
Input Seamless Bandwidth T he bandwidth, measured in bps, used for published applications that are
not embedded in a session window.
Input Session Compression T he compression ratio used from client to server for a session.
Input Session Line Speed T he line speed, measured in bps, used from client to server for a session.
Input SpeedScreen Data Channel T he bandwidth, measured in bps, used from client to server for data channel
Bandwidth traffic.
Input T ext Echo Bandwidth T he bandwidth, measured in bps, used for text echoing.
Input T hinWire Bandwidth T he bandwidth, measured in bps, used from client to server for T hinWire
traffic.
Latency - Last Recorded T he last recorded latency measurement for the session.
Latency - Session Average T he average client latency over the lifetime of a session.
Latency - Session Deviation T he difference between the minimum and maximum measured latency
values for a session.
Output Audio Bandwidth T he bandwidth, measured in bps, used for playing sound in an ICA session.
Output Clipboard Bandwidth T he 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 T he 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 T he 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 T he bandwidth, measured in bps, used when receiving data from the client
COM port.
Output Control Channel Bandwidth T he bandwidth, measured in bps, used when executing LongCommandLine
parameters of a published application.
Output Drive Bandwidth T he bandwidth, measured in bps, used when performing file operations
between the client and server drives during an ICA session.
Output Font Data Bandwidth T he bandwidth, measured in bps, used when initiating font changes within a
SpeedScreen-enabled ICA session.
Output Licensing Bandwidth T he bandwidth, measured in bps, used to negotiate licensing during the
Output HDX Mediastream for Flash T he bandwidth, measured in bps, used when streaming Flash data in an
Data Bandwidth HDX-enabled session.
Output LPT 1 Bandwidth T he 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 T he 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 T he bandwidth, measured in bps, used when performing management
functions.
Output Printer Bandwidth T he bandwidth, measured in bps, used when printing to a client printer
through a client that has print spooler support enabled.
Output Seamless Bandwidth T he bandwidth, measured in bps, used for published applications that are
not embedded in a session window.
Output Session Bandwidth T he bandwidth, measured in bps, used from server to client for a session.
Output Session Compression T he compression ratio used from server to client for a session.
Output Session Line Speed T he line speed, measured in bps, used from server to client for a session.
Output SpeedScreen Data Channel T he bandwidth, measured in bps, used from server to client for data channel
Bandwidth traffic.
Output T ext Echo Bandwidth T he bandwidth, measured in bps, used for text echoing.
Output T hinWire Bandwidth T he bandwidth, measured in bps, used from server to client for T hinWire
traffic.
T he following performance counters are available for the Secure T icket Authority (STA).
ST A Bad Data Request Count T he total number of unsuccessful ticket validation and data retrieval
requests during the lifetime of the ST A.
ST A Bad T icket Request Count T he total number of unsuccessful ticket generation requests received
during the lifetime of the ST A.
ST A Count of Active T ickets T otal count of active tickets currently held in the ST A.
ST A Good Data Request Count T he total number of successful ticket validation and data retrieval
requests received during the lifetime of the ST A.
ST A Good Refresh Request Count T he total number of successful ticket refresh requests received during
the lifetime of the ST A.
ST A Good T icket Request Count T he total number of successful ticket generation requests received
during the lifetime of the ST A.
ST A Peak All Request Rate T he maximum rate of all monitored activities per second.
ST A Peak Data Request Rate T he maximum rate of data requests per second during the lifetime of the
ST A.
ST A Peak T icket Refresh Rate T he maximum rate of refresh requests per second during the lifetime of
the ST A.
ST A Peak T icket Request Rate T he maximum rate of ticket generation requests per second during the
lifetime of the ST A.
ST A T icket T imeout Count T he total number of ticket time-outs that occur during the lifetime of
the ST A.
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).
T he 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
Control whether or not to allow the use of multiple audio Audio Plug N Play
devices
Control whether or not to allow audio input from Client microphone redirection
microphones on the user device
Control audio mapping to speakers on the user device Client audio redirection
Printers connected to the client LPT port LPT port redirection bandwidth limit, or
LPT port redirection bandwidth limit percent
T WAIN devices (such as a camera or scanner) T WAIN device redirection bandwidth limit, or
T WAIN device redirection bandwidth limit percent
Control whether or not drives on the user device are Auto connect client drives
connected when users log on to the server
Control cut-and-paste data transfer between the server and Client clipboard redirection
the local clipboard
Control how drives map from the user device Client drive redirection
Control whether or not user devices attached to local COM Client COM port redirection
ports are available in a session
Control whether or not client printers attached to local LPT Client LPT port redirection
ports are available in a session
Control whether or not users' local floppy drives are available Client floppy drives, and
in a session Client drive redirection
Control whether or not users' network drives are available in Client network drives, and
a session Client drive redirection
Control whether or not users' local CD, DVD, or Blu-ray drives Client optical drives, and
are available in a session Client drive redirection
Control whether or not users' local removable drives are Client removable drives, and
available in a session Client drive redirection
Control whether or not users' T WAIN devices, such as Client T WAIN device redirection
scanners and cameras, are available in a session and control T WAIN compression level
compression of image data transfers
Control whether or not USB devices are available in a session Client USB device redirection, and
Client USB device redirection rules
Control whether or not Plug-and-Play USB devices, such as a Client USB Plug and Play device redirection
camera or a point-of-sale device, are available in a session
Improve the speed of writing and copying files to a client Use asynchronous writes
disk over a WAN
Content Redirection
Control whether or not to use content redirection from the Host to client redirection
server to the user device
Control the amount of memory allocated for displaying Display memory limit
graphics in a session
Control how a user's display degrades in response to memory Display mode degrade preference
Control compression of images for use in sessions of limited Lossy compression level
bandwidth Lossy compression level threshold value
Progressive compression level
Progressive compression threshold value
Control image display optimization based on whether or not Extra Color Compression, and
users reach a specified bandwidth threshold Extra Color Compression T hreshold
Control whether or not Flash content is rendered in sessions Flash acceleration (legacy features with Citrix Online
plug-in 12.1)
Flash default behavior (second generation features
with Citrix Receiver)
Control whether or not to allow the use of legacy Flash Flash backwards compatibility
acceleration for older versions of Citrix Receiver (formerly
Citrix Online plug-in)
Control whether or not Web sites can display Flash content Flash server-side content fetching URL list
when accessed in sessions Flash URL compatibility list
Enable color matching of Flash instances and the Web Flash background color list
pages on which they appear within a session
Control the length of time sessions remain active after Linger Disconnect T imer Interval
exiting applications Linger T erminate T imer Interval
Control the length of time pre-launched sessions are inactive Pre-launch Disconnect T imer Interval
before disconnecting or terminating Pre-launch T erminate T imer Interval
Enable support for multi-stream connections between Multi-Stream (Computer and User settings)
servers and user devices
Printing
Control creation of client printers on the user device Auto-create client printers, and
Client printer redirection
Allow use of legacy printer names and preserve backward Client printer names
compatibility with prior versions of the server
Control the location where printer properties are stored Printer properties retention
Control whether print requests are processed by the client Direct connections to print servers
or the server
Control whether or not users can access printers connected Client printer redirection
to their user devices
Control installation of native Windows drivers when Automatic installation of in-box printer drivers
automatically creating client and network printers
Control when to use the Universal Printer Driver Universal print driver usage
Security
Require that connections use a specified encryption level SecureICA minimum encryption level
Limit the number of sessions that a user can run at the same Concurrent logon limit
time
Allow or deny permission for users to shadow connections Users who can shadow other users
Users who cannot shadow other users
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).
Advance warning f requency interval
T his setting defines the interval between appearances of the advance warning message to users.
T his setting contains the editable text of the message to users notifying them of upcoming software updates or
maintenance requiring them to log off.
By default, the message contains the following: {T IMESTAMP}Please save your work and log off. T he server will go offline
for maintenance in {HOURSLEFT } hours.
T his setting contains the editable text of the title bar of the advance warning message to users.
T his setting defines how far before the software update or maintenance the advance warning message first appears.
By default, the advance warning time period setting is 16:00:00, indicating the first advance warning message appears
approximately 16 hours before the software update or maintenance.
T his setting contains the editable text of the message alerting users that a forced logoff has begun.
By default, the message contains the following: T he server is currently going offline for maintenance.
T his setting contains the editable text of the title bar of the final force logoff message.
T his setting defines the period of time between notifying users to log off and the implementation of the forced logoff to
process the pending software updates or maintenance.
T his setting contains the editable text of the message telling users to save their work and log off prior to the start of a
forced logoff.
By default, the message contains the following: {T IMESTAMP} Please save your work and log off. T he server will go offline
for maintenance in {MINUT ESLEFT } minutes.
T his setting contains the editable text of the title bar of the force logoff message.
T his setting determines that, when enabled, the XenApp Agent service can automatically switch from Configuration
Manager mode to Provisioning Services mode when it is running in a Provisioning Services environment. If the setting is
T his setting contains the editable text of the message notifying users when the server is about to be restarted.
By default, the message contains the following: T he server is currently going offline for maintenance.
T his setting determines the frequency with which the XenApp Agent service runs the agent task
T his 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.
T his setting specifies the TCP/IP port number used by the ICA protocol on the server. T he 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.
T his 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.
Desktop launches
T his 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.
T his 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.
T his setting allows or prevents the use of multiple audio devices to record and play sound. By default, this setting is allowed.
Audio Quality
T his setting specifies the quality level of sound received in user sessions. By default, the sound quality is set to High - high
definition audio.
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.
T his setting allows or prevents applications hosted on the server to play sounds through a sound device installed on the
user device. T his 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.
T his 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.
T his 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. T he 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.
T his 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. T he server farm does not provide a combined log of reconnection events for all servers.
T his 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.
T his 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.
T his 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.
T his 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.
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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his setting specifies the maximum allowed bandwidth in kilobits per second for controlling T WAIN 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 T WAIN device redirection bandwidth limit percent setting, the most
restrictive setting (with the lower value) is applied.
T his setting specifies the maximum allowed bandwidth for controlling T WAIN 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 T WAIN 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.
XenApp 6.5
T his 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.
T he 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.
A secure connection (for example, using SSL/T LS 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 wallpaper
T his 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
T his 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. T he
menu appears when you mouse over that arrow.
T his 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.
T his 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.
T his delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for
ICA traffic.
T his setting specifies the frequency, in seconds, at which ICA round trip calculations are performed. By default, ICA round
trip is calculated every 15 seconds.
T his 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.
T his delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for
ICA traffic.
T his 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.
T his 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.
T his 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.
T his 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.
T his setting allows or prevents users from accessing and saving files to network (remote) drives through the user device. By
default, accessing client network drives is allowed.
When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are
disabled, client network drives are not mapped and users cannot access these drives manually, regardless of the state of
the Client network drives setting.
To ensure network drives are automatically connected when users log on, configure the Auto connect client drives setting.
T his 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.
T his 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.
T his 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.
T hese URL types are opened locally when you enable this setting:
Hypertext T ransfer Protocol (HT T P)
Secure Hypertext T ransfer Protocol (HT T PS)
Real Player and QuickT ime (RT SP)
Real Player and QuickT ime (RT SPU)
Legacy Real Player (PNM)
Microsoft’s Media Format (MMS)
T his 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.
T his 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.
T his 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.
T his 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. T his setting overrides all other special folder redirection settings throughout XenApp.
Because special folder redirection must interact with the user device, policy settings that prevent users from accessing or
saving files to their local hard drives also prevent special folder redirection from working. If you enable the Special folder
redirection setting, make sure the Client fixed drives setting is enabled as well.
T his 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.
T he 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.
Flash acceleration
T his setting enables or disables Flash content rendering on user devices instead of the server. By default, client-side Flash
content rendering is enabled.
Note: T his 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.
T his 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. T he 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
T his 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.
T his setting establishes the default behavior for second generation Flash acceleration. By default, Flash acceleration is
enabled.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
T he Legacy Server side optimizations section contains policy settings for handling Flash content on session hosts.
T his 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.
T his 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.
T his 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.
Image caching
T his 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.
T his 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.
T his setting displays a brief explanation to the user when the color depth or resolution is degraded. By default, notifying
users is disabled.
T his setting discards queued images that are replaced by another image. By default, queuing and tossing is enabled.
T his improves response when graphics are sent to the user device. Configuring this setting can cause animations to become
choppy due to dropped frames.
T he Caching section contains settings that enable you to cache image data on user devices when user connections are
limited in bandwidth.
T he 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.
T his 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.
T his 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.
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. T his may involve returning and reallocating the licenses.
If you change the port number of the license server, specify a new number in all the license files on the server.
T he Power and Capacity Management section contains policy settings for managing Power and Capacity Management
agents.
Farm name
T his 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. T hey 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
T his 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
Valid workload names can be up to 80 characters. Additionally, the Value box cannot be null and a valid entry cannot consist
of spaces.
T he T ime Zone Control section contains policy settings related to using local time in sessions.
T his 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.
T his 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 (User
Configuration > Policies > 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.
T his 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.
T his 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.
T his 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.
T his 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.
T his 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.
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\SOFT WARE\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
T hese policy settings are applicable to the following Citrix products, unless otherwise specified:
XenApp
XenDesktop
T his 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.
T he 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.
T he Office Communicator client software must be published on the server.
T his 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 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. T his is rare but can happen under low bandwidth conditions; for example, with media in
which there is a very low frequency of key frames.
T his setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size is 5 seconds.
T his setting enables or disables using the buffer size specified in the Windows Media Redirection Buffer Size setting. By
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).
Multi-Port Policy
T his 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. T his setting takes effect only when the Multi-Stream Computer policy
setting is enabled.
T his setting enables or disables multi-stream on the XenApp server. By default, Multi-Stream is disabled.
If you use Citrix Branch Repeater with Multi-Stream support in your environment, you do not need to configure this setting.
Configure this policy setting when using third-party routers or legacy Branch Repeaters to achieve the desired Quality of
Service.
When configuring this setting, reboot the server to ensure changes take effect.
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)
T his setting enables or disables multi-stream on the user device. By default, this setting is disabled for all users.
T his 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
T his 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.
T his 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.
T his setting allows or prevents access to COM ports on the user device. By default, COM port redirection is allowed.
T his 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. T his policy setting is necessary only for servers
that host legacy applications that print to LPT ports.
T his 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.
T his 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. T he default printer in a session will be the first printer autocreated in the
session, which is either:
T he first printer added locally to the Windows server in Control Panel > Devices and Printers
T he 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).
T his setting specifies the events that are logged during the printer auto-creation process. You can choose to log no errors
or warnings, only errors, or errors and warnings. By default, errors and warnings are logged.
An example of a warning is an event in which a printer’s native driver could not be installed and the universal printer driver is
installed instead. To allow universal printer drivers to be used in this scenario, configure the Universal print driver usage
setting to Use universal printing only or Use universal printing only if requested driver is unavailable.
Session printers
T his 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.
T his 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. T his setting is applied to direct connections on the desktop via Quick Launch. T his
T he 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.
XenApp
XenDesktop
T his setting takes effect only if the Client printer redirection setting is present and set to Allowed.
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, T CP/IP, or other local port.
Do not auto-create client printers turns off autocreation for all client printers when users log on. T his causes the
Remote Desktop Services settings for autocreating client printers to override this setting in lower priority policies.
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.
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.
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. T his gives server applications access to
client printers that have the same drivers as the server, but different driver names.
You can add a driver mapping, edit an existing mapping, 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.
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. T his 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 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.
XenApp
XenDesktop
EMF
XPS
PCL5c
PCL4
PS
You can add, edit, or remove drivers, and change the order of drivers in the list.
Universal printing employs generic printer drivers instead of standard model-specific drivers, potentially simplifying the burden
of driver management on host computers. T he 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.
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.
T he Universal Printing section contains policy settings for managing universal printing.
XenApp
XenDesktop
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. T ypically, 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.
No compression
Best quality (lossless compression)
High quality
Standard quality
Reduced quality (maximum compression)
When adding this setting to a policy that includes the Universal printing optimization defaults setting, be aware of the
following items:
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: T hese options are supported for EMF printing. For XPS printing, only the Desired image quality option is supported.
Universal printing preview preference
T his 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.
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
Prompt f or password
T his 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.
T his setting specifies the minimum level at which to encrypt session data sent between the server and a user device.
T he 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/T LS encryption.
SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server and Receivers to avoid using
SecureICA.
T he 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.
Once disconnected, the XenApp license is released. If the user launches an application before the timer interval expires, the
Linger Disconnect timer resets.
If the user launches an application before the timer interval expires, the Linger Terminate timer resets.
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.
If the user launches an application before the timer expires, the session is reconnected, if necessary. T he application
launches in the existing session. If the timer interval is set to zero, pre-launched sessions are terminated immediately.
T he Server Limits section contains policy settings for controlling idle connections.
T he Session Reliability section contains policy settings for managing session reliability connections.
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. T he user’s display freezes and the cursor
changes to a spinning hourglass until connectivity resumes. T he 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.
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.
T his 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.
T his 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. T hese include user shadowing requests, such as when
users stop shadowing, failure to launch shadowing, and access to shadowing denials.
T his 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
T his 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.
Shadowing is protocol-specific. T his 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.
T his setting specifies the users who are allowed to shadow other users. By default, no users are specified.
T his setting specifies the users who are not allowed to shadow other users. By default, no users are specified.
T his 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.
T he 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. T he
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. T he Sales Manager cannot initiate shadowing sessions with anyone else
in the company.
T he USB devices section contains policy settings for managing file redirection for USB devices.
Client USB Plug and Play device redirection applies to XenApp only.
Policy rules take the format {Allow:|Deny:} followed by a set of tag= value expressions separated by whitespace. T he
following tags are supported:
To create a rule that denies all USB devices, use “DENY:” with no other tags.
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.
T his 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.
T he Moving Images section contains settings that enable you to remove or alter compression for dynamic images.
T he 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: T he increased level of compression associated with progressive compression also enhances the interactivity of
dynamic images over client connections. T he 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:
T he 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.
When enabled, extra color compression is applied only when the client connection bandwidth is below the Extra Color
Compression T hreshold value. When the client connection bandwidth is above the threshold value or Disabled is selected,
extra color compression is not applied.
Heavyweight compression
T his 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.
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.
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.
Connection Limits
Database
Health Monitoring and Recovery
Memory Optimization
Offline Applications
Reboot Behavior
Server
Server Sessions
Virtual IP
XML Service
T hese policies are applicable to XenApp server, except for the policies for Reboot Behavior, which are applicable to XenApp
Enterprise and Platinum editions only.
T he Server Settings section contains policy settings for configuring access control, DNS address resolution, icon handling,
and XenApp product information for licensing.
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.
To ensure only specific farm servers are affected by this setting, configure a worker group that includes only the servers you
specify. T hen, include the worker group in the filter you add to the policy. If no filter is specified, this setting affects all farm
servers.
Consider disabling this setting if caching icons impacts performance of the server. However, do not disable this setting on
servers acting as XML brokers for the farm.
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.
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.
Setting the product edition activates the features available with a particular edition. T he 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.
T he Connection Limits section contains policy settings for controlling user and administrator sessions and logon event
logging.
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.
T he Database Settings section contains policy settings for specifying the database connections used when servers join a
farm.
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
T his 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.
When you specify a failover database server, the value is placed in the ODBC DSN file on the XenApp server. T his setting is
applicable only to farms that use Microsoft SQL Server for the data store.
T he Health Monitoring and Recovery section contains policy settings for configuring Health Monitoring and Recovery tests
and server load balancing exclusions.
Health monitoring
T his 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.
Test Name Def ault Interval Def ault Def ault Recovery Action
(seconds) Threshold
T he Memory/CPU section contains policy settings for managing CPU utilization and memory optimization.
Note: T o 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
T his 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.
When adding this setting to a policy, make sure the Memory optimization setting is present and set to Enabled.
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),
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
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 automatically to a 12-hour clock. If you enter a time without a T T value,
the time defaults to AM.
T he Offline Applications section contains policy settings for controlling offline application access, licensing, and logging.
To configure licenses, administrators can use the License Administration Console or command-line tools. T hey must also
ensure they have a sufficient number of licenses to support the total number of users with offline access permission.
T he total number of users with offline access permission should not exceed the total number of licenses available for
offline access.
T he Reboot Behavior section contains policy settings for scheduling server restarts, disabling logons, and configuring
warning messages.
T hese policy settings are applicable to XenApp Enterprise and Platinum editions only.
To send a custom message, the Reboot custom warning setting must be enabled.
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.
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 T T value, the time of day defaults to AM.
Configure the Reboot warning start time setting to specify when to start sending the warning messages.
Configure the Reboot warning interval setting to specify how often the warning is sent.
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.
Scheduled reboots
T his 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:
Reboot schedule frequency
Reboot logon disable time
Reboot schedule randomization interval
Reboot schedule start date
Reboot schedule time
T he Server Session Settings section contains policy settings for configuring Single Sign-On and session importance.
Session importance
T his 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 Preferential Load Balancing, sessions with higher importance
levels are directed to servers with lower resource allotments.
Single Sign-On
T his 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.
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.
T he Virtual IP section contains policy settings for configuring Virtual IP support for applications.
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.
When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.
After enabling this setting, configure the Virtual IP enhanced compatibility programs list setting to add the applications that
can use virtual IP addresses.
When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.
After enabling this setting, configure the Virtual IP virtual loopback programs list to add the applications that can use virtual
loopback addresses.
When adding programs to the list, specify only the executable name. It is not necessary to specify the entire path.
T he XML Service section contains policy settings for configuring the Citrix XML Service.
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.
When specifying the XML Service port number, the range of values you can enter is 1024-65535. Citrix recommends using
port 8080.
Session importance
T his 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
T his 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.
T his 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.
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
Publishing T he most commonly used method for publishing resources to users for access on any Citrix-enabled
Resources user device. T his approach uses the publishing wizard in the AppCenter to make available hosted and
using the streamed applications, content, and desktops across the XenApp environment.
AppCenter
Publishing VM Publish applications hosted on virtual or physical systems (servers or desktops) through the
Hosted Apps AppCenter. T his 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 Deploy and publish MSI-based applications, App-V sequences, and XenApp published applications to
Publishing XenApp servers, farms, and worker groups. XenApp 6.5 Connector extends Microsoft System Center
Applications 2012 Configuration Manager so you can choose the most appropriate deployment type based on a
with Microsoft user's environment. Users can access applications delivered by XenApp from Citrix Receiver or the
System Center Configuration Manager Application Catalog. XenApp Connector integration with Citrix Provisioning
2012 Services enables you to coordinate updates to XenApp vDisk images.
Configuration
Manager
Deploying and Deploy and publish physical applications and App-V sequences to XenApp directly through the System
Publishing Center Console. By using Power and Capacity Management to directing incoming user connections
Applications away from servers set to receive application, deploy applications to XenApp servers with minimal to
with Microsoft no service interruptions. Deploy Microsoft Windows Server Update Services (WSUS) updates to
System Center XenApp server the same way.
Configuration
Manager 2007
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.
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 addition, the XenApp 6 Powershell SDK offers Citrix customers, distributors, and partners a programmatic interface for
publishing applications by 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.
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.
T he 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.
Evaluating Application Delivery Methods
T he application delivery method is a factor in determining the number of servers in a farm and their individual hardware
requirements.
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. T his 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.
1. In the AppCenter, under the XenApp node, expand the farm or server to which you want to publish an application.
T ip: T o 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 in the Actions pane, select Create folder.
Name the folder for the application you are publishing.
3. Select the folder you created and in the Actions pane, select Publish application.
4. In the Publish Application wizard, on the Name page, provide a display name (maximum 256 characters) and application
description. T he name appears on user devices when users access the application and in 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 T ype page, specify the type of resource you want to publish and the delivery method. You can publish three
types of resources: server desktop, content, and application. T he 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 a 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.
T he AppCenter has a limit of 1,000 unique application icons. When that limit is exceeded, the AppCenter displays a
generic icon for all new applications.
10. On the Publish immediately page, choose whether or not to make the published application immediately available to
users.
By default, the published application is available when you click Finish.
T o prevent users from accessing the application until you manually enable it through application properties, select
Disable application initially.
11. T o view and select advanced options, check Configure advanced application settings now. Alternatively, modify the
advanced settings by using application properties.
When you finish, published resources (unless disabled) are available for users.
For directory services or domain environments, such as Novell Domain Services for Windows or Microsoft Active Directory
Service, containing over 10,000 objects, Citrix recommends the following:
Use groups to categorize and assign permissions to large numbers of users. An application published to one group of
1,000 users requires XenApp to validate only one object for all 1,000 users. T he same application published to 1,000
individual user accounts requires IMA to validate 1,000 objects.
When adding users by using the Citrix User Selector, if the Users container holds thousands of objects, add a list of
names.
To ensure applications are enabled for multiple users, install the applications by using one of the following methods:
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. At the command prompt, enter the command change user /install and then press Enter.
3. At the command prompt, run the Setup executable for the application.
In the Publish Application wizard, select the resource type that you want to deliver and the delivery method. To view the
setting, on the Action menu, select Application properties and then select Type.
To change the resource type, on the Action menu, select Other Tasks > Change application type and follow the instructions
in the wizard.
Content. Publishes nonexecutable information, such as media, web pages, or documents. After selecting this
application type, you must specify the Uniform Resource Locator (URL ) or Uniform Naming Convention (UNC) 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: 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:
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.
T o 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.
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. T his 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 T emplates is not supported. However, you can change the
pre-launch configuration by modifying the registry values, located at:
For 32-bit: HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\ICA Client\Prelaunch and
HKEY_CURRENT _USER\Software\Citrix\ICA Client\Prelaunch
T he application name, display name, description, and icon are visible only in the AppCenter and do not apply to the pre-
launch application.
Properties:
Enable/disable application
Servers
Users
Location
Access conditions
Access gateway filters
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
Properties:
Content redirection allows you to control whether users access information with applications published on servers or with
applications running locally on client devices.
Note: For your users to access content published with a specified universal naming convention (UNC) path and through the
Web Interface, you must publish and configure an application for content redirection so it is associated with the file type
of the published content.
To enable content redirection f rom server to client
When you enable server to client content redirection, embedded URLs are intercepted on the XenApp server and sent to
the client device and the Web browser or multimedia players on the client device open these URLs. T his feature frees
servers from processing these types of requests by redirecting application launching for supported URLs from the server to
the local client device. T he browser locally installed on the client device is used to navigate to the URL. Users cannot disable
this feature. Accessing published content with local client desktops does not use XenApp resources or licenses because
local viewer applications do not use XenApp sessions to display the published content.
For example, users may frequently access Web and multimedia URLs they encounter when running an email program
published on a server. If you do not enable content redirection from server to client, users open these URLs with Web
browsers or multimedia players present on servers running XenApp.
Note: If the client device fails to connect to a URL, the URL is redirected back to the server.
Complete the following configurations:
1. Locate the Citrix policy setting for User > ICA > File Redirection. Add and enable Host to client redirection to allow file
type associations for URLs and some media content to be opened on the user device (disabled by default). When
disabled, content opens on the server.
2. From the Citrix AppCenter, publish the content file and select the users or groups that can access it.
T he following URL types are opened locally through user devices for Windows, Mac and Linux when this type of content
redirection is enabled:
HT T P (Hypertext T ransfer Protocol)
HT T PS (Secure Hypertext T ransfer Protocol)
RT SP (Real Player and QuickT ime)
RT SPU (Real Player and QuickT ime)
PNM (Legacy Real Player)
MMS (Microsoft Media Format)
If content redirection from server to client is not working for some of the HT T PS links, verify that the user device has an
appropriate certificate installed. If the appropriate certificate is not installed, the HT T P ping from the client device to the
URL fails and the URL is redirected back to the server. For legacy plug-ins, content redirection from server to client requires
Internet Explorer Version 5.5 with Service Pack 2 on systems running Windows 98 or higher.
For example, if you have users who run applications such as email programs locally, use the content redirection capability
with XenApp to redirect application launching from the user device to the server. When users double-click attachments
encountered in an email application running locally, the attachment opens in an application that is published on the server,
associated with the corresponding file type, and assigned to the user.
1. On your XenApp Services site, enable content redirection for users to connect to published applications with Citrix
Receiver (formerly the Online Plug-in). If you do not already have a XenApp Services site, you can create one in the
XenApp console or Web Interface console (depending on the version of XenApp you have installed). T he option is
located under PNAgent settings > Server Farms > Manage Server Farms > Advanced.
2. In the Citrix AppCenter, as you publish the application, associate it with file types and select the users or groups that can
connect to it. When users launch the application, the file type association is changed to reference the published
application in the Windows registry on the user device.
For example, if you publish a Microsoft Word document, make sure to also publish Microsoft Word on a XenApp server so
that the .doc file can open in Word.
Note: When you associate a file type with a published application, several file extensions can be affected. For example,
when you associate the Word document file type, file extensions in addition to the .doc extension are associated with
the published application.
3. Verify that the Client drive redirection User policy setting is enabled, either for the entire farm, for specific servers, or for
specific users or groups.
When you configure content redirection from client to server, context menu commands available from within Windows
Explorer function differently than on user devices that do not use this feature. For example, if you right-click a file in
Windows Explorer on a user device with content redirection from client to server enabled for the file type, the Open
command opens the file with the remote application on XenApp. For a streamed application, the file could be opened either
on the user device or on the XenApp server, depending on the delivery configuration.
Most commands on the Windows Explorer context menu are unaffected because they are not configured under keys
modified by XenApp. Context menu items are generally defined by each application when installed.
Only a Citrix administrator with full access to the Published Applications task can change published applications. Use the
application properties to change settings for a published application, including the location of the published application, the
servers on which the published application is available, and the user accounts allowed to access the published application.
Important: T he resource type you publish (application, content, or server desktop) determines your path through the Publish
Application wizard; consequently, the properties associated with the resource may vary.
To rename or delete a published application
Use the Name property to change the application name and description that you selected in the Publish Application wizard.
Changes take effect after the user reconnects or refreshes the user device. T his feature can distinguish among multiple
versions of the same application.
As you publish updated applications on your servers, delete the older or less-frequently used applications. Deleting a
published application does not uninstall the application. It simply removes access to the application through plug-in
connections. You can delete multiple applications simultaneously.
Important: If a duplicate application name is found in the farm, a four-digit hexadecimal number is appended to the original
string. If the character limit is reached and duplicated, the AppCenter replaces the end characters with four-digit
hexadecimal numbers, starting from the right.
1. In the left pane of the Citrix AppCenter, select the published application.
2. From the Action menu, select Application properties and then select Name.
3. T he Display name is the name users see on their user device, and it must be unique within the folder. XenApp supports
application names that use Latin-1 and Unicode character sets, including characters used in Japanese, Chinese, and
Korean.
4. T he Application name appears on the Current Settings tab in the AppCenter and should be unique within a farm
(maximum 38 characters). When the application is published, this name is the same as the display name by default.
5. T he Application description appears in Web Interface.
Choose the server on which the published application or desktop is available through the Servers page of the Publish
Application wizard. To modify the setting, from the Action menu, select Application properties and then select Servers.
If you modify your servers for a published application, some users may not be in a trusted domain for that server. If you
receive an error message when trying to modify configured servers for a published application, duplicate the application and
then modify the servers and users lists of the new application.
Before you publish resources, consider how the configuration of user accounts can affect their access, including
anonymous access and explicit (configured) user account access.
Note: As a best practice, use groups for unique roles to categorize and assign permissions to large numbers of users. An
application published to one group of 1,000 users requires the validation of only one object for all 1,000 users. T hat same
application published to 1,000 individual user accounts requires the validation of 1,000 objects.
1. Select how to configure user accounts:
Select Allow anonymous users to let all users log on anonymously and start the streamed application without
specifying a user name, domain name, and password (selected by default). T his selection disables the remaining
options on the page.
Select Allow only configured users to allow only configured users to start the application. For example, select this
option for all streamed applications.
Selecting this option enables the Select directory type drop-down list, which allows you to configure the users for this
application. You can configure the list later in the application properties.
Note: Streamed applications do not support anonymous users. Additionally, if you enable the streamed application for
offline access, these options are not shown.
2. Use the Select directory type drop-down box to select either Citrix User Selector or Operating System User Selector.
3. Click Add.
If you selected Citrix User Selector, complete the following tasks in the Select Users or Groups dialog box:
Select your account authority from the Look in drop-down list. T he drop-down list contains all trusted account
authorities configured on the servers in the farm. T hese include Novell Domain Services for Windows (NDSfW)
domains, Windows NT domains, Active Directory domains, and local servers. (NDSfW domains appear only if previously
configured.) When you select an account authority, the user accounts that are part of the selected authority appear
in the window below the drop-down list. By default, only user groups appear.
Select Show users to display all user names in the selected domain. T his option displays every user in the selected
domain. For NDS, alias objects also appear. T he user accounts you select are listed in Configured users.
T ip: Instead of selecting names from the list, type them in a text box. T o do this, click Add List of Names and use
semicolons (;) to separate names.
If you selected Operating System User Selector, use the standard Windows dialog box to select your user or group.
Note: T his option has several limitations. You can browse only account authorities and select users and groups that are
accessible from the computer running the AppCenter. In addition, you might initially select users and groups outside the
trust intersection of the farm, which causes errors later. Other limitations include the inability to add NDS users and
groups.
T he list of user accounts is added to the Configured Accounts list. Changes take effect the next time the user launches the
application.
Before you publish resources, decide how to configure user accounts so that as you publish applications in the wizard, you
can select appropriate user access.
T here are limitations on explicit users who log on to a server farm to run applications: administrators can specify the type of
profile, settings, and other configurations for these users.
Anonymous users are granted minimal session permissions that include the following restrictions:
When an anonymous user session ends, no user information is retained. T he server does not maintain desktop settings,
user-specific files, or other resources created or configured for the user device.
Note: T he anonymous user accounts that XenApp creates during installation do not require additional configuration. If you
want to modify their properties, do so with the standard Windows user account management tools.
To configure shortcuts f or user devices
Configure or modify the application shortcut presented to user devices on the Shortcut presentation page of the
Application Publishing wizard. To modify the setting, from the Action menu, select Application properties and then select
Shortcut presentation.
1. T o select a new icon for the application, click Change icon and use the options on the window.
2. T o organize applications within folders on the user device, under Client application folder, enter a folder name for this
application. When users view their applications, this application is listed in the folder you entered. T his feature is disabled
by default in Receiver for Windows. Refer to the Receiver for Windows documentation for information about enabling
it.
3. T o specify the placement of the application shortcut, in the Application shortcut placement section, select one or more
of these options:
Add to the client’s Start menu. Creates a shortcut to this application in the user’s local Start menu. T his feature
applies only to applications published to legacy PNAgent sites. A folder appears in the first pane of the Start menu in
the location you select:
Place under Programs folder. T his option creates a shortcut under the Programs folder of the local Start menu. If a
folder structure is specified in the Start Menu Folder text box, the folder structure is created within the local
Programs folder.
Start menu folder. T he location of the shortcut within the Start menu (or Programs folder, if selected). For
example, to have the application appear under a folder called “Reports,” enter Reports. For more than one level of
folders, separate each folder name with a backslash; for example, “Reports\HR\survey.” If no folder structure is
Changes take effect after the user reconnects or refreshes the user device.
If NetScaler Gateway is installed, use the Access Control page of the Publish Application wizard specify the type of
connections that allow the application to appear in the list of published applications on the user device. To modify the
setting, on the Action menu, select Application properties and then select Access control.
For example, if NetScaler Gateway is installed and the application has software requirements, configure Web Interface or
StoreFront settings in NetScaler Gateway and configure the Web Interface or StoreFront to accept connections from
NetScaler Gateway. You also need to configure the Secure T icket Authority (STA) on NetScaler Gateway. For more
information, see "Providing Access to Published Applications and Virtual Desktops T hrough the Web Interface" in the
NetScaler Gateway documentation.
Important: T o use this feature, set your servers that receive XML requests to trust those requests.
Use this page to view or modify connection types:
Allow connections made through Access Gateway Advanced Edition (Version 4.0 or later). T his is the default. Select the
type of connections that allow the application to appear in the list of applications:
Any connection. Allows connections made through NetScaler Gateway (Version 4.0 or later), regardless of filters. T his
is the default.
Any connection that meets any of the following filters. Allows connections made through NetScaler Gateway that
meet one or more of the connection filters specified in the list.
To Add or Edit a filter, click the respective button and enter the predefined NetScaler Gateway farm name and filter.
Allow all other connections. Allows all connections except those made through NetScaler Gateway. T his is the default.
Users who do not have the required software running on the user device cannot access the published application.
By associating published applications with file types and then assigning the applications to users, you implement the
following automatically:
Content redirection from user device to server. Devices running the Citrix Receiver (or other Citrix Plug-in) open all files of
an associated type with a specific published application and delivery method. For example, when users double-click an
email attachment, the attachment opens in an application based on the file type and delivery method set for those
users.
Note: If you do not want specific users to launch published applications automatically when opening published content,
do not assign published applications associated with file types to those users.
Content publishing. Users connecting through the Web Interface or using the Citrix Receiver open content published on
servers with applications published on servers. For example, you publish a Microsoft Word document. When you also
publish the Microsoft Word application, associate it with a list of file types (files with the .doc extension, for example),
and assign it to a group of users, the published content is opened in the Microsoft Word application published on the
server.
File type association is a two-step process. For example, if you want to associate Microsoft Word with the .doc file
extension:
Publish a document of the Microsoft Word for Windows file type.
Publish the Microsoft Word application and associate it with the Microsoft Word for Windows file type. When users
double-click the document from the user device, it opens in the Microsoft Word application published on the server.
Users connecting through the Receiver or Web Interface can open published content with published applications.
1. Select one or more of the buttons to select the file types that you want the application to open when a user opens a
file. Published applications can be associated with one or more file types.
2. T o list all file types associated with the application, click Show all available file types for this application. Clear the check
box to display only the selected file types.
When changing the available file types for an application, select this check box to display the superset of file types
available, not just those selected when initially publishing the application.
Note: When you associate a file type with a published application, several file extensions can be affected. For example,
when you associate the Word document file type, file extensions in addition to the .doc extension are associated with
the published application.
File types are associated with applications in a server’s Windows registry. If you install and then publish applications after
installing XenApp, you must update the file type associations in the Windows registry on the server.
Choose which file types are opened with a published application. When you publish an application, a list of available file
types appears on the Content redirection page. T his list is current only if the data store was updated with the file type
associations for the application. Update the data store from the registries of several servers containing an application to
associate a complete set of file types with the application.
If you publish applications to be hosted on more than one server, be sure to update the file types on each server.
To access this dialog box, from the Publish Application wizard, continue to the Alternate profiles page. Alternatively, select a
published application in the left pane and from the Action menu, select Modify application properties > Modify all
properties > Advanced > Alternate profiles.
When you click Add, enter the starting and ending IP range for which the alternate profile applies.
Specify the full path of the alternate profile or browse to locate the profile, such as a UNC: \\citrixserver\profiles\Adobe
Reader\Adobe reader.profile. After you configure the range, user devices from IP addresses within the specified range
access the applications from the alternate profile instead of from the default profile.
Command-line parameters
Application limits and the importance of applications
Application appearance
Application availability (enable or disable)
Use the Location page of the Publish Application wizard to enter the command line and pass parameters to published
applications. To modify the setting, from the Action menu, select Application properties and then select Location.
When you associate a published application with file types, the symbols “%*” (percent and star symbols enclosed in double
quotation marks) are appended to the end of the command line for the application. T hese symbols act as a placeholder for
parameters passed to user devices.
If a published application does not launch when expected, verify that its command line contains the correct symbols. By
default, XenApp validates parameters supplied by user devices when the symbols “%*” are appended. For published
applications that use customized parameters supplied by the user device, the symbols “%**” are appended to the command
line to bypass command-line validation. If you do not see these symbols in a command line for the application, add them
manually.
If the path to the executable file includes directory names with spaces (such as “C:\Program Files”), you must enclose the
command line for the application in double quotation marks to indicate that the space belongs in the command line. To do
this, follow the instructions below for adding quotation marks around the %* symbols and then add a double quotation
mark at the beginning and the end of the command line. Be sure to include a space between the closing quotation mark for
the command line and the opening quotation mark for the %* symbols.
For example, change the command line for the published application Windows Media Player to the following:
When a user starts a published application, the plug-in establishes a connection to a server in the farm and initiates a
session. If the user then starts another published application without logging off from the first application, the user has
two concurrent connections to the server farm. Use this page to limit the number of concurrent connections that users can
make.
You can configure application limits and importance from the Publish Application wizard Limits page, or from the Action
menu > Modify application properties > Modify all properties > Advanced > Limits.
If Preferential Load Balancing is available in your XenApp edition, this setting (along with the session importance policy
In the Application Importance list box, set the priority that is used with the Session Importance setting to determine the
level of service for the session in the XenApp farm: High, Normal, and Low.
Define how the application appears to the user through the Appearance page of the Publish Application wizard, or from
the Action menu, select Application properties and then select Appearance.
T o set the default window size, select Session window size. Specify the window size as a standard resolution, custom
resolution, percentage of the screen, or full screen.
T o set the color depth for the application, select Maximum color quality. T he available options are Better appearance
(32-bit), Better speed (16-bit), or 256-color (8-bit).
T o hide the application title bar and maximize the application at startup, change the setting in Application Startup
Settings.
You can take published applications offline temporarily or indefinitely when you are maintaining a published application,
such as applying an upgrade or a service pack to it. While an application is offline, it is not accessible to users. You can
disable multiple applications simultaneously.
You can initially disable an application as you publish it in the publishing wizard or enable or disable it anytime from the Citrix
AppCenter.
In the Publish Application wizard, continue to the Publish immediately page and select the Disable application initially
check box. When selected, the application is published, but users cannot access it until you enable it.
In the AppCenter, select the application in the navigation pane, and on the Action menu, select Enable application or
Disable application.
Note: If the Disable application initially option is selected and cannot be cleared, either the application requires configured
users but none are specified, or the application is of a type that runs on a server (such as an installed application or
streamed-to-server application) but no servers are specified.
To configure locations of published applications 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. T he 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:
Published content
When you publish content, specify the location using address formats such as the following types (examples shown in
parentheses):
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.
When using command-line validation, add all servers that store content, such as Word documents or PDF files, to the
Trusted Sites list on the XenApp server. When adding servers to the Trusted Sites list, ensure you are logged on to the
XenApp server as Administrator. If the content servers reside in separate domains, ensure trust relationships are established
between these servers and the XenApp server.
You can disable command-line validation for selected published applications or all published applications on a server.
If your environment includes published applications that use customized client-supplied parameters for purposes other
than content redirection from client to server, these applications might not function correctly when command-line
validation is enabled. T o ensure client-supplied parameters are passed from client to server, disable command-line
validation for these published applications.
T o 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.
Use this option to move a published application to another folder in the AppCenter tree or to move servers to another
server folder. Published applications can be moved only to Applications or folders under Applications. Similarly, servers can be
moved only to Servers or folders under Servers. You can move multiple applications simultaneously.
Exporting published application settings to a file allows you to import these settings files and create new applications at a
later time. First you export the desired settings to a settings file, and then you import this file to create new applications
easily. In particular, import these settings files to overwrite the settings on a previously published application.
T his export option offers choices to export a single application, the user list only, or server list only.
A Citrix administrator requires the View permission for the application folder in which the application resides to export
published application settings.
1. In the left pane of the Citrix AppCenter, select the application whose settings you want to export. T o export multiple
published application settings to a file simultaneously, in the right pane of the AppCenter, press CT RL and select the
names of the applications you want to export.
2. From the Action menu, select Other T asks > Export application settings to a file. Select what to export:
Entire Application. Exports the application and all the settings associated with the published application to an .app file.
If you choose this option, you can export settings from multiple applications; select them from the left pane of the
AppCenter before selecting the export task.
Important: If application settings are exported as a batch, they must be imported as a batch.
After you export published application settings to a file, use the settings to create a new application or alter the user or
server settings of a previously published application.
Citrix administrators require Published Application permissions for the application folder in which the application resides to
import application settings.
1. In the left pane of the Citrix AppCenter, select either the folder into which you would like to place a new published
application or the published application whose user or server settings you want to change.
2. From the Action menu, select Other T asks > Import application settings from a file.
3. Use the Open dialog box to locate the settings file you want to import.
If you selected a folder in Step 1 of this procedure and an APP file in Step 2, the new application appears under the
folder you selected.
If you selected a previously published application in Step 1 and either an ASL or AUL file in Step 2, click Yes to confirm
that you want to overwrite existing settings. T he imported ASL or AUL file updates the server settings or user settings
of the application, respectively.
Note: If any of the servers or users that were exported for a published application cannot be imported, a warning message
appears identifying the list of users or servers that could not be imported. You can either proceed or cancel the import at
that point. Cancelling the import cancels the entire import operation. T his situation might occur if a server was removed
from the farm after a published application was exported, if a user was removed from the domain, or if the administrator
does not have proper permissions to publish the application on one or more of the servers that were exported.
T he settings that Citrix plug-ins use to communicate with a published application vary according to the type of plug-in.
Citrix Receiver (which includes the Online Plug-in) automatically uses the settings you specify here to communicate with this
published application.
You can set the encryption level for communications in multiple places in XenApp and your Windows operating system. If a
higher priority encryption level is set elsewhere, the settings that you specify can be overridden. T he most secure setting
out of the following settings is used:
T he encryption settings specified here when publishing an application should be at the same level as the encryption settings
you specified elsewhere. T hat is, any encryption setting you specify in the Remote Desktop Session Host Configuration
tool or connection policies cannot be higher than the application publishing setting.
If the encryption level for an application is lower than any settings you specified for Remote Desktop Session Host
Configuration and connection policies, those settings override the application settings. If the minimum requirements check
box is selected and the plug-in connection does not meet the most restrictive level of encryption, the server rejects the
connection when the plug-in tries to connect to the application. If the minimum requirements check box is selected, the
plug-in setting is always used. However, the plug-in setting must be as secure as the server setting or the connection is
denied.
If you select Minimum requirement under the Encryption list box, plug-ins can connect to the published application only if
they are communicating using the specified level of encryption or higher. After you set this encryption level on the server,
any plug-ins connecting with that server must connect at that encryption level or higher.
If a plug-in is running on a 64-bit computer, only basic encryption is supported. In this situation, setting a level of encryption
higher than Basic and selecting the minimum requirements check box prevents plug-ins from connecting.
Use the virtual IP address feature to allow a dynamically-assigned IP address to each session so that configured
applications running within that session appear to have a unique address.
Also, this feature lets you configure applications that depend on communication with localhost (127.0.0.1 by default) to use
a unique virtual loopback address in the localhost range (127.*).
If the application requires an IP address for identification purposes only, configure your server to use the client IP address.
In Microsoft Server Manager, expand Remote Desktop Services > RD Session Host Connections to enable the RD IP
Virtualization feature and configure the settings. For details, refer to Microsoft help and documentation, including the
Microsoft T echNet Web site.
When the feature is enabled, at session start-up, the server requests dynamically-assigned IP addresses from the
Dynamic Host Configuration Protocol (DHCP) server.
Based on your Virtual IP policy and the settings you configure, the RD IP Virtualization feature assigns IP addresses to
remote desktop connections on a per session or per program basis. If you assign IP addresses for multiple programs,
they share a per-session IP address.
After an address is assigned to a session, it uses the virtual address rather than the primary IP address for the system
whenever the following calls are made:
Bind¸closesocket¸connect, WSAConnect, WSAAccept, getpeername, getsockname,
sendto, WSASendTo, WSASocketW, gethostbyaddr, getnameinfo, getaddrinfo
XenApp extends the Windows virtual IP feature by allowing the gethostbyname API to return the virtual IP address. In
addition, XenApp adds virtual loopback to all APIs.
Note: All processes that require the XenApp feature must be added to the programs list for the Virtual IP policy that you
enable. Child processes do not inherit this functionality automatically. Processes can be added with full paths or just the
Binding Applications
Using the Microsoft IP virtualization feature within the Remote Desktop session hosting configuration, applications are
bound to specific IP addresses by inserting a “filter” component between the application and Winsock function calls. T he
application then sees only the IP address it is supposed to use. Any attempt by the application to listen for TCP or UDP
communications is bound to its allocated virtual IP address (or loopback address) automatically, and any originating
connections opened by the application are originated from the IP address bound to the application.
In functions that return an address such as GetHostByName() (controlled by a XenApp policy) and GetAddrInfo()
(controlled by a Windows policy), if the local host IP address is requested, virtual IP looks at the returned IP address and
changes it to the virtual IP address of the session. Applications that try to get the IP address of the local server through
such name functions see only the unique virtual IP address assigned to that session. T his IP address is often used in
subsequent socket calls (such as bind or connect).
Often an application requests to bind to a port for listening on the address 0.0.0.0. When an application does this and uses
a static port, you cannot launch more than one instance of the application. T he virtual IP address feature also looks for
0.0.0.0 in these types of calls and changes the call to listen on the specific virtual IP address. T his enables more than one
application to listen on the same port on the same computer because they are all listening on different addresses. Note
this is changed only if it is in an ICA session and the virtual IP address feature is turned on. For example, if two instances of
an application running in different sessions both try to bind to all interfaces (0.0.0.0) and a specific port, such as 9000, they
are bound to VIPAddress1:9000 and VIPAddress2:9000 and there is no conflict.
Some applications cannot run in multiple sessions on XenApp. For example, if the application binds to a fixed TCP port on a
specific IP address such as 0.0.0.0 or 127.0.0.1, this prevents multiple instances of the application from running in multiple
sessions because the port is already in use. T he virtual IP feature of XenApp can help solve this problem.
1. Obtain the T CPView tool from Microsoft. T his tool lists all applications that bind specific IP addresses and ports.
2. Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.
3. Launch the application and, using T CPView, note which IP addresses and ports are opened by the application and which
process names are opening these ports.
To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1.
To ensure that an application does not open the same IP address on a different port, launch an additional instance of the
application.
Enable these Virtual IP policy settings to add additional support to the Windows IP Virtualization feature. Virtual IP
addresses provide published applications with unique IP addresses for use in sessions. T his is especially important for
Computer Telephony Integration (CT I) applications that are widely used in call centers. Users can access these applications
on a XenApp server in the same way that they access any other published application. For more information, see
— To determine whether an application needs to use virtual IP addresses
.
T o extend the IP virtualization feature, configure the following Citrix policy settings for Virtual IP:
Virtual IP enhanced compatibility. Use this setting if your application uses the GetHostByName API. When enabled, calls
to GetHostByName within a session return the virtual IP address for the session (disabled by default). T he feature
applies only for the applications listed in the virtual IP compatibility programs list.
Virtual IP compatibility programs list. Lists the applications that use the virtual IP enhanced compatibility policy.
Virtual IP adapter address filtering. Use this setting if your application returns a large number of addresses, which slows
down performance. When enabled, the list of addresses returned by GetAdaptersAddresses includes only the session
virtual IP address and the loopback address, which can improve performance (disabled by default). T he feature is enabled
only for the applications listed in the virtual IP filter adapter addresses programs list.
Virtual IP filter adapter addresses programs list. Lists the applications that use the IP adaptor address filtering policy.
Use the virtual loopback policy for applications that use a loopback address for interprocess communication. Enabling this
virtual IP policy setting allows each session to have its own loopback address for communication. When an application uses
the localhost address (127.0.0.1) in a Winsock call, the virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X,
where X.X.X is a representation of the session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that
the session ID exceeds the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0) to the
maximum of 127.255.255.255.
T he virtual loopback feature does not require any additional configuration other than specifying in the programs list which
processes use the feature. Virtual loopback has no dependency on Virtual IP, so no Microsoft server configuration is needed
to enable virtual loopback.
Use the Client IP Address feature if an application fails because it requires a unique address strictly for identification or
licensing purposes, and the application does not require a virtual address for communication. T his feature hooks only calls
that return a host IP address, such as gethostbyname(). Only use this feature with applications that send the value in this
type of call to the server application for identification or licensing.
If you deploy this feature, consider the IP addresses used by each client device. For example, if two remote users use the
same IP address, a conflict will arise due to the duplicate address.
When these values are configured, configure either the Virtual IP Processes or Virtual Loopback Processes with the same
process names in the Virtual IP compatibility programs list setting or Virtual IP virtual loopback programs list setting for the
policy. T his function creates and manages the following registry entry, which is still required for the Client IP feature to
Note: T he virtual IP address feature functions only with applications that load the user32.dll system dynamic link library.
For identification purposes, some applications require the IP address be unique for a session. Such IP addresses are not
needed for binding or addressing purposes. In such a case, configure the session to use the IP address of the client device.
Type: REG_DWORD
HKEY_LOCAL_MACHINE\SOFT WARE\Wow6432Node\Citrix\VIP\
Name: HookProcessesClientIP
Data: multiple executable names representing application processes that use client IP addresses
Note: On XenApp, 32-bit Edition, these entries are found in HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\VIP\.
3. Close the Registry and restart your server.
4. After making the prescribed registry modifications, add the application process in the programs list for the policy. Do not
configure the use of client IP addresses if:
Plug-ins connect by using network protocols other than T CP/IP
Plug-ins reconnect to disconnected sessions from different user devices
Sessions use a pass-through plug-in
You can publish any Windows application as a VM-hosted application, but ideal candidates include applications that:
To use VM hosted apps, you create a VM hosted apps site and populate it with desktop groups configured with
applications you want to deliver. Users access these applications but have no direct access to the desktops.
You give users access to these applications using the Web Interface. Although VM hosted apps cannot share a farm with
XenApp servers, a VM hosted apps site can share a Web Interface site with XenApp server farms. Applications from VM
hosted apps sites and XenApp farms appear the same to users.
VM hosted apps uses Citrix XenDesktop infrastructure to deliver applications hosted on desktops.
When you install VM hosted apps as a feature of XenApp, the XenDesktop infrastructure required is installed at the same
time. If you are using VM hosted apps as a feature of XenDesktop, the feature is available when you install XenDesktop
5.5; you install nothing additional.
VM hosted apps uses XenApp licenses. Each user consumes one XenApp license for all application sessions, regardless of
whether applications are hosted using VM hosted apps or XenApp server.
If you are using VM hosted apps as a feature of XenApp, no additional Citrix licenses are required.
XenDesktop Controller. T he XenDesktop Controller consists of services that authenticate users, manage the assembly
To provision desktops for VM hosted apps, use Machine Creation Services included in XenDesktop 5.5 or use Provisioning
services.
Use Profile manager to manage user personalization settings for VM hosted apps.
Service monitoring and EdgeSight resource manager are not compatible with VM hosted apps, but application performance
monitoring can be used with VM hosted apps by downloading EdgeSight for Desktops.
Upgrading the server components of VM hosted apps from a previous version is not supported.
You can upgrade the Virtual Desktop Agent. When you install the Virtual Desktop Agent, any previous version of it on the
virtual desktop is automatically upgraded.
For more information on migrating from this version of VM hosted apps to the previous version, see Migrate XenDesktop 4.
Plan your VM hosted apps deployment as part of planning your overall XenApp deployment. Determine which applications
to deliver using VM hosted apps and consider which types of desktops are most appropriate for the applications you want
to deliver, what privileges to give desktop users, and how to secure your desktop environment.
If your VM hosted apps deployment includes virtual machines, install your hosting infrastructure and Provisioning services
separately from VM hosted apps site.
A VM hosted apps site can use a dedicated Web Interface server or share one with other VM hosted apps sites and
XenApp server farms. When VM hosted apps site shares a Web Interface site with a XenApp server farm, users can access
applications from both without regard to how the application is published.
Secure the desktops in your VM hosted apps deployment as described in Security Planning for XenDesktop. When securing
desktops for VM hosted apps:
Users who are administrators can install software on the desktop even though VM hosted apps does not provide direct
access to the desktop
T ime zone considerations apply to applications that display the time of day
Keep in mind that VM hosted apps does not support thin clients
If you plan to use virtual infrastructure, set it up before configuring your VM hosted apps site:
For information on setting up and using XenServer, see the XenServer documentation
For information on setting up and using Microsoft System Center Virtual Machine Manager 2008, see "Using Microsoft
System Center Virtual Machine Manager 2008 with XenDesktop" in the XenDesktop 5 documentation on the Citrix web
site.
For information on setting up and using VMware, see "Using VMware with XenDesktop" in the XenDesktop 5
documentation on the Citrix web site.
Perform the VM hosted app installation and set-up tasks in this order:
1. Install the server-side components of XenDesktop needed for your VM hosted apps deployments.
2. Configure the VM hosted apps site.
3. After you have configured a site you can add more controllers to it, if necessary.
4. T o manage your deployment remotely, install Desktop Studio on additional computers.
5. Install the Virtual Desktop Agent on any base images, virtual desktops, and physical desktops that are part of your VM
hosted apps deployment.
XenDesktop Controller. T he SDKs are automatically installed when you install the Controller.
Desktop Studio. T he SDKs are automatically installed when you install Desktop Studio. Desktop Studio configures the
VM hosted apps site.
Web Interface. VM hosted apps requires the version of Web Interface provided with it.
Desktop Director. T his Web-based tool enables level-1 and level-2 IT Support staff to monitor a VM hosted apps
deployment and perform day-to-day maintenance tasks. Installation of Desktop Director is optional.
License Server. A VM hosted apps site can use an existing license server.
To install server components from the command line, see "XenDesktopServerSetup.exe" in the XenDesktop 5
documentation on the Citrix web site.
T he AutoSelect.exe file performs a wizard-based installation of some or all of these components, allowing you to select
T he Web Interface autorun provided with VM hosted apps does not install the software prerequisites or disable session
sharing and workspace control.
1. Run AutoSelect.exe.
2. Select Install XenDesktop.
3. Accept the End User License Agreement.
4. By default, all server components are selected for installation. Clear any components you do not want to install at this
time.
If you do not want AutoSelect.exe to install the Web Interface, clear Web Access.
If you want to use an existing license server for your VM hosted apps deployment, clear License Server.
5. Accept the default install location or choose another one.
6. Manage firewall configuration. If the Windows firewall is detected, the necessary ports can be opened automatically for
you. If another firewall is detected, you are told which ports you need to open manually.
7. Follow the prompts to complete the installations.
8. If you installed the Desktop Studio, unless you clear Configure XenDesktop after closing on the last page of the
installation wizard, Desktop Studio starts so that you can configure the VM hosted apps site. If Web Interface is not
yet installed, install it before or after configuring the VM hosted apps site.
1. T o install the Web Interface, locate WebInterface.exe file in the files you downloaded for VM hosted apps, in the
x64/Web Interface folder or the x86/Web Interface folder.
2. Run WebInterface.exe and follow the prompts to complete the installation.
See the Web Interface documentation for information on installing and configuring Web Interface. You can configure Web
Interface so that your VM hosted apps site shares a Web Interface site with one or more XenApp server farms.
To remove the XenDesktop components used by VM hosted apps, use the Windows control panel.
Before removing a Controller from the server, remove it from the VM hosted apps site. For information on removing a
Controller from a site, see "To remove a controller" in the XenDesktop 5 documentation on the Citrix web site.
Choose whether you want to use the default database or an existing database:
T o use the locally installed copy of SQL Express to automatically create the site
Host Specify the type of virtual infrastructure host (Citrix XenServer, Microsoft, or
VMWare) your VM hosted apps site will connect to, if any.
If you specified a virtual infrastructure host type, specify the address, user name,
and password of the host.
If you specified XenServer as your host type, and High Availability is enabled on
XenServer, you can select servers for High Availability configuration. Citrix
recommends that you select all servers in the pool to allow communication
between XenDesktop and XenServer if the pool master fails.
Specify whether you want to create virtual machines manually or use XenDesktop
infrastructure to create virtual machines.
Enter a name for the connection between the VM hosted apps site and the virtual
infrastructure host.
T his page appears if you are If both local and shared storage are available on the hosting unit you must select a
configuring the site to use single type; you cannot mix them.
XenDesktop infrastructure to
For each host :
create virtual machines.
Enter a name
Specify shared or local
Select the storage location
Specify the network the virtual machines reside on
4. T o use Access Gateway, pass-through authentication, or smart card authentication with your VM hosted apps site,
configure XenDesktop to trust XML services by running this PowerShell SDK command:
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true
After you configure the site, you can add more XenDesktop Controllers. See "T o add a controller" in the XenDesktop 5
documentation on the Citrix web site.
After the initial configuration, you can change licensing and host configuration settings by starting Desktop Studio and
expanding the Desktop Studio > Configuration node.
If you are using a private certificate authority you may need to install your root certificate on the controller.
To install a certificate on the controller
If you are using XenDesktop or Provisioning Services to provision VMs, you need to install and configure the Virtual Desktop
Agent only once, but if you are using separate stand-alone virtual or physical machines you must install it on each of the
machines so they can register with the controller to allow user connections.
You can install the Virtual Desktop Agent from a console session or from an RDP session, but installing from an ICA session
is not supported.
To install the Virtual Desktop Agent components from the command line, see "XenDesktopVdaSetup.exe" in the
XenDesktop 5 documentation on the Citrx web site.
1. Run AutoSelect.exe.
2. On the Installation page, select Install Virtual Desktop Agent.
3. Associate this desktop with the VM hosted app site.
4. Configure the agent as follows:
Reconfigure the firewall. If the Windows firewall is detected, the necessary ports can be opened automatically for
you. If another firewall is detected, you are told which ports you need to open manually. You can also request to have
the necessary ports opened for desktop shadowing and Windows Remote Management.
If this installation is running in a VM on a hypervisor, select Optimize XenDesktop Performance to have the VM
automatically optimized for use with VM hosted apps. Optimization involves actions such as disabling offline files,
disabling background defragmentation, and reducing the event log size. For full information on the optimization tool,
see the Citrix Knowledge Center.
A summary of what is going to be installed appears.
5. When installation is complete the default is to restart the machine; you must do this for the changes to take effect.
Note: When you install the Virtual Desktop Agent, a new local user group for authorized RDP users is automatically
created. T he group is called Direct RDP Access Administrators. For further information on using protocols other than ICA,
see the Citrix Knowledge Center.
VM hosted apps requires desktops and controllers to have synchronized system clocks. T his is required by the underlying
Kerberos infrastructure that secures the communication between the machines. You can use normal Windows domain
infrastructure to ensure that the system time on all machines is correctly synchronized.
To add or remove components, use the Windows control panel. Select Citrix Virtual Desktop Agent. You can then select to
add, remove, or reconfigure components, or to remove the Virtual Desktop Agent completely.
T he Reconfigure Components option enables you to update the site and port numbers.
To enable users to connect to virtual desktops, you must configure your virtual desktop firewall as follows:
%Program Files%\Citrix\ICAService\picaSvc.exe requires inbound T CP on port 1494. Because this connection uses a
kernel driver, you may need to configure this setting as a port exception rather than a program exception, depending on
your firewall software. If you are running Windows Firewall, you must configure this setting as a port exception.
%Program Files%\Citrix\ICAService\CitrixCGPServer.exe requires inbound T CP on port 2598.
Note: Citrix recommends that you do not use T CP ports 1494 and 2598 for anything other than ICA and CGP, to avoid the
possibility of inadvertently leaving administrative interfaces open to attack. Ports 1494 and 2598 are correctly registered
with the Internet Assigned Number Authority (see http://www.iana.org/).
For communication between controllers and virtual desktops:
Windows Remote Assistance requires ports T CP/135, T CP/3389, and DCOM. On Windows Vista and Windows 7 desktops
you can configure these exceptions by enabling the built-in Remote Assistance exception. On Windows XP you must set
additional exceptions:
1. Enable the Remote Assistance exception.
2. Add and enable the T CP 135 exception.
3. Add and enable the "%systemroot%\PCHEALT H\HELPCT R\Binaries\helpsvc.exe" exception.
4. See http://support.microsoft.com/kb/555179.
To deploy the Virtual Desktop Agent using Active Directory Group Policy Objects
If you are using Active Directory in your environment, you can deploy the Virtual Desktop Agent to all machines in a domain
or Organizational Unit (OU) using Group Policy Objects(GPO).
1. Create a network share and copy the XDSAgent.msi file from the XenDesktop installation media to that share. Note
that you must set permissions on that share to allow read access to the .msi file.
2. Create a new GPO for the Organizational Unit containing the computers on which you want to deploy the Virtual
Desktop Agent.
3. Edit the GPO you created in Step 2 to add the XDSAgent.msi file, using the following guidelines:
Enter the full Universal Naming Convention (UNC) path of the .msi file. For example, \\x-desktop-
svr6\SoftwareInstall\XDSAgent.msi
Choose Assigned as the deployment method
After you save the new GPO, the Virtual Desktop Agent is installed on computers within the specified OU next time they
are restarted.
You can restart computers in the OU remotely by running the #shutdown -r -m command.
For more information about using Active Directory, see the Microsoft Active Directory documentation.
Note: If you deploy the Virtual Desktop Agent using GPO, you must also set the Site GUID using GPO. For more
Create and manage application desktop groups and the applications they host.
Manage your XenDesktop Controller environment. See the XenDesktop topic "Managing Your Controller Environment" in
the XenDesktop 5 documentation on the Citrix web site for information on controller discovery, adding controllers,
removing controllers, moving controllers between sites, and configuring the Secure Sockets Layer.
Configure hosts and connections. See the XenDesktop topic "Configuring Hosts and Connections" in the XenDesktop 5
documentation.
Enable users to use smart cards. See the XenDesktop topic "Using Smart Cards with XenDesktop" in the XenDesktop 5
documentation. VM hosted apps do not support thin clients.
Use Citrix policies to control users access or session environment. See the XenDesktop topics "Working with XenDesktop
Policies" and " Policy Settings Reference" in the XenDesktop 5 documentation.
Monitor your VM hosted apps deployment. See the XenDesktop topic "Monitoring XenDesktop 5."
Most VM hosted apps management tasks are perform using Desktop Studio or the XenDesktop SDK. To use the SDK, see
the topic "About the XenDesktop SDK" in the XenDesktop 5 documentation.
In VM hosted apps, collections of virtual machines or physical computers are managed as a single entity called a catalog.
After catalogs of machines are created, the machines can be allocated into desktop groups which then can be used to
deliver VM-hosted applications to users.
VM hosted apps supports all machine types available in XenDesktop 5.5. For information about machine types, creating
catalogs, and managing catalogs, see "Creating and Provisioning Desktops" in the XenDesktop 5 documentation.
VM hosted apps supports both types of desktop groups available in XenDesktop 5.5: private and shared. For a description
of desktop groups, see the topic "About Desktop Groups" in the XenDesktop 5 documentation. When you create a
desktop group for VM hosted apps, you specify that it is an application desktop group.
T he characteristics of a desktop depend on its machine type and desktop group type:
Pooled-random machines are used to create Are virtual machines created by XenDesktop when the catalog
shared desktop groups containing them is created
Discard the user's changes when the user logs off
Can be shut down and started by the XenDesktop Controller
Pooled-static machines are used to create Are virtual machines created by XenDesktop when the catalog
private desktop groups containing them is created
Discard the user's changes when the user logs off
Can be shut down and started by the XenDesktop Controller
Dedicated machines are used to create private Are virtual machines created by XenDesktop when the catalog
Existing machines are used to create private Are virtual machines that already exist when the catalog
desktop groups containing them is created
Are not used with Provisioning services
Can be configured to retain or discard the user's changes when
the user logs off
Can be shut down and started by the XenDesktop Controller
Physical machines are used to create private Enable you to use the XenDesktop Controller to manage
desktop groups dedicated blade PCs in the data center
Can be configured to retain or discard the user's changes when
the user logs off
Cannot be shut down or started by the XenDesktop Controller
Streamed machines are used to create shared Are used with Provisioning services
desktop groups Can be configured to retain or discard the user's changes when
the user logs off
1. In Desktop Studio, select the Assignments node in the left pane and click Create Application Desktop Group. Use the
Create Desktop Group wizard to create the desktop group.
2. On the Catalog page, select a catalog for this desktop group, and enter the number of machines the group will consume
from the catalog.
T ip: If machine administrators include the total number of machines in a catalog's description, this appears on the
Catalog page. Assignment administrators can use the number in conjunction with their selections in the wizard to ensure
sufficient machines are available for the desktop group.
T he Users page appears if the desktop group is based on pooled - static, existing, or physical machines and these
machines have not already been allocated accounts.
3. If you want to give users access to applications hosted on the desktops in a private desktop group, give them access to
the desktop group. On the Users page, add the users or user groups that can access the desktops, and enter the number
of desktops available to each user.
You can select user groups by browsing or entering a list of Active Directory users and groups each separated by a
semicolon. You can import user data from a file after you create the group.
4. On the Machine allocation page, confirm the mapping of machines to users for any machines that were allocated when
the catalog was created.
5. On the Delegation page, select the XenDesktop administrators who will manage this desktop group.
6. On the Summary page, check all details, and enter a name for the desktop group.
If a user accesses one of the applications on a desktop, none of the other applications on that desktop are available to
other users. Other users access applications published by the desktop group using other desktops in the desktop group, if
other desktops are available.
If session sharing is enabled, applications published from the same desktop group share a session when they are accessed
by the same user from the same user device. If session sharing is disabled, applications published from the same desktop
group are launched in separate sessions.
Session sharing requires applications to have the same values for these settings:
Color depth
Encryption
Audio quality
Domain name
User name
Farm name
Special folder redirection
Virtual COM port mapping
Display size
Client printer port mapping
Client printer spooling
EnableSessionSharing
T WIDisableSessionSharing
Applications that require different values for these settings cannot share sessions.
To help determine if applications are compatible with each other for session sharing, use the Get-
BrokerSessionSharingIncompatibleApplication cmdlet in the XenDesktop SDK.
By publishing the same applications to different types of desktop groups containing different machine types, you can
provide a different user experience for the application depending on which desktop group users access the application
from. For example, you might want to give one set of users access to an application on a private desktop group, allowing
the users to customize the application and retain their changes after ending a session, but give another set of users access
to an application on a shared desktop group, so that their changes are discarded when the session ends.
If you publish an application from a private desktop group and a shared desktop group, when a user who has access to the
application in both desktop groups accesses the application, VM hosted apps launches the application from a desktop in
the private desktop group if a desktop is available in that group. If no desktop is available in the private desktop group, VM
hosted apps launches the application from the shared desktop group.
You can configure an application to redirect content from the user device to the desktop hosting the application by
associating file types with the application. When a user opens a file on the user device of the type associated with the
application, this launches the application on a desktop hosting the application.
File types available for association with applications are stored in the VM hosted apps site database. T he list of file types
can be updated by importing file types from desktops in the desktop group assigned to an application while you are
configuring content redirection for the application. A desktop must be in maintenance mode to update file types.
When you create or modify an application using Desktop Studio, the list of file types you see is filtered to include only
those file types likely to be used with the application. To associate other file types with the application, use the
XenDesktop SDK.
To create an application
1. In Desktop Studio, select the Applications node in the left pane and click Create Application.
2. Use the Create Application wizard to create the application:
Wizard What to do
page
Desktop Select existing desktop groups or create new desktop groups to host the application.
groups
Optional: Specify the command-line and working directory to locate the application.
Select the icon displayed. Browse to the icon you want or accept the default icon.
Optional: Specify a folder on the user device for the application shortcut, whether the shortcut
appears on the user device Start menu and its location there, and whether it appears on the user
device desktop.
Modifications made to an application might not take effect for users connected to the application until the users have
logged off their sessions.
You can modify any of an application's properties by using a wizard similar to the one used to create applications.
To use f olders
1. T o create a folder:
1. Select the Applications node or expand the node and select a folder within the node.
2. Click Create Folder.
2. T o manage the folders and the applications:
Select the folder or application and use the right-click menu.
T o copy a folder or application, drag and drop it.
T o move a folder or application, hold the Shift key while dragging and dropping it.
Note: T ags used with VM hosted apps cannot be used to restrict access to machines or applications.
1. In Desktop Studio, select the Applications node in the left pane.
2. Select an application and click Edit tags.
Depending on the machine type, you can log off and disconnect sessions. If you log off a session, it closes and the desktop
becomes available to other users unless it is allocated to a specific user. If you disconnect a session, the user's applications
continue to run and the desktop remains allocated to that user. If the user reconnects, the same desktop is allocated.
Note: Depending on the machine type that the session connects to, you can configure power state timers to ensure that
unused sessions are automatically processed. T his frees up desktops and saves power. For example, XenDesktop can
automatically log off any disconnected session after 10 minutes.
1. In Desktop Studio, find the session you want to log off or disconnect:
Select the Applications node. Select the application for the session you want to log off or disconnect. Select the
Sessions tab.
Use Search to locate the session.
2. Select the session or machine and click Log off or Disconnect.
You can send messages to users to inform them about desktop maintenance. For example, you may want to tell users to
log off before critical maintenance is about to take place.
1. In Desktop Studio, find the users you want to send a message to:
Select the Applications node. Select the application for the session you want to log off or disconnect. Select the
Sessions tab. Select the session for the user you want to send a message to.
Use Search to locate the session. Select a session, desktop, or user.
2. Click Send message.
3. Compose your message and click OK.
Create additional administrators for the site, if necessary. See the topic "Delegating Administration T asks" in the
XenDesktop 5 documentation on the Citrix web site. XenDesktop full administrators and assignment administrators can
create and edit VM-hosted applications.
Set up any general Citrix policies that you require, including policies for printing. See the XenDesktop topic "Working with
XenDesktop Policies" for details of configuring policies.
Configure USB support.
Configure HDX technologies to optimize users' audio and multimedia experience. See "Enhancing the User Experience
With HDX" in the XenDesktop 5 documentation.
Configure time zone settings to allow users to see their local time when using applications that display a time of day.
See the XenDesktop 5 topic "Configuring T ime Zone Settings".
Configure connection timers to provide appropriate durations for uninterrupted connections, idle sessions, and
disconnected sessions. See the XenDesktop 5 topic "Configuring Connection T imers".
Configure workspace control to enable users to roam between different user devices. See the XenDesktop 5 topic
"Workspace Control in XenDesktop."
Workspace control is enabled by default if you installed the Web Interface using the Web Interface autorun.
Workspace control is disabled by default if you installed the Web Interface using AutoSelect.exe or
XenDesktopServerSetup.exe.
If a user accesses a VM-hosted application from a desktop hosted from the same VM hosted apps site as that
application, workspace control is not supported.
You can enable users to interact with a wide range of USB devices during a VM hosted apps session. T he level of support
provided depends on the client installed on the user device; see the relevant client documentation for further details.
Isochronous features in USB devices such as webcams, microphones, speakers, and headsets are supported in typical low
latency/high speed LAN environments. T his allows these devices to interact with packages such as Microsoft Office
Communicator and Skype.
T he following types of device are supported directly in a VM hosted apps session and do not require special configuration:
Keyboards
Mice
Smart cards
Note: Specialist keyboards and mice (for example, Bloomberg keyboards, and 3D mice) can be configured to use USB
support. For more information, see CT X119722 in the Citrix Knowledge Center.
By default, certain types of USB devices are not supported for remoting through VM hosted apps. For example, a user may
have a network interface card attached to the system board by internal USB. Remoting this would not be appropriate. T he
following types of USB device are not supported by default for use in a VM hosted apps session:
Bluetooth dongles
USB network interface cards
USB support allows hosted applications access to USB devices that are connected to the user device. In environments
where security separation between client and hosted application is needed, users should connect only appropriate USB
devices. You can also set policies at the desktop group and user device that restrict the types of USB devices that will be
made available to the hosted application.
For information on all USB devices supported, see CT X119861 in the Citrix Knowledge Center.
Double-hop USB is not supported. T hat is, if a user connects to a VM hosted apps session for a hosted desktop, the VM
hosted apps session does not have USB support.
Add the Client USB device redirection policy setting to a Citrix User policy and set it to Allowed.
If necessary, update the range of USB devices supported.
Edit the plug-in registry (or the .ini files in the case of the Receiver for Linux). For information about how to do this, see
the relevant client documentation. An ADM file is included on the installation media to allow you to make changes to
the plug-in through Active Directory Group Policy: dvd root \os\lang\Support\Configuration\icaclient_usb.adm.
Configure administrator override rules for the Virtual Desktop Agent by adding the Client USB device redirection rules
setting to a Citrix User policy. T he range specified in the Virtual Desktop Agent must correspond exactly to the range
specified on the client; if it does not, then only the devices allowed in both ranges are allowed.
When you are creating new USB redirection rules, refer to the USB Class Codes, available from the USB Web site at
http://www.usb.org/.
USB redirection rules take the format {Allow:|Deny:} followed by a set of tag=value expressions separated by white space.
T he following tags are supported:
Tag Description
Safe to remove device during a No Yes, provided users follow operating system recommendations
session for safe removal
If both client drive mapping and the Client USB device redirection policy setting are enabled, then if a mass storage device is
inserted before or after the session starts, it will be redirected using client drive mapping. Automatic support of devices
upon insertion, however, depends on the client being used and the individual user preferences; for further information, see
the relevant client documentation.
By integrating XenApp Connector with Configuration Manager, administrators can use a single infrastructure and tool set
to both deploy and publish applications. Without XenApp Connector, you could use the Configuration Manager console to
deploy applications to all XenApp servers and then use XenApp to publish the applications to users. XenApp Connector
enables you to handle both of those tasks in the Configuration Manager console.
XenApp Connector extends the Configuration Manager user-centric and rules-based application delivery capabilities to
deliver applications to users in the most appropriate manner (MSI, App-V, or XenApp) for their device. T hat choice is based
on Configuration Manager rules that check whether a device meets prerequisites such as network location or physical
characteristics.
Users of devices managed by Configuration Manager then access XenApp hosted applications from Citrix Receiver and the
Configuration Manager Application Catalog. Policy rules determine whether those managed devices launch either locally
installed applications or Receiver based applications. Users of unmanaged devices, such as mobile devices and Macs, access
applications managed by Configuration Manager from web sites created in Citrix StoreFront or Citrix Web Interface.
Orchestrate software installation to XenApp servers, farms, and worker groups using:
MSI-based applications
Microsoft Application Virtualization (App-V) stream-to-server applications
Applications that are part of the XenApp server disk image in the XenApp farm
Automatically create XenApp published application sequences which are then made available to Receiver users as
XenApp published applications.
Coordinate application installation, operating system updates, and applications updates to XenApp servers managed by
Citrix Provisioning Services.
XenApp Connector fully integrates with Provisioning Services, allowing you to publish applications that are deployed to a
base vDisk for a XenApp image.
XenApp Connector can also use the XenApp Power and Capacity Management Concentrator to manage the power
states and load consolidation of XenApp servers when installing Configuration Manager applications or Windows
Software Update Management (SUM) updates, with minimal disruption to user sessions.
How to Download
Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page.
Viewing and downloading features on the download pages require that you have a Citrix account associated with your
When you configure XenApp Connector, the XenApp Connector Configuration wizard prompts you to specify a
maintenance window for XenApp servers. For production environments, the recommended option is to create a custom
maintenance window.
In addition to considering the optimum maintenance window for your users, be aware that you can specify how users are
notified about maintenance through several group policies. T he policies include how far in advance of maintenance or a
software update that the user is first notified, the interval between subsequent notifications, and the message title and
text. For forced logoff situations, the policies include the grace period between a notification about a forced logoff and
that action, as well as the message title and text.
For a description of all group policies related to XenApp Connector, see Connector for Configuration Manager Policy
Settings.
What's new
XenApp 6.5 Connector (SP2) for Configuration Manager (XenApp Connector) provides the following enhancements:
Support f or System Center 2012 R2 Conf iguration Manager — You can now deploy XenApp Connector in a System
Center 2012 R2 Configuration Manager environment. Click the link below for details about upgrading from XenApp 6.5
Connector or XenApp 6.5 Connector (SP1) to this SP2 release.
Learn More
Support f or StoreFront 2.1 aggregated resources — If your Citrix deployment includes StoreFront 2.1 and is
configured to publish applications from multiple XenApp farms in a single store, Receiver users are presented with an
aggregated list of resources.
Support for the feature is built-in to XenApp 6.5 Connector (SP2) and requires no additional configuration. However,
make sure that each instance of a published application has the same display name in Configuration Manager. Click the
link below for more information about StoreFront resource aggregation.
Learn More
Customer Experience Improvement Program — Would you like to help us improve XenApp Connector based on how
you use it? T he XenApp Connector Configuration wizard now allows you to opt in or out of our Customer Experience
Improvement Program. All data collected is 100% anonymous and you can change your participation choice at any time.
We will use the aggregated data about XenApp Connector installation and usage to plan future enhancements.
Learn More
XenApp 6.5 Connector (SP2) replaces the SP1 release and includes all features from that release:
Assisted set up of a Conf iguration Manager Maintenance Window — T he XenApp Connector Configuration
wizard now makes it easier to choose the optimum maintenance window for proof-of-concept or production
environments:
Follow the on-screen instructions to choose the setting appropriate for your environment.
After first-time use of the Configuration wizard, run it again to view all maintenance windows for the farm.
If you create a custom maintenance window in the Configuration wizard, use the Configuration Manager console for
future changes.
Learn More
Support f or the latest components — T his release of XenApp Connector includes support for XenApp 6.5 Feature
Pack 2 for Windows Server 2012 R2, Receiver for Windows 4.0, and App-V Client for Remote Desktop Services, version
5.0, SP1 and SP2.
Learn More
Simplif ied upgrades — T he installer removes the previous version of XenApp Connector for Configuration Manager
2012. Your existing configuration, except for a maintenance window defined in XenApp Connector, is retained.
Learn More
Known issues
To work around this issue, reinstall the Configuration Manager console extension, delete the XenApp deployment types,
and then uninstall the console extension.
If you use the XenApp PCM feature, refer to Install and set up components for Power and Capacity Management for
related system requirements.
XenApp
Any of the following XenApp releases running on Windows Server 2008 Enterprise R2, 64-bit edition, SP1:
User devices
Important: Device requirements differ for managed and unmanaged devices. A managed device is defined as a device with
the Configuration Manager client agent installed. A managed device must be enabled for software distribution. Managed
devices do not include Windows Workgroup computers because Configuration Manager cannot deploy applications
targeted to user collections on those devices.
An unmanaged device is a device without the Configuration Manager client agent installed.
Authentication requirements
Receiver must be configured for single sign-on, which requires the following configuration of user devices and the
StoreFront server (version 2.1 or 2.0):
T he user must be a domain user (not a local machine user).
T he user device must be on the same Active Directory domain as the Storefront stores.
Pass-through authentication must be configured on the Storefront server.
T he StoreFront server URL must be in the Internet Explorer T rusted Zone.
If the store service uses HT T PS, the certificate and trust chain must be correctly configured for the server being used.
T he XenApp Connector for Configuration Manager 2012 consists of the following components:
T he XenApp Connector publishing task processes publishing items that are linked to a XenApp deployment type. Items
published to a XenApp device collection appear under the Applications\ConfigMgr12 folder in the XenApp AppCenter
console.
By default, the Publishing task runs every hour. Use the XenApp Connector Configuration wizard to change the publishing
interval. Use the Start menu shortcut (Run Publishing Task) to manually run the task.
T he Connector ensures that applications are not published until all the required XenApp workers have the application
successfully installed by Configuration Manager.
High availability
T he XenApp Connector high availability feature provides a reliable fault tolerance mechanism to ensure service continuity
during disruptions in infrastructure components such as software, hardware, network, and power. To take advantage of
this feature, just install and configure the connector service on multiple servers.
Only one instance of the connector service operates regularly while the other service(s) remain idle as backups. If the
active connector service becomes inoperable, another instance is automatically designated as the active one and takes
over the load. Active instance and related information are stored in the Configuration Manager database for persistence
and are retained during a XenApp Connector upgrade.
A Citrix XenApp Farms node under Assets and Compliance > Device Collections. After synchronizing data from a XenApp
farm, XenApp Connector updates the Citrix XenApp Farms node with all XenApp farms, servers, and worker groups.
Device Collections > Citrix XenApp Farms > farms
Device Collections > Citrix XenApp Farms > farms > Worker Groups > groups
Citrix recommends that you do not delete XenApp farm device collections and that you edit them only if you need to
change a custom maintenance window specified in the XenApp Connector Configuration wizard.
A XenApp Publications folder under Software Library > Application Management. Items in this folder are published to
In preparation for this, the XenApp Agent service orchestrates draining the XenApp workers servers and notifying users
before the next maintenance window to ensure that no users are logged in when the software is being installed. Users
are forcibly logged off if the deployment deadline has passed.
T he XenApp deployment type handler detects and manages publications associated with an application configured with a
XenApp deployment type. T he handler works with the Configuration Manager client agent to determine whether an
application needs to be installed on a managed device and whether to launch that managed application or a Receiver
version of the application.
T he PCM Concentrator monitors and manages the XenApp servers in the PCM farm and interacts with the PCM Agent
running on each XenApp server to get and set the PCM tier and PCM control mode.
T he PCM Agent registers host XenApp servers with the PCM Concentrator and acts on requests issued by the PCM
Concentrator.
Citrix Receiver for Windows, Receiver for Web sites, and XenApp Services sites
After a user of a device managed by Configuration Manager subscribes to XenApp deployment type applications using the
Application Catalog, icons for those applications appear in the user's Start menu, on the Receiver for Windows home page
(if Receiver is configured with StoreFront), on Receiver for Web sites, and on Web Interface XenApp Services sites. When
the user clicks the icon for a subscribed application, Receiver launches the application.
For users of unmanaged devices, such as mobile devices and Macs, users access applications deployed to user collections by
navigating in a Web browser to Receiver for Web sites or Web Interface XenApp Services sites. T hose sites display
applications managed by Configuration Manager, including applications deployed with the XenApp deployment type.
Proof of concept
A proof of concept deployment includes only one XenApp Connector service machine, configured to point to one XenApp
host. Accepting the defaults during installation results in a proof of concept deployment.
1. A Configuration Manager site manages the servers of a XenApp farm and other devices.
T he Configuration Manager client is required on all workers in the farm.
2. T he XenApp Connector service communicates with the Configuration Manager SMS Provider.
3. T he XenApp Connector service communicates with a XenApp host, which must be a Controller and not a worker
machine.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, the XenApp Connector service communicates with the PCM Concentrator.
5. If you use PCM, the PCM Concentrator communicates with the XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
High availability
A high availability deployment includes multiple XenApp Connector service machines. If a XenApp Connector service stops
working for any reason, such as an infrastructure disruption, another XenApp Connector service automatically takes its
place. Only one instance of the XenApp Connector service operates regularly. T he others remain idle as backups.
Adding XenApp Connector service machines does not increase capacity, so a high availability deployment is recommended
regardless of the size of your operation.
2. Any number of XenApp Connector services can point to the Configuration Manager SMS Provider.
Different XenApp Connector services can point to different SMS Providers per Configuration Manager Site to
improve fault tolerance by avoiding a single point of failure on the Configuration Manager side.
T he Configuration Manager Site database is also used to store the High Availability table, which contains information
about which XenApp Connector service is currently the active one for a given farm.
3. XenApp Connector services communicate with one or more XenApp hosts, which must be Controllers and not worker
machines.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, the XenApp Connector services communicate with the PCM Concentrator.
T he XenApp Connector service supports operating against a single PCM Concentrator per PCM site.
5. If you use PCM, the PCM Concentrator communicates with the XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
T he simplest way to use XenApp Connector to manage multiple XenApp farms is to set up one or more XenApp Connector
service machines for each XenApp farm.
Configure each XenApp Connector service independently as if the XenApp farm it points to is the only farm in the
enterprise. XenApp Connector automatically handles the existence of the other farms and operates without conflict.
2. Any number of XenApp Connector services can point to the Configuration Manager SMS Provider.
Different XenApp Connector services can point to different SMS Providers per Configuration Manager Site to
improve fault tolerance by avoiding a single point of failure on the Configuration Manager side.
T he Configuration Manager Site database is also used to store the High Availability table, which contains information
about which XenApp Connector service is currently the active one for a given farm.
3. XenApp Connector services communicate with the XenApp hosts, which must be Controllers and not worker machines.
T his communication is handled using the XenApp Commands SDK (Citrix.XenApp.Commands).
4. If you use PCM, set up a dedicated PCM Site per XenApp farm.
T he XenApp Connector service supports operating against a single PCM Concentrator per PCM site.
5. If you use PCM, each PCM Concentrator communicates with a XenApp farm as a whole by interacting with the PCM
Agent installed on each individual XenApp worker machine.
T he following diagram shows a typical deployment of XenApp Connector service machines in a large multi-geography site
hierarchy that uses a Configuration Manager Central Administration Site (CAS) with three Primary Sites (Americas, Europe,
and Asia).
When planning the deployment of the XenApp Connector within a given Configuration Manager topology:
In this deployment, install the XenApp Connector console extension and service as follows:
On machines, such as the CAS server, where the Configuration Manager console is installed and used to manage the
hierarchy, install only the XenApp Connector console extension (and not the XenApp Connector service).
On machines where you install the XenApp Connector service, there is no need to install the XenApp Connector console
extension.
Secondary sites, not shown in the diagram, are managed by their parent Primary Site and therefore by the XenApp
Connector service(s) on or pointing to their respective Primary Site. Do not install XenApp Connector on Secondary Site
machines, as it would serve no purpose.
1. Use Configuration Manager 2012 to deploy an MSI or App-V application to a XenApp farm collection.
2. Use the Publish Application wizard in Citrix AppCenter to publish the application to users.
3. Use Receiver for Windows to subscribe to and then launch the application.
If those steps are successful, your environment is ready for XenApp Connector.
Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page. T he package name is
XA6.5_Connector_SP2_for_SCCM2012.exe.
Viewing and downloading features on the download pages require that you have a Citrix account associated with your
license entitlement for XenApp 6.5. You only see those features to which you are entitled according to your license.
Features are made available to you on the download page depending on the edition level of your entitlement: Platinum,
Enterprise, or Advanced. If you do not have a Citrix account that is associated with the license entitlement for XenApp 6.5,
Citrix Customer Support can assist you.
T his setup applies only to managed devices that connect to published applications by using Receiver for Windows. A
managed device is one with the Configuration Manager client agent installed.
Prerequisites
Citrix Receiver for Windows
If Citrix Receiver for Windows is not deployed at your site, obtain the installer from the Citrix downloads site.
For a list of supported Receivers and their authentication requirements, refer to User devices.
Configure Receiver to use pass-through authentication on user devices. (Pass-through authentication is also referred
to as single sign-on authentication.)
For information, refer to the /includeSSON command-line parameter description in the Receiver for Windows
documentation in Citrix eDocs.
Install Receiver per-machine and in the all users mode on all machines.
Important: After you have tested a proof-of-concept installation, Citrix recommends that you use Configuration Manager
Install the following components on XenApp servers, in the order listed. For supported platforms, refer to System
requirements.
Important: After you have tested a proof-of-concept installation, Citrix recommends that you use Configuration
Manager to deploy these components to other XenApp servers. For information about deploying MSI applications, refer
to Deploy MSI and App-V applications to XenApp servers.
To verify installation, search for the component in Programs and Features.
2. Group Policy hotf ix. On the XenApp server where the Group Policy Management Console is installed, install XenApp
Server Components/XenApp Group Policy Settings.../CitrixGroupPolicyManagement_x64[86].msi.
To verify installation, search for the Connector for Configuration Manager section in the Group Policy Management
Console.
Important: You must delete the XenApp deployment type before uninstalling XenApp Connector from the Configuration
Manager console. For more information, see Known issues.
To uninstall Citrix XenApp Connector components, use the Windows Programs and Features (or Add/Remove Programs)
utility. T he Uninstall Options dialog box enables you to choose which components to uninstall:
I am upgrading or plan to re-install. T his option removes the Program Files > Citrix > XenApp Connector for ConfigMgr
2012 folder and the following components from the Configuration Manager console:
T he XenApp deployment type option as well as Citrix XenApp from the table in the Applications > Deployment T ypes
tab
Application Management > XenApp Publications
I want to uninstall permanently. T he items mentioned above plus the components listed in the Cleanup to perform area.
Let me make selections manually. T his option enables you to choose the components to remove.
Log files and items in the Configuration Manager database are not removed.
To see the results of the uninstall, start the Configuration Manager console.
Prerequisites
Before you install XenApp Connector, prepare your environment as follows. For supported platforms, refer to System
requirements.
1. Identify the computers in your XenApp Connector installation:
1. Decide where to install the XenApp Connector service. T he component is not supported on servers where XenApp is
installed. You can install it on its own dedicated VM or on the Configuration Manager Site Server.
For environments with multiple XenApp farms, install XenApp Connector on a dedicated VM in each farm and point it
to a controller in the farm. You can then configure each XenApp Connector with the same SMS Provider.
Install the XenApp PowerShell host on the same server as the XenApp Connector service. T he XenApp Connector
service uses the XenApp PowerShell SDK to manage XenApp servers and gather farm data. Ensure this computer is
not managed by Power and Capacity Management.
2. Identify where to install the Configuration Manager console extension. You must install it on a server or workstation
that has the Microsoft System Center 2012 Configuration Manager console installed. You can install the console
extension on the same server as the XenApp Connector service.
2. Enable the XenApp Connector service to communicate with the XenApp PowerShell host and the SMS Provider for the
Configuration Manager site:
1. Determine which port to use as the remote PowerShell port and whether to use an SSL connection.
2. Open the port on the firewalls or routers used by these servers.
3. In the policies of the computer on which you will install the XenApp Connector service, ensure that the Do not allow
storage of passwords and credentials for network authentication option is disabled.
4. Create the XenApp service account (the account that will run the XenApp Connector service) and configure it as follows:
Citrix Full Administrator
Application Administrator on the Configuration Manager 2012 site
Local Administrator on each of the following:
XenApp PowerShell host
SMS Provider for the Configuration Manager 2012 site
In the XenApp farm Administrators node
For information about using AppCenter to add an administrator, refer to "Managing Citrix Administrators" in the
XenApp documentation.
Has "Log on as a service" rights on the computer on which the XenApp Data Connector is installed
Has rights to log on as batch job on the computer on which the XenApp Connector service will be installed.
5. Determine the security role to use for the XenApp Connector administrative user. You can use the Configuration
Manager built-in roles of Full Administrator or Application Administrator, or you can configure a security role in
Configuration Manager with the following permissions:
Application (all permissions)
Client Agent Setting (all permissions)
Configuration Item (all permissions)
Distribution Point (all permissions)
For a small proof-of-concept deployment you can install the XenApp Connector service and the XenApp Connector console
extension on the same Configuration Manager host. To install the console extension on a different server, see "Install the
XenApp Connector console extension on a different server" in this topic.
1. On the server on which you want to install the XenApp Connector service, if Configuration Manager is installed, close it.
2. Run the XenApp Connector installer: XA6.5_Connector_SP2_for_SCCM2012.exe.
3. Follow the instructions in the installation wizard.
If the Configuration Manager server where you are installing the XenApp Connector service has the Configuration
Manager console installed, the Configuration Manager Console Extension check box is selected by default. T o install
the console extension on a different Configuration Manager server, clear the check box.
If Launch Configuration when Setup exits is selected on the last screen of the installation wizard, the Configuration
wizard starts when the installation is complete.
If you choose not to run the Configuration wizard now, you can do so later by using the Config Wizard shortcut on
the Start menu or desktop.
Installing the XenApp Connector registers the XenApp deployment type with Configuration Manager 2012, creates the
client agent setting required for idle policy configuration, and installs and starts the XenApp Connector Configuration
wizard.
By default, the console extension installs on the same server as the XenApp Connector service if the server also has the
Configuration Manager console installed. You can install it on different servers or workstations that have the Microsoft
System Center 2012 Configuration Manager console installed.
T he XenApp Connector Configuration wizard opens after you install the XenApp Connector service. To open the
Configuration wizard at any time, use the Config Wizard shortcut on the Start menu or desktop.
You will need the following information to configure the XenApp Connector service:
Credentials for the XenApp Connector service account used to run XenApp Connector service.
T he fully-qualified domain name (FQDN) for the XenApp Controller. T he FQDN must include all three levels
(hostname.subdomain.domain).
Whether to create a maintenance window for the XenApp servers and, if so, the desired start time, end time, and
Use the on-screen instructions in the Configuration wizard for guidance as you follow these steps.
1. On the Configuration Manager Site page, specify the site information and then click Next.
2. On the Software Installation Maintenance Window page, select a maintenance window option.
Note: T he following options appear the first-time you run the Configuration wizard. After that, if there is at least one
maintenance window defined, this page displays (for the farm) all maintenance windows created by this Configuration
wizard and the Configuration Manager console.
Create a 24 x7... — T his option is not recommended for production environments: Software deployment starts
immediately, which can instantly cause down time for users.
Create a custom... — T his option is recommended for production environments. T o change the deployment schedule
later, use the Configuration Manager console.
I will create my own... — If you choose this option, be aware that software deployment starts immediately unless a
deployment schedule is already specified in the Configuration Manager console.
3. Complete the remaining Configuration wizard pages. When prompted, choose whether to participate in our Customer
Experience Improvement Program.
4. Review the information on the Settings Summary page.
5. T o edit the following settings, click Advanced Settings.
XenApp farm sync interval – how often the XenApp Connector updates the Configuration Manager database with
new, changed, or removed XenApp farm servers and worker groups
XenApp publication interval – how often the XenApp Connector checks the Configuration Manager database for
new or updated publication information
XenApp power-on interval – how long in advance off-line servers are powered on to receive software updates
Pre-requisites
Open the ports on the firewalls or routers used by the servers running the XenApp Connector service and PCM.
On the server running the PCM Concentrator, make the XenApp service account a Local Administrator.
1. Citrix recommends that you document your current PCM server configuration before enabling XenApp Connector to
modify it.
2. Install PowerShell and enable PowerShell remoting on the servers you plan to use for the following:
XenApp Connector service
SMS Provider for the Configuration Manager site
Power and Capacity Management Concentrator
To enable PowerShell remoting:
Important: We recommend that you upgrade the XenApp Connector components before you upgrade to System Center
2012 R2 Configuration Manager.
T his upgrade uninstalls the previous version, installs XenApp 6.5 Connector (SP2), and then runs the Configuration wizard.
We recommend that you perform these steps in the order presented to ensure a successful upgrade.
1. Download XenApp 6.5 Connector (SP2) from the XenApp Connector download page and extract the files.
2. If Configuration Manager is installed on the server on which you want to install the XenApp Connector service, close the
service.
3. On all XenApp servers hosting published applications:
1. Install the XenApp Agent service: XenApp Server Components/XenAppAgent_x64.msi.
2. Install the XenApp deployment type handler: XenApp Server Components/XenAppDT Handler_x64.msi.
If you are using XenApp Connector to deploy XenApp applications only to users running PVS-based shared images, install
those two components on the PVS master vDisk image instead.
4. Run the XenApp 6.5 Connector (SP2) installer: XA6.5_Connector_SP2_for_SCCM2012.exe.
5. Follow the instructions in the installation wizard.
If the Configuration Manager server where you are installing the XenApp Connector service has the Configuration
Manager console installed, the Configuration Manager Console Extension check box is selected by default. T o install
the console extension on a different Configuration Manager server, clear the check box.
If Launch Configuration when Setup exits is selected on the last screen of the installation wizard, the Configuration
wizard starts when the installation is complete.
If you choose not to run the Configuration wizard now, you can do so later by using the Config Wizard shortcut on
the Start menu or desktop.
T he Receiver installer is available from the Citrix downloads site. Be sure to:
Configure Receiver to use pass-through authentication on user devices. For information, refer to information about
the /includeSSON command-line parameter in the Receiver for Windows documentation in Citrix eDocs.
Install Receiver per-machine and in the all users mode on all machines.
To verify that your upgraded environment is working correctly, perform the following steps after you upgrade XenApp
Connector components and again after you upgrade to System Center 2012 R2 Configuration Manager.
If your deployment includes PVS vDisk images or SUM updates, you will follow a different set of steps. For information
about deploying applications and software updates, refer to the following sections:
Important: T he procedures in this section highlight XenApp-specific settings. For detailed information about using the
Configuration Manager console, refer to the Microsoft Documentation Library for System Center 2012 Configuration
Manager.
App-V stream-to-server applications are not physically installed by this procedure. T he XenApp Agent service running on the
XenApp server detects the pending application deployment and interacts with Configuration Manager to deploy the virtual
application by creating a shortcut for it and registering the App-V package on the system.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
5. On the Scheduling page, use the default (as soon as possible) for a proof-of-concept deployment or for XenApp
Controller components. Otherwise, specify a schedule.
6. Follow the on-screen instructions to complete the wizard.
3. Force the application to install on the XenApp farm.
At this point, the application you created has the deployment type that specifies how to install the application. You will
later add to the application a XenApp deployment type, used to publish the application to devices. You must configure
the application so that the deployment type that installs the application is used to deploy it to XenApp servers.
1. In the Deployment T ypes tab, right-click the application you added in Step 1 and choose Properties.
2. In the Properties window, on the Requirements tab, click Add.
3. In the Create Requirement dialog box: From Category, choose Custom.
4. From Condition, choose Citrix XenApp Server Version.
5. From the Rule type drop-down menu, choose Existential.
6. Keep the default setting T he selected global condition must exist on client devices. T hat setting indicates that the
device must be a XenApp server.
1. Create the application and define the Script Installer deployment type:
1. In the Configuration Manager console, expand Software Library> Application Management and then click
Applications.
2. On the Home tab, click Create Application. T he Create Application Wizard opens.
3. On the General page, click Manually specify the application information and then click Next.
4. Specify a Name. You will need to enter this same name in the next step. Also specify any other information you
require on the General Information and the Application Catalog pages.
5. On the Deployment T ypes page, click Add and then create the Script Installer deployment type with these settings:
Set T ype to Script Installer, click Next, and enter the same Name you entered in step d.
On the Content page, leave the Content location blank.
On the Content page, in Installation program, enter a non-existing filename, such as dummy.exe.
T he application is already installed, so this method prevents an installation.
On the Detection Method page, click Add Clause and then locate the file for the already installed application.
On the User Experience page, set Installation behavior to Install for system and set Logon requirement to Whether
or not a user is logged on.
2. T o deploy the application to a XenApp device collection:
1. In the Applications list, click the application name and then click Home > Deploy.
2. On the General page, across from Collection, click Browse, choose Device Collections, and then select a XenApp
server.
3. On the Deployment Settings page, from the Purpose list, choose Required so that the application will be pushed as a
mandatory deployment.
4. On the Scheduling page, a proof-of-concept deployment would typically use the default (as soon as possible).
Otherwise, specify a schedule.
5. Follow the on-screen instructions to complete the wizard.
3. Force the application to install on the XenApp farm.
At this point, the application you created has the deployment type that specifies how to install the application. You will
later add to the application a XenApp deployment type, used to publish the application to devices. You must configure
the application so that the deployment type that installs the application is used to deploy it to XenApp servers.
1. In the Deployment T ypes tab, right-click the application you added in Step 1 and choose Properties.
2. In the Properties window, on the Requirements tab, click Add.
3. In the Create Requirement dialog box: From Category, choose Custom.
4. From Condition, choose Citrix XenApp Server Version.
5. From the Rule type drop-down menu, choose Existential.
6. Keep the default setting T he selected global condition must exist on client devices. T hat setting indicates that the
device must be a XenApp server.
7. Click OK twice.
4. T o verify in Configuration Manager that the application installed on the XenApp server, go to Monitoring > Deployments.
5. After you have completed those deployment steps for all XenApp servers that publish the application, publish the
For information about Provisioning Services, refer to “Automating vDisk Updates” in the Provisioning Services
documentation in Citrix eDocs.
1. Prepare a PVS master vDisk image as described in Enable integration with Citrix Provisioning Server.
2. If the application is not already created in Configuration Manager, add it as described in Deploy MSI and App-V
applications to XenApp servers.
3. Create a XenApp deployment type for the application:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard.
T he XenApp deployment type you added appears in the Deployment Types tab.
4. Deploy the applications to a XenApp device collection that includes only the master vDisk image. Updates and
applications will be published to the VM in that collection and will automatically be applied to any new or existing clones
of the PVS vDisk. T he master vDisk image will update according to the schedule configured in the vDisk Update
Management settings.
1. In the Applications list, click the application name and then click Home > Deploy.
2. On the General page, across from Collection, click Browse, choose Device Collections, and then select a XenApp
server.
3. On the Content page, click Add, choose Distribution Point, and select a distribution point.
4. On the Deployment Settings page, from the Purpose list, choose Required so that the application will be pushed as a
mandatory deployment.
5. On the Scheduling page, a proof-of-concept deployment would typically use the default (as soon as possible).
Otherwise, specify a schedule.
6. Follow the on-screen instructions to complete the wizard.
5. After the master vDisk image updates, promote the new master vDisk image, as described in “Promoting Updated
Versions” in the Provisioning Services documentation in Citrix eDocs. T he XenApp servers are updated with the new vDisk
image.
1. If you use PCM, ensure that XenApp Connector is enabled to use PCM on the XenApp servers to receive SUM updates.
See Install and set up components for Power and Capacity Management for details.
T he optional XenApp PCM feature coordinates the power states and load consolidation of the XenApp servers, enabling
XenApp Connector to deploy SUM updates with minimal disruption of user sessions.
2. If you have not already done so, use the XenApp Connector Configuration wizard to configure a maintenance window
for the XenApp servers.
3. Use the Configuration Manager console to deploy one or more SUM updates to servers in the XenApp farm collection.
T he deadline you set for this software update installation is used only if the Connector agent service fails to install the
update before that time.
XenApp Connector can use PCM to drain users from the XenApp servers you targeted to receive a SUM update. At
specified times within the maintenance window, the Connector agent service runs on every targeted XenApp server and
installs the SUM update on XenApp servers that have no user sessions. If the SUM update has not been installed on all
targeted XenApp servers when the software update installation deadline is reached, the Connector agent service forces
the installation on any server that does not yet have the update installed and then restarts the server, even if there are
active user sessions.
To allow PCM to manage power states and load consolidation of XenApp servers, the XenApp Connector changes the
servers' power controller preference and power control mode:
If no deployments are pending for a XenApp server, the server's power controller preference remains at 1st choice, which
is the default ranking for servers managed by Power and Capacity Management.
When you designate an online XenApp server to receive a deployment, XenApp Connector performs the following
operations:
T akes control of the server's power controller preference and changes it to 5th choice.
After the user sessions have completely drained or (after a configurable amount of time) been logged off, triggers the
software install for the pending deployment.
Just before the application is installed, sets the server state to Maintenance.
After the deployment processing completes, changes the server's power controller preference to 1st choice,
relinquishes control of the server's power controller preference, restarts the machine (if needed), and enables the user
to log on.
When you designate an offline XenApp server to receive a deployment, XenApp Connector performs the following
operations:
T akes control of the server's power controller preference and changes it to 6th choice.
Sets the server state to Maintenance and the server control mode to Unmanaged for the duration of the
maintenance window or the processing of all pending deployments, whichever occurs first.
Powers on the server. T he XenApp power-on interval configured in the XenApp Connector Configuration wizard
Note: While a XenApp server's power controller preference is controlled by XenApp Connector, attempting to change the
server's power controller preference using the PCM console results in a warning that doing so might cause undesirable
effects.
Whether you are publishing MSI, App-V, or XenApp applications to devices, you perform the following sequence of steps in
the Configuration Manager console:
1. Add the XenApp deployment type to the application and add a publishing item to the XenApp deployment type.
For each publishing item linked to a XenApp deployment type, the XenApp Connector publishing task creates a XenApp
published application. You can reuse publishing items.
Receivers on non-Windows devices ignore any Configuration Manager-specific settings and manage the applications as
usual.
On devices managed by Configuration Manager (managed devices), you must Configure integration with managed
devices to enable an application to be accessed from Receiver.
Important: T he procedures in this section highlight XenApp-specific settings. For detailed information about using the
Configuration Manager console, refer to the Microsoft Documentation Library for System Center 2012 Configuration
Manager.
Before publishing an application to devices, you must deploy the application to XenApp servers that publish the application.
For more information, refer to topics under Deploy applications and software updates to XenApp servers.
Unless otherwise indicated, XenApp Connector does not require changes to the default settings.
1. Add the XenApp deployment type to the application and define a new publishing item:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard. Settings for XenApp deployment types:
Click through the General, T ype, and Location pages to accept the defaults.
If you are using the legacy XenApp ICA client and want to specify a folder location in the Start menu for the
application, on the Presentation page enter the Client application folder.
Click through the remaining pages and make changes as needed for your environment.
T he XenApp deployment type you added appears in the Deployment Types tab.
Note: If you later need to delete a publishing item, use the Configuration Manager console so that both the
Configuration Manager database and the XenApp farm are updated. Using Citrix AppCenter to delete a publishing item
from a XenApp farm does not update the Configuration Manager database.
XenApp administrators might notice that the description field of the published application in AppCenter now has an
additional keyword, ConfigMgr. T hat keyword indicates that the application is available for installation by the XenApp
deployment type handler. Do not remove the keyword.
3. T o verify the deployment, go to Monitoring > Deployments to view the deployment status and then open Receiver on a
target device to subscribe to (if needed) and open the application.
1. Add the XenApp deployment type to the application and define a new App-V type publishing item:
1. In the Applications list, click the application name and then click Home > Create Deployment T ype. T he Create
Deployment T ype Wizard opens.
2. On the General page, from the T ype list, choose Citrix XenApp 6.5 and then click Next.
3. On the General information page, click Next.
4. On the Publishing page, add publishing items to the deployment type. T o create a publishing item for a XenApp
deployment type, click New and complete the XenApp Publishing Wizard. Settings for XenApp deployment types:
Click through the General page.
On the T ype page, click App-V virtual application.
On the Location page, choose the App-V package and the Application in that package to be published.
If you are using the legacy XenApp ICA client and want to specify a folder location in the Start menu for the
application, on the Presentation page enter the Client application folder.
Click through the remaining pages and make changes as needed for your environment.
T he XenApp deployment type you added appears in the Deployment Types tab.
5. T o allow users of the Configuration Manager Software Center to access the XenApp-published application as if it
were locally installed, increase the priority of the XenApp deployment type to 1: In the Deployment T ypes tab, right-
click the XenApp deployment type and choose Increase Priority. Repeat as needed until its priority is 1.
Note: If you later need to delete a publishing item, use the Configuration Manager console so that both the
Configuration Manager database and the XenApp farm are updated. Using Citrix AppCenter to delete a publishing item
from a XenApp farm does not update the Configuration Manager database.
XenApp administrators might notice that the description field of the published application in AppCenter now has an
additional keyword, ConfigMgr. T hat keyword indicates that the application is available for installation by the XenApp
deployment type handler. Do not remove the keyword.
3. T o verify the deployment, go to Monitoring > Deployments to view the deployment status and then open the Receiver
on a target device to subscribe to (if needed) and open the application.
Not e: For detailed guidance on integrating App-V with XenApp 6.5, see this overview.
T he following procedure describes the required configuration that provides access to applications from Receiver on
managed devices. Following the steps is a description of how the configuration impacts application installation,
uninstallation, and access for both Receiver and Software Center.
T his section also describes other optional configuration, such as changing application shortcut locations.
On managed devices, XenApp-hosted applications published by Configuration Manager are targeted to Software Center.
To also provide access to those applications from Receiver for Windows, you must make Receiver a dependency for the
XenApp deployment type.
1. If Receiver for Windows is not already added to Configuration Manager, add it.
1. In the Configuration Manager console, expand Software Library> Application Management and then click
Applications.
2. On the Home tab, click Create Application.
3. On the General page, click Manually specify the application information and then click Next.
4. Specify a Name. You will need to enter this same name in the next step.
5. On the Deployment T ypes page, click Add and then create the Script Installer deployment type with these settings:
Set T ype to Script Installer, click Next, and enter the same Name you entered in step d.
On the Content page, next to Content location, click Browse, navigate to the folder that contains
CitrixReceiver.exe, and click Select Folder.
Also on the Content page: Next to Installation program, click Browse, select CitrixReceiver.exe, and then click Open.
After "CitrixReceiver.exe" add these two required parameters: /silent /includeSSON.
If your Receiver for Windows deployment plan requires other command-line options, include them too.
On the Detection Method page, click Add Clause, change T ype to Folder, for Path enter
%ProgramFiles(x86)%\Citrix, and for File or folder name enter ICA Client.
On the User Experience page, set Installation behavior to Install for system if resource is device; otherwise install
for user and set Logon requirement to Whether or not a user is logged on. Click through the remaining pages.
2. In the Configuration Manager Applications list, select an application and then click the Deployment T ypes tab.
3. Right-click the XenApp deployment type and choose Properties.
4. Click the Dependencies tab and then click Add.
5. Specify a Dependency group name and then click Add.
6. In the Specify Required Application dialog box, select Receiver in the Available applications list and again in the
Deployment types list.
XenApp hosted applications installed by Configuration Manager appear to a Receiver for Windows user like any other
application, are available for subscription, and appear in the Windows Start menu after the user subscribes to an available
Users can access applications deployed to user or device collections from the Application Catalog. T hese applications
include those deployed with the XenApp deployment type. Applications installed from the Application Catalog appear in
the Windows Start menu.
After Configuration Manager installs an application, Receiver cannot remove the application from that computer. T hus, if
the user attempts to uninstall the application from the Software Center, the application remains installed on the
computer.
By default, applications appear under Start > All Programs. You can specify the relative path under the Programs folder to
contain the shortcuts to subscribed applications. To do that, specify START MENUDIR=Text string on the Receiver for
Windows command-line. For example, to place shortcuts under Start > All Programs > Receiver, specify
START MENUDIR=\Receiver\. Users can change the folder name or move the folder at any time.
You can also control this feature through a registry key. For information, refer to "Configure and install Receiver for
Windows using command-line parameters" in the latest Receiver for Windows documentation in Citrix eDocs.
Applications installed from the Configuration Manager Application Catalog are reported by the XenApp deployment type
handler as installed.
Applications subscribed to by a Receiver user (and thus installed on the local computer) are reported by the XenApp
deployment type handler, by default, as installed in the Application Catalog even if the application was not installed by
Configuration Manager. With this behavior, an administrator can determine from Configuration Manager reporting that the
computer is out of compliance. T his default is controlled on a Windows computer by the registry key
ReportSubscribedAppsAsConfigMgrInstalled.
In case of an application that is installed by Receiver but not by Configuration Manager, that registry key affects
installation and uninstallation as follows:
If ReportSubscribedAppsAsConfigMgrInstalled is T rue and the user tries to uninstall the application from the Application
Catalog, the Application Catalog reports to the user that the uninstallation attempt failed. T he user must unsubscribe
the application from Receiver or use Windows Add/Remove Programs to uninstall it.
If ReportSubscribedAppsAsConfigMgrInstalled is False and the user installs the application from the Application Catalog,
HKLM\SOFT WARE\Citrix\Dazzle
HKCU\SOFT WARE[\Wow6432Node]\Citrix\Dazzle
Note: Applications delivered from older clients that support legacy Web Interface XenApp Services sites are not included in
Configuration Manager reporting.
In an environment that includes mandatory deployments to a user collection, a user in that collection can experience about
a 90-second delay (for about 20 applications) during each log on while XenApp deployment type based apps deploy to the
user’s desktop.
A best practice to reduce this overhead is to use roaming profiles for the user collection experiencing delays. Although a
first-time user will experience the delay, applications will be available almost immediately for subsequent logons.
1. Specify the share location to store a user’s roaming profile: You need elevated domain privileges to perform this task.
1. From within Active Directory Users and Computers, search for the user account and open RoamingUser Properties.
2. Select the Profile tab and specify the location of the share where the user’s roaming profile is to be stored: In Profile
path, enter \\ServerName\ShareName\UserID. T he users must have read/write access to this share. T he user’s
account profile will be stored in a folder contained in the share you specified.
2. Configure Citrix Receiver to also use this network share to store its information so that it will be available from any
machine the user logs into:
1. In the Windows Registry Editor, browse to HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\Dazzle.
2. If the entry Local does not exist, create it: Right-click Dazzle, select New > String Value, enter a Value name of Local,
and enter the Value data %APPDAT A%\Citrix\selfservice\local.
3. Restart Citrix Receiver and log on the user.
XenApp Connector extends the tracing capabilities provided by Configuration Manager by using standard .NET listeners and
registering a CDF module. You can use CDFMonitor, the Configuration Manager log viewer tool CMTrace, or other third-
party tools to view trace information.
Log files use the naming convention ComponentName.CreationT imeStamp.log. For example, log files for the component
Citrix.ConfigMgr.PublishingT ask.exe are named Citrix.ConfigMgr.PublishingT ask.CreationT imeStamp.log.
CDF modules use the naming convention ConfigMgr_ModuleName.
For detailed information about CDFMonitor, refer to CDFMonitor.
Locat ion in % P rogramF iles% \Cit rix\XenApp Connect or f or Conf igMgr 2012\
Config Wizard\Logs
Connector Service\Logs
Citrix.ConfigMgr.HighAvailabilityMonitor
Citrix.ConfigMgr.SynchronizationT ask Verify sync tasks after adding or removing devices or users.
XenApp Agent\Logs
XenApp DT Handler\Logs
T he following table lists the Configuration Manager client and server logs.
AppEnforce Verify that, if AppDiscovery indicates an application did not install, this log starts with
the installation routine.
SMSAdminUI View information about the operation of the Configuration Manager console.
Citrix.ConfigMgr.XenAppDT
Configuration files enable you to specify logging features such as maximum file size and number of files to retain. T he
.config file for each component uses the naming convention ComponentName.exe.config.
Configuration files are under the installation folder (%ProgramFiles%\Citrix\XenApp Connector for ConfigMgr 2012), as
follows:
On the server where the XenApp Connector service is installed:
install\Config Wizard
install\Connector Service
install\XenApp DT Handler
XenApp Connector uses the Power and Capacity Management Concentrator to coordinate the power states and load
consolidation of farm servers when sending Configuration Manager advertisements and installing applications and Windows
updates.
XenApp Data Connector is the bridge between the XenApp farm and Configuration Manager. It manages XenApp server
collections and worker groups in Configuration Manager and gathers configuration data defined in the Configuration
Manager console to configure XenApp servers. XenApp Data Connector manages XenApp servers and gathers farm data
using the XenApp PowerShell SDK.
Configuration Manager Console Extension extends the Configuration Manager console to provide a graphical user
interface enabling you to deploy applications to XenApp servers and publish XenApp hosted applications. Install
Configuration Manager Console Extension on the same server as the Configuration Manager console.
XenApp Connector for Configuration Manager 2007 supports XenApp 6.5 for Windows Server 2008 R2.
T he XenApp Connector components, XenApp Data Connector and Configuration Manager Console Extension, can be
installed on a single server or on different servers within a single farm.
T he XenApp Connector requires less than 1 MB of disk space to install and creates only log files that can be automatically
purged. T he hardware requirement of the XenApp Connector components are identical to those of their supported
operating systems.
T he XenApp Connector components, XenApp Data Connector and Configuration Manager Console Extension, can be
installed on a single server or on different servers within a single farm.
T he XenApp Connector requires less than 1 MB of disk space to install and creates only log files that can be automatically
purged. T he hardware requirement of the XenApp Connector components are identical to those of their supported
operating systems.
T o enable XenApp Data Connector to communicate with the XenApp PowerShell host, the server running the Power
and Capacity Management Concentrator, and the SMS Provider for the Configuration Manager site:
Determine which port to use as the remote PowerShell port and decide whether to use an SSL connection.
Open the port on the firewalls or routers used by these servers.
In the policies of the computer on which you install the XenApp Data Connector, ensure that the Do not allow storage
of passwords and credentials for network authentication option is disabled.
Create or designate the account used to run the XenApp Data Connector, with these attributes:
Citrix full administrator
Local administrator on each of the following:
XenApp PowerShell host
Server running the Power and Capacity Management Concentrator
SMS Provider for the Configuration Manager site
Rights to log on as batch job on the computer on which the XenApp Data Connector will be installed
Appears on the Security tab of Configuration Manager site's properties dialog box. (T his dialog box is viewed and
edited through the Configuration Manager console.)
After installing and configuring the Configuration Manager Console Extension, you add this account to the Security tab
of Citrix XenApp Farm collection's properties dialog box. T he XenApp Connector configuration wizard creates Citrix
XenApp Farm collection.
1. On the server on which you want to install XenApp Connector, if Configuration Manager is running, close it.
2. Locate XAConfigMgr07.exe on the XenApp installation media and run it on the server on which you want to install
XenApp Connector.
Uninstall the components of XenApp Connector for Configuration Manager 2007 by using Control Panel.
When XenApp Data Connector is uninstalled, all files and folders created when it installed on the server are removed.
When the Configuration Manager Console Extension is uninstalled, these items are removed from the Configuration
Manager console:
Refresh the Configuration Manager console to see the results of the uninstall.
When you uninstall XenApp Connector, some items are not removed:
Note: While a XenApp server's power controller preference is controlled by XenApp Connector, attempting to change the
server's power controller preference using Power and Capacity Management console results in a warning saying that
changing the servers power controller preference with the console might cause undesirable effects.
XenApp Connector uses Power and Capacity Management to manage the installation of installed XenApp applications and
WSUS updates; it does not affect the deployment of Microsoft Application Virtualization (App-V) sequences.
Citrix recommends you document your current XenApp Power and Capacity Management server configuration before
modifying it for XenApp Connector.
T o enable XenApp Connector to use Power and Capacity Management to manage XenApp server power states and load
consolidation, from the Power and Capacity Management console, configure these settings for the XenApp server:
Set power control mode to Managed.
Set power control preference to 1st choice, 5th choice, or 6th choice.
T o deploy an installed XenApp application to XenApp servers, use Configuration Manager to create a software distribution
package and program for the application. Advertise this package and program to deploy the application:
If the application can be installed without restarting the server
For applications that require restarting the server, if you plan to place all servers in the farm into maintenance at the
same time to install the application
Otherwise, after creating the software distribution package and program, create and advertise a program for XenApp for
the application. T his program for XenApp enables you to deploy the application in a way that manages XenApp user
connections so that the application is installed without disrupting user sessions.
For Configuration Manager to manage a XenApp server, send it advertisements, and include it in publications, its information
must be included in the Configuration Manager database.
1. In the Configuration Manager console, expand the software distribution container for the application you want to
deploy.
2. Within the Programs folder, right-click Programs for XenApp and select New > New program for XenApp.
3. Enter the name, installer program, and any comments for the program for XenApp, and click OK.
T his creates a program for XenApp for the application you want to deploy. You can automatically access the publication
wizard now or configure the publication of the application later. Automatically accessing the publication wizard from the
program wizard specifies the package associated with the program as the target of the application being published.
Publishing an applications from the Configuration Manager console is similar to publishing application from the Citrix
AppCenter console, but instead of publishing to servers, you publish to a collection or package. T he application publishing
wizard that XenApp Connector provides within the Configuration Manager console enables you to specify the published
application's type and how it appears to users, which users can access it, and its publication schedule.
You can use the application publishing wizard to configure an application for publication before or after creating an
advertisement for the program that deploys with the application.
1. If the application publishing wizard is not already running, start it from the Configuration Manager console by right-
clicking the XenApp Publications folder and selecting New > XenApp application publishing.
2. T o publish the application, follow the instructions in the wizard. When publishing an application you indicate the
following:
After creating a program for XenApp, advertise it to those XenApp servers on which you want to deploy it.
1. In the Configuration Manager console, expand the software distribution container for the application you want to
deploy.
2. Within the Programs folder, right-click Program for XenApp for the program you want to advertise and select Advertise.
3. Select the collection of XenApp servers or worker groups on which you want to install the application.
4. T o ensure users are not connected to the server during the installation schedule the advertisement.
1. Specify multiple mandatory assignments, one for each installation attempt. Create at least two mandatory
assignments for each maintenance window.
2. Select Rerun if failed previous attempt as the program rerun behavior.
Unlike other advertisements created in Configuration Manager, advertisements for XenApp have a timeout period after
which the XenApp Connector notifies users and logs them off. You set the timeout period when you configure the
XenApp Connector. T o ensure that the last mandatory assignment logs users off and installs the application, ensure the
period between the first and last mandatory assignments is longer than the timeout period.
For XenApp servers that are configured to allow XenApp Connector to use Power and Capacity Management to manage
their power states and load consolidation, XenApp Connector changes the servers' power controller preference to drain
user connections from targeted servers that have not processed the advertisement.
For Configuration Manager to manage a XenApp server, send it advertisements, and included it in publications, its
information must be included in the Configuration Manager database.
Important: Do not edit the XenApp Publications folder. It is for the XenApp Connector's internal use only.
1. If the application publishing wizard is not already running, start it from the Configuration Manager console by right-
clicking the XenApp Publications folder and selecting New > XenApp application publishing.
2. T o publish the application, follow the instructions in the wizard. When publishing an application you indicate the
following:
Whether the application you are publishing is an installed XenApp application or Microsoft Application Virtualization
(App-V) sequence.
Whether your publishing target is a collection or a package.
If you are certain that the application you are publishing is already installed on all the servers, specify a collection as
the target. When you specify a collection as the target, the Connector configures all servers in the collection to
give users access to the application. Using a collection as the target is best suited to publishing applications that
are always installed on servers, such as Internet Explorer.
If the application you are publishing might not already be installed on all servers, specify a package as the target.
When you specify a package as the target, only after servers have processed the package advertisement and the
application program do they give users access to the application. T his ensures that users only access servers where
the application is already installed.
If you are publishing an App-V sequence, always specify the file type or file types you want associate with the
application for content redirection. T he wizard cannot associate an appropriate default file type for App-V
sequences.
3. Configure the content redirection advanced setting if the application you are publishing is:
An App-V sequence
An installed XenApp application located on a computer other than the computer on which the Configuration
Manager console is installed
If the file type you want does not appear in the list of file types, click Add to add a custom file type.
XenApp Connector for Configuration Manager 2007 enables you to manage the delivery of Microsoft Windows Server
Update Services (WSUS) software updates to XenApp servers. By using the Power and Capacity Management feature to
coordinate the power states and load consolidation of the XenApp servers, XenApp Connector deploys WSUS updates with
minimal disruption of user sessions.
1. Ensure that XenApp Connector is enabled to use Power and Capacity Management on the XenApp servers to which you
want to install WSUS updates.
2. If you have not already done so, configure XenApp Connector for WSUS updates and configure a maintenance window
for XenApp servers:
1. On the server on which XenApp Connector is installed, run the XenApp Connector configuration wizard,
ConfigWizard.exe.
2. On the Configuration Manager Site page of the wizard, enable WSUS, create a maintenance window for XenApp
servers, and specify maintenance window's the start time, end time, and frequency. Follow the prompts to complete
the configuration wizard.
T he configuration wizard creates a Citrix WSUS task sequence advertisement in the Advertisements folder of the
Software Distribution node of the Configuration Manager console. T his advertisement has the maintenance window
schedule you specified.
3. Use Configuration Manager console to deploy one or more WSUS updates to servers in the XenApp Farm collection. T he
deadline you set for this software update installation is used only if the Citrix WSUS task sequence fails to install the
update before that time.
XenApp Connector uses Power and Capacity Management to drain users from XenApp servers you targeted to receive the
WSUS update.
At the specified times within the maintenance window, Citrix WSUS task sequence runs on every targeted XenApp server
and installs the WSUS update on XenApp servers that have no user sessions.
If the WSUS update has not been installed on all targeted XenApp servers when the software update installation deadline
is reached, Citrix WSUS task sequence forces installation of the update on the any server that does not yet have the
update installed and reboots the server, even if it has active user sessions.
To view log files created by the tasks that make up XenApp Data Connector, use the SMS Trace tool provided with the
Microsoft System Center Configuration Manager 2007 Toolkit V2. To view other XenApp Connector log files, use the SMS
Trace tool or a text editor that maintains formatting, such as WordPad.
Log files created by the tasks that make up XenApp Data Connector are created and appended in the log folder in the
install directory.
XenApp Program and Package Service Most recent output: Program and Package Service.log
XenApp and ConfigMgr Synchronization Service Most recent output: Synchronization Service.log
To change these defaults, as well as parameters that control the types and information contained in the log files and the
appearance of the log file when viewed with the SMS Trace tool, edit the XAConnector.config file.
Log files created when either component of the XenApp Connector is installed are created in the user's %temp% folder.
Important: Windows Server 2008 R2 deletes a session's temporary directory when the server restarts. T o preserve the install
log files, either copy the logs to a safe place before the server restarts or change your local computer policy (before
installation) to prevent deletion of the temporary directories.
Log files created when the Configuration Manager Console Extension is installed are created and appended in the "log"
folder in the install directory.
AdminUI Install Errors and actions during installation of the Configuration Manager Console Extension
Operations Manager is a management solution for Microsoft Windows server deployments that collects, filters, analyzes,
responds to, and reports information about computers— all from a single view on a desktop console. You can use
Operations Manager for performance monitoring, event management, alerting and reporting, and trend analysis.
Operations Manager also includes an extensive product support knowledge base, with links to Knowledge Base articles on
the Microsoft Web site that provides you with centralized access to the information you require to manage a complex
enterprise environment and troubleshoot problems occurring on servers and applications across the network.
For more information about Operations Manager, see Microsoft’s Web site: http://www.microsoft.com/.
Key features and benefits of using the Management Pack in your XenApp deployment are:
St at e monit oring
T he Management Pack monitors the overall state of your deployment, determining its availability and performance state at
any given time by comparing real-time data collected from the Provider and the Licensing Provider against thresholds
defined in the Management Pack. You can view this information at different levels, from the state of the deployment as a
whole, right down to the state of individual servers.
Event management
T he Management Pack captures a variety of events from servers and server farms. T hese events are collated and then
presented through the Operations Manager Console, allowing an overall view of server operation.
For further information about installing the XenApp Provider and the Licensing Provider, see Managing Providers and WMI.
To use the Management Pack, you must be running Operations Manager 2007 or Operations Manager 2007 SP1. For
information about Operations Manager 2007 minimum hardware and software requirements, see your Operations
Manager 2007 documentation.
To obtain information about servers and the server farm, the Management Pack requires the XenApp Provider to be
installed on every XenApp computer that you want to monitor. T he XenApp Provider is a data provider that extracts
information about the server on which it is installed and presents this to the Operations Manager Agent. T he Provider
supplies information about the server and, where appropriate, about the farm in which this server operates.
T he Management Pack also requires the Licensing Provider to be installed on the license servers if you want to monitor
them. T he Licensing Provider is a data provider that supplies information about Citrix licenses. For example, the
Management Pack displays information about the number of licenses in use for each license pool, and raises alerts if the
pool is low on available licenses or if a license is about to expire.
Both Providers are installed by default. For more information about the Providers, see Managing Providers and WMI.
Only licensed servers running Citrix Presentation Server 4.0 or later are fully supported as managed servers. Unlicensed
servers and servers running earlier versions are not monitored by the Management Pack.
1. Locate the three files, Citrix.PresentationServer.mp, Citrix.Library.mp, and Citrix.Licensing.mp. T he files on the installation
media are also available for download from http://www.citrix.com/.
Note: If you do not want to monitor license servers, you can omit the Citrix.Licensing.mp file.
2. Log on to the Operations Manager and open the Operations Console.
After the Management Pack installs or upgrades successfully, Operations Manager automatically deploys it to all the
managed computers in your management group.
After you install the Management Pack, add the servers you want to monitor to the list of agent-managed computers if
you are not already monitoring these computers using Operations Manager. Ensure that all license servers are also added to
the list of managed computers in Operations Manager. To add these servers to the list of managed computers, install the
Operations Manager agents on the respective servers. For more information, see your Operations Manager documentation.
Some health monitors specific to XenApp are disabled by default because they require configuration to make them
appropriate to your site. For information about how to configure these monitors, see Configuring and Enabling Site-specific
Monitors.
Important: Ensure that the XenApp Provider is installed on every server that you want to monitor, and that an appropriate
license is allocated in each server farm being monitored. For more information about the XenApp Provider and the Licensing
Provider, see Managing Providers and WMI.
You can uninstall the Management Pack by using the Operations Manager Console. Uninstalling the Management Pack
removes all the references to it from the Operations Manager database, including the base monitoring objects provided by
the Management Pack along with any dynamically discovered event, performance, or alert data. For information about
uninstalling management packs, see your Operations Manager documentation.
Important: If there are any other management packs in Operations Manager that are dependent on the Citrix XenApp
Management Pack, you must uninstall them before you can successfully uninstall the Management Pack.
T he Management Pack monitors and reports on several Citrix-specific objects. T hese objects are described in the following
table:
Citrix Deployment Represents a discovered XenApp deployment that can consist of multiple
farms and zones.
Citrix Farm Represents a XenApp farm that can consist of multiple zones. A farm is
Citrix Zone Represents a zone that can consist of multiple Citrix managed servers. A
zone is managed by a single zone data collector.
Citrix Zone Data Collector Represents a managed server performing the role of zone data collector.
Citrix Farm Metric Server Represents a managed server performing the role of farm metric server.
If you installed the Citrix AppCenter on the Operations Manager server, you can start the console from the Operations
Manager Console.
You can start the AppCenter from any non-empty Citrix view.
Important: T o start the AppCenter, the ASCLAUNCHPAT H environment variable must be set to the path of the console; for
example, C:\Program Files (x86)\Citrix\Citrix Delivery Services Console\Framework\CmiLaunch.exe.
1. Log on to the Operations Manager Console.
2. Perform one of the following:
In the Actions pane, select Start Access Management Console.
Right-click an object in the Results pane, and select Managed Citrix Presentation Server tasks > Start Access
Management Console.
You can use Installation Manager through a Microsoft Management Console (MMC) snap-in, or by issuing custom
Microsoft PowerShell cmdlets.
File share T ransfers and stores task files, including storing cache files containing previously scheduled tasks and
results. For regional deployments, you may want to use multiple file shares.
T he task management computer and the file share can be on separate computers or on one of the target servers.
Administration Contains the core Installation Manager functionality. Install this package on the task management
computer.
Utilities Contains the PowerShell cmdlets required for MSI or MSP installation on target servers. Install this
package on the target servers.
Note: If you will not use Installation Manager to deploy MSI or MSP packages, you do not need to
install the Utilities package on the target servers.
T he task management computer (where you install the Administration package) can be a separate computer or one of the
target servers.
Supported platforms
Windows Vista (32-bit and 64-bit)
Windows 7 (32-bit and 64-bit)
Windows Server 2008 R2 (64-bit)
Required software
.NET Framework 3.5 SP1
PowerShell 2.0 (on Vista platforms, PowerShell 1.0 is also supported)
MMC 3.0
XenApp 6.5 for Windows Server 2008 R2 must be installed on the Windows Server 2008 R2 platform if you want to
publish applications using the management console, associate published applications with servers, or deploy existing
published applications to target servers.
T he target servers must be running Windows Server 2008 R2 and XenApp 6.5 for Windows Server 2008 R2. Each target
server requires the following software (this software is required for XenApp installation, so it is likely to already be installed):
.NET Framework 3.5 SP1
PowerShell 2.0
If you will be using Installation Manager to deploy MSI or MSP packages to target servers, you must install the Utilities
package on each target server. T here are no additional software requirements to install or use the Utilities package on the
target servers.
T he file share can be on any Windows Server 2003 or later platform. T he file share can be on a separate computer, on the
task management computer, or on a target server.
Installation Manager uses implicit authentication for remote access to the Windows Task Scheduler API. To create
Installation Manager tasks, you must have administrative access to the Installation Manager console and the target
servers, have full control of the file share, and belong to the Local Administrator group on each target server.
When a task is scheduled, Installation Manager automatically assigns permission from the target servers to the file share.
When you install the Utilities package on a target server, four Windows firewall rules are enabled (these rules are disabled by
default). T hese rules allow access to the T ask Scheduler and Event Log Management services using DCOM. T he enabled
rules are:
Remote Scheduled T ask Management (RPC and RPC-EPMAP)
Remote Event Log Management (RPC and RPC-EPMAP)
Before uninstalling Installation Manager, be sure all users are logged off. Close all applications, including the console.
Use the Remove Programs feature in the Control Panel to remove the Installation Manager package MSI.
To remove the Utilities package from target servers, you can use the Remove Programs feature, or you can schedule a
command-line task to uninstall the package from all target servers.
To schedule installation of MSI or MSP packages using Installation Manager, the Utilities package must be installed on the
target servers.
From the Installation Manager console, click Schedule MSI package distribution in the Actions pane. In the Schedule MSI
Package Distribution dialog box:
Enter the name of the task. T he task name must start with an alphabetic character. T he name must be unique, unless
you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select
this option, the task is updated with the new definition.
In the T arget list, specify the target servers where you want to install this package. Click Servers to select from Active
Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name.
In MSI/MSP file path, enter the location of the MSI or MSP package to be scheduled for installation. To include a
transform file, specify its location in MST list.
To make the MSI, MSP, and MST files available from a single shared folder accessible by all target servers, click Advanced
and specify a Shared folder in the Advanced Options dialog box. Any selected MSI, MSP, and MST files will be copied to
this folder, if not already present. Installation Manager assigns read permission from the target servers to the file share.
Enter the date and time to start the installation in Schedule date and time, or select Now to launch the task
immediately.
Use Session Options to specify what happens to user sessions on the target servers during and after the installation
process.
Logoff existing Forces users to log off the server before launching the installation. You can specify how long
sessions to wait before users are logged off; you can also send a message to logged-on users that
instructs them to save their work and log off.
Reboot target Restarts the server after installation. You can specify how long to wait after the installation
after successful completes to restart the server.
installation
If Installation Manager fails to schedule a task on a server (for example, when a server is offline), it tries to reschedule
the task. T o specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify
Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error
occurs.)
To schedule installation of MSI or MSP packages using a PowerShell cmdlet, see Create-IMMSITask.
You should be familiar with using Task Scheduler; see the Microsoft documentation for information. Use the Task Scheduler
MMC to create the Task Scheduler file. Installation Manager passes the Task Scheduler file directly to Windows Task
Scheduler; it is not transferred using the file share.
From the Installation Manager console, click Distribute Windows T ask Scheduler file in the Actions pane. In the distribute
Windows T ask Scheduler File dialog box:
Enter the name of the task. T he task name must start with an alphabetic character. T he name must be unique, unless
you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select
this option, the task is updated with the new definition.
Enter the location of the T ask Scheduler file in T ask XML file.
In the T arget list, specify the target servers where you want to install this task. Click Servers to select from Active
Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name.
If Installation Manager fails to schedule a task on a server (for example, when a server is offline), it tries to reschedule
the task. T o specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify
Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error
occurs.)
To schedule installation of Task Scheduler Files using a PowerShell cmdlet, see Create-IMTask.
From the Installation Manager console, click Schedule command-line task in the Actions pane. In the Schedule command-
line task dialog box:
Enter the name of the task. T he task name must start with an alphabetic character. T he name must be unique, unless
you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select
this option, the task is updated with the new definition.
In the T arget list, specify the target servers where you want to install this task. Click Servers to select from Active
Directory or XenApp server folders, or enter a comma-delimited list of servers by DNS name.
After you use Installation Manager to install an application on a XenApp server, use this procedure to add the XenApp
server to a preexisting published application object. T his results in XenApp including that server when it load balances
session requests to that application.
1. From the Installation Manager console, select a task in the T ask pane and then click Publish Application in the Actions
pane.
2. Click Browse and then enter the name of the XenApp server where Installation Manager will retrieve the list of published
applications.
3. Click Go and select the published application from the list.
Rescheduling creates a copy of the task, so you can change its parameters. You can reschedule command-line tasks and
MSI/MSP package deployments.
1. From the Installation Manager console, select a task in the T ask pane and then click Reschedule in the Actions pane.
2. In the Reschedule CMD T ask or Reschedule MSI T ask dialog box, change field values as needed.
Removing a Task Scheduler entry does not remove the task from the list in the MMC. If you remove a task that has already
executed, this action removes only its Task Scheduler entry; it does not undo the installation or deployment of files.
From the Installation Manager console, select a task in the Task pane and then click Remove in the Actions pane.
Cmdlet Summary
T his reference assumes you are familiar with using PowerShell. T he Installation Manager cmdlets support the standard
PowerShell common parameters, such as WhatIf.
T his topic provides brief options descriptions. For complete cmdlet syntax, type Get-Help cmdlet-name at the PowerShell
prompt.
Get-IMServer
Option Description
-farm IP address or DNS name of the MFCOM farm object. If this option is omitted, the local server is used.
-folder Path to the server folder in the farm, in the format \folder1\folder2.
For example, the following cmdlet lists servers in the XenApp farm with a DNS name of XenAppFarmIN.
Get-IMServer -farm XenAppFarmIN
-folder Servers\TargetFolder
Create-IMMSITask
Schedules installation of an MSI or MSP package on target servers. You can specify the following options:
Option Description
-msi (Required) Path to the installation package. T he file must be accessible by the task management
computer. T he cmdlet checks if this file exists; if it does not exist, an error is displayed.
-targets (Required) T arget servers where the package will be installed. Specify one of the following:
A comma-delimited list of individual servers by DNS name
An object containing Name attributes (as returned by the Get-IMServer cmdlet)
-mst List of paths to MSI transform files. T he files must be accessible by the task management computer.
T he cmdlet checks if this file exists; if it does not exist, an error is displayed.
- Forces users to log off the server before launching the installation. (You can use the -message option
logoffSessions to prompt users to save their work and log off.)
-reboot Restarts the server after installation. (You can use the -timeout option to specify how long to wait
after installation completes to restart the server, and the -message option to specify a message to
be sent to connected sessions before the restart.)
-message Sends a message to all connected sessions before a logoff or restart. T his option is valid with the -
logoffSessions and -reboot options.
-timeout Specifies the number of minutes that connected sessions have until a server restart.
-update Overwrites any existing task with the same task name. If this option is omitted and another task with
the same name exists, the task fails.
-prepareUnc Specifies a shared folder, in UNC format, that Installation Manager uses to transfer files to target
servers. Installation Manager automatically copies the specified MSI, MSP, and transform (MST ) files
to this folder and assigns read permission from the target servers to the file share. You must have
sufficient rights to set UNC permissions. T he folder must be accessible by all specified target servers.
-log Path to a file or XML object where the success or failure status of the installation on each target
server is logged.
-retrytime If a target server cannot be contacted, this option specifies how long (in seconds) Installation
Manager will retry the installation task. If you specify a retry time, you must also specify a retry
interval.
-retryinterval If a target server cannot be contacted, this option specifies how often (in seconds) Installation
Manager will retry the installation task. If you specify a retry interval, you must also specify a retry
time.
For example, the following cmdlet distributes an MSI package (located at c:localfolder\myapp.msi), using a transform
(located at c:\localfolder\myapp_silent.mst), and a shared folder (\\fileserver\im), on the target servers XAWRK1, XAWRK2,
and XAWRK3. T he task will launch the first day of October 2010 at 11:50 p.m. Users will be alerted with a message before
Schedules installation of a Task Scheduler file. You should be familiar with using Task Scheduler. Use the Task Scheduler
MMC to create the Task Scheduler file. Installation Manager passes the Task Scheduler file directly to Windows Task
Scheduler; it is not transferred using the file share.
Option Description
-task (Required) Path to the XML file or PowerShell XML object to install. T he XML schema must follow Task
Scheduler 2.0 specifications.
-targets (Required) T arget servers where the file will be installed. Specify one of the following:
A comma-delimited list of individual servers by DNS name
An object containing Name attributes (as returned by the Get-IMServer cmdlet)
-update Overwrites any existing task with the same task name. If this option is omitted and another task with
the same name exists, the task fails.
-retrytime If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager
will retry the installation task. If you specify a retry time, you must also specify a retry interval.
- If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager
retryinterval will retry the installation task. If you specify a retry interval, you must also specify a retry time.
-log Path to a file or XML object where the success or failure status of the installation on each target server
is logged.
For example, the following cmdlet distributes a Windows T ask Scheduler file (located at C:\task.xml) that runs a backup
script (named Backuptask) on the target servers (XAWRK1, XAWRK2, and XAWRK3). If a target server is busy, Installation
Manager will retry every 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition will
Schedules installation of a command-line task. You can specify the following options:
Option Description
-targets (Required) T arget servers where the package will be installed. Specify one of the following:
A comma-delimited list of individual servers by DNS name
An object containing Name attributes (as returned by the Get-IMServer cmdlet)
-schedule Date and time the installation task will run. Specify one of the following:
A date in the format DD/MM/YYYY and the time in 24-hour format HH:MM:SS, enclosed in single or
double quotes
now to launch the task immediately
-update Overwrites any existing task with the same task name. If this option is omitted and another task with
the same name exists, the task fails.
- Specifies a shared folder, in UNC format, that Installation Manager can use to transfer files to target
prepareUnc servers. Installation Manager automatically transfers files to this folder and updates the folders' ACL to
ensure all servers have read access to it. You must have sufficient rights to set UNC permissions.
-retrytime If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager
will retry the installation task. If you specify a retry time, you must also specify a retry interval.
- If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager
retryinterval will retry the installation task. If you specify a retry interval, you must also specify a retry time.
-log Path to a file or XML object where the success or failure status of the installation on each target server
is logged.
For example, the following cmdlet schedules installation of a task (named Installnotepad) using the command-line
notepad.exe, on target servers XAWRK1, XAWRK2, and XAWRK3. If a target server is busy, Installation Manager will retry
every 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition will be overwritten.
Success/failure status of the installations will be logged to C:\log.xml.
Create-IMCMDTask -name Installnotepad
Obtains success or failure status about scheduled task installations. You can specify the following options.
Option Description
-targets (Required) T arget servers for which you want task installation information. Specify one of the following:
A comma-delimited list of individual servers by DNS name
An object containing Name attributes (as returned by the Get-IMServer cmdlet)
-fromdate Starting date of the interval for which you want status.
-todate End date of the interval for which you want status.
-log XML path of the log file. If this option is omitted, the status is displayed in the PowerShell console.
For example, the following cmdlet displays status in the PowerShell console about the installation of the task named
Installnotepad on target servers XAWRK1 and XAWWRK2.
Get-IMTask -targets XAWRK1,XAWRK2
-name Installnotepad
Remove-IMTask
Removes a task scheduled on target servers. You can specify the following options:
Option Description
-targets (Required) T arget servers on which you want to remove a scheduled task. Specify one of the following:
A comma-delimited list of individual servers by DNS name
An object containing Name attributes (as returned by the Get-IMServer cmdlet)
-retrytime If a target server cannot be contacted, this option specifies how long (in seconds) Installation Manager
will retry the task removal. If you specify a retry time, you must also specify a retry interval.
- If a target server cannot be contacted, this option specifies how often (in seconds) Installation Manager
retryinterval will retry the task removal. If you specify a retry interval, you must also specify a retry time.
-log Path to a file or XML object where the success or failure status of the task removal on each target
server is logged.
Generally, a positive value indicates a successful condition or provides general information. A negative value usually indicates
an error condition.
Administration Messages
-100 A connection to the server could not be established. T he server may not be physically
connected.
-101 Invalid farm argument. Specify a valid server address. T he specified farm name may either be
syntactically wrong or may not exist.
-104 Invalid arguments. Specify either "match" or "like" arguments, not Specify either Match or Like for filtering
both. servers.
-105 XenApp SDK is not installed or Check DCOM Settings DCOM settings in the client computer
are either missing or incorrect.
-106 T he folder specified {0} does not exist. Specify a valid folder
name in the format Servers/folder1/folder2.
-107 Access denied while enumerating Servers/Folders in farm. T he administrator is not a Citrix
Administrator.
-205 Server is unreachable. Check network connections. T he task cannot register itself with the
T ask Scheduler.
-207 You do not have permission to access the target server. You T he application cannot register a task
-211 Invalid T ask XML format. Document contains invalid tags. T he task XML document does not
comply with the T ask Scheduler 2.0
standard schema.
-212 Unable to write Log file {0}. check that the path exists and that T he application cannot create the log
you have write permissions to it. file because it does not have write
permission for the specified path.
-214 Unable to read T ask file {0} check that the file exists and that T he task file is not at the specified
you have read permissions to it. location or cannot be accessed due to
incorrect permissions.
-216 Specify the interval time in seconds for the Retry parameter. A negative value was specified for the
retry interval time.
-219 T his task name already exists on the target server. Enter a unique T he specified task name already exists.
task name.
-220 Network path {0} is unreachable. Check network connections. T he servers are physically disconnected.
-221 Invalid T ask XML format. Cannot find "action" tag. T he task XML file does not contain the
mandatory <actions> tag.
-222 You do not have permission to schedule a task. You must be a Insufficient permissions exist to access
local Administrator on the target server. the target task scheduler.
-223 Invalid T ask XML format. T he "command" tag contains invalid T he task XML file does not contain the
data. mandatory <command> tag.
-224 Invalid T ask XML format. T he "command" tag is not well-formed. T he task XML <command> tag
formation is not valid.
-226 T he filename, directory name, or volume label syntax is incorrect T he specified task name is in an invalid
for path {0} format.
-233 Invalid task name. T he specified task name does not start
with an alphabetical character.
-234 Invalid target argument. Specify a valid server address. T he specified server IP address is not
valid.
-241 Missing retrytime argument. It is mandatory if retryinterval is A retry interval value was specified
provided. without a retry time value.
-242 Missing retryinterval argument. It is mandatory if retrytime is A retry time value was specified without
provided. a retry interval value.
-300 Use the following date and 24-hour time format: DD/MM/YYYY T he time and date specified for the
HH:MM:SS. schedule option are not in the required
format.
-301 Unable to prepare UNC path {0}. Check your credentials. Access was denied to the PrepareUNC
path due to insufficient permission.
-302 Invalid command argument. Specify a valid command-line A cmdlet option was incorrectly
operation. specified.
-400 Specify a reboot timeout period in minutes for the Reboot- T he timeout value specified is not an
T imeout parameter. integer.
-404 Unable to read MSI file {0}. Check that the file exists and that Access was denied to the MSI file due
you have read permissions to it. to insufficient permission.
-405 Unable to read MST file {0}. Check that the file exists and that Access was denied to the transform
you have read permissions to it. (MST ) file due to insufficient permission.
-600 Unable to connect to Event Log of the target server. You must
be a member of "Event Log Readers" group in the target server.
-611 T ask Failed. Verify if IM Utilities is installed at target server. T he Utilities package is not installed on
the target server.
-801 COM error while scheduling task in target system : {0} A COM exception occurred while
schedule a task in the T ask Scheduler
on the target server.
-802 Generic error while scheduling task in target system :{0} An exception occurred while scheduling
a task in the T ask Scheduler on the
target server.
-803 COM error while retrieving task information from target system : A COM exception occurred while
{0} retrieving task information from the
T ask Schedule on the target server.
-804 COM error while removing task form target system :{0} A COM exception occurred while
removing a task form the T ask
Scheduler on the target server.
-805 Generic error while removing task from target system :{0} An exception occurred while removing a
task from the T ask Scheduler on the
target server.
-901 MFCOM is not registered on the system. Use the MFREG tool to
register the server.
Utilities Messages
T he following messages may be generated if you installed the Utilities package on the target servers, which is required if
you are scheduling MSI or MSP packages for installation on the target servers.
-105 XenApp SDK is not installed or Check DCOM Settings DCOM settings in the client
-226 T he filename, directory name, or volume label syntax is incorrect for path
{0}
-701 Unable to read Installation files using system credentials. Ensure "Everyone" Unable to access MSI log file.
has read permission to the share and "Advanced:Shared Folder" parameter
contains the UNC path where the file is located.
-702 Unable to connect to the XenApp farm. Specify only XenApp servers when XenApp farm initialization
using publish-app or disable-logon parameters. failed.
-703 Unable to add server to published application. T he installation was T he server may not exist.
successful, use Delivery Services Console to add the server to the published
application object.
-709 T erminal Server role is not enabled. Reboot and logoff parameters are only T arget server does not have
available for T erminal Server targets. T erminal Services enabled.
-710 Unable to send message to connected sessions. Operation was canceled. Error sending T erminal
Services messages.
-711 Unable to reboot server. T he installation was successful otherwise, reboot Error restarting T erminal
the server manually to complete the operation. Services target.
712 T his Citrix XenApp PowerShell snap-in contains cmdlets used to perform
installations on XenApp servers.
-724 Unable to write event to Windows Event Log. An error occurred when
WMI Provider. Acts as an intermediary between the CIM (Common Information Model) Object Manager and the system
being managed. T he purpose of a WMI provider is to extract management information from the underlying system and
present this to a WMI consumer.
The CIM Object Manager (CIMOM). Acts as a broker between the WMI providers and consumers. When a WMI
consumer requests information, CIMOM identifies the WMI provider that can supply the information, obtains the
information, and passes it to the consumer. CIMOM has its own repository in which it stores the data supplied to
consumers. T he Managed Object Format (MOF) files are also stored in the CIMOM repository. A MOF file defines the
schema, which is the data that a WMI provider can supply and the methods it can execute in response to WMI requests.
WMI Consumer. A management tool such as Microsoft Operations Manager (MOM), an MMC snap-in such as the Citrix
AppCenter or a third party application.
Depending on which version of XenApp you have installed, Citrix XenApp Management Pack for MOM 2005, or Citrix
XenApp Management Pack for Systems Center Operations Manager 2007 and Citrix XenApp Management Pack for
Systems Center Operations Manager 2007 SP1 are included with your product.
XenApp Provider
T he Citrix XenApp Provider for Microsoft Windows Management Instrumentation (also referred to as the XenApp Provider
or the Provider) extracts information about the server on which it is installed and, where appropriate, about the server farm
in which this server operates. It presents this information to a WMI consumer, such as MOM, for display.
For example, information about sessions on the server and published applications in the server farm is provided. You can use
this information to monitor the health and availability of the server and server farm.
When you install the Provider, the files are installed in the \WMI folder in the same directory in which XenApp is installed.
Typically, this is: C:\Program Files\Citrix\System32\Citrix\WMI. T he following files are included in this folder:
To gather and display information, use a suitable WMI consumer, such as the Citrix XenApp Management Pack for
Microsoft Operations Manager.
Security Considerations
To display information about XenApp computers and server farms using a WMI consumer, access to the Root\Citrix
namespace in the WMI configuration is required. T he appropriate Citrix administration rights to display information about
servers and server farms is also required.
If you delegate areas of XenApp administration and server farm management to Citrix administrators, these administrators
can monitor and control only the specific administration tasks for which they have permissions. For example, if a Citrix
administrator can manage only published applications, only information about published applications is available to them
from the XenApp Provider.
Licensing Provider
T he Licensing Provider is available on each Windows-based license server. It is installed by default with the license server.
T his WMI provider extracts information about licensing from the license server on which it runs and presents this data to a
WMI consumer, such as MOM, for display. For example, the Licensing Provider supplies information about the number of
licenses in use and licenses that are about to expire.
T he XenApp Provider no longer supplies licensing information for computers running MetaFrame Presentation Server 3.0 or
later. However, the Licensing Provider still supplies licensing information for servers running earlier versions of XenApp. T his
means that you can monitor multiple farms, running different versions of XenApp. For backwards compatibility, the licensing
classes are still in the schema for the XenApp Provider.
Note: For information about the data the Licensing Provider can supply, see the Citrix .mof files. T he files are in the
\LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).
To gather and display information, use a suitable WMI consumer, such as the Citrix XenApp Management Pack for
Microsoft Operations Manager.
XenApp Provider
Licensing Provider
Note: T hese diagrams represent typical WMI schemas, rather than providing a comprehensive list of all the data returned by
the Providers. For more information about the data the XenApp Provider can supply, see the Citrix .mof files in the \WMI
folder (for example: C:\Program Files\Citrix\System32\Citrix\WMI). For more information about the data the Licensing
Provider can supply, see the Citrix .mof file in the \LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).
XenApp Provider WMI Schema (Part 1 of 3)
Software updates to XenApp 6.5 and to Secure Gateway 3.3 are available that introduce support for Versions 1.1 and 1.2 of
the Transport Layer Security (T LS) protocol. To upgrade your XenApp and/or Secure Gateway deployments, download and
apply the following software updates:
T he Secure Gateway for Windows helps you to secure access to enterprise network computers running Citrix XenApp and
provides a secure Internet gateway between Citrix XenApp and user devices. T he Secure Gateway transparently encrypts
and authenticates all user connections to help protect against data tampering and theft. All data traversing the Internet
between a remote workstation and the Secure Gateway is encrypted using the Secure Sockets Layer (SSL) or Transport
Layer Security (T LS) protocol.
T he Secure Gateway is an application that runs as a service on a server that is deployed in the demilitarized zone (DMZ).
T he server running the Secure Gateway represents a single point of access to the secure, enterprise network. T he Secure
Gateway acts as an intermediary for every connection request originating from the Internet to the enterprise network. For
increased security, the Secure Gateway Proxy is used with the Secure Gateway in a double-hop DMZ deployment. T he
Secure Gateway is installed in the first DMZ and the Secure Gateway Proxy is installed in the second DMZ. T he Secure
Gateway Proxy acts as a conduit for traffic originating from the Secure Gateway to servers in the secure network, and
from servers in the secure network to the Secure Gateway.
Your enterprise network can contain one or more servers running Citrix XenApp. A server farm is used for hosting published
resources that users can access over the network.
T he Secure Gateway works with the following components of Citrix XenApp for logon and authentication:
Important: T he Secure Gateway and Secure Gateway Proxy are not supported in environments that use NetScaler
Gateway and Advanced Access Control.
Planning a Secure Gateway Deployment
T he deployment of the Secure Gateway depends on several factors, including which Citrix components you have in your
enterprise network. T he Secure Gateway is designed to work with Citrix XenApp.
If your enterprise network contains a server farm, you can deploy the Secure Gateway to provide secure Internet access to
published resources. In such deployments, the Secure Gateway works with the Web Interface to provide authentication,
authorization, and redirection to published resources hosted on a Citrix XenApp server.
To ensure that the security of the Secure Gateway is not compromised, Citrix recommends reserving servers for the
exclusive use of the Secure Gateway.
Note: Citrix recommends setting up the Secure Gateway in a test environment before implementation to your production
environment to make sure all of the features work correctly.
Place the Secure Gateway in the DMZ between two firewalls for maximum protection. In addition, physically secure the
DMZ to prevent access to the firewalls and servers within the DMZ. A breach of your DMZ servers may, at best, create an
annoyance in the form of downtime while you recover from the security breach.
Important: Citrix recommends that you configure your firewalls to restrict access to specific T CP ports only. If you
configure your firewalls to allow access to T CP ports other than those used for HT T P, ICA, SSL, and XML data, you may
allow users to gain access to unauthorized ports on the server.
Installing the Secure Ticket Authority
When Citrix XenApp is installed, the Secure T icket Authority (STA) is installed and configured automatically.
T he STA eliminates the requirement for Microsoft’s Internet Information Services (IIS). T he STA can be hosted by the Citrix
XML Service. If the STA is hosted by the Citrix XML Service, configure the Citrix SSL Relay.
During installation of the Secure Gateway, enter the FQDN of the server running Citrix XenApp. If you are using an SSL-
enabled connection between the Secure Gateway and the STA, make sure the correct certificates are installed from a
certificate authority.
T he deployment of the Secure Gateway depends on several factors, including which Citrix components you have in your
enterprise network. T he Secure Gateway is designed to work with Citrix XenApp.
If your enterprise network contains a server farm, you can deploy the Secure Gateway to provide secure Internet access to
published resources. In such deployments, the Secure Gateway works with the Web Interface to provide authentication,
authorization, and redirection to published resources hosted on a Citrix XenApp server.
Note: Citrix recommends setting up the Secure Gateway in a test environment before implementation to your production
environment to make sure all of the features work correctly.
Place the Secure Gateway in the DMZ between two firewalls for maximum protection. In addition, physically secure the
DMZ to prevent access to the firewalls and servers within the DMZ. A breach of your DMZ servers may, at best, create an
annoyance in the form of downtime while you recover from the security breach.
Important: Citrix recommends that you configure your firewalls to restrict access to specific T CP ports only. If you
configure your firewalls to allow access to T CP ports other than those used for HT T P, ICA, SSL, and XML data, you may
allow users to gain access to unauthorized ports on the server.
Secure Gateway Features
Designed-in security
T he Secure Gateway provides authentication, authorization, and cryptography functionality that is consistent with
Microsoft’s best practices for secure software.
Network protocol support
T he Secure Gateway supports the T CP/IP protocols, such as FT P, HT T P, and T elnet.
IPv4 and IPv6 protocol support
T he Secure Gateway can be configured to accept inbound connections from clients using IPv4 and IPv6 addresses.
Secure Socket Layer support
T he Secure Gateway provides SSL support to secure communication between the client and the Secure Gateway
components.
Simple deployment
Citrix XenApp includes the Secure T icket Authority (ST A) and is merged into a single Windows Installer package resulting in a
more efficient deployment. T he ST A is deployed automatically on the same computer as Citrix XenApp, resulting in a
reduction of the number of computers required for basic deployment Internet Information Server is no longer a
requirement for installing the ST A Internet Information Server deployment is a supported option during installation of Citrix
XenApp.
Certif icate management
T he Secure Gateway Configuration wizard prevents the selection of a certificate that does not have a private key and
verifies that the appropriate certificate is installed in the local computer certificate store. Wildcard certificate support.
Wildcard certificates can be deployed on the Secure Gateway, the Secure Gateway Proxy, and on the computer where
Citrix XenApp is hosting the ST A.
Load balancing
T he Secure Gateway provides load balancing for the Secure Gateway Proxy. IP addresses are retrieved from the DNS using
a domain name or listed individually.
Logging
T he Secure Gateway uses the Apache standard access log files and supports log rotation functionality for the access log
files. T he access log files provide connection information to the Secure Gateway or the Secure Gateway Proxy.
Instrumentation
T he Secure Gateway includes a new set of performance counters to analyze the usage and load on the Secure Gateway
server.
Based on Apache Technology
T he software code based on Apache technology is used as a foundation for building the Secure Gateway.
Operating Systems
Important: Secure Gateway runs as a 32-bit application on 64-bit Windows operating systems.
Hardware Requirements
T he Secure Gateway requires the minimum hardware requirements for supported Windows operating systems, as specified
by Microsoft.
Important: For maximum security, Citrix recommends you reserve a standalone server for the Secure Gateway.
Citrix Products Compatibility with Secure Gateway
You can use Secure Gateway installed on a computer running a different Windows operating system than XenApp servers in
the same environment.
T he Secure Gateway is compatible with the following Citrix Receiver for Windows and Citrix online plug-in software:
Citrix Receiver for Windows 13.0, which includes Citrix Receiver Admin and Citrix Receiver Web. Citrix Receiver for
Windows 13.0 is the successor to the Online Plug-in for Windows 12.1.
Citrix Online Plug-in for Windows 12.1, including Citrix online plug-in web.
Citrix Online Plug-in for Windows 11.2, including Citrix online plug-in web.
Important: Secure Gateway and Secure Gateway Proxy do not support the Citrix Offline Plug-in.
User Devices
Note: Operating systems on mobile devices, such as Android, iOS, Mac, and PlayBook, may also support connections for
Receiver using Secure Gateway. For mobile devices, refer to the System Requirements of the device for supported
connections.
T he Secure Gateway supports the use of digital certificates. As the security administrator, you need to decide whether or
not the communication links between the Secure Gateway and other servers in the DMZ or secure network need to be
encrypted. See Digital Certificates and the Secure Gateway.
Important: If you purchased server certificates from a commercial certificate authority (CA), support for root certificates
for most commercial CAs is built into Internet Explorer and Windows server products. If you obtained server certificates
from a private CA or commercial CA whose root certificates are not, by default, supported by the Windows operating
system, you must install matching root certificates on all user devices and servers connecting to secure servers.
Certificate Requirements f or a Single-Hop DMZ
If your secure network contains Citrix XenApp with the Secure Gateway in the DMZ, servers and clients need the following
certificates:
Root certificates on all user devices that connect to the server running the Secure Gateway.
Root certificates on every Secure Gateway component that connects to a secure server. For example, a root certificate
must be present on the server running the Secure Gateway to verify the server certificate installed on the server running
the ST A.
A server certificate on the server running the Secure Gateway.
Optional. A server certificate on the servers running the ST A. T he ST A is installed by default when you install Citrix
XenApp.
All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links
between the Secure Gateway and other servers in the DMZ or secure network be encrypted.
If your secure network contains Citrix XenApp with the Secure Gateway in the first DMZ, and the Secure Gateway Proxy
and the Web Interface in the second DMZ, servers and clients require the following certificates:
Root certificates on all user devices connecting to the server running the Secure Gateway.
Root certificates on every Secure Gateway server that connects to a secure server or Web server. For example, an
appropriate root certificate must be present on the server running the Secure Gateway to verify the server certificate
installed on the Citrix XenApp server.
A server certificate on the server running the Secure Gateway.
Optional. A server certificate on the server(s) running the Secure Gateway Proxy.
Optional. A server certificate on the server running the ST A.
If the Secure Gateway is in the DMZ, servers and clients need the following certificates:
Root certificates on all user devices that connect to the server running the Secure Gateway.
Root certificates on every Secure Gateway component that connects to a secure server. For example, a root certificate
must be present on the server running the Secure Gateway to verify the server certificate installed on the server running
the ST A.
A server certificate on the server running the Secure Gateway.
Optional. A server certificate on the servers running the ST A. T he ST A is installed by default when you install Citrix
XenApp.
All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links
between the Secure Gateway and other servers in the DMZ or secure network be encrypted.
WXYCo Inc. is an audit firm that recently purchased licenses for Citrix XenApp.
T he company’s employees are financial auditors who visit client sites and conduct financial audits. T hey use a proprietary,
client-server auditing software application, AuditorX. T hey publish AuditorX on computers running Citrix XenApp. T hey also
deploy the Web Interface for Web access to their published resources. Employees can access AuditorX and other published
resources through a Web browser on a user device connected to the LAN.
WXYCo realizes installing the Secure Gateway allows them to provide secure Internet access to published resources on its
server farms. Because the workforce is largely mobile, use of the Internet to connect to the enterprise network is expected
to reduce remote access costs dramatically.
T his figure illustrates a secure enterprise network separated from the Internet by a single-hop DMZ. T he enterprise
network contains a server farm including one server running Citrix XenApp with the Secure T icket Authority (STA). T he
firewall separating the secure network from the DMZ has ports 80, 443, and 1494 open. If session reliability is enabled, port
2598 is open on the internal firewall.
T he DMZ contains a single server running the Secure Gateway, and the Web Interface. Traffic to the Web Interface is
proxied through the Secure Gateway which communicates with the Web Interface using HT T P.
T he DMZ is separated from the Internet by a firewall that has port 443 open. T he mobile workforce carries notebook PCs
running a 32-bit Windows operating system, Internet Explorer 5.5, and the Citrix online plug-in for 32-bit Windows.
T he security analyst recommends securing the communication link between the Secure Gateway and the STA. To do this,
the company purchased two server certificates from a commercial certificate authority (CA). T he server running the Secure
Gateway and the Web Interface have root and server certificates installed. T he server running Citrix XenApp has a server
certificate installed. For more information about certificates, see Digital Certificates and the Secure Gateway.
Running the Web Interf ace behind the Secure Gateway in the Demilitarized Zone
In a single-hop DMZ deployment scenario, all incoming traffic is intercepted by the Secure Gateway. T he Web Interface can
be installed on the same server as Secure Gateway or on a separate server. All data exchanged between user devices and
the Web Interface is relayed through the Secure Gateway.
T he firewall facing the Internet has port 443 open. Users connect to the Secure Gateway using a URL such as
https://Secure Gateway FQDN/, where Secure Gateway FQDN is the fully qualified domain name for the server running the
Secure Gateway.
Advantages A single server certificate is required on the server running the Secure Gateway and the
Web Interface.
A single port, 443, must be opened on the firewall facing the Internet.
T he Web Interface cannot be contacted directly from the Internet and is more secure.
Smart Card Authentication. T he Secure Gateway negotiates the SSL handshake and
terminates the SSL connection before forwarding the client connection request to the
Web Interface. Smart card authentication integrated with the Web Interface is
unavailable because the Secure Gateway terminates the SSL connection before it
reaches the Web Interface.
Firewall and Proxy Settings Requiring Knowledge of the Client IP Address Are
Ineffective. All communication from the user device to the Web Interface is proxied
through the Secure Gateway. As a result, all client communications to the Web
Interface originate from the IP address of the server running the Secure Gateway.
T hough you can still configure firewall and proxy settings on the Web Interface for
specific client address prefixes, these settings must allow all client communications
through the Secure Gateway to have the Web Interface IP address. You will not be able
to distinguish between different user devices connecting through the Secure Gateway.
Citrix recommends deploying the Secure Gateway in this configuration if your network is small to medium sized, with a
usage profile of hundreds of users. T his type of deployment is optimal when users are connecting over the Internet to the
Secure Gateway.
All traffic to the server running the Web Interface is proxied through the server running the Secure Gateway. Lockdown
Internet Information Services (IIS) to allow only the Secure Gateway to communicate with the Web Interface.
For instructions about configuring IIS to explicitly grant or deny access to applications or Web sites, refer to the IIS
documentation that ships with your version of Microsoft Windows Server.
Running the Web Interf ace Parallel with the Secure Gateway
In this configuration, the Secure Gateway and the Web Interface are installed on separate servers. Users can connect
directly to the Web Interface.
Users connect directly to the Web Interface, using a URL such as https://Web Interface FQDN/citrix/AccessPlatform or
https://Web Interface FQDN/citrix/XenApp, where Web Interface FQDN is the fully qualified domain name for the server
running the Web Interface.
Citrix recommends securing both servers by installing a server certificate on each server running the Secure Gateway and the
Web Interface. Open port 443 on the firewall facing the Internet.
You want to use the features available with the Web Interface, including smart card authentication and firewall and proxy
settings that depend on knowing the client IP address.
Setting Up the Web Interf ace and the Secure Gateway in a Single-Hop Demilitarized Zone
In this scenario, the Web Interface and the Secure Gateway are hosted on the same server in the DMZ. Install and
configure the Web Interface before you install the Secure Gateway.
T he Secure Gateway is installed on the same server as the Web Interface in the DMZ.
T he Web Interface and the Secure Gateway Proxy are installed on separate servers in the second DMZ segment. T he
server farm is located in the secure network. T he firewall between the first and second DMZ segments has ports 80 and
443 open.
T he Secure Gateway, deployed in the first DMZ segment, is responsible for intercepting all incoming traffic. T he Web
Interface is responsible for user authentication and authorization. After authentication, the Secure Gateway Proxy is
responsible for relaying all data exchanged between the Secure Gateway and servers in the secure network. T he firewall
between the second DMZ segment and the secure network has ports 80, 443, and 1494 open.
Deploy the Secure Gateway in this configuration if your network contains a double-hop DMZ. A double-hop DMZ provides
additional protection because an attacker would need to penetrate multiple security zones to reach servers in the secure
network.
If the resources accessible through the Secure Gateway are extremely sensitive and require a high level of security, consider
this configuration.
If the Secure Gateway is in the first DMZ, the Secure Gateway Proxy is in the second DMZ, and the Web Interface is in the
second DMZ, servers and clients need the following certificates:
Root certificates on all user devices connecting to the server running the Secure Gateway.
Root certificates on every Secure Gateway component that connects to a secure server or Web server. For example, an
appropriate root certificate must be present on the server running the Secure Gateway to verify the server certificate
installed on the server running Citrix XenApp.
A server certificate on the server running the Secure Gateway.
Optional. A server certificate on the server(s) running the Secure Gateway Proxy.
Optional. A server certificate on the server running the ST A.
All Secure Gateway components support the use of digital certificates. Although not a requirement, Citrix recommends that
the communication links between the Secure Gateway and other servers in the DMZ or secure network be encrypted.
WXYCo, Inc. deployed the Web Interface for access to published resources hosted on Citrix XenApp servers. T he company
plans to deploy the Secure Gateway to provide secure Internet access to published resources.
T he security analyst recommended setting up a double-hop DMZ between the Internet and the company’s secure network
and securing communications between the Secure Gateway, the Web Interface, and the Secure Gateway Proxy.
T he second DMZ segment contains a server running the Secure Gateway Proxy and a second server running the Web
Interface. T he firewall separating the first and second DMZ segments has port 443 open. T he first DMZ segment contains
a single server running the Secure Gateway. All traffic originating from the Secure Gateway to servers in the secure network
is proxied through the Secure Gateway Proxy.
If the communications link between the Secure Gateway and the Secure Gateway Proxy is not secured, open port 1080 on
the firewall between the first DMZ segment and the second.
T he Secure Gateway communicates directly with the server running the Web Interface in the second DMZ segment, which
in turn communicates directly with servers in the secure network. T he first DMZ segment is separated from the Internet by
a firewall that has port 443 open.
T he mobile workforce carries notebook PCs running a 32-bit Windows operating system, Internet Explorer 5.5, and the
Citrix online plug-in for 32-bit Windows.
Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ
T he Secure Gateway is installed on a standalone server in the first DMZ. T he Secure Gateway Proxy is installed on a stand-
alone server in the second DMZ.
T he Web Interface needs to be set up on a Web server in the second DMZ segment. Ensure you complete the following
tasks before you install the Secure Gateway.
1. Install the Web Interface on a standalone server in the second DMZ segment.
2. T o secure communications between the Secure Gateway and the Web Interface, ensure you install a server certificate
on the server running the Web Interface.
3. Add and configure server farms for use with the Web Interface.
4. Configure the Secure Gateway using the FQDN of the ST A.
5. Use a Web browser on a user device to connect and log on to the Web Interface.
6. Verify that you can launch published applications.
Publishing the Web Address f or the Secure Gateway in a Double-Hop Demilitarized Zone
Because all traffic to the Web Interface is proxied through the Secure Gateway, users should type one of the following
where Secure Gateway FQDN is the fully qualified domain name for the server running the Secure Gateway.
In the case of WXYCo, the default Web address for the logon page or Web site is one of the following:
https://www.gateway01.wxyco.com/Citrix/AccessPlatform/
https://www.gateway01.wxyco.com/Citrix/XenApp
Alternatively, consider changing the default Web root directory in IIS on the server running the Web Interface to point to
the Web Interface directory. T his enables you to access the logon page or Web site by connecting directly to the root Web
address; that is, https://Secure Gateway FQDN/.
In this case, the Web address that employees of WXYCo use to access the logon page is:
https://www.gateway01.wxyco.com/
When Secure Gateway or Secure Gateway Proxy is installed on a supported 64-bit Windows operating systems, it installs in
the 32-bit application location by default.
Important: You must have access to administrative privileges to install and configure the Secure Gateway and use the
management tools. Disable User Account Control (UAC) while installing and configuring the Secure Gateway and Secure
Gateway Proxy.
Note: If Secure Gateway or Secure Gateway Proxy is already installed, disconnected all active sessions before reinstalling or
reconfiguring it. Otherwise, the Secure Gateway service might fail to restart.
Testing Your Deployment
After you complete installation and configuration of the Secure Gateway, test your deployment to make sure it works and
is accessible through the Internet.
You can also run the Secure Gateway Diagnostics tool to find a solution. T his utility contacts all servers running the Secure
Gateway components and generates a report containing configuration and status information for each component.
1. Use a Web browser on a user device to connect to the Secure Gateway; for example,
https://www.gateway01.wzyco.com/Citrix/AccessPlatform/ or https://Web Interface FQDN/Citrix/XenApp.
2. Log on using domain credentials. After a brief interval, the Applications page containing icons for published resources
appears.
3. Verify that you can launch published applications from this page.
You can upgrade from these versions of Secure Gateway or Secure Gateway Proxy:
Secure Gateway or Secure Gateway Proxy 3.2
Secure Gateway or Secure Gateway Proxy 3.1.4
Secure Gateway or Secure Gateway Proxy 3.1.3
Perform a fresh installation to migrate from these versions of Secure Gateway or Secure Gateway Proxy; upgrading is not
supported:
Secure Gateway or Secure Gateway Proxy 3.1
Secure Gateway or Secure Gateway Proxy 3.0.x
Secure Gateway or Secure Gateway Proxy 3.0
Using Firewall Sof tware with the Secure Gateway or Secure Gateway Proxy
T he firewall software included in your Microsoft Windows server operating system (such as Windows Firewall with
Advanced Security) where the Secure Gateway or Secure Gateway Proxy is used might not automatically allow access to
required ports. Non-Microsoft firewall software might also disallow port access by default.
Also, the Secure Gateway or Secure Gateway Proxy does not automatically create an exception to allow access to the
default SSL port 443, the default Secure Gateway Proxy port 1080, or any port number you select when configuring the
software.
Manually add or allow access to these ports to any firewall software you are using in your environment.
Installation Sequence
T he Secure Gateway installer installs the Secure Gateway or the Secure Gateway Proxy. When installation is complete, the
Secure Gateway Configuration wizard automatically starts so you can configure Secure Gateway.
Important: T he Secure Gateway is designed to discover and verify the existence of the other Citrix components during
configuration. For example, during configuration the Secure Gateway verifies that servers running the Web Interface and
the Secure T icket Authority (ST A), if used, are functional. If a required component is not found, the Secure Gateway may
fail to start. Ensure that you follow the recommended installation sequence.
T he installation sequence must be in this order:
T he Secure Gateway Configuration wizard guides you through the process of specifying configuration parameters for the
Secure Gateway. Each dialog box includes context-sensitive Help so that you can obtain additional information specific to
the parameters you are configuring. Click Help within any dialog box to access the context-sensitive Help.
You can access the Secure Gateway Configuration wizard from the Secure Gateway Management Console node in this
console. You can also access the Secure Gateway Configuration wizard or the Secure Gateway Proxy Configuration wizard
from All Programs in the Start menu of the server running the service or proxy. Running the Secure Gateway Configuration
Wizard requires administrative privileges.
Software updates to XenApp 6.5 and to Secure Gateway 3.3 are available that introduce support for Versions 1.1 and 1.2 of
the Transport Layer Security (T LS) protocol. To upgrade your XenApp and/or Secure Gateway deployments, download and
apply the following software updates:
T he Secure Gateway Configuration or Secure Gateway Proxy Configuration wizard automatically starts when the
installation is complete. T he wizard guides you through configuration tasks and provides context-sensitive help describing
the procedures and information you need to enter.
Configuring the Secure Gateway for use with Citrix XenApp requires the following information:
If you need to start the configuration wizard manually (for instance, to change the configuration at any time after initial
installation and configuration), perform the following steps.
To specify a configuration level for Secure Gateway, select one of the following to access the parameters available for
modification during the configuration process:
Standard
Includes only the minimum set of parameters required to configure the Secure Gateway. T he Secure Gateway
Configuration wizard sets all remaining parameters to their default values, respectively.
1. Select one of the following to access the parameters available for modification during the configuration process:
Standard
Includes only the minimum set of parameters required to configure the Secure Gateway Proxy. T he Secure Gateway
Proxy Configuration wizard sets all remaining parameters to their default values, respectively.
Advanced
Includes all of the Secure Gateway Proxy’s configurable parameters, for example, supported secure protocols and
logging exclusions.
2. Select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option to secure communications
between the Secure Gateway and the Secure Gateway Proxy servers using SSL or T LS
Select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option to secure communications
between the Secure Gateway and the Secure Gateway Proxy servers using SSL or T LS
Install a server certificate on the server running the Secure Gateway Proxy
Install a client certificate on the Secure Gateway
T he task summary when selecting the advanced or standard configuration type is as follows:
T he task summary when selecting the advanced or standard configuration type is as follows:
T o add the Secure T icket Authority details Not available Not available
Server certificates enable user devices to verify the identity of the server running the Secure Gateway.
Note: T his option is not displayed when you are installing the Secure Gateway Proxy and you select the Secure traffic
between the Secure Gateway and Secure Gateway Proxy option.
1. Select a valid server certificate installed on the computer running Secure Gateway or Secure Gateway Proxy from the
Certificates Found menu.
2. Click View to display the details of the selected certificate.
T his configuration dialog appears if you selected Advanced for the Secure Gateway’s configuration level. Select the secure
protocol and cipher suite used to secure the data transmitted between the Secure Gateway and the user device or Secure
Gateway Proxy.
Note: When deployed in proxy mode, the Secure Gateway Proxy’s client is the Secure Gateway. However, when deployed in
Configure the Secure Gateway to use only T LS v1.2 as the secure protocol. If you select this option, the version of Citrix
Receiver installed on all user devices must support T LS v1.2.
Configure the Secure Gateway for T LS v1.0 as the secure protocol. T his option is provided for compatibility with earlier
Citrix Receiver versions. Use this option while upgrading Citrix Receiver to the latest version that supports T LS v1.2.
Configure the Secure Gateway and Secure Gateway Proxy to use SSL 3.0 and T LS v1.0 as its secure protocols. T his
option is provided for compatibility with earlier Citrix Receiver versions. Use this option while upgrading Citrix Receiver to
the latest version that supports T LS v1.2. T his option is not recommended as the SSL protocol is less secure than the T LS
protocol.
Note: If a user device supports both the SSL and T LS protocols, T LS is used to secure the data transmitted between the
Secure Gateway/Secure Gateway Proxy and Citrix Receiver.
GOV
T his choice enables the Secure Gateway/Secure Gateway Proxy to use the following ciphersuites:
RSA_WIT H_AES_256_GCM_SHA384 *
RSA_WIT H_AES_256_CBC_SHA
RSA_WIT H_3DES_EDE_CBC_SHA
COM
T his choice enables the Secure Gateway/Secure Gateway Proxy to use the following ciphersuites:
RSA_WIT H_AES_128_GCM_SHA384 *
RSA_WIT H_AES_128_CBC_SHA
RSA_WIT H_RC4_128_SHA
RSA_WIT H_RC4_128_MD5
T his choice enables the Secure Gateway/Secure Gateway Proxy to use ciphersuites in both the GOV and COM lists.
Note: T he ciphersuite actually negotiated for a particular connection also depends on ciphersuites supported at the user
device.
Specify the IP addresses and TCP ports that you want the Secure Gateway/Secure Gateway Proxy to monitor for
incoming connections.
1. Select each Monitor all IP addresses check box to configure the Secure Gateway to listen for connections on all
available IPv4 or IPv6 addresses.
T his option is useful when configuring the Secure Gateway/Secure Gateway Proxy on a server using multiple network
interface cards (NICs). When configured in proxy mode, the Secure Gateway Proxy listens on all available IP addresses for
Secure Gateway connections. When configured for relay mode, the Secure Gateway Proxy listens on all available IP
addresses for client connections.
3. Clear the Monitor all IP addresses check boxes to configure the Secure Gateway/Secure Gateway Proxy to listen on
one or more specific IP addresses. T hen click Add to add one or more IP addresses and related T CP port address.
Typically, you would exclude dynamic IP addresses. When a dynamic IP address changes, new connections are not accepted
on that address and the service can fail to start when the server is restarted.
Options Description
No outbound traffic restrictions Select this option to enable the Secure Gateway/Secure Gateway Proxy to
establish connections to any server within the DMZ or secure network. Click
Next to continue.
Use the Secure Gateway Proxy T his option is not available when configuring the Secure Gateway Proxy. Select
this option when configuring the Secure Gateway in a double-hop environment.
Select the Secure traffic between the Secure Gateway and the Secure
Gateway Proxy check box to use HT T PS to secure communications between
them.
Use an Access Control List (ACL) Select this option to create an access control list for the Secure
Note: In a double-hop DMZ, configure outbound access control lists on the Secure Gateway Proxy server only.
To configure servers running the Secure Gateway Proxy:
1. From the Configure outbound connections dialog window, select Use the Secure Gateway Proxy radio button and click
Configure.
2. Click Add.
3. T ype the fully qualified domain name (FQDN) or IP addresses and T CP port of the Secure Gateway Proxy servers to
which you want the Secure Gateway server to connect. T he default T CP port for unsecured communications between
the Secure Gateway and the Secure Gateway Proxy is 1080. T he default T CP port for secure communications between
the Secure Gateway and Secure Gateway Proxy is 443.
4. Click OK.
5. Select the Secure traffic between the Secure Gateway and Secure Gateway Proxy option to secure communications
between the Secure Gateway and the Secure Gateway Proxy servers using SSL or T LS.
When this option is not selected, the connection between the Secure Gateway and Secure Gateway Proxy is not
secured. To secure traffic between the Secure Gateway and Secure Gateway Proxy you must also:
Install a server certificate on the server running the Secure Gateway Proxy
Install a client certificate on the Secure Gateway
You do not need to include servers running the Secure T icket Authority because these are configured elsewhere in the
wizard.
1. Select the Use an Access Control List (ACL) button, click Configure, and then click Add.
2. If you select the IP Address Range option, type or select the following information:
Option Description
Start address Enter the IP address of a server that you want to add to the outbound access
control list. When specifying an IP address range, enter the range’s start IP address.
If you use an IP address range for multiple servers running XenApp, be sure that the
servers you specify offer the full range of applications that you want to be
available.
End address Leave this field blank if you are creating an entry for a single server. Otherwise,
enter the end address of the range.
T CP port Enter the T CP port used by the server(s). T o allow connections to any port on a
server you can use the wild card asterisk character (*) in the T CP port field. You can
use this wild card to allow one ACL entry for a range of IP addresses to permit
connections using the ICA and Common Gateway Protocol (CGP) protocols.
Use default port Select this option to use the default port used by the server for the protocol
CGP Select this option to allow CGP connections to the selected servers. T ypically, you
would use CGP for servers running Citrix XenApp that accept CGP connections. CGP
can provide session reliability if you enable session reliability on the selected servers.
T o allow CGP as well as ICA/SOCKS connections to the same servers, add a
separate entry for each protocol. T his option is not available to the Secure
Gateway Proxy.
3. If you select the Server FQDN option, type or select the following information:
Options Description
FQDN Enter the fully qualified domain name of the server to which the Secure
Gateway Proxy allows access.
T CP port Enter the T CP port used by the server. T o allow connections to any port on a
server, you can use the wild card asterisk character (*) in the T CP port field.
Secure traffic between the server Select this option to secure communications between the server and the
and the Secure Gateway Proxy Secure Gateway Proxy servers using SSL or T LS. When this option is not
selected, the connection is not secured.
4. Click OK, then click Add to add another connection, or click OK to close the dialog box.
You can configure the Secure Gateway to contact multiple STAs for failover protection. If you specify multiple STAs, be
sure that this list matches the list of STAs that the Web Interface is configured to contact.
Option Description
FQDN Enter the fully qualified domain name of the server running the ST A.
Path T his field is populated automatically with the default virtual directory path,
/Scripts/CtxST A.dll or CitrixAuthService/AuthService.asmx. If you changed the
default path when you configured the Citrix XML Service to share a port with
Internet Information Services on the server running Citrix XenApp, enter the correct
path.
ID T his field is populated automatically by the Secure Gateway when it resolves the
specified FQDN and reads the ID string from the server running the ST A. If the
Secure Gateway is unable to resolve the address specified you are prompted to
enter the ID for the ST A. T he ID for the ST A is a randomly generated string. You
T CP port Enter a network port number used by the Secure Gateway to contact the ST A.
Use default Select this option to use the default port assignment for the ST A. T he default T CP
port for unsecured communications between the Secure Gateway and the ST A is
80. T he default T CP port for secure communications between the Secure Gateway
and ST A is 443.
You can configure how connection requests time out. Preventing requests from timing out may be useful if your network
has periods of high latency. However, uncompleted connection requests that do not time out, or time out slowly, can
preempt additional connections through the Secure Gateway. T he number of connections the Secure Gateway server can
support depends on the server processor, usage, and limits set in the Concurrent Connection Limits section.
Option Description
No connection timeout Select this option if you do not want to limit the time in which Secure Gateway
must complete a connection request. Do not select this option if typical usage
behavior can result in so many uncompleted connection requests that the server
stops accepting connection requests.
Connection timeout (seconds) Set the interval of time in which the Secure Gateway can complete a connection
request. If the connection is not established by the time the specified value
elapses, then the connection times out. By default, the connection timeout value
is configured for 100 seconds.
Concurrent Connection Limits T his option is not available for the Secure Gateway Proxy. Set the following values
using numbers suitable to your environment. Consider processor type and processor
speed as well as typical usage behavior. Failure to do so may overload the
processor and result in a poor quality of service for your end users.
Unlimited. Select this option to configure the Secure Gateway to support up to
1,920 concurrent client connections (250 connections are allocated to HT T P/S
by default, leaving 1,670 ICA/CGP connections, including MAPI over CGP
connections). T he Secure Gateway stops accepting new connection requests if
the number of concurrent client connections reaches 1,920. T his setting
overrides the value entered in Maximum connections.
Maximum Connections. Specify the maximum number of concurrent ICA/CGP
connections supported by the Secure Gateway. T he Secure Gateway stops
accepting new ICA/CGP connection requests when the number of concurrent
connections equals the value entered in this field.
Typically, third-party network devices such as load balancers generate extraneous Secure Gateway log information. For
example, load balancers might poll the Secure Gateway repeatedly to ensure that the server is active. Each poll is recorded
by the Secure Gateway as a connection, resulting in the event log containing several unnecessary entries.
T he Secure Gateway and the Secure Gateway Proxy generate their own log files. T herefore, if you deployed the Secure
Gateway in proxy mode, you must configure each component’s logging exclusions separately.
1. Click Add to enter the IP address of a network device that you want the Secure Gateway to exclude from its logging
operations.
2. After typing the IP address, click OK.
T he Web Interface works with the Secure Gateway to provide a logon interface, and facilitates the authentication and
authorization of connection requests to server farms.
Running the Secure Gateway and the Web Interface on a single server is supported only in a single-hop DMZ environment.
Indirect
To access the Web Interface, users enter the URL of the Secure Gateway. Users connect to the Secure Gateway,
which routes the request to the Web Interface. If the Web Interface is installed on the same computer as the Secure
Gateway, select the Installed on this computer check box (this option is not available in a double-hop environment).
If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to
the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the
Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP
address, and one server.
Direct
If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to
the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the
Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP
address, and one server.
2. If you do not select the Installed on this computer check box, type or select the following information in the Details
area:
FQDN
Enter the fully qualified domain name of the server running the Web Interface. If you selected Installed on this
computer, this field is automatically populated with the value localhost.
TCP port
Enter the port number the Secure Gateway should use when communicating with the Web Interface.
3. Select the Secure traffic between the Web Interface check box to configure the Secure Gateway to use HT T PS when
1. Specify the type of errors and events that the Secure Gateway/Secure Gateway Proxy writes to the event log and
Event Viewer. T he logging levels available include the following:
2. Click Next.
You must start or restart the Secure Gateway/Secure Gateway Proxy to use the new configuration settings. If the Secure
Gateway/Secure Gateway Proxy is already running, restarting it disconnects all active sessions. To avoid disconnecting
active user sessions, you can clear the Restart Secure Gateway Proxy check box.
Select Start the Secure Gateway or Start the Secure Gateway Proxy and click Finish.
Note: If a client is connected to the Secure Gateway and the Secure Gateway is restarted, the Secure Gateway does
not generate service stop and service start event log messages. If a client is not connected and the Secure Gateway is
restarted, Secure Gateway does generate these messages.
You can access the Secure Gateway Management Console from the Citrix program menu on the Start menu. You can start,
stop, and restart the Secure Gateway using the icons available on the console toolbar. In addition, the Secure Gateway
Management Console displays the following information:
Session and connection information for the Web Interface that is currently running through the Secure Gateway. T he
sessions for the Web Interface have one connection for one session.
An instance of the Windows Performance Monitor containing performance statistics applicable to the Secure Gateway.
Review this list to obtain detailed information regarding the status of client connections running through the Secure
Gateway.
T he following statistics are available for all active sessions running through the Secure Gateway:
Statistic Description
Domain T he network domain from which the current user is logged on.
T ime Elapsed T he amount of time, in seconds, that elapsed since this connection was
established.
1. From the Session Information pane, right-click the active session you want to disconnect and select All T asks >
Disconnect.
2. Right-click and select All T asks - Disconnect.
1. From the Session Information pane, right-click any session entry and select All T asks > Freeze Display.
2. From the Session Information pane, right-click any session entry and select All T asks > Resume Display.
T he Secure Gateway includes a customized Windows System Monitor containing real-time performance statistics, or
counters, for the Secure Gateway. You can use this monitor to evaluate and troubleshoot connections running through the
Secure Gateway.
Understand the workload on the Secure Gateway and the corresponding effect it has on system resources
Observe changes and trends in workloads and resource usage so you can plan system sizing and failover
T est changes in configuration or other tuning efforts by monitoring the results
Diagnose problems and target components or processes for optimization
Performance statistics include the data throughput rate in bytes per second across CGP, HT T P/S, SOCKS, and total client
connections through Secure Gateway. T he "Successful" counters indicate the number of users’ connections that have
successfully completed since the Secure Gateway service was last started. Users can have multiple connections within each
session. T he “Active” counters indicate the number of active connections going through the Secure Gateway.
T he Secure Gateway System Monitor takes advantage of several of the features included in the Windows System Monitor,
including customizing the display of counter information and saving counter data. You can use the System Monitor icons at
the top of the pane or shortcut keys to customize the display. For a list of the shortcut keys, see the Windows System
Monitor help. You can display the Windows Performance monitor from the Secure Gateway Management Console.
Citrix recommends that you monitor performance of the Secure Gateway as part of your administrative routine.
You can use the Secure Gateway performance statistics to troubleshoot connections to the Secure Gateway. For example:
T he Secure Gateway processor load might be too high because too many users are connected to the Secure Gateway
server. You can look at the total active connections to check how many users are connected.
Users might not be able to launch their published applications because the Secure Gateway cannot connect to the
XenApp servers. T he failed “Backend” connections counter is high if this is the problem.
Bytes/Sec from Client T he data throughput rate (bytes per second) from all connected
clients to the Secure Gateway.
Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients.
CGP Active Connections T he total number of CGP client connections currently active.
CGP Bytes/Sec from Client T he data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the CGP protocol.
CGP Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients using the CGP protocol.
CGP Kilobytes from Client T he total number of kilobytes sent from all clients connected to the
Secure Gateway using the CGP protocol.
CGP Kilobytes to Client T he total number of kilobytes sent from the Secure Gateway to all
clients connected using the CGP protocol.
CGP Peak Bytes/Sec from Client T he highest data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the CGP protocol.
CGP Peak Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients using the CGP protocol.
Client Connect T ime: Average (in ms) T he average amount of time (in milliseconds) for a client connection
request to complete the connection process.
Client Connect T ime: Longest (in ms) T he longest amount of time (in milliseconds) for a client connection
request to complete successfully.
Connections: T otal Successful T he total number of successful client connections. It is the sum of all
successful connections for all protocols: CGP, HT T P/S, and SOCKS.
Connections:Pending T otal number of client connection requests accepted, but not yet
completed, by the Secure Gateway. Pending connections are still
active and have not timed out or failed.
Failed Backend Connections T he total number of backend connections that failed. Clients that
successfully connect to the Secure Gateway may not successfully
connect to backend servers, such as a Web server. T hese connections
are not counted as part of the failed client connection count.
Failed Connections: Client T imed Out T he total number of client connection requests that were accepted
but timed out before completing the protocol handshake.
Failed Connections: General Client Error T he total number of client connection requests that failed to
connect to the Secure Gateway for any reason other than timing
out or SSL handshake error.
Failed Connections: SSL Client Handshake Error T he total number of client connection requests that were accepted
but did not successfully complete the SSL handshake.
Failed Connections: T otal Client T he total number of failed client connection requests. It is the sum
of the Failed Connections (T imed Out), Failed Connections (SSL Error),
and Failed Connections (General Client Error) counters.
HT T P/S Bytes/Sec from Client T he data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the HT T P/S protocol.
HT T P/S Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients using the HT T P/S protocol.
HT T P/S Kilobytes from Client T he total number of kilobytes sent from all clients connected to the
Secure Gateway using the HT T P/S protocol.
HT T P/S Kilobytes to Client T he total number of kilobytes sent from all connected clients to the
Secure Gateway using the HT T PS protocol.
HT T P/S Peak Bytes/Sec from Client T he highest data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the HT T P/S protocol.
HT T P/S Peak Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Kilobytes from Client T he total number of kilobytes sent from all connected clients to the
Secure Gateway.
Kilobytes to Client T he total number of kilobytes sent from the Secure Gateway to all
connected clients.
Peak Bytes/Sec from Client T he highest data throughput rate (bytes per second) from all
connected clients to the Secure Gateway.
Peak Bytes/Sec to Client T he highest data throughput rate (bytes per second) from the Secure
Gateway to all connected clients.
SOCKS Active Connections T he total number of SOCKS client connections currently active.
SOCKS Bytes/Sec from Client T he data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the SOCKS protocol.
SOCKS Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients using the SOCKS protocol.
SOCKS Kilobytes from Client T he total number of kilobytes sent from all clients connected to the
Secure Gateway using the SOCKS protocol.
SOCKS Kilobytes to Client T he total number of kilobytes sent from all connected clients to the
Secure Gateway using the SOCKS protocol.
SOCKS Peak Bytes/Sec from Client T he highest data throughput rate (bytes per second) from all clients
connected to the Secure Gateway using the SOCKS protocol.
SOCKS Peak Bytes/Sec to Client T he data throughput rate (bytes per second) from the Secure
Gateway to all connected clients using the SOCKS protocol.
SSL Handshake T ime: Average Average length of time (in milliseconds) for an SSL handshake to
complete.
SSL Handshake T ime: Longest Length of time (in milliseconds) for the longest SSL handshake to
complete.
SSL Handshakes/Sec: Peak Highest number of successful SSL handshakes per second.
SSL Handshakes: T otal T otal number of SSL handshakes that completed successfully
between a client and the Secure Gateway.
To launch the Secure Gateway Diagnostics tools, click Secure Gateway Diagnostics from the Administration Tools found in
the Citrix program group or from the Secure Gateway Management Console on the Start menu.
T he diagnostics tool scans the registry and reports global settings for the Secure Gateway. It uses the Secure Gateway
configuration information to contact servers running the Web Interface, the Secure Gateway Proxy, and the STA, and
reports whether or not the communication check passed or failed. It examines the server certificate installed on the server
running the Secure Gateway and checks credentials and validity.
In the Secure Gateway Diagnostics window, information icons indicate that a registry or configuration value is present:
For any component marked with a warning or failed check icon, verify that you properly installed the component and
provided all necessary configuration information.
Event logging allows administrators and Citrix support representatives to diagnose problems with the Secure Gateway.
T he Secure Gateway Event Viewer is a customized Windows Event Viewer that displays errors and events generated by the
Secure Gateway. T he error messages include:
Status
Messages of normal operational events, such as starting or stopping the Secure Gateway.
Fatal
T he Secure Gateway error messages can be viewed using Windows Event Viewer.
If a client is connected to the Secure Gateway and the Secure Gateway is restarted, the Secure Gateway does not
generate service stop and service start event log messages. If a client is not connected and the Secure Gateway is
restarted, Secure Gateway does generate these messages.
T he access logs generated by the Secure Gateway service record connection information. For the Secure Gateway, the
access logs record HT T P, SOCKS, and CGP connection information. T he Secure Gateway Proxy access log records SOCKS
connections. Each access log provides specific information regarding connections.
3. Open the log file with an ASCII text editor such as Notepad.
T his configuration does not make Secure Gateway sessions fault tolerant, but provides an alternative server if one server
fails.
When the number of concurrent sessions exceeds the capacity of a single server running the Secure Gateway, multiple
servers running the Secure Gateway must be deployed to support the load. T here is no practical limit to the number of
servers running the Secure Gateway that can be deployed to service large server farms.
To deploy multiple servers running the Secure Gateway, a load balancer is required. T he function of the load balancer is to
distribute client sessions to one of a number of servers offering a service. T his is normally done by implementing a virtual
address on the load balancer for a particular service and maintaining a list of servers offering the service. When a client
connects to a service, the load balancer uses one of a number of algorithms to select a server from the list and directs the
client to the selected server.
T he algorithm can be as simple as a “round robin” where each client connect request is assigned to the next server in a
circular list of servers, or a more elaborate algorithm based on server load and response times.
T he client response to a server failure depends on which server fails and at what point in the session the server fails. Types
of server failure include:
Intelligent load balancers can detect the failure of a server through server polling, temporarily remove the failed server from
the list of available servers, and restore them to the list when they come back online.
Load balancing relies on the use of a virtual IP address. T he virtual IP address is bound to an FQDN and all clients request
connections from the virtual IP address rather than the individual servers running the Secure Gateway behind it. A single IP
address, the virtual IP, acts as an entry point to your servers running the Secure Gateway, simplifying the way clients access
Web content, published applications, and services on computers running Citrix XenApp.
If you are using a load balancing solution, all servers running the Secure Gateway can be accessed using a common FQDN;
for example, csgwy.company.com.
T he benefits of load balancing across multiple servers running the Secure Gateway include:
Scalability
Optimize the Secure Gateway performance by distributing its client requests across multiple servers within the array. As
traffic increases, additional servers are added to the array. T he load balancing solution used imposes the only restriction to
the maximum number of servers running the Secure Gateway in such an array.
High availability
Load balancing provides high availability by automatically detecting the failure of a server running the Secure Gateway and
redistributing client traffic among the remaining servers within a matter of seconds.
Load balancing an array of servers running the Secure Gateway is accomplished using a virtual IP address that is dynamically
mapped to one of the real IP addresses (for example, 10.4.13.10, 10.4.13.11 and 10.4.13.12) of a server running the Secure
Gateway. If you use a virtual IP address such as 10.4.13.15, all your requests are directed to the virtual IP address and then
routed to one of the servers. You can set up the virtual IP address through software, such as Windows NT Load Balancing
Service, or hardware solutions, such as a Cisco CSS 11000 Series Content Services switch. If you use hardware in a
production environment, make sure to use two such devices to avoid a single point of failure.
You can load balance an array of servers running the Secure Gateway Proxy in the same way as the Secure Gateway.
Instead of using an external load balancer, the Secure Gateway Proxy has built-in support for load balancing.
T his is useful in situations where you experience extremely high loads on the Secure Gateway array. In this case, it might
help to deploy a second Secure Gateway Proxy and load balance the two servers.
In addition, if the communications link between the Secure Gateway and the Secure Gateway Proxy is secured, you can use
a single certificate for the Secure Gateway Proxy array.
Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers
Load balancing solutions available in the market today may feature built-in SSL accelerator cards. If you are using such a
solution to load balance an array of servers running the Secure Gateway, disable the SSL acceleration for traffic directed at
the servers running the Secure Gateway. Consult the load balancer documentation for details about how to do this.
Presence of SSL accelerator cards in the network path before the server running the Secure Gateway means the data
arriving at the Secure Gateway is decrypted. T his conflicts with a basic function of the Secure Gateway, which is to decrypt
SSL data before sending it to a Citrix XenApp server. T he Secure Gateway does not expect non– SSL traffic and drops the
connection.
In an environment containing the Secure Gateway, ICA and HT T P/S connections are routed through the Secure Gateway.
TCP/IP keep-alive messages from the Citrix XenApp server to the remote client are intercepted, and responded to, by the
server running the Secure Gateway. Similarly, TCP/IP keep-alive packets from the server running the Secure Gateway are
sent only to the user device; the server running the Secure Gateway does not transmit keep-alives to the Citrix XenApp
server. Setting the keep-alive values on the server running the Secure Gateway to match the values set on the Citrix XenApp
server ensures that the server farm is aware of the client connection state and can either disconnect or log off from the
connection in a timely manner.
T he Secure Gateway establishes connections over the Internet between remote clients and Citrix XenApp servers. When a
client connection is dropped without being properly logged off, the Secure Gateway continues to keep the connection to
the server open. Accumulation of such “ghost” connections eventually affects Secure Gateway performance.
A Secure Gateway deployment subject to a heavy load may run out of sockets because of these “ghost” connections
remaining open. T he Secure Gateway uses TCP/IP keep-alives to detect and close broken connections between the Secure
Gateway and the client device. T he default Windows setting for KeepAliveT ime is two hours. T his is the duration that
TCP/IP waits before verifying whether or not an idle connection is still connected. “Ghost” connections may therefore
remain open for up to two hours before the system detects that a connection failed.
To prevent broken connections from remaining open, the Secure Gateway changes the KeepAliveT ime to one minute. If a
connection is dropped, the Secure Gateway knows within one minute, instead of two hours.
If there is no response, TCP/IP retries the verification process after the interval specified by KeepAliveInterval and for a
maximum number of times specified by TcpMaxDataRetransmissions. T he default value for KeepAliveInterval is one second
and the default value for TcpMaxDataRetransmissions is five seconds.
If the Secure Gateway is under a heavy load and is used predominately to secure HT T P connections to internal Web
servers, the Secure Gateway rapidly opens and closes connections. Closed connections stay in the T IME_WAIT state for an
interval specified by TcpT imedWaitDelay.
T he default value of TcpT imedWaitDelay is four minutes; the Secure Gateway sets this value to 30 seconds. T his change
enables the Secure Gateway to recycle sockets faster resulting in improved performance. T he system cannot reuse sockets
in the T IME_WAIT state. MaxUserPort specifies the number of sockets available on the system. By default, the system uses
ports between 1024 and 5000; the Secure Gateway modifies this setting to use ports between 1024 and 65000.
T he KeepAliveInterval, KeepAliveT ime, MaxUserPort, TcpMaxDataRetransmissions, and TcpT imedWaitDelay parameters are
stored in the Windows registry at:
Note: T he Secure Gateway is an application– specific proxy designed to achieve a corresponding level of security. It is not a
firewall and should not be used as such. Citrix recommends that you use a firewall to protect servers running the Secure
Gateway, Citrix XenApp, and other corporate resources from unauthorized access from the Internet and internal users.
Preventing Indexing by Search Engines
Search engines use a program that automatically retrieves Web pages and indexes the pages. T his includes pages hosted on
the Secure Gateway that might potentially be sensitive.
Use a global file (robots.txt) to prevent indexing by most search engines. Install it at the root of the Web server, such as
sg.customer.com/robots.txt. T he content of robots.txt is:
User-agent: *
Disallow: /
T he process of establishing a secure connection involves negotiating the ciphersuite that is used during communications. A
ciphersuite defines the type of encryption that is used— it defines the cipher algorithm and its parameters, such as the size
of the keys.
Negotiation of the ciphersuite involves the user device informing the Secure Gateway which ciphersuites it is capable of
handling, and the Secure Gateway informing the client which ciphersuite to use for client-server communications.
T he Secure Gateway supports two main categories of ciphersuite: COM (commercial) and GOV (government). T he ALL
option includes both the commercial and government suites.
Some organizations, including U.S. government organizations, require the use of government-approved cryptography to
protect sensitive but unclassified data.
You must restart the Secure Gateway to let configuration changes take effect.
T he ciphersuites used to secure communications between the Secure Gateway and the Secure Gateway Proxy are
determined by the configuration settings on the server running the Secure Gateway Proxy. T he default setting on the
Secure Gateway for outgoing connections to the Secure Gateway Proxy is set to use all ciphersuites.
Security policies of some organizations may require tighter control of the ciphersuites offered by the Secure Gateway for
outgoing connections to the Secure Gateway Proxy. T his is achieved by modifying the SChannel registry settings.
For instructions about modifying the SChannel registry settings to restrict ciphersuites, refer to the Microsoft Knowledge
Base Article Q245030, “How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll.”
T he Secure Gateway handles both SSL Version 3 and T LS Version 1 protocols. In this context:
You can restrict the Secure Gateway to accept only SSL Version 3 or T LS Version 1 connections. If you decide to change
the default protocol setting on the Secure Gateway, modify protocol settings on the client Web browser as well as the
Gateway Client to match the protocol setting on the server running the Secure Gateway.
Citrix recommends against changing the default setting for the secure protocol used by the Secure Gateway.
Citrix recommends removing all unnecessary user accounts on servers running the Secure Gateway.
Avoid creating multiple user accounts on servers running the Secure Gateway and limit the file access privileges granted to
each account. Review active user accounts regularly and when personnel leave.
An important security step is to disable or remove all sample Web applications installed by the Internet Information Services
(IIS). Never install sample sites on production servers because of the many well-identified security risks they present. Some
sample Web applications are installed so that you can access them only from http://localhost or the IP address 127.0.0.1.
Nevertheless, you should remove the sample sites. T he IISSamples, IISHelp, and Data Access virtual directories and their
associated folders are good examples of sample sites that should not reside on production servers.
To ensure that security of the Secure Gateway components is not compromised, you can do the following:
Set appropriate ACLs on IIS to prevent unauthorized access to executable and script files. For instructions about locking
down IIS, refer to current Microsoft product documentation and online resources available from the Microsoft Web site.
Secure all the Secure Gateway components using SSL or T LS to ensure that data communications between all the
Secure Gateway components is encrypted.
To maximize the security of the servers running the Secure Gateway components hosted by IIS, follow Microsoft security
Windows services introduce vulnerabilities to the computer. If a Windows service is not required by your organization, Citrix
recommends that the service be disabled. For a complete list of services and their functions, see the
— Threats and Countermeasures Guide
on the Microsoft Web site. Note that disabling a Windows service could stop the computer from functioning correctly.
Ensure that you install all operating system-specific service packs and hotfixes, including those applicable to applications
and services that you are running on the system.
Ensure you do not install hotfixes for services that are not installed. Ensure you regularly review Security Bulletins from
Microsoft.
Citrix recommends that you review Microsoft guidelines for securing Windows servers.
In general, refer to the Microsoft Web site for current guidance to help you understand and implement the processes and
decisions that must be made to get, and stay, secure.
Run the Secure Gateway Diagnostics tool on the server running the Secure Gateway and examine the results reported. T he
report contains configuration values for the Secure Gateway and results of connection attempts to components and
services in the DMZ and secure network that the Secure Gateway uses.
For instructions about using the Secure Gateway Diagnostics tool, see Generating the Secure Gateway Diagnostics Report.
Careful review of the Secure Gateway event log can help you identify the sources of system problems. For example, if log
warnings show that the Secure Gateway failed because it could not locate the specified certificate, you can conclude that
the certificate is missing or installed in the incorrect certificate store. In general, information in the event log helps you trace
a record of activity leading up to the event of failure.
If you receive an error: T he Secure Gateway Fails with a CSG0188 Error, the error implies that SChannel could not validate
certificate credentials of the server certificate used by the Secure Gateway. Ensure that the certificate installed was issued
by a trusted source, is still valid, and is issued for the correct computer.
For more troubleshooting information, see the Citrix support Web site at http://support.citrix.com/ for technical support
options.
Client Connections Launched f rom IP Addresses in the Logging Exclusions List Fail
For security reasons, IP addresses configured in the logging exclusions list are not allowed to establish connections to the
Secure Gateway. T his measure blocks connections to the Secure Gateway that do not leave an audit trail.
T he logging exclusions list is designed to help keep the system log free of redundant data. Configure the IP address of load
balancing devices in the Logging Exclusions list. Configuring an exclusions list enables the Secure Gateway to ignore polling
activity from such devices and keeps the log free of this type of data.
Some load balancers stop reporting active client connections flowing through them if the connections are idle for a while
because of the way in which certain load balancers treat idle connections.
Connections that are idle for a certain amount of time stop being represented as active connections in the load balancer’s
reporting tools even though the connections are still valid.
Resolve this issue by modifying the keep– alive settings in the Windows registry on the server(s) running the Secure
Gateway.
If you load balance an array of servers running the Secure Gateway, decrease the keep– alive values to force packets to be
sent after a period of session inactivity.
Perf ormance Issues with Transf erring Files Between a User Device and a Citrix XenApp Server
Users may experience performance issues with data transfer using client drive mapping on high bandwidth, high latency
connections.
As a workaround, you can optimize throughput by increasing the value of TcpWindowSize in the Windows registry of your
server running the Secure Gateway.
Caution: Using the Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating
system. Citrix cannot guarantee resolution of problems resulting from the incorrect use of Registry Editor. Use Registry
Editor at your own risk.
To modify this setting, edit the following Windows Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\TcpWindowSize
Be aware that this change incurs higher system memory usage. Citrix recommends increasing physical system memory on
the server running the Secure Gateway to suit the typical usage profile of the network.
Windows XP Service Pack 2 prevents connections to all IP addresses that are in the loopback address range except for
127.0.0.1. If the Gateway Client is using a loopback address other than 127.0.0.1, the connection to the Secure Gateway
fails.
Microsoft provides a patch to fix this issue. For more information, refer to the Microsoft Knowledgebase Article “Programs
that connect to IP addresses that in the loopback address range may not work as you expect in Windows XP Service Pack
2 (884020)” available from the Microsoft Support Web site at http://support.microsoft.com/.
Failed Client Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log
You may find duplicate entries for client connection attempts in the Secure Gateway application and performance logs.
Duplicate entries can occur in the following situations:
SSL protocol mismatch between the user device and the server running the Secure Gateway
Client automatically attempts to reconnect if the first connection attempts fails
T he log entries are actually a record of client behavior. In these cases, the client attempts to reconnect if it fails the first
Placing the Secure Gateway Behind a Reverse Web Proxy Causes an SSL Error 4
If the Web Interface and the Secure Gateway are on the same server, it can create confusion if a reverse Web proxy is
placed between the client and the Secure Gateway. Clients can communicate with the enterprise network using HT T PS
but traffic for ICA/SSL is refused. When a combination of the Web Interface and the Secure Gateway is placed behind a
reverse Web proxy server, users can log on using the Web Interface and enumerate application icons, which is all HT T P
communications. When users launch a published application, they receive an SSL Error 4 because the ICA/SSL session is
terminated by the reverse Web proxy, not by the Secure Gateway.
T his graphic shows the incorrect placement of the Secure Gateway and Web Interface behind a reverse Web proxy.
T he Secure Gateway views the reverse Web proxy as a “man in the middle” that compromises the integrity of the ICA/SSL
network stream. T his causes the SSL handshake between the client and the Secure Gateway to fail.
T he Secure Gateway and the Web Interface are installed on two separate servers. T he server running the Web Interface is
behind the reverse Web proxy. T he Secure Gateway is parallel to the reverse Web proxy.
T his graphic shows the correct placement of the Secure Gateway, which is parallel to the reverse Web proxy.
If the reverse Web proxy is configured to forward all network traffic (not just HT T P traffic) to the combination Secure
Gateway and Web Interface, the SSL connection is not terminated at the proxy and users can connect through the Secure
Gateway. T he following figure is an example of how different vendors refer to this type of deployment.
T his graphic shows the use of a network address translator instead of a reverse Web proxy.
T his approach has the disadvantage that some control must be sacrificed regarding the type of traffic that is permitted to
cross the proxy. Incoming traffic must be routed directly to the Secure Gateway and the Web Interface without being
decrypted, authenticated, or inspected. From a security standpoint, this is not much different from exposing the Secure
Gateway server directly to the Internet. T here is a logical SSL tunnel between the client and the Secure Gateway.
For more information about obtaining, exporting, and installing security certificates for your operating system, consult the
Microsoft TechNet library available at http://technet.microsoft.com.
T he SSL protocol is today’s standard for securely exchanging information on the Internet. Originally developed by
Netscape, the SSL protocol became crucial to the operation of the Internet. As a result, the Internet Engineering Taskforce
(IET F) took over responsibility for the development of SSL as an open standard. To clearly distinguish SSL from other
ongoing work, the IET F renamed SSL as T LS. T he T LS protocol is the descendant of the third version of SSL; T LS 1.0 is
identical to SSL 3.1.
Some organizations, including U.S. government organizations, require the use of T LS to secure data communications. T hese
organizations may also require the use of validated cryptography. FIPS (Federal Information Processing Standard) 140 is a
standard for cryptography.
T he Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. T he wildcard
certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as
http://www1.citrix.com or http://www2.citrix.com. T he use of a wildcard certificate allows several Web sites to be covered
by a single certificate.
T he SSL/T LS protocol allows sensitive data to be transmitted over public networks such as the Internet by providing the
following important security features:
Authentication
A client can determine a server’s identity and ascertain that the server is not an impostor. Optionally, a server can also
authenticate the identity of the client requesting connections.
Privacy
Data passed between the client and server is encrypted so that if a third party intercepts messages, it cannot unscramble
the data.
Data integrity
T he recipient of encrypted data knows if a third party corrupts or modifies that data.
Understanding Cryptography
Cryptography is also used to authenticate the identity of a message source and to ensure the integrity of its contents.
A message is sent using a secret code called a cipher. T he cipher scrambles the message so that it cannot be understood by
anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message,
thus ensuring confidentiality.
Cryptography also ensures that the contents of a message are not altered. To do this, the sender includes a cryptographic
operation called a hash function in the message. A hash function is a mathematical representation of the information,
similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates
the hash function. If the receiver’s hash function value is the same as the sender’s, the integrity of the message is assured.
Types of Cryptography
In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that
information secure and visible only to individuals who have the corresponding key to recover the information.
Secret key cryptography is also known as symmetric key cryptography. With this type of cryptography, both the sender and
the receiver know the same secret code, called the key. Messages are encrypted by the sender using the key and decrypted
by the receiver using the same key.
T his method works well if you are communicating with only a limited number of people, but it becomes impractical to
exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the
secret key securely.
Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public
key cryptography, keys work in pairs of matched public and private keys.
T he public key can be freely distributed without compromising the private key, which must be kept secret by its owner.
Because these keys work only as a pair, encryption initiated with the public key can be decrypted only with the
corresponding private key. T he following example illustrates how public key cryptography works:
Ann wants to communicate secretly with Bill. Ann encrypts her message using Bill’s public key (which Bill made available to
everyone) and Ann sends the scrambled message to Bill.
When Bill receives the message, he uses his private key to unscramble the message so that he can read it.
When Bill sends a reply to Ann, he scrambles the message using Ann’s public key.
When Ann receives Bill’s reply, she uses her private key to unscramble his message.
T he major advantage asymmetric encryption offers over symmetric key cryptography is that senders and receivers do not
have to communicate keys up front. Provided the private key is kept secret, confidential communication is possible using
the public keys.
T he main disadvantage of public key cryptography is that the process of encrypting a message, using the very large keys
common to PKI, can cause performance problems on all but the most powerful computer systems. For this reason, public
key and secret key cryptography are often combined. T he following example illustrates how this works:
Bill wants to communicate secretly with Ann, so he obtains Ann’s public key. He also generates random numbers to use
just for this session, known as a session key.
When Bill and Ann successfully exchange the session key, they no longer need public key cryptography— communication
can take place using just the session key. For example, public key encryption is used to send the secret key; when the secret
key is exchanged, communication takes place using secret key encryption.
T his solution offers the advantages of both methods— it provides the speed of secret key encryption and the security of
public key encryption.
T he ISO X.509 protocol defines a mechanism called a certificate that contains a user’s public key that is signed by a trusted
entity called a certificate authority (CA).
Certificates contain information used to establish identities over a network in a process called authentication. Like a driver’s
licence, a passport, or other forms of personal identification, certificates enable servers and clients to authenticate each
other before establishing a secure connection.
Certificates are valid only for a specified time period; when a certificate expires, a new one must be issued. T he issuing
authority can also revoke certificates.
To establish an SSL/T LS connection, you require a server certificate at one end of the connection and a root certificate of
the CA that issued the server certificate at the other end.
When establishing an SSL connection with a Web browser on a user device, the server sends its certificate to the client.
When receiving a server certificate, the Web browser (for example, Internet Explorer) on the user device checks to see which
CA issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the Web browser prompts the user
to accept or decline the certificate (effectively accepting or declining the ability to access this site).
When User A receives a message from User B, the locally stored information about the CA that issued the certificate is used
to verify that it did indeed issue the certificate. T his information is a copy of the CA’s own certificate and is referred to as a
root certificate.
Certificates generally have a common format, usually based on International Telecommunication Union (IT U) standards. T he
certificate contains information that includes the:
Certificate Chains
Some organizations delegate the responsibility for issuing certificates to resolve the issue of geographical separation
between organization units, or that of applying different issuing policies to different sections of the organization.
Responsibility for issuing certificates can be delegated by setting up subordinate CAs. T he X.509 standard includes a model
for setting up a hierarchy of CAs. In this model, the root CA is at the top of the hierarchy and has a self-signed certificate.
T he CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate
CAs in the hierarchy have their CA certificates signed by the subordinate CAs.
T his illustration shows the hierarchical structure of a typical digital certificate chain.
CAs can sign their own certificates (that is, they are self-signed) or they can be signed by another CA. If the certificate is
self-signed, they are called root CAs. If they are not self-signed, they are called subordinate or intermediate CAs.
If a server certificate is signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two
certificates: the end entity certificate and the root CA. If a user or server certificate is signed by an intermediate CA, the
certificate chain is longer.
T he following figure shows the first two elements are the end entity certificate (in this case, gwy01.company.com) and the
certificate of the intermediate CA, in that order. T he intermediate CA's certificate is followed by the certificate of its CA.
T his listing continues until the last certificate in the list is for a root CA. Each certificate in the chain attests to the identity
of the previous certificate.
From time to time, CAs issue certificate revocation lists (CRLs). CRLs contain information about certificates that can no
longer be trusted. For example, suppose Ann leaves XYZ Corporation. T he company can place Ann's certificate on a CRL to
prevent her from signing messages with that key.
Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use.
Before you trust a public key, make sure that the certificate does not appear on a CRL.
When you identify the number and type of certificates required for your Secure Gateway deployment, decide where to
obtain the certificates. Where you choose to obtain certificates depends on a number of factors, including:
Whether or not your organization is a CA, which is likely to be the case only in very large corporations
Whether or not your organization already established a business relationship with a public CA
Whether or not your organization already established a business relationship with a public CA
T he cost of certificates or the reputation of a particular public CA
If your organization is running its own CA, you must determine whether or not it is appropriate to use your company's
certificates for the purpose of securing communications in your Secure Gateway installation. Citrix recommends that you
contact your corporate security department to discuss this and to get further instructions about how to obtain
certificates.
If you are unsure if your organization is a CA, contact your corporate security department or your organization's security
expert.
If your organization is not running its own CA, you need to obtain your certificates from a public CA such as VeriSign.
Obtaining a digital certificate from a public CA involves a verification process in which:
Your organization provides corporate information so the CA can verify that your organization is who it claims to be. T he
verification process may involve other departments in your organization, such as accounting, to provide letters of
incorporation or similar legal documents.
Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA.
T he CA verifies your organization as a purchaser; therefore your purchasing department is likely to be involved.
You provide the CA with contact details of suitable individuals whom they can call if there are queries.
Your organization's security expert should have a procedure for obtaining server certificates. Instructions for generating
Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test
the Secure Gateway before deploying it in a production environment. If you do this, be aware that you need to download
matching Test Root Certificates that must be installed on each user device that connects through the Secure Gateway.
To provide secure communications (SSL/T LS), a server certificate is required on the server running the Secure Gateway. T he
steps required to obtain and install a server certificate on a server running the Secure Gateway are as follows:
When requesting a certificate, the greater the bit length, the higher the security. Citrix recommends that you select 1024
or higher. If you are specifying a bit length higher than 1024, ensure that the clients you deploy support it. For
information about supported encryption strength on a user device, see the appropriate user device's documentation.
Part of an initial request for a certificate involves generating a public/private key pair that is stored on your server.
Because the public key from this key pair is encoded in your certificate, loss of the key pair on your server renders your
certificate worthless. Make sure you back up your key pair data on another computer, a floppy disk, or both.
T ypically, the procedure for generating a key pair requires you to specify a password to encrypt the pair. T he password
prevents any person with access to the keypair data from extracting the private key and using it to decrypt SSL/T LS
traffic to and from your server. Ensure that you store the password in a secure location.
When you import a certificate, you copy the certificate from a file that uses a standard certificate storage format to a
certificate store for your computer account. Use the proper procedures or wizard as specified by your operating system
to place certificates in the correct store on local computers. Do not attempt to import the server certificate file by
double-clicking or right-clicking the certificate file within Windows Explorer. Doing so places the certificate in the
certificate store for the current user.
A root certificate must be present on every user device that connects to the secure network through the Secure Gateway.
Support for most trusted root authorities is already built into the Windows operating system and Internet Explorer.
T herefore, there is no need to obtain and install root certificates on the user device if you are using these CAs. However, if
you decide to use a different CA, you need to obtain and install the root certificates yourself.
Root certificates are available from the same CAs that issue server certificates. Well-known or trusted CAs include Verisign,
Baltimore, Entrust, and their respective affiliates. Certificate authorities tend to assume that you already have the
appropriate root certificates (this is because most Web browsers have root certificates built-in) so you need to specifically
request the root certificate. Several types of root certificates are available. For example, VeriSign has approximately 12 root
certificates that they use for different purposes, so it is important to ensure that you obtain the correct root certificate
from the CA.
T he Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. T he wildcard
certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as
http://www1.citrix.com or http://www2.citrix.com. T he use of a wildcard certificate allows several Web sites to be covered
by a single certificate.
SmartAuditor uses flexible policies to trigger recordings of XenApp sessions automatically. T his enables IT to monitor and
examine user activity of applications — such as financial operations and healthcare patient information systems —
demonstrating internal control, thus ensuring regulatory compliance and successful security audits. Similarly, SmartAuditor
also aids in technical support by speeding problem identification and time-to-resolution.
Benefits
Enhanced auditing f or regulatory compliance. SmartAuditor allows organizations to record on-screen user activity for
applications that deal with sensitive information. T his is especially critical in regulated industries such as health care and
finance, where compliance with personal information security rules is paramount. Trading applications and patient
information systems are two prime examples.
Powerf ul activity monitoring. SmartAuditor captures and archives screen updates, including mouse activity and the visible
output of keystrokes in secured video recordings to provide a record of activity for specific users, applications, and servers.
Organizations that use SmartAuditor have a better chance of proving criminal intent, where it exists, by using video
evidence combined with traditional text-based eDiscovery tools.
Faster problem resolution. When users call with a problem that is hard to reproduce, help desk support staff can enable
recording of user sessions. When the issue recurs, SmartAuditor provides a time-stamped visual record of the error, which
can then be used for faster troubleshooting.
SmartAuditor is available in English, French, German, Japanese, Spanish, and simplified Chinese. All SmartAuditor components
that connect to each other must be the same language edition; mixed-language installations are not supported.
T he English-language edition of SmartAuditor is supported on English, Russian, traditional Chinese, and Korean operating
systems. T he French, German, Japanese, Spanish, and simplified Chinese editions of SmartAuditor are supported on
operating systems in their respective languages.
T he SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, and SmartAuditor Policy
Console) can be installed on a single server or on different servers.
SmartAuditor Database
Microsoft SQL Server 2008 R2 (Enterprise and Express editions), Microsoft SQL Server 2008 (Enterprise and Express
editions), or Microsoft SQL Server 2005 (Enterprise and Express editions) with Service Pack 2
.NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4
SmartAuditor Server
Requirements:
Requirements:
Install the Microsoft IIS Management Console manually before installing the SmartAuditor Policy Console.
Microsoft IIS Management Console
SmartAuditor Agent
Install the SmartAuditor Agent on every XenApp server on which you want to record sessions.
Requirements:
XenApp 6.5 for Windows Server 2008 R2 Platinum edition or XenApp 6 for Windows Server 2008 R2 Platinum edition
server software
Microsoft Windows Server 2008 R2 with Service Pack 1 or Microsoft Windows Server 2008 R2
.NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4
Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HT T P support enabled
SmartAuditor Player
Microsoft Windows XP
Microsoft Windows Vista
Windows 7
T he update contained in Microsoft Knowledge Base article 961118 is required if you are using .NET Framework Version 3.5
and installing the SmartAuditor Player on the same computer as a XenApp server. Install the update after installing .NET
Framework.
Monitoring acceptable use of resources. Ray, the IT Manager in a local firm, needs to know whether employees are
following the acceptable use policies and other business controls he instituted to regulate access to resources published
using XenApp. Until now he had no way of measuring acceptable usage and had to trust that users of mission-critical
applications were not misusing their privileges. He now uses SmartAuditor to record user sessions and has his surveillance
officer review recorded sessions to establish cases of misuse.
Monitoring specific users or groups. John, a surveillance officer at a stockbroking firm, needs to monitor a group of
stockbrokers to observe particularly sensitive, high-value transactions. He uses SmartAuditor to record sessions for this
group of stockbrokers.
Investigating suspected violations. Lisa is John’s colleague at the stockbroking firm. She is a compliance officer who is
tasked to investigate suspected compliance violations. She uses SmartAuditor to record all XenApp sessions for a particular
employee.
Monitoring access scenarios. Marcus, the IT Manager at an insurance company, needs to monitor access to specific
applications. He uses SmartAuditor to record all sessions that involve use of a particular published application.
Technical support and troubleshooting applications. Victor, a Support Engineer at a leading software vendor based in
the United States, is often called on to resolve application issues at remote customer sites in Asia. He uses SmartAuditor to
record user sessions and reviews recorded sessions to understand the sequence of events that led the application to fail.
His colleagues in the development team are also able to deploy new versions of applications for usability testing at focus
groups. User sessions are recorded and the team can understand usability issues that exist during a review of recorded
sessions.
Training applications. Jim is a professor in the Computer Science department of a large university. He uses SmartAuditor to
record students accessing a collaborative development environment. Based on their interactions with the environment, he
can identify the areas in which they need to improve and can provide appropriate feedback.
SmartAuditor Agent. A component installed on each XenApp server to enable recording. It is responsible for recording
session data.
SmartAuditor Server. A server that hosts:
T he Broker. An IIS 6.0+ hosted Web application that handles the search queries and file download requests from the
SmartAuditor Player, handles policy administration requests from the SmartAuditor Policy Console, and evaluates
recording policies for each XenApp session.
T he Storage Manager. A Windows service that manages the recorded session files received from each SmartAuditor-
enabled computer running XenApp.
SmartAuditor Player. A user interface that users access from a workstation to play recorded XenApp session files.
T his illustration shows the SmartAuditor components and their relationship with each other:
In the deployment example illustrated here, the SmartAuditor Agent, SmartAuditor Server, SmartAuditor Database,
SmartAuditor Policy Console, and SmartAuditor Player all reside behind a security firewall. T he SmartAuditor Agent is
installed on a XenApp server. A second server hosts the SmartAuditor Policy Console, a third server acts as the SmartAuditor
Server, and a fourth server hosts the SmartAuditor Database. T he SmartAuditor Player is installed on a workstation. A client
device outside the firewall communicates with the XenApp server on which the SmartAuditor Agent is installed. Inside the
firewall, the SmartAuditor Agent, SmartAuditor Policy Console, SmartAuditor Player, and SmartAuditor Database all
communicate with the SmartAuditor Server.
T o enable SmartAuditor components to communicate with each other, ensure you install them in the same domain or
across trusted domains that have a transitive trust relationship. T he system cannot be installed into a workgroup or
across domains that have an external trust relationship.
SmartAuditor does not support the clustering of two or more SmartAuditor Servers in a deployment.
Due to its intense graphical nature and memory usage when playing back large recordings, Citrix does not recommend
installing the SmartAuditor Player as a published application.
T he SmartAuditor installation is configured for SSL/HT T PS communication. Ensure that you install a certificate on the
SmartAuditor Server and that the root certificate authority (CA) is trusted on the SmartAuditor components.
If you install the SmartAuditor Database on a stand-alone server running SQL Server 2005 Express Edition or SQL Server
2008 Express Edition, the server must have T CP/IP protocol enabled and SQL Server Browser service running. T hese
settings are disabled by default, but they must be enabled for the SmartAuditor Server to communicate with the
database. See the Microsoft documentation for information about enabling these settings.
Consider the effects of session sharing when planning your SmartAuditor deployment. Session sharing for published
applications can conflict with SmartAuditor recording policy rules for published applications. SmartAuditor matches the
active policy with the first published application that a user opens. After the user opens the first application, any
subsequent applications opened during the same session continue to follow the policy that is in force for the first
application. For example, if a policy states that only Microsoft Outlook should be recorded, the recording commences
when the user opens Outlook. However, if the user opens a published Microsoft Word second (while Outlook is running),
Word also is recorded. Conversely, if the active policy does not specific that Word should be recorded, and the user
launches Word before Outlook (which should be recorded, according to the policy), Outlook is not recorded.
A Session Recording deployment does not have to be limited to a single farm. With the exception of the Session Recording
Agent, all components are independent of the server farm. For example, you can configure multiple farms to use a single
Session Recording Server.
Alternatively, if you have a large farm with many agents and plan to record many graphically intense applications (for
example, AutoCAD applications), or you have many sessions to record, a Session Recording Server can experience a high
performance demand. To alleviate performance issues, you can install multiple Session Recording Servers on different
computers and point the Session Recording Agents to the different computers. Keep in mind that an agent can point to
only one server at a time.
T hese are the two suggested configurations for a Session Recording deployment:
Deploy the Session Recording Agent on single XenApp server.
Deploy the Session Recording Agent on multiple XenApp servers in a server farm.
Communication between SmartAuditor components is achieved through Internet Information Services (IIS) and Microsoft
Message Queuing (MSMQ). IIS provides the web services communication link between each SmartAuditor component.
MSMQ provides a reliable data transport mechanism for sending recorded session data from the SmartAuditor Agent to
the SmartAuditor Server.
Installing Certificates
On the computer on which the SmartAuditor Server is installed, the IIS Web server sends its server certificate to the client
when establishing an SSL connection from the SmartAuditor Agent, SmartAuditor Player, or SmartAuditor Policy Console.
When receiving a server certificate, the SmartAuditor Agent, SmartAuditor Player, or Policy Console determines which
Certificate Authority (CA) issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the certificate
is declined and an error is logged in the Application Event log for the SmartAuditor Agent or an error message appears to
the user in the SmartAuditor Player or Policy Console.
A server certificate is installed by gathering information about the server and requesting a CA to issue a certificate for that
server. You must specify the correct information when requesting a server certificate and ensure the server name is specified
correctly. If the fully qualified domain name (FQDN) is used for connecting clients (SmartAuditor Agent, SmartAuditor Player,
and Policy Console) the certificate information specified to the CA must use the FQDN of the server rather than the
NetBIOS name. If you specify NetBIOS names, do not specify the FQDN when requesting a server certificate. Install the
server certificate into the local server’s certificate store. Install the issuing CA certificate on each connecting client.
Your organization may have a private CA that issues server certificates that you can use with SmartAuditor. If you are using
a private CA, ensure each client device has the issuing CA certificate installed. Refer to Microsoft documentation about
using certificates and certificate authorities. Alternatively, some companies and organizations currently act as CAs, including
VeriSign, Baltimore, Entrust, and their respective affiliates.
All certificates have an expiration date defined by the CA. To find the expiration date, check the properties of the
certificate. Ensure certificates are renewed before the expiration date to prevent any errors occurring in SmartAuditor.
Note: Note: For security reasons, grant users only the rights they need to perform specific functions, such as viewing
recorded sessions.
You grant rights to SmartAuditor users by assigning them to roles using the SmartAuditor Authorization Console on the
SmartAuditor Server. SmartAuditor users have three roles:
Player. Grants the right to view recorded XenApp sessions. T here is no default membership in this role.
PolicyQuery. Allows the servers hosting the SmartAuditor Agent to request recording policy evaluations. By default,
authenticated users are members of this role.
Policy Administrator. Grants the right to view, create, edit, delete, and enable recording policies. By default,
administrators of the computer hosting the SmartAuditor Server are members of this role.
1. Log on to computer hosting the SmartAuditor Server, as administrator or as a member of the Policy Administrator role.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Authorization Console.
3. Select the role to which you want to assign users.
4. Choose Action > Assign Windows Users and Groups.
5. Add the users and groups.
Any changes made to the console take effect during the update that occurs once every minute.
Hardware Recommendations
Consider how much data you will be sending to each SmartAuditor Server and how quickly the servers can process and store
this data. T he rate at which your system can store incoming data must be higher than the data input rate.
To estimate your data input rate, multiply the number of sessions recorded by the average size of each recorded session
and divide by the period of time for which you are recording sessions. For example, you might record 5,000 Microsoft
Outlook sessions of 20MB each over an 8-hour work day. In this case, the data input rate is approximately 3.5MBps. (5,000
sessions times 20MB divided by 8 hours, divided by 3,600 seconds per hour.)
You can improve performance by optimizing the performance of a single SmartAuditor Server or by installing multiple
SmartAuditor Servers on different computers.
Storage solutions suitable for use with SmartAuditor include a set of local disks controlled as RAID arrays by a local disk
controller or by an attached Storage Area Network (SAN).
Note: SmartAuditor should not be used with Network-Attached Storage (NAS), due to performance and security problems
associated with writing recording data to a network drive.
For a local drive set up, a disk controller with built-in cache memory enhances performance. A caching disk controller must
have a battery backup facility to ensure data integrity in case of a power failure.
Network Capacity
A 100Mbps network link is suitable for connecting a SmartAuditor Server. A gigabit Ethernet connection may improve
performance, but does not result in 10 times greater performance than a 100Mbps link.
Ensure that network switches used by SmartAuditor are not shared with third-party applications that may compete for
available network bandwidth. Ideally, network switches are dedicated for use with the SmartAuditor Server.
If a single SmartAuditor Server does not meet your performance needs, you can install more SmartAuditor Servers on
different computers. In this type of deployment, each SmartAuditor Server has its own dedicated storage, network
switches, and database. To distribute the load, point the SmartAuditor Agents in your deployment to different
SmartAuditor Servers.
Database Scalability
T he SmartAuditor Database requires Microsoft SQL Server 2005 or Microsoft SQL Server 2008. T he volume of data sent to
the database is very small because the database stores only metadata about the recorded sessions. T he files of the
recorded sessions themselves are written to a separate disk. Typically, each recorded session requires only about 1KB of
space in the database, unless the SmartAuditor Event API is used to insert searchable events into the session.
T he Express Editions of Microsoft SQL Server 2005 and Microsoft SQL Server 2008 imposes a database size limitation of
4GB. At 1KB per recording session, the database can catalog about four million sessions. Other editions of Microsoft SQL
Server have no database size restrictions and are limited only by available disk space. As the number of sessions in the
database increases, performance of the database and speed of searches diminishes only negligibly.
If you are not making customizations through the SmartAuditor Event API, each recorded session generates four database
transactions: two when recording starts, one when the user logs onto the session being recorded, and one when recording
ends. If you used the SmartAuditor Event API to customize sessions, each searchable event recorded generates one
transaction. Because even the most basic database deployment can handle hundreds of transactions per second, the
processing load on the database is unlikely to be stressed. T he impact is light enough that the SmartAuditor Database can
run on the same SQL Server as other databases, including the XenApp data store database.
If your SmartAuditor deployment requires many millions of recorded sessions to be cataloged in the database, follow
Microsoft guidelines for SQL Server scalability.
Step
Selected the computers on which to install each SmartAuditor component and ensured that each
computer meets the hardware and software requirements for the component or components to be
installed on it.
If you use the SSL protocol for communication between the SmartAuditor components, install the correct
certificates in your environment.
Install any hotfixes required for the SmartAuditor components. T he hotfixes are available from the Citrix
Knowledge Center.
T he SmartAuditor Administration components are the SmartAuditor Database, SmartAuditor Server, and the SmartAuditor
Policy Console. You can choose which of these components to install on a server. Use the Autorun to install SmartAuditor
components.
T he SmartAuditor Player is installed on one or more workstations for users who view session recordings.
After installing SmartAuditor, configure the components for your environment so you can record and play XenApp sessions.
To automate installation
To install Smart Auditor Agent on multiple servers, write a script that uses silent installation.
T he following command line installs the SmartAuditor Agent and creates a log file to capture the install information.
yourservername is the NetBIOS name or FQDN of the computer hosting the SmartAuditor Server. If not specified, this value
defaults to localhost.
yourbrokerprotocol is either HT T P or HT T PS, and represents the protocol that SmartAuditor Agent uses to communicate
with SmartAuditor Broker; this value defaults to HT T PS if not specified.
yourbrokerport is an integer representing the port SmartAuditor Agent uses to communicate with SmartAuditor Broker. If
not specified, this value defaults to zero, which directs SmartAuditor Agent to use the default port number for the selected
protocol: 80 for HT T P or 443 for HT T PS.
To uninstall SmartAuditor
To remove SmartAuditor components from a server or workstation, use the uninstall or remove programs capability available
through the Windows Control Panel.
When you install SmartAuditor, no users have permission to play recorded sessions. You must assign permission to each user,
including the administrator.
T he active recording policy specifies session recording behavior on all XenApp servers that have SmartAuditor Agent installed
and connected to the SmartAuditor Server. When you install SmartAuditor, the active recording policy is Do not record.
Sessions cannot be recorded until you change the active recording policy.
1. Log on as administrator to the server where the SmartAuditor Policy Console is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console.
3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the computer
hosting the SmartAuditor Server, protocol, and port are correct.
4. In the SmartAuditor Policy Console, expand Recording Policies. T his displays the recording policies available when you
install SmartAuditor, with a check mark indicating which policy is active:
Do not record. T his is the default policy. If you do not specify another policy, no sessions are recorded.
Record everyone with notification. If you choose this policy, all sessions are recorded. A pop-up window appears
notifying the user that recording is occurring.
Record everyone without notification. If you choose this policy, all sessions are recorded. Users are unaware that they
are being recorded.
5. Select the policy you want to make the active policy.
6. From the menu bar, choose Action > Activate Policy.
Note: SmartAuditor allows you to create your own recording policy. When you create recording policies, they appear in the
Recording Policies folder within the SmartAuditor Policy Console.
To configure SmartAuditor Player
Before a SmartAuditor Player can play sessions, you must configure it to connect to the SmartAuditor Server that stores
the recorded sessions. Each SmartAuditor Player can be configured with the ability to connect to multiple SmartAuditor
Servers, but can connect to only one SmartAuditor Server at a time. If the Player is configuring with the ability to connect
to multiple SmartAuditor Servers, users can change which SmartAuditor Server the Player connects to by selecting a check
box.
You can activate system policies available when SmartAuditor is installed or create and activate your own custom policies.
SmartAuditor system policies apply a single rule to all users, published applications, and servers. Custom policies specifying
which users, published applications, and servers are recorded.
T he active policy determines which sessions are recorded. Only one policy is active at a time.
Do not record. If you choose this policy, no sessions are recorded. T his is the default policy; if you do not specify
another policy, no sessions are recorded.
Record everyone with notif ication. If you choose this policy, all sessions are recorded. A pop-up window appears
notifying the user that recording is occurring.
Record everyone without notif ication. If you choose this policy, all sessions are recorded. Users are unaware that
they are being recorded.
To activate a policy
For each rule you create, you specify a recording action and a rule criteria. T he recording action applies to sessions that
meet the rule criteria.
Do not record. (Choose Disable session recording within the rules wizard.) T his recording action specifies that sessions
that meet the rule criteria are not recorded.
Record with notification. (Choose Enable session recording with notification within the rules wizard.) T his recording
action specifies that sessions that meet the rule criteria are recorded. A pop-up window appears notifying the user that
recording is occurring.
Record without notification. (Choose Enable session recording without notification within the rules wizard.) T his
recording action specifies that sessions that meet the rule criteria are recorded. Users are unaware that they are being
recorded.
For each rule, choose at least one of the following to create the rule criteria:
Users or Groups. You create a list of users or groups to which the recording action of the rule applies.
Published Applications. You create a list of published applications to which the recording action of the rule applies. Within
the rules wizard, choose the XenApp farm or farms on which the applications are available.
Applications Servers. You create a list of XenApp servers to which the recording action of the rule applies. Within the
rules wizard, choose the XenApp farm or farms where the servers reside.
When you create more than one rule in a recording policy, some sessions may match the criteria for more than one rule. In
these cases, the rule with the highest priority is applied to the session.
Rules with the Do not record action have the highest priority
Rules with the Record with notification action have the next highest priority
Rules with the Record without notification action have the lowest priority
Some sessions may not meet any rule criteria in a recording policy. For these sessions, the recording action of the policies
fallback rule applies. T he recording action of the fallback rule is always Do not record. T he fallback rule cannot be modified
or deleted.
SmartAuditor allows you to use Active Directory groups when creating policies. Using Active Directory groups instead of
individual users simplifies creation and management of rules and policies. For example, if users in your company’s finance
department are contained in an Active Directory group named Finance, you can create a rule that applies to all members of
this group by selecting the Finance group within the rules wizard when creating the rule.
For example, if all managers in your company are members of an Active Directory group named Executive, you can ensure
that these users’ sessions are never recorded by creating a rule that disables session recording for the Executive group.
While the policy containing this rule is active, no sessions of members of the Executive group are recorded. T he sessions of
other members of your organization are sessions recorded based on other rules in the active policy.
Note: When using the rules wizard, you may be prompted to “click on underlined value to edit” when no underlined value
appears. Underlined values appear only when applicable. If no underline values appear, ignore the step.
1. Log on to the server where SmartAuditor Policy Console is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console.
3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor
Server, protocol, and port are correct. Click OK.
4. In the SmartAuditor Policy Console, select Recording Policies.
5. From the menu bar, choose Action > Add New Policy. A policy called New Policy appears in the left pane.
6. Select the new policy and choose Action > Rename from the menu bar.
7. T ype a name for the policy you are about to create and press Enter or click anywhere outside the new name.
8. With the policy selected, choose Action > Add New Rule from the menu bar to launch the rules wizard.
9. Follow the instructions to create the rules for this policy.
To modif y a policy
To delete a policy
When you activate a policy, the previously active policy remains in effect until the user’s session ends; however, in some
cases, the new policy takes effect when the file rolls over. Files roll over when they have reached the maximum size limit.
T he following table details what happens when you apply a new policy while a session is being recorded and a rollover
occurs:
If the previous And the new policy Af ter a rollover the policy will be:
policy was: is:
Do not record Any other policy No change. T he new policy takes effect only when the user logs on
to a new session.
Record without Recording continues. No message appears the next time a user logs
notification on.
When you install the SmartAuditor Agent, recording is enabled. Citrix recommends that you disable SmartAuditor on servers
that are not recorded because they experience a small impact on performance, even if no recording takes place.
Note: When you install SmartAuditor, the active policy is Do not record (no sessions are recorded on any server). T o begin
recording, use the SmartAuditor Policy Console to activate a different policy.
To configure the connection to the SmartAuditor Server
T he connection between the SmartAuditor Agent and the SmartAuditor Server is typically configured when the
SmartAuditor Agent is installed. To configure this connection after SmartAuditor Agent is installed, use SmartAuditor Agent
Properties.
To create notifications
If the active recording policy specifies that users are notified when their sessions are recorded, a pop-up window appears
displaying a notification message after users type their credentials. T he following message is the default notification: “Your
activity with one or more of the programs you recently started is being recorded. If you object to this condition, close the
programs.” T he user clicks OK to dismiss the window and continue the session.
T he default notification message appears in the language of the operating system of the computers hosting the
SmartAuditor Server.
After accepting and activating, the new message appears in the Language-specific notification messages box.
To enable custom event recording
SmartAuditor allows you to use third-party applications to insert custom data, known as events, into recorded sessions.
T hese events appear when the session is viewed using the SmartAuditor Player. T hey are part of the recorded session file
and cannot be modified after the session is recorded.
For example, an event might contain the following text: “User opened a browser.” Each time a user opens a browser during
a session that is being recorded, the text is inserted into the recording at that point. When the session is played using the
SmartAuditor Player, the viewer can locate and count the times that the user opened a browser by noting the number of
markers that appear in the Events and Bookmarks list in the SmartAuditor Player.
Use SmartAuditor Agent Properties to enable a setting on each server where you want to insert custom events. You
must enable each server separately; you cannot globally enable all servers in a farm.
Write applications built on the Event API that runs within each user’s XenApp session (to inject the data into the
recording).
T he SmartAuditor installation includes an event recording COM application (API) that allows you to insert text from third-
party applications into a recording. You can use the API from many programming languages including Visual Basic, C++, or
C#. T he SmartAuditor Event API .dll is installed as part of the SmartAuditor installation. You can find it at C:\Program
Files\Citrix\SmartAuditor\Agent\Bin\Interop.UserApi.dll.
Using SmartAuditor Player, you can view a session after or while it is being recorded. Viewing a session that is currently
recording is similar to seeing actions happening live; however, there is actually a one to two second delay as the data
propagates from the XenApp server.
Some functionality is not available when viewing sessions that have not completed recording:
A digital signature cannot be assigned until recording is complete. If digital signing is enabled, you can view live playback
sessions, but they are not digitally signed and you cannot view certificates until the session is completed.
Playback protection cannot be applied until recording is complete. If playback protection is enabled, you can view live
As a security precaution, SmartAuditor automatically encrypts recorded files before they are downloaded for viewing in the
SmartAuditor Player. T his playback protection prevents them from being copied and viewed by anyone other than the user
who downloaded the file. T he files cannot be played back on another workstation or by another user. Encrypted files are
identified with an .icle extension; unencrypted files are identified with an .icl extension. T he files remain encrypted while they
reside in the cache on the workstation where the SmartAuditor Player is installed until they are opened by an authorized
user.
If you installed certificates on the computers on which the SmartAuditor components are installed, you can enhance the
security of your SmartAuditor deployment by assigning digital signatures to session recording.
Use SmartAuditor Server Properties to specify where recordings are stored and where archived recordings are restored.
By default, archived recordings are restored to the drive:\SessionRecordingsRestore directory of the computer hosting the
SmartAuditor Server. You can change the directory where the archived recordings are restored.
As recordings grow in size, the files can take longer to download and react more slowly when you use the seek slider to
navigate during playback. To control file size, specify a threshold limit for a file. When the recording reaches this limit,
SmartAuditor closes the file and opens a new one to continue recording. T his action is called a rollover.
File size. When the file reaches the specified number of megabytes, SmartAuditor closes the file and opens a new one.
By default, files roll over after reaching 50 megabytes; however, you can specify a limit from 10 megabytes to one
gigabyte.
Duration. After the session records for the specified number of hours, the file is closed and a new file is opened. By
default, files roll over after recording for 12 hours; however, you can specify a limit from one to 24 hours.
SmartAuditor checks both fields to determine which event occurs first to determine when to rollover. For example, if you
specify 17MB for the file size and six hours for the duration and the recording reaches 17MB in three hours, SmartAuditor
reacts to the 17MB file size to close the file and open a new one.
To prevent the creation of many small files, SmartAuditor does not rollover until at least one hour elapses (this is the
minimum number that you can enter) regardless of the value specified for the file size. T he exception to this rule is if the file
size surpasses one gigabyte.
If sessions are recorded with the live playback feature enabled, you can view sessions that are in progress, with a delay of a
few seconds, as well as sessions that are completed.
Sessions that have a longer duration or larger file size than the limits configured by your SmartAuditor administrator appear
in more than one session file.
Note: A SmartAuditor administrator must grant users the right to access to recorded XenApp sessions. If you are denied
access to viewing sessions, contact your SmartAuditor administrator.
When SmartAuditor Player is installed, the SmartAuditor administrator typically sets up a connection between the
SmartAuditor Player and a SmartAuditor Server. If this connection is not set up, the first time you perform a search for files,
you are prompted to set it up. Contact your SmartAuditor administrator for set up information.
T his illustration shows the SmartAuditor Player with callouts indicating its major elements. T he functions of these elements
are described throughout this chapter.
If the SmartAuditor administrator set up your SmartAuditor Player with the ability to connect to more than one
SmartAuditor Server, you can select the SmartAuditor Server that the SmartAuditor Player connects to. T he SmartAuditor
Player can connect to only one SmartAuditor Server at a time.
Perform a search using the Smart Auditor Player. Recorded sessions that meet the search criteria appear in the search
results area.
Access recorded session files directly from your local disk drive or a share drive.
Access recorded session files from a Favorites folder
When you open a file that was recorded without a digital signature, a warning appears telling you that the origin and
integrity of the file was not verified. If you are confident of the integrity of the file, click Yes in the warning pop-up window
to open the file.
Recorded session file names begin with an i_, followed by a unique alphanumeric file ID, followed by the .icl and .icle file
extension: .icl for recordings without playback protection applied, .icle for recordings with playback protection applied.
SmartAuditor saves recorded session files in a directory structure that incorporates the date the session was recorded. For
example, the file for a session recorded on May 22, 2008, is saved in folder path 2008\05\22.
1. Log on to the workstation where SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. Do any of the following:
From the SmartAuditor Player menu bar, select File > Open and browse for the file
Using Windows Explorer, navigate to the file and drag the file into the Player window
Using Windows Explorer, navigate to and double-click the file
If you created Favorites in the Workspace pane, select Favorites and open the file from the Favorites area in the
same way you open files from the search results area
Using Favorites
Creating Favorites folders allows you to quickly access recordings that you view frequently. T hese Favorites folders
reference recorded session files that are stored on your workstation or on a network drive. You can import and export
these files to other workstations and share these folders with other SmartAuditor Player users.
Note: Only users with access rights to SmartAuditor Player can download the recorded session files associated with
Favorites folders. Contact your SmartAuditor administrator for access rights.
Use the other options that appear in the File > Folder menu to delete, rename, move, copy, import, and export the folders.
To search f or recorded sessions
SmartAuditor Player allows you to perform quick searches, perform advanced searches, and specify options that apply to all
searches. Results of searches appear in the search results area of the SmartAuditor Player.
Note: T o display all available recorded sessions, up to the maximum number of sessions that may appear in a search,
perform a search without specifying any search parameters.
1. Log on to the workstation where SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. Define your search criteria:
Enter a search criterion in the Search field. T o assist you:
Move the mouse pointer over the Search label to display a list of parameters to use as a guideline
Click the arrow to the right of the Search field to display the text for the last 64 searches you performed
Use the drop-down list to the right of the Search field to select a period or duration specifying when the session was
recorded.
4. Click the binocular icon to the right of the drop-down list to start the search.
SmartAuditor Player search options allow you to limit maximum number of session recordings that appear in search results
and to specify whether or not search results include archived session files.
1. Log on to the workstation where SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. From the SmartAuditor Player menu bar, choose T ools > Options > Search.
4. In the Maximum result to display field, type the number of search results you want to display. A maximum of 500 results
can be displayed.
After you open a recorded session in the SmartAuditor Player, you can navigate through the recorded sessions using these
methods:
Use the player controls to play, stop, pause, and increase or decrease playback speed
Use the seek slider to move forward or backward
If you have inserted markers into the recording or if the recorded session contains custom events, you can also navigate
through the recorded session by going to those markers and events.
Note: During playback of a recorded session, a second mouse pointer may appear. T he second pointer appears at the point
in the recording when the user navigated within Internet Explorer 7.0 and clicked an image that was originally larger than
the screen but was scaled down automatically by Internet Explorer 7.0. While only one pointer appears during the session,
two may appear during playback.
Note: T his version of SmartAuditor does not support SpeedScreen Multimedia Acceleration for Citrix Presentation Server or
the Flash quality adjustment policy setting for Citrix XenApp. When this option is enabled, playback displays a black square.
Using the Seek Slider
Use the seek slider below the Player window to jump to a different position within the recorded session. You can drag the
seek slider to the point in the recording you want to view or click anywhere on the slider bar to move to that location.
You can also use the following keyboard keys to control the seek slider:
Ctrl + Move mouse wheel one notch down Seek forward 90 seconds.
Note: T o adjust the speed of the seeks slider: From the SmartAuditor Player menu bar, choose Tools > Options > Player
and drag the slider to increase or decrease the seek response time. A faster response time requires more memory.
To change the playback speed
You can set SmartAuditor Player to play recorded sessions in exponential increments from one-quarter normal playback
speed to 32 times normal playback speed.
Fast review mode allows you to set SmartAuditor Player to skip the portions of recorded sessions in which no action takes
place. T his setting saves time for playback viewing; however, it does not skip animated sequences such as animated mouse
pointers, flashing cursors, or displayed clocks with second hand movements.
Events are inserted to sessions as they are recorded, using the Event API and a third-party application. Events are saved as
part of the session file. You cannot delete or alter them using the SmartAuditor Player.
Bookmarks are markers you insert into the recorded sessions using the SmartAuditor Player. Bookmarks are associated with
the recorded session until you delete them, but they are not saved as part of the session file. By default, each bookmark is
labeled with the text Bookmark, but you can change this to any text annotation up to 128 characters long.
Events and bookmarks appear as dots under the Player window. Events appear as yellow dots; bookmarks appear as blue
dots. Moving the mouse over these dots displays the text label associated with them. You can also display the events and
bookmarks in the events and bookmarks list of the SmartAuditor Player. T hey appear in this list with their text labels and
the times in the recorded session at which they appear, in chronological order.
You can use events and bookmarks to help you navigate through recorded sessions. By going to an event or bookmark, you
can skip to the point in the recorded session where the event or bookmark is inserted.
T he events and bookmarks list displays the events and bookmarks inserted in the recorded session that is currently playing.
It can show events only, bookmarks only, or both.
1. Log on to the workstation where the SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. Move the mouse pointer into the events and bookmarks list area and right-click to display the menu.
4. Choose Show Events Only, Show Bookmarks Only, or Show All.
To insert a bookmark
After a bookmark is created, you can add an annotation to it or change its annotation.
1. Log on to the workstation where SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. Begin playing the recorded session containing the bookmark.
4. Ensure that the events and bookmarks list is displaying bookmarks.
5. Select the bookmark in the events and bookmarks list and right-click to display the menu.
To delete a bookmark
To go to an event or bookmark
Going to an event or bookmark causes the SmartAuditor Player to go to the point in the recorded session where the event
or bookmark is inserted.
1. Log on to the workstation where the SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. Begin playing a session recording containing events or bookmarks.
4. Go to an event or bookmark:
In the area below the Player window, click the dot representing the event or bookmark to go to the event or
bookmark.
In the events and bookmarks list, double-click the event or bookmark to go to it. T o go to the next event or
bookmark, select any event or bookmark from the list, right-click to display the menu, and choose Seek to Bookmark.
You can specify how much disk space is used for the cache. When the recordings fill the specified disk space, SmartAuditor
deletes the oldest, least used recordings to make room for new recordings. You can empty the cache at any time to free up
disk space.
To enable caching
To empty cache
When SmartAuditor Agent cannot connect, the Exception caught while sending poll messages to SmartAuditor Broker
event message is logged, followed by the exception text. T he exception text provides the reason why the connection
failed. T hese reasons include:
T he underlying connection was closed. Could not establish a trust relationship for the SSL/T LS secure channel. T his
exception means that the SmartAuditor Server is using a certificate that is signed by a CA that the server on which the
SmartAuditor Agent resides does not trust, or have a CA certificate for. Alternatively, the certificate may have expired or
been revoked.
Resolution: Verify that the correct CA certificate is installed on the server hosting the SmartAuditor Agent or use a CA
that is trusted.
T he remote server returned an error: (403) forbidden. T his is a standard HT T PS error displayed when you attempt to
connect using HT T P (nonsecure protocol). T he computer hosting the SmartAuditor Server rejects the connection
because it accepts only secure connections.
Resolution: Use SmartAuditor Agent Properties to change the SmartAuditor Broker protocol to HT T PS.
T he SmartAuditor Broker returned an unknown error while evaluating a record policy query. Error code 5 (Access Denied).
See the Event log on the SmartAuditor Server for more details. T his error occurs when sessions are started and a request
for a record policy evaluation is made. T he error is a result of the Authenticated Users group (this is the default member)
being removed from the Policy Query role of the SmartAuditor Authorization Console.
Resolution: Add the Authenticated Users group back into this role, or add each server hosting each SmartAuditor Agent to
the PolicyQuery role.
T he underlying connection was closed. A connection that was expected to be kept alive was closed by the server. T his error
means that the SmartAuditor Server is down or unavailable to accept requests. T his could be due to IIS being offline or
restarted, or the entire server may be offline.
Resolution: Verify that the SmartAuditor Server is started, IIS is running on the server, and the server is connected to the
network.
When the SmartAuditor Server cannot connect to the SmartAuditor Database, you may see a message similar to one of
the following:
Unable to connect to the SmartAuditor Server. Ensure that the SmartAuditor Server is running. T his error message appears
when you launch the SmartAuditor Policy Console.
Resolution:
T he Express Edition of Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is installed on a stand-alone server and
does not have the correct services or settings configured for SmartAuditor. T he server must have T CP/IP protocol
enabled and SQL Server Browser service running. See the Microsoft documentation for information about enabling
these settings.
During the SmartAuditor installation (administration portion), incorrect server and database information was given.
Uninstall the SmartAuditor Database and reinstall it, supplying the correct information.
T he SmartAuditor Database Server is down. Verify that the server has connectivity.
T he computer hosting the SmartAuditor Server or the computer hosting the SmartAuditor Database Server cannot
resolve the FQDN or NetBIOS name of the other. Use the ping command to verify the names can be resolved.
Logon failed for user ‘NT _AUT HORIT Y\ANONYMOUS LOGON’. T his error message means that the services are logged on
incorrectly as .\administrator.
Resolution: Restart the services as local system user and restart the SQL services.
If your XenApp sessions are not recording successfully, start by checking the application event log in the Event Viewer on
the XenApp server running the SmartAuditor Agent and SmartAuditor Server. T his may provide valuable diagnostic
information.
Component connectivity and certif icates. If the SmartAuditor components cannot communicate with each other,
this can cause session recordings to fail. T o troubleshoot recording issues, verify that all components are configured
correctly to point to the correct computers and that all certificates are valid and correctly installed.
Non-Active Directory domain environments. SmartAuditor is designed to run in a Microsoft Active Directory domain
environment. If you are not running in an Active Directory environment, you may experience recording issues. Ensure that
all SmartAuditor components are running on computers that are members of an Active Directory domain.
Session sharing conf licts with the active policy. SmartAuditor matches the active policy with the first published
application that a user opens. Subsequent applications opened during the same session continue to follow the policy
that is in force for the first application. T o prevent session sharing from conflicting with the active policy, publish the
conflicting applications on separate XenApp servers or disable session sharing. For instructions about how to disable
session sharing, refer to the Citrix Knowledge Center. When disabling session sharing, consider that this can also affect
the total number of sessions on a server, clipboard mapping, and session logon time.
Recording is not enabled. By default, installing the SmartAuditor Agent on a XenApp server enables the server for
recording. Recording will not occur until an active recording policy is configured to allow this.
The active recording policy permit recording. For a session to be recorded, the active recording policy must permit
the sessions for the user, server, or published application to be recorded.
SmartAuditor services are not running. For sessions to be recorded, the SmartAuditor Agent service must be running
on the XenApp server and the SmartAuditor Storage Manager service must be running on the computer hosting the
SmartAuditor Server.
If you experience difficulties when viewing recordings using the SmartAuditor Player, the following error message may
appear on the screen:
Download of recorded session file failed. Live session playback is not permitted. T he server has been configured to disallow
this feature. T his error indicates that the server is configured to disallow the action.
Resolution: In the SmartAuditor Server Properties dialog box, choose the Playback tab and select the Allow live session
playback check box.
If you experience difficulties when searching for recordings using the SmartAuditor Player, the following error messages
may appear on the screen:
Search for recorded session files failed. T he remote server name could not be resolved: servername. where servername is
the name of the server to which the SmartAuditor Player is attempting to connect. T he SmartAuditor Player cannot
contact the SmartAuditor Server. T wo possible reasons for this are an incorrectly typed server name or the DNS cannot
resolve the server name.
Resolution: From the Player menu bar, choose Tools > Options > Connections and verify that the server name in the
SmartAuditor Servers list is correct. If it is correct, from a command prompt, run the ping command to see if the name
can be resolved. When the SmartAuditor Server is down or offline, the search for recorded session files failed error
message is Unable to contact the remote server.
Unable to contact the remote server. T his error occurs when the SmartAuditor Server is down or offline.
Resolution: Verify that the SmartAuditor Server is connected.
Access denied error. An access denied error can occur if the user was not given permission to search for and download
recorded session files.
Resolution: Assign the user to the Player role using the SmartAuditor Authorization Console.
Search for recorded session files failed. T he underlying connection was closed. Could not establish a trust relationship for
the SSL/T LS secure channel. T his exception is caused by the SmartAuditor Server using a certificate that is signed by a
CA that the client device does not trust or have a CA certificate for.
Resolution: Install the correct or trusted CA certificate workstation where the SmartAuditor Player is installed.
T he remote server returned an error: (403) forbidden. T his error is a standard HT T PS error that occurs when you attempt
to connect using HT T P (nonsecure protocol). T he server rejects the connection because, by default, it is configured to
accept only secure connections.
Resolution: From the SmartAuditor Player menu bar, choose Tools > Options > Connections. Select the server from the
SmartAuditors Servers list, then click Modify. Change the protocol from HT T P to HT T PS.
T he SmartAuditor Agent and SmartAuditor Server (Storage Manager and Broker) log connection errors in the applications
event log in the Event Viewer of the computer hosting the SmartAuditor Server, while the SmartAuditor Policy Console and
SmartAuditor Player display connection error messages on screen when they fail to connect.
Note: Check the application event log for errors and warnings.
To verif y SmartAuditor Server is connected
Caution: Using Registry Editor can cause serious problems that can require you to reinstall the operating system. Citrix
cannot guarantee that problems resulting from incorrect use of Registry Editor can be solved. Use Registry Editor at your
own risk.
1. Log on to the computer hosting the SmartAuditor Server.
2. Open the Registry Editor.
3. Browse to HKEY_LOCAL_MACHINE\SOFT WARE\Citrix\SmartAuditor\Server.
4. Verify the value of SmAudDatabaseInstance correctly references the SmartAuditor Database you installed in your SQL
Server instance.
1. Using a SQL Management tool, open your SQL instance that contains the SmartAuditor Database you installed.
2. Open the Security permissions of the SmartAuditor Database.
3. Verify the SmartAuditor Computer Account has access to the database. For example, if the computer hosting the
SmartAuditor Server is named SmartAudSrv in the MIS domain, the computer account in your database should be
configured as MIS\SmartAudSrv$. T his value is configured during the SmartAuditor Database install.
Testing connections to the SmartAuditor Server IIS site by using a Web browser to access the SmartAuditor Broker Web
page can help you determine whether problems with communication between SmartAuditor components stem from
misconfigured protocol configuration, certification issues, or problems starting SmartAuditor Broker.
If you see an XML document within your browser, this verifies that the computer running the SmartAuditor Policy Console
is connected to the computer hosting the SmartAuditor Server using the configure protocol.
To troubleshoot certificate issues
If you are using HT T PS as your communication protocol, the computer hosting the SmartAuditor Server must be configured
with a server certificate. All component connections to the SmartAuditor Server must have root certificate authority (CA).
Otherwise, attempted connections between the components fail.
You can test your certificates by accessing the SmartAuditor Broker Web page as you would when testing IIS connectivity.
If you are able to access the XML page for each component, the certificates are configured correctly.
Here are some common ways certificate issues cause connections to fail:
Invalid or missing certif icates. If the server running the SmartAuditor Agent does not have a root certificate to trust
the server certificate, cannot trust and connect to the SmartAuditor Server over HT T PS, causing connectivity to fail.
Verify that all components trust the server certificate on the SmartAuditor Server.
Inconsistent naming. If the server certificate assigned to the computer hosting the SmartAuditor Server is created
using a fully qualified domain name (FQDN), then all connecting components must use the FQDN when connecting to
the SmartAuditor Server. If a NetBIOS name is used, configure the components with a NetBIOS name for the
SmartAuditor Server.
Expired certif icates. If a server certificate expired, connectivity to the SmartAuditor Server through HT T PS fails. Verify
the server certificate assigned to the computer hosting the SmartAuditor Server is valid and has not expired. If the same
certificate is used for the digital signing of session recordings, the event log of the computer hosting the SmartAuditor
Server provides error messages that the certificate expired or warning messages when it is about to expire.
If your users see the notification message but the viewer cannot find the recordings after performing a search in the
SmartAuditor Player, there could be a problem with MSMQ. Verify that the queue is connected to the SmartAuditor Server
(Storage Manager) and use a Web browser to test for connection errors (if you are using HT T P or HT T PS as your MSMQ
communication protocol).
1. Log on to the computer hosting the SmartAuditor Server and disable secure connections for SmartAuditor Broker in IIS.
2. Change the protocol setting from HT T PS to HT T P in each SmartAuditor Agent Properties dialog box:
1. Log on to each server where the SmartAuditor Agent is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties.
3. In SmartAuditor Agent Properties, choose the Connections tab.
4. In the SmartAuditor Broker area, select HT T P from the Protocol drop-down list and choose OK to accept the change.
If you are prompted to restart the service, choose Yes.
3. Change the protocol setting from HT T PS to HT T P in the SmartAuditor Player settings:
1. Log on to each workstation where the SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. From the SmartAuditor Player menu bar, choose T ools > Options > Connections, select the server and choose Modify.
4. Select HT T P from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box.
4. Change the protocol setting from HT T PS to HT T P in the SmartAuditor Policy Console:
1. Log on to the server where the SmartAuditor Policy Console is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console.
3. Choose HT T P from the Protocol drop-down list and choose OK to connect. If the connection is successful, this
setting is remembered the next time you launch the SmartAuditor Policy Console.
1. Log on to the computer hosting the SmartAuditor Server and enable secure connections for the SmartAuditor Broker in
IIS.
2. Change the protocol setting from HT T P to HT T PS in each SmartAuditor Agent Properties dialog box:
1. Log on to each server where the SmartAuditor Agent is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties.
3. In SmartAuditor Agent Properties, choose the Connections tab.
4. In the SmartAuditor Broker area, select HT T PS from the Protocol drop-down list and choose OK to accept the
change. If you are prompted to restart the service, choose Yes.
3. Change the protocol setting from HT T P to HT T PS in the SmartAuditor Player settings:
1. Log on to each workstation where the SmartAuditor Player is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.
3. From the SmartAuditor Player menu bar, choose T ools > Options > Connections, select the server and choose Modify.
4. Select HT T PS from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box.
4. Change the protocol setting from HT T P to HT T PS in the SmartAuditor Policy Console:
1. Log on to the server where the SmartAuditor Policy Console is installed.
2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console.
3. Choose HT T PS from the Protocol drop-down list and choose OK to connect. If the connection is successful, this
setting is remembered the next time you launch the SmartAuditor Policy Console.
T he following table lists the commands and options that are available for the ICLDB utility. Type the commands using the
following format:
icldb [version | locate | dormant | import | archive | remove | removeall] command-options [/l] [/f ] [/s] [/?]
Note: More extensive instructions are available in the help associated with the utility. T o access the help, from a command
prompt, type drive:\Program Files\Citrix\SmartAuditor\Server\Bin directory, type icldb /?. T o access help for specific
commands, type icldb command /?.
Command Description
archive Archives the session recording files older than the retention period specified.
Use this command to archive files.
dormant Displays or counts the session recording files that are considered dormant. Dormant files are
session recordings that were not completed due to data loss.
Use this command to verify if you suspect that you are losing data. You can verify if the
session recording files are becoming dormant for the entire database, or only recordings
made within the specified number of days, hours, or minutes.
Additionally, use this command to merge databases (if you have two databases, you can
import the files from one of the databases).
locate Locates and displays the full path to a session recording file using the file ID as the criteria.
Use this command when you are looking for the storage location of a session recording file.
It is also one way to verify if the database is up-to-date with a specific file.
remove Removes the references to session recording files from the database.
Use this command (with caution) to clean up the database. Specify the retention period to
be used as the criteria.
removeall Removes all of the references to session recording files from the SmartAuditor Database
When deploying XenApp within large organizations, particularly in government environments, security standards are an
important consideration. For example, many government bodies in the United States and elsewhere specify a preference or
requirement for applications to be compliant with Federal Information Processing Standards (FIPS) 140. T hese topics
address common issues related to such environments.
T he 6.5 release modifies several XenApp features in order to comply with the new FIPS 140 guidelines for 2010.
SHA-256 hashing -
T he Citrix Streaming Profiler now creates SHA-256 hashes of each file in a profile. When enabled for backwards
compatibility with the legacy Offline Plug-in 6.0.x, the Offline Plug-in can verify the integrity of profiles that contain
SHA-256 and SHA-1 hashes. For more information, see T o support legacy plug-ins.
SmartAuditor now creates SHA-256 hashes of saved sessions. For backwards compatibility, the SmartAuditor Player
can verify the integrity of sessions whose integrity checksum is computed using SHA-256 or SHA-1.
204 8-bit RSA keys -
IMA Encryption now creates 2048-bit RSA keys.
T he keys contain both size and algorithm information, and can be imported by any version of XenApp that supports
IMA Encryption.
IMA Encryption RSA keys are generated only during a new install or when manually changed. If the key is replaced on
one server, it must be replaced on all servers. T herefore, there are no issues arising from mixed farms.
Application streaming supports certificates containing 2048-bit RSA keys.
Server Farms
A server farm is a collection of XenApp servers that you can manage (from the Delivery Services Console) as a single entity. A
server can belong to only one farm, but a farm can include servers from more than one domain. T he design of server farms
must balance two goals:
Providing users with the fastest possible application access
Achieving the required degree of centralized administration and network security
XenApp provides server-based computing to local and remote users through the Independent Computing Architecture (ICA)
protocol developed by Citrix. ICA is the communication protocol by which servers and client devices exchange data in a
XenApp environment. ICA is optimized to enhance the delivery and performance of this exchange, even on low bandwidth
connections.
As an application runs on the server, XenApp intercepts the application’s display data and uses the ICA protocol to send this
data (on standard network protocols) to the Citrix Receiver software running on the user’s client device. When the user
types on the keyboard or moves and clicks the mouse, the Citrix Receiver software sends the generated data to the
ICA requires minimal client workstation capabilities, and includes error detection and recovery, encryption, and data
compression.
Note: T he HDX Flash redirection technology may stream Flash content outside of the ICA protocol in separate T CP
connections. For more information, see Configuring HDX MediaStream Flash Redirection
Web Interf ace
In XenApp deployments that include the Web Interface, use HT T PS for communication between the server running the
Web Interface and the client devices running Web browsers (and Citrix Receiver software).
Virtual Channels
T he following table shows which Citrix Independent Computing Architecture (ICA) virtual channels or combination of virtual
channels can be used with XenApp for authentication, or for and application signing and encryption methods.
Note: T his table applies only to XenApp, not to Citrix Single Sign-on.
Core ICA protocol (no virtual Smart card virtual Kerberos virtual
channel) channel channel
Biometric1 authentication *
Password authentication * *
Application *
signing/encryption
1
T hird-party equipment is required for biometric authentication.
T he following products can be used with XenApp to provide additional security. T hese additional security measures are not
included in the sample deployments.
RSA SecurID supports authentication on both XenApp and Citrix Single Sign-on.
When deploying XenApp within large organizations, particularly in government environments, security standards are an
important consideration. For example, many government bodies in the United States and elsewhere specify a preference or
requirement for applications to be compliant with Federal Information Processing Standards (FIPS) 140. T hese topics
address common issues related to such environments.
T he 6.5 release modifies several XenApp features in order to comply with the new FIPS 140 guidelines for 2010.
SHA-256 hashing -
T he Citrix Streaming Profiler now creates SHA-256 hashes of each file in a profile. When enabled for backwards
compatibility with the legacy Offline Plug-in 6.0.x, the Offline Plug-in can verify the integrity of profiles that contain
SHA-256 and SHA-1 hashes.
SmartAuditor now creates SHA-256 hashes of saved sessions. For backwards compatibility, the SmartAuditor Player
can verify the integrity of sessions whose integrity checksum is computed using SHA-256 or SHA-1.
204 8-bit RSA keys -
IMA Encryption now creates 2048-bit RSA keys.
T he keys contain both size and algorithm information, and can be imported by any version of XenApp that supports
IMA Encryption.
IMA Encryption RSA keys are generated only during a new install or when manually changed. If the key is replaced on
one server, it must be replaced on all servers. T herefore, there are no issues arising from mixed farms.
Application streaming supports certificates containing 2048-bit RSA keys.
Server Farms
A server farm is a collection of XenApp servers that you can manage (from the Delivery Services Console) as a single entity. A
server can belong to only one farm, but a farm can include servers from more than one domain. T he design of server farms
must balance two goals:
Providing users with the fastest possible application access
Achieving the required degree of centralized administration and network security
XenApp provides server-based computing to local and remote users through the Independent Computing Architecture (ICA)
protocol developed by Citrix. ICA is the communication protocol by which servers and client devices exchange data in a
XenApp environment. ICA is optimized to enhance the delivery and performance of this exchange, even on low bandwidth
connections.
As an application runs on the server, XenApp intercepts the application’s display data and uses the ICA protocol to send this
data (on standard network protocols) to the Citrix Receiver software running on the user’s client device. When the user
types on the keyboard or moves and clicks the mouse, the Citrix Receiver software sends the generated data to the
ICA requires minimal client workstation capabilities, and includes error detection and recovery, encryption, and data
compression.
Note: T he HDX Flash redirection technology may stream Flash content outside of the ICA protocol in separate T CP
connections. For more information, see Configuring HDX MediaStream Flash Redirection
Web Interf ace
In XenApp deployments that include the Web Interface, use HT T PS for communication between the server running the
Web Interface and the client devices running Web browsers (and Citrix Receiver software).
Virtual Channels
T he following table shows which Citrix Independent Computing Architecture (ICA) virtual channels or combination of virtual
channels can be used with XenApp for authentication, or for and application signing and encryption methods.
Note: T his table applies only to XenApp, not to Citrix Single Sign-on.
Core ICA protocol (no virtual Smart card virtual Kerberos virtual
channel) channel channel
Biometric1 authentication *
Password authentication * *
Application *
signing/encryption
1
T hird-party equipment is required for biometric authentication.
T he following products can be used with XenApp to provide additional security. T hese additional security measures are not
included in the sample deployments.
RSA SecurID supports authentication on both XenApp and Citrix Single Sign-on.
For more information about FIPS 140 and NIST, visit the NIST Web site at http://csrc.nist.gov/.
FIPS 140-1, published in 1994, established requirements for cryptographic modules to provide four security levels that
allowed cost-effective solutions appropriate for different degrees of data sensitivity and different application
environments.
FIPS 140-2, which superseded FIPS 140-1 in 2002, incorporated changes in standards and technology since 1994.
FIPS 140-3, which is still in draft, adds an additional security level and incorporates new security features that reflect
recent advances in technology.
When configured properly, XenApp 6.5 can use FIPS 140-validated cryptographic modules in a manner that is compliant with
FIPS 140-2.
T he security community at large values products that follow the guidelines detailed in FIPS 140 and the use of FIPS 140-
validated cryptographic modules.
Some U.S. Government organizations restrict purchases of products that contain cryptography to those that use FIPS 140-
validated modules.
In the U.K., guidance published by the Communications-Electronics Security Group (CESG) recommends the use of FIPS 140-
approved products where the required use for information is below the REST RICT ED classification, but is still sensitive (that
is, data classified PROT ECT ).
T o implement secure access to application servers and to meet the FIPS 140 requirements, Citrix products can use
cryptographic modules that are FIPS 140-validated in Windows implementations of secure T LS or SSL connections. T he
following XenApp components can use cryptographic modules that are FIPS 140-validated:
XenApp
Citrix Receiver and Citrix online plug-in
Web Interface
SSL Relay
Secure Gateway for Windows
Single Sign-on
Offline applications (streaming)
Where these client and server components communicate with the T LS or SSL connection enabled, the cryptographic
modules that are used are provided by the Microsoft Windows operating system. T hese modules use the Microsoft
Cryptography Application Programming Interface (CryptoAPI) and are FIPS 140-validated.
Note: On both Windows Vista with Service Pack 1 and Windows Server 2008, you must apply Microsoft hotfix kb954059
(http://support.microsoft.com/kb/954059) to ensure that the random number generator used within CryptoAPI and,
therefore the underlying operating system, is FIPS 140-compliant.
FIPS Compliance
Given the accuracy of the above statements, and assuming that all these steps are followed, the resulting XenApp
configuration will use FIPS 140 cryptomodules in a FIPS-compliant manner.
SSL/TLS Protocols
If user devices in your environment communicate with your farm across the Internet, Citrix recommends enabling Secure
Sockets Layer (SSL) 3.0 or Transport Layer Security (T LS) 1.0 encryption when you publish a resource. T hese protocols are
collectively referred to SSL/T LS.
Both SSL and T LS are open protocols that provide data encryption, server authentication, message integrity, and optional
client authentication for a T CP/IP connection:
SSL is an open, nonproprietary security protocol for T CP/IP connections.
T LS, which is also an open standard, is the latest, standardized version of the SSL protocol.
SSL 3.0 and T LS 1.0 are not interoperable. However, because there are only minor differences between them, the server
certificates in your installation can be used for both SSL and T LS implementations.
Deployment samples in the XenApp 6.5 Security Standards documentation include implementations of each. T he nature of
your environment may determine the way in which you enable SSL:
For user devices communicating with your farm remotely, Citrix recommends that you use the Secure Gateway to pass
client communications to the computer running XenApp. T he 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 user 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 user devices and servers in your farm.
Note:
If you use SSL Relay, you must install it on every server in the farm.
Because SSL Relay requires you to store certificates on each server, it may be less convenient for larger environments. If
your farm has more than five servers and you are concerned with internal threats, you may prefer to use the Secure
Gateway with an internal firewall.
Government Ciphersuites
You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography to protect
"sensitive but unclassified" data by using the applicable ciphersuite:
RSA_WIT H_3DES_EDE_CBC_SHA supports RSA key exchange and T ripleDES encryption, as defined in Internet RFC
2246 (http://www.ietf.org/rfc/rfc2246.txt).
RSA_WIT H_AES_128_CBC_SHA supports RSA key exchange with Advanced Encryption Standard (AES) and 128-bit keys
for T LS connections, as defined in FIPS 197 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf and Internet RFC
3268 (http://www.ietf.org/rfc/rfc3268.txt). For more information about AES, see
http://csrc.nist.gov/archive/aes/index1.html.
RSA_WIT H_AES_256_CBC_SHA supports RSA key exchange with AES and 256-bit keys for T LS connections, as defined
in FIPS 197 and RFC 3268.
IP Security
IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that provides authenticated and encrypted
communications with data integrity and replay protection. IPSec is described in Internet RFC 2401.
IPSec is a network-layer protocol set, so higher level protocols such as Citrix Independent Computing Architecture (ICA) can
use it without modification. Microsoft Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server
2008, and Windows Server 2003 have built-in support for IPSec.
Although not illustrated in the sample deployments, you can use IPSec to secure a XenApp deployment within a virtual
private network (VPN) environment.
Citrix Single Sign-on increases application security for all XenApp applications, allowing organizations to centralize password
management while providing users with fast sign-on access to Web, Windows, and host-based applications.
Smart Cards
You can use smart cards with XenApp, supported XenApp plug-ins, the Web Interface, and Single Sign-on to provide secure
access to applications and data. Using smart cards simplifies the authentication process while enhancing logon security.
XenApp supports smart card authentication to published applications, including “smart card-enabled” applications such as
Microsoft Outlook.
In a business network, smart cards are an effective implementation of public key technology and can be used for the
following purposes:
For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a
smart card reader attached to the client device in order to log on to a XenApp server. After users are authenticated to the
application, they can digitally sign email using certificates stored on their smart cards.
Note: T he availability of some smart card features depends on the smart card cryptographic service provider (CSP).
Secure Use of Smart Cards
Your organization may have specific security policies concerning the use of smart cards. T hese policies may, for example,
state how smart cards are issued and how users should safeguard them. Some aspects of these policies may need to be
reassessed in a XenApp environment:
T asks performed by smart card administrators (for example smart card issuance) may be inappropriate for carrying out
through XenApp. Usually these functions are performed at a dedicated smart card station, and may require two smart
card readers.
Infrequent and sensitive tasks, such as unblocking a smart card, may also be inappropriate for carrying out through
XenApp. Security policies often forbid users to perform these functions; they are carried out by the smart card
administrator.
Note: Citrix recommends that you carry out these tasks locally on the user device if possible, rather than using XenApp.
Highly sensitive applications that require strict separation of duties or tamper-resistant audit trails may entail additional
special-purpose security control measures. T hese measures are outside the scope of XenApp.
You can reset PINs from the desktop using Microsoft Identity Lifecycle Manager (ILM) and Certificate Lifecycle Manager
(CLM) smart card management systems, or using any smart card vendor's reset utilities that use the Windows smart card
PC/SC (WinSCard) API.
XenApp supports various smart cards, including the Common Access Card in a deployment that includes the Citrix Receiver
for Windows. Contact your Common Access Card vendor or Citrix representative for more information about supported
versions of Common Access Card hardware and software.
Citrix continues to test smart cards to address compatibility with XenApp, using certificates from common certificate
authorities such as those supported by Microsoft. If you have any concerns regarding your certificate authority and
compatibility with XenApp, contact your local Citrix representative.
Kerberos Authentication
Kerberos is an authentication protocol. Version 5 of this protocol was first standardized as Internet RFC 1510. Many
operating systems, including Microsoft Windows 2000 and later, support Kerberos as a standard feature.
T his authentication exchange is performed within a Citrix Independent Computing Architecture (ICA) virtual channel and
does not require any additional protocols or ports. T he authentication exchange is independent of the logon method, so it
can be used with passwords, smart cards, or biometrics.
To use Kerberos authentication with XenApp, both the client and server must be appropriately configured. You can also use
Microsoft Active Directory Group Policy to selectively disable Kerberos authentication for specific users and servers.
For information on implementing Kerberos Authentication in a XenApp environment, see Knowledge Center article
CT X121918.
T he Receiver is available for Windows, Windows CE, Macintosh, Linux, Solaris, Android, Blackberry, and iOS operating
systems, as well as the Java Runtime Environment. Additionally, you can use the online plug-in Web with web browsers that
support ActiveX controls or Netscape plug-ins.
Receiver for Windows and the online plug-in use cryptographic modules provided by the operating system. Other plug-ins,
including Receiver for Java, contain their own cryptographic modules. Receiver for Java can, therefore, be used on older
Windows operating systems that do not support strong encryption.
T he Standards Summary table lists the latest versions of the Receiver available on various platforms and indicates whether
each plug-in is FIPS 140 compliant, supports T LS, uses 3DES or AES government ciphersuites, supports certificate revocation
checking, includes smart card support, or supports Kerberos authentication.
Standards Summary
For a list of the security standards relevant to the Receiver and the online plug-in, see
http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/citrix-receiver-feature-matrix.pdf.
T he table below shows the root certificate source for each version of the Receiver or online plug-in.
Receiver for Windows CE for Handheld and Pocket operating system certificate store
PCs 11.02
T his diagram shows the deployment that uses the SSL Relay.
T he following table lists the components of the deployment and the operating systems required for the servers and user
devices.
XenApp f arm XenApp 6.5 for Microsoft Windows Server Windows Server 2008 R2
2008 R2
Windows XP Professional
T his deployment provides end-to-end encryption of the communication between the user device and the XenApp servers.
Both the SSL Relay and the appropriate server certificate must be installed and configured on each server in the farm.
T he SSL Relay operates as an intermediary in communication between user devices and the XML Service on each server.
Each user device authenticates the SSL Relay by checking the SSL Relay’s server certificate against a list of trusted
certificate authorities. After this authentication, the user device and the SSL Relay negotiate requests in encrypted form.
T he SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent from the servers to the
user device passes through the SSL Relay, which encrypts the data and forwards it to the user device to be decrypted.
Message integrity checks verify that each communication has not been tampered with.
SSL/T LS support and the supported ciphersuites can also be controlled using the Microsoft security option System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations:
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
For more information, see the documentation for your operating system.
SSL/TLS Support
You can configure XenApp to use either the Secure Sockets Layer 3.0 protocol or the Transport Layer Security 1.0 protocol.
In sample deployment A, the components are configured for T LS. When using the SSL Relay Configuration Tool, ensure that
T LS is selected on the Connection tab.
Supported Ciphersuites
In this deployment, XenApp can be configured to use government-approved cryptography, such as the ciphersuite
RSA_WIT H_3DES_EDE_CBC_SHA, to protect “sensitive but unclassified” data. When using the SSL Relay Configuration
Tool, ensure that only GOV is selected on the Ciphersuite tab.
For T LS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced
Encryption Standard (AES).
T he following table lists the components of the deployment and the operating systems required for the servers and user
devices.
XenApp f arm XenApp 6.5 for Microsoft Windows Server Windows Server 2008 R2
2008 R2
Web server Web Interface 5.4 for Internet Information Windows Server 2008 R2
Services
Windows Server 2008
Secure Gateway Secure Gateway 3.3 for Windows Windows Server 2008 R2
server
Windows Server 2008
Windows XP Professional
Use T LS to secure the connections between user devices and the Secure Gateway. To do this, deploy SSL/T LS-enabled
plug-ins and configure the Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ).
You ca secure the connections between users’ seb browsers and the Web Interface by using the secure protocol HT T PS.
Additionally, secure communication between the Web Interface and the XenApp servers using T LS.
In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and
provides a single point of encryption and access to the farm. T he Secure Gateway does this by providing a gateway that is
separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in
and out of the firewalls.
While this deployment is highly scalable, the trade-off is that ICA communication is encrypted only between user devices
and the Secure Gateway, not between the Secure Gateway and the XenApp servers.
Note: T he SSL Relay In this deployment is used to encrypt communication between the Web Interface and the XML
Service running on the XenApp servers. T he Secure Gateway communicates with the XenApp servers directly, so the SSL
Relay is not used for communication between the Secure Gateway and the server farm.
You can secure the communication between the Secure Gateway and the server farm using IPSec, as shown in this
T his diagram shows a detailed view of this deployment, which includes IPSec.
IPSec
To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure
IPSec on each server, including the Secure Gateway server.
IPSec is configured using the local security settings (IP security policies) for each server. In this deployment, IPSec is enabled
on the requisite servers and the security method is configured for Triple DES encryption and SHA-1 integrity to meet FIPS
140 requirements.
SSL/T LS support and the supported ciphersuites can also be controlled using the Microsoft security option System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations:
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
For more information, see the documentation for your operating system.
For T LS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced
Encryption Standard (AES).
Plug-ins Used
In this deployment, users access their applications using Citrix Receiver. For more information about the security features
and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.
T he following table lists the components of the deployment and the operating systems required for the servers and user
devices.
XenApp f arm XenApp 6.5 for Microsoft Windows Server Windows Server 2008 R2
2008 R2
Web server Web Interface 5.4 for Internet Information Windows Server 2008 R2
Services
Windows Server 2008
Windows XP Professional
You can use T LS to secure the connections between user devices and the Secure Gateway. To do this, deploy SSL/T LS-
enabled plug-ins and configure the Secure Gateway at the network perimeter, typically in a DMZ.
Here, the DMZ is divided into two sections by an additional firewall. T he server running the Secure Gateway Service is
located in the first section of the DMZ; the Web Interface and the Secure Gateway Proxy are located in the second
section. Communication between the Secure Gateway Proxy and the server farm is secured by using IPSec.
In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and
provides a single point of encryption and access to the farm. T he Secure Gateway does this by providing a gateway that is
separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in
and out of the firewalls.
Security Considerations
IPSec
To enable IPSec to secure communication between the Secure Gateway Proxy and the XenApp server farm, you must
configure IPSec on each server, including the Secure Gateway Proxy.
IPSec is configured by using the local security settings (IP security policies) for each server. In this deployment, IPSec is
SSL/T LS support and the supported ciphersuites can also be controlled using the Microsoft security option System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations:
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
For more information, see the documentation for your operating system.
SSL/TLS Support
You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the
Secure Sockets Layer 3.0 protocol. In this deployment, the components are configured for T LS.
Supported Ciphersuites
In this deployment, Secure Gateway, the Secure Gateway Proxy, and the Web Interface can be configured to use
government-approved cryptography, such as the ciphersuite RSA_WIT H_3DES_EDE_CBC_SHA, to protect “sensitive but
unclassified” data.
For T LS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced
Encryption Standard (AES).
Plug-ins Used
In this deployment, users access their applications using Citrix Receiver. For more information about the security features
and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins Seciurity.
T his diagram shows deploying with SSL Relay and the Web Interface.
T he following table lists the components of the deployment and the operating systems required for the servers and user
devices.
XenApp f arm XenApp 6.5 for Microsoft Windows Server Windows Server 2008 R2
2008 R2
Web server Web Interface 5.4 for Internet Information Windows Server 2008 R2
Services
Windows Server 2008
Windows XP Professional
Use HT T PS to secure the connections between users’ Web browsers and the Web Interface. Secure the connection
between the Web Interface and the SSL Relay using T LS. Additionally, use T LS to secure the connections between user
devices and the SSL Relay.
T he SSL Relay operates as an intermediary in communication between user devices, the Web Interface, and the XML
Service on each server. Each user device authenticates the SSL Relay by checking the SSL Relay’s server certificate against a
list of trusted certificate authorities. After this authentication, the user device and the SSL Relay negotiate requests in
encrypted form. T he SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent from the
servers to the user device passes through the SSL Relay, which encrypts the data and forwards it to the user device to be
decrypted. Message integrity checks verify that each communication has not been tampered with.
T his diagram shows a detailed view of SSL Relay with the Web Interface.
Security Considerations
SSL/T LS support and the supported ciphersuites can also be controlled using the Microsoft security option System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations:
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
For more information, see the documentation for your operating system.
SSL/TLS Support
You can configure the SSL Relay and the Web Interface to use either the Secure Sockets Layer 3.0 protocol or the
Transport Layer Security 1.0 protocol. In this deployment, the components are configured for T LS.
When using the SSL Relay Configuration Tool, ensure that T LS is selected on the Connection tab.
For T LS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced
Encryption Standard (AES).
Plug-ins Used
In this deployment, users access their applications using Citrix Receiver. For more information about the security features
and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.
See the Citrix Single Sign-on documentation for further information about the Citrix Single Sign-on components in this
deployment.
T his diagram shows a Citrix Single Sign-on and the Secure Gateway deployment.
Note: T he Single Sign-on central store is hosted on two servers (primary and secondary) and both servers are running Active
Directory. T he secondary server is only used to provide failover for the primary server.
T he following table lists the components of the deployment and the operating systems required for the servers and user
devices.
XenApp f arm XenApp 6.5 for Microsoft Windows Server Windows Server 2008 R2
2008
Java 1.4.x or later
SSL Relay not enabled
Citrix Single Sign- Citrix Single Sign-on 5.0 Service Windows Server 2008 R2
on Service
Citrix Single Sign- Citrix Single Sign-on 5.0 central store Windows Server 2008 R2
on central store
Windows Server 2008
Web server Web Interface 5.4 for Internet Information Windows Server 2008 R2
Services
Windows Server 2008
Secure Gateway Secure Gateway 3.3 for Windows Windows Server 2008 R2
server
Windows Server 2008
Windows XP Professional
Use T LS to secure the connections between user devices and the Secure Gateway. To do this, deploy SSL/T LS-enabled
plug-ins and configure the Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ).
Secure the connections between users’ Web browsers and the Web Interface using HT T PS. Additionally, use T LS to secure
communication between the Web Interface and the XenApp server farm, and between the farm and the Citrix Single Sign-
on central store and Single Sign-on service. Secure the communication between the Secure Gateway and the server farm
using IPSec.
In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and
provides a single point of encryption and access to the farm. T he Secure Gateway does this by providing a gateway that is
separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in
Sample deployment E is highly scalable. ICA communication is encrypted between user devices and Secure Gateway, as well
as between the Secure Gateway and the XenApp servers.
Security Considerations
IPSec
To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure
IPSec on each server, including the Secure Gateway server.
IPSec is configured using the local security settings (IP security policies) for each server. In this deployment, IPSec is enabled
on the requisite servers and the security method is configured for Triple DES encryption and SHA-1 integrity to meet FIPS
140 requirements.
SSL/T LS support and the supported ciphersuites can also be controlled using the Microsoft security option System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations:
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
For more information, see the documentation for your operating system.
SSL/TLS Support
In this deployment, you can configure Secure Gateway and the Web Interface to use the Transport Layer Security 1.0
protocol.
Supported Ciphersuites
In this deployment, Secure Gateway and the Web Interface can be configured to use government-approved cryptography,
such as the ciphersuite RSA_WIT H_3DES_EDE_CBC_SHA, to protect “sensitive but unclassified” data.
For T LS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced
Encryption Standard (AES).
Plug-ins Used
In this deployment, users access their applications using Citrix Receiver. For more information about the security features
and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.