no resources showing up for user with the Windows App

Question

no resources showing up for user with the Windows App

JohnSebastian-3934 581

I have two users who sign into the Azure Subscription with the Windows App but no resources show up at all. I have confirmed that these users belong to an Entra ID Group that is assigned to the desktop for my host pool.

In our environment, we have two different Entra ID tenants that we deal with. One is our corporate Entra ID identity provider and the other is specifically an Entra ID tenant tied to the project that these two users are trying to get to the Azure Virtual Desktop in that Entra ID tenant.

I'm guessing that the Windows App utilizes the default browser for the users when they log into the Entra ID tenant. We have seen many instances where browsers are hanging on to credentials or pointers to the incorrect Entra ID tenant. If these users are connected to our corporate Entra ID tenant via their default browsers, and at the same time they start the Windows App and successfully log in with our specific Project's Entra ID credentials, no resources show up for them in the Windows App. Could this be caused by the default browser for these user accounts somehow holding on to the corporate Entra ID tenant credentials?

We have an enormous amount of difficulty with browsers when using multiple Entra ID tenants and I'm wondering if Windows App is somehow affected by this as well?

Anonymous

2026-01-13T18:53:26.06+00:00
Hello @JohnSebastian-3934

Please ensure that the following steps have been completed for any users who are unable to access the resources:

In the Azure portal, navigate to AVD VM > Access Control (IAM) > Role Assignments, and confirm that the entra group (which includes the users) has been assigned either the Virtual Machine User Login or Virtual Machine Administrator Login role.

Verify that the RDP property targetisaadjoined:i:1 has been added to the AVD host pool. To check this, go to the Azure portal > select the host pool configured for Azure AD Join > RDP Properties > Advanced Tab > add targetisaadjoined:i:1.

Disable security defaults by going to Entra ID > Manage > Properties > Manage Security Defaults > set to disable.

Add Conditional Access policies to exclude the VM from MFA by including the user.

Additionally, confirm there are no network restrictions that could impact access to AVD. You can use the following tool to check if any required AVD endpoints are blocked: https://learn.microsoft.com/en-us/azure/virtual-desktop/check-access-validate-required-fqdn-endpoin…

[Run this tool on any session host VM by logging in with local admin credentials to verify connectivity and access]

Lastly, make sure the users are using the latest version of the Windows App.
JohnSebastian-3934 581 Reputation points

2026-01-13T19:20:27.18+00:00

Thank you for your message. These same users can access the AVD using the Remote Desktop Client App. So the users already setup properly to connect to the AVD. It's the behavior of the Windows App that is strange. They installed the Windows App (because the other client is being retired), logged in with their same credentials but then the Windows App shows no resources whereas the Remote Desktop Client App shows the resources just fine.
Zachery McEachin 0 Reputation points

2026-05-12T18:43:26.59+00:00

Was there ever an answer to this? I have the same exact thing happening for one of my end users. Can access the resource just fine in the web client but not the Windows app..
JohnSebastian-3934 581 Reputation points

2026-05-12T21:37:49.96+00:00

I am sad to say that we never resolved this. Several other users eventually were able to see the resources in their feed. I'm not sure what they did but probably a combination of browser cache emptying and rebooting of devices. I have one user who was never able to get this working. Unfortunately she decided that she didn't want to do what MS Support was suggesting to help troubleshoot so I gave up on her. She uses the web interface instead.

3 answers

Your answer

Anonymous

2026-01-13T18:53:26.06+00:00

Hello @JohnSebastian-3934

Please ensure that the following steps have been completed for any users who are unable to access the resources:

In the Azure portal, navigate to AVD VM > Access Control (IAM) > Role Assignments, and confirm that the entra group (which includes the users) has been assigned either the Virtual Machine User Login or Virtual Machine Administrator Login role.

Verify that the RDP property targetisaadjoined:i:1 has been added to the AVD host pool. To check this, go to the Azure portal > select the host pool configured for Azure AD Join > RDP Properties > Advanced Tab > add targetisaadjoined:i:1.

Disable security defaults by going to Entra ID > Manage > Properties > Manage Security Defaults > set to disable.

Add Conditional Access policies to exclude the VM from MFA by including the user.

Additionally, confirm there are no network restrictions that could impact access to AVD. You can use the following tool to check if any required AVD endpoints are blocked: https://learn.microsoft.com/en-us/azure/virtual-desktop/check-access-validate-required-fqdn-endpoin…

[Run this tool on any session host VM by logging in with local admin credentials to verify connectivity and access]

