Address VDI and M365 licensing
Hello everyone, this is a requested change for the components of Azure AD machine join. The use case here is for clients to upgrade their existing Windows PC (7,8,10) to Windows 10 enterprise. Our customer base uses VMware's Horizon view for VDI. VMware's official supported license is KMS. Our clients would love to transition to a cloud based licensing model, but the Windows 10 E3 license does not work with the cloning technology for a couple of reasons.
Horizon Cloning options & pool types:
• Manual - VM is not built in Horizon, only brokered through it.
• Full Clone - Full Virtual Machine that are created from a vCenter template. This uses a complete sysprep for the cloning operation
• Linked Clones use QuickPrep - Uses a customized version of sysprep called QuickPrep. Clones in a pool will all share the same SID
• Instant Clones use ClonePrep - Non-persistent only. Uses a customized version of Sysprep called ClonePrep. Clones will have the same SID as the master image. Preserves the GUIDs of applications.
• Non-persistent pools delete and re-create the machine AD object on user logout and login
Azure AD join and Windows 10 E3 activation:
• Hybrid Azure SCP created in AD tenant, Windows 10 machines selected for syncing to Azure
• Machines are domain joined and in an OU syncing to Azure (AAD syncs every 30 minutes)
• Windows 10 E3 licensed user logs into PC meeting the above requirements
• A usercertificate field is created in AD and populated with a unique value for that user
o GUID and SID values must be unique to populate in Azure AD
• Reboot the machine
• Login with the Windows 10 E3 licensed user
• Machine is upgraded from Windows 10 Pro to Enterprise
As the Guid and SID must be unique to sync to Azure, the machines do not join Azure, and the machines are not upgraded to Windows 10 enterprise.
The vast majority of our clients use non-persistent clones in their environment due to the ease of administration, resource consolidation, and other business needs. As such this will not work with the current Azure machine join.
I am unsure of the technical complexity of the changes needed to allow these two technologies to work together. Replacing on prem KMS would be a huge selling point for just about anyone in a VDI environment. We also looked at ADFS/Federation technologies and while it does change the authentication, the activation still fails as the cloning replaces the machine on user log out.
Adjusting the sync time on AAD was also attempted, but this is problematic for organizations with 100,000s of AD objects syncing to O365/Azure.
Allow machines to join Azure on other AD attributes. This can be done in O365 if UPN is unavailable to tie to O365.
Perhaps AAD could sync on a specific OU if a change was detected in that specific group. Once a user logs out and logs in, the change could be synced quickly to the cloud apart from the entire AD sync.
Thanks for the feedback. We’re reviewing our gaps for VDI support, and will address them based on priority
Please reach out to firstname.lastname@example.org to discuss this further