SOLVED

[Announcement] Connectivity issues from synchronized users to VMs joined to AAD DS

Microsoft

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:

Locate where the Azure AD user is sourced.Locate where the Azure AD user is sourced.

79 Replies

@Christian_Montoya 

 

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

@CraigSmith87 : Where was that recommendation made (to not match your AAD tenant name)?

@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.

No other steps will be necessary, aside from setting the pool to be a validation pool. I will keep you all updated on this thread.

@Christian_Montoya 

 

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?

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.

@antonywm

Once a user is messed up in this state, it is completely impossible to correct the situation yourself.

You can get into this state in many many different ways, ranging from AADC/AADS hybrid deployments, to recreating a deleted user, to using a Microsoft account to sign in, to moving from one AAD tenant to another.

The mechanism WVD uses for user info persistence is fundamentally unstable and unsound and it seems that no one on the Microsoft team has understanding of Azure AD (or maybe the Azure platform as a whole).

@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..

best response confirmed by Eva Seydl (Microsoft)
Solution

@Christian_Montoya : A fix has been rolled out to production for this issue. 

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.

@Eva Seydl great news! Things are working now. Thank you!

@Eva Seydl

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.

 

 

 

Hi,
This fixed it for us to. After it was implemented everything started working without having to do anything.

Cheers,
Rich

@rdoorduin : For this scenario, I recommend filing a support ticket, as the fix that was rolled out should cover all of the standard cases.

@Christian_Montoya 

 

What is the fix. Can you please share the details. What needs to be done to resolve this issue. Please explain.

 

 

 

Thanks

@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?