Azure Virtual Desktop FAQ

If you want to create host pools and other objects, you must be assigned the Contributor role on the subscription or resource group you're working with.

You must be assigned the User Access Admin role on an application group to publish application groups to users or user groups.

To restrict an admin to only manage user sessions, such as sending messages to users, signing out users, and so on, you can create custom roles. For example:

{
    "actions": [
        "Microsoft.Resources/deployments/operations/read",
        "Microsoft.Resources/tags/read",
        "Microsoft.Authorization/roleAssignments/read",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/*",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/write"
    ],
    "notActions": [],
    "dataActions": [],
    "notDataActions": []
}

Users must be in the same Microsoft Entra tenant as their assigned workspace, host pool, and app group. Having everything in the same tenant lets you assign users to proper role-based access control (RBAC) roles so they can access their resources.

However, you can deploy virtual machines (VMs) in a different Microsoft Entra tenant if they're joined to either the same AD as the user or an AD that has a trust relationship with the user's AD.

All service resources have a location associated with them. A host pool's location determines which geography the service metadata for the host pool is stored in. An application group can't exist without a host pool. If you add apps to a RemoteApp application group, you also need a session host to determine the start menu apps. For any application group action, you'll also need a related data access on the host pool. To make sure data isn't being transferred between multiple locations, the application group's location should be the same as the host pool's.

Workspaces also must be in the same location as their application groups. Whenever the workspace updates, the related application group updates along with it. Like with application groups, the service requires that all workspaces are associated with application groups created in the same location.

When you run a PowerShell cmdlet, you only see the resource name and location.

For example:

Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg

Location Name   Type
-------- ----   ----
westus   0224hp Microsoft.DesktopVirtualization/hostpools

To see all of a resource's properties, add either format-list or fl to the end of the cmdlet.

For example:

Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg |fl

To see specific properties, add the specific property names after format-list or fl.

For example:

Get-AzWvdHostPool -Name demohp -ResourceGroupName 0414rg |fl CustomRdpProperty

CustomRdpProperty : audiocapturemode:i:0;audiomode:i:0;drivestoredirect:s:;redirectclipboard:i:1;redirectcomports:i:0;redirectprinters:i:1;redirectsmartcards:i:1;screen modeid:i:2;

Azure Virtual Desktop doesn't support Microsoft Entra guest user accounts. For example, let's say a group of guest users have Microsoft 365 E3 Per-user, Windows E3 Per-user, or WIN VDA licenses in their own company, but are guest users in a different company's Microsoft Entra ID. The other company would manage the guest users' user objects in both Microsoft Entra ID and Active Directory like local accounts.

You can't use your own licenses for the benefit of a third-party. Also, Azure Virtual Desktop doesn't currently support Microsoft Account (MSA).

We don't currently have a reliable way to collect the web client's IP addresses, so we don't include that value in the table.

There are multiple options in Azure Virtual Desktop for handling backup. At the Compute level, backup is recommended only for Personal Host Pools through Azure Backup. At the Storage level, recommended backup solution varies based on the backend storage used to store user profiles. If Azure Files Share is used, Azure Backup for File Share is recommended. If Azure NetApp Files is used, Snaphots/Policies or Azure NetApp Files Backup are tools available.

Azure Virtual Desktop is currently optimized for Teams. Microsoft currently doesn't support third-party collaboration apps like Zoom. Third-party organizations are responsible for giving compatibility guidelines to their customers. Azure Virtual Desktop also doesn't support Skype for Business.

Once you create a host pool, you can't change its type. However, you can move any VMs you register to a host pool to a different type of host pool.

These factors can affect scale limit for host pools:

• The Azure template is limited to 800 objects. To learn more, see Azure subscription and service limits, quotas, and constraints. Each VM also creates about six objects, so that means you can create around 132 VMs each time you run the template.

• There are restrictions on how many vCPUs you can create per region and per subscription. For example, if you have an Enterprise Agreement subscription, by default you can create 350 vCPUs. You need to divide 350 by either the default number of vCPUs per VM or your own vCPU limit to determine how many VMs you can create each time you run the template. Learn more at Virtual Machines limits - Azure Resource Manager and Check vCPU quotas.

• The VM prefix name can't exceed 11 characters, so that when a sequential number is added the total name is a maximum of 15 characters. To learn more, see Naming rules and restrictions for Azure resources.

Azure Lighthouse doesn't fully support managing Azure Virtual Desktop environments. Since Lighthouse doesn't currently support cross-Microsoft Entra ID tenant user management, Lighthouse customers still need to sign in to the Microsoft Entra ID that customers use to manage users.

You also can't use CSP sandbox subscriptions with the Azure Virtual Desktop service. To learn more, see Integration sandbox account.

Finally, if you enabled the resource provider from the CSP owner account, the CSP customer accounts aren't able to modify the resource provider.

After you register a VM to a host pool within the Azure Virtual Desktop service, the agent regularly refreshes the VM's token whenever the VM is active. The certificate for the registration token is valid for 90 days. Because of this 90-day limit, we recommend VMs to be online for 20 minutes every 90 days so that the machine can refresh its tokens and update the agent and side-by-side stack components. Turning on your VM within this time limit prevents its registration token from expiring or becoming invalid. If you started your VM after 90 days and are experiencing registration issues, follow the instructions in the Azure Virtual Desktop agent troubleshooting guide to remove the VM from the host pool, reinstall the agent, and reregister it to the pool.

Yes. Azure Virtual Desktop host pools have an option for selecting either availability set or availability zones when you create a VM. These availability options are the same as the ones Azure Compute uses. If you select a zone for the VM you create in a host pool, the setting automatically applies to all VMs you create in that zone. If you'd prefer to spread your host pool VMs across multiple zones, you need to follow the directions in Add virtual machines with the Azure portal to manually select a new zone for each new VM you create.

Make sure that Azure availability zones are available in the region where your VMs are located.

The availability option you should use for your VMs depends on your image's location. The following table explains the relationship each setting has with these variables to help you figure out which option is best for your deployment.

We recommend you use Windows Defender Application Control instead of AppLocker.

Yes. You can have both deployments within the same Microsoft Entra tenant.

No. Ephemeral OS disks for Azure VMs aren't supported with Azure Virtual Desktop.

Metadata of a host pool is replicated within a geography for resiliency. If the region your host pool is in goes down, it fails over to its replica. During this failover period, Azure Virtual Desktop doesn't accept new user connections to the session host VMs in that host pool until the failover is complete. Any existing sessions on the session host VMs in that host pool remain connected and unaffected. To learn more about how service resilience is implemented for Azure Virtual Desktop, see Azure Virtual Desktop service architecture and resilience.

If you try to go over 200 VMs in an availability set in Azure Virtual Desktop, you receive an error message that says "Can't create VM because the limit of 200 VMs has already been reached." For more information, see the Availability sets overview.

Session hosts in a pooled host pool aren't supported for in-place upgrade. Session hosts in a personal host pool are supported for in-place upgrade. For more information, see In-place upgrade for supported VMs running Windows in Azure and In-place upgrade for VMs running Windows Server in Azure.