Product Documentation

Monitor environments with Director

Aug 05, 2015

Director is installed by default as a website on the Delivery Controller. For prerequisites and other details, see the System requirements topic for this release.

This release of Director is not compatible with XenApp deployments earlier than 7.5 or XenDesktop deployments earlier than 7.

When Director is used in an environment containing more than one Site, be sure to synchronize the system clocks on all the servers where Controllers, Director, and other core components are installed. Otherwise, the Sites might not display correctly in Director.

Tip: If you intend to monitor XenApp 6.5 in addition to XenApp 7.5 or XenDesktop 7.x Sites, Citrix recommends installing Director on a separate server from the Director console that is used to monitor XenApp 6.5 sites. 
Important: To protect the security of user names and passwords sent using plain text through the network, Citrix strongly recommends that you allow Director connections using only HTTPS, and not HTTP. Certain tools are able to read plain text user names and passwords in HTTP (unencrypted) network packets, which creates a security risk for users.

To configure permissions

To log on to Director, administrators with permissions for Director must be Active Directory domain users and must have the following rights:

  • Read rights in all Active Directory forests to be searched (see Advanced configuration).
  • Configured Delegated Administrator roles (see Delegated Administration and Director).
  • To shadow users, administrators must be configured using a Microsoft group policy for Windows Remote Assistance. In addition:
    • When installing VDAs, ensure the Windows Remote Assistance feature is enabled on all user devices (selected by default).
    • When you install Director on a server, ensure that Windows Remote Assistance is installed (selected by default). However, it is disabled on the server by default. The feature does not need to be enabled for Director to provide assistance to end users. Citrix recommends leaving the feature disabled to improve security on the server.
    • To enable administrators to initiate Windows Remote Assistance, grant them the required permissions by using the appropriate Microsoft Group Policy settings for Remote Assistance. For information, see CTX127388: How to Enable Remote Assistance for Desktop Director.
  • For user devices with VDAs earlier than 7, additional configuration is required. See Configure permissions for VDAs earlier than 7.

To install Director

Install Director using the installer, which checks for prerequisites, installs any missing components, sets up the Director website, and performs basic configuration. The default configuration provided by the installer handles typical deployments. If Director was not included during installation, use the installer to add Director. To add any additional components, rerun the installer and select the components to install. For information on using the installer, see the Installation topics. Citrix recommends that you install using the product installer only, not the .MSI file.

When Director is installed on the Controller, it is automatically configured with localhost as the server address, and Director communicates with the local controller by default.

To install Director on a dedicated server that is remote from a Controller, you are prompted to enter the FQDN or IP address of a Controller. Director communicates with that specified Controller by default. Specify only one Controller address for each Site that you will monitor. Director automatically discovers all other Controllers in the same Site and falls back to those other Controllers if the Controller you specified fails.

Note: Director does not load balance between Controllers.

To secure the communications between the browser and the Web server, Citrix recommends that you implement SSL on the IIS website hosting Director. Refer to the Microsoft IIS documentation for instructions. Director configuration is not required to enable SSL.

To log on to Director

The Director website is located at https or http://<Server_FQDN>/Director.

If one of the Sites in a multi-site deployment is down, the logon for Director takes a little longer while it attempts to connect to the Site that is down.

Delegated Administration and Director

Delegated Administration uses three concepts: administrators, roles, and scopes. Permissions are based on an administrator's role and the scope of this role. For example, an administrator might be assigned a Help Desk administrator role where the scope involves responsibility for end-users at one site only.

For information about creating delegated administrators, see the main Delegated Administration topic.

Administrative permissions determine the Director interface presented to administrators and the tasks they can perform. Permissions determine:
  • The views the administrator can access, collectively referred to as a view.
  • The desktops, machines, and sessions that the administrator can view and interact with.
  • The commands the administrator can perform, such as shadowing a user's session or enabling maintenance mode.

The built-in roles and permissions also determine how administrators use Director:

Administrator Role Permissions in Director
Full Administrator Full access to all views and can perform all commands, including shadowing a user's session, enabling maintenance mode, and exporting trends data.
Delivery Group Administrator Full access to all views and can perform all commands, including shadowing a user's session, enabling maintenance mode, and exporting trends data.
Read Only Administrator Can access all views and see all objects in specified scopes as well as global information. Can download reports from HDX channels and can export Trends data using the Export option in the Trends view.

Cannot perform any other commands or change anything in the views.

Help Desk Administrator Can access only the Help Desk and User Details views and can view only objects that the administrator is delegated to manage. Can shadow a user's session and perform commands for that user. Can perform maintenance mode operations. Can use power control options for Desktop OS Machines.

Cannot access the Dashboard, Trends, or Filters views. Cannot use power control options for Server OS machines.

Machine Catalog Administrator No access. This administrator is not supported for Director and cannot view data.
Host Administrator No access. This administrator is not supported for Director and cannot view data.
Note: You can modify the views in Director, such as removing or enabling buttons, through Delegated Administrator roles and permissions. For example, if your organization does not want a certain group of Director administrators to shadow users, select a role or customize a role that does not allow shadowing or does not allow the custom permission "Perform Remote Assistance on a machine," and the Shadow button will not appear in the UI.