Lastly, make sure the users are using the latest version of the Windows App.
JohnSebastian-3934 581 Reputation points

2026-01-13T19:20:27.18+00:00

Thank you for your message. These same users can access the AVD using the Remote Desktop Client App. So the users already setup properly to connect to the AVD. It's the behavior of the Windows App that is strange. They installed the Windows App (because the other client is being retired), logged in with their same credentials but then the Windows App shows no resources whereas the Remote Desktop Client App shows the resources just fine.
Zachery McEachin 0 Reputation points

2026-05-12T18:43:26.59+00:00

Was there ever an answer to this? I have the same exact thing happening for one of my end users. Can access the resource just fine in the web client but not the Windows app..
JohnSebastian-3934 581 Reputation points

2026-05-12T21:37:49.96+00:00

I am sad to say that we never resolved this. Several other users eventually were able to see the resources in their feed. I'm not sure what they did but probably a combination of browser cache emptying and rebooting of devices. I have one user who was never able to get this working. Unfortunately she decided that she didn't want to do what MS Support was suggesting to help troubleshoot so I gave up on her. She uses the web interface instead.

Answer 1

VPHAN 42,485 Independent Advisor

Hi JohnSebastian-3934,

You are correct to be frustrated. The new Windows App relies on "Identity-First" auto-discovery which frequently fails in complex B2B multi-tenant scenarios where the manual "Subscribe with URL" feature was essential. Although the Classic Client is being deprecated, the hard End of Support date is not until March 2026, meaning you have over a year of safe, supported use. The new app fails here because it assumes your home identity will automatically advertise your guest links, a process that breaks easily under specific Conditional Access policies or tenant configurations. Since you confirmed the Classic Client works perfectly, the robust technical solution is to keep these specific users on the Remote Desktop (Classic) client (MSRDC). The new Windows App currently lacks the feature parity to handle your cross-tenant setup reliably without the manual "Add" options. If you are forced to use the new app, the only potential workaround is signing out completely and attempting to "Switch Organization" via the profile menu, though this is often inconsistent. For now, treat the Classic Client as the production-ready tool for this specific use case and delay migration until the new app matures.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

JohnSebastian-3934 581 Reputation points

2026-01-26T15:15:50.6366667+00:00

Thank you for the information. What I don't know from your answer or any of these Q&A forms is: Are Microsoft Development Engineers aware of this? I never know who the people answering these post are. If they are official Microsoft representatives or just people from the community. Do I need to actually open a ticket with Microsoft Support to get the attention of the developers of the Windows App? Are they working on features to fix this glaring problem with the windows app? Do you even know? Are you representing Microsoft Development? Also, I hope the date that you posted (March 2026) is a typo and you really meant March 2027. Can you clarify?
VPHAN 42,485 Reputation points Independent Advisor

2026-01-26T15:34:13.8766667+00:00

to answer your questions:
1/ Are Microsoft Development Engineers aware of this? - yes.

2/ Who am I? I am not a Microsoft employee, nor do I represent the Microsoft Development Team. You may know about the people commenting from their tittle.

3/ Do you need to open a ticket? - Absolutely, posting on forums does not create a "Business Impact" metric for the engineering team.

4/ Is the "March 2026" date a typo? - no, it is not a typo. Microsoft has officially set the End of Support date for the Remote Desktop Client (MSI version / MSRDC) to March 27, 2026.

VP

Answer 2

VPHAN 42,485 Independent Advisor

Hi JohnSebastian-3934,

We need to verify the Azure Virtual Desktop (AVD) resource linkage and then force the client to look at the correct feed.

1. Verify Workspace Association (Most Common Cause): The Application Group must be explicitly registered to a Workspace for the resources to appear in the feed.

Navigate to the Azure Portal > Azure Virtual Desktop > Application Groups.

Select the Application Group where the users are assigned.

Look at the Workspace property in the Overview blade.

If it reads "Not assigned," click Assignments or Workspace in the sidebar and register the Application Group to the target Workspace. Without this link, the feed returns an empty list, regardless of user permissions.

2. Verify Group Assignment Level

Go to Application Groups > Select the specific group (e.g., DAG-Project) > Assignments.

Confirm the Entra ID Group containing those two users is listed here.

Note on Nested Groups: If you are using nested groups (Group A inside Group B), ensure that Azure AD Connect or the Entra definition supports the nesting for the claim token. Direct user assignment is the best test to rule this out.

3. Client-Side: Bypass Discovery Cache

