AVD host will launch in the app but not in a web browser

If your Azure Virtual Desktop (AVD) resource launches fine in the desktop client but nothing happens when you click it in the web client, it’s almost always one of these:

1) Browser requirements & the correct URL

Use the AVD web client (new URL) in a supported, up-to-date browser. Edge ≥131 / Chrome ≥130 / Safari ≥18 / Firefox ≥128 are supported. Older URLs or unsupported versions can misbehave with no visible error.

https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/connect-windows-cloud-services

Try: open a fresh InPrivate/Incognito window and go to the current AVD web client (ARM) site, then sign in again.

2) Third-party cookies / tracking prevention / pop-ups

Modern browsers increasingly block third-party cookies and some redirects by default. AVD’s web sign-in and feed rely on Microsoft identity cookies and redirects. If they’re blocked, clicking a desktop/app can appear to do “nothing.”

Fix (any one of these usually works):

• Allow third-party cookies (or add exceptions) for Microsoft identity and AVD web client domains (e.g., login.microsoftonline.com, aadcdn.msftauth.net, and the AVD web client domain).

Set Tracking prevention (Edge/Chrome) to Balanced/Standard (not Strict), and allow pop-ups/redirects for the site.

• Clear site data for the AVD web client + microsoftonline.com, then retry in a fresh session. https://learn.microsoft.com/en-us/entra/identity-platform/reference-third-party-cookies-spas

3) Conditional Access (CA) policy blocking only the web path

It’s common to allow the desktop client but accidentally block the web client with a CA policy (e.g., “Require compliant device,” “Require approved client app,” or applying controls to the wrong AVD app IDs). Symptoms can be a silent failure after clicking.

Checks:

In Entra Sign-in logs, filter by the user and time of your web attempt; review the Conditional Access tab to see what policy blocked it.

• Ensure you don’t target the “Azure Virtual Desktop Azure Resource Manager Provider” app with MFA/controls (it should not have MFA). Verify policies target the correct AVD app IDs and that browser access isn’t inadvertently blocked. https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access

4) Network / firewall or proxy blocking AVD web endpoints or WebSockets

The web client uses HTTPS/WSS to AVD gateways and service endpoints. If your corporate firewall/proxy blocks required FQDNs or WebSockets over 443, the click can be a no-op.

Action: allow the required AVD FQDNs/endpoints (service tag/URL list) and ensure egress to *.wvd.microsoft.com et al. If you use a proxy, follow the AVD proxy guidelines.

https://learn.microsoft.com/en-us/azure/virtual-desktop/required-fqdn-endpoint

Quick “Try this first”

Open Microsoft Edge (latest), InPrivate window.

1. Go to the current AVD web client site and sign in again.
2. In browser settings for that site: allow third-party cookies, ensure pop-ups/redirects aren’t blocked, and set tracking prevention to Balanced/Standard.

Retry launching the desktop/app.

1. If still nothing: check Entra sign-in logs for CA policy blocks, and ask your network team to confirm required AVD endpoints are allowed (including WebSockets).

If you need to gather evidence

Open F12 Developer Tools → Console/Network while you click the resource; note any 401/403 or blocked cookie messages.

Capture the sign-in event from Entra logs and the browser console error, then share both with your AVD/Identity admin.

Most common fix we see lately: enabling third-party cookies (or adding exceptions) for the AVD web client and Microsoft identity domains; recent browser changes make this more strict by default.

I'm experiencing a similar issue, but with additional details that might help narrow down the problem:

My Scenario:

• Multiple RemoteApps published in the same workspace
• All apps display correctly in the web client at https://client.wvd.microsoft.com
• Only ONE app is clickable/launches successfully
• The remaining apps do nothing when clicked (no response, no error dialog, no visual feedback)
• All apps work perfectly in the Windows Desktop Client and Windows App

Troubleshooting Steps Attempted:

• Tested in private/incognito browser windows (rules out cache/cookies)
• Tried different browsers: Edge (Chromium), Chrome, Firefox - same behavior in all
• Tested both on and off VPN
• Verified pop-up blockers are disabled for *.wvd.microsoft.com and *.avd.microsoft.com
• Checked user permissions and role assignments (Desktop Virtualization User role correctly assigned)
• Created separate workspaces with one app per workspace - NO EFFECT, issue persists even with single apps in isolated workspaces
• Tested with different user accounts - same problem
• Verified Application Group types are consistent (all RemoteApp type)

Browser Debugging Results: Using browser Developer Tools (F12) Console, I found:

• An "Uncaught" JavaScript error in Microsoft's web client code (main.5c027af2.js:2)
• The error lists multiple app names simultaneously, suggesting the web client's JavaScript is failing when attempting to process RemoteApp launches
• Also seeing an unrelated RDP camera redirection configuration warning

Configuration Details:

• Azure Virtual Desktop environment with hybrid Azure AD join
• Multiple Application Groups assigned to workspace(s)
• Same users, same apps, same host pools - everything works flawlessly in native Windows clients
• Issue is 100% reproducible and consistent in web client

Conclusion: This appears to be a bug or architectural limitation in the AVD web client's JavaScript code when handling RemoteApp launches. The fact that isolating apps into separate workspaces doesn't resolve the issue suggests the problem is in the web client's core RemoteApp launching mechanism, not in how apps are organized.

The desktop clients handle the exact same configuration without any issues, which confirms the backend AVD infrastructure and app publishing configuration are correct.

Questions:

1. Has Microsoft acknowledged this as a known limitation or bug in the web client?
2. Is there any workaround besides directing all users to native desktop clients?
3. Are there specific Application Group settings or properties that improve web client compatibility?
4. Should this be escalated as a support ticket with Microsoft?

Any guidance would be greatly appreciated, as the web client is an important access method for users who cannot install native clients.

Hi Randy C,

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. 

Regards,

Shraddha

Just to add that my organisation is having the same issue, we have 3 hostpools and from the webclient two of them do not respond to being clicked on, exactly as described by Randy C. I have tried different browsers, devices (both personal and corporate) and users with the same result. I have found that the 'Windows App' works correctly and all 3 hostpools are accessible, so it does seem to be focused on the webclient. This was certainly working fine last week, seems to have stopped either over the weekend or Monday.

Regards,

Martyn