XenApp 6 - Citrix Docs...Digital Certificates and the Secure Gateway Smart Auditor System Requirements for SmartAuditor Getting Started with SmartAuditor Planning Your Deployment Scalability

© 1999-2017 Citrix Systems, Inc. All rights reserved. p.1https://docs.citrix.com

Known Issues

System Requirements for XenApp 6 for Windows Server 2008 R2

Designing a XenApp Deployment

Farm Terminology and Concepts

Planning a Successful User Experience

Farm Hardware Considerations

Planning for Applications and Server Loads

Evaluating Application Delivery Methods

Placing Applications on Servers

Determining the Number of XenApp Servers to Deploy

Deciding How Many Farms to Deploy

Planning Controllers

Planning for Accounts and Trust Relationships

Recommendations for Active Directory Environments

Installing and Configuring XenApp

Preparing to Install and Configure XenApp

Installing XenApp Using the Wizard-Based Server Role Manager

Installing XenApp from the Command Line

Configuring XenApp Using the Wizard-based Server Configuration Tool

Configuring XenApp from the Command Line

Preparing for XenApp 6 Imaging and Provisioning

Data Store Database Reference

XenApp Migration Tool

Requirements and Installation

Using the XenApp 6 Migration Tool Cmdlets

Cmdlet Reference

Advanced Cmdlets

XenApp 6

Sep 18 , 2015


Management Consoles and Other Tools

Managing Citrix Administrators

Publishing Resources for Users

Managing Streamed Applications

Configuring Content Redirection

Managing Application Properties

Making Virtual IP Addresses Available to Applications

Working with Citrix Policies

Creating Citrix Policies

Navigating Citrix Policies and Settings

Configuring Policy Settings

Applying Policies

Using Multiple Policies

Determining Which Policies Apply to a Connection

Applying Policies to Access Gateway Connections

Enabling Scanners and Other TWAIN Devices

Policy Settings Reference

ICA Policy Settings

Licensing Policy Settings

Server Session Settings

Server Policy Settings

Virtual IP Policy Settings

XML Service Policy Settings

Managing Session Environments and Connections

Defining User Environments in XenApp

Managing and Monitoring XenApp Sessions

Controlling Client Connections in XenApp

Optimizing User Sessions for XenApp


Securing Server Farms

Securing Client-Server Communications

Configuring SSL/TLS Between Servers and Clients

Securing Network Communications

Using Smart Cards with XenApp

Configuring Kerberos Logon

Logging Administrative Changes to a XenApp Farm

XenApp Service Account Privileges

Maintaining Server Farms

Removing and Reinstalling XenApp

Monitoring Server Performance with Health Monitoring & Recovery

Using Citrix Performance Monitoring Counters

Using Worker Groups for Enhanced Resource Access

Using Preferential Load Balancing

Managing CPU Usage

Deploying virtual memory optimization

Managing Farm Infrastructure

Updating Citrix License Server Settings

Configuring the Citrix XML Service Port and Trust

Understanding XenApp Printing

Planing your Printing Configuration

Configuring and Maintaining XenApp Printing

XenApp Server Utilities Reference

Performance Counters Reference

Enhancing the User Experience with HDX

Management Pack for System Center Operations Manager 2007

System Requirements for the Management Pack

Installing the Management Pack

Security Considerations for the Management Pack


Citrix Managed Objects Included in the Management Pack

Citrix Views Included in the Management Pack

Configuring and Enabling Site-specif ic Monitors

To open the Access Management Console or Delivery Services Console from the Operations Manager Console

Installation Manager


Using the Installation Manager Console

Using Installation Manager PowerShell Cmdlets

Installation Manager Messages Reference

Managing Providers and WMI

Load Management

Power and Capacity Management

Understanding Power and Capacity Management

Installing Power and Capacity Management

Configuring Power and Capacity Management

Power and Capacity Management Task Descriptions

XenApp and Secure Gateway

System Requirements for Secure Gateway

Certif icate Requirements

Deploying the Secure Gateway in a Single-Hop DMZ

Deploying the Secure Gateway in a Double-Hop DMZ

Installing the Secure Gateway and Secure Gateway Proxy

Configuring the Secure Gateway or Secure Gateway Proxy

Managing the Secure Gateway

Performance Counters Available for the Secure Gateway

Generating the Secure Gateway Diagnostics Report

Configuring Firewalls for the Secure Gateway

Ensuring High Availability of the Secure Gateway

Coordinating Keep-Alive Values Between the Secure Gateway and XenApp

Improving Security (Recommendations)


Troubleshooting the Secure Gateway

Digital Certif icates and the Secure Gateway

Smart Auditor

System Requirements for SmartAuditor

Getting Started with SmartAuditor

Planning Your Deployment

Scalability Considerations

Security Recommendations

Installing SmartAuditor

Configuring SmartAuditor to play and record sessions

Granting Access Rights to Users

Creating and Activating Recording Policies

Configuring SmartAuditor Recording

Viewing Recordings

To open and play recordings

Events and bookmarks

Set the playback display

Cache recorded session f iles

Troubleshooting SmartAuditor

Verifying Component Connections

Changing communication protocol

Managing Your Database Records

VM Hosted Apps

Install and Set Up

Manage

Customize

XenApp Connector for Configuration Manager 2007 R2

Systems Requirements for XenApp Connector for Configuration Manager 2007 R2

Install and Set Up XenApp Connector for Configuration Manager 2007 R2

Enabling and Disabling Power and Capacity Management with XenApp Connector for Configuration Manager 2007

R2

Uninstalling XenApp Connector for Configuration Manager 2007 R2


Deploying Applications to XenApp servers

To publish applications with XenApp Connector for Configuration Manager 2007 R2

Maintaining Log Files

XenApp Printing Optimizations

XenApp 6 Security Standards and Deployment Scenarios

Security Considerations in a XenApp Deployment

Sample Deployment with SSL Relay and the Web Interface

Sample Deployment with Secure Gateway (Single Hop)

Sample Deployment with the Secure Gateway (Double Hop)

Sample Deployment with SSL Relay and the Web Interface

Sample Deployment with Single Sign-on and Secure Gateway (Single-Hop)

Citrix SCOM Management Pack for XenApp 6.x

Citrix SCOM Management Pack for License Server


Known Issues

May 07, 2015

Installation Issues

If you install a role component from the Autorun menu by selecting Manually Install Components and then install the

XenApp server role from Autorun, you may be prompted during XenApp role configuration for the location of that

component's server, even though you did not select that component during XenApp server role installation. Re-enter the

server information you specif ied during the manual installation. This also applies during a command-line XenApp role

configuration; you must specify the server information for all the installed components. [#229147]

The Provisioning Services Target Device software resets your network connection during install. As a result, you may see

user interface crashes or other failures if you select this component to install from a network location. Citrix

recommends that you install the Provisioning Services Target Device software using one of the following methods

[#229881]:

Install from a local DVD image or ISO

Copy the installation media locally before performing the installation

Select Manually Install Components from the Autorun menu

Install with a command-line installation

You must install the Provisioning Services role and the Provisioning Services Target Device component on separate

servers. If you select both on the same server, the installation fails. [#229999]

If you install the XenApp server role and then uninstall it , Citrix recommends that you re-image the server with a clean

operating system before installing the XenApp server role again. Re-installation of the XenApp server role on a machine

where it was previously uninstalled may fail in the following conditions [#228363, 224925]:

If you previously created a farm on this machine

If you had IIS installed on the machine previously and/or chose to install XML Service Integration with IIS

If you specify an unsupported Microsoft SQL Server database version during XenApp server role configuration, the

configuration fails but the error message may not state the cause. For supported database versions, see the system

requirements topic and CTX114501. [#225264]

To install the EdgeSight for XenApp Agent, either install it at the same time you install the XenApp server role (and then

restart the server after you configure XenApp), or, if you have already installed the XenApp server role, install the agent

from the installation media using the MSI f ile in Service Monitoring\Installers\Agent\. Then restart the XenApp server. If

you installed the XenApp server role and later installed the EdgeSight for XenApp Agent using the Server Role Manager,

you are not prompted for the agent configuration, and the agent does not report to your EdgeSight server. To provide

the proper configuration in this case, uninstall the agent and reinstall it from the installation media. [#229617, 229778]

If the network connection fails or disconnects during a wizard-based XenApp installation, you may see the error

message "Citrix eXtensible Meta Installer has stopped working." This is typically a non-fatal error; restart the XenApp

Server Role Manager and f inish your installation or configuration. You can also avoid this issue by copying the installation

media locally or installing from the DVD. [#227578]

After installing the Delivery Services Console, if you use the Autorun menu to install Applications on Virtual Machines and

select Install optional components > Upgrade Management Consoles, a separate console is installed, rather than adding

a "VM Hosted Apps" node to the Delivery Services Console. [#226895]

When installing the XenApp server role, if the required IIS role services are deployed on the server and you choose not to

enable IIS integration by deselecting the XML Service IIS Integration component in a wizard-based installation, or by

omitting the XA_IISIntegration option in a command-line installation, you must change the XML service port (to a port

other than 80) when configuring the XenApp role. [#230674]

When you select both the XenApp and Web Interface roles to install, and the IIS role services are not deployed on the

http://support.citrix.com/article/CTX114501


server, the Web Interface role automatically deploys the IIS server roles. However, the XML Service IIS Integration

component checkbox is not selected by default. Either select this checkbox or specify an XML Service port other then

80 when you configure XenApp. [#230683]

Launching the Server Configuration Tool by double-clicking XenAppConfiguration.exe is not supported. Launch the

Server Configuration Tool through the Server Role Manager. [#230819]

When using the Server Role Manager to install and configure the SmartAuditor server role from a network share that

requires authentication, after restarting the server, log on to the network share [#231084]

This issue applies only when installing XenApp on a server running the Simplif ied Chinese Windows Server 2008 R2

operating system.

If you purchased the XenApp Gold Edition, select the Enterprise edition in the XenApp Server Role Installer (if you are

installing XenApp using the command-line installation method, specify the /Enterprise option). The SmartAuditor server is

among the server roles you can select to install . To install the SmartAuditor agent, select Manually Install Components in

the XenApp Autorun menu.

If you are a XenApp Enterprise Edition customer, your Enterprise license does not include the use of the SmartAuditor

feature, even though the selection is offered to you in the XenApp Server Role Installer. The SmartAuditor feature is

available only with XenApp Gold or Platinum editions. [#230245]

XenApp Connector for Configuration Manager 2007 R2 Issues

If you change the name of a worker group in your XenApp deployment and are using Configuration Manager, it creates

a collection based on the new name of the worker group, but the original collection associated with the prior work

group name remains. If you have used the original collection as the target of an advertisement, manually change the

advertisement to target the new collection.

When there are no servers in a target (due to no successful advertisements yet), an error message displays indicating a

browser name error or that no servers were in the collection. This is normal and the error ceases after a server in the

target has a successful advertisement. [#234879]

When using the publishing wizard to specify the command line that launches the application, if the command line

includes quotation marks, type the command line manually instead of browsing to it. [#235821]

Ignore this error message in the Publish.log f ile: "Write-Host : The OS handle's position is not what FileStream expected.

Do not use a handle simultaneously in one FileStream and in Win32 code or another FileStream. This may cause data

loss." This error message does not indicate that XenApp Connector is not functioning properly.

Single Sign-on Issues

Saving a Single sign-on plug-in installation image in the protected directories (for example, C:\ or C:\Windows) on a

computer running Windows 7 results in an installation failure. To avoid this issue, designate a location (for example,

create a folder under C:\ or a user's document folder) in which to save the image. [#224612]

Installing the Single sign-on plug-in with XenApp from the wizard-based Server Role Manager does not allow you to

install and configure optional plug-in features, such as Self-Service and Data Integrity. To successfully install the Single

sign-on plug-in with these features, from the XenApp Autorun menu, click Manually install components > Server

Components > Miscellaneous > Single sign-on > Single sign-on Plug-in. Dialog boxes appear during this installation

process letting you select and configure the features. [#226801]

If you use custom alerts in Citrix Service monitoring for XenApp (formerly Citrix EdgeSight for XenApp), or other event log

rollup utilities, you must change the source name of Citrix Password Manager to Citrix Single Sign-On. [#222720]

The Single sign-on 4.8 plug-in may not start after it has been upgraded from Password Manager Agent 4.5. An error

message appears stating that Syncmgr.vrs is missing. To ensure a successful installation, uninstall Password Manager

Agent 4.5 prior to installing Single sign-on 4.8 plug-in. If the Single sign-on 4.8 plug-in is already installed, run the Repair


feature from the Programs section of the Control Panel. [#230824]

Network credential dialog boxes on Windows Server 2008 R2 and Windows 7 are not recognized by the Citrix Single sign-

on plug-in. Users are not prompted to store their user IDs and passwords. An application template, Windows 7 Network

Authentication Dialog, available from Citrix, resolves this problem for environments where a single set of credentials is

used for each user. [#221161]

Other Known Issues

On Windows Server 2008 R2 platforms, logging off MSN Messenger using the X button on the Messenger window fails

to close the application. When you do so, the application minimizes to the system taskbar, which is not accessible with

Windows Server 2008 R2.

As a workaround, with administrative privileges, you can configure Messenger to run in Windows XP compatibility mode

for all users. To do this, from the Windows Start > All Programs menu, select Windows Live Messenger. From the right-

click menu, select Properties. On the Compatibility tab, choose "Change settings for all users." Then check "Run this

program in compatibility mode for" and choose "Windows XP (Service Pack 3)." [#228845]

When using XenApp in a Novell Directory Services for Windows environment, XenApp servers experience reduced

performance when enumerating published resources and during application launch when resolution to the least-loaded

server occurs. As a workaround, modify the following registry key:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix/IMA\

Value Type: DWORD (32-bit)

Value Name: DisablePasswordExpiryCheck

Be sure to set access control lists (ACLs) for the Network Service account to "Read." When this workaround is

implemented, the number of simultaneous user logons is reduced. Therefore, users might experience longer logon times

during peak usage periods. [#228841]

The Cumulative Server Load counter (available as part of the Citrix MetaFrame Presentation Server performance monitor

counters) might not display the same values as the XenApp command query farm /load (also known as qfarm /load)

when querying the same server running Citrix XenApp if there are pending connections to this server. The counter and

command should display identical information once all sessions are active. [#228466, 228842]

In some instances, when a user launches a published application, two Status Indicator icons might appear on the

Windows Taskbar for the single published application. The second icon disappears after a few seconds. No workaround

exists for this issue and it does not interfere with published application functionality. [#221203]

If an administrator specif ies a specif ic Windows theme for users through a Personalization group policy template, the

Windows theme might not appear to be applied when launching a published application configured for seamless or non-

seamless windows. (Any configured themes are correctly applied when launching published desktop.) To ensure themes

are applied, administrators can modify the Windows registry. For details, see CTX124407 in the Citrix Knowledge Center.

[#228080]

On XenApp servers running the German language version of Windows, after configuring Citrix policy settings for a Group

Policy Object, the Settings report for the Group Policy Object does not display the Citrix policy setting values when

generated. As a workaround, use a language version of Windows other than German to view the policy settings values.

[#223303]

The Group Policy Results report does not include Citrix policy settings when run on a Group Policy Object (GPO) that

meets one of the following conditions:

The GPO contains both a Citrix administrative template (.adm) and Citrix policy settings

The GPO containing Citrix policy settings inherits the settings of another GPO that contains a Citrix administrative

template

To resolve this issue, use separate GPOs for Citrix policy settings and administrative templates and ensure these GPOs do



not inherit settings. [#230497]

In user environments where Citrix Receiver is installed and Microsoft Windows 7 Specialized Security Limited

Functionality (SSLF) templates are applied, Citrix Receiver might not run automatically at user logon or startup.

Additionally, any installed Citrix plug-in and client software might not launch automatically at user logon or startup. The

suggested workaround for this scenario for administrators is to remove the CitrixReceiver entry from the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and deploy the Citrix Receiver software

through the user's Startup shortcut. [#230500]

When installing the Citrix online plug-in on a user device, pass-through authentication is not automatically configured. To

ensure pass-through authentication is enabled for users accessing XenApp Services sites:

1. On the XenApp server, enable the pass-through authentication method for the XenApp Services site.

2. Ensure that on the user device, Internet Explorer has the URL to Web Interface added to the local Intranet Zone.

3. On the user device, add the icaclient.adm file using the Group Policy Editor and configure the following settings:

Enable Local user name and password and then select Enable pass-through authentication

Disable Kerberos authentication

4. After configuration, run gpupdate /force, log off the user device, and log back on.

For detailed instructions about configuring these settings, see CTX113004 in the Citrix Knowledge Center. [#230082,

230078]

When using Remote Desktop IP Virtualization in per session mode on servers with dual network adapters, virtual IPs are

not assigned when sessions are created. This is an issue in Windows Server 2008 R2 that might occur if you use virtual IPs

with XenApp. To work around this issue, configure Remote Desktop IP Virtualization to assign virtual IPs on a per

program basis. [#228288]

The "Pass-through with smart card from Access Gateway" feature cannot be used with XenApp 6.0. Because of an issue

with XenApp 6.0, smart card users logging on to Access Gateway integrated XenApp Web sites are unable to access

resources when the pass-through with smart card from Access Gateway feature is enabled. Users clicking on a link in the

XenApp Web site to access a resource delivered by XenApp 6.0 see the error message "An error occurred while making

the requested connection." You can avoid this issue by configuring the site to prompt smart card users for their PIN each

time they access a resource. [#230942]

Changes to worker groups might not be reflected accurately in the registry when a worker group is renamed or deleted.

The registry entry for the worker group in

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\WorkerGroups subkey is not automatically updated.

[#231048]

As a workaround:

1. Create a new temporary worker group with all servers in the farm, which forces the registry to update for the

renamed or deleted worker groups.

2. Delete the temporary worker group.

When generating the Settings report of a Group Policy Object (GPO) linked to the domain, the Group Policy

Management console stops working. To work around this issue, access the original GPO, under the Group Policy Objects

node, to generate the Settings report. [#261163]

For changes to Health Monitoring and Recovery to take effect, in Windows Component Services, Services (Local), restart

the Citrix Health Monitoring and Recovery Service. [230902]

For instructions about creating server-side content fetching whitelists for HDX MediaStream for Flash, search Citrix

eDocs (this Web site) for the topic "Configuring HDX MediaStream for Flash on the User Device." Instructions found in

the HDX administrative templates are outdated. [#229985]

Windows Media Player, when installed on a XenApp server, occasionally hides video behind a black Media Player screen



on a user device running Windows 7. To correct this, users should change their Media Player view to Skin Mode.

Alternatively, they can minimize and maximize the Media Player (more than once might be necessary) to refresh the

video. [#230238]

Installing the HDX MediaStream for Flash version 1.1.0 package (CitrixHDXMediaStreamForFlash-ServerInstall.msi) using

Active Directory Software Installation might fail. To prevent this failure, use a start-up script to deploy the package.

[#229263]

After performing a Repair on Citrix HDX MediaStream for Flash-Server, the HDX MediaStream for Flash service might fail

to restart. To avoid this issue, uninstall Citrix HDX MediaStream for Flash - Server and reinstall it . [#228502]

The Session Shadowing feature in XenApp 6 is supported only in single-monitor configurations for both computers. If

either the shadowing or shadowed computer is configured with multiple monitors, shadowing is not supported.

[#251490]


System Requirements for XenApp 6 for WindowsServer 2008 R2

Dec 06, 2011

System requirements for XenApp features and related technologies are described in their respective System Requirements

documentation; that includes plug-ins and agents, Web Interface, Single Sign-on, Service Monitoring, EdgeSight,

SmartAuditor, Application Session Recording, Provisioning Services, and Power and Capacity Management.

Citrix recommends using the latest Citrix License Server.

To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your users, install the

most recent version of any plug-ins you use.

Important: Do not join servers running XenApp 6 for Windows Server 2008 R2 to a deployment with servers running previousversions of XenApp.

Deploying Prerequisites

During a wizard-based installation, the XenApp Server Role Manager (using the Server Role Installer), automatically installs

prerequisites for the selected roles.

For command-line installations, deploy the prerequisites before initiating XenApp role installation. Citrix recommends you

deploy prerequisites (such as IIS role services) using the Microsoft ServerManagerCmd.exe command or Powershell, which

Microsoft provides for Windows operating system roles.

XenApp for Windows Server 2008 R2

Supported operating system: Microsoft Windows Server 2008 R2, except the Web Server edition and the core installation

option.

Most servers running Microsoft Windows Server 2008 R2 meet the hardware requirements for XenApp with ampleprocessing power to host user sessions accessing the published resources. However, additional research may be needed todetermine if current hardware meets the requirements.

Technology Requirement

CPU 64-bit architecture with Intel Pentium

Xeon family with Intel Extended Memory 64 Technology

AMD Opteron family

AMD Athlon 64 family

Compatible processor

Memory 512MB RAM (minimum)

Disk space Up to 3.2GB

The XenApp Server Role Manager deploys the following software (except as noted), if it is not already installed:.NET Framework 3.5 SP1 (this is a prerequisite for the XenApp Server Role Manager; it is deployed automatically when


you choose to add the XenApp server role from the Autorun menu)

Windows Server Remote Desktop Services role (if you do not have this prerequisite installed, the Server Role Manager

installs it and enables the RDP client connection option; you will be asked to restart the server and resume the

installation when you log on again)

Windows Application Server role

Microsoft Visual C++ 2005 SP1 Redistributable (x64)


If the server already has the following IIS role services installed, the Citrix XML Service IIS Integration component is selectedby default in the wizard-based XenApp installation, and the Citrix XML Service and IIS share a port (default = 80). If the IISrole services are not installed, the Citrix XML Service IIS Integration component is not selected by default in the wizard-based installation. In this case, if you select the checkbox, the Server Role Manager installs the following IIS role services. (Ifyou do not install these services, the Citrix XML Service defaults to standalone mode with its own port settings, which youcan configure using the XenApp Server Configuration Tool.)

Web Server (IIS) > Common HTTP Features > Default Document (selecting this role service automatically selects Web

Server (IIS) > Management Tools > Management Console, which is not required or checked for XenApp installation)

Web Server (IIS) > Application Development > ASP.NET (selecting this role service automatically selects Web Server (IIS) >

Application Development > .NET Extensibility; although not checked for XenApp installation, .NET Extensibility is required

by ASP.NET)

Web Server (IIS) > Application Development > ISAPI Extensions

Web Server (IIS) > Application Development > ISAPI Filters

Web Server (IIS) > Security > Windows Authentication

Web Server (IIS) > Security > Request Filtering

Web Server (IIS) > Management Tools > IIS 6 Management Compatibility (which includes IIS 6 Metabase Compatibility,

IIS 6 WMI Compatibility, IIS 6 Scripting Tools, and IIS 6 Management Console)

If you plan to use Philips SpeechMike devices with XenApp, you may need to install drivers on the servers hosting sessions

that record audio, before installing XenApp. For more information, see Citrix information on the Philips web site.

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

XenApp server role installation.

Important: Do not install XenApp on a domain controller. Citrix does not support installing XenApp on a domain controller.

XenApp Management

XenApp Management includes the Delivery Services Console. By default, the console is installed on the same server where

you install the XenApp server role; however, you can install and run the console on a separate computer. To install the

Delivery Services Console on a workstation, from the XenApp Autorun menu, select Manually Install Components >

Common Components > Management Consoles.

Supported operating systems:Windows Server 2008 R2

Windows Server 2008

Windows Server 2003 (Standard, Datacenter, and Enterprise editions)

Windows Server 2003, 32-bit edition, with Service Pack 2

Windows Server 2003, 64-bit edition

Windows Server 2003 R2, 32-bit edition

Windows XP Professional

Windows XP Professional, 32-bit edition, with Service Pack 3


Windows XP Professional, 64-bit edition, with Service Pack 2

Windows Vista (Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions, with Service Pack 1

Windows 7, 32-bit and 64-bit editions

Requirements:Disk space: 25MB

Microsoft Management Console (MMC):

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

For other supported Windows operating systems: MMC 2.0 or 3.0

The XenApp Server Role Manager deploys the following software, if it is not already installed:Microsoft .NET Framework 3.5 SP1

Microsoft Windows Installer (MSI) 3.0

Microsoft Windows Group Policy Management Console



Microsoft Visual C++ 2008 SP1 Redistributable

Microsoft Visual C++ 2005 SP1 Redistributable

Microsoft Primary Interoperability Assemblies 2005

If you install the Delivery Services Console on a computer that previously contained the Microsoft Group Policy

Management Console (GPMC) and an earlier version of the Delivery Services Console, you may also need to uninstall and

reinstall the Citrix XenApp Group Policy Management Experience (x64) program in order to use the GPMC to configure Citrix

policies.

Data Store Databases

The following databases are supported for the data store:Microsoft SQL Server 2008 Express (can be deployed for you by the XenApp Server Configuration Tool when creating a

new XenApp farm)

Microsoft SQL Server 2005

Microsoft SQL Server 2008

Oracle 11g R2

For information about the latest supported versions, see CTX114501.



Designing a XenApp Deployment

May 16, 2015

XenApp is the central software component of the Citrix Windows Application Delivery Infrastructure. The goals of XenApp

and the Citrix Windows Application Delivery Infrastructure are to deliver on-demand applications to both physical and virtual

desktops, and to determine and provide the best method of delivery. XenApp offers three methods for delivering

applications to user devices, servers, and virtual desktops:

Server-side application virtualization: applications run inside the Data Center. XenApp presents each application interface

on the user device, and relays user actions from the device, such as keystrokes and mouse actions, back to the

application.

Client-side application virtualization: XenApp streams applications on demand to the user device from the Data Center

and runs the application on the user device.

VM hosted application virtualization: problematic applications or those requiring specif ic operating systems run inside a

desktop in the Data Center. XenApp presents each application interface on the user device and relays user actions from

the device, such as keystrokes and mouse actions, back to the application.

To provide these types of application delivery, you have many choices of deployment designs and XenApp features, whichyou 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 andCitrix Dazzle), Access Infrastructure, and Virtualization Infrastructure.

On the left of this diagram are Citrix Dazzle and Citrix Receiver, which represent the set of devices on which you can

install client software. Citrix Dazzle provides your users with a selection of applications you have made available to them.

Citrix Receiver manages the client software plug-ins that enable your users to interact with virtualized applications.

When designing a XenApp deployment, you consider how your users work, their devices, and their locations.

Access Infrastructure represents secure entry points deployed within your DMZ and provide access to resources

published on XenApp servers. When designing a XenApp deployment, you provide secure access points for the different


types of users in your organization.

Virtualization Infrastructure represents a series of servers that control and monitor application environments. When

designing a XenApp deployment, you consider how applications are deployed based on your user types and their devices,

the number of servers you need, and which features you want to enable in order to provide the support, monitoring, and

management your organization requires.

The following diagram shows the access infrastructure in greater detail.

In this access infrastructure diagram:All of your users use Citrix Dazzle to choose applications they want to run. Citrix Receiver plug-ins run them.

Onsite users within your corporate f irewall interact directly with the XenApp Web and Services Site.

Remote-site users access applications through sites replicated by Citrix Branch Repeater.

Off-site users access applications though secure access, such as Access Gateway.

The Merchandising Server makes available self-service applications to your users through Citrix Dazzle.

EasyCall Voice Services enables your users to initiate telephone calls by clicking on telephone numbers displayed in their

applications.

The XML Service relays requests and information between the Access Infrastructure and the Virtualization

Infrastructure.

The following diagram shows the virtualization infrastructure in greater detail.


In this virtualization infrastructure diagram:The XML service relays information and requests.

Based on Active Directory profiles and policies, the XenApp servers invoke the correct application delivery type for the

user. The XenApp servers provide server-side application virtualization and session management. Session and deployment

configuration information are stored in data collectors and a central data store represented by the deployment data

store.

The App Hub provides Streamed Application Profiles, which are client-side virtualization applications housed in your

enterprise storage.

The VM Hosted Apps server isolates problematic applications inside a seamless desktop, which, depending on the user

profile, can be virtualized on the user device or on the server. The desktop images are provisioned through Provisioning

Server. Session and server configuration information are stored in the deployment data store.

Provisioning Services delivers desktops to servers, which are stored as desktop images in your image repository.

SmartAuditor provides session monitoring. Recorded sessions are stored in your enterprise storage and configuration

information is stored in the deployment data store.

Service Monitoring enables you to test server loads so you can estimate how many servers you need for your

deployment and to monitor those servers once they are deployed.

Power and Capacity Management enables you to reduce power consumption and manage server capacity by

dynamically scaling the number of online servers.

Single Sign-on provides password management for virtualized applications. Passwords are stored in the account

authority.

Planning for System Monitoring and Maintenance

When designing your XenApp farm, include a monitoring and management strategy to ensure the sustainability of your

environment. Consider incorporating one or more monitoring tools into your environment and customizing them to provide

alerts based on metrics associated with hardware, software, and usage requirements.

Designing for monitoring and management should include hardware, software, performance, and network areas. For

hardware monitoring, Citrix recommends the hardware management tools provided by most server vendors.

Citrix EdgeSight is an excellent technology for monitoring XenApp farms. Citrix suggests customizing the default Resource

Manager and EdgeSight metrics to meet your specific monitoring needs.


Farm Terminology and Concepts

Jul 29, 2011

Terminology

The XenApp planning documentation uses the following terminology:Multi-user environment

An environment, including XenApp and Remote Desktop Services, where applications are published on servers for use by

multiple users simultaneously.

Production farm

A farm that is in regular use and accessed by users.

Design validation farm

A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm.

Pilot farm

A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is

based on access by select users, and then adding users until all users access the farm for their everyday needs.

About Controllers

XenApp farms have two types of infrastructures:The virtualization infrastructure consists of the XenApp servers that deliver virtualized applications and VM hosted

Applications, and controllers that support sessions and administration, such as the data store, data collector, Citrix XML

Broker, Citrix License Server, Configuration Logging database (optional), Load Testing Services database (optional), and

Service Monitoring components.

Access infrastructure consists of controllers such as the Web Interface, Secure Gateway (optional), and Access Gateway

(optional) that provide access administration.

In small deployments, you can group one or more controllers together. In large deployments, you provide services on one or

more dedicated servers.

Factors other than size can affect how you group controllers. Security concerns, virtualized servers, and user load play a

part in determining which functions can be collocated.

Typically, in larger farms, you segregate the controller functions onto distinct servers. For small farms, you might have one

controller server hosting infrastructure functions and multiple worker servers hosting published applications.

Small farms that require redundancy might have one or two servers hosting controllers. For example, in a small farm, the

data store might be configured on the same server as the data collector and the XML Broker and, perhaps also the Citrix

License Server and the Web Interface.

Medium and large farms might group controllers and services together when they have similar functions. For example, the

XML Broker might be grouped with the data collector. In some larger deployments, each infrastructure service would likely

have one or more dedicated servers. In large farms, the Citrix License Server and the Web Interface are typically hosted on

separate servers.

About Virtualization Infrastructure

The virtualization infrastructure, which is the center of a XenApp deployment, concerns the following concepts:


Application enumeration

Application enumeration is when Citrix client software lists virtualized applications available on the XenApp servers. The

client software transmits data to locate servers on the network and retrieves information about the published applications.

For example, during enumeration, the XenApp online plug-in communicates through Citrix XML Service with the XenApp

server to determine applications available for that user.

Application publishing

To deliver an application to your users through Citrix Dazzle and the XenApp online or off line plug-ins, whether virtualized

on the desktop or the server, you use the Delivery Services Console to publish the application.

Citrix Licensing

A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone

server, depending on your farm’s size. After you install the license server, download the appropriate license f iles and add

these to the license server.

Data Store

The data store is the database where servers store farm static information, such as configuration information about

published applications, users, printers, and servers. Each server farm has a single data store.

Data Collector

A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the

zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive

incremental data updates and queries from servers within the zone. Data collectors relay information to all other data

collectors in the farm. By default, the f irst server in the farm functions as the data collector.

By default, the data collector is configured on the f irst farm server when you create the farm and all other servers are

configured with equal rights to become the data collector if the data collector fails. When the zone’s data collector fails, a

data collector election occurs and another server takes over the data collector functionality. Farms determine the data

collector based on the election preferences set for a server.

The data collector is a controller and applications are typically not published on it.

Zones

A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones,

each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as

communication gateways with the other zone data collectors.

The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone,

even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary

only in large farms that span WANs.

Streaming Prof iles

You can deliver applications to users by either virtualizing them on the desktop (streaming) or by virtualizing them on the

server (hosting). If you are virtualizing applications on the desktop, either streaming to the client or server, create a

streaming profile server in your environment. To virtualize applications on the desktop, you create profiles of the application

and then store the profile on a f ile or Web server. The profile consists of the manifest f ile (.profile), which is an XML f ile that

defines the profile, as well as the target f iles, a hash key f ile, the icons repository (Icondata.bin), and a scripts folder for pre-

launch and post-exit scripts.

Web Interface

The Web Interface is a required component in any environment where users access their applications using either the online

plug-in or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the

Web Interface is sometimes collocated with other functions..

XenApp Web and XenApp Services Sites

XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services


sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp

Web or XenApp Services site, either directly or through the XenApp plug-in or the Access Gateway, the site:

Forwards the user’s credentials to the Citrix XML Service

Receives the set of applications available to that user by means of the XML Service

Displays the available applications to the user either through a Web page or by placing shortcuts directly on the user’s

computer

Citrix XML Service and the Citrix XML Broker

The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a

user authenticates to the Web Interface, the XML Broker:

Receives the user’s credentials from the Web Interface and queries the server farm for a list of published applications

that the user has permission to access. The XML Broker retrieves this application set from the Independent

Management Architecture (IMA) system and returns it to the Web Interface.

Upon receiving the user’s request to launch an application, the broker locates the servers in the farm that host this

application and identif ies which of these is the optimal server to service this connection based on several factors. The

XML Broker returns the address of this server to the Web Interface.

The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on every server during

XenApp installation. However, only the XML Service on the server specif ied in the Web Interface functions as the broker.

(The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the

XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker

might be configured on one or more dedicated servers.

The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is

used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service,

regardless of whether it is hosted on a dedicated server or collocated with other controller functions.


Planning a Successful User Experience

Feb 17, 2010

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

how easily users can print.

Session Start-up Times

Certain factors can cause sessions to start slower than necessary.Printer autocreation policy settings - Consider limiting the number of printers that are autocreated if session start time is

a factor.

Network activities occurring independently of sessions - Operations such as logging on to Active Directory, querying

Lightweight Directory Access Protocol (LDAP) directory servers, loading user profiles, executing logon scripts, mapping

network drives, and writing environment variables to the registry, can affect session start times. Also, connection speed

and programs in the Startup items within the session, such as virus scanners, can affect start times.

Roaming profile size and location - When a user logs onto a session where Microsoft roaming profiles and home folders

are enabled, the roaming profile contents and access to that folder are mapped during logon, which uses additional

resources. In some cases, this can consume signif icant amounts of the CPU usage. Consider using home folders with

redirected personal folders to mitigate this problem.

Whether the data collector has suff icient resources to make load balancing decisions eff iciently - In environments with

collocated infrastructure servers, Citrix suggests hosting the Citrix XML Broker on the data collector to avoid delays.

License server location - For WANs with multiple zones, where the license server is in relation to the zone.

Printing Configuration

Your printing configuration directly affects how long sessions take to start and the traffic on your network. Planning your

printing configuration includes determining the printing pathway to use, how to provision printers in sessions, and how to

maintain printer drivers.

Consider these recommendations:Use Citrix Universal printer drivers and the Universal Printer whenever possible. This results in fewer drivers and less

troubleshooting.

Disable the automatic installation of printer drivers, which is the default setting.

Adjust printer bandwidth using XenApp policy rules, if appropriate.

If printing across a WAN, use the XenApp Print job routing policy rule to route print jobs through the client device.

Test new printers with the Stress Printers utility, which is described in the Citrix Knowledge Center.

Choose printers that are tested with multiuser environments. Printers must be PCL or PS compatible and not host-based.

The printing manufacturer determines whether printers work in a XenApp environment, not Citrix.


Farm Hardware Considerations

Feb 09, 2010

The number of users a XenApp server can support depends on several factors, including:The server’s hardware specif ications

The applications deployed (CPU and memory requirements)

The amount of user input being processed by the applications

The maximum desired resource usage on the server (for example, 90% CPU usage or 80% memory usage)

General recommendations for selecting and configuring farm hardware include:RAID - In multiprocessor configurations, Citrix recommends a RAID (Redundant Array of Independent Disks) setup.

XenApp supports hardware and software RAID.

Reducing hard disk failure - Hard disks are the most common form of hardware failure. You can reduce the likelihood of

hardware failure with a RAID 1 (mirroring) and RAID 5 (striped set with distributed parity) configuration. If RAID is not an

option, a fast Serial Attached SCSI (SAS) or a Small Computer System Interface (SCSI) Ultra-320 drive is recommended.

Disk speed - Faster hard disks are inherently more responsive and might eliminate or curtail disk bottlenecks.

Number of controllers - For quad or eight-way servers, Citrix recommends installing at least two controllers: one for the

operating system and another to store applications and temporary f iles. Isolate the operating system as much as

possible, with no applications installed on its controller. This principle also applies in small farms. If possible (assuming a

multicore or multiprocessor system), install the operating system on a separate hard drive from XenApp and the

applications. This prevents input/output bottlenecks when the operating system needs to access the CPU. Distribute

hard drive access load as evenly as possible across the controllers.

Dual-processor (dual-core) deployments combine overall efficiency and a lower total cost of ownership. However, once a

system has a dual-core processor, implementing additional processors does not necessarily provide proportionate

performance increases. Server scalability does not increase linearly with the number of processors: scalability gains level

off between eight to sixteen CPU cores.

Hard disk partitions - Partition and hard-disk size depend on the number of users connecting to the XenApp server and

the applications on the server. Because each user’s Remote Desktop Services profile is loaded on the server, consider

that large numbers of user profiles can use gigabytes of disk space on the server. You must have enough disk space for

these profiles on the server.


Planning for Applications and Server Loads

Apr 21, 2015

Before you can determine how many servers you need in your farm and on which servers to install applications, decide

which applications you want to deliver and how you want to deliver them.

Consider these factors when defining your farm’s hardware and operating system configuration:Can I run the applications? Citrix recommends testing non-Vista-compliant applications before you publish them on your

farm. Some non-Vista-compliant applications run using the Application Compatibility feature.

How many users do I anticipate will want to connect to each application during peak and off-peak hours? Do I need to

allocate servers for load balancing?

Will users be accessing certain applications frequently? Do I want to publish all of these applications on the same server

to facilitate session sharing and reduce the number of connections to a server? If you want to use session sharing, you

might also want users to run applications in seamless windows. .

Will my organization need to provide proof of regulatory compliance for certain applications? Will any applications

undergo a security audit? If you intend to use SmartAuditor to record sessions on these servers, install the SmartAuditor

agent on these servers. In addition, make sure the servers have suff icient system resources to ensure adequate

performance.

Will any of my applications be graphically intensive? If so, consider using the XenApp SpeedScreen, Memory Utilization

Management, or CPU Utilization Management features as well as more robust hardware for sessions hosted on these

servers.

Assessing Applications for XenApp Compatibility

Ensure applications are compatible with the server operating system and are multiuser compatible. Application compatibility

drives the application delivery method (for example, accessed from the server, streamed to server, or streamed to client

desktops).

Evaluate whether or not applications are compatible with multiuser environments and, if so, the application server’s

scalability. Before testing applications for compatibility, investigate how the application works with Remote Desktop

Services or XenApp. Remote Desktop Services-compliant and Windows Logo certified applications experience few, if any,

issues compared with noncompliant applications.

Initial application compatibility testing typically involves publishing the application so that 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 f ind and f ix the root cause of the problem. To identify rootapplications issues, consider using tools like the Microsoft Application Compatibility Toolkit (ACT) or Microsoft’s WindowsSysinternals. Examples of common issues include:

.INI f iles that contain hard-coded f ile path names, database connection settings, and read/write f ile locking

configurations that need to be reconfigured to prevent f ile conflicts.


Custom applications developed with hard-coded paths in the registry.

Applications that use the computer name or IP address for identif ication purposes. Because a server can run multiple

instances of the application, all instances could use the same IP address or computer name, which can cause the

application to fail.

When you find any of these hard-coded settings or other conflicts, document the setting in your farm design document.

After you find resolutions to these issues, design your farm and test your design by creating a pilot test farm.


Evaluating Application Delivery Methods

Nov 30 , 2010

The application delivery method is a factor in determining the number of servers in a farm and their individual hardware

requirements.

How you choose to deliver applications depends on your organization's needs and end-users' requirements. For example,

some organizations use XenApp to streamline administration. In other organizations, the existing hardware infrastructure

might affect the delivery method selected, as can the types of applications to be delivered. In addition, some end-users

might run all applications while connected to the company network, while others might work in remote locations and run

applications while disconnected from the network.

Method/Description Advantages Considerations

Installed on the server:

Applications are installed on the server, where the processing takes

place, and accessed from the server. This is the traditional XenApp

application delivery model. For many organizations, this provides the

lowest cost of ownership for IT resources because it provides the

greatest scalability.

This method

provides a

consistent user

experience

regardless of the

user device.

You manage

applications

centrally.

User devices do

not require

extensive

resources, such as

excessive memory

or hard drive space.

This delivery

method supports

thin clients.

This method is

effective for

applications with

components that

are intertwined

with the operating

system (such as a

.NET framework).

Farm servers require

sufficient resources

to support the

applications.

Users must be

connected to the

server or network

to run the

applications (no

offline access).

Streamed to server:

Executables for applications are put in profiles and stored on a file

server or Web server (the App Hub); however, when launched, they

stream to the server, and application processing takes place on the

This method has

similar advantages

as for installed

applications,

Farm servers require

sufficient resources

to support the

applications.


server. Unlike installed applications, streamed applications are stored

in the App Hub and provide application isolation by design.

including a

consistent user

experience, central

management, and

use of server

resources instead

of those of the

user device.

In many cases,

streaming to server

lets conflicting

applications, such

as multiple versions

of the same

application, run on

the same server

without needing

to silo them.

Updating

applications is

simplif ied because

you update only a

single application

profile.

Users must be

connected to the

server or network

(no off line access).

Some applications

are not candidates

for profiling, such

as those using a

.NET framework.

Streamed to desktop:

Executables for applications are put in profiles and stored on a file

server or Web server (the App Hub). When launched, the files required

to execute the application are streamed to the user device, and

application processing takes place on the user device instead of the

XenApp server. When applications are streamed to the user device,

the user experience is similar to running applications locally. After

applications are cached on the user device, users can continue

running the apps after disconnecting from the network (referred to

as offline access).

Users can have the

local application

experience, but

you manage the

applications

centrally.

Users might have a

better experience

when resource-

intensive

applications, such

as graphics

applications, are

streamed to

desktops.

Using application

properties and

Citrix policies and

filters for Offline

Applications, you

control the

User devices must

have suff icient

resources to run

the applications

locally; the user

devices cannot be

thin clients.

User devices must

run Windows

operating systems,

including Windows

7, XP, or Vista.



applications and

users that have

offline access, as

well as the license

period for off line

use.

Dual mode delivery:

When you select "streamed if possible, otherwise accessed from a

server" (referred to as dual mode or fallback), XenApp tries to stream

the application to the user device first, but uses the backup access

method if streaming to desktop is not supported on the user device.

For example, you can specify that some users, such as sales

personnel, run applications streamed to desktop when they are

accessing the applications from Windows devices, and run them as

installed applications when they are accessing them from handheld

mobile or kiosk-type devices.

This method

provides the most

versatility for

application

delivery, offering all

the advantages of

streaming to

desktops for

supported user

devices, plus a

backup delivery

method for the

rest.

You control

delivery options

centrally using

Citrix policies and

filters, such as the

server's Load

Balancing Policies

for Streamed App

Delivery.

For the backup

method to occur,

ensure that the

application is either

installed on the

XenApp server or

the streaming

profile is configured

for a target

operating system

that matches the

server.


Choosing Between Published Desktops and Published Applications

Before selecting the method for delivering applications, decide if you want to publish the desktop or publish applications.Publishing the desktop - Presents users with an entire Windows Server desktop when they log onto XenApp. (For

security, the desktop should be locked down .)

Publishing applications - Publishes specif ic applications and delivers only those applications to users. This option provides

greater administrative control and is used most frequently.

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


Placing Applications on Servers

May 01, 2015

When designing your farm, consider the following:The servers on which the applications are installed

If load balancing or preferential load balancing changes your need to dedicate servers to mission-critical or highly used

applications

The geographic location of the servers delivering applications (for WANs and organizations with branch off ices)

Grouping Applications on Servers

Traditionally, two strategies for grouping applications on servers are siloing applications and not siloing applications.

When applications are siloed on farm servers, each server has a limited number of applications. Some servers might have only

one application; others might have a set of interrelated applications. For example, you might install a medical application on

Server A, and on Server B install an enterprise resource planning (ERP) application. However, if the ERP application is

integrated with email, you might also have an email client on Server B. Siloing is sometimes required when applications have

unique hardware requirements, for business reasons, to segregate mission-critical applications, or to separate frequently-

updated applications. However, siloing applications is not as efficient as nonsiloed applications for hardware use and

network traffic.

With a nonsiloed approach, you install all applications on each server. Applications can be installed traditionally or in isolation

(installing them in separate profiles).

Citrix recommends installing applications that interact with each other on the same server, or including them in the same

streaming profile. For example, if an application interacts with an email client by letting users send email notifications, install

the application and the email client on the same server. Likewise, if applications share settings and preferences (such as

Microsoft Office), install them on the same server.

Advantages Disadvantages

Siloed It is easy to track the application’s location and usage

Centralization makes it is easy to configure and maintain

the application

Other applications do not interfere with the installed

application

Can be useful for mission-critical applications

Additional servers are required to ensure

sufficient redundancy

Nonsiloed Reduces the number of servers required for applications

in small- to medium-sized farms

Might simplify user permissions and ensure consistent

settings during application installation

A single server is accessed by each user and session

sharing is ensured

Cannot be used when applications

conflict with other applications

By using features such as Load Manager and Preferential Load Balancing, you might not need to silo mission-critical


applications or applications with high levels of peak usage.

When an application conflicts with other applications, rather than silo it on one server, consider streaming the application.

Streaming the application effectively isolates it, which allows conflicting applications to run on a single server, reducing the

need for silos.

Planning Server Loads

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

Load Manager - Lets you balance new connections to the server. When a user launches the f irst 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 specif ic portion of CPU resources to a specif ic session or application.

You can use Preferential Load Balancing to assign importance levels (Low, Normal, or High) to specif ic users and

applications. For example, doctors in a hospital could be specif ied as important users and MRI scans or X-rays could be

specif ied as important applications. These important users and applications with higher levels of service have more

computing resources available to them. By default, a Normal level of service is assigned to all users and applications.

Different application workloads can co-exist on a server; simply assign important applications a higher importance level.

The key difference between the Load Manager and Preferential Load Balancing features is that the Preferential Load

Balancing can be used to treat each session differently, whereas Load Manager treats each session the same.

Although you can use applications as the basis for Load Manager decisions, Citrix does not recommend it. Citrix

recommends invoking Load Manager based on the server only.

Citrix does not recommend load balancing across zones on a WAN.

Centralizing or Distributing Application Servers

For organizations with geographically dispersed sites, application servers might be located centrally with the infrastructure

servers (for example, in a data center) or decentrally, near the users who access the applications or in the same geographic

region as the users.

Citrix recommends placing application servers logically near any data sources. For example, for an enterprise resource

planning application, collocate those XenApp servers within the same data center. Another example is a multinational

corporation that uses Microsoft Exchange 2007 as the data source for email. Although the company could centralize all

the Exchange servers at the primary data center, they would be more likely to enable the Exchange servers within each

region and then locate the XenApp servers hosting Outlook there as well.


Serverscentralized atone site

Centralized server administration and support.

Centralized application management.

Potentially better physical security than in

Single point of failure; if the site loses

connectivity, users have no alternative access.


branch off ices.

Serversdistributedacrossmultiple sites

Enhanced business continuity and

redundancy; if one site loses connection, it

does not affect all application access.

When data is maintained at different sites,

placing servers at those sites provides users

with local access to the data.

Sites can administer their own servers.

Zone Preference and Failover can be invoked

if multiple zones.

Server-to-server communication crosses the

WAN.

If users need access to multiple sites, you might

need to coordinate and replicate domains,

trusts, user profiles, and data.

Sites might need added local administration

and support.


Determining How to Install Applications

In large farms, installing applications on servers can be time consuming. Also, applications on load-balanced servers require

identical configuration options and settings. To solve these issues, you can install these applications by using Installation

Manager, installation scripts, Microsoft System Center Configuration Manager (formerly known as Systems Management

Server (SMS)), or streaming the applications.


Determining the Number of XenApp Servers toDeploy

Mar 02, 2010

After you identify the applications you are delivering to your users and their methods of delivery, you can estimate the

number of XenApp servers required for your deployment.

For applications virtualized on the server, the number of servers required depends on the following factors:

The processing requirements of the applications and the processing capacity and available RAM of your servers. To

determine the processing requirements for an application, see its product documentation.

The native operating system of the applications. Running 32-bit applications on 64-bit operating systems requires more

RAM than running a 32-bit application on a 32-bit operating system.

Whether you are streaming applications to the server or installing the applications on the server. Depending on the

network topography and the application being delivered, a deployment where applications are installed on the servers

can service more users than a deployment with an equal number of servers where the applications are streamed to the

servers.

The size of the f iles 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, Thread Queue Length, Memory Consumption, and Pages Per Second, to determine the resource limits of

the servers in your environment. This will help you determine the number of servers to deploy in your production

environment.


Deciding How Many Farms to Deploy

Apr 14 , 2013

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

Location and needs of the users or your organization - If your organization is a service provider, you might want to

dedicate a farm to each organization for which you provide service. Multiple farms might make it easier to demonstrate

compliance with specif ic 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.

Application deployment methods - If you plan to use Microsoft System Center Configuration Manager 2007 R2 to

deploy applications, XenApp Connector for System Center Configuration Manager 2007 R2 components must be

installed on servers within the same farm.

There is no exact formula for determining the ideal number of farms, but general guidelines can help:In general, a single farm meets the needs of most deployments. A signif icant benefit to deploying a single farm is

needing only one data store database.

Consider using multiple farms when you have geographically dispersed data centers that can support their own data

store database, or when you do not want communication between servers within the farm to cross a f irewall or WAN.

For very large deployments with thousands of servers, breaking the environment into multiple farms can increase

performance.

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

Farm Elementor Component

Single Farm Multiple Farms

Data Store The farm has one data store. Each farm must have a data store.

Data StoreReplication

Citrix recommends that you replicate the data store toremote sites when using one farm in a WAN environment.

If each remote site is a farm with itsown data store, there is no need fordata store replication.

Load Balancing You can load balance an application across the farm. You cannot load balance an applicationacross servers in different farms.

FirewallTraversal

If the farm spans multiple sites, f irewall ports must beopen for server-to-server communication.

Site-based farms eliminate the need toopen f irewall ports for server-to-servercommunication.

Server-to-server

Data store information is synchronized with memberservers through notif ications and queries. When a farm

Multiple farms might improveperformance over a single farm when


Communication has multiple zones, data collectors communicate dynamicinformation such as logons and application use across thefarm.

server-to-server traff ic crosses a WANlink or when the farm is very large.

ManagementTools

You can monitor and configure the farm from a singlemanagement console and need to log on to only onefarm to do so.

You can monitor and configure multiplefarms from management console.Communicating with multiple farmsfrom the console requires logging on toeach farm.

Farm Elementor Component

Single Farm Multiple Farms

Sharing Components Between Farms

Some Citrix components can be shared between multiple farms; consequently, it is not necessary to consolidate all serversin 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.


Planning Controllers

May 16, 2015

Regardless of your farm size, Citrix recommends having at least one server dedicated to controller functions, which are

deployment functions other than those related to running published applications. Publishing applications on a controller

slows down application enumeration. If you decide to install controller functions on a server hosting published applications,

choose a server that hosts an infrequently used and not resource-intensive application (or lower the load threshold for that

server so that it accepts fewer connections).

While farm size (small, medium, large) as determined by the number of servers, can indicate the general category of your

farm, another factor to consider is the number of user connections. Because applications can scale differently from server

to server (some servers might support 100 user connections, others might support only ten), looking solely at the number of

servers might be misleading. Determine how you want to group controller functions by designing an initial configuration,

then fine tune the design after testing the pilot farm.

As you add user connections in your test configuration, watch the Windows Performance Monitor counters:When the peak number of users is connecting simultaneously to the farm; this usually occurs in the morning.

When the peak number of users is connected to the farm; this usually occurs during the day.

If the counters exceed the values listed in the table, move the controller functions on to separate servers until the counter

metric no longer exceeds the value.

Performance Monitor Counter Name Criteria

CPU > 85% - 90%

Memory > 80%

ResolutionWorkItemQueueReadyCount > 0 for extended periods of time

WorkItemQueueReadyCount > 0 for extended periods of time

LastRecordedLicenseCheck-OutResponseTime > 5000 ms

Typically, you need to evaluate the LastRecordedLicenseCheck-OutResponseTime counter only in large farms.

Planning for Data Collectors

When planning for data collectors, consider:If you need a dedicated data collector

If you do not need a dedicated data collector, which infrastructure services can share the same server

If you need a zone in each geographic region, which means that you need data collectors for those regions as well

To maintain consistent information between zones, data collectors relay information to all other data collectors in a farm,

creating network traffic.


In general, data collector memory consumption increases as farm size increases. However, it is not significant. For example,

the Independent Management Architecture service running on the data collector typically uses 300 MB on a 1000 server

farm.

Likewise, CPU usage is not significant. A data collector hosted on a dual-processor server can support over 1000 servers in its

zone. In general, CPU usage increases as the number of servers in a zone increases, the number of zones increases, and the

number of users launching applications increases.

On most networks, Citrix recommends reducing the number of data collectors and zones. For example, if you have a farm

with 100 servers in one location, Citrix recommends having one zone with a dedicated data collector (although you can

have backup data collectors).

Citrix recommends installing XenApp on the server you want to host the data collector functionality and, after installing

other member servers, configuring a server as the backup data collector.

Planning the XenApp Data Store

Updated: 2015-04-21

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

Farm configuration information

Published application configurations

Server configurations

Citrix administrator accounts

Printer configurations

The— System Requirements

lists the databases you can use for the farm data store. For information about supported database versions, see

http://support.citrix.com/article/CTX114501.

Choosing a Database

Consider these factors before deciding which database product to use:The number of servers you currently plan to have in the farm, and whether or not you plan to expand that number

Whether or not you have a database administrator with the expertise to configure and manage a data store running on

SQL Server or Oracle

Whether or not you foresee the enterprise expanding, which would result in expanding the size and maintenance of the

database

Any database maintenance requirements, such as backup, redundancy, and replication

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

Small Medium Large Enterprise

Servers 1-50 25-100 50-100 100 or more

Named Users < 150 < 3000 < 5000 > 3000



Applications < 100 < 100 < 500 < 2000 Small Medium Large Enterprise

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 off ices across a WAN.

See the database product documentation for hardware requirements for the database server.

Important: Ensure that the data store is backed up regularly. If the data store database is lost, you must recreate the farm.You cannot recreate the data store from an existing farm.

Database Server Hardware Performance Considerations

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

Starting the Citrix IMA Service on multiple servers simultaneously

Adding a server to the farm

Removing a server from the farm

The response time of other events (such as starting the IMA Service on a single server, recreating the local host cache, or

replicating printer drivers to all servers in the farm) is affected more by the farm size than by the data store response time.

Adding processors to the server hosting the data store can improve response time when executing multiple simultaneous

queries. In environments with large numbers of servers coming online simultaneously and at frequent intervals, additional

processors can service requests faster.

The capabilities of the processor on the database server affect management console performance, how long it takes to

add (configure) and remove a server from the farm, and how long it takes to start multiple servers simultaneously.

In the following chart, five sample farm configurations (A through E) are listed, with measurements of various metrics in the

farm.

Conf iguration A B C D E

Number of servers in farm 50 100 250 500 1000

Number of applications published to all servers 50 50 50 50 50

Number of user policies 25 25 25 25 25

Printers per server 5 5 5 5 5


Printer drivers installed per server 25 25 25 25 25

Network print servers with printers 5 5 5 5 5

Number of Load Manager load evaluators 10 10 10 10 10

Number of application folders in management console 10 10 10 10 10

Number of server folders in management c onsole 8 16 25 50 50

Number of Application Isolation Environments 10 10 10 10 10

Number of Citrix administrators 10 10 10 10 10

Size of data store database in megabytes 32 51 76 125 211


The following table lists suggested hardware for the server hosting the data store, for each configuration in the previous

table.


Dual Pentium 4/1.6GHz with 2GB RAM X X X

Dual Pentium 4/3.0GHz with 4GB RAM X X X X

Quad Pentium 4/3.0GHz with 4GB RAM X X X X X

The actual performance of a farm’s data store varies depending on the database engine and the level of performance

tuning achieved.

Replication Considerations

A significant amount of network traffic for XenApp farms consists of reads from the data store; writes are infrequent. The

amount of bandwidth required increases as farm size increases. Actions such as data store reads and restarting multiple

servers simultaneously use disproportionately more bandwidth on larger farms.

Citrix recommends using a single data store for most deployments, but in some situations, placing a replicated data store at

remote sites can improve farm performance. Citrix recommends replicating the data store across all high-latency or low-

bandwidth WAN links. A replicated data store ensures all data store reads occur on the network local to the XenApp server.

In a WAN environment, place replicas of the data store at sites with a large number of servers; this minimizes reads across

the WAN link. Database replication consumes bandwidth. Limit the use of replicated databases to configurations where the

remote site has enough servers to justify the bandwidth cost of placing a replicated copy of the database at the site. For


SQL Server, you must use immediate updating transactional replication.

Crossing high latency links without using replicated databases can create situations where the data store is locked for

extended periods of time when performing farm maintenance from remote sites. Data store reads do not adversely affect

local connections but remote sites can experience slower performance. This means that the Citrix IMA Service may start

after extended periods of time and some normal operations may fail when initiated from the remote site.

Note: You might experience poor performance if you use a local XenApp management console to perform farmmaintenance on a remote site that has high latency. You can resolve this issue by publishing the management consoles asapplications on a server at the remote site and use a Citrix plug-in to access the published management tools.

Planning for Configuration Logging and IMA Encryption

The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive data in the IMA data store.

Enabling IMA encryption provides an additional layer of security for the data preserved by the Configuration Logging

feature.

If you do not enable IMA encryption, XenApp uses the standard encryption used in previous versions of XenApp. The— Securing Server Farms

documentation contains more information about IMA encryption, Configuration Logging, and when to enable these

features.

To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the key, use

CTXKEYTOOL, which is available on the installation media.

For custom installations or provisioning servers in large environments, consider:Deploying XenApp by using images, and including the key f ile as part of the server image

Generating a key, putting the key in a folder on your network, using a UNC path to specify the location, and performing

an unattended installation

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

Designing Zones for a XenApp Deployment

A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All servers must belong to a zone.

Unless otherwise specified during XenApp Setup, all servers in the farm belong to the same zone, which is named Default

Zone.

Zones have two purposes:Collect data from member servers in a hierarchical structure

Eff iciently distribute changes to all servers in the farm

Each zone contains a server designated as its data collector. Data collectors store information about the zone’s servers

and published applications. In farms with more than one zone, data collectors also act as communication gateways

between zones.

This illustration depicts a server farm with multiple zones. Each zone’s data collector communicates with the other datacollectors across the WAN link.


Because session and load information within a XenApp farm can become large in enterprise deployments— up to several

megabytes— to ensure a scalable and resilient XenApp farm, it is imperative that you design zones based on your network

topology.

XenApp member servers replicate their dynamic data to the ZDC designated for their zone. XenApp uses a star topology for

replication among zones— each ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is

important to design zones so that there is adequate bandwidth among ZDCs.

When designing zones, the most important variables to consider are latency and bandwidth. The amount of bandwidth and

the impacts of latency are highly dependent on your XenApp deployment. The lower the bandwidth and the higher the

latency, the longer a farm takes to resynchronize the dynamic data among zones after an election.

In farms distributed across WANs, zones enhance performance by grouping geographically related servers together. Citrix

does not recommend having more than one zone in a farm unless it has servers in geographically distributed sites. Zones are

not necessary to divide large numbers of servers. There are 1000-server farms that have only one zone.

Data collectors generate a lot of network traffic because they communicate with each other constantly:

Each zone data collector has an open connection to all data collectors in the farm.

During a zone update, member servers update the data collector with any requests and changed data.

Data collectors relay changes to the other data collectors. Consequently, data collectors have the session information

for all zones.

In general, Citrix recommends using the fewest number of zones possible, with one being optimal. If all farm servers are in

one location, configuring only one zone for the farm does not reduce performance or make the farm harder to manage.

However, in large networks, such as organizations with data centers on different continents, grouping geographically-

related servers in zones can improve farm performance.

Keep in mind that data collectors must replicate changes to all other data collectors in the farm. Also, bandwidth

consumption and network traffic increase with the number of zones.

Separate zones are not required for remote sites, even ones on separate continents; latency is the biggest factor in

determining if servers should be put in their own zone. For large farms with servers in different geographic regions, create

zones based on the location of significant numbers of servers.

Also decide if you want to configure failover zones or preferred zones. If a zone fails, you can configure for user

connections to be redirected to another zone (failover) or control to which zones specific users connect (preference).


Failover requirements might determine the number of zones required.

For example, an organization with 20 farm servers in London, 50 servers in New York, and three servers in Sydney could

create two or three zones. If the Sydney location has good connectivity to either New York or London, Citrix recommends

grouping Sydney with the larger location. Conversely, if the WAN connection between Sydney and the other locations is

poor, and zone preference and failover is required, Citrix recommends configuring three zones.

Consider these zone design guidelines:Minimize the number of zones in your farm.

Create zones for major datacenters in different geographic regions.

If a site has a small number of servers, group that site in a larger site’s zone.

If your organization has branch off ices with low bandwidth or unreliable connectivity, do not place those branch off ices

in their own zone. Instead, group them with other sites with which they have the best connectivity. When combined

with other zones, this might form a hub-and-spoke zone configuration.

If you have more than f ive sites, group the smaller sites with the larger zones. Citrix does not recommend exceeding f ive

zones.

Planning for the Web Interface and XML Broker

The Web Interface and the XML Broker are complementary services. The Web Interface provides users with access to

applications. The XML Broker determines which applications appear in the Web Interface, based on the user’s permissions.

When determining whether or not to dedicate servers to the Web Interface and the XML Broker, consider scalability and

security.

In small to medium farms, you can:Run XenApp and the Web Interface on the same server, depending on your security considerations.

Group the XML Broker with other infrastructure services, such as the data collector or the data store, in very small farms

(one to f ive servers). Citrix recommends grouping the XML Broker with the data collector.

In larger farms, Citrix recommends:Configuring the XML Broker on data collectors or dedicated servers. In deployments with dedicated servers for

infrastructure functions, dedicate a server to the XML Broker to accommodate authentication traff ic.

Running the Web Interface on dedicated Web servers.

Do not publish applications on the server functioning as the XML Broker

Important: If you change the port used by the Citrix XML Service on the XML Broker, set the correct port in the plug-in.

Security Considerations

When users access the Web Interface from the Internet, Citrix recommends locating the Web Interface server on the

internal network and the Citrix XML Broker with the XenApp farm. Shielding the XML Broker from the external Internet

protects the XML Broker and the farm from Internet security threats.

If you must place the Web Interface in the DMZ and want to secure the connection between the XML Broker and the

Web Interface, put the Web Interface server in the DMZ with Secure Gateway or Access Gateway. This configuration

requires putting the Web Interface on a separate Web server. Install a certificate on the Web Interface server and configure

SSL Relay on the servers hosting the Citrix XML Broker.

In very small farms, configuring the Web Interface and the XML Broker on the same server eliminates having to secure the


link from the Web Interface to the farm. This deployment is used primarily in environments that do not have users

connecting remotely. However, this might not be possible if your organization does not want Web servers such as Internet

Information Services (IIS) in the farm.


Planning for Accounts and Trust Relationships

Jul 13, 2010

Consider how users will access resources. When multiple servers host the same published application, users could be

connected to any of these servers when they access the resource. Therefore, if a user does not have permissions for all

servers, the user might not be able to access the resource. To avoid these issues, you might need to establish domain trust

relationships between users or servers.

Also, in a farm with multiple, untrusted domains, when servers are load balanced, users can be routed to a server in a domain

in which they do not have access permissions. To ensure your users are routed only to servers in domains in which they have

access permissions:

Publish copies of an application in each domain, and allow users access only to the copy of the application in the domain

in which they have access permissions.

Create a Worker Group Preference and Failover policy that routes users to servers in domains in which the users have

access permissions.

System Account Considerations

Consider the following when deciding how to configure your Citrix administrator accounts:One full authority administrator account must always exist for the server farm. Citrix XenApp prevents you from deleting

the last full authority administrator account. However, if no administrator accounts exist in the farm data store

database, a local administrator account can log on to the Delivery Services Console to set up Citrix administrator

accounts.

To create effective Citrix administrator accounts, ensure that all users you are going to add as Citrix administrators are

Domain Users for the domain in which your farm resides. Users who are Citrix administrators who take server snapshots

must also be authorized Windows Management Instrumentation (WMI) users on each server for which they are taking

snapshots.

Including Servers from Other Domains

XenApp supports trust-based routing; servers in domains that do not trust each other can be members of the same farm.

When a server needs to perform one of the following operations on an untrusted domain, the server determines from thedata store which servers can perform the operation and routes the request to the most accessible server:

Authenticating a Citrix administrator

Refreshing the display or launching an application in Web Interface

Enumerating users and groups

Resolving users or groups when adding users to published application, printer auto-creation lists, or defining new Citrix

administrators

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

server does not.

Substituting Domain Accounts for User Accounts

By default, XenApp creates local accounts to run the following XenApp services:

XenApp Service Default Local User Account


CPU Utilization Mgmt/CPU Rebalancer ctx_cpuuser

Configuration Manager for the Web Interface Service Ctx_ConfigMgr

XenApp Service Default Local User Account

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.


Recommendations for Active Directory Environments

Mar 02, 2010

Citrix recommends the following configuration for server farms with Active Directory:XenApp servers are in their own Organizational Units (OUs).

Create OUs for application silos, keeping servers from different silos organized in their own OUs. (You can, however,

create application silos that span multiple OUs.)

All servers reside in the same domain.

The server farm domain has no trust relationships with non-Active Directory domains, as this can affect operations

requiring trusted domains.

The server farm is in a single Active Directory forest. If your farm has servers in more than one forest, users cannot log on

by entering user principal names (UPNs).

UPN logons use the format username@UPN identif ier. With Active Directory, UPN logons do not require a domain to be

specif ied, because Active Directory can locate full UPN logons in the directory. However, if the server farm has multiple

forests, problems occur if the same UPN identif ier exists in two domains in separate forests.

Important: Citrix XenApp does not support UPN logons if a server farm spans multiple Active Directory forests.

Active Directory User Permission

Active Directory security groups can affect authenticating to published applications or the management console. The

tables that follow contain best practice guidance.

Also, if a user is a member of a domain local group, the group is in the user’s security token only when the user logs onto a

computer in the same domain as the domain local group. Trust-based routing does not guarantee that a user’s logon

request is sent to a server in the same domain as the domain local group.

Network configurations do not affect authentication to the management console because that console allows only pass-

through authentication.

Domain Global Groups

Authenticating to published applications No adverse effects

Authenticating to management console No adverse effects

Domain LocalGroups

Authenticatingto publishedapplications

Recommendation: All servers that load balance an application must be in the same domain if a domainlocal group is authorized to use the application.Rationale: Domain local groups assigned to an application must be from the common primary domain

of all the load balancing servers. When you publish applications, domain local groups appear in the

accounts list if the condition above is met and accounts from the common primary domain are

displayed. If a published application has users from any domain local groups and you add a server from

a different domain, domain local groups are removed from the configured users list, because all servers

must be able to validate any user with permission to run the application.


Authenticatingtomanagementconsole

Recommendation: If a user is a Citrix administrator only by membership in a domain local group, theuser must connect the console to a server in the same domain as the domain local group.Rationale: If the user connects the console to a server in a different domain than the domain local

group, the user is denied access to the console because the domain local group is not in the user’s

security token.

Domain LocalGroups

UniversalGroups

Authenticatingto publishedapplications

Recommendation: If universal groups are assigned permission to the application, all servers thatmanage the application must be in an Active Directory domain.Rationale: A server in a non-Active Directory domain could authenticate the user to run the

application. In this case, universal groups are not in the user’s security token, so the user is denied

access to the application. It is possible for a server in a non-Active Directory domain to load balance

an application with servers in an Active Directory domain if the domains have an explicit trust

relationship.

Authenticatingtomanagementconsole

Recommendation: If a user is authenticating to the console and is a Citrix administrator only bymembership in a universal group, the console must connect to a server that belongs to an ActiveDirectory domain in the universal group’s forest.Rationale: Non-Active Directory domain controllers and domains outside a universal group’s forest

have no information about the universal group.

Active Directory Federated Services

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

When installing XenApp on each server in your farm, ensure the port sharing with IIS option and ensure that IIS is

configured to support HTTPS; see— System Requirements

for more information.

Set up a trust relationship between the server running the Web Interface and any other servers in the farm

communicating with the Web Interface through the Citrix XML Broker. The Web Interface must be able to access the

certif icate revocation list (CRL) for the Certif icate Authority used by the federation servers.

If you are provisioning the farm by imaging, configure trust requests on the server before you take the image. These

trust requests must be enabled on each server in the farm and cannot be set at a farm level.

To prevent external users from having unauthorized access to services on farm servers, configure all XenApp servers for

constrained delegation. To provide users with access to resources on those servers, add the relevant services to the

Services list using the MMC Active Directory Users and Computers snap-in.

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


Installing and Configuring XenApp

Mar 01, 2010

XenApp installation and configuration are separate tasks available through a graphical user interface or command line.For a wizard-based XenApp installation or configuration, use the Server Role Manager.

For a command-line installation, use the XenAppSetupConsole command to install XenApp roles and the

XenAppConfigConsole command to configure XenApp roles.

This task division provides f lexibility when using provisioning tools and disk imaging:Use startup scripts to install and configure XenApp when a disk image is launched.

Install XenApp on the disk image and use startup scripts to configure XenApp when the instance is launched.

Install and configure XenApp on the disk image and run startup scripts that modify the configuration when the image is

launched. You can use this option to modify your XenApp configuration on the f ly, without having to reconfigure or

reimage disks.

For information about provisioning and imaging using Citrix products, see the Citrix Web site.

Using the Server Role Manager

XenApp for Windows Server 2008 R2 uses roles for XenApp features and technologies. The XenApp Server Role Managerprovides a graphical user interface that guides you through installing (that is, adding) certain XenApp roles, using the ServerRole Installer. In addition to expediting prerequisite and role installation, this tool detects the deployment phase for eachrole and displays the next task required to complete the installation and configuration of that role. From the Server RoleManager, you can:

Add server roles

Launch installers for partially-integrated roles

Automatically install many role prerequisites

Launch configuration tools such as the XenApp Server Configuration Tool to configure the XenApp server

Initiate a XenApp server restart (reboot)

You can run the XenApp Server Role Manager at any time. It initially runs from the XenApp installation media. After you

install a role, the Server Role Manager is installed locally, and runs every time you log on to the XenApp server (you can

disable this feature by selecting a checkbox on the main Server Role Manager page). You can also rerun it from its Program

Files location (Program Files (x86)\Citrix\XenApp\ServerRoleManager\XenAppServerRoleManager). If a Server Role Manager

is installed locally and you invoke a different one from the XenApp installation media, the version on the installation media is

used.

Each XenApp role has an integration level:

IntegrationLevel

Description

Full Role prerequisites and the role software install automatically. Fully integrated roles include XenApp,

Citrix License Server, Web Interface, Single sign-on service, and Provisioning Server.

Partial Role prerequisites install automatically. The role is added to the Server Role Manager task list, where

you can launch the role installer (that is, the wizard for that role). Partially integrated roles include

Secure Gateway, Power and Capacity Management Administration, SmartAuditor Server, and EdgeSight


Server.

Information-

only or

media-only

Roles you cannot install using the Server Role Manager. Information-only roles include Merchandising

Server, which is a virtual appliance that requires a virtual machine.

The XenApp installation media contains installation files for media-only roles. See the role

documentation for installation instructions.

IntegrationLevel

Description

Using the Command Line

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

command prompt.


Preparing to Install and Configure XenApp

Apr 21, 2015

Review the XenApp Readme for late-breaking issues.

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.To ensure availability of the features and functionality of XenApp for Windows Server 2008 R2 to your users, install the

most recent version of any plug-ins you use.

When installing roles or role components other than XenApp server, see the role documentation for details about

information requested during installation and configuration.

Important: Do not join servers running XenApp 6 for Windows Server 2008 R2 to a deployment with servers running previousversions of XenApp.Note: To prepare XenApp for server imaging and provisioning, you can use the XenApp Server Configuration Tool includedon the XenApp 6 for Windows Server 2008 R2 installation media. However, the preparation process is streamlined and moreeffective if you use the updated XenApp Server Configuration Tool, which you can install on the server with CTX124981. Ifyou install the updated XenApp Server Configuration Tool after you install XenApp, you must use the same user accountthat was used to install XenApp.

Before Installing XenApp

Review the installation process (wizard-based or command-line) to learn what information you must provide.

Review the system requirements for the XenApp server and for other roles you plan to install.

Wizard-based installations include automatic installation of prerequisite software and required Windows roles.

For command-line installations, you must install the prerequisite software and Windows roles before initiating XenApp

installation. You can deploy prerequisites with PowerShell cmdlets, the Microsoft ServerManagerCmd.exe command,

or the Microsoft Deployment Image Servicing and Management (DISM) tool.

Ensure the Microsoft Windows Server has the latest Microsoft hotfixes and that the operating system clock has the

correct time.

Prepare for Windows Multilingual User Interface (MUI) support, if needed.

Important: By default, the XenApp server installation process creates install logs in the user's temporary directory

(%TEMP%). On Windows Server 2008 R2 servers, the session's temporary directory is deleted by default when the server

restarts. If you encounter problems during installation or want to preserve those log f iles, use one of the following

options:

Copy the logs from the %TEMP% location to a safe place before the server restarts.

Before installing the XenApp server role, change your local computer policy to prevent deletion of the temporary

directories.

1. Go to Start > Run, then type gpedit.msc.

2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop

Services > Remote Desktop Session Host > Temporary folders.

3. Verify that Do not delete temp folder upon exit is set.

4. Restart the server.

For a command-line installation, use the /logfile:path option to specify an installation log f ile in a different directory.

Before Configuring XenApp

http://support.citrix.com/article/ctx124981


Review the configuration process (wizard-based or command-line) to learn what information you must provide.

During configuration, you specify the database to be used for the XenApp farm data store: Microsoft SQL Server

Express, Microsoft SQL Server, or Oracle. See CTX114501 for supported versions.

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

If you use a Microsoft SQL Server or Oracle database, install and configure the database before initiating XenApp

configuration. (For an Oracle database, this includes installing an Oracle client on the XenApp server and restarting the

server.)

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) f ile 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 f ile and copy it to other servers,

or put it on a network share, provided you remove the value for any workstation-specif ic information (such as the Oracle

WSID). Use the /DsnFile:dsn_file option to specify the f ile location on the XenApp configuration command line.

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.



Installing XenApp Using the Wizard-Based Server RoleManager

Mar 01, 2010

To install XenApp using the wizard-based Server Role Manager:

1. On the installation media, double-click autorun.exe. The Autorun menu launches.

2. Select Install XenApp Server. The Server Role Manager launches and checks if any roles are already installed.

3. Select Add server roles.

4. Select your XenApp edition.

5. Accept the End User License Agreement.

6. Select the roles you want to add. (The Server Role Manager displays only the roles supported in the XenApp edition you

selected. Some roles may require current Subscription Advantage membership.)

7. Select role subcomponents.

Roles may have default and optional components such as management tools, plug-ins, or agents. Certain

subcomponents may be selected by default when you select a role to add.

For example, when you select the XenApp role, the XenApp Management subcomponent is selected by default; this

subcomponent includes the Delivery Services Console. If you prefer not to install the console on this server, you can

deselect it. You can also select other available role subcomponents.

If you are installing the XenApp role, the Optional Components list includes XML Service IIS Integration. When selected,

the Citrix XML Service and IIS share a port (default = 80).

If the server on which you are installing XenApp has IIS installed, the XML Service IIS Integration component is

selected by default.

If IIS is not installed, the component checkbox is not selected. In this case, if you select the checkbox, the Server Role

Installer installs IIS. (If you do not install the XML Service IIS Integration component, the Citrix XML Service defaults

to standalone mode with its own port settings, which you can configure using the XenApp Server Configuration Tool.)

The Citrix online plug-in and Citrix offline plug-in are installed automatically when you install the XenApp role. These plug-

ins do not appear in the components lists, and you cannot disable these installations during a wizard-based installation.

8. Review the prerequisites summary, which indicates which role or subcomponent needs the prerequisite, and whether the

Server Role Installer installs it or you must install it . For software you must install, the display indicates whether the

XenApp installation media contains the software or you must obtain it elsewhere.

9. Review the summary, which lists the selected roles and subcomponents to be installed or prepared. It also lists

prerequisites which will be automatically deployed for all selected roles.

After you click 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 ascreating 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 youselected, the task list indicates the next task necessary for installation or configuration.

For installed fully integrated roles that require configuration, click Configure to launch the configuration tool for that

role.

For partially integrated roles, click Install to launch the installer for that role. See the role documentation for details.


Installing XenApp from the Command Line

Mar 21, 2012

Command Syntax

On the server where you want to install XenApp or other roles, from the "XenApp Server Setup\bin\" directory on the

XenApp media, type the following at a command prompt:

XenAppSetupConsole.exe options_properties

Options and Properties

/help

Displays command help.

/logf ile:path

Path for the log f ile generated during the installation.

/install:items

Comma-delimited list of components, features, or technologies to install. Valid values are:

EdgeSightServer. EdgeSight Server.

Licensing. Citrix Licensing Server.

MerchandisingServer. Merchandising Server.

PCMAdmin. Power and Capacity Management administration components.

Provisioning. Provisioning Services.

Secure Gateway. Secure Gateway.

SmartAuditorServer. SmartAuditor server.

SsonService. Single sign-on service.

WebInterface. Web Interface.

XenApp. XenApp server.

If you select XenApp, the Delivery Services Console, Citrix online plug-in, and Citrix off line plug-in are installed by default.

You can also specify one or more of the following options to install, separated by commas. If you do not specify an

option, it is not installed.

Option Description

XA_IISIntegration If the server has IIS role services installed, this option is installed by default and the

Citrix XML Service and IIS share a port (default = 80). If the server does not have the

IIS role services installed, XA_IISIntegration is not installed by default, and the Citrix

XML Service defaults to standalone mode with its own port settings, which you can

change during XenApp configuration.

EdgeSightAgentFeature EdgeSight agent.

SmartAuditorAgentFeature SmartAuditor agent.

SSONAgentFeature Single sign-on plug-in.


PCMAgentFeature Power and Capacity Management agent.

PVDeviceFeature Provisioning Services target device.

Option Description

/exclude:items

(Valid only when installing the XenApp server) Comma-separated list of sub-features to be omitted from the installation.

Valid values are:

XA_Console. Omits the automatic installation of the Delivery Services Console when you install the XenApp role.

XA_IISIntegration. Exclude this sub-feature if the server has IIS role services installed, but you choose to use a

nondefault XML port (default = 80) for your installation. If the server has the IIS role services installed and you do not

specify /exclude:XA_IISIntegration, the default XML port is selected and you cannot reconfigure this setting later.

/edition

Specif ies the XenApp edition. Valid values are:

Platinum

Enterprise

Advanced

If no edition is specif ied, the default is /Platinum.

/logf ile:path

Specif ies where to create a log f ile.

INSTALLDIR=directory

Specif ies where to install the items. Default: C:\Program Files (x86)\Citrix

ONLINE_PLUGIN_INSTALLDIR=directory

Specif ies where to install the Citrix online plug-in. Default: C:\Program Files (x86)\Citrix\ICA Client

Examples

The following command installs the XenApp server Platinum Edition in its default location.XenAppSetupConsole.exe /install:XenApp /PlatinumThe following command installs the XenApp server Platinum edition and the Web Interface in C:\Program Files (x86)\Citrix(which is the default location).XenAppSetupConsole.exe /install:XenApp,WebInterface INSTALLDIR=C:\Program Files (x86)\CitrixThe following command installs the XenApp server Platinum Edition and the Single sign-on plug-in, and excludes installationof the Delivery Services Console.XenAppSetupConsole.exe /install:XenApp,SSONAgentFeature /exclude:XA_Console


Configuring XenApp Using the Wizard-based ServerConfiguration Tool

May 07, 2010

Note: This procedure applies to configuring XenApp servers for the f irst time, unless otherwise indicated.To configure XenApp using the wizard-based Server Configuration Tool:

1. Access the XenApp Server Role Manager.

The XenApp Server Role Manager runs every time you log on to the XenApp server, unless you disable that feature. You

can run the XenApp Server Role Manager from Program Files

(x86)\Citrix\XenApp\XenAppServerRoleManager\XenAppServerRoleManager.

2. In the XenApp Server Role Manager task list, click Configure under XenApp. The Server Configuration Tool launches.

3. Indicate the task you want to perform. If you have not yet configured the XenApp server role, you can create a farm or

add the server to (join) an existing farm. The remainder of this procedure assumes you are creating a new farm or adding

a server to an existing farm; see the Note for information about other scenarios.

When you install XenApp for Windows Server 2008 R2 on the f irst server, that server is where you create a new farm.

After you install XenApp on other servers, you add each server to (join) an existing farm.

Note:

If you previously configured the XenApp server role, and you are using the XenApp Server Configuration Tool from the

XenApp 6 for Windows Server 2008 R2 installation media, you can create a farm, add the server to (join) an existing

farm, or leave (remove the server from) the farm. If you choose to create a farm or add the server to an existing farm,

the server will be removed from its current farm before creating or joining another farm.

If you previously configured the XenApp server role, and you installed the updated XenApp Server Configuration Tool,

you can prepare the server for imaging and provisioning, or leave (remove the server from) the farm.

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

Enter a farm name, up to 32 characters (can include spaces). If you are using Oracle as your Configuration Logging

database, do not use hyphens in the farm name.

Specify the domain and username for a user who will be the f irst Citrix administrator. The administrator has full

permissions to the farm and can create additional administrator accounts.

5. When creating a farm, specify Citrix License Server information. Choose one of the options:

To use an existing license server, enter the license server name. By default, the license server uses port 27000 unless

you deselect that option and specify a different port number.

Defer specifying license server information.

For complete information, see the licensing documentation.

6. Select the data store database type and connection information.

If you choosethe entry for

Action

New database When creating a farm, the Server Configuration Tool installs the Microsoft SQL Server Express

database automatically, with the instance name CITRIX_METAFRAME and database name MF20;

the database uses Windows authentication.

Existing You are prompted for the instance name, the database name, and the authentication method.


Microsoft SQL

Server

database

This database can be located on a remote SQL server.

Existing Oracle

database

You are prompted for the Net Service name. (The Oracle entry appears only if the Oracle client is

installed on the server where you are configuring the XenApp role.)

If you choosethe entry for

Action

7. Specify the database credentials. Specify the user name in the form <DBMACHINE>\<USER> or <DOMAIN>\<USER>.

SQL Server Express requires an existing Windows account, but it does not need to be a server or system administrator.

The XenApp Server Configuration Tool adds two database administrators to SQL Server Express: (local)\administrators

and the supplied credentials for the local or domain user.

When adding a server to (joining) a farm, you can optionally test the connection to the database. The result does not

affect Server Configuration Tool operations.

8. The default session shadowing settings (which allow shadowing) are recommended for most farms. Shadowing settings

supplied during XenApp configuration override system or domain policy for user-to-user shadowing.

Important: Shadowing features are permanent and should be changed only if you wish to permanently prevent system

or domain policy from affecting that setting. If you disable shadowing or change shadowing features during

configuration, you cannot reconfigure them later.

Option Description

Prohibit shadowing of user

session on this server

Disables user session shadowing on this server. If selected, shadowing cannot be

enabled on this server through policies. Default = unselected

Allow shadowing of user

sessions on this server

Enables user session shadowing on this server. Default = selected

When you enable shadowing, you can apply the following features (default = all

unselected):

Prohibit remote control. If selected:

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

Remote control is permanently prohibited; this cannot be enabled on this server

through policies.

Force a shadow acceptance prompt. If selected:

Authorized users must send an acceptance prompt when attempting to

shadow a session.

A shadow acceptance prompt is shown on every shadowing attempt; this

cannot be disabled on this server through policies.

Force logging of all shadow connections. If selected:

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

event log.

Shadow connections are always logged; this cannot be disabled on this server

through policies.

9. If you do not change the following server settings, the Server Configuration Tool uses default values.


Setting Description

License

Server

(Displays only when adding a server to (joining) a farm). Choose one of the options:

Enter the name of an existing license server name (NetBIOS computer name, fully-qualif ied domain

name (FQDN), or IP address). By default, the license server uses port 27000 unless you deselect that

option and specify a different port number.

(Default) To use the global farm settings for the license server, select this option.

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

the name.

XML

Service

By default, XenApp server role installation configures the Citrix XML Service and Internet Information

Service (IIS) to share the same TCP/IP port (80) for communications. In this case, you cannot change the

XML Service setting. See— System Requirements

for more information.

Online

plug-in

Server name or URL of the Web Interface server used by the Citrix online plug-in.

Remote

Desktop

Users

Only members of the Remote Desktop Users group can connect to published applications. Until you add

users to this group, only administrators can connect remotely to the server. Select one or more of the

following.

Add Anonymous users. Adds anonymous users to the Remote Desktop Users group. Default = selected

Add the Authenticated users. Adds current (and future) domain accounts in the Windows Users group

to the Remote Desktop Users group. Default = unselected

Add the list of users from the Users group. Adds all current users from the Users group to the Remote

Desktop Users group. If you add users later, you must add them manually to the Remote Desktop

Users group. Default = selected

10. If you installed the plug-in (or agent) for Single sign-on, SmartAuditor, EdgeSight, or Power and Capacity Management

on this server, specify the requested information to enable communications with them. (The plug-in (or agent) roles use

separate tools for their configuration.)

11. Review the summary page and click Apply.

After configuration completes, you are returned to the XenApp Server Role Manager task list, which indicates if anyrequirements remain, such as a server restart. The XenApp Server Role Manager updates the task list after any taskcompletes.

To initiate a server restart, click Reboot.

To change a role configuration, click Edit Configuration.


Configuring XenApp from the Command Line

May 08 , 2015

Note: The— Command Syntax

topic lists and describes all XenApp configuration command-line options. This topic contains information about using theXenApp configuration command and its options.

Command Conventions

Several options use Boolean values (true or false).If you omit an option that requires a Boolean value, the default value is used. For example, if you do not include the

/AddLocalAdmin:True|False option in the command, the default value (false) is used (that is, a local administrator is not

added).

If you specify an option that requires a Boolean value but you omit the value, the option default value is true. For

example, for the /AddLocalAdmin:True|False option, if you specify only /AddLocalAdmin (with no :True or :False value),

the option is true (that is, a local administrator is added).

You can use environment variables to represent one or more command-line options. For example, you can group the

standard Pause, Confirm, and NotStrict options as a single environment variable. You can also use environment variables in

the command-line option values. For example, /ServerName:%currentServer%, where currentServer is defined as an

environment variable.

Command Option Categories

The following table lists options that affect the same subject, feature, or object. It also indicates when an option isrequired. (The table does not contain option arguments; see— Command Syntax

for full option descriptions.)

Subject,Feature, orObject

Options

Configuration

process

/NotStrict

/Confirm

/Pause

/LogFilename

XML Service

Information

/CustomXMLServicePort

General farm

information

/ExecutionMode - required when creating, joining, or leaving a farm

/FarmName - required when creating a farm

/CitrixAdministratorAccount - required when creating a farm

/LicenseServerName

/LicenseServerPort

/ZoneName

/AddLocalAdmin


Database

used for the

XenApp farm

data store

/SqlExpressRootDir

/SimpleDB - this option and /DsnFile are mutually exclusive

/ServerName - required when joining a farm if you specif ied /SimpleDB when creating the farm

/DsnFile - required when creating or joining a farm if you are using a SQL Server or Oracle database;

this option and /SimpleDB are mutually exclusive

/AuthenticationType

/OdbcUserName - required when creating and joining a farm

/OdbcPassword - required when creating and joining a farm

If you use a Microsoft SQL Server Express database, you can simplify configuration by using the

/SimpleDB option when creating the XenApp farm. When joining a farm that uses a Microsoft SQL

Server Express database, use the /ServerName:server_name option to specify the name of the XenApp

server on which you created the farm.

Sessionshadowing

Shadowing is enabled by default.Important: Citrix recommends using the default values (that is, do not specify them in this command).Shadowing settings specif ied 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 topermanently prevent system or domain policy from affecting that setting. If you disable shadowing orchange shadowing features during configuration, you cannot reconfigure them later.

/ProhibitShadowing

/ProhibitRemoteControl

/ForceShadowPopup

/ForceShadowLogging

Remote

Desktop

Users Group

/AddAnonymousUsersToRemoteDesktopUserGroup

/AddUsersGroupToRemoteDesktopUserGroup

/AddAuthenticatedUsersToRemoteDesktopUserGroup

XenApp

image

preparation

and

provisioning

ExecutionMode:ImagePrep

Requires the updated XenApp Server Configuration Tool; see CTX124981.

Subject,Feature, orObject

Options

Return Codes

The XenAppConfigConsole command supports the following return codes:

Value Meaning

0 Success

1 Invalid command-line options - for example, the command includes the options /ServerName:server_name and



/ExecutionMode:Create (an option that is valid only when joining a farm was specif ied when creating a farm)

2 Unmatched parameters - an unrecognized option was specif ied

3 Invalid parameters - for example, for an option that requires a Boolean value (that is, True or False), youspecif ied 'Bob'

4 Commit failed - the configuration process did not complete; check the log f ile for details

Value Meaning

Mapping of Earlier XenApp Version Properties to Options

Earlier XenApp versions supported installation and configuration properties. Some of those properties have equivalentoptions in XenApp for Windows Server 2008 R2.

Property in Earlier XenApp Version Option in XenApp for Windows Server 2008 R2

CTX_MF_FARM_SELECTION /ExecutionMode

CTX_MF_NEW_FARM_NAME /FarmName

CTX_MF_DOMAIN_NAME, CTX_MF_USER_NAME /CitrixAdministratorAccount:domain\user

CTX_MF_SILENT_DSNFILE /DsnFile

CTX_MF_ODBC_USER_NAME /OdbcUserName

CTX_MF_ODBC_PASSWORD /OdbcPassword

CTX_MF_LICENSE_SERVER_NAME /LicenseServerName

CTX_MF_LICENSE_SERVER_PORT /LicenseServerPort

CTX_MF_ZONE_NAME /ZoneName

CTX_MF_XML_PORT_NUMBER, CTX_MF_XML_CHOICE /CustomXmlServicePort

CTX_MF_SHADOWING_CHOICE:yes /ProhibitShadowing:false

CTX_MF_SHADOW_PROHIBIT_REMOTE_ICA /ProhibitRemoteControl

CTX_MF_SHADOW_PROHIBIT_NO_NOTIFICATION /ForceShadowPopup


CTX_MF_SHADOW_PROHIBIT_NO_LOGGING /ForceShadowLogging

CTX_MF_ADD_ANON_USERS /AddAnonymousUsersToRemoteDesktopUserGroup

CTX_MF_CREATE_REMOTE_DESKTOP_USERS /AddUsersGroupToRemoteDesktopUserGroup

Property in Earlier XenApp Version Option in XenApp for Windows Server 2008 R2

Command Syntax

Command Syntax

On the server where the XenApp server role is installed, from C:\Program Files (x86)\Citrix\XenApp\ServerConfig, type the

following at a command prompt:

XenAppConfigConsole.exe [options]

Options

/help

Displays command help.

/NotStrict

Allows the executable to continue processing even if options do not apply in the current context.

/Conf irm

Displays a confirmation message before modifying the server. This can be useful when testing for correct use of command

options.

/Pause

Pauses the executable after processing completes. This prevents the command prompt from closing when launching the

command from a batch f ile.

/LogFilename:f ile

Logs the progress of the executable to a log f ile. In the log, the symbols >> indicate a function call; the symbols << indicate

a function return

/SqlExpressRootDir:sql_express_install_src_dir

Specif ies the location of the SQL Server Express source installation directory. Default = C:\Program Files

(x86)\Citrix\XenApp\ServerConfig\SqlExpress_2008.

/ExecutionMode:Create | Join | Leave | ImagePrep

Specif ies the task you want to perform. If you have not yet configured the XenApp server role, you can create a farm or

add the server to (join) an existing farm.

Task Description

Create If you have not yet configured the XenApp server role on this server: After you install XenApp on the first

server, that server is where you Create a new farm during configuration and add the server to the farm.

If you previously configured the XenApp server role on this server, specifying Create removes the server

from its current farm before creating another farm.

Join If you have not yet configured the XenApp server role on this server: After you install XenApp on other


servers, you Join a farm when you configure each of those servers and add each server an existing farm.

If you previously configured the XenApp server role on this server, specifying Join removes the server from

its current farm before joining another farm.

Leave (Valid only if you previously configured the XenApp server role on this server to join an existing farm)

Specify Leave if you want to remove the server from the farm.

ImagePrep (Valid only with the updated XenApp Server Configuration Tool and if you previously configured the

XenApp server role on this server to join an existing farm) For information about this task, see Preparing

for XenApp 6 Imaging and Provisioning.

Task Description

/FarmName:farm_name

Valid only with /ExecutionMode:Create) Specif ies the farm name, up to 32 characters (can include spaces). If you are using

Oracle for the Configuration Logging database, do not use hyphens in the farm name.

/CitrixAdministratorAccount:domain_name\user_name

(Valid only with /ExecutionMode:Create) Specif ies the domain and username for the user who will be the f irst Citrix

administrator. The administrator has full permissions to the farm and can create additional administrator accounts.

/SimpleDB

Indicates the farm uses a SQL Server Express database for the data store.

/ServerName:server_name

(Valid only with /ExecutionMode:Join and /SimpleDB) Specif ies the name of the server where the XenApp farm was created

(that is, where the SQL Server Express database was installed).

/DsnFile:dsn_f ile

Specif ies the path to the DSN file used to connect to the data store.

/AuthenticationType:Windows | Sql

(Valid only when using a SQL Server or Oracle database for the farm data store) Specif ies the authentication type. Default

= Windows

/OdbcUserName:odbc_user_name

Specif ies the database user name in the form <DBMACHINE>\<USER> or <DOMAIN>\<USER>. SQL Server Express requires

an existing Windows account, but it does not need to be a server or system administrator. XenApp configuration adds two

database administrators to SQL Server Express: (local)\administrators and the supplied credentials for the local or domain

user.

Specify the database user password with the /OdbcPassword option.

/OdbcPassword:odbc_password

Specif ies the database user password.

Specify the database user name with the /OdbcUserName option.

/LicenseServerName:license_server_name

Specif ies the name of the existing license server.

/LicenseServerPort:license_server_port

Specif ies the license server port. Default = 27000

/ProhibitShadowing:True | False

Disables or enables session shadowing. Default = False (shadowing is enabled)

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-config-wrapper/ps-image-prep.html


Important: Citrix recommends using the default values (that is, do not specify them in this command). Shadowing settings

specif ied during XenApp configuration override system or domain policy for user-to-user shadowing. Shadowing features

are permanent and should be changed only if you wish to permanently prevent system or domain policy from affecting that

setting. If you disable shadowing or change shadowing features during configuration, you cannot reconfigure them later.

/ProhibitRemoteControl:True | False

(Valid only if shadowing is enabled) Prohibits or allows remote control shadowing. When this option is true, authorized users

can view sessions but do not have keyboard and mouse input. Default = False





/ForceShadowPopup:True | False

(Valid only if shadowing is enabled) Enables or disables sending a shadowing acceptance popup. When this option is true,

authorized users must send an acceptance prompt when attempting to shadow a session. Default = False





/ForceShadowLogging:True | False

(Valid only if shadowing is enabled) Enables or disables logging of all shadow connections. When this option is true, all

shadowing attempts, successes, and failures are logged to the Windows event log. Default = False





/ZoneName:zone_name

Specif ies the zone name. Default = Default Zone

/CustomXmlServicePort:port_number

Specif ies the port number to be used by the Citrix XML Service. By default, the Citrix XML Service and Internet Information

Service (IIS) use the same TCP/IP port (80) for communications. Specify this option if you do not want those services to

share the port (for example, if you install the Citrix XML Service on a dedicated XML server). See— System Requirements

for more information. Default = 80

/SkipXmlSetting:True | False

When this option is true, the Citrix XML service and IIS port numbers are not configured (that is, the default port 80 is not

used). Default = False

/AddAnonymousUsersToRemoteDesktopUserGroup:True | False

Enables or disables adding anonymous users to the Remote Desktop Users group. Default = True

/AddUsersGroupToRemoteDesktopUserGroup:True | False

Enables or disables adding all current users from the Users group to the Remote Desktop Users group. If you add users later,

you must add them manually to the Remote Desk-top Users group. Default = True

/AddAuthenticatedUsersToRemoteDesktopUserGroup:True | False

Enables or disables adding current (and future) domain accounts in the Windows Users group to the Remote Desktop Users

group. Default = False

/AddLocalAdmin:True | False


Enables or disables creation of Citrix administrator accounts for all user accounts in the local Administrators group. Default

= False

/SmartAuditorServerName:smart_auditor_server_name

(Required if you installed the SmartAuditor agent on the XenApp server) Specif ies the name of the SmartAuditor server.

/SsoPluginUncPath:path_to_central_store

UNC path to Single sign-on central store. Default = use Active Directory

/OnlinePluginServerUrl:wi_url_or_servername

Server name or URL of the Web Interface server used by the Citrix online plug-in.

/PcmFarmName:pcm_farm_name

Power and Capacity Management farm name.

/PcmWorkloadName:pcm_workload_name

Power and Capacity Management workload name.

EdgeSightCompanyName:edgesight_company_name

EdgeSight company name.

/EdgeSightServerName:edgesight_server_name

EdgeSight server name.

/EdgeSightServerPort:edgesight_server_port

EdgeSight server port. Default = 80

/RemoveCurrentServer:True | False

(Valid only with /ExecutionMode:ImagePrep and updated XenApp Server Configuration Tool) Enables or disables removing

the current server intance from the XenApp farm. Default = True

/PrepMsmq:True | False

(Valid only with /ExecutionMode:ImagePrep and updated XenApp Server Configuration Tool) Enables or disables resetting

the MSMQ ID during resealing. Default = True


Preparing for XenApp 6 Imaging and Provisioning

Apr 07, 2011

Primary deployment methods for XenApp servers include server imaging, virtualization, and provisioning. In XenApp 6 for

Windows Server 2008 R2, XenApp server role installation and configuration are separate tasks; this offers flexibility in

deciding when to capture (create) XenApp images.

Provisioning a XenApp server uses one of three typical approaches; the approach you use depends on when you configure

XenApp (earlier or later) in your preparation steps. The XenApp server joins its farm on the first restart (reboot) after

configuration; this ensures that the XenApp server image joins or rejoins the farm after it has been cloned with its final

identity.

Important: Cloning is not supported for the f irst server in the farm (where you created the farm during configuration), andshould be used only for creating new member servers for an existing farm.The following descriptions assume you already created a XenApp farm containing at least one server. You need the data

store database information and credentials for the farm.

Approach 1: Capture an image after XenApp installation, but before configuration and restart

In this approach, you install the XenApp server role, but wait to configure XenApp (join a farm) until after the server is cloned

and booted. XenApp server configuration is automated, using a script.

This approach is not supported in Citrix Provisioning Services using Shared Image mode.1. Install the XenApp server role, but do not configure the server. You may want to restart the server to ensure the system

path is updated properly before installing other applications. Deploying prerequisites such as Remote Desktop Services

roles may require a server restart before you can install XenApp.

2. Install your applications and configure the settings you want in your image.

3. Run the generalization tools you normally run.

4. Set up a script to run when each cloned server boots. This script configures the XenApp server (including farm

information) using the command line (XenAppConfigConsole.exe). The script then restarts the server, whereupon the

server joins the farm.

You can set up scripts using typical methods such as Active Directory startup scripts or the RunOnce registry key.

5. Capture an image of the server.

Approach 2: Capture an image after XenApp installation and configuration, but before restart

In this approach, you install and configure the XenApp server role, but wait to restart the server until after it is cloned. When

the server restarts as a clone of the original image, it joins the farm with its new identity.

You do not need direct access to your database server or network during configuration, so this approach can be used toprepare XenApp images for remote deployments. If you do not or cannot verify your database credentials, and they areinvalid, XenApp will not join the farm when the server restarts. In that case, run the XenApp Server Configuration Tool,providing correct credentials, and then recapture an image.1. Install your applications and configure the settings you want in your image.

2. Install the XenApp server role. Deploying prerequisites such as Remote Desktop Services roles may require a server restart

before you can install XenApp.

3. Configure the XenApp server to add the server to (join) a farm, but do not restart the server.




Note: If you are using the SmartAuditor agent or other features that depend on Microsoft Messaging Queuing (MSMQ),use the updated XenApp Server Configuration Tool and the procedure in Approach 3.

Approach 3: Capture or update an image after XenApp installation, configuration, and restart

If you require XenApp to be installed and working before you create a final image, you must remove the server 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.

Note: You can use this approach with the XenApp Server Configuration Tool included on the XenApp 6 for Windows Server2008 R2 installation media. However, the process is streamlined and more effective if you use the updated XenApp ServerConfiguration Tool (see CTX124981) before installing XenApp.1. Install the XenApp server role.

Optionally, install the Provisioning Services Target Device software. This software resets your network connection during

installation. Failures may occur if you install this component from a network location. Although these failures are not

commonly harmful, Citrix recommends installing the Provisioning Services Target Device software from a DVD, mounted

ISO, or local copy of the installation media.

2. Configure XenApp to join a farm, and then restart (reboot) the server.

3. Install your applications and configure the settings you want in your image.

4. If you are using the Server Configuration Tool from the XenApp 6 for Windows Server 2008 R2 installation media:

1. From the XenApp Server Role Manager, edit your configuration and choose the task to remove the server from the

farm. (For a command-line configuration, specify the /ExecutionMode:Leave option.)

2. If you are provisioning the XenApp server with SmartAuditor agent or other features that depend on MSMQ, you

must enable MSMQ (manually or scripted) to reset its identif ier when the server image boots.

3. Edit your configuration to join the farm again (this requires providing database credentials).

If you installed the updated XenApp Server Configuration Tool, edit your XenApp configuration and select the task

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, enable the Remove this

current server instance from the farm checkbox. (For a command-line configuration, use the

/RemoveCurrentServer:True option.)

If you are provisioning the XenApp server with SmartAuditor or other features that depend on MSMQ, enabling the

Prepare Microsoft Messaging Queuing provisioning checkbox ensures a new unique machine identif ier when the

server image boots. (For a command-line configuration, use the /PrepMsmq:True option.)



The server joins the farm when the image boots.

Resealing an image

If a golden image requires updating (for example, with Citrix or Windows hotfixes, or third-party applications and patches),you can reseal the image. This procedure is similar to approach 3.1. Boot into the image to make modif ications. The XenApp server will try to join the farm if it can.

2. Modify the server as needed.

3. Proceed with step 4 in Approach 3.

During the resealing process, the updated Server Configuration Tool:



Removes server-specif ic information, such as WSID in MF20.dsn, WSID in RadeOffline.dsn.

Creates a unique Secure Ticket Authority (STA) ID in CtxSta.config, using the MAC address.

Resets the local databases and removes the Servers setting from the Independent Management Architecture (IMA) data

store by clearing the IMA local host cache and RadeOffLine databases.

Places the following configuration information into the Local Group Policy Object (LGPO) if they have nondefault values

(nondefault values appear as configured, default values appear as not configured).

Product feature and server edition

License server hostname

License server port number

XML Service port

Installation and Configuration Considerations

For provisioning purposes, you can install the XenApp server role using the wizard-based XenApp Server Role Manager or the

command line. For wizard-based installations, do not proceed to configuring the XenApp server role until you are ready,

based on the approach you select.

When preparing a XenApp server for imaging and provisioning:The server should not be the only server in the XenApp farm.

The server should not be the data collector.

The server should not have the data store database installed on it.

The server should not have the Citrix License Server installed on it.

Important: When provisioning XenApp, you must remove the server SSL certif icate before running XenConvert; otherwise,the SSL certif icate 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 theProvisioning Services target device, and excludes installation of the Delivery Services Console.\XenApp Server Setup\bin\XenAppSetupConsole.exe /install:XenApp,PVDeviceFeature /exclude:XA_ConsoleConfiguring the XenApp server after it is instanced (approach 1) should be automated using the command line. You can use

the wizard-based XenApp Server Configuration Tool or the command line to configure the XenApp server if you choose

approach 2 or 3.

For example, the following command, issued from the typical XenApp Server Configuration Tool location (C:\Program Files(x86)\Citrix\XenApp\ServerConfig\XenAppCOnfigConsole.exe), joins the server to the farm, specifying database credentialsand the DSN file location, license server information, log f ile location, and Remote Desktop User Group configurationsettings.“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\ -XenAppConfigConsole.exe" /ExecutionMode:Join /OdbcUserName:administrator /OdbcPassword:somepasswd /LicenseServerName:somelicenseserver /LicenseServerPort:27000 /ZoneName:some_zone_name /DsnFile:"c:\somepath\to\example.dsn" /Log:c:\SomewhereConfigLog.txt /CustomXmlServicePort:8080 /AddAnonymousUsersToRemoteDesktopUserGroup:True /AddUsersGroupToRemoteDesktopUserGroup:True /AddAuthenticatedUserstoRemoteDesktopUserGroup:TrueThe following command prepares XenApp for imaging and provisioning. The server will be removed from the current farm,and when the server image boots, it will contain a unique MSMQ machine identif ier.


“C:\Program Files (x86)\Citrix\XenApp\ServerConfig\ -XenAppConfigConsole.exe" /ExecutionMode:ImagePrep /RemoveCurrentServer=True /PrepMsmq:True


Data Store Database Reference

Apr 21, 2015

See the database vendor documentation before installing, configuring, and using the database software. CTX114501

contains information about supported database versions.

If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp configuration automatically

installs it.

Important:Citrix does not support case-sensitive databases.

To avoid corruption, do not directly edit data in the data store database with utilities or tools other than those provided

by Citrix.

Maintaining, Backing up, and Restoring a XenApp Data Store

Most database maintenance requires running the dsmaint and dscheck commands on XenApp farm servers. The XenApp— Commands Reference

documentation contains syntax and use details.

Use dsmaint to:Upgrade the XenApp data store

Move the data in the data store to a different database server

Change the name of the DSN file

If the data store fails, each farm server can run from the data in its Local Host Cache indefinitely, provided it can contact

the license server. However, you cannot make any modifications to the farm or use the Delivery Services Console.

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 command. Without a backup, prepare

a new data store the way you did before configuring XenApp and run the Server Configuration Tool from any farm server.

After running the Server Configuration Tool, manually reenter the lost settings. If you use the same name as the previous

data store, you do not need to reconfigure the farm servers.

Microsoft SQL Server Database

The server hosting the Microsoft SQL Server database should meet the following minimum requirements:Approximately 100MB of disk space for every 250 servers and 50 published applications in the XenApp farm. Provide more

disk space for greater numbers of published applications.

Set the "temp" database to automatically grow on a partition with at least 1GB of free disk space. Citrix recommends

4GB if the farm is large and includes multiple print drivers.

The default database installation settings and database sizes usually suffice for XenApp data store needs.

Microsoft SQL Server supports Windows and Microsoft SQL Server authentication. For high-security environments, Citrix

recommends using Windows authentication only.

The user account for installing, upgrading, or applying hotfixes to the data store must have database owner (db_owner)



rights to the database. When you finish installing the database with database owner rights, set the user permissions to

read/write only to increase the security of the database. Change the rights back to database owner before installing

service packs or feature releases; installations can fail if the user account used to authenticate to the data store during

Setup does not have database owner rights.

When using Microsoft SQL Server in a replicated environment, use the same user account for the data store on each

Microsoft SQL Server.

Each farm requires a dedicated database. However, multiple databases can be running on a single server running Microsoft

SQL Server. Do not configure the farm to use a database that is shared with any other client/server applications.

Back up the database regularly and follow Microsoft recommendations for configuring database and transaction logs for

recovery (for example, setting the Truncate log on Checkpoint option to control log space).

Using Sockets to Connect to a Microsoft SQL Server Database

Two protocols used to connect to a database are TCP/IP sockets and named pipes. Named pipes is an authenticated

communication protocol, so any time you attempt to open a connection to the SQL Server database using this protocol,

the Windows authentication process occurs. TCP/IP sockets do not rely on Windows authentication to establish a

connection, but do provide user/password authentication to the database after the connection is established. Windows

authentication reduces the possibility of an error occurring when the server hosting SQL Server and the XenApp server do

not have the correct domain or Active Directory trust relationship. Therefore, Citrix recommends using TCP/IP sockets.

If you use named pipes, manually enable the named pipes option on the database server using the Surface Area

Configuration tool packaged with SQL Server.

Creating a Microsoft SQL Server Data Source Connection

1. On the Create a New Data Source to SQL Server screen, enter the data source description and select the SQL Server to

which to connect.

2. Select Windows NT Authentication or SQL Server Authentication.

3. Click Client Configuration.

4. Select TCP/IP from the available network libraries.

5. After installing XenApp, modify the Data Source Name (DSN) created during configuration and change its client

configuration to use TCP/IP.

To modify a DSN, use the Windows ODBC Data Source Administrator utility to open the File DSN, which is located by

default in the %ProgramFiles(x86)%\Citrix\Independent Management Architecture folder, and select TCP/IP as the

connection protocol for the client configuration.

Using Failover with Microsoft SQL Server

For fault tolerance with Microsoft SQL Server, use Microsoft clustering, which provides failover and failback for clustered

systems. Failover of the SQL Server database in a clustered environment is transparent to XenApp.

The database files for an instance of Microsoft SQL Server are placed in a single cluster group owned by the node on which

the instance is installed. If a node running an instance of Microsoft SQL Server fails, the cluster group containing the data

files for that instance is switched to another node. The new node already has the executable files and registry information

for that instance of Microsoft SQL Server on its local disk drive, so it can start up an instance of Microsoft SQL Server and

start accepting connection requests for that instance.

Microsoft Cluster Services clustering does not support load balancing among clustered servers because it functions in


active/passive mode only.

Using Distributed Databases with Microsoft SQL Server

XenApp supports distributed (replicated) databases. Replicated databases are useful when too many read requests to the

data store create a processing bottleneck. Microsoft SQL Server uses replication to create the distributed database

environment.

XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for storing

data in the database. When configuring Microsoft SQL Server for a two-phase commit, use the Immediate Updating

Subscriber model.

When configuring Microsoft SQL Server, you may need to increase the value of the Max Text Replication Size property to

improve replication performance.

Caution: To avoid corruption, do not use merged replication.To set up a distributed environment for an existing XenApp farm:1. Configure a Publisher (the Microsoft SQL Server currently hosting the data store) and Subscribers (remote sites) using

Microsoft SQL Server Enterprise Manager.

2. Run the dsmaint publishsqlds command on a server in the farm. This executes the necessary SQL statements to create

the published articles on the current Microsoft SQL Server (Publisher).

3. Configure the remote sites (Subscribers) to subscribe to the published articles created in the previous step.

Oracle Database

The server hosting the Oracle database should meet the following minimum requirements:Approximately 100MB of disk space for every 250 servers and 50 published applications in the farm. Provide more disk

space for greater numbers of published applications.

20 MB minimum tablespace size.

Oracle supports Windows and Oracle authentication. Oracle for Solaris supports Oracle authentication only; it does not

support Windows authentication.

In the Oracle sqlnet.ora file, set SQLNET.AUTHENTICATION_SERVICES= (NONE). The default setting (NTS) will cause

connection failures.

Do not install XenApp on a server hosting an Oracle database.

Install the Oracle client on the server where you will be installing XenApp and then restart the server before you install

XenApp.

The Oracle user account must be the same for every server in the farm because all XenApp servers share a common schema.

If you are using one database to hold information for multiple farms, each farm represented in the database must have a

different user account because the data store information is stored in the Oracle user account.

The account used to connect to the data store database has the following Oracle permissions:Connect

Resource

Unlimited Tablespace (optional)

Consider the following guidelines when configuring an Oracle server.


Use Shared/Multi-Threaded Server mode to reduce the number of processes in farms with more than 100 servers

(performance may be affected during periods of high data store load).

If you are using Multi-Threaded Server mode, verify that values in the Init.ora f ile are greater than or equal to the

following values. If you are running multiple farms on the same Oracle database, include all XenApp servers in the

calculations. Round up fractional values.

shared_servers = Number of servers / 10

max_shared_servers = Number of servers / 5

Where Number of servers is the total number of servers running XenApp.

When using an Oracle server in dedicated mode, add one additional process for each server connected directly to the

Oracle database. For example, if the Oracle server uses 100 processes before installing XenApp, and the farm has 50

servers, set the processes value to at least 150 in the Init.ora f ile on the Oracle server.

Create online backups using Archivelog mode, which reduces the recovery time of an unresponsive database.

If you are using the same Oracle database for multiple server farms, create a unique tablespace with its own user name

and password for added security for each farm. Do not use the default system account within Oracle.

Maintain a standby database for quick disaster recovery. A standby database maintains a copy of the production

database in a permanent state of recovery.

Using Distributed Databases with Oracle

Oracle uses replication to create the distributed database environment. To reduce the load on a single database server,

install read/write replicas and distribute the farm servers evenly across the master and replicas.

XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for writes

to the database.

Using Oracle as a distributed database solution has the following requirements:All participating databases must be running Oracle.

All participating databases must be running in Multi-Threaded Server/Shared mode (rather than Dedicated mode).

All Oracle clients (XenApp servers that connect directly to the Oracle database) must be SQL*Net Version 2 or Net8.

Install the farm data store database f irst on the master site, then configure replication at the sites used for database

replication snapshots.

Replicate all objects contained in the data store user schema (tables, indexes, and stored procedures).

If the performance at the replicated database site is significantly slower, verify that all the indexes for the user’s schema

are successfully replicated.

When configuring Oracle for a two-phase commit:Use synchronous snapshots that can be updated with a single master site. XenApp requires write access to snapshot.

Use the Oracle Fast Refresh feature where possible (this requires snapshot logs).

When setting up the replication environment, do not configure conflict resolution.

Set the replication link interval to be as frequent as the network environment allows. With Oracle replication, if no

changes are made, data is not sent over the link.

When Oracle is configured in Multi-Threaded Server mode and remote data transfers are initiated from the remote site,

they can block local data transfers (because all connections share a set of worker threads). To remedy this, increase the

value of the Max_Mts_Servers parameter in the Init.ora f ile.


XenApp 6 Migration Tool

Nov 28 , 2011

The XenApp 6 Migration Tool comprises PowerShell cmdlets packaged as a PowerShell 2.0 module. The Migration Tool pulls

data from a legacy XenApp farm and imports (adds) it to your new XenApp 6 server farm.

You install the Migration Tool and run the cmdlets on a server in the new XenApp 6 farm. When you start a migration, you

point to a remote server in the legacy XenApp 5 farm. The Migration Tool uses MFCOM to communicate with that remote

server; the Migration Tool uses XenApp 6 commands to communicate with the new XenApp 6 farm.

Citrix recommends performing the migration entirely from a server in the new XenApp 6 farm; this is called a direct migration.

However, if your deployment does not allow this, see— Advanced Cmdlets

for information about indirect migrations.

Settings are grouped as object types. You can migrate all object types at once, or include and exclude object types and

named objects in the migration. You can specify new values for migrated object properties. Servers in the legacy farm are

migrated to worker groups in the new farm according to server mappings you specify.

Repeat the migration as additional servers in the legacy farm become ready for reimaging in the new farm. During

subsequent migrations, the XenApp 6 Migration Tool compares newly-migrated objects from the legacy farm with

previously-migrated object in the new farm. Previously-migrated objects in the new farm are updated if needed.

For example, assume you migrate applications from the legacy farm in June, then change the configuration of Application

XYZ in the legacy farm in September. When you migrate applications again in December, the configuration of Application

XYZ is updated in the new farm.

However, if you migrate settings, then change them in the new farm, a later migration of the same objects will overwrite

the new settings with the legacy farm values.

As the migration of more legacy farm servers continues, use the Web Interface user roaming feature to help ensure that

users can access applications and resources.

Objects You Can Migrate

You can migrate the following XenApp object types.

Object Type Description

Application All applications are enumerated; however, for the corresponding worker group to be associated with

the application, the application must be published to one of the servers specified in the server mapping

file. Only users that can be resolved on the server in the new farm (account authorities that are trusted

in the new farm) are migrated.

Folder Includes application folders and server folders. Server folders are migrated so that server permissions

can be copied; however, the server objects are not migrated.

Load

evaluator

Load evaluators and their rules are migrated. Migrated load evaluators are attached to applications

(where applicable), but they are not attached to servers.


Policy Policies are migrated by creating an IMA (Independent Management Architecture) User GPO (Group

Policy Object) with the same name as the policy. Server filters are migrated by using the Server Group

(worker group) filter for the servers in the mapping file. For user filters, only the accounts that can be

resolved on the target server in the new farm (account authorities that are trusted in the new farm)

are migrated.

The Zone Preference and Failover policy is converted to a Worker Group Preference and Failover policy.

Servers in the zone that are specified in the server mapping file resolve to a worker group.

Server

configuration

Configuration settings for servers specified in the server mapping file are migrated by creating an IMA

Machine GPO named "WorkerGroupname" where name is the name of the worker group specified in

the server mapping file. This policy is filtered by worker group. Worker groups are created as necessary,

but they are not associated with servers or OUs (Organizational Units).

Farm

configuration

Farm configuration settings are migrated by creating an IMA Machine GPO named "Farm." This policy is

unfiltered.

Administrator Only Citrix administrators whose accounts can be resolved on the server in the new farm are migrated

(the corresponding account authorities are trusted in the new farm or they represent Citrix built-in

accounts).

Object Type Description

Farm and server settings from the legacy farm are compared against the default values used when the new XenApp farm

was created. The corresponding setting in the policy in the new farm is set to "Not Configured" if it matches the default

value for the same setting in the new farm.

Health Monitoring and Recovery (HMR) test executables are not copied; however, HMR test configurations are migrated

into policies in the new farm.

You cannot transfer the following settings using the Migration Tool:Zones

Printer management

Configuration Logging settings

Only settings that reside in the IMA data store are migrated; settings that reside only in the server registry are not migrated.

The migration process ignores the following settings:Deprecated settings, such as AIE (Application Isolation Environment).

Permissions that do not exist in the XenApp 6 for Windows Server 2008 R2 release, whether they correspond to a

deprecated feature or a configuration setting that is now supported as a policy.



Jul 06, 2010

You can migrate a single XenApp 5 farm (multiple farm consolidation to a single farm is not supported).

You should be familiar with MFCOM and PowerShell.

Requirements for the Legacy Farm

The servers in the legacy farm must be running XenApp 5 for Windows Server 2003 with Hotfix Rollup Pack 5 (HRP5) or

XenApp 5 for Windows Server 2008.

The legacy farm server from which you are exporting must have network COM+ access enabled.

To access the XenApp 5 server in the legacy farm using a remote connection, you must be a member of the DCOM users

group, and you must be a Citrix administrator with at least view-only privileges in the legacy farm.

When migrating from a 32-bit XenApp farm to a XenApp 6 farm, network printers used by policies (session printers) must

have a 64-bit driver installed in the print server; otherwise, those printers will not be migrated.

Requirements for the New Farm

The servers in the new farm must be running XenApp 6 for Windows Server 2008 R2.

To install the Citrix XenApp Migration Module, you must have permission to install components. To run the XenApp 6

Migration Tool cmdlets, you must be a Citrix administrator with full privileges.

You must have write access to the folder where the migrationoptions.xml f ile (containing server mappings, migration

options, and object property overrides) and the exported data from the legacy farm is placed. By default, this is a folder

named Data, located under the XenApp 6 Migration Tool installation f iles in

C:\Users\user\appdata\local\citrix\citrix.xenapp.migration). You can specify a different folder with the -DataFolderPath

option in the Set-XAMigrationOption cmdlet.

By default, execution of PowerShell scripts is disabled. To run the XenApp 6 Migration Tool cmdlets, sign the scripts or

enable the scripts to run (Set-ExecutionPolicy RemoteSigned). You are prompted during installation if this has not been

done.

If your legacy farm uses f ile type association for published applications, update the new farm with f ile type associations

(using the Update f ile types from registry task in the Delivery Services Console) before you migrate applications. This

allows the migration process to create the associations in the new farm.

Create worker groups in the new farm for server and application silos. (However, if a worker group specif ied in a server

mapping does not exist, the XenApp 6 Migration Tool creates it.)

The following software is required to install the Citrix XenApp Migration Module and run the cmdlets. This software is

required for XenApp server installation and configuration, so it is likely to already be installed.

.NET Framework 3.5 SP1

MSI 3.0

PowerShell 2.0

If you installed the beta version of the XenApp 6 Migration Tool, manually uninstall it and then delete the folder

\users\user\AppData\Local\Citrix\Citrix.XenApp.Migration before installing the newer version of the tool.

Installing the XenApp 6 Migration Tool

Install the XenApp 6 Migration Tool on one server in the new farm. In most cases, this is the server where you installed andconfigured XenApp 6 to create the farm.1. Download the XenApp 6 Migration Tool from My Citrix.


2. Double-click Citrix.XenApp.Migration.exe; the self-extracting executable launches an MSI that installs the module. During

installation, you are prompted to set the PowerShell execution policy to unrestricted, if the current policy setting differs.

3. The installer creates shortcuts in the Start menu. Clicking (launching) the shortcut opens PowerShell and loads the

module. (If you do not use the shortcut, open a PowerShell console and type Import-Module Citrix.XenApp.Commands.)

When launching the XenApp 6 Migration Tool, restart the server if you receive the following error message: Import-Module: The specified module 'Citrix.XenApp.Migration' was not loaded because no valid module file wasfound in any module directory.

Note: Citrix recommends performing the migration entirely from a server in the new farm. If your deployment does notallow this, see Advanced Cmdlets.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-migrate-xa6-wrapper/ps-migrate-xa6-advanced.html


Using the XenApp 6 Migration Tool Cmdlets

Jul 06, 2010

Run the XenApp 6 Migration Tool cmdlets from the PowerShell console.

1. Before starting a migration, use the following cmdlets to build a f ile containing server mappings and optionally, migration

options and property value overrides.

Use the Add-XAServerMapping cmdlet to map servers in the legacy farm to worker groups in the new farm. The

servers in the mapping are representative servers chosen from each server silo in the legacy farm. Server mappings are

not required, but a XenApp farm cannot be completely migrated without them (without server mappings, no data

about the servers will be migrated; for example, server settings, application servers, or Zone Preference and Failover

policy).

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

To remove a server mapping, use the Remove-XAServerMapping cmdlet.

Use the Set-XAMigrationOption cmdlet to tailor the migration. Setting migration options is optional; it offers

f lexibility in tailoring your migration.

You can specify a remote server name; this is the name of the server in the legacy farm from which objects will be

migrated. Specifying the remote server name as a migration option eliminates having to specify it each time you start

a migration.

You can also optionally specify a nondefault folder location where the exported data from the legacy farm is stored,

and object types or named objects to include or exclude from the migration.

To display the migration options you specif ied, use the Get-XAMigrationOption cmdlet.

Use the Add-XASettingOverride cmdlet to specify values for individual object properties, if you do not want to use the

migrated values in the new farm. Specifying setting overrides is optional.

To display the names of object properties you can specify with the Add-XASettingOverride cmdlet, use the Get-

XALegacySettingName cmdlet.

To display the property override values you specif ied, use the Get-XASettingOverride cmdlet.

To remove a property override value you specif ied, use the Remove-XASettingOverride cmdlet.

2. Launch the migration with the Start-XAMigration cmdlet.

To see what would happen during the migration (for example, which objects are migrated and updated, and changes

to property values) without actually performing the action, use the -PendingReportOnly option. This option provides

more detailed output than the -WhatIf PowerShell common parameter.

3. After running a migration, use the Get-XAMigrationObjectCount cmdlet to display a count of the objects in the legacy

and new farms. This helps monitor equivalency between the new farm and the legacy farm. You can tailor the display to

report differences from an existing snapshot.

Subsequent migrations (using the Start-XAMigration cmdlet) will use the current specifications in the server mappings,

migration options, and property value overrides file.

Post-migration Tasks

Associate servers or OUs with worker groups.

Associate application folders with worker groups.

Attach load evaluators to servers.

Assign zones.


Configure printer settings.

Initiate Configuration Logging in the new farm.

Configure Health Monitoring settings.

Optionally, add new servers in the old server folder hierarchy to preserve delegated permissions.

To enable streamed-to-server applications to launch after migrating from a 32-bit XenApp farm to a XenApp 6 farm,

rebuild profiled applications.


Cmdlet Reference

Jun 04 , 2010

Cmdlet Summary

For PowerShell help, type Get-Help cmdlet-name.To see examples, use the -examples option.

For detailed information, use the -detailed option.

For technical information, use the -full option.

Cmdlet Description

Add-XAServerMapping Adds a server mapping.

Add-XASettingOverride Specif ies a value for an object property.

Get-XALegacySettingName Outputs the settings you can use with the Add-XASettingOverride cmdlet.

Get-XAMigrationObjectCount Outputs a count of objects in the legacy and new farms.

Get-XAMigrationOption Outputs the list of migration options.

Get-XAServerMapping Outputs the list of server mappings.

Get-XASettingOverride Outputs the list of object property value overrides.

Remove-XAServerMapping Removes a server mapping.

Remove-XASettingOverride Removes an object property value override.

Set-XAMigrationOption Sets migration options.

Start-XAMigration Starts the migration.

The Migration Tool cmdlets support the PowerShell common parameters. In particular, -Confirm and -Verbose can be helpful

in the migration process.

Although the -WhatIf common parameter is supported, using the -PendingReportOnly option with the Start-XAMigration

cmdlet provides more detailed information.

Add-XAServerMapping

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-migrate-xa6-wrapper/ps-migrate-xa6-cmdlet-ref.html












Adds a mapping between a server in the legacy farm and a worker group in the new farm. You must specify the followingoptions:

Option Description

-ServerName server-name MFCOM name of the server in the legacy farm.

-WorkerGroupNamename

Name of the worker group in the new farm. If the worker group does not exist, it iscreated.

For example, the following cmdlet maps the server named OfficeApps5 to the worker group named DenverAcctg.Add-XAServerMapping -ServerName OfficeApps5 -WorkerGroupName DenverAcctgAdd-XASettingOverride

Specifies a value for an object property (setting). This value is used for the object property in the new farm, regardless of

the value of the property in the legacy farm (it overrides the setting in the legacy farm). To display the names of object

properties you can specify with the Add-XASettingOverride cmdlet, use theGet-XALegacySettingName cmdlet.

You can specify the following options:

Option Description

-PropertyName

property-name

Property name. You can use wildcards.

-ObjectType object-

type

Object type.

Valid values are: Administrator, Application, FarmConfiguration, Folder, LoadEvaluator, Policy, and

ServerConfiguration. You can use wildcards.

-Value New property value.

-MatchValue Original property value to match before overriding the setting with the new value. If the value

does not match, the override is skipped.

If this option is omitted, the override always occurs.

-ObjectName

object-name

Object name.

For example, the following cmdlet specif ies a CPU priority level of "high" for migrated applications in the new farm.Add–XASettingOverride CpuPriorityLevel HighThe following cmdlet changes the CommandLineExecutable property value to C:\Program Files\Test\Test.exe when itscurrent value is C:\ProrgramFiles (x86)\Test\Test.exe.Add-XASettingOverride -PropertyName CommandLineExecutable -ObjectType Application


-Value "C:\Program Files\Test\Test.exe" -MatchValue "C:\Program Files (x86)\Test\Test.exe"Get-XALegacySettingName

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

Option Description

-PropertyName

property-name

Property name. You can use wildcards.

-ObjectType object-

type

Object type.


ServerConfiguration. You can use wildcards.

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

Outputs counts of objects in the legacy and new farms. Use the -ImportOnly option to generate the differences from an

existing snapshot.

Get-XAMigrationOption

Outputs the list of migration options (that is, the migration options previously specified with Set-XAMigrationOption

cmdlets).

Get-XAServerMapping

Outputs the list of all server mappings (that is, the mappings previously specified with Add-XAServerMapping cmdlets).

Get-XASettingOverride

Outputs the list of setting overrides (that is, object property values previously specified with Add– XASettingOverride

cmdlets).

Remove-XAServerMapping

Removes a server mapping (that is, a mapping previously specified with an Add-XAServerMapping cmdlet).

Remove-XASettingOverride

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

Set-XAMigrationOption

Sets migration options.


Option Description

-

RemoteServerName

name

Name of the server in the legacy farm from which objects will be exported. This value is used if

you do not specify the -RemoteServerName option in the Start-XAMigration cmdlet.

If you do not specify the -RemoteServerName option in the Start-XAMigration or Set-

XAMigrationOption cmdlet, the migration ends.

-DataFolderPathpath

Path to the folder where exported data from the legacy farm is placed. If the folder does not

exist, the Migration Tool will attempt to create it.

If you do not specify this option, exported data is moved to the Data folder located under the

Migration Tool installation files.

-ObjectType

object-type

Object type. This option is used with the – Include and – Exclude options, which specify object

names.


ServerConfiguration.

-Include object-

name

Object names to include in the migration. This option is used with the – ObjectType option.

Separate multiple object names with commas. You can use wildcards.

-Exclude object-

name

Object names to exclude from the migration. This option is used with the – ObjectType option.

Separate multiple object names with commas. You can use wildcards.

-Enabled $false |

$true

Provides an alternative to using the -Exclude * option to exclude all objects specified with the -

ObjectType option from the migration.

For example, the following cmdlet uses the -ObjectType and -Exclude options to exclude applications named "A1" and "A2"from the migration.Set-XAMigrationOption –ObjectType Application –Exclude A1, A2The following cmdlet uses the -ObjectType, -Include, and -Exclude options to include all applications with a namecontaining "Microsoft" except "Office."Set-XAMigrationOption –ObjectType Application –Include *Microsoft* –Exclude *Office*The following cmdlet uses the -ObjectType and -Enabled options to disable migration of all applications.Set-XAMigrationOption –ObjectType Application –Enabled $falseStart-XAMigration

Launches the migration. You can specify the following options:

Option Description


-

RemoteServerName

name

Name of the server in the legacy farm from which objects will be exported.

If you do not specify this option, but you specified a -RemoteServerName option in the Set-

XAMigrationOption cmdlet, that name is used.

If you do not specify the -RemoteServerName option in the Start-XAMigration or Set-

XAMigrationOption cmdlet, the migration ends.

-

PendingReportOnly

Generates records that indicate which objects will be migrated and which values will be changed,

but does not actually perform the migration.

This option provides more detail than the standard PowerShell -WhatIf option.

-ExportOnly Exports objects from the legacy farm to a file, but does not import them to the new farm.

This option is generally used only when MFCOM cannot be used between the legacy farm and

the new farm. In this case, use a Start-XAMigration – ExportOnly cmdlet on a server in the legacy

farm.

-ImportOnly Imports objects to the new farm.

This option is generally used only when MFCOM cannot be used between the legacy farm and

the new farm. In this case, use a Start-XAMigration – ExportOnly cmdlet on a server in the legacy

farm, collecting exported information in a file. Then, use a Start – XAMigration – ImportOnly

cmdlet on a server in the new farm to import the objects, using the exported information.

Option Description


Advanced Cmdlets

Jul 06, 2010

Using the Migration Tool on Separate Servers (Indirect Migration)

Citrix recommends performing the migration entirely from a server in the new farm (a direct migration). However, if youcannot use MFCOM to communicate between the legacy farm and the new farm, perhaps because the two farms are indifferent domains that do not have a trust relationship, you can perform an indirect migration. In this case, you must alsoinstall the XenApp 6 Migration Tool on a server in the legacy farm, in addition to installing it on a server in the new farm. Foran indirect migration, after you install the XenApp 6 Migration Tool on a server in the new farm:1. On a server in the legacy farm:

1. Install the required software (.NET Framework 3.5 SP1, MSI 3.0, and PowerShell 2.0).

2. Download the XenApp 6 Migration Tool from My Citrix.

3. Install the XenApp 6 Migration Tool (32-bit or 64-bit version, depending on the legacy server operating system).

4. Build a f ile containing server mappings, migration options, and property value overrides, as described in Using the

XenApp 6 Migration Tool Cmdlets.

5. Export settings using the Start-XAMigration cmdlet with the -ExportOnly option. The output is a series of XML f iles.

2. Copy the XML f iles to the server in the new farm, replacing the f iles on that server. This includes the f ile containing server

mappings, migration options, and property value overrides.

3. From the new farm, issue a cmdlet to import the settings (using the Start-XAMigration cmdlet with the -ImportOnly

option or using one of the advanced import cmdlets .

Advanced Import Cmdlets

The Start-XAMigration cmdlet is intended for scripted, unattended migrations. For interactive testing, the XenApp 6

Migration Tool includes additional object-specific import cmdlets. These cmdlets offer alternatives to using the –

ImportOnly option with the Start-XAMigration cmdlet and the -ObjectType and -Include options with the Set-

XAMigrationOption cmdlet.

You can also use these cmdlets during indirect migrations.

These cmdlets use the configured server mappings, migration options, and object property value overrides.

For complete PowerShell syntax, type Get-Help cmdlet.Import-XAApplication

Import-XAFolder

Import-XALoadEvaluator

Import-XAPolicy

Import-XAServerConfiguration

Import-XAFarmConfiguration

Import-XAAdministrator

Advanced XALegacy Cmdlets

Using the advanced XALegacy cmdlets can be helpful if an object did not migrate as expected. The Get-XALegacy* cmdlets

connect to the legacy farm and read the settings for an object in the legacy farm. You can use the Convert-

XALegacyObject, New-XALegacyConnection, and Remove-XALegacyConnection cmdlets when creating a custom

migration script that does not use the Import-XA* or Start-XAMigration cmdlets.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-migrate-xa6-wrapper/ps-migrate-xa6-using-cmdlets.html


For complete PowerShell syntax, type Get-Help cmdlet.Get-XALegacyAdministrator

Get-XALegacyApplication

Get-XALegacyFarmConfiguration

Get-XALegacyFolder

Get-XALegacyHmrTest

Get-XALegacyLoadEvaluator

Get-XALegacyPolicy

Get-XALegacyPolicyConfiguration

Get-XALegacyPolicyFilter

Get-XALegacyServer

Get-XALegacyServerConfiguration

Get-XALegacySessionPrinter

Convert-XALegacyObject

New-XALegacyConnection

Remove-XALegacyConnection

These advanced cmdlets include objects that cannot be migrated alone (for example, session printers that are inside a user

policy, and HMR tests that are inside farm or server settings). This greater granularity may be helpful when troubleshooting

migration, because these objects are more complex, with multiple sets of properties.


Management Consoles and Other Tools

May 16, 2015

Citrix provides a comprehensive set of tools for managing servers, farms, published resources, and connections.

You can launch all tools by accessing the Citrix program group on the Start menu.

Delivery Services Console

The Delivery Services Console is a tool that snaps into the Microsoft Management Console (MMC) and enables you to

perform a number of management functions.

For Citrix XenApp, you can set up and monitor servers, server farms, published resources, and sessions. Configure application

access (both through the Web Interface and the Citrix online plug-in) and set up policies and printers.

In addition, you can manage load balancing, troubleshoot alerts, diagnose problems in your farms, view hotfix information

for your Citrix products, and track administrative changes.

My Views are configurable displays that give you quick access to items you must examine regularly or items in different

parts of the console tree that you want to group together. For example, create a My View display to monitor your

preferred performance data for two sets of servers in different server farms. The performance-related information in a My

View display is refreshed at regular intervals.

With Hotfix Management, check which hotfixes are applicable to your Citrix products, search for particular updates on your

system, and identify servers where up-to-date hotfixes must be applied. In the left pane of the console, select Citrix

Resources > Configuration Tools > Hotfix Management.

If your deployment includes multiple XenApp farms (such as one farm comprising servers running XenApp 6 for Windows

Server 2008 R2, and another farm comprising servers running XenApp 5), you can use one MMC console that has separate

Delivery Services Console snap-ins to manage each farm.

License Administration Console

Use this console to manage and track Citrix software licenses. For more information about licensing, see the License

Administration console Help and the— Getting Started with Citrix Licensing Guide

in Licensing Your Product.

Citrix SSL Relay Configuration Tool

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

Shadow Taskbar

Shadowing allows users to view and control other users’ sessions remotely. Use the Shadow Taskbar to shadow sessions

and to switch among multiple shadowed sessions. You can also shadow ICA sessions with the Access Management Console

or Delivery Services Console.

SpeedScreen Latency Reduction Manager

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

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-install-configure-v2.html


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.

To start the console and discover servers

When you install the first server in a new server farm, you provide credentials for a full authority Citrix administrator. This

account has the authority to manage and administer all areas of farm management. If you are logging on to the Delivery

Services Console for the first time, use this account to log on and to add other individuals to the Citrix administrators group.

Citrix recommends that you use a domain account to run the console. You can use your local administrator account, but

the user name and password should be the same for all local administrator accounts for all servers in your farms.

Click Start > All Programs > Citrix > Management Consoles > Citrix Delivery Services Console.

The first time you open the Delivery Services Console you are automatically prompted to start the discovery process: you

select the components you want, configure the discovery process, and find the items to manage.

Discovery is an important operation that checks for items (such as devices or applications) that were added to or removed

from your XenApp environment. Appropriate changes then appear in the console tree.

After this, run the discovery process only if you want to refresh the view of your deployment. The console tree refreshes

automatically each time you add, remove, or modify items in your deployment.

When using discovery to connect to your XenApp deployment, you must specify the name or IP address of at least one

server in each farm that you want to manage. When discovery is complete, the console tree displays the items that you

specified.

You can configure discovery only for some components. The configuration process can vary among components. The

Configure and run discovery task appears in the Actions pane only for configurable components; otherwise, only the Run

discovery task is available.

1. In the console tree, select Citrix Resources or the product or component whose objects you want to discover.

2. Click Configure and run discovery, or to run discovery without any configuration, click Run discovery.

3. When discovering XenApp deployments, specify the name or IP address of at least one server running XenApp in each

farm that you want to manage.

To view zones

Zones can be viewed and configured in the console. For information on configuring zones, see To configure zones andback-up data collectors.1. Depending on the version of XenApp you have installed, from the Start menu, select All Programs > Citrix > Management

Consoles and choose Citrix Delivery Console.

2. In the left pane, expand the Zones node.

3. Under Zones, select a zone. The results pane displays the servers in the chosen zone.

To refresh user data automatically

Refreshing user data automatically is disabled by default. You can control the frequency of automatic updates to server,

server folder, and published application information on the Delivery Services Console. The auto-refresh settings apply only

https://taas.citrix.com/?utm_source=eDocs&utm_medium=web&utm_campaign=edocs-xenapp-6-consoles-page

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-maintain-wrapper-sub/ps-maintain-farm-infrastructure.html


to the Delivery Services Console you are running and not other instances of the console on your network.

Note: Do not enable this feature if you have many sessions, because it can affect performance.1. In the left pane, select one of these nodes (depending on what type of user data you want to refresh automatically):

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

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

The application for which you want to refresh the user data automatically

2. In the Actions pane or from the Other Tasks section (depending on the node that you selected), click Refresh user data

and choose one of these options:

Automatically refresh user data for servers. Selecting this option enables automatic refreshing of each server’s

configuration and connection information. After selection, the associated Refresh rate f ield becomes available.

Automatically refresh user data for farms and server folders. Selecting this option enables automatic refreshing of the

folder organization for farm and server. After selection, the associated Refresh rate f ield becomes available.

Automatically refresh user data for applications. Selecting this option enables automatic refreshing of each published

application’s configuration and connection information. After selection, the associated Refresh rate f ield becomes

available.

3. In the Refresh rate (seconds) box, select the number of seconds between each update (10, 30, 60, or 90).


Managing Citrix Administrators

Apr 27, 2015

Citrix administrators are individuals tasked with managing server farms.

To create a Citrix administrator

You can make any member of a Windows or Novell Domain Services for Windows account authority a Citrix administrator.

1. From the Start menu, select All Programs > Citrix > Management Consoles > Delivery Services Console.

2. In the left pane, expand Citrix Resources > XenApp and select a farm.

3. From the Actions pane on the right, click Add administrator.

4. Click Add and select the configured user or user group account to designate as a Citrix administrator.

5. On the Privileges page, select the authority level you want to grant the administrator account.

6. If you are creating a custom administrator account, in the Tasks pane, select the tasks you want to delegate to the

custom administrator.

To modify a Citrix administrator

1. From the Start menu, select All Programs > Citrix > Management Consoles > Delivery Services Console.

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:

To change an administrator's privilege level, open the Privileges page

To assign or update custom permissions, open the Permissions page

To disable a Citrix administrator

Disable a Citrix administrator if you want to temporarily remove access for an administrator but retain the account and

settings.

1. Select the administrator whose privileges you want to disable.

2. On the Actions pane, click Disable.

When an administrator is disabled, the administrator icon appears in grey and an Enable task becomes available.

To re-enable a Citrix administrator

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

To remove a Citrix administrator

Remove a Citrix administrator if you want to delete the account and settings. Only administrators with full access candisable 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.

Delegating Tasks to Custom Administrators

You can delegate tasks through the Delivery Services Console by associating custom Citrix administrator accounts with


permissions to perform select tasks.

Citrix recommends you create Windows, Active Directory, or NDS groups to assign these permissions. When you create

custom Citrix administrators, simply select the group instead of individual users. This allows you to add and remove users to

these groups without reconfiguring all of the permissions.

Permissions you set on nodes apply farm wide. Permissions you set on folders (applications, servers, and any folders within)

apply only to the applications and servers contained within the selected folder.

You cannot grant permissions to applications and servers directly. To grant permissions to applications and servers, youmust f irst place the applications or servers in folders and then grant permissions at the folder level. Therefore, before youdelegate tasks for applications and servers, make sure you group the applications and servers in folders that allow you todelegate the tasks in a meaningful way.Note: To apply the same permissions to a new folder as to its parent folder, select the Copy permissions from the parentfolder 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 Delivery Services Console.

2. From the left pane, expand Citrix Resources > XenApp and the farm, then choose the Administrators node.

3. On the Administrators tab, select the administrator to whom you want to delegate tasks.

4. From the right pane, under Actions, click Administrator properties.

5. In the Citrix Administrator Properties dialog box, on the Privileges pane, if Custom is not selected, select it.

6. Click Permissions to view the task permissions assigned to the administrator.

7. Click on a folder in the Folders list to view additional tasks.

8. To select the tasks to which the administrator has access, select or clear the check boxes, as appropriate.

9. If you set permissions on a node or a folder that contains a subfolder, the Copy to Subfolders button becomes active.

Click this button if you want to copy the permissions from the parent node or folder to the constituent folder.

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

To assign folder permissions

To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the farm level. To

view and change permission on objects, such as printers, you must be a Citrix administrator with full access to view and

change object permissions.


2. From the left pane, select the folder under the farm to which you want to grant access.

3. From the Actions pane, select Other Tasks, then Permissions. The resulting dialog box lists the administrators who

currently have access to the selected folder.

4. To give access to an administrator that is not on the Administrators list, click Add and then click the check box to allow

access to the folder.

If the administrator to whom you want to give access does not appear in the Add Access to folder dialog box, click Add

to create the administrator.

To assign or change object permissions

To allow custom administrators to perform specific tasks in the farm, you assign object permissions at the farm level. To

view and change permission on objects, such as printers, you must be a Citrix administrator with full access to view and

change object permissions.



2. From the left pane, select the farm to whose objects you want to grant access.

3. From the right pane, under Actions, choose Other Tasks, then Set permission on objects.

4. Select the object whose permissions you want to change and click Permissions.

Under Administrators, you can see the administrators who have access to tasks related to the object.

5. From the Administrators list select the administrator to whom you want to assign additional or change existing folder

permissions. If the administrator you want is not on the list, click Add and select the administrator.

If the administrator you want is not a custom administrator, click Edit and change the administrator's privilege level to

Custom. This allows you to change the administrator's permissions.

6. With the administrator selected, use the check boxes to change specif ic permissions in the Tasks pane.

If the folder contains subfolders, the following options become available:Choose Copy the permissions of this administrator for this folder to its subfolders to copy newly configured permissions

to all folders nested in the selected folder for the custom administrator.

Choose Copy the permissions of all administrators for this folder to its subfolders to copy the newly configured

permissions of each custom administrator who has access to the selected folder to the folders nested within it.

Note: If you change the permissions later in the top level folder, the changes are not automatically copied to the nested

folders. When you make changes to top level folders, use either the Copy the permissions of this administrator for this

folder to its subfolders or the Copy the permissions of all administrators for this folder to its subfolders function to copy

the permissions again.


Publishing Resources for Users

May 16, 2015

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 f ile 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 f iles such as Web pages, documents, media f iles, spreadsheets, and URLs. In XenApp, the combined total of data

types you publish is referred to as content.

The server desktops, so users can access all of the resources available on the server.

Note: Citrix recommends that server desktops be locked down to prevent user access to sensitive areas of the operating

system.

Publish all of these resource types using the Publish Application wizard in the XenApp console. To further refine how your

users launch and access published resources, refer to information about configuring content redirection and XenApp

policies.

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.When you publish an application, configuration information for the application is stored in the data store for the server

farm. The configuration information includes which types of files are associated with the application; users who can

connect to the application; importance level for Preferential Load Balancing; and client-side session properties that include

window size, number of colors, level of encryption, and audio setting.

When delivered to users, published applications appear very similar to applications running locally on the client device.

Users start applications depending on the delivery options you select in the publishing wizard and the plug-in they are

running on their client devices. Consult the appropriate plug-in sections in eDocs or other documentation for more

information about the plug-in with which your users start published applications.

Publishing in Domains with Thousands of Objects

For directory services or domain environments, such as Novell Domain Services for Windows or Microsoft Active DirectoryService, containing over 10,000 objects, Citrix recommends the following:

Use groups to categorize and assign permissions to large numbers of users. An application published to one group of

1,000 users requires XenApp to validate only one object for all 1,000 users. The same application published to 1,000

individual user accounts requires IMA to validate 1,000 objects.

When adding users through the Citrix User Selector, if the Users container holds thousands of objects, add a list of


names.

To configure servers to publish for multiple users

To ensure applications are enabled for multiple users, install the applications using one of the following methods:Install applications as the Built-in Administrator

Select an “install for multiple users” option in the installation wizard for the application, if the Setup for the application

provides this option

Install the application for all users from a command line

To install an application for all users, after enabling Remote Desktop Services, use these steps before installing the

application:

1. Open a command prompt so that you are running it with Administrator privileges; for example, right-click the command

prompt and select Run as Administrator.

2. Run the following command at a command prompt: change user /install

3. From the command prompt, run the Setup executable for the application.

To publish a resource using the Publish Application wizard

Open the XenApp console from any computer that can connect to the farm.

Steps and options in the wizard vary depending on the application type you select. This procedure describes the basic

options.

1. From the XenApp console, under the XenApp node, expand the farm or server to which you want to publish an

application.

Tip: To add a server to the list of servers for a published desktop or application (after publishing the application), drag and

drop the server onto the published desktop or application in the left pane of the console. You can also drag and drop

the published desktop or application onto the server.

2. Select the Applications node and from the Actions pane choose Create folder. Name the folder for the application you

are publishing.

3. Select the folder you created and from the Actions pane choose Publish application.

4. In the Publish Application wizard, on the Name page, provide a display name (maximum 256 characters) and application

description. The name appears on user devices when users access the application and on the console for the farm

applications. XenApp supports application names that use Latin-1 and Unicode character sets, including characters used

in Japanese, Chinese, and Korean.

5. On the Type page, specify the type of resource you want to publish and the delivery method. Three types of resources

can be published (server desktop, content, and application). The next few steps in the wizard differ based on which type

you select. For more details, see— To select a resource type and delivery method

and— To select a streaming delivery method

.

6. On the Location page, add the command-line and working directory (optional) to locate the application.

7. On the Servers page, add the individual servers or worker groups on which the published application runs when accessed

by an ICA connection.

Note: If you add a worker group, make sure that all the servers in the worker group are running the application you are

publishing.

8. On the Users page, create the Configured users list for users or groups who have access to the application. Use the


options to allow access to configured user accounts only or to anonymous users.

9. On the Shortcut presentation page, select the icon for the application and choose how the application is enumerated

on the user device. The console has a limit of 1,000 unique application icons. When that limit is exceeded, the console

displays a generic icon for all new applications.

10. On the Publish immediately page, choose whether or not to make the published application immediately available to

users.

By default, the published application is available when you click Finish.

To prevent users from accessing the application until you manually enable it through application properties, select

Disable application initially.

11. To view and select advanced options, check Configure advanced application settings now. Alternatively, modify the

advanced settings using the application properties.

When you f inish, published resources (unless disabled) are available for users.

Publishing App-V Sequences in XenApp

You can deliver the Microsoft Application Virtualization (App-V) sequences to users by publishing the sequences in XenApp

and delivering the Microsoft Application Virtualization Desktop client through Citrix Merchandising Server and Citrix Receiver

Updater.

To deliver App-V sequences using the Citrix application streaming feature, Citrix provides a conduit utility that supports a

dual mode execution. With dual-mode, users launch applications as they normally do, and the conduit checks for presence

of the App-V client. If the App-V client is installed, the App-V sequence streams to the user device; if not, the application

launches from a XenApp server and streams to the user device.

System requirements:Citrix supports App-V sequences on all operating systems supported by Microsoft App-V.

Citrix Receiver Updater for Windows supports App-V clients 4.5 and 4.6.

User devices must have the Citrix Offline Plug-in 6.x installed locally.

Citrix recommends the following process:Deliver the App-V client to users through Citrix Merchandising Server and Citrix Receiver Updater

Publish App-V sequences for virtualizing on user devices if possible, otherwise virtualizing on XenApp servers

Users can then launch the App-V sequences on their desktops by clicking on the icons delivered through XenApp.

Before you start, locate the following f iles and have them available:Microsoft Application Virtualization Desktop Client installer (setup.exe) from your Microsoft Desktop Optimization Pack

(MDOP) installation media, to upload to the Merchandising Server.

App-V Plug-in – Integration Kit from the Citrix download site.

Save the unzipped contents locally:

Save the App Streaming To AppV Conduit folder on your App Hub (the server where you store your profiles). The

folder contains a pre-created AppStreamingToAppVConduit.profile f ile, as well as the required support f iles for the

profile. This single profile can be used to publish an unlimited number of App-V sequences.

Upload the App-V MetaData f iles and the App-V client's setup.exe f ile to the Merchandising Server to create an App-

V client. Citrix provides these f iles to add the functionality to the client needed for Citrix Receiver Updater. These f iles

include:

AppV_MetaData.xml

AppVReg.msi

AppVReg_MetaData.xml


Save the Streaming Conduit - source code folder locally. These f iles are not needed to publish your applications, but

you can use them to modify the conduit, if needed. This folder contains the source code for the conduit.

To deliver the App-V client with the Citrix Merchandising Server and Citrix ReceiverUpdater

1. In the Merchandising Server Administrator Console, navigate to the Plug-in > Upload page.

2. To upload the App-V_Reg plug-in components:

1. For the Metadata File, click Browse to navigate to the unzipped location of AppVReg_MetaData.xml.

2. For the Plug-in File, click Browse to navigate to the unzipped location of AppVReg.msi.

3. Click Upload.

3. To upload the App-V client components:

1. For the Metadata File, click Browse to where you downloaded App-V_MetaData.xml.

2. For the Plug-in File, click Browse to navigate to the location of the Microsoft Application Virtualization Desktop

Client installer, setup.exe.

3. Click Upload.

4. Configure a delivery to communicate with your App-V server. For additional information on creating and scheduling

deliveries, see the Merchandising Server documentation in the Archive.

An overview of the entire Plug-in upload and delivery process when using Merchandising Server 1.0 can be viewed at

http://www.citrix.com/tv/#videos/773.

If users have the Self-service Plug-in, they can add published App-V sequences as they normally add applications.

To publish App-V sequences for streaming to desktops

The conduit utility AppStreamingToAppVConduit (which is the pre-created Citrix .profile) provides pre-launch and post-exitscripts that enable a dual-mode delivery method. This delivery method uses the App-V client to stream the application tothe user device. If the user device does not support streaming or lacks the App-V client, the conduit triggers the secondarymethod and delivers the application to a XenApp server, which then delivers the application through session virtualizationusing a remote display protocol. The application can be locally installed on the XenApp server, or streamed through Citrixapplication streaming using the App-V client installed on the server.1. In the Citrix AppCenter, open the application publishing wizard and follow the on-screen instructions.

2. Name the application with a name familiar to users, such as "Microsoft PowerPoint 2007."

3. On the Type page, configure the dual-mode delivery method:

Select Application.

For application type, select the dual-mode option: Streamed if possible, otherwise accessed from a server.

For the server application type, select the secondary delivery method, such as Installed application.

4. On the Location page:

Browse to your App-V server where both the conduit utility and App-V sequence are located.

The application to launch is AppStreamingToAppVConduit.

Add the command-line parameters to locate the specif ic App-V sequence on your App-V server.

For Command Line:

Enter the full path to your Microsoft Application Virtualization Client executable, followed by the location of your

App-V sequence, such as:

"C:\\Program Files\Microsoft Application Virtualization Client\sfttray.exe" "\\appv\content\Off2k7\Microsoft Office

http://docs.citrix.com/en-us/archive/archive-finding-docs.html

http://www.citrix.com/tv/#videos/773


PowerPoint 2007 12.0.6425.0000.osd"

5. On the Shortcut presentation page, manually select the icon from your icons directory (no icon by default), such as the

icon for Microsoft PowerPoint.

6. Finish the publishing wizard as you normally do.

For more information about the AppStreamingToAppVConduit utility, see http://support.citrix.com/article/CTX124860 in

the Citrix Knowledge Center.

To launch the App-V sequences

When users log on:Citrix Receiver Updater informs them of Plug-in updates, and if they accept the App-V client, it installs silently in the

background.

If they use the Citrix Self-service Plug-in for the Receiver, they can subscribe to App-V sequences through that Plug-in.

Users launch applications as they normally do, and the conduit checks for presence of the App-V client:If the App-V client is installed, the App-V sequence streams to the user device, where it runs in the App-V isolation

environment.

If the client is not installed (or the device does not support streaming for other reasons), the conduit triggers the Offline

Plug-in to initiate a XenApp server session where the application executes and is presented to the user over a remote

display protocol.

To select a resource type and delivery method

In the Publish Application wizard, select the resource type that you want to deliver and the delivery method. To view thesetting, from the Action menu, select Application properties and then select Type.To change the resource type, from the Action menu, select Other Tasks > Change application type and follow the

instructions in the wizard.

1. Select one of the following resource types:

Server desktop. Publishes the entire Windows desktop of a server in the farm. When the plug-in connects to the

server, the user sees a desktop interface from which any application installed on that server can be started. After

selecting this application type, you must specify the server that you want to publish.

To publish a desktop, you must be running XenApp. If you are running the console on a computer that is not running

XenApp, you cannot publish the local desktop.

Content. Publishes nonexecutable information, such as media, Web pages, or documents. After selecting this

application type, you must specify the URL (Uniform Resource Locator) or UNC (Uniform Naming Convention) path to

the f ile you want to publish. Click Browse to view available content resources on your network.

Application (selected by default). Publishes an application installed on one or more servers in the farm. Note that if

you are running the console on a computer that is not a member of the farm, you cannot publish local applications.

You need to indicate one of the following application types:

Accessed from a server. Grants users access to applications that run on a XenApp server and use shared server

resources. If you choose this option, you must then enter the location of the executable f ile for the application

and the XenApp server on which it will run. Choose this option as the application type unless you intend to stream

your applications.

Streamed if possible, otherwise accessed from a server (also called dual mode streaming). Grants users access to a

profiled application that streams from the f ile share to their user devices and launches locally from within an



isolation environment. Alternatively, for user devices that do not support streamed applications (for example, if the

offline plug-in is not installed), this setting allows the use of an ICA connection to access the application installed

on or streamed from a XenApp server.

Streamed to client. Grants users access to a profiled application that streams from the f ile share to their user

devices and launches locally from within an isolation environment. With this option, the application uses client

resources instead of server resources. Users must have the off line plug-in installed and access the application using

online plug-in or a Web Interface site. If selected, user devices that do not support client-side application

virtualization (such as, they use a non-Windows client) or do not have the off line plug-in installed locally cannot

launch the application.

2. If you selected Accessed from a server or Streamed if possible, otherwise accessed from a server, you also need to select

the Server application type. These are:

Installed application. Enables users to launch an application installed on a XenApp server.

Streamed to server. Grants users access to stream a profiled application from the f ile share to a XenApp server and

launch it from XenApp through an ICA connection.

Note: For more information about client-side application virtualization through streaming, see the information for

application streaming.

To configure locations of published applications

To access this option in the Citrix AppCenter, from the Publish Application wizard, continue to the Location page.

Alternatively, to modify a location, select a published application and under Common Tasks, select Modify application

properties > Modify all properties > Basic > Location.

When you publish an application, specify the command-line and working directory (optional) for the application:

Command-line. The full path of the application's executable f ile. Append the symbols "%*" (percent and star symbols

enclosed in double quotation marks) to the end of the command-line to act as a placeholder for client-supplied

application parameters. When a Plug-in makes a connection request, the server replaces the symbol "%*" in the

command-line with application parameters provided by the Plug-in.

If the path to the application's executable includes directory names with spaces, enclose the command line for the

application in double quotation marks. Include a space between the closing quotation mark and the double quotation

marks around the percent and star symbols. An example of the format to use with a path with spaces and a placeholder

is:

"C:\Program Files\Windows Media Player\mplayer1.exe" "%*" Important: Changing the command-line text removes all f ile type associations from the application. If you change the

command-line text, modify the Content Redirection application property page to select the f ile types you want to

associate with the application for client to server content redirection.

Working directory. By default, this path is the same as the path in the Command line f ield. To run the application from a

different directory, add an absolute path to this f ield.

To configure locations of published content

When you publish content, specify the location using address formats such as the following types (examples shown in

parentheses):

HTML Web site address (http://www.citrix.com)

Document f ile on a Web server (https://www.citrix.com/press/pressrelease.doc)

Directory on an FTP server (ftp://ftp.citrix.com/code)


Document f ile on an FTP server (ftp://ftp.citrix.com/code/Readme.txt)

UNC file path (f ile://myServer/myShare/myFile.asf) or (\\myServer\myShare\myFile.asf)

UNC directory path (f ile://myServer/myShare) or (\\myServer\myShare)

To disable command-line validation

XenApp provides command-line validation for content that is redirected from the client to the server only. By default,

XenApp validates published application command-line parameters passed from the client to the server. When you use the

symbols "%*", XenApp ensures the parameters are valid before the application launches. If the parameters are invalid, the

application launches without passing the parameters. XenApp records all failed validation attempts in the server's system

log and in the security event log.

If your environment includes published applications that use customized client-supplied parameters for purposes other than

content redirection from client to server, these applications might not function correctly when command-line validation is

enabled. To ensure client-supplied parameters are passed from client to server, disable command-line validation for these

published applications.

When using command-line validation, add all servers that store content, such as Word documents or PDF files, to the

Trusted Sites list on the XenApp server. When adding servers to the Trusted Sites list, ensure you are logged on to the

XenApp server as Administrator. If the content servers reside in separate domains, ensure trust relationships are established

between these servers and the XenApp server.

You can disable command-line validation for selected published applications or all published applications on a server.

If your environment includes published applications that use customized client-supplied parameters for purposes other

than content redirection from client to server, these applications might not function correctly when command-line

validation is enabled. To ensure client-supplied parameters are passed from client to server, disable command-line

validation for these published applications.

To disable command-line validation for selected published applications, from the Location page of the application

properties, append the symbols “%**” (percent and two star symbols enclosed in double quotation marks) to the

command-line parameter.


Managing Streamed Applications

May 18 , 2015

After you create profiles for streaming applications using the Streaming Profiler, you make them available to users by

publishing the applications.

The Publish Application wizard in the XenApp console guides you through the process of selecting the streaming options.

Configure the application streaming delivery method as you publish the application. Choose delivery options based on the

users who will access the applications and their environments.

The profiled applications must be stored on a file share or Web server that is accessible from your XenApp server so you can

publish the application, and it must be accessible by your users so they can launch the application.

Streaming Applications to User Devices

If you deliver streamed applications directly to user desktops, users can launch the streamed applications, which run in an

isolation environment on their desktops and use local resources to run the applications. This delivery method offers the full

set of application streaming options including desktop integration and offline access.

Before publishing an application to be streamed to client desktops, complete the following tasks:Install the off line plug-in locally, where it runs in the background to enable application streaming.

Install the latest version of online plug-in locally.

To stream to client devices across a network protected by a f irewall, configure f irewall policies to allow those

applications access.

After all of these tasks are complete, publish the application as Streamed to client.

Streaming Applications to a XenApp Server

To simplify application delivery to servers in a server farm, stream applications to a XenApp server and virtualize the

applications through an ICA connection to user devices.

For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the site to the

Trusted sites list in Internet Explorer on the user devices.

Before publishing an application that is streamed to server, ensure your Web Interface sites and Citrix XenApp sites areconfigured to run one of the following application types:

Remote applications only, or

Dual mode streaming (streamed if possible, otherwise accessed from a server)

For information about managing application types on Web Interface sites, see the Web Interface documentation.

After you ensure all of these tasks are complete, publish the application as Streamed to a server.

Publishing Streamed Applications

To stream applications to user devices, start by reviewing the— System Requirements for Application Streaming

in the Application Streaming product documentation in the Citrix eDocs Archive.

Before publishing an application for streaming, you must use the Citrix Streaming Profiler, a stand-alone utility, to create a


streaming application profile and save the profile on a network file share or Web server (your App Hub). For instructions,

search for— Creating Application Profiles

. In particular, see— To create a profile and target

, as well as other topics in that section.

After creating the application profile, continue by publishing the application to make it available to users. When you publish

an application, you make choices about how to deliver the application and its properties. Use the Publish Application wizard

in the Delivery Services Console, the same wizard you use to publish installed applications. To review the general steps in the

wizard, see Publishing Resources for Users.

In the wizard, select the delivery options to publish the application for streaming. For guidance, search for— To select a streaming delivery method

. Continue by locating the application profile stored in your App Hub and finish the wizard.

In addition, refer to other topics about application properties and preferences and how to configure offline access

(optional).

Finally, to prepare user devices for streaming, search for— Deciding Which Plug-ins to Use for Application Streaming

, as well as other topics about the Citrix Plug-ins.Important: To launch streamed applications, user devices must have suff icient RAM locally.

To select a streaming delivery method

You select the resource type in the XenApp console while running the Publish Application wizard.

Important: For users to stream applications through a Web site using an Internet Explorer or Firefox browser, add the siteto the Trusted sites list in Internet Explorer on the user devices.1. To open the Publish Application wizard, from the XenApp console, under the XenApp node, expand the farm or server to

which you want to publish an application. Select the Applications node, and from the Actions pane, choose Publish

application and follow the instructions in the wizard.

Optionally, to change the delivery method after publishing an application, from the Action menu, select Other Tasks >

Change application type and follow the instructions in the wizard.

2. In the Publish Application wizard, on the Type page, select Application.

3. Select a delivery method from the Application type list:

Accessed from a server. Users launch the application that runs on a XenApp server and uses shared server resources, or

launch it from a Web browser using a Web Interface site you create. If you choose this option, you must then enter

the location of the executable f ile for the application and the XenApp server on which it will run. This is the typical

application type unless you intend to stream your applications to the client desktop. With this method, users access

the applications using the online plug-in or Web plug-in. This method does not support desktop integration or off line

access to applications.

From the Server application type list, select the delivery method:

Installed application. Users launch the application installed on a XenApp server.

Streamed to server. The application in the profile is streamed from the App Hub to the XenApp server, where the

offline plug-in is installed by default. The application displays on the user devices using the online plug-in or Web

plug-in; the off line plug-in is not required on the user device. With this method, users access the applications using

the online plug-in or Web plug-in. This method does not support desktop integration or off line access to

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-pub-pawiz-all.html


applications.

Streamed if possible, otherwise accessed from a server (called dual mode streaming). Grants users access to a profiled

application that streams from the f ile share to their user devices and launches locally from within an isolation

environment. Alternatively, user devices that do not support streamed applications (such as when they do not have

the off line plug-in installed) instead use an ICA connection to access the application installed on or streamed from a

XenApp server.

From the Server application type list, select the alternative delivery method for clients that do not support streaming

to user device:

Installed application. Users launch the application installed on a XenApp server.

Streamed to server. The application in the profile is streamed from the App Hub to the XenApp server, where the

offline plug-in is installed by default. The application displays on the user devices using the online plug-in or Web

plug-in; the off line plug-in is not required on the user device. With this method, users access the applications using

the online plug-in or Web plug-in. This method does not support desktop integration or off line access to

applications.

Streamed to client. With this method, you make available the full set of application streaming features. When you

stream applications directly to client desktops, some of the application f iles are cached locally and the application

runs locally from within an isolation environment using the resources of the user device.

Users must have both the off line plug-in and online plug-in installed locally.

With this delivery method, you can configure the application and users for off line access. When this configuration

is completed, the entire application is fully cached on the user device. Users can disconnect from the network and

continue using the application for the time specif ied in the off line license.

User devices that do not support client-side application virtualization (such as, they use a non-Windows client) or

do not have the off line plug-in installed locally cannot launch the application.

Note: You can also force a delivery method for applications published as "Streamed to client" based on f ilters. To do

this, configure the Load Balancing policy setting (located in the Delivery Services Console) for Streamed App Delivery.

The policy setting overrides the selection in the publishing wizard.

To force a delivery method for streamed applications

Use the Load Balancing Policies to apply settings to sessions that are filtered for Web access, specific users, client devices,

IP addresses, or server. Use the delivery method policy to override the delivery method of applications published as stream to

client.

If you disable the policy setting or do not configure it, the delivery method specified in the Publish Application wizard is used

1. From the Delivery Services Console, select the farm.

2. Under the server, select Load Balancing Policies.

3. From the Actions pane, configure the policy settings for Streamed App Delivery.

4. Select one of the following options:

Allow applications to stream to the client or run on a Terminal Server (default setting).

Force applications to stream to the client. User devices always stream the application from the App Hub to the user

devices. Users must have the off line plug-in installed and access the application using the online plug-in or a Web

Interface site. For example, you might use this setting to prevent the use of server resources. User devices without

the off line plug-in and either the online or Web plug-in cannot launch the application.

Do not allow applications to stream to the client. Users always launch streamed applications from the server. For

example, you might use this option to prevent applications from streaming to specif ic clients. In addition:

If you publish a streaming application with Streamed if possible, otherwise accessed from a server (dual mode


streaming), users always launch the application from the server using the alternative method you selected.

If you publish an application as Streamed to client (without dual mode), the connection fails.

This table describes the default delivery of each application type and the results of setting the policy. The policy setting

overrides the delivery protocol for applications that are published as “streamed to client.”

Application type No policy (default delivery) With policy: Do notallow stream toclient

With policy:Force stream toclient

Streamed to client Citrix off line plug-in streams application todesktop.

Connection fails. Connectionworks.

Accessed f rom a server:— Installed application

Citrix online plug-in virtualizes theapplication installed on XenApp (notstreamed).

Policy does not apply. Policy does notapply.

— Streamed to server Offline plug-in streams application from fileshare to XenApp and any online plug-invirtualizes the application from XenApp.

Policy does not apply. Policy does notapply.

Streamed if possible;otherwise accessedfrom a server (dualmode):— Installed application

Dual mode: Offline plug-in streamsapplication to desktop.Otherwise, the online plug-in connects to

the application installed on server (not

streamed).

Online plug-in alwaysconnects toapplication installedon server.

Offline plug-inalways streamsapplication todesktop.

— Streamed to server Dual mode: Offline plug-in streamsapplication to desktop.Otherwise, offline plug-in streams

application to the server.

Offline plug-in alwaysstreams applicationto the server.

Offline plug-inalways streamsapplication todesktop.

To provide HTTP or HTTPS delivery method

To stream a profile using the HTTP or HTTPS protocol delivery method, use the following example to configure a virtual

directory on the Web server.

These steps assume that you already profiled the application and saved it to a file share using a UNC path.

To stream from an HTTPS address, see the additional steps at the end of this procedure. Note that HTTPS requires

additional certificate setup. For assistance, contact your network administrator.

The Basic authentication scheme for HTTP is not allowed by default. To allow Basic authentication, create the followingregistry key:

For 32-bit systems: HKEY_LOCAL_MACHINE\Software\Citrix\Rade\AllowUnsecuredHttpAuthFor 64-bit systems: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\Rade\AllowUnsecuredHttpAuthType: REG_DWORD

Value: 1


In the following example, the XenApp server, Web server, and file server are located on the same physical server. This is not a

requirement.

To configure the Web server:1. Create a f ile share, if one does not already exist. For example: Web server name: WebServer Physical location on Web

server: c:\webProfiles The share name: webProfiles An administrator must share this folder with the “everyone” group

assigned READ access and the “administrators” group assigned WRITE access at both the share level and NTFS level.

UNC path: \\WebServer\webProfiles

2. On the Web site hosting the profile, add the following MIME type information:

Extension:*

MIME type: application/octet-stream

Set "Execute Permissions" to NONE

You can set this information for the Web site hosting the profiles or for a specific folder in the virtual directory that holds

the profiles.

3. In addition, if the profile includes pre-launch or post-exit scripts, also add the following MIME type information for the

file extension of each script, such as .bat or .com. Extension: <file extension>, and MIME type: application/octet-stream

4. In the directory hosting the profiles:

1. Open Properties and select the Directory tab.

2. In the Configuration area, keep one application f ile extension (it doesn't matter which one you keep) and remove all

the rest of the f ile extensions.

3. Create a placeholder extension for application mapping; for example, ".testcitrix," which should not occur in the

profile.

4. Copy the settings from the f ile extension that remains (Step 4b) to the placeholder extension.

5. Delete the f ile extension that remained in Step 4b, leaving only the placeholder extension from Step 4c.

5. Create a virtual Web site that points to the f ile share using the UNC path. For best results, do not use spaces in the URL.

For example: HTTP (or HTTPS) path of virtual directory: http://WebServer.domain.com/webProfiles

6. Turn on Directory Browsing on the virtual Web site. Now you can test the configuration; continuing the example, browse

to http://WebServer.domain.com/webProfiles/myApplication/myApplication.profile. If the Web server is configured

correctly, the .profile f ile opens looking like an xml f ile (not an error message). For HTTP, you have now completed the

configuration of the Web server.

7. For HTTPS, additional binding configuration of the Web server is required. See the additional steps following this

procedure, based on your operating system.

8. In the Citrix AppCenter, publish the application as Streamed to client, Streamed to server, or Streamed if possible,

otherwise accessed from a server and continue in the wizard.

9. On the Location page, enter the full URL path (starting with HTTP or HTTPS) to the profile (browsing to an HTTP

location is not supported at this time). Use a fully qualif ied domain name, not a relative domain name.

10. Click in the f ield titled Application to launch from the Citrix streaming application profile to select the application.

11. Finish the remaining pages of the wizard. The application is ready to stream to the client device using the HTTP delivery

method.

To stream from an HTTPS address from Windows Server 2008 additional configuration is required on the Web server. An

appropriate Web Server Certificate must be already installed:

1. From IIS, edit the Bindings for the Web Site.

2. In the Site Bindings dialog, click Add.

3. Under Type, choose https.

4. For SSL certif icate, choose the installed Web Server Certif icate.


5. Using the previous example, browse to https://WebServer/webProfiles on the Web server, which must be a member of

the domain and have the root certif icate installed.

To stream from an HTTPS address from Windows Server 2003, install a Web Server Certificate from a domain certificate

authority:

1. From IIS, open Properties for the virtual Web site.

2. Click the Directory Security tab.

3. Under Server Communications, click Server Certif icate.

4. Complete the Web Server Certif icate wizard, and using the previous example, browse to https://WebServer/webProfiles

on the Web server, which must be a member of the domain and have the root certif icate installed.

Configuring Offline Access

Administrators can configure applications that are published to stream to desktops for offline access. This feature allows

users to disconnect from the company network and continue to run their applications in offline mode for a specified length

of time. No additional configuration is needed while profiling the application to create application profiles or targets that

can be accessed offline.

After you configure the offline application policy settings and configure a streamed application for offline access, the next

time the user device connects to XenApp, the offline plug-in downloads the application and caches it on the user device.

Important: Before you configure off line access, refer to— System Requirements for Application Streaming

for the supported platforms and system prerequisites for user devices.Step 1: Configure policy settings for off line access

Step 2: Install the online and off line plug-ins on user devices

Step 3: Publish the application for off line access

You can complete these steps in any order, but users cannot run applications in offline mode until all steps are completed.

Step 1: Configure Policy Settings for Offline Applications

Configure these Citrix policy settings for Offline Applications:Offline app users (required). Create a list of users or groups who have off line access permission and add that list both

when creating the policy for Offline app users and when publishing the application.

Users or groups listed in the offline app users policy setting and who are also configured for the application have

permission to run offline-enabled applications in online and offline mode. Users who are configured for the application,

but who are not added to the policy list can access the application online, but not offline.

Users or groups on this list use an offline license to launch applications regardless of whether they are connected to the

network or disconnected.

Offline app license period (required). Specify the number of days applications can work off line before users have to

renew the license (21 days by default, but can range from 2 to 365 days).

For versions 1.0 through 5.1 of the plug-in, the license for each application in the profile is activated when the user

launches the application the first time, for online or offline use. Beginning with version 5.2 of the plug-in, when the user

launches an application in the profile for the first time, for online or offline use, the offline license is activated for all

other applications in the profile, as well. This occurs at the farm level. Thus, the offline license for all applications in the

profile expires based on the date of the first application launched the first time, regardless of when the other


applications are launched.

To configure licenses, administrators can use the License Management Console or command-line tools. They must also

ensure they have a sufficient number of licenses to support the total number of users with offline access permission.

Users who run XenApp hosted applications can also stream applications to user devices without requiring a separate

license. For general information, in the topics for— Licensing Your Product

, see— Getting Started with Citrix Licensing

.

When users with offline access log on using the online plug-in, they automatically either check out an offline license or

renew a license already checked out. If users stay logged on, licenses are renewed automatically each day. If the license

is near its expiration date while a user is running the application in offline mode, a notice appears reminding the user to

log on (that is, change to online mode). When the user logs on, the offline license is renewed automatically if a license is

available.

If the license expires and no license is available, the user cannot launch the application offline.

Offline app client trust (optional). Use this setting to enable off line application clients that have disconnected to

recreate sessions when reconnecting, without authenticating again.

Offline app event logging (optional). Use this setting to enable logging of off line application events to the event log on

the server.

Step 2: Install the Online and Offline Plug-ins on User Devices

To use the offline access feature, install both the offline and online plug-ins on the user device. The offline plug-in caches

each streamed application on the hard drive of the user device. After the application is cached, the user can disconnect

from the network or server and continue to run the application in offline mode for the period of time specified in the

license.

Step 3: Publish the Application for Offline Access

The offline access feature is available only for applications that you publish as Streamed to client or Streamed if possible,

otherwise accessed from a server.

In addition, when publishing an application for offline access, check the application's documentation and Web site to

determine whether any special configuration is required on the user device to enable offline access of that application. For

example, to stream Microsoft Outlook to the user device for offline access, users must enable the Microsoft Exchange

Setting to "Use Cached Exchange Mode."

Configure the application for off line access while publishing the application or later using the application properties:Enable the application for off line access and select the caching preference.

Create a list of users or groups who have off line access permission and add that list both when creating the policy for

Offline app users and when publishing the application.


Configuring Content Redirection

Aug 03, 2015

The capability to redirect application and content launching from server to client or client to server is referred to as content

redirection.

Content redirection allows you to control whether users access information with applications published on servers or with

applications running locally on client devices.

Note: For your users to access content published with a specif ied universal naming convention (UNC) path and through theWeb Interface, you must publish and configure an application for content redirection so it is associated with the f ile typeof the published content.

To enable content redirection from server to client

When you enable server to client content redirection, embedded URLs are intercepted on the XenApp server and sent to

the client device and the Web browser or multimedia players on the client device open these URLs. This feature frees

servers from processing these types of requests by redirecting application launching for supported URLs from the server to

the local client device. The browser locally installed on the client device is used to navigate to the URL. Users cannot disable

this feature. Accessing published content with local client desktops does not use XenApp resources or licenses because

local viewer applications do not use XenApp sessions to display the published content.

For example, users may frequently access Web and multimedia URLs they encounter when running an email program

published on a server. If you do not enable content redirection from server to client, users open these URLs with Web

browsers or multimedia players present on servers running XenApp.

Note: If the client device fails to connect to a URL, the URL is redirected back to the server.

Complete the following configurations:

1. 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 XenApp console, publish the content f ile and select the users or groups that can access it.

The following URL types are opened locally through user devices for Windows and Linux when this type of contentredirection is enabled:

HTTP (Hypertext Transfer Protocol)

HTTPS (Secure Hypertext Transfer Protocol)

RTSP (Real Player and QuickTime)

RTSPU (Real Player and QuickTime)

PNM (Legacy Real Player)

MMS (Microsoft Media Format)

If content redirection from server to client is not working for some of the HTTPS links, verify that the user device has an

appropriate certificate installed. If the appropriate certificate is not installed, the HTTP ping from the client device to the

URL fails and the URL is redirected back to the server. For legacy plug-ins, content redirection from server to client requires

Internet Explorer Version 5.5 with Service Pack 2 on systems running Windows 98 or higher. For more information on server

to client redirection failure see, http://support.citrix.com/article/CTX133949



To configure content redirection from client to server

Configure content redirection from client to server by associating published applications with file types and then assigning

them to the users you want to be affected. When you configure client to server content redirection, users running the

online plug-in open all files of the associated type with applications published on the server. Content redirection from client

to server is available only for users connecting with the online plug-in.

For example, if you have users who run applications such as email programs locally, use the content redirection capability

with XenApp to redirect application launching from the user device to the server. When users double-click attachments

encountered in an email application running locally, the attachment opens in an application that is published on the server,

associated with the corresponding file type, and assigned to the user.

Complete the following configurations:

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). The option is

located under PNAgent settings > Server Farms > Manage Server Farms > Advanced.

2. In the Delivery Services Console, as you publish the application, associate it with f ile types and select the users or groups

that can connect to it. When users launch the application, the f ile 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 f ile type with a published application, several f ile extensions can be affected. For example,

when you associate the Word document f ile type, f ile 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 specif ic servers, or for

specif ic 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.


Managing Application Properties

Apr 28 , 2015

After publishing applications through the Publish Application wizard, manage the published applications and their properties:Rename, move, disable, and delete published applications

Change, duplicate, import, and export published application settings

Only a Citrix administrator with full access to the Published Applications task can change published applications. Use the

application properties to change settings for a published application, including the location of the published application, the

servers on which the published application is available, and the user accounts allowed to access the published application.

From the Action menu, select Application properties.

Important: The resource type you publish (application, content, or server desktop) determines your path through the PublishApplication wizard; consequently, the properties associated with the resource may vary.

To rename a published application

Use the Name property to change the application name and description that you selected in the Publish Application wizard.Changes take effect after the user reconnects or refreshes the user device. This feature can distinguish among multipleversions of the same application.1. In the left pane of the console, select the published application.

2. From the Action menu, select Application properties and then select Name.

3. The Display name is the name users see on their user device, and it must be unique within the folder. XenApp supports

application names that use Latin-1 and Unicode character sets, including characters used in Japanese, Chinese, and

Korean.

4. The Application name appears in the console and should be unique within a farm (maximum 38 characters). When the

application is published, this name is the same as the display name by default.

5. The Application description appears in Web Interface.

Important: If a duplicate application name is found in the farm, a four-digit hexadecimal number is appended to the originalstring. If the character limit is reached and duplicated, the console replaces the end characters with four-digit hexadecimalnumbers, starting from the right. The application name appears in the left pane of the Properties dialog box for anapplication.

To configure locations of servers for published resources

Choose the server on which the published application or desktop is available through the Servers page of the Publish

Application wizard. To modify the setting, from the Action menu, select Application properties and then select Servers.

Important: For installed applications, select the server where the published application is installed. For streamed-to-serverapplications, select the server to which the profiled application will stream and execute.

The Servers list displays the servers that belong to the farm. Initially, all servers in the farm appear. Use a f ilter to display

only servers running a particular operating system or Citrix version.

Note: If you apply a f ilter (in the Select Servers dialog box), the f ilter settings remain in effect each time the Publish

Application wizard is run until the f ilter is removed or changed.

Use the Import from file option to import an application server list f ile (*.asl). You export the server list of a previously

published application and then import this settings f ile when creating a new published application.

If you modify your servers for a published application, some users may not be in a trusted domain for that server. If you

receive an error message when trying to modify configured servers for a published application, duplicate the application and


then modify the servers and users lists of the new application.

To specify locations of applications for streaming

Before you publish applications for streaming, you must create an application profile using the Citrix Streaming Profiler, a

stand-alone utility, and save the profile to a network file share in your App Hub that is accessible to the Publish Application

wizard.

As you publish the application in the Publish Applications wizard, specify the location of the profile:

1. Citrix streaming application profile address. Provide the location of the manifest f ile (.profile). For example, enter the Full

Universal Naming Convention (UNC) path (such as \\citrixserver\profiles\Adobe Reader\Adobe Reader.profile).

2. Application to launch from the Citrix streaming application profile. After this f ield populates with f iles, choose the

application from the drop-down menu.

3. Extra command-line parameters. (Optional) These parameters are used when the profiled application includes asterisks

(**) as a placeholder for additional parameters. If no asterisks are in the command-line string, the extra parameters are

added at the end of the command-line.

To enable an application for offline access

Before you publish applications for streaming, you must create an application profile using the Citrix Streaming Profiler, a

stand-alone utility, and save the profile to a network file share in your App Hub that is accessible to the Publish Application

wizard.

Configure streamed applications for offline access as you publish them or later in the Application Properties:

As you publish applications in the Publish Applications wizard, click the Enable off line access check box on the Offline

Access page.

In Application Properties, select Basic > Streaming settings > Offline Access. Click the Enable off line access check box to

enable the feature.

T ip: If , later, some operation in the application fails off line due to a missing component, it will fail while connected as well.The solution is to ensure that you package all the necessary components by thoroughly testing the profile.The server fully caches applications enabled for offline access on user devices; the entire application is sent to user devices

while the user is online so that the user can launch the application offline and have full functionality of the application. By

default, applications are cached when a user logs on.

Select when to cache the streamed application:

Pre-cache application at login. Caches the application when the user logs on (selected by default). However, concurrent

logons may slow network traff ic.

Cache application at launch time. Caches the application when users launch it. Use this option if the number of users

logging on at the same time (and pre-caching their applications) could overload the network.

Pre-caching is also possible using third-party tools, such as Microsoft System Management Server (SMS) or Altiris. If you use

a third-party caching method, ignore this setting because it is not used; that is, applications are not cached twice.

To configure user access to applications

Choose the user accounts that can access applications through the Users page of the Publish Application wizard. To modify

user accounts, from the Action menu, select Application properties and then select Users.


Before you publish resources, consider how the configuration of user accounts can affect their access, including

anonymous access and explicit (configured) user account access.

Note: As a best practice, use groups for unique roles to categorize and assign permissions to large numbers of users. Anapplication published to one group of 1,000 users requires the validation of only one object for all 1,000 users. That sameapplication published to 1,000 individual user accounts requires the validation of 1,000 objects.1. Select how to configure user accounts:

Select Allow anonymous users to let all users log on anonymously and start the streamed application without

specifying a user name, domain name, and password (selected by default). This selection disables the remaining

options on the page.

Select Allow only configured users to allow only configured users to start the application. For example, select this

option for all streamed applications.

Selecting this option enables the Select directory type drop-down list, which allows you to configure the users for this

application. You can configure the list later in the application properties.

Note: Streamed applications do not support anonymous users. Additionally, if you enable the streamed application for

off line access, these options are not shown.

2. Use the Select directory type drop-down box to select either Citrix User Selector or Operating System User Selector.

3. Click Add.

If you selected Citrix User Selector, complete the following tasks in the Select Users or Groups dialog box:

Select your account authority from the Look in drop-down list. The drop-down list contains all trusted account

authorities configured on the servers in the farm. These include Novell Domain Services for Windows (NDSfW)

domains, Windows NT domains, Active Directory domains, and local servers. (NDSfW domains appear only if previously

configured.) When you select an account authority, the user accounts that are part of the selected authority appear

in the window below the drop-down list. By default, only user groups appear.

Select Show users to display all user names in the selected domain. This option displays every user in the selected

domain. For NDS, alias objects also appear. The user accounts you select are listed in Configured users.

T ip: Instead of selecting names from the list, type them in a text box. To do this, click Add List of Names and use

semicolons (;) to separate names.

If you selected Operating System User Selector, use the standard Windows dialog box to select your user or group.

Note: This option has several limitations. You can browse only account authorities and select users and groups that are

accessible from the computer running the console. In addition, you might initially select users and groups outside the

trust intersection of the farm, which causes errors later. Other limitations include the inability to add NDS users and

groups.

The list of user accounts is added to the Configured Accounts list. Changes take effect the next time the user launches the

application.

Granting Access to Explicit or Anonymous Users

Before you publish resources, decide how to configure user accounts so that as you publish applications in the wizard, you

can select appropriate user access.

Granting Access to Explicit Users

An explicit user is any user who is not a member of the Anonymous group. Explicit users have user accounts that you create,

configure, and maintain with standard user account management tools.

There are limitations on explicit users who log on to a server farm to run applications: administrators can specify the type of


profile, settings, and other configurations for these users.Important: Do not assign any explicit users to the Anonymous group.

Granting Access to Anonymous Users

During XenApp installation, Setup creates a special user group named Anonymous. By default, anonymous users have guest

permissions. Publishing applications for this special Anonymous user group lets you completely eliminate the need for user

authentication for those applications. When a user starts an application that is configured for anonymous users, the server

does not require an explicit user name and password to log the user on to the server and run the application.

Anonymous users are granted minimal session permissions that include the following restrictions:

Ten-minute idle (no user activity) time-out

Logoff from broken or timed out connections

The user cannot change the password (none is required)

When an anonymous user session ends, no user information is retained. The server does not maintain desktop settings,user-specif ic f iles, or other resources created or configured for the user device.Note: The anonymous user accounts that XenApp creates during installation do not require additional configuration. If youwant to modify their properties, do so with the standard Windows user account management tools.

To configure shortcuts for user devices

Configure or modify the application shortcut presented to user devices on the Shortcut presentation page of theApplication Publishing wizard. To modify the setting, from the Action menu, select Application properties and then selectShortcut presentation.1. To select a new icon for the application, click Change icon and use the options on the window.

2. To organize applications within folders on the user device, under Client application folder, enter a folder name for this

application. When users view their applications, this application is listed in the folder you entered.

3. To specify the placement of the application shortcut, in the Application shortcut placement section, select one or more

of these options:

Add to the client’s Start menu. Creates a shortcut to this application in the user’s local Start menu. A folder appears in

the f irst pane of the Start menu in the location you select:

Place under Programs folder. This option creates a shortcut under the Programs folder of the local Start menu. If a

folder structure is specif ied in the Start Menu Folder text box, the folder structure is created within the local

Programs folder.

Start menu folder. The location of the shortcut within the Start menu (or Programs folder, if selected). For

example, to have the application appear under a folder called “Reports,” enter Reports. For more than one level of

folders, separate each folder name with a backslash; for example, “Reports\HR\survey.” If no folder structure is

specif ied, the application is available from the top level of the Start menu.

Add shortcut to the client’s desktop. Creates a shortcut to this application on the user’s local desktop.

Changes take effect after the user reconnects or refreshes the user device.

To configure access controlled by the Access Gateway

If Access Gateway (Version 4.0 or later) is installed, use the Access Control page of the Publish Application wizard specify

the type of connections that allow the application to appear in the list of published applications on the user device. To

modify the setting, from the Action menu, select Application properties and then select Access control.

For example, if Access Gateway is installed and the application has software requirements, define a filter in Access Gateway

and apply the filter to the published application using XenApp.


Important: To use this feature, set your servers that receive XML requests to trust those requests.Use this page to view or modify connection types:

Allow connections made through Access Gateway Advanced Edition (Version 4.0 or later). This is the default. Select the

type of connections that allow the application to appear in the list of applications:

Any connection. Allows connections made through Access Gateway (Version 4.0 or later), regardless of f ilters. This is

the default.

Any connection that meets any of the following f ilters. Allows connections made through Access Gateway (Version

4.0 or later) that meet one or more of the connection f ilters specif ied in the list.

To Add or Edit a filter, click the respective button and enter the predefined Access Gateway farm name and filter.

Allow all other connections. Allows all connections except those made through Access Gateway (Version 4.0 or later).

This is the default.

Users who do not have the required software running on the user device cannot access the published application.

To associate published applications with file types

As you publish applications, you associate the published item with certain file types present in the Windows registry on the

server. Associate published applications with file types initially from the Publish Application wizard. To modify the file types,

from the Action menu, select Application properties and then select Content redirection.

By associating published applications with f ile types and then assigning the applications to users, you implement thefollowing automatically:

Content redirection from user device to server. Users running a Citrix plug-in open all f iles of an associated type with a

specif ic published application and delivery method. For example, when users double-click an email attachment, the

attachment opens in an application based on the f ile type and delivery method set for those users.

Note: If you do not want specif ic users to launch published applications automatically when opening published content,

do not assign published applications associated with f ile types to those users.

Content publishing. Users connecting through the Web Interface or using the online plug-in open content published on

servers with applications published on servers. For example, you publish a Microsoft Word document. When you also

publish the Microsoft Word application, associate it with a list of f ile types (f iles 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 f ileextension:

Publish a document of the Microsoft Word for Windows f ile type.

Publish the Microsoft Word application and associate it with the Microsoft Word for Windows f ile type. When users

double-click the document from the user device, it opens in the Microsoft Word application published on the server.

Users connecting through the Web Interface or using the online plug-in can open published content with published

applications.

1. Select one or more of the buttons to select the f ile types that you want the application to open when a user opens a

file. Published applications can be associated with one or more f ile types.

2. To list all f ile types associated with the application, click Show all available f ile types for this application. Clear the check

box to display only the selected f ile 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 f ile type with a published application, several f ile extensions can be affected. For example,

when you associate the Word document f ile type, f ile extensions in addition to the .doc extension are associated with

the published application.

To update file type associations

File types are associated with applications in a server’s Windows registry. If you install and then publish applications afterinstalling XenApp, you must update the f ile type associations in the Windows registry on the server. To verify which f iletypes are associated with a published application, from the Action menu, select Application properties and then selectContent redirection.Use Update file types to associate these file types with the application in the server farm’s data store.

Important: Updating the f ile type association data for a farm can take a long time. It depends on the number andavailability of servers, the number of streamed applications, and the availability of the streamed application f ile shares. Ifyou do not have permission to access these f ile shares, an alert appears.Update the file type associations in the data store if :

You installed an application but have not yet published it.

You plan to enable content redirection from user device to server or have users open published content using the

application.

The data store does not already contain the f ile type associations. If you updated the f ile types from the registries of

other servers hosting the application, the data store already contains the associations.

If needed, update f ile types for the farm or for an individual server:In the console, select a farm in the left pane and from the Action menu, select Other Tasks > Update f ile types.

Select a server in the left pane and from the Action menu, select Other Tasks > Update f ile types from registry.

Choose which file types are opened with a published application. When you publish an application, a list of available file

types appears on the Content redirection page. This list is current only if the data store was updated with the file type

associations for the application. Update the data store from the registries of several servers containing an application to

associate a complete set of file types with the application.

If you publish applications to be hosted on more than one server, be sure to update the file types on each server.

To configure alternate profiles

For streamed applications only, use this feature to add an alternate profile for connections that come from specif ic IPaddresses. For example, use an alternate profile to allow one published application for users on either side of a WAN withfile servers on their side. When you create an alternate profile, you create a duplicate of the primary profile that is locatedon a different f ile share, which is more accessible to the user device.Note that if the alternate profile is different from the primary package, the user device may exhibit strange behavior.

To access this dialog box, from the Publish Application wizard, continue to the Alternate profiles page. Alternatively, select a

published application in the left pane and from the Action menu, select Modify application properties > Modify all

properties > Advanced > Alternate profiles.

When you click Add, enter the starting and ending IP range for which the alternate profile applies.

Specify the full path of the alternate profile or browse to locate the profile, such as a UNC: \\citrixserver\profiles\AdobeReader\Adobe reader.profile. After you configure the range, user devices from IP addresses within the specif ied rangeaccess the applications from the alternate profile instead of from the default profile.


To pass parameters to published applications

Use the Location page of the Publish Application wizard to enter the command line and pass parameters to published

applications. To modify the setting, from the Action menu, select Application properties and then select Location.

When you associate a published application with file types, the symbols “%*” (percent and star symbols enclosed in double

quotation marks) are appended to the end of the command line for the application. These symbols act as a placeholder for

parameters passed to user devices.

If a published application does not launch when expected, verify that its command line contains the correct symbols. By

default, XenApp validates parameters supplied by user devices when the symbols “%*” are appended. For published

applications that use customized parameters supplied by the user device, the symbols “%**” are appended to the command

line to bypass command-line validation. If you do not see these symbols in a command line for the application, add them

manually.

If the path to the executable file includes directory names with spaces (such as “C:\Program Files”), you must enclose the

command line for the application in double quotation marks to indicate that the space belongs in the command line. To do

this, follow the instructions below for adding quotation marks around the %* symbols and then add a double quotation

mark at the beginning and the end of the command line. Be sure to include a space between the closing quotation mark for

the command line and the opening quotation mark for the %* symbols.

For example, change the command line for the published application Windows Media Player to the following:

“C:\Program Files\Windows Media Player\mplayer1.exe” “%*”

To reduce user privileges for a streamed application

For applications configured to stream to client devices, only, use this setting to reduce the user privileges for the

application, thus reducing security risks. From the User privileges page of the Publish Application wizard or from the Action

menu, select Modify application properties > Modify all properties > User privileges.

Important: Before you select this option, test the application with a limited access configuration. Some applications expectusers to have elevated privileges and might fail to operate correctly when launched by users with a least-privileged useraccount.Select Run application as a least-privileged user account (not selected by default). This setting configures all users, even

those with an administrator account, to run the application with normal user privileges.

For more information about least-privileged user accounts, search the Microsoft Technet Web site.

To configure application limits and importance

When a user starts a published application, the plug-in establishes a connection to a server in the farm and initiates a

session. If the user then starts another published application without logging off from the first application, the user has

two concurrent connections to the server farm. Use this page to limit the number of concurrent connections that users can

make.

You can configure application limits and importance from the Publish Application wizard Limits page, or from the Action

menu > Modify application properties > Modify all properties > Advanced > Limits.

Under Concurrent instances, select from the following options:Limit instances allowed to run in server farm and then enter the numerical limit in Maximum instances

Allow only one instance of application for each user


If Preferential Load Balancing is available in your XenApp edition, this setting (along with the session importance policy

setting) determines the Resource Allotment associated with the session. The higher the Resource Allotment of the session,

the higher the percentage of CPU cycles allotted to it.

In the Application Importance list box, set the priority that is used with the Session Importance setting to determine the

level of service for the session in the XenApp farm: High, Normal, and Low.

To configure audio and encryption options for published applications

For applications published for an online connection, use the Client options page of the Publish Application wizard to

configure the Citrix plug-in audio and encryption options for when users connect to a published application. To modify the

setting, from the Action menu, select Application properties and then select Client options.

The settings that Citrix plug-ins use to communicate with a published application vary according to the type of plug-in. The

Citrix online plug-in and Web Interface automatically use the settings you specify here to communicate with this published

application.

You can set the encryption level for communications in multiple places in XenApp and your Windows operating system. If a

higher priority encryption level is set elsewhere, the settings that you specify can be overridden. The most secure setting

out of the following settings is used:

The setting in Remote Desktop Server Configuration and/or the setting in Citrix Connection Configuration Tool

(Mfcfg.exe)

The policy setting that applies to the connection

The application setting (that is, the level you are setting in this dialog box)

The Microsoft Group Policy

The encryption settings specified here when publishing an application should be at the same level as the encryption settings

you specified elsewhere. That is, any encryption setting you specify in the Remote Desktop Server Configuration tool or

connection policies cannot be higher than the application publishing setting.

If the encryption level for an application is lower than any settings you specified for Remote Desktop Server Configuration

and connection policies, those settings override the application settings. If the minimum requirements check box is selected

and the plug-in connection does not meet the most restrictive level of encryption, the server rejects the connection when

the plug-in tries to connect to the application. If the minimum requirements check box is selected, the plug-in setting is

always used. However, the plug-in setting must be as secure as the server setting or the connection is denied.

If you select Minimum requirement under the Encryption list box, plug-ins can connect to the published application only if

they are communicating using the specified level of encryption or higher. After you set this encryption level on the server,

any plug-ins connecting with that server must connect at that encryption level or higher.

If a plug-in is running on a 64-bit computer, only basic encryption is supported. In this situation, setting a level of encryption

higher than Basic and selecting the minimum requirements check box prevents plug-ins from connecting.

Select Client audio options:

Enable legacy audio. Select this option to allow audio support for applications to which HDX MediaStream

Multimedia Acceleration does not apply.

Note: By default, audio is disabled on the user device. To allow users to listen to audio in sessions, turn on audio or

give the users permission to turn on audio themselves in the plug-in interface they are using, such as Citrix XenApp.

Minimum requirement. Select this option to allow plug-ins to connect to the published application only if they have


audio support. The Minimum requirement check box under the Client audio list box applies only to the legacy audio

setting. It does not apply to HDX MediaStream Multimedia Acceleration.

In the Connection encryption section, select one or more of the following options:

Select Enable SSL and TLS protocols to request the use of the Secure Sockets Layer (SSL) and Transport Layer

Security (TLS) protocols for plug-ins connecting to the published application.

Select Encryption to apply the RC5 encryption level for the connection.

In the Printing section, select or clear Start this application without waiting for printers to be created. Selecting this

option can allow the plug-in to connect faster. However, if you select this option, the printers may take a few seconds

to be created; do not select this option for applications that print to the printer immediately after being launched.

To configure application appearance

Define how the application appears to the user through the Appearance page of the Publish Application wizard, or from

the Action menu, select Application properties and then select Appearance.

To set the default window size, select the Session window size. Specify window size as a standard resolution, custom

resolution, percentage of the screen, or full screen.

To set the color depth for the application, select the Maximum color quality. The available options are Better

appearance (32-bit), Better speed (16-bit), or 256-color (8-bit).

To hide the application title bar and maximize the application at startup, change the setting in the Application Startup

Settings.

To disable or enable a published application

Take published applications offline temporarily or indefinitely when you are maintaining a published application, such as

applying an upgrade or a service pack to it. While an application is offline, it is not accessible to users. You can disable

multiple applications simultaneously.

You can initially disable an application as you publish it in the publishing wizard or enable or disable it anytime from the

console.

From the Publish Application wizard, continue to the Publish immediately page and select the Disable application initially

check box. When checked, the application is published, but users cannot access it until you enable it.

In the console, select the application in the navigation pane, and from the Action menu, select Enable application or

Disable application.

In the console, select the application in the navigation pane, and to modify the f ile types, from the Action menu, select

Application properties and then select Name. On this page, select Disable application.

Note: If the Disable application initially option is selected and cannot be cleared, either the application requires configuredusers but none are specif ied, or the application is of a type that runs on a server (such as an installed application orstreamed-to-server application) but no servers are specif ied.

To delete a published application

As you publish updated applications on your servers, delete the older or less-frequently used applications. Deleting apublished application does not uninstall the application. It simply removes access to the application through plug-inconnections. You can delete multiple applications simultaneously.1. In the left pane of the console, select the application.

2. On the Action menu, select Delete application.

To move a published application to another folder


Use this option to move a published application to another folder in the console tree or to move servers to another serverfolder. Published applications can be moved only to Applications or folders under Applications. Similarly, servers can bemoved only to Servers or folders under Servers. You can move multiple applications simultaneously.1. In the left pane of the console, select the application.

2. On the Action menu, select Move to folder.

3. Use the Select destination folder dialog box to change the location of the application.

Alternatively, drag applications into a new folder.

To duplicate published application settings

Use the settings of a published application as a template to publish other applications. For example, if you published anapplication with a specif ied user list, you might want to apply the same user list to a new application hosted on the sameset of servers. If so, copy the f irst published application, change the name and location to those of the second application,and thereby publish a different application with the same user and server properties. You can duplicate multiple applicationssimultaneously.1. In the left pane of the console, select the application.

2. From the Action menu, select Duplicate application and a copy of the application appears under the Applications node.

3. Select the duplicated application and change the required properties.

To export published application settings to a file

Exporting published application settings to a file allows you to import these settings files and create new applications at a

later time. First you export the desired settings to a settings file, and then you import this file to create new applications

easily. In particular, import these settings files to overwrite the settings on a previously published application.

This export option offers choices to export a single application, the user list only, or server list only.

A Citrix administrator requires the View permission for the application folder in which the application resides to export

published application settings.

1. In the left pane of the console, select the application whose settings you want to export. To export multiple published

application settings to a f ile simultaneously, in the right pane of the console, press CTRL and select the names of the

applications you want to export.

2. From the Action menu, select Other Tasks > Export application settings to a f ile. Select what to export:

Entire Application. Exports the application and all the settings associated with the published application to an .app f ile.

If you choose this option, you can export settings from multiple applications; select them from the left pane of the

console before selecting the export task.

Important: If application settings are exported as a batch, they must be imported as a batch.

Server List Only. Exports only the list of configured servers for the application to an ASL f ile, including any per-server

command-line overrides, if applicable. Then select an application and import the server list, replacing the existing server

list. Alternatively, import this list of servers when publishing an application by clicking Import from file on the Servers

page of the Publish Application wizard.

Note: This task is available only for applications that have servers associated with them. For this reason, this task is

unavailable for published content or streamed-to-client applications. You can export the server list associated with

one published application only.

3. Settings f iles are saved in XML format. The settings associated with your published application are saved to a settings

file with one of the following extensions: APP, AUL, or ASL. The f ile name is the same as the application by default. For

example, if you choose to export all the application settings of a published application called Notepad123, the default

f ile name for the exported application settings f ile is Notepad123.app.


To import published application settings from a file

After you export published application settings to a file, use them to create a new application or alter the user or server

settings of a previously published application.

Citrix administrators require Published Application permissions for the application folder in which the application resides to

import application settings.

1. In the left pane of the console, select either the folder into which you would like to place a new published application or

the published application whose user or server settings you want to change.

2. From the Action menu, select Other Tasks > Import application settings from a f ile.

3. Use the Open dialog box to locate the settings f ile you want to import.

If you selected a folder in Step 1 of this procedure and an APP f ile 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 f ile in Step 2, click Yes to confirm

that you want to overwrite existing settings. The imported ASL or AUL f ile 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 messageappears identifying the list of users or servers that could not be imported. You either proceed or cancel the import at thatpoint. Cancelling the import cancels the entire import operation. This situation might occur if a server was removed from thefarm after a published application was exported, if a user was removed from the domain, or if the administrator does nothave proper permissions to publish the application on one or more of the servers that were exported.


Making Virtual IP Addresses Available to Applications

Apr 28 , 2015

Some applications, such as CRM and CTI, use an IP address for addressing, licensing, identification, or other purposes and

thus require a unique IP address or a loopback address in sessions. Other applications may bind to a static port, which,

because the port is already in use, causes the failure of multiple attempts to launch an application in a multiuser

environment. For such applications to function correctly in a XenApp environment, a unique IP address is required for each

device.

Use the virtual IP address feature to allow a dynamically-assigned IP address to each session so that configured

applications running within that session appear to have a unique address.

Processes require virtual IP if either:

They use a hard-coded TCP port number, or

They do both of the following:

Use Windows sockets, and

Require a unique IP address or require a specif ied TCP port number

Also, this feature lets you configure applications that depend on communication with localhost (127.0.0.1 by default) to use

a unique virtual loopback address in the localhost range (127.*).

Processes require virtual loopback if either:

They use the Windows socket loopback (localhost) address (127.0.0.1), or

They use a hard-coded TCP port number

If the application requires an IP address for identification purposes only, configure your server to use the client IP address.

How Virtual IP Addressing Works

The Microsoft Remote Desktop (RD) IP Virtualization feature works as follows:

In Microsoft Server Manager, expand Remote Desktop Services > RD Session Host Connections to enable the RD IP

Virtualization feature and configure the settings. For details, refer to Microsoft help and documentation, including the

Microsoft TechNet Web site.

Once the feature is enabled, at session start-up, the server requests dynamically-assigned IP addresses from the

Dynamic Host Configuration Protocol (DHCP) server.

Based on your Virtual IP policy and the settings you configure, the RD IP Virtualization feature assigns IP addresses to

remote desktop connections on a per session or per program basis. If you assign IP addresses for multiple programs,

they share a per-session IP address.

After an address is assigned to a session, it uses the virtual address rather than the primary IP address for the system

whenever the following calls are made:

Bind¸closesocket¸connect, WSAConnect, WSAAccept, getpeername, getsockname, sendto, WSASendTo, WSASocketW, gethostbyaddr, getnameinfo, getaddrinfo

XenApp extends the Windows virtual IP feature by allowing the gethostbyname API to return the virtual IP address. In

addition, XenApp adds virtual loopback to all APIs.

Note: All processes that require the XenApp feature must be added to the programs list for the Virtual IP policy that you

enable. Child processes do not inherit this functionality automatically. Processes can be added with full paths or just the


executable name. For security reasons, Citrix recommends that you use full paths.

Binding Applications

Using the Microsoft IP virtualization feature within the Remote Desktop session hosting configuration, applications are

bound to specific IP addresses by inserting a “filter” component between the application and Winsock function calls. The

application then sees only the IP address it is supposed to use. Any attempt by the application to listen for TCP or UDP

communications is bound to its allocated virtual IP address (or loopback address) automatically, and any originating

connections opened by the application are originated from the IP address bound to the application.

In functions that return an address such as GetHostByName() (controlled by a XenApp policy) and GetAddrInfo()(controlled by a Windows policy), if the local host IP address is requested, virtual IP looks at the returned IP address and

changes it to the virtual IP address of the session. Applications that try to get the IP address of the local server through

such name functions see only the unique virtual IP address assigned to that session. This IP address is often used in

subsequent socket calls (such as bind or connect).

Often an application requests to bind to a port for listening on the address 0.0.0.0. When an application does this and uses

a static port, you cannot launch more than one instance of the application. The virtual IP address feature also looks for

0.0.0.0 in these types of calls and changes the call to listen on the specific virtual IP address. This enables more than one

application to listen on the same port on the same computer because they are all listening on different addresses. Note

this is changed only if it is in an ICA session and the virtual IP address feature is turned on. For example, if two instances of

an application running in different sessions both try to bind to all interfaces (0.0.0.0) and a specific port, such as 9000, they

are bound to VIPAddress1:9000 and VIPAddress2:9000 and there is no conflict.

To determine whether an application needs to use virtual IP addresses

Some applications cannot run in multiple sessions on XenApp. For example, if the application binds to a fixed TCP port on a

specific IP address such as 0.0.0.0 or 127.0.0.1, this prevents multiple instances of the application from running in multiple

sessions because the port is already in use. The virtual IP feature of XenApp can help solve this problem.

To determine whether or not the application needs to use virtual IP addresses:

1. Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specif ic IP addresses and ports.

2. Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.

3. Launch the application and, using TCPView, note which IP addresses and ports are opened by the application and which

process names are opening these ports.

To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1.

To ensure that an application does not open the same IP address on a different port, launch an additional instance of the

application.

To make virtual IP addresses available to applications running in sessions

Enable these Virtual IP policy settings to add additional support to the Windows IP Virtualization feature. Virtual IP

addresses provide published applications with unique IP addresses for use in sessions. This is especially important for

Computer Telephony Integration (CTI) applications that are widely used in call centers. Users can access these applications

on a XenApp server in the same way that they access any other published application. For more information, see— To determine whether an application needs to use virtual IP addresses

.


Before you begin, in Microsoft Server Manager console, enable the Remote Desktop IP Virtualization feature and configure

it to dynamically assign IP addresses using the DHCP server on a per-session or per-program basis.

To extend the IP virtualization feature, configure the following Citrix policy settings for Virtual IP:Virtual IP enhanced compatibility. Use this setting if your application uses the GetHostByName API. When enabled, calls

to GetHostByName within a session return the virtual IP address for the session (disabled by default). The feature

applies only for the applications listed in the virtual IP compatibility programs list.

Virtual IP compatibility programs list. Lists the applications that use the virtual IP enhanced compatibility policy.

Virtual IP adapter address f iltering. Use this setting if your application returns a large number of addresses, which slows

down performance. When enabled, the list of addresses returned by GetAdaptersAddresses includes only the session

virtual IP address and the loopback address, which can improve performance (disabled by default). The feature is enabled

only for the applications listed in the virtual IP f ilter adapter addresses programs list.

Virtual IP f ilter adapter addresses programs list. Lists the applications that use the IP adaptor address f iltering policy.

To make a virtual loopback address available to applications running in sessions

Use the virtual loopback policy for applications that use a loopback address for interprocess communication. Enabling this

virtual IP policy setting allows each session to have its own loopback address for communication. When an application uses

the localhost address (127.0.0.1) in a Winsock call, the virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X,

where X.X.X is a representation of the session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that

the session ID exceeds the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0) to the

maximum of 127.255.255.255.

The virtual loopback feature does not require any additional configuration other than specifying in the programs list which

processes use the feature. Virtual loopback has no dependency on Virtual IP, so no Microsoft server configuration is needed

to enable virtual loopback.

For more information, see— To determine whether an application needs to use virtual IP addresses

.

Configure the following Citrix policy settings for Virtual IP:Virtual IP loopback support. Use this setting to allow each session to have its own virtual loopback address for

communication (disabled by default). The feature is enabled only for the applications listed in the Virtual IP virtual

loopback programs list.

Virtual IP virtual loopback programs list. Lists the applications that use the Virtual IP loopback support policy.

To supply client IP addresses to published applications on a server

Use the Client IP Address feature if an application fails because it requires a unique address strictly for identification or

licensing purposes, and the application does not require a virtual address for communication. This feature hooks only calls

that return a host IP address, such as gethostbyname(). Only use this feature with applications that send the value in this

type of call to the server application for identification or licensing.

If you deploy this feature, consider the IP addresses used by each client device. For example, if two remote users use the

same IP address, a conflict will arise due to the duplicate address.

When these values are configured, configure either the Virtual IP Processes or Virtual Loopback Processes with the same

process names in the Virtual IP compatibility programs list setting or Virtual IP virtual loopback programs list setting for the

policy. This function creates and manages the following registry entry, which is still required for the Client IP feature to


work: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\VIPHook\Processname

On XenApp, 32-bit Edition, this entry is: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\VIPHook\Processname

Note: The virtual IP address feature functions only with applications that load the user32.dll system dynamic link library.For identification purposes, some applications require the IP address be unique for a session. Such IP addresses are not

needed for binding or addressing purposes. In such a case, configure the session to use the IP address of the client device.

1. On the server on which the applications reside, start regedit.

Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating

system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use

Registry Editor at your own risk. Be sure to back up the registry before you edit it.

Using regedit, create the following two registry entries:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VIP\

Name: UseClientIP

Type: REG_DWORD

Data: 1 (enable) or 0 (disable, which is the default)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\VIP\

Name: HookProcessesClientIP

Type: REG_MULTI_SZ

Data: multiple executable names representing application processes that use client IP addresses

Note: On XenApp, 32-bit Edition, these entries are found in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VIP\.

Close regedit and restart your server.

After making the prescribed registry modif ications, add the application process in the programs list for the policy.

Do not configure the use of client IP addresses if :

Plug-ins connect using network protocols other than TCP/IP

Plug-ins reconnect to disconnected sessions from different client devices

Sessions use a pass-through plug-in


Working with Citrix Policies

Apr 07, 2010

To control user access or session environments, configure a Citrix policy. Citrix policies are the most efficient method of

controlling connection, security, and bandwidth settings.

You can create policies for specif ic groups of users, devices, or connection types. Each policy can contain multiple settings.For example, you can configure settings to:

Configure farm settings such as Virtual IP, Health Monitoring and Recovery, and multimedia acceleration

Control sound quality for client devices

Allow users to access the Documents folder on their local client device

Allow or prevent remote users from being able to save to their hard drives from a session

Allow or prevent users from accessing the Windows clipboard

Set a required encryption level for Citrix plug-ins

Set the session importance level, which, along with the application importance level, determines resource allotment for

Preferential Load Balancing

You can work with policies through the Group Policy Editor in Windows or the Delivery Services Console in XenApp. The

console or tool you use to do this depends on whether or not your network environment includes Microsoft Active

Directory and whether or not you have the appropriate permissions to manage Group Policy Objects (GPOs).

Using the Group Policy Editor

If your network environment includes Active Directory and you have the appropriate permissions to manage Group Policy,

use the Group Policy Editor to create policies for your farm. The settings you configure affect the GPOs you specify

through the Group Policy Management console.

Using the Delivery Services Console

If your environment includes a different directory service (such as Novell Directory Services for Windows) or you are a Citrixadministrator without permission to manage Group Policy, use the Delivery Services Console to create policies for yourfarm. The settings you configure are stored in a farm GPO in the data store.Note: In Active Directory environments, the farm GPO takes precedence over the local GPO on the server in the eventpolicy settings conflict. However, Active Directory GPOs take precedence over the farm GPO.

Tips for Working with Policies

If you create more than one policy in your environment, make sure that you prioritize the policies so that it is clear which

policy should take precedence in the event of a conflict.

The process for configuring policies is:

1. Create and name the policy.

2. Configure policy settings.

3. Apply the policy to connections by adding f ilters.

4. Prioritize the policy.

In general, Citrix policies override similar settings configured for the entire server farm, for specific servers, or on the client.

However, the highest encryption setting and the most restrictive shadowing setting always override other settings.


Creating Citrix Policies

Mar 17, 2010

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.

To create a policy

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

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

From the Group Policy Editor, select the Citrix Policies node in the left pane.

2. Click New. The New Policy wizard appears.

3. Enter the policy name and, optionally, a description. Consider naming the policy according to who or what it affects; for

example, Accounting Department or Remote Users.

4. Choose the policy settings you want to configure.

5. Choose the f ilters 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.


Navigating Citrix Policies and Settings

Mar 17, 2010

In Active Directory, policy settings are collected into two main categories: Computer Configuration and User Configuration.

Computer configuration settings pertain to servers, regardless of who logs on. User configuration settings pertain to users

accessing the server, regardless of where they log on.

XenApp policies and settings are collected into similar categories: Computer and User. Computer policy settings pertain to

XenApp servers and are applied when the server is rebooted. User policy settings pertain to user sessions and are applied for

the duration of the session.

Accessing Policies and Settings

In the Delivery Services Console, you can access policies and settings by clicking the Policies node from the console tree and

then selecting either the Computer or User tabs in the middle pane. In the Group Policy Editor, you can access policies and

settings by clicking the Citrix Policies node under Computer Configuration or User Configuration in the tree pane.

The Computer and User tabs each display a list of the policies that have been created. Beneath this list, the following tabsare displayed:

Summary displays the settings and f ilters 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 f ilters for the selected policy

Searching Policies and Settings

From these consoles, you can search the policies you create and their settings and f ilters. All searches f ind items by name asyou type. You can perform searches from the following places:

For searching policies, use the search tool near the list of Citrix policies

For searching settings, use the search tool on the Settings tab

For searching f ilters, use the search tool on the Filters tab

You can refine your search by:On the Settings or Filters tabs, selecting Active Settings or Active Filters, respectively, to search only the settings or

f ilters that have been added to the selected policy.

On the Settings tab, selecting a category such as Auto Client Reconnect or Bandwidth to search only the settings in

that category.

To search the entire catalog of settings or filters, select All Settings or All Filters.


Configuring Policy Settings

Apr 28 , 2015

Policies contain settings that are applied to connections when the policy is enforced. Policy settings can be enabled,

disabled, or not configured. By default, policy settings are not configured, meaning they are not added to a policy. Settings

can be applied only when they are added to a policy.

Some policy settings can be in one of the following states:Allowed or Prohibited allows or prevents the action controlled by the setting.

Enabled or Disabled turns the setting on or off . If you disable a setting, it is not enabled in lower-ranked policies.

For settings that are Allowed or Prohibited, the action controlled by the setting is either allowed or prevented. In some

cases, users are allowed or prevented from managing the setting's action in the session. For example, if the Menu animation

setting is set to Allowed, users can control menu animations in their client environment.

In addition, some settings control the effectiveness of dependent settings. For example, the Client drive redirection setting

controls whether or not users are allowed to access the drives on their devices. To allow users to access their network

drives, both this setting and the Client network drives setting must be added to the policy. If the Client drive redirection

setting is disabled, users cannot access their network drives even if the Client network drives setting is enabled.

In general, Computer policy setting changes go into effect when the server reboots. User policy setting changes go into

effect the next time the relevant users establish a connection. Policy setting changes can also take effect when XenApp

re-evaluates policies at 90 minute intervals.

Default Values of Settings

For some policy settings, you can enter a value or you can choose a value from a list when you add the setting to a policy.

You can limit configuration of the setting by selecting Use default value. Selecting this option disables configuration of the

setting and allows only the setting's default value to be used when the policy is enforced. This occurs regardless of the

value that was entered before selecting Use default value.

For example, for the Lossy compression level setting, the default value is Medium. When you add this setting to a policy and

select Use default value, medium compression is always applied to images when the policy is enforced, even if the setting

was previously configured as High or None.

Default values for all Citrix policy settings are located in the— Policy Settings Reference

.

Best Practices for Policy Settings

Citrix recommends the following when configuring policy settings:Assign policies to groups rather than individual users. If you assign policies to groups, assignments are updated

automatically when you add or remove users from the group.

Do not enable conflicting or overlapping settings in Remote Desktop Session Host Configuration. In some cases,

Remote Desktop Session Host Configuration provides similar functionality to Citrix policy settings. When possible, keep

all settings consistent (enabled or disabled) for ease of troubleshooting.

Disable unused policies. Policies with no settings added create unnecessary processing.

To add settings to a policy


Policy settings can be enabled, disabled, or not configured. By default, policy settings are not configured, meaning they are

not added to a policy. Settings can be applied only when they are added to a policy.

You can add settings to policies using one of the following methods:Using the New Policy wizard, when creating a new policy

Using the Settings tab of the Edit Policy dialog box, when modifying an existing policy

Using the Settings tab of the AppCenter or Group Policy 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 policyimmediately after you configure the selected setting. However, when you modify a policy using the Edit Policy dialog box,changes you make are applied to the policy only after you click OK on the Edit Policy dialog box.1. Select a setting you want to add to the policy and click Add.

The Add Setting dialog box appears, displaying the setting's default value, if applicable. You can accept or change this

value according to your policy requirements. If no default value is present, enter the appropriate value for your

environment.

2. Click OK to add the setting to the policy.

The configured setting appears on the Settings tab of the console in the Active Settings view.


Applying Policies

Apr 28 , 2015

When you add a filter to a policy, the policy's settings are applied to connections according to specific criteria or rules. If no

filter is added, the policy is applied to all connections.

You can add as many f ilters as you want to a policy, based on a combination of criteria. The availability of certain f iltersdepends on whether you are applying a Computer policy or a User policy. The following table lists the available f ilters:

Filter Name Filter Description Policy Scope

AccessControl

Applies a policy based on the access control conditions through which a client isconnecting.

User policiesonly

Client IPAddress

Applies a policy based on the IP address (IPv4 or IPv6) of the user device used toconnect to the session.

User policiesonly

Client Name Applies a policy based on the name of the user device from which the session isconnected.

User policiesonly

User Applies a policy based on the user or group membership of the user connecting tothe session.

User policiesonly

WorkerGroup

Applies a policy based on the worker group membership of the server hosting thesession.

Computer

policies

User policies

When a user logs on, XenApp identifies the policies that match the filters for the connection. XenApp sorts the identified

policies into priority order, compares multiple instances of any policy setting, and applies the policy setting according to the

priority ranking of the policy. XenApp recalculates the policy every 90 minutes after the user logs on to the farm.

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

configured are ignored.

Unfiltered Policies

By default, XenApp provides Unfiltered policies for Computer and User policy settings. The settings added to this policy

apply to all connections.

If you use Active Directory in your environment and use the Group Policy Editor to manage Citrix policies, settings you add

to the Unfiltered policy are applied to all farm servers and connections that are within the scope of the Group Policy

Objects (GPOs) that contain the policy. For example, the Sales OU contains a GPO called Sales-US that includes all members

of the US sales team. The Sales-US GPO is configured with an Unfiltered policy that includes several user policy settings.

When the US Sales manager logs on to the farm, the settings in the Unfiltered policy are automatically applied to the

session because the user is a member of the Sales-US GPO.

If you use the Delivery Services Console to manage Citrix policies, settings you add to the Unfiltered policy are applied to all

servers and connections in the farm.


Filter Modes

A filter's mode determines whether or not the policy is applied only to connections that match all the filter criteria. If the

mode is set to Allow (the default), the policy is applied only to connections that match the filter criteria. If the mode is set

to Deny, the policy is applied if the connection does not match the filter criteria. The following examples illustrate how filter

modes affect Citrix policies when multiple filters are present.

Example: Filters of Like Type with Differing Modes

In policies with two filters of the same type, one set to Allow and one set to Deny, the filter set to Deny takes precedence,

provided the connection satisfies both filters. For example:

Policy 1 includes the following f ilters:Filter A is a User f ilter that specif ies the Sales group and the mode is set to Allow.

Filter B is a User f ilter that specif ies the Sales manager's account and the mode is set to Deny.

Because the mode for Filter B is set to Deny, the policy is not applied when the Sales manager logs on to the farm, even

though the user is a member of the Sales group.

Example: Filters of Differing Type with Like Modes

In policies with two or more filters of differing types, set to Allow, the connection must satisfy at least one filter of each

type in order for the policy to be applied. For example:

Policy 2 includes the following f ilters:Filter C is a User f ilter that specif ies the Sales group and the mode is set to Allow.

Filter D is a Client IP Address f ilter that specif ies 10.8.169.* (the corporate network) and the mode is set to Allow.

When the Sales manager logs on to the farm from the office, the policy is applied because the connection satisfies both

filters.

Policy 3 includes the following f ilters:Filter E is a User f ilter that specif ies the Sales group and the mode is set to Allow.

Filter F is an Access Control f ilter that specif ies Access Gateway connection conditions and the mode is set to Allow.

When the Sales manager logs on to the farm from the office, the policy is not applied because the connection does not

satisfy Filter F.

To apply a policy

You must add at least one f ilter to a policy for that policy to be applied.1. From the policy wizard, select the f ilter you want to apply and click Add.

2. From the New Filter dialog box, click Add to configure f ilter elements.

3. Select the mode for the f ilter.

The policy is applied the next time the relevant users establish a connection.


Using Multiple Policies

Apr 28 , 2015

You can use multiple policies to customize XenApp to meet users’ needs based on their job functions, geographic locations,or connection types. For example, for security reasons you may need to place restrictions on user groups who regularlywork with highly sensitive data. You can create a policy that requires a high level of encryption for sessions and preventsusers from saving sensitive f iles on their local client drives. However, if some people in the user group do need access totheir local drives, you can create another policy for only those users. You then rank or prioritize the two policies to controlwhich one takes precedence.Note: When managing policies through the Delivery Services Console, be aware that making frequent changes canadversely impact server performance. When you modify a policy, the XenApp server synchronizes its copy of the farm GroupPolicy Object (GPO) with the data store, propagating the change to other servers in the farm. For example, if you makechanges to f ive policies, the server synchronizes the farm GPO five times. In a large farm with multiple policies, this frequentsynchronization can result in delayed server responses to user requests. To ensure server performance is not impacted byneeded policy changes, arrange to make these changes during off-peak usage periods.When using multiple policies, you need to determine how to prioritize them, how to create exceptions, and how to view the

effective policy when policies conflict.

In general, policies override similar settings configured for the entire server farm, for specific servers, or on the client. The

exception to this principle is security. The highest encryption setting in your environment, including the operating system

and the most restrictive shadowing setting, always overrides other settings and policies.

Citrix policies interact with policies you set in your operating system. Some Windows policies take precedence over Citrix

policies. For some policy settings, such as Secure ICA, the settings in policies must match the settings in the operating

system. If a higher priority encryption level is set elsewhere, the Secure ICA policy settings that you specify in the policy or

when you are publishing an application can be overridden.

For example, the encryption settings that you specify when you are publishing an application should be at the same level as

the encryption settings you specified throughout your environment.

Prioritizing Policies and Creating Exceptions

Prioritizing policies allows you to define the precedence of policies when they contain conflicting settings. The processXenApp uses to evaluate policies is as follows:1. When a user logs on, all policies that match the f ilters for the connection are identif ied.

2. XenApp sorts the identif ied policies into priority order and compares multiple instances of any setting, applying the

setting according to the priority ranking of the policy.

You prioritize policies by giving them different priority numbers. By default, new policies are given the lowest priority. If policy

settings conflict, a policy with a higher priority (a priority number of 1 is the highest) overrides a policy with a lower priority.

Settings are merged according to priority and the setting's condition; for example, whether the setting is disabled or

enabled. Any disabled setting overrides a lower-ranked setting that is enabled. Policy settings that are not configured are

ignored and do not override the settings of lower-ranked settings.

When you create policies for groups of users, client devices, or servers, you may f ind that some members of the grouprequire 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 f ilter added to the policy

A f ilter with the mode set to Deny tells XenApp to apply the policy to connections that do not match the f ilter criteria. Forexample, a policy contains the following f ilters:

Filter A is a Client IP address f ilter that specif ies the range 208.77.88.* and the mode is set to Allow.

Filter B is a User f ilter that specif ies a particular user account and the mode is set to Deny.

The policy is applied to all users who log on to the farm with IP addresses in the range specified in Filter A. However, the

policy is not applied to the user logging on to the farm with the user account specified in Filter B, even though the user's

computer is assigned an IP address in the range specified in Filter A.

To change the priority of a policy

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.


Determining Which Policies Apply to a Connection

Apr 28 , 2015

Sometimes a connection does not respond as expected because multiple policies apply. If a higher priority policy also

applies to a connection, it can override the settings you configure in the original policy. You can determine how final policy

settings are merged for a connection by calculating the Resultant Set of Policy.

You can calculate the Resultant Set of Policy in the following ways:Use the Citrix Policy Modeling Wizard to simulate a connection scenario and discern how Citrix policies might be applied

Use Group Policy Results to produce a report describing the Citrix policies in effect for a given user and server.

You can launch both tools from the Group Policy Management console in Windows. If your XenApp environment does not

include Active Directory, you can launch the Citrix Group Policy Modeling Wizard from the Actions pane of the Delivery

Services Console.

Using the Citrix Policy Modeling Wizard

With the Citrix Group Policy Modeling Wizard, you can specify conditions for a connection scenario such as domain

controller, users, Citrix policy filter evidence values, and simulated environment settings such as slow network connection.

The report that the wizard produces lists the Citrix policies that would likely take effect in the scenario.

If you are logged on to the server as a domain user and your environment includes Active Directory, the wizard calculates

the resultant set of policy by including settings from Active Directory Group Policy Objects (GPOs). If you run the wizard

from the Delivery Services Console, the farm GPO residing on the server is included in this calculation as well. However, if you

are logged on to the server as a local user and run the wizard from the Delivery Services Console, the wizard calculates the

Resultant Set of Policy using only the farm GPO.

Using Group Policy Results

The Group Policy Results tool helps you evaluate the current state of GPOs in your environment and generates a report

that describes how these objects, including Citrix policies, are currently being applied to a particular user and server.

To simulate connection scenarios with Citrix policies

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

From the Delivery Services Console, click the Policies node in the console tree and then click Run the modeling wizard

from the Actions pane.

From the Group Policy Management console, right-click the Citrix Group Policy Modeling node in the console tree and

then select Citrix Group Policy Modeling Wizard.

2. Follow the wizard to select the domain controller, users, computers, environment settings, and Citrix f ilter criteria you

want to use in the simulation.

When you click Finish, the wizard produces a report of the modeling results. In the Delivery Services Console, the report

appears as a node in the console tree, underneath the Policies node. The Modeling Results tab in the middle pane displays

the report, grouping effective Citrix policy settings under User Configuration and Computer Configuration headings.

Troubleshooting Policies With No Configured Settings

Because settings configured in some policies can conflict with settings configured in others and policies can have multiple

filters, a policy may not behave as expected or it may not run at all. Users, IP addresses, and other filtered objects can have


more than one policy that applies to them simultaneously. In this case, XenApp merges these policies’ settings to

effectively form a new policy resulting from the existing ones. This combination of settings is known as the resultant policy.

When there are multiple policies that can apply to a session, it is the resultant policy that XenApp enforces.

When you run the Citrix Group Policy Modeling Wizard or the Group Policy Results tool, you might create a resultant policythat has no configured settings. When this happens, users connecting to their applications under conditions that matchthe policy evaluation criteria are not affected by any policy rules. This occurs when:

No policies have f ilters that match the policy evaluation criteria

Policies that match the f ilter do not have any settings configured

Policies that match the f ilter are disabled

If you want to apply policy settings to the connections that meet the specif ied 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


Applying Policies to Access Gateway Connections

Mar 12, 2010

You can create a policy that is applied to Access Gateway connections or to Access Gateway connections with certain

properties.

You can create Citrix policies to accommodate different access scenarios based on factors such as authentication

strength, logon point, and client device information such as endpoint analysis. You can selectively enable client-side drive

mapping, cut and paste functionality, and local printing based on the logon point used to access the published application.

Prerequisites for Filtering on Access Gateway Connections

For Citrix XenApp to f ilter on Access Gateway connections, you must complete all of the following:Create one or more f ilters within Access Gateway. See the Access Gateway section of Citrix eDocs for more information

about creating f ilters.

Note: You must be using Access Gateway Advanced Edition (Version 4.0 or later) or Access Gateway Enterprise Edition

(Version 9.1 or later) to create f ilters that work with XenApp.

For published applications, select Allow connections made through Access Gateway Advanced Edition in the application

properties.

Ensure that your farm is configured to allow Access Gateway connections, which it is by default.

Create a Computer policy within XenApp that has the Trust XML requests policy setting enabled.

Create a User policy within XenApp that includes a f ilter referencing Access Gateway f ilters.

To apply a policy filter based on Access Gateway connections

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

From the Delivery Services Console, select the Policies node in the left pane and then select the User tab in the middle

pane.

From the Group Policy Editor, under User Configuration in the left pane, select the Citrix Policies node.

2. Select an existing User policy or create a new User policy.

3. Follow the policy wizard to the f ilters page or click the Filters tab in the middle pane of the console.

4. Select Access Control and then click Add.

5. Click Add to configure the f ilter.

6. Select With Access Gateway.

7. To apply the policy to connections made through Citrix Access Gateway without considering Access Gateway policies,

accept the default entries in the AG farm name and Access condition f ields.

8. To apply the policy to connections made through Citrix Access Gateway based on existing Access Gateway policies,

perform the following actions:

1. In AG farm name, enter one of the following items:

If using Access Gateway Advanced Edition, enter the name of the Access Gateway farm.

If using Access Gateway Enterprise Edition, enter the virtual server name of the Access Gateway appliance.

2. In Access condition, enter one of the following items:

If using Access Gateway Advanced Edition, enter the name of the Access Gateway f ilter for XenApp to use.

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

Important: XenApp does not validate Access Gateway farm, server, and f ilter names, so always verify this information

with the Access Gateway administrator.


9. To apply the policy to every connection except those made through Access Gateway, in the Mode list box, select Deny.

The f ilter's mode tells XenApp whether or not to apply the policy to connections that match the f ilter criteria. Selecting

Deny tells XenApp to apply the policy to connections that do not match the f ilter criteria.


Enabling Scanners and Other TWAIN Devices

Jun 08 , 2010

XenApp lets users control client-attached TWAIN imaging devices, such as scanners and cameras, from published

applications. This feature is known as TWAIN redirection because XenApp provides TWAIN support by redirecting

commands sent from a published application on the server to the client device.

Users can connect regardless of connection type. However, XenApp requires the following for TWAIN support:The imaging device must be connected locally to the user device and have the associated vendor-supplied TWAIN driver

installed locally.

Citrix online plug-in 11.x or later or the Citrix off line plug-in.

XenApp 32-bit and 64-bit servers support TWAIN redirection for 32-bit TWAIN applications only. XenApp does not

support 16-bit TWAIN drivers.

The Client TWAIN device redirection policy setting must be added to the appropriate policy. To configure image

compression, add the TWAIN compression level setting and select the appropriate compression level.

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

Scanners and Scanning Devices Canon CanoScan 3200F

Canon CanoScan 8000F

Canon CanoScan LiDE600F

Fujitsu f i-6140

HP ScanJet 8250

Software Microsoft Office Publisher 2007

Microsoft Office Word 2007 Clip Organizer

OmniPage SE

Consider the following after enabling TWAIN redirection:Configure bandwidth limits for image transfers. You can add the TWAIN device redirection bandwidth limit or the TWAIN

device redirection bandwidth limit percent settings to the policy and enter the appropriate values denoting the maximum

bandwidth allowed for image transfers.

Some applications are not Remote Desktop Session Host aware and look for Twain32.dll in the \Windows directory of

the user profile (by default, C:\Documents and Settings\UserName\Windows). Copying Twain32.dll into the \Windows

directory of each user profile resolves this issue. You can also correct this by adding the application to the Remote

Desktop Session Host application compatibility list with the following two f lags specif ied:


Windows application: 0x00000008

Do not substitute user Windows directory: 0x00000400

This feature supports the following modes of TWAIN information transfer:

Native

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

Note: The disk f ile transfer mode is not supported.


Policy Settings Reference

May 01, 2015

Policies contain settings that are applied when the policy is enforced. You configure these settings using the Delivery

Services Console or the Local Group Policy Editor, depending on whether or not you use Active Directory in your XenApp

environment.

The descriptions for each policy setting include the following information:The name of the policy setting

The Citrix products to which the policy setting applies

The additional settings, if applicable, required to enable a particular feature

Other settings that are similar to the policy setting in question, if applicable

Policy Settings: Quick Reference Table

The following tables present settings you can configure within a policy. Find the task you want to perform in the left

column, then locate its corresponding setting in the right column.

Graphics & Multimedia

Task: Use this policy setting:

Control the amount of memory allocated for displayinggraphics in a session

Display memory limit

Control how a user's display degrades in response to memorylimits and whether or not to notify the user

Display mode degrade preference

Notify user when display mode is degraded

Control compression of images for use in sessions of limitedbandwidth

Lossy compression level

Lossy compression level threshold value

Progressive compression level

Progressive compression threshold value

Control whether or not Flash content is rendered in sessions Flash acceleration

Control whether or not Web sites can display Flash contentwhen accessed in sessions

Flash server-side content fetching whitelist

Flash URL blacklist

Desktop UI


Control whether or not Desktop wallpaper is used in users'sessions

Desktop wallpaper


View window contents while a window is dragged View window contents while draggingDesktop UI

Task: Use this policy setting:User Devices

To limit bandwidth used for: Use this policy setting:

Client audio mapping Audio redirection bandwidth limit, or

Audio redirection bandwidth limit percent

Cut-and-paste using local clipboard Clipboard redirection bandwidth limit, or

Clipboard redirection bandwidth limit percent

Devices connected to a local COM port COM port redirection bandwidth limit, or

COM port redirection bandwidth limit percent

Access in a session to local client drives File redirection bandwidth limit, or

File redirection bandwidth limit percent

Printers connected to the client LPT port LPT port redirection bandwidth limit, or

LPT port redirection bandwidth limit percent

Custom devices connected to the client through OEM virtualchannels

OEM channels bandwidth limit, or

OEM channels bandwidth limit percent

Client session Overall session bandwidth limit

Printing Printer redirection bandwidth limit, or

Printer redirection bandwidth limit percent

TWAIN device (such as a camera or scanner) TWAIN device redirection bandwidth limit, or

TWAIN device redirection bandwidth limit percent

Audio


Control whether or not to allow audio input frommicrophones on the user device

Client microphone redirection

Control audio quality on the user device Audio quality

Control audio mapping to speakers on the user device Client audio redirection


Audio

Task: Use this policy setting:User drives and devices


Control whether or not drives on the user device areconnected when users log on to the server

Auto connect client drives

Control how drives map from the user device Client drive redirection

Improve the speed of writing and copying f iles to a clientdisk over a WAN

Use asynchronous writes

Control whether or not user devices attached to local COMports are available in a session

Client COM port redirection

Control whether or not client printers attached to local LPTports are available in a session

Client LPT port redirection

Control whether or not users' local hard drives are available ina session

Client f ixed drives, and

Client drive redirection

Control whether or not users' local f loppy drives are availablein a session

Client f loppy drives, and


Control whether or not users' network drives are available ina session

Client network drives, and


Control whether or not users' local CD, DVD, or Blu-ray drivesare available in a session

Client optical drives, and


Control whether or not users' local removable drives areavailable in a session

Client removable drives, and


Control whether or not users' TWAIN devices, such asscanners and cameras, are available in a session and controlcompression of image data transfers

Client TWAIN device redirection

TWAIN compression level

Control cut-and-paste data transfer between the server andthe local clipboard

Client clipboard redirection

Control use of custom devices, such as an electronic pen(stylus)

OEM channels


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 backwardcompatibility with prior versions of the server

Client printer names

Control the location where printer properties are stored Printer properties retention

Control whether print requests are processed by the clientor the server

Direct connections to print servers

Control whether or not users can access printers connectedto their user devices


Control installation of native Windows drivers whenautomatically creating client and network printers

Automatic installation of in-box printer drivers

Control when to use the Universal Printer Driver Universal printing

Choose a printer based on a roaming user’s sessioninformation

Default printer

Content redirection


Control whether or not to use content redirection from theserver to the user device

Host to client redirection

Time Zone Control


Control whether or not to use the server’s time zone insteadof the client’s estimated local time zone

Local T ime Estimation

Control whether to use the server’s time zone or the client’stime zone

Use local time of client

User Connections and Shadowing



Limit the number of sessions that a user can run at the sametime

Concurrent logon limit

Control whether or not shadowing is allowed Shadowing

Allow or deny permission for users to shadow connections Users who can shadow other users

Users who cannot shadow other users

User Connections and Shadowing


Single Sign-On


Identify which credential repository to use when using SingleSign-On

Single Sign-On central store

Allow or prevent use of Single Sign-On Single Sign-On

Off line Applications


Allow or prevent off line application users to reconnectwithout reauthentication

Offline app client trust

Allow or deny permission for users to access off lineapplications

Offline app users

Security

Task: Use this policy rule:

Require that connections use a specif ied encryption level SecureICA minimum encryption level


ICA Policy Settings

May 03, 2015

The ICA section contains policy settings related to ICA listener connections, mapping to the Clipboard and custom

channels, connecting to server desktops, and controlling the launch behavior of non-published programs.

ICA listener connection timeout

This setting specifies the maximum wait time for a connection using the ICA protocol to be completed. By default, the

maximum wait time is 120000 milliseconds, or two minutes.

ICA listener port number

This setting specifies the TCP/IP port number used by the ICA protocol on the server.

The default port number is 1494. The port number must be in the range of 0– 65535 and must not conflict with other well-

known port numbers.

If you change the port number, restart the server for the new value to take effect. If you change the port number on the

server, you must also change it on every plug-in that connects to the server.

Client clipboard redirection

This setting allows or prevents the Clipboard on the user device to be mapped to the Clipboard on the server. By default,

clipboard redirection is allowed.

To prevent cut-and-paste data transfer between a session and the local Clipboard, select 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.

Related Policy Settings

Clipboard redirection bandwidth limit


Desktop launches

This setting allows or prevents non-administrative users to connect to a desktop session on the server.

When allowed, non-administrative users can connect. By default, non-administrative users cannot connect to desktop

sessions.

Launching of non-published programs during client connection

This setting specifies whether or not to launch initial applications or published applications through ICA or RDP on the

server. By default, only published applications are allowed to launch.

OEM Channels

This setting allows or prevent custom (OEM) devices attached to ports on the user device to be mapped to ports on the

server. By default, mapping of custom devices is allowed.


After allowing this setting, configure the maximum amount of bandwidth the OEM’s virtual channel can consume in a client

connection using the OEM channels bandwidth limit or the OEM channels bandwidth limit percent settings.


OEM channels bandwidth limit


Audio Policy Settings

The Audio section contains policy settings you can configure to permit user devices to send and receive audio in sessions

without reducing performance.

Audio Quality

Use the projected figures for each level of sound quality to calculate the bandwidth potentially consumed in connections

to specific servers. For example, if 25 users record at Medium on one server, the bandwidth used in the connections to that

server is over 52,500 bytes per second.

Bandwidth is consumed only while audio is recording or playing. If both occur at the same time, the bandwidth consumption

is doubled.

To control sound quality, choose one of the following options:Select Low - for low speed connections for low-bandwidth connections. Sounds sent to the client are compressed up to

16 Kbps. This compression results in a signif icant decrease in the quality of the sound but allows reasonable performance

for a low-bandwidth connection. With both audio playback and recording total bandwidth consumption is 22 Kbps at

maximum.

Select Medium - optimized for speech for most LAN-based connections. Sounds sent to the client are compressed up to

64 Kbps. With both audio playback and recording total bandwidth consumption is 33.6 Kbps at maximum.

Select High - high definition audio for connections where bandwidth is plentiful and sound quality is important. Clients

can play sound at its native rate. Sounds can use up to 1.3 Mbps of bandwidth to play clearly. Transmitting this amount

of data can result in increased CPU utilization and network congestion.


Audio redirection bandwidth limit


Client audio redirection

This setting allows or prevents applications hosted on the server to play sounds through a sound device installed on the

user device. This setting also allows or prevents users from recording audio input.

After allowing this setting, you can limit the bandwidth consumed by playing or recording audio. Limiting the amount of

bandwidth consumed by audio can improve application performance but may also degrade audio quality. Bandwidth is

consumed only while audio is recording or playing. If both occur at the same time, the bandwidth consumption doubles.

To specify the maximum amount of bandwidth, configure the Audio redirection bandwidth limit or the Audio redirection

bandwidth limit percent settings.







This setting enables or disables client microphone redirection. When enabled, users can use microphones to record audio

input in a session.

For security, users are alerted when servers that are not trusted by their devices try to access microphones. Users can

choose to accept or not accept access. Users can disable the alert on the Citrix online plug-in.

If the Client audio redirection setting is disabled on the user device, this rule has no effect.





Auto Client Reconnect Policy Settings

The Auto Client Reconnect section contains policy settings for controlling automatic reconnection of sessions.

Auto client reconnect

This setting allows or prevents automatic reconnection by the same client after a connection has been interrupted. By

default, automatic reconnection is allowed.

Allowing automatic reconnection allows users to resume working where they were interrupted when a connection was

broken. Automatic reconnection detects broken connections and then reconnects the users to their sessions.

However, automatic reconnection can result in a new session being launched (instead of reconnecting to an existing

session) if a plug-in’s cookie, containing the key to the session ID and credentials, is not used. The cookie is not used if it

has expired, for example, because of a delay in reconnection, or if credentials must be reentered. Auto client reconnect is

not triggered if users intentionally disconnect.

Auto client reconnect authentication

This setting requires authentication for automatic client reconnections. By default, authentication is not required.

When a user initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory and creates a

cookie containing the encryption key which is sent to the plug-in. When this setting is added, cookies are not used. Instead,

XenApp displays a dialog box to users requesting credentials when the plug-in attempts to reconnect automatically.

Auto client reconnect logging

This setting enables or disables recording of auto client reconnections in the event log. By default, logging is disabled.

When logging is enabled, the server’s System log captures information about successful and failed automatic reconnection

events. The server farm does not provide a combined log of reconnection events for all servers.

Bandwidth Policy Settings


The Bandwidth section contains policy settings you can configure to avoid performance problems related to client session

bandwidth use.


This setting specifies the maximum allowed bandwidth in kilobits per second for playing or recording audio in a user session.

If you enter a value for this setting and a value for the Audio redirection bandwidth limit percent setting, the most

restrictive setting (with the lower value) is applied.


This setting specifies the maximum allowed bandwidth limit for playing or recording audio as a percent of the total session

bandwidth. If you enter a value for this setting and a value for the Audio redirection bandwidth limit setting, the most


If you configure this setting, you must also configure the Overall session bandwidth limit setting which specifies the total

amount of bandwidth available for client sessions.

Clipboard redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for data transfer between a session and the

local Clipboard. 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.


This setting specifies the maximum allowed bandwidth for data transfer between a session and the local Clipboard as a

percent of the total session bandwidth. If you enter a value for this setting and a value for the Clipboard redirection

bandwidth limit setting, the most restrictive setting (with the lower value) is applied.



COM port redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a COM port in a client

connection. If you enter a value for this setting and a value for the COM port redirection bandwidth limit percent setting,

the most restrictive setting (with the lower value) is applied.

COM port redirection bandwidth limit percent

This setting specifies the maximum allowed bandwidth for accessing COM ports in a client connection as a percent of the

total session bandwidth. If you enter a value for this setting and a value for the COM port redirection bandwidth limit

setting, the most restrictive setting (with the lower value) is applied.



File redirection bandwidth limit


This setting specifies the maximum allowed bandwidth in kilobits per second for accessing a client drive in a user session. If

you enter a value for this setting and a value for the File redirection bandwidth limit percent setting, the most restrictive

setting (with the lower value) takes effect.

File redirection bandwidth limit percent

This setting specifies the maximum allowed bandwidth limit for accessing client drives as a percent of the total session

bandwidth. If you enter a value for this setting and a value for the File redirection bandwidth limit setting, the most




LPT port redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for print jobs using an LPT port in a single user

session. If you enter a value for this setting and a value for the LPT port redirection bandwidth limit percent setting, the

most restrictive setting (with the lower value) is applied.

LPT port redirection bandwidth limit percent

This setting specifies the bandwidth limit for print jobs using an LPT port in a single client session as a percent of the total

session bandwidth. 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.



OEM channels bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for custom (OEM) virtual channels. If you enter

a value for this setting and a value for the OEM channels bandwidth limit percent setting, the most restrictive setting (with

the lower value) is applied.


This setting specifies the maximum allowed bandwidth for custom (OEM) virtual channels as a percent of the total session

bandwidth. If you enter a value for this setting and a value for the OEM channels bandwidth limit setting, the most




Overall session bandwidth limit

This setting specifies the total amount of bandwidth available in kilobits per second for user sessions. Limiting the amount

of bandwidth consumed by a client connection can improve performance when other applications outside the client

connection are competing for limited bandwidth.


Printer redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for accessing client printers in a user session. If

you enter a value for this setting and a value for the Printer redirection bandwidth limit percent setting, the most restrictive

setting (with the lower value) is applied.

Printer redirection bandwidth limit percent

This setting specifies the maximum allowed bandwidth for accessing client printers as a percent of the total session

bandwidth. If you enter a value for this setting and a value for the Printer redirection bandwidth limit setting, the most




TWAIN device redirection bandwidth limit

This setting specifies the maximum allowed bandwidth in kilobits per second for controlling TWAIN imaging devices from

published applications. If you enter a value for this setting and a value for the TWAIN device redirection bandwidth limit

percent setting, the most restrictive setting (with the lower value) is applied.


This setting specifies the maximum allowed bandwidth for controlling TWAIN imaging devices from published applications as

a percent of the total session bandwidth. If you enter a value for this setting and a value for the TWAIN device redirection

bandwidth limit setting, the most restrictive setting (with the lower value) is applied.



Desktop UI Policy Settings

The Desktop UI section contains policy settings that control visual effects, such as desktop wallpaper, menu animations,

and drag-and-drop images, to manage the bandwidth used in client connections. You can improve application performance

on a WAN by limiting bandwidth usage.

Desktop wallpaper

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

Menu animation is a Microsoft personal preference setting that causes a menu to appear after a short delay, either by

scrolling or fading in. When this policy setting is set to Allowed, an arrow icon appears at the bottom of the menu. The

menu appears when you mouse over that arrow.

By default, menu animation is allowed.

View window contents while dragging


This policy setting controls the display of window contents when dragging a window across the screen.

When set to 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. By default, viewing window contents is allowed.

End User Monitoring Policy Settings

The End User Monitoring section contains policy settings for measuring session traffic.

ICA round trip calculation

This setting determines whether or not ICA round trip calculations are performed for active connections. By default,

calculations for active connections are enabled.

By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates user interaction.

This delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for

ICA traffic.

ICA round trip calculation interval (Seconds)

This setting specifies the frequency, in seconds, at which ICA round trip calculations are performed. By default, ICA round

trip is calculated every 15 seconds.

ICA round trip calculations for idle connections

This setting determines whether or not ICA round trip calculations are performed for idle connections. By default,

calculations are not performed for idle connections.

By default, each ICA roundtrip measurement initiation is delayed until some traffic occurs that indicates user interaction.

This delay can be indefinite in length and is designed to prevent the ICA roundtrip measurement being the sole reason for

ICA traffic.

File Redirection Policy Settings

The File Redirection section contains policy settings relating to client drive mapping and client drive optimization.


This setting allows or prevents automatic connection of client drives when users log on. By default, automatic connection

is allowed. When allowing this setting, make sure to enable the settings for the drive types you want automatically

connected. For example, to allow automatic connection of users' CD-ROM drives, configure this setting and the Client

optical drives setting.



Client f loppy drives

Client optical drives

Client f ixed drives

Client network drives

Client removable drives



This setting enables or disables drive redirection to and from the user device. When enabled, users can save files to all their

client drives. When disabled, all file redirection is prevented, regardless of the state of the individual file redirection settings

such as Client floppy drives and Client network drives. By default, file redirection is enabled.


Client f loppy drives





Client fixed drives

This setting allows or prevents users from accessing or saving files to fixed drives on the user device. By default, accessing

client fixed drives is allowed.

When allowing this setting, make sure the Client drive redirection setting is present and set to Allowed. If these settings are

disabled, client fixed drives are not mapped and users cannot access these drives manually, regardless of the state of the

Client fixed drives setting.

To ensure fixed drives are automatically connected when users log on, configure the Auto connect client drives setting.




Client floppy drives

This setting allows or prevents users from accessing or saving files to floppy drives on the user device. By default, accessing

client floppy drives is allowed.


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.





This setting allows or prevents users from accessing and saving files to network (remote) drives through the user device. By

default, accessing client network drives is allowed.


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.





This setting allows or prevents users from accessing or saving files to CD-ROM, DVD-ROM, and BD-ROM drives on the user

device. By default, accessing client optical drives is allowed.


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.





This setting allows or prevents users from accessing or saving files to USB drives on the user device. By default, accessing

client removable drives is allowed.


disabled, client removable drives are not mapped and users cannot access these drives manually, regardless of the state of

the Client removable drives setting.

To ensure removable drives are automatically connected when users log on, configure the Auto connect client drives

setting.




Host to client redirection

This setting enables or disables file type associations for URLs and some media content to be opened on the user device.

When disabled, content opens on the server. By default, file type association is disabled.

These URL types are opened locally when you enable this setting:Hypertext Transfer Protocol (HTTP)

Secure Hypertext Transfer Protocol (HTTPS)

Real Player and QuickTime (RTSP)

Real Player and QuickTime (RTSPU)

Legacy Real Player (PNM)


Microsoft’s Media Format (MMS)

Special folder redirection

This setting allows or prevents Citrix online plug-in and Web Interface users to see their local Documents and Desktop

special folders from a session. By default, special folder redirection is allowed.

This setting prevents any objects filtered through a policy from having special folder redirection, regardless of settings that

exist elsewhere. When you allow this setting, any related settings specified for the Web Interface or Citrix online plug-in are

ignored.

To define which users can have special folder redirection, select Allowed and include this setting in a policy filtered on the

users you want to have this feature. This setting overrides all other special folder redirection settings throughout XenApp.

Because special folder redirection must interact with the user device, policy settings that prevent users from accessing or

saving files to their local hard drives also prevent special folder redirection from working. If you enable the Special folder

redirection setting, make sure the Client fixed drives setting is enabled as well.

For seamless applications and seamless and published desktops, special folder redirection works for Documents and

Desktops folders. Citrix does not recommend using special folder redirection with published Windows Explorer.




Use asynchronous writes

This setting enables or disables asynchronous disk writes. By default, asynchronous writes are disabled.

Asynchronous disk writes can improve the speed of file transfers and writing to client disks over WANs, which are typically

characterized by relatively high bandwidth and high latency. However, if there is a connection or disk fault, the client file or

files being written may end in an undefined state. If this happens, a pop-up window informs the user of the files affected.

The user can then take remedial action, such as restarting an interrupted file transfer on reconnection or when the disk

fault is corrected.

Citrix recommends enabling asynchronous disk writes only for users who need remote connectivity with good file access

speed and who can easily recover files or data lost in the event of connection or disk failure. When enabling this setting,

make sure that the Client drive redirection setting is present and set to Allowed. If this setting is disabled, asynchronous

writes will not occur.



Graphics Policy Settings

The Graphics section contains policy settings for controlling how images are handled in user sessions.

Display memory limit

This setting specifies the maximum video buffer size in kilobytes for the session. By default, the display memory limit is

32768 kilobytes.


Specify an amount in kilobytes from 128 to 65536. Using more color depth and higher resolution for connections requires

more memory. If the memory limit is reached, the display degrades according to the Display mode degrade preference

setting.

Display mode degrade preference

This setting specifies that color depth or resolution degrades first when the session display memory limit is reached.

When the session memory limit is reached, you can reduce the quality of displayed images by choosing whether color depth

or resolution is degraded first. When color depth is degraded first, displayed images use fewer colors. When resolution is

degraded first, displayed images use fewer pixels per inch. By default, color depth is degraded first.

To notify users when either color depth or resolution are degraded, configure the Notify user when display mode is

degraded setting.

Image caching

This setting enables or disables caching of images in sessions. When needed, the images are retrieved in sections to make

scrolling smoother. By default, image caching is enabled.

Maximum allowed color depth

This setting specifies the maximum color depth allowed for a session. By default, the maximum allowed color depth is 32

bits per pixel.

Setting a high color depth requires more memory. To degrade color depth when the memory limit is reached, configure the

Display mode degrade preference setting. When color depth is degraded, displayed images use fewer colors.

Notify user when display mode is degraded

This setting displays a brief explanation to the user when the color depth or resolution is degraded. By default, notifying

users is disabled.

Queuing and tossing

This setting discards queued images that are replaced by another image. This improves response when graphics are sent to

the client. Configuring this setting can cause animations to become choppy due to dropped frames. By default, queuing and

tossing is enabled.

Image Compression Policy Settings

The Image compression section contains settings that enable you to remove or alter compression. When client

connections are limited in bandwidth, downloading images without compression can be slow.


This setting controls the degree of lossy compression used on images delivered over client connections that are limited in

bandwidth. In such cases, displaying images without compression can be slow. By default, medium compression is selected.

For improved responsiveness with bandwidth-intensive images, use high compression. Where preserving image data is vital;

for example, when displaying X-ray images where no loss of quality is acceptable, you may not want to use lossy


compression.


Lossy compression threshold value


Progressive heavyweight compression level

Lossy compression threshold value

This setting represents the maximum bandwidth in kilobits per second for a connection to which lossy compression is

applied. By default, the threshold value is 2000 kilobits per second.

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




This setting provides a less detailed but faster initial display of images. The more detailed image, defined by the normal lossy

compression setting, appears when it becomes available. Use very high or ultra high compression for improved viewing of

bandwidth-intensive graphics such as photographs.

For progressive compression to be effective, its compression level must be higher than the Lossy compression level setting;by default, progressive compression is not applied.Note: The increased level of compression associated with progressive compression also enhances the interactivity ofdynamic images over client connections. The quality of a dynamic image, such as a rotating three-dimensional model, istemporarily decreased until the image stops moving, at which time the normal lossy compression setting is applied.Related Policy Settings



Progressive heavyweight compression


The maximum bandwidth in kilobits per second for a connection to which progressive compression is applied. This is applied

only to client connections under this bandwidth. By default, the threshold value is 1440 kilobits per second.



Progressive heavyweight compression

This setting enables or disables reducing bandwidth beyond progressive compression without losing image quality by using a

more advanced, but more CPU-intensive, graphical algorithm. By default, progressive heavyweight compression is disabled.

If enabled, heavyweight compression applies to all lossy compression settings. It is supported on the Citrix online plug-in but

has no effect on other plugins.





Keep Alive Policy Settings

The Keep Alive section contains policy settings for managing ICA keep-alive messages.

ICA keep alive timeout

This setting specifies the number of seconds between successive ICA keep-alive messages. By default, the interval between

keep-alive messages is 60 seconds.

Specify an interval between 1-3600 seconds in which to send ICA keep-alive messages. Do not configure this setting if your

network monitoring software is responsible for closing inactive connections. If using Citrix Access Gateway, set keep-alive

intervals on the Access Gateway to match the keep-alive intervals on XenApp.

ICA keep alives

This setting enables or disables sending ICA keep-alive messages periodically. By default, keep-alive messages are not sent.

Enabling this setting prevents broken connections from being disconnected. If XenApp detects no activity, this setting

prevents Remote Desktop Services from disconnecting the session. XenApp sends keep-alive messages every few seconds

to detect if the session is active. If the session is no longer active, XenApp marks the session as disconnected.

ICA Keep-Alive does not work if you are using Session Reliability. Configure ICA Keep-Alive only for connections that are not

using Session Reliability.


Session reliability connections

Multimedia Policy Settings

The Multimedia section contains policy settings for managing streaming audio and video in user sessions.

HDX MediaStream Multimedia Acceleration

This setting controls and optimizes the way XenApp servers deliver streaming audio and video to users. By default, this

setting is allowed.

Allowing this setting increases the quality of audio and video rendered from the server to a level that compares with audio

and video played locally on a client device. XenApp streams multimedia to the client in the original, compressed form and

allows the client device to decompress and render the media.

HDX MediaStream multimedia acceleration optimizes multimedia files that are encoded with codecs that adhere to

Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation standards. To play back a given multimedia

file, a codec compatible with the encoding format of the multimedia file must be present on the client device.

By default, audio is disabled on the Citrix online plug-in. To allow users to run multimedia applications in ICA sessions, turn on

audio or give the users permission to turn on audio themselves in their plug-in interface.

Select Prohibited only if playing media using multimedia acceleration appears worse than when rendered using basic ICA

compression and regular audio. This is rare but can happen under low bandwidth conditions; for example, with media in

which there is a very low frequency of key frames.


HDX MediaStream Multimedia Acceleration default buffer size

This setting specifies a buffer size from 1 to 10 seconds for multimedia acceleration. By default, the buffer size is 5 seconds.

HDX MediaStream Multimedia Acceleration default buffer size use

This setting enables or disables using the buffer size specified in the HDX MediaStream Multimedia Acceleration default

buffer size setting. By default, the buffer size specified is used.

Multimedia conferencing

This setting allows or prevents support for video conferencing applications. By default, video conferencing support is

enabled.

When adding this setting to a policy, make sure the HDX Mediastream Multimedia Acceleration setting is present and set

to Allowed.

When using multimedia conferencing, make sure the following conditions are met:Manufacturer-supplied drivers for the web cam used for multimedia conferencing must be installed.

The web cam must be connected to the client device before initiating a video conferencing session. XenApp uses only

one installed web cam at any given time. If multiple web cams are installed on the client device, XenApp attempts to use

each web cam in succession until a video conferencing session is created successfully.

An Office Communicator server must be present in your farm environment.

The Office Communicator client software must be published on the server.

HDX MediaStream for Flash (client side) Policy Settings

The HDX MediaStream for Flash (client side) section contains policy settings for handling Flash content in user sessions.

Flash acceleration

This setting enables or disables Flash content rendering on user devices instead of the server. By default, client-side Flash

content rendering is enabled.

When enabled, this setting reduces network and server load by rendering Flash content on the user device. Additionally, the

Flash URL blacklist setting forces Flash content from specific Web sites to be rendered on the server.

When this setting is disabled, Flash content from all Web sites, regardless of URL, is rendered on the server. To allow only

certain Web sites to render Flash content on the user device, configure the Flash server-side content fetching whitelist

setting.

Flash event logging

This setting allows or prevents Flash events to be recorded in the Windows application event log. By default, logging is

allowed.

Flash latency threshold

This setting specifies a threshold between 0-30 milliseconds to determine where Adobe Flash content is rendered. By

default, the threshold is 30 milliseconds.


During startup, HDX MediaStream for Flash measures the current latency between the server and user device. If the

latency is under the threshold, HDX MediaStream for Flash is used to render Flash content on the user device. If the

latency is above the threshold, the network server renders the content if an Adobe Flash player is available there.


This setting specifies Web sites whose Flash content is allowed to be downloaded to the server and then transferred to

the user device for rendering. Flash content on unlisted Web sites is downloaded directly to the client.

When adding this setting to a policy, make sure the Flash acceleration setting is present and set to Enabled. Otherwise,

Web sites listed in the whitelist are ignored.

Listed URL strings do not need the http:// or https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid at

the beginning and end of a URL.

Flash URL blacklist

This setting specifies Web sites whose Flash content is rendered on the server. Flash content on unlisted Web sites is

rendered on the user device.

When adding this setting to a policy, make sure the Flash acceleration setting is present and set to Enabled. Otherwise,

Web sites listed in the URL blacklist are ignored.

Listed URL strings do not need the http:// or https:// prefix. These prefixes are ignored if found. Wildcards (*) are valid at

the beginning and end of a URL.

HDX Multimedia for Flash (server side) Policy Settings

The HDX Multimedia for Flash (server side) section contains policy settings for handling Flash content on session hosts.

Flash quality adjustment

This setting adjusts the quality of Flash content rendered on session hosts to improve performance. By default, Flash

content is optimized for low bandwidth connections only.

Ports Policy Settings

The Ports section contains policy settings for client LPT and COM port mapping.

Auto connect client COM ports

This setting enables or disables automatic connection of COM ports on user devices when users log on to the farm. By

default, client COM ports are not automatically connected.



Auto connect client LPT ports

This setting enables or disables automatic connection of LPT ports on user devices when users log on to the farm. By

default, client LPT ports are not connected automatically.





This setting allows or prevents access to COM ports on the user device. By default, COM port redirection is allowed.


Auto connect client COM ports

COM port redirection bandwidth limit

COM port redirection bandwith limit percent


This setting allows or prevents access to LPT ports on the user device. By default, LPT port redirection is allowed.

LPT ports are used only by legacy applications that send print jobs to the LPT ports and not to the print objects on the

client device. Most applications today can send print jobs to printer objects. This policy setting is necessary only for servers

that host legacy applications that print to LPT ports.


Auto connect client LPT ports

LPT port redirection bandwidth limit

LPT port redirection bandwith limit percent

Printing Policy Settings

The Printing section contains policy settings for managing client printing.


This setting allows or prevents client printers to be mapped to a server when a user logs on to a session. By default, client

printer mapping is allowed.


Auto-create client printers

Default printer

This setting specifies how the default printer on the user device is established in a session. By default, the user's current

printer is used as the default printer for the session.

To use the current Remote Desktop Services or Windows user profile setting for the default printer, select Do not adjustthe user’s default printer. If you choose this option, the default printer is not saved in the profile and it does not changeaccording to other session or client properties. The default printer in a session will be the f irst printer autocreated in thesession, which is either:

The f irst printer added locally to the Windows server in Control Panel > Printers

The f irst autocreated printer, if there are no printers added locally to the server

You can use this option to present users with the nearest printer through profile settings (known as Proximity Printing).


Printer auto-creation event log preference

This setting specifies the events that are logged during the printer auto-creation process. You can choose to log no errors

or warnings, only errors, or errors and warnings. By default, errors and warnings are logged.

An example of a warning is an event in which a printer’s native driver could not be installed and the universal printer driver is

installed instead. To allow universal printer drivers to be used in this scenario, configure the Universal printing setting to Use

universal printing only or Use universal printing only if requested driver is unavailable.


Universal printing

Session printers

This setting specifies the network printers to be auto-created in a session. You can add printers to the list, edit the settings

of a list entry, or remove printers from the list. You can apply customized settings for the current session at every logon.

Wait for printers to be created (desktop)

This setting allows or prevents a delay in connecting to a session so that desktop printers can be auto-created. By default,

a connection delay does not occur. This setting does not apply to published applications or published desktops.

Client Printers Policy Settings

Updated: 2013-08-12

The Client Printers section contains policy settings for client printers, including settings to autocreate client printers, use

legacy printer names, retain printer properties, and connect to print servers.

Auto create client printers

This setting specifies the client printers that are auto-created. This setting overrides default client printer auto-creation

settings. By default, all client printers are auto-created.

This setting takes effect only if the Client printer redirection setting is present and set to Allowed.

When adding this setting to a policy, select an option:Auto-create all client printers automatically creates all printers on a user device.

Auto-create the client’s default printer only automatically creates only the printer selected as the default printer on the

user device.

Auto-create local (non-network) client printers only automatically creates only printers directly connected to the user

device through an LPT, COM, USB, TCP/IP, or other local port.

Do not auto-create client printers turns off autocreate for all client printers when users log on. This causes the Remote

Desktop Services settings for autocreating client printers to override this setting in lower priority policies.



Client printer names

This setting selects the naming convention for auto-created client printers. By default, standard printer names are used.


For most configurations, select Standard printer names which are similar to those created by native Remote Desktop

Services, such as “HPLaserJet 4 from clientname in session 3.”

Select Legacy printer names to use old-style client printer names and preserve backward compatibility for users or groups

using MetaFrame Presentation Server 3.0 or earlier. An example of a legacy printer name is “Client/clientname#/HPLaserJet

4.” Because this option is less secure, use it only to provide backward compatibility for users or groups using MetaFrame

Presentation Server 3.0 or earlier.

Direct connections to print servers

This setting enables or disables direct connections from the host to a print server for client printers hosted on an accessible

network share. By default, direct connections are enabled.

Allow direct connections if the network print server is not across a WAN from the host. Direct communication results in

faster printing if the network print server and host server are on the same LAN.

If this setting is disabled, print jobs are routed through the user device, where it is redirected to the network print server. Use

this option if the network is across a WAN or has substantial latency or limited bandwidth. Data sent to the user device is

compressed, so less bandwidth is consumed as the data travels across the WAN.

If two network printers have the same name, the printer on the same network as the user device is used.

Printer properties retention

This setting specifies whether or not to store printer properties and where to store them. By default, the system

determines if printer properties are to be stored on the user device, if available, or in the user profile.

When adding this setting to a policy, select an option:Held in profile only if not saved on client allows the system to determine where printer properties are stored. Printer

properties are stored either on the client device, if available, or in the user profile. Although this option is the most

flexible, it can also slow logon time and use extra bandwidth for system-checking.

Saved on the client device only is for user devices that have a mandatory or roaming profile that is not saved. Choose

this option only if all the servers in your farm are running XenApp 5 and above and your users are using Citrix XenApp

online plug-in versions 9.x and above.

Retained in user profile only is for user devices constrained by bandwidth (this option reduces network traff ic) and logon

speed or for users with legacy plug-ins. This option stores printer properties in the user profile on the server and prevents

any properties exchange with the client device. Use this option with MetaFrame Presentation Server 3.0 or earlier and

MetaFrame Presentation Server Client 8.x or earlier. Note that this is applicable only if a Remote Desktop Services

roaming profile is used.

Retained and restored client printers

This setting enables or disables the retention and re-creation of printers on the user device. By default, client printers are

auto-retained and auto-restored.

Retained printers are user-created printers that are created again, or remembered, at the start of the next session. When

XenApp recreates a retained printer, it considers all policy settings except the Auto-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.

Drivers Policy Settings


The Drivers section contains policy settings related to printer drivers.

Automatic installation of in-box printer drivers

This setting enables or disables the installation of Windows native drivers on the user device as needed. By default, native

drivers are installed when users log on.

Printer driver mapping and compatibility

This setting specifies driver substitution rules for auto-created printers. When you define these rules, you can allow or

prevent printers to be created with the specified driver. Additionally, you can allow created printers to use only universal

printer drivers.

Driver substitution overrides (or maps) printer driver names the client provides, substituting an equivalent driver on the server.

This gives server applications access to client printers that have the same drivers as the server but different driver names.

You can add a driver mapping, edit an existing mapping, remove a mapping, or change the order of driver entries in the list.

When adding a mapping, enter the client printer driver name and then select the server driver you want to substitute.


Universal printing

Auto-create client printers

Universal Printing Policy Settings

The Universal Printing section contains policy settings for managing universal printing.

Auto-create generic universal printer

This setting enables or disables auto-creation of the Citrix Universal Printer generic printing object. By default, generic

universal printers are not auto-created.

Universal driver priority

This setting specifies the order in which XenApp attempts to use Universal Printer drivers, beginning with the first entry in

the list. You can add, edit, or remove drivers, and change the order of drivers in the list.

Universal printing

This setting specifies when to use universal printing. Universal printing consists of a generic printer object (Citrix Universal

Printer) and universal printer drivers that work with both Windows and non-Windows clients. By default, universal printing is

used only if the requested driver is unavailable.

When adding this setting to a policy, select an option:Use universal printing only if requested driver is unavailable uses native drivers for client printers if they are available. If the

driver is not available on the server, the client printer is created automatically with the appropriate universal driver.

Use only printer model specif ic drivers specif ies that the client printer use only the native drivers that are auto-created at

logon. If the native driver of the printer is unavailable, the client printer cannot be auto-created.

Use universal printing only specif ies that no native drivers are used.

Use printer model specif ic drivers only if universal printing is unavailable uses the universal printer driver if it is available. If

the driver is not available on the server, the client printer is created automatically with the appropriate native printer

driver.


Universal printing preview preference

This setting specifies whether or not to use the print preview function for auto-created or generic universal printers. By

default, print preview is not used for auto-created or generic universal printers.

Security Policy Settings

The Security section contains policy settings for configuring session encryption and password requirements.

Prompt for password

This setting requires the user to enter a password for all server connections regardless of access scenario. By default, users

are prompted for passwords only for specific types of connections.

SecureICA Encryption

This setting specifies the minimum level at which to encrypt session data sent between the server and a user device.

When adding this setting to a policy, select an option:Basic encrypts the client connection using a non-RC5 algorithm. It protects the data stream from being read directly, but

it can be decrypted. By default, the server uses Basic encryption for client-server traff ic.

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.



The settings you specify for client-server encryption can interact with any other encryption settings in XenApp and your

Windows operating system. If a higher priority encryption level is set on either a server or user device, settings you specify

for published resources can be overridden.

You can raise encryption levels to further secure communications and message integrity for certain users. If a policy requires

a higher encryption level, plug-ins using a lower encryption level are denied connection.

SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for your server farm,

use SecureICA with SSL/TLS encryption.

SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the server and plug-ins to avoid using

SecureICA.

Server Limits Policy Settings

The Server Limits section contains policy settings for controlling idle connections.

These policy settings are applicable to XenApp only.

Server idle timer interval

This setting determines, in milliseconds, how long an uninterrupted user session will be maintained if there is no input from

the user. By default, idle connections are not disconnected (Server idle timer interval = 0). To enable, configure this policy

setting.


Session Limits Policy Settings

The Session Limits section contains policy settings you can use to control the number of connections users can make and

how long sessions remain connected before they are forced to log off.


This setting specifies the maximum number of connections a user can make to the server farm at any given time. The user’s

active and disconnected sessions are counted for the user’s total number of concurrent connections. This setting reduces

the number of client connection licenses in use and conserves resources. By default, there is no limit on concurrent

connections.


Limits on administrator sessions

Limit user sessions

Session Reliability Policy Settings

The Session Reliability section contains policy settings for managing session reliability connections.

Session reliability connections

This setting allows or prevents sessions to remain open during a loss of network connectivity. By default, session reliability is

allowed.

Session Reliability keeps sessions active when network connectivity is interrupted. Users continue to see the application

they are using until network connectivity resumes.

When connectivity is momentarily lost, the session remains active on the server. The user’s display freezes and the cursor

changes to a spinning hourglass until connectivity resumes. The user continues to access the display during the interruption

and can resume interacting with the application when the network connection is restored. Session Reliability reconnects

users without reauthentication prompts.

If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, configure the

Auto client reconnect authentication setting to require authentication. Users are then prompted to reauthenticate when

reconnecting to interrupted sessions.

If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence. Session Reliability closes,

or disconnects, the user session after the amount of time you specify in the Session reliability timeout setting. After that,

the settings you configure for Auto Client Reconnect take effect, attempting to reconnect the user to the disconnected

session.




Session reliability port number

This setting specifies the TCP port number for incoming session reliability connections.


Session reliability timeout

This setting specifies the length of time in seconds the session reliability proxy waits for a client to reconnect before

allowing the session to be disconnected.

The default length of time is 180 seconds, or three minutes. Though you can extend the amount of time a session is kept

open, this feature is designed to be convenient to the user and it does not prompt the user for reauthentication. If you

extend the amount of time a session is kept open indiscriminately, chances increase that a user may get distracted and

walk away from the client device, potentially leaving the session accessible to unauthorized users.

If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, configure the

Auto client reconnect authentication setting to require authentication. Users are then prompted to reauthenticate when

reconnecting to interrupted sessions.


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.




Shadowing Policy Settings

The Shadowing section contains policy settings related to user-to-user shadowing. Shadowing is useful for training

purposes and for viewing presentations. You can also allow help desk personnel to shadow users so they can troubleshoot

user problems.

Input from shadow connections

This setting allows or prevents shadowing users to take control of the keyboard and mouse of the user being shadowed

during a shadowing session. By default, the person shadowing can send input to the session being shadowed.

Log shadow attempts

This setting allows or prevents recording of attempted shadowing sessions in the Windows event log. By default,

shadowing attempts are logged.

Several different event types are recorded in the Windows Event log. These include user shadowing requests, such as when

users stop shadowing, failure to launch shadowing, and access to shadowing denials.

Notify user of pending shadow connections

This setting allows or prevents shadowed users from receiving notification of shadowing requests from other users. When a

user receives a shadowing request, the user can accept or deny the request. By default, users are not notified when they

are being shadowed.

Shadowing


This setting allows or prevents users from shadowing other users’ sessions. By default, administrators can shadow users’

sessions. When you add this setting to a policy, specify the users allowed to shadow by configuring the 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. This means you can shadow ICA sessions over ICA and Remote Desktop Protocol (RDP)

sessions over RDP only.

Shadowing restrictions are set at install time and are permanent. If you enable or disable shadowing, or certain shadowing

features during Setup, you cannot change these restrictions later. You must reinstall XenApp on the server to change

shadowing restrictions.

Any user policies you create to enable user-to-user shadowing are subject to the restrictions you place on shadowing

during Setup.

Users who can shadow other users

This setting specifies the users who are allowed to shadow other users.

Users who cannot shadow other users

This setting specifies the users who are not allowed to shadow other users.

Time Zone Control Policy Settings

The Time Zone Control section contains policy settings related to using local time in sessions.

Local Time Estimation

This setting enables or disables estimating the local time zone of user devices that send inaccurate time zone information

to the server. By default, the server estimates the local time zone when necessary.

Use local time of client

This setting determines the time zone setting of the user session. When enabled, the administrator can choose to default

the user session’s time zone settings to that of the user’s time zone settings. By default, the server’s time zone is used for

the session.

For this setting to take effect, enable the 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.

TWAIN Devices Policy Settings

The TWAIN devices section contains policy settings related to mapping client TWAIN devices, such as digital cameras or

scanners, and optimizing image transfers from server to client.


Client TWAIN device redirection

This setting allows or prevents users from accessing TWAIN devices on the user device from published image processing

applications. By default, TWAIN device redirection is allowed.



TWAIN device redirection bandwidth limit



This setting specifies the level of compression of image transfers from client to server. Use Low for best image quality,

Medium for good image quality, or High for low image quality. By default, no compression applied.

USB Devices Policy Settings

The USB devices section contains policy settings for managing file redirection for USB devices.

Client USB device redirection

This setting allows or prevents redirection of USB devices to and from the client (workstation hosts only). By default, USB

devices are not redirected.

Client USB device redirection rules

This setting specifies redirection rules for USB devices.

When a user plugs in a USB device, the host device checks it against each policy rule in turn until a match is found. The first

match for any device is considered definitive. If the first match is an Allow rule, the device is remoted to the virtual desktop.

If the first match is a Deny rule, the device is available only to the local desktop. If no match is found, default rules are used.

For more information about the default policy configuration for USB devices, refer to CTX119722, “Creating USB Policy

Rules,” in the Citrix Knowledge Center.

Policy rules take the format {Allow:|Deny:} followed by a set of tag= value expressions separated by whitespace. Thefollowing tags are supported:VID

Vendor ID from the device descriptor

PID

Product ID from the device descriptor

REL

Release ID from the device descriptor

Class

Class from either the device descriptor or an interface descriptor

SubClass

Subclass from either the device descriptor or an interface descriptor


Prot

Protocol from either the device descriptor or an interface descriptor

When creating new policy rules, be aware of the following:Rules are case-insensitive.

Rules may have an optional comment at the end, introduced by #.

Blank and pure comment lines are ignored.

Tags must use the matching operator =. For example, VID=1230.

Each rule must start on a new line or form part of a semicolon-separated list.

Refer to the USB class codes available from the USB Implementers Forum, Inc. Web site.

Examples of administrator-defined USB policy rules

Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive

Deny: Class=08 subclass=05 # Mass Storage

To create a rule that denies all USB devices, use “DENY:” with no other tags.


Licensing Policy Settings

Mar 10 , 2010

The Licensing section contains policy settings for configuring Citrix Licensing.

License server host name

This setting specifies the name of the server hosting XenApp licenses.

If you decide to change the license server name, ensure that a license server with the new name already exists on your

network. Because license files are tied to the license server’s host name, you must download a license file that is generated

for the new license server if you decide to change the server’s name. This may involve returning and reallocating the licenses.

License server port

This setting specifies the port number of the server hosting XenApp licenses.

If you change the port number of the license server, specify a new number in all the license files on the server.


Server Session Settings

Mar 10 , 2010

The Server Session Settings section contains policy settings for configuring session importance and Single Sign-On.

Session importance

This setting specifies the importance level at which a session is run.

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


CPU Management Server Level

Single Sign-On

This setting enables or disables the use of Single Sign-on when users connect to servers or published applications in a

XenApp farm. By default, Single Sign-On is enabled.

Single Sign-On central store

This setting specifies the UNC path of the Single Sign-On central store to which users are allowed to connect.

Policies apply only to shared folders you configure to be Single Sign-On central stores. If you want this setting to use the

central store specified by the Single Sign-On plug-in, leave this field blank.

Server farm zone failover preferences apply only to published objects, not to central stores. If the user’s preferred zone is

not operating and the connection fails over to a backup zone, the user cannot access published objects using Single Sign-

On if the central store is in the failed zone.


Server Policy Settings

May 03, 2015

The Server Settings section contains policy settings for configuring access control, DNS address resolution, icon handling,

and XenApp edition.

Connection access control

This setting specifies the types of client connections from which users can start sessions.

When adding this setting to a policy, select an option:Any connections (selected by default) allows access to published applications through any connection.

Citrix Access Gateway, Citrix online plug-in, and Web Interface connections only allows access to published applications

through the listed connections, including any version of Access Gateway. This option denies access through any other

connection.

Citrix Access Gateway connections only allows access to published applications only through Access Gateway Advanced

Edition servers (Version 4.0 or later).

DNS address resolution

This setting enables or disables the server to return fully qualified domain names to clients using the Citrix XML Service.

DNS address resolution works only in server farms that contain servers running MetaFrame XP Feature Release 1 or later,

and clients must be using Presentation Server Client Version 6.20.985 or later or Citrix XenApp Plugin for Hosted Apps

version 11.x.

Full icon caching

This setting enables or disables the caching of larger, high resolution published application icons on farm servers. By default,

icons are cached.

To ensure only specific farm servers are affected by this setting, configure a worker group that includes only the servers you

specify. Then, include the worker group in the filter you add to the policy. If no filter is specified, this setting affects all farm

servers.

Consider disabling this setting if caching icons impacts performance of the server. However, do not disable this setting on

servers acting as XML brokers for the farm.

XenApp product edition

This setting specifies the XenApp product edition.

Setting the product edition activates the features available with a particular edition. The product edition also determines

which type of license a server requests from the license server. Make sure the edition you set matches the licenses that are

installed.

Connection Limits Policy Settings

The Connection Limits section contains policy settings for controlling user and administrator sessions and logon event

logging.


Limit user sessions

This setting specifies the maximum number of connections that users can establish, in the range 0-8192. A value of 0

indicates no connections.

When a user tries to establish a connection in excess of this limit, a message tells the user the connection is not allowed.

When a connection request is denied, the server records the user’s name and time in the System log.



Limits on administrator sessions

This setting enables or disables connection limit enforcement for Citrix administrators. Limiting connections for Citrix

administrators can adversely affect their ability to shadow other users. By default, administrators are exempt from

connection limits.

Logging of logon events

This setting enables or disables the logging of events (to the server event log) about connection attempts that were

denied because they exceeded logon limits. By default, these events are not logged.

Health Monitoring and Recovery Policy Settings

The Health Monitoring and Recovery section contains policy settings for configuring Health Monitoring and Recovery tests

and server load balancing exclusions.

Health monitoring

This setting allows or prevents running Health Monitoring and Recovery tests on the farm servers. By default, Health

Monitoring and Recovery tests are allowed to run.

Health monitoring tests

This setting specif ies which Health Monitoring Tests to run. You can add or remove tests. You can also edit theconfiguration of a test (name, location, description, interval, threshold, time-out and recovery action). By default, thefollowing Citrix tests are run:

Citrix IMA Service

Logon Monitor

XML Service

Remote Desktop Services

Maximum percent of offline servers

This setting specifies the maximum percentage of servers that Health Monitoring and Recovery can exclude from load

balancing. By default, ten percent of servers are excluded.

Memory Optimization Policy Settings

The Memory/CPU section contains policy settings for managing CPU utilization and memory optimization.


CPU management server level

This setting specifies the level of CPU utilization management on the server. Managing CPU resources can normalize CPU

peaks and reduce the resources required to handle CPU spikes. By default, CPU utilization is not managed.

When adding this setting to a policy, select an option:No CPU utilization management disables CPU utilization management on the server.

Fair sharing of CPU between sessions ensures that CPU resources are equitably shared among users by having the server

allocate an equal share of CPU to each user.

Preferential Load Balancing allocates more CPU resources to one user over another based on the resource allotment for

each session. The resource allotment is determined by the importance levels of both the published application running in

the session and the session itself .

Note: To use CPU Utilization Management, ensure the Fair Share CPU Scheduling (DFSS) feature of Remote DesktopServices is disabled on the server.Related Policy Settings

Session importance

Memory optimization

This setting enables or disables memory optimization. Enabling memory optimization improves the ability to manage DLL

allocation in both real and overall virtual memory by creating shared DLLs for applications that are open in multiple sessions.

By default, this setting is disabled.

Memory optimization application exclusion list

This setting specifies the applications that memory optimization should ignore. You can add, edit, or delete applications in

the list.

Memory optimization interval

This setting specifies the interval for running memory optimization. By default, memory optimization runs daily.

When adding this setting to a policy, make sure the Memory optimization setting is present and set to Enabled.

Memory optimization schedule: day of month

This setting specifies the day of the month that memory optimization runs, in the range 1-31. By default, memory

optimization is scheduled for the first day of each month.

When adding this setting to a policy, make sure the following policy settings are present:Memory optimization, set to Enabled

Memory optimization interval, set to Monthly

If the specified day does not occur in a given month (for example, the 30th day in February, or the 31st day in April or June),

memory optimization does not run in that month.

Memory optimization schedule: day of week

This setting specifies the day of the week that memory optimization runs. By default, memory optimization runs on


Sundays.


Memory optimization interval, set to Weekly

Memory optimization schedule: time

This setting specifies the time at which memory optimization runs. The time format is H:MM TT, where H is the hour, MM is

the minute, and TT is the time of day (AM or PM). By default, memory optimization runs at 3:00 AM.


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 TT value,

the time defaults to AM.

Offline Applications Policy Settings

The Offline Applications section contains policy settings for controlling offline application access, licensing, and logging.

Offline app client trust

This setting enables or disables the ability of offline application clients to recreate sessions when reconnecting, without

authenticating again. By default, users must authenticate when reconnecting to offline applications.

Offline app event logging

This setting enables or disables logging of offline application events to the event log on the server. By default, offline

application events are not logged.

Offline app license period

This setting specifies the number of days applications can work offline before users have to renew the license. The license

period, 21 days by default, can range from 2 to 365 days. Licenses automatically renew at login and every day while logged

in. Changes to the license period occur when the license is renewed.

To configure licenses, administrators can use the License Administration Console or command-line tools. They must also

ensure they have a sufficient number of licenses to support the total number of users with offline access permission.

Offline app users

This setting specifies the users who have permission to access offline applications. You can add or delete users from this list.

Users in this group can continue using configured applications after disconnecting from the network for the number of

days specified in the Offline app license period setting. You must configure the applications for offline access in the

application properties.

The total number of users with offline access permission should not exceed the total number of licenses available for


offline access.

Reboot Behavior Policy Settings

Updated: 2013-09-03

The Reboot Behavior section contains policy settings for scheduling server restarts, disabling logons, and configuring

warning messages.

These policy settings are applicable to XenApp Enterprise and Platinum editions only.

Reboot custom warning

This setting enables or disables sending a custom warning message (in addition to the standard restart message) to users

before a scheduled server restart. To specify the text for this warning, configure the Reboot custom warning text setting.

By default, only the standard warning message is sent.

Reboot custom warning text

This setting specifies the text in the custom warning message sent to users before a scheduled server restart. To send a

custom message, the Reboot custom warning setting must be enabled.

Reboot logon disable time

This setting specifies the number of minutes before a scheduled server restart that logons to the server are disabled. By

default, logons are disabled 60 minutes prior to server restart.

Reboot schedule frequency

This setting specifies the frequency, in days, that scheduled server restarts occur. By default, scheduled restarts occur every

7 days (once each week).

Reboot schedule start date

This setting specifies the date on which scheduled server restarts begin, in the form MM/DD/YYYY.

Reboot schedule time

This setting specifies the time at which scheduled server restarts occur in the form H:MM TT, where H is the hour, MM is

the minute, and TT is the time of day (AM or PM). Restart times are scheduled in the local time zone of the server and use a

12-hour clock.

If you enter a time according to a 24-hour clock, the time is converted automatically to a 12-hour clock. If you enter a time

without a TT value, the time of day defaults to AM.

Reboot warning interval

This setting specifies how often standard and custom warning messages are sent to users before a scheduled restart. By

default, messages are sent every 15 minutes.

Configure the Reboot warning start time setting to specify when to start sending the warning messages.


Reboot warning start time

This setting specifies the number of minutes before a scheduled server restart to send standard or custom warnings to

users. By default, messages are sent 60 minutes prior to server restart.

Configure the Reboot warning interval setting to specify how often the warning is sent.

Reboot warning to users

This setting enables or disables sending a standard warning message to users before a scheduled server restart. By default,

messages are not sent to users prior to server restarts.

To send a custom warning message (in addition to the standard message), enable the Reboot custom warning setting and

specify the text in the Reboot custom warning text setting.

Scheduled reboots

This setting enables or disables scheduled server restarts. You can configure automatic restarts at specific times and

frequencies, as well as the starting date of the schedule. By default, server reboots are not scheduled.


Virtual IP Policy Settings

Mar 10 , 2010

The Virtual IP section contains policy settings for configuring Virtual IP support for applications.

Virtual IP adapter address filtering

This setting enables or disables filtering of the list of addresses returned by the GetAdaptersAddresses() function to only

include the session virtual IP address and the loopback address. By default, the list of adapter addresses is not filtered.

Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop Session Host Configuration.

Additionally, enable the Virtual IP enhanced compatibility policy setting. If these settings are not configured, filtering does

not occur.

After enabling this setting, configure the Virtual IP filter adapter addresses programs list to add the applications whose

overhead can be reduced through adapter address filtering.

Virtual IP compatibility programs list

This setting specifies the application processes that can use virtual IP addresses. When adding programs to the list, specify

only the executable name. It is not necessary to specify the entire path.

Virtual IP enhanced compatibility

This setting enables or disables additional support of Windows Remote Desktop IP virtualization. This allows calls to the

gethostbyname() function within sessions to return the assigned virtual IP address for the session. By default, this setting is

disabled.

Before enabling this setting, make sure IP Virtualization is enabled in Remote Desktop Session Host Configuration. If this

setting is not configured, additional support does not occur.

After enabling this setting, configure the Virtual IP enhanced compatibility programs list setting to add the applications that

can use virtual IP addresses.

Virtual IP filter adapter addresses programs list

This setting specifies the application executables that can use filter adapter addresses. When adding programs to the list,

specify only the executable name. It is not necessary to specify the entire path.

Virtual IP loopback support

This setting enables or disables the use of virtual loopback addresses in sessions. By default, sessions do not have virtual

loopback addresses.

After enabling this setting, configure the Virtual IP virtual loopback programs list to add the applications that can use virtual

loopback addresses.

Virtual IP virtual loopback programs list

This setting specifies the application executables that can use virtual loopback addresses. When adding programs to the

list, specify only the executable name. It is not necessary to specify the entire path.


XML Service Policy Settings

Mar 10 , 2010

The XML Service section contains policy settings for configuring the Citrix XML Service.

Trust XML requests

This setting specifies whether the Citrix XML Service should trust requests it receives. Before enabling this rule, avoid

security risks by using IPSec, firewalls, or another technology that ensures only trusted services communicate with the Citrix

XML Service.

XML Service port

This setting specifies the port number to use for the Citrix XML Service. To disable the port, enter 0 as the port number. By

default, the port is disabled.

When specifying the XML Service port number, the range of values you can enter is 1024-65535. Citrix recommends using

port 8080.


Managing Session Environments and Connections

Jan 18 , 2010

Provide user access to your farm’s resources by:

Customizing user environments

Controlling connections

Monitoring, managing, and optimizing sessions

When a user initially connects to your farm and opens a published application, the server opens the application in a session.

In XenApp, the term session refers to a particular instance of a user’s activity on the server; sessions are the virtualization of

the user’s environment.

Users access published applications in sessions after the client device establishes a connection with the server.

When a user logs on to the farm, the client device links to the server through a connection and establishes a session. This

connection is known as the client connection. Users access published resources through client connections, inside of

sessions.

As an administrator, you can customize users’ environments, including whether or not users can access mapped drives, such

as the local client device’s hard disk; if they can access local special folders, the printers that are available, and the amount

of bandwidth used for audio support. You can change these settings based on the location from where the users are

connecting.

XenApp provides settings to ensure sessions remain reliable. You can also monitor users’ sessions, and their sessions’ status,

by shadowing.


Defining User Environments in XenApp

Apr 28 , 2015

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 f irst open an application, so that XenApp appears to be

an integrated part of their everyday environment.

By either allowing or preventing users from accessing their local devices or ports during a session. You can also prevent

users from accessing devices and ports during remote sessions.

By defining whether or not users can hear audio or use microphones during sessions. If you enable audio support, you

can specify the level of audio compression and limit bandwidth, if necessary. You can control audio either at the group

level through policies or at the published application level.

By ensuring that mobile workers, such as travelling salespeople or workers inside a hospital, always have the most

appropriate printers and devices available to them inside of a session.

For the Citrix online plug-in, you can also customize the user’s experience by choosing whether you want published

applications and desktops to appear in a window within a Remote Desktop window or “seamlessly.” In seamless window

mode, published applications and desktops appear in separate resizable windows, which make the application appear to be

installed locally. Certain features are available only in seamless mode.

Some features that relate to session environments or connections, such as dual-monitor mode support and information

about logons, are plug-in specific. Details about these features are located in the Citrix online plug-in and the Web

Interface documentation.

Controlling the Appearance of User Logons

When users connect to a server, they see all connection and logon status information in a sequence of screens, from the

time they double-click a published application icon on the client device, through the authentication process, to the moment

the published application launches in the session.

XenApp achieves this logon look and feel by suppressing the status screens generated by a server’s Windows operating

system when a user connects. To do this, XenApp Setup enables the following Windows local group policies on the server

on which you install the product:

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

Administrative Templates > System > Verbose versus normal status messages

However, Active Directory group policies take precedence over equivalent local group policies on servers. Therefore, when

you install XenApp on servers that belong to an Active Directory domain, those Active Directory policies may prevent

XenApp from suppressing the status screens generated by the Windows operating systems of the individual servers. In that

case, users see the status screens generated by the Windows operating system when connecting to that server. For

optimal performance, do not configure these group policies in Active Directory.

Controlling Access to Devices and Ports

The Citrix online plug-in supports mapping devices on client computers so users can access the devices within sessions.Client device mapping provides:

Access to local drives and ports


Cut-and-paste data transfer between a session and the local clipboard

Audio (system sounds and .wav f iles) playback from the session

During logon, the plug-in reports the available client drives and COM ports to the server. By default, client drives appear as

network resources so the drives appear to be directly connected to the server. The client’s drives are displayed with

descriptive names so they are easy to locate among other network resources. These drives are used by Windows Explorer

and other applications like any other network drive.

In Citrix policies,— redirection

settings are used for mapping.

Redirecting Client COM Ports and Audio

Client COM port redirection allows a remote application running on the server to access devices attached to COM ports on

the user device. COM port and audio redirection are configured with the Client COM port redirection and Client audio

redirection User policy settings.

For more information, see the documentation for the plug-ins you plan to deploy.

To enable user execute permissions on mapped drives

In general, XenApp displays client drive letters as they appear on the user device; for example, the user device's hard disk

drive appears as "C: on ClientName," where ClientName is the name of the user device. This allows the user to access client

drive letters in the same way locally and within sessions.

You can turn off client drive redirection through XenApp policies. In doing so, you also turn off mapping to client floppy disk

drives, hard drive, CD-ROM drives, or remote drives regardless of the policy settings for those individual devices.

As a security precaution, when a user logs on to XenApp, by default, the server maps client drives without user executepermission. To enable users to execute f iles residing on mapped client drives, override this default by editing the registry ona 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 Editorat your own risk. Be sure to back up the registry before you edit it.1. After installing XenApp, open the Registry Editor.

2. Find the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\picadm\Parameters\ExecuteFromMappedDrive.

3. To grant users execute permission on mapped drives, set ExecuteFromMappedDrive to 1.

4. To deny users execute permission on mapped drives, set ExecuteFromMappedDrive to 0.


Displaying Local Special Folders in Sessions

To make it easier for your users to save files to their special folders locally, you can enable Special Folder Redirection. Special

folders is a Microsoft term that refers to Windows folders such as Documents, Computer, and the Desktop.

Without Special Folder Redirection enabled, the Documents and Desktop icons that appear in a session point to the user’s

Documents and Desktop folders on the server. Special Folder Redirection redirects actions, such as opening or saving a file,

so that when users save or open files from special folders, they are accessing the special folder on their local computers. In

addition, for the Citrix Receiver, the Documents folder in the Start menu maps to the Documents folder on the client


device.

To use Special Folder Redirection, users must access the farm with the Citrix online plug-in 11.x or later or the Web

Interface.

Restrictions

Do not enable Special Folders Redirection in situations when a user connects to the same session from multiple client

devices simultaneously. For Special Folder Redirection to work, the user must log off from the session on the first client

device and start a new session on the second client device. If users must run multiple sessions simultaneously, use roaming

profiles or set a home folder for that user in the User Properties in Active Directory.

Because Special Folder Redirection must interact with the client device, some settings prevent Special Folder Redirection

from working. You cannot have policy settings that prevent users from accessing or saving to their local hard drives.

Currently, for seamless and published desktops, Special Folder Redirection works only for the Documents folder. For

seamless applications, Special Folder Redirection only works for the Desktop and Documents folders. Citrix does not

recommend using Special Folder Redirection with published Windows Explorer.

Special Folder Redirection requires access to the Documents and Desktop folders on the user’s local computer. When a

user launches an application through the Web Interface and uses File Security to select No Access in the File Security dialog

box in Connection Center, access is denied to the user’s local workstation drives, including the user’s local Documents and

Desktop folders. As a result, some applications might be unstable when trying to perform read/write operations to the

denied folders. To avoid this, always grant full local access when Special Folder Redirection is enabled.

Caution: Special Folder Redirection does not redirect public folders on Windows Vista and Windows Server 2008. If users areconnecting to servers that are not in their domain, instruct users not to save to public folders. If users save documents topublic folders, they are saving them to a local folder on the server hosting the published application. In large environmentswhere many servers host the same application, it could be diff icult to determine which server contains the public folderwhere 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. Then, 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 userssave documents to these folders, they are saved to the server.

To enable Special Folder Redirection for a XenApp Web site

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

To Select the options


Enable Special Folder Redirection by default and let users turn it off in

their session options.

Provide Special Folder Redirection to all

users

Allow users to customize Special Folder

Redirection

Disable Special Folder Redirection by default, but let users turn it on in

their session options


Redirection

Enable Special Folder Redirection by default and prevent users from

turning it on or off


users


5. Click OK.

To enable Special Folder Redirection for a XenApp Services site

This 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

their session options.


users


Redirection

Disable Special Folder Redirection by default, but let users turn it on in

their session options


Redirection

Enable Special Folder Redirection by default and prevent users from

turning it on or off


users

5. Click OK.

To filter Special Folder Redirection users through a Citrix policy setting

You can allow or prevent specif ic users from having redirected special folders with the Special Folders Redirection policysetting.1. Enable the Special Folder Redirection policy setting and apply f ilters 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).

Configuring Audio for User Sessions

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

resources, including:

Audio properties you configure for individual published applications

Audio related policy settings you configure for specif ic connection types

Audio settings the user configures on the user device

For example, you can use audio-related connection policy settings to control bandwidth usage and server CPU utilization.

You can configure a policy setting to enable audio for connections where audio is essential, and configure another setting

to disable audio for connections where it is not essential. Use policy settings to control the availability of speakers and

microphones in sessions.

Important: To use audio in sessions, users must also enable audio on the user device.When audio is enabled, you can also use policy settings to set compression levels and bandwidth allocation.

To enable or disable audio for published applications

If you disable audio for a published application, audio is not available within the application under any condition. If you

enable audio for an application, you can use policy settings and filters to further define under what conditions audio is

available within the application.

1. In the 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.

To configure bandwidth limits for audio

Use policy settings to configure the amount of bandwidth you want to allocate to audio transfers between servers and

client devices. For example, you might want to create separate policy settings for groups of dial-up users and for those

who connect over a LAN, accommodating the different amounts of bandwidth each group will have available.

In this procedure, you are editing settings for a policy that applies to a specif ic group of f iltered objects, such as servers orusers.1. Configure the following Citrix User policy settings:

Audio redirection bandwidth limit. Specify the bandwidth available for audio in kilobits per second.

Audio redirection bandwidth limit percent. Limit the bandwidth available for audio to a percentage of the overall

bandwidth available. If you configure this setting, you must enable the Overall session bandwidth limit setting.

To configure audio compression and output quality


Use Citrix policy settings to configure the compression levels to apply to sound files. Generally, higher sound quality requires

more bandwidth and higher server CPU utilization. You can use sound compression to balance sound quality and overall

session performance.

Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. Over dial-up

connections, where bandwidth typically is limited, users likely care more about download speed than sound quality. For such

users, create a policy for dial-up connections that applies high compression levels to sound and another for LAN

connections that applies lower compression levels.

In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such as servers or

users.

1. Configure the Audio quality Citrix User policy setting with one of the following options:

Low - for low-speed connections. This causes any sounds sent to the client device to be compressed to a maximum

of 16Kbps. This compression results in a signif icant decrease in the quality of the sound. The CPU requirements and

benefits of this setting are similar to those of the Medium setting; however, the lower data rate allows reasonable

performance for a low-bandwidth connection.

Medium - optimized for speech. This is recommended for most LAN-based connections. This setting causes any

sounds sent to the client device to be compressed to a maximum of 64Kbps. This compression results in a moderate

decrease in the quality of the sound played on the client device.

High - high definition audio. This is recommended for connections where bandwidth is plentiful and sound quality is

important. This setting allows client devices to play a sound f ile at its native data rate. Sounds at the highest quality

level require about 1.3Mbps of bandwidth to play clearly. Transmitting this amount of data can increase bandwidth

requirements, and result in increased CPU utilization and network congestion.

To enable support for microphones and speakers

For users to use speaker and microphones in sessions, both audio input (for microphones) and output (for speakers) must be

enabled. Audio input and output are controlled by two policy settings; you must configure both to ensure that audio input

and output are enabled.

Note: Microphone input is supported on the Citrix online plug-in for Windows, Windows CE, and Linux.This allows you to implement separate connection policies; for example, for users of mobile devices and for users who

connect over a LAN. For the mobile user group, you may want to enable audio input but disable audio output. This lets

mobile users record notes from the field, but prevents the server from sending audio to the mobile devices, ensuring better

session performance. Enabling audio input and output also enables support for digital dictation.

On the client device, users control audio input and output in a single step— by selecting an audio quality level from the

Options > Session Options dialog box.

By default, when you configure these settings, audio input is enabled on client devices. Web Interface users can override

the policy and disable their microphones by selecting No in the Audio Security dialog box, which they access from the Citrix

Connection Center.

In this procedure, you are editing settings for a policy that applies to a specific group of filtered objects, such as servers or

users.

1. To enable audio input for sessions, configure the Client microphone redirection Citrix User policy setting.

2. To enable audio output for sessions, configure the Client audio redirection Citrix User policy setting.


To use and set sound quality for digital dictation devices

If you have enabled microphone and speaker support, XenApp requires no additional configuration to allow users to record

audio using a standard microphone. However, to allow users to use digital dictation devices such as Philips SpeechMike

devices and dictation software such as WinScribe Internet Author and Internet Typist, you must install and configure the

associated software and set session sound quality to accommodate them.

To enable Phillips SpeechMike devices, go to the Philips web site for information and software downloads.

Note: The Citrix plug-ins for Linux and Windows CE do not support Philips SpeechMike products.To make Philips SpeechMike devices or similar products available in user sessions, install the device drivers associated with

the products on the XenApp server and on client devices. To make dictation software such as WinScribe Internet Author

and Internet Typist available, install this software on the XenApp server. After installation, you might be required to enable

the controls for the dictation device within the dictation software. Refer to the product documentation for instructions.

Set sound quality to at least medium quality. To enable the use of Philips SpeechMagic Speech Recognition server with

WinScribe software, set sound quality to high to enable accurate speech-to-text translation.

1. From Citrix Web Interface Management, select the XenApp Services site you want to configure.

2. In the Action pane, select Session Options.

3. Select Color and Sound.

4. In the Sound area, select one of :

Medium - optimized for speech

High - high definition audio

Ensuring Session Continuity for Mobile Workers

The Workspace Control feature provides users with the ability to disconnect quickly from all running applications, to

reconnect to applications, or to log off from all running applications. Workspace Control enables users to move among

client devices and gain access to all of their open applications when they log on.

For example, you can use Workspace Control to assist health-care workers in a hospital who need to move quickly between

workstations and access the same set of applications each time they log on to XenApp. If you configure Workspace

Control options to allow it, these workers can disconnect from multiple applications at one client device and then

reconnect to open the same applications at a different client device.

For users accessing applications through the Web Interface or the Citrix online plug-in, you can configure— and allow users

to configure— these activities:

Logging on. By default, Workspace Control enables users to reconnect automatically to all running applications when

logging on, bypassing the need to reopen individual applications. Through Workspace Control, users can open

disconnected applications plus applications active on another client device. Disconnecting from an application leaves the

application running on the server. If you have roaming users who need to keep some applications running on one client

device while they reconnect to a subset of their applications on another client device, you can configure the logon

reconnection behavior to open only the applications that the user disconnected from previously.

Reconnecting. After logging on to the server farm, users can reconnect to all their applications at any time by clicking

Reconnect. By default, Reconnect opens applications that are disconnected plus any applications currently running on

another client device. You can configure Reconnect to open only those applications that the user disconnected from

previously.

Logging off . For users opening applications through the Web Interface, you can configure the Log Off command to


log the user off from the Web Interface and all active sessions together, or log off from the Web Interface only.

Disconnecting. Users can disconnect from all running applications at once without needing to disconnect from each

application individually.

Workspace Control is enabled in the server farm by default and is available only for users accessing applications through the

Web Interface or the Citrix online plug-in.

User policies, client drive mappings, and printer configurations change appropriately when a user moves to a new client

device. Policies and mappings are applied according to the client device where the user is currently logged on to the session.

For example, if a health care worker logs off from a client device in the emergency room of a hospital and then logs on to a

workstation in the hospital’s X-ray laboratory, the policies, printer mappings, and client drive mappings appropriate for the

session in the X-ray laboratory go into effect at the session startup.

You can customize what printers appear to users when they change locations as well as control whether they can print to

local printers, how much bandwidth is consumed when users connect remotely, and other aspects of their printing

experiences.

For more information about enabling and configuring Workspace Control for users, see the Web Interface documentation.

Maintaining Session Activity

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

Session Reliability

Auto Client Reconnect

ICA Keep-Alive

Configuring Session Reliability

Session Reliability keeps sessions active and on the user’s screen when network connectivity is interrupted. Users continue

to see the application they are using until network connectivity resumes.

This feature is especially useful for mobile users with wireless connections. Take, for example, a user with a wireless

connection who enters a railroad tunnel and momentarily loses connectivity. Ordinarily, the session is disconnected and

disappears from the user’s screen, and the user has to reconnect to the disconnected session.

With Session Reliability, the session remains active on the server. To indicate that connectivity is lost, the user’s display

freezes and the cursor changes to a spinning hourglass until connectivity resumes on the other side of the tunnel. The user

continues to access the display during the interruption and can resume interacting with the application when the network

connection is restored. Session Reliability reconnects users without reauthentication prompts.

Users of the Citrix online plug-in cannot override the server setting.

Note: You can use Session Reliability with Secure Sockets Layer (SSL).By default, Session Reliability is enabled through policy settings. You can customize the policy settings for this feature as

appropriate. You can edit the port on which XenApp listens for session reliability traffic and edit the amount of time Session

Reliability keeps an interrupted session connected.

The Citrix Computer policy Session reliability connections setting allows or prevents session reliability.


The Session reliability timeout setting has a default of 180 seconds, or three minutes. Though you can extend the amount

of time Session Reliability keeps a session open, this feature is designed to be convenient to the user and it does not,

therefore, prompt the user for reauthentication. If you extend the amount of time a session is kept open indiscriminately,

chances increase that a user may get distracted and walk away from the client device, potentially leaving the session

accessible to unauthorized users.

Incoming session reliability connections use port 2598, unless you change the port number with the Citrix Computer policy

Session reliability port number setting.

If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, use the Auto

Client Reconnect feature. You can configure the Citrix Computer policy Auto client reconnect authentication setting to

prompt users to reauthenticate when reconnecting to interrupted sessions.


or disconnects, the user session after the amount of time you specify in the Citrix Computer policySession reliability

timeout setting. After that, the Auto Client Reconnect policy settings take effect, attempting to reconnect the user to

the disconnected session.

Configuring Automatic Client Reconnection

The Auto Client Reconnect feature allows Citrix plug-ins for Windows, Java, and Windows CE to detect broken connections

and automatically reconnect users to disconnected sessions. When a plug-in detects an involuntary disconnection of a

session, it attempts to reconnect the user to the session until there is a successful reconnection or the user cancels the

reconnection attempts.

When a connection breaks, it may leave the server session in an active state. Users can reconnect only to sessions that are

in a disconnected, or inactive, state. Cookies containing keys to user credentials and session IDs are created on the client

device when sessions are started. Because users can be reconnected only to disconnected sessions, Auto Client Reconnect

uses the cookie on the client device to disconnect an active session before attempting to reconnect.

Configure Auto Client Reconnect with the following Citrix Computer policy settings:Auto client reconnect. Enables or disables automatic reconnection by the same client after a connection has been

interrupted.

Auto client reconnect authentication. Enables or disables the requirement for user authentication upon automatic

reconnection

Auto client reconnect logging. Enables or disables logging of reconnection events in the event log. Logging is disabled by

default. When enabled, the server's System log captures information about successful and failed automatic

reconnection events. Each server stores information about reconnection events in its own System log; the server farm

does not provide a combined log of reconnection events for all servers.

Auto Client Reconnect incorporates an authentication mechanism based on encrypted user credentials. When a user

initially logs on to a server farm, XenApp encrypts and stores the user credentials in memory, and creates and sends a cookie

containing the encryption key to the plug-in. The plug-in submits the key to the server for reconnection. The server

decrypts the credentials and submits them to Windows logon for authentication. When cookies expire, users must

reauthenticate to reconnect to sessions.

Cookies are not used if you enable the Auto client reconnection authentication setting. Instead, XenApp displays a dialog

box to users requesting credentials when the plug-in attempts to reconnect automatically.

Note: For maximum protection of users’ credentials and sessions, use SSL encryption for all communication between clients


and the server farm.Disable Auto Client Reconnect on the Citrix plug-in for Windows by using the icaclient.adm file. For more information about

plug-in configuration, see the online plug-in documentation.

Settings for connections also affect Auto Client Reconnect.

Configuring Connections for Automatic Client Reconnection

By default, Auto Client Reconnect is enabled through policy settings on the farm level. User reauthentication is not required.

However, if a server’s ICA TCP connection is configured to reset sessions with a 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 the plug-in.

The connection can be configured to reset, or log off, sessions with broken or timed out connections. When a session is

reset, attempting to reconnect initiates a new session; rather than restoring a user to the same place in the application in

use, the application is restarted.

If XenApp is configured to reset sessions, Auto Client Reconnect creates a new session. This process requires users to enter

their credentials to log on to the server.

Automatic reconnection can fail if the plug-in submits incorrect authentication information, which might occur during an

attack or the server determines that too much time has elapsed since it detected the broken connection.

Configuring ICA Keep-Alive

Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled, if XenApp

detects no activity (for example, no clock change, no mouse movement, no screen updates), this feature prevents Remote

Desktop Services from disconnecting that session. XenApp sends keep-alive packets every few seconds to detect if the

session is active. If the session is no longer active, XenApp marks the session as disconnected.

However, the ICA Keep-Alive feature does not work if you are using Session Reliability. Session Reliability has its own

mechanisms to handle this issue. Only configure ICA Keep-Alive for connections that do not use Session Reliability.

ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy.

1. Configure the following Citrix Computer policy settings:

1. ICA keep alive timeout. Specif ies the interval (1-3600 seconds) used to send ICA keep-alive messages. Do not

configure this option if you want your network monitoring software to close inactive connections in environments

where broken connections are so infrequent that allowing users to reconnect to sessions is not a concern.

The 60 second default interval causes ICA Keep-Alive packets to be sent to client devices every 60 seconds. If a client

device does not respond in 60 seconds, the status of the ICA sessions changes to disconnected.

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


Managing and Monitoring XenApp Sessions

Apr 28 , 2015

You can interact directly with sessions by resetting, disconnecting or logging off sessions, or sending messages to users. You

can monitor sessions through AppCenter displays or directly through shadowing.

Disconnecting and Resetting Sessions

A disconnected session is still active and its applications continue to run, but the client device is no longer communicating

with the server. A user can reconnect to a disconnected session from a different client device without loss of data. For

example, you might disconnect users’ sessions if they experience problems on their client device and do not want to lose

data from their applications.

When you disconnect a session, you close the connection between the client device and the server. However, this does not

log off the user, and programs that were running in the session are still running on the server. (Some applications that rely

on virtual channels, such as media players, may behave differently. For example, if you disconnect from a session running

Media Player while playing audio, the audio stops playing because the audio virtual channel is no longer available.) When a

session is disconnected, session state displays indicate Disconnected. If the client user then connects to the server (by

selecting a published application or custom connection to the server), the disconnected session is reconnected.

You can log off users from their sessions. You can also reset a user’s client session or a disconnected session.

You can also connect to a user’s disconnected session when you are using the AppCenter from within a client session on a

XenApp server. To connect, you must know the password of the user who started the session. Your session must support

the same video resolution as the disconnected session.

Resetting a session terminates all processes that are running in that session. You can reset a session to remove remaining

processes in the case of a session error; however, resetting a session can cause applications to close without saving data.

When you reset a disconnected session, session state displays indicate Down. When you refresh the AppCenter display or

when the next automatic refresh occurs, the session no longer appears in the list of sessions.

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 use session controls

From the AppCenter:To disconnect a session:

1. Select the server to which the user is connected.

2. In the results pane, click the Sessions tab.

3. Select the session you want to reset. (You can select one or more sessions.)

4. In the Actions pane, select Disconnect.

To logoff from a session:

Caution: Ending user sessions using Logoff can result in loss of data if users do not close their applications f irst. Before

initiating the logoff , send a message to warn users to exit all applications.


2. In the results pane, click the Sessions tab.


3. Select the session you want to log off . (You can select one or more sessions.)

4. In the Actions pane, select Log off . Confirm the logoff when prompted.

To terminate processes in a user session:

Caution: Terminating a process may abruptly end a critical process and leave the server in an unusable state.


2. In the results pane, click the Users tab and select the session for which you want to terminate a process.

3. In the lower portion of the results pane, click the Processes tab and select the process you want to terminate.

4. In the Actions pane, select Terminate.

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.

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

Sending a message that appears in user sessions can be helpful in situations such as broadcasting information about new

applications and upgrades, requesting a shadowing session, or warning of a logoff or system shutdown.

1. From the AppCenter, select the server to which the users are connected. To send a message to all user sessions in the

farm, select a farm node instead of a server.

2. In the results pane, click the Users tab and select one or more sessions.

3. In the Actions pane, select Send Message. The Send Message dialog box appears.

4. Edit the title of the message, if required, and enter the message text.

Monitoring Session Information

1. From the Delivery Services Console, select the server on which you want to monitor sessions.

2. In the results pane, click the Sessions tab. The display lists all sessions running on the server.

By default, the upper portion of the results pane includes the following information for all sessions (click Choose columns

to specify which columns to display and the display order):

Field Description

User Name of the user account that initiated the session. For anonymous connections, the user name is a

string beginning with "Anon" followed by a session number.

Session ID Unique number that begins with 0 for the f irst connection to the console. Listener sessions are

numbered from 65,537 and numbered backward sequentially.

Application Name of the published application running in the session.

Type Session type: ICA or RDP

State Active, Listen, Idle, Disconnected, or Down.

Client

Name

Name of the client device that is running the session.

Logon

Time

When the user logged on.


Idle T ime How long the session has been idle.

Server Server on which the application is running.

Field Description

3. Select a session. Depending on the session you select:

Tasks become available in the Actions pane; these can include Reset, Log off , Disconnect, and Send Message.

The lower portion of the results pane displays tabs containing additional information: Information, Client Cache,

Session Information, Client Modules, and Processes.

Viewing User Sessions

You can view another user’s session on another device by using shadowing. When shadowing, you can monitor the session

activity as if you are watching the screen of the client device that initiated the session. If configured, you can also use your

keyboard and mouse to control the user’s keyboard and mouse remotely in the shadowed session. Shadowing a session

provides a powerful tool for you to assist and monitor users. Shadowing is a useful option for your Help desk staff who can

use it to aid users. Help desk personnel can view a user’s screen or actions to troubleshoot problems and can demonstrate

correct procedures. You can also use shadowing for remote diagnosis and as a teaching tool. You can shadow using either

the Delivery Services Console or the Shadow Taskbar.

You enable shadowing on a server when you configure XenApp and select the default option, which allows shadowing on all

connections on the server. If you do not leave the shadowing option enabled during configuration, you must reinstall

XenApp to get shadowing functionality.

By default, the user is notified of the pending shadowing and asked to allow or deny shadowing.

Important: Your client device and shadowing ICA session must support the video resolution of the user’s ICA session (theshadowed session). If not, the operation fails. You cannot shadow a system console from another session.For shadowing options by connection type, such as keyboard, mouse, and user notification options, use the Remote

Desktop Server Configuration tool.

Viewing User Sessions with the Shadow Taskbar

Use the Shadow Taskbar to shadow multiple ICA sessions from a single location, including the server console. Use the

Shadow button to start shadowing one or more users. The Shadow Taskbar uses the client to launch an ICA session to

monitor a user. A separate ICA session is started for each shadowed user.

You must enter your user name and password to start an ICA session on the server running the Shadow Taskbar.

Note the following:The client uses a license to log on to the server and start shadowing a user.

The Shadow Taskbar shows sessions on the server or domain you logged on to. You can view servers in a different

domain by logging on to an account in that domain and restarting the Shadow Taskbar.

Each shadow session consumes memory on the server, so limit the number of simultaneous shadow sessions.

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

the shadowing sessions you have open.

To start the Shadow Taskbar


1. From the Start menu, choose All Programs > Citrix > Administration Tools > Shadow Taskbar.

2. To configure shadowing options, right-click an empty area of the Shadow Taskbar or press SHIFT + F10. To switch to a

shadow session, click its button in the Shadow Taskbar.

To close the Shadow Taskbar, right-click an empty area of the Shadow Taskbar and select Exit.

Enabling Logging for Shadowing

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

on the server:

In a central f ile. Configuring this option records a limited number of logging events, such as when and who started a

shadowing session and who is being shadowed. When you configure shadow logging through the Shadow Taskbar, the

logged events are not recorded in the Windows Event log. Instead, they go to a f ile that you specify.

In the Windows Event log. Configuring this option logs several different event types in the Application log of the

Windows Event log. These include user shadowing requests, such as when users stop shadowing, failure to launch

shadowing, and access to shadowing denied. However, these events are logged as they occur and it can be cumbersome

to see a shadowing history because the events are strewn throughout the Event log.

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

centralized and easier to review.

To configure shadow logging to log in a central file

1. Click on an empty area of the Shadow Taskbar and press SHIFT + F10.

2. Click Logging Options.

3. Select the Enable Logging check box and specify a log f ile path.

Click Clear Log to empty the current log file.

To enable shadow logging in the Windows Event log

Configure the Citrix User policy Log shadow attempts setting.

Enabling User-to-User Shadowing with Policies

You can create a user policy to enable user-to-user shadowing, which allows users to shadow other users without requiring

them to be members of the Citrix administrator group. With user-to-user shadowing, multiple users from different locations

can view presentations and training sessions, allowing one-to-many, many-to-one, and many-to-many online collaboration.

Also, you can enable Help Desk personnel to shadow users’ sessions or allow your Sales Department to hold an online

meeting to review sales leads.

Important: You configure shadowing settings during XenApp configuration. If you choose to prohibit shadowing duringconfiguration, you cannot enable shadowing with user policies.You enable user-to-user shadowing by creating policies that define users who can and cannot shadow. You then assign the

policies to the users to be shadowed.

The list of users permitted to shadow is exclusive for each user for whom a policy is assigned. For example, if you create a

policy that permits User A to shadow User B, this policy allows only User A to shadow User B, unless you add more users to

the list of users who can shadow in the same policy’s Property sheet.


To create a policy to define users who can shadow

1. Create a user policy that identif ies the users who can shadow other users’ sessions.

2. Assign the policy to the users to be shadowed.

3. Publish the Citrix Shadow Taskbar and assign it to the users who will shadow. Be sure to instruct these users how to

initiate shadowing from their client devices.

Note: Instruct users not to launch the Shadow taskbar in seamless mode. The Shadow taskbar cannot function in seamlessmode.Example: To create a user policy for user-to-user shadowing and assign it to users

This example demonstrates how to enable user-to-user shadowing by creating a policy for your “Sales” user group that

allows them to shadow the department manager for online collaboration on sales leads. This procedure shows the creation

of a shadowing policy.

1. Create a new policy named “Sales Group Shadowing.”

2. Add the Shadowing Citrix Computer policy setting and set it to Allowed

3. Because the Sales Manager may work with sensitive data, add the Notify user of pending shadow connections Citrix

User policy setting and set it to Enabled. If the Sales Manager does not want other users to be able to take control of

his mouse and keyboard, add the Input from shadow connections Citrix User policy setting and set it to Prohibited.

4. Add the Users who can shadow other users Citrix User policy setting, and select the users who can shadow the Sales

Manager.

5. To specify users who cannot shadow the Sales Manager, add the Users who cannot shadow other users Citrix User

policy setting, and select users.

6. Add the User f ilter and select the users who can receive shadowing requests.


Controlling Client Connections in XenApp

Apr 29, 2015

You can control XenApp client connections in these ways.Citrix Receiver

A software client that is installed on the user device, supplies the connection to the virtual machine via TCP port 80 or 443,

and communicates with StoreFront using via the StoreFront Service API.

XenApp policies

Policies let you define how you want clients to connect, including SSL or encryption requirements, and the properties for

the user’s environments after the connection is established.

Citrix recommends using XenApp policies whenever possible to control connections. Connection settings defined through

XenApp policies also supersede all other connection settings in your environment, including those at the operating system

level, in TS Config, and specified when you publish an application

Application Publishing

You can define connection settings on a per-application basis when you are publishing a resource. Settings you can define

include the maximum number of connections to an application, importance level of the application, maximum number of

instances an application can run in the farm, types of connections that can access an application, audio properties, and

encryption requirements.

Terminal Services Conf iguration

Terminal Services Configuration (TS Config), which is part of Windows Server 2008, lets you define XenApp connection

settings similar to the ones found in XenApp policies. However, these TS Config settings must be defined on a per-server

basis. Because defining settings using TS Config requires setting them on each server in your farm, Citrix recommends using

TS Config to define connection settings only for test farms or very small server farms.

Active Directory

Citrix provides a Group Policy Object (GPO) template, the icaclient.adm, that contains Citrix-specif ic rules for securing client

connections. This GPO lets you configure rules for network routing, proxy servers, trusted server configuration, user routing,

remote client devices, and the user experience. For more information, see the Citrix online plug-in documentation.

Preventing Specific Client Connection Types

You can specify the types of client connections from which users can start sessions. For example, to increase security, you

can specify that users must connect through Access Gateway Advanced Edition (Version 4.0 or later). This allows you to

benefit from filters created in Access Gateway.

To configure connection access control

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

Any connections allows access to published applications through any connection.

Citrix Access Gateway, Citrix online plug-in, and Web Interface connections only allows access to published

applications through the listed connections, including any version of Access Gateway. Denies access through any

other connection.

Citrix Access Gateway connections only allows access to published applications only through Access Gateway

Advanced Edition servers (Version 4.0 or later).


Specifying Connection Limits

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

Performance degradation and errors resulting from individual users who run more than one instance of a published

application at the same time

Denial-of-service attacks by malicious users who run multiple application instances that consume server resources and

connection license counts

Over-consumption of resources by non-critical activities such as Web browsing

Connection limits, including the option to log denials resulting from connection limits, are configured in Computer policy

settings. (You cannot configure connection limits in the plug-ins.)

There are two types of connection limits:Concurrent connections to the server farm - Restricts the number of simultaneous connections that each user in the

server farm can establish. See— Limiting Connections to a Server Farm

.

Published application instances - Restricts the total number of instances of a published application that can run in the

server farm at one time, and prevents users from launching more than one instance of a published application. See— Limiting Application Instances

. .

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

Limiting Connections to a Server Farm

To conserve resources, you can limit the number of concurrent connections that users are permitted to establish. Limiting

connections can help prevent over-consumption of server resources by a few users.

Active sessions and disconnected sessions are counted for the total number of concurrent connections. For example, you

can set a limit of three concurrent connections for users. If a user has three concurrent connections and tries to establish a

fourth, the limit you set prevents the additional connection. A message tells the user that a new connection is not allowed.

Connection control affects users only if a connection attempt is prevented. If a user’s number of connections exceeds a

connection limit, the plug-in displays a message that describes why the connection is not available.

You can also limit the number of connections on a farm by ensuring that session sharing is enabled.

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

When this setting is used, users can still launch additional sessions, as long as the limit has not been reached.

1. Configure the following Citrix Computer policy settings:

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

of 0 indicates no connections.

Limits on administrator sessions. Enables or disables connection limit enforcement for Citrix administrators. Limiting

connections for Citrix administrators can adversely affect their ability to shadow other users.

Local administrators are exempt from the limit so they can establish as many connections as necessary.

To specify the maximum number of connections a user can make to the server farm at a given


timeWhen this setting is used and the specified number is reached, the user cannot launch additional sessions, even if the server

has availability.

1. Configure the Citrix User Policy Concurrent logon limit setting.

Sharing Sessions and Connections

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

In seamless window mode, published applications and desktops are not contained within an ICA session window. Each

published application and desktop appears in its own resizable window, as if it is physically installed on the client device.

Users can switch between published applications and the local desktop.

In non-seamless window mode, published applications and desktops are contained within an ICA session window. This

creates the effect of the application appearing in two windows.

The mode that you choose typically depends on the type of client device that your users will be using and whether you are

publishing a desktop or individual applications. Desktops are typically published in non-seamless window mode. This table

provides examples of when you might want to publish desktops and applications.

If your users will be using... then you...

Local computers Might want to publish desktops or individual applications.

Local computers with locally installedapplications

Might want to publish individual applications.

Thin clients Must publish desktops.

Kiosks Might want to publish desktops, which allows the user to have a moreholistic experience and provide more control from a security perspective.

When a user launches a published application, the plug-in establishes a connection to a XenApp server and initiates a

session. If session sharing is not configured, a new session is opened on the server each time a user opens an application.

Likewise, every time a user opens a new application, a new client connection is created between the client device and the

server.

Session sharing is a mode in which more than one published application runs on a single connection. Session sharing occurs

when a user has an open session and launches another application that is published on the same server; the result is that

the two applications run in the same session. For session sharing to occur, both applications must be hosted on the same

server. Session sharing is configured by default when you specify that applications appear in seamless window mode. If a

user runs multiple applications with session sharing, the session counts as one connection.

If you want to share sessions, ensure all applications are published with the same settings. Inconsistent results may occur

when applications are configured for different requirements, such as encryption.

Note: Session sharing is not supported on PocketPC clients.Session sharing always takes precedence over load balancing. That is, if users launch an application that is published on the


same server as an application they are already using but the server is at capacity, XenApp still opens the second application

on the server. Load management does not transfer the user’s request to another server where the second application is

published.

Limiting Application Instances

By default, XenApp does not limit the number of instances of a published application that can run at one time in a farm. By

default, a user can launch more than one instance of a published application at the same time.

You can specify the maximum number of instances that a published application can run at one time or concurrently in the

server farm. For example, you can publish an application and set a limit of 30 concurrent instances in the farm. Once 30

users are running the application at the same time, no more users can launch the application because the limit of 30

concurrent instances was reached.

Another connection control option lets you prevent any user from running multiple instances of a particular published

application. With some applications, running more than one instance in a single user context can cause errors.

You can apply application limits independently to each published application. For example, you can apply the limitations on

total concurrent instances and multiple instances by a single user to one published application. You can limit only the total

concurrent instances of another application. You can configure a third application to limit launching of multiple instances by

individual users.

Note: Connection control options apply to published applications and published desktops only and do not affect publishedcontent such as documents and media f iles that execute on the client device.To specify a limit for a published application or desktop

1. From the Delivery Services Console, select the farm, then select Applications.

2. Select the application or desktop you want to modify. In the Action menu, select Application properties.

3. In the Properties tree, select Limits. Select one or both of the following options:

Limit instances allowed to run in server farm. Enter the maximum number of instances that can run at one time in the

server farm without regard to who launches the application.

For example, if you enter 10 and a user tries to launch the application when 10 instances are running, the server denies

the connection request and records the time and the name of the published application in the System log.

Allow only one instance of application for each user. Prevents any user from running more than one instance of this

application at the same time.

Logging Connection Denial Events

Event logging records an entry in the System log each time a server denies a user connection because of a connection

control limit. Each server records the data in its own System log. By default, this type of event logging is disabled.

You can configure XenApp to log when limits are reached (and connections denied) for the following:Maximum connections per user

Application instance limits

Application instances per user

To enable or disable logging of connection denial events, configure the Logging of logon limit events Citrix Computer policy

setting.


Configuring the ICA Listener

To configure the ICA listener, use the Citrix ICA Client Configuration Tool (CtxICACfg.exe). For more information, seeCTX125139.Important: Do not use Microsoft Remote Desktop Services tools to configure the ICA listener.

Preventing User Connections During Farm Maintenance

You might want to prevent logons to a server when you install software or perform other maintenance or configuration

tasks. This is helpful when you are installing applications that require there be no active sessions on the server. It also lets

you restart the server without having to wait for users to disconnect.

By default, logons are enabled when you install XenApp and users can launch an unlimited number of sessions and instances

of published applications. You can prevent users from connecting to a server in the farm by disabling logons.

To disable logons on a server

1. From the Delivery Services Console, select the server.

2. In the Actions pane, select Other Tasks > Disable logon.

Note: To reenable disabled logons, select Other Tasks > Enable logon.



Optimizing User Sessions for XenApp

May 16, 2015

XenApp includes various HDX features that allow you to enhance user experience by maintaining session activity and

improving session responsiveness.

Network latency and bandwidth availability can impact the performance of connections to published applications and

content. These HDX technologies allow you to improve connection speed and responsiveness during user sessions.

Optimizing Audio and Video Playback

HDX MediaStream Multimedia Acceleration improves the user’s experience of accessing published audio-visual applicationsand content. Enabling this feature increases the quality of audio and video rendered from the server to a level thatcompares with audio and video played locally on a client device. In addition, it reduces use of network bandwidth and serverprocessing and memory because compressed multimedia f iles are intercepted and forwarded to the client to beuncompressed. This feature optimizes multimedia playback through published instances of Internet Explorer, WindowsMedia Player, and RealOne Player. It offers signif icant performance gains in these areas:

User Experience. Multimedia playback in sessions is much smoother.

Server CPU Utilization. The client device decompresses and renders multimedia content, freeing server CPU utilization.

Network Bandwidth. Multimedia content is passed over the network in compressed form, reducing bandwidth

consumption.

Note: With HDX MediaStream Multimedia Acceleration enabled, RealOne Player’s built-in volume and balance controls donot work within client sessions. Instead, users can adjust volume and balance from the volume controls available from thedevice notif ication area.Without HDX MediaStream Multimedia Acceleration, the cumulative cost of several users playing multimedia content in

sessions simultaneously is high, both in terms of server CPU utilization and network bandwidth consumption. When you play

multimedia content in a session, the server decompresses and renders the multimedia file, which increases the server’s CPU

utilization. The server sends the file over the network in uncompressed form, which consumes more bandwidth than the

same file requires in compressed form.

With HDX MediaStream Multimedia Acceleration, the server streams multimedia to the client in the original, compressed

form. This reduces bandwidth consumption and leaves the media for the client device to decompress and render, thereby

reducing server CPU utilization.

HDX MediaStream Multimedia Acceleration optimizes multimedia files that are encoded with codecs (compression

algorithms) that adhere to Microsoft’s DirectShow, DirectX Media Objects (DMO), and Media Foundation standards.

DirectShow and Media Foundation are application programming interfaces (APIs) that allow, among other things,

multimedia playback. To play back a given multimedia file, a codec compatible with the encoding format of the multimedia

file must be present on the client device.

Generally, if you can play back a given multimedia file locally on a given client device, you can play back the same file on the

same client device within a session. Users can download a wide range of codecs, such as those supported by Windows

Media Player or RealOne Player, from vendor Web sites.

Users accessing audio-visual applications on servers on which HDX MediaStream Multimedia Acceleration is enabled use a

little more memory but far less bandwidth than when this feature is disabled. Users use only a little more memory or

bandwidth when accessing audio-visual applications compared to regular enterprise applications.


To allow users to run multimedia applications in ICA sessions, turn on audio or give the users permission to turn on audio

themselves in Citrix online plug-in. By default, all other plug-ins and methods are configured with audio enabled and

optimized for speech sound quality.

Other requirements for using HDX MediaStream Multimedia Acceleration are:

Users must be running a Citrix online plug-in.

The user device must have the same memory and processing speed as is needed for playing multimedia locally.

The correct codec to decompress the media f ile type used (MPEG for example) must reside on the user device. Windows

devices have the most common codecs already installed. If you need additional codecs, you can download them from

the Web sites of the manufacturers of media players.

Note: To make Windows Media Player 11 and Media Foundation components available on your XenApp server, install andconfigure 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 f ilter technologies

such as Windows Media Player, RealPlayer.

Applications like Internet Explorer and Microsoft Encarta are also supported, as they leverage Windows Media Player.

Both f ile-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 f iles protected with Digital Rights Management(DRM).When the quality of media playing on a user device deteriorates, possible solutions are:

If video appears in slowly changing slides while audio is intact or audio becomes choppy, this is caused by low bandwidth.

Arrange for users to play media on the network where more bandwidth is available.

If audio and video are not synchronized, generally only the video or audio is played using HDX MediaStream Multimedia

Acceleration. This can happen if a client device lacks a codec for either video or audio. Install the needed codec on the

client or use media content on the server for which clients have both codecs.

By default, HDX MediaStream Multimedia Acceleration is enabled at the server farm level.

Configuring HDX MediaStream Multimedia Acceleration

Configure HDX MediaStream Multimedia Acceleration in a Citrix policy.

Note: By default, audio is disabled on the client. To allow users to run multimedia applications in sessions, turn on audio orgive the users permission to turn on audio themselves on their user devices.1. Configure the following Citrix Computer policy setting:

HDX MediaStream Multimedia Acceleration. Enables or disables the feature.

HDX MediaStream Multimedia Acceleration default buffer size. Specif ies the buffer size in seconds, in the range 1-10;

requires enabling the HDX MediaStream Multimedia Acceleration default buffer size use option. You can see how

much server memory the selected buffer can use by changing the buffer time.

HDX MediaStream Multimedia Acceleration default buffer size use. Enables or disables use of a buffer. When this

option is enabled, specify the buffer size with the HDX MediaStream Multimedia Acceleration default buffer size

option

Optimizing Flash Content


HDX MediaStream server-side Flash functionality allows you to optimize the way XenApp renders and delivers Adobe Flash

content to users. To display Flash content in sessions, you must have the Flash plug-in and the corresponding ActiveX

control installed in the Web browser before you publish it.

Users playing Flash content in published applications might observe poor rendering quality of the animation, slow session

responsiveness, or a combination of both. This occurs when Adobe Flash Player, which renders the content on the server,

starts in high-quality mode by default. While this guarantees the highest possible rendering mode for each frame, it also

means that each frame consumes considerable bandwidth on its way to the user.

HDX MediaStream server-side Flash functionality improves the user’s session responsiveness by forcing the Flash Player to

use simpler graphics (for example, no smoothing or anti-aliasing). This feature also reduces the amount of processing power

that is required to render Flash content.

By default, HDX MediaStream server-side Flash functionality is enabled at the server farm level. However, if HDX

MediaStream client-side Flash functionality is enabled, server-side rendering is overridden.

1. Configure the Flash quality adjustment Citrix User policy setting with one of the following options:

Optimize Adobe Flash animation options for all connections. Select this option to always reduce the amount of Flash

data sent to users. The result is minimized CPU usage on the servers on which users are using Flash within Internet

Explorer.

Optimize Adobe Flash animation options for low bandwidth connections only. Select this option to improve

responsiveness when Flash content is sent to users on restricted bandwidth connections (under 150Kbps). On

restricted bandwidth connections, such as over a WAN, less data is downloaded and the quality of Flash content is

lower. When bandwidth is not limited, for example on a LAN, users get higher quality Flash animation.

Do not optimize Adobe Flash animation options. Select this option if bandwidth is not limited.

2. To reduce bandwidth consumption and improve video playback and server scalability, configure the Citrix Computer policy

setting for Queueing and tossing. Configuring this setting can cause animations to become choppy due to dropped

frames.

Optimizing Throughput of Image Files

The size of image files affects the amount of time the files take to travel from server to client. Often, image files contain

redundant or extraneous data that is of little benefit to the user and slows down the user’s session while downloading and

rendering. Using lossy image compression, SpeedScreen Image Acceleration lets you find a balance between the quality of

photographic image files as they appear on client devices and the amount of bandwidth the files consume on their way

from server to client.

SpeedScreen Image Acceleration applies a lossy compression scheme to reduce the size of image files that the server sends

to the client for faster throughput. The compression scheme removes redundant or extraneous data from the files while

attempting to minimize the loss of information. Under most circumstances, the data loss is minimal and its effect nominal.

However, Citrix recommends that you use discretion in applying this feature where preservation of image data may be vital,

as in the case, for example, of X-ray images.

This feature is enabled by default. Use policy settings to override the default settings and accommodate different userneeds by applying different levels of image compression to different connections.1. Configure the Lossy compression level Citrix User policy setting with one of the following options:

Level Image quality Bandwidth requirements

High Low Lowest


Medium (default) Good Lower

Low High Higher

None Same as original Highest

Level Image quality Bandwidth requirements

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.

Optimizing Display of Image Files

You can enable Progressive Display to increase the performance of displaying images or parts of images that are changing.

Progressive Display speeds the initial display of an image file by choosing an increased compression level while an image is

dynamic. This initial display is then sharpened up to normal quality in the background if the image is not immediately

changed or overwritten in the application. The quality of the final image is controlled by Image Acceleration.

Progressive Display can improve the performance not only of applications that render and display images, but also those

parts of an image that are dynamic, such as when scrolling through a PDF or similar document.

Configure the Progressive compression level Citrix User policy setting with the desired level (Low, Medium, High, Very high, or

Ultra high), and configure the Lossy compression level Citrix User policy setting to None.

Optimizing Keyboard and Mouse Responsiveness

SpeedScreen Latency Reduction is a collective term used to describe features such as Local Text Echo and Mouse ClickFeedback that help enhance user experience on a slow network.Mouse Click Feedback

On high latency connections, users often click the mouse multiple times because there is no visual feedback that a mouse

click resulted in an action. Mouse Click Feedback, which is enabled by default, changes the appearance of the pointer from

idle to busy after the user clicks a link, indicating that the system is processing the user’s request. When the user clicks the

mouse, the ICA software immediately changes the mouse pointer to an hourglass to show that the user’s input is being

processed. You can enable and disable Mouse Click Feedback at the server level.

Local Text Echo

On high latency connections, users often experience significant delays between when they enter text at the keyboard and

when it is echoed or displayed on the screen. When a user types text, the keystrokes are sent to the server, which renders

the fonts and returns the updated screen to the client. You can bridge the delay between keystroke and screen redraw by

enabling Local Text Echo. Local Text Echo temporarily uses client fonts to immediately display text a user types while the

screen redraw from the server is in transit.

By default, Local Text Echo is disabled. You can enable and disable this feature both at the server and application level. You

can also configure Local Text Echo settings for individual input f ields within an application.

Note: Applications that use non-standard Windows APIs for displaying text may not support Local Text 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: To run the Speedscreen Latency Reduction Manager with the User Account Control (UAC) enabled, you must be adomain administrator, delegated administrator, or part of the Administrators group on the local computer, or you will beprompted for administrator credentials.Through SpeedScreen Latency Reduction Manager, you can configure common SpeedScreen Latency Reduction settings

for all applications on a server or select custom settings for individual applications. Before you can configure any settings,

you must add the application.

Adjusting SpeedScreen Latency Reduction for an Application

If a published application exhibits abnormal behavior after it is configured to use SpeedScreen Latency Reduction, you can

use the Add New Application wizard included with SpeedScreen Latency Reduction Manager to adjust latency reduction

functionality for the selected application, or all instances of the selected application on the server. To optimize usability of

the application, use this wizard to adjust, turn on, or turn off SpeedScreen Latency Reduction for the application.

Note: The application must be running before you can use this wizard to modify existing settings.To adjust SpeedScreen Latency Reduction for an application

If a published application exhibits abnormal behavior after it is configured to use SpeedScreen Latency Reduction, you can

use the Add New Application wizard included with SpeedScreen Latency Reduction Manager to adjust latency reduction

functionality for the selected application, or all instances of the selected application on the server. To optimize usability of

the application, use this wizard to adjust, turn on, or turn off SpeedScreen Latency Reduction for the application.

Note: The application must be running before you can use this wizard to modify existing settings.Before you can adjust Speedscreen Latency Reduction for an application, you must add the application to the

Speedscreen Latency Reduction Manager.

1. From the Start menu, select All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager.

2. From the Applications menu of SpeedScreen Latency Reduction Manager, select New to start the wizard and follow the

prompts.

3. Use the Define the Application screen to select an application instance on the server. To specify the application, use one

of these methods:

Click the icon at the bottom of the page and drag the pointer onto the window of an application. The application

must be running when you select it.

Click the Browse button and navigate to the application.

4. Specify whether Local Text Echo is enabled or disabled on the application by selecting or clearing the Enable local text

echo for this application check box. For a definition of Local Text Echo, see "Optimizing Keyboard and Mouse


Responsiveness".

5. Specify whether the setting you selected in the previous step should be applied to all instances of the application on the

server or just the instance selected.

Test all aspects of an application with Local Text Echo in a non-production environment before enabling it to ensure that

the display is acceptable to users.

When you configure SpeedScreen Latency Reduction Manager on a particular server, the settings are saved in thess3config folder in the Citrix installation directory of that server. You can propagate the settings to other servers bycopying 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 toall installations of the selected application when configuring Local Text Echo through the wizard. Paths to publishedapplications might differ from one server to another; therefore, applying the settings to all instances of the selectedapplication ensures that the settings apply regardless of where the application is located on the destination server.To configure latency reduction settings for all applications on a server


2. From the Application menu, select Server Properties. The Server Properties dialog box containing existing settings for the

selected server appears.

3. Configure the SpeedScreen Latency Reduction settings that you want to be applied to all of the applications on the

server. All users connecting to the server benefit from the SpeedScreen options you set here. Changes made to

SpeedScreen Latency Reduction settings at an application level override any server-wide settings.

Enable local text echo as default for all applications on this server. Select this check box to enable Local Text Echo

for all applications on the server.

Enable mouse click feedback as default for all applications on this server. Select this check box to enable Mouse Click

Feedback for all applications on the server.

Latency threshold times for SpeedScreen (in milliseconds). Latency threshold times are used when the client device

setting for SpeedScreen is set to Auto.

High latency threshold. Specify a threshold value above which SpeedScreen options should be enabled.

Low latency threshold. Specify a threshold value below which SpeedScreen options should be disabled.

For a definition of Local Text Echo and Mouse Click Feedback, see— Optimizing Keyboard and Mouse Responsiveness

.

To configure custom latency reduction settings for an individual application


2. In the SpeedScreen Latency Reduction Manager, select the application.

3. From the Application menu, select Properties. The Application Properties tab containing existing SpeedScreen Latency

Reduction settings for the selected application appears. It contains this information:

Application Name. The application executable name appears here; for example, Excel.exe.

Path to Application. The path to the application executable appears here; for example, C:\Microsoft Office\Excel.exe.

4. If desired, configure application settings:

Disable local text echo for this application. The current setting for Local Text Echo is displayed. Select the check box

to disable Local Text Echo for this application. Clear the check box to enable it.

Limit local text echo for this application. The current Local Text Echo setting for the application appears. Select the

check box to limit Local Text Echo functionality for this application, and select the type of text display you need from

the drop-down list.

Forces Speedscreen to treat all input f ields in the selected application in native mode. Select the check box if you


configure a setting that forces SpeedScreen to treat all input f ields in the selected application in native mode.

To configure latency reduction settings for input fields in an application

Input fields in an application are fields where text can be added. You can use SpeedScreen Latency Reduction Manager to

set latency reduction behavior for selected input fields in a configured application to reduce delays between when users

enter text at the keyboard and when it is echoed or displayed on the screen.


2. Select an application.

3. From the Applications menu, select Properties. The Application Settings window appears.

4. Select the Input Field Configuration tab, then configure these settings as needed.

The Configured Input Field List displays the list of configured input f ields. SpeedScreen Latency Reduction uses a

window hierarchy to identify the input f ields that need special settings. The entries shown in the tree view are the

window class names of the configured f ields. 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 f ield. This wizard guides you

through the process of configuring SpeedScreen Latency Reduction settings for an input f ield.

Click Delete to delete the selected input f ield from the Configured Input Field List.

Enable local text echo for this input f ield enables Local Text Echo. If this check box is selected, you can apply more

Local Text Echo settings to the selected f ield.

Limit local text echo forces behavior in input f ields 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 f loating bubble ensures text is echoed within a f loating bubble.

Reduce font size forces input f ields in non-standard applications to display text at a reduced font size. Use this

setting when input f ields in non-standard applications display misaligned text, oversized fonts, or other undesirable

font behavior. Choose the percentage by which to reduce the font size. Percentage values available are 10%, 20%,

and 30%.

Use system default colors forces non-standard input f ields to use system default colors. SpeedScreen Latency

Reduction tries to auto-detect the text and background colors used in input f ields; however, non-standard input

fields sometimes report incorrect or inadequate information. As a result, text echo in input f ields on nonstandard

applications can appear corrupted. This setting turns off auto-detection and controls how system default colors are

applied to input f ields.

Choose Both the text and background to apply system default colors to both text and background.

Choose The background only to apply system default colors only to the background.

Input f ield is a password controls how hidden characters are displayed in non-standard input f ields. Typically, hidden

characters are located in password entry f ields. Text echo in non-standard input f ields might make these hidden

characters appear as normal text, compromising security. This setting forces hidden characters to display as asterisks

or spaces.

Choose Hidden characters denoted by “*” if you want Local Text Echo for such input f ields to be replaced by

asterisks.

Choose Hidden characters denoted by spaces if you want Local Text Echo for password input f ields to be replaced

by spaces.

To create exception entries for non-standard input fields in an application


Some input fields do not conform to standard Windows behavior and thus do not work correctly with SpeedScreen

Latency Reduction. You can create exception entries for such fields, while still providing minimal latency reduction

functionality for the rest of the application. The Input Field Compatibility wizard included with SpeedScreen Latency

Reduction Manager guides you through the process of selecting non-standard input fields and creating exception entries

for them.

Note: The application must be running before you can configure an input f ield within it.1. Start the application.

2. Select Start > All Programs > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager.

3. From the Applications menu in SpeedScreen Latency Reduction Manager, select Properties. The Application Settings

window appears.

4. Select the Input Field Configuration tab. Click New to start the wizard and follow the prompts.

5. With the application running, select the input f ield you want to configure and complete these steps:

1. Drag the pointer onto the input f ield window for which SpeedScreen behavior needs to be customized.

2. If the SpeedScreen Latency Reduction Manager window is obscuring the target input f ield, check the Hide

SpeedScreen Latency Reduction Manager check box. This causes the SpeedScreen Latency Reduction Manager

window to be hidden from view.

6. To define the level of compatibility for the input f ield, select the level of SpeedScreen Latency Reduction compatibility

to apply to the selected input f ield. Use the slider bar to select the desired compatibility level. The default compatibility

level is Auto, which provides full SpeedScreen Latency Reduction functionality. However, because the f ield 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 f ields that are incompatible with the default Auto

setting. Text echo appears in place with limited acceleration.

Low Compatibility. If an input f ield is incompatible with both the Auto and Medium compatibility settings, select Low.

Text echo appears in a f loating text bubble rather than within the input f ield.

Off , or Zero Compatibility. If an input f ield is incompatible with Auto, Medium, and Low compatibility settings, disable

Local Text Echo for that f ield by selecting Off .

Configuring HDX Broadcast Display Settings

To configure HDX Broadcast display settings

1. To improve the response when graphics are sent to the client, configure the Citrix Computer policy Queueing and tossing

setting. Queued images that are replaced by another image are discarded. This is useful when bandwidth is limited. A

drawback to selecting this option is that it can cause animations to become choppy because intermediate frames get

dropped.

2. To make scrolling smoother because sections of an image can be retrieved from the cache, configure the Citrix

Computer policy Image caching setting.

3. Enter the maximum memory to be used on the server for each client connection with the Citrix Computer policy Display

memory limit setting.

You can specify an amount in kilobytes from 300 to 65536. Using more color depth and higher resolution for connections

requires more memory. You can calculate the maximum memory required by using this equation:

(color depth in bits per pixel / 8) * vertical resolution in pixels * horizontal resolution in pixels = memory required in bytes

For example, if the color depth is 24, the vertical resolution is 600, and the horizontal resolution is 800, the maximum

memory required is:


(24bpp / 8) * 600 pixels * 800 pixels = 1440000 bytes of memory required

You can specify 1440KB in maximum memory to handle connections with these settings.

4. For the Citrix Computer policy Display mode degrade preference setting, configure one of the following options:

Degrade color depth f irst. Select this option if you want color depth to be reduced before resolution is lowered when

the session memory limit is reached.

Degrade resolution f irst. Select this option if you want resolution to be lowered before color depth when the session

memory limit is reached.

5. To display a brief explanation to the user when a session is degraded, configure the Citrix Computer policy Notify user

when display mode is degraded setting. Possible reasons for degradation include exceeding the memory limit and

connecting with a client that cannot support the requested parameters.


Securing Server Farms

May 06, 2015

Consult with your organization’s security experts for a comprehensive security strategy that best fits your needs.

The Citrix XenApp plug-ins are compatible with and function in environments where the Microsoft Specialized Security -

Limited Functionality (SSLF) desktop security template is used. These templates are supported in the Microsoft Windows

XP and Vista platforms. Refer to the Windows XP and Windows Vista security guides available at

http://technet.microsoft.com for more information about the template and related settings.

Securing Access to Your Servers

Updated: 2015-04-29

An important first step in securing your server farm is securing access to the servers.

Securing the Delivery Services Console

You can use the Delivery Services Console to connect to any server in your farm. Use it only in environments where packet

sniffing cannot occur. Also, ensure that only administrators can access it. You can set NTFS permissions so that non-

administrators do not have Execute permission for the console executable.

Using NTFS partitions

To ensure that appropriate access control can be enforced on all files installed by XenApp, install XenApp only on NTFS-

formatted disk partitions.

Trusted Server Configuration

This feature identifies and enforces trust relations involved in client connections. This can be used to increase the

confidence of client administrators and users in the integrity of data on client devices and to prevent the malicious use of

client connections. When this feature is enabled, clients can specify the requirements for trust and determine whether or

not they trust a connection to the server.

Securing the Data Store

Protecting the data store involves not only protecting the data in the data store database but also restricting who canaccess 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 allservers configured with that account. To reconfigure the Citrix IMA Service password, use the dsmaint config command oneach affected server. Be sure to create a backup of your data store before changing the password on your data store.Consult the database vendor documentation for more information.

Microsoft SQL Server

http://technet.microsoft.com


The user account that is used to access the data store on Microsoft SQL Server has public and db_owner roles on the

server and database. System administrator account credentials are not needed for data store access; do not use a system

administrator account because this poses an additional security risk.

If the Microsoft SQL Server is configured for mixed mode security, meaning that you can use either Microsoft SQL Serverauthentication or Windows authentication, you may want to create a Microsoft SQL Server user account for the solepurpose 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 initialinstallation of the database with db_owner permission. Changing the user account’s permission from db_owner may causeproblems installing future service packs or feature releases for XenApp. Be sure to change the account permission back todb_owner before installing a XenApp service pack or feature release.

Microsoft SQL Server Express

Windows authentication is supported for the Microsoft SQL Server Express database. For security reasons, Microsoft SQL

Server authentication is not supported. The user name and password typically are those for the local system administrator

account. If users have access to the data store server, change the password with the 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.

Using the Secure Gateway

Use the Secure Gateway to provide SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled

client, combined with encryption of the HTTP communication between the Web browser and the Web server. Using the

Secure Gateway makes firewall traversal easier and improves security by providing a single point of entry and secure access

to your server farms.

In general, use the Secure Gateway when:You want to hide internal IP addresses

You want to secure public access to your farm’s servers

You need two-factor authentication (in conjunction with the Web Interface)

Using the Secure Gateway provides the following benefits:Secure Internet access

Removes the need to publish the addresses of every server running XenApp

Simplif ies server certif icate management

Allows a single point of encryption and access to the servers

Use the Secure Gateway to create a gateway that is separate from the computers running XenApp. Establishing the

gateway simplifies firewall traversal because ICA traffic is routed through a widely accepted port for passage in and out of

firewalls. The Secure Gateway provides increased scalability.

However, because ICA communication is encrypted only between the client and the gateway, you may want to use SSL

Relay to secure the traffic between the gateway and the servers running XenApp, including the servers hosting the Citrix

XML Service.


For more information, see the Secure Gateway for Windows administrator documentation.

Using the Secure Ticket Authority

The Secure Ticket Authority (STA) is responsible for issuing session tickets in response to connection requests for published

resources on XenApp. These session tickets form the basis of authentication and authorization for access to published

resources.

When you install XenApp, you also install the STA. The STA is embedded within the Citrix XML Service.Important: If you are securing communications between the Secure Gateway and the STA, ensure that you install a servercertif icate on the server running the STA and implement SSL Relay. In most cases, internally generated certif icates are usedfor this purpose.

To display STA performance statistics

1. Access the Performance Monitor.

2. Right-click in the right pane and click Add Counters.

3. For the location of the performance counters, select Use local computer counters.

4. From the Performance Object drop-down list, select Secure Ticket Authority.

5. Select the performance counters you want to monitor and click Add.

6. Click Close.

7. Use the Windows Performance Console controls that appear at the top of the right pane to switch views and add

counters.

Identifying Entries in the STA Log

The STA logs fatal errors to its application log, which is located in the \inetpub\scripts directory. When creating a log, the

STA uses the following format for naming log files:

stayyyymmdd-xxx.log where yyyy is the year, mm is the month, and dd is the day of the log file creation.

The first time the STA is loaded, it creates a log file.

To view entries in the STA log, use a plain-text editor to open the log file.

If the STA does not create a log file, it may be due to lack of write privileges to the \inetpub\scripts directory.


Securing Client-Server Communications

Apr 29, 2015

There are two methods for encrypting the session data transmitted between clients and servers: SecureICA and SSL/TLS

encryption.

By default, all ICA communications are set to Basic ICA protocol encryption. The Basic setting obfuscates data but does

not provide industry standard encryption. You can increase the level of SecureICA encryption up to 128-bit and/or add

SSL/TLS encryption.

The difference between the two types of client-server encryption is as follows:

SecureICA. The SecureICA feature encrypts the session data sent between a server running XenApp and a client. In

general, increase the level of ICA protocol encryption when you want to encrypt internal communication within a LAN or

a WAN, or you want to encrypt internal access to an intranet. Increasing the level of ICA protocol encryption prevents

session data from being sent in clear text, but it does not perform any authentication.

SSL/TLS protocols. SSL/TLS protocols can protect you from internal and external threats, depending on your network

configuration. Citrix recommends that you enable SSL/TLS protocols. Enabling SSL/TLS ensures the confidentiality,

authentication, and integrity of session data.

If you enable protection against both internal and external threats, you must enable SSL encryption. Using SecureICA with

SSL or TLS provides end-to-end encryption.

Both protocols are enabled on the server side, when you publish an application or resource. The Web Interface and Citrix

online plug-in automatically detect and use the settings specified on the server (that is, when you publish a resource).


Windows operating system. If a higher priority encryption level is set on either a server or client device, settings you specify

for published resources can be overridden. The most secure setting out of any of the settings below is used:

The setting in Remote Desktop Server Configuration

The XenApp policy setting that applies to the connection

The client-server setting (that is, the level you set when you publish a resource)

The Microsoft Group Policy

When you set an encryption level, make sure that it is consistent with the encryption settings you specified elsewhere. For

example, any encryption setting you specify in the TSCC or connection policies cannot be higher than the application

publishing setting.

If the encryption level for an application is lower than what you specified through the TSCC and connection policies, the

TSCC settings and the policies override the application settings.

Using SecureICA

Updated: 2015-04-29

By default, client-server communications are obfuscated at a basic level through the SecureICA feature, which can be used

to encrypt the ICA protocol.

Plug-ins use the ICA protocol to encode user input (keystrokes and mouse clicks) and address it to a server farm for


processing. Server farms use the ICA protocol to format application output (display and audio) and return it to the client

device.

You can increase the level of encryption for the ICA protocol when you publish a resource or after you publish a resource.

In addition to situations when you want to protect against internal security threats, such as eavesdropping, you may want

to use ICA encryption in the following situations:

You need to secure communications from devices that use Microsoft DOS or run on Win16 systems

You have older devices running plug-in software that cannot be upgraded to use SSL

As an alternative to SSL/TLS encryption, when there is no risk of a “man-in-the-middle” attack

When traversing public networks, Citrix does not recommend SecureICA as your only method of encryption. Citrix

recommends using SSL/TLS encryption for traversing public networks. Unlike SSL/TLS encryption, SecureICA, used on its

own, does not provide authentication of the server. Therefore information could be intercepted as it crosses a public

network and then be rerouted to a counterfeit server. Also, SecureICA does not check data integrity.

Enabling SSL/TLS Protocols

If client devices in your environment communicate with your farm across the Internet, Citrix recommends enabling SSL/TLS

encryption when you publish a resource. If you want to use SSL/TLS encryption, you must use either the SSL Relay feature

or the Secure Gateway to relay ICA traffic to the computer running XenApp.

The nature of your environment may determine the way in which you enable SSL:

For client devices communicating with your farm remotely, Citrix recommends that you use the Secure Gateway to pass

client communications to the computer running XenApp. The Secure Gateway can be used with SSL Relay on the

computer running XenApp to secure the Secure Gateway to XenApp traff ic, 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 f irewall and place your farm behind the f irewall

Use the SSL Relay feature to secure the traff ic between servers in your farm

In larger environments, it may not be convenient to use SSL Relay because doing so requires storing certificates on every

server in your farm. In large environments, you may want to use the Secure Gateway with an internal firewall if you are

concerned with internal threats.

Regardless of whether you use the Secure Gateway or SSL Relay, if you want to use SSL, you must select the Enable SSL

and TLS protocols setting when you publish an application.

If you are using Web Interface with the Secure Gateway, see the information about SSL in the Secure Gateway and Web

Interface administrator documentation.

To configure session data encryption

The following procedure explains how to increase the level of encryption by enabling SecureICA (ICA protocol encryption)

or SSL/TLS (Secure Sockets Layer and Transport Layer Security) encryption after you publish an application.

1. From the Delivery Services Console, select a published application in the left pane.

2. From the Action menu, select Application properties.

3. In the Application Properties dialog box, select Advanced > Client options.

4. In the Connection encryption section, select one or more of the following:


Select the Enable SSL and TLS protocols check box. This option requests the use of the SSL and TLS protocols for

clients connecting to the published application.

In the Encryption section, select a higher level of encryption from the drop-down list box.

If you are using SecureICA and you want to ensure that ICA traffic is always encrypted at a certain level, you can set a

policy for encryption. Creating a SecureICA policy prevents you from accidentally publishing a resource at a lower level of

encryption. If this policy is enabled and you publish a resource at a lower level of encryption than the policy requires, the

server rejects client connections. For plug-ins that take their encryption settings from the server, such as the Web Interface

and the Citrix online plug-in, this can be problematic.

Therefore, Citrix recommends as a best practice, that if you enable an encryption policy, you publish applications (or

resources) by replicating an existing published application and editing it so as to replace the application with the new

application you want to publish.

To set a policy for ICA encryption


Windows operating system. If a higher priority encryption level is set on either a server or client device, settings you specify

for published resources can be overridden.

SecureICA does not perform authentication or check data integrity. To provide end-to-end encryption for your server farm,

use SecureICA with SSL/TLS encryption. SecureICA does not use FIPS-compliant algorithms. If this is an issue, configure the

server and plug-ins to avoid using SecureICA.

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.




Configuring SSL/TLS Between Servers and Clients

Apr 29, 2015

For XenApp to accept connections encrypted with SSL or TLS, you must use SSL Relay to configure support on each

XenApp server.

Citrix SSL Relay can secure communications between clients, servers running the Web Interface, and XenApp servers that

are using SSL or TLS. Data sent between the two computers is decrypted by the SSL Relay and then redirected using

SOCKSv5 to the Citrix XML Service.

SSL Relay operates as an intermediary in the communications between the plug-in and the Citrix XML Service running on

each server. Each plug-in authenticates the SSL Relay by checking the relay’s server certificate against a list of trusted

certificate authorities. After this authentication, the plug-in and SSL Relay negotiate requests in encrypted form. SSL Relay

decrypts the requests and passes them to the server.

When returning the information to the plug-in, the server sends all information through SSL Relay, which encrypts the data

and forwards it to the client to be decrypted. Message integrity checks verify that each communication is not tampered

with.

In general, use SSL Relay for SSL/TLS support when you:Want to secure communications with servers that host the Citrix XML Service.

Have a small number of servers to support (f ive or fewer). To use SSL/TLS to protect against internal threats in larger

farms, consider configuring SSL/TLS support with Secure Gateway.

Do not need to secure access at a DMZ.

Do not need to hide server IP addresses or you are using Network Address Translation (NAT).

Need end-to-end encryption of data between clients and servers.

Configure SSL Relay and the appropriate server certificate on each XenApp server in the server farm. By default, SSL Relay is

installed with XenApp in C:\Program Files (x86)\Citrix\SSLRelay, where C is the drive where you installed XenApp.

The Citrix XML Service provides an HTTP interface for enumerating applications available on the server. It uses TCP packets

instead of UDP, which allows connections to work across most firewalls. The Citrix XML Service is included in the server. The

default port for the Citrix XML Service is 80.

Installing and Configuring the SSL Relay Tool

If you configure the SSL Relay tool with the User Account Control (UAC) feature of Microsoft Windows enabled, you mightbe prompted for administrator credentials. To run the SSL Relay tool, you must have the following privileges and associatedpermissions:

Domain administrator

Delegated administrator

Administrator group of the local computer where you are installing the tool

Obtaining and Installing Server and Root SSL Certificates

A separate server certificate is required for each XenApp server on which you want to configure SSL or TLS. The server

certificate identifies a specific computer, so you must know the fully qualified domain name (FQDN) of each server.

Certificates must be signed by a trusted entity called a Certificate Authority (CA). In addition to installing a server certificate

on each server, you must install the root certificate from the same CA on each client device that will communicate with SSL


Relay.

Root certificates are available from the same CAs that issue the server certificates. You can install server and client

certificates from a CA that is bundled with your operating system, an enterprise CA (a CA that your organization makes

accessible to you), or a CA not bundled with your operating system. Consult your organization’s security team to find out

which of the following methods they require for obtaining certificates.

Install the server certificate on each server. SSL Relay uses the same registry-based certificate store as IIS, so you can install

certificates using IIS or the Microsoft Management Console (MMC) Certificate Snap-in. When you receive a certificate from

the CA, you can restart the Web Server Certificate wizard in IIS and the wizard will install the certificate. Alternatively, you

can view and import certificates on the computer using the MMC and adding the certificate as a stand-alone snap-in.

Choosing an SSL Certificate Authority

You can obtain and install certificates for your servers and client devices in the following ways:

Certif icates 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 certif icate from a bundled CA, double-click the certif icate f ile

and the Windows Certif icate Store wizard installs the server certif icate on your server. For information about which

operating systems include native support, see your Microsoft documentation.

Certif icates 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 certif icate f ile and the Windows Certif icate Store wizard installs the server certif icate on your

server. For more information about whether or not your company uses an enterprise CA, consult your security team.

Certif icates from a CA not bundled with the operating system. Certif icates 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 certif icates from an external CA, see the

documentation for the servers and clients in your configuration. Alternatively, you can install certif icates using Active

Directory or the IIS snap-in:

If your computers belong to an Active Directory server, you can install the certif icates using Active Directory. For

instructions about how to use Active Directory to install your certif icates, see your Microsoft documentation.

You can use the Microsoft Web Server Certif icate wizard in the IIS snap-in to request and import a certif icate. For

more information about using this wizard, see your Microsoft documentation.

Acquiring a Signed SSL Certificate and Password

After you choose a Certif icate Authority (CA), generate a certif icate signing request (CSR) and send it to the CA using theWeb server software that is compatible with the CA. For example, if you are using the IIS snap-in to obtain yourcertif icates, you can use Microsoft Enterprise Certif icate Services to generate the CSR. The CA processes the request andreturns the signed SSL certif icate and password to you. For information about what software you can use to generate theCSR, consult the documentation for your chosen CA.Important: The common name for the certif icate must be the exact fully qualif ied 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.

To enable the SSL Relay and select the relay credentials

1. On the server where you installed Citrix SSL Relay, click All Programs > Citrix > Administration Tools > Citrix SSL Relay

Configuration Tool.

2. Click the Relay Credentials tab.

3. Select the Enable SSL relay check box to enable the relay features.


4. Select the Display Friendly Name check box to display the certif icate’s friendly name, if available.

This check box determines which information from the certificate appears in the Server Certificate list. Some certificates

contain an additional friendly name field. If you check this box and no friendly name exists, the certificate’s subject

common name is used (which is typically the server name). If Display Friendly Name is not checked, the entire subject

name is used.

5. Select the server certif icate from the Server Certif icate drop-down box (used to identify the SSL Relay identity).

Using the SSL Relay with the Microsoft Internet Information Service (IIS)

To use the SSL Relay and Microsoft Internet Information Services (IIS) on the same server, for example, if you install the

Web Interface and XenApp on the same server, you must change the port number that IIS or the SSL Relay use. SSL Relay

uses TCP port 443, the standard port for SSL connections. Most firewalls open this port by default. Optionally, you can

configure the SSL Relay to use another port. Be sure that the port you choose is open on any firewalls between the client

devices and the server running the SSL Relay.

Microsoft IIS is installed by default on Windows Server 2003 and allocates port 443 for SSL connections. It is not installed

by default on Windows Server 2008. To run SSL Relay on a server running Windows Server 2003 or 2008 (with Web Server IIS

installed and enabled), you must:

Install a server certif icate on IIS before you change the port number. You can use the same server certif icate 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.

Configuring the Relay Port and Server Connection Settings

The SSL Relay relays packets only to the target computers listed on the Connection tab of the Citrix SSL Relay

Configuration Tool. By default, the SSL Relay is configured to relay packets only to the target computer on which the SSL

Relay is installed. You can add other computers in the same server farm for redundancy.

Use the Connection tab to configure the listener port and allowed destinations for the SSL Relay. The SSL Relay relays

packets only to the target computers listed on the Connection tab. The target server and port specified on your server

running the Web Interface or XenApp plug-in 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 certif icate is added, the default ICA and Citrix XML Service ports are added for the local computer.Relay Listening Port. The TCP port where SSL clients connect to the SSL Relay. The default port number is 443. If your

server has multiple IP addresses, this port is used on all of them. If you change this value, you must make the same

change on the client device. You may also need to open the port on any f irewalls between the client device and the SSL

Relay.

Encryption Standard. SSL Relay can be configured to use either SSL or TLS. The protocol that is required is configured

using the SSL Relay configuration tool.

Server Name. The fully qualif ied domain name (FQDN) of the server to which to relay the decrypted packets. If

certif icates are not configured, no servers are listed. If certif icates are configured, the FQDN of the server on which the

SSL Relay is running appears here.

Ports. The TCP ports where ICA and the Citrix XML Service are listening.


Important: If you change the default Citrix SSL Relay port, you must set SSLProxyHost to the new port number in the Citrixonline plug-in icaclient.adm file. For more information about plug-in settings, see the plug-in administrator documentation.

To modify the destination server list


Configuration Tool.

2. Click the Connection tab.

To add a server to the destination server list:

1. Click New.

2. Type the FQDN of the computer in the Server Name box. (Additional servers must also be specif ied in the

configuration of servers running the Web Interface.)

3. Type the port number of the Citrix XML Service in the Destination ports box and click Add.

To change the port for a server listed in the destination server list:

1. Select the server entry and click Edit.

2. In the Target Server Properties dialog box, select a destination port to remove and click Delete.

3. In the f ield below Destination ports, type the number of the new destination port and click Add.

To run the SSL Relay on port 443 without using HTTPS

1. Stop the Microsoft Internet Information Service.

2. Configure and start the SSL Relay service.

3. Restart the Microsoft Internet Information Service.

The SSL Relay uses port 443 before IIS, including when the server is restarted.Note: When you configure XenApp, members of the User group are allowed to edit registry entries in the registry hiveHKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Secure\Citrix\Citrix SSL Relay, orHKEY_LOCAL_MACHINE\SOFTWARE\Secure\Citrix\Citrix SSL Relay on XenApp, 32-bit Edition. You can use the MicrosoftSecurity 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 online plug-in). The Ciphersuites dialog box lists the available and

allowed ciphersuites. The SSL Relay accepts connections only from clients that support at least one of the allowed

ciphersuites. Installing additional ciphersuites is not supported.

Available ciphersuites are grouped into GOV (Government) or COM (Commercial). Note that GOV ciphersuites are normally

used when TLS is specified. However, any combination of ciphersuite and security protocol can be used. Contact your

organization’s security expert for guidance about which ciphersuites to use.

Descriptions of ciphersuites are found in Appendix C of the Internet Society RFC 2246, available online at http://www.rfc-

editor.org.

By default, connections using any of the supported ciphersuites are allowed.

To add or remove ciphersuites


Configuration Tool. Click the Ciphersuites tab.

2. Select a ciphersuite from either the left column and click Add to allow it or from the right column and click Remove to

disallow it.

http://www.rfc-editor.org



Securing Network Communications

Apr 29, 2015

Network communication between servers and client devices can be a security risk in any enterprise environment. In addition

to physically securing servers, most organizations install network security measures including firewalls to isolate servers

running XenApp and Web browsers from the Internet and publicly accessible networks. To deploy XenApp on internal

networks, secure communications between the client and server by means of SSL/TLS or other security measures.

Depending on your security needs, you can incorporate the following network communication security components whendesigning XenApp deployments:

At the client-server level inside your network:

By encrypting the Independent Computing Architecture (ICA) protocol using SecureICA

Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption

At the network level, when clients are communicating with your farm remotely across the Internet:

Secure Gateway

Secure Ticket Authority

Network f irewalls

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.

Configuring TCP Ports

This table lists the TCP/IP ports that the servers, Citrix online plug-in, IMA Service, and other Citrix services use in a serverfarm. This information can help you configure f irewalls and troubleshoot port conflicts with other software.

Communication Default port Conf iguration

Delivery Services Console/AccessManagement Console

135 Not configurable

Citrix SSL Relay 443 See— Using the SSL Relay with the Microsoft Internet InformationServer (IIS)

Citrix XML Service 80 See— Installing and Configuring XenApp

Client-to-server (directed UDP) 1604 Not configurable

ICA sessions (clients to servers) 1494 See— XenApp Command Reference

for information about using the ICAPORT command

Citrix Vendor Daemon 7279 See— Licensing Your Product

License Management Console 8082 See— Licensing Your Product


Server to license server 27000 In the console, open the farm or server properties page,and select License Server

Server to Microsoft SQL Server orOracle server

139, 1433, or 443for MS-SQL

See the documentation for the database software

Server to server 2512 See— XenApp Command Reference

for information about using the IMAPORT command

Session reliability 2598 See— Configuring Session Reliability

Communication Default port Conf iguration

Using Proxy Servers

A proxy server accepts connection requests from client devices and redirects those requests to the appropriate XenApp

servers. Using a proxy server, much like using a firewall, gives you more control over access to the XenApp servers and

provides a heightened level of security for your network. A proxy server, as opposed to a firewall, uses a different port from

that used by the XenApp servers.

For information about using proxy servers with the XenApp plug-ins, see the Citrix online plug-in documentation.

Supported proxy servers are:Microsoft Internet Security and Acceleration (ISA) Server 2004 and 2006

iPlanet Web Proxy Server 3.6

Squid 2.6 STABLE 4

Microsoft Proxy Server 2.0

Configuring Authentication for Workspace Control

If users log on using smart cards or pass-through authentication, you must set up a trust relationship between the server

running the Web Interface and any server in the farm that the Web Interface accesses for published applications. Without

the trust relationship, the Disconnect, Reconnect, and Log Off (“Workspace Control”) commands fail for those users

logging on with smart card or pass-through authentication. For more information about Workspace Control, see— Ensuring Session Continuity for Mobile Workers

.

You do not need to set up a trust relationship if your users authenticate to the Web Interface or the Citrix online plug-in by

typing in their credentials.

To set up the trust relationship, configure the Citrix Computer policy Trust XML requests setting. The Citrix XML Service

communicates information about published applications among servers running the Web Interface and servers running

XenApp.

If you configure a server to trust requests sent to the Citrix XML Service, consider these factors:The trust relationship is not necessary unless you want to implement Workspace Control and your users log on using

smart cards or pass-through authentication.

Enable the trust relationship only on servers directly contacted by the Web Interface. These servers are listed in the Web

Interface Console.

When you set up the trust relationship, you depend on the Web Interface server to authenticate the user. To avoid

security risks, use SSL Relay, IPSec, f irewalls, 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, f irewalls, or other security technology, it is

possible for any network device to disconnect or terminate client sessions.

Configure SSL Relay, IPSec, f irewalls, or other technology that you use to secure the environment so that they restrict

access to the Citrix XML Service to only the Web Interface servers. For example, if the Citrix XML Service is sharing a port

with IIS, you can use the IP address restriction capability in IIS to restrict access to the Citrix XML Service.


Using Smart Cards with XenApp

May 08 , 2015

You can use smart cards in your XenApp environment. Smart cards are small plastic cards with embedded computer chips.

In a XenApp environment, smart cards can be used to:Authenticate users to networks and computers

Secure channel communications over a network

Use digital signatures for signing content

If you are using smart cards for secure network authentication, your users can authenticate to applications and content

published on servers. In addition, smart card functionality within these published applications is also supported.

For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a

smart card reader attached to the client device to log on to the server. After users are authenticated to the application,

they can digitally sign email using certificates stored on their smart cards.

Citrix has tested smart cards that meet Standard 7816 of the International Organization for Standardization (ISO) forcards with electrical contacts (known as a contact card) that interface with a computer system through a smart cardreader device. The 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 islaunched, users must disconnect and relaunch the ICA session to use the smart card inside the session. Refer to CTX132230for details.Citrix supports the use of PC/SC-based cryptographic smart cards. These cards include support for cryptographic

operations such as digital signatures and encryption. Cryptographic cards are designed to allow secure storage of private

keys such as those used in Public Key Infrastructure (PKI) security systems. These cards perform the actual cryptographic

functions on the smart card itself, meaning the private key and digital certificates never leave the card.

In addition, Citrix supports two-factor authentication for increased security. Instead of merely presenting the smart card(one factor) to conduct a transaction, a user-defined PIN (a second factor), known only to the user, is employed to provethat 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 functionalspecif ication 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.

The following components are required on the server:PC/SC software

Cryptographic Service Provider (CSP) software

These components are required on the device running the supported Citrix plug-in:PC/SC software

Smart card reader software drivers

Smart card reader



Your Windows server and client operating systems may come with PC/SC, CSP, or smart card reader drivers already present.

See your smart card vendor for information about whether these software components are supported or must be replaced

with vendor-specific software.

You do not need to attach the smart card reader to your server during CSP software installation if you can install the smart

card reader driver portion separately from the CSP portion.

If you are using pass-through authentication to pass credentials from your client device to the smart card server session,

CSP software must be present on the client device.

A complete and secure smart card solution can be complex and Citrix recommends that you consult your smart card vendor

or integrator for details. Configuration of smart card implementations and configuration of third-party security systems,

such as certificate authorities, are beyond the scope of this documentation.

Smart cards are supported for authenticating users to published applications or for use within published applications that

offer smart card functionality. Only the former is enabled by default upon installation of XenApp.

The following XenApp clients and plug-ins support smart cards:Citrix online plug-in

Client for Linux

Client for Windows-based terminals

Client for MacIntosh

To configure smart card support for users of these plug-ins and clients, see the plug-in or client documentation.


Configuring Kerberos Logon

May 25, 2010

The Citrix online plug-in features enhanced security for pass-through authentication. Rather than sending user passwords

over the network, pass-through authentication leverages Kerberos authentication. Kerberos is an industry-standard

network authentication protocol built into the Windows operating systems. Kerberos logon offers security-minded users

the convenience of pass-through authentication combined with secret-key cryptography and data integrity provided by

industry-standard network security solutions.

Kerberos logon works only between clients and servers that belong to the same or to trusted Windows domains. Servers

must also be trusted for delegation, an option you configure through the Active Directory Users and Computers

management tool.

Kerberos logon is not available:If you use the following Remote Desktop Services options:

Use standard Windows authentication

Always use the following logon information or Always prompt for password

If you route connections through Secure Gateway

If the server running XenApp requires smart card logon

Kerberos requires Citrix XML Service DNS address resolution to be enabled for the server farm or reverse DNS resolution to

be enabled for the Active Directory domain.

The User Access Control feature prompts users to enter credentials when all of the following requirements are met:Kerberos logon is enabled on the server running XenApp

Users logging on to the computer running XenApp are members of the Administrator group on that computer

After logon, Administrator group users attempt to access network resources such as shared folders and printers

Windows supports two authentication protocols, Kerberos and NTLM, so Windows applications such as Windows Explorer,

Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, Microsoft Office, and others, can use Windows pass-

through authentication to access network resources without explicit user authentication prompts.

When Kerberos pass-through authentication is used to start a XenApp session, there are technical limitations that mayaffect application behavior.

Applications running on XenApp that depend on the NTLM protocol for authentication generate explicit user

authentication prompts or fail.

Most applications and network services that support Windows pass-through authentication accept both Kerberos and

NTLM protocols, but some do not. In addition, Kerberos does not operate across certain types of domain trust links in

which case applications automatically use the NTLM protocol. However the NTLM protocol does not operate in a

XenApp session that is started using the Kerberos pass-through authentication, preventing applications that cannot use

Kerberos from authenticating silently.

Kerberos pass-through authentication for applications expires if the XenApp session is left running for a very long time


(typically one week) without being disconnected and reconnected.

Kerberos is based on security tickets issued by domain controllers, which impose a maximum refresh period (typically one

week). When the maximum refresh period has ended, Windows obtains a new Kerberos ticket automatically by using the

cached network credentials that are required for the NTLM protocol. However these network credentials are not

available when the XenApp session was started using Kerberos pass-through authentication.

Configure the Citrix Computer policy DNS address resolution setting.

Caution: Using Registry Editor can cause serious problems that can require you to reinstall the operating system. Citrixcannot guarantee that problems resulting from incorrect use of Registry Editor can be solved. Use Registry Editor at yourown risk.To prevent Kerberos authentication for users on a specific server, create the following registry key as a DWORD Value on

the server:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon\ DisableSSPI = 1

You can configure the Citrix online plug-ins to use Kerberos with or without pass-through authentication.


Logging Administrative Changes to a XenApp Farm

Apr 29, 2015

The Configuration Logging feature allows you to keep track of administrative changes made to your server farm

environment. By generating the reports that this feature makes available, you can determine what changes were made to

your server farm, when they were made, and which administrators made them. This is especially useful when multiple

administrators are modifying the configuration of your server farm. It also facilitates the identification and, if necessary,

reversion of administrative changes that may be causing problems for the server farm.

When this feature is enabled for a licensed server farm, administrative changes initiated from the following componentslead to the creation of log entries in a central Configuration Logging database:

Delivery Services Console

some command-line utilities

tools custom built with SDKs

Before you enable the Configuration Logging feature:Determine the level of security and control you need over the configuration logs. This determines if you need to set up

additional database user accounts and if you want to make XenApp administrators enter credentials before clearing

logs.

Determine how strictly you want to log tasks; for example, if you want to log administrative tasks and if you want to

allow administrators to make changes to a farm if the task cannot be logged (for example, if the database is

disconnected).

Determine if you want to allow administrators to be able to clear configuration logs and if you want them to have to

supply credentials for this purpose. This requires the permission to Edit Configuration Logging settings.

Important: To securely store the credentials used for accessing the Configuration Logging database, you can enable theIMA encryption feature when you deploy your server farm. After this is enabled, however, you cannot disable it withoutlosing the data it encrypted. Citrix recommends that you configure IMA encryption before the Configuration Loggingfeature is configured and used.To enable the Configuration Logging feature:

Set up the Configuration Logging database

Define the Configuration Logging database access permissions

Configure the Configuration Logging database connection

Set the Configuration Logging properties

Delegate administrative permissions, as needed

The Configuration Logging feature, after it is properly enabled, runs in the background as administrative changes trigger

entries in the Configuration Logging database. The only activities that are initiated by the user are generating reports,

clearing the Configuration Logging database, and displaying the Configuration Logging properties.

To generate a configuration logging report, use the PowerShell command Get-CtxConfigurationLogReport. For more

information, see help for Get-CtxConfigurationLogReport or Windows PowerShell with Common Commands.

The Configuration Logging feature supports Microsoft SQL Server and Oracle databases; for information about supported

versions, see CTX114501.



The Configuration Logging database must be set up before Configuration Logging can be enabled. Only one Configuration

Logging database is supported per server farm, regardless of how many domains are in the farm. When the Configuration

Logging database is set up, you also must ensure that the appropriate database permissions are provided for XenApp so

that it can create the database tables and stored procedures (preceded by “CtxLog_AdminTask_”) needed for

Configuration Logging. Do this by creating a database user who has “ddl_admin” or “db_owner” permissions for SQL Server,

or a user who has the "connect" and "resource" roles and "unlimited tablespace" system privilege for Oracle. This is used to

provide XenApp full access to the Configuration Logging data.

The Configuration Logging feature does not allow you to use a blank password to connect to the Configuration Logging

database.

Each server in the server farm must have access to the Configuration Logging database.

Considerations for SQL Server

Only one server farm is supported per Configuration Logging database. To store Configuration Logging information for a

second farm, create a second Configuration Logging database.

When using Windows Integrated Authentication, only fully qualified domain logons are valid. Local user account credentials

will fail to authenticate on the database server that hosts the Configuration Logging database.

Ensure that all Citrix administrators accessing the same farm are configured to use the same default schema. The database

user who will create the Configuration Logging tables and stored procedures must be the owner of the default schema. If

you are using dbo as the default schema, the database user must have db_owner permissions. If you are using ddl_admin as

the default schema, the database user must have ddl_admin permissions.

See the SQL Server documentation for information about managing and using schemas.

Considerations for Oracle

Only one farm is supported per schema. To store Configuration Logging information for a second farm in the same

database instance, use a different schema. Tables and stored procedures are created in the schema associated with the

user who initially configured the Configuration Logging feature. For information about managing and using a different

schema, see the Oracle documentation.

Important: To use an Oracle database for configuration logging, the 32-bit Oracle client must be installed on the DeliveryServices Console.Before running the Delivery Services Console, update the Oracle tnsnames.ora client file to include the connectivity

information needed to access the available databases.

The first time the Configuration Logging feature is enabled, it connects to the Configuration Logging database and

discovers that the database schema does not exist. XenApp then creates the database schema, tables, and stored

procedures. To create a database schema, XenApp needs full access to the database. After the database schema is

created, full access is no longer necessary and you have the option of creating additional users with fewer permissions.

The following table lists the minimum permissions required to perform the Configuration Logging tasks.

Conf iguration Logging task Database permissions needed


To create log entries in the

database tables

INSERT for the database tables

EXECUTE for the stored procedures

SELECT

SQL Server: for sysobjects and sysusers

Oracle: for sys.all_objects, and for sequence objects and the "create

session" system privilege

To clear the log DELETE/INSERT for the database tables

EXECUTE for the GetFarmData stored procedure

SELECT

SQL Server: for sysobjects and sysusers



To create a report EXECUTE for the Configuration Logging stored procedures

SELECT

SQL Sever: for sysobjects and sysusers



Conf iguration Logging task Database permissions needed

The Configuration Logging components must have access to the GetFarmData stored procedure to find out if a

Configuration Logging database is associated with a farm. If you do not have permission to execute an existing

GetFarmData stored procedure, this farm is invisible to the Configuration Logging components.

Considerations for SQL Server

Before you configure the Configuration Logging database connection, grant EXECUTE permission to the sp_databases

system stored procedure to list the databases on the database server.

The authentication mode must be the same for the database user who creates log entries in the database tables and the

database user who clears the log.

After the Configuration Logging database is set up by your database administrator and the appropriate database

credentials are provided to XenApp, use the Configuration Logging Database wizard to configure the connection to the

database.

1. From the Delivery Services Console, select a farm.

2. From the Action menu, select Farm properties.

3. Click Configuration Logging.

4. Click Configure Database. The wizard opens.

5. Select the connection type (SQL Server or Oracle). For SQL Server, use the drop-down list to select a SQL Server; for

Oracle, select a net service name (from the Oracle tnsnames.ora client f ile). You can also type the entry.

6. (SQL Server only). Select an authentication mode: Windows integrated security (recommended) or SQL Server

authentication.


7. Enter a valid user name and password for the database. Credentials are always required (even if you are using Windows

Integrated Authentication with SQL Server). The credentials are stored using the IMA encryption feature. Each server

that creates log entries uses the credentials to connect to the Configuration Logging database.

8. (SQL Server only). Select or type the name of the database.

9. Configure connection options and connection pooling options. You can use the default values for these settings. (For

SQL Server, the possible exception is Use encryption. For security reasons, the default value is Yes; however, if the

database server to which you are connecting does not support encryption, the connection will fail. Click Test Database

Connection on the summary page to check for encryption support.)

10. Click Test Database Connection. A display indicates whether or not the connection established successfully.

After you configure the connection to the Configuration Logging database, you cannot set the database back to None. To

stop logging, clear the Log administrative tasks to Configuration Logging database check box in the Configuration Logging

dialog box.

Before you set Configuration Logging properties, configure the database and the connection to the database. Otherwise,the Configuration Logging property f ields are not active.Full Citrix administrators can edit the Configuration Logging settings and clear the log, or they can authorize other

administrators to perform these tasks by assigning them the delegated administration Edit Configuration Logging Settings

permission. Without this permission, ordinary administrators cannot perform these functions.

1. From the Delivery Services Console, select a farm.

2. From the Action menu, select Farm properties.

3. Click Configuration Logging.

4. To enable Configuration Logging, select the Log administrative tasks to Configuration Logging database check box. If

you want administrators to be able to make changes to the server farm when log entries cannot be saved to the

Configuration Logging database, select the Allow changes to the farm when logging database is disconnected check

box.

5. To prompt administrators to enter their credentials before clearing the log, select the Require administrators to enter

database credentials before clearing the log check box.

It may become necessary to clear the entries in the Configuration Logging database if the population of the tables

becomes too large.

To manage which database users can clear the configuration log, Citrix recommends that you enable the Require

administrators to enter database credentials before clearing the log check box in the Configuration Logging properties.

Anyone attempting to clear the log is prompted for database credentials.

The credentials must correspond to the authentication mode you selected when you connected to the database initially.Specif ically:

For SQL authentication, credentials with permissions for the Configuration Logging database on the SQL server are

required

For Windows Integrated authentication, XenApp impersonates the database user when it connects to the SQL

database, so credentials for the Windows user account are required

Use one of the following methods to clear log entries from the Configuration Logging database:


From the Delivery Services Console, expand the farm node and select 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.

Independent Management Architecture (IMA) is the underlying architecture used in XenApp for configuring, monitoring, and

operating all XenApp functions. The IMA data store stores all XenApp configurations.

IMA encryption protects administrative data used by Configuration Logging. This information is stored in the IMA data

store. For IT environments with heightened security requirements, using IMA encryption provides a higher degree of security

for Configuration Logging. One example would include environments that require strict separation of duties or where the

Citrix Administrator should not have direct access to the Configuration Logging database.

IMA encryption is a farm-wide setting that applies to all servers in the farm after encryption is enabled. Consequently, touse IMA encryption, you must enable it on all servers in the farm. IMA encryption has the following components:

Component Description

CTXKEYTOOL Also known as the IMA encryption utility, CTXKEYTOOL is a command-line utility you use to manageIMA encryption and generate key f iles. CTXKEYTOOL is in the Support folder of the XenApp media.

Key f ile The key f ile contains the encryption key used to encrypt sensitive IMA data. You create the key f ileusing CTXKEYTOOL. To preserve the integrity of the encryption, Citrix recommends that you keep thekey f ile in a secure location and that you do not freely distribute it.

Key The same valid IMA encryption key must be loaded on all servers in the farm if IMA encryption isenabled. After copying the key f ile to a server, you load the key by using CTXKEYTOOL.

Configuring IMA encryption includes the following tasks:On the f irst server in a farm (that is, the server on which you create the farm during XenApp configuration), generate a

key f ile, load the key, and enable it

Make the key f ile accessible to other servers in the farm or put it on a shared network location

Load the key onto other servers in the farm (that is, the servers that join the farm during configuration)

Citrix recommends that if you are enabling IMA encryption in environments that have multiple farms, you give the key for

each farm a different name.

Storing CTXKEYTOOL Locally

1. Copy the CTXKEYTOOL.exe f ile from the Support folder of XenApp media to your local computer.

2. Create a folder named Resource at the same level in your directory structure as the CTXKEYTOOL file.

3. Copy the entire Support\Resource\en folder to the new Resource folder.

You can store the CTXKEYTOOL.exe file and the Resource\en folder anywhere on your computer, provided you maintain

the same relative directory structure used on the media.

To generate a key and enable IMA encryption on the first server in a farm

Before enabling IMA encryption on the first server in the XenApp farm (that is, the server on which you created the farm),


install and configure XenApp, and restart the server.

1. On the server where you created the XenApp farm, run CTXKEYTOOL with the generate option, specifying the full UNC

or absolute path (including the f ile name of the key you want to generate) to the location where you want to store the

file key.

Citrix suggests naming the key after the farm on which it will be used; for example, farmakey.ctx. Citrix also suggests

saving the key to a folder that uses the name of your farm; for example, Farm A Key.

If the key file generates successfully, the message “Key successfully generated" appears.

2. To obtain the key from the f ile and put it in the correct location on the server, run CTXKEYTOOL with the load option

on the server on which you want to add the key, specifying the full UNC or absolute path (including the key f ile name) to

the location where you stored the key f ile. If the key loaded successfully, the message “Key successfully loaded”

appears.

3. Run CTXKEYTOOL with the newkey option to use the currently loaded key and enable the key. If IMA encryption is

enabled successfully, the message “The key for this farm has been replaced. IMA Encryption is enabled for this farm”

appears.

If you choose to store the key on a shared network location, Citrix recommends the following:Give the folder a meaningful name that specif ies the name of the farm for which the key was created. This is important

in situations when you follow the Citrix best practice recommendation of creating a unique key for the farm.

Ensure that the account you use to generate the key is the same as the account that will be used to configure all the

servers in the farm. You must use the same account for both tasks.

1. When you generate the key f ile, 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 f ile to the shared network

location.

3. Grant Read/Execute access to the key f ile for each server that will be joining the farm, and to the administrator

performing the installation.

To load a key on servers that join the farm

Before enabling IMA encryption on servers you are joining to a XenApp farm, install and configure XenApp, but do not

restart the server.

1. If you do not have the key f ile on a shared network location, load the key f ile to the server.

2. To obtain the key from the f ile and put it in the correct location on the server, run CTXKEYTOOL with the load option,

specifying the full UNC or absolute path (including the key f ile name) to the location where you stored the key f ile. 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 f irst server in the farm


Repeat this procedure on all servers you configure to join the farm.

If you move a server that has IMA encryption to a farm that has IMA encryption enabled, run CTXKEYTOOL with the load

option (specifying the key that was generated for the new farm) on that server is configured but before it is restarted.


If you move a server that has IMA encryption enabled to a farm that does not have IMA encryption enabled, IMA

encryption is disabled automatically on the server being moved.

Managing IMA Encryption

IMA encryption includes other features that you can use as needed:

Citrix strongly recommends backing up the farm key to a safe, secondary location, such as a CD, immediately after you

generate a key. You can create a copy of the key f ile when you create it, or you can back up the farm key by running

CTXKEYTOOL with the backup option.

You can recreate a key f ile 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 f ile by running CTXKEYTOOL with the backup option on any server in the farm that has the

key and is functioning properly.

You can disable IMA encryption by running CTXKEYTOOL with the disable option. Because IMA encryption is a farm-wide

feature, disabling it on one server disables the feature on all servers.

If you disable IMA encryption, to access the Configuration Logging database, you must reenter the password for the

Configuration Logging database. In addition, no configuration information is logged until you reenter your database

credentials.

To reenable IMA encryption after you disabled it, run CTXKEYTOOL with the enable option. After enabling IMA

encryption, Citrix recommends that you run CTXKEYTOOL with the query option to verify that IMA encryption is

enabled.

For more information about CTXKEYTOOL, see the— XenApp Command Reference

documentation.


XenApp Service Account Privileges

Jun 24 , 2011

These tables provide information about the services installed by default with XenApp, their accounts, associated

permissions, and privileges.

This table lists the display name for the service, which is the name that appears in the Services panel. When the display

name and the service name differ, the table provides service name in (parentheses). The Dependencies column in the table

lists the system components, such as Windows services, Citrix services, or drivers, on which the service depends. The

Dependencies column also includes subdependencies that might not appear on the Dependencies tab for the service.

Licensing services, which are not listed here, might also appear if the license server is installed on the same server as XenApp.

Display Name(Service Name)

Executable Logon Account /Startup Type

Description Dependencies

Citrix 64-bit VirtualMemoryOptimization

ctxsfosvc64.exe Local System/ Manual Dynamicallyoptimizes 64-bitapplications runningon a XenApp server.

None

Citrix Client Network(CdmService)

cdmsvc.exe Local System/Automatic

Maps client drivesand peripherals foraccess in sessions.

Client DriveMapping (CDM),WindowsManagementInstrumentationDriverExtensions,Workstation

Citrix CPU UtilizationMgmt/CPURebalancer(CTXCPUBal)

ctxcpubal.exe .\ctx_cpuuser/Manual Enhances resourcemanagement acrossmultiple CPUs.Installed only onservers that havemultiple CPUs.

None

Citrix CPU UtilizationMgmt/ResourceMgmt (ctxcpuSched)

ctxcpusched.exe Local System/ Manual Manages resourceconsumption toenforce entitlementpolicies.

RemoteProcedure Call(RPC)

Citrix DiagnosticFacility COM Server(CdfSvc)

CdfSvc.exe NT AUTHORITY\NetworkService/Automatic

Manages andcontrols diagnostictrace sessions, whichdiagnose problems



on a XenApp server.

Citrix EncryptionService

encsvc.exe NT AUTHORITY\ LocalService/ Automatic

Enables securecommunication withRC5 128-bitencryption betweenCitrix plug-ins andXenApp.

WindowsManagementInstrumentationDriverExtensions

Citrix End UserExperienceMonitoring (CitrixEUEM)

SemsService.exe Local Service/ Manual Collects and collatesend-user experiencemeasurements.

Citrix SMCSupport Driver

Citrix HealthMonitoring andRecovery(CitrixHealthMon)

HCAService.exe NT AUTHORITY\ LocalService/ Automatic

Provides healthmonitoring andrecovery services inthe event problemsoccur.

CitrixIndependentManagementArchitectureservice

Citrix IndependentManagementArchitecture(IMAService)

ImaSrv.exe NT AUTHORITY\NetworkService/Automatic

Providesmanagement servicesin the XenApp farm.

Citrix ServicesManagerservice, IPsecPolicy Agent,RemoteProcedure Call(RPC)m TCP/IPProtocol Driver,Server, WindowsManagementInstrumentationDriverExtensions,Workstation

Citrix MFCOMService (MFCom)

mfcom.exe NT AUTHORITY\NetworkService/Automatic

Provides COMservices that allowremote connectionsfrom themanagement tools.

RemoteProcedure Call(RPC), CitrixIndependentManagementArchitectureservice, CitrixServicesManager service

Citrix Print ManagerService (cpsvc)

CpSvc.exe Local Service/Automatic Manages thecreation of printersand driver usagewithin XenApp

Print Spooler,RemoteProcedure Call(RPC)





sessions. Supportsthe Citrix UniversalPrinting features.

Citrix SecureGateway Proxy(CtxSecGwy)

CtxSGSvc.exe NT AUTHORITY\Network Service/Automatic

Proxy to the CitrixSecure Gatewayserver.

None

Citrix ServicesManager(IMAAdvanceSrv)

IMAAdvanceSrv.exe Local System/Automatic

Provides XenAppwith an interface tothe operatingsystem. Otherservices use thisservices for elevatedoperations.

None

Citrix StreamingService (RadeSvc)

RadeSvc.exe .\Ctx_StreamingSvc/Automatic

Manages the Citrixoff line plug-in whenstreamingapplications.


Citrix Virtual MemoryOptimization

CTXSFOSvc.exe Local System /Manual Dynamicallyoptimizesapplications runningon a XenApp serverto free up servermemory.

None

Citrix WMI Service(CitrixWMIservice)

ctxwmisvc.exe NT AUTHORITY\ LocalService/Manual

Provides the CitrixWMI classes forinformation andmanagementpurposes.

CitrixIndependentManagementArchitectureservice , CitrixServicesManagerservice, IPsecPolicy Agent,RemoteProcedure Call(RPC), TCP/IPProtocol Driver,Server, WindowsManagementInstrumentationDriverExtensions,Workstation

Citrix XML Service ctxxmlss.exe Network Service Services XML data None





(CtxHttp) /Automatic requests sent byXenApp components

Citrix XTE Server(CitrixXTEServer)

XTE.exe NT AUTHORITY\NetworkService /Manual

Services networkrequests for sessionreliability and SSLfrom XenAppcomponents.

None




Caution: Citrix does not recommend altering account permissions and privileges. If you delete the accounts or alter theirpermissions incorrectly, XenApp might not function correctly.

This table lists the permissions associated with accounts XenApp services use.

Account Name Permissions Notes

Local Service Limited NT AUTHORITY\LocalService

Network Service Limited, network resources NT AUTHORITY\NetworkService

Local System Administrator NT AUTHORITY\System

Ctx_StreamingSvc Domain or local user Acts as a User

Ctx_ConfigMgr Domain or local user Acts as a Power User

Ctx_CpuUser Domain or local user Acts as a User

If your organization requires that service accounts run as domain accounts and not as local accounts, you can createdomain accounts to replace the Ctx_ConfigMgr and Ctx_CpuUser accounts before installing XenApp. Ensure the newaccount has the same privileges as the default account.

Privileges Local Service Network Service Ctx_Conf igMgr Ctx_CpuUser

Change the system time x x

Generate security audits x x

Increase quotas x x

Log on as a batch job x x x x


Log on as a service x x x x

Replace a process level token x x

Debug programs x

Increase scheduling priority x

Privileges Local Service Network Service Ctx_Conf igMgr Ctx_CpuUser

Citrix does not support changing the account for the Citrix Streaming Service (Ctx_StreamingSvc), which has the privileges:

log on as a batch job, log on as a service, backup files and directories, restore files and directories, deny log on locally, deny

remote log on, and take ownership of files or other objects.


Maintaining Server Farms

Apr 29, 2015

A server farm is a group of servers running Citrix XenApp and managed as a single entity. The servers in the server farm share

a single IMA-based data store.

Citrix recommends performing farm maintenance tasks from the data collector, assuming no applications are published on

the data collector, because this updates farm data faster. Performing farm maintenance tasks from a server hosting

published applications can slow down users trying to connect to published applications and take longer to update in the

data store.

The Delivery Services Console provides a wide variety of summary information about the farm and each server in the farm.

You can customize your view and group applications or servers in folders to make navigating through their console listings

easier. Folders are also useful for Object Based Delegated Administration. Grouping servers into folders can facilitate the

process of delegating administrative tasks to Citrix administrators.

From the Start menu, select All Programs > Citrix > Management Consoles and choose Citrix Delivery Services Console.

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 Delivery Services Console or the Local Group Policy Editor, depending on

whether or not you use Active Directory in your XenApp environment. Use these settings to maintain the farm, including

scheduling restarts, optimizing and monitoring server performance, and setting the port for the Citrix XML Service and

License Server. For more information, see the— Policy Settings Reference

.




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 specif ic hotfix applied to them.1. From the Delivery Services Console, 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 specif ic user is connected. Type a user name in the Name box.

Applications By User. Lists the applications that the specif ied user is using. Type a user name in the Name box.

Servers without hotfix. Lets you search for all of the servers missing a specif ic hotfix. This feature is useful if you want

to check that you applied a hotfix to all servers in your farm. Type a hotfix number in the Name box.

3. Use the Browse button to select one of the Citrix Resources locations to search in.

https://taas.citrix.com/?utm_source=eDocs&utm_medium=web&utm_campaign=edocs-xenapp-6-maintain-page


To perform administrator tasks on a server's desktop, you can access a server’s desktop only if the desktop of the selected

server is published. Configure connection settings to your servers through the Microsoft Management Console (MMC) using

Remote Desktop Server Configuration.

1. Configure the Citrix policies setting for Desktop launches to Allowed. If it is set to Prohibited, this feature fails.

2. From the Delivery Services Console, select a server.

3. In the Actions pane, select Other Tasks > Connect to server, and choose one of the following settings:

Connect to server’s published desktop

Connect directly to server's desktop

4. In the Launch ICA Desktop Session dialog box, choose from the following selections. The selections you make here

become the new default settings.

Accept the Width and Height values (800 x 600 by default) or specify a different resolution.

Colors (Better Speed by default). Select the color depth for the application. The available options are 256 colors (8-

bit), Better Speed (16-bit), or Better Appearance (32-bit).

Encryption. Select one of the following options from the list.

Basic encrypts the connection using a non-RC5 algorithm (default setting). Basic encryption protects the data

stream from being read directly but can be decrypted.

128-Bit Login Only (RC5) encrypts the logon data with RC5 128-bit encryption and the ICA connection with basic

encryption.

40-Bit (RC5) encrypts the connection with RC5 40-bit encryption.



When a user starts a published application, the client establishes a connection to a server in the farm and initiates a clientsession. If the user then starts another published application without logging off from the f irst application, the user hastwo concurrent connections to the server farm. To conserve resources, you can limit the number of concurrentconnections that users can make.Configure the Citrix policy for Server Settings > Connection Limits by setting the following options:

Limit User sessions. Specify the maximum number of connections a user can make to any single server at the same time.

Limits on administrator sessions. Enable this setting to extend the connection limit to Citrix administrators.

Important: Limiting connections for Citrix administrators can adversely affect their ability to shadow other users.

Logging of logon limit events. Enable this setting to record information about denied connection events in the server’s

system log.

By default, logons are enabled for each server in a farm. You can disable logons on a per-server basis, such as duringmaintenance, then re-enable after maintenance is complete. When you disable logons, current sessions remain active untilthe users log off .1. From the Delivery Services Console, select the server.

2. In the Actions pane, select one of the following:

Other Tasks > Disable logon

Other Tasks > Enable logon

To optimize performance, you can restart servers automatically at specified intervals by creating a restart schedule.


Restart schedules are based on the local time for each server to which they apply. This means that if you apply a schedule

to servers that are located in more than one time zone, the restarts do not happen simultaneously; each server is restarted

at the selected time in its own time zone.

When the Citrix Independent Management Architecture (IMA) service starts after a restart, it establishes a connection to

the data store and updates the local host cache. This update can vary from a few hundred kilobytes of data to several

megabytes of data, depending on the size and configuration of the server farm.

To reduce the load on the data store and to reduce the IMA service start time, Citrix recommends maintaining restart

groups of no more than 100 servers. In large server farms with hundreds of servers, or when the database hardware is not

sufficient, restart servers in groups of approximately 50, with at least 10 minute intervals between groups.

Configure the Citrix policy for Reboot Behavior by setting the following options:Scheduled reboots (disabled by default). Enable this setting to apply a restart schedule and warnings.

Continue by configuring related reboot policy settings for scheduling restarts, including settings for warnings to users

and the schedules by frequency and start date.


Removing and Reinstalling XenApp

May 08 , 2015

Tasks you might need to perform to remove servers from your farm or remove XenApp software from a server include:Removing XenApp from a computer in your farm or forcing its removal

Repairing a XenApp installation

Reinstalling XenApp after a hardware failure, which includes renaming the server

Removing a server from a farm or moving it to another farm

Removing a server from your farm if the hardware hosting XenApp fails

Citrix recommends that you remove XenApp by using Control Panel > Programs and Features while the server is still

connected to the farm and the network. Select Citrix XenApp <version>, click Uninstall. After the program is finished, restart

the server.

This method removes the host information from the farm data store and removes the server from the farm properties

displayed in the management tools.

To remove XenApp remotely, you can do so from within a Remote Desktop Connection (RDC) session or using tools such as

Microsoft Configuration Manager 2007 (formerly Systems Management Server (SMS)).

If you want to remove only specif ic components of XenApp, do so in the following order:Citrix Management (such as Delivery Services Console)

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 Configuring XenApp from the Command Line.

To force the removal of XenApp from a computer, you can use msiexec on a command line to add the property:

CTX_MF_FORCE_SUBSYSTEM_UNINSTALL. Set its value to Yes.

The following sample command line enables logging of the uninstallation operation and forces the removal of XenApp:

msiexec /x mps.msi /L*v c:\output.log CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=Yes

where mps.msi is the name and location of the msi package.

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

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-config-wrapper/ps-config-command-line.html


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. The records in the data store for the

old server apply to its replacement of the same name.

Ensure that the replacement server settings are identical to the failed server, including:Server name

Operating system

Settings for applications made during installation or when the application was published

User accounts

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 atyour own risk. Make sure you back up the registry before you edit it.To rename a XenApp server:1. Create a Citrix local administrator account on the server you want to rename.

2. On the server you want to rename, run chglogon /disable to prevent users from logging on to the server.

3. Open the Delivery Service Console on a different server, and remove the server to be renamed from published

applications assigned to that server.

4. On the server you want to rename, stop the Citrix Independent Management Architecture (IMA) service.

5. In the Registry, set the HKEY_LOCAL_MACHINE\SOFTWARE\ Wow6432Node\Citrix\IMA\RUNTIME\PSRequired

registry value to 1.

Caution: Not changing the PSRequired registry value to 1 can result in incomplete records in the data store. Changing this

value to 1 forces the Citrix Independent Management Architecture service to communicate with the data store and

create a record for the newly named server.

The value for PSRequired reverts to 0 the next time the Citrix Independent Management Architecture service restarts.

6. Change the name of the server in the server operating system and restart the server.

7. Log on to the console using the local administrator account you created.

8. Update all references to the old server to the new server name. For versions prior to 6.0, this might require logging on to

the XenApp Advanced Configuration tool or Presentation Server Console as well.

Important: Before removing the old server name, change all objects that reference the old name to the new server name,

including data collector ranking, published application references, load evaluators, and zone settings.

9. Expand the Servers folder and remove the old server name from the list of servers.

10. Add the new server name to the list of configured servers for published applications.

Caution: If you remove all servers belonging to a single domain and have Citrix administrators in the domain, their useraccounts cannot be enumerated by the Delivery Services Console and appear as a question mark (?) in the list of Citrixadministrators.To remove a server from a farm, use the XenApp Server Configuration Tool to leave the farm or join the server to another

farm. Access the Server Configuration Tool from the Server Role Manager or use XenAppConfigConsole.exe from the

command line. (For information on using XenAppConfigConsole.exe, see Configuring XenApp from the Command Line.)



If you cannot use the Server Configuration Tool – for example, because the hardware for the server fails or the servercannot be started – use this alternative method to remove the server from the farm:1. Open the Delivery Services Console from another server in the farm.

1. In the left pane, select the server you want to remove.

2. From the Action menu, select Other Tasks > Remove from farm.

2. Run the dscheck command on the farm’s data store to repair any consistency errors.

3. If you want reuse the server, Citrix recommends reimaging the server and reinstalling XenApp before joining the server to

a farm.

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.


Monitoring Server Performance with HealthMonitoring & Recovery

Apr 29, 2015

You can use Health Monitoring and Recovery to run tests on the servers in a server farm to monitor their state and discover

any health risks. Citrix provides a standard set of tests; you have the option of importing additional tests, including custom

tests that you develop. The Citrix tests included with XenApp allow you to monitor several services and activities including

Remote Desktop Services, XML Service, Citrix IMA Service, and logon/logoff cycles.

By default, Health Monitoring and Recovery is enabled on all of the servers in your farm, and the tests that are included run

on all servers, including the data collector. Typically, you do not need to run these tests on the data collector because,

particularly in a large farm, the data collector is not used for serving applications. If you do not want Health Monitoring &

Recovery to run on the data collector, you must disable it manually.

Store all custom tests in the following location:

%Program Files%\Citrix\HealthMon\Tests\Custom\

where %Program Files% is the location in which you installed XenApp. When saving custom tests, do not include spaces in

the file names.

Configure the Citrix policy for Health Monitoring and Recovery by setting the following options:Health monitoring (enabled by default). Use this setting to allow 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 off line servers (10 percent by default). Use this setting to specify the number of servers that the

Health Monitoring and Recovery feature can exclude from load balancing.

Use the load balancing feature of XenApp with Health Monitoring and Recovery to ensure that if a server in the farm

experiences a problem (for example the Citrix IMA Service is down), the state of that server does not interfere with the

user’s ability to access the application because the user’s connection to that application is redirected through another

server. For more information about load balancing and using Load Manager, see the— Load Management

section in eDocs.

Citrix IMA Service test

This test queries the service to ensure that it is running by enumerating the applications available on the server.

Logon monitor test

This test monitors session logon/logoff cycles to determine whether or not there is a problem with session initialization or

possibly an application failure. If there are numerous logon/logoff cycles within a short time period, the threshold for the

session is exceeded and a failure occurs. The session time, interval, and threshold can be configured by modifying the

parameters in the Test f ile f ield. These parameters are listed and described in the following table.


Logon monitor test parameter Description

SessionTime Defines the maximum session time for a short logon/logoff cycle. Default is f ive

seconds.

SessionInterval The time period designated to monitor logon/logoff cycles. Default is 600

seconds.

SessionThreshold The number of logon/logoff cycles that must occur within the session interval

for the test to fail. Default is 50 cycles.

Remote Desktop Services test

This test enumerates the list of sessions running on the server and the session user information, such as user name.

XML Service test

This test requests a ticket from the XML service running on the server and prints the ticket.

Check DNS test

This test performs a forward DNS lookup using the local host name to query the local DNS server in the computer’s

environment for the computer’s IP address. A failure occurs if the returned IP address does not match the IP address that is

registered locally. To perform reverse DNS lookups in addition to forward DNS lookups, use the f lag /rl when running this

test.

Check Local Host Cache test

Citrix does not recommend running this test unless you have problems with corrupted local host caches. This test ensures

the data stored in the XenApp server’s local host cache is not corrupted and that there are no duplicate entries. Because

this test can be CPU-intensive, use a 24-hour test interval (86,400 seconds) and keep the default test threshold and time-

out values.

Before running this test, ensure the permissions of the files and registry keys that the test accesses are set properly. To do

this, run the LHCTestACLsUtil.exe file located in C:\Program Files (x86)\Citrix\System32 of the XenApp server. To run this

utility, you must have local administrator privileges.

Check XML Threads test

This test inspects the threshold of the current number of worker threads running in the Citrix XML Service. When running

this test, use a single integer parameter to set the maximum allowable threshold value. The test compares the current value

on the XenApp server with the input value. A failure occurs if the current value is greater than the input value.

Citrix Print Manager Service test

This test enumerates session printers to determine the health of the Citrix Print Manager service. A failure occurs if the test

cannot enumerate session printers.

Microsoft Print Spooler Service test

This test enumerates printer drivers, printer processors, and printers to determine whether or not the Print Spooler Service in

Windows Server 2008 is healthy and ready for use

ICA Listener test

This test determines whether or not the XenApp server is able to accept ICA connections. The test detects the default ICA


port of the server, connects to the port, and sends test data in anticipation of a response. The test is successful when the

server responds to the test with the correct data.




The Health Monitoring and Recovery tests included with XenApp are configured with default settings. You can modify the

settings for each test. Monitor error messages in the Events log. For a description of the Citrix tests, see— Monitoring Server Performance with Health Monitoring & Recovery.

To set recovery actions, configure the Citrix policy settings for Health Monitoring and Recovery > Health monitoring tests.

Recovery Actions

Alert Only

Sends an error message to the Event log but takes no other action. The test continues to run, and if it subsequently

successfully passes, an event is sent to the system log. This recovery action is the default for all tests except the Citrix XML

Service test.

Remove Server f rom load balancing

Excludes the server from load balancing. Clients do not attempt to make new connections to this server through Load

Manager. However, existing connections are maintained, and attempts are made to reconnect disconnected sessions. You

can make new direct connections to the server; this enables you to try to correct any problems. To prevent possible farm-

wide outages, this is the default recovery action for the Citrix XML Service test.

Note: To restore one or more servers to load balancing, use the enablelb command-line utility.

Shut Down IMA

Shuts down the Citrix IMA Service. After this happens, tests continue to run but failures will not trigger events to be sent to

the Event log until the Citrix IMA Service is up and running again.

Restart IMA

Shuts down and then restarts the Citrix IMA Service. After this happens, tests will run but failures will not trigger events to

be sent to the Event log until the Citrix IMA Service is up and running again.

Reboot Server

Restarts the server. An alert is triggered before the server is restarted. After the system is restarted, the tests resumes.

Note: If the Recovery Action list contains the entry Action ID followed by a number, this means that Citrix supplied a newaction through a hotfix. Although you applied the hotfix to the selected server, you did not apply it to the computer onwhich the Access Management Console or Delivery Services Console is running. When the hotfix is fully applied, ameaningful name for the new action is added to the list.

If you want to perform particular tests that are not included in Health Monitoring & Recovery, you can develop custom

tests using the Health Monitoring & Recovery SDK. This SDK includes a Readme file and white papers that contain

https://taas.citrix.com/?utm_source=eDocs&utm_medium=web&utm_campaign=edocs-xenapp-6-monitor-page


information required to use the SDK, including security requirements and return values. In addition, the SDK contains various

sample test scripts that you can use as examples to develop custom tests that can be run on a server farm or on individual

servers in a farm. The Health Monitoring & Recovery SDK is available for download from the Citrix Knowledge Center.

After developing the custom test:Save the test in the custom test location, such as c:\program files (x86)\Citrix\HealthMon\Tests\Custom

Specify the custom test in a Citrix policy

To specify custom tests in a Citrix policy

1. Configure the Citrix policy setting for Health monitoring to enable the feature.

2. Configure the Citrix policy setting for Health monitoring tests, and select Add Custom.

3. In the Add Custom Test dialog box:

Provide a name for the test.

Provide the f ile location using the following example:

If the file location is: c:\program files (x86)\Citrix\HealthMon\Tests\Custom\mytest.exe

The path you enter is: Custom\mytest.exe

The rest of the path is added by the Health Monitoring & Recovery feature based on the installed location.

Complete the remaining options as preferred.


Using Citrix Performance Monitoring Counters

Nov 24 , 2009

Performance monitoring counters for ICA data are installed with XenApp and can be accessed from Performance Monitor,

which is part of the Windows operating system. Performance monitoring provides valuable information about utilization of

network bandwidth and helps determine if a bottleneck exists.

By using Performance Monitor, you can monitor the following counters:Bandwidth and compression counters for ICA sessions and computers running XenApp

Bandwidth counters for individual virtual channels within an ICA session

Latency counters for ICA sessions

1. On the server where XenApp is installed, open the Server Manager console.

2. In the Tree view, select Diagnostics > Performance > Monitoring Tools > Performance Monitor.

3. From the menu bar, selection Action > Properties.

4. In the Performance Monitors dialog box, select the Data tab.

5. Click Add.

6. In the Add Counters dialog box, from the Select counters from computer drop-down list, ensure Local computer is

selected.

7. In the Available counters list, select ICA Session.

8. To add all ICA counters, in the Available counters list, select ICA Session. To add one or more ICA counters, click the plus

sign next to ICA Session and select the individual counters to be added.

9. Select All instances to enable all instances of the selected ICA counters, No instance, or Select instances from list and

highlight only the instances you need. In Performance Monitor, the instance list contains all active ICA sessions, which

includes any session (shadower) that is shadowing an active ICA session (shadowee). An active session is one that is

logged on to successfully and is in use; a shadowing session is one that initiated shadowing of another ICA session.

Note: In a shadowing session, although you can select ICA counters to monitor, you see no performance data for that

session until shadowing is terminated.

10. Click Add and then click Close.

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.


Using Worker Groups for Enhanced Resource Access

Apr 29, 2015

Worker groups are collections of XenApp servers, residing in the same farm, that are managed as a single unit. Using workergroups, you can:

Streamline application publishing to multiple farm servers

Load balance access to published resources

Filter policies so that settings are applied only to sessions hosted on a specif ic set of farm servers

When using worker groups, consider the following:A farm server can belong to multiple worker groups

A worker group can include any number of XenApp servers or none at all

Only servers that belong to the same XenApp farm are included in a worker group

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.

To ensure an optimal experience for users accessing published resources, XenApp provides load balancing policies to directusers to the least-loaded XenApp server hosting the resource. You can use load balancing policies to:

Reduce WAN traff ic by directing users to the closest regional server

Direct users to a backup server in the event of an outage

Direct a specif ic group of users to a group of dedicated servers

Load balancing policies consist of the following elements:A f ilter to determine when the policy is applied

A worker group preference list to determine the servers to which users are directed when logging on

When you create a load balancing policy, configure a filter so that the load balancing policy can be applied to users when

they access published resources. If you do not configure a filter, the load balancing policy will have no effect when users log

on. As with other Citrix policies, you can filter based on access control, client IP address, client name, and users.

Additionally, to ensure users are directed to the appropriate servers, create a worker group preference list to prioritize the

servers that users can access. A priority of 1 is considered the highest priority. When a user launches a published application,

the load balancing policy directs the user to servers in the highest priority worker groups first. Users are directed to servers in

lower priority worker groups if servers in the higher priority worker groups are offline or have reached maximum capacity.

Users are not directed to servers in worker groups that are not included in the worker group preference list. If a user

attempts to launch an application that is not installed on any servers in any of the listed worker groups, regardless of


priority, the launch attempt fails and an error is logged to the Application event log on the data collector.

After you create load balancing policies, you prioritize them just as you would any other Citrix policy. If multiple load

balancing policies apply to a single user, XenApp uses the worker group preference list from the highest priority policy to

direct the user. Preference lists from lower priority load balancing policies are not considered.

You can use worker groups as filters in Citrix policies to apply policy settings to connections. When adding the filter, you

specify the worker group by name only. If the worker group is subsequently renamed or deleted, XenApp no longer

recognizes the filter and the policy is not applied to any connections.

1. From the Delivery Services Console, 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 the server grouping and then click Add. For example, select Organizational Units to add servers

based on their OU membership in Active Directory.

Note: If you do not use Active Directory in your environment, select Farm Servers to add individual XenApp servers to the

worker group.

5. Select the groups of servers you want to add to the worker group. For example, if you selected Organizational Units 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.

1. From the Delivery Services Console, select the Load Balancing Policies node in the left pane.

2. From the Actions pane, click Create load balancing policy.

3. Under Filters, select the f ilter to use to determine when the load balancing policy is applied.

4. Under Load Balancing Policies, select Worker Group Preference and then select Configure application connection

preference based on worker group.

5. Click Add and select the worker group you want to include.

6. Click Add to add the worker group to the list. Each worker group you add is automatically assigned a priority, from

highest (1) to lowest.

7. To adjust the priority of the worker groups in the list, select a worker group and then perform one of the following

actions:

Click Set priority and enter the priority level you want for the worker group. Entering a priority for a worker group does

not affect the priority of any other worker group in the list. Multiple worker groups can share the same priority.

Click Increase Priority or Decrease Priority to adjust incrementally the priority of the worker group.

To adjust the priority of a load balancing policy

1. From the Delivery Services Console, 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.


For business continuity, you can specify that if all servers in a worker group go offline, XenApp redirects user connections to

a backup worker group. This feature is known as Worker Group Preference and Failover; you configure it in the XenApp

console through the Load Balancing Policies.

As a best practice, to keep ICA traff ic from going over the WAN, you should:Direct requests for applications by specifying a Worker Group connection order in the Load Balancing Policies.

Create a policy that applies to connections from a worker group. Then, specify that worker group as the Primary Group

in the policy. This makes XenApp route incoming connection requests from users to that worker group f irst.

For more information about worker groups, see— Creating Worker Groups

.


Using Preferential Load Balancing

Apr 29, 2015

Preferential Load Balancing assigns importance levels (Low, Normal, or High) to specific users and applications. For example,

doctors and nurses in a hospital are specified as important users and MRI scans and X-rays are specified as important

applications. These important users and applications with higher levels of service connect to their sessions more quickly and

have more computing resources available to them. By default, a Normal level of service is assigned to all users and

applications.

Preferential Load Balancing calculates importance levels based on the Resource Allotment for each session. The Resource

Allotment is determined by the importance levels of both the session and the published application that the session is

running.

To enable Preferential Load Balancing, configure the CPU management server level policy setting and select Preferential

Load Balancing.

Continue by configuring the Session importance setting. 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 is calculated based on the published application importance level and the result of the XenApp policy

engine for that session. The policy engine bases the session result on the session importance policy setting.

A session’s Resource Allotment determines the level of service it experiences in comparison with other sessions on the same

XenApp server, as well as sessions on other XenApp servers. The higher a session’s Resource Allotment, the higher service it

receives compared with those other sessions.

The figure illustrates a XenApp farm running sessions with different Resource Allotments. It illustrates how a session’s

Resource Allotment affects its competition with other sessions on the same server and on different servers. Session 1 on

Server 2 has a relatively high Resource Allotment compared with all other sessions in the farm. As a result Session 1 gets the

highest percentage of CPU cycles (90%) of any session running in the farm, and at the same time has to compete with

fewer sessions on that server (there are only two sessions on Server 2, as opposed to three). Any new session would be

assigned to Server 1 because it has the lowest Resource Allotment of the three servers.

The session with the highest Resource Allotment gets the highest percentage of CPU cycles of any sessions running in thefarm.


The three application importance settings have Resource Allotment values associated with them, as do the three session

importance policy settings. To determine the effective Resource Allotment associated with a session running the published

application, multiply the application importance value by the session importance policy value. The most powerful session is

one with a high importance policy setting (3) running a high importance application (3), with a total Resource Allotment of 9

(3x3). Conversely, the least powerful session is one with a low importance policy setting (1) running a low importance

application (1), with a total Resource Allotment of 1 (1x1).

Use this table to help determine how to set your importance levels for applications and sessions.

Resource Allotments based on importance levels

Application Importance Session Importance (from policy) Session Resource Allotment

Low (1) Low (1) 1

Low (1) Normal (2) 2

Low (1) High (3) 3

Normal (2) Low (1) 2

Normal (2) Normal (2) 4

Normal (2) High (3) 6


High (3) Low (1) 3

High (3) Normal (2) 6

High (3) High (3) 9

Resource Allotments based on importance levels

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.


Managing CPU Usage

Jul 27, 2011

The CPU utilization management feature can be used to improve the ability of a farm to manage resources and normalize

CPU peaks when the farm’s performance becomes limited by CPU-intensive operations. When you enable CPU utilization

management, the server manages the share of the CPU allocated to each user. By default, this is an equal share. This

prevents one user from impacting the productivity of other users and allows more users to connect to a server. This feature

allows you to control the share.

The CPU utilization management feature ensures that CPU resources are equitably shared among users by having the serverallocate an equal share of the CPU to each user. This is accomplished by providing CPU reservation and CPU shares.

CPU reservation is a percentage of your server’s CPU resource that is available to a user. If all of a reserved allocation is

not being used, other users or processes can use the available resource, as needed. Up to 20% of the work capability of a

single CPU on a server is always set aside for the local system account and is not available to users.

CPU shares are percentages of the CPU time. By default, CPU utilization management allocates four shares for each

user. If two users are logged on to a server and the local system account does not need any of the resources on the

system, each user receives 50% of the CPU time. If there are four users, each user receives 25% of the CPU time.

Important: The range for CPU share is 1 through 64 percent. For CPU reservation, the total cannot be more than 99%,which represents the entire CPU resource on the computer.If you enable CPU utilization management, you must disable the Microsoft Dynamic Fair Share Scheduling (DFSS).

Do not enable CPU utilization management on farms or servers that host:CPU-intensive applications that may require a user to have a share of the CPU greater than that allocated to fellow

users.

Special users who require higher priority access to servers. You can exclude specif ied users from CPU restrictions.

You can enable CPU utilization management using Citrix policy settings. This feature is not enabled by default.

Important:The Dynamic Fair Share Scheduling (DFSS) aspect of the Windows Remote Desktop Services role is incompatible with CPU

utilization management. Ensure that DFSS is disabled on each server where CPU Utilization Management is enabled.

1. Configure the Citrix 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 f ilters to the policy based on worker groups or organizational units.


Deploying virtual memory optimization

Feb 16, 2010

You can enhance system speed, performance, and scalability by improving virtual memory utilization for a server using the

Citrix memory optimization service. The service improves how DLLs are shared among applications running on the server,

saving virtual and real memory. The service changes the location that individual DLLs are loaded in memory to increase the

amount of possible sharing. The process is called rebasing.

Memory optimization is especially useful when user demand exceeds available RAM and causes farm performance to

degrade. Performance degradation can occur during peak times when users run memory-intensive applications in multiple

sessions.

For a variety of reasons, not all applications can be successfully optimized. You can add those applications that cannot be

optimized to an exclusion list to bypass optimization. You do not want to enable memory utilization management on farms

or servers that exclusively host signed or certified applications because these cannot be optimized. XenApp can detect only

some published applications that are signed or certified.

The memory optimization feature includes the ability to set the schedule for DLL rebasing and to exclude specific

applications from DLL rebasing. Rebasing is composed of two parts: A scanning component that locates modules that are

candidates to be rebased, and a rewriting component that performs the optimization. If you enable memory optimization,

the scanning component runs regularly on the server. However, the rewriting component runs only when scheduled.

Configure the Citrix 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. The process automatically excludes some applications. However, if

published applications fail after enabling and running memory optimization, exclude those applications from memory

optimization by adding them to the exclusion list.

Some types of application that cannot be optimized include:Applications that reside on network shares (automatically excluded).

Applications that have digitally signed components.

Applications whose DLLs are protected by Windows Rights Management. For example, applications such as Office 2003

do not benefit from this feature.

Applications whose executable programmatically checks the DLL after it is loaded.

Applications that require a f ixed DLL address.


In general, if an application was working, but it stops working after you enable this feature, add the application to the

exclusion list and see if the problem is resolved.

With memory optimization enabled, to exclude additional applications, configure the Citrix policy settings for Memory/CPU

> Memory optimization application exclusion list by adding the full path and executable name for the application, for

example:

C:\\%Program Files%\ProgramName.exe

where %Program Files% is the full path to the application.

After you enable virtual memory optimization, the server rebases DLLs automatically at server start-up. When the service

rebases, it changes the location that individual DLLs are loaded in memory to increase the amount of possible sharing.

You can create an additional virtual memory optimization schedule that identifies other times when a server rebases DLLs

for greater operating efficiency. As a best practice, schedule virtual memory optimization at a time when your servers have

their lightest loads.

With memory optimization enabled, configure these Citrix policy settings for Memory/CPU: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 specif ied day does not occur in a given month, such as day "31" in June, memory optimization does not run in that

month. This setting is used only if you set the interval to Monthly.

Memory optimization schedule: day of week (Sunday by default). Select the day of the week that memory optimization

runs. This setting is used only if you set the interval to Weekly.

Memory optimization schedule: time (3:00 AM by default). This setting is used only if you set the interval to Daily, Weekly,

or Monthly.


Managing Farm Infrastructure

Apr 29, 2015

All farms include infrastructure functions to support the servers hosting published applications. Whether you configure

these functions on shared or stand-alone servers depends on your farm’s size and requirements.

Farms comprise at least one zone or grouping of servers. Multiple zones are sometimes used to improve the performance

on geographically segmented farms. Within the zone, there is a data collector, which contains information about other

servers in the farm, and servers designated as backup data collectors. If the data store fails, each server on the farm also

contains a backup of all data store information, known as the local host cache.




A subset of data store information, the local host cache, exists on each server in the farm, providing each member server

with quick access to data store information. The local host cache also provides redundancy of the data store information,

if for example, a server in the farm loses connectivity to the data store.

When a change is made to the farm’s data store, a notification to update the local host cache is sent to all the servers in

the farm. However, it is possible that some servers will miss an update because of network problems. Member servers

periodically query the data store to determine if changes were made since the server’s local host cache was last updated. If

changes were made, the server requests the changed information.

Refreshing the Local Host Cache

You can force a manual refresh of a server’s local host cache by executing dsmaint refreshlhc from a command prompt. This

action forces the local host cache to read all changes immediately from the farm’s data store. Refreshing the local host

cache is useful, for example, if the Citrix Independent Management Architecture (IMA) Service is running, but published

applications do not appear correctly when users browse for application sets.

A discrepancy in the local host cache occurs only if the IMA Service on a server misses a change event and is not

synchronized correctly with the data store.

Recreating the Local Host Cache

You can manually create the local host cache from the farm’s data store. If the IMA Service fails to start or you have a

corrupt local host cache, you may need to recreate it.

To recreate the local host cache, stop the IMA Service and then run the command dsmaint recreatelhc. Running thiscommand performs three actions:

Sets the value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\

RUNTIME\PSRequired to 1.

Deletes the existing local host cache (Imalhc.mdb)

Creates an empty local host cache (Imalhc.mdb)

https://taas.citrix.com/?utm_source=eDocs&utm_medium=web&utm_campaign=edocs-xenapp-6-managing-farm-page


You must restart the IMA Service after running dsmaint recreatelhc. When the IMA Service starts, the local host cache is

populated with fresh data from the data store.

The data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA Service

fails to start.

You can adjust the interval by which member servers query the farm's data store for missed changes. The default interval is30 minutes. In most cases, this default setting is suff icient.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 Editorat your own risk. Be sure to back up the registry before you edit it.You can configure the interval by creating the following registry key on each server you want to adjust, with the value

expressed in hexadecimal notation:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ DCNChangePollingInterval (DWORD)

Value: 0x1B7740 (default 1,800,000 milliseconds)

You must restart the IMA Service for this setting to take effect.

Most changes made through the Delivery Services Console are written to the data store. When you open one of these

tools, it connects to a specified server. The Citrix Independent Management Architecture (IMA) Service running on this

server performs all reads and write operations to the data store for the console.

If the data store is experiencing high CPU usage when few read or write operations to the data store are occurring, it is

possible that the data store is not powerful enough to manage a query interval of 30 minutes. To determine whether or

not the data store query interval is causing the high CPU usage on the data store, you can set the query interval to a very

large number and test CPU usage. If the CPU usage returns to normal after you set a large query interval, the data store

query interval is probably the cause of the high CPU usage. You can adjust the query interval based on performance testing.

To test the query interval, set the interval to 60 minutes and then restart all the servers in the farm. If the data store is stillexperiencing constant high CPU usage, increase the query interval further. If the CPU usage returns to normal, you can try asmaller value. Continue these adjustments until data store CPU usage is normal.Important: Do not set the data store query interval higher than necessary. This interval serves as an important safeguardagainst lost updates. Setting the interval higher than necessary can cause delays in updating the local host cache of thefarm’s member servers.

To optimize IMA traffic, after Setup, you can continue creating zones, moving servers between zones, and renaming zones.

For design considerations for zones, including whether to create zones for small groups of remote servers, see the topics— Designing a XenApp Deployment

.

When you create a server farm and whenever a new server joins a zone, a server is elected as the data collector for that

zone. If the data collector for the zone becomes unavailable, a new data collector is elected for the zone based on a

simple ranking of servers in the zone.

Important: A primary domain controller or backup domain controller must not become the data collector for a zone. Thissituation may arise if XenApp is installed on Windows domain controllers. Do not install XenApp on a domain controller.


Citrix does not support installing XenApp on a domain controller.1. From the Delivery Services Console, select the farm.

2. Expand the server node and select Zones to view the existing zones for the farm.

To create new zones

1. To create or modify zones, on the Actions menu, under Zones, click New to open the wizard. Follow the instructions to

name the zone, select servers.

2. On the Set server's election preferences page, click Edit and select the ranking for the server by choosing from the

following election options:

Most Preferred. The server is always the f irst choice to become the data collector. It is recommended that only one

server per zone be given this setting.

Preferred. When electing a new data collector, XenApp elects the next collector from the Preferred servers if the

Most Preferred server is not available.

Default Preference. The default setting for all servers. The next collector is selected from the Default servers if

neither a Most Preferred server nor a Preferred server is available.

Not Preferred. Apply this setting to servers that you do not want to become the data collector for the zone. This

setting means that this server becomes the data collector only when no servers are available with any of the other

three settings (Most Preferred, Preferred, Default Preference).

3. Restart the servers to apply the changes.

Zones are listed in the middle pane according to their election preference.

Also from the Actions pane, select the Set server's zone membership option to move the selected server to another zone,

or select the Change server's zone membership option to move the selected server to another zone.


Updating Citrix License Server Settings

May 18 , 2015

XenApp servers must point to the license server where license files are stored. The license server settings include the name

of the license server that your farm accesses to check out licenses and the port number the license server uses to

communicate.

You can set the license server settings with the XenApp Server Configuration tool when creating or joining a farm, or you

can change the settings through a Citrix policy by specifying the name of the license server or port number that the license

server uses to communicate in the Licensing section of the policy and apply the policy through filters.

You may want to change these settings in the following instances:You rename your license server.

You want to point to a second license server to relieve some of the traff ic to the f irst license server. For example, you

have many connections and you f ind that it is slowing down the network, or you would like to add a second license

server to the farm and point half of the connections to it.

You want to specify another license server to point to individual servers to segregate licenses. For example, you want to

host the accounting department’s licenses on a server other than the human resources department.

The default port number (27000) is already in use.

You have a f irewall between the license server and the computers running your Citrix products, and you must specify a

static Citrix vendor daemon port number.

To change the name of the license server or port number that it uses to communicate, configure the Citrix policy forLicensing by setting the following options:

Enter the License server host name of the server hosting XenApp licenses.

Enter the License server port number (default 27000).

Changing the settings on this page is only one part of the procedure, however.

If you decide to change the license server name, ensure that a license server with the new name already exists on your

network. Because license files are tied to the license server’s host name, if you change the license server name, you must

download a license file that is generated for the new license server. This may involve returning and reallocating the licenses.

To return and reallocate your licenses, go to www.citrix.com/account.

If you change the port number, specify the new number in all license files on the server.

For additional information, see— Licensing Your Product

.

The product editions of XenApp support different features. To activate the features available with a particular edition

installed on each server, set the product edition on each server through Citrix policies.

The product edition also determines which type of license a server requests from the license server. Make sure the edition

you set match the licenses you installed.

1. Locate the Citrix policies for Server Settings, and configure the XenApp product edition setting.

2. Create a f ilter to apply the policy to specif ic worker groups.

http://www.citrix.com/account


3. To apply the change, you must restart each server affected by the policy.


Configuring the Citrix XML Service Port and Trust

Apr 29, 2015

The Citrix XML Service is used by user devices connecting over the TCP/IP+HTTP protocol and the Web Interface.

By default, XenApp server role installation configures the Citrix XML Service and Internet Information Service (IIS) to share

the same TCP/IPport (80) for communications. In this case, you cannot change the XML Service setting.

During the installation of Citrix XenApp on your server, you configured the XML Service to either share the port with your

Microsoft Internet Information Server or to use a particular port. For details about the XenApp and Web Server (IIS) server

roles, refer to the— System Requirements for XenApp for Windows Server 2008 R2

.

If you specified a custom XML Service port during installation, you can change the XML port number if necessary.

Note: The port option appears only if you entered a different port number than the default Share with IIS during the WebInterface installation. Use the XML Service policy setting to change the port number.

1. Locate Citrix policy setting for XML Service.

2. Configure the XML service port setting. Citrix recommends using port 8080.

The trust setting is needed only for Smooth Roaming when users authenticate using pass-through or smart-cardauthentication with Web Interface, or for smart-card authentication with the online plug-in. Trust is not required forexplicit authentication.1. Locate Citrix policy setting for XML Service.

2. Configure the Trust XML requests setting (disabled by default).

If you do not trust XML requests, certain features of XenApp are not available. Trusting requests sent to the XML Servicemeans:

Smooth Roaming works when connecting with the Web Interface using pass-through or smart card authentication, and

when connecting with the online plug-in using smart card authentication or the Kerberos pass-through option.

For example, you can use workspace control to assist health-care workers in a hospital using smart cards, who need to

move quickly among workstations and be able to pick up where they left off in published applications.

XenApp can use the information passed on from Access Gateway (Version 4.0 or later) to control application access and

session policies. This information includes Access Gateway f ilters that can be used to control access to published

applications and to set XenApp session policies. If you do not trust requests sent to the XML Service, this additional

information is ignored.

Before enabling the Citrix XML Service to trust requests it receives, use IPSec, firewalls, or another technology to ensure

that only trusted services communicate with the Citrix XML Service.

To avoid security risks, enable the setting only under the following conditions:

Some users connecting to their sessions using the Web Interface are also using pass-through authentication or smart

cards.


The same users need to move from one client device to another and still be able to pick up where they left off in

published applications.

You implemented IPSec, f irewalls, or any technology that ensures that only trusted services communicate with the XML

Service.

You are selecting this setting only on servers that are contacted by the Web Interface.

You are restricting access to the XML Service to the servers running the Web Interface. When Internet Information

Services (IIS) and the XML Service share a port, you can use IIS to restrict port access to include the IP addresses of

servers running the Web Interface only.

Note: This setting takes effect only after the XML Service restarts.The XML Service port set using a Group Policy Object takes precedence over the port you set using the command-line in

this method.

1. At a command prompt, stop IIS by typing:

net stop w3svc

2. Delete the following f iles from the IIS scripts directory on your Web server:

ctxadmin.dll

CtxConfProxy.dll

ctxsta.dll

radexml.dll

wpnbr.dll

3. At a command prompt, restart IIS by typing:

net start w3svc

The XML Service no longer shares a port with IIS.

4. To ensure the XML Service is stopped, at a command prompt, type:

net stop ctxhttp

5. At a command prompt, to unload the XML Service from memory, type:

ctxxmlss /u

6. To install the XML service, type:

ctxxmlss /rnn

where nn is the number of the port you want to use; for example, ctxxmlss /r88 forces the Citrix XML Service to use

TCP/IP port 88.

7. At a command prompt, start the XML Service by typing:

net start ctxhttp

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. At a command prompt, to unregister the Citrix XML Service, type:

ctxconfproxy.dll

ctxsta.config

ctxsta.dll

ctxxmlss.exe

ctxxmlss.txt

radexml.dll

wpnbr.dll

These files are installed in \Program Files (x86)\Citrix\System32 during XenApp installation.

The default scripts directory is \Inetpub\AdminScripts.

4. In the IIS scripts directory, create a folder called ctxadmin and copy the f ile ctxadmin.dll from \Program Files

(x86)\Citrix\System32 to \Inetpub\AdminScripts\ctxadmin.

5. At a command prompt, stop and restart the Web server by typing:

i isreset

This setting takes effect after the Web server restarts.


Understanding XenApp Printing

Apr 27, 2015

Managing printers in a XenApp environment is a multistage process. The cycle for managing printers on a farm requires that

you:

1. Design your printing configuration. This includes analyzing your business needs, your existing printing infrastructure, how

your users and applications interact with printing today, and what a realistic printing management model would look like

for your organization (that is, assessing that the administrative overhead of printing pathway you choose is realistic in

your environment).

2. Configure your printing environment, including creating the policies necessary to deploy your printing design.

3. Test a pilot printing deployment before rolling it out to users.

4. Maintain your Citrix printing environment, including updating policies when new employees or servers are added and

maintaining drivers on your farm servers.

5. Troubleshoot issues that may arise in your printing environment.

Before you begin planning your deployment, make sure that you understand these major concepts for printing in XenApp:The concept of printer provisioning in a session and the two major types of provisioning (auto-created and self-

provisioned). To understand these concepts, you need to understand, among other things, the difference between a

printer, a printing device, and a printer driver.

How print jobs can be routed in XenApp.

The policies that you can create to manage drivers.

XenApp printing concepts build on Windows printing concepts. To configure and successfully manage printing in a Citrix

environment, you must understand how Windows network and client printing works and how this translates into printing

behavior in a Citrix environment.

Updated: 2015-05-08

This section provides a limited overview of basic printing concepts in a standard (non-Remote Desktop Services) Windows

environment. However, Citrix recommends reviewing the Windows documentation about network printing, print servers, and

Remote Desktop Services printing before learning about Citrix printing concepts.

In a Windows environment, you can either print from your computer to a locally attached desktop printer (for example, a

printer on LPT1 or COM1) or you can print to a network printer that is managed by a print server.

This diagram shows how print jobs are spooled from the client device to a print server and then sent to the printing devicein a Windows network.


Here are a few basic definitions:Printing Device

In the context of this topic, the term printing device refers to the physical printer (that is, the hardware device to which you

send print jobs).

Printers

The term printer refers to the software representation of a printing device. Computers must store information about

printers so they can f ind and interact with printing devices. When you see printer icons in the Printers panel in the Control

Panel, you are seeing the software representation of the printers. (You are not seeing the printer drivers.)

For clarity, the term printer object is sometimes used to denote the software representation of a printing device.

Printer driver

The printer driver is the software program that lets the computer communicate with this hardware device. This program

converts the information to be printed to a language that the printing device can process. It also understands the device

and job settings of the printing device and presents a user interface for users to configure these. In Windows systems,

printer drivers are distinct from the software representation of printers.

Print job

When a user prints a document, the data sent to the printer is known as a print job. Jobs are queued to the printer in a

specif ic sequence, which the print spooler controls. When this sequence appears, it is known as the print queue.

Print spooler

The spooler is the Windows service that manages printer objects, coordinates drivers, lets you create new printers,

determines where print jobs are processed, and manages the scheduling of print jobs. The print spooler also determines if

the printer prints each page as it receives it or if the printer waits until it receives all pages to print the job.

Typically, when a print job is spooled to a printer, the spooler loads documents into a buffer. The printing device then

retrieves the print jobs from the buffer when it is ready to print the job. By storing the job, the computer can perform other

operations while the printing occurs in the background.

Print queue

A sequential, prioritized list of the print jobs waiting to be printed. The spooler maintains this list for each printer object in

the computer.

Print server


A computer that manages the communications between client devices and printers. In this context, the term print server

refers to dedicated computers that are running a Windows server operating system and hosting x number of shared

printers. Print servers provide client workstations with drivers they need to print and store f iles, or print jobs, in a print queue

until the printer can print them. A print server is a remote print spooler.

Network printer

A shared printer object accessed through a network print server.

Print job spooling is important because where print jobs are spooled to is where print jobs are processed. Processing

location affects network traffic, resource utilization, and has additional implications in a XenApp context.

Print jobs can be spooled either locally or remotely. Typically, print jobs sent to locally attached printers are spooled locally,

and jobs sent to network printers are spooled remotely.

Locally Spooled Print Jobs

When print jobs are spooled locally, the local Windows computer processes the job. The application creates a spooled print

job; the local print spooler, aided by the printer driver, processes the print job, and sends the rendered output to the printing

device.

In a Windows environment, when you print to a printer connected to your local computer (when print jobs are spooled

locally), the printer drivers and settings are stored on the computer itself. A typical printing process for locally spooled print

jobs is:

1. The application tells the local spooler to create a print job and an associated spool f ile on the local computer.

2. On the local computer, Windows writes the application’s drawing commands to the local spool f ile. This process of

writing commands occurs repeatedly until the job is completely spooled.

3. The local spooler processes the job with the printer driver in a process known as— rendering

.

4. The local spooler delivers the rendered data to the printing device (for example, a locally attached printer).

Remotely Spooled Print Jobs

When print jobs are spooled remotely, the Windows print server processes the print job.

A typical printing process for remotely spooled print jobs is

1. The application tells the remote spooler to create a print job on the print server and an associated spool f ile.

2. On the local computer, Windows writes the application’s drawing commands to the remote spool f ile. This process of

writing commands across the network occurs repeatedly until the job is completely spooled.

3. The remote spooler processes the job with the printer driver in a process known as— rendering

.

4. The print server delivers the rendered data to the printing device (typically a network printer).

Key Differences Between Remote and Local Spooling

Unlike remote spooling, local spooling does not use any network resources. Remote spooling requires that the local


computer and the remote printer exchange many messages across the network. Even in a non-Citrix environment, if a WAN

has substantial latency, users will have a poor user experience if the print jobs are spooled remotely across the WAN.

However, in some situations, for example when the resources on the local computer are needed for other tasks, remote

spooling is preferable. In remote spooling, the print job is processed on the print server, which off-loads processing from the

local computer.

Updated: 2015-04-30

In a XenApp environment, all printing is initiated (by the user) on the server. However, print jobs are not always sent directly

from the server to the printing device. Instead, the print jobs can be redirected through the client device.

Because there is no persistent workspace for users in XenApp (when a session ends, the user’s workspace is deleted), all

settings need to be rebuilt at the beginning of each session. As a result, each time a user starts a new session, XenApp must

reprovision (recreate or restore) the printers available in a session.

When a user clicks Print, XenApp:Determines what printers (that is, printer objects) to provide to the user. This is known as printer provisioning.

Restores the user’s printing preferences.

Determines which printer is the default for the session.

However, you can customize how XenApp performs these tasks by configuring options for printer provisioning, print job

routing, printer property retention, and driver management. Settings for these options can affect the performance of

printing in your environment and the user experience. For example, you can reduce the amount of latency when users print

by choosing a method of provisioning that is appropriate for your network configuration.

As a result, understanding key printing concepts is critical when planning your printing configuration:The difference between the client and network printing pathway and how this is not the same as local printers and

network printers

The term printer provisioning, the types of printer provisioning (static and dynamic), printer autocreation, and user self-

provisioning

Print job routing and when changing it can improve utilization

The basics of printer driver management

Overview of Client and Network Printing Pathways

An important concept in XenApp is the printing pathway. The term printing pathway encompasses both the path by which

print jobs are routed and the location where print jobs are spooled. Both aspects of this concept are important. Routing

affects network traffic. Spooling affects utilization of local resources on the device that processes the job.

In XenApp, print jobs can take two different printing pathways:Network printing pathway

Client printing pathway

The term network printing pathway refers to print jobs that are routed from the farm server hosting the user’s session to a

print server and spooled remotely.


This diagram shows a XenApp network printing example: Printing begins on the farm server hosting the user’s session (wherethe application is published and executing). XenApp routes the print job over a network connection to the network printserver. The network print server then routes the print job to an associated network printing device.

When a print job is spooled remotely in a Windows environment, it uses this process:

1. The application tells the remote spooler to create a print job and an associated spool f ile.

2. The Windows Print Provider sends the spool f ile to the print server.

3. The print server processes the spool f ile.

4. The print server then sends the print job to the appropriate network printer.

The term server local printers refers to a configuration that uses the network printing pathway where printing devices are

attached locally to a XenApp farm server. Server local printers are shared printing devices that are physically attached to a

farm server.

Note: To use a locally attached printer as a server local printer in a XenApp farm, the printer must be shared; otherwiseXenApp does not recognize it.Server local printers are often a good choice for printing in small farm environments. However, server local printers are not

used widely in enterprise environments because they require installing the printer drivers on each server in the farm and

require additional resources on the XenApp server. Server local printers are managed and configured in the same ways as

network printers.

This diagram shows a XenApp server local printing example: Printing begins on the farm server hosting the user’s session andis routed to a printing device attached locally to the server.

The term client printing pathway refers to print jobs that are routed over the ICA protocol through the client device to the

printer (either a printer connected directly to the client device or connected through a print server) and spooled on the Citrix


online plug-in.

When using the client printing pathway, a virtual printer is constructed in the session that redirects to the printer object on

the client device. The client device, in turn, sends the print job to the printing device.

Importantly, because all processing occurs on the XenApp server, when users print a document from a published application,

they are actually starting that print job on the XenApp server. These jobs are spooled locally on the XenApp server.

There are two different configurations of the client printing pathway: one for printers attached directly to the client device

and another for network printers.

The simplest configuration is the one where the printer is attached directly to the client device. In this configuration, the

application server sends the print job back to the client/client device. The client device then relays it to a locally attached

printer.

This diagram shows a simplif ied XenApp client printing example: Printing begins on the server where the application ispublished. XenApp sends the print job over the connection to the client device. The client device then routes the print job tothe printer connected locally to the client device.

When a print job is spooled to a client along the client printing pathway, it uses this process:

1. The published application tells the local spooler on the server hosting the application (that is, the host server) to create a

print job and an associated spool f ile on the host server.

2. On the host server, Windows writes the application’s drawing commands to the local spool f ile. (This process of writing

commands occurs repeatedly until the job is completely spooled.)

3. The local spooler processes the job with the printer driver in a process known as— rendering

.

4. The rendered data is delivered to the client device through the ICA protocol.

5. The client device relays the print data to the client-side printing device (a locally attached printer in this example).

While client printers are often printers physically attached to client devices, they can also be printers on the network. In this

case, print jobs are routed through the client device to the print server.

The process is the same as for printing to a local printing device through the client. However, instead of sending the job to

the client device, the job is sent to the network print server.

This diagram shows client printing to a network printer: Printing begins on the server where the application is published.XenApp routes the print job over the connection to the client device. The client device then routes the print job over the


network to the print server, which in turn routes the print job to the network printer.

When a print job is spooled to a network printer along the client printing pathway, it uses this process:

1. The application server sends the print job to the client for processing.

2. The client processes the spooled job and sends it to the Windows print server for processing.

3. The Windows print server then sends the print job to the appropriate network printer.

Configuring XenApp to use the client printing pathway for network printing devices is useful when a print server is in a

domain different from the farm servers (and the client devices have access to the print server’s domain). Using the client

printing pathway lets application servers send print jobs over the ICA connection to access the printer through the client

device.

Configuring the client printing pathway for network printing is useful for low bandwidth connections, such as WANs, that

can benefit from the traffic compression that results from sending jobs over the ICA connection. The client printing

pathway also lets you limit traffic or restrict bandwidth allocated for print jobs.

Provisioning Printers for Sessions

For a computer to process a print command, it needs both the required printer object and a printer driver. Because sessions

are hosted in a virtual workspace instead of locally on a hard drive, printers and their drivers are not stored on the local

computer. Instead, they are restored at logon or reconnect. The process by which XenApp makes printers available in a

session is known as provisioning.

You can control printer provisioning and the way you configure it affects what printers users see in sessions and the speed

of the printers.

There are two types of printer provisioning:Static. Server local printers are provisioned only once, when you connect them to the farm server. After that, they are

always created in sessions with the same properties and do not vary according to policies.

Dynamic. The printers that are available in a session are determined as the session is built. As a result, they can change

according to changes to policies, changes in user location, and changes to the network (provided they are reflected in

policies). When printers are provisioned dynamically, the printers that appear in a session are not predetermined and


stored. Rather, the printers are assembled, based on policies, as the session is built.

Because provisioning static printers is relatively simple, this topic focuses on provisioning printers dynamically.

The two most common methods of dynamic printer provisioning are:

User provisioning

Autocreation

To control what printers users have in their sessions and ensure printers are available when users start their sessions,

provision their printers through autocreation. If you do not want to specify (and administer) user printers, you can let users

self-provision their printers.

If you choose, you can prevent printer autocreation and let users provision printers visible from their client device.

You can allow users to add printers to their sessions on their own. Users can map client printers that are not autocreated by

policy manually in a user session through the Windows Add Printer wizard on the server (in their sessions). If users have thin

clients or cannot access their client devices, they can self-provision by running the ICA Client Printer Configuration tool

(PrintCfg.exe). For users to self-provision with the utility, you must publish PrintCfg.exe on your farm.

The term autocreation refers to printers XenApp creates automatically, at the beginning of each session, based on what

printers are configured on the client device and any policies that apply to the session.

By default, XenApp makes printers available in sessions by creating all printers configured on the client device automatically,

including locally attached and network printers. After the user ends the session, the printers for that session are deleted.

The next time a session starts, XenApp evaluates any policies for printer creation and enumerates the appropriate printers

from the client device.

You can change the default autocreation policy settings to limit the number or type of printers that are auto-created.XenApp can auto-create:

Client redirected printers, including auto-created client printers and a Universal Printer

Network printers

There is maintenance associated with provisioning by printers by using client and network printer autocreation. When you

add new printers, you need to update the autocreation list. Also, the drivers for these printers must be added to all servers

on the farm; however, you can specify for XenApp to do this automatically.

This topic comprises:Auto-creating client printing

Provisioning a Citrix Universal Printing solution

Auto-creating netwrok printing

Letting users provision their own printers

All of these provisioning methods use the client printing pathway except for auo-creating network printers, which uses the

network printing pathway.

Updated: 2013-12-11


The autocreation feature creates a list of printers that a user can use after logging on. When the user logs in, their print

drivers will be installed and all printers returned in this list will be available for use.

XenApp can auto-create redirected client printers in two different ways:

By creating a one-to-one match with printers on the client device

By creating one generic printer, the Citrix Universal Printer, that represents all (or any) printers on the client device

In many environments, especially large ones, Citrix recommends that you auto-create only one default printer. Auto-

creating a smaller number of printers creates less overhead on the server and is better for CPU utilization.

However, in environments where users with limited computer skills need to print to a wide variety of local printing devices,

you may want to leave the default autocreation setting so that all printers are created on logon.

If you do not want large numbers of printers created at the beginning of each session, consider specifying for XenApp to

use the Citrix Universal Printer.

Auto-Creating Printers from the Client DeviceAt the start of a session, XenApp auto-creates all printers on the client device by default. You can control what, if any,

types of printers are provisioned to users and prevent autocreation entirely.

The Citrix policy setting Auto-create client printers lets you control autocreation and specify that:All printers visible to the client device, including network and locally attached printers, are created automatically at the

start of each session

All non-network printers physically attached to the client device are created automatically

Only the default printer for the client device is created automatically

No printers visible to the client device are created automatically

When configuring policies for printer autocreation, ensure:User accounts are not shared

You add Microsoft native or fully tested drivers only

Users have write access on the server to %systemroot%\system32\spool

These points help ensure that printers auto-create successfully.

Provisioning a Citrix Universal Printing SolutionCitrix Universal printers and drivers are printing solutions that let users print regardless of whether or not they have the

correct printers and drivers installed.

Universal printing solutions are printers and drivers not tied to any specific device. Consequently, they simplify administration

by reducing the number of drivers required on farm servers or the number of printers created at the beginning of sessions.

Because users need to access fewer printers and drivers, the speed of starting a session is increased and the complexity of

printer administration is decreased.

XenApp includes two types of universal printing solutions:Citrix Universal Printer. A generic printer object, replacing the printers that appear in the users Printers control panel

during their session. This printer can be used with almost any printing device.

Citrix Universal Printer Drivers. Windows Native Printer drivers are generic drivers that work with almost any printer.

These drivers also work with non-Windows clients. Citrix-created Universal printer drivers consist of the Citrix XPS

Universal Printer driver and the EMF-based Citrix Universal Printer driver.


These printing solutions can be used in one of the following ways:Auto-created device printer with Citrix Universal printer driver. A device-specif ic printer gets auto-created but uses

a Citrix Universal printer driver. For example, configured policy rules specify that the printer LaserJet5L still gets auto-

created at the beginning of each session; however, the session uses the Citrix Universal printer driver to communicate

with the driver on the client device and the print job is processed on the client device.

Auto-created Citrix Universal Printer with a Citrix Universal printer driver. A Citrix Universal Printer gets auto-

created and it uses a Citrix Universal printer driver. That is, at the beginning of each session, the only printer that is auto-

created is the Citrix Universal Printer. Like the f irst example, the session uses the Citrix Universal printer driver to

communicate with the driver on the client device and the print job is processed on the client device.

Auto-created device printers, auto-created Citrix Universal Printer with a Citrix Universal printer driver – At the

beginning of the session, the Citrix Universal Printer and device-specif ic printers are auto-created. Both printers use the

Citrix Universal printer driver.

Whether you use a Citrix Universal printing solution depends on various factors:The Citrix Universal Printer and printer driver might not work for all client devices or plug-ins in your environment. The Citrix

Universal Printer and printer driver solution requires the Citrix Online Plug-in or the Citrix Offline Plug-in.

The Citrix Universal Printer does not work if plug-ins are not connecting through the ICA channel, such as when you are

using the Citrix Offline Plug-in and streaming applications to the client.

If you want to use a universal printing solution for non-Windows plug-ins, use one of the other universal printer drivers

that are based on postscript/PCL and installed automatically with XenApp.

The Citrix Universal printer driver might also create smaller print jobs than older or less advanced printer drivers. However,

sometimes it might be better to use a device-specif ic 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 printernames 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 Pluginfor Hosted Apps 11.0, the Citrix Online Plug-in, the Citrix XenApp Plug-in for Streamed Apps, and the Citrix Offline Plug-in.This feature is available in Presentation Server 4.0 to XenApp 6.Citrix Universal Printer

The Citrix Universal Printer is a generic printer created at the beginning of sessions that can be used with almost any

printing device. This printer can print to and communicate, through the client, with any client-side printer.

You may also want to use the Citrix Universal Printer because the printer name does not change when users reconnect.

Changing printer names can cause problems for some applications.

The Citrix Universal Printer is created on a per-session basis. When used with a Citrix Universal Printer driver, it can greatly

reduce the resource usage at the start of a session from printer autocreation. When you use the Universal Printer, you can

specify that only the Universal Printer be auto-created for each printer on the client device.

When the Citrix Universal Printer is enabled, an extra printer is created in the session with the name Citrix UNIVERSAL Printer

in session number of session. To use only the Citrix Universal Printer in sessions and not auto-create any printers on the

client device, enable the Universal Printer through the registry and configure the Citrix policy setting Auto-create client

printers to Do not auto-create client printers.


The user experience varies depending on the type of Citrix Universal Printer.

Because the Citrix Universal Printer is not tied to a specif ic printing device, both the EMF-based and XPS-based CitrixUniversal Printers provide ways to preview and select settings:

EMF-based Citrix Universal Printer. The EMF-based Citrix Universal Printer can display a print preview before printing. If

the Preview on client option is selected in the printer’s printing preferences, the user sees a preview of the print job and

has the option of choosing a target printer and controlling print device setting. If the Preview on client option is not

selected, no preview is displayed and print job is routed directly to the default printer on the user device.

XPS-based Citrix Universal Printer. Like Microsoft XPS Document Writer, the Citrix XPS Universal Printer sends

documents to Internet Explorer if a user selects Print Preview or modif ies the print settings, displaying them in

Microsoft’s XPS “electronic paper” format.

Note: The Print Previewer cannot be controlled by the administrator unless users have the Citrix Presentation Server Client,Version 10.100 or later, the Citrix XenApp Plug-in for Hosted Apps, Version 11x, or the Citrix Online Plug-in.

By default, any network printing devices on the client device are created automatically at the beginning of sessions.

However, if possible, XenApp always tries to route jobs directly from XenApp to the print server and not through the client

connection.

To specify that specific printers are created in sessions rather than auto-create all the network printing devices available

from the client device, configure the Citrix policy setting Session printers.

Network printers created with the Session printers setting can vary according to conditions where the session was initiated,

such as location (by filtering on objects such as subnets).

Note: For printers in domains that do not have a trust relationship with the XenApp farm, disable the Citrix policy settingDirect connections to print servers. When this setting is disabled, print jobs are routed through the client using the clientprinting 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 client devices, all users can add printing devices to be used in a

session. The only time users cannot add printers to their sessions is when they cannot access their client device because

they are using a thin client and there are no applications published that let them browse and add printers.

Printers that users create on their own during a session are known as retained printers because they are created again (or

remembered) at the start of the next session. When XenApp recreates a retained printer at the start of a session, it

considers all Citrix policy settings except Auto-create client printers.

Retained printers appear in sessions on that device until the client printer within the session is deleted manually, the

remembered printer connection is removed from the client’s properties store, or the client-side printer is inaccessible.

Users might need to use the PrintCfg.exe tool to add printers if they cannot browse to the printer from within the session

or cannot access their client desktop. If they use this tool, the printers are routed along the client printing pathway.

Device or Session-Based Print Settings

By default, all changes users make to the printer device settings and preferences, whether in a session or working on their


local computer, are saved and used locally and in a session. This means that printer settings and preferences are always the

same on the client device and in a session. Citrix policy settings let you change the way XenApp software saves and applies

printer device settings and preferences.

You can configure sessions to obtain print settings, specifically user printing preferences, from either the printer object or

the printing device.

XenApp can write printer settings to the printer object at the end of a session or to a client printing device, provided the

user’s network account has sufficient permissions. By default, XenApp plug-ins use the settings stored in the printer object

in the session, before looking in other locations for settings and preferences.

The main reason you want sessions to obtain their print settings from the printing device is if Windows users make changes

to local printers outside of sessions (that is, on their local computer offline). Non-Windows plug-ins synchronize changes

made out of sessions automatically.

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

To understand how printing preferences are retained and applied, you must understand:The locations printing settings can be stored in a XenApp environment

The priority XenApp software uses to apply printing preferences from previous sessions to the printers in a newly created

session

Where XenApp software stores printing preferences by default and if there are factors in your environment that will

prevent the software from successfully storing them in this location (that is, when you need to change this setting)

General Locations of Printing PreferencesIn Windows printing environments, changes made to printing preferences can be stored on the local computer or in a

document. In a XenApp environment, when users modify printing settings, the settings are stored in these locations:

On the client device itself . The settings are set on the client device by right-clicking the printer in the Control Panel

and selecting Printing Preferences. For example, if Landscape is selected as page orientation, landscape is saved as the

default page orientation preference for that printer. This type of preference is known as Device Settings.

Inside of a document . In word-processing and desktop-publishing programs, settings, such as page orientation, are

often stored inside documents. These settings are often referred to as Document Settings. For example, when you



queue a document to print, Microsoft Word typically stores the printing preferences you specif ied, such as page

orientation and the printer name, inside the document. These settings appear by default the next time you print that

document.

From changes a user made during a session. XenApp keeps only changes to the printing settings of an auto-created

printer if the change was made in the the Control Panel in the session; that is, on the server.

On the server. These are the default settings associated with a particular printer driver on the server.

If you want to control user printing preferences, it is important to understand that the settings preserved in any Windows-

based environment vary according to where the user made the changes. This also means that the printing settings that

appear in one place, such as in a spreadsheet program, can be different than those in others, such as documents. As result,

printing settings applied to a specific printer can change throughout a session.

Hierarchy of Users’ Printing PreferencesBecause printing preferences can be stored in multiple places, XenApp processes them according to a specific priority. Also,

it is important to note that Device Settings are treated distinctly from, and usually take precedence over, Document

Settings.

XenApp searches for settings in this order:

1. XenApp checks for retained printer settings.

If XenApp finds retained settings, it applies these settings when the user prints.

2. If there are no retained printer settings, XenApp searches for any changes to the printer settings for the default printer

for the client device.

If XenApp finds any changes to printing preferences on the client device, it applies these settings when the user prints.

3. If there are no retained or client printer settings, XenApp applies the default printer settings stored on the server when

the user prints.

At this point, the printer settings are merged. Generally, XenApp merges any retained settings and the settings inherited

from the client device with the settings for the default printer driver on the server.

By default, XenApp always applies any printing settings a user modified during a session; that is, the retained settings,

before considering any other settings.

Saving Users’ Printing PreferencesBy default, XenApp attempts to store printing properties, a combination of the user’s printing preferences and printing

device-specific settings, on the client device. If the client does not support this operation, XenApp stores printing properties

in its user profile for that user. Sessions from non-Windows XenApp plug-ins or even older Windows XenApp plug-ins use the

user profiles on the server for properties retention. You can use the Printer Properties Retention policy rule to force

properties to be saved on either the client or on the server.

If one of the following apply, you might need to reconfigure how XenApp stores user printing preferences:

Client version. Not all XenApp plug-ins allow users to store printer properties on a client device. Users must be running

Citrix Presentation Server Client 9.x and higher to store user-modif ied printer properties on the client device.

Type of Windows user prof ile. That is, if you are using local, roaming, or mandatory profiles on your Windows network.

If you are using a mandatory profile and you want to retain the user’s printer properties, you must store the properties

on the client device.


Farm Size. If you have a large farm and you are load balancing applications, users will experience inconsistent printing

behavior and properties if you use local profiles. The only way you can get consistent printing behavior is to save the

printer properties on the client device.

Type of workers. If you have mobile or remote workers and you are using roaming profiles, you must save the printer

properties to the user’s profile and not the client device.

If none of these factors apply to you, Citrix recommends you not change where the printer properties are stored. Leaving

the default setting, which saves the printer properties on the client device, is the easiest way to ensure consistent printing

properties.

You can specify whether you want these settings stored on the client device or with the user’s profile. You can also change

this default behavior so settings are not stored. However, before you make these decisions, you must understand how

XenApp determines what print settings it applies and also what the difference is between storing print settings on the

client device or with a profile.

Setting Default Printers

The printer that XenApp selects for a session’s default printer can be based on:

A network printer you specify as the default

The default printer on the client device

If you want to base the default session printer on either of these, use the Citrix policy setting Default printer. See To

specify a default printer for a session for details.

However, if you specified that XenApp auto-create the default client printer, then, if no other printers are provisioned in

sessions, you might not need to specify a default session printer.

Printing and Mobile Workers

In situations where users move among different workstations or sites, you can make sure that the closest printers are

presented to them wherever they try to print. Examples of such users include hospital workers who move among

workstations in different wings of a hospital, reconnecting to the same session using a smart card, or employees who travel

to remote business units.

If you have mobile workers and need this type of printing functionality, use one of these features:

SmoothRoaming

Proximity Printing

Also known as Workspace control, this feature lets a user disconnect from one session, move to another device, and

reconnect to continue that same session. The printers assigned on the first client device are replaced on reconnection with

the printers designated on the second client device. As a result, users are always presented with applicable printer options

from wherever they connect.

This feature lets you control the assignment of network printers so that the most appropriate printer is presented, based

on the location of the client device.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-printing-configuring-all.html


The Proximity Printing solution is enabled through the Citrix policy setting Default printer.

Proximity Printing can make administration easier even if you do not have mobile workers. For example, if a user moves from

one department or floor to another, you do not need to assign additional printers to that user if Proximity Printing is

implemented. When the workstation is recognized within the new location’s IP address range, it has access to all network

printers within that range.

However, if you configure Proximity Printing, you must maintain the Session printer policy. For example, as network printers

are added or removed, you must update this policy to reflect the current set of network printers. Likewise, if you modify

the DHCP IP address ranges for floors or departments, you must update this policy.

Proximity Printing requires that you can f ilter the policy on some type of geographic indicator, such as:The name of the workstation, if the name relates to the workstation’s location

Your network’s IP addresses, if they correlate with user locations

Optimizing Printing Performance by Routing

In a XenApp environment, you can control how print jobs destined for network printers are routed. Jobs can take two paths

to a network printing device: along the client or network printing pathway.

By default, XenApp routes print jobs along the client printing pathway as follows:

Auto-created client printers. XenApp routes jobs to locally attached printers from the server, through the client, and

then to the print device. The ICA protocol compresses the print job traff ic. When a printing device is attached locally to

the client device, the jobs must be routed through the plug-in.

Auto-created network printers. By default, all print jobs destined for network printers route from the server, across

the network, and directly to the print server. However, if the application server and the print server are on different

domains, XenApp automatically routes the print job through the plug-in.

When network printers are visible from the server, you can use policies to control how print jobs are routed to network

printers. You can configure that jobs be routed to network printers:

Through the plug-in. This is accomplished by auto-creating the network printer but specifying its jobs to route through

the plug-in.

Over the network. This is accomplished either by leaving the default settings so that the network printer is auto-

created (or configuring a policy to do this) or by provisioning the network printer through the Session printers policy rule.

Routing jobs along the network printing pathway is ideal for fast local networks and when you want users to have the

same user experience that they have on their local client device (that is, when you want the printer names to appear the

same in every session).

However, print jobs relayed using the network printing pathway are not suited to WANs. The spooling of print jobs using the

network printing pathway method uses more bandwidth than using the client pathway; many packets are exchanged

between the host server and the print server. Consequently, users might experience latency while the print jobs are spooling

over the WAN. Also, the print job traffic from the server to the print server is not compressed and is treated as regular

network traffic.

When printing jobs across a network with limited bandwidth, Citrix recommends routing jobs through the client device so

that the ICA protocol compresses the jobs. To do so, disable the Citrix policy setting Direct connections to print servers.


Managing Printer Drivers

During printer auto-creation, if XenApp detects a new local printer connected to a client device, it checks the server hosting

the published application (from which the user is trying to print) for the required printer driver. By default, XenApp

automatically installs a native driver if one is not found on the server hosting the published application.

Because users in a XenApp environment do not have a persistent workspace, drivers cannot be stored on the client. To print

to a local device, XenApp must find the correct driver on: (a) its server or in the server’s Windows operating system, and (b)

the client device. The diagram that follows shows how the printer driver is used in two places for client printing.

This diagram shows client printing to a local printer: The printer driver on the server routes the job over the ICA channel tothe client device. The client device then routes the print job through the same printer driver, which is accessible on the clientdevice. The printer driver on the client device relays the print job to the print spooler on the client device, which in turnroutes the print job to the local printer.

The printer driver on the server and the driver used by the client device must match exactly. If not, printing fails. As a result,

XenApp provides features to manage drivers, install them automatically, and replicate them across your farm.

The following problems can arise from not managing client printer drivers correctly:

Any missing drivers can prevent users from printing successfully. If a third-party printer driver has multiple or inconsistent

names across your farm, a session might not be able to f ind 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-specif ic printer driver for the XenApp server's operating system (version and

bit depth) must be installed on the XenApp server. Two print servers are not required.

If a defective driver is replicated throughout a server farm, it is diff icult and time consuming to remove it from every

server to prevent its use with client printers.

When planning your driver management strategy, determine if you will support device-specific or the Universal Printing driver,

or both.

If you support standard drivers, you also need to determine:


What types of drivers you want to support

If you want printer drivers automatically installed when they are missing on farm servers

If you want to create driver compatibility lists

If you want to replicate drivers across your farm servers automatically


Planning Your Printing Configuration

May 07, 2015

Choosing the most appropriate printing configuration options for your needs and environment can simplify administration.

Without performing any printing configurations, users can print in most environments. However, users might not get the

printing experience they expect and default printing configurations might not be appropriate for your environment.

Your printing configuration depends upon:

Your business needs and your existing printing infrastructure. Design your printing configuration around the needs of

your organization. Your existing printing implementation (user’s ability to add printers, which users have access to what

printers, and so on) might be a useful guide when defining your XenApp printing configuration.

If your organization has security policies that reserve printers for certain users (for example, printers for Human

Resources or payroll).

If users need to print while away from their primary work location; for example, workers who move between

workstations or travel on business.

When designing your printing configuration, try to give users the same experience in a session as they have when they print

when working on their local client devices.

Updated: 2015-05-08

By default, if you do not configure any policy rules, XenApp printing behavior is as follows:

All printers configured on the client device are created automatically at the beginning of each session. This behavior is

equivalent to configuring the Citrix policy setting Auto-create client printers with the Auto-create all client printers

option.

XenApp routes all print jobs queued to printers locally attached to client devices as client print jobs (that is, over the ICA

channel and through the client device).

XenApp routes all print jobs queued to network printers directly from the server hosting the published application. If

XenApp cannot route the jobs over the network, it will route them through the client device as a redirected client print

job. This behavior is equivalent to disabling the Citrix policy setting Direct connection to print servers.

XenApp retains all properties and settings users configure for printers they provision themselves in sessions. XenApp

stores printing properties on the client device. If the client device does not support this operation, XenApp stores printing

properties in the user profile for that user. This behavior is equivalent to configuring the Citrix policy setting Printer

properties retention with the Held in profile only if not saved on client option.

XenApp uses the Windows version of the printer driver if it is available on the server hosting the application. If the printer

driver is not available, the XenApp server attempts to install the driver from the Windows operating system. If the driver is

not available in Windows, it uses one of the Citrix Universal printer drivers. This behavior is equivalent to enabling the Citrix

policy setting Automatic installation of in-box printer drivers and configuring the Universal printing setting with the Use

universal printing only if requested driver is unavailable.

Note: If you are unsure about what the shipping defaults are for printing, display them by creating a new policy and settingall printing policy rules to Enabled. The 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)

How print jobs are routed

How printer drivers are managed

You can have different printing configurations for different client devices or users or any other objects on which policies are

filtered. You must understand the ramifications of setting the options in printing policies, so review the information in the

printing topics carefully before configuring them. See Configuring and Maintaining XenApp Printing for configuration details.

Client printing can, potentially, let a user from one session use another user’s printer in a different session. Unlike network

printer connections, client printers auto-created in a XenApp session are local printers managed by the local print provider

and Citrix spooler extensions. The local print provider maintains a single shared namespace for all local printers on a server.

This means that a user’s client printers may be visible and potentially accessible to users from other sessions on the server.

By default, the XenApp printer naming convention helps combat this problem by avoiding the potential for printers and

ports to be shared between sessions. Printers connected through a pass-through server use the session ID to identify the

printer uniquely, keeping the remainder of the name the same. This allows the user to identify both the printer and client it

is connected to, without identifying which pass-through server through which it might have connected.

In addition, to increase client printing security, access to the client printers is restricted to:

The account that the print manager service runs in (default: Ctx_cpsvcuser)

Processes running in the SYSTEM account such as the spooler

Processes running in the user’s session

Windows security blocks access to the printer from all other processes on the system. Furthermore, requests for services

directed to the print manager must originate from a process in the correct session. This prevents bypassing the spooler and

communicating directly with CpSvc.exe.

As an administrator, 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 f lag todefault print f lags 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.


http://www.citrix.com/ready


Configuring and Maintaining XenApp Printing

May 08 , 2015

Most XenApp printing functions are configured through the following Citrix policy categories and settings:Client printers. The settings in this category affect the client redirected printers and printing using the client printing

pathway.

Drivers. The settings in this category control driver management.

Printer redirection bandwidth limit . This setting restricts the bandwidth allocated to printers.

Session printers. This setting configures how network printers are provisioned.

If you do not enable any settings that affect printing, XenApp uses the default printing behavior that is described in

Planning Your Printing Configuration.

Printing settings follow standard Citrix policy behavior:

Printing settings are evaluated during initial logon and remain in force throughout the session. Any new printers added to

a policy or a user device during a session do not appear in the session until the user logs off and logs on, creating a new

session.

The policies are f iltered on standard objects that apply to all Citrix policy settings. Therefore, when configuring printing

settings, determine which f ilter 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 specif ic

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.

Configure the Citrix policy setting Auto-create client printers to control how or if printers are created automatically at the

start of sessions. By default, this setting is not enabled, so XenApp creates all printers on the user device.

To modify printer auto-creation behavior

Configure one of the following in the Auto-create client printers setting:

Do not auto-create client printers. Client printers are not auto-created.

Auto-create the client’s default printer only. Only the client’s default printer attached to or mapped from the client

preconfigured in the Control Panel is auto-created in the session.

Auto-create local (non-network) client printers only. Any non-network printers attached to the client device

preconfigured in the Control Panel are auto-created in the session.

Auto-create all client printers. All network printers and any printers attached to or mapped from the user device

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-printing-planning.html


preconfigured in the Control Panel are auto-created in the session.

To configure legacy client printer support

To auto-create client printers with legacy printer names and preserve backward compatibility for users or groups usingMetaFrame 3.0 or earlier, choose the Legacy printer names option from the Citrix policy Client printer names setting.

There are several different Universal Printing solutions. You can configure:

Citrix XPS Universal Printer driver

Citrix Universal Printer driver, which is EMF-based

Auto-created Citrix Universal Printer with a Citrix Universal printer driver

Configuring only a Universal printer driver will not improve session start time (printers on the client device are still enumerated

and auto-created at the beginning of sessions). However, configuring a Universal printer driver does improve printer driver

performance.

To configure universal printing

Configure the Citrix policy setting Universal Printing by using the following settings:Auto-create generic universal printer. Enables or disables the auto-creation of the Citrix Universal Printer generic printing

object. By default, generic universal printers are not auto-created.

Universal driver priority. Specif ies the order in which XenApp attempts to use universal printer drivers, beginning with the

first entry in the list. You can add, edit, or remove drivers and change the order of the drivers in the list.

Universal printing. Specif ies when to use universal printing.

Universal printing preview preference. Specif ies whether to use the print preview function for auto-created or generic

universal printers.

To change the default settings on the Universal Printer

You can change the default settings for the Citrix Universal Printer, including settings for paper size, paper width, print

quality, color, duplex, and the number of copies. You override the default settings of the Citrix Universal Printer and modify

these settings by manually setting registry keys. For a list of the specific registry values, see the Citrix Knowledge Center.

For more information, see Configuring Universal Printer Drivers on Farm Servers.

If automatic printer creation fails for network printers on a client device or for session printers because the corresponding

drivers are not installed automatically by Windows (because you configured a policy setting preventing auto-installation or

they are third-party drivers), you must add the corresponding drivers to your farm servers manually.

1. Add printers to the XenApp server by manually installing the printers. You can use the Add Printer wizard in Windows or

browse to the server on which the printer is installed and double click the printer, which forces Windows to place the

drivers in its local driver store.

2. Delete the printers. Deleting the printers ensures that they are created only when intended; that is, only if the client has

that network printer installed or the GPO with Session printers configured uses f iltering and applies to only a subset of

all users of the XenApp server.



To add a network printer while configuring the Session printers setting

In the Citrix policy setting for Session printers, add a network printer using one of the following methods:

Printer UNC path. Enter the path using the format \\servername\printername.

Browse. Locate a printer on the network.

Browse for printers on a specif ic server. Enter the server name using the format \\servername and click Browse.

Important: The server merges all enabled session printer settings for all applied policies, starting from the highest to lowestpriorities. When a printer is configured in multiple policy objects, custom default settings are taken from only the highestpriority policy object in which that printer is configured.

To specify a default printer for a session

To specify a network printer, it must already be added to the policy in which you are enabling the Citrix policy settingDefault printer.1. Complete the procedure, To add a network printer while configuring the Session printers setting.

2. On the Default printer settings page, from the Choose client’s default printer drop-down list, choose one of the

following:

Name of the network printer you want to be default for this policy. Printers that were added with the Session

printers policy setting are displayed in this drop-down menu and can be specif ied as the default printer.

Set default printer to the client’s main printer. Sets the default printer for the session to the client’s current default

printer. If the client's main printer is not mapped, this option has no effect.

Important: Mapping for the client’s main printer can also be disabled through other policies, group policies, or Remote

Desktop Services settings.

Do not adjust the user’s default printer. Uses the current Remote Desktop Services or Windows user profile setting

for the default printer. If you choose this option, the default printer is not saved in the profile and it does not change

according to other session or client properties. You can use this option to present users with the nearest printer

through profile settings (functionality known as Proximity Printing).

When Do not adjust the user’s default printer is selected, the default printer in a session will be the first printer

autocreated in the session, which is either:

The f irst printer added locally to the Windows server in the Control Panel

The f irst autocreated printer, if there are no printers added locally to the server

3. Apply the policy to the group of users (or other f iltered objects) you want to affect.

To edit the printer settings in the sessions policy

1. On the Session printers settings page, select the name of the printer for which you want to modify the settings.

2. Click Settings.

3. Check Apply customized settings.

4. Change the settings for Paper Size, Copy Count, Print Quality, and Orientation.

5. To ensure that the settings you specify here are restored in concurrent sessions even if users modify them in their initial

session, select the Apply customized settings at every logon check box.

This check box applies to additional sessions opened while the user’s first session is still active.

Important: The type of Windows profiles configured in your environment change the effect of settings. For more

information, see Controlling Printing Settings and User Preferences.

If you clear this check box and a user opens his or her initial session, changes these printer settings, and then opens a


http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-printing-concepts-wrapper-v2.html


second session (while the first session is still active), the settings you specified in this dialog box are not carried over to

the second session.

For example, if you specified Landscape as a custom Orientation setting, the check box is selected, a user starts a

session (Session1), the user changes the Orientation to Portrait, and then starts another simultaneous session (Session2),

Session2 uses your custom settings and the Orientation is Landscape. If you clear Apply customized settings at every

logon, XenApp carries the user’s changes into Session2 so the Orientation is Portrait.

After clicking OK, the Settings value in the list of printers on Session printers page changes to Modif ied.

To configure server local printers

To let users connecting to the farm print to a printer that is local to a farm server, physically connect the printer to a farm

server and share it as follows:

1. On the server where the printer is physically connected, in Control Panel > Hardware > Devices and Printers, right-click

the printer you want to share.

2. Choose Printer Properties.

3. In the Sharing tab, select these check boxes:

Share this printer

Render print jobs on client computers

Sharing the printer allows creation of the printer when a session on that server is launched.

When you want to make sure that users always see the closest printer to their client device in a session, configure the

Proximity printing solution. Proximity printing enables users within a specified IP address range to automatically access the

network printing devices that exist within that same range.

The ability to configure proximity printing assumes that your network is designed as follows:It uses a DHCP server to assign your users’ IP addresses by their location (for example, f loor of a building)

All departments/floors within the company have unique designated IP address ranges

Network printers are assigned IP addresses within the range of IP addresses for the department/floor in which they are

located

To configure Proximity Printing using IP addresses

1. Create a separate policy for each subnet (or to correspond with printer location).

2. In each policy, add the printers in that subnet’s geographic location to the Session printers setting.

3. Set the Default printer setting to Do not adjust the user's default printer.

4. Filter the policies by Client IP address.

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 networkwith limited bandwidth, Citrix recommends routing jobs through the client device so that the ICA protocol compresses thejobs. To do so, disable the Citrix policy setting Direct connection to print servers.


The following groups of users cannot add printers to sessions unless you publish printer provisioning tools for them:

Windows users who do not have access to the Add Printer wizard on the local client device or any applications that let

them browse to printers

Non-Windows plug-in users

If you want these users to add printers on their own, publish either:

The ICA Client Printer Configuration Tool (PrintCfg.exe). This tool lets Windows CE and DOS users add printers.

The Add Printer wizard. Publishing this Windows wizard lets users with Windows plug-ins add printers that are on the

local client device or network. Publishing this wizard is also referred to sometimes as publishing the Print Manager.

After a user adds printers using either of these methods, XenApp retains the printer information for the next time a user

logs on from that client device. Client printers created using this process are considered retained printers.

To publish the Windows Add Printer wizard

This procedure assumes that you already published Windows Explorer on the server on which you want to publish the AddPrinter wizard.1. Create the following folder at the root level of one of the XenApp server’s drives: C:\Printers.{2227A280-3AEA-1069-

A2DE-08002B30309D} where C represents a drive on the XenApp server.

When you press Enter, the folder icon changes to a printer icon.

2. Create a published application with the following properties:

Command line. “Path of explorer.exe” C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}

Working directory. The path where explorer.exe is located.

If you get a path error and cannot access the published printers folder, modify the command line to include %*. For

example,

Command line. “Path of explorer.exe” %*C:\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}

To publish the ICA Client Printer Configuration Tool

1. Follow the instructions for publishing an application in To publish the Windows Add Printer wizard.

2. On the Location page, enter the path for the ICA Client Printer Configuration tool (printcfg.exe) on your server.

On a 64-bit system, the default location for the tool is C:\Program Files (x86)\Citrix\system32\printcfg.exe.

On a 32-bit system, the default location for the tool is C:\Program Files\Citrix\system32\printcfg.exe.

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. Selected by default. Allows the system to determine the method. It stores

printer properties on the client device, if available, or if not, in the user profile. Although this option is the most f lexible, it

can also slow logon time and use extra bandwidth to perform the needed system-checking.

Choose this option if your server farm requires backward compatibility with prior versions of XenApp and its plug-ins and

is not constrained by bandwidth or logon performance.



Saved on the client device only. Stores printer properties only on the client device. If users are assigned a Remote

Desktop Services mandatory profile or roaming profile, select this option.

Retained in user profile only. Stores printer properties in the user profile on the server and prevents any properties

exchange with the client device. This option is useful if your system is constrained by bandwidth (this option reduces

network traff ic) and logon speed or your users use legacy plug-ins. Use this option with MetaFrame Presentation Server

3.0 or earlier and MetaFrame Presentation Server Client 8.x or earlier. Note that this is applicable only if a Remote

Desktop Services roaming profile is used.

Do not retain printer properties. Does not retain printer properties.

To obtain printer properties directly from the printer itself , rather than from the properties store, use the followingprocedure. This procedure ensures that changes made off line to printers on the local computer are used next time a userstarts 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 Editorat your own risk. Be sure to back up the registry before you edit it.1. Open the Registry Editor and navigate to one of the following registry locations:

For 64-bit, HKLM\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences

For 32-bit, HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Preferences

2. Create the following registry key: Name:Win32FavorRetainedPrinterSettings Data Type: REG_SZ Value Data: false

3. Restart the Citrix Print Manager Service.

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

When users log on:XenApp checks the client printer driver compatibility list before it sets up the client printers

If a printer driver is on the list of drivers that are not allowed, XenApp does not set up the printer unless the Universal

Printing policy setting is enabled

When the compatibility list prevents setup of a client printer, XenApp writes a message in the server’s Event log

To prevent drivers from being installed automatically, configure the Citrix policy setting Automatic installation of in-box

printer drivers.

To specify how client printer drivers are installed on XenApp servers

To specify how client printer drivers are installed on the XenApp servers, configure the following Citrix policy settings:

Automatic installation of in-box printer drivers. Controls whether printer drivers from the Windows in-box driver set or


from driver packages staged on the host using pnputil.exe /a are automatically installed when auto-creating either a

client or network printer. By default, these drivers are installed as needed. Disabling this setting prevents the automatic

installation of printer drivers.

Printer driver mapping and compatibility. Lists driver substitution settings for auto-created printers. Allows or prevents

printers to be created with the specif ied driver. Additionally, you can allow created printers to use only universal printer

drivers.

To control the automatic installation of printer drivers

Configure the Citrix policy setting Automatic installation of in-box printer drivers (enabled by default). This setting allowsXenApp to install Windows native printer drivers (the Windows in-box driver set or from driver packages staged on the hostusing 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.

To add or remove drivers or edit driver names in the compatibility list

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. The XPS Universal printer driver can be

configured as the default by configuring the Citrix policy setting Universal driver priority.

The Citrix Universal printer drivers are listed in the Print Management MMC snap-in. Provided all prerequisites for the driverwere installed when you ran XenApp Setup, the following drivers appear:

Citrix Universal Printer, which is the .EMF driver

Citrix XPS Universal Printer

HP Color LaserJet 2800 PS (Citrix PS Universal Printer Driver)

If you need a Universal driver that does not appear in this list, you must install it .

To specify the Universal Printer driver for sessions

Configure the Citrix policy setting Universal printing by choosing one of the following:

Use only printer model specif ic drivers. Specif ies that the client printer uses only the native drivers that are autocreated

at logon. If the native driver of the printer is unavailable, the client printer cannot be autocreated.

Use universal printing only. Specif ies that the client printer uses the universal printer driver only. Select this option if you

do not want to use native drivers.

Use universal printing only if requested driver is unavailable. Uses native drivers for client printers if they are available. If the

driver is not available on the server, the client printer is created automatically with the highest available universal driver, as

specif ied in the Universal driver priority policy setting.


Use printer model specif ic drivers only if universal printing is unavailable. Specif ies that the client printer uses universal

printer driver if it is available. If the driver is not available on the server, the client printer is created automatically with the

appropriate native printer driver.

To change the default Citrix Universal Printer driver

To force XenApp to use the Citrix XPS Universal Printer driver before the EMF-based Citrix Universal Printer driver, configure

the Citrix policy setting Universal driver priority 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.

You can use the printer driver remapping feature to substitute:Good printer drivers for outdated or corrupted drivers

Specif ic Windows printer drivers for manufacturer’s client printer drivers

A driver that is available on Windows server for a client driver name

Each client provides information about client-side printers during logon, including the printer model name. During client

printer autocreation, Windows server printer driver names are selected that correspond to the printer model names provided

by the client. The autocreation process then employs the identified, available printer drivers to construct redirected client

print queues.

To map client printer drivers to server printer drivers

Configure the Citrix policy setting Printer driver mapping and compatibility by adding the client printer driver name and

selecting the server driver that you want to substitute for the client printer driver from the Find printer driver menu. You can

use wildcards in this setting. For example, to force all HP printers to use a specific driver, specify HP* in the policy setting.

To edit printing settings for mapped client printer drivers

After you have added a client printer driver to the list of mapped drivers, you can modify the printing settings for the driver.This setting overrides retained printer settings the user set during a previous session.You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If you specify a

printing option that the printer driver does not support, that option has no effect.

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 f iles 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 networksor dial-up connections. To prevent such degradation, you can limit the bandwidth used by client printing.Important: The printer bandwidth limit is always enforced, even when no other channels are in use.By limiting the data transmission rate for printing, you make more bandwidth available in the ICA data stream for

transmission of video, keystrokes, and mouse data. More available bandwidth can help prevent degradation of the user

experience during printing.

There are two ways you can limit printing bandwidth in client sessions using printer settings in the Bandwidth category:

Use the Citrix policy Bandwidth printer settings in the Delivery Services Console to enable and disable the printing

bandwidth session limit for the farm.

Use individual server settings to limit printing bandwidth in the server farm. You can perform this task using gpedit.msc

locally on each server to configure the Citrix policy Bandwidth printer settings.

You can use the Citrix Session Monitoring and Control Console (included in the WFAPI SDK) to obtain real-time information

about printing bandwidth. The print spooling virtual channel control (that is, the CTXCPM Client printer mapping virtual

channel control) lets you set a priority and bandwidth limit for bandwidth control of this virtual channel.

To configure a printing bandwidth setting in an existing policy

Configure one of the options in the Citrix policy Bandwidth setting. If you enter values for both settings, the most


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.

To limit printer bandwidth for a server

Using the Window Group Policy Editor locally on a server, configure one of the options in the Citrix policy Bandwidth setting.

If you enter values for both settings, the most restrictive setting (with the lower value) is applied.

Printer redirection bandwidth limit to specify the bandwidth available for printing in kilobits per second (kbps).

Printer redirection bandwidth limit percent to limit the bandwidth available for printing to a percentage of the overall

bandwidth available.

Note: If you want to specify bandwidth as a percentage using the Printer redirection bandwidth limit percent setting,

you must enable the Overall session bandwidth limit as well.

The following table summarizes where you can manage and modify print queues and display printers in a XenApp

environment. For definitions of the terms client printing pathway and network printing pathway, see Overview of Client and

Network Printing Pathways. Client printing pathway is not synonymous with printers attached to client devices.

Printing Pathway UACEnabled?

Location

Client printers (Printers attached to Client printing On Print Management snap-in in the

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-printing-concepts-wrapper-v2.html


the client device) pathway Microsoft Management Console

Off Control Panel

Network printers (Printers on anetwork print server)

Client printingpathway

On Print Management snap-in in theMicrosoft Management Console

Off Control Panel

Network printers (Printers on anetwork print server)

Network printingpathway

On Print Server > Print Managementsnap-in in the MicrosoftManagement Console

Off Print Server > Control Panel

Server local printers (Shared printerslocally attached to a XenApp server)

N/A On Control Panel

Off Control Panel

Local network server printers (Printersfrom a network print server that areadded to server running XenApp)

Network printingpathway

On Control Panel

Off Control Panel

Printing Pathway UACEnabled?

Location

Managing Printers Using the Network Printing Pathway

If you want to modify or manage a user’s network print queue that a user printed to across the network printing pathway,

you must manage it through Control Panel on the print server with the correct level of Windows administrator privileges.

Print queues for network printers that use the network printing pathway are private and cannot be managed through

XenApp.

Whenever you configure a network printing pathway and the server hosting the application does not have or cannot install

the driver, by default, XenApp sends the print job along the client printing pathway. You can tell a job sent to the network

printer is redirected along the client printing pathway when you see printers appearing in the Windows Server Manager

Snap-in > Print and Document Services role that has the following syntax:

PrinterName on PrintServer (from clientname) in session n

where:

PrinterName is the name of the printer being redirected

PrintServer is the name of the print server with which the printer is associated

clientname is the name of the client through which the print job is being rerouted

n is the session ID for that ICA connection


For example, Dell Laser Printer 1710n Ps3 on 3r41-2 (from 3R39-2) in session 2.

Displaying Printers Using the Client Printing Pathway

If UAC is not enabled, you can, however, display and manage redirected client print queues and server local printers through

Control Panel > Printers of individual servers. The client printers displayed on a server fluctuate based on what sessions are

active on a server because XenApp creates these printers based on the printers on the connecting client devices. You can

display client printers in Control Panel > Printers.

1. On the XenApp server that is hosting the session for which you want to display the printers, install the Print Services

server role.

2. In Administrative Tools, open the Print Management stand-alone snap-in.

3. To display client redirected printers, in the Print Management tree, select Print Management > Custom Filters > All

Printers. The Print Management snap-in displays the client printers redirected from all clients connected to that server.

You can display and manage the print queues for these printers and select Printers With Jobs in the Print Management

Tree to display active jobs on redirected printers.

1. On the XenApp server, open Control Panel > Printers.

The Printers screen displays the local printers mapped to the ICA session. By default, the name of the printer takes theform printername (from clientname) in session x; for example, “printer01 (from machine01) in session 7.” Printername is thename of the printer on the client device, clientname is the unique name given to the client device or the Web Interface, andx is the SessionID of the user’s session on the server.


XenApp Server Utilities Reference

Jun 06, 2012

Citrix XenApp server utilities provide an alternative method to using the console for maintaining and configuring servers and

farms. Citrix XenApp server utilities must be run from a command prompt on a server running Citrix XenApp.

Command Description

altaddr Specify server alternate IP address.

app Run application execution shell.

auditlog Generate server logon/logoff reports.

ctxkeytool Generate farm key for IMA encryption.

ctxxmlss Change the Citrix XML Service port number.

dscheck Validate the integrity of the server farm data store.

dsmaint Maintain the server farm’s data store.

enablelb Enable load balancing for servers that fail health monitoring tests.

icaport Configure TCP/IP port number used by the ICA protocol on the server.

imaport Change IMA ports.

query View information about server farms, processes, ICA sessions, and users.


Performance Counters Reference

May 01, 2015

Performance monitoring counters that directly relate to the performance of sessions, networking, and security are installed

with XenApp. You can access these counters from the Performance Monitor, which is part of Windows operating systems.

Use performance monitoring to obtain system performance data and the effects of configuration changes on system

throughput.

Using the standard Windows procedure, you can add and then view the following categories of XenApp-related counters,

called performance objects in Performance Monitor:

Citrix CPU Utilization Mgmt User

Citrix IMA Networking

Citrix Licensing

Citrix MetaFrame Presentation Server

ICA Session

Secure Ticket Authority

The following counters are available through the Citrix CPU Utilization Mgmt User performance object in PerformanceMonitor.

Counter Description

CPU Entitlement The percentage of CPU resource that Citrix CPU Utilization Management makesavailable to a user at a given time.

CPU Reservation The percentage of total computer CPU resource reserved for a user, should thatuser require it.

CPU Shares The proportion of CPU resource assigned to a user.

CPU Usage The percentage of CPU resource consumed by a user at a given time, averagedover a few seconds.

Long-term CPU Usage The percentage of CPU resource consumed by a user, averaged over a longerperiod than the CPU Usage counter.

The following counters are available through the Citrix IMA Networking performance object in Performance Monitor.

Counter Description

Bytes Received/sec The inbound bytes per second.

Bytes Sent/sec The outbound bytes per second.


Network Connections The number of active IMA network connections to other IMA servers.Counter Description

The following counters are available through the Citrix Licensing performance object in Performance Monitor.

Counter Description

Average License Check-In Response Time (ms) The average license check-in response time in milliseconds.

Average License Check-Out Response Time (ms) The average license check-out response time in milliseconds.

Last Recorded License Check-In Response Time(ms)

The last recorded license check-in response time in milliseconds.

Last Recorded License Check-Out ResponseTime (ms)

The last recorded license check-out response time in milliseconds.

License Server Connection Failure The number of minutes that the XenApp server has beendisconnected from the License Server.

Maximum License Check-In Response Time The maximum license check-in response time in milliseconds.

Maximum License Check-Out Response Time The maximum license check-out response time in milliseconds.

The following counters are available through the Citrix MetaFrame Presentation Server performance object in PerformanceMonitor.

Counter Description

Application Enumeration/sec The number of application enumerations per second.

Application Resolution Time (ms) The time in milliseconds that a resolution took to complete.

Application Resolutions Failed/sec The number of application resolutions failed per second.

Application Resolutions/sec The number of resolutions completed per second.

Cumulative Server Load The combined processor utilization and connected XenApp user sessionloads for this server.

DataStore Connection Failure The number of minutes that the XenApp server has been disconnected fromthe data store.


DataStore bytes read The number of bytes read from the data store.

DataStore bytes read/sec The number of bytes of data store data read per second.

DataStore bytes written/sec The number of bytes of data store data written per second.

DataStore reads The number of times data was read from the data store.

DataStore reads/sec The number of times data was read from the data store per second.

DataStore writes/sec The number of times data was written to the data store per second.

DynamicStore bytes read/sec The number of bytes of dynamic store data read per second.

DynamicStore bytes written/sec The number of bytes of dynamic store data written per second.

DynamicStore Gateway Update Count The number of dynamic store update packets sent to remote datacollectors.

DynamicStore Gateway Update, BytesSent

The number of bytes of data sent across gateways to remote datacollectors.

DynamicStore Query Count The number of dynamic store queries that were performed.

DynamicStore Query Request, BytesReceived

The number of bytes of data received in dynamic store query requestpackets.

DynamicStore Query Response, BytesSent

The number of bytes of data sent in response to dynamic store queries.

DynamicStore reads/sec The number of times data was read from the dynamic store per second.

DynamicStore Update Bytes Received The number of bytes of data received in dynamic store update packets.

DynamicStore Update PacketsReceived

The number of update packets received by the dynamic store.

DynamicStore Update Response BytesSent

The number of bytes of data sent in response to dynamic store updatepackets.

DynamicStore writes/sec The number of times data was written to the dynamic store per second.

Filtered Application Enumerations/sec The number of f iltered application enumerations per second.

Counter Description


ICA Roundtrip Latency Median The median time of ICA roundtrip latency for all sessions on the server.

LocalHostCache bytes read/sec The number of bytes of IMA local host cache data read per second.

LocalHostCache bytes written/sec The number of bytes of IMA local host cache data written per second.

LocalHostCache reads/sec The number of times data was read from the IMA local host cache persecond.

LocalHostCache writes/sec The number of times data was written to the IMA local host cache persecond.

Maximum number of XML threads The maximum number of threads allocated to service Web-based sessionssince the server restarted.

Number of busy XML threads The number of busy threads.

Number of XML threads The number of threads allocated to service Web-based sessions.

Resolution WorkItem Queue ExecutingCount

The number of resolution work items that are currently being executed.

Resolution WorkItem Queue ReadyCount

The number of resolution work items that are ready to be executed.

WorkItem Queue Executing Count The number of work items that are currently being executed.

WorkItem Queue Pending Count The number of work items that are not yet ready to be executed.

WorkItem Queue Ready Count The number of work items that are ready to be executed.

Zone Elections The number of zone elections. This value starts at zero each time the IMAService starts and is incremented each time a zone election takes place.

Zone Elections Triggered The number of times a server triggers a zone election.

Zone Elections Won The number of times a server wins a zone election.

Counter Description

The following counters are available through the ICA Session performance object in Performance Monitor.

Counter Description

Input Audio Bandwidth The bandwidth, measured in bps, used when playing sound in an ICA session.


Input Clipboard Bandwidth The bandwidth, measured in bps, used when performing clipboardoperations such as cut-and-paste between the ICA session and the localwindow.

Input COM 1 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client COM 1 port.

Input COM 2 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client COM 2 port.

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

Input Control Channel Bandwidth The bandwidth, measured in bps, used when executing LongCommandLineparameters of a published application.

Input Drive Bandwidth The bandwidth, measured in bps, used when performing f ile operationsbetween the client and server drives during an ICA session.

Input Font Data Bandwidth The bandwidth, measured in bps, used when initiating font changes within aSpeedScreen-enabled ICA session.

Input HDX Mediastream for Flash DataBandwidth

The bandwidth, measured in bps, used when streaming Flash data in anHDX-enabled session.

Input Licensing Bandwidth The bandwidth, measured in bps, used to negotiate licensing during thesession establishment phase. Often, no data for this counter is available, asthis negotiation takes place before logon.

Input LPT 1 Bandwidth The bandwidth on the virtual channel that prints to a client printerattached to the client LPT 1 port through an ICA session that does notsupport a spooler. This is measured in bps.

Input LPT 2 Bandwidth The bandwidth on the virtual channel that prints to a client printerattached to the client LPT 2 port through an ICA session that does notsupport a spooler. This is measured in bps.

Input Printer Bandwidth The bandwidth, measured in bps, used when printing to a client printerthrough a client that has print spooler support enabled.

Input Seamless Bandwidth The bandwidth, measured in bps, used for published applications that arenot embedded in a session window.

Input Session Bandwidth The bandwidth, measured in bps, used from client to server for a session.

Input Session Compression The compression ratio used from client to server for a session.

Counter Description


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

Input SpeedScreen Data ChannelBandwidth

The bandwidth, measured in bps, used from client to server for data channeltraff ic.

Input Text Echo Bandwidth The bandwidth, measured in bps, used for text echoing.

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

Latency - Last Recorded The last recorded latency measurement for the session.

Latency - Session Average The average client latency over the lifetime of a session.

Latency - Session Deviation The difference between the minimum and maximum measured latencyvalues for a session.

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

Output Clipboard Bandwidth The bandwidth, measured in bps, used for clipboard operations such as cut-and-paste between the ICA session and the local window.

Output COM 1 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client COM 1 port.

Output COM 2 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client COM 2 port.

Output COM Bandwidth The bandwidth, measured in bps, used when receiving data from the clientCOM port.

Output Control Channel Bandwidth The bandwidth, measured in bps, used when executing LongCommandLineparameters of a published application.

Output Drive Bandwidth The bandwidth, measured in bps, used when performing f ile operationsbetween the client and server drives during an ICA session.

Output Font Data Bandwidth The bandwidth, measured in bps, used when initiating font changes within aSpeedScreen-enabled ICA session.

Output Licensing Bandwidth The bandwidth, measured in bps, used to negotiate licensing during thesession establishment phase. Often, no data for this counter is available, asthis negotiation takes place before logon.

Output HDX Mediastream for Flash The bandwidth, measured in bps, used when streaming Flash data in an

Counter Description


Data Bandwidth HDX-enabled session.

Output LPT 1 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client LPT 1 port.

Output LPT 2 Bandwidth The bandwidth, measured in bps, used when routing a print job through anICA session that does not support a spooler to a client printer attached tothe client LPT 2 port.

Output Management Bandwidth The bandwidth, measured in bps, used when performing managementfunctions.

Output Printer Bandwidth The bandwidth, measured in bps, used when printing to a client printerthrough a client that has print spooler support enabled.

Output Seamless Bandwidth The bandwidth, measured in bps, used for published applications that arenot embedded in a session window.

Output Session Bandwidth The bandwidth, measured in bps, used from server to client for a session.

Output Session Compression The compression ratio used from server to client for a session.

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

Output SpeedScreen Data ChannelBandwidth

The bandwidth, measured in bps, used from server to client for data channeltraff ic.

Output Text Echo Bandwidth The bandwidth, measured in bps, used for text echoing.

Output ThinWire Bandwidth The bandwidth, measured in bps, used from server to client for ThinWiretraff ic.

Resource Shares The total number of shares used by the session.

Counter Description

The following performance counters are available for the Secure Ticket Authority (STA).

Performance Counter Description

STA Bad Data Request Count The total number of unsuccessful ticket validation and data retrievalrequests during the lifetime of the STA.

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

STA Bad Ticket Request Count The total number of unsuccessful ticket generation requests received


during the lifetime of the STA.

STA Count of Active T ickets Total count of active tickets currently held in the STA.

STA Good Data Request Count The total number of successful ticket validation and data retrievalrequests received during the lifetime of the STA.

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

STA Good Ticket Request Count The total number of successful ticket generation requests receivedduring the lifetime of the STA.

STA Peak All Request Rate The maximum rate of all monitored activities per second.

STA Peak Data Request Rate The maximum rate of data requests per second during the lifetime of theSTA.

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

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

STA Ticket T imeout Count The total number of ticket time-outs that occur during the lifetime ofthe STA.

Performance Counter Description


Enhancing the User Experience With HDX

May 04 , 2015

HDX MediaStream for Flash allows you to move the processing of Adobe Flash content to user devices rather than using

network resources. This results in a high-definition experience when using Windows Internet Explorer to access Flash

content, including animations, videos, and applications. By moving the processing to the user device, HDX MediaStream for

Flash reduces server and network load, resulting in greater scalability.

HDX MediaStream for Flash supports all operating systems supported by Citrix XenApp 6 for Windows Server 2008 R2.

Requirements:

User device is Windows-based.

Citrix online plug-in 11.2 or 12.0 is installed on the user device.

Low latency LAN-type network connection is in use.

Adobe Flash Player 10 is installed on the user device and servers running XenApp.

Note: If an earlier version of the Flash Player is installed, or the Flash Player is not installed, Flash content is rendered on

the server.

Only Windows Internet Explorer browsers with ActiveX capabilities are supported (Windows Internet Explorer 7 and 8)

and should be available to the user device from the server.

HDX server-side installations on computers running Windows Server 2003 require the update contained in the Microsoft

Knowledge Base article KB956572, available from the Microsoft Web site.

To remove HDX MediaStream for Flash from the server, use the Uninstall a program option accessed in the Control Panel,

selecting Citrix HDX MediaStream for Flash - Server.

After installation on the server, HDX MediaStream for Flash is enabled for client-side acceleration by default. No further

configuration is needed. If you want to change the default settings, you can do so with the following Citrix User Policy

settings on the server:

Flash acceleration

Flash event logging



Flash URL blacklist

After installation on user devices and in the absence of any overriding Policy settings on the client, HDX MediaStream for

Flash is ready for use by your users. No further configuration is needed. If you want to change the default settings on the

user device, you can do so with the Group Policy Object Editor.

When users connect to an Adobe Flash application for the first time during a XenApp session, a dialog box appears advising

them to enable HDX MediaStream for Flash only if they trust the program to which they are connecting. Your users can

then enable or disable HDX MediaStream for Flash. The dialog box does not reappear during the current XenApp session,


but returns the first time the user accesses Flash content during future XenApp sessions. If users do not enable HDX

MediaStream for Flash, the Flash content plays on the server.

It is possible to add and configure the Group Policy Objects prior to installation on the client device. If the Group PolicyObjects are set to enable prior to installation, HDX MediaStream for Flash will be enabled on the user device and the dialogbox will not appear to the user.Caution:HDX MediaStream for Flash requires significant interaction between the user device and server components. Therefore, this

feature should only be used in environments where security separation between the user device and server is not needed.

User devices should be configured to use the HDX MediaStream for Flash feature only with trusted servers. HDX

MediaStream for Flash requires the Flash Player to be installed on the user device. Therefore, HDX MediaStream for Flash

should only be enabled if the Flash Player itself is secured.

To configure HDX MediaStream for Flash on the User Device with Group PolicyObjects

1. Create or select an existing Group Policy Object.

2. Import and add the HDX MediaStream for Flash - Client administrative template (HdxFlash-Client.adm), available in:

For 32-bit comput ers:For 32-bit comput ers: %Program Files%\Citrix\ICA Client\Configuration\language.

For 64 -bit comput ers:For 64 -bit comput ers: %Program Files (x86)%\Citrix\ICA Client\Configuration\language

Note: For details on creating Group Policy Objects and importing and adding templates, see the Microsoft Active Directorydocumentation at http://www.microsoft.com.

Configuring HDX MediaStream for Flash on the Server

You can configure HDX MediaStream for Flash settings on the server through the Policies node of the Delivery ServicesConsole. You control the settings for the HDX MediaStream for Flash features through the following Citrix User Policysettings:

Flash acceleration

Flash event logging



Flash URL blacklist

HDX MediaStream for Flash is enabled on the server for client-side rendering by default. You can enable and disable HDX

MediaStream for Flash from the server through the Citrix User Policy setting Flash acceleration, in the HDX MediaStream

for Flash (client side) category.

Configure the Flash acceleration setting by selecting Enable, the default, or Disable.

When Enable is selected, all Flash content from sites not blocked by the Flash URL blacklist are rendered on the user device.

If Disable is selected, all Flash content is rendered on the server.

HDX MediaStream for Flash uses Windows event logging on the server to log events. You can review the event log todetermine whether HDX MediaStream for Flash is being used and gather details about any issues. The following arecommon to all events logged by HDX MediaStream for Flash:

http://www.microsoft.com


HDX MediaStream for Flash reports events to the Application log

The Source value is Flash

The Category value is None

In addition to the Windows event log, on computers with Windows Server 2008 or Windows Server 2008 R2, an HDX

MediaStream for Flash-specific log appears in the Applications and Services Logs node. If Windows Server 2003 is used, HDX

MediaStream for Flash log information is only found in the Windows event log.

Configure the Flash event logging setting by selecting Enable, the default, or Disable.

HDX MediaStream for Flash detects the level of network latency between the server and user device the first time an

individual browser or browser tab accesses an embedded Flash Player. If latency is determined to be within an acceptable

threshold, HDX MediaStream for Flash is used to render Flash content on the user device. If the latency is above this

threshold, the network server renders the content if a Flash player is available there.

The default threshold setting is 30 milliseconds.

Configure the Flash latency threshold setting by typing a value between 0 and 30 in the Value field.

HDX MediaStream for Flash downloads Flash content to the user device where it is played. The Flash server-side content

fetching whitelist setting allows you to specify Web sites whose Flash content can be downloaded to the server then sent

to the user device. This setting works in conjunction with Enable server-side content fetching setting on the user device

This setting is frequently used when the user device does not have direct access to the Internet. The XenApp server

provides that connection.

Consider the following when configuring the Flash server-side content fetching whitelist setting:Add the top-level .html page that instantiates the Flash Player to the whitelist; not the URL of the Flash application.

Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list.

Use a trailing wildcard to allow all child URLs, for example http://www.sitetoallow.com/*).

The prefixes http:// or https:// are used when present, but they are not required.

Configure the Flash server-side content fetching whitelist setting by clicking New to add new URLs to the whitelist.Important: The Enable server-side content fetching setting on the user device must also be enabled for the Flash server-side content fetching whitelist on the server to work.

Block specified Web sites from playing on user devices with HDX MediaStream for Flash by adding the sites' URLs to a

blacklist. Instead, the blocked Flash content plays on the server.

Consider the following when configuring the Flash URL blacklist setting:Add the top-level .html page that instantiates the Flash Player to the blacklist; not the URL of the Flash application.

Use an asterisk character at the beginning or end of the URL as a wildcard to expand your list.

Use a trailing wildcard to block all child URLs, for example http://www.sitetoblock.com/*).

The prefixes http:// or https:// are treated equally, so http://www.sitetoblock.com/ is treated the same as

https://www.sitetoblock.com/.

Add sites containing Flash content that does not render correctly on the user device to the blacklist.


Configure the Flash URL blacklist setting by clicking New to add new URLs to the blacklist.

Configuring HDX MediaStream for Flash on the User Device

After installation on user devices and in the absence of any overriding policy settings on the client, HDX MediaStream forFlash is ready for use by your users. No further configuration is needed. If you want to change the default settings on theuser device, you can do so with the Group Policy Object Editor:

Enable HDX MediaStream for Flash on the user device

Enable synchronization of the client-side HTTP cookies with the server-side

Enable server-side content fetching

1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node.

2. Expand the Administrative Templates and Classic Administrative Templates (ADM) nodes and select HDX MediaStream

for Flash - Client.

3. From the Setting list, select Enable HDX MediaStream for Flash on the user device and open the Properties dialog box.

4. Select Not Configured, Enabled, or Disabled.

5. If you selected Enabled, from the Use HDX MediaStream for Flash list, select Always, Ask, or Never.

Note: Selecting Ask results in users receiving a dialog box the f irst time they access Flash content in each XenApp session

in which the user can enable HDX MediaStream for Flash. If the user does not enable HDX MediaStream for Flash, the

Flash content is played on the server. Selecting Always and Never do not result in this dialog box. Select Always to always

use HDX MediaStream for Flash to play Flash content on the user device. Select Never to never use HDX MediaStream

for Flash and have Flash content play on the server.

6. For the policy to take effect:

Comput er Conf igurat ion: Comput er Conf igurat ion: Changes take effect as computers in the organizational unit restart.

User Conf igurat ion:User Conf igurat ion: Users in the organizational unit must log off and then log on to the network.

Enable synchronization of the client-side HTTP cookies with the server-side in order to download HTTP cookies from the

server. These HTTP cookies are then used for client-side content fetching and 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.


for Flash - Client.

3. From the Setting list, select Enable synchronization of the client-side HTTP cookies with the server-side and open the

Properties dialog box.





By default, HDX MediaStream for Flash 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 send it to the userdevice. Unless there is an overriding policy, such as a blacklist, the content will play on the user device.


Important: The Flash server-side content fetching whitelist setting on the server must be enabled and populated withtarget URLs for server-side content fetching to work.1. In the Group Policy Object Editor, expand either the Computer Configuration or User Configuration node.


for Flash - Client.

3. From the Setting list, select Enable server-side content fetching and open the Properties dialog box.





You can configure audio through the Policies node of the Delivery Services Console. You control the settings for the audio

features through the following Citrix User Policy settings:

Audio quality





To set audio quality

Generally, higher sound quality requires more bandwidth and greater server CPU utilization. You can use sound compression

to balance sound quality and overall session performance. Use policy settings to configure the compression levels you want

to apply to sound files.

Consider creating separate policies for groups of dial-up users and for those who connect over a LAN. Over dial-up

connections, where bandwidth typically is limited, users likely care more about download speed than sound quality. For such

users, create a policy for dial-up connections that applies high compression levels to sound and another for LAN

connections that applies lower compression levels.

Configure the Audio quality setting by choosing from these audio quality levels:Low - for low speed connections. Audio playback consumes a maximum of 11 kbps of bandwidth. With both audio

playback and recording total bandwidth consumption is 22 kbps at maximum. Ideal for multimedia conferences when

using low speed connections.

Medium - optimized for speech. Audio playback consumes a maximum of 16.8 kbps of bandwidth. With both audio

playback and recording total bandwidth consumption is 33.6 kbps at maximum. Ideal for multimedia conferences.

High - high definition audio. Audio playback consumes a maximum of 96 kbps of bandwidth. With both audio playback

and recording total bandwidth consumption is 166 kbps at maximum. Ideal for music and video playback.

Note: High definition increases bandwidth requirements by sending more audio data to user devices and increases server

CPU utilization.

To disable speakers

You can allow users to receive audio from an application on a server through speakers or other sound devices, such as

headphones, on their client devices. Client audio mapping can cause excessive load on the servers and the network.


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.

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.

If audio is disabled on the client software, this setting has no effect.

The Client audio redirection setting must be enabled for an enabled Client microphone redirection to work.

For security, users are alerted when servers that are not trusted by their user devices try to access microphones. Users can

choose to accept or not accept access. Users can disable the alert on the Citrix online plug-in.

Configure the Client microphone redirection setting by choosing Allowed, the default, or Prohibited.

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.

Avoiding Echo During Multimedia Conferences With HDX RealTime

When users take part in audio or video conferences, they may hear an echo in their audio. Echoes usually occur when

speakers and microphones are too close to each other. For that reason, Citrix recommends the use of headsets for audio

and video conferences.

HDX RealTime provides an echo cancellation option, enabled by default, which minimizes echo during a conference. For

echo cancellation to be most effective, the user should select either Medium - optimized for speech or Low - for low-speed

connections audio quality. The High - high definition audio setting is intended for music playback, rather than conference

speech and should be avoided for conferences.

The effectiveness of echo cancellation is sensitive to the distance between the speakers and the microphone. These

devices must not be too close to each other or too far from each other.

Echo cancellation is available with only Citrix Online Plug-in 12.0 for Windows and Web Interface 5.3.

1. For 32-bit comput ers:For 32-bit comput ers: On the user device, open the registry and navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA

Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.

For 64 -bit comput ers:For 64 -bit comput ers: On the user device, open the registry and navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA


Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.

Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating

system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use

Registry Editor at your own risk. Be sure to back up the registry before you edit it.

2. In the Value data f ield, type TRUE or FALSE to enable or disable echo cancellation.

HDX RealTime provides your users with a complete desktop multimedia conferencing feature.

System Requirements for HDX RealTime Multimedia Conferencing

The following conditions are required to use the HDX RealTime multimedia conferencing feature:

Install Citrix Online Plug-in 12.0 for Windows on the user device.

Install Microsoft Office Communications Server 2007 in the same environment as the computer running XenApp. This is

not a published application.

Note: Best practice indicates installing Microsoft Office Communications Server 2007 on a different computer than

XenApp.

Publish Microsoft Office Communicator 2007 on your XenApp server.

Ensure the user device has the appropriate hardware to produce sound.

Assign one processor per user per session, whether physical or virtual devices are used for video conferencing.

Use the web camera default settings.

Enable the following three policies settings:

Multimedia conferencing


HDX MediaStream Multimedia Acceleration (see— Configuring HDX MediaStream Multimedia Acceleration

)

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 RealTime tries

the f irst camera found, continuing in succession until a connection is made.

Configuring Multimedia Conferencing

Multimedia conferencing is a Citrix Computer Policy setting. This policy allows or prevents support for multimedia

conferencing applications. By default, Multimedia conferencing is enabled.

Configuring Client Audio redirection

Client audio redirection is a Citrix User Policy setting. It allows or prevents the redirection of sound from a hosted

application to a sound device on the user device. When enabled, users can also record sound from their devices. Client audio

redirection is enabled by default.

HDX 3D allows graphics-heavy applications running on XenApp on a physical server to render on the server's graphics

processing unit (GPU). By moving DirectX, Direct3D and Windows Presentation Foundation (WPF) rendering to the server's


GPU, the server's central processing unit (CPU) is not slowed by graphics rendering. Additionally, the server is able to process

more graphics because the workload is split between the CPU and GPU. This feature is only available on servers with a GPU

that supports a display driver interface (DDI) version of 9ex, 10, or 11. DirectX and Direct3D require no special settings.

To enable WPF applications to render using the server's GPU, in the

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook subkey in the

registry of the server running XenApp, create the EnableWPFHook key with a key type of REG_DWORD and set its value to

1.

Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system.Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editorat your own risk. Be sure to back up the registry before you edit it.


Management Pack for System Center OperationsManager 2007

Jan 21, 2010

The Citrix XenApp Management Pack supports Microsoft System Center Operations Manager 2007 and Microsoft System

Center Operations Manager 2007 SP 1 on servers running Citrix XenApp 5 for Windows Server 2008 and Citrix XenApp 6 for

Windows Server 2008 R2. The Management Pack allows you to monitor the health, availability, and configuration of

XenApp servers and server farms, and anticipate and react quickly to problems that might occur.

Operations Manager is a management solution for Microsoft Windows server deployments that collects, filters, analyzes,

responds to, and reports information about 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/.

The Management Pack interprets and reports information supplied by:The XenApp Provider that runs on Citrix servers

The Licensing Provider that runs on license servers

System events generated on Citrix servers

Key features and benefits of using the Management Pack in your XenApp deployment are:St at e monit oringSt at e monit oring

The Management Pack monitors the overall state of your deployment, determining its availability and performance state at

any given time by comparing real-time data collected from the Provider and the Licensing Provider against thresholds

defined in the Management Pack. You can view this information at different levels, from the state of the deployment as a

whole, right down to the state of individual servers.

Event managementEvent management

The Management Pack captures a variety of events from servers and server farms. These events are collated and then

presented through the Operations Manager Console, allowing an overall view of server operation.

Perf ormance monit oringPerf ormance monit oring

You can use the Management Pack to monitor server performance. You can customize rules and create new ones to set

thresholds for key performance attributes in the server farm.

Ext ensive knowledge baseExt ensive knowledge base

The Management Pack includes an extensive product support knowledge base, including links to relevant Citrix Knowledge

Center articles. Centralized access to information about managing servers allows you to quickly interpret events and

troubleshoot problems.

Cust omizable monit ors, rules, and alert sCust omizable monit ors, rules, and alert s

Changes in state, such as raised events or breached thresholds, trigger rules and alerts to notify you of any state changes.

You can configure the Management Pack to customize how it responds to state-changing events by modifying and

http://www.microsoft.com


extending the monitors and rules to meet the needs of your environment.

Important: Alerts relating to farm metric servers or summary database servers are not raised on servers running XenApp 5.

Cit rix viewsCit rix views

Citrix views are available in the Citrix Presentation Server folder. These views allow you to monitor events and alerts raised

for servers and server farms, and to identify trends and performance issues occurring on servers and published applications.

Easy inst allat ionEasy inst allat ion

The Management Pack consists of three f iles that are available on the installation media or for download from

http://www.citrix.com/. To install the Management Pack, simply import these f iles into Operations Manager using the

Operations Manager Console.

Sealed Management PackSealed Management Pack

The Management Pack is packaged, versioned, and signed with a certif icate. The certif icate used to sign the Management

Pack is provided by a publicly trusted Certif icate Authority verifying that the software was developed and produced by

Citrix. Sealing the Management Pack means that you can import and customize the Management Pack and all your

customizations are saved separately from the original pack. When you upgrade to a new version of the Management Pack,

all your customizations are retained and included in the next version of the pack.

For further information about installing the XenApp Provider and the Licensing Provider, see Managing Providers and WMI.

http://www.citrix.com

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/wmi-provider-node-wrapper-v2.html


System Requirements for the Management Pack

Jan 21, 2010

To use the Management Pack, you must be running Operations Manager 2007 or Operations Manager 2007 SP1. For

information about Operations Manager 2007 minimum hardware and software requirements, see your Operations

Manager 2007 documentation.

To obtain information about servers and the server farm, the Management Pack requires the XenApp Provider to be

installed on every XenApp computer that you want to monitor. The XenApp Provider is a data provider that extracts

information about the server on which it is installed and presents this to the Operations Manager Agent. The Provider

supplies information about the server and, where appropriate, about the farm in which this server operates.

The Management Pack also requires the Licensing Provider to be installed on the license servers if you want to monitor

them. The Licensing Provider is a data provider that supplies information about Citrix licenses. For example, the

Management Pack displays information about the number of licenses in use for each license pool, and raises alerts if the

pool is low on available licenses or if a license is about to expire.

Both Providers are installed by default. For more information about the Providers, see Managing Providers and WMI.

Only licensed servers running Citrix Presentation Server 4.0 or later are fully supported as managed servers. Unlicensed

servers and servers running earlier versions are not monitored by the Management Pack.

The Management Pack does not support agentless monitoring.



Installing the Management Pack

May 04 , 2015

1. Locate the three f iles, Citrix.PresentationServer.mp, Citrix.Library.mp, and Citrix.Licensing.mp. The f iles on the installation

media are also available for download from http://www.citrix.com/.

Note: If you do not want to monitor license servers, you can omit the Citrix.Licensing.mp file.

2. Log on to the Operations Manager and open the Operations Console.

3. Click Administration in the Administration pane and expand the Administration node.

4. Right-click Management Packs, then select Import Management Pack(s).

5. Select the three Management Pack f iles and click Open.

Note: If you do not want to monitor license servers, you can omit the Citrix.Licensing.mp file. The Management Pack

successfully monitors the other servers in your deployment.

Important: Citrix.Library.mp provides the foundation components for all Citrix Management Packs and must be imported

prior to importing any other Citrix Management Packs. In addition, Citrix.Licensing.mp requires

Citrix.PresentationServer.mp. If you import these f iles without also importing the f iles they are dependent upon, the

Management Pack will not function properly. However, the Management Pack functions correctly after these

dependencies are resolved.

6. Click Import.

Note: If you are upgrading the Management Pack, you are notif ied that you are replacing the existing Management

Pack. Continuing with the upgrade will not affect any customized rules or company knowledge articles that you added

to the Management Pack.

After the Management Pack is successfully installed or upgraded, Operations Manager automatically deploys it to all the

managed computers in your management group.

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 specif ic to XenApp are disabled by default because they require configuration to make themappropriate to your site. For information about how to configure these monitors, see Configuring and Enabling Site-specif icMonitors.Important: Ensure that the XenApp Provider is installed on every server that you want to monitor, and that an appropriatelicense is allocated in each server farm being monitored. For more information about the XenApp Provider and the LicensingProvider, see Managing Providers and WMI.

You can uninstall the Management Pack using the Operations Manager Console. Uninstalling the Management Packremoves all the references to it from the Operations Manager database, including the base monitoring objects provided bythe Management Pack along with any dynamically discovered event, performance, or alert data. For information aboutuninstalling management packs, see your Operations Manager documentation.Important: If there are any other management packs in Operations Manager that are dependent on the Citrix XenAppManagement Pack, you must uninstall them before you can successfully uninstall the Management Pack.

http://www.citrix.com/

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/mom-v3-wrapper-v2/mom-v3-configmonitors-v2.html



Security Considerations for the Management Pack

May 06, 2015

To display information about servers and server farms using the Management Pack, you must have the appropriate

administration rights in Operations Manager.

Operations Manager uses a component called the Operations Manager Agent Service to retrieve data from servers,

including servers running the XenApp Provider. The Operations Manager Agent Service runs using the Operations Manager

Agent Action account. Because the Provider requires Citrix administration rights, the Operations Manager Agent Action

account must also have full Citrix administration rights. If this account does not have the appropriate rights, error messages

appear when attempting to access WMI data specific to XenApp.

You must be a member of the appropriate Operations Manager user or administrator group to view alerts and informationon the Operations Manager Console. If you are not a member of the appropriate group, access to information andfunctions is restricted, regardless of whether you are a Citrix administrator or not.Important: Users who have the appropriate administration rights in Operations Manager can view information relating toXenApp in the Operations Manager Console. However, these users might not be Citrix administrators. Depending upon howyour accounts are set up in Operations Manager, users might be able to view information about XenApp that is notnormally available to them in the Access Management Console or the XenApp Advanced Configuration tool. Therefore,Citrix recommends that you take this into consideration when managing your Operations Manager user and administratorgroups.By default, the WMI namespace for the Licensing Provider allows access to all authenticated users. Therefore, you might

want to review access control list (ACL) settings for the Licensing Provider namespace (\root\CitrixLicensing).


Citrix Managed Objects Included in the ManagementPack

May 08 , 2015

The Management Pack monitors and reports on several Citrix-specif ic objects. These objects are described in the followingtable.

ObjectObject Descript ionDescript ion

Citrix Deployment Represents a discovered XenApp deployment that can consist of multiplefarms and zones.

Citrix Farm Represents a XenApp farm that can consist of multiple zones. A farm ismonitored by a single farm metric server.

Citrix Zone Represents a zone that can consist of multiple Citrix managed servers. Azone 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.

Citrix Managed Server Represents a server monitored by Operations Manager.

Citrix Unsupported Server Represents a server not monitored by Operations Manager. Anunsupported server is not running a version of XenApp supported by theManagement Pack running the XenApp Provider.

Citrix Unlicensed Server Represents a server not monitored by Operations Manager. Anunlicensed server is running the XenApp Provider, but is unlicensed ormissing a valid license. Operations Manager checks the licenses on theseservers hourly.

Citrix License Server Represents a server running Citrix Licensing.

Citrix Server Represents a server running any XenApp component.


Citrix Views Included in the Management Pack

May 08 , 2015

The Management Pack includes a number of Citrix views that are available in the Citrix Presentation Server folder of the

Operations Console. These views allow you to monitor events and alerts raised for XenApp servers and server farms, and to

identify trends and performance issues occurring on servers and published applications.

There are five main types of Citrix views: alert and event views, Citrix deployment state views, the Citrix Presentation Server

topology diagram view, Citrix performance views, and license server views. All Citrix views can be customized to meet your

organization's requirements.

You can see the state monitors and processing rules that define how Operations Manager collects, processes, and

responds to information, and that generate the Citrix views

1. In the Operations Console, click Authoring in the Navigation pane.

2. Select Management Pack Objects > Rules or Management Pack Objects > Monitors.

The monitors and rules are grouped according to the object to which they apply. You can configure these monitors andrules and create new ones; see your Operations Manager documentation for more information.Note: After you install the Management Pack, some Citrix views might be empty for a short time until the discovery scriptruns. By default, this script runs hourly.

Alert and event views provide you with real-time event and alert information. Alert views group alerts by severity, and eventviews sort events by date and time. In both alert views and event views, the Details pane shows extra information includingCitrix Knowledge Center articles about each particular alert or event.

ViewView Descript ionDescript ion

All Citrix Events Displays all the events raised by XenApp components on managed servers.

Active Alerts from Citrix Servers Displays all unresolved alerts raised against managed servers by all managementpacks (not only the XenApp Management Pack).

Active Citrix Alerts Displays all unresolved alerts raised by the Management Pack.

Each XenApp deployment state view summarizes the state of a component along with the state of any components

directly related to it; for example, a XenApp farm view displays the state of the farm itself along with the state of the

zones that are part of the farm.


Citrix Farms Displays the state of the XenApp farms in your deployment.


Citrix Managed Servers Displays the state of the XenApp managed servers in your deployment.

Citrix Unlicensed Servers Displays the state of the XenApp unlicensed servers in your deployment.

Citrix Unsupported Servers Displays the state of the XenApp unsupported servers in your deployment.

Citrix Zones Displays the state of the XenApp zones in your deployment.

Farm Metric Servers Displays the state of the farm metric servers in your deployment.

Zone Data Collectors Displays the state of the zone data collectors in your deployment.


State views display high-level state information about a XenApp component without detailing how and why changes of

state occurred. You can investigate the reasons behind state changes by right-clicking a managed object in the Results

pane of any view and selecting Show Health Explorer. The Health Explorer presents the detailed state of the selected

object, displaying the state of each of its monitors on the left and a record of events that caused state changes on the

right.

The type of managed object you select determines which monitors appear in the Health Explorer. For example, if you select

a farm or a farm metric server, the Health Explorer displays farm-wide alert monitors. Monitors are grouped by potential

problem sources. For example, all printing issues are grouped together. Expanding the printing node allows you to see

specific printing monitors, together with the history and causes of any state changes.

The Citrix Presentation Server topology diagram is an Operations Manager diagram view that provides a hierarchicalrepresentation of a XenApp deployment, showing farms, zones, servers, license servers, and their relationships.


Diagram showing a Citrix Presentation Server topology diagram view

The following table lists the XenApp-specific icons used in the topology view and their meanings:

IconIcon MeaningMeaning

Deployment

Server farm

Server

License server


Farm metric server

Zone data collector

Zone

IconIcon MeaningMeaning

The topology view provides the following information:

The name of the farm, zone, or server. Zone names are prefixed by their farm names.

The current alert state, propagated up the tree so that state changes are visible even when the view is collapsed.

Whether a server is a zone data collector or a farm metric server and the hosting server name.

ToolTips are used to provide the following additional information:

XenApp version number, including hotfixes where appropriate

Role (zone data collector or farm metric server)

The name of the license server the computer uses

Logons enabled or disabled

For zones, the number of servers in the zone

For zone data collectors, the name of the zone being managed

For farm metric servers, the name of the farm being monitored

Note: If you make changes to your deployment and move one or more servers from one zone to another zone, thetopology diagram view may still show the moved servers in their original zone. Reimporting the Management Pack forcesthe topology view to refresh.

To reconfigure security settings on zone data collectors

By default, computers running discovery scripts cannot submit data about any other computer. This means that for zone

data collectors to submit data about other servers in the farm, you must change their security settings.

1. In the Operations Manager console, expand the Administration node.

2. Select Administration > Device Management > Agent Managed.

3. Then, for each zone data collector:

1. Double-click the computer name.

2. On the Security tab, select Allow this agent to act as a proxy and discover managed objects on other computers.

Important: If you do not set this option for your zone data collectors, the topology diagram view will not display anydiscovered objects. This might cause an error message to appear in the Operations Manager event log.


Citrix performance views provide performance monitoring details about your deployment.


Active Sessions Displays the number of active sessions on each managed server.

Published Application Load From LoadBalancing

Displays the published application load from the Load Managercomponent. Note that this information is available only if you areusing Load Manager in your server farm and you configured theapplication load level. In addition, you must also enable the “Samplepublished application load from load balancing” rule in MOM.

Server Load From Load Balancing Displays the server load from the Load Manager component. Notethat this information is available only if you are using Load Managerin your server farm.

License Server views provide information about the licenses and license servers in your deployment.Important: If you did not install the Citrix.Licensing.mp file, these views are not available.


Active Citrix License ServerAlerts

Displays all unresolved alerts raised against license servers by the Management Pack.

License Servers Displays the state of the license servers in your deployment.

Pooled Licenses In Use Displays the number of pooled licenses in use, as a percentage of the total number ofpooled licenses.


Configuring and Enabling Site-specific Monitors

Apr 12, 2013

Most state monitors and processing rules that are specific to XenApp are enabled by default and begin functioning after

you install the Management Pack. However, some of these are disabled by default because they require configuration

specific to your site.

Disabled monitors appear dimmed. The monitors in the following table control how Operations Manager processes and

responds to information.

Disabled Monit orDisabled Monit or Associat ed AlertAssociat ed Alert Descript ion of Monit orDescript ion of Monit or

Too Many DisconnectedSessions

The number ofdisconnected sessions onthis server is high.

Defines an upper limit of disconnected XenAppsessions. The global default is 100 sessions. If thislimit is exceeded, the alert warns you about possibleperformance problems. Note that this limit is used forall managed servers. This monitor is disabled bydefault because the acceptable number ofdisconnected sessions varies between sites.

Citrix Session Idle Too Long A Citrix session has beenidle too long

Runs a script that retrieves information from the

XenApp Provider to determine if an XenApp session

has been idle too long. If a session is idle too long,

the script triggers an alert in response to the

Operations Manager event. The alert signals

problems with the session.

Note that all sessions, including idle sessions,

consume resources. Therefore, idle sessions might

cause problems where server resources are limited.

This monitor is disabled by default because the

acceptable length of time for which a session should

be idle varies among sites.

Too Many Active Sessions The number of activesessions on this server ishigh.

Triggers an alert to signal that there are too manyactive sessions running on a server.This monitor is disabled by default because the

number of active sessions is dependent upon several

variables including the hardware and software in your

deployment.

Sample Published ApplicationLoad From Load Balancing

Enabling this monitordisplays information in the“Published ApplicationLoad From Load

Retrieves WMI information about the publishedapplication load from Load Manager.This monitor is disabled by default because this

information is available only if you are using Load


Balancing” healthmonitoring view.

Manager in your server farm and if you configured

the application load level.Disabled Monit orDisabled Monit or Associat ed AlertAssociat ed Alert Descript ion of Monit orDescript ion of Monit or


To open the Access Management Console or DeliveryServices Console from the Operations ManagerConsole

Feb 01, 2010

If you installed the Access Management Console or Delivery Services Console (the name of the console depends on the

version of XenApp you are using) on the Operations Manager server, you can start the console from the Operations

Manager Console.

You can start the Access Management Console or Delivery Services Console from any non-empty Citrix view.

Important: To start the Access Management Console or Delivery Services Console, the ASCLAUNCHPATH environmentvariable must be set to the path of the console; for example, C:\Program Files (x86)\Citrix\Citrix Delivery ServicesConsole\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.


Installation Manager

Jul 21, 2010

Installation Manger is a XenApp feature you can use to distribute hot fixes, patches, and file/registry updates. You can also

use Installation Manager to distribute simple applications, but Citrix recommends using application streaming or App-V to

manage applications. Additionally, you can use XenApp Connector for Configuration Manager 2007 R2 to install and publish

applications to XenApp servers.

Use Installation Manager to:Schedule the installation of MSI or MSP packages on target XenApp servers. You can also specify an MST (transform)

file to change parameters in the MSI package.

Distribute XML f iles generated by Windows Task Scheduler to target XenApp servers.

Automate server restarts after installing an application on a target XenApp server, making the application and the server

ready for use. You can also notify users of upcoming operations such as a server restart.

Associate a published application with a XenApp server.

View task status to see if it ran successfully on target XenApp servers.

You can use Installation Manager through a Microsoft Management Console (MMC) snap-in, or by issuing custom

Microsoft PowerShell cmdlets.

An Installation Manager environment has the following components:

ComponentComponent Descript ionDescript ion

Taskmanagementcomputer

The computer where you manage task deployment.

File share Transfers and stores task f iles, including storing cache f iles containing previously scheduled tasks andresults. For regional deployments, you may want to use multiple f ile shares.

Target servers The XenApp servers on which tasks are deployed.

The task management computer and the file share can be on separate computers or on one of the target servers.

Installation Manager comprises two packages:

PackagePackage Descript ionDescript ion

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 toinstall the Utilities package on the target servers.


PackagePackage Descript ionDescript ion



Jul 19, 2010

The task management computer (where you install the Administration package) can be a separate computer or one of thetarget 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


PowerShell 2.0 (on Vista platforms, PowerShell 1.0 is also supported)

MMC 3.0

XenApp 6 for Windows Server 2008 R2 must be installed on the Windows Server 2008 R2 platform if you want to publish

applications using the management console, associate published applications with servers, or deploy existing published

applications to target servers.

The target servers must be running Windows Server 2008 R2 and XenApp 6 for Windows Server 2008 R2. Each target serverrequires the following software (this software is required for XenApp installation, so it is likely to already be installed):


PowerShell 2.0

If you will be using Installation Manager to deploy MSI or MSP packages to target servers, you must install the Utilities

package on each target server. There are no additional software requirements to install or use the Utilities package on the

target servers.

The file share can be on any Windows Server 2003 or later platform. The file share can be on a separate computer, on the

task management computer, or on a target server.

Installation Manager uses implicit authentication for remote access to the Windows Task Scheduler API. To create

Installation Manager tasks, you must have administrative access to the Installation Manager console and the target

servers, have full control of the file share, and belong to the Local Administrator group on each target server.

The following example illustrates account and permission configuration:1. Create an Active Directory group named “Installation Manager Administrators.”

2. Add the “Installation Manager Administrators” group as a member of each target server’s Local Administrator, Distributed

COM Users, and Event Log Readers local groups. (To simplify the permissions process by combining groups, you could

create a Group Policy Preference policy in Active Directory.)

3. Assign full control rights to the “Installation Manager Administrators” group for the f ile share and folder. The group

requires rights to manipulate Access Control Lists (ACLs) on the share folder.

When a task is scheduled, Installation Manager automatically assigns permission from the target servers to the file share.


1. Download the Installation Manager for Windows Server 2008 R2 software (IM_2008_R2.zip) from My Citrix to a shared

folder on the network. Extract the .zip f ile and save the appropriate .msi f iles:

Save the Administration package (IMAdmin.msi for 32-bit systems or IMAdmin-x64.msi for 64-bit systems) to the task

management computer.

Save the Utilities package (IMUtilities-x64.msi) to each target server.

Note: A target server requires the Utilities package only if you plan to schedule the installation of MSI or MSP

packages on the target server.

2. Be sure all users are logged off the computers where you will install the Installation Manager packages. Close all

applications, including the consoles.

3. On the task management computer, double-click the Administration package (IMAdmin.msi for 32-bit systems or

IMAdmin-x64.msi for 64-bit systems) and follow the wizard instructions.

4. If you will be using Installation Manager to deploy MSI or MSP packages to the target server, on each target server,

double-click the Utilities package (IMUtilities-x64.msi) and follow the wizard instructions.

5. In the MMC on the task management computer, use Add/Remove Snap-in to add the Installation Manager snap-in.

When prompted for the Installation Manager shared folder, either type the path or click Browse and navigate to it.

When you install the Utilities package on a target server, four Windows f irewall rules are enabled (these rules are disabled bydefault). These rules allow access to the Task Scheduler and Event Log Management services using DCOM. The enabledrules are:

Remote Scheduled Task 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.


Using the Installation Manager Console

Jul 21, 2010

The Installation Manager console contains standard MMC panes and the following custom panes:The Task pane lists tasks created using Installation Manager. This information is stored in the f ile share as IMTask.xml.

The Target pane displays the results on each target server of the task selected in the Task pane. This information is

stored in subdirectories of the shared folder as ImTaskResult.xml. The display refreshes automatically every ten minutes.

To manually refresh the display, click Refresh in the Actions pane.

The lower pane displays the PowerShell cmdlet equivalent of an action selected in the Actions pane. For example, if you

select a task named InstallApp in the Task pane and a target server named srv2 in the Target pane, then click Refresh in

the Actions pane, the lower pane displays:

Get-IMTask – Name “InstallApp” – Targets srv2 – Log “\\im\InstallApp\IMTaskResult.xml”

From the Installation Manager console, you can:Schedule installation of an MSI or MSP package

Schedule installation of a Task Scheduler f ile

Schedule installation of a command-line task

Associate published applications with servers

Reschedule a task

Remove a scheduled task

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 MSIPackage Distribution dialog box:

Enter the name of the task. The task name must start with an alphabetic character. The name must be unique, unless

you click Advanced and select Overwrite existing task definition in the Advanced Options dialog box. When you select

this option, the task is updated with the new definition.

In the Target list, specify the target servers where you want to install this 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.

Opt ionOpt ion What happens when select edWhat happens when select ed

Disable session Prevents users from logging on during the installation.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-mgr-wrapper/ps-install-mgr-using-console.html







logon during

installation

process

Logoff existing

sessions

Forces users to log off the server before launching the installation. You can specify how long

to wait before users are logged off ; you can also send a message to logged-on users that

instructs them to save their work and log off .

Reboot target

after successful

installation

Restarts the server after installation. You can specify how long to wait after the installation

completes to restart the server.

Opt ionOpt ion What happens when select edWhat happens when select ed

If Installation Manager fails to schedule a task on a server (for example, when a server is off line), it tries to reschedule

the task. To specify how long Installation Manager will retry, and the interval between retries, click Advanced and specify

Retry Interval values. (If you specify a retry time or retry interval, you must specify both values; otherwise, an error

occurs.)

To schedule installation of 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 Task Scheduler f ile in the Actions pane. In the distributeWindows Task Scheduler File dialog box:




Enter the location of the Task Scheduler f ile in Task XML f ile.

In the Target list, specify the target servers where you want to install this task. Click Servers to select from Active





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:




In the Target list, specify the target servers where you want to install this task. Click Servers to select from Active


http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-mgr-wrapper/ps-install-mgr-pshell-cmdlets.html



Enter the command, or the location of the command, you want to execute on the target servers. If you enter a path,

the command must be available to execute on the target servers at the specif ied path, or it must be available in the

profile “PATH.” To make a command available from a single shared folder accessible by all target servers, click Advanced

and specify a Shared Folder in the Advanced Options dialog box.

Enter the date and time to start the installation in Schedule date and time, or select Now to launch the task

immediately.




occurs.)

To schedule installation of a command-line task using a PowerShell cmdlet, see Create-IMCMDTask.

After you use Installation Manager to install an application on a XenApp server, use this procedure to add the XenAppserver to a preexisting published application object. This results in XenApp including that server when it load balancessession requests to that application.1. From the Installation Manager console, select a task in the Task pane and then click Publish Application in the Actions

pane.

2. Click Browse and then enter the name of the XenApp server where Installation Manager will retrieve the list of published

applications.

3. Click Go and select the published application from the list.

Rescheduling creates a copy of the task, so you can change its parameters. You can reschedule command-line tasks andMSI/MSP package deployments.1. From the Installation Manager console, select a task in the Task pane and then click Reschedule in the Actions pane.

2. In the Reschedule CMD Task or Reschedule MSI Task dialog box, change f ield 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.

To remove scheduled tasks using a PowerShell cmdlet, see Remove-IMTask.




Using Installation Manager PowerShell Cmdlets

Jul 21, 2010

This reference assumes you are familiar with using PowerShell. The Installation Manager cmdlets support the standard

PowerShell common parameters, such as WhatIf.

To import the Installation Manager PowerShell cmdlets, either:Type Add – PSSnapIn IMAdmin at the PowerShell command prompt, or

Import the cmdlets automatically by adding asnp IMAdmin to the PowerShell profile profile.ps1

This topic provides brief options descriptions. For complete cmdlet syntax, type Get-Help cmdlet-name at the PowerShellprompt.

CmdletCmdlet Descript ionDescript ion

Get-IMServer Lists servers in a XenApp farm

Create-IMMSITask Schedules installation of an MSI or MSP package

Create-IMTask Schedules installation of a Task Scheduler f ile

Create-IMCMDTask Schedules installation of a command-line task

Get-IMTask Obtains success or failure status information about scheduled tasks

Remove-IMTask Removes a scheduled task

Lists the servers in a specific XenApp farm.


Opt ionOpt ion Descript ionDescript ion

-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








Schedules installation of an MSI or MSP package on target servers. You can specify the following options:


-name (Required) Unique task name.

-msi (Required) Path to the installation package. The file must be accessible by the task management

computer. The cmdlet checks if this file exists; if it does not exist, an error is displayed.

-targets (Required) Target 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. The files must be accessible by the task management computer.

The cmdlet checks if this file exists; if it does not exist, an error is displayed.

-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

-

logoffSessions

Forces users to log off the server before launching the installation. (You can use the -message option

to prompt users to save their work and log off.)

-disablelogon Prevents users from logging on during the installation.

-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. This 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. The 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 (\\f ileserver\im), on the target servers XAWRK1, XAWRK2,and XAWRK3. The task will launch the f irst day of October 2010 at 11:50 p.m. Users will be alerted with a message beforethe installation begins. Users will not be able to log on during the installation, and the server will be restarted ten minutesafter the installation completes. If a target server is busy, Installation Manager will retry every 10 seconds for a total of 60seconds.Create-IMMSITask -name Installmyapp -targets XAWRK1,XAWRK2,XAWRK3 -msi c:\localfolder\myapp.msi -mst c:\localfolder\myapp_silent.mst -schedule '01/10/2010 23:50:00' -prepareUNC \\fi leserver\im -retrytime 60 -retryinterval 10 -message "Please save your work and logoff. Server wil l reboot for maintenance." -timeout 10 -logoffsessions -reboot

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.




-task (Required) Path to the XML file or PowerShell XML object to install. The XML schema must follow Task

Scheduler 2.0 specifications.

-targets (Required) Target servers where the f ile will be installed. Specify one of the following:A comma-delimited list of individual servers by DNS name





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

-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 Task Scheduler f ile (located at C:\task.xml) that runs a backupscript (named Backuptask) on the target servers (XAWRK1, XAWRK2, and XAWRK3). If a target server is busy, InstallationManager will retry every 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition willbe overwritten. Success/failure status of the installations will be logged to C:\log.xml.Create-IMTask -name Backuptask -targets XAWRK1,XAWRK2,XAWRK3 -task c:\task.xml -update -retrytime 60 -retryinterval 10 -log c:\log.xml

Schedules installation of a command-line task. You can specify the following options:



-command (Required) Command-line operation to run on the target servers.

-targets (Required) Target servers where the package will be installed. Specify one of the following:A comma-delimited list of individual servers by DNS name


-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



-

prepareUnc

Specifies a shared folder, in UNC format, that Installation Manager can use to transfer files to target

servers. Installation Manager automatically transfers files to this folder and updates the folders' ACL to

ensure all servers have read access to it. You must have sufficient rights to set UNC permissions.



will retry the installation task. If you specify a retry time, you must also specify a retry interval.

-

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-linenotepad.exe, on target servers XAWRK1, XAWRK2, and XAWRK3. If a target server is busy, Installation Manager will retryevery 10 seconds for a total of 60 seconds. If a task with the same name already exists, its definition will be overwritten.Success/failure status of the installations will be logged to C:\log.xml.Create-IMCMDTask -name Installnotepad -command notepad.exe -targets XAWRK1,XAWRK2,XAWRK3 -update -retrytime 60 -retryinterval 10 -log C:\log.xml

Obtains success or failure status about scheduled task installations. You can specify the following options.


-targets (Required) Target servers for which you want task installation information. Specify one of the following:A comma-delimited list of individual servers by DNS name


-name Task name.

-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 namedInstallnotepad on target servers XAWRK1 and XAWWRK2.Get-IMTask -targets XAWRK1,XAWRK2 -name Installnotepad

Removes a task scheduled on target servers. You can specify the following options:


-targets (Required) Target 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


-name (Required) Task name.


will retry the task removal. If you specify a retry time, you must also specify a retry interval.

-

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.


For example, the following cmdlet removes the task named Installnotepad from target servers XAWRK1 and XAWRK2. If atarget server is busy, Installation Manager will retry every 10 seconds for a total of 60 seconds. Success/failure status ofthe task removal will be displayed in the PowerShell console.Remove-IMTask -targets XAWRK1,XAWRK2 -name Installnotepad -retrytime 60 -retryinterval 10


Installation Manager Messages Reference

Jul 19, 2010

Installation Manager may report the following messages.IMAdmin

IMUtilities

Generally, a positive value indicates a successful condition or provides general information. A negative value usually indicates

an error condition.

The numbers in the following tables are organized by the absolute value of the initial digit, then by remaining digits.

NumberNumber St ringSt ring T rigger or Condit ionT rigger or Condit ion

0 SUCCESS The task ran successfully.

1 SCHEDULED The task is scheduled in the TaskScheduler.

-1 FAILURE The task failed to register or execute.

-100 A connection to the server could not be established. The server may not be physicallyconnected.

-101 Invalid farm argument. Specify a valid server address. The specif ied farm name may either besyntactically wrong or may not exist.

103 This Citrix XenApp PowerShell snap-in contains cmdlets used toperform remote management operations in your XenAppenvironments.

-104 Invalid arguments. Specify either "match" or "like" arguments, notboth.

Specify either Match or Like for f ilteringservers.

-105 XenApp SDK is not installed or Check DCOM Settings DCOM settings in the client computerare either missing or incorrect.

-106 The folder specif ied {0} does not exist. Specify a valid foldername in the format Servers/folder1/folder2.

-107 Access denied while enumerating Servers/Folders in farm. The administrator is not a CitrixAdministrator.

2 EXECUTING The task is running.

-205 Server is unreachable. Check network connections. The task cannot register itself with the

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-mgr-wrapper/ps-install-mgr-messages.html

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-install-mgr-wrapper/ps-install-mgr-messages.html


Task Scheduler.

-207 You do not have permission to access the target server. Youmust be a local Administrator on that server.

The application cannot register a taskbecause the logon credentials are notvalid.

-211 Invalid Task XML format. Document contains invalid tags. The task XML document does notcomply with the Task Scheduler 2.0standard schema.

-212 Unable to write Log f ile {0}. check that the path exists and thatyou have write permissions to it.

The application cannot create the logfile because it does not have writepermission for the specif ied path.

-214 Unable to read Task f ile {0} check that the f ile exists and thatyou have read permissions to it.

The task f ile is not at the specif iedlocation or cannot be accessed due toincorrect permissions.

-216 Specify the interval time in seconds for the Retry parameter. A negative value was specif ied for theretry interval time.

-219 This task name already exists on the target server. Enter aunique task name.

The specif ied task name already exists.

-220 Network path {0} is unreachable. Check network connections. The servers are physically disconnected.

-221 Invalid Task XML format. Cannot f ind "action" tag. The task XML f ile does not contain themandatory <actions> tag.

-222 You do not have permission to schedule a task. You must be alocal Administrator on the target server.

Insufficient permissions exist to accessthe target task scheduler.

-223 Invalid Task XML format. The "command" tag contains invaliddata.

The task XML f ile does not contain themandatory <command> tag.

-224 Invalid Task XML format. The "command" tag is not well-formed. The task XML <command> tagformation is not valid.

-226 The f ilename, directory name, or volume label syntax is incorrectfor path {0}

The specif ied task name is in an invalidformat.

-229 Invalid Task XML format. The Task Scheduler cannot recognizethe XML format.

230 Task successfully registered. The task registered successfully in theTask Scheduler.

-233 Invalid task name. The specif ied task name does not startwith an alphabetical character.



-234 Invalid target argument. Specify a valid server address. The specif ied server IP address is notvalid.

239 Task successfully updated. The existing task in the Task Schedulerupdated successfully.

-241 Missing retrytime argument. It is mandatory if retryinterval isprovided.

A retry interval value was specif iedwithout a retry time value.

-242 Missing retryinterval argument. It is mandatory if retrytime isprovided.

A retry time value was specif ied withouta retry interval value.

3 SCHEDULE_PENDING The task is not yet registered in theTask Scheduler.

-300 Use the following date and 24-hour time format: DD/MM/YYYYHH:MM:SS.

The time and date specif ied for theschedule option are not in the requiredformat.

-301 Unable to prepare UNC path {0}. Check your credentials. Access was denied to the PrepareUNCpath due to insufficient permission.

-302 Invalid command argument. Specify a valid command-lineoperation.

A cmdlet option was incorrectlyspecif ied.

-303 Failed to assign read permissions of computer {0} to the path{1}. Ensure the path and computer name are correct, and thatyou have suff icient access rights to the path.

4 CANCELLED The running task was stopped.

-400 Specify a reboot timeout period in minutes for the Reboot-Timeout parameter.

The timeout value specif ied is not aninteger.

-404 Unable to read MSI f ile {0}. Check that the f ile exists and thatyou have read permissions to it.

Access was denied to the MSI f ile dueto insufficient permission.

-405 Unable to read MST f ile {0}. Check that the f ile exists and thatyou have read permissions to it.

Access was denied to the transform(MST) f ile due to insufficient permission.

5 CANCEL_PENDING The task running is being stopped.

501 Task successfully removed. The task was successfully removedfrom the Task Scheduler.

6 REMOVED The task was removed from the TaskScheduler.

-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.-601 Task not found. The task is not found in the target

server's Task Scheduler.

605 Task was scheduled. The task is scheduled to run on thetarget server.

606 Task is running... The task is running on the target server.

607 Scheduling... The task is not yet registered.

608 Task was cancelled. The running task has been stopped.

609 Canceling task... The task running is being stopped.

-610 Task failed. The task failed to execute.

-611 Task Failed. Verify if IM Utilities is installed at target server. The Utilities package is not installed onthe target server.

-801 COM error while scheduling task in target system : {0} A COM exception occurred whileschedule a task in the Task Scheduleron the target server.

-802 Generic error while scheduling task in target system :{0} An exception occurred while schedulinga task in the Task Scheduler on thetarget server.

-803 COM error while retrieving task information from target system :{0}

A COM exception occurred whileretrieving task information from theTask Schedule on the target server.

-804 COM error while removing task form target system :{0} A COM exception occurred whileremoving a task form the TaskScheduler on the target server.

-805 Generic error while removing task from target system :{0} An exception occurred while removing atask from the Task Scheduler on thetarget server.

-901 MFCOM is not registered on the system. Use the MFREG tool toregister the server.


The following messages may be generated if you installed the Utilities package on the target servers, which is required ifyou 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 clientcomputer are either missingor incorrect.

-226 The f ilename, directory name, or volume label syntax is incorrect for path{0}

-700 Installation failed: {0} MSIEXEC failed to run.

-701 Unable to read Installation f iles using system credentials. Ensure "Everyone"has read permission to the share and "Advanced:Shared Folder" parametercontains the UNC path where the f ile is located.

Unable to access MSI log f ile.

-702 Unable to connect to the XenApp farm. Specify only XenApp servers whenusing publish-app or disable-logon parameters.

XenApp farm initializationfailed.

-703 Unable to add server to published application. The installation wassuccessful, use Delivery Services Console to add the server to the publishedapplication object.

The server may not exist.

705 Published Application name is already existed.

-709 Terminal Server role is not enabled. Reboot and logoff parameters are onlyavailable for Terminal Server targets.

Target server does not haveTerminal Services enabled.

-710 Unable to send message to connected sessions. Operation was canceled. Error sending TerminalServices messages.

-711 Unable to reboot server. The installation was successful otherwise, rebootthe server manually to complete the operation.

Error restarting TerminalServices target.

712 This Citrix XenApp PowerShell snap-in contains cmdlets used to performinstallations on XenApp servers.

-715 Incorrect number of parameters to MSIScriptlet.ps1 Not all parameters werepassed to scriplet f ile.

-716 Missing MSI f ile path argument. The MSI f ile option isrequired.

718 Success. The MSI installedsuccessfully.

-720 Missing task name argument. The task name option isrequired.

723 Success. System will reboot. The task ran successfully and


the server will restart tocomplete the installation.

-724 Unable to write event to Windows Event Log. An error occurred whenwriting to Event Logger.



Managing Providers and WMI

May 04 , 2015

Diagram showing the main components of a WMI installation

WMI Provider.WMI Provider. Acts as an intermediary between the CIM (Common Information Model) Object Manager and the

system being managed. The purpose of a WMI provider is to extract management information from the underlying

system and present this to a WMI consumer.

T he CIM Object Manager T he CIM Object Manager (CIMOM).(CIMOM). Acts as a broker between the WMI providers and consumers. When a WMI

consumer requests information, CIMOM identif ies the WMI provider that can supply the information, obtains the

information, and passes it to the consumer. CIMOM has its own repository in which it stores the data supplied to

consumers. The Managed Object Format (MOF) f iles 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.WMI Consumer. A management tool such as Microsoft Operations Manager (MOM), an MMC snap-in such as the

Citrix Access Management Console or Delivery Services Console, or a third party application.

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.

The Citrix XenApp Provider for Microsoft Windows Management Instrumentation (also referred to as the XenApp Provider

or the Provider) extracts information about the server on which it is installed and, where appropriate, about the server farm

in which this server operates. It presents this information to a WMI consumer, such as MOM, for display.

For example, information about sessions on the server and published applications in the server farm is provided. You can use

this information to monitor the health and availability of the server and server farm.

The Provider runs on the server as a Windows service.

Citrix Licensing is handled by one or more license servers.


The Licensing Provider is available on each Windows-based license server. It is installed by default with the license server.

This WMI provider extracts information about licensing from the license server on which it runs and presents this data to a

WMI consumer, such as MOM, for display. For example, the Licensing Provider supplies information about the number of

licenses in use and licenses that are about to expire.

The XenApp Provider no longer supplies licensing information for computers running MetaFrame Presentation Server 3.0 orlater. However, the Lincensing Provider still supplies licensing information for servers running earlier versions of XenApp. Thismeans that you can monitor multiple farms, running different versions of XenApp. For backwards compatibility, the licensingclasses are still in the schema for the XenApp Provider.Note: For information about the data the Licensing Provider can supply, see the Citrix .mof f iles. The f iles are in the\LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).

Install the XenApp Provider on every XenApp computer for which you want to gather information. You install the Provider

during the installation of XenApp.

When you install the Provider, the files are installed in the \WMI folder in the same directory in which XenApp is installed.

Typically, this is: C:\Program Files\Citrix\System32\Citrix\WMI. The following files are included in this folder:

The executable f ile for CitrixWMIService (ctxwmisvc.exe)

Provider DLLs

Various .fom files

Managed Object Format f iles (.mof f iles)

The Provider runs as a Windows service called Citrix WMI Service.

The Licensing Provider is installed by default when you install the Citrix License Server for Windows.

The Licensing Provider runs as a Windows service called CitrixLicensingProviderService.

To display information about XenApp computers and server farms using a WMI consumer, access to the Root\Citrix

namespace in the WMI configuration is required. The appropriate Citrix administration rights to display information about

servers and server farms is also required.

If you delegate areas of XenApp administration and server farm management to Citrix administrators, these administrators

can monitor and control only the specific administration tasks for which they have permissions. For example, if a Citrix

administrator can manage only published applications, only information about published applications is available to them

from the XenApp Provider.

Uninstall the XenApp Provider using the XenApp uninstaller.

The Licensing Provider is part of Citrix Licensing. To uninstall the Licensing Provider, uninstall the Citrix License Server.

This section contains diagrams of the WMI schemas for the XenApp Provider and Licensing Provider. The schema is the

data that a WMI provider can supply and the methods it can execute in response to WMI requests. The following schema


are shown:

XenApp Provider

Licensing Provider

Note: These diagrams represent typical WMI schemas, rather than providing a comprehensive list of all the data returned bythe Providers. For more information about the data the XenApp Provider can supply, see the Citrix .mof f iles in the \WMIfolder (for example: C:\Program Files\Citrix\System32\Citrix\WMI). For more information about the data the LicensingProvider can supply, see the Citrix .mof f ile in the \LicWMI folder (for example: C:\Program Files\Citrix\Licensing\LicWMI).



Citrix Licensing Provider WMI Schema



Load Management

May 04 , 2015

You can set up, manage, and monitor server and published application loads in a server farm so that users can run the

published applications they need quickly and efficiently.

XenApp calculates the load on a server using load evaluators and rules. Each load evaluator contains one or more rules. Each

rule defines an operational range for the server or published application to which its evaluator is assigned.

When a client user selects a published application to run, the client contacts the server farm to locate the address of a

server that hosts the published application. XenApp maintains a list of available host servers within the server farm. Upon

receiving the client’s request, XenApp selects the server with the lowest load and returns its address to the client. The client

starts a session on that server and launches the published application.

XenApp calculates a server load using the load evaluators attached to a server or published application. When any rule for

any relevant load evaluator reports full load or exceeds its threshold, XenApp removes the load-managed server from the

internal list of available servers. The next request for an ICA connection to a published application is routed to the next

available load-managed server in the list.

Every server running XenApp is included in the load calculation regardless of the network protocol unless the server reports

full load. If a server reports full load, it is no longer available for load management until its load is reduced (for example, users

log off from the server or server processes consume less CPU time). After the load is reduced, the server is added

automatically to the list. Servers are continuously added to and removed from the list as server load and user activity

fluctuate.

These load evaluators are included in XenApp:Def ault .Def ault . XenApp attaches the Default load evaluator to each server after you add your license to the server farm. It

contains two rules: Server User, which reports a full load when 100 users log on to the attached server; and Load

Throttling, which specif ies the impact that logging on has on load and limits the number of concurrent connection

attempts the server is expected to handle.

Advanced.Advanced. This load evaluator contains the CPU Utilization Load, Memory Usage, Page Swaps, and Load Throttling rules.

Important: You cannot delete the Citrix-provided Advanced or Default load evaluators.

You can create new load evaluators based on the rules available.

Important: Each server or published application can have only one load evaluator attached to it.You can attach one load evaluator to a server and one load evaluator to each published application on the same server. For

example, you can keep the Default load evaluator attached to your server and attach another load evaluator to each of

your published applications on that server.

When you select the Load Evaluators node in the left pane of the Delivery Services Console, the following tabs aredisplayed:

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.


XenApp provides the Default and Advanced load evaluators as ready-made options for managing the loads of your XenApp

servers. However, they may not meet all your load management needs. You can create your own load evaluators with the

rules available and attach them to your servers or published applications.

1. From the Delivery Services Console, select Load Evaluators in the left pane.

2. From the Actions pane, select New > Add load evaluator.

3. On the Add Load Evaluator dialog box, type a name and description for the new load evaluator.

4. Select one or more rules from the Rules list and configure it as reqquired.

The properties of a load evaluator include its name, description, assigned rules, and rule settings. You can view the

properties of a load evaluator at any time from the Current Settings tab, located beneath the load evaluators list.

1. From the Delivery Services Console, select Load Evaluators in the left pane.

2. In the middle pane, select the load evaluator that you want to edit.

3. From the Actions pane, click Modify load evaluator properties..

4. On the Load Evaluator Properties dialog box, do one of the following:

View the load evaluator properties

Make your changes to the load evaluator properties

These load management rules are included in XenApp:Applicat ion User LoadApplicat ion User Load

Limits the number of users allowed to connect to a selected published application. This rule monitors the number of active

ICA sessions using the published application. The default value to report full load is 100.

Cont ext Swit chesCont ext Swit ches

Defines a range of context switches per second for a selected server. A context switch occurs when the operating system

switches from one process to another. The default value to report full load is 16000. The default value to report no load is

900— at that value this rule is ignored. This rule uses the System: Context Switches/sec performance counter to determine

load.

CPU Ut ilizat ionCPU Ut ilizat ion

Defines a range of processor utilization, as a percentage, for a selected server. The default value to report full load is 90

percent. The default value to report no load is 10 percent— at that value this rule is ignored. This rule uses the Processor: %

Processor T ime performance counter to determine load.

Disk Dat a I/ODisk Dat a I/O

Defines a range of data throughput, in kilobytes per second, for a selected server. The default full load value is 32767

kilobytes per second. The default no load value is 0 kilobytes per second— at that value this rule is ignored. This rule uses

the PhysicalDisk: Disk Bytes/sec performance counter to determine load.

Disk Operat ionsDisk Operat ions

Defines a range of disk operation, in read/write cycles per second, for a selected server. The default full load value is 100

operations per second. The default no load value is 0— at that value this rule is ignored. This rule uses the PhysicalDisk: Disk

Writes/sec and Disk Reads/sec performance counters to determine load.


IP RangeIP Range

Defines a range of allowed or denied client IP addresses for a published application. It controls access to a published

application based on the IP addresses of the clients. You can define ranges of IP addresses, then select to allow or deny

access if the client IP addresses are within the defined ranges.

This rule must be used in conjunction with another.

Load T hrot t lingLoad T hrot t ling

Limits the number of concurrent connection attempts that a server handles. This prevents the server from failing when

many users try to connect to it simultaneously. The default setting (High impact) assumes that logons affect server load

signif icantly. This rule affects only the initial logon period, not the main part of a session.

The Load Throttling rule can be applied only to a server, not to an individual application.

Memory UsageMemory Usage

Defines a range of memory usage by a server. The default full load value is 90. The default no load value is 10— at that

value this rule is ignored. This rule uses the Memory: % Committed Bytes in Use performance counter to determine load.

Page FaultPage Fault

Defines a range of page faults per second for a selected server. A page fault occurs when the operating system tries to

access data that was moved from physical memory to disk. The default full load value is 2000. The default no load value is 0

— at that value this rule is ignored. This rule uses the Memory: Page Faults/sec performance counter to determine load.

Page SwapsPage 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 f ile. The default full load value is 100. The default no load value is 0— at that

value this rule is ignored. This rule uses the Memory: Pages/sec performance counter to determine load.

SchedulingScheduling

Schedules the availability of selected servers or published applications. This rule sets the weekly days and hours during which

the server or published application is available to users and can be load managed.

Server User LoadServer User Load

Limits the number of users allowed to connect to a selected server. The default full load value is 100 and represents the

maximum number of users the system can support on a server. Load Manager user loads are calculated using active ICA

sessions only.

To participate in load management, each server or published application must have a load evaluator assigned to it. The rules

and their settings determine how the load of a particular server or published application is managed.

For example, if you have a published application that uses a significant percentage of a server’s memory and processing

capabilities, you can attach the Advanced load evaluator to every server hosting the application. By doing so, XenApp

distributes the available memory and processor demand across the load-managed servers.

Each server or published application can have only one load evaluator attached to it.

To assign a load evaluator to a server

1. From the Delivery Services Console, select the Servers node in the left pane.


2. Select the server to which you want to attach a load evaluator.

3. From the Actions pane, select Other Tasks > Assign load evaluator.

4. On the Assign Load Evaluator dialog box, select the load evaluator to attach.

To assign a load evaluator to a published application

1. From the Delivery Services Console, select the Applications node in the left pane.

2. Select the published application to which you want to attach a load evaluator.

3. From the Actions pane, select Other Tasks > Attach application to load evaluator.

4. On the Assign Load Evaluator dialog box, select the load evaluator to attach.

Use the Scheduling rule to determine when a server or published application is available to users and can be load managed.

If this rule is included in a load evaluator and attached to a server or published application, the server or published

application is available only during the days and times set in this rule.

The Scheduling rule must be used in conjunction with another rule. It cannot be the only rule in a load evaluator.

You cannot apply the Scheduling rule to any custom ICA connections that connect to specific servers. Custom ICA

connections cannot be controlled using the Scheduling rule.

To configure the Scheduling rule

1. In the Delivery Services Console, select Load Evaluators in the left pane.

2. In the middle pane, select the load evaluator you want to change.

3. From the Actions pane, select Modify load evaluator properties.

4. From the Rules list, select the Scheduling rule.

5. In the Scheduling Settings panel, use the Add and Remove buttons to select the days and times that you want the

server or published application to be available (Monday through Friday, 8:00 AM to 6:00 PM, by default).



Aug 12, 2009

Citrix XenApp Power and Capacity Management can help reduce power consumption and manage XenApp server capacity

by dynamically scaling up or scaling down the number of online XenApp servers. Consolidating sessions onto fewer online

servers improves server utilization, while providing sufficient capacity to handle load while minimizing unnecessary power

consumption.

As users log on to the system and reduce the idle capacity (how much capacity is available for additional sessions), other

servers in the workload are powered up. As users log off and idle capacity increases, idle servers are shut down. This helps

optimize capacity for XenApp workloads.

Scheduling provides an automated approach. An administrator defines specific times for powering on and powering off

workloads. For example, a schedule powers on servers at 8 a.m. and powers them down at 7 p.m. from Monday through

Friday.

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.

The administrator can manually override capacity and schedule settings to accommodate unexpected changes in demand.

Metrics are collected for system usage reports.

Power and Capacity Management respects all configured XenApp server settings, farm settings, and policies.


Understanding Power and Capacity Management

May 04 , 2015

For XenApp Power and Capacity Management, capacity is expressed as a number of sessions (or session count).

The XenApp servers being managed by Power and Capacity Management are called a farm. This farm may include some or

all of the servers in a XenApp farm, or it may contain XenApp servers from different XenApp farms (for example, in a XenApp

farm that covers multiple sites, you might have a Power and Capacity Management farm for the XenApp servers in each

site). The Power and Capacity Management farm name is distinct from the XenApp farm name.

You define a workload, which 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.) You use setpoints to control how servers are power managed and

how load is consolidated within the workload.

Use Power and Capacity Management to observe and record utilization and capacity levels. Console monitoring and report

generation provide valuable information, regardless of whether or not you enable power management and load

consolidation.

This illustration shows the major components of XenApp Power and Capacity Management: concentrator, agent,database, reporting, and management console.

Concent rat orConcent rat or

The concentrator is a Windows service and the central component of the Power and Capacity Management system. The

concentrator coordinates system states and operations for the managed XenApp servers. You can have one or two

concentrators; if you have two and one fails, the other assumes control.

Dat abaseDat abase

The database component is 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.

Report ingReport ing

Power and Capacity Management reports are hosted on Microsoft SQL Server Reporting Services. The administrator

generates reports for historical system loads, capacities, and utilization summaries.

Management ConsoleManagement Console


The management console is a Microsoft Managed Console (MMC) snap-in you use to manage, monitor, and configure the

Power and Capacity Management system.

AgentAgent

The agent is a Windows service installed on each XenApp server. The agent reports capacity and system states, and acts on

operations and commands issued by the concentrator.

The concentrator, database, reporting, and management console components are referred to as administration

components.

A setpoint defines either a target capacity level (number of sessions) or a target number of online servers. You specifysetpoints for each workload. Power and Capacity Management uses four setpoints.

The power controller, which powers servers on and off , uses all four setpoints.

The load consolidator, which controls the load on online servers by enabling and disabling logons, uses only the minimum

available servers setpoint. The load consolidator also uses a secondary optimal load value, which specif ies how close to

capacity a server can get before additional load should be directed to other servers.

Setpoint Descriptions

Online session reserveOnline session reserve

The online session reserve setpoint specif ies the amount of online but unused capacity that must be maintained above the

current load. As the load ebbs and f lows throughout the day, the system maintains this buffer; this is termed a load

following model.

In practice, the Power and Capacity Management powers on the smallest number of servers that can hold the target

online capacity.

Minimum session capacit y and maximum session capacit yMinimum session capacit y and maximum session capacit y

The minimum and maximum session capacity setpoints work as guards for the online session reserve. The online session

reserve setpoint can raise and lower the online capacity, as long as it remains between the two guards.

The minimum session capacity setpoint causes servers to be powered up until the system has at least the amount of

online capacity to meet or exceed the setpoint. After this setpoint is met or exceeded, the minimum session capacity

has no effect; if the online session reserve setpoint drives online capacity above the minimum session capacity setpoint

value, Power and Capacity Management ignores the minimum session capacity setpoint.

The maximum session capacity setpoint functions similarly to minimum session capacity; however, it causes servers to be

powered off until the online capacity is at or below the setpoint. Although the maximum session capacity setpoint is

used less frequently, it can be helpful when preparing for system maintenance. After online capacity is below the

setpoint value, this setpoint has no effect.

Minimum available serversMinimum available servers

The minimum available servers setpoint works on a per-server basis (the other three setpoints are capacity based). Use this

setpoint to ensure a minimum level of service availability, in terms of servers. This can be helpful in handling:

Redundancy: Multiple servers ensure acceptance of new sessions if a server crashes.

Logon rates: Logging on new sessions can quickly increase server load to the point where existing sessions are degraded

or new logons take signif icantly longer to complete. In such cases, using this setpoint can ensure you have a suff icient

number of servers online to load balance the logon load.

The power controller attempts to keep this many servers online, while the load consolidator attempts to keep this number

of servers available to accept new sessions. You usually increase this setpoint just before and throughout the morning rush


to ensure suff icient available servers for the high rate of incoming sessions. If you do not increase this setpoint for the

morning rush, the capacity setpoints may ensure there are enough servers online to host the expected load, but the load

consolidator may keep too many servers disabled. Therefore, the servers that are enabled may become overloaded while

new sessions are logging on.

Default Setpoints

A new workload has default setpoint values that place the workload in the most available configuration – all managedservers are online. Thus, a newly discovered workload cannot be power controlled until you define appropriate setpoints forit (and enable power management).

Set pointSet point Def aultDef ault

Online session reserve Infinite; all servers are kept online. The management console displays this value as an infinitysymbol.

Minimum sessioncapacity

Zero, which is equivalent to unset.

Maximum sessioncapacity

infinite, which is equivalent to unset; the management console displays this value as aninfinity symbol.

Minimum availableservers

Zero, which is equivalent to unset.

You specify setpoints in a workload schedule. Set the secondary optimal load value in global configuration settings.

Setpoint Priorities

The system attempts to meet the online session reserve setpoint first. It then bounds the output using the minimum and

maximum session capacity setpoints. Finally, the system checks and ensures that the resulting number of online servers

meets the minimum available servers setpoint.

Therefore, setpoints have the following order of importance, from highest to lowest:Minimum available servers

Maximum session capacity

Minimum session capacity

Online session reserve

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 sessionuse occurs at 9:30 a.m.

To effectively handle demand, schedule the system to ramp up at 9:00 a.m. by setting the minimum available servers to 5,

and the online session reserve to 300.

After peak use (9:30 a.m.), schedule the setpoints to lower values at 10:30 a.m., with minimum available servers set to 2

and the online session reserve set to 100.

After normal working hours, reduce these setpoint values further at 7:00 p.m., with minimum available servers set to 1 and


the online session reserve set to 50.

After you initially set the online session reserve and minimum available servers setpoint values with scheduled changes

throughout the day, observe server and session activity, and then fine-tune the schedule and setpoint values to optimize

server capacity and use.

Manual Overrides

After you enable a workload for power management, you can manually override the schedule with different setpoint

values.

For example, a manual override can be useful when there is an unexpected surge in demand on the XenApp workload that is

likely to continue for a few hours. Instead of changing the schedule, you can initiate an override. When the surge has

subsided and the normal conditions have returned, you can cancel the override, and the scheduled setpoint values are

reapplied.

Using a manual override can 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.

Within a workload, servers are grouped by profiles. A server profile comprises information the agent discovers andinformation you configure.

The agent discovers hardware information such as the CPU type and the amount of memory, and sends it to the

concentrator. The concentrator creates a profile entry in the database for a new profile (or, if the profile values are the

same as those in an existing profile, the existing profile is reused).

Using the management console, you configure two server profile values that Power and Capacity Management uses

(with other criteria) to measure server capacity:

Typical session capacity - specif ies the number of XenApp sessions (on average) that server can host

Estimated session capacity limit - allows the dynamic session capacity feature to estimate capacity higher than the

typical session capacity value when it detects spare computing resources

In a server profile, you can also specify a power action timeout 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.

If the hardware configuration changes (for example, more RAM is added to a server), Power and Capacity Management

creates a new profile. (The original profile is not altered, because other servers may still be using it. Also, when a hardware

change occurs, server capacity can change.)

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.

The control mode affects whether the server is eligible for power management or participating in load consolidation.

UnmanagedUnmanaged

The server is not controlled by the Power and Capacity Management system, and is ignored by the workload to which it


belongs. It does not contribute to the capacity of the workload. To quickly remove a server from the scope of system

control without affecting the rest of the workload, setting this mode is the quickest and easiest way.

Managed (base load)Managed (base load)

The server contributes to the capacity of the workload and meeting its current setpoints; however, it is not controlled. The

power management controller does not power this server off or on, and the load consolidation controller does not disable

this server in order to force load onto other servers.

Some XenApp servers that provide essential services should not be taken off line, such as the data collector or the server

hosting the XenApp data store. Designate these servers as managed (base load). If power management has a target of

keeping a certain number of servers online, the online managed (base load) 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.

ManagedManaged

The server is fully controlled by the Power and Capacity Management system and can be powered on or off by the power

management controller. While online, the load consolidation controller may enable or disable new sessions being placed on

this server, in order to force sessions onto other servers.

When planning,Identity which XenApp servers host critical 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).

Identity which XenApp servers host critical services and host XenApp session. Set the server control mode for these

servers to managed (base load).

Set the server control mode for existing servers in server properties, and for new servers in global configuration settings.

You can install a Power and Capacity Management concentrator on two servers. This concentrator cluster has a master-

slave relationship; one concentrator is the master and the other is a slave. All connections from agents on the XenApp

servers go to the current master concentrator; there is no load balancing among multiple concentrators.

Important: Multiple concentrators share a common database. Implement effective SQL Server database clustering andredundancy management.Concentrators negotiate for mastership and monitor the health of the current master via the database. If the current

master stops updating the database, the slave concentrator becomes the master. Failover usually occurs within 60 seconds.

You can explicitly force a running slave concentrator to become the master concentrator. This may be necessary when a

master concentrator has planned maintenance.

Each concentrator registers an Active Directory Service Connection Point (SCP) under the machine account where the

concentrator is installed and records an entry in the database. When the agent on the XenApp server starts, it queries the

SCP to discover all known concentrators. Each agent then tries to connect to each concentrator, looking for the master.

The management console also performs the same discovery process and connection attempts.

To change the port the agent uses to communicate with the concentrator (the default port is 11168), edit the

PCMConcentrator.exe.config file in the Install directory, then restart the PCM Concentrator service.

Power and Capacity Management uses virtual machine management to automatically locate virtual machines it manages;

therefore, you do not need to manually configure associations between the virtual machines and their managing XenServer


hosts.

Virtual machine management supports multiple concurrent XenServer resource pools. The concentrator automatically

connects to the XenServer resource pool, and periodically queries the inventory of virtual machines. The management

console displays the inventory poll results as a count of the number of virtual machines. The concentrator continually

updates the results.

If you move a virtual machine image from one XenServer resource pool to another, Power and Capacity Management learns

about this during its inventory polling.

Note: The list of discovered virtual machines does not necessarily match the servers being managed by Power and CapacityManagement; each machine manager maintains a list of all virtual machines discovered.When the concentrator selects a server to power on, it asks all virtual machine managers if they have the virtual machinewith that server image.

If a match is found, the machine manager issues the appropriate XenAPI commands to the resource pool to start a

virtual machine.

If no virtual machine is found (because its machine manager has not been configured or connected, or because the

server image is hosted on a physical machine), Power and Capacity Management broadcasts the Wake-on-LAN packet

on the network. Then, the concentrator waits a prescribed interval (power control timeout) for the Power and Capacity

Management agent on the appropriate XenApp server to establish connection to the concentrator.

Dynamic Capacity Estimation calculates individual server capacities based on the load on each server. This enables the

capacity of each server to more accurately reflect the actual number of sessions it is capable of handling.

The load on each server is determined by its assigned XenApp load evaluator. The assigned evaluator(s) should therefore be

configured so that the desired load criteria are taken into account. The Power and Capacity Management agent regularly

monitors the load and updates the estimated capacity on its server accordingly.

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.

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 XenServer 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. Configure power controller preference in server properties. For best practice,

specify 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 drain mode. While in drain mode, a server does not accept new sessions, but allows

reconnection of disconnected sessions. (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 and reenables logons.

When Power and Capacity Management issues a power off or power on control, a timer starts (set the value of this timer


in the server profile). If the operation does not complete successfully before the timer expires, Power and Capacity

Management reports the operation failed. The management console displays power control operation failures. When a

power control operation completes successfully, all control errors associated with that server are cleared.

You can enable or disable power management on a global and per-workload basis. The global setting overrides the per-

workload setting. When you disable power management for a workload, any servers currently in drain mode are reverted

out of drain mode.

Load consolidation has the opposite effect to traditional XenApp load balancing. It aims 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 running 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. It

aims to load up small groups of servers with new sessions to a level that the servers are comfortable with handling. In

Power and Capacity Management, this level is called the optimal load. Once a server reaches optimal load, load

consolidation will enable an additional server in the workload to accept new session load. When used in conjunction with

Power Management, this additional server will be powered on automatically if it is currently powered off.

The optimal load is a configurable value expressed as a percentage, with a default value of 70%. That is to say, load

consolidation will add sessions to a server until it reaches or exceeds 70% of full server capacity. The remaining 30% of

capacity acts as a buffer to ensure existing sessions on the server have spare computing resources to work with. You can

tune the optimal load threshold to find the right balance between performance and utilization.

For load consolidation to work effectively, the capacity level of each server needs to be measured. Because the remaining

capacity can change as load on the server fluctuates, capacity levels need to be continually re-evaluated. This is the role of

dynamic capacity estimation.


Installing Power and Capacity Management

May 04 , 2015

To install the Power and Capacity Management components, use the installation (MSI) packages interactively (wizard-based) or in a silent installation.

Inst allat ionInst allat ionPackagePackage

Descript ionDescript ion

XenAppPCMAgent.msi Installer for the agent

XenAppPCMAdmin.msi Combined installer for the administration components (database, reports, concentrator, andmanagement console)

If you are not installing all the administration components at the same time on the same computer, install them in thefollowing 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

Although Power and Capacity Management planning encompasses many considerations, preparation tasks specific to the

component installation include:

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

mode to unmanaged or managed (base load) for servers that are not power controlled. This practice prevents the

possibility of session load being sent to XenApp farm servers that Power and Capacity Management is not aware of .

Decide where to install the Power and Capacity Management components.

Install the agent on each XenApp server.

You can install all the administration components on a single computer. You can also install one or more individual

administration components on separate computers.

The XenApp servers on which you install the 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 you

can run the installation 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.

Choose a farm name and workload name. You specify the farm name when installing the concentrator and the agent,

and the workload name when installing the agent.


Important: The following requirements apply when using Power and Capacity Management components for a farmcomprising XenApp for Windows Server 2008 R2 servers.

Supported Platforms

The Enterprise and Platinum Editions of XenApp for Windows Server 2008 R2 support this version of XenApp Power and

Capacity Management.

The 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 XenServer virtual computers hosting XenApp servers (in one or more XenServer clusters) are

supported through the XenServer API.

You can host XenApp on Microsoft Hyper-V or VMWare platforms and install the Power and Capacity Management agent.

However, only capacity monitoring, reporting, and load consolidation are supported; power management is not supported.

Component Requirements

Unless otherwise noted, 32-bit and 64-bit editions are supported.

ComponentComponent Support and Requirement sSupport and Requirement s

Database Requirements:Microsoft .NET Framework 3.5

Microsoft SQL Server 2005, Microsoft SQL Server 2008, or Microsoft SQL Server 2008 R2; see

CTX114501 for the latest supported versions

Microsoft SQL Server Reporting Services

Internet Information Services (IIS) 6.0 (required only if using Microsoft SQL Server 2005)

Use Microsoft Internet Explorer to view reports.

Concentrator Supported operating system: Windows Server 2008 R2 (64-bit)

Requirement: Microsoft .NET Framework 3.5

Agent Supported operating system: Windows Server 2008 R2 (64-bit)

Requirements:Microsoft .NET Framework 3.5

XenApp for Windows Server 2008 R2

Management

console

Supported operating systems:Windows Server 2003

Windows Server 2008


Windows XP

Windows Vista

Windows 7

Requirements:


Microsoft .NET Framework 3.5

MMC 3.0 Update: http://support.microsoft.com/kb/907265 (pre-installed on Windows Vista,

Windows 7, Windows Server 2008, and Windows Server 2008 R2 systems)

ComponentComponent Support and Requirement sSupport and Requirement s

When installing the concentrator, you specify the database (and the database instance, if you are not using the default

instance). By default, the installer updates the database to give the concentrator necessary permissions. This action

assumes that the user installing the concentrator has administrator privileges on the SQL Server instance to modify the

permissions of the Power and Capacity Management database.

If the user installing the concentrator does not have administrator privileges on the SQL Server to modify the permissionsof the Power and Capacity Management database:

In a wizard-based installation, select the Do not grant DB access to concentrator check box. (This check box appears

only when you are not installing the concentrator and the database at the same time.)

In a silent installation, include the CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes property.

Then use SQL Server Management Studio to add the necessary permissions.

To add permissions to the database:1. Using SQL Server Management Studio, navigate to the main Security - Logins node.

2. Add a new login for the concentrator identity. If you are running the concentrator as the default network service, this is

domain-name\computer-name$. (If you are entering a machine account, do not use the Search button; instead, type the

machine account name.)

3. Navigate to the XenAppPCM database > Security > Users node.

4. Add a new user. Citrix recommends the User Name be the same as the Login Name you specif ied in step 2. In the role

membership list, select ConcentratorRole.

Installing a Second Concentrator

After installing the first concentrator on a machine, install another on a different computer. 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.

Interactively Installing the Agent

To interactively install the agent on a XenApp server, double-click XenAppPCMAgent.msi and follow the wizard prompts.

Interactively Installing the Administration Components

To interactively install the administration components (database, reports, concentrator, and management console), double-

click XenAppPCMAdmin.msi and follow the wizard prompts.

By default, all administration components are selected, except reports.

http://support.microsoft.com/kb/907265


Silently Installing the Agent

Use the following command to silently install the Power and Capacity Management agent on a XenApp server.msiexec /i XenAppPCMAgent.msi /qn CTX_XAPCM_ACCEPT_EULA=yes CTX_XAPCM_FARM_NAME=farm-name [CTX_XAPCM_WORKLOAD_NAME=workload-name] [CTX_XAPCM_AGENT_NOSTART=yes] [CTX_XAPCM_AGENT_ACCOUNT=domain-account] [CTX_XAPCM_AGENT_PASSWORD=domain-account-password]CT X_XAPCM_ACCEPT _EULA= yesCT X_XAPCM_ACCEPT _EULA= yes

Accepts the license agreement. To read the EULA (End User License Agreement), launch the installation interactively and

navigate to the license dialog.

If you omit this property, or if the specif ied value is not "yes," the installation fails.

CT X_XAPCM_FARM_NAME= f arm-nameCT X_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 (=). The collection of XenApp servers being managed by Power and Capacity

Management is known as a farm. This farm may include some or all of the servers in a XenApp farm or may contain XenApp

servers from different XenApp farms. The name must be unique.

If you omit this property, the installation fails.

CT X_XAPCM_WORKLOAD_NAME= workload-nameCT X_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.)

CT X_XAPCM_AGENT _NOST ART = yesCT X_XAPCM_AGENT _NOST ART = yes

Prohibits the Agent service from starting during installation.

If you omit this property, or if the specif ied value is not "yes," the Agent service starts during installation.

CT X_XAPCM_AGENT _ACCOUNT = domain-accountCT X_XAPCM_AGENT _ACCOUNT = domain-account

Domain account with the following rights:

Citrix administrator for the XenApp instance

Log on as service

Shut down the system

Query rights for Active Directory (to locate the "Citrix XenAppPCM" SCP for the farm assigned to this agent)

If you specify this property, you must specify a domain account password with the CTX_XAPCM_AGENT_PASSWORD

property. You must also supply a domain account with the CTX_XAPCM_CONCENTRATOR_ACCOUNT property when

installing the concentrator (because the Concentrator service cannot use a built-in account if the Agent service is using a

domain account and vice versa).

If you omit this property, the built-in "Local System" account is used. In this case, do not specify the

CTX_XAPCM_AGENT_PASSWORD property.

CT X_XAPCM_AGENT _PASSWORD= domain-account -passwordCT X_XAPCM_AGENT _PASSWORD= domain-account -password

Password for the domain account. This property is valid only if you specif ied a domain account with the

CTX_XAPCM_AGENT_ACCOUNT property.

Example of Silently Installing the Agent


The following command silently installs the agent with:A farm name of "my_farm"

A workload name of "my_workload"

The agent service running under the domain account "my_domain\my_user" with the password "my_password"

msiexec /i XenAppPCMAgent.msi /qn CTX_XAPCM_ACCEPT_EULA=yes CTX_XAPCM_FARM_NAME=my_farm CTX_XAPCM_WORKLOAD_NAME=my_workload CTX_XAPCM_AGENT_ACCOUNT=my_domain\my_user CTX_XAPCM_AGENT_PASSWORD=my_password

Silently Installing the Administration Components

Use the following command to silently install one or more Power and Capacity Management administration components.msiexec /i XenAppPCMAdmin.msi /qn CTX_XAPCM_ACCEPT_EULA=yes [ADDLOCAL=components] [CTX_XAPCM_FARM_NAME=farm-name] [CTX_XAPCM_DB_INSTANCE=db-instance] [CTX_XAPCM_DB_NAME=db-name] [CTX_XAPCM_REPORT_URL=report-url] [CTX_XAPCM_DO_NOT_ADD_ACCOUNT_TO_DB=yes] [CTX_XAPCM_CONCENTRATOR_ACCOUNT=domain-account] [CTX_XAPCM_CONCENTRATOR_PASSWORD=domain-account-password]CT X_XAPCM_ACCEPT _EULA= yesCT X_XAPCM_ACCEPT _EULA= yes

Accepts the license agreement. To read the EULA, launch the installation interactively and navigate to the license dialog.

If you omit this property, or if the specif ied value is not "yes," the installation fails.

ADDLOCAL= component sADDLOCAL= component s

Comma-separated list of components to be installed. Valid values are:

DatabaseInstaller

Reports

Concentrator

Console

Reports is a subfeature of the database component; therefore, you can install reports only if you are also installing the

database component, or if you previously installed the database component.

If you omit this property, the database, concentrator, and management console components are installed; reports is not

installed.

CT X_XAPCM_FARM_NAME= f arm-nameCT X_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 (=) . The collection of XenApp servers being managed by Power and Capacity

Management is known as a farm. This farm may include some or all of the servers in a XenApp farm, or it may contain

XenApp servers from different XenApp farms. The name must be unique.

If you are installing the database component and omit this parameter, the installation fails.

CT X_XAPCM_DB_INST ANCE= db-inst anceCT X_XAPCM_DB_INST ANCE= db-inst ance

Use this property when installing the database, reports, and concentrator components.

Database instance name.

If you are installing the database component, this property specif ies 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 specif ies the instance

name of the SQL Server instance in which the schema is installed. If the default SQL instance on this computer was

used, specify "." (dot); otherwise, specify the computer and instance name (for example, SQLServer\instance1").

If you omit this property, "." is used.

CT X_XAPCM_DB_NAME= db-nameCT X_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.

CT X_XAPCM_REPORT _URL= report -urlCT X_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 qualif ied 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 qualif ied with the instance name

(http[s]://server_name/ReportServer_instance_name.

If you omit this property, "http://local_machine_name/ReportServer" is used.

CT X_XAPCM_DO_NOT _ADD_ACCOUNT _T O_DB= yesCT X_XAPCM_DO_NOT _ADD_ACCOUNT _T O_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 specif ied value is not "yes," the database is configured to accept connections from the

concentrator.

CT X_XAPCM_CONCENT RAT OR_ACCOUNT = domain-accountCT X_XAPCM_CONCENT RAT OR_ACCOUNT = domain-account

Use this property when installing the concentrator.

Domain account with a userPrincipleName attribute within Active Directory with the following rights:

Log on as service

Read/write rights for Active Directory (to create the "Citrix XenAppPCM" SCP for the farm this concentrator manages);

for example, read/write access to the Active Directory concentrator computer container (CN)

If you specify this property, you must specify a password with the CTX_XAPCM_CONCENTRATOR_PASSWORD property.

You must also supply a domain account for the CTX_XAPCM_AGENT_ACCOUNT property when installing the agent

(because the Concentrator service cannot use a built-in account if the Agent service is using a domain account and vice

versa).

If you omit this property, the built-in "Network Service" account is used. In this case, do not specify the

CTX_XPCM_CONCENTRATOR _PASSWORD property.

CT X_XAPCM_CONCENT RAT OR_PASSWORD= domain-account -passwordCT X_XAPCM_CONCENT RAT OR_PASSWORD= domain-account -password

Use this property when installing the concentrator and only if you specif ied a domain account with the

CTX_XAPCM_CONCENTRATOR_ACCOUNT property.

Password for the domain account.


Example of Silently Installing the Administration Components

The following command silently installs all the administration components with:A farm name of "my_farm"

The default SQL Server instance on a server named "my_db" with a database name of "my_dbname"

Reporting services on "http://my_report_server/reportserver"

The concentrator running under the domain account "my_domain\my_user" with the password "my_password"

msiexec /i XenAppPCMAdmin.msi /qn CTX_XAPCM_ACCEPT_EULA=yes ADDLOCAL=Concentrator,Console,DatabaseInstaller,Reports CTX_XAPCM_FARM_NAME=my_farm CTX_XAPCM_DB_INSTANCE=my_db CTX_XAPCM_DB_NAME=my_dbname CTX_XAPCM_REPORT_URL=http://my_report_server/reportserver CTX_XAPCM_CONCENTRATOR_ACCOUNT=my_domain\my_user CTX_XAPCM_CONCENTRATOR_PASSWORD=my_password

To remove Power and Capacity Management components, use Windows Add/Remove Programs.

Removing the Concentrator

If you deployed a concentrator running as a domain user, removing the concentrator (using Add/Remove Programs) may

not remove the database entry. If this occurs, the concentrator continues to appear in the Cluster Management window.

To remove the database entry:1. Using an account with database administrator privileges, open SQL Server Management Studio and connect to the

XenAppPCM database.

2. Open the Concentrators table.

3. Select the row containing the concentrator you uninstalled and delete the row.


Configuring Power and Capacity Management

Aug 17, 2009

After component installation, first-time use of the Power and Capacity Management system includes specifying

configuration values. With a basic setup (using default setpoint values and without enabling load consolidation or power

management), you can monitor the system and create reports.

Complete the following Initial configuration tasks:Connect to a XenApp Power and Capacity Management farm to manage (required only if you have more than one

Power and Capacity Management farm)

Configure server profile properties

Configure server properties

Specify global configuration settings

Add machine managers, if your Power and Capacity Management farm includes XenApp servers hosted on XenServer

virtual machines

Optionally, add sites, if your Power and Capacity Management farm includes XenApp servers hosted on XenServer virtual

machines

After the initial setup, observe management console displays and generate reports. Using the collected information, youcan then:

Create a schedule

Enable power management and load consolidation

The management console connects to the master concentrator to obtain data. The menu, toolbars, and Actions pane are

standard MMC 3.0 panes, some of which can be hidden if required. The workloads and tabs panes comprise the Power and

Capacity Management snap-in.

The workloads pane contains the following information:

ColumnColumn Descript ionDescript ion

Workload All Workloads, plus names of individual workloads

PowerManaged

Indicates if power management is enabled or disabled for the system (All Workloads) and for eachworkload.

Checkmark = enabled ("override" indicates a manual override is in effect)

x = disabled (with a notation if a workload does not have a schedule)

LoadConsolidated

Indicates if load consolidation is enabled or disabled for the system (All Workloads) and for eachworkload.

Checkmark = enabled

x = disabled

Utilization Current utilization shown in meter form and percent text (utilization is the ratio of : total activesessions/total session capacity available from all online servers)


Sessions Current number of load, unused, and off line sessions, shown graphically and in absolute counts.

Servers Current number of online and off line servers in the workload, shown graphically and in absolute counts.

ColumnColumn Descript ionDescript ion

The tabs pane contains five tabs.

St at usSt at us

Utilization, sessions, and servers information on the Status tab is equivalent to the information for the selected workload in

the workloads pane above it.

When All Workloads is selected, the Status display also indicates if power management and load consolidation are

globally enabled or disabled.

When a single workload is selected, the Status display also indicates if power management and workload load

consolidation are enabled or disabled for that workload.

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 ormancePerf ormance

The Performance tab displays metric graphs collected for a specif ic 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.

ServersServers

The Servers tab lists all servers in the workload selected in the workloads pane. Information for each server includes:

ColumnColumn Cont entCont ent

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, draining, powering on, or powering off. If you disable logons to a server, this field indicates

Maintenance.

Utilization Current utilization percentage in graphic and text forms.

Sessions Current sessions counts in graphic and text forms.

Hovering over an entry displays the current session count for that server and the current load

consolidation activity, if any. An icon to the left of the graph represents the current load consolidation

activity (when load consolidation is enabled for the server's workload):

Green triangle = server is accepting new connections and is below optimal load

Yellow triangle = server is accepting new connections but is above optimal load


Grey dot = logons are disabled for this server

The Sessions graphic fades for servers in drain mode.

Session

Capacity

Hovering over an entry displays how the dynamic capacity estimate differs from the typical session

capacity value configured in the server profile (the session capacity value indicates 'calculated').

ColumnColumn Cont entCont ent

Capacit iesCapacit ies

The Capacities tab displays server profile information and the typical session capacity for each server profile (or Unset if the

typical session capacity has not been configured). To display the DNS names of servers that use a profile, select the profile,

then click the entry in the Servers column.

ScheduleSchedule

The Schedule tab displays the current Monday through Sunday schedule for a workload. (This tab is not displayed when All

Workloads is selected in the workloads pane.) The entry for each day indicates time and setpoint values.


Power and Capacity Management Task Descriptions

May 04 , 2015

When task instructions include selecting an entry in the Actions pane, there may be equivalent selections in the Action

menu. Also, when the task instructions include selecting an entry in a workload or tabs pane and then selecting from the

Actions pane, there may be equivalent selections in a right-click menu.

To connect to a Power and Capacity Management farm

This task is required only if you have more than one 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.

To configure or delete a server profile

In the tabs pane, select Capacities. Select one or more profiles.To configure server profile properties:

1. In the Actions pane, click Server Profile Properties. The Server Profile Properties dialog box appears.

2. Enter the typical session capacity value. A zero value is equivalent to unset.

3. Enter the power action timeout (seconds) value.

4. Enter the estimated session capacity limit in the range 0-1000 (0 = not set). This value must be greater than or equal

to the typical session capacity value.

To delete a server profile, click Delete Server Profile in the Actions pane. Confirm the deletion. You can delete a server

profile only if it has no associated servers.

To configure server properties

1. In the workload pane, select a workload or All Workloads.

2. In the tabs pane, select Servers, then select one or more servers.

3. In the Actions pane, click Server Properties.

4. In the Server Properties dialog box, select the desired control mode and power controller preference.

To specify global configuration settings

In the Actions pane, click Configuration. In the XenApp PCM Configuration dialog box:Select the control mode for new servers added to the Power and Capacity Management farm.

Select the optimal load percentage for servers.

Enable or disable metrics data collection. Select the number of days to retain the collected metrics data. The default is

365 days (1 year).

To add, modify, or delete virtual machine managers

In the Actions pane, click Machine Managers and use the Machine Managers dialog box to add, modify, or delete virtualmachine managers.

When adding a virtual machine manager:

Click Add.

Specify a URL to the XenServer resource pool in the form http[s]://ip-or-hostname.

For the type, leave Citrix XenServer 4.0 or newer selected.

For the site, specify where the resource pool is located.


For authentication, if you select the Authenticate with user name and password check box, specify the user name

and password XenServer uses to authenticate. Do not select the checkbox if you want to use the domain credentials

of the concentrator service to authenticate to XenServer (pass-through authentication).

Leave the Enable this machine manager checkbox selected.

When modifying a virtual machine manager, select the machine manager and click Modify. Change values as needed.

When deleting a virtual machine manager, select the machine manager and click Delete. Confirm the deletion.

Important: Assign unique MAC addresses to virtual machines even across resource pools. This is typically done by using theauto-generate MAC option when creating the virtual machine.

To add, modify, or delete a site

In the Actions pane, click Sites and use the Server Sites dialog box to add, modify, or delete a site.

When adding a site:

Click Add.

Specify a site name.

Select a power controller preference for servers that belong to this site.

When modifying a site, select the site and click Modify. Change values as needed.

When deleting a site, select the site and click Delete. Confirm the deletion.

To create, copy, or delete a schedule

Select a workload in the workloads pane. In the tabs pane, select Schedule.To create a schedule, select the Allow Edit checkbox. Edit the schedule for one or more days of the week.

To copy the schedule from the previous day, click the Copy day's schedule in the day of the week area.

To copy the entire workload schedule to another workload, ensure the workload being copied has focus, then select

Copy Schedule To in the Actions pane.

To delete a schedule, select Delete Schedule in the Actions pane.

To delete an individual schedule item, select the leftmost cell in the item, then press the Delete key.

To enable or disable power management and load consolidation

Select a workload or All Workloads in the workloads pane, then select an operation in the Actions pane, the Action menu, or

the right-click menu.

When you enable power management and load consolidation globally (by selecting All Workloads), you can also enable or

disable power management and load consolidation on a per-workload basis. The global setting overrides the per-workload

setting. For example, to enable power management for one workload, power management must be enabled for All

Workloads.

To generate a workload or server report

1. Select the reporting object:

To generate a workload report, in the workloads pane, select a workload or All Workloads. In the Actions pane, click

Generate Workload Report.

To generate a server report, click the Servers tab in the tabs pane and select a server. In the Actions pane, click

Generate Server Report.

2. Select the report type, period of time the report covers, and the interval.

3. Select Generate Report.

Important: The management console uses Microsoft Internet Explorer to display reports (overriding the user default


browser setting). For optimal display, always use Microsoft Internet Explorer to view reports.

To explicitly designate a master concentrator

1. Select Cluster Management in the Actions pane.

2. In the Cluster Management dialog box, select a concentrator and click Set Master.

To delete a server or workload

You can delete a server only if it (or the server it represents) is not online with the Power and Capacity Management agentrunning. To delete a server:1. Click the Servers tab and select one or more servers.

2. Click Delete Server in the Actions pane and confirm the deletion.

You can delete a workload only if it has no servers associated with it. Deleting a workload also deletes all associatedprofiles and schedules. To delete a workload:1. Select one or more workloads in the workloads pane.

2. Click Delete Workload in the Actions pane and confirm the deletion.

After you delete a server (or a workload or server profile) that is offline, if Power and Capacity Management discovers those

objects, they will be re-created. For example, if you delete an offline XenApp server that has the Power and Capacity

Management agent installed, then power on that server, the server will be re-added to the Power and Capacity

Management system.

To initiate or cancel a manual override

To initiate a manual override for a workload:1. Select the workload in the workloads pane.

2. Select Power Controller Manual Override in the Actions pane.

3. In the Power Controller Manual Override dialog box, enter setpoint values or select the infinity check boxes, and click

Start Override.

To cancel a manual override for a workload:1. Select the workload in the workloads pane.

2. Select Power Controller Manual Override in the Actions pane.

3. Click Stop Override.

To manually publish the concentrator

If the account running the Concentrator service does not have sufficient access in Active Directory (AD) to automatically

publish its service information, other Power and Capacity Management components will not be able locate Power and

Capacity Management and the system will not operate correctly. This will manifest itself by the concentrator writing errors

to the application log, and the console not showing the XenApp servers on which the agent has been installed.

To overcome this, manually publish the concentrator within AD.1. Log onto the computer hosting the concentrator using an account that has suff icient access in AD.

2. Ensure that the Concentrator service is running.

3. From a command prompt, change directory (CD) to the directory in which the PCMConcentrator.exe f ile is located; by

default this is “%SystemDrive%\Program Files\Citrix\ XenApp Power and Capacity Management\Concentrator”. Run the

following command:

PCMConcentrator /publish


4. Restart the Concentrator service.

This creates an AD object only; no AD schema changes are required. This object is created as a child object of the computer

container hosting the concentrator, called “CN=Citrix XenAppPCM SCP”.

Conversely, you can manually revoke the publishing information by running:

PCMConcentrator /revoke

This command deletes the aforementioned object in AD.

To change the workload assigned to a XenApp server

A XenApp server is assigned to a workload during the installation of the Power and Capacity Management agent. You can

change the name of the workload to which a XenApp server is assigned by editing the registry on 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 Editorat your own risk. Be sure to back up the registry before you edit it.Key:

HKEY_LOCAL_MACHINE\Software\Policies\Citrix\XenAppPCM

String ValueName:

WorkloadName

Change the contents of the WorkloadName to the value required. The Agent service does not need to be restarted for this

change to take effect.

To unassign the server from all workloads, enter the value Unassigned.


XenApp and Secure Gateway

May 08 , 2015

The Secure Gateway for Windows helps you to secure access to enterprise network computers running Citrix XenApp and

provides a secure Internet gateway between Citrix XenApp and user devices. The Secure Gateway transparently encrypts

and authenticates all user connections to help protect against data tampering and theft. All data traversing the Internet

between a remote workstation and the Secure Gateway is encrypted using the Secure Sockets Layer (SSL) or Transport

Layer Security (TLS) protocol.

The Secure Gateway is an application that runs as a service on a server that is deployed in the demilitarized zone (DMZ).

The server running the Secure Gateway represents a single point of access to the secure, enterprise network. The Secure

Gateway acts as an intermediary for every connection request originating from the Internet to the enterprise network. For

increased security, the Secure Gateway Proxy is used with the Secure Gateway in a double-hop DMZ deployment. The

Secure Gateway is installed in the first DMZ and the Secure Gateway Proxy is installed in the second DMZ. The Secure

Gateway Proxy acts as a conduit for traffic originating from the Secure Gateway to servers in the secure network, and

from servers in the secure network to the Secure Gateway.

Your enterprise network can contain one or more servers running Citrix XenApp. A server farm is used for hosting published

resources that users can access over the network.

The Secure Gateway works with the following components of Citrix XenApp for logon and authentication:

Citrix Web Interface

Provides user access to published resources in a server farm from a Web browser. The Web Interface works with the Secure

Gateway to provide a logon interface, and facilitates authentication and authorization of connection requests to the

server farm.

Secure Ticket Authority (STA)

The STA is responsible for issuing session tickets in response to connection requests for published resources on Citrix

XenApp. These session tickets form the basis of authentication and authorization for access to published resources. During

installation of Citrix XenApp, the STA is installed automatically. It is no longer necessary to reserve a separate server for the

STA.

Citrix XML Service

When the Secure Gateway provides secure access to published resources available in a server farm, the Citrix XML Service is

contacted for published resources availability and location. The Citrix XML Service is the point of contact for a server farm

and provides an HTTP interface to the user device. It uses the TCP protocol instead of UDP, which allows connections to

work across most f irewalls. The default port for the Citrix XML Service is 80. Ensure that this port is configured, functioning

correctly, and is accessible through the f irewall in front of the secure network.

Citrix Online Plug-in Web

You can use Citrix online plug-in web to access resources available from the Web Interface and for access to resources

published with traditional Application Launching and Embedding (ALE).

Important: The Secure Gateway and Secure Gateway Proxy are not supported in environments using Advanced AccessControl.

Secure Gateway Features

Designed-in security

The Secure Gateway provides authentication, authorization, and cryptography functionality that is consistent with


Microsoft’s best practices for secure software.

Network protocol support

The Secure Gateway supports the TCP/IP protocols, such as FTP, HTTP, and Telnet.

IPv4 and IPv6 protocol support

The Secure Gateway can be configured to accept inbound connections from clients using IPv4 and IPv6 addresses.

Secure Socket Layer support

The Secure Gateway provides SSL support to secure communication between the client and the Secure Gateway

components.

Simple deployment

Citrix XenApp includes the Secure Ticket Authority (STA) and is merged into a single Windows Installer package resulting in a

more eff icient deployment. The STA is deployed automatically on the same computer as Citrix XenApp, resulting in a

reduction of the number of computers required for basic deployment Internet Information Server is no longer a

requirement for installing the STA Internet Information Server deployment is a supported option during installation of Citrix

XenApp.

Certif icate management

The Secure Gateway Configuration wizard prevents the selection of a certif icate that does not have a private key and

verif ies that the appropriate certif icate is installed in the local computer certif icate store. Wildcard certif icate support.

Wildcard certif icates can be deployed on the Secure Gateway, the Secure Gateway Proxy, and on the computer where

Citrix XenApp is hosting the STA.

Load balancing

The Secure Gateway provides load balancing for the Secure Gateway Proxy. IP addresses are retrieved from the DNS using

a domain name or listed individually.

Logging

The Secure Gateway uses the Apache standard access log f iles and supports log rotation functionality for the access log

files. The access log f iles provide connection information to the Secure Gateway or the Secure Gateway Proxy.

Instrumentation

The Secure Gateway includes a new set of performance counters to analyze the usage and load on the Secure Gateway

server.

Based on Apache Technology

The software code based on Apache technology is used as a foundation for building the Secure Gateway.

Section 508 compliance

Secure Gateway is compliant with Section 508 of the United States Workforce Rehabilitation Act of 1973.

Session reliability

Improvements in session reliability benefit both mobile and local users by having their work items remain open when

network connectivity is lost, and then seamlessly resumed when connectivity is restored. This feature is especially useful for

mobile users with wireless connections that are interrupted or dropped. When a session connection is interrupted, all open

windows to published resources remain visible while reconnection is attempted automatically in the background.

Relay mode

Secure Gateway can be installed in relay mode for internal secure communications. Relay mode can be used in secure

corporate environments such as intranets, LANs, and WANs. Relay mode is not recommended for external connections

from the Internet to a server farm or server access farm.

Supports single-hop or double-hop DMZ deployment

The Secure Gateway can be installed to span a single-hop or a double-hop DMZ. If your DMZ is divided into two stages,

install the appropriate Secure Gateway component in each DMZ segment to securely transport HTTP/S and ICA traff ic to


and from the secure network.

Supports secure communication between the Secure Gateway components

The Secure Gateway components support the use of digital certif icates and the task of securing links by using SSL/TLS

between components.

Conf iguration, management, and diagnostic tools

The Secure Gateway Management Console is a Microsoft Management Console (MMC) snap-in you can use to manage,

analyze, and troubleshoot a Secure Gateway deployment. The Secure Gateway Diagnostics tool, available from the Secure

Gateway Management Console, reports configuration values, certif icate details, and the state of each configured

component.

Minimal client conf iguration

User devices require no preinstalled software for security. Remote, secure access is easy to support, requiring little effort

from IT staff .

Certif icate–based security

The Secure Gateway uses standard Public Key Infrastructure (PKI) technology to provide the framework and trust

infrastructure for authentication and authorization.

Standard encryption protocols

The Secure Gateway uses industry-standard SSL or TLS encryption technology to secure Web and application traff ic

between the client and server. Connections between clients and the Secure Gateway are encrypted using SSL or TLS

protocols. You can further enhance security by forcing the Secure Gateway to restrict its use of ciphersuites to commercial

or government ciphersuites certif ied for Federal Information Processing Standard (FIPS) 140 requirements.

Authentication and authorization

The Secure Gateway works with the Web Interface to facilitate authentication of users attempting to establish

connections to a server farm. Authorization occurs when the Secure Gateway confirms that the user is authenticated by

the enterprise network. The authorization process is entirely transparent to the user.

Single point of entry

The need to publish the address of every Citrix XenApp server is eliminated and server certif icate management is simplif ied.

The Secure Gateway allows a single point of encryption and access to computers running Citrix XenApp.

Firewall traversal

Connections from clients are secured with standard protocols using ports typically open on corporate f irewalls. This allows

easy traversal of f irewalls without custom configuration.

Ease of installation and management

Adding the Secure Gateway to an existing server farm is relatively quick and simple, and requires minimal configuration,

signif icantly reducing time and management costs.

Reliability and fault tolerance

The solution allows implementation of duplicate components to enable a redundant system. Large arrays can be built using

industry-standard SSL load balancing systems for scalability. Even if hardware fails, the server farm remains protected.

Scalable and extensible solution

A single server running the Secure Gateway can support a small corporate site consisting of hundreds of users. You can

support medium to large sites catering to thousands of users connecting to an array of load balanced servers running the

Secure Gateway. The Secure Gateway components do not require special hardware devices or network equipment

upgrades.

Event and audit logging

Critical and fatal system events are logged to the Secure Gateway application log, enabling administrators to help diagnose

system problems. Logging levels are configurable and can be set from the user interface. Depending on the configured


logging level, you can retrieve a complete record of network connection attempts to the Secure Gateway. You can also

configure the Secure Gateway to omit log entries for polls from network equipment such as load balancers.

Planning a Secure Gateway Deployment

The deployment of the Secure Gateway depends on several factors, including which Citrix components you have in your

enterprise network. The Secure Gateway is designed to work with Citrix XenApp.

If your enterprise network contains a server farm, you can deploy the Secure Gateway to provide secure Internet access to

published resources. In such deployments, the Secure Gateway works with the Web Interface to provide authentication,

authorization, and redirection to published resources hosted on a Citrix XenApp server.

To ensure that the security of the Secure Gateway is not compromised, Citrix recommends reserving servers for the

exclusive use of the Secure Gateway.

Note: Citrix recommends setting up the Secure Gateway in a test environment before implementation to your productionenvironment 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 f irewalls to restrict access to specif ic TCP ports only. If youconfigure your f irewalls to allow access to TCP ports other than those used for HTTP, ICA, SSL, and XML data, you mayallow users to gain access to unauthorized ports on the server.

Installing the Secure Ticket Authority

When Citrix XenApp is installed, the Secure Ticket Authority (STA) is installed and configured automatically.

The STA eliminates the requirement for Microsoft’s Internet Information Services (IIS). The STA can be hosted by the Citrix

XML Service. If the STA is hosted by the Citrix XML Service, configure the Citrix SSL Relay.

During installation of the Secure Gateway, enter the FQDN of the server running Citrix XenApp. If you are using an SSL-

enabled connection between the Secure Gateway and the STA, make sure the correct certificates are installed from a

certificate authority.

Testing Your Deployment

After you complete installation and configuration of the Secure Gateway, test your deployment to make sure it works and

is accessible through the Internet.

If you encounter problems loading the logon page, try working your way through the deployment steps to figure out the

problem.

You can also run the Secure Gateway Diagnostics tool to find a solution. This utility contacts all servers running the Secure

Gateway components and generates a report containing configuration and status information for each component. For

more information, see Generating the Secure Gateway Diagnostics Report.

To test your deployment

1. Use a web browser on the 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 with the domain credentials. After a brief interval, the Applications page containing icons for published resources

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-event-viewer-task-v2.html


appears.

3. Verify that you can start published applications from this page.


System Requirements for Secure Gateway

Jul 11, 2012

The Secure Gateway and Secure Gateway Proxy are not supported in environments using Advanced Access Control.

Operating Systems

You can install the Secure Gateway components on computers running:Windows Server 2008 R2 Service Pack 1

Windows Server 2008 R2

Windows Server 2008 Service Pack 2 (32- and 64-bit)

Windows Server 2003 Service Pack 2 (32- and 64-bit)

Important: Secure Gateway runs as a 32-bit application on 64-bit Windows operating systems.

Hardware Requirements

The Secure Gateway requires the minimum hardware requirements for supported Windows operating systems, as specified

by Microsoft.

Important: For maximum security, Citrix recommends you reserve a standalone server for the Secure Gateway.

Citrix Products Compatibility with Secure Gateway

The Secure Gateway is compatible with the following Citrix products:Citrix XenApp 6.5 for Windows Server 2008 R2

Citrix XenApp 6 for Windows Server 2008 R2

Citrix XenApp 5 for Windows Server 2008

Citrix XenApp 5 for Windows Server 2003

Web Interface

You can use Secure Gateway installed on a computer running a different Windows operating system than XenApp servers in

the same environment.

The Secure Gateway is compatible with the following Citrix Receiver for Windows and Citrix online plug-in software:Citrix Receiver for Windows 13.0, which includes Citrix Receiver Admin and Citrix Receiver Web. Citrix Receiver for

Windows 13.0 is the successor to the Online Plug-in for Windows 12.1.

Citrix Online Plug-in for Windows 12.1, including Citrix online plug-in web.

Citrix Online Plug-in for Windows 11.2, including Citrix online plug-in web.

Important: Secure Gateway and Secure Gateway Proxy do not support the Citrix Offline Plug-in.

User Devices

The following Microsoft operating systems are supported for user devices:

Windows XP Home Edition


Windows XP Service Pack 3

Windows Vista

Windows Vista Service Pack 2

Windows 7

Windows 7 Service Pack 1


Windows Server 2003

Windows Server 2008


Windows Server 2008 R2 Service Pack 1

Note: Operating systems on mobile devices, such as Android, iOS, Mac, and PlayBook, may also support connections forReceiver using Secure Gateway. For mobile devices, refer to the System Requirements of the device for supportedconnections.


Certificate Requirements

Jul 22, 2010

All user devices and secure servers in a Secure Gateway deployment use digital certificates to verify each other’s identity

and authenticity.

The Secure Gateway supports the use of digital certificates. As the security administrator, you need to decide whether or

not the communication links between the Secure Gateway and other servers in the DMZ or secure network need to be

encrypted. See Digital Certificates and the Secure Gateway.

Important: If you purchased server certif icates from a commercial certif icate authority (CA), support for root certif icatesfor most commercial CAs is built into Internet Explorer and Windows server products. If you obtained server certif icatesfrom a private CA or commercial CA whose root certif icates are not, by default, supported by the Windows operatingsystem, you must install matching root certif icates on all user devices and servers connecting to secure servers.

Certificate Requirements for a Single-Hop DMZ

If your secure network contains Citrix XenApp with the Secure Gateway in the DMZ, servers and clients need the following

certificates:

Root certif icates on all user devices that connect to the server running the Secure Gateway.

Root certif icates on every Secure Gateway component that connects to a secure server. For example, a root certif icate

must be present on the server running the Secure Gateway to verify the server certif icate installed on the server running

the STA.

A server certif icate on the server running the Secure Gateway.

Optional. A server certif icate on the servers running the STA. The STA is installed by default when you install Citrix

XenApp.

All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links

between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Certificate Requirements for a Double-Hop DMZ

If your secure network contains Citrix XenApp with the Secure Gateway in the first DMZ, and the Secure Gateway Proxy

and the Web Interface in the second DMZ, servers and clients require the following certificates:

Root certif icates on all user devices connecting to the server running the Secure Gateway.

Root certif icates on every Secure Gateway server that connects to a secure server or Web server. For example, an

appropriate root certif icate must be present on the server running the Secure Gateway to verify the server certif icate

installed on the Citrix XenApp server.


Optional. A server certif icate on the server(s) running the Secure Gateway Proxy.

Optional. A server certif icate on the server running the STA.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-digital-certificates-wrapper-v2.html


Deploying the Secure Gateway in a Single-Hop DMZ

May 08 , 2015

In a single-hop deployment, users can connect to the enterprise network in two ways. The first is where the Secure

Gateway intercepts the client connection and routes it to the Web Interface. After logging on and authenticating user

credentials, the Secure Gateway handles the connection. Alternatively, users can be directed to the Web Interface first,

where they log on and then the connection is handled by the Secure Gateway. The first scenario is referred to as “behind

the Secure Gateway.” The second scenario is referred to as “parallel to the Secure Gateway.”

Certificate Requirements for a Single-Hop DMZ Deployment

If the Secure Gateway is in the DMZ, servers and clients need the following certificates:

Root certif icates on all user devices that connect to the server running the Secure Gateway.

Root certif icates on every Secure Gateway component that connects to a secure server. For example, a root certif icate

must be present on the server running the Secure Gateway to verify the server certif icate installed on the server running

the STA.


Optional. A server certif icate on the servers running the STA. The STA is installed by default when you install Citrix

XenApp.

All Secure Gateway components support the use of digital certificates. Citrix recommends that the communication links

between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Deployment Scenario A: Secure Gateway in a Single-Hop DMZ

WXYCo Inc. is an audit firm that recently purchased licenses for Citrix XenApp.

The company’s employees are financial auditors who visit client sites and conduct financial audits. They use a proprietary,

client-server auditing software application, AuditorX. They publish AuditorX on computers running Citrix XenApp. They also

deploy the Web Interface for Web access to their published resources. Employees can access AuditorX and other published

resources through a Web browser on a user device connected to the LAN.

WXYCo realizes installing the Secure Gateway allows them to provide secure Internet access to published resources on its

server farms. Because the workforce is largely mobile, use of the Internet to connect to the enterprise network is expected

to reduce remote access costs dramatically.


A secure server farm using a single-hop DMZ.

This figure illustrates a secure enterprise network separated from the Internet by a single-hop DMZ. The enterprise

network contains a server farm including one server running Citrix XenApp with the Secure Ticket Authority (STA). The

firewall separating the secure network from the DMZ has ports 80, 443, and 1494 open. If session reliability is enabled, port

2598 is open on the internal firewall.

The DMZ contains a single server running the Secure Gateway, and the Web Interface. Traffic to the Web Interface is

proxied through the Secure Gateway which communicates with the Web Interface using HTTP.

The DMZ is separated from the Internet by a firewall that has port 443 open. The mobile workforce carries notebook PCs

running a 32-bit Windows operating system, Internet Explorer 5.5, and the Citrix online plug-in for 32-bit Windows.

The security analyst recommends securing the communication link between the Secure Gateway and the STA. To do this,

the company purchased two server certificates from a commercial certificate authority (CA). The server running the Secure

Gateway and the Web Interface have root and server certificates installed. The server running Citrix XenApp has a server

certificate installed. For more information about certificates, see Digital Certificates and the Secure Gateway.

Running the Web Interface behind the Secure Gateway in the Demilitarized Zone

In a single-hop DMZ deployment scenario, all incoming traffic is intercepted by the Secure Gateway. The Web Interface can

be installed on the same server as Secure Gateway or on a separate server. All data exchanged between user devices and

the Web Interface is relayed through the Secure Gateway.

The firewall facing the Internet has port 443 open. Users connect to the Secure Gateway using a URL such as

https://Secure Gateway FQDN/, where Secure Gateway FQDN is the fully qualified domain name for the server running the

Secure Gateway.

Advantages A single server certif icate is required on the server running the Secure Gateway and theWeb Interface.

A single port, 443, must be opened on the f irewall facing the Internet.

The Web Interface cannot be contacted directly from the Internet and is more secure.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-digital-certificates-wrapper-v2.html


Disadvantages Deploying the Secure Gateway in this configuration affects Web Interfacefunctionality. When you deploy the Secure Gateway in this configuration, you lose someof the features available with the Web Interface, including the following:

Smart Card Authentication. The Secure Gateway negotiates the SSL handshake andterminates the SSL connection before forwarding the client connection request to theWeb Interface. Smart card authentication integrated with the Web Interface isunavailable because the Secure Gateway terminates the SSL connection before itreaches the Web Interface.

Firewall and Proxy Settings Requiring Knowledge of the Client IP Address AreIneffective. All communication from the user device to the Web Interface is proxiedthrough the Secure Gateway. As a result, all client communications to the WebInterface originate from the IP address of the server running the Secure Gateway.Though you can still configure f irewall and proxy settings on the Web Interface forspecif ic client address prefixes, these settings must allow all client communicationsthrough the Secure Gateway to have the Web Interface IP address. You will not be ableto distinguish between different user devices connecting through the Secure Gateway.

Citrix recommends deploying the Secure Gateway in this configuration if your network is small to medium sized, with a

usage profile of hundreds of users. This type of deployment is optimal when users are connecting over the Internet to the

Secure Gateway.

If any of the limitations described above are a concern and you have a sizeable user base accessing the Secure Gateway

over the LAN, consider deploying the Web Interface in the configuration described in Running the Web Interface Parallel

with the Secure Gateway.

Locking Down Internet Information Services

All traffic to the server running the Web Interface is proxied through the server running the Secure Gateway. Lock down

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 Interface Parallel with the Secure Gateway

In this configuration, the Secure Gateway and the Web Interface are installed on separate servers. Users can connect

directly to the Web Interface.

Users connect directly to the Web Interface, using a URL such as https://Web Interface FQDN/citrix/AccessPlatform or

https://Web Interface FQDN/citrix/XenApp, where Web Interface FQDN is the fully qualified domain name for the server

running the Web Interface.

Citrix recommends securing both servers by installing a server certificate on each server running the Secure Gateway and the

Web Interface. Open port 443 on the firewall facing the Internet.

You want to use the features available with the Web Interface, including smart card authentication and firewall and proxy

settings that depend on knowing the client IP address.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-singlehop-deployments-v2.html


Setting Up and Testing a Server Farm

Complete the following tasks prior to installing and configuring the Secure Gateway.

Install and configure a server farm in the enterprise network.

Install, configure, and publish applications on the server farm.

Connect to the server farm using a user device and ensure you can access available published resources.

See the Citrix XenApp installation and administration topics for detailed instructions about performing these tasks.


Deploying the Secure Gateway in a Double-Hop DMZ

May 16, 2015

Deploy the Secure Gateway in a double-hop DMZ configuration if your DMZ is divided into two segments. In this

configuration, the server running the Secure Gateway is in the first DMZ segment. The firewall between the first DMZ

segment and the Internet has port 443 open.

The Web Interface and the Secure Gateway Proxy are installed on separate servers in the second DMZ segment. The

server farm is located in the secure network. The firewall between the first and second DMZ segments has ports 80 and

443 open.

The Secure Gateway, deployed in the first DMZ segment, is responsible for intercepting all incoming traffic. The Web

Interface is responsible for user authentication and authorization. After authentication, the Secure Gateway Proxy is

responsible for relaying all data exchanged between the Secure Gateway and servers in the secure network. The firewall

between the second DMZ segment and the secure network has ports 80, 443, and 1494 open.

Deploy the Secure Gateway in this configuration if your network contains a double-hop DMZ. A double-hop DMZ provides

additional protection because an attacker would need to penetrate multiple security zones to reach servers in the secure

network.

If the resources accessible through the Secure Gateway are extremely sensitive and require a high level of security, consider

this configuration.

Certificate Requirements for a Double-Hop DMZ Deployment

If the Secure Gateway is in the first DMZ, the Secure Gateway Proxy is in the second DMZ, and the Web Interface is in the

second DMZ, servers and clients need the following certificates:

Root certif icates on all user devices connecting to the server running the Secure Gateway.

Root certif icates on every Secure Gateway component that connects to a secure server or Web server. For example, an

appropriate root certif icate must be present on the server running the Secure Gateway to verify the server certif icate

installed on the server running Citrix XenApp.


Optional. A server certif icate on the server(s) running the Secure Gateway Proxy.

Optional. A server certif icate on the server running the STA.

All Secure Gateway components support the use of digital certificates. Although not a requirement, Citrix recommends that

the communication links between the Secure Gateway and other servers in the DMZ or secure network be encrypted.

Deployment Scenario B: Double-Hop Demilitarized Zone

WXYCo, Inc. deployed the Web Interface for access to published resources hosted on Citrix XenApp servers. The company

plans to deploy the Secure Gateway to provide secure Internet access to published resources.

The security analyst recommended setting up a double-hop DMZ between the Internet and the company’s secure network

and securing communications between the Secure Gateway, the Web Interface, and the Secure Gateway Proxy.

A Secure Gateway deployment in a double-hop DMZ environment with a server farm


This figure shows a Secure Gateway deployment used to secure a server farm in a double-hop DMZ environment. The

secure enterprise network is separated from the Internet by a double-hop DMZ. The enterprise network contains a server

farm including a server running Citrix XenApp with the Secure Ticket Authority (STA). The firewall separating the secure

network from the second DMZ segment has port 443 open. If session reliability is enabled, port 2598 is open.

The second DMZ segment contains a server running the Secure Gateway Proxy and a second server running the Web

Interface. The firewall separating the first and second DMZ segments has port 443 open. The first DMZ segment contains

a single server running the Secure Gateway. All traffic originating from the Secure Gateway to servers in the secure network

is proxied through the Secure Gateway Proxy.

If the communications link between the Secure Gateway and the Secure Gateway Proxy is not secured, open port 1080 on

the firewall between the first DMZ segment and the second.

The Secure Gateway communicates directly with the server running the Web Interface in the second DMZ segment, which

in turn communicates directly with servers in the secure network. The first DMZ segment is separated from the Internet by

a firewall that has port 443 open.

The mobile workforce carries notebook PCs running a 32-bit Windows operating system, Internet Explorer 5.5, and the

Citrix online plug-in for 32-bit Windows.

Setting Up the Secure Gateway and the Secure Gateway Proxy in a Double-Hop DMZ

The Secure Gateway is installed on a standalone server in the first DMZ. The Secure Gateway Proxy is installed on a stand-

alone server in the second DMZ.

See Installing the Secure Gateway and Secure Gateway Proxy.

Setting Up and Testing the Web Interface in a Double-Hop DMZ

The Web Interface needs to be set up on a Web server in the second DMZ segment. Ensure you complete the following

tasks before you install the Secure Gateway.

1. Install the Web Interface on a standalone server in the second DMZ segment.

2. To secure communications between the Secure Gateway and the Web Interface, ensure you install a server certif icate

on the server running the Web Interface.

3. Add and configure server farms for use with the Web Interface.

4. Configure the Secure Gateway using the FQDN of the STA.



5. Use a Web browser on a user device to connect and log on to the Web Interface.

6. Verify that you can launch published applications.

Publishing the Web Address for the Secure Gateway in a Double-Hop Demilitarized Zone

In a double-hop deployment, all traffic to the Web Interface is proxied through the Secure Gateway. Provide users with one

of the following default web address to access the logon page or XenApp web site:

https://Secure Gateway FQDN/Citrix/AccessPlatform

https://Secure Gateway FQDN/Citrix/XenApp

where Secure Gateway FQDN is the fully qualified domain name for the server running the Secure Gateway.

In the case of WXYCo, the default web address for the logon page or web site is one of the following:

https://www.gateway01.wxyco.com/Citrix/AccessPlatform/

https://www.gateway01.wxyco.com/Citrix/XenApp

Alternatively, consider changing the default web root directory in IIS on the server running the Web Interface to point to

the Web Interface directory. This enables you to access the logon page or web site by connecting directly to the root web

address; that is, https://Secure Gateway FQDN/.

In this case, the web address that employees of WXYCo use to access the logon page is:

https://www.gateway01.wxyco.com/


Installing the Secure Gateway and Secure GatewayProxy

May 08 , 2015

In addition to describing the Secure Gateway and Secure Gateway Proxy installation and configuration processes, this

section also explains how to move to the current version of Secure Gateway from an installed earlier version. It also

presents how to use a firewall with Secure Gateway and Secure Gateway Proxy.

When Secure Gateway or Secure Gateway Proxy is installed on a supported 64-bit Windows operating systems, it installs in

the 32-bit application location by default.

Important: You must have access to administrative privileges to install and configure the Secure Gateway and use themanagement tools. If User Account Control (UAC) is enabled, you must run the installer program in elevated mode; that is,with administrative privileges enabled.

Upgrading Secure Gateway or Secure Gateway Proxy

Upgrading from earlier versions of Secure Gateway or Secure Gateway Proxy is not supported. You must perform a fresh

installation:

1. Remove any installed Secure Gateway hotfix software packages.

2. Remove the Secure Gateway or Secure Gateway Proxy software.

3. Perform a fresh installation of Secure Gateway or Secure Gateway Proxy.

Using Firewall Software with the Secure Gateway or Secure Gateway Proxy

The firewall software included in your Microsoft Windows server operating system (such as Windows Firewall with

Advanced Security) where the Secure Gateway or Secure Gateway Proxy is used might not automatically allow access to

required ports. Non-Microsoft firewall software might also disallow port access by default.

Also, the Secure Gateway or Secure Gateway Proxy does not automatically create an exception to allow access to the

default SSL port 443, the default Secure Gateway Proxy port 1080, or any port number you select when configuring the

software.

Manually add or allow access to these ports to any firewall software you are using in your environment.

Installing the Secure Gateway or Secure Gateway Proxy

The Secure Gateway installer installs the Secure Gateway or the Secure Gateway Proxy. When installation is complete, the

Secure Gateway Configuration wizard automatically starts so you can configure Secure Gateway.

The following steps outline the installation sequence of the Secure Gateway:Install Citrix XenApp.

Install root and server certif icates on the appropriate computers.

If using a double-hop DMZ, install the Secure Gateway Proxy in the second DMZ.

If you are securing communications between the Secure Gateway and the Secure Gateway Proxy, ensure you install a

server certif icate on the server running the Secure Gateway Proxy.

Install the Secure Gateway in the f irst, or only, DMZ.

Important: The Secure Gateway is designed to discover and verify the existence of the other Citrix components during


configuration. For example, during configuration the Secure Gateway verif ies that servers running the Web Interface andthe Secure Ticket Authority (STA), if used, are functional. If a required component is not found, the Secure Gateway mayfail to start. Ensure that you follow the recommended installation sequence.The installation sequence must be in this order:

1. Always install components within the secure network f irst.

2. Optional. If your network contains a double-hop DMZ, install components in the second DMZ segment next.

3. Install components in the f irst DMZ segment last.

To install the Secure Gateway or Secure Gateway Proxy

1. On the installation media, click autorun.exe. The Autorun menu launches..

2. Select Manually install components > Server Components > Secure Gateway.

3. On the Welcome screen, click Next.

4. Read and accept the license agreement, and then click Next.

5. In Installation Mode, select Secure Gateway or Secure Gateway Proxy.

6. To install the Secure Gateway components in the default destination path, click Next. To install these components in a

different location, click Browse and then navigate to the folder you want to use.

7. In Service Account, select the user account to determine credentials and privileges. Citrix recommends that you select an

account that restricts privileges.

8. Click Next and follow the instructions in the wizard to complete installation.

9. After installing the Secure Gateway, configure it as described in Configuring Firewalls for the Secure Gateway.

To uninstall the Secure Gateway

1. Exit any applications running on the server.

2. Open the Control Panel and click Programs and Features.

3. Select Secure Gateway and click Uninstall.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-configuring-firewalls-v2.html


Configuring the Secure Gateway or Secure GatewayProxy

May 16, 2015

The Secure Gateway Configuration or Secure Gateway Proxy Configuration wizard automatically starts when the

installation is complete.

The Secure Gateway Configuration wizard guides you through the process of specifying configuration parameters for the

Secure Gateway. Each dialog box includes context-sensitive Help so that you can obtain additional information specific to

the parameters you are configuring. Click Help within any dialog box to access the context-sensitive Help.

You can access the Secure Gateway Configuration wizard from the Secure Gateway Management Console node in this

console. You can also access the Secure Gateway Configuration wizard or the Secure Gateway Proxy Configuration wizard

from All Programs in the Start menu of the server running the service or proxy. Running the Secure Gateway Configuration

Wizard requires administrative privileges.

Running the Secure Gateway Configuration Wizard requires administrative privileges.

Configuring the Secure Gateway for use with Citrix XenApp requires the following information:

The FQDN and path of the server running the STA

The FQDN and path of the server running the Web Interface

To start the configuration wizard

If you need to start the configuration wizard manually (for instance, to change the configuration at any time after initialinstallation and configuration), perform the following steps.1. Log on as an administrator to the computer running the Secure Gateway.

2. Open the wizard by clicking Start and locating the Secure Gateway Management Console.

3. In the Secure Gateway Management Console menu, click Action > All Tasks and select Stop to stop the Secure Gateway

Service.

4. From the Start button, locate and click Secure Gateway Configuration Wizard or Secure Gateway Proxy Configuration

Wizard.

5. Click OK.

To select a configuration level (Secure Gateway)

1. Select one of the following to access the parameters available for modif ication during the configuration process:

Standard

Includes only the minimum set of parameters required to configure the Secure Gateway. The Secure Gateway

Configuration wizard sets all remaining parameters to their default values, respectively.

Advanced

Includes all of the Secure Gateway’s configurable parameters, for example, supported secure protocols and logging

exclusions.

Task Summary for Secure Gateway, Advanced or Standard Configuration

The task summary when selecting the advanced or standard configuration type is as follows:


Tasks Advanced Conf igurationSelected

StandardConf igurationSelected

To select a server certif icate X X

To configure secure protocol settings X Not available

To configure inbound user connections X X

To configure outbound connections X X

To add the Secure Ticket Authority X X

To configure connection parameters X Not available

To configure logging exclusions X Not available

To add the Web Interface server details X X

To configure the logging parameters X X

To select a server certificate

Server certif icates enable user devices to verify the identity of the server running the Secure Gateway.Note: This option is not displayed when you are installing the Secure Gateway Proxy and you select the Secure traff icbetween the Secure Gateway and Secure Gateway Proxy option as described in To select a configuration level (SecureGateway).1. Select a valid server certif icate installed on the computer running Secure Gateway or Secure Gateway Proxy from the

Certif icates Found menu.

2. Click View to display the details of the selected certif icate.

To configure secure protocol settings

This configuration dialog appears if you select Advanced as 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 inrelay mode, the Secure Gateway Proxy’s client is the Citrix online plug-in.1. Select a secure protocol:

Transport Layer Security (TLSv1)

Configure the Secure Gateway to use only TLS as its secure protocol. If you select this option, verify that all user

devices support and are configured to use TLS as well.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-configuration-wizard-start-task.html











Secure Sockets Layer (SSLv3) and TLSv1

Configure the Secure Gateway and Secure Gateway Proxy to use SSL and TLS as its secure protocols. This option is

useful when deploying the Secure Gateway or Secure Gateway Proxy in an environment in which some clients support

only SSL.

Note: If a user device supports both the SSL and TLS protocols, TLS is used to secure the data transmitted between

the Secure Gateway/Secure Gateway Proxy and the client.

2. Select a cipher suite:

GOV

You can configure the Secure Gateway/Secure Gateway Proxy to use the following government strength cipher suite:

RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}

COM

You can configure the Secure Gateway/Secure Gateway Proxy to use the following commercial strength cipher

suites: RSA_WITH_RC4_128_MD5 or {0x00,0x04}, RSA_WITH_RC4_128_SHA or {0x00,0x05}

ALL

You can configure the Secure Gateway/Secure Gateway Proxy to use both the commercial and government strength

cipher suites. This option is useful when deploying the Secure Gateway/Secure Gateway Proxy in an environment

where some user devices support only COM while others support only GOV.

Note: When the Secure Gateway and a user device support both COM and GOV cipher suites, the Secure Gateway

uses the COM cipher suite.

3. Click Next to proceed.

To configure inbound user connections

Specify the IP addresses and TCP ports that you want the Secure Gateway/Secure Gateway Proxy to monitor for

incoming connections. See also Installing the Secure Gateway and Secure Gateway Proxy.

1. Select each Monitor all IP addresses check box to configure the Secure Gateway to listen for connections on all

available IPv4 or IPv6 addresses. This option is useful when configuring the Secure Gateway/Secure Gateway Proxy on a

server using multiple network interface cards (NICs). When configured in proxy mode, the Secure Gateway Proxy listens

on all available IP addresses for Secure Gateway connections. When configured for relay mode, the Secure Gateway

Proxy listens on all available IP addresses for client connections.

2. Type a listener TCP port number in the TCP Port f ield. This option is available only when the Monitor all IP addresses

option is selected. The Secure Gateway/Secure Gateway Proxy listens for Secure Gateway or client connections on all

available IP addresses using the port specif ied on the server. The default TCP port is 443.

3. Clear the Monitor all IP addresses check boxes to configure the Secure Gateway/Secure Gateway Proxy to listen on

one or more specif ic IP addresses. Then click Add to add one or more IP addresses and related TCP port address.

Typically, you would exclude dynamic IP addresses. When a dynamic IP address changes, new connections are not accepted

on that address and the service can fail to start when you restart the server.

To configure outbound connections

Select the servers to which the Secure Gateway can connect:

Options Description

No outbound traff ic restrictions Select this option to enable the Secure Gateway/Secure Gateway Proxy to



establish connections to any server within the DMZ or secure network. ClickNext to continue.

Use the Secure Gateway Proxy This option is not available when configuring the Secure Gateway Proxy. Selectthis option when configuring the Secure Gateway in a double-hop environment.See To configure secure protocol settings. Select the Secure traff ic betweenthe Secure Gateway and the Secure Gateway Proxy check box to use HTTPS tosecure communications between them.

Use an Access Control List (ACL) Select this option to create an access control list for the SecureGateway/Secure Gateway Proxy. An access control list restricts the SecureGateway/Secure Gateway Proxy to establishing connections to serversspecif ied in the list. Click Configure to specify the start and end IP address rangefor allowed connections. See To configure an access control list for outboundconnections.

Options Description

Note: In a double-hop DMZ, configure outbound access control lists on the Secure Gateway Proxy server only.

To configure an access control list for outbound connections

You do not need to include servers running the Secure Ticket Authority because these are configured elsewhere in thewizard.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 f ield blank if you are creating an entry for a single server. Otherwise,

enter the end address of the range.

TCP port Enter the TCP port used by the server(s). To allow connections to any port on a

server you can use the wild card asterisk character (*) in the TCP port f ield. You can

use this wild card to allow one ACL entry for a range of IP addresses to permit

connections using the ICA and Common Gateway Protocol (CGP) protocols.

Use default port Select this option to use the default port used by the server for the protocol

selected.

ICA Select this option to allow ICA/SOCKS connections to the selected servers.

Typically, you would use ICA for servers running Citrix XenApp that accept

ICA/SOCKS connections. This option is not available to the Secure Gateway Proxy.

CGP Select this option to allow CGP connections to the selected servers. Typically, you

would use CGP for servers running Citrix XenApp that accept CGP connections. CGP




can provide session reliability if you enable session reliability on the selected servers.

To allow CGP as well as ICA/SOCKS connections to the same servers, add a

separate entry for each protocol. This option is not available to the Secure

Gateway Proxy.

Option Description

3. If you select the Server FQDN option, type or select the following information:

Options Description

FQDN Enter the fully qualif ied domain name of the server to which the Secure

Gateway Proxy allows access.

TCP port Enter the TCP port used by the server. To allow connections to any port on a

server, you can use the wild card asterisk character (*) in the TCP port f ield.

Secure traff ic between the server

and the Secure Gateway Proxy

Select this option to secure communications between the server and the

Secure Gateway Proxy servers using SSL or TLS. When this option is not

selected, the connection is not secured.

4. Click OK, then click Add to add another connection, or click OK to close the dialog box.

To configure servers running the Secure Gateway Proxy

1. From the Configure outbound connections dialog window, click Use the Secure Gateway Proxy and then click Configure.

2. Click Add.

3. Type the fully qualif ied domain name (FQDN) or IP addresses and TCP port of the Secure Gateway Proxy servers to

which you want the Secure Gateway server to connect. The default TCP port for unsecured communications between

the Secure Gateway and the Secure Gateway Proxy is 1080. The default TCP port for secure communications between

the Secure Gateway and Secure Gateway Proxy is 443.

4. Click OK.

5. Select Secure traff ic between the Secure Gateway and Secure Gateway Proxy to secure communications between the

Secure Gateway and the Secure Gateway Proxy servers by using SSL or TLS. When this option is not selected, the

connection between the Secure Gateway and Secure Gateway Proxy is not secured. To secure traff ic between the

Secure Gateway and Secure Gateway Proxy you must also:

Install a server certif icate on the server running the Secure Gateway Proxy

Install a client certif icate on the Secure Gateway

6. Click OK.

To add the Secure Ticket Authority

You can configure the Secure Gateway to contact multiple Secure Ticket Authority (STA) serviers 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.

Type or select the following information:

Option Description

FQDN Enter the fully qualif ied domain name of the server running the STA.


Path This f ield is populated automatically with the default virtual directory path,/Scripts/CtxSTA.dll or CitrixAuthService/AuthService.asmx. If you changed the defaultpath when you configured the Citrix XML Service to share a port with InternetInformation Services on the server running Citrix XenApp, enter the correct path.

ID This f ield is populated automatically by the Secure Gateway when it resolves thespecif ied FQDN and reads the ID string from the server running the STA. If theSecure Gateway is unable to resolve the address specif ied you are prompted to enterthe ID for the STA. The ID for the STA is a randomly generated string. You can viewSTA IDs by running the Secure Gateway diagnostic tool.

Secure traff ic between theSTA and the Secure Gateway

Select this option to secure communications between the Secure Gateway and theSTA by using SSL or TLS. To enable this security feature, the FQDN of the STA mustmatch the FQDN specif ied by its server certif icate.

TCP port Enter a network port number used by the Secure Gateway to contact the STA.

Use default Select this option to use the default port assignment for the STA. The default TCPport for unsecured communications between the Secure Gateway and the STA is 80.The default TCP port for secure communications between the Secure Gateway andSTA is 443.

Option Description

To configure connection parameters

You can configure how connection requests time out. Preventing requests from timing out may be useful if your network

has periods of high latency. However, uncompleted connection requests that do not time out, or time out slowly, can

preempt additional connections through the Secure Gateway. The number of connections the Secure Gateway server can

support depends on the server processor, usage, and limits set in the Concurrent Connection Limits section.

Select one of the following options:

Option Description

No connection timeout Select this option if you do not want to limit the time in which Secure Gatewaymust complete a connection request. Do not select this option if typical usagebehavior can result in so many uncompleted connection requests that the serverstops accepting connection requests.

Connection timeout (seconds) Set the interval of time in which the Secure Gateway can complete a connectionrequest. If the connection is not established by the time the specif ied valueelapses, then the connection times out. By default, the connection timeout valueis configured for 100 seconds.

Concurrent Connection Limits This option is not available for the Secure Gateway Proxy. Set the following valuesusing numbers suitable to your environment. Consider processor type and processorspeed as well as typical usage behavior. Failure to do so may overload theprocessor and result in a poor quality of service for your end users.

Unlimited. Select this option to configure the Secure Gateway to support up to

1,920 concurrent client connections (250 connections are allocated to HTTP/S


by default, leaving 1,670 ICA/CGP connections, including MAPI over CGP

connections). The Secure Gateway stops accepting new connection requests if

the number of concurrent client connections reaches 1,920. This setting

overrides the value entered in Maximum connections.

Maximum Connections. Specify the maximum number of concurrent ICA/CGP

connections supported by the Secure Gateway. The Secure Gateway stops

accepting new ICA/CGP connection requests when the number of concurrent

connections equals the value entered in this f ield.

Option Description

To configure logging exclusions

Typically, third-party network devices, such as load balancers, generate extraneous Secure Gateway log information. For

example, load balancers might poll the Secure Gateway repeatedly to ensure that the server is active. Each poll is recorded

by the Secure Gateway as a connection, resulting in the event log containing several unnecessary entries.

The Secure Gateway and the Secure Gateway Proxy generate their own log files. Therefore, if you deployed the Secure

Gateway in proxy mode, you must configure each 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.

To add the Web Interface server details

The Web Interface works with the Secure Gateway to provide a logon interface, and facilitates the authentication and

authorization of connection requests to server farms.

Running the Secure Gateway and the Web Interface on a single server is supported only in a single-hop DMZ environment.

1. Select one of the following access options:

Indirect

To access the Web Interface, users enter the URL of the Secure Gateway. Users connect to the Secure Gateway,

which routes the request to the Web Interface. If the Web Interface is installed on the same computer as the Secure

Gateway, select the Installed on this computer check box (this option is not available in a double-hop environment).

If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to

the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the

Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP

address, and one server.

Direct

If you configure your firewall to permit connections to the Secure Gateway only, the Web Interface is not exposed to

the Internet, which is preferable in some enterprises. Configuring indirect access can be economical if you deploy the

Web Interface on the Secure Gateway server. In that case, all that is required is one SSL certificate, one public IP

address, and one server.

2. If you do not select the Installed on this computer check box, type or select the following information in the Details

area:

FQDN


Enter the fully qualified domain name of the server running the Web Interface. If you selected Installed on this

computer, this field is automatically populated with the value localhost.

TCP port

Enter the port number the Secure Gateway should use when communicating with the Web Interface.

3. Select the Secure traff ic between the Web Interface check box to configure the Secure Gateway to use HTTPS when

communicating with the Web Interface.

To configure the logging parameters

1. Specify the type of errors and events that the Secure Gateway/Secure Gateway Proxy writes to the event log and

Event Viewer. The logging levels available include the following:

Fatal Events Only

Fatal error messages are logged when an operational failure prevents the Secure Gateway Proxy from starting. Select

this option to log only fatal events.

Error and Fatal Events

Error messages are logged when a partial failure, such as the Secure Gateway Proxy being out of memory, occurs.

Select this option to log errors and fatal events.

Warning, error, and fatal events

Warning messages are logged when tickets time out, data packets are corrupted, and similar events occur. Select this

option to log warnings, errors, and fatal events.

All events including informational

All events are logged, including informational messages resulting from client connections. Select this option to log all

events and errors. Selecting this option will result in the Event Viewer window and event log filling up rapidly.

2. Click Next.

To complete the configuration

You must start or restart the Secure Gateway or Secure Gateway Proxy server to use the new configuration settings. If the

Secure Gateway or the Secure Gateway Proxy is already running, restarting the server 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 notgenerate service stop and service start event log messages. If a client is not connected and the Secure Gateway isrestarted, Secure Gateway does generate these messages.See also Installing the Secure Gateway and Secure Gateway Proxy.

To stop the Secure Gateway or Secure Gateway Proxy service

1. Log on as an administrator to the Secure Gateway.

2. From the Start button, locate and click Secure Gateway Management Console.

3. In the Secure Gateway Management Console, on the Action menu, click All Tasks and click Stop.



Managing the Secure Gateway

May 06, 2015

The Secure Gateway Management Console is an MMC snap-in that provides an administrator with tools to administer,

monitor, and troubleshoot the Secure Gateway.

You can access the Secure Gateway Management Console from the Citrix program menu on the Start menu. You can start,

stop, and restart the Secure Gateway using the icons available on the console toolbar. In addition, the Secure Gateway

Management Console displays the following information:

Session and connection information for the Web Interface that is currently running through the Secure Gateway. The

sessions for the Web Interface have one connection for one session.

An instance of the Windows Performance Monitor containing performance statistics applicable to the Secure Gateway.

Review this list to obtain detailed information regarding the status of client connections running through the Secure

Gateway.

The Secure Gateway Management Console also provides access to the following:

The Secure Gateway Configuration wizard

The Secure Gateway Diagnostics tool

Viewing Session and Connection Information with the Secure Gateway Console

The Secure Gateway provides session and connection information in the Secure Gateway Management Console.

To view session connection properties

1. From the Session Information pane, select a session.

2. Right-click and select Properties. Alternatively, double-click a session.

The following statistics are available for all active sessions running through the Secure Gateway:

Statistic Description

Client IP The IP address and port of the remote client.

User The current user associated with the session, if any.

Domain The network domain from which the current user is logged on.

Time Established The time that this connection was established.

Time Elapsed The amount of time, in seconds, that elapsed since this connection wasestablished.

To disconnect an active session

1. From the Session Information pane, right-click the active session you want to disconnect and select All Tasks >


Disconnect.

2. Right-click and select All Tasks - Disconnect.

To freeze (pause) and resume the display of session information

The information in the session information pane refreshes every five seconds. If you want to view details of a particular

session, you may find it useful to turn off the automatic screen refresh feature.

1. From the Session Information pane, right-click any session entry and select All Tasks > Freeze Display.

2. From the Session Information pane, right-click any session entry and select All Tasks > Resume Display.

Viewing Secure Gateway Performance Statistics

The Secure Gateway includes a customized Windows System Monitor containing real-time performance statistics, or

counters, for the Secure Gateway. You can use this monitor to evaluate and troubleshoot connections running through the

Secure Gateway.

Performance data can be used to:

Understand the workload on the Secure Gateway and the corresponding effect it has on system resources

Observe changes and trends in workloads and resource usage so you can plan system sizing and failover

Test changes in configuration or other tuning efforts by monitoring the results

Diagnose problems and target components or processes for optimization

Performance statistics include the data throughput rate in bytes per second across CGP, HTTP/S, SOCKS, and total client

connections through Secure Gateway. The "Successful" counters indicate the number of users’ connections that have

successfully completed since the Secure Gateway service was last started. Users can have multiple connections within each

session. The “Active” counters indicate the number of active connections going through the Secure Gateway.

The Secure Gateway System Monitor takes advantage of several of the features included in the Windows System Monitor,

including customizing the display of counter information and saving counter data. You can use the System Monitor icons at

the top of the pane or shortcut keys to customize the display. For a list of the shortcut keys, see the Windows System

Monitor help.You can display the Windows Performance monitor from the Secure Gateway Management Console.

Citrix recommends that you monitor performance of the Secure Gateway as part of your administrative routine.

To view the Secure Gateway performance statistics

You can use the Secure Gateway performance statistics to troubleshoot connections to the Secure Gateway. For example:

The Secure Gateway processor load might be too high because too many users are connected to the Secure Gateway

server. You can look at the total active connections to check how many users are connected.

Users might not be able to launch their published applications because the Secure Gateway cannot connect to the

XenApp servers. The failed “Backend” connections counter is high if this is the problem.

1. Open the Secure Gateway Management Console.

2. In the tree view, select Secure Gateway Performance Statistics. Performance statistics for the Secure Gateway appear

in the right pane.

3. Use the Windows Performance Console controls that appear at the top of the right pane to perform tasks such as

switching views or adding counters.


Performance Counters Available for the SecureGateway

Jul 29, 2011

The following performance counters are available for the Secure Gateway:

Counter name Description

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

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

CGP Active Connections The total number of CGP client connections currently active.

CGP Bytes/Sec from Client The data throughput rate (bytes per second) from all clientsconnected to the Secure Gateway using the CGP protocol.

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

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

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

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

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

CGP Successful Connections The total number of successful CGP connections.

Client Connect T ime: Average (in ms) The average amount of time (in milliseconds) for a client connectionrequest to complete the connection process.

Client Connect T ime: Longest (in ms) The longest amount of time (in milliseconds) for a client connectionrequest to complete successfully.

Connections/Second The number of successful client connection requests per second.

Connections/Second: Peak The highest number of successful client connection requests persecond.


Connections: Peak Active The highest number of concurrent connections through the SecureGateway.

Connections: Total Active The total number of client connections currently active.

Connections: Total Successful The total number of successful client connections. It is the sum of allsuccessful connections for all protocols: CGP, HTTP/S, and SOCKS.

Connections:Pending Total number of client connection requests accepted, but not yetcompleted, by the Secure Gateway. Pending connections are stillactive and have not timed out or failed.

Failed Backend Connections The total number of backend connections that failed. Clients thatsuccessfully connect to the Secure Gateway may not successfullyconnect to backend servers, such as a Web server. These connectionsare not counted as part of the failed client connection count.

Failed Connections: Client T imed Out The total number of client connection requests that were acceptedbut timed out before completing the protocol handshake.

Failed Connections: General Client Error The total number of client connection requests that failed toconnect to the Secure Gateway for any reason other than timingout or SSL handshake error.

Failed Connections: SSL Client Handshake Error The total number of client connection requests that were acceptedbut did not successfully complete the SSL handshake.

Failed Connections: Total Client The total number of failed client connection requests. It is the sumof the Failed Connections (T imed Out), Failed Connections (SSL Error),and Failed Connections (General Client Error) counters.

HTTP/S Active Connections The total number of HTTP/S connections currently active.

HTTP/S Bytes/Sec from Client The data throughput rate (bytes per second) from all clientsconnected to the Secure Gateway using the HTTP/S protocol.

HTTP/S Bytes/Sec to Client The data throughput rate (bytes per second) from the SecureGateway to all connected clients using the HTTP/S protocol.

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

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

HTTP/S Peak Bytes/Sec from Client The highest data throughput rate (bytes per second) from all clientsconnected to the Secure Gateway using the HTTP/S protocol.

HTTP/S Peak Bytes/Sec to Client The data throughput rate (bytes per second) from the Secure



Gateway to all connected clients using the HTTP/S protocol.

HTTP/S Successful Connections The total number of successful HTTP/S connections.

Kilobytes from Client The total number of kilobytes sent from all connected clients to theSecure Gateway.

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

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

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

SOCKS Active Connections The total number of SOCKS client connections currently active.

SOCKS Bytes/Sec from Client The data throughput rate (bytes per second) from all clientsconnected to the Secure Gateway using the SOCKS protocol.

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

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

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

SOCKS Peak Bytes/Sec from Client The highest data throughput rate (bytes per second) from all clientsconnected to the Secure Gateway using the SOCKS protocol.

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

SOCKS Successful Connections The total number of successful SOCKS connections.

SSL Handshake Time: Average Average length of time (in milliseconds) for an SSL handshake tocomplete.

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

SSL Handshakes/Sec Number of successful SSL handshakes per second.

SSL Handshakes/Sec: Peak Highest number of successful SSL handshakes per second.



SSL Handshakes: Pending Number of SSL handshakes currently in progress between a clientand the Secure Gateway.

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



Generating the Secure Gateway Diagnostics Report

May 06, 2015

The Secure Gateway Diagnostics tool presents configuration information and results of communication checks against

servers hosting components such as the global settings, network protocols, and certificates. It is a quick and easy way of

performing a series of checks to ascertain the health and status of the Secure Gateway components.

To launch the Secure Gateway Diagnostics tools, click Secure Gateway Diagnostics from the Administration Tools found in

the Citrix program group or from the Secure Gateway Management Console on the Start menu.

The diagnostics tool scans the registry and reports global settings for the Secure Gateway. It uses the Secure Gateway

configuration information to contact servers running the Web Interface, the Secure Gateway Proxy, and the STA, and

reports whether or not the communication check passed or failed. It examines the server certificate installed on the server

running the Secure Gateway and checks credentials and validity.

In the Secure Gateway Diagnostics window, information icons indicate that a registry or configuration value is present:

Information icon A registry or configuration value is present.

Warning icon A registry or configuration value is missing.

Passed check icon A communication check for the component passed.

Failed check icon A communication check for the component failed.

For any component marked with a warning or failed check icon, verify that you properly installed the component and

provided all necessary configuration information.

Viewing the Secure Gateway Events

Event logging allows administrators and Citrix support representatives to diagnose problems with the Secure Gateway.

To view Secure Gateway events

1. Open the Control Panel and double-click Administrative Tools.

2. Double-click Event Viewer.

3. Expand the Applications and Services Logs node and select Secure Gateway. All errors and events generated by the

Secure Gateway appear in the right pane.

4. To view additional information, double-click an entry in the right pane. The General tab contains the event ID and a brief

description of the Secure Gateway error.

Logging Events with the Secure Gateway Event Viewer

The Secure Gateway Event Viewer is a customized Windows Event Viewer that displays errors and events generated by the

Secure Gateway. The error messages include:

Status


Messages of normal operational events, such as starting or stopping the Secure Gateway.

Fatal

Messages of operational failure events that prevent the Secure Gateway from starting.

Service

Messages regarding a partial failure of the Secure Gateway.

Warning

Messages logged as a result of events such as corrupted data requests, data packets received, or ticket time-outs.

Informational

Messages that are logged as a result of client connection events.

The Secure Gateway error messages can be viewed using Windows Event Viewer.

If a client is connected to the Secure Gateway and the Secure Gateway is restarted, the Secure Gateway does not

generate service stop and service start event log messages. If a client is not connected and the Secure Gateway is

restarted, Secure Gateway does generate these messages.

Viewing the Secure Gateway Access Logs

The access logs generated by the Secure Gateway service record connection information. For the Secure Gateway, the

access logs record HTTP, SOCKS, and CGP connection information. The Secure Gateway Proxy access log records SOCKS

connections. Each access log provides specific information regarding connections.

To view the Secure Gateway access logs

1. Open Windows Explorer.

2. Navigate to the following path: The default path for the error logs is the installation path for the Secure Gateway or

the Secure Gateway Proxy, typically %systemroot%\Program Files\Citrix\Secure Gateway\logs.

3. Open the log f ile with an ASCII text editor such as Notepad.


Configuring Firewalls for the Secure Gateway

Jul 22, 2010

The Secure Gateway is typically deployed in the DMZ, so that traffic originating from a remote user device must traverse

firewalls to get to the destination server in the secure network. It is, therefore, crucial to the Secure Gateway operation

that firewalls are configured to allow network traffic traversal. Correct firewall configuration can help prevent disconnects

and contribute toward better performance of the Secure Gateway.

Of particular concern with regard to firewall traversal is ICA/SSL traffic, a Citrix-proprietary protocol used for

communications between user devices and computers running Citrix XenApp. Firewalls are not ICA-aware and do not make

any distinction between HTTPS or ICA/SSL traffic. The ICA protocol is a real-time, interactive protocol that is very sensitive

to latency and other network delays. Because ICA traffic typically consists of mouse-clicks and keystrokes, delays in their

transmission could result in significantly degraded performance of the connection. In contrast, HTTPS traffic is less sensitive

to latency or other types of network delays. Therefore, HTTPS connections to computers running Citrix XenApp are less

affected than ICA connections to computers running Citrix XenApp.

To ensure that users experience usable and reliable sessions when using the Secure Gateway, Citrix recommends configuring

your firewall to work in forwarding mode as opposed to proxy mode. Set the firewall to use its maximum inspection level.

Configuring your firewall to use forwarding mode ensures that TCP connections are opened directly between remote user

devices and the Secure Gateway.

However, if you prefer to configure your firewall to use proxy mode, ensure that your firewall does not:

Impose any time-outs on ICA/SSL sessions, including idle, absolute, and data traff ic time-outs

Use the Nagle algorithm for ICA/SSL traff ic

Impose any other specif ic restrictions or f ilters on ICA/SSL traff ic


Ensuring High Availability of the Secure Gateway

May 06, 2015

You can design a Secure Gateway deployment to ensure high availability by deploying multiple servers running the Secure

Gateway.

This configuration does not make Secure Gateway sessions fault tolerant, but provides an alternative server if one server

fails.

When the number of concurrent sessions exceeds the capacity of a single server running the Secure Gateway, multiple

servers running the Secure Gateway must be deployed to support the load. There is no practical limit to the number of

servers running the Secure Gateway that can be deployed to service large server farms.

To deploy multiple servers running the Secure Gateway, a load balancer is required. The function of the load balancer is to

distribute client sessions to one of a number of servers offering a service. This is normally done by implementing a virtual

address on the load balancer for a particular service and maintaining a list of servers offering the service. When a client

connects to a service, the load balancer uses one of a number of algorithms to select a server from the list and directs the

client to the selected server.

The algorithm can be as simple as a “round robin” where each client connect request is assigned to the next server in a

circular list of servers, or a more elaborate algorithm based on server load and response times.

The client response to a server failure depends on which server fails and at what point in the session the server fails. Types

of server failure include:

Web Interface

The server running the Web Interface is involved during user sign on, application launch, or application relaunch. Failure of

the Web Interface requires you to reconnect to the logon page and sign on again when you want to launch a new

application or relaunch an existing application.

STA

The STA is involved in the launch or relaunch of an application. Failure of the STA during application launch requires that you

return to the published applications page on the Web Interface to relaunch the application.

Secure Gateway

The Secure Gateway is involved during application launch and the time an application remains active. If a session fails, the

client connection goes to another server and the session automatically reconnects without having to log on again.

Intelligent load balancers can detect the failure of a server through server polling, temporarily remove the failed server from

the list of available servers, and restore them to the list when they come back online.

Load Balancing Multiple Secure Gateway Servers

The benefits of load balancing across multiple servers running the Secure Gateway include:

Scalability

Optimize the Secure Gateway performance by distributing its client requests across multiple servers within the array. As

traff ic increases, additional servers are added to the array. The load balancing solution used imposes the only restriction to

the maximum number of servers running the Secure Gateway in such an array.

High availability


Load balancing provides high availability by automatically detecting the failure of a server running the Secure Gateway and

redistributing client traff ic 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.

Load Balancing an Array of the Secure Gateway Proxy

You can load balance an array of servers running the Secure Gateway Proxy in the same way as the Secure Gateway.

Instead of using an external load balancer, the Secure Gateway Proxy has built-in support for load balancing.

This is useful in situations where you experience extremely high loads on the Secure Gateway array. In this case, it might

help to deploy a second Secure Gateway Proxy and load balance the two servers.

In addition, if the communications link between the Secure Gateway and the Secure Gateway Proxy is secured, you can use

a single certificate for the Secure Gateway Proxy array.

Certificate Requirements for Load Balancing Secure Gateway Servers

Load balancing relies on the use of a virtual IP address. The virtual IP address is bound to an FQDN and all clients request

connections from the virtual IP address rather than the individual servers running the Secure Gateway behind it. A single IP

address, the virtual IP, acts as an entry point to your servers running the Secure Gateway, simplifying the way clients access

Web content, published applications, and services on computers running Citrix XenApp.

If you are using a load balancing solution, all servers running the Secure Gateway can be accessed using a common FQDN;

for example, csgwy.company.com.

In conclusion, you need a single server certificate, issued to the FQDN (mapped to the virtual IP or DNS name) of the load

balancing server. The certificate must be installed on every server running the Secure Gateway in the server array that is

being load balanced.

Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers

Load balancing solutions available in the market today may feature built-in SSL accelerator cards. If you are using such a

solution to load balance an array of servers running the Secure Gateway, disable the SSL acceleration for traffic directed at

the servers running the Secure Gateway. Consult the load balancer documentation for details about how to do this.

Presence of SSL accelerator cards in the network path before the server running the Secure Gateway means the data

arriving at the Secure Gateway is decrypted. This conflicts with a basic function of the Secure Gateway, which is to decrypt

SSL data before sending it to a Citrix XenApp server. The Secure Gateway does not expect non– SSL traffic and drops the

connection.


Coordinating Keep-Alive Values Between the SecureGateway and XenApp

May 06, 2015

If you enable TCP/IP keep-alive parameters on computers running XenApp, Citrix recommends that you modify the

parameters on the server running the Secure Gateway in the same manner.

In an environment containing the Secure Gateway, ICA and HTTP/S connections are routed through the Secure Gateway.

TCP/IP keep-alive messages from the Citrix XenApp server to the remote user 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 user connection state and can either disconnect or log off from the

connection in a timely manner.

Setting Connection Keep-Alive Values and the Secure Gateway

The Secure Gateway establishes connections over the Internet between remote users and Citrix XenApp servers. When a

user connection is dropped without being properly logged off, the Secure Gateway continues to keep the connection to

the server open. Accumulation of such “ghost” connections eventually affects Secure Gateway performance.

A Secure Gateway deployment subject to a heavy load may run out of sockets because of these “ghost” connections

remaining open. The Secure Gateway uses TCP/IP keep-alives to detect and close broken connections between the Secure

Gateway and the user device. The default Windows setting for KeepAliveTime is two hours. This is the duration that TCP/IP

waits before verifying whether or not an idle connection is still connected. “Ghost” connections may therefore remain open

for up to two hours before the system detects that a connection failed.

To prevent broken connections from remaining open, the Secure Gateway changes the KeepAliveTime to one minute. If a

connection is dropped, the Secure Gateway knows within one minute, instead of two hours.

If there is no response, TCP/IP retries the verification process after the interval specified by KeepAliveInterval and for a

maximum number of times specified by TcpMaxDataRetransmissions. The default value for KeepAliveInterval is one second

and the default value for TcpMaxDataRetransmissions is five seconds.

If the Secure Gateway is under a heavy load and is used predominately to secure HTTP connections to internal Web

servers, the Secure Gateway rapidly opens and closes connections. Closed connections stay in the TIME_WAIT state for an

interval specified by TcpTimedWaitDelay.

The default value of TcpTimedWaitDelay is four minutes; the Secure Gateway sets this value to 30 seconds. This change

enables the Secure Gateway to recycle sockets faster resulting in improved performance. The system cannot reuse sockets

in the TIME_WAIT state. MaxUserPort specifies the number of sockets available on the system. By default, the system uses

ports between 1024 and 5000; the Secure Gateway modifies this setting to use ports between 1024 and 65000.

The KeepAliveInterval, KeepAliveTime, MaxUserPort, TcpMaxDataRetransmissions, and TcpTimedWaitDelay parameters are

stored in the Windows registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters\


For more information about making changes to these parameters, see the Microsoft knowledgebase articles, Q120642 -

“TCP/IP & NBT Configuration Parameters for Windows 2000 or Windows NT,” Q314053 - “TCP/IP & NBT Configuration

Parameters for Windows XP,” and Q196271 - “Unable to Connect from TCP Ports Above 5000”. Under normal circumstances,

it is not necessary to change these settings.


Improving Security (Recommendations)

Jul 22, 2010

This section suggests ways to improve security when using the Secure Gateway.

Note: The Secure Gateway is an application– specif ic proxy designed to achieve a corresponding level of security. It is not afirewall and should not be used as such. Citrix recommends that you use a f irewall to protect servers running the SecureGateway, Citrix XenApp, and other corporate resources from unauthorized access from the Internet and internal users.

Changing or Restricting Ciphersuites

The process of establishing a secure connection involves negotiating the ciphersuite that is used during communications. A

ciphersuite defines the type of encryption that is 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.

The Secure Gateway supports two main categories of ciphersuite: COM (commercial) and GOV (government). The ALL

option includes both the commercial and government suites.

The COM ciphersuites are:

SSL_RSA_WITH_RC4_128_MD5 or {0x00,0x04}

SSL_RSA_WITH_RC4_128_SHA or {0x00,0x05}

The GOV ciphersuite is:

SSL_RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}

Some organizations, including U.S. government organizations, require the use of government-approved cryptography to

protect sensitive but unclassified data.

To change or restrict the ciphersuites

1. Log on as an administrator to the server running the Secure Gateway.

2. Launch the Secure Gateway Configuration wizard.

3. Select Advanced Configuration and click Next until you see the Configure secure protocol settings screen. The default

setting for ciphersuites is ALL.

4. To restrict the ciphersuite, change the value to GOV or COM, as required. Click Next.

5. Follow prompts until configuration is complete. Click to exit the configuration wizard.

You must restart the Secure Gateway to let configuration changes take effect.

Restricting Ciphersuite Use to Secure Communication

The ciphersuites used to secure communications between the Secure Gateway and the Secure Gateway Proxy are

determined by the configuration settings on the server running the Secure Gateway Proxy. The default setting on the

Secure Gateway for outgoing connections to the Secure Gateway Proxy is set to use all ciphersuites.

Security policies of some organizations may require tighter control of the ciphersuites offered by the Secure Gateway for


outgoing connections to the Secure Gateway Proxy. This is achieved by modifying the SChannel registry settings.

For instructions about modifying the SChannel registry settings to restrict ciphersuites, refer to the Microsoft Knowledge

Base Article Q245030, “How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll.”

Modifying Protocols to Restrict Secure Gateway Connections

The Secure Gateway handles both SSL Version 3 and TLS Version 1 protocols. In this context:

The Secure Gateway uses TLS Version 1 as the default

Internet Explorer uses SSL Versions 2 and 3 as the default

You can restrict the Secure Gateway to accept only SSL Version 3 or TLS Version 1 connections. If you decide to change

the default protocol setting on the Secure Gateway, modify protocol settings on the client Web browser as well as the

Gateway Client to match the protocol setting on the server running the Secure Gateway.

Citrix recommends against changing the default setting for the secure protocol used by the Secure Gateway.

Removing Unnecessary User Accounts

Citrix recommends removing all unnecessary user accounts on servers running the Secure Gateway.

Avoid creating multiple user accounts on servers running the Secure Gateway and limit the file access privileges granted to

each account. Review active user accounts regularly and when personnel leave.

Removing Sample Sites Installed with IIS

An important security step is to disable or remove all sample Web applications installed by the Internet Information Services

(IIS). Never install sample sites on production servers because of the many well-identified security risks they present. Some

sample Web applications are installed so that you can access them only from http://localhost or the IP address 127.0.0.1.

Nevertheless, you should remove the sample sites. The IISSamples, IISHelp, and Data Access virtual directories and their

associated folders are good examples of sample sites that should not reside on production servers.

Securing Components that Run on IIS

To ensure that security of the Secure Gateway components is not compromised, you can do the following:

Set appropriate ACLs on IIS to prevent unauthorized access to executable and script f iles. For instructions about locking

down IIS, refer to current Microsoft product documentation and online resources available from the Microsoft Web site.

Secure all the Secure Gateway components using SSL or TLS to ensure that data communications between all the

Secure Gateway components is encrypted.

To maximize the security of the servers running the Secure Gateway components hosted by IIS, follow Microsoft security

guidelines for locking down Internet Information Services on Windows Servers.

Stopping and Disabling Unused Services

Windows services introduce vulnerabilities to the computer. If a Windows service is not required by your organization, Citrix

recommends that the service be disabled. For a complete list of services and their functions, see the— Threats and Countermeasures Guide

on the Microsoft Web site. Note that disabling a Windows service could stop the computer from functioning correctly.

Installing Service Packs and Hotfixes


Ensure that you install all operating system-specific service packs and hotfixes, including those applicable to applications

and services that you are running on the system.

Ensure you do not install hotfixes for services that are not installed. Ensure you regularly review Security Bulletins from

Microsoft.

Following Microsoft Security Guidelines

Citrix recommends that you review Microsoft guidelines for securing Windows servers.

In general, refer to the Microsoft Web site for current guidance to help you understand and implement the processes and

decisions that must be made to get, and stay, secure.


Troubleshooting the Secure Gateway

May 08 , 2015

After you have configured NAT and packet filtering on your network, use the Secure Gateway Diagnostics tool to confirm

that the Secure Gateway is configured correctly and that it is able to resolve addresses and communicate with servers

located in the DMZ and the secure network. Troubleshooting information concerning firewall traversal, Domain Name

Service (DNS), and Network Address Translation (NAT) are beyond the scope of this document.

Run the Secure Gateway Diagnostics tool on the server running the Secure Gateway and examine the results reported. The

report contains configuration values for the Secure Gateway and results of connection attempts to components and

services in the DMZ and secure network that the Secure Gateway uses.

For instructions about using the Secure Gateway Diagnostics tool, see Generating the Secure Gateway Diagnostics Report.

Careful review of the Secure Gateway event log can help you identify the sources of system problems. For example, if log

warnings show that the Secure Gateway failed because it could not locate the specified certificate, you can conclude that

the certificate is missing or installed in the incorrect certificate store. In general, information in the event log helps you trace

a record of activity leading up to the event of failure.

If you receive an error: The Secure Gateway Fails with a CSG0188 Error, the error implies that SChannel could not validate

certificate credentials of the server certificate used by the Secure Gateway. Ensure that the certificate installed was issued

by a trusted source, is still valid, and is issued for the correct computer.

For more troubleshooting information, see the Citrix support Web site at http://support.citrix.com/ for technical support

options.

To check your certificates

1. Log on as an administrator to the server running the Secure Gateway.

2. Open the Secure Gateway Configuration Wizard.

3. Select the products you want to secure and then click OK.

4. On the Secure Gateway configuration level screen, select Advanced.

5. In the Select server certif icate dialog box, select the certif icate the Secure Gateway is configured to use and click View.

6. Check that the value in the Issued To f ield matches the FQDN of this server.

7. When you view the certif icate, ensure that it contains a key icon and the caption “You have private key that

corresponds to this certif icate” at the bottom of the General tab. The lack of an associated private key can result in the

CSG0188 error.

8. Ensure the certif icate is not expired. If it is expired, you need to apply for certif icate renewal.

Contact the appropriate resources in your company for assistance with certificate renewal.

User Connections Started from IP Addresses in the Logging Exclusions List Fail

For security reasons, IP addresses configured in the logging exclusions list are not allowed to establish connections to the

Secure Gateway. This measure blocks connections to the Secure Gateway that do not leave an audit trail.

The logging exclusions list is designed to help keep the system log free of redundant data. Configure the IP address of load

balancing devices in the Logging Exclusions list. Configuring an exclusions list enables the Secure Gateway to ignore polling

activity from such devices and keeps the log free of this type of data.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-event-viewer-task-v2.html

http://support.citrix.com/


Load Balancers Do Not Report Active User Sessions if Connections Are Idle

Some load balancers stop reporting active user 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. For more information about configuring TCP/IP keep– alive settings, see

Coordinating Keep-Alive Values Between the Secure Gateway and XenApp.

Performance Issues with Transferring Files Between a User Device and a 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 operatingsystem. Citrix cannot guarantee resolution of problems resulting from the incorrect use of Registry Editor. Use RegistryEditor at your own risk.To modify this setting, edit the following Windows Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\TcpWindowSize

Citrix recommends setting the value of TCPWindowSize to 0xFFFF(64K).

Be aware that this change incurs higher system memory usage. Citrix recommends increasing physical system memory on

the server running the Secure Gateway to suit the typical usage profile of the network.

Gateway User Connections Fail When Using Windows XP Service Pack 2

Windows XP Service Pack 2 prevents connections to all IP addresses that are in the loopback address range except for

127.0.0.1. If the Gateway user 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 User Connections to the Secure Gateway Result in Duplicate Entries in the Secure Gateway Log

You may find duplicate entries for user 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

User device automatically attempts to reconnect if the f irst connection attempts fails

The log entries are actually a record of user behavior. In these cases, the user attempts to reconnect if it fails the first time.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/sg-presentation-server-v2/sg-keep-alive-values-v2.html

http://support.microsoft.com/


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 user device and the Secure Gateway. User devices can communicate with the enterprise network using

HTTPS but traffic for ICA/SSL is refused. When a combination of the Web Interface and the Secure Gateway is placed

behind a reverse Web proxy server, users can log on using the Web Interface and enumerate application icons, which is all

HTTP communications. When users launch a published application, they receive an SSL Error 4 because the ICA/SSL session

is terminated by the reverse Web proxy, not by the Secure Gateway.

This graphic shows the incorrect placement of the Secure Gateway and Web Interface behind a reverse Web proxy.

The Secure Gateway views the reverse Web proxy as a “man in the middle” that compromises the integrity of the ICA/SSL

network stream. This causes the SSL handshake between the user device and the Secure Gateway to fail.

There are two possible solutions to correct this problem:

Run the Secure Gateway parallel to the reverse Web proxy

Use a network address translator (NAT) in place of the reverse Web proxy

Use a Network Address Translator Instead of a Reverse Web Proxy

If the reverse Web proxy is configured to forward all network traffic (not just HTTP traffic) to the combination Secure

Gateway and Web Interface, the SSL connection is not terminated at the proxy and users can connect through the Secure

Gateway. The following figure is an example of how different vendors refer to this type of deployment.


This graphic shows the use of a network address translator instead of a reverse Web proxy.

This approach has the disadvantage that some control must be sacrificed regarding the type of traffic that is permitted to

cross the proxy. Incoming traffic must be routed directly to the Secure Gateway and the Web Interface without being

decrypted, authenticated, or inspected. From a security standpoint, this is not much different from exposing the Secure

Gateway server directly to the Internet. There is a logical SSL tunnel between the user device and the Secure Gateway.


Digital Certificates and the Secure Gateway

May 06, 2015

SSL and TLS are leading Internet protocols providing security for e-commerce, Web services, and many other network

functions. The SSL/TLS protocol uses cryptography to secure communications. Cryptography provides the ability to encode

messages to ensure confidentiality. To establish an SSL/TLS connection, you need a digital certificate.

For more information about obtaining, exporting, and installing security certificates for your operating system, consult the

Microsoft TechNet library available at http://technet.microsoft.com.

The SSL protocol is 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

(IETF) took over responsibility for the development of SSL as an open standard. To clearly distinguish SSL from other

ongoing work, the IETF renamed SSL as TLS. The TLS protocol is the descendant of the third version of SSL; TLS 1.0 is

identical to SSL 3.1.

Some organizations, including U.S. government organizations, require the use of TLS to secure data communications. These

organizations may also require the use of validated cryptography. FIPS (Federal Information Processing Standard) 140 is a

standard for cryptography.

Understanding SSL and TSL

The SSL/TLS protocol allows sensitive data to be transmitted over public networks such as the Internet by providing the

following important security features:

Authentication

A client can determine a 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

The recipient of encrypted data knows if a third party corrupts or modif ies 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. The cipher scrambles the message so that it cannot be understood by

anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message,

thus ensuring confidentiality.

Cryptography allows the sender to include special information in the message that only the sender and receiver know. The

receiver can authenticate the message by reviewing the special information.

Cryptography also ensures that the contents of a message are not altered. To do this, the sender includes a cryptographic

operation called a hash function in the message. A hash function is a mathematical representation of the information,

similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates

the hash function. If the receiver’s hash function value is the same as the sender’s, the integrity of the message is assured.

http://technet.microsoft.com


Types of Cryptography

There are two main types of cryptography:

Secret key cryptography

Public key cryptography

In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that

information secure and visible only to individuals who have the corresponding key to recover the information.

Secret key cryptography is also known as symmetric key cryptography. With this type of cryptography, both the sender and

the receiver know the same secret code, called the key. Messages are encrypted by the sender using the key and decrypted

by the receiver using the same key.

This method works well if you are communicating with only a limited number of people, but it becomes impractical to

exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the

secret key securely.

Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public

key cryptography, keys work in pairs of matched public and private keys.

The public key can be freely distributed without compromising the private key, which must be kept secret by its owner.

Because these keys work only as a pair, encryption initiated with the public key can be decrypted only with the

corresponding private key. The following example illustrates how public key cryptography works:

Ann wants to communicate secretly with Bill. Ann encrypts her message using 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.

The major advantage asymmetric encryption offers over symmetric key cryptography is that senders and receivers do not

have to communicate keys up front. Provided the private key is kept secret, confidential communication is possible using

the public keys.

Understanding Digital Certificates and Certificate Authorities

The 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. The issuing

authority can also revoke certificates.

To establish an SSL/TLS connection, you require a server certificate at one end of the connection and a root certificate of

the CA that issued the server certificate at the other end.

Server certif icate

A server certif icate certif ies the identity of a server. The type of digital certif icate that is required by the Secure Gateway is


called a server certif icate

Root certif icate

A root certif icate identif ies the CA that signed the server certif icate. The root certif icate belongs to the CA. This type of

digital certif icate is required by a user device to verify the server certif icate.

When establishing an SSL connection with a Web browser on a user device, the server sends its certificate to the client.

When receiving a server certificate, the Web browser (for example, Internet Explorer) on the user device checks to see which

CA issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the Web browser prompts the user

to accept or decline the certificate (effectively accepting or declining the ability to access this site).

When User A receives a message from User B, the locally stored information about the CA that issued the certificate is used

to verify that it did indeed issue the certificate. This information is a copy of the CA’s own certificate and is referred to as a

root certificate.

Certificates generally have a common format, usually based on International Telecommunication Union (ITU) standards. The

certificate contains information that includes the:

Issuer

The organization that issues the certif icates.

Subject

The party that is identif ied by the certif icate.

Period of validity

The certif icate’s start date and expiration date

Public key

The subject’s public key used to encrypt data.

Issuer’s signature

The CA’s digital signature on the certif icate used to guarantee its authenticity.

A number of companies and organizations currently act as CAs, including VeriSign, Baltimore, Entrust, and their respective

affiliates.

Certificate Chains

Some organizations delegate the responsibility for issuing certificates to resolve the issue of geographical separation

between organization units, or that of applying different issuing policies to different sections of the organization.

Responsibility for issuing certificates can be delegated by setting up subordinate CAs. The X.509 standard includes a model

for setting up a hierarchy of CAs. In this model, the root CA is at the top of the hierarchy and has a self-signed certificate.

The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate

CAs in the hierarchy have their CA certificates signed by the subordinate CAs.


This illustration shows the hierarchical structure of a typical digital certificate chain.

CAs can sign their own certificates (that is, they are self-signed) or they can be signed by another CA. If the certificate is

self-signed, they are called root CAs. If they are not self-signed, they are called subordinate or intermediate CAs.

If a server certificate is signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two

certificates: the end entity certificate and the root CA. If a user or server certificate is signed by an intermediate CA, the

certificate chain is longer.

The following figure shows the first two elements are the end entity certificate (in this case, gwy01.company.com) and the

certificate of the intermediate CA, in that order. The intermediate CA’s certificate is followed by the certificate of its CA.

This listing continues until the last certificate in the list is for a root CA. Each certificate in the chain attests to the identity

of the previous certificate.

This illustration shows a typical digital certificate chain.

Certificate Revocation Lists

From time to time, CAs issue certificate revocation lists (CRLs) that contain information about certificates that can no

longer be trusted. For example, suppose Ann leaves XYZ Corporation. The company can place Ann’s certificate on a CRL to


prevent her from signing messages with that key.

Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use.

Before you trust a public key, make sure that the certificate does not appear on a CRL.

Deciding Where to Obtain Certificates

When you identify the number and type of certificates required for your Secure Gateway deployment, decide where to

obtain the certificates. Where you choose to obtain certificates depends on a number of factors, including:

Whether or not your organization is a CA, which is likely to be the case only in very large corporations

Whether or not your organization already established a business relationship with a public CA

The fact that the Windows operating system includes support for many public Certif icate Authorities

The cost of certif icates or the reputation of a particular public CA

If Your Organization Is its Own Certificate Authority

If your organization is running its own CA, you must determine whether or not it is appropriate to use your company's

certificates for the purpose of securing communications in your Secure Gateway installation. Citrix recommends that you

contact your corporate security department to discuss this and to get further instructions about how to obtain

certificates.

If you are unsure if your organization is a CA, contact your corporate security department or your organization's security

expert.

If Your Organization Is Not its Own Certificate Authority

If your organization is not running its own CA, you need to obtain your certificates from a public CA such as VeriSign.

Obtaining a digital certificate from a public CA involves a verification process in which:

Obtaining a digital certificate from a public CA involves a verification process in which:

Your organization provides corporate information so the CA can verify that your organization is who it claims to be. The

verif ication process may involve other departments in your organization, such as accounting, to provide letters of

incorporation or similar legal documents.

Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA.

The CA verif ies 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.

Obtaining and Installing Server Certificates

Your organization’s security expert should have a procedure for obtaining server certificates. Instructions for generating

server certificates using various Web server products are available from the Web sites of popular CAs such as Verisign and

others.

Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test

the Secure Gateway before deploying it in a production environment. If you do this, be aware that you need to download

matching Test Root Certificates that must be installed on each user device that connects through the Secure Gateway.

To provide secure communications (SSL/TLS), a server certificate is required on the server running the Secure Gateway. The

steps required to obtain and install a server certificate on a server running the Secure Gateway are as follows:


1. Create a certif icate request.

2. Apply for a server certif icate from a valid CA.

3. Save the certif icate response f ile sent by the CA as an X.509 Certif icate (.cer format).

4. Import the X.509 certif icate into the certif icate store.

5. Export the certif icate into Personal Information Exchange format (.pfx, also called PKCS #12).

6. Install the server certif icate on the server running the Secure Gateway.

Consider the following before obtaining and installing certificates:

When requesting a certif icate, 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 certif icate 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 certif icate, loss of the key pair on your server renders your

certif icate worthless. Make sure you back up your key pair data on another computer, a f loppy disk, or both.

Typically, the procedure for generating a key pair requires you to specify a password to encrypt the pair. The password

prevents any person with access to the keypair data from extracting the private key and using it to decrypt SSL/TLS

traff ic to and from your server. Ensure that you store the password in a secure location.

When you import a certif icate, you copy the certif icate from a f ile that uses a standard certif icate storage format to a

certif icate store for your computer account. Use the proper procedures or wizard as specif ied by your operating system

to place certif icates in the correct store on local computers. Do not attempt to import the server certif icate f ile by

double-clicking or right-clicking the certif icate f ile within Windows Explorer. Doing so places the certif icate in the

certif icate store for the current user.

Obtaining and Installing Root Certificates

A root certificate must be present on every user device that connects to the secure network through the Secure Gateway.

Support for most trusted root authorities is already built into the Windows operating system and Internet Explorer.

Therefore, there is no need to obtain and install root certificates on the user device if you are using these CAs. However, if

you decide to use a different CA, you need to obtain and install the root certificates yourself.

Obtaining a Root Certificate from a CA

Root certificates are available from the same CAs that issue server certificates. Well-known or trusted CAs include Verisign,

Baltimore, Entrust, and their respective affiliates. Certificate authorities tend to assume that you already have the

appropriate root certificates (this is because most Web browsers have root certificates built-in) so you need to specifically

request the root certificate. Several types of root certificates are available. For example, VeriSign has approximately 12 root

certificates that they use for different purposes, so it is important to ensure that you obtain the correct root certificate

from the CA.

Support for Wildcard Certificates with the Secure Gateway

The Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. The wildcard

certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as

http://www1.citrix.com or http://www2.citrix.com. The use of a wildcard certificate allows several Web sites to be covered

by a single certificate.


SmartAuditor

May 05, 2015

SmartAuditor allows you to record the on-screen activity of any user’s session, over any type of connection, from any

server running XenApp. SmartAuditor records, catalogs, and archives sessions for retrieval and playback.

SmartAuditor uses flexible policies to trigger recordings of XenApp sessions automatically. This enables IT to monitor and

examine user activity of applications — such as financial operations and healthcare patient information systems —

demonstrating internal control, thus ensuring regulatory compliance and successful security audits. Similarly, SmartAuditor

also aids in technical support by speeding problem identification and time-to-resolution.

Benefits

Enhanced auditing for regulatory compliance. SmartAuditor allows organizations to record on-screen user activity for

applications that deal with sensitive information. This is especially critical in regulated industries such as health care and

finance, where compliance with personal information security rules is paramount. Trading applications and patient

information systems are two prime examples.

Powerful activity monitoring. SmartAuditor captures and archives screen updates, including mouse activity and the visible

output of keystrokes in secured video recordings to provide a record of activity for specific users, applications, and servers.

Organizations that use SmartAuditor have a better chance of proving criminal intent, where it exists, by using video

evidence combined with traditional text-based eDiscovery tools.

Faster problem resolution. When users call with a problem that is hard to reproduce, help desk support staff can enable

recording of user sessions. When the issue recurs, SmartAuditor provides a time-stamped visual record of the error, which

can then be used for faster troubleshooting.

Example Usage Scenarios

Monitoring acceptable use of resources. Ray, the IT Manager in a local firm, needs to know whether employees are

following the acceptable use policies and other business controls he instituted to regulate access to resources published

using XenApp. Until now he had no way of measuring acceptable usage and had to trust that users of mission-critical

applications were not misusing their privileges. He now uses SmartAuditor to record user sessions and has his surveillance

officer review recorded sessions to establish cases of misuse.

Monitoring specific users or groups. John, a surveillance officer at a stockbroking firm, needs to monitor a group of

stockbrokers to observe particularly sensitive, high-value transactions. He uses SmartAuditor to record sessions for this

group of stockbrokers.

Investigating suspected violations. Lisa is 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.


System Requirements for SmartAuditor

Mar 04 , 2010

SmartAuditor is available in English, French, German, Japanese, Spanish, and simplified Chinese. All SmartAuditor components

that connect to each other must be the same language edition; mixed-language installations are not supported.

The English-language edition of SmartAuditor is supported on English, Russian, traditional Chinese, and Korean operating

systems. The French, German, Japanese, Spanish, and simplified Chinese editions of SmartAuditor are supported on

operating systems in their respective languages.

SmartAuditor Administration Components

The SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server, and SmartAuditor Policy

Console) can be installed on a single server or on different servers.

SmartAuditor Database

Supported Windows operating systems:Microsoft Windows Server 2008 R2

Microsoft Windows Server 2003 with Service Pack 2

Microsoft Windows 2000 with Service Pack 4

Requirements:Microsoft SQL Server 2008 (Enterprise and Express editions)

Microsoft SQL Server 2005 (Enterprise and Express editions) with Service Pack 2

.NET Framework Version 3.5

SmartAuditor Server

Supported Windows on Microsoft Windows Server 2008 R2.

Requirements:.NET Framework Version 3.5.

If the SmartAuditor Server uses HTTPS as its communications protocol, SSL. SmartAuditor uses HTTPS by default, which

Citrix recommends.

Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled.

SmartAuditor Policy Console

Supported Windows operating systems:Microsoft Windows Server 2008 R2

Microsoft Windows 7

Microsoft Windows Vista

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 for Windows Server 2008 R2 Platinum edition server software

Microsoft Windows Server 2008 R2

.NET Framework Version 3.5.

Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled

SmartAuditor Player

Supported Windows operating systems:Microsoft Windows XP

Microsoft Windows Vista

Windows 7

The SmartAuditor Player requires .NET Framework Version 3.5.

The update contained in Microsoft Knowledge Base article 961118 is required if you are using .NET Framework Version 3.5

and installing the SmartAuditor Player on the same computer as a XenApp server. Install the update after installing .NET

Framework.

For optimal results, install SmartAuditor Player on a workstation with:Screen resolution of 1024 x 768

Color depth of at least 32-bit

Memory: 1GB RAM (minimum)— additional RAM can improve performance on large f iles


Getting Started with SmartAuditor

Aug 09, 2013

After you perform the following steps, you can begin recording and reviewing XenApp sessions.

1. Become familiar with the SmartAuditor components.

2. Select the deployment scenario for your environment.

3. Verify the installation requirements.

4. Install SmartAuditor.

5. Configure the SmartAuditor components to permit recording and viewing of sessions.

SmartAuditor consists of five components:

SmartAuditor Agent. A component installed on each XenApp server to enable recording. It is responsible for recording

session data.

SmartAuditor Server. A server that hosts:

The Broker. An IIS 6.0+ hosted Web application that handles the search queries and f ile download requests from the

SmartAuditor Player, handles policy administration requests from the SmartAuditor Policy Console, and evaluates

recording policies for each XenApp session.

The Storage Manager. A Windows service that manages the recorded session f iles received from each SmartAuditor-

enabled computer running XenApp.

SmartAuditor Player. A user interface that users access from a workstation to play recorded XenApp session f iles.

This illustration shows the SmartAuditor components and their relationship with each other:

In the deployment example illustrated here, the SmartAuditor Agent, SmartAuditor Server, SmartAuditor Database,SmartAuditor Policy Console, and SmartAuditor Player all reside behind a security f irewall. The SmartAuditor Agent isinstalled on a XenApp server. A second server hosts the SmartAuditor Policy Console, a third server acts as the SmartAuditorServer, and a fourth server hosts the SmartAuditor Database. The SmartAuditor Player is installed on a workstation. A clientdevice outside the f irewall communicates with the XenApp server on which the SmartAuditor Agent is installed. Inside thefirewall, the SmartAuditor Agent, SmartAuditor Policy Console, SmartAuditor Player, and SmartAuditor Database allcommunicate with the SmartAuditor Server.


Important Deployment Notes

Updated: 2015-05-05

To enable SmartAuditor components to communicate with each other, ensure you install them in the same domain or

across trusted domains that have a transitive trust relationship. The system cannot be installed into a workgroup or

across domains that have an external trust relationship.

SmartAuditor does not support the clustering of two or more SmartAuditor Servers in a deployment.

Due to its intense graphical nature and memory usage when playing back large recordings, Citrix does not recommend

installing the SmartAuditor Player as a published application.

The SmartAuditor installation is configured for SSL/HTTPS communication. Ensure that you install a certif icate on the

SmartAuditor Server and that the root certif icate authority (CA) is trusted on the SmartAuditor components.

If you install the SmartAuditor Database on a stand-alone server running SQL Server 2005 Express Edition or SQL Server

2008 Express Edition, the server must have TCP/IP protocol enabled and SQL Server Browser service running. These

settings are disabled by default, but they must be enabled for the SmartAuditor Server to communicate with the

database. See the Microsoft documentation for information about enabling these settings.

Consider the effects of session sharing when planning your SmartAuditor deployment. Session sharing for published

applications can conflict with SmartAuditor recording policy rules for published applications. SmartAuditor matches the

active policy with the f irst published application that a user opens. After the user opens the f irst application, any

subsequent applications opened during the same session continue to follow the policy that is in force for the f irst

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 specif ic that Word should be recorded, and the user

launches Word before Outlook (which should be recorded, according to the policy), Outlook is not recorded.


Planning Your Deployment

Nov 09, 2009

Depending upon your environment, you can deploy the SmartAuditor components in different scenarios.

A SmartAuditor deployment does not have to be limited to a single farm. With the exception of the SmartAuditor Agent, all

components are independent of the server farm. For example, you can configure multiple farms to use a single

SmartAuditor Server.

Alternatively, if you have a large farm with many agents and plan to record many graphically intense applications (for

example, AutoCAD applications), or you have many sessions to record, a SmartAuditor Server can experience a high

performance demand. To alleviate performance issues, you can install multiple SmartAuditor Servers on different computers

and point the SmartAuditor Agents to the different computers. Keep in mind that an agent can point to only one server at

a time.

Suggested Deployment Scenarios

These are the two suggested configurations for a SmartAuditor deployment:Deploy the SmartAuditor Agent on single XenApp server.

Deploy the SmartAuditor Agent on multiple XenApp servers in a server farm.

Deployment 1: Single XenApp Server

Use this type of deployment for recording sessions from one XenApp server. The SmartAuditor Agent is installed on aXenApp server. Typically, the SmartAuditor Administration components (SmartAuditor Database, SmartAuditor Server,SmartAuditor Policy Console) are installed on another server, but they can be installed on the same server as theSmartAuditor Agent. These servers are in a data center behind a security f irewall. The SmartAuditor Player is installed on aworkstation that is behind the f irewall, but not in the data center. Outside the f irewall, in an unsecured networkenvironment, are client devices, such as a workstation, a PDA, and a laptop computer.


Note: For this deployment scenario, ensure that you install SQL Server on the same computer as the SmartAuditor Server.

Deployment 2: Server Farm Deployment

Use this type of deployment for recording sessions for one or more farms.The SmartAuditor Agent is installed on eachXenApp server in a farm. The farm resides in a data center behind a security f irewall. The SmartAuditor Administrationcomponents (SmartAuditor Database, SmartAuditor Server, SmartAuditor Policy Console) are installed on other servers andthe SmartAuditor Player is installed on a workstation, all behind the f irewall but not in the data center. Outside the f irewall,in an unsecured network environment, are XenApp clients, such as a workstation, a PDA, and a laptop computer.



Scalability Considerations

Nov 09, 2009

Installing and running SmartAuditor requires few additional resources beyond what is necessary to run XenApp. However, if

you plan to use SmartAuditor to record a large number of sessions or if the sessions you plan to record will result in large

session files (for example, graphically intense applications), consider the performance of your system when planning your

SmartAuditor deployment.

Hardware Recommendations

Consider how much data you will be sending to each SmartAuditor Server and how quickly the servers can process and store

this data. The rate at which your system can store incoming data must be higher than the data input rate.

To estimate your data input rate, multiply the number of sessions recorded by the average size of each recorded session

and divide by the period of time for which you are recording sessions. For example, you might record 5,000 Microsoft

Outlook sessions of 20MB each over an 8-hour work day. In this case, the data input rate is approximately 3.5MBps. (5,000

sessions times 20MB divided by 8 hours, divided by 3,600 seconds per hour.)

You can improve performance by optimizing the performance of a single SmartAuditor Server or by installing multiple

SmartAuditor Servers on different computers.

Disk and Storage Hardware

Disk and storage hardware are the most important factors to consider when planning a SmartAuditor deployment. The

write performance of your storage solution is especially important. The faster data can be written to disk, the higher the

performance of the system overall.

Storage solutions suitable for use with SmartAuditor include a set of local disks controlled as RAID arrays by a local disk

controller or by an attached Storage Area Network (SAN).

Note: SmartAuditor should not be used with Network-Attached Storage (NAS), due to performance and security problemsassociated 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.

Computer Processing Capacity

Consider the following specification for the computer on which a SmartAuditor Server is installed:

A dual CPU or dual-core CPU is recommended

A 64-bit processor architecture is recommended, but an x86 processor type is also suitable


2GB to 4GB of RAM is recommended

Exceeding these specifications does not significantly improve performance.

Deploying Multiple SmartAuditor Servers

If a single SmartAuditor Server does not meet your performance needs, you can install more SmartAuditor Servers on

different computers. In this type of deployment, each SmartAuditor Server has its own dedicated storage, network

switches, and database. To distribute the load, point the SmartAuditor Agents in your deployment to different

SmartAuditor Servers.

Database Scalability

The SmartAuditor Database requires Microsoft SQL Server 2005 or Microsoft SQL Server 2008. The volume of data sent to

the database is very small because the database stores only metadata about the recorded sessions. The files of the

recorded sessions themselves are written to a separate disk. Typically, each recorded session requires only about 1KB of

space in the database, unless the SmartAuditor Event API is used to insert searchable events into the session.

The Express Editions of Microsoft SQL Server 2005 and Microsoft SQL Server 2008 imposes a database size limitation of

4GB. At 1KB per recording session, the database can catalog about four million sessions. Other editions of Microsoft SQL

Server have no database size restrictions and are limited only by available disk space. As the number of sessions in the

database increases, performance of the database and speed of searches diminishes only negligibly.

If you are not making customizations through the SmartAuditor Event API, each recorded session generates four database

transactions: two when recording starts, one when the user logs onto the session being recorded, and one when recording

ends. If you used the SmartAuditor Event API to customize sessions, each searchable event recorded generates one

transaction. Because even the most basic database deployment can handle hundreds of transactions per second, the

processing load on the database is unlikely to be stressed. The impact is light enough that the SmartAuditor Database can

run on the same SQL Server as other databases, including the XenApp data store database.

If your SmartAuditor deployment requires many millions of recorded sessions to be cataloged in the database, follow

Microsoft guidelines for SQL Server scalability.


Security Recommendations

May 05, 2015

SmartAuditor is designed to be deployed within a secure network and accessed by administrators, and as such, is secure.

Out-of-the-box deployment is designed to be simple and security features such as digital signing and encryption can be

configured optionally.

Communication between SmartAuditor components is achieved through Internet Information Services (IIS) and Microsoft

Message Queuing (MSMQ). IIS provides the web services communication link between each SmartAuditor component.

MSMQ provides a reliable data transport mechanism for sending recorded session data from the SmartAuditor Agent to

the SmartAuditor Server.

Consider these security recommendations when planning your deployment:

Isolate servers running SmartAuditor components on a separate subnet or domain.

Protect the recorded session data from users accessing other servers by installing a f irewall between the SmartAuditor

Server and other servers.

Ensure servers running SmartAuditor components are physically secure. If possible, lock these computers in a secure room

to which only authorized personnel can gain direct access.

Strictly limit who is authorized to make recording policy changes and view recorded sessions.

Install digital certif icates, use the SmartAuditor f ile signing feature, and set up SSL communications in IIS.

Use playback protection. Playback protection is a SmartAuditor feature that encrypts recorded f iles before they are

downloaded to the SmartAuditor Player. By default, this option is enabled and is in the SmartAuditor Server Properties.

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.

The SmartAuditor installation is configured to use HTTPS by default and requires that you configure the default Web site


with a server certificate issued from a CA. If you need instructions for installing server certificates in IIS, consult your IIS

documentation.


Installing SmartAuditor

May 05, 2015

Before you start the installation, ensure that you completed this list:

Step

Selected the computers on which to install each SmartAuditor component and ensured that eachcomputer meets the hardware and software requirements for the component or components to beinstalled on it.

If you use the SSL protocol for communication between the SmartAuditor components, install the correctcertif icates in your environment.

Install any hotfixes required for the SmartAuditor components. The hotfixes are available from the CitrixKnowledge Center.

To install SmartAuditor Administration components

Use the Autorun to install SmartAuditor components.

The SmartAuditor Administration components are the SmartAuditor Database, SmartAuditor Server, and the SmartAuditor

Policy Console. You can choose which of these components to install on a server.

1. On the installation media, click autorun.exe. The Autorun menu launches.

2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Administration.

3. Use the installation wizard to select the SmartAuditor Administration components you want to install.

4. On the Database Configuration page:

If you are installing all the Administration components on the same server, accept localhost in the Accessing user

account for computer or localhost f ield.

If you are installing the SmartAuditor Server and the SmartAuditor Database on different servers, type the name of

the computer hosting the SmartAuditor Server in the following format: domain\machine-name$. Ensure that the

dollar symbol ($) follows the name.

5. Follow the wizard’s instructions to complete the installation.

To install the SmartAuditor Agent

The SmartAuditor Agent must be installed on a computer running XenApp.1. On the installation media, click autorun.exe. The Autorun menu launches.

2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Agent.

3. In the SmartAuditor Agent Configuration page, enter the name of the computer where you installed the SmartAuditor

Server.

4. Follow the wizard’s instructions to complete the installation.

To install SmartAuditor Player

The SmartAuditor Player is installed on one or more workstations for users who view session recordings.

1. On the installation media, click autorun.exe. The Autorun menu launches.

http://support.citrix.com


2. Select Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Player.

3. Use the installation wizard to install SmartAuditor Player.

After installing SmartAuditor, configure the components for your environment so you can record and play XenApp sessions.

To uninstall SmartAuditor

To remove SmartAuditor components from a server or workstation, use the uninstall or remove programs capability available

through the Windows Control Panel.

Automating Installations

To install Smart Auditor Agent on multiple servers, write a script that uses silent installation.

The following command line installs the SmartAuditor Agent and creates a log file to capture the install information.

msiexec /i SmartAuditorAgent.msi smartauditorservername=yourservername smartauditorbrokerprotocol=yourbrokerprotocol smartauditorbrokerport=yourbrokerport /l*v yourinstallationlog /q where:

yourservername is the NetBIOS name or FQDN of the computer hosting the SmartAuditor Server. If not specified, this value

defaults to localhost.

yourbrokerprotocol is either HTTP or HTTPS, and represents the protocol that SmartAuditor Agent uses to communicate

with SmartAuditor Broker; this value defaults to HTTPS if not specified.

yourbrokerport is an integer representing the port SmartAuditor Agent uses to communicate with SmartAuditor Broker. If

not specified, this value defaults to zero, which directs SmartAuditor Agent to use the default port number for the selected

protocol: 80 for HTTP or 443 for HTTPS.

/l*v specifies verbose mode logging

yourinstallationlog is the location of the setup log file created.

/q specifies quiet mode.


Configuring SmartAuditor to play and record sessions

May 05, 2015

After you install the SmartAuditor components, perform these steps to configure SmartAuditor to record XenApp sessionsand allow users to view them:

Authorize users to play recordings

Change the active recording policy to one that records sessions

Configure SmartAuditor Player to connect to the SmartAuditor Server

To authorize users to play recorded sessions

When you install SmartAuditor, no users have permission to play recorded sessions. You must assign permission to each user,

including the administrator.

1. Log on as administrator to the computer hosting the SmartAuditor Server.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Authorization Console.

3. In the SmartAuditor Authorization Console, select Player.

4. Add the users and groups you want to authorize to view recorded sessions.

To set the active recording policy to record sessions

The active recording policy specifies session recording behavior on all XenApp servers that have SmartAuditor Agent installed

and connected to the SmartAuditor Server. When you install SmartAuditor, the active recording policy is Do not record.

Sessions cannot be recorded until you change the active recording policy.

1. Log on as administrator to the server where the SmartAuditor Policy Console is installed.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Policy Console.

3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the computer

hosting the SmartAuditor Server, protocol, and port are correct.

4. In the SmartAuditor Policy Console, expand Recording Policies. This displays the recording policies available when you

install SmartAuditor, with a check mark indicating which policy is active:

Do not record. This is the default policy. If you do not specify another policy, no sessions are recorded.

Record everyone with 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.

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 theRecording Policies folder within the SmartAuditor Policy Console.

To configure SmartAuditor Player

Before a SmartAuditor Player can play sessions, you must configure it to connect to the SmartAuditor Server that stores

the recorded sessions. Each SmartAuditor Player can be configured with the ability to connect to multiple SmartAuditor

Servers, but can connect to only one SmartAuditor Server at a time. If the Player is configuring with the ability to connect

to multiple SmartAuditor Servers, users can change which SmartAuditor Server the Player connects to by selecting a check

box.


1. Log on to the workstation where SmartAuditor Player is installed.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Player.

3. From the SmartAuditor Player menu bar, choose Tools > Options.

4. In the Connections tab, click Add.

5. In the Hostname field, type the name or Internet protocol (IP) address of the computer hosting the SmartAuditor Server.

6. If you want to configure the SmartAuditor Player with the ability to connect to more than one SmartAuditor Server,

repeat Steps 4 and 5 for each SmartAuditor Server.

7. Ensure that the check box for the SmartAuditor Server you want to connect to is selected.


Granting Access Rights to Users

Jun 04 , 2010

Note: For security reasons, grant users only the rights they need to perform specif ic functions, such as viewing recordedsessions.You grant rights to SmartAuditor users by assigning them to roles using the SmartAuditor Authorization Console on the

SmartAuditor Server. SmartAuditor users have three roles:

Player. Grants the right to view recorded XenApp sessions. There is no default membership in this role.

PolicyQuery. Allows the servers hosting the SmartAuditor Agent to request recording policy evaluations. By default,

authenticated users are members of this role.

Policy Administrator. Grants the right to view, create, edit, delete, and enable recording policies. By default,

administrators of the computer hosting the SmartAuditor Server are members of this role.

SmartAuditor supports users and groups defined in Active Directory.

To assign users to roles

1. Log on to computer hosting the SmartAuditor Server, as administrator or as a member of the Policy Administrator role.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Authorization Console.

3. Select the role to which you want to assign users.

4. Choose Action > Assign Windows Users and Groups.

5. Add the users and groups.

Any changes made to the console take effect during the update that occurs once every minute.


Creating and Activating Recording Policies

Mar 01, 2010

Use the SmartAuditor Policy Console to create and activate policies that determine which sessions are recorded.

You can activate system policies available when SmartAuditor is installed or create and activate your own custom policies.

SmartAuditor system policies apply a single rule to all users, published applications, and servers. Custom policies specifying

which users, published applications, and servers are recorded.

The active policy determines which sessions are recorded. Only one policy is active at a time.

Using System Policies

SmartAuditor provides these system policies:

Do not record. If you choose this policy, no sessions are recorded. This is the default policy; if you do not specify

another policy, no sessions are recorded.

Record everyone with 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.

System policies cannot be modified or deleted.

Creating Custom Recording Policies

Updated: 2015-05-16

When you create your own policy, you make rules to specify which users and groups, published applications, and servers

have their sessions recorded. A wizard within the SmartAuditor Policy Console helps you create rules.

For each rule you create, you specify a recording action and a rule critera. The recording action applies to sessions that

meet the rule criteria.

For each rule, choose one recording action:

Do not record. (Choose Disable session recording within the rules wizard.) This recording action specif ies that sessions

that meet the rule criteria are not recorded.

Record with notif ication. (Choose Enable session recording with notif ication within the rules wizard.) This recording

action specif ies that sessions that meet the rule criteria are recorded. A pop-up window appears notifying the user that

recording is occurring.

Record without notif ication. (Choose Enable session recording without notif ication within the rules wizard.) This

recording action specif ies that sessions that meet the rule criteria are recorded. Users are unaware that they are being

recorded.

For each rule, choose at least one of the following to create the rule criteria:

Users or Groups. You create a list of users or groups to which the recording action of the rule applies.

Published Applications. You create a list of published applications to which the recording action of the rule applies. Within

the rules wizard, choose the XenApp farm or farms on which the applications are available.


Applications Servers. You create a list of XenApp servers to which the recording action of the rule applies. Within the

rules wizard, choose the XenApp farm or farms where the servers reside.

When you create more than one rule in a recording policy, some sessions may match the criteria for more than one rule. In

these cases, the rule with the highest priority is applied to the session.

The recording action of a rule determines its priority:

Rules with the Do not record action have the highest priority

Rules with the Record with notif ication action have the next highest priority

Rules with the Record without notif ication action have the lowest priority

Some sessions may not meet any rule criteria in a recording policy. For these sessions, the recording action of the policies

fallback rule applies. The recording action of the fallback rule is always Do not record. The fallback rule cannot be modified

or deleted.

Using Active Directory Groups

SmartAuditor allows you to use Active Directory groups when creating policies. Using Active Directory groups instead of

individual users simplifies creation and management of rules and policies. For example, if users in your 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.

White Listing Users

You can create SmartAuditor policies that ensure that the sessions of some users in your organization are never recorded.

This is called white listing these users. White listing is useful for users who handle privacy-related information or when your

organization does not want to record the sessions of a certain class of employees.

For example, if all managers in your company are members of an Active Directory group named Executive, you can ensure

that these users’ sessions are never recorded by creating a rule that disables session recording for the Executive group.

While the policy containing this rule is active, no sessions of members of the Executive group are recorded. The sessions of

other members of your organization are sessions recorded based on other rules in the active policy.

To create a new policy

Note: When using the rules wizard, you may be prompted to “click on underlined value to edit” when no underlined valueappears. 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.


3. If you are prompted by a Connect to SmartAuditor Server pop-up window, ensure that the name of the SmartAuditor

Server, protocol, and port are correct. Click OK.

4. In the SmartAuditor Policy Console, select Recording Policies.

5. From the menu bar, choose Action > Add New Policy. A policy called New Policy appears in the left pane.

6. Select the new policy and choose Action > Rename from the menu bar.

7. Type a name for the policy you are about to create and press Enter or click anywhere outside the new name.

8. With the policy selected, choose Action > Add New Rule from the menu bar to launch the rules wizard.

9. Follow the instructions to create the rules for this policy.


To modify a policy

1. Log on to the server where the SmartAuditor Policy Console is installed.




4. In the SmartAuditor Policy Console, expand Recording Policies.

5. Select the policy you want to modify. The rules for the policy appear in the right pane.

6. Add a new rule, modify a rule, or delete a rule:

From the menu bar, choose Action > Add New Rule. If the policy is active, a pop-up window appears requesting

confirmation of the action. Use the rules wizard to create a new rule.

Select the rule you want to modify, right-click, and choose Properties. Use the rules wizard to modify the rule.

Select the rule you want to delete, right-click, and choose Delete Rule.

To delete a policy

Note: You cannot delete a system policy or a policy that is active.1. Log on to the server where the SmartAuditor Policy Console is installed.





5. In the left pane, select the policy you want to delete. If the policy is active, you must activate another policy.

6. From the menu bar, choose Action > Delete Policy.

7. Select Yes to confirm the action.

To activate a policy






5. Select the policy you want to make the active policy.

6. From the menu bar, choose Action > Activate Policy.

Understanding Rollover Behavior

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

information on maximum file sizes for recordings, see in Specifying File Size for Recordings.

The following table details what happens when you apply a new policy while a session is being recorded and a rollover

occurs:

If the previouspolicy was:

And the new policyis:

After a rollover the policy will be:

Do not record Any other policy No change. The new policy takes effect only when the user logs on

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-sa-library-wrapper-v2/ps-sa-record-enable-v2.html


to a new session.

Record withoutnotif ication

Do not record Recording stops.

Record withnotif ication

Recording continues and a notif ication message appears.

Record withnotif ication

Do not record Recording stops.

Record withoutnotif ication

Recording continues. No message appears the next time a user logson.

If the previouspolicy was:

And the new policyis:

After a rollover the policy will be:


Configuring SmartAuditor Recording

May 05, 2015

You install the SmartAuditor Agent on each XenApp server for which you want to record sessions. Within each agent is a

setting that enables recording for the server on which it is installed. After recording is enabled, SmartAuditor evaluates the

active recording policies, which determines which sessions are recorded.

When you install the SmartAuditor Agent, recording is enabled. Citrix recommends that you disable SmartAuditor on servers

that are not recorded because they experience a small impact on performance, even if no recording takes place.

To disable or enable recording on a server

1. Log on to the server where the SmartAuditor Agent is installed.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Agent Properties.

3. Under Session recording, select or clear the Enable session recording for this XenApp server check box to specify whether

or not sessions can be recorded for this server.

4. When prompted, restart the SmartAuditor Agent Service to accept the change.

Note: When you install SmartAuditor, the active policy is Do not record (no sessions are recorded on any server). To beginrecording, use the SmartAuditor Policy Console to activate a different policy.

To configure the connection to the SmartAuditor Server

The connection between the SmartAuditor Agent and the SmartAuditor Server is typically configured when the

SmartAuditor Agent is installed. To configure this connection after SmartAuditor Agent is installed, use SmartAuditor Agent

Properties.

1. Log on to the server where SmartAuditor Agent is installed.


3. Click the Connections tab.

4. In the SmartAuditor Server f ield, type the server name or its Internet protocol (IP) address.

5. In the SmartAuditor Storage Manager message queue section, select the protocol that is used by the SmartAuditor

Storage Manager to communicate and modify the default port number, if necessary.

6. In the Message life f ield, accept the default of 7200 seconds (two hours) or type a new value for the number of

seconds each message is retained in the queue if there is a communication failure. After this period of time elapses, the

message is deleted and the f ile is playable until the point where the data is lost.

7. In the SmartAuditor Broker section, select the communication protocol the SmartAuditor Broker uses to communicate

and modify the default port number, if necessary.

8. When prompted, restart the SmartAuditor Agent Service to accept the changes.

To create notification

If the active recording policy specifies that users are notified when their sessions are recorded, a pop-up window appears

displaying a notification message after users type their credentials. The following message is the default notification: “Your

activity with one or more of the programs you recently started is being recorded. If you object to this condition, close the

programs.” The user clicks OK to dismiss the window and continue the session.

The default notification message appears in the language of the operating system of the computers hosting the



You can create custom notifications in languages of your choice; however, you can have only one notification message for

each language. Your users see the notification message in the language corresponding to their user preferred locale

settings.

1. Log on to the computer hosting the SmartAuditor Server.

2. From the Start menu, choose All Programs > Citrix > SmartAuditor > SmartAuditor Server Properties.

3. In SmartAuditor Server Properties, click the Notif ications tab.

4. Click Add.

5. Choose the language for the message and type the new message. You can create only one message for each language.

After accepting and activating, the new message appears in the Language-specif ic notif ication 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.

These events appear when the session is viewed using the SmartAuditor Player. They are part of the recorded session file

and cannot be modified after the session is recorded.

For example, an event might contain the following text: “User opened a browser.” Each time a user opens a browser during

a session that is being recorded, the text is inserted into the recording at that point. When the session is played using the

SmartAuditor Player, the viewer can locate and count the times that the user opened a browser by noting the number of

markers that appear in the Events and Bookmarks list in the SmartAuditor Player.

To insert custom events into recordings on a server:

Use SmartAuditor Agent Properties to enable a setting on each server where you want to insert custom events. You

must enable each server separately; you cannot globally enable all servers in a farm.

Write applications built on the Event API that runs within each user’s XenApp session (to inject the data into the

recording).

The SmartAuditor installation includes an event recording COM application (API) that allows you to insert text from third-

party applications into a recording. You can use the API from many programming languages including Visual Basic, C++, or

C#. The SmartAuditor Event API .dll is installed as part of the SmartAuditor installation. You can find it at C:\Program

Files\Citrix\SmartAuditor\Agent\Bin\Interop.UserApi.dll.



3. In SmartAuditor Agent Properties, click the Recording tab.

4. Under Custom event recording, select the Allow third party applications to record custom data on this XenApp server

check box.

To enable or disable live session playback

Using SmartAuditor Player, you can view a session after or while it is being recorded. Viewing a session that is currently

recording is similar to seeing actions happening live; however, there is actually a one to two second delay as the data

propagates from the XenApp server.

Some functionality is not available when viewing sessions that have not completed recording:

A digital signature cannot be assigned until recording is complete. If digital signing is enabled, you can view live playback

sessions, but they are not digitally signed and you cannot view certif icates until the session is completed.

Playback protection cannot be applied until recording is complete. If playback protection is enabled, you can view live


playback sessions, but they are not encrypted until the session is completed.

You cannot cache a f ile until recording is complete.

By default, live session playback is enabled.



3. In SmartAuditor Server Properties, click the Playback tab.

4. Select or clear the Allow live session playback check box.

To enable or disable playback protection

As a security precaution, SmartAuditor automatically encrypts recorded files before they are downloaded for viewing in the

SmartAuditor Player. This playback protection prevents them from being copied and viewed by anyone other than the user

who downloaded the file. The files cannot be played back on another workstation or by another user. Encrypted files are

identified with an .icle extension; unencrypted files are identified with an .icl extension. The files remain encrypted while they

reside in the cache on the workstation where the SmartAuditor Player is installed until they are opened by an authorized

user.

Citrix recommends that you use HTTPS to protect the transfer of data.

By default, playback protection is enabled.



3. In SmartAuditor Server Properties, click the Playback tab.

4. Select or clear the Encrypt session recording f iles downloaded for playback check box.

To enable and disable digital signing

If you installed certificates on the computers on which the SmartAuditor components are installed, you can enhance the

security of your SmartAuditor deployment by assigning digital signatures to session recording.

By default, digital signing is disabled.

To enable digital signing



3. In SmartAuditor Server Properties, click the Signing tab.

4. Browse to the certif icate that enables secure communication among the computers on which the SmartAuditor

components are installed.

To disable digital signing



3. In SmartAuditor Server Properties, click the Signing tab.

4. Click Clear.

To specify where recordings are stored


Use SmartAuditor Server Properties to specify where recordings are stored and where archived recordings are restored.

Note: To archive f iles or restore deleted f iles, use the icldb command.

To specify the location for recorded files

By default, recordings are stored in the drive:\SessionRecordings directory of the computer hosting the SmartAuditor Server.

You can change the directory where the recordings are stored, add additional directories to load-balance across multiple

volumes, or make use of additional space. Multiple directories in the list indicates recordings are load-balanced across the

directories. You can add a directory multiple times. Load balancing cycles through the directories.



3. In SmartAuditor Server Properties, click the Storage tab.

4. Use the File storage directories list to manage the directories where recordings are stored.

You can create file storage directories on the local drive, the SAN volume, or a location specified by a UNC network path.

Network mapped drive letters are not supported. Do not use SmartAuditor with Network-Attached Storage (NAS), due to

serious performance and security problems associated with writing recording data to a network drive.

To specify a restore directory for archived files

By default, archived recordings are restored to the drive:\SessionRecordingsRestore directory of the computer hosting the

SmartAuditor Server. You can change the directory where the archived recordings are restored.



3. In SmartAuditor Server Properties, click the Storage tab.

4. In the Restore directory for archived f iles f ield, type the directory for the restored archive f iles.

Specifying File Size for Recordings

As recordings grow in size, the files can take longer to download and react more slowly when you use the seek slider to

navigate during playback. To control file size, specify a threshold limit for a file. When the recording reaches this limit,

SmartAuditor closes the file and opens a new one to continue recording. This action is called a rollover.

You can specify two thresholds for a rollover:

File size. When the f ile reaches the specif ied number of megabytes, SmartAuditor closes the f ile and opens a new one.

By default, f iles 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 specif ied number of hours, the f ile is closed and a new file is opened. By

default, f iles roll over after recording for 12 hours; however, you can specify a limit from one to 24 hours.

SmartAuditor checks both fields to determine which event occurs first to determine when to rollover. For example, if you

specify 17MB for the file size and six hours for the duration and the recording reaches 17MB in three hours, SmartAuditor

reacts to the 17MB file size to close the file and open a new one.

To prevent the creation of many small files, SmartAuditor does not rollover until at least one hour elapses (this is the

minimum number that you can enter) regardless of the value specified for the file size. The exception to this rule is if the file

size surpasses one gigabyte.


To specify a maximum limit for a file



3. In SmartAuditor Server Properties, click the Rollover tab.

4. Enter an integer between 10 and 1024 to specify the maximum file size in megabytes.

5. Enter an integer between 1 and 24 to specify the maximum recording duration in hours.


Viewing Recordings

May 05, 2015

Use SmartAuditor Player to view, search, and bookmark recorded XenApp sessions.

If sessions are recorded with the live playback feature enabled, you can view sessions that are in progress, with a delay of a

few seconds, as well as sessions that are completed.

Sessions that have a longer duration or larger file size than the limits configured by your SmartAuditor administrator appear

in more than one session file.

Note: A SmartAuditor administrator must grant users the right to access to recorded XenApp sessions. If you are deniedaccess 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.



The SmartAuditor Player appears.

This illustration shows the SmartAuditor Player with callouts indicating its major elements. The functions of these elementsare described throughout this chapter.

To display or hide window elements

The SmartAuditor Player has window elements that toggle on and off.

1. Log on to the workstation where the SmartAuditor Player is installed.



3. From the SmartAuditor Player menu bar, choose View.

4. Choose the elements that you want to display. Selecting an element causes it to appear immediately. A check mark

indicates that the element is selected.

To change SmartAuditor Servers

If the SmartAuditor administrator set up your SmartAuditor Player with the ability to connect to more than one

SmartAuditor Server, you can select the SmartAuditor Server that the SmartAuditor Player connects to. The SmartAuditor

Player can connect to only one SmartAuditor Server at a time.



3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections.

4. Select the SmartAuditor Server to which you want to connect.


To open and play recordings

Jun 04 , 2010

You can open session recordings in SmartAuditor Player in two ways:

Perform a search using the Smart Auditor Player. Recorded sessions that meet the search criteria appear in the search

results area.

Access recorded session f iles directly from your local disk drive or a share drive.

Access recorded session f iles from a Favorites folder

When you open a file that was recorded without a digital signature, a warning appears telling you that the origin and

integrity of the file was not verified. If you are confident of the integrity of the file, click Yes in the warning pop-up window

to open the file.

To open and play a recording in the search results area



3. Perform a search.

4. If the search results area is not visible, select Search Results in the Workspace pane.

5. In the search results area, select the session you want to play.

6. Do any of the following:

Double-click the session

Right-click and select Play

From the SmartAuditor Player menu bar, select Play > Play

To open and play a recording by accessing the file

Recorded session f ile names begin with an i_, followed by a unique alphanumeric f ile ID, followed by the .icl and .icle f ileextension: .icl for recordings without playback protection applied, .icle for recordings with playback protection applied.SmartAuditor saves recorded session f iles in a directory structure that incorporates the date the session was recorded. Forexample, the f ile 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.


3. Do any of the following:

From the SmartAuditor Player menu bar, select File > Open and browse for the f ile

Using Windows Explorer, navigate to the f ile and drag the f ile into the Player window

Using Windows Explorer, navigate to and double-click the f ile

If you created Favorites in the Workspace pane, select Favorites and open the f ile from the Favorites area in the

same way you open f iles from the search results area

Using Favorites

Creating Favorites folders allows you to quickly access recordings that you view frequently. These Favorites folders

reference recorded session files that are stored on your workstation or on a network drive. You can import and export

these files to other workstations and share these folders with other SmartAuditor Player users.

Note: Only users with access rights to SmartAuditor Player can download the recorded session f iles associated withFavorites folders. Contact your SmartAuditor administrator for access rights.


To create a Favorites subfolder:



3. In the SmartAuditor Player, select the Favorites folder in your Workspace pane.

4. From the menu bar, choose File > Folder > New Folder. A new folder appears under the Favorites folder.

5. Type the folder name, then press Enter or click anywhere to accept the new name.

Use the other options that appear in the File > Folder menu to delete, rename, move, copy, import, and export the folders.

To search for recorded sessions

Updated: 2015-05-05

SmartAuditor Player allows you to perform quick searches, perform advanced searches, and specify options that apply to all

searches. Results of searches appear in the search results area of the SmartAuditor Player.

Note: To display all available recorded sessions, up to the maximum number of sessions that may appear in a search,perform a search without specifying any search parameters.

To perform a quick search



3. Define your search criteria:

Enter a search criterion in the Search f ield. To assist you:

Move the mouse pointer over the Search label to display a list of parameters to use as a guideline

Click the arrow to the right of the Search f ield to display the text for the last 64 searches you performed

Use the drop-down list to the right of the Search f ield to select a period or duration specifying when the session was

recorded.

4. Click the binocular icon to the right of the drop-down list to start the search.

To perform an advanced search



3. In the SmartAuditor Player window, click Advanced Search on the tool bar or choose Tools > Advanced Search.

4. Define your search criteria in the tabs of the Advanced Search dialog box:

Common allows you to search by domain or account authority, server farm, group, zone, server, application, or f ile ID.

Date/Time allows you to search date, day of week, and time of day.

Events allows you to search on custom events that your SmartAuditor administrator inserted to the sessions.

Other allows you to search by session name, client name, client address, and recording duration. It also allows you to

specify, for this search, the maximum number of search results displayed and whether or not archived f iles are included

in the search.

As you specify search criteria, the query you are creating appears in the pane at the bottom of the dialog box.

5. Click Search to start the search.

Tip: You can save and retrieve advanced search queries. Click Save within the Advanced Search dialog box to save thecurrent query. Click Open within the Advanced Search dialog box to retrieve a saved query. Queries are saved as f iles with an.isq extension.

To set search options


SmartAuditor Player search options allow you to limit maximum number of session recordings that appear in search resultsand to specify whether or not search results include archived session f iles.1. Log on to the workstation where SmartAuditor Player is installed.


3. From the SmartAuditor Player menu bar, choose Tools > Options > Search.

4. In the Maximum result to display f ield, type the number of search results you want to display. A maximum of 500 results

can be displayed.

5. To set whether or not archived f iles are included in searches, select or clear Include archived f iles.

To play recorded sessions

After you open a recorded session in the SmartAuditor Player, you can navigate through the recorded sessions using these

methods:

Use the player controls to play, stop, pause, and increase or decrease playback speed

Use the seek slider to move forward or backward

If you have inserted markers into the recording or if the recorded session contains custom events, you can also navigate

through the recorded session by going to those markers and events.

Note: During playback of a recorded session, a second mouse pointer may appear. The second pointer appears at the pointin the recording when the user navigated within Internet Explorer 7.0 and clicked an image that was originally larger thanthe screen but was scaled down automatically by Internet Explorer 7.0. While only one pointer appears during the session,two may appear during playback.Note: This version of SmartAuditor does not support SpeedScreen Multimedia Acceleration for Citrix Presentation Server orthe Flash quality adjustment policy setting for Citrix XenApp. When this option is enabled, playback displays a black square.

Using Player Controls

You can click the player controls under the Player window or access them by choosing Play from the SmartAuditor Player

menu bar. Use Player controls to:

Play the selected session f ile.

Pause playback.

Stop playback. If you click Stop, then Play, the recording restarts at the beginning of the f ile.

Halve the current playback speed down to a minimum of one-quarter normal speed.

Double the current playback speed up to a maximum of 32 times normal speed.

Using the Seek Slider

Use the seek slider below the Player window to jump to a different position within the recorded session. You can drag the


seek slider to the point in the recording you want to view or click anywhere on the slider bar to move to that location.

You can also use the following keyboard keys to control the seek slider:

Key: Seek action:

Home Seek to the beginning.

End Seek to the end.

Right Arrow Seek forward f ive seconds.

Left Arrow Seek backward f ive seconds.

Move mouse wheel one notchdown

Seek forward 15 seconds.

Move mouse wheel one notch up Seek backward 15 seconds.

Ctrl + Right Arrow Seek forward 30 seconds.

Ctrl + Left Arrow Seek backward 30 seconds.

Page Down Seek forward one minute.

Page Up Seek backward one minute.

Ctrl + Move mouse wheel onenotch down

Seek forward 90 seconds.

Ctrl + Move mouse wheel onenotch up

Seek backward 90 seconds.

Ctrl + Page Down Seek forward six minutes.

Ctrl + Page Up Seek backward six minutes.

Note: To adjust the speed of the seeks slider: From the SmartAuditor Player menu bar, choose Tools > Options > Player anddrag 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 playbackspeed to 32 times normal playback speed.




3. From the SmartAuditor Player menu bar, choose Play > Play Speed.

4. Choose a speed option.

The speed adjusts immediately. A number indicating the increased or decreased speed appears below the Player windowcontrols. Text indicating the exponential rate appears briefly in green in the Player window.

To skip over spaces where no action occurred

Fast review mode allows you to set SmartAuditor Player to skip the portions of recorded sessions in which no action takesplace. This setting saves time for playback viewing; however, it does not skip animated sequences such as animated mousepointers, f lashing cursors, or displayed clocks with second hand movements.1. Log on to the workstation where SmartAuditor Player is installed.


3. From the SmartAuditor Player menu bar, choose Play > Fast Review Mode.

The option toggles on and off . Each time you choose it, its status appears briefly in green in the Player window.


Events and bookmarks

May 05, 2015

You can use events and bookmarks to help you navigate through recorded sessions.

Events are inserted to sessions as they are recorded, using the Event API and a third-party application. Events are saved as

part of the session file. You cannot delete or alter them using the SmartAuditor Player.

Bookmarks are markers you insert into the recorded sessions using the SmartAuditor Player. Bookmarks are associated with

the recorded session until you delete them, but they are not saved as part of the session file. By default, each bookmark is

labelled with the text Bookmark, but you can change this to any text annotation up to 128 characters long.

Events and bookmarks appear as dots under the Player window. Events appear as yellow dots; bookmarks appear as blue

dots. Moving the mouse over these dots displays the text label associated with them. You can also display the events and

bookmarks in the events and bookmarks list of the SmartAuditor Player. They appear in this list with their text labels and

the times in the recorded session at which they appear, in chronological order.

You can use events and bookmarks to help you navigate through recorded sessions. By going to an event or bookmark, you

can skip to the point in the recorded session where the event or bookmark is inserted.

To display events and bookmarks in the list

The events and bookmarks list displays the events and bookmarks inserted in the recorded session that is currently playing.It can show events only, bookmarks only, or both.1. Log on to the workstation where the SmartAuditor Player is installed.


3. Move the mouse pointer into the events and bookmarks list area and right-click to display the menu.

4. Choose Show Events Only, Show Bookmarks Only, or Show All.

To insert a bookmark



3. Begin playing the recorded session to which you want to add a bookmark.

4. Move the seek slider to the position where you want to insert the bookmark.

5. Move the mouse pointer into the Player window area and right-click to display the menu.

6. Add a bookmark with the default label Bookmark or create an annotation:

To add a bookmark with the default label Bookmark, choose Add Bookmark.

To add a bookmark with a descriptive text label that you create, choose Add Annotation. Type the text label you

want to assign to the bookmark, up to 128 characters. Click OK.

To add or change an annotation

After a bookmark is created, you can add an annotation to it or change its annotation.1. Log on to the workstation where SmartAuditor Player is installed.


3. Begin playing the recorded session containing the bookmark.

4. Ensure that the events and bookmarks list is displaying bookmarks.

5. Select the bookmark in the events and bookmarks list and right-click to display the menu.


6. Choose Edit Annotation.

7. In the window that appears, type the new annotation and click OK.

To delete a bookmark



3. Begin playing the recorded session containing the bookmark.

4. Ensure that the events and bookmarks list is displaying bookmarks.

5. Select the bookmark in the events and bookmarks list and right-click to display the menu.

6. Choose Delete.

To go to an event or bookmark

Going to an event or bookmark causes the SmartAuditor Player to go to the point in the recorded session where the eventor bookmark is inserted.1. Log on to the workstation where the SmartAuditor Player is installed.


3. Begin playing a session recording containing events or bookmarks.

4. Go to an event or bookmark:

In the area below the Player window, click the dot representing the event or bookmark to go to the event or

bookmark.

In the events and bookmarks list, double-click the event or bookmark to go to it. To go to the next event or

bookmark, select any event or bookmark from the list, right-click to display the menu, and choose Seek to Bookmark.


Set the playback display

May 05, 2015

Options allow you to change how recorded sessions appear in the Player window. You can pan and scale the image, show

the playback in full-screen mode, display the Player window in a separate window, and display a red border around the

recorded session to differentiate it from the Player window background.

To display the Player window in full-screen format



3. From the SmartAuditor Player menu bar, choose View > Player Full Screen.

4. To return to the original size, press ESC or F11.

To display the Player window in a separate window



3. From the SmartAuditor Player menu bar, choose View > Player in Separate Window. A new window appears containing

the Player window. You can drag and resize the window.

4. To embed the Player window in the main window, choose View > Player in Separate Window, or press F10.

To scale the session playback to fit the Player window



3. From the SmartAuditor Player menu bar, choose Play > Panning and Scaling > Scale to Fit.

Scale to Fit (Fast Rendering) shrinks the image while providing a good quality image. Images are drawn quicker than

when using the High Quality option but the images and text are not as sharp. Use this option if you are experiencing

performance issues when using the High Quality mode.

Scale to Fit (High Quality) shrinks the image while providing high quality images and text. Using this option may cause

the images to be drawn more slowly than the Fast Rendering option.

To pan the image



3. From the SmartAuditor Player menu bar, choose Play > Panning and Scaling > Panning. The pointer changes to a hand

and a small representation of the screen appears in the top right of the Player window.

4. Drag the image. The small representation indicates where you are in the image.

5. To stop panning, choose one of the scaling options.

To display a red border around the session recording



3. From the SmartAuditor Player menu bar, choose Tools > Options > Player from the menu bar.

4. Select the Show border around session recording check box.

T ip: If the Show border around session recording check box is not selected, you can temporarily view the red border by


clicking and holding down the left mouse button while the pointer is in the Player window.


Cache recorded session files

May 05, 2015

Each time you open a recorded session file, the SmartAuditor Player downloads the file from the location where the

recordings are stored. If you download the same files frequently, you can save download time by caching the files on your

workstation. Cached files are stored on your workstation in these folders:

userprofile\Local Settings\Application Data\Citrix\SmartAuditor\Player\Cache on Microsoft Windows XP

userprofile\AppData\Local\Citrix\SmartAuditor\Player\Cache on Microsoft Windows Vista

You can specify how much disk space is used for the cache. When the recordings fill the specified disk space, SmartAuditor

deletes the oldest, least used recordings to make room for new recordings. You can empty the cache at any time to free up

disk space.

To enable caching



3. From the SmartAuditor Player menu bar, choose Tools > Options > Cache.

4. Select the Cache downloaded f iles on local machine check box.

5. If you want to limit the amount of disk space used for caching, select the Limit amount of disk space to use check box

and specify the number of megabytes to be used for cache.

6. Click OK.

To empty cache



3. From the SmartAuditor Player menu bar, choose Tools > Options > Cache.

4. Select the Cache downloaded f iles on local machine check box.

5. In the SmartAuditor Player, choose Tools > Options > Cache.

6. Click Purge Cache, then OK to confirm the action.


Troubleshooting SmartAuditor

May 01, 2015

This troubleshooting information contains solutions to some issues you may encounter during and after installing

SmartAuditor components:

Components failing to connect to each other

Sessions failing to record

Problems with viewing sessions or f inding recordings

SmartAuditor Agent Cannot Connect

Updated: 2015-05-05

When SmartAuditor Agent cannot connect, the Exception caught while sending poll messages to SmartAuditor Broker

event message is logged, followed by the exception text. The exception text provides the reason why the connection

failed. These reasons include:

The underlying connection was closed. Could not establish a trust relationship for the SSL/TLS secure channel. This

exception means that the SmartAuditor Server is using a certificate that is signed by a CA that the server on which the

SmartAuditor Agent resides does not trust, or have a CA certificate for. Alternatively, the certificate may have expired or

been revoked.

Resolution: Verify that the correct CA certificate is installed on the server hosting the SmartAuditor Agent or use a CA

that is trusted.

The remote server returned an error: (403) forbidden. This is a standard HTTPS error displayed when you attempt to

connect using HTTP (nonsecure protocol). The computer hosting the SmartAuditor Server rejects the connection

because it accepts only secure connections.

Resolution: Use SmartAuditor Agent Properties to change the SmartAuditor Broker protocol to HTTPS.

The SmartAuditor Broker returned an unknown error while evaluating a record policy query. Error code 5 (Access Denied).

See the Event log on the SmartAuditor Server for more details. This error occurs when sessions are started and a request

for a record policy evaluation is made. The error is a result of the Authenticated Users group (this is the default member)

being removed from the Policy Query role of the SmartAuditor Authorization Console.

Resolution: Add the Authenticated Users group back into this role, or add each server hosting each SmartAuditor Agent to

the PolicyQuery role.

The underlying connection was closed. A connection that was expected to be kept alive was closed by the server. This error

means that the SmartAuditor Server is down or unavailable to accept requests. This could be due to IIS being offline or

restarted, or the entire server may be offline.

Resolution: Verify that the SmartAuditor Server is started, IIS is running on the server, and the server is connected to the

network.

SmartAuditor Server Cannot Connect to the SmartAuditor Database

When the SmartAuditor Server cannot connect to the SmartAuditor Database, you may see a message similar to one of


the following:

Event Source: Citrix SmartAuditor Storage Manager Description: Exception caught while establishing database connection.

This error appears in the applications event log in the Event Viewer of the computer hosting the SmartAuditor Server.

Unable to connect to the SmartAuditor Server. Ensure that the SmartAuditor Server is running. This error message appears

when you launch the SmartAuditor Policy Console.

Resolution:The Express Edition of Mircosoft SQL Server 2005 or Microsoft SQL Server 2008 is installed on a stand-alone server and

does not have the correct services or settings configured for SmartAuditor. The server must have TCP/IP protocol

enabled and SQL Server Browser service running. See the Microsoft documentation for information about enabling

these settings.

During the SmartAuditor installation (administration portion), incorrect server and database information was given.

Uninstall the SmartAuditor Database and reinstall it , supplying the correct information.

The SmartAuditor Database Server is down. Verify that the server has connectivity.

The computer hosting the SmartAuditor Server or the computer hosting the SmartAuditor Database Server cannot

resolve the FQDN or NetBIOS name of the other. Use the ping command to verify the names can be resolved.

Logon failed for user ‘NT_AUTHORITY\ANONYMOUS LOGON’. This error message means that the services are logged on

incorrectly as .\administrator.

Resolution: Restart the services as local system user and restart the SQL services.

Sessions are not Recording

If your XenApp sessions are not recording successfully, start by checking the application event log in the Event Viewer on

the XenApp server running the SmartAuditor Agent and SmartAuditor Server. This may provide valuable diagnostic

information.

If sessions are not recording, these issues might be the cause:

Component connectivity and certif icates. If the SmartAuditor components cannot communicate with each other,

this can cause session recordings to fail. To troubleshoot recording issues, verify that all components are configured

correctly to point to the correct computers and that all certif icates 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 f irst published

application that a user opens. Subsequent applications opened during the same session continue to follow the policy

that is in force for the f irst application. To prevent session sharing from conflicting with the active policy, publish the

conflicting applications on separate XenApp servers or disable session sharing. For instructions about how to disable

session sharing, refer to the Citrix Knowledge Center. When disabling session sharing, consider that this can also affect

the total number of sessions on a server, clipboard mapping, and session logon time.

Recording is not enabled. By default, installing the SmartAuditor Agent on a XenApp server enables the server for

recording. Recording will not occur until an active recording policy is configured to allow this.

The active recording policy permit recording. For a session to be recorded, the active recording policy must permit

the sessions for the user, server, or published application to be recorded.

SmartAuditor services are not running. For sessions to be recorded, the SmartAuditor Agent service must be running

on the XenApp server and the SmartAuditor Storage Manager service must be running on the computer hosting the



MSMQ is not conf igured. If MSMQ is not correctly configured on the server running the SmartAuditor Agent and the

computer hosting the SmartAuditor Server, recording problems may occur.

Unable to View Live Session Playback

If you experience difficulties when viewing recordings using the SmartAuditor Player, the following error message may

appear on the screen:

Download of recorded session file failed. Live session playback is not permitted. The server has been configured to disallow

this feature. This error indicates that the server is configured to disallow the action.

Resolution: In the SmartAuditor Server Properties dialog box, choose the Playback tab and select the Allow live session

playback check box.

Searching for Recordings in the Player Fails

If you experience difficulties when searching for recordings using the SmartAuditor Player, the following error messages

may appear on the screen:

Search for recorded session f iles failed. The remote server name could not be resolved: servername. where servername is

the name of the server to which the SmartAuditor Player is attempting to connect. The SmartAuditor Player cannot

contact the SmartAuditor Server. Two possible reasons for this are an incorrectly typed server name or the DNS cannot

resolve the server name.

Resolution: From the Player menu bar, choose Tools > Options > Connections and verify that the server name in the

SmartAuditor Servers list is correct. If it is correct, from a command prompt, run the ping command to see if the name

can be resolved. When the SmartAuditor Server is down or offline, the search for recorded session files failed error

message is Unable to contact the remote server.

Unable to contact the remote server. This error occurs when the SmartAuditor Server is down or off line.

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 f iles.

Resolution: Assign the user to the Player role using the SmartAuditor Authorization Console.

Search for recorded session f iles failed. The underlying connection was closed. Could not establish a trust relationship for

the SSL/TLS secure channel. This exception is caused by the SmartAuditor Server using a certif icate that is signed by a

CA that the client device does not trust or have a CA certif icate for.

Resolution: Install the correct or trusted CA certificate workstation where the SmartAuditor Player is installed.

The remote server returned an error: (403) forbidden. This error is a standard HTTPS error that occurs when you attempt

to connect using HTTP (nonsecure protocol). The server rejects the connection because, by default, it is configured to

accept only secure connections.

Resolution: From the SmartAuditor Player menu bar, choose Tools > Options > Connections. Select the server from the

SmartAuditors Servers list, then click Modify. Change the protocol from HTTP to HTTPS.

Troubleshooting MSMQ

If your users see the notification message but the viewer cannot find the recordings after performing a search in the

SmartAuditor Player, there could be a problem with MSMQ. Verify that the queue is connected to the SmartAuditor Server


(Storage Manager) and use a Web browser to test for connection errors (if you are using HTTP or HTTPS as your MSMQ

communication protocol).

To verify that the queue is connected:

1. Log on to the server hosting the SmartAuditor Agent.

2. View the outgoing queues.

3. Verify that the queue to the computer hosting the SmartAuditor Server has a connected state.

If the state is “waiting to connect,” there are a number of messages in the queue, and the protocol is HTTP or HTTPS

(corresponding to the protocol selected in the Connections tab in the SmartAuditor Agent Properties dialog box),

perform Step 4.

If state is “connected” and there are no messages in the queue, there may be a problem with the server hosting the

SmartAuditor Server. Skip Step 4 and perform Step 5.

4. If there are a number of messages in the queue, launch a Web browser and type the following address:

For HTTPS: https://servername/msmq/private$/CitrixSmAudData, where servername is the name of the computer

hosting the SmartAuditor Server

For HTTP: http://servername/msmq/private$/CitrixSmAudData, where servername is the name of the computer


If the page returns an error such as The server only accepts secure connections, change the MSMQ protocol listed in

the SmartAuditor Agent Properties dialog box to HTTPS. Otherwise, if the page reports a problem with the Web site’s

security certificate, there may be a problem with a trust relationship for the SSL/TLS secure channel. In that case,

install the correct CA certificate or use a CA that is trusted.

5. If there are no messages in the queue, log on to the computer hosting the SmartAuditor Server and view private queues.

Select citrixsmauddata. If there are a number of messages in the queue (Number of Messages Column), verify that the

SmartAuditor StorageManager service is started. If it is not, restart the service.


Verifying Component Connections

May 05, 2015

During the setup of SmartAuditor, the components may not connect to other components. All the components

communicate with the SmartAuditor Server (Broker). By default, the Broker (an IIS component) is secured using the IIS

default Web site certificate. If one component cannot connect to the SmartAuditor Server, the other components may

also fail when attempting to connect.

The SmartAuditor Agent and SmartAuditor Server (Storage Manager and Broker) log connection errors in the applications

event log in the Event Viewer of the computer hosting the SmartAuditor Server, while the SmartAuditor Policy Console and

SmartAuditor Player display connection error messages on screen when they fail to connect.

To verify SmartAuditor Agent is connected



3. In SmartAuditor Server Properties, click Connection.

4. Verify that the value for SmartAuditor Server is the correct server name of the computer hosting the SmartAuditor

Server.

5. Verify that the server given as the value for SmartAuditor Server can be contacted by the XenApp server.

Note: Check the application event log for errors and warnings.

To verify SmartAuditor Server is connected

Caution: Using Registry Editor can cause serious problems that can require you to reinstall the operating system. Citrixcannot guarantee that problems resulting from incorrect use of Registry Editor can be solved. Use Registry Editor at yourown risk.1. Log on to the computer hosting the SmartAuditor Server.

2. Open the Registry Editor.

3. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Server.

4. Verify the value of SmAudDatabaseInstance correctly references the SmartAuditor Database you installed in your SQL

Server instance.

To verify SmartAuditor Database is connected

1. Using a SQL Management tool, open your SQL instance that contains the SmartAuditor Database you installed.

2. Open the Security permissions of the SmartAuditor Database.

3. Verify the SmartAuditor Computer Account has access to the database. For example, if the computer hosting the

SmartAuditor Server is named SmartAudSrv in the MIS domain, the computer account in your database should be

configured as MIS\SmartAudSrv$. This value is configured during the SmartAuditor Database install.

Testing IIS Connectivity

Testing connections to the SmartAuditor Server IIS site by using a Web browser to access the SmartAuditor Broker Web

page can help you determine whether problems with communication between SmartAuditor components stem from

misconfigured protocol configuration, certification issues, or problems starting SmartAuditor Broker.

To verify IIS connectivity for the SmartAuditor Agent



2. Launch a Web browser and type the following address:

For HTTPS: https://servername/SmartAuditorBroker/RecordPolicy.rem?wsdl, where servername is the name of the

computer hosting the SmartAuditor Server

For HTTP: http://servername/SmartAuditorBroker/RecordPolicy.rem?wsdl, where servername is the name of the

computer hosting the SmartAuditor Server

3. If you are prompted for NT LAN Manager (NTLM) authentication, log on with a domain administrator account.

If you see an XML document within your browser, this verif ies that the computer running the SmartAuditor Agent isconnected to the computer hosting the SmartAuditor Server using the configure protocol.

To verify IIS connectivity for the SmartAuditor Player



For HTTPS: https://servername/SmartAuditorBroker/Player.rem?wsdl, where servername is the name of the computer


For HTTP: http://servername/SmartAuditorBroker/Player.rem?wsdl, where servername is the name of the computer



If you see an XML document within your browser, this verif ies that the computer running the SmartAuditor Player isconnected to the computer hosting the SmartAuditor Server using the configure protocol.

To verify IIS connectivity for the SmartAuditor Policy Console



For HTTPS: https://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where servername is the name of

the computer hosting the SmartAuditor Server

For HTTP: http://servername/SmartAuditorBroker/PolicyAdminstration.rem?wsdl, where servername is the name of

the computer hosting the SmartAuditor Server


If you see an XML document within your browser, this verif ies that the computer running the SmartAuditor Policy Consoleis connected to the computer hosting the SmartAuditor Server using the configure protocol.

Troubleshooting Certificate Issues

If you are using HTTPS as your communication protocol, the computer hosting the SmartAuditor Server must be configured

with a server certificate. All component connections to the SmartAuditor Server must have root certificate authority (CA).

Otherwise, attempted connections between the components fail.

You can test your certificates by accessing the SmartAuditor Broker Web page as you would when testing IIS connectivity.

If you are able to access the XML page for each component, the certificates are configured correctly.

Here are some common ways certificate issues cause connections to fail:

Invalid or missing certif icates. If the server running the SmartAuditor Agent does not have a root certif icate to trust

the server certif icate, cannot trust and connect to the SmartAuditor Server over HTTPS, causing connectivity to fail.

Verify that all components trust the server certif icate on the SmartAuditor Server.

Inconsistent naming. If the server certif icate assigned to the computer hosting the SmartAuditor Server is created


using a fully qualif ied 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


Expired certif icates. If a server certif icate expired, connectivity to the SmartAuditor Server through HTTPS fails. Verify

the server certif icate assigned to the computer hosting the SmartAuditor Server is valid and has not expired. If the same

certif icate is used for the digital signing of session recordings, the event log of the computer hosting the SmartAuditor

Server provides error messages that the certif icate expired or warning messages when it is about to expire.


Changing communication protocol

May 05, 2015

For security reasons, Citrix does not recommend using HTTP as a communication protocol. The SmartAuditor installation is

configured to use HTTPS. If you want to use HTTP instead of HTTPS, you must change several settings.

To use HTTP as the communication protocol

1. Log on to the computer hosting the SmartAuditor Server and disable secure connections for SmartAuditor Broker in IIS.

2. Change the protocol setting from HTTPS to HTTP in each SmartAuditor Agent Properties dialog box:

1. Log on to each server where the SmartAuditor Agent is installed.


3. In SmartAuditor Agent Properties, choose the Connections tab.

4. In the SmartAuditor Broker area, select HTTP from the Protocol drop-down list and choose OK to accept the change.

If you are prompted to restart the service, choose Yes.

3. Change the protocol setting from HTTPS to HTTP in the SmartAuditor Player settings:

1. Log on to each workstation where the SmartAuditor Player is installed.


3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select the server and choose Modify.

4. Select HTTP from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box.

4. Change the protocol setting from HTTPS to HTTP in the SmartAuditor Policy Console:



3. Choose HTTP from the Protocol drop-down list and choose OK to connect. If the connection is successful, this

setting is remembered the next time you launch the SmartAuditor Policy Console.

To revert to HTTPS as the communication protocol

1. Log on to the computer hosting the SmartAuditor Server and enable secure connections for the SmartAuditor Broker in

IIS.

2. Change the protocol setting from HTTP to HTTPS in each SmartAuditor Agent Properties dialog box:

1. Log on to each server where the SmartAuditor Agent is installed.


3. In SmartAuditor Agent Properties, choose the Connections tab.

4. In the SmartAuditor Broker area, select HTTPS from the Protocol drop-down list and choose OK to accept the

change. If you are prompted to restart the service, choose Yes.

3. Change the protocol setting from HTTP to HTTPS in the SmartAuditor Player settings:

1. Log on to each workstation where the SmartAuditor Player is installed.


3. From the SmartAuditor Player menu bar, choose Tools > Options > Connections, select the server and choose Modify.

4. Select HTTPS from the Protocol drop-down list and click OK twice to accept the change and exit the dialog box.

4. Change the protocol setting from HTTP to HTTPS in the SmartAuditor Policy Console:



3. Choose HTTPS from the Protocol drop-down list and choose OK to connect. If the connection is successful, this

setting is remembered the next time you launch the SmartAuditor Policy Console.


Managing Your Database Records

May 05, 2015

The ICA Log database (ICLDB) utility is a database command-line utility used to manipulate the session recording database

records. This utility is installed during the SmartAuditor installation in the drive:\Program Files\Citrix\SmartAuditor\Server\Bin

directory at the server hosting the SmartAuditor Server software.

Quick Reference Chart

The following table lists the commands and options that are available for the ICLDB utility. Type the commands using the

following format:

icldb [version | locate | dormant | import | archive | remove | removeall] command-options [/l] [/f ] [/s] [/?]

Note: More extensive instructions are available in the help associated with the utility. To access the help, from a commandprompt, type drive:\Program Files\Citrix\SmartAuditor\Server\Bin directory, type icldb /?. To access help for specif iccommands, type icldb command /?.

Command Description

archive Archives the session recording f iles older than the retention period specif ied.Use this command to archive files.

dormant Displays or counts the session recording f iles that are considered dormant. Dormant f iles aresession recordings that were not completed due to data loss.Use this command to verify if you suspect that you are losing data. You can verify if the

session recording files are becoming dormant for the entire database, or only recordings

made within the specified number of days, hours, or minutes.

import Imports session recording f iles into the SmartAuditor database.Use this command to rebuild the database if you lose database records.

Additionally, use this command to merge databases (if you have two databases, you can

import the files from one of the databases).

locate Locates and displays the full path to a session recording f ile using the f ile 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 f iles from the database.Use this command (with caution) to clean up the database. Specify the retention period to

be used as the criteria.

You can also remove the associated physical file.

removeall Removes all of the references to session recording f iles from the SmartAuditor Database


and returns the database to its original state. The actual physical f iles are not deleted;however you cannot search for these f iles in the SmartAuditor Player.Use this command (with caution) to clean up the database. Deleted references can be

reversed only by restoring from your backup.

version Displays the SmartAuditor Database schema version.

/l Logs the results and errors to the Windows event log.

/f Forces the command to run without prompts.

/s Suppresses the copyright message.

/? Displays help for the commands.

Command Description


VM Hosted Apps

May 06, 2015

VM hosted apps allows you to deliver applications from virtual machines or physical computers, including blade servers,

running Windows single-user desktop operating systems. Users access these applications through a Web browser, the Citrix

online plug-in, or Citrix Receiver, just as they would applications hosted from XenApp servers running Remote Desktop

Services. VM hosted apps allows you to deliver applications that otherwise must be installed locally or require extensive

compatibility testing on XenApp servers.

You can publish any Windows application as a VM-hosted application, but ideal candidates include applications that:

Are incompatible with or not supported by Remote Desktop Services

Require special hardware devices, such as USB, special keyboards, or biometric devices

Consume large amounts of computing or graphics resources

Require a single-user environment

To use VM hosted apps, you create a VM hosted apps site and populate it with desktop groups configured with

applications you want to deliver. Users access these applications but have no direct access to the desktops.

You give users access to these applications using the Web Interface. Although VM hosted apps cannot share a farm with

XenApp servers, a VM hosted apps site can share a Web Interface site with XenApp server farms. Applications from VM

hosted apps sites and XenApp farms appear the same to users.

VM Hosted Apps and XenDesktop

VM hosted apps is available as a feature of XenApp and as a feature of XenDesktop 5.

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;

you install nothing additional.

VM hosted apps does not support XenDesktop-ready thin clients.

Licensing and VM Hosted Apps

VM hosted apps uses XenApp licenses. Each user consumes one XenApp license for all application sessions, regardless of

whether applications are hosted using VM hosted apps or XenApp server.

If you are using VM hosted apps as a feature of XenApp, no additional Citrix licenses are required.

If you are using VM hosted apps as a feature of XenDesktop 5:The XenApp licenses required for the VM hosted apps feature are included with XenDesktop 5 Enterprise edition and

XenDesktop 5 Platinum edition

If you want to use VM hosted apps with a version of XenDesktop 5 that does not include XenApp licenses, you supply

the XenApp licenses required

Key Components of a VM Hosted Apps Deployment

XenDesktop Controller. The XenDesktop Controller consists of services that authenticate users, manage the assembly


of user virtual desktop environments, and broker connections between users and their virtual desktops. It controls the

state of the desktops, starting and stopping them based on demand and administrative configuration.

Desktop Studio. Provides wizards to guide you through the process of setting up your environment, creating your

desktops, assigning desktops to users, and publishing applications on desktops.

Virtual Desktop Agent. You install the Virtual Desktop Agent on the desktops in your VM hosted apps site. It manages

communication between the desktops and the Controller and between the desktops and user devices.

Using VM Hosted Apps With Other XenApp Features

To provision desktops for VM hosted apps, use Machine Creation Services included in XenDesktop 5 or use Provisioning

services.

Use Profile manager to manage user personalization settings for VM hosted apps.

Service monitoring and Edgesight resource manager are not compatible with VM hosted apps, but application performance

monitoring can be used with VM hosted apps by downloading Edgesight for Desktops.

SmartAuditor is not compatible with VM hosted apps.

Migrating From the Previous Version of VM Hosted Apps

Upgrading the server components of VM hosted apps from the previous version (delivered with XenApp 5 Feature Pack 2 for

Windows Server 2003) 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 "Upgrade to

XenDesktop 5" in the XenDesktop 5 product documentation located in the Citrix eDocs Archive.

Planning Your VM Hosted Apps Deployment

Plan your VM hosted apps deployment as part of planning your overall XenApp deployment. Determine which applications

to deliver using VM hosted apps and consider which types of desktops are most appropriate for the applications you want

to deliver, what privileges to give desktop users, and how to secure your desktop environment.

If your VM hosted apps deployment includes virtual machines, install your hosting infrastructure and Provisioning services

separately from VM hosted apps site.

A VM hosted apps site can use a dedicated Web Interface server or share one with other VM hosted apps sites and

XenApp server farms. When VM hosted apps site shares a Web Interface site with a XenApp server farm, users can access

applications from both without regard to how the application is published.

Elements of a VM Hosted Application Site

At least one XenDesktop Controller. Adding more controllers to your site increases failover and scalability.

A database. By default, a database is created locally when you install the Controller, but you can choose to use a

database on a separate server. All VM hosted apps site information is stored on the database; controllers communicate

only with the database and not with each other.

At least one Desktop Studio. By default, this is installed on servers on which you install the Controller, but you can install

it on a separate computer if you want to manage your deployment remotely.

Desktop Director (optional). This Web-based tool enables level-1 and level-2 IT Support staff to monitor a VM hosted


apps deployment and perform day-to-day maintenance tasks. By default, this is installed on servers on which you install

the Controller, but you can choose to install it on a separate computer.

A domain controller running Active Directory. Active Directory is required for the XenDesktop infrastructure used by VM

hosted apps. Do not install either XenDesktop or the SQL Server database on a domain controller. For more information

on Active Directory, see "Active Directory Consideration" in the XenDesktop 5 product documentation located in the

Citrix eDocs Archive.

Virtual machines or physical computers hosting desktops. These desktops deliver applications to users. You install the

Virtual Desktop Agent on these machines to manage communications and broker connections.

Web Interface. VM hosted apps requires the version of Web Interface provided with it. XenApp farms and VM hosted

apps sites can share the same Web Interface site.

Access to a Citrix license server. A VM hosted apps site can use its own license server or share one with other VM hosted

apps sites and XenApp server farms.

Security Planning for VM Hosted Apps

Secure access and delivery of applications for your VM hosted apps deployment as you would a XenApp server farm. See

XenApp planning and administration topics for information on implementing secure connections to published applications.

See Web Interface topics for information on securing the Web Interface.

Isolate VM hosted apps farms from XenApp server farms:Separate them with f irewalls

Use separate hosting infrastructure and hypervisor pools

Secure the desktops in your VM hosted apps deployment as described in "Security Planning for XenDesktop" in theXenDesktop 5 product documentation located in the Citrix eDocs Archive. 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

Time zone considerations apply to applications that display the time of day

Keep in mind that VM hosted apps does not support thin clients

Planning High Availability Deployments

For information on using XenDesktop infrastructure to increase the fault tolerance of your VM hosted app deploy to

ensure that business-critical VM-hosted applications are always available, see the XenDesktop topic "High Availability

Planning" in the XenDesktop 5 product documentation located in the Citrix eDocs Archive.

Planning Administrator Roles

VM hosted apps allows you to create administrators in any of the five XenDesktop administration roles. For more

information, see the XenDesktop topic "Delegated Administration" in the XenDesktop 5 product documentation located in

the Citrix eDocs Archive. XenDesktop full administrators and assignment administrators can create and edit VM-hosted

applications. Otherwise, these XenDesktop administration roles can perform tasks on your VM hosted apps site as they

would on any other XenDesktop site.


Install and Set Up

May 06, 2015

Note: If you are installing VM hosted apps as a feature of XenDesktop, see "Installing and Setting up XenDesktop 5" in theXenDesktop 5 product documentation in the Citrix eDocs Archive.Download VM hosted apps from MyCitrix.com.

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 Mircosoft

System Center Virtual Machine Manager 2008 with XenDesktop" in the XenDesktop 5 product documentation in the

Citrix eDocs Archive

For information on setting up and using VMWware, see "Using VMWare with XenDesktop" in the XenDesktop 5 product

documentation in the Citrix eDocs Archive

Perform the VM hosted app installation and set-up tasks in this order:1. Install the server-side components of XenDesktop needed for your VM hosted apps deployments.

2. Configure the VM hosted apps site.

3. After you have configured a site you can add more controllers to it, if necessary.

4. To manage your deployment remotely, install Desktop Studio on additional computers.

5. Install the Virtual Desktop Agent on any base images, virtual desktops, and physical desktops that are part of your VM

hosted apps deployment.

Installing and Removing Server Components for VM Hosted Apps

The server components for VM hosted apps are:

XenDesktop Controller. The SDKs are automatically installed when you install the Controller.

Desktop Studio. The SDKs are automatically installed when you install Desktop Studio. Desktop Studio configures the

VM hosted apps site.

Web Interface. VM hosted apps requires the version of Web Interface provided with it.

Desktop Director. This Web-based tool enables level-1 and level-2 IT Support staff to monitor a VM hosted apps

deployment and perform day-to-day maintenance tasks. Installation of Desktop Director is optional.

License Server. A VM hosted apps site can use an existing license server.

Installing the server components requires local administration permissions.

To install server components from the command line, see "XenDesktopServerSetup.exe" in the XenDesktop 5 product

documentation in the Citrix eDocs Archive.

The AutoSelect.exe file performs a wizard-based installation of some or all of these components, allowing you to select

the components you want to install. By default, all components are selected.

When AutoSelect.exe or XenDesktopServerSetup.exe installs the Web Interface:The Web Interface's software prerequisites are install automatically

Session sharing and workspace control are disabled by default

The Web Interface autorun provided with VM hosted apps does not install the software prerequisites or disable session


sharing and workspace control.

To install server components using the installation wizard

1. Run AutoSelect.exe.

2. Select Install XenDesktop.

3. Accept the End User License Agreement.

4. By default, all server components are selected for installation. Clear any components you do not want to install at this

time.

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 f irewall configuration. If the Windows f irewall is detected, the necessary ports can be opened automatically for

you. If another f irewall is detected, you are told which ports you need to open manually.

7. Follow the prompts to complete the installations.

8. If you installed the Desktop Studio, unless you clear Configure XenDesktop after closing on the last page of the

installation wizard, Desktop Studio starts so that you can configure the VM hosted apps site.

If Web Interface is not yet installed, install it before or after configuring the VM hosted apps site.

Repeat these steps to install server components on other servers.

To install Web Interface

1. To install the Web Interface, locate WebInterface.exe f ile in the f iles you downloaded for VM hosted apps, in the

x64/Web Interface folder or the x86/Web Interface folder.

2. Run WebInterface.exe and follow the prompts to complete the installation.

See the Web Interface documentation for information on installing and configuring Web Interface. You can configure Web

Interface so that your VM hosted apps site shares a Web Interface site with one or more XenApp server farms.

To remove server components

To remove the XenDesktop components used by VM hosted apps, use the Windows control panel.

Before removing a Controller from the server, remove it from the VM hosted apps site. For information on removing a

Controller from a site, see "To remove a controller" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.


To configure a VM hosted apps site

May 06, 2015

Use Desktop Studio to configure your VM hosted apps.

Configuring your VM hosted apps site requires:Licensing the site.

Specifying the edition of XenApp or XenDesktop for which you have licenses.

Note: Use the XenDesktop SDK instead of Desktop Studio to configure the license edition for your VM hosted apps site

if you are using VM hosted apps as a feature of XenDesktop, you want to deliver desktops and VM-hosted applications

from the site, and your XenApp edition is different from your XenDesktop edition. Using the SDK, you can specify both a

XenApp edition and a XenDesktop edition.

Setting up the site database.

Important: If you plan to use an external database created manually, not created using Desktop Studio, ensure your

database administrator uses the following collation setting when creating the database: Latin1_General_CI_AS_KS

(where Latin1_General varies depending on the country; for example Japanese_CI_AS_KS). If this collation setting is not

specif ied during database creation, subsequent creation of the XenDesktop service schemas within the database will

fail, and an error similar to "<service>: schema requires a case-insensitive database" appears (where <service> is the name

of the service whose schema is being created).

Providing information about your virtual infrastructure.

If you are using XenServer, Citrix recommends using HTTPS to secure communication between XenDesktop and

XenServer. To use HTTPS you must replace the default SSL certificate installed with XenServer with one from a trusted

certificate authority.

To perform the initial configuration of your VM hosted apps site:

1. Start Desktop Studio if it has not started automatically after installation.

2. Select Application deployment.

3. Follow the prompts to complete the configuration:

Wizard page What to do

Site Enter a name for your VM hosted apps site.

Specify license server information:

To configure a license server not installed on the XenDesktop Controller, specify

the address as name:port, where name can be a DNS, NetBIOS, or IP address.

To configure a license server installed on the XenDesktop Controller, specify the

license f ile location.

If you configured a license server not installed on the XenDesktop Controller,

specify the XenApp or XenDesktop edition for which you have licenses.

Choose whether you want to use the default database or an existing database:

To use the locally installed copy of SQL Express to automatically create the site


database on the controller on which you are working, select Use default

database.

To use an existing database, select Use specif ied database. The server location

must be a DNS, NetBIOS, or IP address, without a port number.

Host Specify the type of virtual infrastructure host (Citrix XenServer, Microsoft, or

VMWare) your VM hosted apps site will connect to, if any.

If you specified a virtual infrastructure host type, specify the address, user name,

and password of the host.

If you specified XenServer as your host type, and High Availability is enabled on

XenServer, you can select servers for High Availability configuration. Citrix

recommends that you select all servers in the pool to allow communication

between XenDesktop and XenServer if the pool master fails.

Specify whether you want to create virtual machines manually or use XenDesktop

infrastructure to create virtual machines.

Enter a name for the connection between the VM hosted apps site and the virtual

infrastructure host.

Resource

This page appears if you are

configuring the site to use

XenDesktop infrastructure to

create virtual machines.

Add storage to use when creating virtual machines.

If both local and shared storage are available on the hosting unit you must select a

single type; you cannot mix them.

For each host :

Enter a name

Specify shared or local

Select the storage location

Specify the network the virtual machines reside on

Wizard page What to do

4. To use Access Gateway, pass-through authentication, or smart card authentication with your VM hosted apps site,

configure XenDesktop to trust XML services by running this Powershell SDK command:

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

After you configure the site, you can add more XenDesktop Controllers. See "To add a controller" in the XenDesktop 5product documentation in the Citrix eDocs Archive.After the initial configuration, you can change licensing and host configuration settings by starting Desktop Studio and

expanding the Desktop Studio > Configuration node.


To replace the default XenServer SSL certificate

Nov 22, 2010

Citrix recommends using HTTPS to secure communication between XenDesktop and XenServer. To use HTTPS you must

replace the default SSL certificate installed with XenServer with one from a trusted certificate authority:

1. Modify /etc/pki/tls/openssl.cnf as follows:

1. Request extensions by uncommenting the following line:

req_extensions = v3_req2. Modify the section for requested sections to read as follows:

[v3_req] basicConstraints = CA:FALSE keyUsage = keyEncipherment extendedKeyUsage = serverAuth

2. Generate a certif icate request: openssl genrsa -out [servername].private 2048 openssl req -new -outform PEM -out

[servername].request -keyform PEM -key [servername].private -days 365 where [servername] is the name of the

XenServer host. This generates a request for a 1 year (365 day) certif icate in the f ile called [servername].request.

3. Have the certif icate request contained in [server name].request signed by a certif icate authority. This can be either a

commercial certif icate authority or an internal corporate certif icate authority such as Microsoft Certif icate Services.

4. After the new certif icate has been signed, move the existing certif icate: mv/etc/xensource/xapi -

ssl.pem/etc/xensource/xapi -ssl.pem_orig

5. Add the new signed certif icate to the XenServer host and tighten the access rights: cat [servername].public

[servername].private > [servername].pem install -m 0400 [servername].pem/etc/xensource/xapi-ssl.pem

6. Edit the f ile /etc/init.d/xapissl, using the line: PEMFILE=“/etc/ssl/certs/[servername].pem”

7. Restart the XenServer communications service by entering the following command: /etc/init.d/xapissl restart

If you are using a private certif icate authority you may need to install your root certif icate on the controller.

1. Locate the root certif icate f ile in Windows Explorer.

2. Right-click the root certif icate f ile and select Install Certif icate. The Certif icate Manager Install Wizard appears.

3. On the Welcome page, click Next.

4. On the Certif icate Store page, select Place all certif icates in the following store.

5. Click Browse.

6. Select Show physical stores.

7. Select Local Computer.

8. Click OK.

9. Follow the instructions in the wizard to complete the install.


Installing and Removing the Virtual Desktop Agent

May 06, 2015

The Virtual Desktop Agent has to be present on the virtual machines (VMs) and physical machines to which your users will

be connecting. It enables the machines to register with controllers and manages the HDX connection between the

machines and the user devices.

If you are using XenDesktop or Provisioning Services to provision VMs, you need to install and configure the Virtual Desktop

Agent only once, but if you are using separate stand-alone virtual or physical machines you must install it on each of the

machines so they can register with the controller to allow user connections.

You can install the Virtual Desktop Agent from a console session or from an RDP session, but installing from an ICA session

is not supported.

To install the Virtual Desktop Agent components from the command line, see XenDesktopVdaSetup.exe in the XenDesktop

5 product documentation in the Citrix eDocs Archive.

The AutoSelect.exe file performs a wizard-based installation of the Virtual Desktop Agent:

1. Run AutoSelect.exe.

2. On the Installation page, select Install Virtual Desktop Agent.

3. Associate this desktop with the VM hosted app site.

4. Configure the agent as follows:

Reconfigure the f irewall. If the Windows f irewall is detected, the necessary ports can be opened automatically for

you. If another f irewall 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 off line f iles,

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 automaticallycreated. The group is called Direct RDP Access Administrators. For further information on using protocols other than ICA,see the Citrix Knowledge Center.VM hosted apps requires desktops and controllers to have synchronized system clocks. This is required by the underlying

Kerberos infrastructure that secures the communication between the machines. You can use normal Windows domain

infrastructure to ensure that the system time on all machines is correctly synchronized.

To add or remove components, use the Windows control panel. Select Citrix Virtual Desktop Agent. You can then select to

add, remove, or reconfigure components, or to remove the Virtual Desktop Agent completely.

The Reconfigure Components option enables you to update the site and port numbers.

To enable users to connect to virtual desktops, you must configure your virtual desktop firewall as follows:


For communication between user devices and virtual desktops:

%Program Files%\Citrix\ICAService\picaSvc.exe requires inbound TCP on port 1494. Because this connection uses a

kernel driver, you may need to configure this setting as a port exception rather than a program exception, depending on

your f irewall software. If you are running Windows Firewall, you must configure this setting as a port exception.

%Program Files%\Citrix\ICAService\CitrixCGPServer.exe requires inbound TCP on port 2598.

Note: Citrix recommends that you do not use TCP ports 1494 and 2598 for anything other than ICA and CGP, to avoid thepossibility of inadvertently leaving administrative interfaces open to attack. Ports 1494 and 2598 are correctly registeredwith the Internet Assigned Number Authority (see http://www.iana.org/).For communication between controllers and virtual desktops:

%Program Files%\Citrix\XenDesktop\WorkstationAgent.exe requires inbound HTTP (http.sys) on the TCP/IP port you

configured at installation time. The default port is 80. Because this connection uses a kernel driver, you may need to

configure this setting as a port exception rather than a program exception, depending on your firewall software. If you are

running Windows Firewall, you must configure this setting as a port exception.

Windows Remote Assistance requires ports TCP/135, TCP/3389, and DCOM. On Windows Vista and Windows 7 desktopsyou can configure these exceptions by enabling the built-in Remote Assistance exception. On Windows XP you must setadditional exceptions:1. Enable the Remote Assistance exception.

2. Add and enable the TCP 135 exception.

3. Add and enable the "%systemroot%\PCHEALTH\HELPCTR\Binaries\helpsvc.exe" exception.

4. See http://support.microsoft.com/kb/555179.

Windows Remote Management requires the following ports:TCP/80 for Windows Remote Management 1.1

TCP/5985 for Windows Remote Management 2.0

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 f ile from the XenDesktop installation media to that share. Note

that you must set permissions on that share to allow read access to the .msi f ile.

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 f ile, using the following guidelines:

Enter the full Universal Naming Convention (UNC) path of the .msi f ile. For example, \\x-desktop-

svr6\SoftwareInstall\XDSAgent.ms

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

http://www.iana.org/



information, see How to Use Group Policy Objects with XenDesktop.



To use Windows XP virtual desktops with Single Sign-on

Aug 11, 2010

If you use Single Sign-on (formerly Password Manager) with Windows XP virtual desktops, you must carry out the followingprocedure to chain the GINA (Graphical Identif ication and Authentication) dynamic link libraries, otherwise users cannot logon successfully through XenDesktop. You must do this after both Single Sign-on and the Virtual Desktop Agent have beeninstalled.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 atyour own risk. Make sure you back up the registry before you edit it.1. Inspect the following Windows XP registry entries and make a note of their current values:

HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GinaDLL

HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\CtxGinaDLL

HKLM\Software\Citrix\Metaframe Password Manager\Shell\OrigGinaDLL

2. Modify the registry entries so that the GINAs are called in the correct order:

HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GinaDLL

This should point to the XenDesktop GINA; for example, C:\Program Files\Citrix\ICAService\picaGina.dll

HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\CtxGinaDLL

This should point to the Password Manager GINA; for example, C:\Program Files\Citrix\MetaFrame Password

Manager\SSOGina\SSOGina.dll

HKLM\Software\Citrix\Metaframe Password Manager\Shell\OrigGinaDLL

This should point to MSGINA.dll, or NOGINAPREVIOUSLYINSTALLED

3. Restart the virtual desktop.


Manage

May 16, 2015

To manage your VM hosted apps site, use XenDesktop infrastructure to:Create and manage application desktop groups and the applications they host.

Manage your XenDesktop Controller environment. See "Managing Your Controller Environment" in the XenDesktop 5

product documentation in the Citrix eDocs Archive for information on controller discovery, adding controllers, removing

controllers, moving controllers between sites, and configuring the Secure Sockets Layer.

Configure hosts and connections. See "Configuring Hosts and Connections" in the XenDesktop 5 product


Enable users to use smart cards. See "Using Smart Cards with XenDesktop" in the XenDesktop 5 product documentation

in the Citrix eDocs Archive. VM hosted apps does not support thin clients.

Use Citrix policies to control users access or session environment. See "Working with XenDesktop Policies" and "Policy

Settings Reference" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.

Monitor your VM hosted apps deployment. See "Monitoring XenDesktop 5" in the XenDesktop 5 product


Most VM hosted apps management tasks are perform using Desktop Studio or the XenDesktop SDK. To use the SDK, see

"About the XenDesktop SDK" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.

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. For information about machine types, creating

catalogs, and managing catalogs, see in "Creating and Provisioning Desktops" in the XenDesktop 5 product documentation

in the Citrix eDocs Archive.

VM hosted apps supports both types of desktop groups available in XenDesktop 5: private and shared. For a description of

desktop groups, see "About Desktop Groups" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.

When you create a desktop group for VM hosted apps, you specify that it is an application desktop group.

The characteristics of a desktop depend on its machine type and desktop group type:

Machine t ype and deskt op Machine t ype and deskt op group t ypegroup t ype T hese deskt ops...T hese deskt ops...

Pooled-random machines are used to create

shared desktop groups

Are virtual machines created by XenDesktop when the catalog

containing them is created

Discard the user's changes when the user logs off

Can be shut down and started by the XenDesktop Controller

Pooled-static machines are used to create

private desktop groups



Discard the user's changes when the user logs off



Dedicated machines are used to create private

desktop groups



Retain the user's changes when the user logs off


Existing machines are used to create private

desktop groups

Are virtual machines that already exist when the catalog


Are not used with Provisioning services

Can be configured to retain or discard the user's changes when

the user logs off


Physical machines are used to create private

desktop groups

Enable you to use the XenDesktop Controller to manage

dedicated blade PCs in the data center


the user logs off

Cannot be shut down or started by the XenDesktop Controller

Streamed machines are used to create shared

desktop groups

Are used with Provisioning services


the user logs off

Machine t ype and deskt op Machine t ype and deskt op group t ypegroup t ype T hese deskt ops...T hese deskt ops...

When you create application desktop groups:You can create desktop groups from multiple catalogs with the same machine type

You cannot create mixed desktop groups from catalogs with multiple machine types

You cannot use a machine in more than one desktop group

You can only create a desktop group if at least one machine remains unused in the catalog you select

See these subjects in the XenDesktop 5 product documentation in the Citrix eDocs Archive for desktop management tasksyou can perform on application desktops:

"To enable or disable maintenance mode".

"To f ind desktops, sessions, and desktop groups". You can f ind applications by selecting the Applications node in

Desktop Studio and searching for the application name.

"To power manage machines".

"To shut down and restart desktops".

"To reallocate desktops". You can reallocate machines in a desktop group and reallocate individual desktops, but not

change the number of desktops allocated to a users.

"To import and export user data".

"To remove desktops from desktop groups".

"To delete desktops from catalogs".

To delete an application desktop group, first remove all applications from the desktop group. See Working With

Applications.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/ps-vmha-wrapper/ps-vmha-manage-wrapper/ps-vmha-apps-overview.html


To create an application desktop group

Nov 22, 2010

VM-hosted applications are hosted by desktops in application desktop groups.

1. In Desktop Studio, select the Assignments node in the left pane and click Create Application Desktop Group. Use the

Create Desktop Group wizard to create the desktop group.

2. On the Catalog page, select a catalog for this desktop group, and enter the number of machines the group will consume

from the catalog.

Tip: If machine administrators include the total number of machines in a catalog's description, this appears on the

Catalog page. Assignment administrators can use the number in conjunction with their selections in the wizard to ensure

sufficient machines are available for the desktop group.

The Users page appears if the desktop group is based on pooled - static, existing, or physical machines and these

machines have not already been allocated accounts.

3. If you want to give users access to applications hosted on the desktops in a private desktop group, give them access to

the desktop group. On the Users page, add the users or user groups that can access the desktops, and enter the number

of desktops available to each user.

You can select user groups by browsing or entering a list of Active Directory users and groups each separated by a

semicolon. You can import user data from a file after you create the group.

4. On the Machine allocation page, confirm the mapping of machines to users for any machines that were allocated when

the catalog was created.

5. On the Delegation page, select the XenDesktop administrators who will manage this desktop group.

6. On the Summary page, check all details, and enter a name for the desktop group.


Working With Applications

May 08 , 2015

When you create an application, you assign desktop groups to deliver the application to users. All desktops in a desktop

group publish the same application or set of applications.

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

TWIDisableSessionSharing

Applications that require different values for these settings cannot share sessions.

To help determine if applications are compatible with each other for session sharing, use the Get-

BrokerSessionSharingIncompatibleApplication cmdlet in the XenDesktop SDK.

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. The list of file types

can be updated by importing file types from desktops in the desktop group assigned to an application while you are

configuring content redirection for the application. A desktop must be in maintenance mode to update file types.

When you create or modify an application using Desktop Studio, the list of file types you see is filtered to include only

those file types likely to be used with the application. To associate other file types with the application, use the

XenDesktop SDK.

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:

WizardWizard

pagepage

What t o doWhat t o do

Desktop

groups

Select existing desktop groups or create new desktop groups to host the application.

Location Specify the application executable file.

Optional: Specify the command-line and working directory to locate the application.

Users Specify users that can access the application.

Shortcut Specify how shortcuts to the application appears to users:

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.

Advanced Set advanced options or accept the defaults:

Advanced access control.

To allow connections through Citrix Access Gateway only, select Allow connections made through

Access Gateway.

To allow a subset of those Access Gateway connections: Select Any connection that meets any

of the following f ilters, define the Access Gateway farm, and specify the SmartAccess strings that

define the allowed user access scenarios for the desktop group.

SmartAccess is a feature of Access Gateway. For more information, see the Access Gateway

documentation.


Appearance. Specify the window size of the application (full screen, pixel size, or percent of display)

and color depth.

Content redirection. Select the file types you want to associate with the application to redirect

content from the user device.

Note: If the file types you want are not displayed, update the file types from an available desktop

that is in maintenance mode.

Multimedia. Choose whether to enable legacy audio for the application.

Resources. Set the application's CPU priority level and specify whether the application waits for

printer creation on start-up.

Security. Specify whether the user device is required to use a secure ICA connection. Selecting this

option means the user device must connect to the application with a minimum encryption level of

128-bit RC-5 encryption. If the user device does not use this level of encryption, the application fails

to launch.

Name Specify the name displayed to users for the application.

Optional: Type a description or tip displayed to users.

Set the application's availability and visibility to users.

WizardWizard

pagepage

What t o doWhat t o do

Modifications made to an application might not take effect for users connected to the application until the users have

logged off their sessions.

To modify any application properties

You can modify any of an application's properties using a wizard similar to the one used to create applications.

1. In Desktop Studio, select the Applications node in the left pane.

2. Select the application you want to modify and click Application Properties.

3. Use the Application Properties wizard to modify the application. Click the name of the wizard page in the right pane of

the wizard to go to that page.

To add or remove desktop groups hosting the application


2. Select the application you want to modify.

3. Add or remove desktop groups:

To add or remove desktop groups, click Edit Desktop Groups.

To remove desktop groups, select the desktop group you no longer want to host the application and click Remove.

Clicking Remove does not delete the desktop group or alter any of its other properties.

To add or remove users who can access the application




3. Add or remove users:

To add users or remove, click Edit Users.

To remove users, select the users you no longer want to have access to the application and click Remove.

To change the application name displayed to users



3. From the right-click menu, choose Rename and type the name you want displayed to users for the application.

To remove applications from a desktop group


2. Select the desktop group you want to remove applications from.

3. Select the Applications tab.From the right-click menu, choose Rename and type the name you want displayed to users

for the application.

4. Select the applications you want to remove.

5. Click Remove Assignment from....

Use folders and tags to organize applications within Desktop Studio

To use folders

1. To create a folder:

1. Select the Applications node or expand the node and select a folder within the node.

2. Click Create Folder.

2. To manage the folders and the applications:

Select the folder or application and use the right-click menu.

To copy a folder or application, drag and drop it.

To move a folder or application, hold the Shift key while dragging and dropping it.

To use tags

In VM hosted apps, tags let you categorize applications in Desktop Studio.Note: Tags used with VM hosted apps cannot be used to restrict access to machines or applications.To add tags to an application or edit tags added to an application:1. In Desktop Studio, select the Applications node in the left pane.

2. Select an application and click Edit tags.


To manage applications sessions

Nov 19, 2010

When a user logs on to a VM-hosted application, the user device links to the Virtual Desktop Agent on the desktop and

establishes a session. When carrying out maintenance or to assist users, you can control sessions in a number of ways. You

can:

Log users off sessions

Disconnect sessions

Send messages to users

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 thatunused sessions are automatically processed. This frees up desktops and saves power. For example, XenDesktop canautomatically log off any disconnected session after 10 minutes.1. In Desktop Studio, f ind the session you want to log off or disconnect:

Select the Applications node. Select the application for the session you want to log off ot 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, f ind the users you want to send a message to:

Select the Applications node. Select the application for the session you want to log off ot disconnect. Select the

Sessions tab. Select the session for the user you want to send a message to.

Use Search to locate the session. Select a session, desktop, or user.

2. Click Send message.

3. Compose your message and click OK.


Customize

May 06, 2015

After completing the initial setup tasks, you can customize and optimize your VM hosted apps deployment:

Create additional administrators for the site, if necessary. See "Delegating Administration Tasks" in the XenDesktop 5

product documentation in the Citrix eDocs Archive. 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 "Working with XenDesktop Policies"

in the XenDesktop 5 product documentation in the Citrix eDocs Archive 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 product documentation in the Citrix eDocs Archive.

Configure time zone settings to allow users to see their local time when using applications that display a time of day.

See "Configuring Time Zone Settings" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.

Configure connection timers to provide appropriate durations for uninterrupted connections, idle sessions, and

disconnected sessions. See "Configuring Connection Timers" in the XenDesktop 5 product documentation in the Citrix

eDocs Archive.

Configure workspace control to enable users to roam between different user devices. See "Workspace Control in

XenDesktop" in the XenDesktop 5 product documentation in the Citrix eDocs Archive.

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. The level of support

provided depends on the client installed on the user device; see the relevant client documentation for further details.

Isochronous features in USB devices such as webcams, microphones, speakers, and headsets are supported in typical low

latency/high speed LAN environments. This allows these devices to interact with packages such as Microsoft Office

Communicator and Skype.

The following types of device are supported directly in a VM hosted apps session and do not require special configuration:

Keyboards

Mice

Smart cards

Note: Specialist keyboards and mice (for example, Bloomberg keyboards, and 3D mice) can be configured to use USBsupport. For more information, see http://support.citrix.com/article/ctx119722 in the Citrix Knowledge Center.By default, certain types of USB devices are not supported for remoting through VM hosted apps. For example, a user may

have a network interface card attached to the system board by internal USB. Remoting this would not be appropriate. The

following types of USB device are not supported by default for use in a VM hosted apps session:

Bluetooth dongles



USB network interface cards

USB hubs

USB graphics adaptors

USB support allows hosted applications access to USB devices that are connected to the user device. In environments

where security separation between client and hosted application is needed, users should connect only appropriate USB

devices. You can also set policies at the desktop group and user device that restrict the types of USB devices that will be

made available to the hosted application.

For information on all USB devices supported, see http://support.citrix.com/article/ctx119861 in the Citrix Knowledge

Center.

Double-hop USB is not supported. That is, if a user connects to a VM hosted apps session for a hosted desktop, the VM

hosted apps session does not have USB support.

To configure USB support for desktops

To configure USB support for the desktops you are using to deliver applications:Enable the USB policy rule, which is in the USB Devices Policy Settings section of the ICA Policy Settings.

Enable USB support when you install the online plug-in on user devices.

If necessary, update the range of USB devices supported. To do this:

Edit the plug-in registry.

Edit the administrator override rules in the Virtual Desktop Agent registry on the computers hosting the desktops. The

range specif ied in the Virtual Desktop Agent must correspond exactly to the range specif ied on the client; if it does

not, then only the devices allowed in both ranges are allowed.

The product default rules are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\GenericUSB Type=String

Name="DeviceRules"

Do not edit the product default rules.

The administrator override rules are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\PortICA\GenericUSB

Type=String Name="DeviceRules"

For details of the rules and their syntax, see http://support.citrix.com/article/ctx119722/ in the Citrix Knowledge Center.

ADM files are included on the installation media to allow you to make changes to the client and the Virtual Desktop

Agent through Active Directory Group Policy. The file for the client is:

dvd root \os\lang\Support\Configuration\icaclient_usb.adm

and the file for the Virtual Desktop Agent is:

dvd root \os\lang\Support\Configuration\vda_usb.adm

To configure USB support for applications

In addition to configuring USB support for the desktop, you must also configure USB support for the application being

delivered by the desktop.

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


http://support.citrix.com/article/ctx119722/


at your own risk. Be sure to back up the registry before you edit it.Set the following registry keys on the user device:

Name: HKEY_CURRENT_USER\Software\Citrix\ICA Client\USB\published application name\NewDevices

published application name is the Desktop Group name in the VM Hosted Apps environment. Create this registry entry

for each Desktop Group that supports USB devices.

Type: REG_SZ

Value: Always or Never

Setting this key to "Always" enables USB support for USB devices that are connected the user device while the

application session is in progress.

Name: HKEY_CURRENT_USER\Software\Citrix\ICA Client\USB\published application name\ExistingDevices

Type: REG_SZ

Value: Always or Never

Setting this key to "Always" enables USB support for USB devices that are present on the user device when the

application session begins.

To update the range of USB devices supported

To change the default range of USB devices, you must update the device rules on both the client and the Virtual DesktopAgent:

Edit the client registry (or the .ini f iles 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 client through Active Directory Group Policy: dvd root \os\lang\Support\Configuration\icaclient_usb.adm.

Edit the administrator override rules in the Virtual Desktop Agent registry on the computer(s) hosting the desktops.

Information about how to do this is included in the rest of this section.

Device rules are enforced on both the client and the Virtual Desktop Agent, so you must make changes on both sides

otherwise devices may not be allowed through.

An ADM file is included on the installation media to allow you to make changes to the Virtual Desktop Agent through

Active Directory Group Policy: dvd root \os\lang\Support\Configuration\vda_usb.adm.

The product default rules are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\GenericUSB Type=String

Name="DeviceRules"

The default policy configuration is as follows:

DENY: class=02 # Communications and CDC-Control DENY: class=09 # Hub devices DENY: class=0a # CDC-Data DENY: class=0b # Smartcard DENY: class=e0 # Wireless controller ALLOW: # Otherwise allow everything elseDo not edit the product default rules. The recommended way to change them is to use the GPO overrides described below,

because these are evaluated before the default rules.

The administrator override rules are stored in:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\PortICA\GenericUSB Type=String Name="DeviceRules"


When you are creating new policy rules, refer to the USB Class Codes, available from the USB Web site at

http://www.usb.org/.

Policy rules take the format {Allow:|Deny:} followed by a set of tag=value expressions separated by white space. The

following tags are supported:

T agT ag Descript ionDescript ion

VID Vendor ID from the device descriptor

PID Product ID from the device descriptor

REL Release ID from the device descriptor

Class Class from either the device descriptor or an interface descriptor

SubClass Subclass from either the device descriptor or an interface descriptor

Prot Protocol from either the device descriptor or an interface descriptor

When creating new policy rules, be aware of the following:Rules are case-insensitive.

Rules may have an optional comment at the end, introduced by #. A delimiter is not required and the comment is ignored

for matching purposes.

Blank and pure comment lines are ignored.

White space is used as a separator, but cannot appear in the middle of a number or identif ier. For example, Deny: Class =

08 SubClass=05 is a valid rule; Deny: Class=0 Sub Class=05 is not.

Tags must use the matching operator =. For example, VID=1230.

Each rule must start on a new line or form part of a semicolon-separated list.

Important: If you are using the Administrative (ADM) template, you must create rules on a single line, as a semicolon-

separated list.

This example shows a set of administrator-defined USB policy rules:

Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive Deny: Class=08 SubClass=05 # Mass Storage

Support for USB Mass Storage Devices

For mass storage devices only, remote access is also available through client drive mapping, where the drives on the user

device are automatically mapped to drive letters on the virtual desktop when users log on. The drives are displayed as

shared folders with mapped drive letters. To configure client drive mapping, use the Client removable drives setting in the File

Redirection Policy Settings section of the ICA Policy Settings.

The main differences between the two types of remoting policy are:

http://www.usb.org/


Feat ureFeat ure Client driveClient drivemappingmapping

USB ruleUSB rule

Enabled by default Yes No

Read-only access configurable Yes No

Safe to remove device during asession

No Yes, provided users follow operating system recommendationsfor safe removal

If both client drive mapping and the USB rule are enabled, then if a mass storage device is inserted— before

a session starts, it will be redirected using client drive mapping first, before being considered for redirection through USB

support. If it is inserted— after

a session has started, it will be considered for redirection using USB support before 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.


XenApp Connector for Configuration Manager 2007R2

Jun 10 , 2010

XenApp Connector for System Center Configuration Manager 2007 R2 enables Microsoft System Center Configuration

Manager 2007 R2, which helps you deploy and publish applications to XenApp servers. XenApp Connector requires XenApp

server farms running XenApp 6 for Windows 2008 R2.

For XenApp servers managed by the Power and Capacity Management feature, 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.

XenApp Connector has two components:XenApp Data Connector

Configuration Manager Console Extension

XenApp Data Connector is the bridge between the XenApp farm and Configuration Manager. It manages XenApp server

collections 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 6

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.


Systems Requirements for XenApp Connector forConfiguration Manager 2007 R2

Apr 12, 2013

XenApp Connector for Configuration Manager 2007 R2 supports XenApp 6 for Windows Server 2008 R2, Platinum and

Enterprise editions.

The XenApp Connector components, XenApp Data Connector and Configuration Manager Console Extension, can be

installed on a single server or on different servers within your farm (multi-farm is not supported).

Supported Windows operating systems:Microsoft Windows Server 2008 (32-bit and 64-bit)


Requirements:Windows PowerShell 2.0

Task Scheduler 2.0

XenApp Data Connector requires connectivity to:Computer running XenApp 6 Powershell SDK

Configuration Manager site server

Power and Capacity Management Concentrator

Supported Windows operating systems:Microsoft Windows Server 2008 (32-bit and 64-bit)


Configuration Manager Console Extension requires Microsoft System Center Configuration Manager 2007 R2.


Install and Set Up XenApp Connector forConfiguration Manager 2007 R2

Mar 03, 2011

Before you install XenApp Connector for Configuration Manager 2007 R2:Identify the computers in your XenApp Connector installation:

Decide where to install XenApp Data Connector.

Decide where to install Configuration Manager Console Extension. Configuration Manager Console Extension is

installed on the same server as Microsoft System Center Configuration Manager 2007 R2 console.

Identify the Configuration Manager site server. Ensure that the SMS Provider for the Configuration Manager site is

installed on this computer.

Identify the computer you plan to use as your XenApp Powershell host. This is the computer running XenApp6

PowerShell SDK that the XenApp Data Connector uses to manage XenApp servers and gather farm data. Ensure this

computer is not managed by Power and Capacity Management.

Identify a server running the Power and Capacity Management Concentrator that XenApp Data Connector will use

to manage power states and load consolidation.

Install PowerShell and enable PowerShell remoting on the servers you plan to use for the following:

XenApp Data Connector

XenApp Powershell host


Power and Capacity Management Concentrator

You can enable PowerShell remoting through the cmdlets Enable-PSRemoting and Set-ExecutionPolicy with

RemoteSigned in the 32- and 64-bit PowerShell windows.

Enable XenApp Data Connector to communicate with these servers by opening default Windows Remote Management

port 5985 on the f irewalls or routers:

XenApp PowerShell host

Server running the Power and Capacity Management Concentrator


Ensure that you have the following sets of credentials, which permit XenApp Connector to write data to Configuration

Manager and XenApp farms:

XenApp administrator credentials

Power and Capacity Management administrator credentials

Credentials required for Configuration Manager services and databases

Credentials for an account that can initiate remote Powershell connections to the XenApp server, the Power and

Capacity Management Concentrator, and the Configuration Manager site server

1. From My Citrix, download the installer package for XenApp Connector for Configuration Manager 2007 R2.

2. On the server on which you want to install XenApp Connector, if Configuration Manager is running, close it.

3. On the server on which you want to install XenApp Connector, run XAConfigMgr07R2.exe and follow the instructions in

the installation wizard.

4. After installation, the installation wizard invokes the configuration wizard. Depending on which components you are

installing, the configuration wizard asks for the following information:


Fully qualif ied domain names for the XenApp PowerShell host, the server running the Power and Capacity

Management Concentrator, and the Configuration Manager site server

Site code of the Configuration Manager site

Credentials that permit XenApp Connector to write data to Configuration Manager and XenApp farms

Advertisement processing interval, which is how often XenApp Connector checks the Configuration Manager

database for new advertisements targeted at the XenApp farm

XenApp farm sync interval, which is how often XenApp Connector updates the Configuration Manager database with

new, changed, or removed XenApp farm servers

XenApp publication interval, which is how often XenApp Connector checks the Configuration Manager database for

new or updated publication information

XenApp power-on interval, which is how long in advance off-line servers are powered on to receive software updates

Advertising wait settings, such as the number of days an advertisement waits before logging off connected users and

the number of minutes after a maintenance notif ication message is sent until users are forced to log off

After installation, if you choose not to run the configuration wizard, you can do so later by running ConfigWizard.exe.


Enabling and Disabling Power and CapacityManagement with XenApp Connector forConfiguration Manager 2007 R2

Jun 10 , 2010

XenApp Connector for Configuration Manager 2007 R2 uses the XenApp Power and Capacity Management feature tomanage the power states and load consolidation of XenApp servers when sending Configuration Manager advertisementsand installing applications. This enables XenApp Connector to install applications on servers managed by Power andCapacity Management with minimal disruption to user sessions.To allow Power and Capacity Management to manage power states and load consolidation of XenApp servers, XenAppConnector changes the servers' power controller preference and power control mode:

If no advertisements are pending for a XenApp server, the server's power controller preference remains at 1, the default

ranking for servers managed by Power and Capacity Management.

When you designate an online XenApp server to receive an advertisement, XenApp Connector:

Changes the power controller preference to 5

Sets the server state is to Maintenance just before the application is installed

Changes the power controller preference changes to 1 and enables users to log in, after advertisement processing

completes

When you designate an off line XenApp server to receive an advertisement, XenApp Connector:

Changes the power controller preference to 6

Sets the server state to Maintenance and the server control mode to Unmanaged for the duration of the

maintenance window or the processing of all pending advertisements, whichever occurs f irst

Changes the power controller preference changes to 1, after advertisement processing completes or the

maintenance window closes

The XenApp power-on interval, which is set when XenApp Connector is configured, determines how long in advance of

processing advertisements offline servers are powered on.

XenApp Connector uses Power and Capacity Management to manage the installation of installed applications only and

does not affect the deployment of Microsoft Application Virtualization (App-V) sequences.

Citrix recommends you document your current XenApp Power and Capacity Management server configuration before

modifying it for XenApp Connector.

To enable XenApp Connector to use Power and Capacity Management to manage XenApp server power states and loadconsolidation, 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 1.

To disable XenApp Connector from using Power and Capacity Management to manage XenApp server power states and

load consolidation, from the Power and Capacity Management console, set the XenApp server's power controller

preference to a value other than 1, 5, or 6.


Uninstalling XenApp Connector for ConfigurationManager 2007 R2

May 24 , 2010

Uninstall the components of XenApp Connector for Configuration Manager 2007 R2 through the Control Panel.

When XenApp Data Connector is uninstalled, all files and folders created when it installed on the server are removed.

When the Configuration Manager Console Extension is uninstalled, these items are removed from the ConfigurationManager console:

XenApp Publications folder in Software Distribution

XenApp Publication Container in Packages

All folders named Programs for XenApp in the Programs folder in each package container

Refresh the Configuration Manager console to see the results of the uninstall.

When you uninstall XenApp Connector, some items are not removed:Log f iles are not removed.

Items are not removed from the Configuration Manager database. When you reinstall XenApp Connector, items that

were visible in the Configuration Manager console are visible again.


Deploying Applications to XenApp servers

Jun 14 , 2010

XenApp Connector for Configuration Manager 2007 R2 uses the same packages and programs to deploy applications toXenApp servers that Microsoft System Center Configuration Manager uses to distribute software to ConfigurationManager client computers. You can use XenApp Connector to install applications on XenApp servers and deploy MicrosoftApplication Virtualization (App-V) sequences to XenApp servers. After deploying an application or App-V sequence toXenApp servers, use XenApp Connector to publish it.To deploy an App-V sequence to XenApp servers, use the Configuration Manager App-V deployment procedure for terminal

servers.

To deploy an application to XenApp servers, use Configuration Manager to create a software distribution package andprogram 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. This program for XenApp enables you to deploy the application in a way that manages XenApp user

connections so that the application is installed without disrupting user sessions.

For Configuration Manager to manage a XenApp server, send it advertisements, and included 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.

3. Enter the name, installer program, and any comments for the program for XenApp, and click OK.

This creates a program for XenApp for the application you want to deploy. You can automatically access the publicationwizard now or configure the publication of the application later.

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

3. Select the collection of XenApp servers or worker groups on which you want to install the application.

4. To ensure users are not connected to the server during the installation schedule the advertisement.

1. Specify multiple mandatory assignments, one for each installation attempt. Create at least two mandatory

assignment 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 notif ies users and logs them off . You set the timeout period when you configure the

XenApp Connector. To ensure that the last mandatory assignment logs users off and installs the application, ensure the

period between the f irst 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 managetheir power states and load consolidation, XenApp Connector changes the servers' power controller preference to drainuser connections from targeted servers that have not processed the advertisement.


To publish applications with XenApp Connector forConfiguration Manager 2007 R2

Jun 15, 2010

Publish XenApp hosted applications from the Microsoft System Center Configuration Manager 2007 R2 console throughthe XenApp Connector for Configuration Manager 2007 R2.Publishing XenApp hosted applications from the Configuration Manager console is similar to publishing XenApp hosted

applications from the Citrix Delivery Services Console, but instead of publishing to servers, you publish to a collection or

package. The publishing wizard that XenApp Connector provides within the Configuration Manager console also enables

you to specify the published application's type and how it appears to users, which users can access it, and its publication

schedule.

For Configuration Manager to manage a XenApp server, send it advertisements, and included it in publications, its

information must be included in the Configuration Manager database.

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 XenApp Application Publishing.

2. To 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.

Note: File type association is not supported for App-V sequences.

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 may not already be installed on all servers, specify a package as the target.

When you specify a package as the target, only after servers have processed the package advertisement and the

application program do they give users access to the application. This ensures that users only access servers where

the application is already installed.


Maintaining Log Files

Jun 29, 2010

Because log files grow over time, manually process and delete them, unless where otherwise noted. View log files with a

text editor that maintains formatting, such as WordPad.

XenApp Data Connector log f iles are created and appended in the "log" folder in the install directory.

F ileFile Cont ent sCont ent s

Connector Distribution output of the "XenApp Program and Package Service” task

Connector Publish output of the “XenApp Publication Service” task

XASSCMSync output of the “XenApp and ConfigMgr Synchronization Service” task

Configuration Manager Console Extension log f iles 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

Install log files are created in the user's %temp% folder.

Important: Windows Server 2008 R2 deletes a session's temporary directory when the server restarts. To preserve the installlog f iles, either copy the logs to a safe place before the server restarts or change your local computer policy (beforeinstallation) to prevent deletion of the temporary directories.


CitrixMsi-XAConfigMgrx64-(date & time) (64-bit) MSI information

CitrixMsi-XAConfigMgrx32-(date & time) (32-bit) MSI information

Citrix-XAConfigMgrSetup-(date & time) setup user interface information

Setup (date & time) setup user interface information


XenApp Printing Optimizations

Aug 09, 2013

The XenApp Printing Optimizations improves printing speed, reduces bandwidth required for printing, and improves the user

experience when printing to redirected client printers.

XenApp Printing Optimizations:Adds settings to the Universal Printing Citrix policy setting that control:

Enhanced Metafile Format (EMF) processing mode

Image and font caching, limits and defaults for print quality and image compression, and users' ability to modify these

settings

Adds options to the Session printers Citrix policy setting that control default printer settings for session printer

Adds options to the Printing driver mapping and compatibility Citrix policy setting that control default printer settings for

mapped client printer drivers

Adds dynamic printer discovery to automatically reenumerate and update XenApp session printers after roaming to a

different location so that relaunching of XenApp sessions is no longer necessary. [#226929]

Server:XenApp 6 for Windows Server 2008 R2

User devices:Citrix online plug-in 12.1 for Windows

Windows 7 (Home Premium, Professional, Enterprise, and Ultimate editions), 32-bit and 64-bit editions

Windows Vista (Home Premium, Business, Enterprise, and Ultimate editions), 32-bit and 64-bit editions

Windows XP Professional, 32-bit and 64-bit editions

Install the XenApp Printing Optimizations as local host or using a remote access method that does not require RemoteDesktop Services, such as virtual network computing.1. Go to the download page for XenApp Printing Optimizations and log into your Citrix account. On the XenApp Printing

Optimizations page, next to XenApp Printing Optimization, click Download and download XenAppGPM.zip.

XenAppGPM.zip contains XenAppGPMX64.msi and XenAppGPMX86.msi, which install an updated version of the Citrix

XenApp Group Policy Management Experience, allowing you to view and edit the policy setting added by the XenApp

Printing Optimizations.

2. Copy the f ile to a shared folder on the network and extract the compressed f ile.

3. Save XenAppGPMX64.msi on the XenApp server on which you want to install the XenApp printing Optimizations.

4. Go to the XenApp support pages and install the latest hotfix rollup pack. This installs the XenApp Printing Optimizations

features.

To view and edit updated printing policies using another server:

Install XenAppGPMX64.msi on 64-bit servers.

Install XenAppGPMX86.msi on 32-bit servers.

https://www.citrix.com/downloads/xenapp/components/xenapp-printing-optimizations.html

http://support.citrix.com/product/xa/v6.0_2008r2/hotfix/general/


To configure the XenApp Printing Optimizations Universal Printing Citrix policy setting, use these settings:

Universal printing EMF processing mode. Controls whether to inject the EMF spool f ile into the spooler on the user device

or reprocess the EMF records on the client. By default, EMF records are spooled directly to the printer. Spooling directly

to the printer allows the spooler to process the EMF records without prompting the user for additional information,

minimizing the occurrence of illegible output.

Universal printing print quality limit. Specif ies the maximum dots per inch (dpi) available for generating printed output in

the session. By default, no limit is specif ied.

Universal printing image compression limit. Defines the maximum quality and the minimum compression level available for

images printed with the Universal printer driver. By default, the image compression limit is set to Best Quality (lossless

compression). If No Compression is selected, compression is disabled for EMF printing only. Compression is not disabled

for XPS printing.

Universal printing optimization defaults. Specif ies default settings for the Universal Printer when it is created for a

session:

Desired image quality. Controls the level of image compression. By default, Standard quality is selected.

Enable heavyweight compression. Enables or disables reducing bandwidth beyond the compression level set by Desired

image quality, without losing image quality. By default, heavyweight compression is disabled.

Allow caching of embedded images. Allows or prevents embedded images to be cached. By default, image caching is

allowed.

Allow caching of embedded fonts. Allows or prevents embedded fonts to be cached. By default, font caching is

allowed.

Allow non-administrators to modify these settings. Allows or prevents non-administrative users from modifying any of

these options through the printer driver's printing preferences. By default, users cannot modify these options.

These options are supported for EMF printing. For XPS printing, only the Desired image quality option is supported.

When Universal printing image compression limit and Universal printing optimization defaults are both used:If the compression level in the Universal printing image compression limit setting is lower than the level defined in

Universal printing optimization defaults setting, images are compressed at the level defined in the Universal printing image

compression limits setting.

If the Universal printing image compression limit setting is set to No Compression, the Universal printing optimization

defaults setting's Desired image quality and Enable heavyweight compression options have no effect in the policy.

Use the Citrix policy setting Session printers to override printer's default settings at the beginning of each session. This

setting overrides retained printer settings the user set during a previous session.

You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If you specify a

printing option that the printer does not support, that option has no effect.

1. On the Session printers settings page, select the name of the printer for which you want to modify the settings.

2. Click Settings.


If you have added a client printer driver to the list of mapped drivers, you can modify the printing settings for the driver. This

setting overrides retained printer settings the user set during a previous session.

You can set print quality, orientation, color, duplex, scale, copy count, TrueType option, and paper size. If you specify a


printing option that the printer driver does not support, that option has no effect.

1. On the Printing driver mapping and compatibility settings page, select the name of the printer for which you want to

modify the settings.

2. Click Settings.


Users cannot change the paper size of the Generic Citrix Universal Printer. However, you can set a default paper size for

the server by editing the registry; see article CTX113148 in the Citrix Knowledge Center. [#247747]

[#238211]


XenApp 6 Security Standards and DeploymentScenarios

May 07, 2015

Citrix products offer the security specialist a wide range of features for securing a XenApp system according to officially

recognized standards.

Security standards as they apply to Citrix XenApp 6.0 for Microsoft Windows Server 2008 R2 are discussed here. These

topics provide an overview of the standards that apply to XenApp deployments and describe the issues involved in securing

communications across a set of sample XenApp deployments. For more information about the details of the individual

security features, refer to the relevant product or component documentation.

When deploying XenApp within large organizations, particularly in government environments, security standards are an

important consideration. For example, many government bodies in the United States and elsewhere specify a preference or

requirement for applications to be compliant with FIPS 140. These topics address common issues related to such

environments.

These topics are designed for security specialists, systems integrators, and consultants, particularly those working with

government organizations worldwide.


Security Considerations in a XenApp Deployment

May 07, 2015

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 plugin software running on the user’s client device. When the user types on

the keyboard or moves and clicks the mouse, the plugin software sends the data generated for processing by the

application running on the server.

ICA requires minimal client workstation capabilities and includes error detection and recovery, encryption, and data

compression.

A server farm is a collection of XenApp servers that you can manage (from the 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. The design of server farms

has to balance the goal of providing users with the fastest possible application access with that of achieving the required

degree of centralized administration and network security.

Note that in XenApp deployments that include the Web Interface, communication between the server running the Web

Interface and client devices running Web browsers (and plugin software) takes place using HTTP.

In a XenApp deployment, administrators can configure encryption using either of the following:

SSL Relay, a component that is integrated into XenApp

Secure Gateway, a separate component provided on the XenApp installation media

The following table shows which ICA virtual channels (or combination of virtual channels) can be used with XenApp for

authentication and application signing or for encryption methods.

Note: This table applies only to XenApp, not to Single sign-on.

Smart card virt ualSmart card virt ualchannelchannel

Kerberos virt ualKerberos virt ualchannelchannel

Core ICA prot ocol (no virt ualCore ICA prot ocol (no virt ualchannel)channel)

Smart card authentication * *

Biometric¹ authentication *

Password authentication * *

Applicationsigning/encryption

*


¹ Third-party equipment is required for biometric authentication. Smart card virt ualSmart card virt ualchannelchannel

Kerberos virt ualKerberos virt ualchannelchannel

Core ICA prot ocol (no virt ualCore ICA prot ocol (no virt ualchannel)channel)

The following products can be used with XenApp to provide additional security. These additional security measures are not

included in the sample deployments.

ICA Encryption Using SecureICA

ICA encryption with SecureICA is integrated into XenApp. With SecureICA, you can use up to 128-bit encryption to protect

the information sent between a XenApp server and users’ client devices. However, it is important to note that SecureICA

does not use FIPS 140-compliant algorithms. If this is an issue, you can configure XenApp servers and plug-ins to avoid using

SecureICA.

Authentication for the Web Interface Using RSA SecurID

You can use the third-party product RSA SecurID as an authentication method for the Web Interface running on Internet

Information Services. If RSA SecurID is enabled, users must log on using their credentials (user name, password, and domain)

plus their SecurID PASSCODE. The PASSCODE is made up of a PIN followed by a tokencode (the number displayed on the

user’s RSA SecurID token).

RSA SecurID supports authentication on both XenApp and Single sign-on.

Authentication for the Web Interface Using SafeWord

You can use the third-party product Aladdin SafeWord as an authentication method for the Web Interface running on

Internet Information Services. If SafeWord is enabled, users must log on using their credentials (user name, password, and

domain) plus their SafeWord passcode. The passcode is made up of the code displayed on the user’s SafeWord token,

optionally followed by a PIN.

SafeWord supports authentication on XenApp, but not on Single sign-on.


FIPS 140 and XenApp

May 18 , 2015

Federal Information Processing Standard 140 (FIPS 140) is a U.S. Federal Government standard that specifies a benchmark

for implementing cryptographic software. It provides best practices for using cryptographic algorithms, managing key

elements and data buffers, and interacting with the operating system. An evaluation process that is administered by the

National Institute of Standards and Technology (NIST) National Voluntary Laboratory Accreditation Program (NVLAP)

allows encryption product vendors to demonstrate the extent to which they comply with the standard and, thus, the

trustworthiness of their implementation.

FIPS 140-1, published in 1994, established requirements for cryptographic modules to provide four security levels that

allowed cost-effective solutions appropriate for different degrees of data sensitivity and different application

environments. FIPS 140-2, which superceded FIPS 140-1 in 2002, incorporated changes in standards and technology since

1994. FIPS 140-3, which is still in draft, adds an additional security level and incorporates new security features that reflect

recent advances in technology.

Some U.S. Government organizations restrict purchases of products that contain cryptography to those that use FIPS 140-

validated modules.

In the U.K., guidance published by the Communications-Electronics Security Group (CESG) recommends the use of FIPS 140-

approved products where the required use for information is below the RESTRICTED classification, but is still sensitive (that

is, data classified PRIVATE).

The security community at large values products that follow the guidelines detailed in FIPS 140 and the use of FIPS 140-

validated cryptographic modules.

To implement secure access to application servers and to meet the FIPS 140 requirements, Citrix products can use

cryptographic modules that are FIPS 140 validated in Windows implementations of secure TLS or SSL connections.

The following XenApp components can use cryptographic modules that are FIPS 140 validated:XenApp

Citrix online plug-in (inlcuding the Citrix online plug-in and citrix online plug-in Web)

Web Interface

SSL Relay

Secure Gateway for Windows

Single sign-on

Offline applications (streaming)

SmartAuditor


Where the client and server components (listed above) communicate with the TLS or SSL connection enabled, the

cryptographic modules that are used are provided by the Microsoft Windows operating system. These modules use the

Microsoft Cryptography Application Programming Interface (CryptoAPI) and are FIPS 140 validated.

Note: On both Windows Vista with Service Pack 1 and Windows Server 2008, you must apply Microsoft hotfix kb954059(http://support.microsoft.com/kb/954059) to ensure that the random number generator used within CryptoAPI and,therefore, the underlying operating system is FIPS 140 compliant.The ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, first defined in Internet RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt),


http://www.ietf.org/rfc/rfc2246.txt


uses RSA key exchange and TripleDES encryption.

This is achieved as follows:

According to the Microsoft documentation (http://technet.microsoft.com/en-us/library/cc750357.aspx), FIPS-compliant

systems that use FIPS 140-certif ied cryptomodules can be deployed by following a prescribed set of steps. These steps

include setting a particular FIPS local policy f lag.

As noted in the Microsoft documentation referenced above, not all Microsoft components and products check the FIPS

local policy f lag. Refer to the Microsoft documentation for instructions on how to configure these components and

products to behave in a FIPS-compliant manner.

Similarly, Citrix components do not check the FIPS local policy f lag. Instead, these components must be configured to

behave in a FIPS-compliant manner.

Specif ically, Citrix components that use TLS must be configured to use government ciphersuites. This will cause the

component to select one of the following ciphersuites:

RSA_WITH_3DES_EDE_CBC_SHA [RFC 2246]

RSA_WITH_AES_128_CBC_SHA [FIPS 197, RFC 3268]

RSA_WITH_AES_256_CBC_SHA [FIPS 197, RFC 3268]

Given the accuracy of the above statements, and assuming that all these steps are followed, the resulting XenApp

configuration will use FIPS 140 cryptomodules in a FIPS-compliant manner.

For a list of currently validated FIPS 140 modules, see http://csrc.nist.gov.

For more information about FIPS 140 and NIST, visit the NIST Web site at http://csrc.nist.gov.

http://technet.microsoft.com/en-us/library/cc750357.aspx

http://csrc.nist.gov



Network and Authentication Protocols

May 07, 2015

You can secure XenApp by using network protocols, ciphersuites, authentication, and authentication methods. You can find

information about several security options in this article.

SSL/TLS Protocols

You can secure communications between client devices and servers using either the Transport Layer Security (TLS) 1.0 or

Secure Sockets Layer (SSL) 3.0 protocols. These protocols are collectively referred to TLS/SSL.

Both TLS and SSL are open protocols that provide data encryption, server authentication, message integrity, and optional

client authentication for a TCP/IP connection. Note that both the SSL Relay and Secure Gateway support TLS and SSL.

SSL is an open, nonproprietary security protocol for TCP/IP connections. If you want to use the SSL Relay to secure

communications between client devices and servers within the server farm, you must install the SSL Relay on each server in

the farm. Alternatively, you can use Secure Gateway. Both the SSL Relay and Secure Gateway implementations are

discussed in this documentation.

TLS, which is also an open standard, is the latest, standardized version of the SSL protocol. The SSL Relay also supports TLS;

you can configure the SSL Relay, Secure Gateway, and the Web Interface to use TLS. Support for TLS Version 1.0 is

included in XenApp 6.0 and Single sign-on 4.8.

Because there are only minor differences between TLS and SSL, the server certificates in your installation can be used for

both TLS and SSL implementations.

Government Ciphersuites

You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography to protect

“sensitive but unclassified” data.

For RSA key exchange and TripleDES encryption, the government ciphersuite is RSA_WITH_3DES_EDE_CBC_SHA.

Alternatively, for TLS connections, you can use Advanced Encryption Standard (AES) as defined in FIPS 197. The government

ciphersuites are RSA_WITH_AES_128_CBC_SHA for 128-bit keys and RSA_WITH_AES_256_CBC_SHA for 256-bit keys.

IP Security

IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that provides authenticated and encrypted

communications with data integrity and replay protection. IPSec is a network-layer protocol set, so higher level protocols

such as Citrix ICA can use it without modification.

Although such sample deployments are outside the scope of this document, you can use IPSec to secure a XenApp

deployment within a virtual private network (VPN) environment.

IPSec is described in Internet RFC 2401.

Microsoft Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, and Windows Server

2003 have built-in support for IPSec.

Citrix Single Sign-on


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:

Authenticating users to networks and computers

Securing channel communications over a network

Securing content using digital signatures

If you are using smart cards for secure network authentication, your users can authenticate to applications and content

published on your server farms. In addition, smart card functionality within these published applications is also supported.

For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a

smart card reader attached to the client device in order to log on to a XenApp server. After users are authenticated to the

application, they can digitally sign email using certificates stored on their smart cards.

Citrix supports the use of Personal Computer Smart Card (PC/SC)-based cryptographic smart cards. These cards include

support for cryptographic operations such as digital signatures and encryption. Cryptographic cards are designed to allow

secure storage of private keys such as those used in Public Key Infrastructure (PKI) security systems. These cards perform

the actual cryptographic functions on the smart card itself, meaning that the private key and digital certificates never leave

the card. In addition, you can use 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 used to prove

that the cardholder is the rightful owner of the smart card.

Smart Card Support

Citrix continues testing various smart cards to address smart card usage and compatibility issues with XenApp.

XenApp supports the Common Access Card in a deployment that includes the Citrix online plug-in for Windows. Contact

your Common Access Card vendor or Citrix representative for more information about supported versions of Common

Access Card hardware and software.

Citrix tests smart cards using certificates from common certificate authorities such as those supported by Microsoft. If you

have any concerns regarding your certificate authority and compatibility with XenApp, contact your local Citrix

representative.

Kerberos Authentication

Kerberos is an authentication protocol. Version 5 of this protocol is standardized as Internet RFC 1510. Many operating

systems, including Microsoft Windows 2000 and later, support Kerberos as a standard feature.

XenApp extends the use of Kerberos. When users log on to a client device, they can connect to XenApp without needing

to authenticate again. The user’s password is not transmitted to XenApp; instead, authentication tokens are exchanged


using the Generic Security Services API (GSSAPI) standardized in Internet RFC 1509.

This authentication exchange is performed within an ICA virtual channel and does not require any additional protocols or

ports. The authentication exchange is independent of the logon method, so it can be used with passwords, smart cards, or

biometrics.

To use Kerberos authentication with XenApp, both the client and server must be appropriately configured. You can also use

Microsoft Active Directory Group Policy selectively to disable Kerberos authentication for specific users and servers.


Receiver and Plug-in Security

May 07, 2015

With the Citrix online plug-in installed on their client devices, users can work with applications running on XenApp servers.

Users can access these applications from virtually any type of client device over many types of network connection,

including LAN, WAN, dial-up, and direct asynchronous connections. Because the applications are not downloaded to the

client devices (as with the more traditional network architecture), application performance is not limited by bandwidth or

device performance.

Citrix plug-ins are available for Windows, Macintosh, Linux, UNIX, and Windows CE operating systems, and the Java Runtime

Environment. Additionally, you can use the Citrix online plug-in Web with Web browsers that support ActiveX controls or

Netscape plug-ins.

Citrix plug-ins for Windows use cryptographic modules provided by the operating system. Other plug-ins, including the Client

for Java, contain their own cryptographic modules. The Client for Java can, therefore, be used on older Windows operating

systems that do not support strong encryption.

The Standards Summary table lists the latest versions of the available plug-ins. The table specifies whether each plug-in is

FIPS 140 compliant, supports TLS, includes smart card support, uses government ciphersuites, supports certificate

revocation checking, and supports Kerberos authentication. Note that certificate revocation checking is applicable to plug-

ins running on Windows XP, Windows Vista, and Windows 7 only. Where the latest version of a plug-in does not completely

supersede a previous version (for example, a particular operating system may be supported only by an earlier plug-in version),

the earlier version of the plug-in is also listed.

Standards Summary

The following table summarizes the standards relevant to the various Citrix plug-ins:

Plug-in type FIPS140

TLS TripleDES AES CRLcheck

Smartcard

Kerberos

Citrix online plug-in 12.x *¹ * * * * * *

Citrix online plug-in Web 12.x *¹ * * * * * *

Client for Windows CE forWindows-Based Terminals 10.x

*² * * *

Client for Windows CE forHandheld and Pocket PCs 10.x

*² * * *

Client for Macintosh 10.x * * * * *

Client for Linux 10.x * * *

Client for Java 9.x * * * * *³


Client for Sun Solaris 8.x * * *

Notes:

¹ These plug-ins inherit FIPS 140 compliance from the base operating system, Windows.

² These plug-ins inherit FIPS 140 compliance from the base operating system, Windows CE.

³ Kerberos authentication is not supported when the Client for Java is running on Mac OS X client devices.

Plug-in type FIPS140

TLS TripleDES AES CRLcheck

Smartcard

Kerberos

The table below shows the certificate source for plug-ins that support at least one of the security features listed in the

table above. Plug-ins marked “OS” use certificates stored in the operating system certificate store, those marked “Plug-in”

use certificates bundled with the plug-in, and plug-ins marked “JRE” use certificates stored in the Java keystore.

Plug-in type Root certif icate source

Citrix online plug-in 12.x OS

Citrix online plug-in Web 12.x OS

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

Client for Windows CE for Handheld and Pocket PCs 10.x OS

Client for Macintosh 10.x OS

Client for Linux 10.x Plug-in

Client for Java 9.x JRE (Java 1.4.x)

JRE or OS (Java 1.5.x or later)

Client for Sun Solaris 8.x Plug-in


Sample Deployment with SSL Relay and the WebInterface

May 18 , 2015

This deployment uses the SSL Relay to provide end-to-end TLS/SSL encryption between the XenApp server and the plugin.

This diagram shows sample deployment A, which uses the SSL Relay.

The deployment uses a server farm comprising XenApp 6 servers. Users run the Citrix online plug-in 12.x on their client

devices.

How the Components Interact

Use TLS/SSL to secure the connections between client devices and the XenApp servers. To do this, deploy TLS/SSL-enabled

plug-ins to users and configure the SSL Relay on the XenApp servers.

This deployment provides end-to-end encryption of the communication between the client device and the XenApp servers.

Both the SSL Relay and the appropriate server certificate must be installed and configured on each server in the farm.

The SSL Relay operates as an intermediary in communication between client devices and the XML Service on each server.

Each client device authenticates the SSL Relay by checking the SSL Relay’s server certificate against a list of trusted

certificate authorities. After this authentication, the client device and the SSL Relay negotiate requests in encrypted form.

The SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent to the client device from

the servers passes through the SSL Relay, which encrypts the data and forwards it to the client device to be decrypted.

Message integrity checks verify that each communication has not been tampered with.

This diagram shows a detailed view of sample deployment A.


Security Considerations for This Depolyment

FIPS 140 Validation in Sample Deployment A

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic

algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices

and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation.

For Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 (in a XenApp 6 farm), Windows Server 2008 (in a

XenApp 5 farm), and Windows Server 2003 (in a XenApp 5 farm), TLS/SSL support and the supported ciphersuites can also

be controlled using the following Microsoft security option:

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

For more information, see the documentation for your operating system.

TLS/SSL Support in Sample Deployment A

You can configure XenApp to use either the Transport Layer Security 1.0 protocol or the Secure Sockets Layer 3.0 protocol.

In sample deployment A, the components are configured for TLS.

When using the SSL Relay Configuration Tool, ensure that TLS is selected on the Connection tab.

Supported Ciphersuites for Sample Deployment A

In this deployment, XenApp can be configured to use government-approved cryptography, such as the ciphersuite

RSA_WITH_3DES_EDE_CBC_SHA, to protect “sensitive but unclassified” data.

When using the SSL Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab.

Alternatively, for TLS connections, you can use AES as defined in FIPS 197. The government ciphersuites are

RSA_WITH_AES_128_CBC_SHA for 128-bit keys and RSA_WITH_AES_256_CBC_SHA for 256-bit keys. As defined in

Internet RFC 3268 http://www.ietf.org/rfc/rfc3268.txt, these ciphersuites use RSA key exchange and AES encryption. For

more information about AES, see csrc.nist.gov.




Certificates and Certificate Authorities in Sample Deployment A

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment

A, a separate server certificate is configured for each XenApp server on which the SSL Relay is used. A root certificate is

required for each client device.

Smart Card Support in Sample Deployment A

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure

authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment A

In this deployment, users access their applications using the Citrix plug-in. For more information about the security features

and capabilities of Citrix plug-ins, see Receiver and Plug-in Security.

http://docs.citrix.com/en-us/xenapp-and-xendesktop/xenapp-6/bm-sec-node-wrapper-xa6/ps-sec-considerations-xa-deployment-xa6/ps-sec-xa-plugins-xa6.html


Sample Deployment with Secure Gateway (SingleHop)

May 08 , 2015

This deployment uses Secure Gateway in a single-hop configuration to provide TLS/SSL encryption between a secure

Internet gateway server and an SSL-enabled plugin, combined with encryption of the HTTP communication between the

Web browser and the Web server. Additionally, you can secure ICA traffic within the internal network using IPSec.

This diagram shows sample deployment B, which uses Secure Gateway in a single-hop configuration.

The following table lists the components of the deployment and the operating systems required for the servers and client

devices.

Components Operating systems

XenApp farm XenApp 6.0 for Microsoft Windows Server

2008 R2

SSL Relay enabled

Secure Ticket Authority installed on XenApp

server


Web server Web Interface 5.3 for Internet InformationServices


Windows Server 2008

Windows Server 2003 with Service Pack 2

.NET Framework 3.5 or 2.0 (IIS 6.0 only)

Visual J#.NET 2.0 Second Edition


Secure Gatewayserver

Secure Gateway 3.2 for Windows Windows Server 2008 R2

Windows Server 2008


User devices Citrix online plug-in for Windows 12.x

TLS-enabled Web browser

Windows 7

Windows Vista




Use TLS to secure the connections between client devices and Secure Gateway. To do this, deploy TLS/SSL-enabled plugins

and configure Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ).

Secure the connections between users’ Web browsers and the Web Interface using HTTPS. Additionally, secure

communication between the Web Interface and the XenApp servers using TLS.

This diagram shows a detailed view of sample deployment B.1.

In this deployment, Secure Gateway removes the need to publish the address of every XenApp server in the farm and

provides a single point of encryption and access to the farm. Secure Gateway does this by providing a gateway that is

separate from the XenApp servers and reduces the issues for firewall traversal to a widely accepted port for ICA traffic in

and out of the firewalls.

Set against the increased scalability of sample deployment B is the fact that ICA communication is encrypted only between

client devices and Secure Gateway. ICA communication between Secure Gateway and the XenApp servers is not encrypted.

Note that the SSL Relay in sample deployment B is used to encrypt communication between the Web Interface and the

XML Service running on the XenApp servers. Secure Gateway communicates with the XenApp servers directly, so the SSL

Relay is not used for communication between Secure Gateway and the server farm.

To comply with FIPS 140, secure the communication between Secure Gateway and the server farm using IPSec, as shown in

sample deployment B.2.

This diagram shows a detailed view of sample deployment B.2, which includes IPSec.


Security Considerations for This Deployment

IPSec in Sample Deployment B

To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure

IPSec on each server, including the Secure Gateway server.

IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment B.2, IPSec is

enabled on the requisite servers and the security method is configured for 3DES encryption and SHA-1 integrity to meet

FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment B

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers and associated cryptographic



For Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003, TLS/SSL support and the supported

ciphersuites can also be controlled using the following Microsoft security option:



TLS/SSL Support in Sample Deployment B

You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the

Secure Sockets Layer 3.0 protocol. In sample deployment B, the components are configured for TLS.

Supported Ciphersuites for Sample Deployment B

In this deployment, Secure Gateway and the Web Interface can be configured to use government-approved cryptography,

such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect “sensitive but unclassified” data.




more information about AES, see http://csrc.nist.gov.




Certificates and Certificate Authorities in Sample Deployment B


B, one server certificate is configured on Secure Gateway and one on the Web Interface. A certificate is also configured on

each XenApp server.

Smart Card Support in Sample Deployment B



Plug-ins Used in Sample Deployment B





Sample Deployment with the Secure Gateway (DoubleHop)

May 08 , 2015

This deployment uses Secure Gateway in a double-hop configuration to provide TLS/SSL encryption between a secure

Internet gateway server and an SSL-enabled plugin, combined with encryption of the HTTP communication between

Secure Gateway and the Web browser, the Web Interface, and the Secure Gateway proxy. Additionally, you can secure ICA

traffic within the internal network using IPSec.

This diagram shows sample deployment C, which uses Secure Gateway in a double-hop configuration.


devices.



2008 R2

SSL Relay enabled


server


Web server Web Interface 5.3 for Internet Information

Services


Windows Server 2008




Secure GatewayService



Secure GatewayProxy

Windows Server 2008




Windows 7

Windows Vista



How the Components in Interact

Here, the DMZ is divided into two sections by an additional firewall. The server running the Secure Gateway Service is

located in the first section of the DMZ. The Web Interface and the Secure Gateway Proxy are located in the second

section. Users connect to the Secure Gateway Service located in the first section of the DMZ.

Use TLS to secure the connections between client devices and Secure Gateway. To do this, deploy TLS/SSL-enabled plug-

ins and configure Secure Gateway at the network perimeter, typically in a DMZ.

This diagram shows a detailed view of sample deployment C.





To comply with FIPS 140, secure the communication between the Secure Gateway Proxy and the server farm using IPSec.


IPSec in Sample Deployment C

To enable IPSec to secure communication between the Secure Gateway Proxy and the XenApp server farm, you must

configure IPSec on each server, including the Secure Gateway Proxy.

IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment C, IPSec is




FIPS 140 Validation in Sample Deployment C








TLS/SSL Support in Sample Deployment C

You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the

Secure Sockets Layer 3.0 protocol. In sample deployment C, the components are configured for TLS.

Supported Ciphersuites for Sample Deployment C

In this deployment, Secure Gateway, the Secure Gateway Proxy, and the Web Interface can be configured to use

government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect “sensitive but

unclassified” data.





Certificates and Certificate Authorities in Sample Deployment C


C, one server certificate is configured on Secure Gateway, one on the Secure Gateway Proxy, and one on the Web

Interface. A certificate is also configured on each XenApp server.

Smart Card Support in Sample Deployment C

Smart card authentication is not supported in sample deployment C. You cannot configure smart card support when Secure

Gateway is positioned between the client devices and the Web Interface to provide a single point of access to the server

farm.

Plug-ins Used in Sample Deployment C







Sample Deployment with SSL Relay and the WebInterface

May 08 , 2015

This deployment uses the SSL Relay and the Web Interface to encrypt the ICA and HTTP communication between the

XenApp server and the Web server, combined with encryption of the HTTP communication between the Web browser and

the Web server.

This diagram shows sample deployment D, which uses the SSL Relay and the Web Interface.


devices.



2008 R2

SSL Relay enabled


server




Windows Server 2008







Windows 7

Windows Vista




Use HTTPS to secure the connections between users’ Web browsers and the Web Interface. Secure the connection

between the Web Interface and the SSL Relay using TLS.

Additionally, use TLS to secure the connections between client devices and the SSL Relay.

The SSL Relay operates as an intermediary in communication between client devices, the Web Interface, and the XML

Service on each server. Each client device authenticates the SSL Relay by checking the SSL Relay’s server certificate against

a list of trusted certificate authorities. After this authentication, the client device and the SSL Relay negotiate requests in

encrypted form. The SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent to the

client device from the servers passes through the SSL Relay, which encrypts the data and forwards it to the client device to

be decrypted. Message integrity checks verify that each communication has not been tampered with.

This diagram shows a detailed view of sample deployment D.


FIPS 140 Validation in Sample Deployment D









TLS/SSL Support in Sample Deployment D

You can configure the SSL Relay and the Web Interface to use either the Transport Layer Security 1.0 protocol or the

Secure Sockets Layer 3.0 protocol. In sample deployment D, the components are configured for TLS.

When using the SSL Relay Configuration Tool, ensure that TLS is selected on the Connection tab.

Supported Ciphersuites for Sample Deployment D

In this deployment, the SSL Relay and the Web Interface can be configured to use government-approved cryptography,


When using the SSL Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab.




more information about AES, see http://csrc.nist.gov

Certificates and Certificate Authorities in Sample Deployment D


D, a separate server certificate is configured for each XenApp server on which the SSL Relay is used.

Smart Card Support in Sample Deployment D



Plug-ins Used in Sample Deployment D







Sample Deployment with Single Sign-on and SecureGateway (Single-Hop)

May 18 , 2015

This deployment uses Citrix Single sign-on and Secure Gateway in a single-hop configuration to enable single sign-on and

TLS/SSL encryption between a secure Internet gateway server and an SSL-enabled plug-in, combined with encryption of

the HTTP communication between the Web browser and the Web server. Additionally, you can secure ICA traffic within the

internal network using IPSec.

See the Citrix Single sign-on documentation for further information about the Citrix Single sign-on components in this

deployment.

This diagram shows sample deployment E, which uses Citrix Single sign-on and Secure Gateway.

Note: The Citrix Single sign-on central store is hosted on two servers (primary and secondary), both running Active Directory.The secondary server is only used to provide failover for the primary server.The following table lists the components of the deployment and the operating systems required for the servers and client

devices.



2008

SSL Relay not enabled


server

Citrix Single sign-on 4.8 plug-in


Java 1.4.x or later

Citrix Single sign-on Service

Citrix Single sign-on 4.8 Service Windows Server 2008 R2

Windows Server 2008 (32-bit)


Windows Server 2003 with Service Pack 2 (32-

bit)


.NET Framework 2.0

Citrix Single sign-on central store

Citrix Single sign-on 4.8 central store Windows Server 2008 R2

Windows Server 2008




Windows Server 2008




Secure Gatewayserver


Windows Server 2008




Windows 7

Windows Vista




Use TLS to secure the connections between client devices and Secure Gateway. To do this, deploy TLS/SSL-enabled plug-

ins and configure Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ). Secure the connections

between users’ Web browsers and the Web Interface using HTTPS.

Additionally, use TLS to secure communication between the Web Interface and the XenApp server farm, and between the

farm and the Single sign-on central store and Single sign-on service.





Set against the increased scalability of sample deployment E is the fact that ICA communication is encrypted only between


client devices and Secure Gateway. ICA communication between Secure Gateway and the XenApp servers is not encrypted.

To comply with FIPS 140, secure the communication between Secure Gateway and the server farm using IPSec.

This diagram shows a detailed view of sample deployment E.


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 sample deployment E, IPSec is



FIPS 140








TLS/SSL 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,







Certificates and Certificate Authorities


E, one server certificate is configured on Secure Gateway and one on the Web Interface. A certificate is also configured on

each XenApp server and on the server running the Password Manager service.

Smart Card Support



Plug-ins




