ARM WVD SID lookup

[Aleksander Pawlak]

Hello!

I just ran through ARM deployment of WVD and I think there has been a difference in technical account implementation. Previously V1.0 release it was enough for local UPN to match Azure AD, without specifically requiring AD Connect Sync between RDS domain and AAD tenant. I am managing a handful of AAD only (Cloud-first) deployments and exploring configuration options from  there on.

I have created AD domain with the same UPN as my AAD tenant, added myself to the WVD apps, but I'm getting errors: 

Source	RDAgent
	Code	1332
	CodeSymbolic	ConnectionFailedNoMappingOfSIDinAD
	Message	No mapping between account names and security IDs was done

I have went to RDOperation TSF log files and converted them,  C:\Windows\System32\config\systemprofile\AppData\Roaming\Microsoft\Monitoring\Tables , 

and found the error stack: 

Microsoft.RDInfra.Shared.Common.RestError.RestException: Could not resolve UPN from SID ---> Microsoft.RDInfra.Shared.Common.RestError.InnerRestException: Could not resolve UPN from SID ---> Microsoft.RDInfra.Shared.Common.RestError.InnerRestException: No mapping between account names and security IDs was done

Would that mean now that On-premises SID is queried against Azure AD in this configuration? If these are not synced, they won't match. Is AAD Connect now a hard requirement? "Manual syncing" of UPNs and passwords no longer seem to work as discussed previously:

https://techcommunity.microsoft.com/t5/Windows-Virtual-Desktop/AD-Sync-not-strictly-required/m-p/873...

CCing @michawets 

 as you have helped me before with this :)

[#2]

@Aleksander Pawlak Do you need AD for any other purpose other than for WVD (meaning the apps do not have any AD dependency)? If so did you explore using Azure AD Domain Services? The manual approach is error prone and so not recommended. Between the non-ARM and ARM environments, this has not changed. The VM registration path and usage remains the same. So I suspect you would see the same issue if you used the account with the non-ARM environment.

[#3]

@Pavithra Thiruvengadam thank you for reply! I'm well aware of AADDS, however for scenarios where I'm helping micro and small businesses AADDS provides a price tag a bit too high for them. What I found was most cost efficient so far was to simply deploy single DC, create Host Pool node, install an app, promote host pool node to DC, and decom the old DC. This way Host pool is its own AD authority and the only one SMB needs - especially when virtualising a single app or two. I really wish to live to day when AAD Joined devices (servers and desktop alike) are first class citizens in Windows / Windows Server / RDS realm. Maybe somewhere in 2028 :)