In the Windows App, do not use the standard "Subscribe" button (which relies on the user's primary identity or email domain discovery).

Instead, select the ellipsis (...) or Add > Workspaces > Subscribe with URL.

Enter the standard ARM feed URL: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery

When prompted for credentials, ensure the users enter their Project Tenant credentials. This forces the client to query the feed directly against the authenticated token of the Project tenant, bypassing any default "Home" tenant assumptions the OS might have made.

4. Clear WAM Cache (If persistence continues) If they still see nothing after the above steps, the Windows Account Manager might be holding a stale token.

Close the Windows App.

Delete the following folder: %LocalAppData%\Packages\Microsoft.RemoteDesktop_8wekyb3d8bbwe\LocalState (If using the Store app) or check %LocalAppData%\Microsoft\Remote Desktop for the classic client.

Remove any stored credentials for the Project tenant from Credential Manager > Windows Credentials.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

JohnSebastian-3934 581 Reputation points

2026-01-13T23:58:01.03+00:00

Hi VP,

Thank you for the message. #1 and #2 are all correct in the environment.

For #3, I don't understand what you are talking about. In my Windows App application, there is no Subscribe button. When I start the app, it presents a login screen, I log in to the Tenant with my credentials and then the feed is refreshed and resources are presented to me. There is no ... or subscribe button. Can you elaborate?
VPHAN 42,485 Reputation points Independent Advisor

2026-01-14T08:24:33.98+00:00

It sounds like you are using the new Windows App (the unified client recently released to replace the classic Remote Desktop client). The interface is indeed different, and the "Subscribe" button has been replaced by a different flow.

it seems the issue is that the Windows App is performing "Auto-Discovery" against the user's Home Tenant (Corporate) instead of the Project Tenant where the resources actually live. Even if they log in with the correct credentials, the app defaults to querying the tenant where the account was originally created.

We need to manually point the app to the Project Tenant's feed.

In the new Windows App interface, please follow these exact steps to bypass the default discovery:

Locate the "Add" Function:

Look for a Plus (+) icon, usually located in the top-right corner of the app window.

If you do not see a + icon, look for a button labeled Add or Add to your list (often appearing when the main area is empty).

Add a Workspace Manually:

Click the + (or Add) button.

Select Workspaces (sometimes labeled Add Workspace or Admin-assigned).

Do not enter the email address immediately if it asks for one. Look for a field or link that says "Enter a URL" or "Subscribe with URL".

Enter the following specific ARM feed URL: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery

Click Add or Next.

Authenticate correctly:

The app will now prompt for credentials.

Have the user sign in. If they are a Guest (B2B) user in the Project Tenant, they must ensure they are authenticating into the Project Tenant context.

If the user has a distinct account for the Project (e.g., ******@project.com), use that.

If the user uses their Corporate credentials (******@corporate.com) to access the Project tenant as a Guest, they might simply need to complete the MFA prompt.

Verify Resources:

Once this URL is added, the app allows the "Project Tenant" to publish its resources to the client. You should see a new section appear with the icons for the Session Hosts/Apps.
JohnSebastian-3934 581 Reputation points

2026-01-14T14:33:56.4033333+00:00

Thank you for your message but have you actually looked at the new Windows App Client interface? I see no way to click Add anywhere.
VPHAN 42,485 Reputation points Independent Advisor

2026-01-18T14:14:40.2966667+00:00
It is very likely you are looking at the Home tab of the new Windows App, which focuses on "pinned" or "recent" apps and often hides the configuration buttons.

If the users are logging in and seeing a successful interface load but an empty list, we need to move them away from the default view to force the connection to the correct tenant.

Please guide the users (or yourself, if testing) through these specific UI checks:

Switch to the "Devices" Tab

On the left-hand navigation bar (or bottom rail on some versions), click on Devices (icon looks like a computer monitor).

The Home tab usually shows nothing if no resources have been launched yet.

Once on the Devices tab, look at the top-right corner. You should see a + (Plus) button or an Add button.

If found: Click + > Workspaces > Subscribe with URL and use the feed URL: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery

Check the Account/Tenant Switcher: If there is absolutely no "Add" button, the Windows App might have automatically signed them in with their "Corporate" identity and assumed that is the only one that matters.

Click the Profile Picture (usually top-left or top-right).

Look for an option that says Switch organization or a dropdown arrow next to the tenant name.

Since these users are likely "Guest" users in the Project Tenant, they must explicitly switch the context of the app to that Project Tenant. If the Project Tenant is not listed, you must use the URL method (Step 1) to register it.

The Ultimate Test: Use the Web Client If the App interface is proving difficult or inconsistent, bypass it completely to confirm the permissions are actually working. This separates "App confusion" from "Account permissions."

Have the user open a browser (Edge/Chrome) in InPrivate/Incognito mode.

Navigate to: https://client.wvd.microsoft.com/arm/webclient/ (or the new URL https://windows.cloud.microsoft/)

Crucial: When signing in, if they are prompted to choose a "Personal" or "Work" account, choose Work.

If they are a Guest, they might need to use the tenant-specific URL to force the login into the Project Tenant: https://client.wvd.microsoft.com/arm/webclient/?tenantId=<Project-Tenant-ID-Here>

If the resources appear here, the issue is purely the Windows App caching the wrong tenant. If they don't appear here, the issue is back to Step #1/#2 (Entra Group/Workspace assignments) in your previous troubleshooting.
JohnSebastian-3934 581 Reputation points

2026-01-21T21:14:48.69+00:00

On my version of Windows App I have a Favorites, Devices, Settings and Feedback options on the left hand side of the screen. When I go to Devices, there is NO + or Add option anywhere on the screen.
VPHAN 42,485 Reputation points Independent Advisor

2026-01-22T01:34:25.1166667+00:00

it's likely you are using the Windows App (Store/Preview version). Microsoft has streamlined this interface significantly, and they have removed the direct "Subscribe with URL" button from the main view for many users, relying instead on identity-based auto-discovery.

Since the "Add" button is missing for you, we cannot force the URL feed manually in the main view. We must either switch the identity context or use the classic client which still supports manual configuration.

In the Windows App, if you are a Guest user (using your Corporate email to access a Project tenant), the app will default to your Corporate "Home" view, which is empty. It does not automatically poll the guest tenants. Look at the Title Bar or the Navigation Pane for your Profile Picture or initials. Click your Profile Picture. Look for a menu option that says Switch Organization or Directories. If you see the Project Tenant listed there, select it. The app will reload the "Devices" tab using the Project Tenant's context, and the resources should appear.

Before we spend more time fighting the App's UI, we must confirm that the account actually has the resources visible when the correct tenant is queried. This rules out all server-side issues.

Open a browser in Private/Incognito mode.

Navigate to: https://windows.cloud.microsoft/ (The new unified web portal) OR https://client.wvd.microsoft.com/arm/webclient/

If prompted, sign in with the user's credentials. If you are a Guest, you may need to force the tenant context by appending the Tenant ID: https://client.wvd.microsoft.com/arm/webclient/?tenantId=<Project-Tenant-ID>

If resources appear here: The permissions are 100% correct. The issue is strictly the Windows App client caching the wrong tenant. Proceed to Step 3.

If resources do NOT appear: Stop troubleshooting the client. The issue is back to the Entra Group or Workspace Assignment (Step 1 & 2 from my first reply).
JohnSebastian-3934 581 Reputation points

2026-01-22T20:16:32.53+00:00

Isn't the Classic Client going away and we are all being forced to this new Windows App? Are there plans for supporting users in environments where they have accounts on Multiple Tenants that they access from the host on which the Windows App runs? Has anyone even thought of this issue on the Development Team before releasing the new Windows App UI while at the same time communicating to users that they have to switch to an app that doesn't work?

I know that this account has the resources available to them because when they use the classic client, everything works just fine. The Azure Virtual Desktop for the correct tenant is available to them to connect to.

Answer 3

Yes, the issue you're experiencing with users not seeing resources in the Windows App could indeed be related to how the default browser is managing credentials for multiple Entra ID tenants. When users are logged into their corporate Entra ID tenant in their default browser, it may interfere with their ability to access resources in the specific project’s Entra ID tenant through the Windows App.

Here are some steps you can take to troubleshoot this issue:

Check User Assignments: Ensure that the users have been correctly assigned to the application groups in the project’s Entra ID tenant. You can confirm this by using the PowerShell cmdlet:
```
   Get-AzRoleAssignment -SignInName <userupn>  
```
Browser Cache: Clear the browser cache or use an incognito/private browsing mode to prevent the browser from using cached credentials from the corporate Entra ID tenant.
Correct Credentials: Make sure users are signing in with the correct credentials for the project’s Entra ID tenant when using the Windows App.
Group Type: Verify that the user group in the project’s Entra ID tenant is a security group, as Azure Virtual Desktop does not support distribution groups.
Reassign Users: If the users were recently moved from one tenant to another, you may need to reassign them to their application groups in the new tenant.

By following these steps, you should be able to resolve the issue and ensure that the users can see their resources in the Windows App.