Prerequisites for Azure Virtual Desktop
There are a few things you need to start using Azure Virtual Desktop. Here you can find what prerequisites you need to complete to successfully provide your users with desktops and applications.
At a high level, you need:
- An Azure account with an active subscription
- A supported identity provider
- A supported operating system for session host virtual machines
- Appropriate licenses
- Network connectivity
- A Remote Desktop client
Azure account with an active subscription
You need an Azure account with an active subscription to deploy Azure Virtual Desktop. If you don't have one already, you can create an account for free.
To deploy Azure Virtual Desktop, you need to assign the relevant Azure role-based access control (RBAC) roles. The specific role requirements are covered in each of the related articles for deploying Azure Virtual Desktop, which are listed in the Next steps section.
Also make sure you've registered the Microsoft.DesktopVirtualization resource provider for your subscription. To check the status of the resource provider and register if needed, select the relevant tab for your scenario and follow the steps.
You must have permission to register a resource provider, which requires the
*/register/action operation. This is included if your account is assigned the contributor or owner role on your subscription.
Sign in to the Azure portal.
Select the name of your subscription.
Select Resource providers.
Search for Microsoft.DesktopVirtualization.
If the status is NotRegistered, select Microsoft.DesktopVirtualization, and then select Register.
Verify that the status of Microsoft.DesktopVirtualization is Registered.
To access desktops and applications from your session hosts, your users need to be able to authenticate. Microsoft Entra ID is Microsoft's centralized cloud identity service that enables this capability. Microsoft Entra ID is always used to authenticate users for Azure Virtual Desktop. Session hosts can be joined to the same Microsoft Entra tenant, or to an Active Directory domain using Active Directory Domain Services (AD DS) or Microsoft Entra Domain Services, providing you with a choice of flexible configuration options.
You need to join session hosts that provide desktops and applications to the same Microsoft Entra tenant as your users, or an Active Directory domain (either AD DS or Microsoft Entra Domain Services).
To join session hosts to Microsoft Entra ID or an Active Directory domain, you need the following permissions:
For Microsoft Entra ID, you need an account that can join computers to your tenant. For more information, see Manage device identities. To learn more about joining session hosts to Microsoft Entra ID, see Microsoft Entra joined session hosts.
For an Active Directory domain, you need a domain account that can join computers to your domain. For Microsoft Entra Domain Services, you would need to be a member of the AAD DC Administrators group.
Adding session hosts on Azure Stack HCI only supports using Active Directory Domain Services.
Your users need accounts that are in Microsoft Entra ID. If you're also using AD DS or Microsoft Entra Domain Services in your deployment of Azure Virtual Desktop, these accounts need to be hybrid identities, which means the user accounts are synchronized. You need to keep the following things in mind based on which identity provider you use:
- If you're using Microsoft Entra ID with AD DS, you need to configure Microsoft Entra Connect to synchronize user identity data between AD DS and Microsoft Entra ID.
- If you're using Microsoft Entra ID with Microsoft Entra Domain Services, user accounts are synchronized one way from Microsoft Entra ID to Microsoft Entra Domain Services. This synchronization process is automatic.
Supported identity scenarios
The following table summarizes identity scenarios that Azure Virtual Desktop currently supports:
|Identity scenario||Session hosts||User accounts|
|Microsoft Entra ID + AD DS||Joined to AD DS||In Microsoft Entra ID and AD DS, synchronized|
|Microsoft Entra ID + AD DS||Joined to Microsoft Entra ID||In Microsoft Entra ID and AD DS, synchronized|
|Microsoft Entra ID + Microsoft Entra Domain Services||Joined to Microsoft Entra Domain Services||In Microsoft Entra ID and Microsoft Entra Domain Services, synchronized|
|Microsoft Entra ID + Microsoft Entra Domain Services + AD DS||Joined to Microsoft Entra Domain Services||In Microsoft Entra ID and AD DS, synchronized|
|Microsoft Entra ID + Microsoft Entra Domain Services||Joined to Microsoft Entra ID||In Microsoft Entra ID and Microsoft Entra Domain Services, synchronized|
|Microsoft Entra-only||Joined to Microsoft Entra ID||In Microsoft Entra ID|
To use FSLogix Profile Container when joining your session hosts to Microsoft Entra ID, you need to store profiles on Azure Files or Azure NetApp Files and your user accounts must be hybrid identities. You must create these accounts in AD DS and synchronize them to Microsoft Entra ID. To learn more about deploying FSLogix Profile Container with different identity scenarios, see the following articles:
- Set up FSLogix Profile Container with Azure Files and Active Directory Domain Services or Microsoft Entra Domain Services.
- Set up FSLogix Profile Container with Azure Files and Microsoft Entra ID.
- Set up FSLogix Profile Container with Azure NetApp Files
When using hybrid identities, either the UserPrincipalName (UPN) or the Security Identifier (SID) must match across Active Directory Domain Services and Microsoft Entra ID. For more information, see Supported identities and authentication methods.
You need to enter the following identity parameters when deploying session hosts:
- Domain name, if using AD DS or Microsoft Entra Domain Services.
- Credentials to join session hosts to the domain.
- Organizational Unit (OU), which is an optional parameter that lets you place session hosts in the desired OU at deployment time.
The account you use for joining a domain can't have multi-factor authentication (MFA) enabled.
Operating systems and licenses
You have a choice of operating systems (OS) that you can use for session hosts to provide desktops and applications. You can use different operating systems with different host pools to provide flexibility to your users. We support the following 64-bit versions of these operating systems, where supported versions and dates are inline with the Microsoft Lifecycle Policy.
|Operating system||User access rights|
The following items are not supported:
Support for Windows 7 ended on January 10, 2023.
Support for Windows Server 2012 R2 ended on October 10, 2023. For more information, view SQL Server 2012 and Windows Server 2012/2012 R2 end of support.
For Azure, you can use operating system images provided by Microsoft in the Azure Marketplace, or create your own custom images stored in an Azure Compute Gallery or as a managed image. Using custom image templates for Azure Virtual Desktop enables you to easily create a custom image that you can use when deploying session host virtual machines (VMs). To learn more about how to create custom images, see:
- Custom image templates in Azure Virtual Desktop
- Store and share images in an Azure Compute Gallery.
- Create a managed image of a generalized VM in Azure.
Alternatively, for Azure Stack HCI you can use operating system images from:
- Azure Marketplace. For more information, see Create Azure Stack HCI VM image using Azure Marketplace images.
- Azure Storage account. For more information, see Create Azure Stack HCI VM image using image in Azure Storage account.
- A local share. For more information, seeCreate Azure Stack HCI VM image using images in a local share.
You can deploy a virtual machines (VMs) to be used as session hosts from these images with any of the following methods:
- Automatically, as part of the host pool setup process in the Azure portal.
- Manually by adding session hosts to an existing host pool in the Azure portal.
- Programmatically, with Azure CLI or Azure PowerShell.
If your license entitles you to use Azure Virtual Desktop, you don't need to install or apply a separate license, however if you're using per-user access pricing for external users, you need to enroll an Azure Subscription. You need to make sure the Windows license used on your session hosts is correctly assigned in Azure and the operating system is activated. For more information, see Apply Windows license to session host virtual machines.
For session hosts on Azure Stack HCI, you must license and activate the virtual machines you use before you use them with Azure Virtual Desktop. For activating Windows 10 and Windows 11 Enterprise multi-session, and Windows Server 2022 Datacenter: Azure Edition, use Azure verification for VMs. For all other OS images (such as Windows 10 and Windows 11 Enterprise, and other editions of Windows Server), you should continue to use existing activation methods. For more information, see Activate Windows Server VMs on Azure Stack HCI.
To simplify user access rights during initial development and testing, Azure Virtual Desktop supports Azure Dev/Test pricing. If you deploy Azure Virtual Desktop in an Azure Dev/Test subscription, end users may connect to that deployment without separate license entitlement in order to perform acceptance tests or provide feedback.
There are several network requirements you need to meet to successfully deploy Azure Virtual Desktop. This lets users connect to their desktops and applications while also giving them the best possible user experience.
Users connecting to Azure Virtual Desktop securely establish a reverse connection to the service, which means you don't need to open any inbound ports. Transmission Control Protocol (TCP) on port 443 is used by default, however RDP Shortpath can be used for managed networks and public networks that establishes a direct User Datagram Protocol (UDP)-based transport.
To successfully deploy Azure Virtual Desktop, you need to meet the following network requirements:
You need a virtual network and subnet for your session hosts. If you create your session hosts at the same time as a host pool, you must create this virtual network in advance for it to appear in the drop-down list. Your virtual network must be in the same Azure region as the session host.
Make sure this virtual network can connect to your domain controllers and relevant DNS servers if you're using AD DS or Microsoft Entra Domain Services, since you need to join session hosts to the domain.
Your session hosts and users need to be able to connect to the Azure Virtual Desktop service. These connections also use TCP on port 443 to a specific list of URLs. For more information, see Required URL list. You must make sure these URLs aren't blocked by network filtering or a firewall in order for your deployment to work properly and be supported. If your users need to access Microsoft 365, make sure your session hosts can connect to Microsoft 365 endpoints.
Also consider the following:
Your users might need access to applications and data that is hosted on different networks, so make sure your session hosts can connect to them.
Round-trip time (RTT) latency from the client's network to the Azure region that contains the host pools should be less than 150 ms. Use the Experience Estimator to view your connection health and recommended Azure region. To optimize for network performance, we recommend you create session hosts in the Azure region closest to your users.
Use Azure Firewall for Azure Virtual Desktop deployments to help you lock down your environment and filter outbound traffic.
To help secure your Azure Virtual Desktop environment in Azure, we recommend you don't open inbound port 3389 on your session hosts. Azure Virtual Desktop doesn't require an open inbound port to be open. If you must open port 3389 for troubleshooting purposes, we recommend you use just-in-time VM access. We also recommend you don't assign a public IP address to your session hosts.
To learn more, see Understanding Azure Virtual Desktop network connectivity.
To keep Azure Virtual Desktop reliable and scalable, we aggregate traffic patterns and usage to check the health and performance of the infrastructure control plane. We aggregate this information from all locations where the service infrastructure is, then send it to the US region. The data sent to the US region includes scrubbed data, but not customer data. For more information, see Data locations for Azure Virtual Desktop.
Session host management
Consider the following points when managing session hosts:
Don't enable any policies or configurations that disable Windows Installer. If you disable Windows Installer, the service can't install agent updates on your session hosts, and your session hosts won't function properly.
If you're joining session hosts to a Microsoft Entra Domain Services domain, you can't manage them using Intune.
If you're using Microsoft Entra join with Windows Server for your session hosts, you can't enroll them in Intune as Windows Server isn't supported with Intune. You need to use Microsoft Entra hybrid join and Group Policy from an Active Directory domain, or local Group Policy on each session host.
You can deploy session hosts in any Azure region to use with Azure Virtual Desktop. For host pools, workspaces, and application groups, you can deploy them in the following Azure regions:
- Australia East
- Canada Central
- Canada East
- Central India
- Central US
- East US
- East US 2
- Japan East
- North Central US
- North Europe
- South Central US
- UK South
- UK West
- West Central US
- West Europe
- West US
- West US 2
- West US 3
This list of regions is where the metadata for the host pool can be stored. However, session hosts can be located in any Azure region, and on-premises when using Azure Virtual Desktop on Azure Stack HCI. For more information about the types of data and locations, see Data locations for Azure Virtual Desktop.
To learn more about the architecture and resilience of the Azure Virtual Desktop service, see Azure Virtual Desktop service architecture and resilience.
Remote Desktop clients
Your users need a Remote Desktop client to connect to desktops and applications. The following clients support Azure Virtual Desktop:
- Windows Desktop client
- Azure Virtual Desktop Store app for Windows
- Web client
- macOS client
- iOS and iPadOS client
- Android and Chrome OS client
- Remote Desktop app for Windows
Azure Virtual Desktop doesn't support connections from the RemoteApp and Desktop Connections (RADC) client or the Remote Desktop Connection (MSTSC) client.
To learn which URLs clients use to connect and that you must allow through firewalls and internet filters, see the Required URL list.
For a simple way to get started with Azure Virtual Desktop by creating a sample infrastructure, see Tutorial: Deploy a sample Azure Virtual Desktop infrastructure with a Windows 11 desktop.
For a more in-depth and adaptable approach to deploying Azure Virtual Desktop, see Deploy Azure Virtual Desktop.