Integrate Citrix XenApp Publishing
When setting up integration with Citrix XenApp Publishing, you first need to set the correct settings and defaults before you can publish applications.
- Workspace Control must be installed on at least one of the Citrix servers in the farm to be integrated with Workspace Control. If Relay Servers are used in your Workspace Control environment, make sure the version of the Relay Servers is identical to the highest version of the Agents in the environment.
Workspace Control has two different mechanisms for Citrix XenApp publishing:
- The local publishing mechanism is used when the Workspace Control Console is running on a Citrix XenApp server and you publish to the farm to which this Citrix XenApp server also belongs.
Local publishing is executed by the Workspace Control Console.
- The remote publishing mechanism is used when the Workspace Control Console is not running on a Citrix XenApp server, or when the Workspace Control Console is running on a Citrix XenApp server in a different farm than the target farm.
Remote publishing is executed by the Workspace Control Agent Service running on the target Citrix XenApp server.
Publishing a single application or content to multiple farms may trigger both mechanisms.
On each Citrix XenApp server to which Workspace Control will publish, the account running the RES Agent Service must be either local system or a domain account with Full Administration Privileges in the Citrix farm.
For local publishing, the account running the Workspace Control Console must be a user account with Full Administration Privileges in the Citrix farm. For remote publishing, the account running the Workspace Control Console is irrelevant.
If you have Citrix XenApp 6.5 Session Host Only servers (Worker) configured in your environment, consider the following requirements:
- Workspace Control must be installed on one or more Citrix XenApp Controllers (Zone Data Controllers). For redundancy purposes, it is preferred to have Workspace Control installed on two or more Citrix XenApp Controllers.
This is required for the following:
- To retrieve available Citrix XenApp Worker Groups and make them available in the Workspace Control environment.
- Execute Citrix application publishing in case applications are published from a Workspace Control Console that is running on a Citrix XenApp Session Host Only server.
- For Agents running on a Citrix XenApp Controller, the option Poll for changes must be set to Every 5 seconds (at Administration > Agents, on the Settings tab).
- Workspace Control Console users can only change the Citrix folder to which a specific application is to be published if they are running the Console on a Citrix server AND the account running the RES Agent Service has Full Administration Privileges in the Citrix farm.
- To successfully publish applications from a machine on which the Microsoft Windows option User Account Control (UAC) is enabled, the Management Console needs to be started as Run as Administrator on that machine.
- A standard 30-second timeout applies to remote publishing tasks. For Citrix XenApp servers to which managed applications will be published remotely, the Agent setting Poll for changes should therefore be set at 5 seconds (at Administration > Agents). A longer interval may cause publishing to fail. The Agent setting Update agent cache on change does not affect Citrix XenApp publishing.
- Lingering Citrix XenApp applications started by Workspace Control will not show the status 'lingering' on the Citrix server. This is caused by the way Workspace Control starts Citrix published applications.
- To enable Session Lingering for Citrix XenApp 7.5 and 7.6, the following registry values can be set:
- For Citrix Session Prelaunch to work, the following prerequisites need to be met:
- the Citrix server needs to be configured to launch the Workspace Composer automatically (Administration > Agents, on the Agents tab, select Automatic for Run Workspace Composer)
- a Citrix Receiver needs to be started on the client.
On the Settings tab, configure general settings for the Citrix XenApp integration in your Workspace Control site:
- Clicking the Test Publishing Ability button will, for the machine it is used on, test to which available Citrix XenApp 7.x sites within the Workspace Control environment it can publish. The machine must be a delivery controller or Citrix Studio must be installed on it.
- For previous editions of Citrix XenApp, the Test Publishing Ability button can only be used on a Citrix XenApp server, and the publishing ability of only the farm that the server belongs to, is looked at.
To successfully use the Test Publishing Ability button on a machine on which the Microsoft Windows option User Account Control (UAC) is enabled, the Management Console needs to be started as Run as Administrator on that machine. Starting the Management Console normally, would cause a message to be displayed about the user not having sufficient access rights (even if this is not the case).
- The field ID used by Workspace Control contains the name of the CMC folder used by Workspace Control when creating Published Applications. You can change this ID if you use two or more Workspace Control Datastores in one Citrix farm. The different IDs for each Workspace Control Datastore will then keep the Published Applications unique in the farm.
- It is possible to assign an application to one or more Organizational Units. When publishing this application in a Citrix environment, all users in the selected Organizational Units are listed and added to the list of users for the published application. However, the users present in the selected Organizational Units may change over time, and these changes need to be reflected in the list of users for the Published Application. Workspace Control will do this automatically at the time specified in the field Rebuild userlist for OU based Published Applications every day at: At the time specified, one of the Citrix servers using this Datastore will go through the list of applications which are configured to use OU-based access control and which are published in Citrix. For these applications, the selected OUs are read and the resulting list of users is matched to the application's current list of configured users and changed accordingly.
- If an ICA Seamless Host Agent message should be shown when a user logs on, select Do not suppress message from ICA Seamless Host Agent during logon. This message is shown if the user connects seamless to a published XenApp desktop via the ICA client and the Terminal Session uses the Microsoft Windows shell. The message is suppressed if the Workspace Control shell is used.
- Select Use RESPFDIR environment variable in command line of published application to use the system environment variable RESPFDIR in the command line of a published XenApp application when that command line refers to the Workspace Control installation folder. (This system environment variable is created by the Workspace Control Agent Service.) Use of this environment variable makes it possible to publish an application across multiple computers with different Workspace Control installation locations. This option should only be used when the system environment variable RESPFDIR is available on all computers that the application is published to. To ensure this, either make sure Ivanti Workspace Control is installed on all computers.
- To make Workspace Control components available as published applications, select the relevant check boxes at Publish the following Workspace Control components for authorized users. The access control settings of these published applications will match those of a Workspace Control desktop session (e.g. only application managers will be added to the user list for the Access Wizard, etc.).
- To create a published server desktop, use the Citrix XenApp Console and a GPO to launch the Workspace Control desktop. See Configure the Ivanti Workspace Composer as a Citrix XenApp Published Application.
- The button Add or remove Citrix XenApp servers to or from existing applications opens a wizard that will guide you through the process of adding or removing Citrix servers to or from the list of configured Citrix servers for selected application(s). For example, you can add a new Citrix server "CTX10" to all applications that already have Citrix server "CTX01" in their list of configured Citrix servers.
On the Defaults tab, you can configure the default settings for all Citrix XenApp published applications and published content. Any managed application for which you enable Citrix XenApp publishing will be preconfigured with the defined default settings.
All these default settings can then be changed for each individual managed application, with the exception of the Instant Passthrough setting Use template ICA file. Selecting this option defines a global custom ICA file that will be used for ALL instant passthrough connections, and will overrule any ICA files configured at application level. To create a custom ICA file per published application, ensure that the global option Use template ICA file is NOT selected. Then, for each Citrix published application for which the default ICA file generated by Workspace Control does not suffice, go to the application's Publishing tab, select Use a custom ICA file for this application and click [Edit].
To update the available servers / groups list, click the Refresh button. This button is only available when using the Workspace Control Console on a machine with Citrix Studio installed on it or when using the Workspace Control Console on the Citrix Delivery Controller. Every 12 hours, Workspace Control updates the list with available Delivery Groups for all configured Citrix Sites if both Workspace Control and a Citrix Delivery Controller (per Citrix Site) are installed on the machine or if Workspace Control and Citrix Studio (per Citrix Site) are installed on the machine.
Server Groups are a Workspace Control mechanism to combine multiple Citrix XenApp servers (only for Citrix XenApp 6.5) into a single unit. They are typically used to represent silos. After defining a Server Group, you can select this Server Group instead of selecting each individual Citrix XenApp server (only for Citrix XenApp 6.5) when publishing an application.
Whenever you change the members of a Server Group, any application that references this group will automatically be republished.
On the Citrix XenApp 7.x tab, you can configure Citrix XenApp 7.x delivery controller(s) to publish applications. Multiple delivery controllers per site can be specified, to create redundancy for Citrix XenApp 7.x application publishing. Use a semicolon (;) to separate multiple Delivery Controllers. A DNS entry is allowed as a delivery controller. These delivery controllers will be used to publish applications for which delivery groups for the same site are selected (at Composition > Applications, on the Properties > Publishing > Citrix XenApp Published Application tab of an application).
Per Citrix Delivery Controller, specify the credentials for Workspace Control to use. If no credentials are specified, the credentials of the Console user (local publishing) and the Workspace Control service (remote publishing) will be used. In all cases, the credentials must be of a user with at least Citrix 'Delivery Group Administrator' role permissions.
Citrix Delivery Groups cannot be created or managed from within Workspace Control. This needs to be done in Citrix Studio.
- When creating Citrix Delivery Groups in Citrix Studio, it is recommended to allow "Domain Users". Restricting users per Delivery Group is possible, but this will affect, for example, applications that are published to All Users from the Workspace Control Console.
- At http://support.citrix.com/article/CTX200337 you can find possibilities to shorten the time Citrix Receiver needs to generate its XML cache file.
Specify credentials for Use the following credentials to communicate with Citrix XenApp servers. If no credentials are given, the credentials of the Console user and the Workspace Control service will be used. In all cases, the credentials must be of a user with at least Citrix 'Delivery Group Administrator' role permissions.