07-17-2019 03:09 PM
07-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.
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 ≤firstname.lastname@example.org≥ 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:
09-11-2019 02:20 PM
@Marcel A' Campo - external users can't work with WVD because they are not replicated via Azure AD Domain Services to the managed AD domain.
09-11-2019 02:30 PM
This issue a showstopper for us. We're trying to roll out VDI for thousands of users globally.... but the inability to automate handling of multiple security identifiers is a bit deal.
Glad I encountered this now, instead of 2 months from now when a single user identity will exist in AADDS, AzureAD, and ADDS.
09-11-2019 02:54 PM
To provide an update, we're still working on this fix. As alluded to before, the fix is 2 steps:
1. To create and populate the fields
2. To adjust the logic to use these fields
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.
This may still seem like a long time out, but we do want to be more cautious on the rollout and ensure we don't break user connections like the changes we made that landed here. There is always an option to push straight to production, but that also doesn't help us if there's another case that we missed and if we did quick validation.
Ultimately, we realize that this has led to the inability to quickly test out the service using Azure AD DS. Once the fix is live, you should be quickly unblocked, re-start efforts to evaluate the product as you need, and hope to see continued feedback as you have been so far on TechCommunity so far.
We will post back here as we progress further in the fix and when we have this available in the validation pools to test.
09-12-2019 12:31 PM
Another month - alright. Still paying for the actual resource (that doesn't work)...have been for several months now. This has become very disappointing. Standstill - Business Units waiting on the solution - complaining about chargebacks for the resource (that doesn't work) will be the next thing.
Please guys - get this fixed.
09-13-2019 05:09 AM
Hi @christianmontoya , is there any news on this?
This is a hard block for us as well!
09-13-2019 08:17 AM
09-18-2019 04:41 AM
@christianmontoya thanks for the update.
We are waiting to deploy WVD with Azure AD DS and if I understand correctly it will be possible once the second fix is rolled out? We have host pools set as "Validation" host pools, can we hope to get the fixes out sooner to these hostpools?
09-19-2019 10:01 AM
@Joakim Westin - I wouldn't count on this fixing the underlying issue. From the description of the fix, it sounds like it will just work around it for some situations.
09-19-2019 10:31 AM
@jeffb8 : Essentially, there are three pieces of information we need for processing the new or reconnecting user connection:
1. UPN in Azure AD token
2. SID in Azure AD token
3. SID that the on-premises domain sends back when it matches up the user
Everything is based according to the UPN, as that is provided in all tokens. The fixes will:
1. Update the SID for the UPN (accounts for user migration on premises or new instantiations of Azure AD DS for users sourced in Windows Server AD)
2. Update the SID that the on-premises domain sends back when it matches up the user, which is needed for manual/auto-reconnect scenarios.
We definitely hear feedback on "why SID?", but unfortunately that is needed for current logon APIs if we want to provide a consistent re-connect experience that can get triggered even if you lose Internet connectivity for a brief second or switch wireless networks.
09-23-2019 10:07 PM
09-26-2019 03:53 PM
@jeffb8 : Ultimately, everything is mapped to a UPN so we know how to connect/reconnect them. Regardless of how you get your UPN, we map the resulting SID (that the domain understands relates to that user) back to the UPN.
Also, just to clarify, the Azure AD token is initially acquired by the user for the Windows Virtual Desktop Azure AD application, and we pass this through our system when we need to reference the incoming Azure AD user. We are not trying to silently get one.
09-27-2019 06:40 AM
@christianmontoya do you have any updates on when we can expect to see the fix rolled out for us?
09-27-2019 06:47 AM - edited 09-27-2019 06:48 AM
FYI, i just ditched AADDS and extended the on-premise AD through S2S VPN and DC VMs in Azure instead.
Re-used my TenantGroup, Tenant, and ServicePrincipal.
Template Deployment and user connexion went flawless on the first try.
I would recommend to forget about AADDS if you can.
09-27-2019 07:19 AM
That's not helpful to those of us who would rather not have to deal with ADDS and AD Connect unnecessarily.
09-27-2019 07:27 AM
@DubC85 Maybe i wasn't clear but i went from :
On-prem AD + AADConnect + AADDS (WVD VM being joined to AADDS)
-> was stuck with this bug for several months
On-prem AD + AADConnect + On-prem AD extended to Azure vNet (WVD VM being joined to AD)
-> everything worked on the first try
09-30-2019 04:00 AM
Yep, this works great, and has since the beginning (adding a hostpool that's actually on your on-prem domain and not AADDS joined). I didn't even add a DC out in the Azure vnet - just joined on-prem domain over the S2S tunnel.
I wish I could use that - I would be six months ahead now. The smaller attack surface of available users (filtered sync to AADDS) will be required for us.
10-01-2019 12:07 PM
10-03-2019 01:13 AM
10-03-2019 04:48 PM
No worries though: once the fix is in and live, the scenario will be supported :) We're on still on track for this month. I will post back here once we have it available for validation pools (host pools with "ValidationEnv" set to $true) so that we can confirm the fix before the broadest rollout.