Jul 17 2019 03:09 PM
Hi everyone, thanks for the continued testing of WVD. We’ve seen multiple connection errors with UPN when connecting to VMs joined to Azure AD Domain Services. We’ve done some preliminary investigations and figured out which scenarios are currently affected and which scenarios should continue to work.
Works
Logging into VM joined to Azure AD DS instance with Azure AD user sourced from Azure Active Directory (aka, New user created just in Azure AD).
Does not work (and investigating fix)
Logging into VM connected to Azure AD DS with Azure AD user sourced from Windows Server AD (aka, synchronized to Azure AD through Azure AD Connect).
You will see an error in the Diagnostics similar to below:
ErrorSource : RDBroker
ErrorOperation : OrchestrateSessionHost
ErrorCode : -2146233088
ErrorCodeSymbolic : ConnectionFailedUserSIDInformationMismatch
ErrorMessage : OrchestrateAsync: SID value in the database is different than the value returned in the
orchestration reply from the agent for user ≤user1@contoso.com≥ with Id
54a45a4c-41ad-4374-5e41-08d6e4d9acde. This scenario is not supported - we will not be able to
redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 7/16/2019 3:17:24 PM
Workaround
If your setup matches the description but you would still like to test, we suggest creating cloud users in Azure Active Directory for the time being.
Resolution
No current ETA, but working towards a fix.
How to check where your user is sourced from
You can navigate to the Azure AD portal or the Azure Active Directory blade in the Azure portal, then go to users:
Oct 03 2019 05:02 PM
@Christian_Montoya thank you for the update :)
Oct 05 2019 09:19 AM
I am still experiencing this same issue you explain above with AADDS, however even when I create a Cloud native user I get the following error when trying to connect to Virtual Desktop / RemoteApp:-
ErrorSource : RDAgent
ErrorOperation : AddUserToRDUGroup
ErrorCode : -2147467259
ErrorCodeSymbolic : ConnectionFailedAdErrorNoSuchMember
ErrorMessage : Failed to add user = ≤Cloud.User@teammetalogic.com≥ to group = Remote
Desktop Users. Reason: Win32.ERROR_NO_SUCH_MEMBER
ErrorInternal : False
ReportedBy : RDGateway
Time : 05/10/2019 17:05:32
Windows Virtual Desktop DNS name - azure.DOMAIN.com was initially created because recommendation was to not have conflicting DNS names with tenant, which is DOMAIN.com
Oct 07 2019 10:28 AM
@CraigSmith87 : Where was that recommendation made (to not match your AAD tenant name)?
Oct 13 2019 05:45 AM
@Christian_MontoyaThank you for the updates. Will there be any additional steps for us to perform if we already have the host pools with validation set to true? Hopefully your target of this month remains on track, I have 2 clients that I would like to migrate to WVD as it, at least from the outset, looks to out perform their existing Citrix environment and a much lower cost.
Oct 14 2019 10:49 AM
Oct 19 2019 02:58 PM
I'm still encountering the issue. On 9/11, you wrote:
We've completed step #1 completely and #2 is what we're implementing/validating now. We expect this to complete and rollout within the next month.
So, we're 5 weeks out from there now and there is still no fix...and it seems like it's not even available in validation environments yet. Is this correct?
You also decided to go GA with a product that can't support basic usage (deleting a user account and recreating it...or just renaming a user)...
I would really like to understand what's going on here. Is there any update here?
Oct 23 2019 05:49 AM - edited Oct 23 2019 05:51 AM
Hi,
would like to add to this thread. I also have deployed WVD in view of rolling it out for our business but when I try and add new user directly to AAD (we have no AADC sync) it is failing with error:
ErrorSource : RDBroker
ErrorOperation : OrchestrateSessionHost
ErrorCode : -2146233088
ErrorCodeSymbolic : ConnectionFailedUserSIDInformationMismatch
ErrorMessage : User xxx@xxx.net: SID information in the database 'S-1-5-21-1382006385-1486747441-1399156625-1111' does not match SID information returned
by agent 'S-1-5-21-1382006385-1486747441-1399156625-1129' in the orchestration reply.. This scenario is not supported - we will not be able
to redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 23/10/2019 12:48:50
@Christian_Montoya: Would appreciate idea of when this will be fixed. Like @jeffb8 and others, I've tried everything (even deleting, adding user) but nothing works.
Oct 25 2019 11:11 AM
Oct 31 2019 06:38 AM
@Christian_Montoya last day of the month. Any news?
I can add that this does not work with accounts sourced from local AD when converting users to cloud by disabling AD-connect either..
Nov 04 2019 12:36 PM
Solution@Christian_Montoya : A fix has been rolled out to production for this issue.
Nov 05 2019 03:44 AM
Fantastic!! I just successfully logged into a desktop session on an account that was previously not working due to the SID issue, no reconfiguration required beforehand, literally just tried the login again and it worked perfectly.
Nov 07 2019 01:03 AM
Nov 07 2019 12:01 PM
@Eva Seydl great news! Things are working now. Thank you!
Nov 13 2019 05:19 AM
Hi Eva, unfortunately this fix did not resolve our sign-in issues. It did change the error code.
We have migrated all our users to Microsoft 365 Business (synced from AD to Azure AD and afterwards removed Azure AD Connect) then configured AADDS and WVD.
We can succesfully signin on the Microsoft Remote Desktop application and from there we can connect to our WVD Hostpool. When entering username and password the Remote Desktop seems to initiate the connection but keeps prompting for username and password, without any error.
Get-RdsDiagnosticActivities states the following:
ActivityId : ##########-f64b-405f-a79a-###########
ActivityType : Connection
StartTime : 13-11-2019 12:46:03
EndTime : 13-11-2019 12:46:11
UserName : user@domain
RoleInstances : computername;≤≥
Outcome : Success
Status : Completed
Details : {[ClientOS, WINDOWS 10.0.18362], [ClientVersion, 1.2.431.19493], [ClientType, com.microsoft.rdc.win
dows.msrdc.x64], [PredecessorConnectionId, ]...}
LastHeartbeatTime : 13-11-2019 12:47:43
Checkpoints : {TransportConnecting, TransportConnected, RdpStackDisconnect, OnCredentialPromptInvoke...}
Errors : {}
We also tried: Set-RdsHostPool -TenantName XX -Name XX -ValidationEnv $true
I'm not sure where to look from here.. What fix has been rolled out? Are there any specifics about this fix?
btw newly created users seem to work ok. so only the synced user have this issue.
Nov 13 2019 06:38 AM
Nov 13 2019 07:35 AM
@rdoorduin : For this scenario, I recommend filing a support ticket, as the fix that was rolled out should cover all of the standard cases.
Nov 25 2019 01:51 PM
What is the fix. Can you please share the details. What needs to be done to resolve this issue. Please explain.
Thanks
Mar 31 2020 03:23 AM
@Christian_Montoya Hi Christian, hope you are all well? Came a cross this topic and was curious if the fix is already live? This thread is handeling the exact situation we have implemented. a combination of users sources from Windows server AD and Azure AD. Everything is working for us and both user types are able to login.
Before we go to production, could you confirm that this scenario is supported?
Mar 31 2020 02:45 PM
@Robin_Kluijt : Yes, this scenario is supported.
Mar 31 2020 11:27 PM
@Christian_Montoya Thanks.