Rediger

Prerequisites for Azure Virtual Desktop

  • Artikel
  • 10 minutter til læsning

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.

  1. Sign in to the Azure portal.
  2. Select Subscriptions.
  3. Select the name of your subscription.
  4. Select Resource providers.
  5. Search for Microsoft.DesktopVirtualization.
  6. If the status is NotRegistered, select Microsoft.DesktopVirtualization, and then select Register.
  7. 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:
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit
  • Windows Enterprise E3, E5
  • Windows VDA E3, E5
  • Windows Education A3, A5
External users can use per-user access pricing instead of license entitlement.
License entitlement:
  • Remote Desktop Services (RDS) Client Access License (CAL) with Software Assurance (per-user or per-device), or RDS User Subscription Licenses.
Per-user access pricing is not available for Windows Server operating systems.

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:

You can deploy virtual machines (VMs) to be used as session hosts from these images with any of the following methods:

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:

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.

Create a host pool with the Azure portal