Built-in roles for Windows Virtual Desktop

Windows Virtual Desktop uses Azure role-based access controls (RBAC) to assign roles to users and admins. These roles give admins permission to carry out certain tasks. To learn more about built-in roles for Azure RBAC, see Azure built-in roles.

The standard built-in roles for Azure are Owner, Contributor, and Reader. However, Windows Virtual Desktop has additional roles that let you separate management roles for host pools, app groups, and workspaces. This separation lets you have more granular control over administrative tasks. These roles are named in compliance with Azure’s standard roles and least-privilege methodology.

Windows Virtual Desktop doesn’t have a specific Owner role. However, you can use a standard Owner role for the service objects.

Desktop Virtualization Contributor

The Desktop Virtualization Contributor role lets you manage all aspects of the deployment. However, it doesn’t grant you access to compute resources. You’ll also need the User Access Administrator role to publish app groups to users or user groups.

• Microsoft.DesktopVirtualization/*
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/*
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Desktop Virtualization Reader

The Desktop Virtualization Reader role lets you view everything in the deployment but doesn’t let you make any changes.

• Microsoft.DesktopVirtualization/*/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/read
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Host Pool Contributor

The Host Pool Contributor role lets you manage all aspects of host pools, including access to resources. You’ll need an extra contributor role, Virtual Machine Contributor, to create virtual machines. You will need AppGroup and Workspace contributor roles to create host pool using the portal or you can use Desktop Virtualization Contributor role.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/hostpools/*
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/*
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Host Pool Reader

The Host Pool Reader role lets you view everything in the host pool, but won’t allow you to make any changes.

• Microsoft.DesktopVirtualization/hostpools/*/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/read
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Application Group Contributor

The Application Group Contributor role lets you manage all aspects of app groups. If you want to publish app groups to users or user groups, you’ll need the User Access Administrator role.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/applicationgroups/*
• Microsoft.DesktopVirtualization/hostpools/read
• Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/*
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Application Group Reader

The Application Group Reader role lets you view everything in the app group and will not allow you to make any changes.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/applicationgroups/*/read
• Microsoft.DesktopVirtualization/applicationgroups/read
• Microsoft.DesktopVirtualization/hostpools/read
• Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/read
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Workspace Contributor

