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'll need:
- An Azure account with an active subscription
- An identity provider
- A supported operating system
- Appropriate licenses
- Network connectivity
- A Remote Desktop client
Azure account with an active subscription
You'll 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. Your account must be assigned the contributor or owner role on your subscription.
You also need to 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:
Important
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 Subscriptions.
- 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.
Identity
To access virtual desktops and remote apps from your session hosts, your users need to be able to authenticate. Azure Active Directory (Azure AD) is Microsoft's centralized cloud identity service that enables this capability. Azure AD is always used to authenticate users for Azure Virtual Desktop. Session hosts can be joined to the same Azure AD tenant, or to an Active Directory domain using Active Directory Domain Services (AD DS) or Azure Active Directory Domain Services (Azure AD DS), providing you with a choice of flexible configuration options.
Session hosts
You need to join session hosts that provide virtual desktops and remote apps to an AD DS domain, Azure AD DS domain, or the same Azure AD tenant as your users.
- If you're joining session hosts to an AD DS domain and you want to manage them using Intune, you'll need to configure Azure AD Connect to enable hybrid Azure AD join.
- If you're joining session hosts to an Azure AD DS domain, you can't manage them using Intune.
Users
Your users need accounts that are in Azure AD. If you're also using AD DS or Azure AD DS in your deployment of Azure Virtual Desktop, these accounts will need to be hybrid identities, which means the user account is synchronized. You'll need to keep the following things in mind based on which account you use:
- If you're using Azure AD with AD DS, you'll need to configure Azure AD Connect to synchronize user identity data between AD DS and Azure AD.
- If you're using Azure AD with Azure AD DS, user accounts are synchronized one way from Azure AD to Azure AD DS. 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 |
---|---|---|
Azure AD + AD DS | Joined to AD DS | In Azure AD and AD DS, synchronized |
Azure AD + AD DS | Joined to Azure AD | In Azure AD and AD DS, synchronized |
Azure AD + Azure AD DS | Joined to Azure AD DS | In Azure AD and Azure AD DS, synchronized |
Azure AD + Azure AD DS + AD DS | Joined to Azure AD DS | In Azure AD and AD DS, synchronized |
Azure AD + Azure AD DS | Joined to Azure AD | In Azure AD and Azure AD DS, synchronized |
Azure AD only | Joined to Azure AD | In Azure AD |
Note
If you're planning on using Azure AD only with FSLogix Profile Container, you will need to store profiles on Azure Files. In this scenario, user accounts must be hybrid identities, which means you'll also need AD DS and Azure AD Connect. You must create these accounts in AD DS and synchronize them to Azure AD. The service doesn't currently support environments where users are managed with Azure AD and synchronized to Azure AD DS.
Important
The user account must exist in the Azure AD tenant you use for Azure Virtual Desktop. Azure Virtual Desktop doesn't support B2B, B2C, or personal Microsoft accounts.
When using hybrid identities, either the UserPrincipalName (UPN) or the Security Identifier (SID) must match across Active Directory Domain Services and Azure Active Directory. For more information, see Supported identities and authentication methods.
Deployment parameters
You'll need to enter the following identity parameters when deploying session hosts:
- Domain name, if using AD DS or Azure AD DS.
- 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.
Important
The account you use for joining a domain can't have multi-factor authentication (MFA) enabled.
When joining an Azure AD DS domain, the account you use must be part of the AAD DC administrators group.
Operating systems and licenses
You have a choice of operating systems that you can use for session hosts to provide virtual desktops and remote apps. 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 |
---|---|
License entitlement:
|
|
License entitlement:
|
Important
Azure Virtual Desktop doesn't support 32-bit operating systems or SKUs not listed in the previous table.
Support for Windows 7 ended on January 10, 2023.
Ephemeral OS disks for Azure VMs are not supported.
You can use operating system images provided by Microsoft in the Azure Marketplace, or your own custom images stored in an Azure Compute Gallery, as a managed image, or storage blob. To learn more about how to create custom images, see:
- Store and share images in an Azure Compute Gallery.
- Create a managed image of a generalized VM in Azure.
- Prepare a Windows VHD or VHDX to upload to Azure.
You can deploy 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.
- Manually, in the Azure portal and adding to a host pool after you've created it.
- Programmatically, with Azure CLI, PowerShell, or REST API.
There are different automation and deployment options available depending on which operating system and version you choose, as shown in the following table:
Operating system | Azure Image Gallery | Manual VM deployment | Azure Resource Manager template integration | Deploy host pools from Azure Marketplace |
---|---|---|---|---|
Windows 11 Enterprise multi-session | Yes | Yes | Yes | Yes |
Windows 11 Enterprise | Yes | Yes | No | No |
Windows 10 Enterprise multi-session | Yes | Yes | Yes | Yes |
Windows 10 Enterprise | Yes | Yes | No | No |
Windows Server 2022 | Yes | Yes | No | No |
Windows Server 2019 | Yes | Yes | Yes | Yes |
Windows Server 2016 | Yes | Yes | No | No |
Windows Server 2012 R2 | Yes | Yes | No | No |
Tip
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.
Network
There are several network requirements you'll need to meet to successfully deploy Azure Virtual Desktop. This lets users connect to their virtual desktops and remote apps 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'll need to meet the following network requirements:
You'll 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 Azure AD DS, since you'll 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 may 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.
Note
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.
To learn more, see Understanding Azure Virtual Desktop network connectivity.
Session host management
Consider the following when managing session hosts:
Don't enable any policies or configurations that disable Windows Installer. If you disable Windows Installer, the service won't be able to install agent updates on your session hosts, and your session hosts won't function properly.
If you're using Azure AD-join with Windows Server for your session hosts, you can't enroll them in Intune as Windows Server is not supported with Intune. You'll need to use hybrid Azure AD-join and Group Policy from an Active Directory domain, or local Group Policy on each session host.
Remote Desktop clients
Your users will need a Remote Desktop client to connect to virtual desktops and remote apps. The following clients support Azure Virtual Desktop:
- Windows Desktop client
- Web client
- macOS client
- iOS and iPadOS client
- Android and Chrome OS client
- Microsoft Store client
Important
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.
Next steps
Get started with Azure Virtual Desktop by creating a host pool. Head to the following tutorial to find out more.
Feedback
Indsend og få vist feedback om