To configure custom roles for Director administrators

In Studio, you can also configure Director-specific, custom roles to more closely match the requirements of your organization and delegate permissions more flexibly. For example, you can restrict the built-in Help Desk administrator role so that this administrator cannot log off sessions.

If you create a custom role with Director permissions, you must also give that role other generic permissions:
  • Delivery Controller permission to log on to Director.
  • Permissions to Delivery Groups to view the data related to those Delivery Groups in Director.

Alternatively, you can create a custom role by copying an existing role and include additional permissions for different views. For example, you can copy the Help Desk role and include permissions to view the Dashboard or Filters view.

Select the Director permissions for the custom role, including:

  • Perform Kill Application running on a machine
  • Perform Kill Process running on a machine
  • Perform Remote Assistance on a machine
  • Perform Reset vDisk operation
  • Reset user profiles
  • View Dashboard page
  • View Help Desk page
  • View Host Connection status and alerts
  • View Slice and Dice page (Filters view)
  • View Trends
  • View User Details page

In addition, from the list of permissions for other components, consider these permissions:

  • From Profile management: Read Profile Definitions
  • From Delivery Groups:
    • Enable/disable maintenance mode of a machine using Delivery Group membership
    • Perform power operations on Windows Desktop machines using Delivery Group membership
    • Perform session management on machines using Delivery Group membership
    • View Delivery Groups

Configure HDX Insight

Note: The availability of this feature depends on your organization's license and your administrator permissions.

HDX Insight is the integration of EdgeSight network analysis and EdgeSight performance management with Director:

  • EdgeSight network analysis leverages HDX Insight to provide an application and desktop contextual view of the network. With this feature, Director provides advanced analytics of ICA traffic in their deployment.
  • EdgeSight performance management provides the historical retention and trend reporting. With historical retention of data versus the real-time assessment, you can create Trend reports, including capacity and health trending.

After you enable this feature in Director, HDX Insight provides Director with additional information:

  • The Trends page shows latency and bandwidth effects for applications, desktops, and users across the entire deployment.
  • The User Details page shows latency and bandwidth information specific to a particular user session.


  • ICA session Round Trip Time (RTT) shows data correctly for Receiver for Windows 3.4 or higher and the Receiver for Mac 11.8 or higher. For earlier versions of these Receivers, the data does not display correctly.
  • In the Trends view, HDX connection logon data is not collected for VDAs earlier than 7. For earlier VDAs, the chart data is displayed as 0.

To configure the EdgeSight network analysis feature on Director

EdgeSight provides network analysis by leveraging NetScaler HDX Insight to provide the Citrix application and desktop administrators the ability to troubleshoot and correlate issues that can be attributed to poor network performance.

NetScaler Insight Center must be installed and configured in Director to enable EdgeSight network analysis. Insight Center is a virtual machine (appliance) downloaded from Using EdgeSight network analysis, Director communicates and gathers the information that is related to your deployment. This information is leveraged from HDX Insight, which provides robust analysis of the Citrix ICA protocol between the client and the back-end Citrix infrastructure.
  1. On the server where Director is installed, locate the DirectorConfig command line tool in C:\inetpub\wwwroot\Director\tools, and run it with parameter /confignetscaler in command line prompt.
  2. When prompted, configure the NetScaler Insight Center machine name (FQDN or IP address), username, password, and HTTP or HTTPS connection type.
  3. To verify the changes, log off and log back on.

Configure permissions for VDAs earlier than XenDesktop 7

If users have VDAs earlier than XenDesktop 7 installed on their devices, Director supplements information from the deployment with real-time status and metrics through Windows Remote Management (WinRM).

In addition, use this procedure to configure WinRM for use with Remote PC in XenDesktop 5.6 Feature Pack1.

By default, only local administrators of the desktop machine (typically domain administrators and other privileged users) have the necessary permissions to view the real-time data.

For information about installing and configuring WinRM, see CTX125243.

To enable other users to view the real-time data, you must grant them permissions. For example, suppose there are several Director users (HelpDeskUserA, HelpDeskUserB, and so on) who are members of an Active Directory security group called HelpDeskUsers. The group has been assigned the Help Desk administrator role in Studio, providing them with the required Delivery Controller permissions. However, the group also needs access to the information from the desktop machine.

To provide the necessary access, you can configure the required permissions in one of two ways:
  • Grant permissions to the Director users (impersonation model)
  • Grant permissions to the Director service (trusted subsystem model)

To grant permissions to the Director users (impersonation model)

By default, Director uses an impersonation model: The WinRM connection to the desktop machine is made using the Director user's identity. It is therefore the user that must have the appropriate permissions on the desktop.

You can configure these permissions in one of two ways (described later in this topic):

  1. Add users to the local Administrators group on the desktop machine.
  2. Grant users the specific permissions required by Director. This option avoids giving the Director users (for example, the HelpDeskUsers group) full administrative permissions on the machine.

