BYOL Windows Server: You are eligible to access Windows Server with Azure Virtual Desktop if you have a per-user or per-device RDS CAL license with active Software Assurance (SA).

Per user access pricing for external users: You can also pay a monthly per-user fee to access Azure Virtual Desktop for external users.

Operating system storage: For optimal performance, it is recommended that you use premium SSD storage for the Azure Virtual Desktop session host’s operating system disk for production workloads. The operating system disk size depends on the operating system and applications installed on the C: drive.

Windows Desktop clients

Web clients

Android clients

macOS clients

iOS clients

Linux or thin clients

Domain-joined user device (automated deployment): SCCM can be used to push the Azure Virtual Desktop client on the end-user device, or the client can be published in the software center so that authorized users can deploy it on their devices/laptops. Alternatively, AD Group Policy can be used to deploy the Azure Virtual Desktop client on an end user’s laptop using a logon script, and Group Policy can be assigned to the security group created for each host pool.

Nondomain-joined user device (automated deployment): An appropriate Azure Virtual Desktop client can be downloaded from a Microsoft site/other app store and installed on the user laptop/device manually.

You need a separate virtual network with dedicated subnets for each host pool (pooled and personal) in each region, and you need to peer AVD vnet with hub virtual network in that region.

You need a dedicated user profile storage for each pooled host pool.

User profile storage access is restricted to a specific virtual network/subnet.

Enable storage account access over a private endpoint from the virtual network.

The same type of host pool in the same region (i.e. belongs to the same Business Unit) can use the same storage account for a user profile as far as there is no compliance/information security requirements.

The storage account needs to join to the domain and allow specific users/groups to access the content.

Consider GEO replication to a DR region if you are planning to enable disaster recovery for the pooled host pool. Premium file storage does not support GEO replication, so if you want to implement DR, then you must select the standard storage account tier or use an FSLogix cloud cache to store a user profile on multiple storage accounts in different regions.

How many IP addresses do you need in your virtual network (based on the size of Azure Virtual Desktop virtual network)?

Will your workloads require connectivity between virtual networks and your on-premises datacenter?

Will you need to inspect and audit outgoing traffic by using on-premises network devices?

Do you need multiple virtual networks?

Do you need to connect multiple virtual networks?

Will you need custom DNS and a domain join?

Azure Virtual Desktop users must be sourced from either the same instance of on-premises Active Directory Domain Services that is synchronized to Azure Active Directory (Azure AD) and the session host needs to be joined to same Active Directory Domain Services (AD DS), or an instance of Azure AD Domain Services (Azure AD DS) synchronized from Azure AD.

A domain join account can’t have multifactor authentication or interactive prompts, and it needs permission on the ADDS OU to add a computer account.

Azure Virtual Desktop supports AD DS or Azure AD DS, and an appropriate identity provider needs to be selected based on the application requirement.

When joining to an Azure AD DS domain, the account must be part of the Azure AD DC administrators’ group, and the account password must work in Azure AD DS.

Always specify an organizational unit distinguished name (DN) for domain joining without quotation marks.

The user principal name used to subscribe to Azure Virtual Desktop must exist in the Active Directory domain where the session host virtual machine is joined.

Smart cards and Windows Hello authentication need a direct connection (line of sight) with an Active Directory domain controller for Kerberos.

Using Windows Hello for Business requires the hybrid certificate trust model to be compatible with Azure Virtual Desktop.

Single sign-on can improve user experience, but it requires additional configuration and is supported only using Active Directory Federation Services.

Use Azure AD Connect to synchronize all identities to a single Azure AD tenant.

Ensure Azure Virtual Desktop session hosts can communicate with Azure AD DS or AD DS.

Use the least privilege principle to assign the minimum permissions needed for authorized tasks.

Segregate session host virtual machines into Active Directory organization units for each host pool to manage policies and orphaned objects more easily.

Use a solution like Local Administrator Password Solution (LAPS) to rotate local administrator passwords on Azure Virtual Desktop session hosts frequently.

Create conditional access policies for Azure Virtual Desktop. Such policies can enforce multifactor authentication based on conditions such as risky sign-ins to increase an organization’s security posture.

Configure AD FS to enable single sign-on for users on the corporate network.

