Share via

URI Launch trouble "TenantDiscoveryFailed"

Crogger 0 Reputation points
2026-04-04T00:04:31.4666667+00:00

The format I'm using is
ms-avd:connect?resourceid=[appgroupID]&workspaceid=[workspaceID]&version=0&username=[userUPN]
The above URI works with both MSRDC and WindowsApp if I replace the appgroupID with the resource ID of an application within the group, but critically, it does not matter which application ID I use. I can take the ID from any of 50+ Applications in the Application Group because the hostpool is of type "Personal", so it will always direct the user to their own node/application ID based on the UPN, NOT the resourceID defined in the URI.

For this reason I think the appropriate resource ID to use should be that of the application group, not the application. The resource ID of the individual application is, after all, not honored in the case of "Personal" hostpools. But when I use the ID of the app group as described in the URI above, that is when I get the TenantDiscoveryFailed error. I also tried the resource ID for the hostpool just in case but got the same error

The reason this is relevant to me is that the individual nodes/applications are ephemeral, meaning they get removed and/or replaced by Terraform somewhat regularly. Whenever this happens, the resource ID of the application changes but the application group ID and hostpool ID are always the same, and the UPN is always consistent. What I've done for now is I've created an extra node/application in the group that is 'assigned' to a dummy user's UPN. I just never allow that one to get deleted, that way I have an Application ID within the group (that doesn't change) to distribute. It is a dumb hack and I also don't like keeping an otherwise idle VM in the group for no other purpose than having a consistent applicationID, especially when the applicationID doesn't even matter for establishing connections through a "Personal" hostpool

I haven't found any documentation stating you have to use the application ID specifically, and the fact that the param is called "resourceid" instead of something more specific like "applicationid" suggests that it is not intended to be limited to applications

Azure Virtual Desktop
Azure Virtual Desktop

A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Nikhil Duserla 9,860 Reputation points Microsoft External Staff Moderator
    2026-04-08T14:17:58.6066667+00:00

    Hello @Crogger ,

    It turns out the ms-avd:connect URI’s resourceid parameter isn’t meant to point at the App Group or Host Pool itself, but at an individual Application resource under that App Group. When you plug in the App Group’s resource ID (or the Host Pool’s), the AVD client goes off to Azure AD looking for a service principal or discovery endpoint that doesn’t exist—hence the TenantDiscoveryFailed error.

    What you should do is:

    1. In the Azure portal, navigate to your Host Pool → Application Groups → select your App Group.
    2. Click Applications and locate the Desktop (or RemoteApp) entry that was created as part of that group.
    3. Copy its Resource ID, which looks like: /subscriptions//resourceGroups//providers/Microsoft.DesktopVirtualization/applicationGroups//applications/
    4. Use that full resource ID in your URI: ms-avd:connect?resourceid=/…/applications/desktop&workspaceid=&version=0&username=

    Because the “Desktop” application is part of every AVD personal host pool and has a stable resource ID, you’ll never have to spin up a dummy VM just to keep an application ID around.

    Hope that clears things up!

    – Tom

    P.S. A quick checklist in case you still see TenantDiscoveryFailed: • Make sure your session hosts are AAD-joined and successfully registering. • Confirm you’re on a recent version of MSRDC or the Windows App (1.2.4066+). • Verify you copied the application resource ID (not the group or host pool).

    Reference docs: • Troubleshoot Azure Virtual Desktop service connections: https://learn.microsoft.com/troubleshoot/azure/virtual-desktop/troubleshoot-service-connection • Windows 365 Store App deep‐linking overview: https://supportability.visualstudio.com/WindowsVirtualDesktop/_wiki/wikis/WindowsVirtualDesktop/724285/Features/AVD%20Clients/Windows%20365%20Store%20App • AAD connectivity for AVD (“TenantDiscoveryFailed” often means the client can’t resolve AAD endpoints): https://learn.microsoft.com/troubleshoot/azure/virtual-desktop/troubleshoot-azure-ad-connections?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider

    Was this helpful?

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-04-04T00:04:47.0866667+00:00

    The ms-avd:connect URI currently requires the resourceid parameter to be the ID of a published resource (desktop or RemoteApp application), not the application group or host pool. Using the application group or host pool resource ID leads to TenantDiscoveryFailed, which matches the behavior described.

    From the documented URI scheme, resourceid is treated as the identifier of the specific resource the client should launch, while workspaceId identifies the workspace:

    ms-avd:connect?workspaceId=<workspaceId>&resourceid=<resourceId>&username=<userUPN>&version=0

    There is no support documented for using an application group ID or host pool ID in place of the application (RemoteApp) or desktop resource ID. The parameter name resourceid is generic, but in practice it must be a resource that the client can enumerate and launch from the workspace feed, which is why an individual application ID works and the application group ID does not.

    For personal host pools, even though the specific VM/session host is chosen based on the user’s UPN, the launch still targets a specific published resource (desktop or app) in the feed. That is why any valid application ID in the group works, but non-resource IDs (app group or host pool) fail.

    Given the current documented behavior and limitations of the URI scheme, the workaround of maintaining at least one stable application resource ID in the application group is consistent with how the client expects resourceid to be used. The platform does not expose a way (via ms-avd:connect) to launch purely by application group or host pool ID while relying only on UPN for routing.

    If avoiding an extra VM is important, consider:

    1. Publishing a single “utility” RemoteApp in the application group that is not tied to a dedicated VM but is part of the same personal host pool pattern, and using its resource ID as the stable resourceid.
    2. Automating URI regeneration and distribution whenever Terraform recreates the applications, so that a current application resource ID is always used.

    However, both approaches still rely on the fundamental requirement that resourceid be a valid published resource in the workspace.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.