To grant permissions to the Director service (trusted subsystem model)

Instead of providing the Director users with permissions on the desktop machines, you can configure Director to make WinRM connections using a service identity and grant only that service identity the appropriate permissions.

With this model, the users of Director have no permissions to make WinRM calls themselves. They can only access the data using Director.

The Director application pool in IIS is configured to run as the service identity. By default, this is the APPPOOL\Director virtual account. When making remote connections, this account appears as the server's Active Directory computer account; for example, MyDomain\DirectorServer$. You must configure this account with the appropriate permissions.

If multiple Director websites are deployed, you must place each web server's computer account into an Active Directory security group that is configured with the appropriate permissions.

To set Director to use the service identity for WinRM instead of the user's identity, configure the following setting, as described in Advanced Configuration:

Service.Connector.WinRM.Identity = Service

You can configure these permissions in one of two ways:

  1. Add the service account to the local Administrators group on the desktop machine.
  2. Grant the service account the specific permissions required by Director (described next). This option avoids giving the service account full administrative permissions on the machine .

To assign permissions to a specific user or group

The following permissions are required for Director to access the information it requires from the desktop machine through WinRM:

  • Read and execute permissions in the WinRM RootSDDL
  • WMI namespace permissions:
    • root/cimv2 — remote access
    • root/citrix — remote access
    • root/RSOP — remote access and execute
  • Membership of these local groups:
    • Performance Monitor Users
    • Event Log Readers

The ConfigRemoteMgmt.exe tool, used to automatically grant these permissions, is on the installation media in the x86\Virtual Desktop Agent and x64\Virtual Desktop Agent folders and on the installation media in the tools folder. You must grant permissions to all Director users.

To grant the permissions to an Active Directory security group, user, or computer account, run the tool with administrative privileges from a command prompt using the following arguments:

ConfigRemoteMgmt.exe /configwinrmuser domain\name

where name is a security group, user, or computer account.

For example, to grant the required permissions to a user security group:

ConfigRemoteMgmt.exe /configwinrmuser MyDomain\HelpDeskUsers

Or to grant the permissions to a specific computer account:

ConfigRemoteMgmt.exe /configwinrmuser MyDomain\DirectorServer$

Advanced configuration

Some advanced Director configuration, such as supporting multiple sites or multiple Active Directory forests, is controlled through settings in Internet Information Services (IIS) Manager.
Important: When you change a setting in IIS, the Director service automatically restarts and logs off users.

To configure advanced settings using IIS:

  1. Open the Internet Information Services (IIS) Manager console.
  2. Go to the Director website under the Default website.
  3. Double-click Application Settings.
  4. Double-click a setting to edit it.

To support users across multiple Active Directory domains and forests

Director uses Active Directory to search for users and to look up additional user and machine information. By default, Director searches the domain or forest in which:
  • The administrator's account is a member.
  • The Director web server is a member (if different).

Director attempts to perform searches at the forest level using the Active Directory global catalog. If the administrator does not have permissions to search at the forest level, only the domain is searched.

To search or look up data from another Active Directory domain or forest requires that you explicitly set the domains or forests to be searched. Configure the following setting:
Connector.ActiveDirectory.Domains = (user),(server)

The value attributes user and server represent the domains of the Director user (the administrator) and Director server respectively.

To enable searches from an additional domain or forest, add the name of the domain to the list, as shown in this example:

Connector.ActiveDirectory.Domains = 

For each domain in the list, Director attempts to perform searches at the forest level. If the administrator does not have permissions to search at the forest level, only the domain is searched.

To add sites to Director

If Director is already installed, configure it to work with multiple sites. To do this, use the IIS Manager Console on each Director server to update the list of server addresses in the application settings.

Add an address of a controller from each site to the following setting:
Service.AutoDiscoveryAddresses = SiteAController,SiteBController

where SiteAController and SiteBController are the addresses of Delivery Controllers from two different sites.

To disable the visibility of running applications in the Activity Manager

By default, the Activity Manager in Director displays a list of all the running applications and the Windows description in the title bars of any open applications for the user's session. This information can be viewed by all administrators that have access to the Activity Manager feature in Director. For Delegated Administrator roles, this includes Full administrator, Delivery Group administrator, and Help Desk Administrator.

To protect the privacy of users and the applications they are running, you can disable the Applications tab from listing running applications.

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
  1. On the VDA, modify the registry key located at HKLM\Software\Citrix\Director\TaskManagerDataDisplayed. By default, the key is set to 1. Change the value to 0, which means the information will not be displayed in the Activity Manager.
  2. On the server with Director installed, modify the setting that controls the visibility of running applications. By default, the value is true, which allows visibility of running applications in the Applications tab. Change the value to false, which disables visibility. This option affects only the Activity Manager in Director, not the VDA.
    Modify the value of the following setting:
    UI.TaskManager.EnableApplications = false
Important: To disable the view of running applications, Citrix recommends making both changes to ensure the data is not displayed in Activity Manager.