Configure permissions for VDAs earlier than XenDesktop 7
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Configure permissions for VDAs earlier than XenDesktop 7
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)
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):
- Add users to the local Administrators group on the desktop machine.
- 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.
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:
- Add the service account to the local Administrators group on the desktop machine.
- 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 .
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:
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.