The Workspace Contributor role lets you manage all aspects of workspaces. To get information on applications added to the app groups, you’ll also need to be assigned the Application Group Reader role.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/workspaces/*
• Microsoft.DesktopVirtualization/applicationgroups/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/*
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Workspace Reader

The Workspace Reader role lets you view everything in the workspace, but won’t allow you to make any changes.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/workspaces/read
• Microsoft.DesktopVirtualization/applicationgroups/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/read
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

User Session Operator

The User Session Operator role lets you send messages, disconnect sessions, and use the «logoff» function to sign sessions out of the session host. However, this role doesn’t let you perform session host management like removing session host, changing drain mode, and so on. This role can see assignments, but can’t modify admins. We recommend you assign this role to specific host pools. If you give this permission at a resource group level, the admin will have read permission on all host pools under a resource group.

The following list describes which permissions this role can access:

• Microsoft.DesktopVirtualization/hostpools/read
• Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
• Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/*
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/deployments/read
• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Support/*

Session Host Operator

The Session Host Operator role lets you view and remove session hosts, as well as change drain mode. They can’t add session hosts using the Azure portal because they don’t have write permission for host pool objects. If the registration token is valid (generated and not expired), you can use this role to add session hosts to the host pool outside of Azure portal if the admin has compute permissions through the Virtual Machine Contributor role.

The following list describes which permissions this role can access:

Install Remote Desktop Session Host role service in Windows Server without Connection Broker role service

This article provides guidelines to install and configure the Remote Desktop Session Host role service on a computer that is running Windows Server 2019, Windows Server 2016, or Windows Server 2012 R2 without the Remote Desktop Connection Broker role service installed.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 2833839

Summary

When you create a standard deployment of Remote Desktop Services, the Remote Desktop Connection Broker role service provides access to the complete functionality of Remote Desktop Services. A configuration that does not use the RD Connection Broker role service provides desktop sessions to users based on the number of Remote Desktop Services client access licenses (RDS CALs) that are installed on the server. Such a configuration does not provide access to RemoteApp programs or the RDWeb website. Because a configuration without the RD Connection Broker role service does not provide access to all RDS functionality, you should use such a configuration only if there is no other option.

You can use the instructions in this article to configure RDS service by using a single server (either a member of a workgroup or a domain controller (DC)). If you have a separate DC, we recommend that you use the Standard Remote Desktop Services deployment wizard.

Configuring RDS on a workgroup server creates the following additional restrictions:

• You must use per-device licensing instead of per-user licensing. For more information, see License your RDS deployment with client access licenses (CALs).
• You must use Windows PowerShell to manage the RDS role services. This is because the Server Manager tools for RDS do not work. For more about using PowerShell cmdlets together with RDS, see Using Powershell to Install, Configure and Maintain RDS in Windows Server 2012.

For more information about the RDS roles, see Remote Desktop Services roles.

Process of deploying RDS service roles

The process of deploying RDS service roles on a single workgroup server or DC differs from that of deploying a standard RDS configuration on multiple computers.

Unless otherwise noted, these steps apply to both workgroup computer and DC cases.

If you are using a single computer as both the RDS server and as a DC, configure the computer as a DC before you begin installing the RDS roles. For more information about how to install Active Directory Domain Services (AD DS) and configure the computer as a DC in Windows Server 2016 or Windows Server 2012, see Install Active Directory Domain Services (Level 100).

On the workgroup computer or DC, install the Remote Desktop Licensing role service and the Remote Desktop Session Host role service. To do this, follow these steps:

1. Open Server Manager.
2. Click Manage and select Add Roles and Features.
3. Select Role-based or Feature-based installation.
4. Select the computer as the destination server.
5. On the Select server roles page, select Remote Desktop Services.
6. On the Select role services page, select the Remote Desktop Licensing and Remote Desktop Session Host role services.
7. Continue the installation. Select default values for the remaining settings.

DC step: Open Remote Desktop Licensing Manager, right-click the server, and then select Review Configuration.

Select Add to group.

If you have to manage group memberships manually, the Terminal Server License Servers group is located in the Built-in container in Active Directory Users and Computers.

Restart the Remote Desktop Services service.

Use one of the following methods to activate the RDS license server:

• To activate a Windows Server 2012 RDS license server, see Test Lab Guide: Remote Desktop Licensing.
• To activate a Windows Server 2016 RDS license server, see Activate the Remote Desktop Services license server.

Install the appropriate RDS CALs.

If you are using a workgroup server, you must use per-device CALs. For more information, see License your RDS deployment with client access licenses (CALs). For more information about how to install RDS CALs, see Install Remote Desktop Services Client Access Licenses.

Add the users that you want to allow to connect to the Remote Desktop Users group. To do this, use the following tools:

• To find the Remote Desktop Users group on a DC, open Active Directory Users and Computers and navigate to the Builtin container.
• To find the Remote Desktop Users group on a workgroup server, open Computer Management and then navigate to Local Users and Groups\Groups.

Change the local policy of the computer to add your remote desktop users to the Allow logon through Remote Desktop Services local policy object. To do this, follow these steps:

1. Open Local Security Policy.
2. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
3. Double-click Allow log on through Remote Desktop Services, and then select Add User or Group.
4. Type Remote Desktop Users (or the user names of each user account that you want to add, separated by semicolons), and then select OK two times.

Configure the Remote Desktop Session Host role service to use the local RDS license server.

Before you begin this procedure, make sure that the RDS license server is activated.

To do this, follow these steps:

Open an elevated Windows PowerShell Command Prompt window.

Run the following command:

To set the licensing mode, run the following command:

In this command, represents the licensing mode and is either 2 (if you are using per-device licensing) or 4 (if you are using per-user licensing). If you are using a workgroup server, you must use 2.

Run the following command:

To verify the settings, run the following command:

You should see the RDS licensing server name in the output. After you finish this step, users can start remote desktop sessions by using any supported RDS client.

DC step: To enable printer redirection to function correctly on a DC that is acting as the RDSH host, follow these additional steps.

Active Directory FSMO roles in Windows

This article mainly helps you to learn about the Flexible Single Master Operation (FSMO) roles in Active Directory.

Original product version: В Windows Server 2012 R2
Original KB number: В 197132

Summary

Active Directory is the central repository in which all objects in an enterprise and their respective attributes are stored. It’s a hierarchical, multi-master enabled database that can store millions of objects. Changes to the database can be processed at any given domain controller (DC) in the enterprise, regardless of whether the DC is connected or disconnected from the network.

Multi-master model

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise. But it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One-way Windows deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values. It’s done by resolving to the DC to which changes were written last, which is the last writer wins. The changes in all other DCs are discarded. Although this method may be acceptable in some cases, there are times when conflicts are too difficult to resolve using the last writer wins approach. In such cases, it’s best to prevent the conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows incorporates methods to prevent conflicting Active Directory updates from occurring.

Single-master model

To prevent conflicting updates in Windows, the Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates. It’s similar to the role given to a primary domain controller (PDC) in earlier versions of Windows, such as Microsoft Windows NT 3.51 and 4.0. In earlier versions of Windows, the PDC is responsible for processing all updates in a given domain.

Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any DC in the enterprise. Because an Active Directory role isn’t bound to a single DC, it’s referred to as an FSMO role. Currently in Windows there are five FSMO roles:

• Schema master
• Domain naming master
• RID master
• PDC emulator
• Infrastructure master

Schema master FSMO role

The schema master FSMO role holder is the DC responsible for performing updates to the directory schema, that is, the schema naming context or LDAP://cn=schema,cn=configuration,dc= . This DC is the only one that can process updates to the directory schema. Once the Schema update is complete, it’s replicated from the schema master to all other DCs in the directory. There’s only one schema master per directory.

Domain naming master FSMO role

The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory, that is, the Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC= . This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories.

RID master FSMO role

The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It’s also responsible for removing an object from its domain and putting it in another domain during an object move.

When a DC creates a security principal object, such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of:

• A domain SID that’s the same for all SIDs created in a domain.
• A relative ID (RID) that’s unique for each security principal SID created in a domain.

Each Windows DC in a domain is allocated a pool of RIDs that it’s allowed to assign to the security principals it creates. When a DC’s allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID master. The domain RID master responds to the request by retrieving RIDs from the domain’s unallocated RID pool, and assigns them to the pool of the requesting DC. There’s one RID master per domain in a directory.

PDC emulator FSMO role

The PDC emulator is necessary to synchronize time in an enterprise. Windows includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority. It doesn’t permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows domain, the PDC emulator role holder retains the following functions:

• Password changes done by other DCs in the domain are replicated preferentially to the PDC emulator.
• When authentication failures occur at a given DC because of an incorrect password, the failures are forwarded to the PDC emulator before a bad password failure message is reported to the user.
• Account lockout is processed on the PDC emulator.
• The PDC emulator performs all of the functionality that a Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary under the following situation:
All workstations, member servers, and domain controllers (DCs) that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000.

The PDC emulator still does the other functions as described in a Windows 2000 environment.

The following information describes the changes that occur during the upgrade process:

• Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package don’t perform directory writes (such as password changes) preferentially at the DC that has advertised itself as the PDC. They use any DC for the domain.
• Once backup domain controllers (BDCs) in down-level domains are upgraded to Windows 2000, the PDC emulator receives no down-level replica requests.
• Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package use the Active Directory to locate network resources. They don’t require the Windows NT Browser service.

Infrastructure master FSMO role

When an object in one domain is referenced by another object in another domain, it represents the reference by:

• The GUID
• The SID (for references to security principals)
• The DN of the object being referenced

The infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a cross-domain object reference.

The Infrastructure Master (IM) role should be held by a DC that is not a Global Catalog server(GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC’s event log.

If all the DCs in a domain also host the global catalog, all the DCs have the current data. It isn’t important which DC holds the infrastructure master role.

When the Recycle Bin optional feature is enabled, every DC is responsible to update its cross-domain object references when the referenced object is moved, renamed, or deleted. In this case, there are no tasks associated with the Infrastructure FSMO role. And it isn’t important which domain controller owns the Infrastructure Master role. For more information, see 6.1.5.5 Infrastructure FSMO Role.