Unable to Login to Azure Virtual Desktop Session host

In this post, I will show you the steps to fix errors when you are unable to login to Azure virtual desktop session host. If you have recently set up an Azure Virtual Desktop (AVD) environment and are attempting to log in to a session host through the Windows app or the web client, you may encounter the following error messages.

Starting March 27, 2026, the Remote Desktop client for Windows (MSI) will no longer be supported. Users should begin migrating to Windows App to ensure continued access to their Azure Virtual Desktop and Windows 365 resources after this date.

Error 1 – Gateway error in web client

When attempting to connect to an Azure Virtual Desktop system through a web browser, you may see:

Oops, we couldn’t connect to “SessionDesktop”. We couldn’t connect to the gateway because of an error. If this keeps happening, ask your admin or tech support for help.

This usually indicates an issue with:

  • The way the client is allowed to authenticate to an Entra joined session host.
  • Azure Virtual Desktop gateway connection problems.
  • Conditional access, network, or TLS configuration blocking the connection.
Oops, we couldn't connect to SessionDesktop

Error 2 – Sign in failed, check username and password

You might also get below error when trying to connect to your azure virtual desktop.

Oops, we couldn’t connect to “SessionDesktop”. Sign in failed. Please check your username and password and try again.

Typical causes include:

  • The device you are connecting from is not joined or registered to the same Entra tenant as the session host and has not been enabled using the targetisaadjoined:i:1 setting.
  • The user is not assigned to the application group for the host pool.
  • The user does not have the required Virtual Machine User Login role on the session host or its resource group.
  • Conditional Access or MFA policies are blocking the Azure Windows VM Sign-In enterprise application.
Oops, we couldn't connect to "SessionDesktop". Sign in failed. Please check your username and password and try again.

Error 3 – Error code 0x3000047 in Windows App

When you are using Remote Desktop client or Windows app, you may get an error code 0x3000047 when connecting to the session host. Below is the exact error information:

An error occurred while accessing this resource. Retry the connection or contact your system administrator.

  • Error Code: 0x3000047
  • Extended error code: 0x0

This error is often associated with:

  • The gateway being unable to establish a session with the host (routing or broker issues).
  • A problematic or unhealthy session host in the pool.
  • Domain / join problems on that session host.
  • The Entra joined authentication path being misconfigured for the client device type. Go to Fix 4 – 0x3000047 for more details.
Error Code: 0x3000047

Error 4 – Error code 0x3000046 in Windows App

This message means the AVD broker could not find a usable session host for your connection. In other words, from the service’s perspective, there are “no available resources” for that host pool, even if you can see VMs in Azure.

Common causes include:

  • When using Start VM on Connect, the platform is unable to start the VM because the start-on-connect role or permissions are misconfigured.
  • All session hosts in the pool are Stopped / deallocated, Unavailable, or in drain mode.
  • In a personal host pool, the user is not correctly assigned to a session host.
  • The session host has lost its registration / connection to the host pool (broken side-by-side stack listener, corrupt registration token, etc.). Go to Fix 5 – Fix error 0x3000046 in the Windows App for more details.

Requirements for Connecting to Entra Joined AVD Session Hosts

For Microsoft Entra joined session hosts, Microsoft documents the following requirements for clients when using the Windows Desktop client with legacy authentication (no SSO). For more information, refer to the link: Microsoft Entra joined session hosts in Azure Virtual Desktop – Azure Virtual Desktop | Microsoft Learn.

Your local PC must be one of the following:

  1. Microsoft Entra joined to the same Entra tenant as the session host, or
  2. Microsoft Entra hybrid joined to the same Entra tenant as the session host, or
  3. Running Windows 11 or Windows 10, version 2004 or later, and Microsoft Entra registered to the same tenant as the session host

If your local PC does not meet one of these conditions, or you are using the web, Android, iOS, or macOS clients, you must configure the host pool to accept username and password based connections by adding the targetisaadjoined:i:1 RDP property.

