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.
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:
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.
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 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.
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
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.|
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.
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:
In addition, from the list of permissions for other components, consider these permissions:
HDX Insight is the integration of EdgeSight network analysis and EdgeSight performance management with Director:
After you enable this feature in Director, HDX Insight provides Director with additional information:
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.
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 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):
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:
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:
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$
To configure advanced settings using IIS:
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.
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 = (user),(server),ENDUSERDOMAIN
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.
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.
Service.AutoDiscoveryAddresses = SiteAController,SiteBController
where SiteAController and SiteBController are the addresses of Delivery Controllers from two different sites.
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.
UI.TaskManager.EnableApplications = false