On the Monday after a company moved 80 employees to remote desktops, the help desk got 40 tickets before 9 a.m. Half said “I signed in, but I see nothing.” The others said “it asks for a password again and again.” The desktops were fine. The problems were all on the connection path: users who were never assigned to a desktop, a client that was out of date, and a Conditional Access rule nobody had tested.
If you need to connect to Azure Virtual Desktop, whether you are an end user or the admin supporting them, the process is simple once you know what must be true before the first click. This guide covers the user steps for every device, the admin setup that makes those steps work, security and cost choices that affect connection, and a troubleshooting section you can use when things go wrong.
What Must Be in Place First
A user connects to a session host, which is an Azure virtual machine that runs the desktop or apps. Before anyone can connect, four things must exist:
- A host pool with at least one available session host. A host pool is a group of session hosts. If every host is shut down or in a failed state, users have nowhere to land. Read what Azure Virtual Desktop is if the service is new to you.
- An application group assigned to the user. An application group publishes a full desktop or specific apps. Users only see what is assigned to them.
- A workspace. This is the list of resources that the client shows after sign-in.
- A user account in Microsoft Entra ID with the right license. Entra ID is Microsoft’s identity service. See Microsoft Entra ID basics for background.
If any of these is missing, the user either sees an empty list or cannot sign in. Admins should confirm all four before sending instructions to staff.
Pro Tip: In my experience, most day-one tickets disappear when I test with a plain user account, not my admin account. Admins often have extra permissions that hide the exact problem users hit.
How to Connect to Azure Virtual Desktop From Any Device
Microsoft provides several clients. The right one depends on the device and how much you want to install. For more detail on options, see the Azure Virtual Desktop client guide.
| Client | Best for | Notes |
|---|---|---|
| Windows App or Remote Desktop client | Windows PCs used daily | Best performance and device redirection |
| Web client | Quick access from any browser | No install; fewer redirection features |
| macOS client | Mac users | Native app |
| iOS and Android clients | Phones and tablets | Good for light use |
| ChromeOS client | Chromebooks | Available through the app store |
Microsoft has been moving users toward the newer Windows App, which is replacing the older Remote Desktop client for many scenarios. Both work with Azure Virtual Desktop, but your organization may standardize on one, so follow your IT team’s guidance.
Connect With the Windows or Mac Client
- Install the client from your organization’s software portal or the official app store.
- Open the app and choose Sign in or Subscribe.
- Enter your work email address and approve any multifactor authentication (MFA) prompt. MFA adds a second proof of identity, such as a phone approval. If you have trouble with it, see what MFA is.
- After sign-in, your workspace shows the desktops and apps assigned to you.
- Double-click a desktop or app. Enter your credentials again if the session host asks.
- Wait for the session to load. The first logon is often slower because your profile is created.
Connect With the Web Client
- Open a modern browser and go to the web client address your IT team provides.
- Sign in with your work account and complete MFA.
- Select the desktop or app tile.
- Allow the browser prompts for clipboard or file access if you need them.
The web client is handy on shared or unmanaged devices because nothing is installed. The tradeoff is fewer features, such as limited device redirection, so heavy users should use the full client.
Connect From a Phone or Tablet
Install the iOS or Android client, sign in with your work account, and select your workspace. Phones work for checking an app or approving a task, but they are a poor fit for long sessions.
Pro Tip: I give users a one-page instruction sheet with the client name, workspace name, and the help desk number. It removes most “which app do I download?” tickets.
Admin Setup: Give Users Access the Right Way
Access to published resources is controlled with Azure RBAC, which assigns permissions through roles instead of broad administrator rights. See what RBAC is. Users need the Desktop Virtualization User role on the application group.
Assign it to a group, not to individuals, so onboarding is one group change. First sign in to Azure CLI with az login, then run:
az role assignment create \
--assignee <entra-group-object-id> \
--role "Desktop Virtualization User" \
--scope <application-group-resource-id>This command grants the members of an Entra group the right to see and launch what the application group publishes. --assignee is the group’s object ID, --role is the built-in role name, and --scope is the full resource ID of the application group. The scope limits the permission to that one application group, which follows the principle of least privilege. If you need to check who can do what, see how to check your role in the Azure portal.
Next, confirm that session hosts are healthy. With Azure PowerShell, after connecting through Connect-AzAccount:
$ResourceGroupName = "rg-avd-prod-eastus"
$HostPoolName = "hp-office-prod"
Get-AzWvdSessionHost -ResourceGroupName $ResourceGroupName `
-HostPoolName $HostPoolName |
Select-Object Name, Status, AllowNewSession, SessionGet-AzWvdSessionHost lists the session hosts in a pool. The Status column should read Available. AllowNewSession shows whether the host accepts new users; if it is false, the host is in drain mode, which admins use for maintenance. Session shows how many users are connected. You can learn more in the Azure PowerShell tutorial.
If a host will not boot, see Azure VM not starting.
Pro Tip: I use Entra groups named after the application group, such as
avd-office-users. When an auditor asks who can reach a desktop, I answer with one group, not a spreadsheet.
Secure the Connection
Connecting to a corporate desktop should be easy for the right person and hard for everyone else.
Identity and MFA. Use Conditional Access policies to require MFA, block risky sign-ins, and limit which devices can connect. Test every policy with a non-admin account before rollout. If sign-in fails unexpectedly, check the Conditional Access policy that applies to the user.
No public RDP. Users connect through the Azure Virtual Desktop service, which uses outbound connections from session hosts, so you do not need to open inbound RDP port 3389 to the internet. Keep network security groups locked down; see NSGs in Azure. Session hosts still need outbound access to the required Azure Virtual Desktop service endpoints, so blocking all outbound traffic breaks registration.
Redirection settings. Clipboard, drive, and printer redirection move data between the user’s device and the session. Disable what you do not need, especially for regulated data.
Secrets. Do not put domain-join passwords or local admin passwords in scripts. Store them in Azure Key Vault. For a baseline checklist, see Azure security best practices.
Logging. Send diagnostics to Azure Monitor so you can see connection errors and sign-in activity; read what Azure Monitor does. Alert on repeated failed connections or hosts that stop reporting.
Pro Tip: I once found a Conditional Access rule that blocked every guest user from the web client by accident. Testing with one account per user type (employee, contractor, guest) catches this before launch.
Control Cost Without Breaking Connections
Session hosts cost money while they run, so many teams shut them down overnight. That creates a new connection problem: the first user in the morning finds no available host.
The Start VM on Connect feature solves this. It lets a deallocated session host start automatically when a user tries to connect. It needs the Azure Virtual Desktop service to have permission to power on VMs in your subscription, and the user waits a few minutes for the VM to boot. Pair it with scaling plans for busy hours. If you prefer simple schedules, see Azure VM auto-shutdown.
Test the cold-start experience yourself. A host that takes five minutes to boot may be fine for a one-off user but not for a call center starting at 8 a.m., where you should pre-warm hosts instead.
Pro Tip: I schedule a small number of hosts to start 30 minutes before t