Solutions for WVD client not connecting

[khan95osu]

I, and it seems many others, have had issues connecting to windows virtual desktop after provisioning seemed successful. This manifests with the web client giving errors after opening port, or with the desktop client saying something went wrong and a vague explanation.

Turns out there are a few rules that must be followed that aren’t mentioned anywhere I looked.

1) the user you are logging in with must be from the local AD or from the AADDS ... NOT an AzureAD user. It must be synced but it must originate from local AD. It must be a domain user. You won’t see what the issue it, but it will fail. Your domain controller does the sign in Authentication, but it’s initiated through azure, so it must be synced and visible in azure but actually created in domain. AzureAD users won’t sync back to the domain so that’s why it needs to be created in domain. Remember to add the domain user to the app group via add-rdsappgroupuser as well.

2) you can’t be logged into windows with a different Microsoft account for the desktop client. The new client apparently looks at the windows accounts, and you will see there is no way to change accounts from the desktop client. This is very annoying. Since it’s tied together if you are logged into a personal Microsoft account or one not from your local AD that’s not been added to the appgroup, it will fail. I was testing accounts but I was logged into windows with my personal Microsoft account and it always gave errors. I logged out, and into the local computer account , and the desktop client worked fine. I figured this out because after I removed the additional testing accounts from windows users I got a Login screen but then it still failed with the same “something went wrong” error. This led me to think it might be getting confused because I could have multiple work accounts on computer and the client never asked which to use. Instead of a VM issue it’s just the client isn’t smart enough to ask which account you want to use even after login. Item 3 also led to to realize that it’s getting confused with accounts.

3) use incognito to test web client. Even though I logged out of azure portal, out of my own Microsoft account, etc, the web client kept failing to connect. BUT if I ran incognito it connected. This told me the app isn’t able to distinguish the account I needed to use. Again, my personal account still had a trace somewhere in the browser and this kept causing issues. WVD kept trying to use an account that’s not part of my WVD setup, hence failure. Try incognito.

I hope these items help you out. None of these were made clear and I beat my head for 3 days re-launching WVD VMs and tenants. Turns out the setup was fine the whole time. It’s the WVD clients that suck. The desktop client must have a way to login a user and NOT pull from windows. Or at least give the user a clear error that explain what account it’s trying to log in with. Just telling me what account it tried to used on either the desktop client or webclient would have identified this in an instant. The diagnostics log weren’t clear enough either.

Ultimately Please just separated the sign ins. Not everyone wants to use SSO, especially a remote worked on their personal laptop that’s not domain joined, or joined to a different domain.

Hope this helped some people out.

[#2]

@khan95osu : Thanks for taking the time to write this up and contributing back, though we wish that you didn't have to have a lot of struggles to deploy and get end-to-end connections working.

In regards to #1, you are absolutely correct. When looking at the docs, where would you expect to find that information?

In regards to #2, this seems odd because we do allow you to login with the identity you choose to provide, not just your logged in identity. Does this continue to repro?

In regards to #3, this is primarily a function of browsers and Azure AD. We can try to improve, unfortunately I don't think there's too much we can do, since disabling any sort of web SSO experience would be course-correcting too far.

Again, thank you for writing these up. We'd be happy to make sure this gets reflected in documentation, and in our service to make it easier to use.