In addition, for Entra joined VMs, you must:

  • Assign users to the Azure Virtual Desktop application group.
  • Assign users the Virtual Machine User Login role (or admins the Virtual Machine Administrator Login role) on the VM, its resource group, or the subscription.

If any of these pieces are missing, users will not be able to log on to the session host even though the pool and workspace look healthy.

Fix 1 – Verify Device Join State and Basic Requirements

Start by verifying the client device meets one of the supported states:

  1. On the local Windows PC, go to Settings > Accounts > Access work or school and open Connected to <tenant> details.
  2. Check Entra joined, Entra Hybrid joined, or Entra registered state.

If the device is not joined or registered to the same Entra tenant as the session host, you have two options:

  • Join or register the device to that tenant (recommended for corporate devices), or
  • Keep it unjoined and use targetisaadjoined:i:1 as described in the next section, which allows username and password sign-in without Entra join.

Also confirm:

  • The user is assigned to the Desktop application group for the host pool.
  • The session host is available and SxS Healthy in the Azure Virtual Desktop portal.

Fix 2 – Add targetisaadjoined:i:1 RDP property

To enable access from Windows devices that are not joined or registered to the same tenant and from web, Android, macOS, and iOS clients, add the targetisaadjoined:i:1 custom RDP property to the host pool.

Microsoft’s Entra joined AVD documentation states that:

  • If the local PC does not meet the join / register conditions, you must add targetisaadjoined:i:1.
  • For web and non-Windows clients, this property is required to connect to Entra-joined session hosts.
  • These connections will use the RDSTLS protocol and are restricted to username and password credentials.

Steps to add targetisaadjoined:i:1 to the host pool

  1. Sign in to the Azure portal at https://portal.azure.com.
  2. Go to Azure Virtual Desktop > Host pools and select your host pool.
  3. In the host pool menu, select RDP properties.
  4. Go to the Advanced tab.
  5. In the RDP properties text box, add a semicolon if there are existing properties, then append: targetisaadjoined:i:1 For example, if you already had custom properties, it might look like: drivestoredirect:s:*;targetisaadjoined:i:1 (as shown in the screenshot).
  6. Save the changes.
targetisaadjoined:i:1

Once this is configured, try connecting again from:

  • A non-Entra joined Windows device using the Windows App, or
  • The web client, iOS, Android, or macOS clients.

If you are using Conditional Access with MFA, make sure the Azure Windows VM Sign-In enterprise application is not being blocked by a policy. Microsoft explicitly recommends excluding this app from certain CA rules for Entra joined AVD, especially when using RDSTLS with targetisaadjoined.

Fix 3 – Assign Virtual Machine User Login role

Even if the connection reaches the session host, users cannot sign in to an Entra joined VM unless they have an appropriate RBAC role. For non-admin users, assign the Virtual Machine User Login role. For admins who need local admin rights, use Virtual Machine Administrator Login.

You can assign the role on:

  • Each VM individually.
  • The resource group containing the session hosts (recommended).
  • The subscription (for wider scope, not typical in smaller labs).

Steps to assign Virtual Machine User Login role

  1. Sign in to the Azure portal.
  2. Go to Resource groups or Virtual machines, depending on the scope you prefer.
  3. Select the resource group or VM that hosts your AVD session hosts.
  4. In the left menu, select Access control (IAM).
Virtual Machine User Login Role
  1. Click Add > Add role assignment.
  2. Search for and select the Virtual Machine User Login role.
Virtual Machine User Login Role
  1. On the Members tab, add:
    • An Entra security group that contains your AVD users (recommended), or
    • Individual users for testing.
  2. Click Review + assign to finish.
Virtual Machine User Login Role

Repeat the same steps with Virtual Machine Administrator Login if you need to grant admin access to a support or engineering group. After assigning the role, wait a few minutes and try connecting again. This typically resolves cases where users see sign-in failures or 0x3000047 on otherwise healthy Entra joined session hosts.

Fix 4 – Check Session host health, domain state, and routing for 0x3000047

