Product documentation
XenApp and XenDesktop
7.15 LTSR
View PDF

Configure permissions for VDAs earlier than XenDesktop 7

August 17, 2018
Contributed by: 
C A

If users have VDAs earlier than XenDesktop 7, 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 document):

  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
<!--NeedCopy-->

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 C:\inetpub\wwwroot\Director\tools folder. You must grant permissions to all Director users.

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

ConfigRemoteMgmt.exe /configwinrmuser domain\name
<!--NeedCopy-->

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

To grant the required permissions to a user security group:

ConfigRemoteMgmt.exe /configwinrmuser domain\HelpDeskUsers
<!--NeedCopy-->

To grant the permissions to a specific computer account:

ConfigRemoteMgmt.exe /configwinrmuser domain\DirectorServer$
<!--NeedCopy-->

For End Process, End Application, and Shadow actions:

ConfigRemoteMgmt.exe /configwinrmuser domain\name /all
<!--NeedCopy-->

To grant the permissions to a user group:

ConfigRemoteMgmt.exe /configwinrmuser domain\HelpDeskUsers /all
<!--NeedCopy-->

To display help for the tool:

ConfigRemoteMgmt.exe
<!--NeedCopy-->
Configure permissions for VDAs earlier than XenDesktop 7
August 17, 2018
Contributed by: 
C A
August 17, 2018
Contributed by: 
C A

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.