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

Christian_Montoya would be great to get an update on when this will be fixed - we were happily using this with this setup then in abruptly broke and we've been investigating on and off as time allowed ever since.

Now i stumbled across this issue (after finally figuring out how to debug what was going wrong). Do we have an ETA as this is now a total block on us using WVD.

I'm really disappointed as this is the 2nd major stumbling block - we've fully adopted Azure AD and the lack of support for Azure AD join is the other one.

This can be such a good solution it's just so frustrating.....

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

Christian_Montoya 

I know before the post that Cloud ID only is working but that is not valid for our production POC

i been testing with cloud ID only and that works , further more the issue with synced account, it looks like recently (because this was working before) you doing  SID check between the azure synced account and the account in azure DS and that will not match. i'm wondering if the scenario without azure DS , i mean extending AD to the cloud and join the virtual desktop machines to the same domain will have the same issue or not for synced user account.

Christian_Montoya 

Hi Christian,

I seem to be experiencing the exact same error in a test environment. However, the user is sourced from Azure Active Directory.

I would be happy to help troubleshoot since I have clients looking forward to WVD. below is some info that might be relevant and if you need identifying tenant info I'll be happy to send via PM:

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 ≤username≥ with Id <id>. This scenario is
not supported - we will not be able to redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 7/28/2019 14:17:15

TenantName : IC-WVD2
TenantGroupName : Default Tenant Group
HostPoolName : Desktop
FriendlyName :
Description :
Persistent : False
CustomRdpProperty :
MaxSessionLimit : 999999
LoadBalancerType : BreadthFirst
ValidationEnv : True
Ring :

Hi,

We have just noticed the same problem in our test environment.

But a strange thing is that it only affects one of the 17 pilot users.

The users were synced from a local AD to Azure AD.

Azure AD connect sync was removed 1 year ago.

Azure AD services was setup to support the WVD environment.

Users envolved in pilot had to reset their passwords and could then logon.

But now, one user gets the error message:

SID value in the database is different than the value returned in the orchestration reply from the agent for user...

The Hostpool is in "validation" 

<#

#>

Christian_Montoya  Same issue for one of test Azure-born user, the second one (Azure-born as well) still works fine.

Hola Christian_Montoya, 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 https://rdweb.wvd.microsoft.com/webclient/index.html 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 : F21212121@fvl.org.co
RoleInstances : rdwebclient;mrs-eus2r0c002-rdgateway-prod-staging::RD2818788A5384;mrs-eus2r0c001-rdbroker-prod-staging::RD2818782C7086;≤WVDSH-0.fvl.org.co≥
Outcome : Failure
Status : Completed
Details : {[ClientOS, Win32 Chrome 76.0.3809.100], [ClientVersion, 1.0.18.5], [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

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

 /Mr-Tbone

/Torbjörn

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