In my last blog I covered off an overview of Azure Virtual Desktop (AVD) which is a combination of both IaaS and PaaS cloud service models, touching on the benefits of virtualization, use-cases, what AVD is at its core along with key benefits and the licensing/eligibility criteria.

One of the key benefits of AVD in that article was an intuitive user experience, which provides the ability for your users to connect into the platform, which in a nutshell is the AVD control plane that is hosted and managed by Microsoft, which then directs you into your session hosts so your users can access what they need to do their job (their applications and/or desktops), this is from any platform and any location, at any-time with a modern experience that most users are familiar with as if they were just working off a personal device of their own.

One of the key differences with this in contrast to something like Remote Desktop Services (RDS) is that we don’t need to setup, manage, or worry about those connectivity components, that being how the users are connecting into AVD. This is because it’s the same experience as what you’d be used to with other Microsoft 365 services, like Outlook, SharePoint, and OneDrive, where you simply enter your Azure Active Directory (Azure AD) credentials (which may or may not be sync’d to traditional Active Directory (AD)), be promoted for another factor of authentication via MFA, and then you’re presented with the relevant resources. This is the same with AVD, where unless you have a specific requirement with on-premises connectivity, you don’t need a VPN Gateway or similar for your users to access your AVD resources in Azure.

How exactly though you might be asking? Well first off, to access your AVD virtual desktops and/or remote apps from your session hosts, your users need to be able to authenticate. Azure AD enables this capability. Azure AD is always used to authenticate users for AVD in the first instance. Session hosts can be joined to the same Azure AD tenant, or to an AD 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. If you haven't enabled single sign-on or saved your credentials locally, you'll also need to authenticate to the session host when launching a connection.

The users connecting to AVD 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. Unlike the on-premises Remote Desktop Services deployments, reverse connect transport doesn't use a TCP listener to receive incoming RDP connections. Instead, it is using outbound connectivity to the AVD infrastructure over the HTTPS connection.

Upon startup of the AVD session host, the Remote Desktop Agent Loader service establishes the AVD broker's persistent communication channel. This communication channel is layered on top of a secure Transport Layer Security (TLS) connection and serves as a bus for service message exchange between session hosts and AVD infrastructure. TLS 1.2 is used for all connections initiated from the clients and session hosts to the AVD infrastructure components.

 

Below is what a client connection sequence would look like:

  1. Using a supported Azure Virtual Desktop client, a user subscribes to the AVD Workspace
  2. Azure AD authenticates the user and returns the token used to enumerate resources available to a user
  3. Client passes token to the AVD feed subscription service
  4. AVD feed subscription service validates the token
  5. AVD feed subscription service passes the list of available desktops and apps back to the client in the form of digitally signed connection configuration
  6. Client stores the connection configuration for each available resource in a set of .rdp files
  7. When a user selects the resource to connect, the client uses the associated .rdp file and establishes the secure TLS 1.2 connection to an AVD gateway instance with the help of Azure Front Door and passes the connection information. The latency from all gateways is evaluated, and the gateways are put into groups of 10ms. The gateway with the lowest latency and then lowest number of existing connections is chosen.
  8. AVD gateway validates the request and asks the AVD broker to orchestrate the connection
  9. AVD broker identifies the session host and uses the previously established persistent communication channel to initialize the connection
  10. Remote Desktop stack initiates the TLS 1.2 connection to the same AVD gateway instance as used by the client
  11. After both client and session host are connected to the gateway, the gateway starts relaying the raw data between both endpoints, this establishes the base reverse connect transport for the RDP
  12. After the base transport is set, the client starts the RDP handshake

 

 

 

Optionally, since I’ve subscribed to the Workspace, I can launch my desktop or apps via the Start Menu (these can also be pinned to the Task Bar):

 

 

 

 

 

 

 

 

 

 

 

 

The app appears as if it was running locally, which could be pinned to the Task Bar and launched from there:

If you’d like to see a demo for yourself or chat some more about AVD or anything Azure related, then please reach out to myself or the Azure team here at Dicker Data.