Forum Discussion
ARM WVD SID lookup
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:
CCing michawets
as you have helped me before with this 🙂
- PavithraT
Microsoft
AlexPawlak 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.
PavithraT 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 🙂
