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


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.



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 ≤≥ 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



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.



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

@MrTbone_se : As it stands now, the issue stems from the SID's being synchronized as part of the Azure AD token and then receiving a different one through Azure AD Domain Services. Are you aware of any difference of properties between this 1 user and the other 16?

@Arthur GERARD : Azure AD Join is in our backlog. We've heard overwhelming interest for this, and we want to align with Azure AD Join/Intune as a means of deploying and managing Windows. We don't have any specific dates on this, but we definitely want to supporting this as a scenario down the road.

Thank you for keeping us informed!
Thanks. Is there an eta for when a fix will be available to host pools in validation mode?

If not, is there any way to submit a support request to get you to delete stale user accounts from your sql azure database or is this exposed in any way? It would at least allow us to proceed with testing if there was a way to recreate the user accounts with problems. As I mentioned above - today we can’t even delete/recreate the user. It has to be created as a cloud only user with a different upn...

Hola @christianmontoya, thanks for the information.


In my case, the scenario and behavior are the following:


I have an Active Directory On-Premise synchronized to Azure Active Directory through ADConnect. In Azure I have implemented an Azure Active Directory Domanin Services (AADDS). Both directories are synchronized (ADDS and AADDS) through the AAD. I have password hashes replication set. I implemented a WVD HostPool.


To perform tests with my synchronized users, I have also created Cloud users (AAD only).


Both types of users allow me to connect the most virtual machines of the WVD HostPool through RDP. However, when I try to use the WebClient through the URL both types of users can log in with their AADDS and AAD credentials. But by selecting applications to log in to them, only users created in the cloud (in AAD) can successfully start; synchronized users from ADDS get the error from the following image:




The log error for synced users is the follow:


ActivityId : e5eaa99a-0873-4e39-9063-d39e511c0000
ActivityType : Connection
StartTime : 12/08/2019 5:09:12 p. m.
EndTime : 12/08/2019 5:09:18 p. m.
UserName :
RoleInstances : rdwebclient;mrs-eus2r0c002-rdgateway-prod-staging::RD2818788A5384;mrs-eus2r0c001-rdbroker-prod-staging::RD2818782C7086;≤≥
Outcome : Failure
Status : Completed
Details : {[ClientOS, Win32 Chrome 76.0.3809.100], [ClientVersion,], [ClientType, HTML], [PredecessorConnectionId, ]...}
LastHeartbeatTime : 12/08/2019 5:09:19 p. m.
Checkpoints : {LoadBalancedNewConnection, TransportConnected, TransportConnecting}
Errors : {Microsoft.RDInfra.Diagnostics.Common.DiagnosticsErrorInfo}


Is the same error that you are describing in this post?


Thanks a lot for your response.


Paul Pedroza





any updates? we are hard blocked in terms of using Windows Virtual Desktop

@christianmontoyaI have checked with every powershell cmdlet i can think of, but the users are identical configured. I have compared with another user that was hired at the same time (2014). And also has been migrated from an onprem AD to an Azure AD only environment. The ad connect was removed a year ago ish. The Azure Domain Services was setup to support WVD preview in June.

My user is on vaccation and I cannot get an answer if it still is an issue or if it has been solved by agent update.


But, you should think of a rollback of the sid verification and do a rearchitect.
If it is so much trouble for preview users, how will this work for GA?

/Mr T-Bone

@christianmontoya  Any update on this  ? As others have reported we are at a stand still. 
Synced from on-premise aren't working.  I have tried validation pools and still no luck with Sync accounts. 



Seems like we’re in store for a repeat of Azure RemoteApp.

@christianmontoyaAnother week without status update?

Any progress of getting the WVD working again for all of us with Azure DS?


I have only one user out of 30 pilots that get sid failure?

  • Cannot see any different attributes on this specific user compared with another user created same week.
  • Both accounts created 3 years ago in a local AD.
  • Synced to Azure AD with AD connect.
  • Local AD and Azure AD connect dismounted and retired 12 month ago.
  • Azure DS started for WVD 3 months ago.




@MrTbone_se  @cititechs  @jeffb8 : Thanks for being patient with us. As an update, we've identified the issue and have taken the first step to solving it, just that's a multi-phase fix/roll-out.


Also, to address some of the feedback, in order to login users and work between cloud/on-prem accounts, there are only so many interfaces and returned values that the system gives us for logon. And, unfortunately, it wasn't as easy as rolling back because then we would then have other sets of users be unable to reconnect to existing sessions.


