Mar 20 2020 09:53 AM
Mar 20 2020 09:53 AM
I have recently deployed WVD thanks to the current global crisis. It is working well for most of our users, apart from one. When she tries to connect to WVD via the web client, she gets this:
When connecting via the Windows client, she gets this:
As far as I know, she is the only member of staff who gets this. She's using Windows 10 Home on a laptop, has tried multiple browsers and is using a DSL ISP (Sky in this instance).
I've tried running "Get-RdsDiagnosticActivities" but it comes back with "There were no activities found"
Mar 23 2020 11:43 AM
Hi, i'm literally facing the same issue:
Mar 23 2020 08:14 PM
Thanks for the feedback. Any thoughts on what could be different for those user's devices?
For reference, I filed the tracking item for investigation:
Item 25683128 : Reports of error 0x3000047 when connecting to WVD
Mar 24 2020 10:09 AMSolution
@Sergey Osherov I think you are on the right track. Here's what we see internally:
Client gets an Error during Orchestration.
Orchestration failed. Code=0x80075a1e, symbolicCode: E_PROXY_ORCHESTRATION_UNKNOWN_ERROR, message: Failed to add user = ≤USERNAME REMOVED≥ to group = Remote Desktop Users. Reason: Win32.ERROR_NO_SUCH_MEMBER, target: (null):4
Mar 25 2020 06:42 AM - edited Mar 25 2020 06:56 AM
@David Belanger OK, so that's interesting.
/edit Actually, no, somehow she's managed to end up with two accounts in O365, one synced from AD and a cloud account. Of course, she's trying to use the Cloud account to get in. What fun.
Thank you for your help.
Mar 25 2020 09:25 AM
The UPNs must be the same in on-prem DC(-s) and Azure AD.
What we've just done was to:
Make sure the O365 UPN is the same with the User Logon Name in local Active Directory.
Apr 17 2020 05:43 AM
It happens to us as well. I add the user through Graph API. The user can't access it for up to 40 minutes. Then the user is able to log in to the WVD.
May 07 2020 02:22 PM
This solved my problem with a session pool where the VMs were not joined to the Azure AD DS domain, but were in an internal domain, with a separate isolated domain controller on a VM within the same subscription.
May 22 2020 04:23 AM
May 26 2020 06:38 AM - edited May 26 2020 07:23 AM
It happens to us as well:
the user has the same UPN in AD and AAD
the user is member of local Remote Desktop User on the WVD Computer
Any guide to diagnose and fix the problem?
May 28 2020 08:08 AM
Same issue, but at the beginning everythig was OK with the first Hoospool, and now I can´t connect. I created two more pool and with the same result
May 28 2020 11:56 AM
I had a similar issue today in my 2004 lab environeemnt, but i only had to reboot my DC and RDSH server.
I would suggest you to check UPNs in your DC and check the rights.
(Rights are per apps in 2019 deployment types, so if you created a new pool you need to add the same users to the new pool).
Once i did re-subscribed the connection worked.
Hope it help.
Jun 01 2020 10:44 AM - edited Jun 01 2020 10:47 AM
My setup worked fine with the default gallery image (Win10 multi-session with Office ProPlus). I then created a custom image and ran all the time into 0x3000047. Tried reboots and checked my UPN suffixes. All looked good, error persisted.
My custom image was with the brand new Windows 10 2004 with Office 365 ProPlus image. Not sure if it had any thing to do with it. Image was sysprepped, captured and published to the shared image gallery.
My observation was that the Session Host(s) created kept their original computer names. The machine was also joined to the domain with the original name, not rdsh-0 what I expected. I manually renamed the session host and rejoined, this did not help.
Finally decided to recreate my custom image based on Windows 10 1908 with Office. This time it worked fine.
Jun 05 2020 03:23 PM - edited Jun 05 2020 03:24 PM
same issue here - 0x3000047 for W10 2004 - based custom image. Will try 1909 base next week.