Active Directory Domain Services (AD DS) : This is a traditional Lightweight Directory Access Protocol (LDAP) server that provides key features such as identity and authentication, computer object management, Group Policy, and trusts. AD DS is a service available in Windows Server, and many organizations are already using it as the central component in their on-premises datacenter. Azure Virtual Desktop supports an on-premises ADDS service, and you can either directly sync on-premises AD DS with Azure AD or extend it in Azure and then sync it with Azure AD to avoid authentication and sync traffic going over VPN/ER. Extended AD DS server in Azure can be used for domain joins and AVD desktop authentication as well.

Azure Active Directory (Azure AD): Azure AD is a cloud-based identity and mobile device management (MDM) provider that gives the ability to create user account and authenticate services for resources such as Microsoft 365, the Azure portal, and software-as-a-service applications. On-premises AD DS can be synchronized with Azure AD to provide a single-user identity across the organization. Azure AD is required for authentication, but it needs to be synced with on-premises AD DS or Azure AD DS.

Azure Active Directory Domain Services (Azure AD DS): Azure AD DS consists of managed domain services the same as traditional AD DS with features such as domain joins, Group Policy, LDAP, and Kerberos/NTLM authentication with a minimal amount of administrative overhead (but limited admin permission; refer to Azure AD DS). Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS. This ability extends central identity use cases. Azure AD DS is one of the best options supported by Azure Virtual Desktop if you don’t have any directory solution in place or if you want to set up isolated AVD POC.

Managed domain (Azure AD DS): Microsoft manages the required resources for Azure AD DS, and you can still use all the traditional AD DS features such as domain joins, Group Policy, LDAP, and Kerberos/NTLM authentication. You don’t deploy, manage, patch, and secure the Azure AD DS infrastructure for components such as Windows Server OS or domain controller (DC) VMs. See Figure 3-3.

A self-managed domain (AD DS service on VM): You can create and configure traditional AD DS on Azure virtual machines (VMs) with Windows Server guest OS, and you can use Active Directory Domain Services (AD DS) to extend your on-premises AD DS to the cloud or use on-premises AD DS as is for cloud as well. There’s additional maintenance overhead with a self-managed AD DS environment, but you have ability to do additional tasks such as extend the schema or create forest trusts. See Figure 3-4.

Stand-alone cloud-only AD DS: This option is mostly used when you don’t have on-premises AD DS and just want to create new self-managed AD DS for the Azure cloud. Azure VMs can be configured as domain controllers to create a cloud-only AD DS environment.

Resource forest deployment: This option is mostly used when you have an on-premises AD DS forest and just want to create a new AD DS domain in an existing on-premises forest for the Azure cloud. Azure VMs can be configured as domain controllers and AD DS domains as part of the existing on-premises forest. A trust relationship is then configured to an on-premises AD DS environment so that other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN/ExpressRoute connection to the on-premises AD DS environment.

Extend on-premises domain to Azure: This option is mostly used when you have an on-premises AD DS domain and forest and just want to add a cloud-based domain controller in an existing on-premises domain. An Azure virtual network needs to be connected to an on-premises network using a VPN/ExpressRoute connection for this model as well. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.

All domain controller replication traffic flows over a site-to-site VPN/ER.

A cloud-extended domain controller can be used for authentication instead of sending traffic on-premises when using pass-through authentication.

By default, the Azure AD Connect sync server configures password hash synchronization between the on-premises domain and Azure AD, and the Azure AD service assumes that users authenticate by providing the same password that they use on-premises. The security policy of organization may prohibit synchronizing password hashes to the cloud. In this case, your organization should consider pass-through authentication.

Azure AD tenant: An instance of Azure AD created by organization. It acts as a directory service for cloud applications by storing objects copied from the on-premises Active Directory and provides identity services.

On-premises AD DS server: An on-premises directory and identity service. The AD DS directory can be synchronized with Azure AD to enable it to authenticate on-premises users.

Azure AD Connect sync server: A computer that runs the Azure AD Connect sync service. This service synchronizes information held in the on-premises Active Directory to Azure AD. For example, if you provision or deprovision groups and users on-premises, these changes propagate to Azure AD.

User authentication: By default, the Azure AD Connect sync server configures password hash synchronization between the on-premises domain and Azure AD, and the Azure AD service assumes that users authenticate by providing the same password that they use on-premises. For many organizations, this is appropriate, but if your organization’s security policy prohibits synchronizing password hashes to the cloud, then you should consider pass-through authentication. Alternatively, you can configure Azure AD to use Active Directory Federation Services (AD FS) or a third-party federation provider to implement authentication and SSO rather than by using the password information held in the cloud.