If you still see Error 0x3000047 after fixing device join, RDP property, and RBAC, check the session host and gateway side:

  • Confirm the session host shows as Available and Healthy in Azure Virtual Desktop.
  • Verify the VM can reach the internet and AVD service endpoints (NSG rules, firewalls, and DNS). Refer to the post for more details: Cannot connect with RDP to a Windows VM in Azure – Virtual Machines | Microsoft Learn.
  • For domain-joined scenarios, some organizations have fixed 0x3000047 by unjoining and rejoining the VM to the domain or by removing a problematic host from the pool.
  • If you suspect a single bad host, temporarily remove that host from the host pool and test again.

Use the diagnostics and logs for Azure Virtual Desktop and the session host to see detailed error codes and broker messages when connections fail.

Fix 5 – Fix error 0x3000046 in the Windows App

Perform below checks to fix the error code 0x3000046 you may get when connecting to an Azure virtual desktop session host.

  • Check host pool and session host status:
    • In the Azure portal, go to Azure Virtual Desktop > Host pools > <your host pool> > Session hosts.
    • Make sure at least one session host shows Status = Available and Allow new sessions = Yes.
    • If all hosts are Stopped, Unavailable, or in Drain mode, start at least one VM and set Allow new sessions to Yes.
  • Confirm the user is assigned (personal host pools): For personal host pools, each user must be assigned to a specific session host.
    • On the host pool, check the Assignments / Session hosts blade and verify that the affected user is assigned to a desktop.
    • If needed, fix the assignment using PowerShell using below code:
Update-AzWvdSessionHost `
  -HostPoolName       "<hostpool-name>" `
  -Name               "<sessionhostname>" `
  -ResourceGroupName  "<rg-name>" `
  -AssignedUser       "user@domain.com"

After correcting the assignment, wait a few minutes and try connecting again from the Windows app.

  • Check UPN consistency and logon permissions: For Entra-joined / hybrid scenarios, inconsistent UPNs can cause 0x3000046 when users try to connect to their personal desktop:
    • Ensure the user’s UPN in on-prem AD matches the UPN in Entra ID.
    • Make sure the user is in the Remote Desktop Users group on the session host (or has equivalent access via group policy / local groups).
  • Validate Start VM on Connect (if used): If you rely on Start VM on Connect, 0x3000046 can appear when the VM is stopped and the platform cannot start it automatically.
    • In the host pool, check that Start VM on Connect is enabled.
    • Verify that the identity used for Start VM on Connect has the correct RBAC permissions (for example, a custom role containing Microsoft.Compute/virtualMachines/start/action and read assigned at VM or resource group scope).
    • As a test, manually Start the VM from the Azure portal and then connect again from the Windows app. If manual start works but Start VM on Connect fails, focus on fixing the RBAC/identity configuration.
  • Check if the session host is still properly registered: If the host VM appears Unavailable or continuously throws 0x3000046 even when running, its registration with the host pool may be broken. Common fixes include:
    • Restart the RDAgentBootLoader and Remote Desktop Agent Loader services on the session host.
    • If that does not help, remove the VM from the host pool and re-add it using a fresh registration token (or recreate the session host from your image).
  • Check capacity and scaling: In pooled host pools, you can also see 0x3000046 if:
    • All hosts have reached their maximum sessions limit, or a scaling plan has put all hosts into drain mode / shut them down at that time.
    • Review the current sessions per host and any scaling plan attached to the host pool to ensure there is capacity when users attempt to sign in.

Conclusion

In this blog post, we’ve discussed various errors that can occur when connecting to Azure Virtual Desktop and provided solutions to help you resolve them. If you’re still unable to resolve the issue after trying these solutions, it’s recommended that you open a support ticket with Microsoft for further assistance.

1 thought on “Unable to Login to Azure Virtual Desktop Session host”

  1. I have an issue related to this but the system is not AzureAD joined or registered. It is also not hybrid. The registered apps are on systems in their own domain and have an rds server that manages user cals. FOr some reason, our test user can attempt to access apps successfully since it gets prompted for credentials BUT any other user fails immediately.

    Reply

Leave a Comment