Will hope to have another update soon regarding the full fix.

@jeffb8 : Just to get more clarity, is it primarily this issue that you think will make it the next Azure RemoteApp? Is there other functionality that we're missing, should be focusing on, or should be fixing?

Hi @christianmontoya ,


The validation pool seems like a good idea (


However to make that really viable we need a schedule of upcoming releases to know when we should be validating (and potentially what specific areas to check). Is that something that is also going to be published?


Some control of when updates are pushed would also be very useful - for example if we find an issue during validation can we prevent that being pushed to our environments or would if just get pushed anyway after some timeout period?




@christianmontoya- one other thing to just mention - we recently had some other issues with AADDS and in conversations with the product group there they told us there is a new version of the sync process planned (quite soon I think) from AAD to AADDS - not sure if this helps you in any way with the issues you have - perhaps if you have any requirements for changes these could be included in what that team is doing?

@Richard Harrison : Great questions! We definitely intend to push out notice of things coming out the validation pool so it can be tested. We have done this in limited capacity and to smaller groups of customers, but we intend to use this more. We have also not pushed a build all the way to the general population due to issues we've seen in validation, so we plan on using it exactly like you're expecting.


And thank you for the notification. Will bring this up with the Azure AD DS team.

@christianmontoya I have deleted and re-created my WVD test environment several times, now I can't longer log in even with users created directly in the Azure cloud, with these accounts, the users before could login. I can no longer log in with synchronized users from my AD On-Premise (ADDS -> AAD -> AADDS) nor with the old ones created directly in Azure (AAD -> AADDS). I can only use the scenario if I create new users in Azure.


ErrorSource : RDBroker
ErrorOperation : OrchestrateSessionHost
ErrorCode : -2146233088
ErrorCodeSymbolic : ConnectionFailedUserSIDInformationMismatch
ErrorMessage : User wahtever@whatever: SID information in the database 'S-1-5-21-1201331163-3862359571-1670876360-8430' does not match SID information returned by agent
'S-1-5-21-1194805571-575163812-3500997978-1549' in the orchestration reply.. This scenario is not supported - we will not be able to redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 28/08/2019 3:24:57 p. m.


This issue specifically is **extremely** concerning - because this isn’t an edge case; this is a fundamental architecture/database design problem in how you uniquely identify users.

You don’t need to get AAD Domain Services or any other complicated scenario in the mix to reproduce this problem. All you need to do is delete **any** user in **any** kind of environment and then create a new one with the same upn. And bam, that user is screwed...forever.

Deleting and recreating the tenant doesn’t help any, which tells me that user registration data is stored independently of tenant data. This will lead down an avenue of problems with no end. There are alternative architectural approaches that would likely be more reliable.

@jeffb8 @christianmontoya 


I can attest this! It seems like a flaw in design.


What happend to me is the following:

I had a user in my old Azure AD tenant. lets call it tenant A, with a UPN of and used WVD succesfully there.


Now I moved my to another Azure AD tenant, tenant B. Setup Azure ADDS there and tried to login with a user with UPN, so the exact same UPN of the user that existed in tenant A. although offcourse it doesn't exists in tenant A anymore.

What I saw when I logged in, was the WVD tenant with the published desktops that I created in my Azure AD tenant A! AND I saw my new WVD tenant with the published desktops that I created in my Azure AD tenant B.


Now, when I tried to sign-in to the desktops from the new tenant B, I get the same error as everyone else, that the SID doesn't match with the one in the database. 

Yes, I can understand that it doesn't match if you still saved the SID from the user in tenant A. But this is a completely new user in tenant B.


Just like JeffN825 already concludes, this means that the user data is independent from the tenant data, which seems strange to me.

Also, I would like some way to delete my old user with its SID from this backend database.



With each day that passes with no meaningful reply on this issue, I become more skeptical that the right team (one with extensive experience in distributed, AzureAD based authentication and authorization) is working on this product. I also wonder if the lack of/delay in reply is indicative of the team taking a pause to re-evaluate if they can successfully develop this solution...?


Is there any information you can provide that might alleviate this concern? 

I'm trying to add users from a 'invited user' source or from an 'external aad' source to a remoteapp group using powershell. I notice that only users created directly in AAD can be added, but externals or invited ones cannot. I keep getting the error  "The specified UserPrincipalName does not exist in the Azure AD associated with the RD tenant.".


Can anyone confirm if these external users or invited users should work with WVD?